Files
obsidian/各章笔记/第03章-用例图.md

277 lines
11 KiB
Markdown
Raw Blame History

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