【软件工程】建模工具之开发各阶段绘图——UML2.0常用图实践技巧（功能用例图、静态类图、动态序列图&状态图&活动图）_功能模块用uml拿个图

更多示例图片可以参考：（除了常见的流程图，其他都有）
概念：类图
静态：用例图
动态：顺序图&状态图&活动图
1、【面向对象】UML类图、用例图、顺序图、活动图、状态图、通信图、构件图、部署图
2、【软考】数据流图&数据库设计&UML建模复习指南
3、【高项】信息化与信息系统（第4版教材第1-5章，计算机科学知识）

1、概念建模 & 领域建模

问题： 团队内，以及团队外，日常进行沟通需求和对齐设计往往采用当面沟通，白板沟通等原始的方式。这些方式存在没有留下痕迹，领域知识表述不充分，难以理解等问题。

改进：最佳实践为领域建模，通过统一交流语言，达到对齐认知的效果，同时沉淀下可分享的知识，并持续迭代和完善，做到随时能以可视化的方式进行呈现。

领域建模 = 领域知识+领域模型

• 领域知识 = 确定实体及其属性+描述实体间静态关系+描述实体之间的动态关系+描述实体生命周期
• 领域模型 = 建立映射

为什么需要领域建模？

• 领域建模的优点：

  • 统一交流语言，对齐认知

  • 经验和知识有沉淀，能够分享

  • 聚焦，可视化

  • 能够持续迭代和完善

• 业务复杂度 = 领域自身复杂度+技术复杂度

  • 设计方法决定技术复杂度
  • 领域本身复杂 + 设计方法 不合适 = 复杂度失控 = 无法理解 无法更改 无法扩展

什么是领域建模？

• 找到问题（提高收入）

  • 业务建模：选定要改进的业务组织，组织到底要解决什么业务问题？（业务用例图，现状业务序列图）
  • 需求(概念建模：引入系统)：为了解决业务问题，所开发系统应提供什么功能和性能？（改进后的业务序列图、系统用例图、书写用例规约）

• 解决问题（降低成本）

  • 分析：提炼系统内需要封装的核心领域机制。可运行的系统需要封装各个领域的知识，其中只 有一个领域（核心域）的知识是系统能在市场上生存的理由。对核心域作研究，可以帮助我们获得基 于核心域的复用。 （分析类图、分析序列图、状态图）
  • 设计：将核心域知识和非核心域知识结合，最终实现系统。说“代码就是设计”指的是这里说 的“设计”。代码确实是设计，但代码不是分析，不是需求，不是业务建模。要您思考过、表达过上面这些问题，就是在建模，用文本、UML、其他表示法或自造符号来表 达都可以。而且我相信，每一个项目，我们都会思考和表达上面这些问题，只不过可能是无意识地、 不严肃地在做，现在我们要学习有意识地做，把它做出利润来。当然，使用 UML 来做是目前一个不坏的选择。（设计模型）
  • 实施（交付）：（业务代码、测试用例）

• 概念与定义：

  • 基于领域知识建立概念模型
  • 领域建模的过程就是通过人脑完成分析跨越鸿沟的过程

• 领域知识+建模方法=领域建模

  • 领域：就是问题域，并且大领域可以分解为小领域

  • 领域知识：

    • 对现实世界和既有流程的清晰完整认识
    • 进入领域内部的深刻认识
    • 对历史经验和最佳实践的理解和继承

  • 建模：建立映射

  • 建模方法：动态建模、静态建模

什么是模型？

• 定义：对现实世界人和事务的一种抽象，一种形式化表达
• 分类：
  • 领域模型
    • 对领域内的概念类或现实世界中对象的可视化表示。
    • 又称概念模型、领域对象模型、分析对象模型。
    • 它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系
  • 逻辑模型：将概念模型具体化，带上属性，类似LDM
  • 数据模型：描述含有数据的实体对象，如E-R图
  • 物理模型：针对逻辑模型，在具体的物理介质上实现出来，如主键，联合索引等，类似PDM
• 模型的价值
  • 信息的组织方式，统一沟通交流语言
  • 对业务的高度抽象
  • 承载设计，保护和共享知识
  • 知识经验沉淀，持续学习
  • 聚焦，可视化
• 信息传递，从抽象到具体
  • 业务角色+业务实体+联系和协作=抽象
  • 为了看的见，我们需要用一些方法来表示它，图是表达领域模型最常用的方式

领域建模的实际应用场景

• 方案设计：CGI与用例有什么关系？
• 需求启发、对齐认知：到底是干啥？数据不对？
• 对外合作、树立口碑

2、需求分析—描述功能（用例图、流程图）

用例50+，流程10+

2.1 业务用例图、系统用例图

用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。是系统的蓝图。

如何画好业务用例图

• 目的：确定开发这个系统的目的，业务组织要解决什么问题
• 最佳实践：
  • 可以在业务用例图旁边以备注方式说明愿景和涉众利益分析 （老板，业务研发人员，业务产品同学）
  • 组织要选对，业务执行者是组织外的
  • 业务执行者是目标组织提供业务价值的期待者
  • 目标系统是系统，而不是子域（中心做的“系统”大部分其实是“XXX系统下”的子域）
• 建模工作流：
  • 1．业务建模——描述组织内部各系统（人脑系统、电脑系统……）如何协作，使得组织可以为其他组织提供有价值的服务。
  • 2．需求——描述为了解决组织的问题，系统必须具有的表现——功能和性能。
  • 3．分析——提炼为了满足功能需求，系统需要封装的核心域机制。
  • 4．设计——为了满足质量需求和设计约束，核心域机制如何映射到选定平台上实现

系统用例与业务用例的区别：

• 业务用例图主要关注业务流程和业务参与者之间的交互，描述了业务参与者如何使用系统来完成业务流程。

  它强调的是业务需求和业务流程，而不是系统的实现细节。业务用例图通常由业务分析师或业务专家绘制，用于与业务参与者交流和确认业务需求，以及定义系统的功能和范围。

• 系统用例图则更加关注系统的实现细节和功能模块之间的关系，描述了系统如何响应业务参与者的请求。

  它强调的是系统的角色和功能，而不是业务流程。系统用例图通常由系统分析师或开发人员绘制，用于与技术团队交流和确认系统的设计和实现。

2.2 流程图

流程图是一种图形化的工具，用于描述一个过程或系统的流程。它通常由基本的流程图符号和连接线组成，用于展示流程中的各个步骤、决策、并发、循环等。

流程图的画法如下：

1. 确定流程的起点和终点，以及流程中的各个步骤和决策点。
2. 使用基本的流程图符号，如开始/结束符号、处理符号、决策符号、输入/输出符号、连接线等，来表示流程中的各个步骤和决策。
3. 按照流程的顺序，将各个步骤和决策点用连接线连接起来，形成完整的流程图。
4. 根据需要，添加补充说明和注释，以便更好地理解和使用流程图。

流程图的基本符号包括：

1. 开始/结束符号：用于表示流程的起点和终点。
2. 处理符号：用于表示流程中的各个处理步骤。
3. 决策符号：用于表示流程中的决策点，通常用“是/否”或“真/假”等条件来表示。
4. 输入/输出符号：用于表示流程中的输入和输出。
5. 连接线：用于连接各个步骤和决策点，表示流程的顺序和关系。

3、概要设计—静态模型（类图）

类图150+

类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。

类之间的几种关系：

• 泛化（Generalization）、实现（Realization）、关联（Association）（又分一般关联、聚合、组合）、依赖（Dependency）。
• 各种关系的强弱顺序如下： 泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

1. 泛化关系（Generalization）：是继承关系的一种特例，表示一个更一般概念的类（父类）与一个更具体概念的类（子类）之间的关系。例如，猫是动物的一种，狗也是动物的一种，可以定义一个Animal类作为父类，然后猫和狗分别继承Animal类，这就是一种泛化关系。
2. 组合关系（Composition）：表示整体与部分之间的关系，整体对象包含部分对象，部分对象不能存在于其他整体对象中。例如，一个汽车由引擎、轮胎、座椅等组成，这些部分对象只能属于这个汽车，不能属于其他汽车。
3. 聚合关系（Aggregation）：表示整体与部分之间的关系，整体对象可以包含部分对象，但部分对象可以存在于多个整体对象中。例如，一个班级可以包含多个学生，但学生也可以属于不同的班级。
4. 关联关系（Association）：两个类之间的关系，其中一个类引用另一个类的对象。例如，学生和班级之间就是一种关联关系，一个班级可以有多个学生，一个学生只属于一个班级。
5. 依赖关系（Dependency）：表示一个类依赖于另一个类的实现或接口，当一个类的方法需要另一个类的对象作为参数时，就存在依赖关系。例如，一个订单类需要一个货物类对象作为参数，就存在订单类对货物类的依赖关系。（需要注意的是，依赖关系是一种短暂的关系，通常只在方法调用的时候存在，而不是持续存在的关系。）
6. 实现关系（Implementation）：一个类实现了一个接口，就必须实现该接口中定义的所有方法。例如，电视机和洗衣机都可以有一个开关的接口，它们都必须实现该接口中的开关方法。
7. 继承关系（Inheritance）：一个类继承另一个类的属性和方法，被继承的类称为父类或基类，继承的类称为子类或派生类。例如，猫和狗都是动物，可以定义一个Animal类作为父类，然后猫和狗分别继承Animal类。

概念建模/对象建模

• 1、不要过多的考虑实现细节，应该是忠于现实，还原细节
  • 尽可能多的展开概念（名词，从现实中来）
  • 对现实世界和既有流程的清晰、深刻、完整认识，不是创造
• 2、先尽可能展开概念实体，然后确定是否为属性
• 3、刚开始不要过度抽象,否则会导致无法表达细节,最后在去泛化时适当抽象
• 4、禁用数据库 ID，属性存在 ID等，实体间的关系已表达
• 5、多种不同维度的泛化，共享数据-关联优先；行为变异-泛化优先

如何进行概念建模？

• 概念建模—实体属性
  • 属性:
    1. 属性直接描述实体的特征, 是名词
    2. 属性对实体的所有实例都有意义，部分实例有意义的属性放到子实体去
    3. 当前问题域内不需要再分解
    4. 重要属性需要在实体里显示出来, 辅助理解模型
  • 检查点:
    1. 读一遍: ‘实体名’的’属性名’ 念着通顺
    2. 属性是简单类型, 不是复杂结构
    3. 实体和属性不存在一对多的关系
    4. 多个属性间不要有冗余
• 概念建模—关系
  • 关系:
    1. 主要的关系: 泛化，关联，聚合, 组合，实现，依赖
    2. 观察实体是否整体与部分关系外加两实体的生命周期来区分关联,聚合和组合
    3. 聚合和组合意味着责任会传递, 责任分配时会先找整体, 再由整体请求部分
    4. 判断不出啥关系时, 先用关联
  • 检查点:
    1. 是整体与部分关系么
    2. 两个实体生命周期是否相同
• 概念建模—多重性
  • 多重性:
    1. 表示实体之间的数量关系, 1对1, 1对多,多对多
    2. 角色是实体在关系里的名称, 表示实体在关系中的地位,作用, 职责
    3. 角色是指定关系上的角色，因此先确定关系再谈角色
    4. 实操中在相同的两个实体之间有多种关系时要标注出角色名
  • 检查点:
    1. 多重性在概念类图里需要标出来
    2. 两实体之间存在不同的关系时需通过关系名和角色名进行区分
• 概念建模—去泛化
  • 泛化转关联:
    1. "去泛化"后要保留原来子类，通过颜色来体现过程以保留完整信息
    2. 去泛化时一般会在父类中添加新的属性, 比较典型的是类型属性
    3. 对于子类的特有属性，通过在父类中增加相同的属性来解决
    4. 去泛化后其它实体和子类的关系也要转移到父类上
  • 检查点:
    1. 所有泛化关系是否在建模后期都已经通过转换去掉
    2. 父类中是否有新增属性体现去泛化过程,子类属性是否丢失
    3. 其它实体和子类的关系是否有转到父类上
• 概念建模—压缩
  • 压缩:
    1. 将建模中的分析出的实体进行合并，1对1和1对多都可以合并
    2. 压缩可以优化模型的结构和关系，提高可读性，可维护性，可扩展性
  • 检查点:
    1. 模型中是否还有两个实体是一对一的关系
    2. 模型中是否存在实体只和另外1个实体有1对多的关系
    3. 模型压缩合并后属性是否都在合并到的实体中有体现

4、详细设计—交互关系（序列图，状态机，活动图*）

序列图分析200设计100业务50+，状态机50+

4.1 业务序列图

时序图：（Sequence Diagram），又名序列图、循序图，顺序图，是一种UML交互图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。

如何画好业务序列图？

• 业务序列图的目的

  • 描述业务流程的手段
  • 是业务建模阶段的产物
  • 辅助提炼改进点，捕获需求

• 业务用例：

  • 目标组织：商家
  • 业务执行者：用户
  • 业务用例：购物
  • 辅助执行者：银行等

• 要点1：改进模式

  • 改进前和改进后的序列图要能体现出使用的改进模式
  • 业务序列图仅表达对业务执行者提供的价值，且仅仅呈现系统之间的交互
  • 如果很多细节交互，属于系统用例的交互步骤，应该放在分析序列图中

• 要点2：系统与子域

  • 系统：来自领域专家对问题的分解（业务类系统，研发支撑类系统）
  • 子域：对应到问题域，XXX治理、XXX自动化等是在线业务研发支撑系统的子域
  • 时间：它是特殊的外部系统，向全世界各种系统发送时间消息

• 要点3：职责与协作

  • 发消息这个场景，应画为系统指向自身
  • 消息接收者指向系统来查询消息，不能出现系统指向人
  • 消息是否要画入业务序列图，取决于它是否独立提供业务价值
  • 如果没有提供独立的业务价值，就不需要画入

4.2 分析序列图

分析序列图的意义

• 动态建模：分析系统内实体间如何协作，来实现系统价值（系统用例）
• 静态建模：概念精华（关联、泛化、压缩）

如何画分析序列图？

• 分析序列图–命名（系统用例内）：分析序列图文件使用「用例名」来命名，便于管理和识别
• 分析类的命名：
  • 边界类：用例名+UI、外系统名称+接口
  • 控制类：用例名称+UC
  • 实体类：概念实体名称
• 分析序列图–粒度（系统用例内）
  • 一个系统用例画一个分析序列图
  • 误区1：时间只能为系统执行者，应该属于另外一个系统用例
  • 误区2：执行者到UI可以有多个步骤，多个步骤并不是多个系统用例
• 分析序列图–职责分配
  • 类似于业务序列图，消息体现类的责任，而非数据流动
  • 边界类：负责输入、输出
  • 空值类：负责控制流，为实体分配责任
  • 实体类：负责主要业务逻辑
• 分析序列图–聚合根调度（职责分配）
  • 分析序列图里的UE是领域概念实体，某些耦合关系比较紧的实体可能在设计阶段会被圈为聚合，其中接受UC消息的实体会被设定为聚合的聚合根
  • 跨聚合的UE调度逻辑一般画在UC上， 聚合内的UE调度逻辑一般画在聚合根实体上。
• 分析序列图–小技巧简化fragment
  • 如果仅仅是前置条件表达，可以不使用fragment，消息采用“条件:消息内容”即可减少画图成本和理解负担

4.3 状态图

状态图:状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。

状态图是什么？

• 状态图是一种用于描述系统或对象在不同状态下的行为和转换的图形化表示方法。它由状态、转移和事件三个基本元素组成。
• 状态是指系统或对象在某一时刻所处的状态，可以是一个具体的状态、一个过程中的状态或一个概括性的状态。状态通常用圆圈或矩形表示。
• 转移是指系统或对象从一个状态转移到另一个状态的过程。转移通常用箭头表示，并标注转移条件和动作。
• 事件是指触发系统或对象状态转移的外部或内部事件。事件通常用菱形表示。
• 状态图可以用于描述各种系统和对象的行为，如软件系统、控制系统、通信协议等。在软件开发中，状态图通常用于描述对象的生命周期、用户界面交互、状态机等。

状态机职责：

• 状态机只能做实体生命周期管理，不做持久化
• 仅仅做实体的属性变更

如何支持重入？

• 什么时候需要重入？
• 什么时候不允许重入？

4.4 活动图

活动图：活动图（activity diagram，动态图）是阐明了业务用例实现的工作流程。

活动图是一种用于描述系统或对象的行为流程的图形化表示方法。它由活动、控制流、决策节点、合并节点等基本元素组成。

活动是指系统或对象的一个行为或操作，可以是一个具体的动作、一个过程中的活动或一个概括性的活动。活动通常用矩形表示。

控制流是指活动之间的顺序关系，用箭头表示。箭头上可以标注条件或约束。

决策节点是指根据一定条件进行选择的节点，用菱形表示。菱形上标注条件。

合并节点是指将多个控制流合并为一个的节点，用圆圈表示。

画法如下：

1. 确定活动图的目的和范围。

2. 画出活动图的主要流程，即活动之间的控制流和顺序关系。

3. 根据需要添加决策节点和合并节点。

4. 细化活动，添加子活动和并行活动。

5. 根据需要添加对象和角色，标注参与者信息。

6. 根据需要添加注释和说明，使活动图更易理解。

7. 审核和修改活动图，确保其正确性和完整性。

活动图可以用于描述各种系统和对象的行为流程，如软件系统、业务流程、用户操作等。在软件开发中，活动图通常用于描述用例场景、业务流程、系统设计等。

5、开发实现（部署图）

部署图2+

部署图描述的是系统运行时的结构，展示了硬件的配置及其软件如何部署到网络结构中。 一个系统模型只有一个部署图，部署图通常用来帮助理解分布式系统。

部署图是一种用于描述系统或流程中各个组件、模块、节点之间的关系和交互的图形化工具。它可以帮助人们更清晰地理解系统或流程的整体结构和运行方式，从而更好地进行设计、优化和管理。

部署图的画法主要包括以下几个步骤：

1. 确定系统或流程的组件和节点：根据需求和目标，确定需要在部署图中展示的系统或流程的各个组件和节点，例如服务器、数据库、应用程序、用户等。

2. 绘制组件和节点：使用适当的符号和图形，将每个组件和节点绘制在部署图中，并标注其名称和功能。

3. 连接组件和节点：使用箭头或线条等符号，将不同组件和节点之间的关系和交互连接起来。例如，可以表示数据流、控制流、消息传递等。

4. 标注属性和参数：对于每个组件和节点，还可以标注其属性和参数，例如IP地址、端口号、运行状态等。

5. 完善细节：根据需要，可以添加其他细节信息，例如安全策略、备份策略、性能指标等。

总之，部署图的画法需要清晰明了，符号简洁易懂，同时也需要考虑到系统或流程的实际情况，做到准确反映其结构和运行方式。

附：UML2.0中的14种图

UML是Unified Model Language的缩写，中文是统一建模语言，是由一整套图表组成的标准化建模语言。

UML图分为结构图和行为图。（表粗的为重点）
结构图分为类图、轮廓图、组件图、组合结构图、对象图、部署图、包图。
行为图又分用例图、状态机图、活动图、交互图。
交互图又分为序列图、时序图、通讯图、交互概览图。

参考资料：1，2，3，4，5