ChoChoX/obsidian
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2026-07-03 23:22:28

Browse Source
This commit is contained in:
ChoChoX
2026-07-03 23:22:28 +08:00
parent 8197fd341e
commit 3aac80fb26
41 changed files with 11906 additions and 10335 deletions
Download Patch File Download Diff File Expand all files Collapse all files

580
软件需求分析/各章笔记/第08章-包图.md
View File

@@ -1,290 +1,290 @@
# 第8章 包图
> **考试重要度**：★★
> **核心内容**：包的概念与可见性、包之间的依赖与泛化关系、四大设计原则
---
## 📢 从文件夹理解包图
💬 你电脑上肯定有文件夹（目录），用来把相关文件放在一起。
在UML中，**包**就是"文件夹"——把关系密切的类、接口、组件等放在一起。
```
┌─────────────────┐
│ 包名 │
│ ┌───────────┐ │
│ │ + 公开类 │ │ ← 被import后外部可用
│ │ # 受保护 │ │ ← 只有子包可用
│ │ - 私有类 │ │ ← 只有包内部可用
│ └───────────┘ │
└─────────────────┘
```
---
## 💡 一、包的可见性
跟类的可见性一样，包中的元素也有三种可见性：
| 可见性 | 符号 | 含义 |
|--------|------|------|
| **公有** | `+` | 任何导入此包的包都可以用 |
| **受保护** | `#` | 只有子包可以用 |
| **私有** | `-` | 只有包内部可以用 |
---
## 💡 二、包之间的关系
### 1. 依赖关系
> 包A中的某个类依赖于包B中的某个类 → 包A依赖于包B。
⚠️ **注意**：包之间的依赖关系**没有传递性**！A依赖B，B依赖C，不等于A依赖C。
### 2. 泛化关系
> 子包继承父包中可见性为public和protected的元素。
### 📌 包图各元素的画法速查
> 这一节把包图里所有的画图元素（包本身、依赖、泛化）用字符画列出来。
#### ① 包的两种画法
**标准文件夹画法**（最常用）：
```
┌──────────────┐
│ UI层 │ ← 上方有"小标签"（像文件夹的舌头）
└──────────────┘
```
字符画表示（小标签在左上角）：
```
┌────────────┐
│┌─┐ │
││ │ │
│└─┘─────────┤
│ UI层 │
│ │
│ ┌─────────┐ │
│ │ 登录页 │ │ ← 包内可以嵌套子包或类
│ └─────────┘ │
└─────────────┘
```
**简化画法**（只用矩形）：
```
┌──────────────┐
│ UI层 │
│ ┌────────┐ │
│ │ 登录页 │ │
│ └────────┘ │
│ ┌────────┐ │
│ │ 主页面 │ │
│ └────────┘ │
└──────────────┘
```
#### ② 包的嵌套
```
┌──────────────────────┐
│ 电子商务系统 │
│ ┌──────────┐ │
│ │ 用户模块 │ │
│ │ ┌──────┐ │ │
│ │ │登录类│ │ │
│ │ └──────┘ │ │
│ │ ┌──────┐ │ │
│ │ │注册类│ │ │
│ │ └──────┘ │ │
│ └──────────┘ │
│ ┌──────────┐ │
│ │ 订单模块 │ │
│ └──────────┘ │
└──────────────────────┘
```
#### ③ 包的可见性符号
```
┌────────────────┐
│ ┌─┐ │
│ │+│ 公开类 │ ← + 公有：任何外部包都可用
│ └─┘───────────┤
│ ┌─┐ │
│ │#│ 受保护类 │ ← # 受保护：只有子包可用
│ └─┘───────────┤
│ ┌─┐ │
│ │-│ 私有类 │ ← - 私有：只有包内部可用
│ └─┘───────────┤
│ │
└────────────────┘
```
#### ④ 包之间的依赖关系 —— 虚线 + 开放箭头
> 一个包中的类**引用**另一个包中的类 → 包之间形成依赖。
```
┌──────────────┐ ┌──────────────┐
│ UI层 │ │ 业务层 │
│ │ │ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │登录窗口 │ │ │ │登录服务 │ │
│ └────────┘ │ │ └────────┘ │
│ │ │ │
└──────────────┘ └──────────────┘
│ ▲
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┘
虚线 + 开放箭头
（依赖方向：UI层 依赖 业务层）
```
⚠️ **依赖方向**：箭头从"使用者"指向"被使用者"（类似类图里的依赖）。
#### ⑤ 包之间的泛化关系 —— 实线 + 空心三角
> 子包继承父包的内容。子包继承父包中**public 和 protected** 的元素。
```
┌──────────────┐ ┌──────────────┐
│ 业务层 │ │ 通用层 │
│ (子包) │ ─ ─ ─ ─ ─ ─ ─ ▷ │ (父包) │
│ │ 空心三角 │ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │订单处理 │ │ │ │日志工具 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │支付处理 │ │ │ │通用工具 │ │
│ └────────┘ │ │ └────────┘ │
└──────────────┘ └──────────────┘
```
⚠️ **泛化方向**：空心三角**指向父包**（与类图泛化一致）。
#### ⑥ 完整包图示例
```
┌────────────────┐
│ 表现层 │
│ ┌────────┐ │
│ │登录页 │ │
│ └────────┘ │
│ ┌────────┐ │
│ │主窗体 │ │
│ └────────┘ │
└───────┬────────┘
│ 依赖
╌ ╌ ╌ ╌ ╌ ╌ ╌
▼
┌────────────────┐ ▷ ┌────────────────┐
│ 业务层 │ ─ ─ ─ ─ ─ ─ ─ ─ ─│ 通用层 │
│ │ 泛化 │ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │登录管理 │ │ │ │日志工具 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │订单管理 │ │ │ │数据校验 │ │
│ └────────┘ │ │ └────────┘ │
└───────┬────────┘ └────────────────┘
│ 依赖
╌ ╌ ╌ ╌ ╌ ╌ ╌
▼
┌────────────────┐
│ 数据层 │
│ ┌────────┐ │
│ │用户DAO │ │
│ └────────┘ │
│ ┌────────┐ │
│ │订单DAO │ │
│ └────────┘ │
└────────────────┘
```
🔑 **一句话记忆口诀**：包用文件夹画，标签是包名；包间依赖是虚线开放箭头（指向被依赖），包间泛化是实线空心三角（指向父包）；包可以嵌套，元素分+/-可见性。
---
## 💡 三、包的四大设计原则
这些原则告诉你**怎么把类分到不同的包里**：
### 1. 重用等价原则（REP）
> 把可以一起复用的类放在一个包中。包 = 可重用的单元。
💬 就像一个工具包——扳手和螺丝刀放在一起，因为它们总是一起用。
### 2. 共同闭包原则（CCP）
> 把需要同时修改的类放在一个包中。
💬 修改了类A就必须修改类B？那它们应该在一个包里——改一个包就够了。
### 3. 共同重用原则（CRP）
> 不会一起用的类不要放在同一个包里。
💬 别把厨房用品和修车工具放一起——要用厨房用品的人不需要修车工具。
### 4. 非循环依赖原则（ADP）
> 包之间的依赖关系**不能形成环**。
💬 A→B→C→A 这样的循环依赖会严重妨碍复用。破解方法：提取共同接口或拆分包。
### 🔑 核心目标：高内聚、低耦合
| 原则 | 作用 |
|------|------|
| **高内聚** | 包内的类关系紧密（REP + CCP） |
| **低耦合** | 包之间的依赖尽量少（CRP + ADP） |
---
## ✍️ 边学边练
**题目**：判断以下做法是否合理。
1. 把订单处理类和用户登录类放在同一个包
2. A包依赖B包，B包依赖C包，C包依赖A包
3. 把所有工具类放在一个util包中，让其他包依赖它
4. 把用户界面类、数据库访问类、业务逻辑类放在同一个包
**答案：**
1. ❌ 不合理 — 违反CRP（不会一起使用的类不要放一起）。订单处理的人不需要登录功能。
2. ❌ 不合理 — 违反ADP（循环依赖）。
3. ✅ 合理 — 符合REP（工具类作为可重用单元）。
4. ❌ 不合理 — 违反CCP和CRP。不同层次的类（界面/数据/逻辑）修改原因不同，应该分开。
⚠️ **实用建议**：通常按层次分包（UI层、业务层、数据层），而不是按功能分包。
---
## 📝 章末自测
**1. 填空题**
- 包的四大设计原则缩写是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
- ADP原则要求包之间的依赖不能形成（ ___ ）（ ___ ）
- 包中元素的三种可见性是：公有(（ ___ ）（ ___ ）)、受保护(（ ___ ）（ ___ ）)、私有(（ ___ ）（ ___ ）)
**2. 简答题**
- 简述REP和CRP之间的矛盾是什么？
- 包图和组件图的关系是什么？
**答案：**
**填空题**：REP、CCP、CRP、ADP；循环；+、#、-
**简答题**：
- REP说要把可一起复用的类放在一个包，这可能导致一个包很大（包含所有可能用到的类）；CRP说不会一起用的类要分开，这可能导致很多小包。两者需要权衡。
- 包存放组件，组件包含类。包相当于文件夹，组件相当于文件。部署时：类→组件→包→结点。
---
> 🔗 上一篇：[第7章 组件图与部署图](第07章-组件图与部署图.md) | 下一篇：[第9章 数据建模](第09章-数据建模.md)
# 第8章 包图
> **考试重要度**：★★
> **核心内容**：包的概念与可见性、包之间的依赖与泛化关系、四大设计原则
---
## 📢 从文件夹理解包图
💬 你电脑上肯定有文件夹（目录），用来把相关文件放在一起。
在UML中，**包**就是"文件夹"——把关系密切的类、接口、组件等放在一起。
```
┌─────────────────┐
│ 包名 │
│ ┌───────────┐ │
│ │ + 公开类 │ │ ← 被import后外部可用
│ │ # 受保护 │ │ ← 只有子包可用
│ │ - 私有类 │ │ ← 只有包内部可用
│ └───────────┘ │
└─────────────────┘
```
---
## 💡 一、包的可见性
跟类的可见性一样，包中的元素也有三种可见性：
| 可见性 | 符号 | 含义 |
|--------|------|------|
| **公有** | `+` | 任何导入此包的包都可以用 |
| **受保护** | `#` | 只有子包可以用 |
| **私有** | `-` | 只有包内部可以用 |
---
## 💡 二、包之间的关系
### 1. 依赖关系
> 包A中的某个类依赖于包B中的某个类 → 包A依赖于包B。
⚠️ **注意**：包之间的依赖关系**没有传递性**！A依赖B，B依赖C，不等于A依赖C。
### 2. 泛化关系
> 子包继承父包中可见性为public和protected的元素。
### 📌 包图各元素的画法速查
> 这一节把包图里所有的画图元素（包本身、依赖、泛化）用字符画列出来。
#### ① 包的两种画法
**标准文件夹画法**（最常用）：
```
┌──────────────┐
│ UI层 │ ← 上方有"小标签"（像文件夹的舌头）
└──────────────┘
```
字符画表示（小标签在左上角）：
```
┌────────────┐
│┌─┐ │
││ │ │
│└─┘─────────┤
│ UI层 │
│ │
│ ┌─────────┐ │
│ │ 登录页 │ │ ← 包内可以嵌套子包或类
│ └─────────┘ │
└─────────────┘
```
**简化画法**（只用矩形）：
```
┌──────────────┐
│ UI层 │
│ ┌────────┐ │
│ │ 登录页 │ │
│ └────────┘ │
│ ┌────────┐ │
│ │ 主页面 │ │
│ └────────┘ │
└──────────────┘
```
#### ② 包的嵌套
```
┌──────────────────────┐
│ 电子商务系统 │
│ ┌──────────┐ │
│ │ 用户模块 │ │
│ │ ┌──────┐ │ │
│ │ │登录类│ │ │
│ │ └──────┘ │ │
│ │ ┌──────┐ │ │
│ │ │注册类│ │ │
│ │ └──────┘ │ │
│ └──────────┘ │
│ ┌──────────┐ │
│ │ 订单模块 │ │
│ └──────────┘ │
└──────────────────────┘
```
#### ③ 包的可见性符号
```
┌────────────────┐
│ ┌─┐ │
│ │+│ 公开类 │ ← + 公有：任何外部包都可用
│ └─┘───────────┤
│ ┌─┐ │
│ │#│ 受保护类 │ ← # 受保护：只有子包可用
│ └─┘───────────┤
│ ┌─┐ │
│ │-│ 私有类 │ ← - 私有：只有包内部可用
│ └─┘───────────┤
│ │
└────────────────┘
```
#### ④ 包之间的依赖关系 —— 虚线 + 开放箭头
> 一个包中的类**引用**另一个包中的类 → 包之间形成依赖。
```
┌──────────────┐ ┌──────────────┐
│ UI层 │ │ 业务层 │
│ │ │ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │登录窗口 │ │ │ │登录服务 │ │
│ └────────┘ │ │ └────────┘ │
│ │ │ │
└──────────────┘ └──────────────┘
│ ▲
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┘
虚线 + 开放箭头
（依赖方向：UI层 依赖 业务层）
```
⚠️ **依赖方向**：箭头从"使用者"指向"被使用者"（类似类图里的依赖）。
#### ⑤ 包之间的泛化关系 —— 实线 + 空心三角
> 子包继承父包的内容。子包继承父包中**public 和 protected** 的元素。
```
┌──────────────┐ ┌──────────────┐
│ 业务层 │ │ 通用层 │
│ (子包) │ ─ ─ ─ ─ ─ ─ ─ ▷ │ (父包) │
│ │ 空心三角 │ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │订单处理 │ │ │ │日志工具 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │支付处理 │ │ │ │通用工具 │ │
│ └────────┘ │ │ └────────┘ │
└──────────────┘ └──────────────┘
```
⚠️ **泛化方向**：空心三角**指向父包**（与类图泛化一致）。
#### ⑥ 完整包图示例
```
┌────────────────┐
│ 表现层 │
│ ┌────────┐ │
│ │登录页 │ │
│ └────────┘ │
│ ┌────────┐ │
│ │主窗体 │ │
│ └────────┘ │
└───────┬────────┘
│ 依赖
╌ ╌ ╌ ╌ ╌ ╌ ╌
▼
┌────────────────┐ ▷ ┌────────────────┐
│ 业务层 │ ─ ─ ─ ─ ─ ─ ─ ─ ─│ 通用层 │
│ │ 泛化 │ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │登录管理 │ │ │ │日志工具 │ │
│ └────────┘ │ │ └────────┘ │
│ ┌────────┐ │ │ ┌────────┐ │
│ │订单管理 │ │ │ │数据校验 │ │
│ └────────┘ │ │ └────────┘ │
└───────┬────────┘ └────────────────┘
│ 依赖
╌ ╌ ╌ ╌ ╌ ╌ ╌
▼
┌────────────────┐
│ 数据层 │
│ ┌────────┐ │
│ │用户DAO │ │
│ └────────┘ │
│ ┌────────┐ │
│ │订单DAO │ │
│ └────────┘ │
└────────────────┘
```
🔑 **一句话记忆口诀**：包用文件夹画，标签是包名；包间依赖是虚线开放箭头（指向被依赖），包间泛化是实线空心三角（指向父包）；包可以嵌套，元素分+/-可见性。
---
## 💡 三、包的四大设计原则
这些原则告诉你**怎么把类分到不同的包里**：
### 1. 重用等价原则（REP）
> 把可以一起复用的类放在一个包中。包 = 可重用的单元。
💬 就像一个工具包——扳手和螺丝刀放在一起，因为它们总是一起用。
### 2. 共同闭包原则（CCP）
> 把需要同时修改的类放在一个包中。
💬 修改了类A就必须修改类B？那它们应该在一个包里——改一个包就够了。
### 3. 共同重用原则（CRP）
> 不会一起用的类不要放在同一个包里。
💬 别把厨房用品和修车工具放一起——要用厨房用品的人不需要修车工具。
### 4. 非循环依赖原则（ADP）
> 包之间的依赖关系**不能形成环**。
💬 A→B→C→A 这样的循环依赖会严重妨碍复用。破解方法：提取共同接口或拆分包。
### 🔑 核心目标：高内聚、低耦合
| 原则 | 作用 |
|------|------|
| **高内聚** | 包内的类关系紧密（REP + CCP） |
| **低耦合** | 包之间的依赖尽量少（CRP + ADP） |
---
## ✍️ 边学边练
**题目**：判断以下做法是否合理。
1. 把订单处理类和用户登录类放在同一个包
2. A包依赖B包，B包依赖C包，C包依赖A包
3. 把所有工具类放在一个util包中，让其他包依赖它
4. 把用户界面类、数据库访问类、业务逻辑类放在同一个包
**答案：**
1. ❌ 不合理 — 违反CRP（不会一起使用的类不要放一起）。订单处理的人不需要登录功能。
2. ❌ 不合理 — 违反ADP（循环依赖）。
3. ✅ 合理 — 符合REP（工具类作为可重用单元）。
4. ❌ 不合理 — 违反CCP和CRP。不同层次的类（界面/数据/逻辑）修改原因不同，应该分开。
⚠️ **实用建议**：通常按层次分包（UI层、业务层、数据层），而不是按功能分包。
---
## 📝 章末自测
**1. 填空题**
- 包的四大设计原则缩写是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
- ADP原则要求包之间的依赖不能形成（ ___ ）（ ___ ）
- 包中元素的三种可见性是：公有(（ ___ ）（ ___ ）)、受保护(（ ___ ）（ ___ ）)、私有(（ ___ ）（ ___ ）)
**2. 简答题**
- 简述REP和CRP之间的矛盾是什么？
- 包图和组件图的关系是什么？
**答案：**
**填空题**：REP、CCP、CRP、ADP；循环；+、#、-
**简答题**：
- REP说要把可一起复用的类放在一个包，这可能导致一个包很大（包含所有可能用到的类）；CRP说不会一起用的类要分开，这可能导致很多小包。两者需要权衡。
- 包存放组件，组件包含类。包相当于文件夹，组件相当于文件。部署时：类→组件→包→结点。
---
> 🔗 上一篇：[第7章 组件图与部署图](第07章-组件图与部署图.md) | 下一篇：[第9章 数据建模](第09章-数据建模.md)

282
软件需求分析/各章笔记/第09章-数据建模.md
View File

@@ -1,141 +1,141 @@
# 第9章 数据建模
> **考试重要度**：★★★★
> **核心内容**：对象模型→数据模型的转换规则、多重性映射、泛化关系映射、三大范式
---
## 📢 从类图到数据库表
💬 前面用类图设计好了系统结构，但数据最终要存到数据库里。**数据建模**就是回答：怎么把"类"变成"数据库表"？
---
## 💡 一、数据库设计的三个阶段
| 阶段 | 任务 | 产物 |
|------|------|------|
| **概念设计** | 把用户需求统一到一个逻辑结构中 | E-R图（或UML类图） |
| **逻辑设计** | 转换为具体DBMS支持的数据模型 | 关系模式（表结构） |
| **物理设计** | 选择存储方式、索引策略等 | 在特定数据库上实现 |
💬 UML类图可以替代E-R图——类图不仅能描述数据，还能描述行为（触发器和存储过程）。
### 关键概念速查
| 概念 | 说明 |
|------|------|
| **主键** | 唯一标识一条记录的字段 |
| **外键** | 引用另一个表主键的字段 |
| **模式** | 所有表及表间关系的集合 |
| **索引** | 提高查询速度的数据结构 |
| **触发器** | 满足条件时自动执行的操作 |
| **存储过程** | 预编译的SQL语句集合 |
---
## 💡 二、对象模型 → 数据模型转换规则
### 基本转换规则
```
类 → 表
属性 → 字段（列）
操作 → 触发器/存储过程
类间关系 → 表间关系（或单独的表）
```
### 多重性在数据模型中的映射（重点！）
| 多重性 | 映射方法 |
|--------|----------|
| **1 对 0..\*** | 在多的一端加外键（指向一的一端的主键） |
| **0..1 对 1** | 在0..1一端加外键（指向1的一端的主键） |
| **0..\* 对 0..\*** | 新建一个关联表，两端主键作为外键 |
> 例：客户(Customer) 1 —— 0..* 订单(Order)
>
> → Order表加外键 `customer_id` 指向 Customer表的主键。
> 例：学生(Student) * —— * 课程(Course)
>
> → 新建选课表(Enrollment)，包含 `student_id` 和 `course_id` 两个外键。
### 泛化关系在数据模型中的映射（三种方案）
| 方案 | 做法 | 优点 | 缺点 |
|------|------|------|------|
| **方案一** | 父类和每个子类各建一个表 | 结构清晰 | 表多，查询要JOIN |
| **方案二** | 不建父类表，父类属性放在每个子类表中 | 查询快 | 数据冗余 |
| **方案三** | 不建子类表，所有子类属性放在父类表中 | 表少 | 字段很多，有空值 |
💬 **方案一像"分家"**——各过各的，但联系起来需要花时间。
💬 **方案二像"合住但分灶"**——各自独立但有些东西重复了。
💬 **方案三像"大家庭"**——都在一个屋檐下，但人多事杂。
---
## 💡 三、三大数据库范式
| 范式 | 要求 | 解决的问题 |
|------|------|------------|
| **1NF** | 每个字段值都是**不可再分**的原子值 | 消除重复列 |
| **2NF** | 满足1NF + 非主键字段**完全依赖**主键 | 消除部分依赖 |
| **3NF** | 满足2NF + 非主键字段**不传递依赖**主键 | 消除传递依赖 |
💬 **1NF**：别在一个格子里塞多个值。
💬 **2NF**：每个字段只跟主键有关，别跟主键的一部分有关。
💬 **3NF**：非主键字段之间不要相互依赖。
---
## ✍️ 边学边练
**题目**：以下表是否符合3NF？如果不符合，说明原因并修正。
```
订单表(Order)
订单ID (主键)
客户ID
客户姓名
客户电话
商品ID
商品名称
数量
下单日期
```
**答案：**
不符合3NF。存在传递依赖：
- 客户姓名、客户电话 → 依赖客户ID（不是直接依赖订单ID）
- 商品名称 → 依赖商品ID（不是直接依赖订单ID）
**修正方案**（拆分成三个表）：
- 订单表：订单ID、客户ID、商品ID、数量、下单日期
- 客户表：客户ID、客户姓名、客户电话
- 商品表：商品ID、商品名称
这样每个非主键字段都直接依赖于所在表的主键，满足3NF。
---
## 📝 章末自测
**1. 填空题**
- 1对多关联的映射方法是：在（ ___ ）（ ___ ）的一端加外键指向（ ___ ）（ ___ ）的一端
- 多对多关联的映射方法是：新建一个（ ___ ）（ ___ ），两边的主键作为外键
- 3NF要求非主键字段之间没有（ ___ ）（ ___ ）依赖
**2. 简答题**
- 简述泛化关系映射的三种方案及其适用场景。
- 类图中的操作在数据模型中对应什么？
**答案：**
**填空题**：多、一；关联表；传递
**简答题**：
- 方案一（每个类一个表）：适合查询灵活、结构变化少的系统。方案二（父子属性合并到子表）：适合子类差异大、按子类查询多的场景。方案三（所有属性合并到父表）：适合子类差异小、字段不多的场景。
- 类图中的操作对应数据库中的**触发器和存储过程**。触发器是满足条件自动执行的代码，存储过程是预编译的SQL程序。
---
> 🔗 上一篇：[第8章 包图](第08章-包图.md) | 下一篇：[第11章 RUP统一过程](第11章-RUP统一过程.md)
# 第9章 数据建模
> **考试重要度**：★★★★
> **核心内容**：对象模型→数据模型的转换规则、多重性映射、泛化关系映射、三大范式
---
## 📢 从类图到数据库表
💬 前面用类图设计好了系统结构，但数据最终要存到数据库里。**数据建模**就是回答：怎么把"类"变成"数据库表"？
---
## 💡 一、数据库设计的三个阶段
| 阶段 | 任务 | 产物 |
|------|------|------|
| **概念设计** | 把用户需求统一到一个逻辑结构中 | E-R图（或UML类图） |
| **逻辑设计** | 转换为具体DBMS支持的数据模型 | 关系模式（表结构） |
| **物理设计** | 选择存储方式、索引策略等 | 在特定数据库上实现 |
💬 UML类图可以替代E-R图——类图不仅能描述数据，还能描述行为（触发器和存储过程）。
### 关键概念速查
| 概念 | 说明 |
|------|------|
| **主键** | 唯一标识一条记录的字段 |
| **外键** | 引用另一个表主键的字段 |
| **模式** | 所有表及表间关系的集合 |
| **索引** | 提高查询速度的数据结构 |
| **触发器** | 满足条件时自动执行的操作 |
| **存储过程** | 预编译的SQL语句集合 |
---
## 💡 二、对象模型 → 数据模型转换规则
### 基本转换规则
```
类 → 表
属性 → 字段（列）
操作 → 触发器/存储过程
类间关系 → 表间关系（或单独的表）
```
### 多重性在数据模型中的映射（重点！）
| 多重性 | 映射方法 |
|--------|----------|
| **1 对 0..\*** | 在多的一端加外键（指向一的一端的主键） |
| **0..1 对 1** | 在0..1一端加外键（指向1的一端的主键） |
| **0..\* 对 0..\*** | 新建一个关联表，两端主键作为外键 |
> 例：客户(Customer) 1 —— 0..* 订单(Order)
>
> → Order表加外键 `customer_id` 指向 Customer表的主键。
> 例：学生(Student) * —— * 课程(Course)
>
> → 新建选课表(Enrollment)，包含 `student_id` 和 `course_id` 两个外键。
### 泛化关系在数据模型中的映射（三种方案）
| 方案 | 做法 | 优点 | 缺点 |
|------|------|------|------|
| **方案一** | 父类和每个子类各建一个表 | 结构清晰 | 表多，查询要JOIN |
| **方案二** | 不建父类表，父类属性放在每个子类表中 | 查询快 | 数据冗余 |
| **方案三** | 不建子类表，所有子类属性放在父类表中 | 表少 | 字段很多，有空值 |
💬 **方案一像"分家"**——各过各的，但联系起来需要花时间。
💬 **方案二像"合住但分灶"**——各自独立但有些东西重复了。
💬 **方案三像"大家庭"**——都在一个屋檐下，但人多事杂。
---
## 💡 三、三大数据库范式
| 范式 | 要求 | 解决的问题 |
|------|------|------------|
| **1NF** | 每个字段值都是**不可再分**的原子值 | 消除重复列 |
| **2NF** | 满足1NF + 非主键字段**完全依赖**主键 | 消除部分依赖 |
| **3NF** | 满足2NF + 非主键字段**不传递依赖**主键 | 消除传递依赖 |
💬 **1NF**：别在一个格子里塞多个值。
💬 **2NF**：每个字段只跟主键有关，别跟主键的一部分有关。
💬 **3NF**：非主键字段之间不要相互依赖。
---
## ✍️ 边学边练
**题目**：以下表是否符合3NF？如果不符合，说明原因并修正。
```
订单表(Order)
订单ID (主键)
客户ID
客户姓名
客户电话
商品ID
商品名称
数量
下单日期
```
**答案：**
不符合3NF。存在传递依赖：
- 客户姓名、客户电话 → 依赖客户ID（不是直接依赖订单ID）
- 商品名称 → 依赖商品ID（不是直接依赖订单ID）
**修正方案**（拆分成三个表）：
- 订单表：订单ID、客户ID、商品ID、数量、下单日期
- 客户表：客户ID、客户姓名、客户电话
- 商品表：商品ID、商品名称
这样每个非主键字段都直接依赖于所在表的主键，满足3NF。
---
## 📝 章末自测
**1. 填空题**
- 1对多关联的映射方法是：在（ ___ ）（ ___ ）的一端加外键指向（ ___ ）（ ___ ）的一端
- 多对多关联的映射方法是：新建一个（ ___ ）（ ___ ），两边的主键作为外键
- 3NF要求非主键字段之间没有（ ___ ）（ ___ ）依赖
**2. 简答题**
- 简述泛化关系映射的三种方案及其适用场景。
- 类图中的操作在数据模型中对应什么？
**答案：**
**填空题**：多、一；关联表；传递
**简答题**：
- 方案一（每个类一个表）：适合查询灵活、结构变化少的系统。方案二（父子属性合并到子表）：适合子类差异大、按子类查询多的场景。方案三（所有属性合并到父表）：适合子类差异小、字段不多的场景。
- 类图中的操作对应数据库中的**触发器和存储过程**。触发器是满足条件自动执行的代码，存储过程是预编译的SQL程序。
---
> 🔗 上一篇：[第8章 包图](第08章-包图.md) | 下一篇：[第11章 RUP统一过程](第11章-RUP统一过程.md)

328
软件需求分析/各章笔记/第11章-RUP统一过程.md
View File

@@ -1,164 +1,164 @@
# 第11章 Rational统一过程（RUP）
> **考试重要度**：★★★
> **核心内容**：RUP的三大特点、四个阶段、九个核心工作流、六大最佳实践
---
## 📢 软件开发不只是写代码
💬 开发软件就像盖一座大楼——你不能上来就搬砖，得先画图纸、打地基、搭框架、装修……
**RUP** 就是一套完整的"盖楼流程指南"，告诉你：什么人、在什么时候、做什么事、怎么做。
---
## 💡 一、RUP是什么？
> **RUP (Rational Unified Process)** = 一套基于UML的软件开发过程框架。
🔑 **核心公式**：RUP = **用例驱动** + **以体系结构为中心** + **迭代和增量开发**
### 三大特点
| 特点 | 含义 |
|------|------|
| **用例驱动** | 从用例出发，贯穿需求→设计→实现→测试全过程 |
| **以体系结构为中心** | 先搭建系统骨架，再逐步填充细节 |
| **迭代和增量开发** | 不是一口气做完，而是一轮一轮地完善 |
---
## 💡 二、RUP的二维结构
```
┌─────────────────────────────────────┐
纵轴 │ 工作流 │
(做 │ 业务建模 需求 分析设计 实现 测试 部署 │
什么) │ 配置管理 项目管理 环境 │
├─────────────────────────────────────┤
横轴 │ 初始 → 细化 → 构造 → 移交 │
(什么 │ ↑ ↑ ↑ ↑ │
时候) │ 里程碑 里程碑 里程碑 里程碑 │
└─────────────────────────────────────┘
```
---
## 💡 三、四个阶段（横轴）
| 阶段 | 核心任务 | 里程碑 |
|------|----------|--------|
| **初始 (Inception)** | 定义项目范围，评估可行性 | 生命周期目标里程碑 |
| **细化 (Elaboration)** | 设计体系结构，制定计划 | 生命周期体系结构里程碑 |
| **构造 (Construction)** | 大规模开发，完成所有功能 | 初始操作能力里程碑 |
| **移交 (Transition)** | 交付用户，培训，部署 | 产品发布里程碑 |
💬 **比喻**：初始=立项审批，细化=画施工图，构造=主体施工，移交=交房验收。
---
## 💡 四、九个核心工作流（纵轴）
### 六个过程工作流
| 工作流 | 做什么 | 主要产物 |
|--------|--------|----------|
| **业务建模** | 理解业务现状 | 业务用例模型、业务对象模型 |
| **需求** | 定义系统功能 | 用例模型、SRS |
| **分析与设计** | 设计系统结构 | 分析模型、设计模型、数据模型 |
| **实现** | 编写代码 | 源代码、可执行系统 |
| **测试** | 验证系统质量 | 测试计划、测试报告 |
| **部署** | 交付使用 | 安装包、用户手册、培训资料 |
### 三个支持工作流
| 工作流 | 做什么 |
|--------|--------|
| **配置与变更管理** | 控制制品版本和变更 |
| **项目管理** | 计划、分配、监控项目 |
| **环境** | 提供开发工具和过程支持 |
---
## 💡 五、4W概念
RUP回答了软件开发的四个基本问题：
| 维度 | 问题 | RUP概念 |
|------|------|---------|
| **Who** | 谁来做？ | 角色（Role） |
| **How** | 怎么做？ | 活动（Activity） |
| **What** | 产出什么？ | 制品（Artifact） |
| **When** | 什么时候做？ | 工作流（Workflow） |
---
## 💡 六、六大最佳实践
🔑 **这是考试的常考点！**
| 最佳实践 | 含义 |
|----------|------|
| **① 迭代式开发** | 不是一次做完，而是多轮迭代，每轮都有一个可运行版本 |
| **② 管理需求** | 用用例来组织和管理需求，控制变更 |
| **③ 使用基于构件的体系结构** | 把系统设计成可替换的构件 |
| **④ 可视化软件建模** | 用UML图来描述系统结构和行为 |
| **⑤ 验证软件质量** | 把质量评估嵌入整个过程，不是事后检查 |
| **⑥ 控制软件变更** | 通过配置管理跟踪和控制每个修改 |
---
## 💡 七、迭代 vs 瀑布
| 维度 | 瀑布模型 | RUP迭代 |
|------|----------|---------|
| **节奏** | 需求→设计→编码→测试，一次性 | 多轮迭代，每轮都走完整流程 |
| **风险** | 到最后才发现问题 | 早期就能发现和解决风险 |
| **变更** | 不欢迎变更 | 每轮迭代可以调整方向 |
| **产出** | 最后才有可运行版本 | 每轮都有可运行版本 |
---
## ✍️ 边学边练
**题目**：判断以下描述对应RUP的哪个阶段或工作流。
1. 项目经理制定本次迭代的计划
2. 测试人员编写测试用例并执行
3. 确定系统的技术架构是B/S还是C/S
4. 系统上线，培训用户使用
5. 绘制用例图，确定系统功能范围
**答案：**
1. **项目管理**（支持工作流）| 可在任何阶段
2. **测试**（过程工作流）| 主要在构造阶段
3. **细化阶段** — 设计体系结构
4. **移交阶段** — 交付给用户
5. **初始阶段** 或 **需求工作流** — 定义范围和功能
---
## 📝 章末自测
**1. 填空题**
- RUP的三大特点是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
- RUP的四个阶段依次是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
- 九个核心工作流中，6个是（ ___ ）（ ___ ）工作流，3个是（ ___ ）（ ___ ）工作流
**2. 简答题**
- 简述RUP六大最佳实践。
- 迭代和增量开发相比瀑布模型有什么优势？
**答案：**
**填空题**：
- 用例驱动、以体系结构为中心、迭代和增量开发
- 初始、细化、构造、移交
- 过程、支持
**简答题**：
- ①迭代式开发 ②管理需求 ③使用基于构件的体系结构 ④可视化软件建模 ⑤验证软件质量 ⑥控制软件变更
- 迭代开发可以早期发现风险、更容易容纳需求变更、每轮都有可运行的版本（增强信心）、可以根据反馈及时调整方向。
---
> 🔗 上一篇：[第9章 数据建模](第09章-数据建模.md)
# 第11章 Rational统一过程（RUP）
> **考试重要度**：★★★
> **核心内容**：RUP的三大特点、四个阶段、九个核心工作流、六大最佳实践
---
## 📢 软件开发不只是写代码
💬 开发软件就像盖一座大楼——你不能上来就搬砖，得先画图纸、打地基、搭框架、装修……
**RUP** 就是一套完整的"盖楼流程指南"，告诉你：什么人、在什么时候、做什么事、怎么做。
---
## 💡 一、RUP是什么？
> **RUP (Rational Unified Process)** = 一套基于UML的软件开发过程框架。
🔑 **核心公式**：RUP = **用例驱动** + **以体系结构为中心** + **迭代和增量开发**
### 三大特点
| 特点 | 含义 |
|------|------|
| **用例驱动** | 从用例出发，贯穿需求→设计→实现→测试全过程 |
| **以体系结构为中心** | 先搭建系统骨架，再逐步填充细节 |
| **迭代和增量开发** | 不是一口气做完，而是一轮一轮地完善 |
---
## 💡 二、RUP的二维结构
```
┌─────────────────────────────────────┐
纵轴 │ 工作流 │
(做 │ 业务建模 需求 分析设计 实现 测试 部署 │
什么) │ 配置管理 项目管理 环境 │
├─────────────────────────────────────┤
横轴 │ 初始 → 细化 → 构造 → 移交 │
(什么 │ ↑ ↑ ↑ ↑ │
时候) │ 里程碑 里程碑 里程碑 里程碑 │
└─────────────────────────────────────┘
```
---
## 💡 三、四个阶段（横轴）
| 阶段 | 核心任务 | 里程碑 |
|------|----------|--------|
| **初始 (Inception)** | 定义项目范围，评估可行性 | 生命周期目标里程碑 |
| **细化 (Elaboration)** | 设计体系结构，制定计划 | 生命周期体系结构里程碑 |
| **构造 (Construction)** | 大规模开发，完成所有功能 | 初始操作能力里程碑 |
| **移交 (Transition)** | 交付用户，培训，部署 | 产品发布里程碑 |
💬 **比喻**：初始=立项审批，细化=画施工图，构造=主体施工，移交=交房验收。
---
## 💡 四、九个核心工作流（纵轴）
### 六个过程工作流
| 工作流 | 做什么 | 主要产物 |
|--------|--------|----------|
| **业务建模** | 理解业务现状 | 业务用例模型、业务对象模型 |
| **需求** | 定义系统功能 | 用例模型、SRS |
| **分析与设计** | 设计系统结构 | 分析模型、设计模型、数据模型 |
| **实现** | 编写代码 | 源代码、可执行系统 |
| **测试** | 验证系统质量 | 测试计划、测试报告 |
| **部署** | 交付使用 | 安装包、用户手册、培训资料 |
### 三个支持工作流
| 工作流 | 做什么 |
|--------|--------|
| **配置与变更管理** | 控制制品版本和变更 |
| **项目管理** | 计划、分配、监控项目 |
| **环境** | 提供开发工具和过程支持 |
---
## 💡 五、4W概念
RUP回答了软件开发的四个基本问题：
| 维度 | 问题 | RUP概念 |
|------|------|---------|
| **Who** | 谁来做？ | 角色（Role） |
| **How** | 怎么做？ | 活动（Activity） |
| **What** | 产出什么？ | 制品（Artifact） |
| **When** | 什么时候做？ | 工作流（Workflow） |
---
## 💡 六、六大最佳实践
🔑 **这是考试的常考点！**
| 最佳实践 | 含义 |
|----------|------|
| **① 迭代式开发** | 不是一次做完，而是多轮迭代，每轮都有一个可运行版本 |
| **② 管理需求** | 用用例来组织和管理需求，控制变更 |
| **③ 使用基于构件的体系结构** | 把系统设计成可替换的构件 |
| **④ 可视化软件建模** | 用UML图来描述系统结构和行为 |
| **⑤ 验证软件质量** | 把质量评估嵌入整个过程，不是事后检查 |
| **⑥ 控制软件变更** | 通过配置管理跟踪和控制每个修改 |
---
## 💡 七、迭代 vs 瀑布
| 维度 | 瀑布模型 | RUP迭代 |
|------|----------|---------|
| **节奏** | 需求→设计→编码→测试，一次性 | 多轮迭代，每轮都走完整流程 |
| **风险** | 到最后才发现问题 | 早期就能发现和解决风险 |
| **变更** | 不欢迎变更 | 每轮迭代可以调整方向 |
| **产出** | 最后才有可运行版本 | 每轮都有可运行版本 |
---
## ✍️ 边学边练
**题目**：判断以下描述对应RUP的哪个阶段或工作流。
1. 项目经理制定本次迭代的计划
2. 测试人员编写测试用例并执行
3. 确定系统的技术架构是B/S还是C/S
4. 系统上线，培训用户使用
5. 绘制用例图，确定系统功能范围
**答案：**
1. **项目管理**（支持工作流）| 可在任何阶段
2. **测试**（过程工作流）| 主要在构造阶段
3. **细化阶段** — 设计体系结构
4. **移交阶段** — 交付给用户
5. **初始阶段** 或 **需求工作流** — 定义范围和功能
---
## 📝 章末自测
**1. 填空题**
- RUP的三大特点是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
- RUP的四个阶段依次是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
- 九个核心工作流中，6个是（ ___ ）（ ___ ）工作流，3个是（ ___ ）（ ___ ）工作流
**2. 简答题**
- 简述RUP六大最佳实践。
- 迭代和增量开发相比瀑布模型有什么优势？
**答案：**
**填空题**：
- 用例驱动、以体系结构为中心、迭代和增量开发
- 初始、细化、构造、移交
- 过程、支持
**简答题**：
- ①迭代式开发 ②管理需求 ③使用基于构件的体系结构 ④可视化软件建模 ⑤验证软件质量 ⑥控制软件变更
- 迭代开发可以早期发现风险、更容易容纳需求变更、每轮都有可运行的版本（增强信心）、可以根据反馈及时调整方向。
---
> 🔗 上一篇：[第9章 数据建模](第09章-数据建模.md)

378
软件需求分析/期中复习/期中复习指南.md
View File

@@ -1,189 +1,189 @@
# 期中考试复习
> **考试**：2022-2023学年第1学期《软件需求分析与设计》期中考试
> **满分**：100分 | 选择题30分 + 系统分析题70分
> **系统场景**：在线酒店订房系统
---
## 📋 试卷结构一览
| 题型 | 题量 | 分值 | 考点 |
|------|------|------|------|
| 选择题 | 15题 | 30分（2分/题） | UML基本概念、关系类型、面向对象特性 |
| 系统分析题 | 7题 | 70分（10分/题） | 7种UML图的实际绘制 |
---
## 🎯 七道大题逐题详解
### 第1题：用例图（10分）
> 画出在线订房系统的用例图。
**答案要点**：
**参与者（3个）**：客户、管理员、身份信息平台
**用例（10个）**：
- 客户相关：找回密码、注册、身份认证、登录、查询房间、下订单、在线支付
- 管理员相关：登录、房间上线、修改房间信息、房间下线
**关键关系**：
- **包含 `<<include>>`**：注册 → 身份认证；下订单 → 查询房间；在线支付 → 下订单
- **关联**：客户↔找回密码、注册、登录、查询房间、下订单；管理员↔登录、房间上线、修改、下线
- **身份认证 → 身份信息平台**（外部系统交互）
⚠️ **易错**：包含关系箭头从基本用例指向包含用例！
---
### 第2题："找回密码"用例描述（10分）
> 写出"找回密码"的完整用例描述。
**参考答案**：
| 项目 | 内容 |
|------|------|
| **用例名** | 找回密码 |
| **参与者** | 客户 |
| **前置条件** | 客户已注册 |
| **基本流程** | ①输入手机号 → ②获取短信验证码 → ③输入验证码 → ④输入新密码(两次) → ⑤两次一致则密码修改成功 |
| **备选流程** | 若两次新密码不一致，提示重新输入 |
| **后置条件** | 密码修改成功，用户可用新密码登录 |
---
### 第3题：实体类类图（10分）
> 画出系统的实体类类图，标注多重性。
**答案要点**：
**实体类**：客户(Customer)、房间(Room)、订单(Order)、管理员(Admin)
**关系及多重性**：
```
客户 1 ────── 0..* 订单 （一个客户可以有多个订单）
房间 1 ────── 0..* 订单 （一个房间可以被多次预订）
管理员 0..2 ── 0..* 订单 （管理员处理订单）
```
---
### 第4题："找回密码"的基于协作的类图（10分）
> 使用边界类、控制类、实体类画出协作类图。
**答案要点**：
| 版型 | 类名 | 职责 |
|------|------|------|
| <<boundary>> | RetrievePasswordBoundary | 找回密码界面，与用户交互 |
| <<control>> | RetrievePasswordControl | 协调找回密码的业务逻辑 |
| <<interface>> | SMSInterface | 短信接口（外部） |
| <<entity>> | UserInfo | 用户信息（持久化） |
**依赖关系**：
```
Boundary → Control → SMSInterface
→ UserInfo
```
---
### 第5题："找回密码"的顺序图（10分）
> 画出"找回密码"的顺序图，标注消息编号。
**答案要点**：
**对象**：用户、:RetrievePasswordBoundary、:RetrievePasswordControl、:UserInfo、:SMSInterface
**消息序列（核心流程）**：
```
1: 用户 → 边界类 : 找回密码()
1.1: 用户 → 边界类 : 输入手机号
1.1.1: 边界 → 控制 : 获取短信(手机号)
1.1.1.1: 控制 → SMS : 获取短信(手机号)
2: 用户 → 边界类 : 输入验证码
2.1: 边界 → 控制 : 验证(验证码)
2.1.1: 控制 → UserInfo : 验证(验证码)
3: 用户 → 边界类 : 输入(新密码1, 新密码2)
3.1: 边界 → 控制 : 验证一致性(p1, p2)
3.1.1: [一致] 控制 → UserInfo : 写入新密码
```
🔑 **编号规则**：`1` → `1.1` → `1.1.1` 表示嵌套调用，`1.1.1` 必须在 `1.1` 完成之前完成。
---
### 第6题："订单"的状态图（10分）
> 画出实体类"订单"的状态图。
**答案要点**：
```
初始 → 待支付 → 已支付 → 已入住 → 完成
↓ ↓
取消 失效
```
| 转移 | 触发事件 |
|------|----------|
| 初始 → 待支付 | 下单 |
| 待支付 → 取消 | 未支付 |
| 待支付 → 已支付 | 成功支付 |
| 已支付 → 失效 | 超时 |
| 已支付 → 已入住 | 入住 |
| 已入住 → 完成 | 退房 |
---
### 第7题："找回密码"的带泳道活动图（10分）
> 画出"找回密码"的带泳道活动图。
**答案要点**：
**泳道（5条）**：用户 | 找回密码边界类 | 找回密码控制类 | 短信接口 | 用户信息
**活动流程**：
```
用户：开始 → 找回密码 → 输入手机号
↓
控制类 → 短信接口：获取短信验证码 → 返回验证码
↓
用户：输入验证码 → 输入2次新密码
↓
控制类：验证两次密码
├─ [不一致] → 结束
└─ [一致] → 用户信息：写入新密码 → 结束
```
---
## 📊 七道题的分值分布与重点
| 题号 | 考什么 | 难度 | 必会程度 |
|------|--------|------|----------|
| 1 | 用例图 | ⭐⭐ | ★★★★★ |
| 2 | 用例描述 | ⭐ | ★★★★★ |
| 3 | 类图（实体类） | ⭐⭐ | ★★★★★ |
| 4 | 协作类图（MVC） | ⭐⭐⭐ | ★★★★ |
| 5 | 顺序图（消息编号） | ⭐⭐⭐ | ★★★★ |
| 6 | 状态图 | ⭐⭐ | ★★★★★ |
| 7 | 活动图（带泳道） | ⭐⭐⭐ | ★★★★ |
---
## 🔑 考前必记要点
1. **包含关系 vs 扩展关系**：包含=必然，扩展=条件。箭头方向不同！
2. **多重性**：`1` `0..1` `0..*` `1..*` 的含义和标注位置
3. **边界类/控制类/实体类**：View/Controller/Model 对应关系
4. **消息编号层级**：`1.1.1` 表示嵌套调用深度
5. **状态图**：别忘了初始状态（实心圆）和终态（圆圈+实心圆）
6. **活动图泳道**：根据参与者来划分，每道一个责任区
# 期中考试复习
> **考试**：2022-2023学年第1学期《软件需求分析与设计》期中考试
> **满分**：100分 | 选择题30分 + 系统分析题70分
> **系统场景**：在线酒店订房系统
---
## 📋 试卷结构一览
| 题型 | 题量 | 分值 | 考点 |
|------|------|------|------|
| 选择题 | 15题 | 30分（2分/题） | UML基本概念、关系类型、面向对象特性 |
| 系统分析题 | 7题 | 70分（10分/题） | 7种UML图的实际绘制 |
---
## 🎯 七道大题逐题详解
### 第1题：用例图（10分）
> 画出在线订房系统的用例图。
**答案要点**：
**参与者（3个）**：客户、管理员、身份信息平台
**用例（10个）**：
- 客户相关：找回密码、注册、身份认证、登录、查询房间、下订单、在线支付
- 管理员相关：登录、房间上线、修改房间信息、房间下线
**关键关系**：
- **包含 `<<include>>`**：注册 → 身份认证；下订单 → 查询房间；在线支付 → 下订单
- **关联**：客户↔找回密码、注册、登录、查询房间、下订单；管理员↔登录、房间上线、修改、下线
- **身份认证 → 身份信息平台**（外部系统交互）
⚠️ **易错**：包含关系箭头从基本用例指向包含用例！
---
### 第2题："找回密码"用例描述（10分）
> 写出"找回密码"的完整用例描述。
**参考答案**：
| 项目 | 内容 |
|------|------|
| **用例名** | 找回密码 |
| **参与者** | 客户 |
| **前置条件** | 客户已注册 |
| **基本流程** | ①输入手机号 → ②获取短信验证码 → ③输入验证码 → ④输入新密码(两次) → ⑤两次一致则密码修改成功 |
| **备选流程** | 若两次新密码不一致，提示重新输入 |
| **后置条件** | 密码修改成功，用户可用新密码登录 |
---
### 第3题：实体类类图（10分）
> 画出系统的实体类类图，标注多重性。
**答案要点**：
**实体类**：客户(Customer)、房间(Room)、订单(Order)、管理员(Admin)
**关系及多重性**：
```
客户 1 ────── 0..* 订单 （一个客户可以有多个订单）
房间 1 ────── 0..* 订单 （一个房间可以被多次预订）
管理员 0..2 ── 0..* 订单 （管理员处理订单）
```
---
### 第4题："找回密码"的基于协作的类图（10分）
> 使用边界类、控制类、实体类画出协作类图。
**答案要点**：
| 版型 | 类名 | 职责 |
|------|------|------|
| <<boundary>> | RetrievePasswordBoundary | 找回密码界面，与用户交互 |
| <<control>> | RetrievePasswordControl | 协调找回密码的业务逻辑 |
| <<interface>> | SMSInterface | 短信接口（外部） |
| <<entity>> | UserInfo | 用户信息（持久化） |
**依赖关系**：
```
Boundary → Control → SMSInterface
→ UserInfo
```
---
### 第5题："找回密码"的顺序图（10分）
> 画出"找回密码"的顺序图，标注消息编号。
**答案要点**：
**对象**：用户、:RetrievePasswordBoundary、:RetrievePasswordControl、:UserInfo、:SMSInterface
**消息序列（核心流程）**：
```
1: 用户 → 边界类 : 找回密码()
1.1: 用户 → 边界类 : 输入手机号
1.1.1: 边界 → 控制 : 获取短信(手机号)
1.1.1.1: 控制 → SMS : 获取短信(手机号)
2: 用户 → 边界类 : 输入验证码
2.1: 边界 → 控制 : 验证(验证码)
2.1.1: 控制 → UserInfo : 验证(验证码)
3: 用户 → 边界类 : 输入(新密码1, 新密码2)
3.1: 边界 → 控制 : 验证一致性(p1, p2)
3.1.1: [一致] 控制 → UserInfo : 写入新密码
```
🔑 **编号规则**：`1` → `1.1` → `1.1.1` 表示嵌套调用，`1.1.1` 必须在 `1.1` 完成之前完成。
---
### 第6题："订单"的状态图（10分）
> 画出实体类"订单"的状态图。
**答案要点**：
```
初始 → 待支付 → 已支付 → 已入住 → 完成
↓ ↓
取消 失效
```
| 转移 | 触发事件 |
|------|----------|
| 初始 → 待支付 | 下单 |
| 待支付 → 取消 | 未支付 |
| 待支付 → 已支付 | 成功支付 |
| 已支付 → 失效 | 超时 |
| 已支付 → 已入住 | 入住 |
| 已入住 → 完成 | 退房 |
---
### 第7题："找回密码"的带泳道活动图（10分）
> 画出"找回密码"的带泳道活动图。
**答案要点**：
**泳道（5条）**：用户 | 找回密码边界类 | 找回密码控制类 | 短信接口 | 用户信息
**活动流程**：
```
用户：开始 → 找回密码 → 输入手机号
↓
控制类 → 短信接口：获取短信验证码 → 返回验证码
↓
用户：输入验证码 → 输入2次新密码
↓
控制类：验证两次密码
├─ [不一致] → 结束
└─ [一致] → 用户信息：写入新密码 → 结束
```
---
## 📊 七道题的分值分布与重点
| 题号 | 考什么 | 难度 | 必会程度 |
|------|--------|------|----------|
| 1 | 用例图 | ⭐⭐ | ★★★★★ |
| 2 | 用例描述 | ⭐ | ★★★★★ |
| 3 | 类图（实体类） | ⭐⭐ | ★★★★★ |
| 4 | 协作类图（MVC） | ⭐⭐⭐ | ★★★★ |
| 5 | 顺序图（消息编号） | ⭐⭐⭐ | ★★★★ |
| 6 | 状态图 | ⭐⭐ | ★★★★★ |
| 7 | 活动图（带泳道） | ⭐⭐⭐ | ★★★★ |
---
## 🔑 考前必记要点
1. **包含关系 vs 扩展关系**：包含=必然，扩展=条件。箭头方向不同！
2. **多重性**：`1` `0..1` `0..*` `1..*` 的含义和标注位置
3. **边界类/控制类/实体类**：View/Controller/Model 对应关系
4. **消息编号层级**：`1.1.1` 表示嵌套调用深度
5. **状态图**：别忘了初始状态（实心圆）和终态（圆圈+实心圆）
6. **活动图泳道**：根据参与者来划分，每道一个责任区

202
软件需求分析/速查手册/UML九图速查.md
View File

@@ -1,101 +1,101 @@
# UML九图速查手册
> **用途**：考前快速回顾9种UML图的核心特征
---
## 📊 九种UML图一句话定位
| 想表达什么？ | 用什么图？ |
|--------------|-----------|
| 系统能干什么？ | **用例图** |
| 系统里有哪些类？它们什么关系？ | **类图** |
| 某一刻对象的具体情况？ | **对象图** |
| 对象之间怎么按时间顺序交互？ | **顺序图** |
| 对象之间怎么在空间上协作？ | **协作图** |
| 一个对象的状态怎么变化？ | **状态图** |
| 一个业务流程步骤怎么走？ | **活动图** |
| 代码文件之间怎么依赖？ | **组件图** |
| 软件部署在哪些硬件上？ | **部署图** |
---
## 🔗 九图分类
```
UML图
├── 功能模型：用例图
├── 静态模型（结构）：类图、对象图、包图
├── 动态模型（行为）：顺序图、协作图、状态图、活动图
└── 物理模型（实现）：组件图、部署图
```
---
## 📋 九图完整对比表
| 图类型 | 分类 | 描述几个对象？ | 强调 | 核心元素 |
|--------|------|:---:|------|----------|
| **用例图** | 功能 | 多 | 系统功能全景 | 参与者、用例、系统边界 |
| **类图** | 静态结构 | 多 | 类的定义和关系 | 类、属性、操作、关系 |
| **对象图** | 静态结构 | 多 | 某一时刻的快照 | 对象、属性值、链 |
| **包图** | 静态结构 | 多 | 类的分组组织 | 包、依赖、泛化 |
| **顺序图** | 动态交互 | 多 | 消息的时间顺序 | 对象、生命线、控制焦点、消息 |
| **协作图** | 动态交互 | 多 | 对象的空间位置 | 对象、链、消息（带序号） |
| **状态图** | 动态行为 | **1个** | 状态如何变迁 | 状态、转移、事件 |
| **活动图** | 动态行为 | 多 | 流程步骤 | 活动、分支、泳道、分叉 |
| **组件图** | 物理实现 | 多 | 代码文件组织 | 组件、接口、依赖 |
| **部署图** | 物理实现 | 多 | 硬件拓扑 | 结点、组件、连接 |
---
## 🎨 各图关键语法速查
### 用例图
- 参与者 = 火柴人 🧑
- 用例 = 椭圆 ○
- 系统边界 = 方框 □
- 关系：包含 `<<include>>` (必然)、扩展 `<<extend>>` (条件)
### 类图
- 类 = 三格矩形（类名|属性|操作）
- 可见性：`+`公有 `-`私有 `#`受保护
- 六大关系：关联(实线)、聚合(空心菱形)、组合(实心菱形)、依赖(虚线)、泛化(空心三角)、实现(虚线空心三角)
### 顺序图
- 对象 + 生命线(虚线) + 控制焦点(矩形条) + 消息(箭头)
- 调用消息 = 实心箭头，异步消息 = 开放箭头
- 嵌套：1 → 1.1 → 1.1.1
### 协作图
- 对象 + 链(实线) + 消息(带序号)
- 必须标注消息序号！没有时间轴
### 状态图
- 状态 = 圆角矩形，转移 = 箭头
- 事件/ [条件] / 动作
- 初始状态 ● → 终态 ⊙
### 活动图
- 活动 = 圆角矩形
- 分支 = 菱形 ◇
- 分叉/汇合 = 粗横线
- 泳道 = 纵向分区
### 组件图
- 组件 = 带<<component>>的矩形
- 关系主要是依赖（虚线箭头）
### 部署图
- 结点 = 3D立方体
- 通信路径 = 实线
---
## 📐 MVC版型速查
| 版型 | 图标 | 职责 | 例子 |
|------|------|------|------|
| <<boundary>> 边界类 | 带竖线的圆 | 与外界交互 | 登录页面、购物车页面 |
| <<control>> 控制类 | 带箭头的圆 | 协调逻辑 | 订单处理、支付验证 |
| <<entity>> 实体类 | 带横线的圆 | 持久化数据 | 用户、订单、商品 |
# UML九图速查手册
> **用途**：考前快速回顾9种UML图的核心特征
---
## 📊 九种UML图一句话定位
| 想表达什么？ | 用什么图？ |
|--------------|-----------|
| 系统能干什么？ | **用例图** |
| 系统里有哪些类？它们什么关系？ | **类图** |
| 某一刻对象的具体情况？ | **对象图** |
| 对象之间怎么按时间顺序交互？ | **顺序图** |
| 对象之间怎么在空间上协作？ | **协作图** |
| 一个对象的状态怎么变化？ | **状态图** |
| 一个业务流程步骤怎么走？ | **活动图** |
| 代码文件之间怎么依赖？ | **组件图** |
| 软件部署在哪些硬件上？ | **部署图** |
---
## 🔗 九图分类
```
UML图
├── 功能模型：用例图
├── 静态模型（结构）：类图、对象图、包图
├── 动态模型（行为）：顺序图、协作图、状态图、活动图
└── 物理模型（实现）：组件图、部署图
```
---
## 📋 九图完整对比表
| 图类型 | 分类 | 描述几个对象？ | 强调 | 核心元素 |
|--------|------|:---:|------|----------|
| **用例图** | 功能 | 多 | 系统功能全景 | 参与者、用例、系统边界 |
| **类图** | 静态结构 | 多 | 类的定义和关系 | 类、属性、操作、关系 |
| **对象图** | 静态结构 | 多 | 某一时刻的快照 | 对象、属性值、链 |
| **包图** | 静态结构 | 多 | 类的分组组织 | 包、依赖、泛化 |
| **顺序图** | 动态交互 | 多 | 消息的时间顺序 | 对象、生命线、控制焦点、消息 |
| **协作图** | 动态交互 | 多 | 对象的空间位置 | 对象、链、消息（带序号） |
| **状态图** | 动态行为 | **1个** | 状态如何变迁 | 状态、转移、事件 |
| **活动图** | 动态行为 | 多 | 流程步骤 | 活动、分支、泳道、分叉 |
| **组件图** | 物理实现 | 多 | 代码文件组织 | 组件、接口、依赖 |
| **部署图** | 物理实现 | 多 | 硬件拓扑 | 结点、组件、连接 |
---
## 🎨 各图关键语法速查
### 用例图
- 参与者 = 火柴人 🧑
- 用例 = 椭圆 ○
- 系统边界 = 方框 □
- 关系：包含 `<<include>>` (必然)、扩展 `<<extend>>` (条件)
### 类图
- 类 = 三格矩形（类名|属性|操作）
- 可见性：`+`公有 `-`私有 `#`受保护
- 六大关系：关联(实线)、聚合(空心菱形)、组合(实心菱形)、依赖(虚线)、泛化(空心三角)、实现(虚线空心三角)
### 顺序图
- 对象 + 生命线(虚线) + 控制焦点(矩形条) + 消息(箭头)
- 调用消息 = 实心箭头，异步消息 = 开放箭头
- 嵌套：1 → 1.1 → 1.1.1
### 协作图
- 对象 + 链(实线) + 消息(带序号)
- 必须标注消息序号！没有时间轴
### 状态图
- 状态 = 圆角矩形，转移 = 箭头
- 事件/ [条件] / 动作
- 初始状态 ● → 终态 ⊙
### 活动图
- 活动 = 圆角矩形
- 分支 = 菱形 ◇
- 分叉/汇合 = 粗横线
- 泳道 = 纵向分区
### 组件图
- 组件 = 带<<component>>的矩形
- 关系主要是依赖（虚线箭头）
### 部署图
- 结点 = 3D立方体
- 通信路径 = 实线
---
## 📐 MVC版型速查
| 版型 | 图标 | 职责 | 例子 |
|------|------|------|------|
| <<boundary>> 边界类 | 带竖线的圆 | 与外界交互 | 登录页面、购物车页面 |
| <<control>> 控制类 | 带箭头的圆 | 协调逻辑 | 订单处理、支付验证 |
| <<entity>> 实体类 | 带横线的圆 | 持久化数据 | 用户、订单、商品 |

220
软件需求分析/速查手册/设计原则与术语速查.md
View File

@@ -1,110 +1,110 @@
# 设计原则与术语速查
> **用途**：考前快速回顾关键设计原则和术语
---
## 🔷 SOLID五大原则
| 原则 | 全称 | 含义 |
|------|------|------|
| **S** | 单一职责原则 | 一个类只负责一件事 |
| **O** | 开闭原则 | 对扩展开放，对修改关闭 |
| **L** | 里氏替换原则 | 子类可以替换父类而不出问题 |
| **I** | 接口隔离原则 | 接口要小而精，不要大而全 |
| **D** | 依赖倒置原则 | 依赖抽象（接口），不依赖具体实现 |
---
## 🔷 包设计四大原则
| 缩写 | 原则 | 含义 |
|------|------|------|
| **REP** | 重用等价原则 | 可一起复用的类放一个包 |
| **CCP** | 共同闭包原则 | 需要同时修改的类放一个包 |
| **CRP** | 共同重用原则 | 不会一起用的类分开放 |
| **ADP** | 非循环依赖原则 | 包之间的依赖不能形成环 |
---
## 🔷 其他重要原则
| 原则 | 含义 |
|------|------|
| **高内聚低耦合** | 包内关系紧密（内聚），包间关系稀疏（耦合） |
| **迪米特法则** | 最少知识原则——只跟"朋友"说话 |
| **组合优于继承** | 能用组合实现的效果，别用继承（更灵活） |
---
## 🔷 数据库三大范式
| 范式 | 要求 |
|------|------|
| **1NF** | 字段值不可再分（原子性） |
| **2NF** | 非主键字段完全依赖主键（消除部分依赖） |
| **3NF** | 非主键字段不传递依赖主键（消除传递依赖） |
---
## 🔷 对象模型→数据模型映射速查
| 对象模型 | 数据模型 |
|----------|----------|
| 类 | 表 |
| 属性 | 字段（列） |
| 操作 | 触发器 + 存储过程 |
| 1对0..*关联 | 多的一端加外键 |
| *对*关联 | 新建关联表 |
| 泛化关系 | 三种方案（父子各建表/只建子表/只建父表） |
---
## 🔷 需求工程术语速查
| 术语 | 定义 |
|------|------|
| **软件需求** | 用户对系统在功能、行为、性能、约束方面的期望 |
| **业务需求** | 组织的高层次目标 |
| **用户需求** | 用户使用系统完成的任务 |
| **功能需求** | 系统必须实现的功能 |
| **非功能需求** | 系统的质量属性和约束 |
| **SRS** | 软件需求规格说明书 |
| **需求基线** | 评审通过、双方承诺的需求版本 |
| **需求跟踪矩阵(RTM)** | 记录需求与设计、代码、测试对应关系的表 |
| **需求变更控制** | 变更申请→审批→修改→重新确认的流程 |
---
## 🔷 面向对象核心概念
| 概念 | 含义 |
|------|------|
| **封装** | 隐藏内部实现，只暴露接口 |
| **继承** | 子类自动拥有父类的属性和方法 |
| **多态** | 同一操作在不同对象上有不同行为 |
| **抽象** | 提取共性，忽略细节 |
---
## 🔷 关联关系多重性速记
| 符号 | 含义 |
|------|------|
| `1` | 恰好1个 |
| `0..1` | 0个或1个 |
| `*` 或 `0..*` | 0个或多个 |
| `1..*` | 至少1个 |
| `n` | 恰好n个 |
---
## 🔷 常见设计模式速查
| 模式 | 类型 | 解决什么问题 |
|------|------|-------------|
| **策略模式** | 行为型 | 同一功能有多种算法实现，可动态切换 |
| **工厂方法** | 创建型 | 创建对象时不指定具体类 |
| **组合模式** | 结构型 | 统一处理整体和部分（如文件系统目录和文件） |
| **DAO模式** | 数据访问 | 分离数据访问逻辑和业务逻辑 |
| **MVC模式** | 架构型 | 分离界面(View)、逻辑(Controller)、数据(Model) |
# 设计原则与术语速查
> **用途**：考前快速回顾关键设计原则和术语
---
## 🔷 SOLID五大原则
| 原则 | 全称 | 含义 |
|------|------|------|
| **S** | 单一职责原则 | 一个类只负责一件事 |
| **O** | 开闭原则 | 对扩展开放，对修改关闭 |
| **L** | 里氏替换原则 | 子类可以替换父类而不出问题 |
| **I** | 接口隔离原则 | 接口要小而精，不要大而全 |
| **D** | 依赖倒置原则 | 依赖抽象（接口），不依赖具体实现 |
---
## 🔷 包设计四大原则
| 缩写 | 原则 | 含义 |
|------|------|------|
| **REP** | 重用等价原则 | 可一起复用的类放一个包 |
| **CCP** | 共同闭包原则 | 需要同时修改的类放一个包 |
| **CRP** | 共同重用原则 | 不会一起用的类分开放 |
| **ADP** | 非循环依赖原则 | 包之间的依赖不能形成环 |
---
## 🔷 其他重要原则
| 原则 | 含义 |
|------|------|
| **高内聚低耦合** | 包内关系紧密（内聚），包间关系稀疏（耦合） |
| **迪米特法则** | 最少知识原则——只跟"朋友"说话 |
| **组合优于继承** | 能用组合实现的效果，别用继承（更灵活） |
---
## 🔷 数据库三大范式
| 范式 | 要求 |
|------|------|
| **1NF** | 字段值不可再分（原子性） |
| **2NF** | 非主键字段完全依赖主键（消除部分依赖） |
| **3NF** | 非主键字段不传递依赖主键（消除传递依赖） |
---
## 🔷 对象模型→数据模型映射速查
| 对象模型 | 数据模型 |
|----------|----------|
| 类 | 表 |
| 属性 | 字段（列） |
| 操作 | 触发器 + 存储过程 |
| 1对0..*关联 | 多的一端加外键 |
| *对*关联 | 新建关联表 |
| 泛化关系 | 三种方案（父子各建表/只建子表/只建父表） |
---
## 🔷 需求工程术语速查
| 术语 | 定义 |
|------|------|
| **软件需求** | 用户对系统在功能、行为、性能、约束方面的期望 |
| **业务需求** | 组织的高层次目标 |
| **用户需求** | 用户使用系统完成的任务 |
| **功能需求** | 系统必须实现的功能 |
| **非功能需求** | 系统的质量属性和约束 |
| **SRS** | 软件需求规格说明书 |
| **需求基线** | 评审通过、双方承诺的需求版本 |
| **需求跟踪矩阵(RTM)** | 记录需求与设计、代码、测试对应关系的表 |
| **需求变更控制** | 变更申请→审批→修改→重新确认的流程 |
---
## 🔷 面向对象核心概念
| 概念 | 含义 |
|------|------|
| **封装** | 隐藏内部实现，只暴露接口 |
| **继承** | 子类自动拥有父类的属性和方法 |
| **多态** | 同一操作在不同对象上有不同行为 |
| **抽象** | 提取共性，忽略细节 |
---
## 🔷 关联关系多重性速记
| 符号 | 含义 |
|------|------|
| `1` | 恰好1个 |
| `0..1` | 0个或1个 |
| `*` 或 `0..*` | 0个或多个 |
| `1..*` | 至少1个 |
| `n` | 恰好n个 |
---
## 🔷 常见设计模式速查
| 模式 | 类型 | 解决什么问题 |
|------|------|-------------|
| **策略模式** | 行为型 | 同一功能有多种算法实现，可动态切换 |
| **工厂方法** | 创建型 | 创建对象时不指定具体类 |
| **组合模式** | 结构型 | 统一处理整体和部分（如文件系统目录和文件） |
| **DAO模式** | 数据访问 | 分离数据访问逻辑和业务逻辑 |
| **MVC模式** | 架构型 | 分离界面(View)、逻辑(Controller)、数据(Model) |