vault backup: 2026-07-03 23:22:28
This commit is contained in:
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -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)
|
||||
|
||||
Reference in New Issue
Block a user