2026-06-10 12:08:39 +08:00
|
|
|
|
# 第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 | 足额→出钞 | 不足→失败 | 足额→出钞;不足→失败 |
|
|
|
|
|
|
|
|
|
|
|
|
💬 **启示**:同样叫"取款",不同系统的操作流程可能完全不同!所以**用例描述必不可少**。
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 💡 五、系统边界
|
|
|
|
|
|
|
|
|
|
|
|
> **定义**:系统边界 = 系统内部和外部的分界线。
|
|
|
|
|
|
>
|
|
|
|
|
|
> - 用例画在边界**里面**(系统能做什么)
|
|
|
|
|
|
> - 参与者画在边界**外面**(谁在使用系统)
|
|
|
|
|
|
|
|
|
|
|
|
🔑 **核心理解**:系统边界决定了谁是参与者。
|
|
|
|
|
|
|
|
|
|
|
|
> 例:基金交易系统
|
|
|
|
|
|
> - 如果**只做交易**(买卖基金)→ 基金管理系统是**外部系统**(参与者)
|
|
|
|
|
|
> - 如果**交易+管理**(买卖+维护基金品种)→ 基金管理系统变成**系统内部功能**
|
|
|
|
|
|
|
2026-06-11 00:02:06 +08:00
|
|
|
|
![[Pasted image 20260610205411.png]]
|
|
|
|
|
|
![[Pasted image 20260610205443.png]]
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 📌 附录:用例图常用画图符号速查
|
|
|
|
|
|
|
|
|
|
|
|
> 本节把用例图中所有画图符号和标识用字符画的形式汇总一遍,画UML图时看着照画就行。
|
|
|
|
|
|
|
|
|
|
|
|
### 1. 参与者(Actor)—— 两种表示法
|
|
|
|
|
|
|
|
|
|
|
|
**人形符号**(最常用):
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
客户
|
|
|
|
|
|
○
|
|
|
|
|
|
╱│╲
|
|
|
|
|
|
╱ ╲
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
**矩形符号**(协作图或在空间紧张时使用):
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
┌──────────┐
|
|
|
|
|
|
│ :客户 │ ← 冒号 + 类名
|
|
|
|
|
|
└──────────┘
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
### 2. 用例(Use Case)—— 椭圆
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
╭──────────╮
|
|
|
|
|
|
╱ 借书 ╲
|
|
|
|
|
|
│ │
|
|
|
|
|
|
╲ ╱
|
|
|
|
|
|
╰──────────╯
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
⚠️ **命名**:椭圆里写**动宾结构**的用例名,如"借书""还书""查询图书"。
|
|
|
|
|
|
|
|
|
|
|
|
### 3. 系统边界 —— 矩形
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
┌─────────── 图书管理系统 ───────────┐
|
|
|
|
|
|
│ │
|
|
|
|
|
|
│ ╭────────╮ │
|
|
|
|
|
|
│ ╱ 借书 ╲ ← 用例在内部 │
|
|
|
|
|
|
│ │ │ │
|
|
|
|
|
|
│ ╲ ╱ │
|
|
|
|
|
|
│ ╰────────╯ │
|
|
|
|
|
|
│ │
|
|
|
|
|
|
└─────────────────────────────────────┘
|
|
|
|
|
|
|
|
|
|
|
|
读者 图书管理员
|
|
|
|
|
|
○ ○ ← 参与者在外部
|
|
|
|
|
|
╱│╲ ╱│╲
|
|
|
|
|
|
╱ ╲ ╱ ╲
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
### 4. 参与者与用例的关联 —— 实线
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
读者 ─────────── 借书
|
|
|
|
|
|
○ (椭圆)
|
|
|
|
|
|
╱│╲
|
|
|
|
|
|
╱ ╲
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
### 5. 包含关系 <<include>> —— 虚线箭头 + 文字标签
|
|
|
|
|
|
|
|
|
|
|
|
**方向**:基本用例 → 包含用例(箭头指向被包含的那个)。
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
╭──────────╮ ╭──────────╮
|
|
|
|
|
|
╱ 注册课程 ╲ ╱ 查询课程 ╲
|
|
|
|
|
|
│ │ <<include>> │ │
|
|
|
|
|
|
╲ ╱ ─ - - - - - ──→ ╲ ╱
|
|
|
|
|
|
╰──────────╯ (虚线 + 箭头) ╰──────────╯
|
|
|
|
|
|
(基本用例) (被包含用例)
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
### 6. 扩展关系 <<extend>> —— 虚线箭头 + 文字标签
|
|
|
|
|
|
|
|
|
|
|
|
**方向**:扩展用例 → 基本用例(箭头指向基本用例,与包含**相反**)。
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
╭──────────╮ ╭──────────╮
|
|
|
|
|
|
╱ 礼品包装 ╲ ╱ 下单 ╲
|
|
|
|
|
|
│ │ <<extend>> │ │
|
|
|
|
|
|
╲ ╱ ─ - - - - - ──→ ╲ ╱
|
|
|
|
|
|
╰──────────╯ (虚线 + 箭头) ╰──────────╯
|
|
|
|
|
|
(扩展用例) (基本用例)
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
⚠️ **易错对比**:<<include>> 和 <<extend>> 箭头方向**相反**,考试常考。
|
|
|
|
|
|
|
|
|
|
|
|
### 7. 用例之间的泛化关系 —— 实线 + 空心三角形
|
|
|
|
|
|
|
|
|
|
|
|
**方向**:子用例 → 父用例(子用例继承父用例的行为)。
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
╭──────────╮ ╭──────────╮
|
|
|
|
|
|
╱ 微信支付 ╲ ╱ 支付 ╲
|
|
|
|
|
|
│ │ ─ ─ ─▷ │ │
|
|
|
|
|
|
╲ ╱ (空心三角) ╲ ╱
|
|
|
|
|
|
╰──────────╯ ╰──────────╯
|
|
|
|
|
|
(子用例) (父用例)
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
### 8. 参与者之间的泛化关系 —— 实线 + 空心三角形
|
|
|
|
|
|
|
|
|
|
|
|
**方向**:特殊参与者 → 一般参与者(特殊继承普通的能力)。
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
╭─────╮
|
|
|
|
|
|
│ 钻石会员 │ (特殊)
|
|
|
|
|
|
│ /│\ │ ─ ─ ─▷ 普通用户
|
|
|
|
|
|
│ / │ \ │ (一般)
|
|
|
|
|
|
╰───────╯
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
### 9. 完整用例图示例
|
|
|
|
|
|
|
|
|
|
|
|
把上面所有符号拼在一起画出来的样子:
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
读者
|
|
|
|
|
|
○
|
|
|
|
|
|
╱│╲
|
|
|
|
|
|
┌──── 图书管理系统 ──────────────────────┐
|
|
|
|
|
|
│ │
|
|
|
|
|
|
│ ╭──────╮ │
|
|
|
|
|
|
│ ╱ 借书 ╲ ←──── <<include>> ────╮ │
|
|
|
|
|
|
││ │ │ │
|
|
|
|
|
|
│ ╲ ╱ │ │
|
|
|
|
|
|
│ ╰──────╯ │ │
|
|
|
|
|
|
│ ╭──────╮ │ │
|
|
|
|
|
|
│ ╱ 还书 ╲ ←──── <<extend>> ────╮ │
|
|
|
|
|
|
││ │ │ │
|
|
|
|
|
|
│ ╲ ╱ │ │
|
|
|
|
|
|
│ ╰──────╯ │ │
|
|
|
|
|
|
│ │ │
|
|
|
|
|
|
│ ╭──────╮ │ │
|
|
|
|
|
|
│ ╱ 缴纳 ╲ ←────────┘ │ │
|
|
|
|
|
|
││ 罚款 │ │ │
|
|
|
|
|
|
│ ╲ ╱ │ │
|
|
|
|
|
|
│ ╰──────╯ │ │
|
|
|
|
|
|
│ ╭──────╮ ── <<include>> ──→ │ │
|
|
|
|
|
|
│ ╱ 查询 ╲ │ │
|
|
|
|
|
|
││ 图书 │ │ │
|
|
|
|
|
|
│ ╲ ╱ │ │
|
|
|
|
|
|
│ ╰──────╯ │ │
|
|
|
|
|
|
│ │ │
|
|
|
|
|
|
└──────────────────────────────────┘ │
|
|
|
|
|
|
│
|
|
|
|
|
|
管理员 │
|
|
|
|
|
|
○ │
|
|
|
|
|
|
╱│╲ │
|
|
|
|
|
|
╱ ╲ │
|
|
|
|
|
|
│ (借书/还书关联)
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
🔑 **一句话记忆口诀**:边界矩形圈住用例,参与者画在边界外;包含扩展都是虚线箭头,方向相反要分清;泛化用空心三角,子指向父别搞错。
|
|
|
|
|
|
|
2026-06-10 12:08:39 +08:00
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## ✍️ 边学边练(三)
|
|
|
|
|
|
|
|
|
|
|
|
**题目**:判断以下说法是否正确。
|
|
|
|
|
|
|
|
|
|
|
|
1. 包含用例必然被执行,扩展用例条件被执行。
|
|
|
|
|
|
2. 包含关系的箭头从包含用例指向基本用例。
|
|
|
|
|
|
3. 系统边界决定了谁是参与者。
|
|
|
|
|
|
4. 用例描述可有可无,有图就够了。
|
|
|
|
|
|
|
|
|
|
|
|
**答案:**
|
|
|
|
|
|
- ① ✅ 正确。包含=必然,扩展=条件。
|
|
|
|
|
|
- ② ❌ 错误。包含关系箭头从**基本用例指向包含用例**(基本用例"使用"包含用例)。扩展关系箭头从**扩展用例指向基本用例**。
|
|
|
|
|
|
- ③ ✅ 正确。边界划在哪里,决定了谁是"外面的"参与者。
|
|
|
|
|
|
- ④ ❌ 错误。没有描述的用例就像只有目录的书——只知道标题不知道内容。
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 📝 章末自测
|
|
|
|
|
|
|
|
|
|
|
|
**1. 填空题**
|
2026-06-11 00:02:06 +08:00
|
|
|
|
- 参与者分三类:( ______ )、外部设备、( _____ )
|
|
|
|
|
|
- 用例之间的关系有三种:( ____ )、( _____ )、( ____ )
|
|
|
|
|
|
- 在用例图中,用例画在系统边界的( ____ )(里面/外面)
|
2026-06-10 12:08:39 +08:00
|
|
|
|
|
|
|
|
|
|
**2. 判断题**(对还是错?)
|
|
|
|
|
|
- ( ) 一个参与者只能是一个人
|
|
|
|
|
|
- ( ) 包含关系表示可选的功能
|
|
|
|
|
|
- ( ) 扩展关系的箭头指向基本用例
|
|
|
|
|
|
- ( ) 系统边界决定了谁是参与者
|
|
|
|
|
|
- ( ) 用例描述就是用于说明用例的操作流程
|
|
|
|
|
|
|
|
|
|
|
|
**3. 简答题**
|
|
|
|
|
|
- 简述包含关系和扩展关系的区别。
|
|
|
|
|
|
- 参与者之间的泛化关系有什么作用?
|
|
|
|
|
|
|
|
|
|
|
|
**答案:**
|
|
|
|
|
|
**填空题**:人、外部系统;包含关系、扩展关系、泛化关系;里面
|
|
|
|
|
|
|
|
|
|
|
|
**判断题**:❌(也可以是外部系统) ❌(包含=必然) ✅ ✅ ✅
|
|
|
|
|
|
|
|
|
|
|
|
**简答题**:
|
|
|
|
|
|
- 包含关系:基本用例必然执行包含用例(如取款必登录);扩展关系:基本用例有条件执行扩展用例(如还书超期才罚款)。箭头方向也不同,包含箭头是基本→包含,扩展箭头是扩展→基本。
|
|
|
|
|
|
- 泛化关系让特殊参与者继承普通参与者的所有关联,减少连线数量,简化模型。
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
## 📘 真题演练
|
|
|
|
|
|
|
|
|
|
|
|
**题目**:为"网上酒店预订系统"画用例图。需求:客户可浏览酒店、预订房间、取消预订、查看订单。管理员可管理酒店信息、管理房间信息、处理预订。客户和管理员都需要登录后才能操作。
|
|
|
|
|
|
|
|
|
|
|
|
**答案:**
|
|
|
|
|
|
**参与者**:客户、管理员
|
|
|
|
|
|
|
|
|
|
|
|
**用例**:
|
|
|
|
|
|
- 客户:浏览酒店、预订房间、取消预订、查看订单、登录
|
|
|
|
|
|
- 管理员:管理酒店信息、管理房间信息、处理预订、登录
|
|
|
|
|
|
|
|
|
|
|
|
**关系**:
|
|
|
|
|
|
- "浏览酒店"不需要登录(独立用例)
|
|
|
|
|
|
- "预订房间"包含"登录"(预订前必须登录)
|
|
|
|
|
|
- "管理酒店信息"包含"登录"
|
|
|
|
|
|
- 其他需要登录的用例同理
|
|
|
|
|
|
|
|
|
|
|
|
⚠️ **关键**:登录通常作为包含用例,因为它是一个共用的强制性步骤。
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
> 🔗 上一篇:[第1章 需求工程](第01章-需求工程.md) | 下一篇:[第4章 类图与对象图](第04章-类图与对象图.md)
|