4、用例图入门：参与者、用例、关系（包含、扩展、泛化）、用例图绘制步骤与案例
用例图是UML中最贴近业务视角的建模工具，它不关心系统内部如何实现，只关注“谁”与系统交互以及“做什么”。对于需求分析师、产品经理和架构师而言，用例图是捕获功能性需求、划定系统边界、与干系人确认范围的通用语言。本章将从参与者、用例、三种核心关系（包含、扩展、泛化）入手，结合完整的绘制步骤与实战案例，帮助你建立从业务事件到用例模型的映射能力。
上图展示了一个在线课程管理系统的用例图骨架。请注意，参与者（学生、教师、教务管理员）位于系统边界框之外，用例（椭圆）位于边界框之内，这直观地表达了“系统为谁服务”以及“系统提供哪些功能”的边界思想。接下来，我们逐一拆解用例图的构成要素与建模方法。
4.1 参与者：系统交互的外部角色
核心原理：参与者（Actor）是与系统交互的外部实体，可以是人、外部系统、硬件设备或定时触发机制。关键在于参与者不在系统内部，它代表的是与系统交换信息的角色，而非具体用户。例如“学生”是参与者，而“张三”是具体用户；如果系统需要区分“学生”和“校友”的不同权限，则应建模为两个参与者。
判断方法：识别参与者时，可以问三个问题：谁向系统提供信息？谁从系统获取信息？谁触发系统的主要事件？如果某个角色只通过另一个角色间接使用系统，通常不需要单独建模。例如，访客通过“学生”账号浏览课程，则访客不是独立参与者。
| 参与者类型 | 示例 | 建模要点 |
|---|---|---|
| 人 | 学生、教师、管理员 | 按角色而非职位建模 |
| 外部系统 | 支付网关、短信平台 | 用矩形+«system»标注 |
| 硬件设备 | 扫码枪、传感器 | 用矩形+«device»标注 |
| 定时触发 | 每日凌晨数据备份 | 用矩形+«timer»标注 |
4.2 用例：系统功能的原子化描述
核心原理：用例（Use Case）描述系统对外提供的一项完整功能，它必须产生对参与者可观察、有价值的结果。用例名称建议采用“动词+名词”格式，如“在线选课”“导出成绩单”。一个用例应包含主成功场景、备选流和异常流，但在用例图中只体现名称，详细流程用活动图或文字描述。
操作流程：识别用例时，从参与者的目标出发，列出所有能达成目标的系统功能。例如“学生”的目标是“完成选课”，对应的用例是“在线选课”，而“验证学号”“检查课程容量”是选课过程中的步骤，不应单独建模为用例。判断标准是：该功能是否独立产生业务价值？如果去掉它，参与者能否通过其他路径达成目标？
4.3 三种核心关系：包含、扩展、泛化
核心原理：关系是用例图的骨架，它决定了用例之间的协作方式。包含（«include»）表示一个用例总是调用另一个用例，被包含用例是公共步骤；扩展（«extend»）表示一个用例在特定条件下才触发另一个用例，扩展点通常有明确的触发条件；泛化（Generalization）表示子用例继承父用例的行为，并可增加或覆盖步骤。
判断方法：当两个用例存在“必须做”的关系时用包含，例如“在线选课”必须“用户登录”，箭头从基础用例指向被包含用例。当存在“如果……则……”的可选行为时用扩展，例如“成绩查询”在用户点击“导出”按钮时扩展出“导出报表”，箭头从扩展用例指向基础用例。泛化则用于父子用例，例如“在线支付”和“线下转账”都是“支付方式”的子用例。
| 关系类型 | 语义 | 箭头方向 | 典型场景 |
|---|---|---|---|
| 包含 «include» | 基础用例必然包含被包含用例 | 基础 → 被包含 | “在线选课”包含“用户登录” |
| 扩展 «extend» | 基础用例在特定条件下触发扩展用例 | 扩展 → 基础 | “成绩查询”扩展“导出报表” |
| 泛化 | 子用例继承父用例行为 | 子 → 父（空心三角） | “信用卡支付”泛化“支付” |
4.4 用例图绘制步骤与实战案例
操作流程：绘制用例图建议遵循五步法：第一步，确定系统边界，用矩形框表示系统，框内放用例，框外放参与者；第二步，识别参与者，列出所有与系统交互的角色；第三步，从参与者目标出发识别用例，每个目标对应一个用例；第四步，分析用例间关系，用包含、扩展、泛化连接；第五步，检查完整性，确保每个参与者至少连接一个用例，每个用例至少被一个参与者触发。
案例拆解：以“在线课程管理系统”为例，我们完整走一遍建模过程。背景：某高校需要替换纸质选课流程，新系统需支持学生在线选课、教师录入成绩、教务管理员管理课程。约束：系统需与学校统一身份认证平台对接，且选课期间并发量较大。初始现象：旧流程中，学生需到教务处排队选课，教师用Excel表格提交成绩，管理员手工汇总。
- 识别参与者：学生（选课、查成绩）、教师（录成绩、查课程）、教务管理员（管理课程、导出报表）、统一身份认证平台（外部系统，负责登录验证）。
- 识别用例：学生目标“完成选课”对应“在线选课”；“查看成绩”对应“成绩查询”。教师目标“提交成绩”对应“成绩录入”。管理员目标“维护课程信息”对应“课程管理”；“获取统计报表”对应“导出报表”。
- 分析关系：“在线选课”和“成绩录入”都必须先“用户登录”，因此用包含关系连接；“成绩查询”在用户点击“导出”按钮时触发“导出报表”，用扩展关系连接；“教师”和“教务管理员”都是“系统用户”的子类，用泛化关系表达。
- 绘制与校验：将参与者放在框外，用例放在框内，按上述关系连线。检查发现“统一身份认证平台”只与“用户登录”交互，可将其作为“用户登录”用例的参与者，而非系统边界内的用例。
结果对比：建模后，系统边界清晰：学生和教师无法直接访问“课程管理”用例，管理员无法触发“在线选课”。这避免了权限混乱。风险与代价：包含关系使“用户登录”成为多个用例的公共依赖，若登录逻辑变更（如增加短信验证），所有包含它的用例都会受影响，因此需在架构设计时考虑登录模块的稳定性。复盘经验：用例图的价值在于沟通而非完美，建议与业务方逐条确认每个用例的业务价值，避免技术实现细节混入模型。