UML 建模（用例图 / 时序图 / 协作图 / 三种模型）

系统架构师考试 | UML 建模专题对应 2021 年下半年案例分析试题二阅读时长：约 12 分钟

前言

UML（Unified Modeling Language，统一建模语言）是面向对象分析和设计的事实标准。系统架构师考试中，UML 主要考"看图填空"——给定一张图，让你填参与者、用例、对象、消息等。本篇系统梳理高频 UML 图：用例图、时序图、协作图，以及面向对象的三种模型（对象模型 / 动态模型 / 功能模型）。

一、用例图（Use Case Diagram）

用途：描述系统的功能边界——谁用系统、能做什么。

1.1 元素构成

元素	图形	说明
参与者（Actor）	火柴人	系统外部的交互方（人、外部系统、定时器）
用例（Use Case）	椭圆	系统提供的一个完整功能
系统边界	矩形	框定系统范围，参与者在外、用例在内
关联	实线	参与者与用例之间的连线
包含（include）	虚线 + `<<include>>`	A 包含 B（B 是 A 的一部分，必执行）
扩展（extend）	虚线 + `<<extend>>`	A 扩展 B（B 在特定条件下触发）
泛化（generalization）	实线 + 空心三角	用例或参与者之间的继承关系

1.2 答题套路

识别参与者——题目里"谁"用这个系统？通常是 2-3 个角色
识别用例——题目里"做什么"？每个动词短语 = 一个用例
区分主用例 vs 辅助用例——包含/扩展关系
画图时参与者放两侧，用例放中间

1.3 实战：预约挂号系统（2021 真题）

参与者：(1) 患者 / (2) 医院管理员
患者侧用例（6 个）：注册登录、信息浏览、账号管理、预约挂号、查询与取消预约、报告查询
管理员侧用例（4 个）：号源管理、预约管理、报表管理、信用管理

技巧：左侧用例往往来自"前台操作"（面向 C 端用户），右侧用例来自"后台管理"（面向 B 端运维）。

二、时序图（Sequence Diagram）

用途：描述对象之间消息的时间顺序——谁先调用谁、调用什么、返回什么。

2.1 元素构成

元素	图形	说明
对象	顶部矩形	写 `对象名:类名`
生命线	垂直虚线	从对象向下延伸
激活条	细长矩形	表示对象正在执行
同步消息	实线 + 实心三角箭头	必须等返回才继续
异步消息	实线 + 空心箭头	不等返回就继续
返回消息	虚线 + 空心箭头	方法返回值
自调用	回路箭头	对象调用自身方法

2.2 答题套路

识别对象——题干里所有"实体"（界面、数据库访问类、表、控制器）
识别消息——动词 = 消息名（“发起请求”/“加载数据”/“返回结果”）
时间顺序：消息从上到下排列
实参/返回值标注在消息名附近

2.3 实战：预约挂号流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
预约人员 -> 预约界面 : 发起预约挂号请求
预约界面 -> 数据库访问类 : 获取医生信息
数据库访问类 -> 医生列表 : 加载医生信息
医生列表 -> 医生出诊时段表 : 加载医生出诊时段
医生出诊时段表 --> 预约界面 : 返回医生可预约时段
预约界面 --> 预约人员 : 显示医生可预约时段
预约人员 -> 预约界面 : 选择医生/就诊时间确认预约
预约界面 -> 数据库访问类 : 写入预约信息
数据库访问类 --> 预约界面 : 返回预约结果
预约界面 --> 预约人员 : 显示预约结果

三、协作图（Communication Diagram）

用途：与时序图等价，但强调对象之间的链接结构而非时间顺序。

3.1 元素构成

对象：矩形
链接：对象之间的实线（表示它们之间有消息往来）
消息：链接上的带序号的箭头（1、1.1、1.2、2、2.1…）
消息顺序：通过嵌套编号表达

3.2 时序图 vs 协作图（核心区别，必考）

维度	时序图（Sequence Diagram）	协作图（Communication Diagram）
强调重点	消息的时间顺序	对象之间的链接结构
布局	纵向（时间向下）	自由（空间）
消息编号	隐式（按位置）	显式（1、1.1、1.2）
易读性	易看"执行次序"	易看"对象关系"
转换	可相互转换（UML 规范支持）	同左

软考答题要点：两者描述同一信息，UML 工具（Enterprise Architect、StarUML、PlantUML）支持自动互转。

四、面向对象三种模型

OOA（面向对象分析）需要建立三个相互独立又相互依赖的模型：

模型	关注点	主要元素	回答的问题
对象模型	静态结构	对象、类、属性、操作、关联、聚合、泛化	“是什么”
动态模型	动态行为	状态、事件、状态转换（状态图）	“什么时候发生”
功能模型	数据变换	加工、数据流、数据存储（DFD）	“做什么”

4.1 三者关联关系（必考）

对象模型 = 静态骨架
动态模型 = 在骨架上跑"时序"（对象 = 状态机主体）
功能模型 = 在骨架上做"变换"
- DFD 中的加工 ≈ 对象模型中类的方法
- DFD 中的数据存储 ≈ 对象模型中类的属性
三者必须并建，缺一不可

4.2 哪些用于需求分析？

功能模型：需求分析最核心（DFD 直接描述系统功能需求）
对象模型：用于需求分析（识别候选对象和类）
动态模型：用于系统分析阶段（控制流、状态转换），部分用例的动态行为也在需求分析中识别

结论：功能模型主要用于需求分析；对象模型和动态模型主要用于系统分析（OOA 阶段）。

五、2024+ 视角

5.1 自动化画图工具

工具	特点	适用
PlantUML	文本式画图，写代码生成 UML	程序员、技术评审
Mermaid	Markdown 友好，GitHub/Hugo 原生支持	文档嵌入
Draw.io	图形化拖拽，免费	非程序员、白板
Structurizr DSL	C4 模型首选	架构图
Mermaid Live Editor	浏览器实时预览	快速原型

PlantUML 画时序图示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
@startuml
actor 患者
participant "预约界面" as UI
participant "数据库访问类" as DAO
database "医生列表" as DB1
database "医生出诊时段表" as DB2

患者 -> UI : 发起预约挂号请求
UI -> DAO : 获取医生信息
DAO -> DB1 : 加载医生信息
DB1 -> DB2 : 加载医生出诊时段
DB2 --> UI : 返回医生可预约时段
UI --> 患者 : 显示医生可预约时段
患者 -> UI : 选择医生/时间确认预约
UI -> DAO : 写入预约信息
DAO --> UI : 返回预约结果
UI --> 患者 : 显示预约结果
@enduml

Mermaid 画时序图示例

sequenceDiagram
    actor 患者
    患者->>预约界面: 发起预约挂号请求
    预约界面->>数据库访问类: 获取医生信息
    数据库访问类->>医生列表: 加载医生信息
    医生列表->>医生出诊时段表: 加载出诊时段
    医生出诊时段表-->>预约界面: 返回可预约时段
    预约界面-->>患者: 显示医生可预约时段
    患者->>预约界面: 确认预约
    预约界面->>数据库访问类: 写入预约信息
    数据库访问类-->>预约界面: 返回结果
    预约界面-->>患者: 显示预约结果

5.2 UML 在云原生时代的变化

C4 模型（Simon Brown）逐渐取代传统 UML 4+1 视图——更贴近代码、易维护
ADR（架构决策记录） + Fitness Function：UML 静态图 → 架构可执行验证
大模型生成 UML：GPT-4 / Claude 直接从需求文档生成用例图、时序图
领域驱动设计（DDD）：UML 类图 → 限界上下文、聚合根、领域事件
Arc42 文档模板：UML 图 + 架构决策 + 质量场景一体化

5.3 软考答题趋势

2024+ 软考更注重实战应用——只背图元素不够，要会从需求中"识别"和"画图"
题目经常给业务描述，让你画 UML 图（不再只是填空）
协作图考频下降（被时序图替代），但区别对比题仍是送分题

六、答题套路总结（软考专用）

题型	套路
填参与者	看动作的发起方（“谁登录/谁查询”）
填用例	提取功能描述里的动词短语（每个动词 = 一个用例）
填对象	提取题干里的实体名词（界面、类、表、控制器）
填消息	提取动词（“发起/加载/返回/传送”）
区别对比题	答"强调重点 / 表示方法 / 布局 / 易读性" 4 个维度
三种模型题	答"关注点 / 主要元素 / 解决什么问题" 3 个维度 + 关联关系

参考资料

2021 年下半年系统架构设计师考试真题（下午案例分析试题二）
《系统架构设计师教程》第 7 章软件工程
UML 2.5 规范（OMG 官方）
《UML 用户指南》Grady Booch、James Rumbaugh、Ivar Jacobson
《PlantUML 官方文档》https://plantuml.com/
《Mermaid 官方文档》https://mermaid.js.org/