本文聚焦系统架构师案例题中的系统建模部分，重点说明 UML、E-R 图和 DFD 分别想表达什么、各自适合回答什么问题、彼此容易混淆的边界在哪里，以及在案例题里遇到题干描述时应如何快速判断该用哪一种图。
学习这一章时，最好不要把它理解成"记一堆图形符号"。真正重要的是：面对一个业务系统，你能不能选对视角，把需求、交互、流程、状态、数据结构和数据流分别画清楚。
一、先建立整体认识
很多人学系统建模会觉得乱，原因不是图太多，而是没有分清这些图各自在回答什么问题。
同样是"订单系统"，不同图看到的其实是不同侧面：
- 产品经理关心"用户能做什么"，这更像用例图
- 架构师关心"下单时哪些对象按什么顺序交互"，这更像时序图
- 业务分析师关心"订单从创建到支付到发货如何流转"，这更像活动图
- 领域建模时关心"订单、用户、商品之间是什么关系"，这更像 E-R 图
- 分析数据加工过程时关心"数据从哪里来，经过哪些处理，又流向哪里"，这更像 DFD
所以系统建模不是在画"同一张图"，而是在用不同视角描述同一个系统。
可以先把这章压缩成一句话：
- 用例图看功能边界
- 时序图和通信图看对象协作
- 活动图看流程
- 状态图看生命周期
- E-R 图看数据结构
- DFD 看数据流动
只要先把这个总框架建立起来，后面的内容就不容易混。
二、UML 图到底在解决什么问题
1. 先记住 UML 最常考的几类图
UML 是统一建模语言，本质上是一套用图形表达系统的标准方法。案例题里不是所有 UML 图都常考，高频的主要是下面几种：
| 图 | 它最关心什么 | 最适合回答的问题 |
|---|---|---|
| 用例图 | 系统功能与外部参与者 | 谁在用系统，系统提供了哪些功能 |
| 时序图 | 交互的时间顺序 | 谁先调用谁，消息按什么顺序走 |
| 通信图 | 对象之间的链接关系 | 哪些对象相互协作，消息沿哪些连接传递 |
| 活动图 | 业务流程和并发 | 业务步骤怎么推进，哪里分支，哪里并行 |
| 状态图 | 对象生命周期 | 一个对象会经历哪些状态，因什么事件切换 |
如果题目是在问"这个系统有什么功能""有哪些外部角色"，不要急着画动态过程，那多半应该先想到用例图；如果题目是在问"提交订单后依次发生了什么调用"，那重点就会落到时序图。
2. 用例图为什么适合讲需求边界
用例图最适合回答的是：系统对外提供了哪些能力，谁会来使用这些能力。
比如在一个在线教育平台里：
- 学员可以选课、学习、提交作业
- 教师可以发布课程、批改作业
- 支付平台可能作为外部系统参与支付
这时最重要的不是内部怎么实现，而是先把系统边界和参与者关系画出来。用例图就是干这个的。
它的核心元素不多：
| 元素 | 含义 | 怎么理解 |
|---|---|---|
| 参与者 Actor | 与系统交互的外部实体 | 可以是人，也可以是外部系统 |
| 用例 Use Case | 系统提供的一项功能 | 例如"下单""支付""查询订单" |
| 关联 | 参与者和用例之间的联系 | 谁可以触发这个功能 |
案例题里最容易考的是用例之间的三种关系：
| 关系 | 含义 | 记忆方式 |
|---|---|---|
| include | 必须复用 | 主用例一定会调用被包含用例 |
| extend | 条件扩展 | 在特定条件下才追加某个行为 |
| generalization | 泛化继承 | 一般与特殊的关系 |
怎么区分 include 和 extend：
include更像"公共必做步骤"，例如"提交订单"一定包含"校验商品库存"extend更像"可选增强步骤"，例如"支付成功后"才可能触发"发送优惠券"
考试识别信号：
- 题干强调"用户、管理员、外部系统"等角色
- 题干强调"系统提供的功能"
- 问的是需求范围，而不是内部调用细节
这时优先想到用例图。
3. 时序图和通信图为什么总被放在一起考
这两种图描述的是同一类事情: 对象之间如何协作。区别在于观察重点不同。
3.1 时序图更关注"先后顺序"
时序图适合表达一条业务链路是如何按时间展开的。
比如"用户提交订单"这件事，可能会经历：
- 前端调用订单服务
- 订单服务调用库存服务
- 库存服务返回校验结果
- 订单服务调用支付服务
- 支付服务返回支付状态
如果你想把"谁先发生、谁后发生、谁等待谁"讲清楚，时序图最好用。
时序图里的高频元素包括：
| 元素 | 作用 |
|---|---|
| 对象/参与者 | 参与交互的实体 |
| 生命线 | 表示对象在交互期间持续存在 |
| 激活条 | 表示对象正在执行某个操作 |
| 消息 | 表示一次调用或返回 |
高频考点是三类消息：
| 消息类型 | 含义 | 更直观的理解 |
|---|---|---|
| 同步消息 | 发送方等待接收方处理完成 | 像普通方法调用 |
| 异步消息 | 发送方发出后继续往下执行 | 像发消息、投递任务 |
| 返回消息 | 表示调用结果返回 | 把处理结果带回来 |
另一个常考点是交互片段：
| 片段 | 作用 | 常见题意 |
|---|---|---|
| opt | 单条件可选执行 | "如果满足条件则执行" |
| alt | 多分支互斥选择 | "成功走一条，失败走另一条" |
| loop | 循环执行 | "重复处理直到满足条件" |
| par | 并行执行 | "两个动作同时进行" |
| break | 中断后转出 | "一旦异常就终止当前流程" |
| critical | 临界区 | "这一段不能被打断" |
| ref | 引用其他交互 | "这里省略，引用另一张图" |
其中最常见的是 opt 和 alt：
opt是一条可选分支alt是多条互斥分支
3.2 通信图更关注"谁和谁有联系"
通信图在 UML 1 中也常叫协作图。它同样描述对象间的消息传递，但更强调对象之间原本就有什么连接关系。
如果说时序图像在看一段录像，通信图更像在看一张协作关系网。
比如在订单场景里，通信图更容易看出：
- 前端和订单服务有连接
- 订单服务和库存服务有连接
- 订单服务和支付服务有连接
- 消息沿这些连接按编号传递
所以通信图更适合表达"协作结构"，而不是详细的时间轴。
3.3 两者怎么区分和选用
| 维度 | 时序图 | 通信图 |
|---|---|---|
| 核心关注点 | 时间顺序 | 对象链接关系 |
| 顺序表达方式 | 自上而下时间轴 | 依靠消息编号 |
| 适合场景 | 强调调用先后、等待、返回 | 强调对象协作结构和职责分配 |
| 阅读体验 | 顺序直观 | 结构直观 |
标准答法可以这样写：
- 若需要描述对象交互的先后顺序和动态过程，应采用时序图
- 若需要描述对象之间的组织关系和协作结构，应采用通信图
4. 活动图为什么适合讲业务流程
活动图描述的是"事情怎么一步一步流转"。它很像流程图，但比普通流程图更适合软件系统，因为它能表达并发、职责划分和流程汇合。
比如请假流程可能是：
- 员工提交申请
- 系统校验剩余假期
- 部门主管审批
- 人事归档
- 系统通知申请人
如果其中"消息通知"和"日志记录"可以并行执行，活动图就比普通文字描述更清楚。
活动图中的常见元素包括：
| 元素 | 含义 |
|---|---|
| 初始节点 | 流程开始 |
| 终止节点 | 流程结束 |
| 活动/动作 | 一个处理步骤 |
| 决策节点 | 条件分支 |
| 合并节点 | 条件分支重新汇合 |
| 分叉/汇合 | 并行开始与并行结束 |
| 泳道 | 把不同角色或部门的职责分开 |
活动图特别适合的场景：
- 跨角色协作流程
- 审批流、工单流、订单履约流
- 有分支、有并发的业务过程
考试识别信号：
- 题干强调"流程步骤""审批流""业务处理过程"
- 图里出现泳道、分支、并发
- 问的是"流程怎么走"，而不是"对象之间怎样发消息"
5. 状态图为什么适合看对象生命周期
状态图描述的是某个对象从创建到结束，中间经历了哪些稳定状态，以及是什么事件把它从一个状态推到另一个状态。
订单场景最典型：
- 待支付
- 已支付
- 已发货
- 已完成
- 已取消
这里重点不是流程步骤，而是"订单这个对象当前处于什么状态"。同样是"取消订单"，在待支付状态可以直接取消，在已发货状态可能就不允许取消，这就是状态建模的价值。
状态图中的关键元素包括：
| 元素 | 含义 |
|---|---|
| 状态 | 对象在某个时刻的稳定条件 |
| 初始状态 | 生命周期起点 |
| 终止状态 | 生命周期终点 |
| 转换 | 状态之间的迁移 |
| 事件/触发 | 导致状态变化的原因 |
| 守卫条件 | 转换发生前必须满足的条件 |
| 动作 | 转换时执行的行为 |
和活动图怎么区分：
- 活动图看"流程步骤"
- 状态图看"对象状态"
如果题目给你的是一个业务对象在不同阶段的变化，优先想到状态图；如果题目给你的是整条业务流程的执行路径，优先想到活动图。
三、E-R 图到底在表达什么数据结构
1. 为什么数据库设计离不开 E-R 图
当业务需求逐渐稳定后，系统迟早要落到数据结构设计。你要知道系统里有哪些核心对象、它们各自有什么属性、彼此之间是什么关系，这时 E-R 图就派上用场了。
它回答的是：现实业务里的事物，如何被抽象成数据库里的实体和联系。
以电商系统为例：
- 用户是实体
- 订单是实体
- 商品是实体
- "用户下订单""订单包含商品"是联系
E-R 图本质上服务于数据库概念设计。
2. E-R 图的核心元素
| 元素 | 含义 | 常见图形 |
|---|---|---|
| 实体 | 可以独立识别的业务对象 | 矩形 |
| 属性 | 实体的特征 | 椭圆 |
| 联系 | 实体之间的业务关系 | 菱形 |
3. 联系类型怎么判断
| 联系类型 | 含义 | 典型例子 |
|---|---|---|
| 1:1 | 一边一个，另一边也一个 | 用户与身份证 |
| 1:N | 一边一个，另一边多个 | 部门与员工 |
| M:N | 两边都可能多个 | 学生与课程，订单与商品 |
题目里如果出现"一个部门有多个员工""一个用户可有多个收货地址"，一般就是 1:N；如果出现"两边都能重复出现"，就要警惕 M:N。
工程上还有一个很重要的落地判断：
M:N关系在关系数据库里通常要拆成中间表
例如"订单和商品"通常会拆出"订单明细"这样的关联实体。
4. 常见扩展概念怎么理解
| 概念 | 含义 | 怎么理解 |
|---|---|---|
| 主键 | 唯一标识实体的属性 | 像实体身份证 |
| 外键 | 引用其他实体主键的属性 | 用来建立表之间关联 |
| 弱实体 | 依赖其他实体存在 | 自身不能完全独立标识 |
| 派生属性 | 可以通过其他属性算出 | 如年龄可由出生日期推导 |
| 多值属性 | 一个属性可取多个值 | 如一个人多个联系电话 |
5. 考试里怎么识别 E-R 图题
- 题干强调"实体、属性、联系"
- 要求做数据库概念结构设计
- 要求判断一对一、一对多、多对多
- 要求识别主键、外键或补全实体关系
如果题目关注的是"数据之间的静态关系"，一般就是 E-R 图视角，而不是 DFD 视角。
四、DFD 为什么强调数据怎么流动
1. DFD 和 E-R 图最容易混，但关注点完全不同
很多人会把 E-R 图和 DFD 混在一起，因为两者都和"数据"有关。但它们描述的不是同一件事。
- E-R 图强调数据对象之间的静态关系
- DFD 强调数据在系统中的流入、加工、存储和流出
可以这样理解：
- E-R 图像在回答"系统里有什么数据对象"
- DFD 像在回答"数据进入系统后经历了什么处理"
2. DFD 的四大元素
| 元素 | 含义 | 怎么理解 |
|---|---|---|
| 外部实体 | 系统外部的数据来源或去向 | 人、外部系统、第三方平台 |
| 加工 | 对数据的处理过程 | 校验、转换、计算、汇总 |
| 数据流 | 数据在元素之间的流动 | 输入、输出、传递的数据 |
| 数据存储 | 数据被保存的位置 | 文件、库表、存储介质 |
比如在报销系统中：
- 员工提交报销单，是外部输入
- 报销审核，是加工
- 报销单数据在节点间传递，是数据流
- 报销数据库，是数据存储
DFD 不关心控制逻辑细节，所以它通常不去表达循环、分支代码、对象消息细节，而是抓住"数据怎么走"。
3. 分层分解为什么是 DFD 的高频考点
DFD 支持从粗到细分层描述系统。
常见层次包括：
- 顶层图：把整个系统当成一个总加工，只展示它和外部实体之间的数据交换
- 0 层图：把总加工拆成若干主要加工
- 1 层图、2 层图：继续细化某个加工
案例题里经常会问你某个分解是否正确，关键就看平衡原则。
所谓平衡，就是：
- 父图中某加工的输入输出数据流，到了子图中仍要能对应得上
- 不能父图里有一个输入，子图里忽然多出一个莫名其妙的新出口
4. DFD 常见规则怎么记
| 规则 | 原因 |
|---|---|
| 外部实体之间不能直接连数据流 | 那说明数据没经过系统处理 |
| 数据存储之间不能直接连数据流 | 存储之间应通过加工发生作用 |
| 加工必须既有输入也有输出 | 否则加工没有意义 |
| 数据流应有名称 | 否则不知道流动的是什么 |
| 父图与子图保持平衡 | 保证分解前后语义一致 |
5. 考试里怎么补 DFD
做 DFD 题时，顺序通常比死记符号更重要，可以按下面思路处理：
- 先找外部实体，看题干里有哪些人、部门、外部系统
- 再找加工，看题干里有哪些处理动作
- 再找数据流，看每个加工的输入和输出是什么
- 最后补数据存储，看哪些数据需要持久化
- 回头检查父子图是否平衡、有没有非法直连
五、这些图在题目里到底怎么选
| 题目要表达的重点 | 优先选择的图 |
|---|---|
| 系统有哪些功能，谁在使用 | 用例图 |
| 对象之间的调用先后顺序 | 时序图 |
| 对象之间的协作结构 | 通信图 |
| 业务流程、审批流、并行步骤 | 活动图 |
| 某个对象的生命周期变化 | 状态图 |
| 数据实体、属性和联系 | E-R 图 |
| 数据的流入、加工、存储和流出 | DFD |
如果还拿不准，可以反问自己一句：
- 我现在更想说明"谁和谁交互"还是"数据怎么流"
- 我现在更想说明"功能边界"还是"对象调用过程"
- 我现在更想说明"流程步骤"还是"状态变化"
一旦问题问对了，图的选择通常就不难了。
六、怎么考，怎么答
1. UML 图选择题
题干如果强调"用户、管理员、外部系统、功能模块"，常考用例图；如果强调"对象之间消息交互顺序"，常考时序图；如果强调"对象之间的组织和协作关系"，常考通信图。
2. 时序图细节题
高频问法包括：
- 时序图有哪些消息类型
- 条件分支该用
opt还是alt - 缺失的对象、消息、返回箭头如何补全
3. 活动图与状态图标准答法
题干如果围绕"业务过程如何推进"，通常考活动图；如果围绕"对象状态如何变化、由什么事件触发切换"，通常考状态图。
4. E-R 图标准答法
高频问法包括：
- 根据业务描述抽取实体和联系
- 判断联系类型
- 识别主键、外键、弱实体
- 将多对多联系转化为中间实体
5. DFD 标准答法
高频问法包括：
- 补全外部实体、加工、数据流、数据存储
- 判断分层分解是否正确
- 检查父图与子图是否平衡
- 判断是否存在非法数据流连接
七、答题模板
1. 时序图与通信图选型题
时序图主要用于描述对象之间交互的时间顺序和动态过程，适合表现消息的先后次序；通信图主要用于描述对象之间的组织关系和协作结构，适合表现对象之间的链接关系与职责分配。
2. 用例图关系辨析题
include表示基础用例必须包含某公共行为，被包含用例会被重复复用；extend表示在特定条件下对基础用例进行可选扩展，因此前者强调必选复用，后者强调条件触发。
3. 活动图与状态图区分题
活动图主要描述业务流程和处理步骤，强调流程推进、分支、并发和泳道职责；状态图主要描述对象在生命周期中的状态变化，强调状态、事件、守卫条件和状态转换。
4. E-R 图题
E-R 图用于数据库概念结构设计，通过实体、属性和联系描述系统中的数据对象及其关系。分析时应先识别核心实体，再判断实体间联系类型，最后确定主键、外键及必要的中间实体。
5. DFD 题
DFD 用于描述数据在系统中的流动、加工与存储。作图时应先确定外部实体，再确定加工、数据流和数据存储，并检查加工是否既有输入又有输出，以及父图与子图之间是否保持平衡。