知乎问答系统---从需求到原型

1 前言

? 本篇博客基于课程内容，针对自己的工程实践内容（设计一个类似知乎问答系统）来进行用例建模和业务领域建模，以及数据建模，最终形成概念原型。使用的是敏捷统一过程的基本建模方法，从需求分析到软件设计，自我提升码农修养，过程相当酸爽。

参考文献 > 课程ppt

1 需求分析

? 需求分析就是需求分析师对用户期望的软件行为进行表述，并进一步用对象或实体的状态、属性和行为来定义需求。进行需求分析有两种主要的方法：原型化方法（Prototyping）和建模的方法（Modeling）。本次仿知乎问答系统的项目基本需求为

• 用户可以进行问题、回答的发布和修改（文字）

• 用户可以对问题拉链，支持按热度和时间序排序
• 用户可以进行回答点踩
• 系统可以展示热门问题列表

2 用例建模

2.1 用例的概念

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

• 参与者(Actor) 参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是业务领域内的参与者或者业务实体。

• 用例(Use Case) 用例必须能为特定的参与者完成一个特定的业务任务，用于表示系统所提供的服务。

• 通讯关联(Communication Association) 通讯关联用于表示参与者和用例之间的对应关系。

需满足原则：A use case must end with an actor. 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

2.2 用例的三个抽象层级

• 抽象用例（Abstract use case）。只要用一个干什么、做什么或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例；
• 高层用例（High level use case）。需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么时候什么地方结束；
• 扩展用例（Expanded use case）。需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。

2.3 用例建模的基本步骤

1. 从需求表述中找出用例，往往是动名词短语表示的抽象用例；
2. 描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
3. 对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
4. 进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。

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

2.4 如何准确提取用例

1. 从需求中寻找业务领域相关的动名词和动名词短语，比如做什么事、什么事情必须被完成，或者执行某任务等；

2. 验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件：

   • 必要条件一：它是不是一个业务过程？

   • 必要条件二：它是不是由某个参与者触发开始？

   • 必要条件三：它是不是显式地或隐式地终止于某个参与者？

   • 必要条件四：它是不是为某个参与者完成了有用的业务工作？

? 如果以上四个必要条件都满足的话，那么该业务领域相关的动名词或动名词短语就是一个用例。

3. 在需求中识别出参与者、系统或子系统。

2.5 用例图中的各种关系

1）参与者与用例间的关联关系

2）用例与用例之间的关系

a. 包含关系

b. 扩展关系

c. 泛化关系

2.6 项目的用例分析

3 业务领域建模---专业的人做专业的事

3.1 概念

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

3.2 基本步骤

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

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

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

• 第四步，将结果用 UML 类图画出来。

记住：我们是对业务建模，不是对系统建模，关注层面应该集中在业务上！

3.3 项目的UML图

4 关系数据建模

user表

CREATE TABLE `user` (
 `id` int(11) NOT NULL COMMENT ‘用户ID‘,
 `username` varchar(500) DEFAULT NULL COMMENT ‘用户名‘,
 `password` varchar(500) DEFAULT NULL COMMENT ‘密码‘,
 `create_at` datetime DEFAULT NULL COMMENT ‘创建时间‘,
 `update_at` datetime DEFAULT NULL COMMENT ‘更新时间‘,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

question表

CREATE TABLE `question` (
 `id` int(11) NOT NULL AUTO_INCREMENT COMMENT ‘问题id‘,
 `user_id` int(11) DEFAULT NULL COMMENT ‘问题发布者id‘,
 `title` varchar(500) DEFAULT NULL COMMENT ‘标题‘,
 `content` varchar(2000) DEFAULT NULL COMMENT ‘内容‘,
 `create_at` datetime DEFAULT NULL COMMENT ‘创建时间‘,
 `update_at` datetime DEFAULT NULL COMMENT ‘更新时间‘,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

profile表

CREATE TABLE `profile` (
 `id` int(11) NOT NULL AUTO_INCREMENT COMMENT ‘profile_id‘,
 `user_id` int(11) DEFAULT NULL COMMENT ‘用户id‘,
 `nickname` varchar(500) DEFAULT NULL COMMENT ‘用户昵称‘,
 `gender` int(11) DEFAULT NULL COMMENT ‘性别（0-女，1-男，2-保密）‘,
 `desc` varchar(1000) DEFAULT NULL COMMENT ‘用户简介‘,
 `avatar_url` varchar(1000) DEFAULT NULL COMMENT ‘头像url‘,
 `create_at` datetime DEFAULT NULL COMMENT ‘创建时间‘,
 `update_at` datetime DEFAULT NULL COMMENT ‘更新时间‘,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

外键依赖

profile表和question表中的user_id均依赖于user表中的id

5 概念原型出炉

5.1 概念原型的含义

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

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

5.2 仿知乎问答系统项目的概念原型

用户注册账号成功后登录问答系统，然后可以发布问题，也可拉链查询现有的问题(根据时间或者热度等排序)，然后可以就问题进行回答，并且可以对别人的回答进行评论。

知乎问答系统---从需求到原型

原文：https://www.cnblogs.com/shenghao-leo/p/14078798.html