用例图怎么画：从题目到图的 5 步（通用方法）
用例图画不出来，通常不是不会画小人和椭圆，而是不知道从题目里怎么抽参与者、目标和系统范围。本文给一套通用 5 步法：先定边界，再列参与者与目标，用最少的关系把图画清楚，并附示例与自查清单。
结论先说：画用例图最稳的方法，是把题目里的“谁（系统外）→ 想达成什么目标 → 系统提供哪些能力”抽出来，然后用系统边界把范围框住。
你不需要一开始就把 include / extend / 泛化全用上；多数作业、需求讨论、功能范围梳理，只要把“参与者—用例”的基础关联画清楚，就已经是合格的用例图。
如果你想边写边出图，可以直接用在线生成器把参与者、用例和关系拖拽出来：
下面给你一套从题目到图的 5 步通用画法（适合课程设计、需求文档、产品功能梳理）。
第 0 步：先把“题目”翻译成一句话（避免越画越散）
很多题目会写得很长，比如：
设计一个图书管理系统，支持读者注册登录、查询图书、借阅归还、查看借阅记录；管理员可以维护图书信息、处理借阅归还；系统对接短信通知。
先把它翻译成一句话（你画图时就拿这句当“北极星”）：
- 系统：图书管理系统
- 主要外部角色：读者、管理员、短信平台（外部系统）
- 主要目标：查书、借还、维护图书、发送通知
这一步的作用是：把“范围”先定住，不然你会在画到一半时开始补各种页面、按钮、字段，图就乱了。
第 1 步：画系统边界（先画框，再放内容）
系统边界就是一个大矩形框，框上写系统名：
- 图书管理系统
- 在线订餐系统
- 学生选课系统
一个实用原则：边界内只放“系统提供的能力”（用例），边界外只放“系统外的角色”（参与者）。
常见卡点：系统边界写模块名还是系统名？
- 只画一个模块也可以，但建议写成“系统名（模块）”，例如“图书管理系统（借阅模块）”，避免读者误解你画的是另一个系统。
第 2 步：从题目里找参与者（不要把“内部组件”当参与者）
参与者（Actor）是系统边界之外、会与系统交互的角色。它可以是人，也可以是外部系统。
从题目抽参与者的简单方法：
- 找“谁能做什么”的主语：读者、管理员、教师、客服……
- 找“系统对接/调用”的对象：短信平台、支付平台、第三方登录……
- 把系统内部东西剔除：数据库、服务器、缓存、内部模块通常不作为参与者
对于“用户”这种词，建议具体化成角色：
- 不写：用户
- 更清晰：普通用户 / 管理员 / 商家 / 运营
经验值：一个用例图里参与者 2～5 个最舒服；超过就考虑拆图（按子系统/按场景）。
第 3 步：给每个参与者列用例（写“目标”，别写“步骤”）
用例（Use Case）表达的是参与者要达成的目标，不是界面动作。
- ✅ 目标式命名：查询图书、借阅图书、归还图书、管理图书信息
- ❌ 步骤式命名：点击查询按钮、打开列表页、进入详情页
一个稳的命名模板：
- 动词 + 名词（查询图书、提交订单、生成报表）
再用两条“防跑偏”规则：
- 如果你写出来的用例里出现“页面/按钮/弹窗”，十有八九在画流程而不是用例。
- 如果一个用例长得像“管理xxx”，先问一句：管理包含哪些目标？能不能拆成 3～6 个更具体的目标（新增/修改/删除/查询/审批…）。
第 4 步：先连基础关联线，再决定要不要 include / extend / 泛化
4.1 先画关联（大多数情况只需要这个）
把参与者和它会用到的用例用实线连起来：
- 读者 —— 查询图书
- 读者 —— 借阅图书
- 管理员 —— 维护图书信息
这一层已经能清楚表达“谁使用哪些能力”。
4.2 再判断 include / extend（少用，但用对很加分）
如果你确实需要表达“复用”和“可选扩展”，再加这两类关系。
-
include（包含）：A 用例执行时，B 用例必定发生，且 B 常被多处复用
- 例：借阅图书 include 校验读者资格
-
extend（扩展）：A 用例执行时，B 用例可能发生（条件触发/可选流程）
- 例：登录 extend 二次验证（只有触发风险时出现）
一句话判断：
- “每次都要做”更像 include
- “有条件才做”更像 extend
4.3 最后再看要不要泛化（宁缺毋滥）
泛化适合表达“同一类角色/用例”的继承：
- 参与者：用户 → 普通用户 / 管理员
- 用例：支付订单 → 微信支付 / 支付宝支付
如果你只是想让图更“学术”，那先别上泛化；用例图的价值在清晰，不在花哨。
第 5 步：做一次“可读性整理”（让别人一眼看懂）
把图画出来后，花 3 分钟做整理，效果会差很多：
- 把参与者放在左右两侧，系统边界在中间
- 用例按模块/业务域摆放（借阅相关放一组、维护相关放一组）
- 线尽量别交叉；宁可移动布局，也别让线穿来穿去
- 用例数量太多就拆图：按“读者视角 / 管理员视角”各一张，或者按子系统拆
到这一步，如果你还没开始画，可以用工具快速把结构搭起来再微调：
示例：从题目抽出一张最小可用的用例图（文字版）
题目（简化）：
图书管理系统：读者可注册登录、查询图书、借阅归还、查看记录；管理员维护图书信息；系统对接短信通知。
1）参与者
- 读者
- 图书管理员
- 短信平台（外部系统）
2）用例（按目标列）
读者相关：
- 注册账号
- 登录系统
- 查询图书
- 借阅图书
- 归还图书
- 查看借阅记录
管理员相关：
- 维护图书信息（可进一步拆：新增/修改/下架/查询）
通知相关：
- 发送借阅通知
3）关系（只画必要的）
- 读者 —— 注册账号、登录系统、查询图书、借阅图书、归还图书、查看借阅记录
- 图书管理员 —— 维护图书信息
- 借阅图书 include 校验读者资格（如果题目明确每次都必须校验）
- 借阅图书 / 归还图书 —— 发送借阅通知（如果通知是必发就用 include；如果可选/失败不影响主流程，可不画或用 extend）
你会发现：即使不画任何页面，也能把系统功能范围与交互对象讲清楚。
画完后自查：一张合格用例图的 10 条清单
- 系统边界是否明确写了系统名？
- 参与者是否都在边界外？是否都是“系统外的角色/外部系统”？
- 用例是否都在边界内？
- 用例命名是否以“动词 + 名词”为主？
- 是否避免了“点击/进入/跳转”等界面步骤词？
- 用例粒度是否一致（不会一边写“管理图书”，一边写“删除某一本图书”）？
- 参与者数量是否过多（>5）导致阅读困难？需要拆图吗？
- 线是否大量交叉？布局是否还能整理？
- include/extend 是否满足“必经/可选”的条件？
- 图是否能用一句话读出来：谁，为了什么目标，使用系统哪些能力？
常见问题（FAQ）
Q1：用例图里要不要画“登录/注册”？
看题目和范围。
- 如果题目明确要求“支持登录/注册”，或你在需求里需要表达“访问系统能力需要身份”，就画。
- 如果你的用例图只关注业务功能（比如“借阅/归还”），也可以不画登录，把“身份校验”作为前置条件写在文字说明里。
Q2：include 和 extend 老分不清，有没有更简单的判断？
有：把它当成“必经步骤”与“条件分支”。
- 每次执行都离不开的复用步骤：include
- 只有在某些条件下才出现的可选流程：extend
如果你不确定，就先别画。用例图不是必须画关系大全。
Q3：用例要写到多细？
一般做到“一个用例 = 一个清晰的业务目标”就够了。
- “维护图书信息”太大：可以拆成“新增图书/修改图书/下架图书/查询图书”。
- “删除某一本具体图书”太细：这更像“维护图书信息”里的一个操作，不一定单独成用例。
Q4：能不能把流程细节也画在用例图里？
不建议。
用例图擅长表达范围与交互；流程细节更适合：
- 活动图 / 流程图：步骤、分支、循环
- 时序图：对象交互与消息顺序
如果你确实需要说明“借阅图书怎么走”，可以在用例图之外补一张活动图或在文档里写主成功场景（Main Flow）。
如果你已经有题目描述，但不知道参与者和用例怎么拆，建议把题目原文贴进生成器里先生成一个初稿，再按本文的 5 步法做二次整理：