用例图是什么？3 分钟搞懂参与者、用例、系统边界（附在线生成器）
第一次接触 UML 用例图不知道从哪下手？本文用 3 分钟讲清用例图是什么、参与者/用例/系统边界怎么写，以及关联、包含、扩展、泛化这些关系什么时候用。
很多人第一次画用例图，卡的不是“不会画椭圆和小人”，而是这几个点：
- 参与者到底写谁？用户算不算参与者？外部系统算不算？
- 一个用例要写到什么粒度？“登录”算不算？“注册+登录”要不要拆？
- 系统边界那个大框里到底写什么？写系统名还是模块名？
- 线怎么连才算规范？include / extend / 泛化到底什么时候用？
先给你一个能直接用的结论：用例图的目标不是把流程画细，而是把“谁（参与者）为了什么（目标）使用系统的哪些能力（用例）”画清楚，并明确系统范围（边界）。
你也可以直接打开在线生成器，边看边画：
如果你关心怎么把图放进 Word/PPT，或者后续继续编辑（draw.io），文末也补了一段最常用的导出方式。
用例图是什么（用一句话记住）
用例图（Use Case Diagram）是 UML 中用来描述“系统提供哪些功能（用例），以及外部参与者如何与这些功能交互”的图。
它适合做：需求分析、功能范围梳理、课程设计/产品说明里的功能清单呈现。
它不适合做：把每一步怎么点按钮、怎么跳转、怎么分支的“流程细节”画出来（那更像活动图/流程图/时序图）。
用例图的 3 个核心元素
1）参与者（Actor）：系统外部的角色
参与者指的是在系统边界之外，会与系统发生交互的角色。它可以是：
- 人：用户、管理员、教师、客服
- 外部系统：支付系统、短信网关、第三方登录（微信/QQ）
- 设备/硬件（少见但也可以）：门禁设备、扫码枪
一个简单判断：它是否在系统外部？它是否向系统发起请求或接收系统输出？
常见误区：把“数据库”“服务器”当参与者。通常不这么画，除非你的建模范围明确把它当成外部系统。
2）用例（Use Case）：参与者想达成的目标
用例是“目标”，不是“页面”也不是“按钮”。
- ✅ 更像：登录、查询图书、借书、还书、审批报销、发布公告
- ❌ 不像：点击登录按钮、进入首页、打开弹窗
命名建议用“动词 + 名词”：
- 借阅图书
- 归还图书
- 查询借阅记录
- 管理图书信息
3）系统边界（System Boundary）：你这次要画的系统范围
系统边界是一个大框，用来说明：哪些用例属于“这个系统提供的能力”。
框上通常写系统名：
- 图书管理系统
- 学生选课系统
- 电商平台
如果需要按模块表达，也可以写：
- 图书管理系统（借阅模块）
但不要把系统边界写成一段长描述，保持短、清晰即可。
用例图怎么画：最稳的 5 步
第 1 步：写清“系统名 + 主要使用对象”
先确定你要画的系统范围，例如：
- 系统：图书管理系统
- 主要使用者：读者、图书管理员
第 2 步：列出参与者（一般 2～4 个就够用）
参与者太多会让图迅速变乱；太少又容易缺关键角色。
建议先列核心角色，再补充外部系统。
第 3 步：给每个参与者列“目标清单”（用例列表）
实践里，用例总数在 8～15 个通常比较舒服。
例子（读者）：
- 登录/退出
- 查询图书
- 借阅图书
- 归还图书
- 查看借阅记录
例子（图书管理员）：
- 录入图书
- 更新图书信息
- 下架图书
- 处理借阅/归还
第 4 步：画系统边界，把用例放进框里
把所有用例放进系统边界框中，参与者放在框外两侧。
第 5 步：先连“参与者—用例”的普通关联线
多数情况下，先把基础关联画清楚，就已经能满足“功能范围梳理”的目的。
include / extend / 泛化属于更进一层的表达：只有当你确实需要表达复用、可选扩展、继承关系时再加。
关联 / include / extend / 泛化：什么时候需要（不容易错的判断）
1）关联（Association）
参与者和用例之间的实线连接，表达“这个角色会使用这个功能”。
- 适用：绝大多数用例图场景。
2）include（包含）
A 用例执行时，B 用例必定发生，并且 B 往往会被多个用例复用。
- 例子：借阅图书 include 校验读者资格（每次借阅都必须校验）
3）extend（扩展）
A 用例执行时，B 用例可能发生，也可能不发生，通常是可选/条件触发。
- 例子：登录 extend 二次验证（只有触发风险时才需要）
4）泛化（Generalization，继承）
泛化用来表达“更一般的角色/用例”与“更具体的角色/用例”之间的继承关系：
-
参与者泛化：父参与者表示一类更通用的角色，子参与者继承它的交互能力。
- 例子：参与者“用户”泛化出“普通用户 / 管理员”（两者都属于用户，但权限不同）
-
用例泛化：父用例表示更通用的目标，子用例是更具体的实现方式。
- 例子：用例“支付订单”泛化出“微信支付 / 支付宝支付”
泛化的常见画法是：实线 + 空心三角箭头，箭头指向“更通用”的父参与者/父用例。
不要为了“看起来更专业”而硬上泛化。只有当你确实存在一组“相似但不完全相同”的角色/用例，并且需要抽象出共同部分时，泛化才有价值。
用例图最常见的 7 个错误（对照自查）
- 把流程当用例：写成“进入首页/点击按钮/跳转页面”。
- 用例命名太抽象：写“管理”“处理”“操作”，但不说对象。
- 参与者写成系统内部组件：数据库/服务器/内部模块。
- 系统边界缺失或写太长：看不出范围。
- 用例粒度忽大忽小：一边写“管理图书”，一边写“删除某一本书”。
- include / extend 使用条件不成立：本来是可选流程却画成 include，或者把必经步骤画成 extend。
- 泛化方向画反：空心三角箭头应指向更通用的父参与者/父用例。
导出与交付：PNG / draw.io 怎么选
到这一步，图本身一般就够用了。最后常见的需求是：怎么把图放进文档、怎么留一个后续可编辑的版本。
- 需要插到 Word / PPT / Markdown 文档里：优先导出 高清 PNG（兼容最好）。
- 后面还要持续修改、或想用 diagrams.net 继续排版：导出 draw.io 文件（可二次编辑）。
在线生成器里可以直接生成后导出：
小结：先把范围和交互画清楚，再上高级关系
用例图画得像不像“标准模板”，不在于线有多花，而在于：
- 参与者是否在系统外部
- 用例是否是“目标”而不是“步骤”
- 系统边界是否明确