1 前言
本篇博客基于高级软件工程课程内容，针对自己的工程实践内容（设计一个类似知乎问答系统）来进行用例建模和业务领域建模，以及数据建模，最终形成概念原型。使用的是敏捷统一过程的基本建模方法，从需求分析到软件设计，自我提升码农修养，过程相当酸爽，让我学习到了如何准确有条理地进行需求分析。
参考文献 > 课程ppt
2 需求分析概述---用户是上帝
- 需求就是对用户期望的软件行为的表述；
- 获取需求就是需求分析师通过关注用户的期望和需要，从而获得用户期望的软件行为，然后对其进行表述的工作；
- 需求分析是在获取需求的基础上进一步对软件涉及的对象或实体的状态、特征和行为进行准确描述或建模的工作。
通常我们进行需求分析有两种主要的方法：原型化方法（Prototyping）和建模的方法（Modeling），下面我们采用用例建模的方法对项目进行需求分析。
3 用例建模---逻辑抽象
3.1 用例的概念
用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。用例模型主要由以下元素构成：
- 参与者(Actor) 参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是业务领域内的参与者或者业务实体。
- 用例(Use Case) 用例必须能为特定的参与者完成一个特定的业务任务，用于表示系统所提供的服务。
- 通讯关联(Communication Association) 通讯关联用于表示参与者和用例之间的对应关系。
需满足原则：A use case must end with an actor. 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
3.2 用例的三个抽象层级
- 抽象用例（Abstract use case）。只要用一个干什么、做什么或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例；
- 高层用例（High level use case）。需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么时候什么地方结束；
- 扩展用例（Expanded use case）。需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。
3.3 用例建模的基本步骤
-
从需求表述中找出用例，往往是动名词短语表示的抽象用例；
-
描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
-
对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
-
进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
其中第一步到第三步是计划阶段，第四步是增量实现阶段。
3.4 如何准确提取用例
-
从需求中寻找业务领域相关的动名词和动名词短语，比如做什么事、什么事情必须被完成，或者执行某任务等；
-
验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件：
-
必要条件一：它是不是一个业务过程？
-
必要条件二：它是不是由某个参与者触发开始？
-
必要条件三：它是不是显式地或隐式地终止于某个参与者？
-
必要条件四：它是不是为某个参与者完成了有用的业务工作？
如果以上四个必要条件都满足的话，那么该业务领域相关的动名词或动名词短语就是一个用例。
-
-
在需求中识别出参与者、系统或子系统。
3.5 用例图中的各种关系
1）参与者与用例间的关联关系
2）用例与用例之间的关系
a. 包含关系
b. 扩展关系
c. 泛化关系
3.6 结合工程实践项目进行用例分析
3.6.1 第一步 找出动名词短语表示的抽象用例
类知乎问答系统的参与者主要为用户，类比现有成熟产品可以大致分析出其用动名词短语表示的抽象用例：
-
注册
-
登录
-
修改资料
-
发布问题
-
修改问题
-
浏览问题
-
发布回答
-
修改回答
-
查看回答
-
评论回答
-
赞同回答
-
不赞同回答
3.6.2 第二步 描述用例开始和结束的状态
以注册为例说明：
3.6.3 第三步 画出用例图
4 业务领域建模---专业的人做专业的事
4.1 概念
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知，因此需要该领域方面的人员来进行协助。
4.2 基本步骤
-
第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
-
第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
-
第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
-
第四步，将结果用 UML 类图画出来。
记住：我们是对业务建模，不是对系统建模，关注层面应该集中在业务上！
4.3 结合项目进行业务建模
4.3.1 收集领域信息并分类
在前面对用例进行建模的过程已经对问答系统领域方面的信息有了较为详细的了解，根据需求对概念进行分类，并列出他们的属性如下：
- 用户类：id，用户名，密码，性别，昵称，头像，描述，等属性
- 问题类：id，标题，内容，创建时间，更新时间，所属用户id
- 回答类： id，内容，评论数，赞同数，标签，所属问题id，所属用户id
- 评论类：id，内容，赞同数，对应评论对象id（回答id或评论id），所属用户ID，
4.3.2 画出UML图
5 关系数据建模---数据库建表的参考
根据UML图我们可以很容易地得出主要类的数据模型，各个表的具体内容如下所示：
- User表
| 字段 | 类型 | 非空 | 注释 |
|---|---|---|---|
| id | bigint | 是 | 用户id |
| name | varchar | 是 | 用户名 |
| nickname | varchar | 是 | 昵称 |
| password | varchar | 是 | 密码 |
| gender | varchar | 否 | 性别 |
| avatar_url | varchar | 否 | 头像图片url |
| description | varchar | 否 | 描述 |
- Question表
| 列名 | 类型 | 非空 | 注释 |
|---|---|---|---|
| id | bigint | 是 | 问题id |
| title | varchar | 是 | 题目 |
| content | varchar | 是 | 内容 |
| created_at | varchar | 是 | 创建时间 |
| update_at | varchar | 否 | 修改时间 |
| user_id | bigint | 是 | 用户id |
- Answer表
| 列名 | 类型 | 注释 |
|---|---|---|
| id | bigint | 回答id |
| content | varchar | 内容 |
| comment_num | bigint | 评论数 |
| agree_num | bigint | 赞同数 |
| tag | varchar | 标签 |
| question_id | bigint | 对应问题id |
| user_id | bigint | 所属用户id |
- Comment表
| 列名 | 类型 | 注释 |
|---|---|---|
| id | bigint | 评论id |
| content | varchar | 内容 |
| agree_num | bigint | 赞同数 |
| reply_id | text | 回复对应的id |
| user_id | int | 所属用户id |
注意各个表的外键依赖表现了类之间的关系！
6 概念原型出炉---虚拟的产品
6.1 概念原型的含义
-
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
-
概念原型是一种虚拟的、理想化的软件产品形式。
6.2 仿知乎问答系统项目的概念原型
用户首先要进行账号的注册后方可登录该知乎问答系统。此后用户可以根据自己需求在系统内进行提问，并可@邀请用户回答；用户可以拉链查询现有的问题(根据时间或者热度等排序)或者根据指定关键词or标签进行问题的检索，然后可以就相关问题进行回答。其他用户可以对别人的回答进行评论，点赞，也可对别人的评论进行点赞和回复。
7 总结感悟
对工程实践项目进行完整的需求分析和建模过程之后，深深感受到了需求分析的难处，十分烧脑，如果没有科学的流程指导可能根本难以入手。更体会到了抓住了需求要害等于抓住了用户这个道理，每天有无数产品诞生，也有无数产品陨落，就看谁更能对人性进行精准的把握。