提到用例图（Use Case Diagram），很多刚接触面向对象分析（OOA）的同学第一反应往往是：“这不就是画个圈圈，外面套几个人形图标吗？这也太简单了，有必要专门讲吗？”
别急着划走。如果你真的这么想，那你很可能正在犯那些资深架构师都在踩的坑。用例图看似简单，实则是整个系统需求的“骨架”。骨架歪了，后面写的代码、设计的类图全得跟着崩盘。今天咱们不整那些枯燥的定义，就拿一个再熟悉不过的场景——大学生选课系统，来一场深度解剖。我会带你看看什么是真正的“参与者”，什么是核心的“用例”，以及为什么你画的图经常被产品经理骂“没逻辑”。
一、 先别急着画图，先搞懂“谁”在参与
在用例图里，最显眼的就是那些火柴人，我们称之为参与者（Actor）。
这里有一个巨大的认知误区：参与者不等于具体的“人”，也不等于“角色名”，更不等于“系统模块”。
1. 参与者的本质：外部实体
参与者是指位于系统边界之外，与系统进行交互的人、设备、时间触发器或其他系统。
让我们回到选课系统。假设我们要设计一个《教务管理系统》。那么，谁是参与者？
- 学生（Student）：这是最直观的。学生去查课、选课、退课。
- 教师（Teacher）：老师录入成绩、查看任课班级名单。
- 教务处管理员（Admin）：设置选课时间段、分配教室、处理冲突。
- 银行支付网关（Bank Gateway）：如果选课需要交学费或押金，系统需要调用外部接口。这时候，“银行”就是一个参与者，哪怕它没有脸，但它是一个独立的系统实体。
- 定时任务调度器（Scheduler）：比如每天凌晨2点自动释放未支付的选课程序。这个“时间”本身也可以被视为一个参与者（通常用时钟图标表示）。
关键点来了： 注意，“学生”是一个抽象的角色，而不是张三或李四。在建模时，我们关注的是行为模式，而不是具体身份。
2. 常见的“伪参与者”陷阱
很多初学者会画出这样的参与者：
- ❌ “前端页面”
- ❌ “数据库”
- ❌ “服务器”
千万别这么干！前端页面、数据库、服务器都是系统内部的实现细节，它们属于系统的边界之内。用例图关注的是功能需求，而不是技术实现。如果用户问：“我要把数据存进MySQL”，你应该回答：“那是后端工程师的事，我只关心你是否成功保存了数据。”
二、 什么是“用例”？不仅仅是动词
用例（Use Case） 是参与者与系统之间为了达成某个特定目标而进行的一系列交互。
1. 用例的特征：达成目标
一个合格的用例必须满足以下条件：
- 有始有终：交互完成后，系统的状态发生了有意义的变化。
- 对参与者有价值：参与者（尤其是外部用户）能从中获得利益。
- 由系统主动响应：不是参与者单方面操作，而是双方互动的结果。
在选课系统中，哪些算用例？
- ✅ “选修课程”：学生发起，系统确认名额，更新状态。有价值，有互动。
- ✅ “查询可选课程”：学生发起，系统返回列表。有价值。
- ✅ “提交成绩”：教师发起，系统存储并通知学生。有价值。
哪些不算用例？
- ❌ “输入用户名”：这只是界面操作，没有达成独立目标。它是“登录”或“选课”过程中的一个步骤。
- ❌ “显示错误提示”：同上，这是异常流的一部分，不是主用例。
- ❌ “连接数据库”：这是内部实现，对用户无直接价值。
2. 粒度控制：多大了才合适？
这是新手最容易纠结的地方。用例应该多大？
- 太小：如果把“点击按钮”、“校验格式”都做成用例，图会变得密密麻麻，失去意义。
- 太大：如果只画一个“使用系统”，那这张图就没法指导开发了。
黄金法则：用例的粒度应该对应于一个完整的功能需求，且通常可以在几分钟到几小时内完成。
在选课系统中，“选课”是一个很好的用例。但如果选课过程极其复杂（比如涉及排队、抽签、跨校互选），你可以将其分解为：
- “申请跨校选课”
- “参与抽签”
- “确认最终课表”
但切记，这些子用例仍然要服务于“选课”这个大目标。
三、 关系：不仅仅是连线
用例图的核心在于关系。UML定义了四种主要关系，但在实战中，只有三种是真正高频使用的。
1. 关联关系（Association）：参与者与用例的握手
这就是那条实线。它表示参与者可以使用该用例。
实战技巧：
- 一条线可以连接多个参与者。
- 一个用例可以有多个参与者。
- 方向性：虽然UML标准允许双向，但在实际交流中，建议箭头指向用例，表示“谁触发了这个用例”。
例子：
学生 —–> 选修课程
教师 —–> 提交成绩
2. 泛化关系（Generalization）：继承与特化
就像类图中的继承一样，泛化关系表示“是一个（is-a）”的关系。
- 参与者泛化：
研究生泛化自学生。这意味着研究生拥有学生所有的用例，还可能拥有自己的特有用例。 - 用例泛化：
在线支付泛化自支付。微信支付和支付宝支付都是在线支付的具体实现方式。
注意：不要在用例泛化上过度设计。除非你有明确的扩展点，否则尽量保持扁平。
3. 包含关系（<>）：必不可少的碎片
这是最容易混淆的概念。包含关系表示：在执行基础用例时，*必须*执行被包含的用例。
关键词：Must。
例子：
在“选课系统”中，无论谁选课，系统都必须先验证身份。
所以：
选修课程 <身份验证
这意味着，如果你删除了“身份验证”这个用例，“选修课程”就无法正常工作。它是一个强制性的子流程。
常见误区：不要把“查询课程详情”作为“选课”的包含用例。因为你可以先查课，不一定马上选。查课是可选的前置动作，不是强制步骤。
4. 扩展关系（<>）：可选的惊喜
扩展关系表示：在基础用例的某个特定条件下，*可能*执行扩展用例。
关键词：If。
例子：
选课 <加入候补队列
这个扩展只在“课程已满”这个特定条件触发时才发生。如果课程有名额，就不会执行“加入候补队列”。
重要区别：
<<include>>是基础用例的一部分，即使不写出来，逻辑上也存在。<<extend>>是对基础用例的补充，基础用例本身是完整的，扩展只是增加了额外的可能性。
5. 依赖与依赖倒置？不，那是类图的事
用例图中不需要考虑依赖注入或接口实现，那些是架构层面的事。用例图只关心业务逻辑。
四、 实战演练：绘制一个健壮的选课系统用例图
让我们把前面的理论拼凑起来，构建一个真实的场景。
场景描述
某高校选课系统，支持本科生和研究生选课。
- 所有学生必须先登录才能操作。
- 学生可以查询课程，也可以选课。
- 如果课程人数已满，学生可以选择加入候补。
- 教师可以录入成绩，但前提是必须有选课记录。
- 系统会在选课结束后自动生成课表。
参与者识别
- 学生（基础参与者）
- 研究生（泛化自学生，可能有一些特殊权限，如跨院系选课）
- 教师
- 系统定时器（用于自动生成课表）
用例识别与关系梳理
登录：
- 这是一个核心基础用例。
选课<> 登录查询课程<> 登录录入成绩<> 登录- 解释：没有登录，其他操作都无法进行。
选课流程：
学生–>选课选课<> 检查课程容量（这是一个内部逻辑，但也可以作为一个独立用例被包含）选课<> 加入候补队列（条件：课程已满）研究生–>跨院系选课（研究生的特有功能）
成绩管理：
教师–>录入成绩录入成绩<> 验证教师权限录入成绩<> 发送通知给学生（当成绩录入成功后，可选地发送通知）
自动化流程：
系统定时器–>生成最终课表生成最终课表<> 锁定选课通道
可视化描述（Mermaid 代码示例）
为了让你更直观地看到结构，我用 Mermaid 语法模拟一下这个图的结构：
usecaseDiagram
actor Student as "学生"
actor Graduate as "研究生"
actor Teacher as "教师"
actor SystemTimer as "系统定时器"
package "教务选课系统" {
usecase Login as "登录"
usecase QueryCourse as "查询课程"
usecase SelectCourse as "选修课程"
usecase JoinWaitlist as "加入候补队列"
usecase CrossDepartmentSelect as "跨院系选课"
usecase EnterGrade as "录入成绩"
usecase GenerateSchedule as "生成最终课表"
}
%% 参与者与用例关联
Student --> Login
Student --> QueryCourse
Student --> SelectCourse
Graduate --> Login
Graduate --> QueryCourse
Graduate --> SelectCourse
Graduate --> CrossDepartmentSelect
Teacher --> Login
Teacher --> EnterGrade
SystemTimer --> GenerateSchedule
%% 包含关系 (Must)
SelectCourse ..> Login : <<include>>
QueryCourse ..> Login : <<include>>
EnterGrade ..> Login : <<include>>
GenerateSchedule ..> Login : <<include>>
%% 扩展关系 (If)
SelectCourse ..> JoinWaitlist : <<extend>>
%% 泛化关系 (Is-A)
Graduate <|-- Student
CrossDepartmentSelect <|-- SelectCourse
注：在实际绘图工具中，泛化和扩展的箭头方向要特别注意。<<extend>> 是从扩展用例指向基础用例，箭头是虚线空心三角或普通箭头（取决于工具实现，标准UML是虚线开放箭头指向基础用例）。
五、 避坑指南：那些年我们踩过的绘图误区
误区1：把UI界面当成用例
错误示范：
- 用例：“输入学号”
- 用例：“点击搜索按钮”
正确做法： 这些是界面元素，不是用例。对应的用例应该是“查询学生信息”。输入学号和点击按钮只是实现“查询”这个用例的手段。
误区2：滥用包含关系
错误示范：
选课<> 显示课程名称
分析：
“显示课程名称”不是一个独立的功能块，它是选课过程中的一个反馈环节。如果把它做成包含用例，会导致用例图变得琐碎且难以维护。只有当一个子流程可以被多个父用例复用，或者是一个强制性的安全/验证步骤时，才考虑使用 <<include>>。
误区3：忽略异常流
错误示范： 只画“选课成功”，不画“选课失败”或“冲突检测”。
正确做法：
虽然用例图主要关注正常路径，但关键的异常处理也应该体现出来。例如，选课 <处理冲突。这能提醒开发人员，冲突处理是一个重要的业务逻辑分支。
误区4：参与者过多过细
错误示范： 画出“本科生”、“研究生”、“留学生”、“交换生”等多个独立的参与者，尽管他们的行为高度重合。
正确做法：
提取共性，使用泛化关系。定义一个通用的 Student 参与者，然后让 Undergraduate、Graduate 等泛化自它。这样既保持了图的简洁，又体现了差异。
六、 给小朋友也能听懂的比喻
为了让你彻底理解，我们可以把选课系统比作学校食堂打饭：
- 参与者：你是学生（拿着饭卡），阿姨（负责打饭），食堂系统（后台记账）。
- 用例：
- “买饭”：你递出饭卡，阿姨盛菜，系统扣钱。这是一个完整的互动。
- “充值”：你往饭卡里加钱。
- 包含关系：
- “买饭” 必须包含 “刷饭卡”。你不刷饭卡，阿姨不会给你打饭。这是强制的。
- 扩展关系：
- “买饭” 可能扩展为 “开发票”。如果你说“我要发票”，阿姨才会去打印。这不是每次必做的，所以是扩展。
- 泛化关系：
- “研究生” 和 “本科生” 都是 “学生”。他们都可以买饭，但研究生可能有“食堂补贴”这个特有的功能。
七、 总结与进阶建议
用例图不是目的，而是沟通的工具。它的核心价值在于厘清边界和明确责任。
- 保持简洁：如果一个用例图超过20个用例，你可能需要考虑拆分子系统或重新审视粒度。
- 动态迭代：用例图不是一成不变的。随着需求变更，你要敢于修改关系。
- 结合文本：单纯的图形容易歧义。每个用例都应该配有详细的用例规约（Use Case Specification），描述前置条件、后置条件、基本事件流和替代流。
最后，记住一点：最好的用例图，是让产品经理、开发人员和测试人员看完后，对“系统能做什么”和“不能做什么”有一致的理解。 如果你们三个人看完图后还在争论“这个按钮要不要画上去”，那说明你的用例图还不够清晰，需要回头重新审视参与者和用例的边界。
希望这篇解析能帮你跳出模板化的思维，真正掌握用例图的精髓。下次画图时，不妨先问问自己：这个参与者真的在系统外面吗？这个用例真的对用户有价值吗？答案会指引你画出更专业的图表。