看网上有很多关于 UML 图的介绍，但都不完整，于是参考了一些 UML 书籍、博客、视频、官网，并基于最新的 UML 2.5 版本（涵盖了 UML 14 种图），总结了这篇文章，希望能给系统分析设计的同学一点参考。
动态行为图（7种）
0****8
用例图
8.1、作用
用例图（Use Case Diagram）是指的由参与者（Actor）、用例（Use Case）、边界，以及它们之间的关系构成的用于描述系统功能。
用例图（Use Case）是外部用户所能观察到的系统功能的模型图，是系统的蓝图。
用例图主要功能：列出系统中的用例和参与者、显示哪个参与者参与了哪个用例的执行工作
核心概念
- 用****例：系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。
- 参与者：通过系统边界与系统进行有意义交互的外部实体。
- 泛化：参与者与参与者之间的关系。
- 关联：用例与参与者之间的关系。
- 扩展、包含、泛化：用例之间的关系。
推荐使用场合
业务建模、需求获取和定义等场合。
8.2、组成元素
组成要素 | 符号 | 作用 |
参与者 |
| 通过系统边界与系统进行有意义交互的外部实体， 用一个小人表示 注意，参与者位于系统边界之外，而不是系统的一部分 |
用例 |
| 系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。用椭圆表示 用例是参与者在系统中做某件事从开始到结束的一系列活动的集合。是外部可见的系统功能，对系统提供的服务进行描述。 |
系统边界 |
| 用于描述系统边界，用一个长方形框表示 |
注释 |
| 用于注释，通过虚线连接 |
关系 | 包含关系
| 包含关系。表示参与者与参与者之间、参与者与用例之间、用例与用例之间的联系。 由一个带箭头（非三角箭头）的虚线表示，虚线中间有 <<include>>，由基用例（整体）指向被包含用例（部分） |
扩展关系
| 扩展关系。由一个带箭头（非三角箭头）的虚线表示，虚线中间有 <<extend>>，由扩展用例指向基用例 例子
| |
泛化关系
例子： 参与者之间的泛化关系
用例之间的泛化关系
| 泛化关系。表示子父关系，由子对象指向父对象，这里的对象可以是参与者，也可以是用例。 由一个带“空心三角箭头”的实线表示，由子对象（参与者或用例）指向父对象（参与者或用例） | |
关联
| 一般用于参与者和用例之间的关联 | |
注释连接
| 用于连接注释块 |
下面来详细介绍下这几要素：
（1）参与者
参与者最常见的是人和系统，除此之外，也可以是“时间”
确定参与者可以从以下几个角度来考虑：
1）为系统提供输入的人或事物
2）接收系统输出的人或事物
3）需要接入的第三方系统或设备
4）时间是否会触发某些事件
5）负责支持或维护系统中信息的人
系统中的参与者一般可以分为四类：
主要业务参与者：主要从用例的执行中获得好处的关联人员。
主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联人员。
外部服务参与者：响应来自用例的请求的关联人员。
外部接收参与者：从用例中接收某些价值或输出的非主要的关联人员。
（2）用例
用例是参与者的目标，用例的特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否准确的依据。
1）用例是动宾短语
2）用例是相对独立的
3）用例是由参与者启动的
4）用例要有可观测的执行结果
5）一个用例是一个单元
（3）关系
1）包含关系
包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为，其中包含用例中定义的行为将被插入基用例定义的行为中。
2）扩展关系
扩展指的是一个用例（扩展用例）对另一个用例（基用例）行为的增强。
扩展使用一个附加了《enxtend》构造型的虚线箭头表示，箭头指向基用例。
注意：扩展与包含的箭头方向是相反的，这表明扩展取决于扩展用例而非基用例，扩展用例决定扩展的执行时机，基用例对此一无所知。
扩展用例的使用包括四个部分：
基用例：需要被扩展的用例，“注册”用例。
扩展用例：提供所添加的行为序列的用例，如图中的“检查实名信息”用例。
扩展关系：使用虚线箭头表示，箭头指向基用例。
扩展点：基用例中的一个或多个位置，表示在该位置会根据某条件来决定是否要中断基用例的执行从而执行扩展用例中的片段。
8.3、示例
（1）图书管理系统用例图
0****9
活动图
9.1、作用
活动图是描述一个用例从开始到结束的动作（活动）的执行流程（业务流程），它是对用例内部流程的补充介绍，强调用例内部的动作流转，一般用于早期的业务流程建模。
活动图（Activity Diagram）是一种行为模型，用于对系统的动态方面进行建模。它描述了用例内部动作（活动）之间的流程，强调行为的执行序列和条件，主要用于描述某一方法、机制或用例的内部行为特征。活动图从本质上说是一种流程图，展现从活动到活动的控制流；与传统的流程图不同的是，活动图还能够展示并发、对象流、分区等高级概念。
活动的每一次执行都包含一系列内部动作的执行，其中每个动作可能执行0次或多次，并按照一定的次序执行，每个动作将导致系统状态的改变或消息传送，通过控制流或对象流来协调内部行为执行逻辑。
活动图是 UML 用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。
核心概念
- 活动、组合活动：表示某个用例内部的控制逻辑。
- 对象、对象流：与活动相关的数据对象。
- 转移、分支：控制活动之间的先后顺序。
- 并发、同步：支持活动间的并发和同步。
- 分区：描述活动的不同参与者。
推荐场景
业务建模、需求、类设计等场合
9.2、组成元素
组成元素 | 符号 | 作用 |
活动/动作 |
| 表示流程中的动作，一般用一个一个动词短语表示 |
对象 |
| |
发送事件 |
| |
接受事件 |
| |
分区（泳道） |
| 活动分区用于识别具有相同特性的一组动作，这些动作被放入相同的区间 分区之间没有顺序，不同分区中的活动既可以顺序进行也可以并发进行，动作流和对象流允许穿越分隔线 在业务模型或需求中，往往按照组织机构的单位或系统角色进行分区，一个单位或角色负责分区中所有节点的行为。而在设计模型中，可以按照不同的类（或构件）进行分区，一个类（或构件）负责执行该分区中所有节点的行为。分区条可以水平或垂直放置，各个动作按照其执行主体放到相应的分区中，这样可以很清楚地界定动作的执行主体。 |
决策点 |
在实际使用时，由三个元素组成，分别是菱形（决策点）、箭头和条件。 其中箭头分为两种：一种是进入箭头（由外指向菱形）；还有一种是离开箭头（由菱形指向外面），离开箭头上都有一个条件，用来表示满足什么条件的时候执行该转换 | 在活动图中，对于同一个触发时间，可以根据不同的条件转向不同的活动，每个可能的转移是一个分支（branch） |
分叉/合并 | 元素
水平方向
垂直方向
| 用于分开或汇聚控制流 |
起点 |
| 活动开始节点 |
终点 |
| 活动结束节点 |
流结束 |
| 活动子流程节点 |
控制流 |
| 控制流用来连接两个动作或控制节点，前一个节点动作执行完成后，通过控制流进入下一个动作。控制流不传递对象或数据，只传递控制令牌，源节点所有令牌都将会传递给目标节点 |
对象流 |
（在 UML 1.x 中为虚线） | 对象流连接一个动作节点和一个对象节点（或直接连接两个对象引脚），用来传递对象或数据，表示源动作“生产”对象，或由目标动作“消费”对象 |
9.3、示例
（1）饭店食客吃饭用例的活动图
首先，从起点开始，通过控制流进入第一个动作，即食客走进饭店，饭店领位员帮忙查看是否有空位。该动作执行完成后，会产生有无空位的分支，通过决策节点描述，两种分支情况分别放置在决策节点的输出控制流上。如果有空位则直接领位，进入后续动作；反之，如果无空位，则食客登记姓名后，领位员发号表明等待的顺序，食客等位。
在等位期间，领位员会频繁检查是否有空位（图中没有建模该动作），如果有空位，则发送找到空位的信号给对应的食客（这是一个领位员执行的独立控制流），这时这两个控制流汇合，并通过合并节点与有空位的分支流合并进入领位动作。
领位完成后，领位员安排服务员点菜，服务员递菜谱，食客根据菜谱点菜。点菜完成后，通过对象流形成菜单对象，服务员将菜单中的热菜发送给厨师（异步发送事件），从而通知厨师做热菜，之后安排上酒水凉菜。厨师接到热菜菜单后（异步接收事件），即启动独立的做热菜流程，热菜做好后发送信号通知服务员上热菜，当前厨师的控制流结束。服务员接收到热菜做好的信号后，为食客上主菜，这是与之前上酒水凉菜的控制流相对独立的一个新流程。在酒水凉菜和主菜都上完后，汇合在一起进入后续的结账环节（省略了中间的食客吃饭的过程）。
（2）借书用例的活动图
（3）购物用例活动图
泳道分为：会员泳道和系统泳道。会员选择商品并加入购物车，系统完成订单生成及其支付完毕。
开始节点：会员添加商品到购物车，点击【订单确认】，开始交于系统处理订单流程
结束节点：商品发送完毕和付款成功，订单处理流程结束
活动状态：产生订单、Check Credit Cart 核对信用卡、Check Stock 核对库存量、Deliver Goods 发送商品、Process Credit Cart 付款
分叉与汇合：【产生订单】份叉为检查库存量和会员支付金额是否足够，如果不足，取消订单，如过库存量和支付金额足够，发送商品和付款，最后汇合为订单完成。
（4）请教用例活动图
10
状态机图
10.1、作用
状态机图（State Machine Diagram），就是 UML 1.x 中的状态图（Statechart Diagram），利用状态和事件描述对象本身的行为。它是一种非常重要的行为图，强调事件导致的对象状态的变化。
顺序图和通信图都是交互图的一种，它们侧重于描述对象之间的交互过程。然而，有时候对象本身也是很复杂的，它可能涉及不同的状态和行为，此时需要通过状态机图来表示，侧重于对象内部的状态和行为交互。
核心概念
- 状态、初态、终态。
- 事件、转移、动作。
- 并发状态机。
推荐使用场合：类设计场合
10.2、组成元素
组成元素 | 符号 |
状态（Stage） |
|
浅度历史（Shallow History） |
|
深度历史（Deep History） |
|
选择（Choice） |
|
初态（Initial State） |
|
终态（Final State） |
|
转移（Transition） |
|
分叉/合并（Fork/Join） |
|
10.3、示例
11
交互图-顺序图（时序图）
11.1、作用
顺序图（Sequence Diagram）用于显示对象间的交互活动，它关注对象之间消息传送的时间顺序
核心概念
- 对象、生命线、执行发生、消息。
- 交互片段（Interaction Frame）：UML 2 中的新增概念，用于封装交互图中的片段，并可对片段施加一定的操作（如选择、循环、并行等），从而使 UML 支持复杂的交互建模。
11.2、组成元素
组成元素 | 符号 |
对象/生命线 （Object/lifeline） |
|
交互片段 （Interaction Frame） | UML 2 中新增
|
执行发生 （Execution Occurrence） |
|
状态不变式 （State Invariant） |
|
同步消息 （Synchronous Message） |
|
异步消息 （Asynchronous Message） |
|
返回消息 （Return Message） |
|
创建消息（Create Message） |
|
11.3、示例
借书过程的顺序图：
（1）UML 1.x 版本
（2）UML 2.x 版本
12
交互图-通信图（协作图）
12.1、作用
通信图（Communication Diagram），在 UML 1.x 中称为协作图（Collaboration Diagram），表示一组对象之间的关系及交互活动。通信图和顺序图是同构的（描述的能力相同，很多工具提供了自动相互转换功能），只是侧重点不同。通信图中的核心概念包括以下几个。
在展示对象交互图时，顺序图侧重描述交互的先后顺序，而交互对象之间的关系并不能体现出来，通信图则是从另外一个视角来描述对象交互的交互图。
核心概念
- 对象、协作角色
- 协作、交互、消息。
推荐使用场合：包括用例分析、用例设计等场合。
12.2、组成元素
组成元素 | 符号 |
对象/生命线 （Object/Lifeline） |
|
链接 （Link） |
|
同步消息 （Synchronous Message） |
|
异步消息 （Asynchronous Message） |
|
返回消息 （Return Message） |
|
12.3、示例
（1）完成借书过程的通信图
13
交互图-时间图
13.1、作用
时间图（Timing Diagram）是一种交互图，用于展现消息跨越不同对象或角色时真实的时间信息，可描述单个或多个对象状态变化的时间点及维持特定状态的时间段。此外，顺序图作为表示交互的主要手段，也可以在其中增加时间约束来表明对象状态变化的时间点及维持特定状态的时间段。
对于一些特定的系统（如实时系统），有时候真实的时间信息非常重要（如某个消息在发送出去后，在1s之内必须返回）, UML 2 引入了新的时间图来描述时间信息。
作为一种全新的UML模型，目前时间图还没有得到广泛推广
核心概念
- 时间约束、持续时间约束、生命线
- 状态、条件、事件
13.2、组成元素
组成元素 | 符号 |
状态/条件实践线 （State/Condition Timeline） |
|
取值生命线 （General Value Lifeline） |
|
生命线 （Lifeline） |
|
消息 （Message） |
|
13.3、示例
打电话的场景为例，说明时间图的使用方法
打电话过程的顺序图（时序图），带了时间约束
打电话过程的时间图（采用直线方式）
打电话过程的时间图（采用区域方式）
14
交互图-交互概览图
14.1、作用
交互概览图（Interaction Overview Diagram）是活动图和顺序图的混合体，它将直观地表达一组相关顺序图之间的流转逻辑。是 UML 2 中新增一种图。
当一个用例内部的交互行为非常复杂时，通过一个顺序图可能无法很好地表示出来，这时候可能会把该用例的行为拆分成几个顺序图。此时，这几个顺序图之间的关系就可以通过交互概览图来描述。
核心概念：
- 交互片段。
- 起点、终点、决策、转移。
推荐使用场合：包括用例分析、用例设计等场合。
14.2、组成元素
组成元素 | 符号 |
片段（Frame） |
|
交互引用（Interaction Use） |
|
决策点（Decision） |
|
起点（InitialNode） |
|
终点（FinalNode） |
|
控制流（ControlFlow） |
|
14.3、示例
某读者使用系统的一段流程图
