用例图 vs 活动图 vs 时序图 vs 流程图：什么时候用哪个？
一次讲清用例图、活动图、时序图、流程图分别解决什么问题、适合的使用场景，以及从同一个需求如何选择或组合使用。
很多人第一次做需求文档时都会卡在同一个问题：到底该画用例图、活动图、时序图，还是流程图？
这四种图并不是“谁更高级”，而是回答的问题不同。选对图，沟通会更省力；选错图，经常会出现“图很漂亮但没人看懂”“实现出来跟预期不一致”。
如果你现在只是想先把需求快速整理成用例图（先把参与者和功能边界定下来），可以先用这个在线工具把文字梳理成草图，再手工微调：
下面我们用一个统一的例子，把四种图放在一起对比，并给你一套“什么时候用哪个”的判断规则。
先记住一句话：四种图分别在“回答不同问题”
- 用例图（Use Case Diagram）：系统提供哪些功能？谁会用？边界在哪里？
- 活动图（Activity Diagram）：这个业务/功能内部的步骤怎么走？有哪些分支与并行？
- 时序图（Sequence Diagram）：参与对象之间的调用顺序是什么？消息先后与返回是什么？
- 流程图（Flowchart）：用更通用的符号表达一个流程/操作步骤（不一定强调系统与对象）。
你可以把它们看成从不同视角描述同一件事：
- 用例图偏“范围与角色”
- 活动图偏“过程与规则”
- 时序图偏“交互与接口”
- 流程图偏“通用流程表达”（面向非技术或跨团队更常见）
快速选择：按你的目标选图（最常用的 6 个场景）
1）你要对齐“系统做什么、不做什么” → 用例图
适合场景：
- 立项/需求评审前：确认功能范围、外部角色、外部系统
- 多个系统边界交错：需要先把“谁负责什么”分清
你在用例图里通常要表达：
- 参与者（人/角色/外部系统）
- 用例（系统功能点）
- 系统边界（系统范围）
- 用例之间的关系（include/extend/泛化，必要时才用）
**不适合拿用例图去表达：**具体页面流程、每一步的判断条件、接口调用细节。
2）你要描述“一个业务怎么跑、分支怎么走” → 活动图
适合场景：
- 一段业务规则很多：审批、风控、订单状态流转
- 需要表达分支（if/else）、并行、泳道分工（谁做哪一步）
活动图强在：
- 把“动作 + 判断 + 合并”串起来
- 能自然放入泳道：产品/用户/系统/第三方分别做哪些动作
3）你要明确“谁先调用谁、接口怎么串” → 时序图
适合场景：
- 前后端/多服务交互复杂：登录、支付、回调、库存锁定
- 需要对齐接口顺序、超时、重试、幂等、异常路径
时序图强在：
- 时间顺序明确（从上到下）
- 对象/服务之间的消息一目了然
4）你要给非技术同学讲清一个操作流程 → 流程图
适合场景：
- SOP、运营流程、线下流程、客服流程
- 跨部门协作但不想引入 UML 术语
流程图强在：
- 符号简单、受众广
- 不强调“系统边界”和“对象”，强调“步骤”
5）你要写 PRD/需求说明：先范围、再过程、最后接口 → 组合使用
常见组合（从粗到细）：
- 用例图：定范围（有哪些功能、谁用）
- 活动图/流程图：描述关键流程与分支
- 时序图：落到技术实现与接口交互
6）你只需要“一个页面怎么点、怎么跳转” → 先别画 UML
如果你的目的只是“页面 A 点击按钮到页面 B，失败弹窗”，很多时候：
- 线框图/页面原型
- 用户旅程/页面流程图 更直接。
统一示例：以“电商下单”为例，看四种图各画什么
假设需求：用户在 App 下单购买商品，支持优惠券、库存校验、支付。
用例图会关注：角色与功能边界
你会列出：
- 参与者：用户、支付平台、库存系统、营销系统
- 用例：浏览商品、加入购物车、提交订单、使用优惠券、支付、查看订单
- 系统边界：电商系统（哪些属于本系统，哪些是外部系统）
用例图画完，你能回答：
- 我们这一期要做哪些功能点？
- 哪些外部系统会参与？
活动图会关注：提交订单这件事“怎么走”
你会把“提交订单”拆成动作与分支：
- 校验收货地址 → 校验库存 → 计算价格 → 校验优惠券
- 库存不足？→ 提示缺货
- 优惠券不可用？→ 提示原因或移除
- 价格变化？→ 二次确认
活动图画完，你能回答：
- 规则在哪里？分支有哪些？
- 哪一步由谁完成（泳道）？
时序图会关注：服务之间的调用顺序
你会画出对象/服务：
- App → 订单服务 → 库存服务 → 营销服务 → 支付服务 并明确：
- 先锁库存还是先创建订单？失败怎么回滚？
- 支付回调谁接？回调幂等怎么保证？
时序图画完，你能回答：
- 接口调用顺序是什么？
- 失败路径与返回码如何处理？
流程图会关注：对用户/运营可理解的步骤
你可能这样写：
- 选择商品 → 填写地址 → 选择优惠 → 确认支付 → 支付成功/失败 → 查看订单
流程图画完，你能回答：
- 用户操作的“主线”是什么？
- 适合放在培训材料或运营手册里
一张对比清单：四种图分别适合输出什么
- 用例图：
- 输出：功能清单、范围边界、角色列表
- 读者：产品、需求、项目、架构
- 活动图：
- 输出：步骤与业务规则、分支、泳道职责
- 读者：产品、需求、开发、测试
- 时序图：
- 输出：对象/服务交互顺序、接口串联、异常路径
- 读者：开发、架构、测试
- 流程图：
- 输出：通用流程/SOP、用户操作路径
- 读者：跨部门/非技术团队更友好
常见误区（选错图通常是因为这些）
- 用例图画成了流程图
- 用例图不强调“先做什么后做什么”。如果你发现自己一直在画箭头顺序，可能该用活动图/流程图。
- 活动图里塞满接口细节
- 活动图适合表达规则和步骤，但“哪个服务调哪个接口、请求/响应字段”更适合时序图或接口文档。
- 时序图把所有页面操作都画进去
- 时序图重点是对象交互。页面点击这种 UI 细节，除非会影响接口顺序，否则建议简化。
- 一张图想解决所有问题
- 需求复杂时，一张“巨图”往往难维护。拆成“范围（用例）—主流程（活动/流程）—关键交互（时序）”通常更清晰。
实操建议：从 0 到 1 的画图顺序（可直接照做）
- 先写一句“系统边界”
- 例如：本期讨论的系统是“电商下单系统”，不包含支付平台。
- 画用例图（先粗后细）
- 先放参与者与 6–12 个核心用例
- 关系（include/extend）先少用，等大家对范围一致后再加
- 选 1–2 条关键路径画活动图/流程图
- 例如：提交订单、支付成功/失败
- 把规则写清：校验、分支、并行、重试
- 对最容易出故障的部分画时序图
- 例如：支付回调、库存锁定与释放
- 明确异常与补偿：超时、重复回调、库存不足
如果你想更快把“参与者 + 功能点”先落在图上（尤其是评审前需要一张范围图），可以用这个页面把需求整理成用例图草稿：
小结
- 用例图：先把“谁用、做什么、范围在哪”说清楚
- 活动图：把“怎么走、分支与规则”说清楚
- 时序图：把“谁先调谁、接口顺序与异常”说清楚
- 流程图：把“通用步骤/操作路径”说清楚
当你不知道从哪张开始时：先用例图定范围，再用活动图/流程图定规则，最后用时序图定交互。