[架构之路-212]- 需求- UML需求建模：用例图、ER图/概念类图、流程图、序列图、状态机图

前言：

需求规格说明书：

• 用户场景=》用例图
• 场景说明=》用例规约
• 领域模型=》实体关系图/概念类图、流程图、活动图、状态图、时序图

UML是图形化统一建模语言，能够通过图形化的方式为目标系统进行建模，之所以成为统一建模语言，它能够为目标软件系统全生命周期建模，包括：

其中，用例图是源头，代表用户的业务场景需求。

用户场景需要定义：（目标系统）用户场景建模 =》 用例图(动态）

目标系统需求定义：（**目标系统）业务领域建模 **=》 实体关系图/类图、流程图/活动图、时序图、状态图。

备注说明：

• 领域建模与逻辑视图的区别是：前者是需求建模，后者是架构设计。
• 领域建模是对用例视图的补充和进一步的细化，与用例图一起，共同组成了需求模型。

什么是需求建模

所谓需求建模，是指将需求背后的业务、场景，通过建模的方式，进行抽象化的分析和提炼，并进一步完成软件产品的抽象设计工作。

在需求分析工程中，需求建模是需求分析工作中很重要的组成，面临复杂的B端业务，如何进行抽象思维设计，并将其简单有效的呈现出来方便沟通，是软件设计工作中面临的挑战。

很多抽象的概念、思想很难用文字表达清楚，通过图形、图表来描述却很容易让人理解。诞生于20世纪90年代的统一建模语言UML（Unified Modeling Language）就是一种常用的图形化语言，经过多年发展，目前已经是一套成熟的规范和标准，是软件工程师做抽象设计时的有力工具。

UML规范中定义了类图（Class Diagram）、用例图（Use Case Diagram）、对象图（Object Diagram）、时序图（SequenceDiagram）、协作图（Communication Diagram）、状态机图（State Machine Diagram）、活动图（Activity Diagram）、组件图（Component Diagram）、部署图（Deployment Diagram）等多种图形方式，每一种图形都用来从某个视角解决某类程序设计的抽象描述问题。上述图并非都是用来需求建模的，大部分是用于软件系统设计建模！！！

产品经理，尤其是B端产品经理，必须掌握UML的相关知识，能够通过UML来辅助需求分析工作，表达阐述自己的设计思路，方便和开发人员进行高效的沟通。产品经理常用的UML图包括ER图（UML中的类图）、跨部门流程图（使用频率最高）、状态机图；可能用到的UML图包括活动图、用例图。接下来，我们逐一进行介绍。

1. 用例图

1.1 用例图

1.1.1 组件

用例图（Use Case Diagram）从用户视角来描述系统的操作功能。

简单来讲就是某个角色或用户在不同场景下能做什么，下图是一个简单的用例图。

1.1.2 用例细化与用例关系

用例与用例之间的关系一般包含：泛化关系、包含关系、拓展关系。

（1）泛化关系

当一个用例可以被特别列举为一个或多个子用例时，可以使用用例泛化关系。子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变已继承的行为。

泛化关系使用带空心箭头的实线，箭头指向被继承的用例，即父用例。（PS：泛化关系的箭头不是指向被泛化，而是指向被继承。泛化和继承是不同的方向。泛化是从下到上的抽象过程，继承是从上到下，从一般到特殊的过程。）

如图所示：

备注：

在泛化关系中，父用例通常不是独立的用例，不直接呈现给用户。

在上图中，各个子用例的功能的公共部分，由父用例完成。各个子用例功能是有重叠的部分，这部分重叠的功能就是父用例。

（2）包含关系

当一个用例（基础用例）的行为包含了另一个用例（包含用例）的行为，可以使用用例包含关系。包含关系的使用场景包含：将几个用例下的重复的功能分解到另一个公共用例中，其他用例与这个公共用例建立包含关系。如果某个用例的功能太多时，可以用包含关系创建子用例。在包含关系中，基础用例依赖于包含用例的执行结果。

包含关系使用虚线箭头+<<include>>字样，箭头指向被包含的用例。

如图所示：

包含关系：

各个子用例的功能，共同组成了包含用例的功能。

（3）扩展关系（extend）

如果某个用例有特殊情况需要处理，就把这个特殊行为通过拓展关系插入到已有用例。比如正常登录行为是输入账号/密码点击登录即可，但是特殊情况下，如果用户忘记密码，就需要走忘记密码操作。

扩展关系主要应用在处理异常情况，或者构建后续拓展框架等情况。 包含与扩展的区别。与包含关系不同的是，扩展关系下的基础用例没有扩展用例也可以完整存在。

扩展关系使用虚线箭头+<<extend>>字样，箭头指向被扩展的用例（即基础用例）。

如图所示：

备注：

扩展关系是该用例是在基础用例的基础之上，新增加的场景，该场景正常情况不会出现，只有在特殊情况下才会出现，是现有功能的扩展！！！

1.2 用例规约

在需求分析工程中，用例驱动的设计（UDD，Use Case Driven Design）是一种经典的复杂软件系统设计的方法论。

用例图的绘制本身并不复杂，但关键在于以用例的方式梳理角色和业务场景，并按照用例设计规范将需求进行结构化分解和描述。如下表，是我们将分销运营人员创建客户的场景，通过用例描述的方式，进行需求规格说明书的编写。

用例编写示例（以下表格文字说明部分引用自图书《火球：UML大战需求分析》）

备注：从上述描述可以看出，每个用例，实际上就是一个业务场景！！！

一个用例规格说明包括：

• 执行者
• 目的，功能
• 前置条件
• 执行过程
• 后置条件
• 可选项
• 异常流程
• 补充说明

2. ER图/概念类图

ER（Entity Relationship）图是一种描述实体对象（Entity）之间关联关系（Relationship）的经典图表，由科学家Peter Chen于1976年发明，最早被用于关系型数据库的表结构设计。

即使没有听说过ER模型，你在工作中肯定已经接触过它。例如，我们在设计产品时，经常要讨论一些对象的对应关系，是一对多还是多对多，这实际上就用到了ER模型。

在6.1.1节的客户模型设计中，我们已经通过ER图展示了客户建模以及业务数据建模的方法。

ER图的呈现方式很多，比较常用的是UML的呈现方式，实际上就是采用UML中的类图（Class Diagram）所规定的符号标记规范来进行描述和呈现。

下图是通过Visio绘制的类图，其中每一个大方框代表一个对象，方框中的第一行描述对象名称；第二行描述对象中的数据字段，例如图中“机构”对象有一个字段“上级机构”；最下面一行描述对象所具备的函数，这是程序设计时用到的概念，产品经理可以不用关心，此处留空即可。两个对象之间用实线连接，实线两端标上数字，用来描述它们之间的对应关系，例如下图描述了机构和门店是1对多关系，即1个机构节点可以对应0个到多个（0..*的含义）门店。

上图描述的机构和门店同样是1对多关系，但请注意此例中，1个机构节点可以对应1个到多个（1..*的含义）门店，至少要对应1个门店。

如果没有Visio，也可以用PowerPoint来绘制UML标记风格的ER图，并且不用拘泥于形式，重点在于说清楚两个对象的对应关系，即连接线上的数字是重点。例如，我们用PowerPoint重新绘制机构和门店对应关系的ER图，如下图所示。

ER图本身只是一种理念，具体的绘制方法有很多标准，下图呈现了不同标准下ER图的画法。

市面上不同的绘图工具，在创建ER图时，所遵循的标准可能不同。

以上介绍了产品经理常用的图表，产品经理绘制图形的主要目的是说明清楚设计思路，这些图表可能给技术人员看，也可能给业务人员看。

在实际工作中，产品经理应该尽量使用简单的方式，让别人理解自己的设计和意图。

不建议使用过于复杂的UML规范，因为不是所有人都具备UML知识，如果采用了复杂的UML标记体系来绘制图形，会导致其他人看不懂，失去沟通的意义。

3. 跨角色流程图（串行、协同）

跨用户角色流程图是一种相对复杂的流程图，可以清晰准确地描述分角色、跨系统的业务流程，跨部门流程图实际上是流程图的泳道化呈现，每个职能部门在图中呈现出一条“泳道”的效果。严格来讲，流程图、跨部门流程图不属于UML的范畴，尤其是流程图，拥有更加悠久的历史，在各行各业均普遍使用。

国际标准组织ISO（International Standard Organization）在1970年定义了流程图的基本符号规则，在实践中，为了便于不同背景的读者阅读理解，建议尽量采用简单的绘图规则，例如，只使用开始、结束、执行、判断这四种标记符号来绘制流程图，而不要引入其他更加复杂、高级的标记符号，以保证流程图容易理解。

跨部门流程图的简单示意如下图所示。绘制跨部门流程图的要点如下。

• 开始、结束节点必须用专门的图形（多边形和椭圆形）来表达，这样容易让阅读者较为轻松地识别开始和结束的位置。
• 每个流程只有一个开始节点，但可以有多个结束节点。
• 尝试调整泳道的顺序，以便保证流程看起来清晰干净，而不是交叉、缠绕在一起。

4. 活动图（并行、协同）

活动图（Activity Diagram）是流程图的一种，用来描述一系列过程。

活动图和流程图最大的区别是：

活动图可以描述并发工作的执行过程，

而标准流程图的节点必须是顺序执行的，只有判断节点才能引出两条分支。

在M公司的案例中，客户根账号（对应客户-管理员角色）被创建后，客户-管理员下一步要创建子账号和门店，实际上这是两个可以并行发生的动作，并没有先后顺序的要求，且门店和子账号都创建完毕后，才可以对二者进行关联。这个逻辑在流程图中无法准确呈现，通过活动图可以清晰地描述，如下图所示，“根账号生效”这个步骤的下一步，产生了一个并行任务的分支，表示“创建门店”和“创建账号”这两件事可以同时发生，接下来是一个分支合并，表示当“创建门店”“创建账号”这两个事件都完成以后，流程可以继续往下走，执行“关联门店账号”的操作，然后结束。

5. 状态机图

状态机图（State Machine Diagram）也叫有限状态机图（Finite State Machine Diagram），是一种描述所有状态及状态之间流转规则的图形。

在软件设计领域，“状态”在业务系统中无处不在：订单要有状态，账号要有状态，门店要有状态，可以说任何对象都有状态。设计状态是一件很有意思的事情，需要注意以下事项：

• 状态值必须是有限的集合，状态的所有枚举值（即状态值）必须能够涵盖所有实际可能的情况。
• 状态值之间要互斥，不能出现二义性。
• 为了更准确细致地描述事物，状态还可以具备子状态，比如订单状态“已取消”，可以定义对应的子状态“客户取消”“商家取消”“系统取消”。
• 状态应该是能持续一定时长的，而不应该是很快就会结束的瞬时态。例如，订单的状态可以是“待发货”“待评价”，但不能是“发货中”“评价中”。
• 在中文语境中，给状态起名字时，可以尝试包含以下三个文字中的任意一个，会发现状态的定义变得清晰简单，这三个字分别是“已”、“中”、“待”。

通过研究状态之间所有可能的流转规则和逻辑，能够识别状态设计的合理性，并梳理清楚业务规则。如果用文字描述状态之间的轮转，会非常不方便。通过状态机图，就可以非常好地解决这个问题。

下图是分销业务中“客户”这一对象的状态机图，可以看出，状态机有一个开始节点和一个结束节点，圆角矩形中的内容代表状态值；分销业务系统中的“客户”一共有四种状态，分别是“待审核”、“已生效”、“未通过”、“已停用”。两个状态之间的连接线，代表状态变化迁移的条件。

6. 时序图

时序图（Sequence Diagram），又名序列图、循序图，是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它可以表示用例的行为顺序，当执行一个用例行为时，其中的每条消息对应一个类操作或状态机中引起转换的触发事件。

时序图用于描述某个用例或业务场景中，用户与系统内不同实体之间的交互关系！！！

因此，首先要确定系统内部的主要实体或模块或对象！！！