工程实践项目中的需求分析建模

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 工程实践中的业务领域建模

收集业务领域信息在第一步的用例建模中已经完成，通过头脑风暴以及分类，能够画出项目的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. 总结

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

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