一、 动笔前的认知重构
很多初学者在搜索“用例图怎么画”时，往往急于打开软件拖拽图标。但最关键的步骤其实发生在你的脑海里。用例图的核心目的只有一个：界定系统的功能边界。
它主要回答三个问题：
- 谁在使用系统？（Who - 参与者）
- 系统提供了什么价值？（What - 用例）
- 系统的边界在哪里？（Where - 系统边界）
📌 关键认知： 用例图是黑盒视图。它只关心系统对外提供了什么功能，不关心系统内部是如何实现这些功能的（那是类图和时序图的事）。
二、 庖丁解牛：拆解三大核心要素
1. 参与者 (Actor)：不只是“人”
在UML中，用火柴人表示参与者。但请注意，参与者代表的是角色（Role）而非具体的人。
- 人类用户：如“管理员”、“VIP会员”、“游客”。
- 外部系统：如“支付宝接口”、“物流系统”。如果你的系统需要向它们发送请求，它们也是参与者。
- 定时任务/时间：如果系统每天凌晨自动备份，那么“时间”也可以看作一个特殊的参与者。
2. 用例 (Use Case)：动宾短语的艺术
用例是系统能够为参与者提供的、具有完整业务价值的功能单元。通常用椭圆表示。
🚫 常见错误：粒度过细
不要把“输入密码”、“点击登录按钮”当作用例。这些只是步骤。“用户登录”才是一个完整的用例。判断标准：这个功能执行完后，用户是否获得了一个可衡量的结果？
3. 系统边界 (System Boundary)
用一个大的矩形框将所有的用例包裹起来，参与者在框外。这表示：框里的是你要开发的，框外的是现有的或别人的。
三、 攻克最难点：四种关系详解
“线”怎么连？箭头指向哪？这是绘制用例图时最大的拦路虎。
| 关系类型 | 线条样式 | 核心逻辑 | 口诀 |
|---|---|---|---|
| 关联 (Association) | 实线 | 参与者与用例之间的交互。 | 谁用谁连线 |
| 包含 (Include) | 虚线 + <<include>> | A用例执行时，必须执行B用例。 例：下单 ➜ 包含 ➜ 验证登录。 |
必须有你 箭头指被包含 |
| 扩展 (Extend) | 虚线 + <<extend>> | A用例执行时，可能触发B用例。 例：支付失败 ➜ 扩展 ➜ 支付。 |
可以没你 箭头指基础 |
| 泛化 (Generalization) | 实线空心三角 | 即继承关系。 例：微信支付 ➜ 泛化 ➜ 支付。 |
子承父业 |
*注：扩展关系的箭头方向最容易搞错，记住是从“扩展点”（特殊情况）指向“基础点”（正常流程）。
四、 手把手教程：5步画出标准用例图
假设我们要画一个“图书管理系统”。
确定系统边界
在画布中央画一个大矩形，顶部写上“图书管理系统”。
识别参与者
思考谁用系统？左侧画“学生”、“老师”；右侧画“豆瓣图书API”（外部系统）。
列出核心用例
在矩形框内画椭圆：“借书”、“还书”、“查询书籍”、“预约书籍”。
建立关联
用实线将“学生”与“借书”、“查询”连接；将“豆瓣API”与“查询书籍”连接。
细化关系 (Include/Extend)
- “借书”前必须检查是否有逾期，提取“检查违规记录”（Include）。
- “还书”时若超时，需“缴纳罚金”（Extend）。
五、 绘图工具选型
传统图形拖拽 (GUI)
如 Visio、ProcessOn。
缺点： 排版噩梦。插入新用例时需手动调整所有线条。
如果你厌倦了反复调整线条对齐，推荐尝试 在线用例图生成器。无论是输入简单的指令
用户 -> (登录) 还是使用可视化表单，它都能自动处理所有规范符号。
六、 总结
画好用例图，功夫在诗外。不要纠结于图标画得圆不圆，而要多思考：“这个功能真的有用户用吗？”。
当你理清了业务逻辑，再配合高效的 在线生成工具，绘制一张专业的UML用例图将变得轻而易举。