工程实践项目中的需求分析建模—问答系统后端

1. 前言及项目背景介绍

最近在高级软件工程课上学习了对项目中的需求进行分析和建模的基本方法，本文针对最近在做的工程实践项目，运用所学方法进行用例建模和业务领域建模，以及数据建模，最终形成概念原型，以验证所学知识。

工程实践项目是实现一个类似知乎的问答社区系统（后端），因为有成熟的产品，所以整体来说需求还是挺明确的，本文以自己的角度对系统进行一系列建模分析，以加深对项目的理解。

2. 用例建模

2.1 什么是用例

用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。

用例的几个基本要素：

• 一个用例应该由业务领域内的某个参与者（Actor）所触发。

• 用例必须能为特定的参与者完成一个特定的业务任务。

• 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

2.2 用例建模的基本步骤

1. 从需求表述中找出用例，往往是动名词短语表示的抽象用例；

2. 描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；

3. 对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；

4. 进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。

其中第一步到第三步是计划阶段，第四步是增量实现阶段。

2.3 准确提取用例的基本方法

为了准确地提取用例，我们必须遵循一些原则和方法：

1. 从需求中寻找业务领域相关的动名词和动名词短语，比如做什么事、什么事情必须被完成,或者执行某任务等;
2. 验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件:
   • 它是不是一个业务过程?
   • 它是不是由某个参与者触发开始?
   • 它是不是显式地或隐式地终止于某个参与者?
   • 它是不是为某个参与者完成了有用的业务工作?
3. 在需求中识别出参与者、系统或子系统。参与者会触发某个用例开始，用例也会显式地或隐式地终止于某个参与者，用例属于系统或子系统。

其中第二点中的四个必要条件尤为重要，是我们能否准确识别用例的关键所在。

2.4 工程实践中的用例建模

类似知乎的问答社区需求比较明确，整个系统也只有一个参与角色（用户），用户主要有如下功能：

• 注册登录
• (underline{浏览问题})
• (underline{发布问题})
• (underline{修改})和(underline{删除问题})
• (underline{回答问题})
• (underline{修改})和(underline{删除回答})
• 在个人中心(underline{查看})自己的(underline{活动历史})

根据上述需求，我们可以找出相应的动名词，结合是否满足用例的四个必要条件来提取出用例，用例用下划线标出，基于此，我们可以画出用户的用例图：

3. 业务领域建模

3.1 什么是业务领域建模

• 业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。

• 开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。

3.2 业务领域建模的基本步骤

1. 收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；

2. 头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；

3. 给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。

4. 将结果用 UML 类图画出来。

3.3 工程实践中的业务领域建模

收集业务领域信息在第一步的用例建模中已经完成，经过头脑风暴以及分类，可以将项目的业务领域概念分为以下几类：

• 用户类：拥有属性 ID，用户名，密码，昵称，邮箱，头像等属性
• 问题类：拥有属性 ID，所属用户ID，标题，内容等，一个用户可以发布多个问题
• 回答类：拥有属性 ID，所属用户ID，所属问题ID，内容等，一个用户可以发表多个回答，一个问题拥有多个回答
• 评论类：拥有属性 ID，所属用户ID，上级ID（可以是回答或评论），内容等，一个用户可以发表多个评论，一个回答或评论拥有多个评论

据此可以画出项目的UML类图：

4. 业务数据建模

根据之前的用例建模以及业务领域建模过程，我们可以大致确定项目所需要的数据模型以及关联关系，相应的关系型表设计如下：

• User

列名	数据类型	长度	唯一	非空	注释
id	bigint	20	是	是	用户ID
username	varchar	255	是	是	用户名
password	varchar	255	否	是	密码
nickname	varchar	255	否	否	昵称
email	varchar	255	是	否	邮箱

• Question

列名	数据类型	长度	唯一	非空	注释
id	bigint	20	是	是	问题ID
user_id	bigint	20	否	是	所属用户ID
title	varchar	255	否	是	标题
content	text	1000	否	否	简述
answer_count	int	11	否	是	回答总数
collect_count	int	11	否	是	收藏总数

• Answer

列名	数据类型	长度	唯一	非空	注释
id	bigint	20	是	是	回答ID
question_id	bigint	20	否	是	所属问题ID
user_id	bigint	20	否	是	所属用户ID
content	text	1000	否	是	内容
comment_count	int	11	否	是	评论总数
collect_count	int	11	否	是	收藏总数
view	int	11	否	是	点击量
up_count	int	11	否	是	点赞次数
down_count	Int	11	否	是	点踩次数

• Q-A

列名	数据类型	长度	唯一	非空	注释
id	bigint	20	是	是	主键
question_id	bigint	20	否	是	问题ID
answer_id	bigint	20	否	是	回答ID

• Comment

列名	数据类型	长度	唯一	非空	注释
id	bigint	20	是	是	评论ID
parent_id	bigint	20	否	是	上级ID
user_id	bigint	20	否	是	所属用户ID
content	text	1000	否	是	内容
comment_count	int	11	否	是	评论总数
up_count	int	11	否	是	点赞次数

• A-C

列名	数据类型	长度	唯一	非空	注释
id	bigint	20	是	是	主键
parent_id	bigint	20	否	是	上级ID
comment_id	bigint	20	否	是	评论ID

5. 概念原型及工作过程

5.1 概念原型

• 概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。

• 概念原型是一种虚拟的、理想化的软件产品形式。

• 概念原型 = 用例 + 数据模型

5.2 工程实践项目的概念原型

在之前的分析中已经得出了项目的用例和数据模型，进而可以总结出项目的概念原型工作过程：

用户登录系统后，可以从首页推荐浏览问题列表，或者从热榜查看热门问题，此外，也可以通过分类或者搜索查找自己感兴趣的问题，点击进入问题详情后，可以以一定的排序方式查看该问题的回答列表，可以对回答进行点赞点踩，评论等，当然也可以自己回答问题。首页提供了发布问题的按钮可以发出提问寻求解答。用户可以在在个人中心对个人信息和活动历史进行管理，比如更新自己的联系方式，查找自己曾经回答过的问题等等。

6. 总结

本文运用课上所学的以面向对象分析和设计为思想方法主线，从需求分析到软件设计的基本建模方法，对目前正在实际开发的工程实践项目进行了建模分析。在这个过程中，我不仅复习了课程内容，更对实际项目有了进一步的认识，这将帮助我更好的完成工程实践。

工程实践项目涉及到多人合作，还有很多更细致的方面，我很难在这有限的时间内把它完全的分析出来，仅以个人角度略作分析，难免有疏漏，还望指正。