10.4.5 用例图
用例图从外部使用者的角度描述系统功能。它不是程序流程图，也不是界面原型图，而是在说明：“谁使用系统，系统给这些角色提供什么服务。”
用例图的组成
| 元素 | 图形 | 含义 | 识别提醒 |
|---|---|---|---|
| 系统边界 | 大矩形 | 标出当前系统范围 | 边界内是系统功能，边界外是外部角色 |
| 参与者 | 小人 | 与系统交互的外部角色 | 可以是人、组织、第三方系统、外部设备 |
| 用例 | 椭圆 | 系统提供的一项服务 | 常用“动词 + 名词”命名，如“新增书籍信息” |
| 关系 | 连线/箭头 | 参与者与用例、用例与用例之间的联系 | 包含、扩展、泛化最常考 |
mermaid
flowchart LR
Librarian["图书管理员"]
Reader["读者"]
subgraph System["图书管理系统"]
Add["新增书籍信息"]
Borrow["借阅图书"]
Check["检查权限"]
Recharge["缴纳押金"]
end
Librarian --- Add
Reader --- Borrow
Add -. "<<include>>" .-> Check
Borrow -. "<<include>>" .-> Check
Recharge -. "<<extend>>\n押金不足" .-> Borrow矩形边界外的是参与者，椭圆内部的是用例。参与者不一定是“具体的人”，而是外部角色，例如支付平台、短信网关、第三方认证系统都可以是参与者。
参与者怎么识别
参与者是系统外部与系统交互的实体。它强调“角色”，不是具体自然人。
| 需求描述 | 可能的参与者 | 原因 |
|---|---|---|
| 管理员维护图书信息 | 管理员 | 外部使用系统的人 |
| 用户通过支付宝付款 | 用户、支付宝系统 | 支付宝是与本系统交互的外部系统 |
| 传感器上传温度数据 | 传感器 | 外部设备也可以触发系统功能 |
| 银行系统核验账户 | 银行系统 | 第三方机构或系统是参与者 |
课程里把用例图参与者与 DFD 外部实体作了类比：两者都在系统边界之外，都会与系统发生交互。不同的是，DFD 是结构化分析工具，用例图是面向对象分析常用工具。
用例怎么命名
用例是系统功能的归纳。命名通常是动作，不是静态名词。
| 不推荐 | 推荐 | 原因 |
|---|---|---|
| 书籍信息 | 新增书籍信息 | 用例应表达系统提供的动作 |
| 订单 | 查询订单、创建订单 | “订单”只是对象，不是功能 |
| 支付 | 完成支付、发起退款 | 更清楚参与者要达成的目标 |
用例只有名字还不够。真正做需求分析时，还要继续细化用例描述，例如基本事件流、备选事件流、前置条件、后置条件。课程这里只要求先掌握图上元素和关系。
用例图建模步骤
- 确定系统边界：先判断哪些功能属于本系统，哪些角色在系统外。
- 识别参与者：找人、组织机构、第三方系统、外部设备。
- 识别用例：从需求动词中归纳系统提供的功能。
- 建立参与关系：哪些参与者使用哪些用例。
- 调整用例模型：必要时用 include、extend、泛化关系整理公共行为、条件行为和抽象行为。
三种用例关系再辨析
| 关系 | 何时使用 | 是否必选 | 箭头方向 |
|---|---|---|---|
<<include>> 包含 | 多个用例都必须执行同一公共步骤 | 必选 | 指向被包含的公共用例 |
<<extend>> 扩展 | 某个条件满足时才追加行为 | 可选 | 指向被扩展的基本用例 |
| 泛化 | 多个具体用例是同一个抽象用例的不同实现 | 必须选择具体子用例 | 子用例指向父用例 |
看到“都要先检查权限”通常是包含；看到“余额不足时才充值”通常是扩展；看到“注册可分为电话注册和网上注册”通常是泛化。
考试识图提示
- 看到小人 + 椭圆 + 系统边界，优先判断用例图。
- 小人表示参与者，椭圆表示用例。
- 系统边界不是参与者，也不是类。
- 参与者可以是人、组织机构、第三方系统或硬件设备，不能被限制成“物理用户”。
例题
用例图中，系统外部与系统交互的角色称为：
关于用例图，下列说法正确的是：
自查要点
- 用例图为什么要先确定系统边界？
- 参与者为什么不等于具体用户？
- 用例命名为什么通常用“动词 + 名词”？
- include、extend、泛化分别解决什么建模问题？