11 KiB
第3章 用例图
考试重要度：★★★★★
核心内容：参与者和用例的识别、用例之间的三种关系（包含/扩展/泛化）、用例描述编写、系统边界
📢 先从生活场景理解用例图
你去银行ATM机取钱，整个过程是这样的：
你（客户）把卡插进去 → 输入密码 → 选择"取款" → 输入金额 → 拿钱 → 取卡
在用例图中：
- 你（客户） = 参与者（Actor）—— 系统外部跟系统打交道的人或系统
- "取款" = 用例（Use Case）—— 系统提供的一项功能
- 取款的详细步骤 = 用例描述（Use Case Description）
💬 一句话：用例图 = 画出"谁"能用系统"做什么"。
💡 一、参与者（Actor）
什么是参与者？
定义：系统以外的、需要使用系统或与系统交互的外部实体。
三类参与者：
| 类型 | 举例 |
|---|---|
| 人 | 客户、图书管理员、系统管理员 |
| 外部设备 | 打印机、传感器、扫描仪 |
| 外部系统 | 短信平台、第三方支付系统、课程目录系统 |
怎么找参与者？
🔑 口诀：找参与者 = 找"谁在用系统"和"系统跟谁通信"。
例：大学图书管理系统中——"读者通过图书管理员借还书籍，系统管理员维护数据"
参与者有：读者、图书管理员、系统管理员
参与者之间的泛化关系
💬 什么是泛化？= 特殊参与者继承了普通参与者的所有能力，还能做更多事。
例：网上购物系统——普通用户只能浏览，注册会员可以浏览+购买。 注册会员 = 普通用户的"特殊版"，这就是泛化关系。
泛化的好处：减少连线数量，简化用例图——特殊参与者自动继承普通参与者的所有关联。
✍️ 边学边练（一）
题目：阅读以下系统描述，找出所有参与者。
"在某大学图书管理系统中，读者通过系统管理员办理借书证。读者分学生和教师。读者借还书籍要通过图书管理员来完成。系统管理员负责借书证维护和图书数据维护等操作。"
答案： 参与者有：图书管理员、系统管理员。
注意：读者不是直接的参与者！因为读者"通过"图书管理员来借还书——他们不直接跟系统交互。但如果系统有自助借还机，读者就可以直接操作，此时读者就是参与者。
⚠️ 易错点：不是所有提到的人物都是参与者，只有直接跟系统交互的才是。
💡 二、用例（Use Case）
什么是用例？
定义：参与者可以感受到的、系统提供的一项完整功能。
🔑 命名规则：用动宾结构——"借书"、"还书"、"查询图书"、"修改密码"。
用例的特征
- 站在系统外部看到的系统功能（不是内部实现）
- 总是跟参与者交互（孤立的操作不算用例）
- 是一个行为上相关的步骤序列（不是一个动作）
- 用例分析本质上是功能分解
怎么找用例？
🔑 口诀：找用例 = 找"参与者能在这个系统里干什么"。
例：大学图书管理系统——读者能"查找图书"，图书管理员能"借书""还书""查找图书"，系统管理员能"维护借书证""维护图书数据"。
💡 三、用例之间的关系（重点！必考！）
用例之间有三种关系：包含、扩展、泛化。
1. 包含关系（<>）
含义：基本用例的行为中必然会执行被包含用例的行为。
💬 比喻：就像"坐飞机"必然包含"安检"——你想坐飞机就必须过安检，逃不掉。
例：网上购物——"在线购物"必然包含"检查信用卡"。 例：ATM取款——"取款"必然包含"登录验证"。
特征：包含关系是必须的、不可跳过的。
2. 扩展关系（<>）
含义：基本用例的行为中有条件地执行扩展用例的行为。
💬 比喻：就像"坐飞机"可能扩展"升舱"——不是每次都升舱，只有条件满足时才升。
例：图书借阅——"还书"时如果超期，才会扩展执行"缴纳罚款"。 例：网上购物——"下单"时如果选了礼品包装，才会扩展执行"礼品包装"。
特征：扩展关系是可选的、有条件的。
🔑 包含 vs 扩展 对比（必考！）
| 对比维度 | 包含 <> | 扩展 <> |
|---|---|---|
| 执行方式 | 必然执行 | 条件执行 |
| 方向 | 基本用例 → 包含用例 | 扩展用例 → 基本用例（箭头指向基本用例） |
| 是否可跳过 | 不可跳过 | 满足条件才执行 |
| 生活比喻 | 坐飞机必安检 | 坐飞机可选升舱 |
⚠️ 画图易错：包含关系的箭头方向是基本用例指向包含用例，扩展关系的箭头方向是扩展用例指向基本用例——两个方向相反！
3. 泛化关系
含义：子用例继承父用例的行为，并可以覆盖或增加。
💬 比喻：就像"支付"是父用例，"微信支付""支付宝支付""银行卡支付"是子用例——它们都是支付，但具体方式不同。
✍️ 边学边练（二）
题目：选课系统描述如下，找出用例和关系。
"学生在登录系统后可以查询课程、注册课程。课程目录从旧系统读取。每学期开始时，系统管理员开放注册。学生选课前必须先查询课程目录。学生完成选课时可以生成课程表，也可以随时生成课程表。系统管理员在登录后可维护学生信息、开放和关闭注册。"
答案： 参与者：学生、系统管理员、旧课程目录系统
用例及关系：
- 学生：查询课程、注册课程、生成课程表、登录
- 系统管理员：登录、维护学生信息、开放注册、关闭注册
- 关系：
- "注册课程" 包含 "查询课程"（选课前必须先查课）← 包含关系
- "查询课程"也可能独立存在
- "生成课程表"是"注册课程"的扩展（选课后可生成，也可随时生成）
⚠️ 关键判断："必须先……"就是包含关系；"可以……"就是扩展关系。
💡 四、用例描述
为什么需要用例描述？
💬 用例图只是"目录"——你看到"取款"这个名字，但不知道取款到底怎么操作。用例描述就是详细的"说明书"。
用例描述的模板
| 描述项 | 说明 |
|---|---|
| 用例名称 | 动宾结构，如"取款" |
| 参与者 | 谁使用这个用例 |
| 前置条件 | 执行前必须满足什么条件 |
| 后置条件 | 执行后系统变成什么状态 |
| 基本操作流程 | 正常情况下的步骤序列 |
| 可选操作流程 | 异常情况或分支的步骤序列 |
| 特殊需求 | 非功能性需求和设计约束 |
三种ATM取款的用例描述对比
通过对比你会发现，不同银行的取款流程不一样：
| 步骤 | 农业银行 | 建设银行 | 东莞银行 |
|---|---|---|---|
| 1 | 验证密码 | 输入金额 | 判断是否第一次取款 |
| 2 | 输入金额 | 检查余额 | 若首次→输入金额；否则→验证密码→输入金额 |
| 3 | 检查余额 | 足额→出钞 | 检查余额 |
| 4 | 足额→出钞 | 不足→失败 | 足额→出钞；不足→失败 |
💬 启示：同样叫"取款"，不同系统的操作流程可能完全不同！所以用例描述必不可少。
💡 五、系统边界
定义：系统边界 = 系统内部和外部的分界线。
- 用例画在边界里面（系统能做什么）
- 参与者画在边界外面（谁在使用系统）
🔑 核心理解：系统边界决定了谁是参与者。
例：基金交易系统
- 如果只做交易（买卖基金）→ 基金管理系统是外部系统（参与者）
- 如果交易+管理（买卖+维护基金品种）→ 基金管理系统变成系统内部功能
✍️ 边学边练（三）
题目：判断以下说法是否正确。
- 包含用例必然被执行，扩展用例条件被执行。
- 包含关系的箭头从包含用例指向基本用例。
- 系统边界决定了谁是参与者。
- 用例描述可有可无，有图就够了。
答案：
- ① ✅ 正确。包含=必然，扩展=条件。
- ② ❌ 错误。包含关系箭头从基本用例指向包含用例（基本用例"使用"包含用例）。扩展关系箭头从扩展用例指向基本用例。
- ③ ✅ 正确。边界划在哪里，决定了谁是"外面的"参与者。
- ④ ❌ 错误。没有描述的用例就像只有目录的书——只知道标题不知道内容。
📝 章末自测
1. 填空题
- 参与者分三类：（ ___ ）（ ___ ）、外部设备、（ ___ ）（ ___ ）
- 用例之间的关系有三种：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
- 在用例图中，用例画在系统边界的（ ___ ）（ ___ ）（里面/外面）
2. 判断题（对还是错？）
- ( ) 一个参与者只能是一个人
- ( ) 包含关系表示可选的功能
- ( ) 扩展关系的箭头指向基本用例
- ( ) 系统边界决定了谁是参与者
- ( ) 用例描述就是用于说明用例的操作流程
3. 简答题
- 简述包含关系和扩展关系的区别。
- 参与者之间的泛化关系有什么作用？
答案： 填空题：人、外部系统；包含关系、扩展关系、泛化关系；里面
判断题：❌(也可以是外部系统) ❌(包含=必然) ✅ ✅ ✅
简答题：
- 包含关系：基本用例必然执行包含用例（如取款必登录）；扩展关系：基本用例有条件执行扩展用例（如还书超期才罚款）。箭头方向也不同，包含箭头是基本→包含，扩展箭头是扩展→基本。
- 泛化关系让特殊参与者继承普通参与者的所有关联，减少连线数量，简化模型。
📘 真题演练
题目：为"网上酒店预订系统"画用例图。需求：客户可浏览酒店、预订房间、取消预订、查看订单。管理员可管理酒店信息、管理房间信息、处理预订。客户和管理员都需要登录后才能操作。
答案： 参与者：客户、管理员
用例：
- 客户：浏览酒店、预订房间、取消预订、查看订单、登录
- 管理员：管理酒店信息、管理房间信息、处理预订、登录
关系：
- "浏览酒店"不需要登录（独立用例）
- "预订房间"包含"登录"（预订前必须登录）
- "管理酒店信息"包含"登录"
- 其他需要登录的用例同理
⚠️ 关键：登录通常作为包含用例，因为它是一个共用的强制性步骤。
🔗 上一篇：第1章 需求工程 | 下一篇：第4章 类图与对象图