diff --git a/1.md b/1.md
deleted file mode 100644
index e69de29..0000000
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..7408e39
--- /dev/null
+++ b/README.md
@@ -0,0 +1,85 @@
+# 📚 软件需求分析与设计 · 学习笔记
+
+> **课程**：软件需求分析与设计  
+> **教材参考**：UML系统建模与需求分析  
+> **适用对象**：软件工程专业学生 / 备考复习  
+> **整理时间**：2026年6月  
+
+---
+
+## 🎯 这本笔记是什么？
+
+这是一本**为期末考试和期中考试准备的复习笔记**，覆盖了课程的全部核心章节。
+
+**特点：**
+- 💬 **通俗讲解** — 用大白话解释核心概念，配合生活中的比喻
+- ✍️ **边学边练** — 每个知识点后面都有配套练习，答案折叠起来先想再看  
+- 📝 **章末自测** — 每章结束有一套模拟题，检验学习效果
+- 📊 **速查手册** — 各种UML图的对比表、设计原则汇总，考前过一遍
+
+---
+
+## 📂 笔记目录
+
+```
+学习笔记/
+├── README.md                    ← 你正在看
+├── 各章笔记/
+│   ├── 第01章-需求工程.md        ★★★★
+│   ├── 第03章-用例图.md          ★★★★★
+│   ├── 第04章-类图与对象图.md     ★★★★★
+│   ├── 第05章-顺序图与协作图.md   ★★★★
+│   ├── 第06章-状态图与活动图.md   ★★★★★
+│   ├── 第07章-组件图与部署图.md   ★★★
+│   ├── 第08章-包图.md            ★★
+│   ├── 第09章-数据建模.md         ★★★★
+│   └── 第11章-RUP统一过程.md      ★★★
+├── 期中复习/
+│   └── 期中复习指南.md
+├── 期末复习指南.md              ← 🆕 期末考试复习
+├── 课后习题汇编.md              ← 📝 全部课后习题合集
+└── 速查手册/
+    ├── UML九图速查.md
+    ├── 设计原则汇总.md
+    └── 术语速查表.md
+```
+
+> 星级表示考试重要程度，★★★★★ 是必考核心章节
+
+---
+
+## 🚀 建议学习路线
+
+### 路线一：按部就班（适合平时学习）
+按章节顺序读：**第1章 → 第3章 → 第4章 → 第5章 → 第6章 → 第7章 → 第8章 → 第9章 → 第11章**
+
+每章花 30-60 分钟，读完一节做一节的练习。
+
+### 路线二：考前突击（适合考前2-3天）
+1. 先看 **速查手册/UML九图速查.md** — 搞清楚9种图各自是干什么的
+2. 精读 **第3章（用例图）** 和 **第4章（类图）** — 这两章是核心中的核心
+3. 精读 **第6章（状态图与活动图）** — 期中必考
+4. 看 **期中复习** 里的7道大题 — 每题都搞懂
+5. 有时间再过第5章（顺序图）和第9章（数据建模）
+
+### 路线三：刷题为主（适合查缺补漏）
+1. 直接做每章的 **章末自测**
+2. 不会的题翻回去看对应章节
+3. 做 **期中复习** 的真题
+
+---
+
+## 🏷️ 符号说明
+
+| 符号 | 含义 |
+|------|------|
+| 💡 | 重要概念/核心理解 |
+| ⚠️ | 易错点/常见陷阱 |
+| ✍️ | 动手练习 |
+| 📝 | 章末自测题 |
+| 💬 | 通俗比喻/大白话解释 |
+| 🔑 | 记忆口诀 |
+
+---
+
+*本笔记用 Obsidian 打开效果最佳，支持双向链接。*
diff --git a/各章笔记/第01章-需求工程.md b/各章笔记/第01章-需求工程.md
new file mode 100644
index 0000000..10560c5
--- /dev/null
+++ b/各章笔记/第01章-需求工程.md
@@ -0,0 +1,271 @@
+# 第1章 需求工程
+
+> **考试重要度**：★★★★  
+> **核心内容**：需求的定义与层次、需求获取与分析技术、需求文档编写、需求管理
+
+---
+
+## 📢 开篇故事：一个失败的工资系统
+
+A公司从300人发展到5000人，原来的手工工资管理方式完全跟不上了。总经理李云找到技术主管王奇说：
+
+> "我们急需一个新工资系统！员工自己登记时间卡，系统自动算工资，五个月搞定，明白吗？"
+
+王奇说："能不能再详细说说？比如有哪些角色用这个系统？每类人需要什么功能？数据怎么流转？"
+
+李云不耐烦："我不就是用户吗？你们自己看着办不就行了？"
+
+💬 **这个故事告诉我们什么？**
+
+1. **老板 ≠ 用户**。老板说的是"业务需求"（高层次目标），但不是具体"用户需求"。
+2. **需求不是想当然的**。开发人员不能凭空猜测用户要什么。
+3. **不同角色有不同需求**。出纳、会计、财务主管、普通员工——每个人要的功能都不一样。
+4. **需求需要花时间获取**。反复沟通、深入调查，急不得。
+
+---
+
+## 💡 一、什么是软件需求？
+
+> **一句话定义**：需求就是用户对软件系统"应该做什么"和"应该做到什么程度"的期望。
+
+### 三个权威定义
+
+| 来源 | 定义 |
+|------|------|
+| **IEEE** | 用户解决问题所需的**条件或能力**；系统必须满足的**约束**；上述内容的**文档化表达** |
+| **Davis** | 从软件外部可见的、满足用户的**特点、功能及属性**的集合 |
+| **Sommerville** | 问题信息与系统**行为、特性、设计和实现约束**的描述集合 |
+
+💬 **大白话**：需求就是三件事——**做什么功能**、**做到什么标准**、**有什么限制**。
+
+---
+
+## 💡 二、需求的三个层次
+
+这是考试的重点！需求像一座三层金字塔：
+
+```
+        ┌──────────────┐
+        │  业务需求     │  ← 老板视角："我们要什么"
+        │  Business     │
+        ├──────────────┤
+        │  用户需求     │  ← 用户视角："我能用它干什么"
+        │  User         │
+        ├──────────────┤
+        │  系统需求     │  ← 开发者视角："具体怎么实现"
+        │  System       │
+        └──────────────┘
+```
+
+| 层次 | 说明 | 举例（工资系统） |
+|------|------|------------------|
+| **业务需求** | 组织的高层次目标，回答"为什么要做这个系统" | "用计算机替代手工工资管理，五个月上线" |
+| **用户需求** | 用户使用系统完成的任务，回答"用户能干什么" | "财务人员可以录入员工时间卡信息" |
+| **系统需求** | 开发人员要实现的具体功能和约束，回答"系统必须做到什么" | "系统自动根据工时和销售额计算工资单" |
+
+### 系统需求又分三类
+
+| 类型 | 说明 | 举例 |
+|------|------|------|
+| **功能需求** | 系统必须提供的功能 | 录入时间卡、计算工资、生成工资单 |
+| **非功能需求** | 系统的质量属性和约束 | 工资计算5秒内完成、数据不能丢失 |
+| **领域需求** | 行业特有的要求 | 遵循《中国图书馆分类法》编目图书 |
+
+---
+
+## ✍️ 边学边练（一）
+
+**题目**：下面哪一个是正确的需求层次顺序（从高到低）？
+
+A. 用户需求 → 业务需求 → 系统需求  
+B. 业务需求 → 用户需求 → 系统需求  
+C. 用户需求 → 系统需求 → 业务需求  
+D. 业务需求 → 系统需求 → 用户需求
+
+**答案：**
+**正确答案：B**
+
+记住口诀：**"老板定方向（业务），用户说任务（用户），开发写代码（系统）"**，从抽象到具体。
+
+---
+
+## 💡 三、需求为什么重要？
+
+### 数据说话
+
+| 成功因素 | 占比 | 失败因素 | 占比 |
+|----------|------|----------|------|
+| 用户参与 | **15.9%** | 需求不完善 | **13.1%** |
+| 管理层支持 | 13.9% | 缺乏用户参与 | 12.4% |
+| 清晰的需求 | 13.0% | 资源不足 | 10.6% |
+
+💬 **一句话**：需求的锅是最大的锅。需求搞错了，后面全白做。
+
+### 五个常见需求败因
+
+1. **需求不完整** — 只问了领导，没问实际操作的人
+2. **缺乏用户参与** — 用户觉得"我不懂技术，你们自己弄"
+3. **不切实际的期望** — "10年内每天24小时100%可用"（技术上做不到）
+4. **需求变更频繁** — 今天加一个，明天改一个，后天不要了
+5. **做了没人用的功能** — 开发了很多功能，实际使用率极低
+
+---
+
+## 💡 四、需求工程的核心流程
+
+> **需求工程** = 所有跟需求有关的活动，分成"开发"和"管理"两大类。
+
+```
+需求开发（做对需求）：  获取 → 分析 → 定义（写文档）
+需求管理（管好需求）：  验证 → 跟踪 → 变更控制
+```
+
+### ① 需求获取 — 怎么收集需求？
+
+💬 **打个比方**：需求获取就像医生问诊——你不会直接让病人给自己开药，而是通过望闻问切来了解病情。
+
+**六大获取技术**：
+
+| 技术 | 怎么做 | 适用场景 |
+|------|--------|----------|
+| **联合分析小组** | 用户 + 领域专家 + 分析员坐在一起 | 大型复杂项目 |
+| **用户访谈** | 一对一或小组面谈 | 深入了解具体业务 |
+| **问卷调查** | 发放问卷收集大量反馈 | 用户分散、人数多 |
+| **观察工作流程** | 到现场看用户怎么干活 | 发现"隐形的需求" |
+| **原型法** | 做个简单的界面模型给用户试用 | 用户说不清楚自己要什么 |
+| **文档分析** | 研究现有的规章制度、报表等 | 理解业务规则 |
+
+⚠️ **关键认知**：很多需求是**隐形的**——用户觉得"这还用说吗"，但实际上不说就不会被实现。所以要主动挖掘。
+
+### ② 需求分析 — 怎么理清需求？
+
+两种基本方法：
+
+| 方法 | 核心思想 | 使用的图 |
+|------|----------|----------|
+| **结构化分析 (SA)** | 把大问题分解成小问题，逐层细化 | DFD数据流图、ER图、状态转换图 |
+| **面向对象分析 (OOA)** | 基于用例，用对象来组织系统 | 用例图、类图、顺序图等UML图 |
+
+💬 **SA像切蛋糕**：一层层切，直到每一块都能一口吃掉。  
+💬 **OOA像拼乐高**：先找到有哪些"积木块"（类），再定义他们怎么拼在一起（关系）。
+
+### ③ 需求定义 — 写需求文档
+
+**两份核心文档**：
+
+| 文档 | 谁看 | 用什么语言 | 什么程度 |
+|------|------|------------|----------|
+| **用户需求说明书** | 用户审核 | 自然语言+业务术语 | 比较粗略 |
+| **软件需求规格说明书(SRS)** | 开发团队 | 技术语言+图形模型 | 非常详细 |
+
+💬 **区别**：用户需求说明书像"装修意向书"（我要北欧风、三室两厅），SRS像"施工图"（客厅长5米宽4米，插座位置距地30cm）。
+
+### 🔑 优秀需求的七个标准
+
+| 标准 | 含义 |
+|------|------|
+| **完整性** | 所有功能都说清楚了，不缺项 |
+| **正确性** | 描述的功能确实是用户要的 |
+| **无歧义** | 所有人读出来是同一个意思（别用"可能""差不多"） |
+| **可行性** | 技术上能做、预算内能做 |
+| **有优先级** | 分清楚哪些先做、哪些后做 |
+| **必要性** | 每个需求都有存在的理由 |
+| **可验证性** | 能通过测试来确认是否实现了 |
+
+### ④ 需求验证 — 怎么确认需求是对的？
+
+**验证什么**：
+- ✅ 有效性：写的功能是不是用户真实需要的
+- ✅ 一致性：有没有前后矛盾的描述
+- ✅ 完备性：有没有漏掉的需求
+- ✅ 可检验性：能不能设计测试来验证
+
+**主要方法**：**需求评审** — 开发方和客户方一起逐条审查，签字确认后形成"需求基线"。
+
+### ⑤ 需求跟踪
+
+**双向跟踪**：
+- **正向跟踪**：需求 → 设计 → 代码 → 测试，确保每个需求都有实现
+- **逆向跟踪**：代码 → 设计 → 需求，确保每一行代码都有需求来源
+
+### ⑥ 需求变更控制
+
+💬 **需求变更像改装修方案**——墙都砌好了你说要拆？不是不行，但要评估影响、调整预算、重新排期。
+
+**变更控制流程**：`提出变更 → 评审影响 → 审批 → 修改 → 重新确认`
+
+---
+
+## ✍️ 边学边练（二）
+
+**题目**：图书馆系统有以下描述，请区分功能需求、非功能需求和领域需求。
+
+1. 系统要能实现图书借阅和归还的登记
+2. 每次借书登记必须在1秒内完成
+3. 图书编目要遵循《中国图书馆分类法》
+4. 借书登记出错率不超过万分之一
+5. 某些文献只能在阅览室阅读，不能外借
+
+**答案：**
+- ① **功能需求** — 描述系统要做什么（借阅登记、归还登记）
+- ② **非功能需求（性能）** — 描述系统要做到什么程度（1秒内）
+- ③ **领域需求** — 行业特有的规则约束
+- ④ **非功能需求（可靠性）** — 错误率的量化指标
+- ⑤ **领域需求** — 版权法对图书馆业务的特殊约束
+
+⚠️ **易错点**：区分功能需求和非功能需求的关键在于——**功能需求说"做什么"，非功能需求说"做多好"**。
+
+---
+
+## 📝 章末自测
+
+**1. 填空题**
+- 需求的三个层次从高到低依次是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
+- 优秀需求的七个特性中，"所有人读出来是同一个意思"指的是（ ___ ）（ ___ ）性
+- 结构化分析的三个模型是：功能模型（DFD）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
+
+**2. 简答题**
+- 简述"用户需求说明书"和"软件需求规格说明书(SRS)"的区别。
+- 结构化分析(SA)和面向对象分析(OOA)的核心区别是什么？
+
+**3. 应用题**
+- 某在线购物系统，请分别写出一条：业务需求、用户需求、功能需求、非功能需求。
+
+**答案：**
+**填空题答案**：
+- 业务需求、用户需求、系统需求
+- 无歧义性
+- 数据模型（ER图）、行为模型（状态转换图）
+
+**简答题答案**：
+- 用户需求说明书用自然语言+业务术语描述，内容粗略，给用户审核用；SRS用技术语言+图形描述，内容精细，是开发的直接依据。
+- SA把系统按功能层层分解，用DFD、ER图等；OOA基于用例识别对象，用UML图来描述，是目前的主流方法。
+
+**应用题参考答案**：
+- 业务需求："建立一个在线购物平台，提升销售额30%"
+- 用户需求："注册用户可以浏览商品、加入购物车、下单支付"
+- 功能需求："系统应提供商品搜索功能，支持按名称、类别、价格范围筛选"
+- 非功能需求："页面加载时间不超过3秒，支持1000人同时在线"
+
+---
+
+## 📘 真题演练
+
+**题目**（教材课后习题）：下列哪些是需求获取的技术？（多选）
+
+A. 用户访谈  
+B. 代码走查  
+C. 问卷调查  
+D. 原型法  
+E. 观察用户工作流程  
+F. 单元测试
+
+**答案：**
+**正确答案：A、C、D、E**
+
+B（代码走查）和F（单元测试）属于开发/测试阶段的活动，不是需求获取技术。
+
+需求获取的六大技术：联合分析小组、用户访谈、问卷调查、观察工作流程、原型法、文档分析。
+
+---
+> 🔗 下一篇：[第3章 用例图](第03章-用例图.md)
diff --git a/各章笔记/第03章-用例图.md b/各章笔记/第03章-用例图.md
new file mode 100644
index 0000000..cb9c6b9
--- /dev/null
+++ b/各章笔记/第03章-用例图.md
@@ -0,0 +1,276 @@
+# 第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)
diff --git a/各章笔记/第04章-类图与对象图.md b/各章笔记/第04章-类图与对象图.md
new file mode 100644
index 0000000..85fc61b
--- /dev/null
+++ b/各章笔记/第04章-类图与对象图.md
@@ -0,0 +1,250 @@
+# 第4章 类图与对象图
+
+> **考试重要度**：★★★★★  
+> **核心内容**：类与对象的识别、六大类关系、抽象类与接口、边界类/控制类/实体类
+
+---
+
+## 📢 从生活中理解类和对象
+
+💬 **类 = 模板，对象 = 具体的东西。**
+
+| 概念 | 生活例子 | 代码例子 |
+|------|----------|----------|
+| **类** | "汽车"这个类别 | `class Car` |
+| **对象** | 你家楼下停的那辆红色宝马 | `Car myCar = new Car()` |
+| **属性** | 颜色、车牌号、排量 | `color`, `plateNumber` |
+| **操作** | 启动、加速、刹车 | `start()`, `accelerate()` |
+
+> 例：银行的"账户"类有属性（姓名、密码、余额）和操作（查询余额、存款、取款）。张三的账户就是一个具体对象，余额是5000元。
+
+---
+
+## 💡 一、类的三格表示法
+
+```
+┌──────────────────────┐
+│   类名               │  ← 第一格：类名
+├──────────────────────┤
+│   -name: String      │  ← 第二格：属性
+│   -age: int          │
+│   +count: int        │
+├──────────────────────┤
+│   +getName(): String │  ← 第三格：操作（方法）
+│   +setAge(a: int)    │
+└──────────────────────┘
+```
+
+### 属性语法
+
+```
+[可见性] 属性名 [:类型] [=初始值] [{约束}]
+```
+
+### 可见性符号
+
+| 符号 | 名称 | 含义 |
+|------|------|------|
+| `+` | Public（公有） | 谁都能访问 |
+| `-` | Private（私有） | 只能类内部访问 |
+| `#` | Protected（受保护） | 类内部+子类能访问 |
+
+---
+
+## ✍️ 边学边练（一）
+
+**题目**：银行账户类Account有属性：账号(私有)、密码(私有)、余额(私有)、利率(公有)。请用UML类图的三格表示法写出。
+
+**答案：**
+```
+┌──────────────────────┐
+│      Account         │
+├──────────────────────┤
+│  -accountNo: String  │
+│  -password: String   │
+│  -balance: double    │
+│  +interestRate: float│
+├──────────────────────┤
+│  +getBalance():double│
+│  +deposit(amt)       │
+│  +withdraw(amt)      │
+└──────────────────────┘
+```
+
+---
+
+## 💡 二、类之间的六大关系（重中之重！必考！）
+
+### 1. 关联关系（Association）—— "认识/拥有"
+
+> **含义**：一个类的属性类型是另一个类。这是最基础的关系。
+
+💬 **比喻**：员工"属于"某个部门——Employee类中有一个Department类型的属性。
+
+**关联关系的子类型**：
+
+| 子类型 | 说明 | 生存期 | 画法 |
+|--------|------|--------|------|
+| **普通关联** | 平等关系 | 各自独立 | 实线 |
+| **聚合（Aggregation）** | 整体-部分，弱关系 | 部分可独立存在 | 空心菱形 |
+| **组合（Composition）** | 整体-部分，强关系 | 部分随整体消亡 | 实心菱形 |
+
+💬 **聚合 vs 组合**：
+- 聚合：学校由学生组成，学校解散了，**学生还在**。
+- 组合：汽车由发动机组成，汽车报废了，**发动机也没意义了**。
+
+### 2. 依赖关系（Dependency）—— "临时使用"
+
+> **含义**：一个类的方法的参数/返回值/局部变量用了另一个类。
+
+💬 **比喻**：你去商店买东西——你跟商店的关系只在买东西那一刻存在，买完就没关系了。
+
+### 3. 泛化关系（Generalization）—— "是……的一种"
+
+> **含义**：子类继承父类的属性和方法。
+
+💬 **比喻**：狗是动物的一种——狗继承了动物的所有特征，还有自己特有的"汪汪叫"。
+
+### 4. 实现关系（Realization）—— "履行接口约定"
+
+> **含义**：类实现了接口中定义的所有方法。
+
+### 关联 vs 依赖 对比
+
+| 维度 | 关联 | 依赖 |
+|------|------|------|
+| **强度** | 强，长期稳定 | 弱，临时短暂 |
+| **代码体现** | 属性类型是另一个类 | 方法参数/局部变量用了另一个类 |
+| **生命周期** | 对象存在就有关系 | 方法调用结束关系就结束 |
+| **画法** | 实线 | 虚线箭头 |
+
+---
+
+## ✍️ 边学边练（二）
+
+**题目**：判断以下场景属于什么关系。
+
+1. 飞机由机翼、发动机、机身组成。（飞机-机翼）
+2. 医生在医院工作。（医生-医院）
+3. 学生是人。（学生-人）
+4. 程序员写代码时用到开发工具。（程序员-开发工具）
+
+**答案：**
+1. **组合关系**（实心菱形）—— 机翼不能脱离飞机独立存在
+2. **关联关系**（普通关联）—— 医生有"所属医院"这个属性
+3. **泛化关系**（继承）—— 学生是人的子类
+4. **依赖关系**（虚线箭头）—— 程序员"写代码"这个方法用到了开发工具，但不是长期持有
+
+⚠️ **易错点**：聚合和组合都表示"整体-部分"，区别在于部分能否独立存在。能独立=聚合，不能独立=组合。
+
+---
+
+## 💡 三、关联关系的重要概念
+
+### 多重性
+
+| 表示法 | 含义 |
+|--------|------|
+| `1` | 恰好1个 |
+| `0..1` | 0个或1个 |
+| `0..*` 或 `*` | 0个或多个 |
+| `1..*` | 至少1个 |
+| `n..m` | n到m个 |
+
+> 例：一个学生选**0..\***门课，一门课被**1..\***个学生选。
+
+### 关联类
+
+> 当一个属性放在哪个类都不合适时，就用关联类。
+
+💬 例：员工和公司之间有个"合同"——合同有"工资"属性。工资既不是员工的固有属性（换公司会变），也不是公司的固有属性。所以"合同"是一个关联类。
+
+### 限定关联
+
+> 用限定符把多对多变成一对多，提高查询效率。
+
+💬 例：一个人可以在多家银行开户（多对多）。但如果限定"在某家银行"，就变成一对多了。
+
+---
+
+## 💡 四、抽象类 vs 接口
+
+| 维度 | 抽象类 | 接口 |
+|------|--------|------|
+| **属性** | 可以有 | 不能有 |
+| **方法实现** | 部分方法有实现 | 所有方法都没有实现 |
+| **关系** | 子类继承（泛化） | 类实现（实现关系） |
+| **多重性** | 只能继承一个 | 可以实现多个 |
+| **关键词** | `abstract class` | `interface` |
+
+💬 **比喻**：抽象类像"半成品家具"（有些部分做好了，有些需要你自己完成）；接口像"插座标准"（只规定了插孔形状和电压，具体怎么发电不管）。
+
+---
+
+## 💡 五、版型：边界类、控制类、实体类
+
+这是MVC模式的UML体现，期中考试经常考！
+
+| 版型 | 职责 | 常见形式 | 对应MVC |
+|------|------|----------|---------|
+| **边界类** <<boundary>> | 与外界交互 | 窗口、对话框、报表 | View |
+| **控制类** <<control>> | 协调业务逻辑 | 处理业务规则 | Controller |
+| **实体类** <<entity>> | 持久化数据 | 数据库表对应的类 | Model |
+
+🔑 **协作关系**：边界类接收用户输入 → 控制类处理业务逻辑 → 实体类存取数据。
+
+---
+
+## ✍️ 边学边练（三）
+
+**题目**：在线购物系统中，"用户"通过"购物页面"下单，系统"订单处理"模块检查库存后，更新"订单"数据和"库存"数据。请指出各属于哪种版型。
+
+**答案：**
+- 购物页面 → **边界类**（与用户交互）
+- 订单处理模块 → **控制类**（协调业务逻辑）
+- 订单、库存 → **实体类**（持久化的数据）
+
+完整流程：边界类("购物页面") → 控制类("订单处理") → 实体类("订单""库存")
+
+---
+
+## 💡 六、对象图
+
+> **对象图 = 类图的"截图"**。类图描述通用规则，对象图描述某一时刻的具体情况。
+
+| 类图 | 对象图 |
+|------|--------|
+| 三个格子（类名+属性+操作） | 两个格子（对象名:类名 + 属性值） |
+| 描述所有可能的情况 | 描述某一个时刻的快照 |
+| 属性定义特征（如"姓名: String"） | 属性有具体值（如"姓名 = 张三"） |
+
+💬 **比喻**：类图像"菜单"（描述菜的做法），对象图像"上桌的菜"（一份具体的菜）。
+
+---
+
+## 📝 章末自测
+
+**1. 填空题**
+- 聚合关系中，整体不存在了，部分（ ___ ）（ ___ ）存在。（能/不能）
+- 组合关系中，整体不存在了，部分（ ___ ）（ ___ ）存在。（能/不能）
+- 边界类、控制类、实体类分别对应MVC中的（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
+
+**2. 判断题**
+- ( ) 依赖关系比关联关系更弱
+- ( ) 接口可以有属性
+- ( ) 抽象类可以被实例化
+- ( ) 对象图是类图的实例
+- ( ) 一个类只能继承一个抽象类，但可以实现多个接口
+
+**3. 分析题**
+- 职工类Employee包含属性empcode、name、address、birthday。Address类包含houseNumber、streetNumber、city、zipcode。分析两个类之间的关系。
+
+**答案：**
+**填空题**：能、不能、View、Controller、Model
+
+**判断题**：✅ ❌(接口无属性) ❌(抽象类不能实例化) ✅ ✅
+
+**分析题**：**关联关系**。因为Employee类中有一个属性address，其类型是Address类。这是一个长期稳定的结构关系。多重性：Employee端1，Address端0..*（一个地址可以被多个员工使用）。
+
+---
+> 🔗 上一篇：[第3章 用例图](第03章-用例图.md) | 下一篇：[第5章 顺序图与协作图](第05章-顺序图与协作图.md)
diff --git a/各章笔记/第05章-顺序图与协作图.md b/各章笔记/第05章-顺序图与协作图.md
new file mode 100644
index 0000000..5cb913b
--- /dev/null
+++ b/各章笔记/第05章-顺序图与协作图.md
@@ -0,0 +1,223 @@
+# 第5章 顺序图与协作图
+
+> **考试重要度**：★★★★  
+> **核心内容**：顺序图的四个核心元素、六种消息类型、调用消息vs异步消息、顺序图与协作图的对比
+
+---
+
+## 📢 从打电话理解交互图
+
+💬 你打电话给朋友借钱，整个对话过程是这样的：
+
+```
+你 → 拨号 → 朋友接电话 → 你说"借我500" → 朋友说"好" → 你挂电话
+```
+
+这就是一个**交互过程**——两个对象之间按时间顺序传递消息。在UML中，我们用**顺序图**和**协作图**来描述这个过程。
+
+---
+
+## 💡 一、顺序图的四个核心元素
+
+```
+┌─────────────────────────────────────────────┐
+│  对象          生命线         控制焦点(激活期)   │
+│  ┌───┐        │              ┌──┐             │
+│  │obj│        │              │  │             │
+│  └─┬─┘        │              └──┘             │
+│    │- - - - - │- - - - - - - - - - -         │
+│    │          │ 消息→                         │
+│    │          │              ┌──┐             │
+│    │          │              │  │             │
+│    │          │              └──┘             │
+└─────────────────────────────────────────────┘
+```
+
+| 元素 | 说明 | 画法 |
+|------|------|------|
+| **对象** | 类的实例，参与交互的实体 | 矩形，顶部放置 |
+| **生命线** | 对象存在的时间线 | 从对象向下延伸的虚线 |
+| **控制焦点**（激活期） | 对象正在执行操作的时间段 | 生命线上的细长矩形条 |
+| **消息** | 对象之间的一次通信 | 带箭头的直线 |
+
+---
+
+## 💡 二、消息的语法格式
+
+消息的完整格式：
+
+```
+[前置条件] [警戒条件] [序号] [返回值:=] 消息名([参数列表])
+```
+
+例子：
+```
+2: display(x, y)              → 简单消息，序号2
+1.3.1: p := find(specs)      → 嵌套消息，有返回值
+[x<0] 4: invert(x, color)    → 条件消息
+3.1*: update()               → 循环消息
+```
+
+### 消息序号的含义
+
+- `1, 2, 3` — 顺序发送的消息
+- `1.1, 1.2, 1.3` — 消息1内部的嵌套调用（1.1必须在1完成之前完成）
+- `A1, B1` — 并发线程中的消息
+
+---
+
+## 💡 三、六种消息类型
+
+| 消息类型 | 说明 | 画法 |
+|----------|------|------|
+| **调用消息** (同步) | 发送者等待接收者完成才继续 | 实线实心箭头 → |
+| **异步消息** | 发送者不等待，继续执行 | 实线开放箭头 ⇢ |
+| **返回消息** | 从调用返回 | 虚线开放箭头 ⇢ |
+| **反身消息** | 发给自己 | 绕回自己的箭头 |
+| **阻止消息** | 接收者不能立即接收就放弃 | 特殊标记 |
+| **超时消息** | 等待指定时间，超时就放弃 | 特殊标记 |
+
+---
+
+## 🔑 调用消息 vs 异步消息（必考！）
+
+| 对比维度 | 调用消息 | 异步消息 |
+|----------|----------|----------|
+| **发送者行为** | 发出后**停下来等** | 发出后**继续干活** |
+| **控制焦点** | 发送者出现等待（重叠矩形条） | 发送者不等待 |
+| **典型场景** | 查询数据库（必须等结果） | 写日志文件（可以后台进行） |
+| **返回消息** | 必有返回，可以省略不画 | 如果是过程调用必有返回 |
+
+💬 **比喻**：
+- 调用消息像**打电话**——你说一句，等对方回一句。
+- 异步消息像**发微信**——你发一条，继续干自己的事，对方看到再回。
+
+---
+
+## 💡 四、顺序图的两种形式
+
+| 形式 | 说明 |
+|------|------|
+| **一般形式** | 包含条件、分支、循环，描述所有可能的场景 |
+| **实例形式** | 只有一个具体的场景，没有任何分支和循环 |
+
+💬 例：取款的一般形式包含"余额够"和"余额不够"两个分支；而某次具体取款（余额够）就是实例形式。
+
+### 条件消息和循环消息的表达
+
+**两种方法**：
+1. 在消息上直接标注：`[x>0] 3: doSomething()` 或 `2.1*: update()`
+2. 使用交互架构（框选一个区域，标注`loop`或`alt`）
+
+---
+
+## 💡 五、协作图
+
+### 协作图 vs 顺序图
+
+| 维度 | 顺序图 | 协作图 |
+|------|--------|--------|
+| **强调** | **时间顺序** | **空间位置关系** |
+| **生命线** | 有（从上到下） | 无 |
+| **控制焦点** | 有（矩形条） | 无 |
+| **消息序号** | 通常简化 | 必须完整标注 |
+| **多对象** | 不直观 | 可以表达 |
+| **主动对象** | 不直观 | 可以表达 |
+
+🔑 **核心区别**：顺序图强调"什么时间谁调用了谁"，协作图强调"谁跟谁有连接关系"。
+
+### 协作图的特殊元素
+
+| 元素 | 说明 |
+|------|------|
+| **多对象** | 代表一组对象，发给它的消息是发给整个集合 |
+| **主动对象** | 拥有自己控制线程的对象，可以主动发起消息 |
+| **{new}** | 标记对象在交互中被创建 |
+| **{destroy}** | 标记对象在交互中被销毁 |
+
+---
+
+## ✍️ 边学边练（一）
+
+**题目**：ATM取款的基本流程如下，请画出分析阶段的顺序图。
+
+1. 用户输入取款金额
+2. 系统判断账户余额是否足额
+3. 若足额，则出钞并修改账户余额
+4. 若不足额，则取款失败
+
+**答案：**
+顺序图包含对象：`:客户`、`:ATM界面`、`:账户`
+
+消息序列：
+```
+1. 客户 → ATM界面: 输入金额(amount)
+2. ATM界面 → 账户: 查询余额()
+3. 账户 → ATM界面: 返回余额(balance)
+4. ATM界面 → 自己: [balance>=amount]判断
+5a. ATM界面 → 账户: 扣款(amount) [金额足够]
+5b. ATM界面 → 客户: 显示"余额不足" [金额不足]
+```
+
+⚠️ 关键：步骤4的判断是ATM界面对象自己的处理，用反身消息或不画都可以。
+
+---
+
+## ✍️ 边学边练（二）
+
+**题目**：判断以下场景应该用调用消息还是异步消息。
+
+1. 用户点击"登录"按钮，系统验证用户名密码
+2. 用户上传文件后，系统后台写入日志
+3. 用户查询订单列表，系统返回查询结果
+4. 系统给所有订阅用户发送邮件通知
+
+**答案：**
+1. **调用消息（同步）**—— 必须等验证结果，用户才能进入下一步
+2. **异步消息**—— 写日志不阻塞用户操作
+3. **调用消息（同步）**—— 必须等返回结果才能显示
+4. **异步消息**—— 发邮件是批量后台操作，不需要等待
+
+🔑 **判断标准**：发送者是否**必须等待**结果才能继续。必须等=调用消息，不必等=异步消息。
+
+---
+
+## 💡 六、交互建模的步骤
+
+1. 根据一个用例的用例描述，找出**基本事件流**和**可选事件流**
+2. 确定参与交互的**对象**（参考类图）
+3. 按事件流的**先后次序**确定消息发送次序
+4. 标注需要**创建**和**撤销**的对象
+5. 处理**循环**和**分支**消息
+
+---
+
+## 📝 章末自测
+
+**1. 填空题**
+- 顺序图的四个核心元素是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
+- 发送后等待返回的消息叫（ ___ ）（ ___ ）消息，发送后继续执行的消息叫（ ___ ）（ ___ ）消息
+- 顺序图强调（ ___ ）（ ___ ）顺序，协作图强调（ ___ ）（ ___ ）关系
+
+**2. 判断题**
+- ( ) 调用消息的返回消息必须画出来
+- ( ) 顺序图可以表示对象的创建和销毁
+- ( ) 协作图中消息序号1.1表示它在消息1完成后才开始
+
+**3. 简答题**
+- 顺序图和协作图各有什么优势和适用场景？
+
+**答案：**
+**填空题**：对象、生命线、控制焦点、消息；调用（同步）、异步；时间、空间位置
+
+**判断题**：
+- ❌ 调用消息的返回消息可以省略不画（隐式）
+- ✅ 对象顶部放置={new}，虚线末端×={destroy}
+- ❌ 消息1.1在消息1**完成之前**就必须完成（嵌套含义）
+
+**简答题**：
+- 顺序图：适合展示按时间顺序发生的消息交互，直观易懂，适合分析单个用例的执行流程
+- 协作图：适合展示对象之间的静态连接关系，能表达多对象和并发，适合整体架构分析
+
+---
+> 🔗 上一篇：[第4章 类图与对象图](第04章-类图与对象图.md) | 下一篇：[第6章 状态图与活动图](第06章-状态图与活动图.md)
diff --git a/各章笔记/第06章-状态图与活动图.md b/各章笔记/第06章-状态图与活动图.md
new file mode 100644
index 0000000..ce5d992
--- /dev/null
+++ b/各章笔记/第06章-状态图与活动图.md
@@ -0,0 +1,218 @@
+# 第6章 状态图与活动图
+
+> **考试重要度**：★★★★★  
+> **核心内容**：状态图的组成（状态/转移/事件）、四种事件类型、活动图元素（泳道/分支/分叉汇合）、状态vs活动的区别
+
+---
+
+## 📢 从手机理解状态图和活动图
+
+💬 你的手机有以下**状态**：闲置 → 解锁 → 使用中 → 锁屏 → 闲置。
+
+每个状态之间的切换需要**事件**触发：点击屏幕、输入密码、按电源键……
+
+这就是**状态图**——描述**一个对象**在生命周期内的状态变化。
+
+而**活动图**描述的是**一个流程**：比如"打电话"这个活动——打开拨号盘 → 输入号码 → 点击拨号 → 通话 → 挂断。这其中可能涉及多个对象。
+
+---
+
+## 💡 一、状态图的核心元素
+
+### 状态图三要素
+
+```
+    ┌──────────┐  事件[条件]/动作   ┌──────────┐
+    │  状态A   │ ─────────────────→  │  状态B   │
+    └──────────┘                    └──────────┘
+```
+
+| 要素 | 说明 |
+|------|------|
+| **状态** | 对象在某个时刻所处的条件或状况 |
+| **转移** | 从一个状态到另一个状态的变化 |
+| **事件** | 触发状态转移的原因 |
+
+### 状态的组成
+
+```
+┌────────────────────────┐
+│       状态名            │
+├────────────────────────┤
+│  entry / 入口动作      │
+│  exit / 出口动作       │
+│  do / 持续活动         │
+│  内部转移（不离开状态）  │
+└────────────────────────┘
+```
+
+### 组合状态和历史状态
+
+💬 **组合状态**：一个大状态里面还有小状态的变化过程。
+
+> 例：汽车"行驶"状态里面还有子状态：加速、匀速、减速。
+
+💬 **历史状态**：记住离开组合状态时处于哪个子状态，回来后可以接着来。
+
+> 例：数据备份——中途被打断，恢复后可以继续从断点备份。
+
+---
+
+## 💡 二、四种事件类型
+
+| 事件类型 | 含义 | 举例 |
+|----------|------|------|
+| **调用事件** | 一个方法的调用 | `借书()` → 借书证从"可借"变为"不可借" |
+| **信号事件** | 一个异步发送的信号实体 | 遥控器发出"Play"信号 → CD机进入"播放"状态 |
+| **变化事件** | 布尔表达式值发生变化 | 温度>100℃ → 锅炉进入"报警"状态 |
+| **时间事件** | 到达某个时间点或时间段 | 30秒超时 → 从"拨号"回到"就绪" |
+
+### 🔑 调用事件 vs 信号事件
+
+| 对比 | 调用事件 | 信号事件 |
+|------|----------|----------|
+| **本质** | 调用一个方法 | 发送一个信号对象 |
+| **发送方** | 可以是自己或其他对象 | 只能是其他对象 |
+| **特点** | 可扩展性弱 | 信号类可泛化，扩展性强 |
+
+💬 例：CD唱机——如果各种遥控信号作为遥控器的属性（变化事件），增加新信号就要修改遥控器类。如果把遥控信号建模为信号类（信号事件），增加新信号只需新增子类，不用改遥控器。
+
+---
+
+## ✍️ 边学边练（一）
+
+**题目**：画出"图书"对象的状态图。
+
+需求：新书购买后需编码才能入库。入库后可借出。借出的书不能被再借出。还书后可再借出。图书破损或过时必须下架，下架后不能再借出。
+
+**答案：**
+**状态**：未编码 → 可借(在库) → 已借出 → 可借(在库) → 已下架
+
+**转移**：
+- 未编码 → 可借：`编码()` 
+- 可借 → 已借出：`借出()`
+- 已借出 → 可借：`还书()`
+- 可借 → 已下架：`下架()` [破损或过时]
+- 已借出 → 已下架：`下架()` [破损或过时]
+
+⚠️ 注意：状态图中有两个状态必须有"下架"转移（从可借和已借出都可以下架）。
+
+---
+
+## 💡 三、活动图的核心元素
+
+### 活动图的基本元素
+
+| 元素 | 说明 | 画法 |
+|------|------|------|
+| **活动** | 一个执行步骤 | 圆角矩形 |
+| **起点** | 流程的开始 | 实心圆 ● |
+| **终点** | 流程的结束 | 圆圈加实心圆 ⊙ |
+| **分支** | 根据条件选择路径 | 菱形 ◇ |
+| **分叉/汇合** | 并发执行的开始/结束 | 粗横线 |
+| **泳道** | 标明活动由谁负责 | 纵向分区 |
+| **对象流** | 活动之间传递的对象 | 带箭头的虚线 |
+
+### 🔑 状态 vs 活动（必考区别！）
+
+| 对比 | 状态 | 活动 |
+|------|------|------|
+| **本质** | 对象所处的**境况** | 一段程序代码的**执行过程** |
+| **持续时间** | 可以很长（等待状态） | 相对短暂（执行完就结束） |
+| **关系** | 是活动执行后的**结果** | 是导致状态变化的**原因** |
+| **关注对象** | 一个对象 | 可以涉及多个对象 |
+| **UML图** | 状态图 | 活动图 |
+
+💬 **比喻**：做菜的过程（洗菜→切菜→炒菜→装盘）是**活动**；菜做完了变成"已做好"是**状态**。
+
+### 活动图的两种用途
+
+1. **对业务流程建模**（不带泳道）—— 用于需求分析，描述用例的工作流程
+2. **对系统操作建模**（带泳道）—— 用于系统设计，把步骤落实到具体对象
+
+---
+
+## ✍️ 边学边练（二）
+
+**题目**：画出"借书"用例的带泳道活动图。
+
+流程：图书管理员录入图书条码和借书证号 → 系统判断借书证能否借书 → 若不能，显示原因并结束 → 若能，生成借阅记录，修改可借本数。
+
+**答案：**
+**泳道划分**：图书管理员 | 系统
+
+```
+图书管理员泳道：
+  录入条码和借书证号 → 
+系统泳道：
+  判断能否借书 → [不能] → 显示原因 → 结束
+                → [能] → 生成借阅记录 → 修改可借本数 → 结束
+```
+
+⚠️ 关键：分叉用菱形，两个分支最终汇合到结束。
+
+---
+
+## 💡 四、状态/活动与用例/方法的关系
+
+### 状态与方法、用例的联系
+
+- 一个方法的执行 → 属性值改变 → 对象进入新**状态**
+- 对象处于不同状态 → 影响后续哪些**用例**可以执行
+- 一个对象完整的状态图 = 多个用例的顺序图**融合**
+
+### 活动与方法、用例的联系
+
+- 一个**活动** = 一个方法中的部分（或全部）语句执行
+- 一个方法可能需要多个活动来完成
+- 一个**用例** = 若干个活动，通常一个用例对应一个活动图
+
+---
+
+## ✍️ 边学边练（三）
+
+**题目**：借书证的状态图中有"可借书"和"不可借书"状态。问：
+
+1. "借书"操作对应什么事件类型？
+2. 从"不可借书"转回"可借书"需要什么事件？
+3. "借书证"的状态图与哪些用例有关？
+
+**答案：**
+1. **调用事件**——"借书"本质上是对借书证对象调用借书方法
+2. **还书事件**——读者还书后，借书证的可借本数减1，重新变为可借
+3. 与"借书""还书""挂失借书证"等用例有关。这些用例的顺序图融合起来，就构成了借书证的完整状态图
+
+---
+
+## 📝 章末自测
+
+**1. 填空题**
+- 状态图描述的是（ ___ ）（ ___ ）个对象的状态变化
+- 四种事件类型是：调用事件、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、时间事件
+- 活动图中的菱形表示（ ___ ）（ ___ ），粗横线表示（ ___ ）（ ___ ）
+
+**2. 判断题**
+- ( ) 状态图和活动图都可以描述多个对象的交互
+- ( ) 信号事件比调用事件更易于扩展
+- ( ) 一个活动可能跨越多个泳道
+- ( ) 带泳道的活动图用在系统设计阶段
+
+**3. 简答题**
+- 简述状态和活动的区别。
+- 什么情况下应该用状态图，什么情况下应该用活动图？
+
+**答案：**
+**填空题**：一（单个）；信号事件、变化事件；分支、分叉/汇合
+
+**判断题**：
+- ❌ 状态图只描述一个对象
+- ✅ 信号类可继承扩展
+- ❌ 每个活动只属于一个泳道
+- ✅ 带泳道用于设计阶段
+
+**简答题**：
+- 状态是对象的境况（活动执行后的结果），可以持续很长时间；活动是代码的执行过程，相对短暂。状态变化由活动引起。
+- 状态图：描述一个对象生命周期内的状态变迁（如订单状态、借书证状态）。活动图：描述一个业务流程或算法步骤（如取款流程、登录验证流程）。
+
+---
+> 🔗 上一篇：[第5章 顺序图与协作图](第05章-顺序图与协作图.md) | 下一篇：[第7章 组件图与部署图](第07章-组件图与部署图.md)
diff --git a/各章笔记/第07章-组件图与部署图.md b/各章笔记/第07章-组件图与部署图.md
new file mode 100644
index 0000000..b9ff3f2
--- /dev/null
+++ b/各章笔记/第07章-组件图与部署图.md
@@ -0,0 +1,138 @@
+# 第7章 组件图与部署图
+
+> **考试重要度**：★★★  
+> **核心内容**：组件的概念与类型、组件与类的关系、正向工程与逆向工程、部署图与结点
+
+---
+
+## 📢 从盖房子理解物理模型
+
+💬 前面学的用例图、类图、顺序图等是**逻辑模型**——描述"软件能干什么"和"软件怎么组织"。
+
+组件图和部署图是**物理模型**——描述"软件代码文件怎么组织"和"软件部署在哪台机器上"。
+
+```
+逻辑模型：用例图 + 类图 + 顺序图 + 协作图 + 活动图 + 状态图
+物理模型：包图 + 组件图 + 部署图
+```
+
+💬 **比喻**：逻辑模型是"建筑设计图"（几室几厅、什么风格），物理模型是"施工方案"（每间房用什么材料、电线怎么走）。
+
+---
+
+## 💡 一、组件的概念
+
+> **定义**：组件 = 系统中可替换的物理部件，是一个实现性文件。
+
+💬 **大白话**：组件就是"软插件"——像电脑的USB设备一样，可以拔下来换一个。
+
+### 组件的三种类型
+
+| 类型 | 说明 | 举例 |
+|------|------|------|
+| **部署组件** | 运行时需要的组件 | DLL文件、JAR文件、数据库表、XML文件 |
+| **工作产品组件** | 开发过程产生的组件 | 源代码文件(.java/.cpp)、数据文件 |
+| **执行组件** | 运行后产生的组件 | EXE文件、动态网页、EJB |
+
+---
+
+## 💡 二、组件和类的关系
+
+🔑 **这是本章最重要的理解！**
+
+| 维度 | 类 | 组件 |
+|------|-----|------|
+| **性质** | 逻辑概念（"虚"） | 物理概念（"实"） |
+| **存在形式** | 设计图上的符号 | 硬盘上的文件 |
+| **包含关系** | 一个类只在一个组件中 | 一个组件可以包含多个类 |
+| **例子** | `class BankAccount` | `BankAccount.java` 这个文件 |
+
+💬 **简单说**：一个.java文件可以定义多个类，这个.java文件就是**组件**，里面的class定义就是**类**。
+
+### 组件之间的关系
+
+组件之间的关系 = 包含的类之间的关系的"投影"。
+
+> 类A依赖于类B → 组件A依赖于组件B
+
+---
+
+## 💡 三、正向工程与逆向工程
+
+| 工程方向 | 含义 | 过程 |
+|----------|------|------|
+| **正向工程** | 模型 → 代码 | 画好类图和组件图 → 工具自动生成代码框架 |
+| **逆向工程** | 代码 → 模型 | 导入源代码 → 工具自动生成类图和组件图 |
+
+💬 **正向工程**：先设计，再生成代码骨架。  
+💬 **逆向工程**：拿到别人写的代码，自动生成类图来理解结构。
+
+---
+
+## 💡 四、部署图
+
+### 结点的概念
+
+> **结点** = 运行时存在的、有计算能力的物理元素。
+
+| 结点类型 | 说明 | 举例 |
+|----------|------|------|
+| **处理机结点** | 有计算能力的硬件 | PC机、服务器、打印机（智能） |
+| **设备结点** | 无计算能力的硬件 | 调制解调器、普通终端 |
+
+### 部署图的作用
+
+部署图显示：
+1. 系统中有哪些**硬件结点**
+2. 结点之间的**连接关系**（通信路径）
+3. 每个结点上运行什么**组件**
+
+💬 **一句话**：部署图 = "哪个软件组件跑在哪台机器上"。
+
+---
+
+## ✍️ 边学边练
+
+**题目**：某Web系统包括以下内容，请区分逻辑模型和物理模型。
+
+① 用户类(User)、订单类(Order)  
+② User.java、Order.java放在src/entity目录下  
+③ 用户登录要用到LoginAction.java  
+④ 整个系统部署在一台Web服务器和一台数据库服务器上  
+⑤ 用户→登录界面→输入信息→验证→跳转主页
+
+**答案：**
+- ① **逻辑模型（类图）**—— 描述有哪些类
+- ② **物理模型（包图+组件图）**—— 描述文件放哪个目录
+- ③ **物理模型（组件图）**—— 描述组件之间的依赖
+- ④ **物理模型（部署图）**—— 描述硬件部署
+- ⑤ **逻辑模型（顺序图/活动图）**—— 描述交互流程
+
+---
+
+## 📝 章末自测
+
+**1. 填空题**
+- 组件的三种类型是：（ ___ ）（ ___ ）、（ ___ ）（ ___ ）、（ ___ ）（ ___ ）
+- 正向工程是指从（ ___ ）（ ___ ）生成（ ___ ）（ ___ ）
+- 部署图中的结点分两种：（ ___ ）（ ___ ）和（ ___ ）（ ___ ）
+
+**2. 判断题**
+- ( ) 一个组件只能包含一个类
+- ( ) 组件图描述的是系统的物理结构
+- ( ) 部署图中的连接表示硬件之间的通信路径
+- ( ) 类图是物理模型，组件图是逻辑模型
+
+**3. 简答题**
+- 简述组件和类的关系。
+
+**答案：**
+**填空题**：部署组件、工作产品组件、执行组件；模型、代码；处理机结点、设备结点
+
+**判断题**：❌(可包含多个) ✅ ✅ ❌(反过来)
+
+**简答题**：
+- 类是逻辑概念，组件是物理概念。一个组件（如.java文件）可以包含一个或多个类。组件是为了"软插件"理念——将类打包成可替换的物理单元。类之间的关系决定了组件之间的关系。
+
+---
+> 🔗 上一篇：[第6章 状态图与活动图](第06章-状态图与活动图.md) | 下一篇：[第8章 包图](第08章-包图.md)
diff --git a/各章笔记/第08章-包图.md b/各章笔记/第08章-包图.md
new file mode 100644
index 0000000..360da69
--- /dev/null
+++ b/各章笔记/第08章-包图.md
@@ -0,0 +1,128 @@
+# 第8章 包图
+
+> **考试重要度**：★★  
+> **核心内容**：包的概念与可见性、包之间的依赖与泛化关系、四大设计原则
+
+---
+
+## 📢 从文件夹理解包图
+
+💬 你电脑上肯定有文件夹（目录），用来把相关文件放在一起。
+
+在UML中，**包**就是"文件夹"——把关系密切的类、接口、组件等放在一起。
+
+```
+┌─────────────────┐
+│  包名           │
+│  ┌───────────┐  │
+│  │ + 公开类  │  │  ← 被import后外部可用
+│  │ # 受保护  │  │  ← 只有子包可用
+│  │ - 私有类  │  │  ← 只有包内部可用
+│  └───────────┘  │
+└─────────────────┘
+```
+
+---
+
+## 💡 一、包的可见性
+
+跟类的可见性一样，包中的元素也有三种可见性：
+
+| 可见性 | 符号 | 含义 |
+|--------|------|------|
+| **公有** | `+` | 任何导入此包的包都可以用 |
+| **受保护** | `#` | 只有子包可以用 |
+| **私有** | `-` | 只有包内部可以用 |
+
+---
+
+## 💡 二、包之间的关系
+
+### 1. 依赖关系
+
+> 包A中的某个类依赖于包B中的某个类 → 包A依赖于包B。
+
+⚠️ **注意**：包之间的依赖关系**没有传递性**！A依赖B，B依赖C，不等于A依赖C。
+
+### 2. 泛化关系
+
+> 子包继承父包中可见性为public和protected的元素。
+
+---
+
+## 💡 三、包的四大设计原则
+
+这些原则告诉你**怎么把类分到不同的包里**：
+
+### 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)
diff --git a/各章笔记/第09章-数据建模.md b/各章笔记/第09章-数据建模.md
new file mode 100644
index 0000000..3026ff6
--- /dev/null
+++ b/各章笔记/第09章-数据建模.md
@@ -0,0 +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)
diff --git a/各章笔记/第11章-RUP统一过程.md b/各章笔记/第11章-RUP统一过程.md
new file mode 100644
index 0000000..adaa08b
--- /dev/null
+++ b/各章笔记/第11章-RUP统一过程.md
@@ -0,0 +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)
diff --git a/期中复习/期中复习指南.md b/期中复习/期中复习指南.md
new file mode 100644
index 0000000..147ff96
--- /dev/null
+++ b/期中复习/期中复习指南.md
@@ -0,0 +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. **活动图泳道**：根据参与者来划分，每道一个责任区
diff --git a/期末复习指南.md b/期末复习指南.md
new file mode 100644
index 0000000..0836c20
--- /dev/null
+++ b/期末复习指南.md
@@ -0,0 +1,146 @@
+# 期末考试复习指南
+
+> **课程**：软件需求分析与设计  
+> **考试结构**：选择30分 + 填空15分 + 解答25分 + 案例30分 = 100分
+
+---
+
+## 📋 考试题型与分值
+
+| 题型 | 题量 | 分值 | 考察内容 |
+|------|------|------|----------|
+| 选择题 | 15题 | 30分（2分/题） | 基础知识点 |
+| 填空题 | 15空 | 15分（1分/空） | 基础知识点 |
+| 解答题 | 5题 | 25分（5分/题） | 需求管理 + UML图理解 |
+| 案例题 | 2题 | 30分 | 综合建模能力 |
+
+---
+
+
+> 📎 **各章笔记链接**：[第1章 需求工程](各章笔记/第01章-需求工程.md) | [第3章 用例图](各章笔记/第03章-用例图.md) | [第4章 类图](各章笔记/第04章-类图与对象图.md) | [第5章 顺序图与协作图](各章笔记/第05章-顺序图与协作图.md) | [第6章 状态图与活动图](各章笔记/第06章-状态图与活动图.md) | [第7章 组件图与部署图](各章笔记/第07章-组件图与部署图.md) | [第9章 数据建模](各章笔记/第09章-数据建模.md) | [第11章 RUP](各章笔记/第11章-RUP统一过程.md)
+> 📎 **速查**：[UML九图速查](速查手册/UML九图速查.md) | [设计原则与术语](速查手册/设计原则与术语速查.md) | [课后习题汇编](课后习题汇编.md)
+
+## 🎯 考试范围与重点
+
+### 重点考察（约占70分）
+
+| 模块 | 重点内容 | 题型 |
+|------|----------|------|
+| **需求工程** | 需求定义 | [第1章](各章笔记/第01章-需求工程.md)、层次分类、需求开发与需求管理过程域、需求获取技术、SRS、优秀需求特性、需求变更控制流程 | 选择/填空/解答 |
+| **用例图** | 参与者与用例识别 | [第3章](各章笔记/第03章-用例图.md)、包含/扩展/泛化关系、用例描述编写、系统边界 | 选择/填空/解答/案例 |
+| **类图** | 类与对象、六大关系 | [第4章](各章笔记/第04章-类图与对象图.md)、多重性、边界类/控制类/实体类、抽象类与接口 | 选择/填空/解答/案例 |
+| **顺序图与协作图** | 消息类型 | [第5章](各章笔记/第05章-顺序图与协作图.md)、调用vs异步、生命线与控制焦点、消息编号、顺序图与协作图互转 | 选择/填空/解答/案例 |
+| **活动图** | 活动、泳道 | [第6章](各章笔记/第06章-状态图与活动图.md)、分支、分叉与汇合、对象流 | 选择/填空/解答/案例 |
+| **状态图** | 状态、转移 | [第6章](各章笔记/第06章-状态图与活动图.md)、事件类型、组合状态、历史状态 | 选择/填空/解答/案例 |
+
+### 简要了解（约占30分）
+
+| 模块 | 重点内容 | 题型 |
+|------|----------|------|
+| **组件图与部署图** | 组件概念 | [第7章](各章笔记/第07章-组件图与部署图.md)、组件与类的关系、正向/逆向工程、结点 | 选择/填空 |
+| **包图** | 包的概念 | [第8章](各章笔记/第08章-包图.md)、四大设计原则（REP/CCP/CRP/ADP） | 选择/填空 |
+| **数据建模** | 对象模型到数据模型转换 | [第9章](各章笔记/第09章-数据建模.md)、多重性映射、三大范式 | 选择/填空 |
+| **RUP** | 三大特点 | [第11章](各章笔记/第11章-RUP统一过程.md)、四个阶段、九个工作流、六大最佳实践 | 选择/填空 |
+
+---
+
+## 🔑 必背简答题（4选1 + 其他）
+
+### 题1：需求的层次
+
+> 📎 详见：[第1章 需求工程](各章笔记/第01章-需求工程.md)（按层次分）
+
+**答案**：需求按层次主要分为业务需求、用户需求、功能需求和非功能需求。
+
+- **业务需求**：描述组织或客户的高层次目标，主要目的是对企业目前的业务流程进行评估，得出一个业务前景。
+- **用户需求**：用户使用系统而完成的任务的集合，在用户案例文档或方案脚本中予以说明。
+- **功能需求**：定义了开发人员必须实现的软件功能，源于用户需求。
+- **非功能需求**：描述了系统展现给用户的行为和执行的操作等，包括产品/质量需求、机构需求和外部需求。
+
+---
+
+### 题2：优秀需求的特性
+
+> 📎 详见：[第1章 需求工程 - 优秀需求的七个标准](各章笔记/第01章-需求工程.md)
+
+**答案**：优秀需求通常具备以下特性：
+
+- **正确性**：准确反映利益相关方的真实需要。
+- **无歧义性**：不同读者都要理解一致，不能有歧义。
+- **可行性**：每一项需求都必须在已知的系统和环境的权能和限制范围内可以实施。
+- **有优先级**：区分需求的优先级别，更好地管理项目。
+- **必要性**：每一项需求都应把客户真正需要的和最终系统所需遵从的标准记录下来。
+- **可验证性**：每项需求都能通过设计测试用例或其他验证方法，来确定产品是否确实按需求实现了。
+
+---
+
+### 题3：需求变更控制流程
+
+> 📎 详见：[第1章 需求工程 - 需求变更控制](各章笔记/第01章-需求工程.md)
+
+**答案**：典型的需求变更流程包括：
+
+1. **提出变更**：任何人（客户、用户、开发等）提交变更申请。
+2. **初步评估**：项目经理或需求分析人员评估变更的合理性与影响范围。
+3. **评审与决策**：变更控制委员会（CCB）或相关决策者审核，决定是否批准。
+4. **更新需求文档**：若批准，更新需求规格说明书，保持版本记录。
+5. **通知相关方**：将变更内容告知开发、测试、项目管理等团队。
+6. **调整计划与执行**：修改设计、代码、测试用例，并更新项目计划。
+7. **验证变更**：测试确认变更已正确实现且无负面副作用。
+
+---
+
+### 题4：需求管理包含的内容
+
+> 📎 详见：[第1章 需求工程 - 需求管理](各章笔记/第01章-需求工程.md)
+
+**答案**：需求管理应该包含以下内容：
+
+- **需求确认**：开发方和客户共同对需求文档进行评审，达成共识并作出书面承诺，使需求文档具有商业合同效果。
+- **需求跟踪**：通过比较需求文档与后续工作成果之间的对应关系，建立与维护"需求跟踪矩阵"，确保产品依据需求文档进行开发。
+- **需求变更控制**：依据"变更申请—审批—更改—重新确认"的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
+
+---
+
+## 📊 UML九图速查
+
+| UML图 | 分类 | 核心用途 | 核心元素 |
+|-------|------|----------|----------|
+| 用例图 | 功能 | 描述系统功能全景 | 参与者、用例、系统边界、关系 |
+| 类图 | 静态结构 | 描述类及其关系 | 类、属性、操作、六大关系 |
+| 对象图 | 静态结构 | 某一时刻的快照 | 对象、属性值、链 |
+| 顺序图 | 动态交互 | 按时间顺序的消息交互 | 对象、生命线、控制焦点、消息 |
+| 协作图 | 动态交互 | 按空间关系的消息交互 | 对象、链、消息序号 |
+| 状态图 | 动态行为 | 单个对象的状态变迁 | 状态、转移、事件 |
+| 活动图 | 动态行为 | 业务流程/工作流 | 活动、泳道、分支、分叉 |
+| 组件图 | 物理实现 | 代码文件组织 | 组件、接口、依赖 |
+| 部署图 | 物理实现 | 硬件拓扑 | 结点、组件、连接 |
+
+---
+
+## ⚠️ 考前易错提醒
+
+1. **包含 vs 扩展**：包含=必然执行（箭头基本→包含），扩展=条件执行（箭头扩展→基本）
+2. **聚合 vs 组合**：聚合=空心菱形（部分可独立存在），组合=实心菱形（部分随整体消亡）
+3. **调用消息 vs 异步消息**：调用=同步等待返回，异步=发出后继续执行
+4. **状态图 vs 活动图**：状态图管一个对象的状态变化，活动图管多对象参与的流程
+5. **消息编号**：`1.1.1` 表示嵌套——1.1.1必须在1.1完成之前完成
+6. **类图关系判断**：属性里放了另一个类=关联，方法参数用了另一个类=依赖
+7. **用例描述**：核心6要素——用例名、参与者、前置条件、后置条件、主事件流、子事件流
+8. **RUP四阶段顺序**：初始→细化→构造→移交（不是初始→构造→细化→移交！）
+
+---
+
+## 🛠️ 案例题备考建议
+
+1. **用例图**：能根据文字描述识别参与者（人/外部系统/设备）和用例（动宾短语），正确标注包含/扩展关系
+2. **类图**：能从需求陈述中提取实体类，标注属性和关系，正确标注多重性
+3. **顺序图**：能根据用例描述画出对象间的消息交互，正确使用消息编号（嵌套层级）
+4. **活动图**：能画带泳道的活动图，正确使用分支和分叉/汇合
+5. **状态图**：能识别对象的关键状态，标注触发状态转移的事件
+
+---
+
+> 📎 **刷题**：[课后习题汇编](课后习题汇编.md) | **期中**：[期中复习指南](期中复习/期中复习指南.md)
+
+> **复习策略**：选择题+填空题→刷课后习题汇编；解答题→背诵本页4道简答题；案例题→回顾实验和Middle Subjective练习
diff --git a/课后习题汇编.md b/课后习题汇编.md
new file mode 100644
index 0000000..dcdc144
--- /dev/null
+++ b/课后习题汇编.md
@@ -0,0 +1,1442 @@
+# 课后习题全集
+
+> **来源**：教材各章课后习题（OCR提取整理）  
+> **总题量**：200+ 道（填空、选择、判断、简答、分析）  
+> **用途**：学完全部章节后，不翻笔记独立刷一遍，检验掌握程度
+
+# 第1章 面向对象技术概述
+
+## 一、填空题（19题）
+
+1. 面向对象方法至少应当包含4个方面：（ ___ ）、（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：标识 / 分类 / 多态 / 继承**
+---
+
+2. "面向对象"是把一组对象中的数据结构和行为（ ___ ）结合在一起组织系统的一种策略。
+   **答案：紧密**
+---
+
+3. （ ___ ）是一个对象可识别的特性。
+   **答案：标识**
+---
+
+4. （ ___ ）是用来描述对象动态特征(行为)的一个操作序列。
+   **答案：服务**
+---
+
+5. （ ___ ）就是把对象的属性服务结合成为一个独立的系统单位，并尽可能隐蔽对象的内部细节。
+   **答案：封装**
+---
+
+6. （ ___ ）就是向对象发出的服务请求，它应该含有下述信息：提供服务的（ ___ ）、服务标识、（ ___ ）和回答信息。
+   **答案：消息 / 对象标识 / 输入信息**
+---
+
+7. 结构化分析方法侧重于对系统进行（ ___ ），面向对象分析方法侧重于从（ ___ ）的角度出发去研究和理解问题。
+   **答案：功能分解 / 现实对象**
+---
+
+8. 面向对象的基本建模原则：（ ___ ）、（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：抽象 / 封装 / 继承 / 分类**
+---
+
+9. 面向对象的软件工程包括（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）和（ ___ ）等主要内容。
+   **答案：面向对象分析(OOA) / 面向对象设计(OOD) / 面向对象编程(OOP) / 面向对象测试(OOT) / 面向对象的软件维护(OOSM)**
+---
+
+10. RDD方法，又称为（ ___ ）。
+    **答案：CRC(类、责任、协作)方法**
+---
+
+11. 对象的概念是（ ___ ），类的概念是（ ___ ）。
+    **答案：对象是对问题域中某个实体的抽象 / 类是对具有相同属性和行为的一个或多个对象的描述**
+---
+
+12. 类和对象的关系是（ ___ ）。
+    **答案：对象是类的实例 / 类是对对象的定义模板**
+---
+
+13. 属性的定义是（ ___ ），服务的定义是（ ___ ）。
+    **答案：属性是描述对象静态特征的一个数据项 / 服务是描述对象动态特征(行为)的一个操作序列**
+---
+
+14. 类属性的定义是（ ___ ）。
+    **答案：类属性是描述类的所有对象的共同特征的一个数据项。对于任何对象实例，它的属性值都是相同的**
+---
+
+15. 类的定义包含（ ___ ）、（ ___ ）和（ ___ ）三要素。
+    **答案：名称 / 属性 / 操作**
+---
+
+16. 面向对象程序设计的三大特性是（ ___ ）、（ ___ ）和（ ___ ）。
+    **答案：封装 / 继承 / 多态**
+---
+
+17. 面向对象方法中的（ ___ ）机制使得子类可以自动地拥有(复制)父类的全部属性和操作。
+    **答案：继承**
+---
+
+18. 面向对象技术采用以类为中心的（ ___ ）、（ ___ ）、（ ___ ）等特性不仅支持软件复用，而且使软件维护工作可靠有效。
+    **答案：封装 / 继承 / 多态**
+---
+
+19. 面向对象的系统分析要确立（ ___ ）、（ ___ ）和（ ___ ） 3个系统模型。
+    **答案：对象模型 / 行为模型 / 功能模型**
+
+## 二、选择题（19题）
+
+1. 以下( )功能是面向对象软件开发环境应具有的。
+   A. 有一个支持复用和共享的类库及其浏览、维护界面
+   B. 有一个存储并管理永久对象的对象管理系统(OMS)
+   C. 有一个或多个基于类库和OMS的面向对象的编程语言
+   D. 提供一套覆盖软件生命周期各阶段的面向对象的开发工具
+   **答案：ABCD**
+---
+
+2. ( )不是对象具有的特性。
+   A. 标识  B. 继承  C. 顺序  D. 多态性
+   **答案：C**
+---
+
+3. ( )不是方法学的设计阶段。
+   A. 分析  B. 系统设计  C. 物理设计  D. 对象设计
+   **答案：C**
+---
+
+4. 构成对象的两个主要因素是( )。
+   A. 属性  B. 封装  C. 服务  D. 继承
+   **答案：AC**
+---
+
+5. 描述对象之间的静态联系用( )。
+   A. 一般-特殊结构  B. 整体-部分结构  C. 实例连接  D. 消息连接
+   **答案：C**
+---
+
+6. ( )描述两个或多个实例之间的关系,而( )描述单一实例的不同的特性。
+   A. 关联  B. 整合  C. 连接  D. 概括
+   **答案：AD**
+---
+
+7. ( )编程语言不是面向对象编程语言。
+   A. FORTRAN  B. Pascal  C. Smalltalk  D. Ada
+   **答案：AB**
+---
+
+8. ( )是面向对象方法。
+   A. Coad & Yourdon方法  B. 维也纳方法  C. OMT方法  D. Booch方法
+   **答案：ACD**
+---
+
+9. 如果想对一个类的意义进行描述,那么应该采取( )。
+   A. 标记值  B. 规格说明  C. 注释  D. 构造型
+   **答案：C**
+---
+
+10. 下面选项中不是面向对象特征的是( )。
+    A. 抽象  B. 继承  C. 封装  D. 泛化
+    **答案：D**
+---
+
+11. 下列关于类与对象的关系的说法正确的是( )。
+    A. 有些对象是不能被抽象成类的
+    B. 类给出了属于该类的全部对象的抽象定义
+    C. 类是对象集合的再抽象
+    D. 类用来在内存中开辟一个数据区,存储新对象的属性
+    **答案：BCD**
+---
+
+12. 类的定义包含( )。
+    A. 类的属性  B. 类所要执行的操作  C. 类的编号  D. 属性的类型
+    **答案：ABD**
+---
+
+13. 封装是指把对象的( )结合在一起,组成一个独立的对象。
+    A. 属性和操作  B. 信息流  C. 消息和事件  D. 数据的集合
+    **答案：A**
+---
+
+14. 封装是一种( )技术,目的是使对象的生产者和使用者分离,使对象的定义和实现分开。
+    A. 工程化  B. 系统维护  C. 信息隐藏  D. 产生对象
+    **答案：C**
+---
+
+15. 面向对象方法中的( )机制使子类可以自动地拥有(复制)父类全部属性和操作。
+    A. 约束  B. 对象映射  C. 信息隐藏  D. 继承
+    **答案：D**
+---
+
+16. 使得在多个类中能够定义同一个操作或属性名,并在每一个类中有不同的实现的一种方法是( )。
+    A. 继承  B. 多态性  C. 约束  D. 接口
+    **答案：A**
+---
+
+17. 建立对象的动态模型的步骤有( )。
+    A. 准备脚本  B. 确定事件  C. 构造状态图  D. 准备事件跟踪表
+    **答案：ABCD**
+---
+
+18. 描述对象之间的动态联系用( )。
+    A. 一般-特殊结构  B. 整体-部分结构  C. 实例连接  D. 消息连接
+    **答案：D**
+---
+
+19. 描述对象之间的结构(或组织)联系用( )。
+    A. 一般-特殊结构  B. 整体-部分结构  C. 实例连接  D. 消息连接
+    **答案：C**
+
+## 三、判断题（10题）
+
+1. ( ) 数据建模(或称对象建模)就是通过信息流的变换来展示系统的功能。
+   **答案：错**
+---
+
+2. ( ) 行为建模就是通过状态描述和导致系统改变状态的事件来显示系统的行为。
+   **答案：对**
+---
+
+3. ( ) 结构化分析SA侧重于对系统进行功能分解。
+   **答案：对**
+---
+
+4. ( ) 面向对象分析OOA侧重于从现实对象的角度出发来分析系统。
+   **答案：对**
+---
+
+5. ( ) 可以使用Pascal编程语言进行面向对象的编程OOP。
+   **答案：错**
+---
+
+6. ( ) 封装就是把对象的属性和行为组成一个独立的系统单位，不用担心内部细节的隐蔽。
+   **答案：错**
+---
+
+7. ( ) 继承对于软件重用有重要意义，一般类继承特殊类，本身就是软件重用。
+   **答案：错**（应为特殊类继承一般类）
+---
+
+8. ( ) 特殊类在继承一般类的行为时，通过参数的不同而表现出不同的行为，就是多态性。
+   **答案：对**
+---
+
+9. ( ) 对象之间只通过消息进行通信，满足了封装的原则。
+   **答案：对**
+---
+
+10. ( ) Smalltalk是面向对象编程语言发展史上的第一个里程碑。
+   **答案：对**
+
+## 四、简答题（7题）
+
+1. 叙述对象和类的关系。
+   **答案：对象是类的实例，类是对对象的定义模板。**
+---
+
+2. 简述面向对象的概念。
+   **答案：面向对象 = 对象 + 类 + 继承 + 消息传递。涉及基本建模原则：抽象、封装、继承、分类。**
+---
+
+3. 简述面向对象设计的原则。
+   **答案：6个原则——开放封闭原则、单一职责原则、依赖倒置原则、Liskov替换原则、迪米特法则、接口隔离原则。**
+---
+
+4. 对象之间如何协同工作？
+   **答案：对象之间通过消息传递来协同工作。一个对象向另一个对象发送消息请求其服务。消息通常包括接收对象名、调用的操作和参数。**
+---
+
+5. 简述封装与信息隐藏的关系。
+   **答案：封装将属性和操作结合成独立单元；信息隐藏是封装的目的——隐藏内部实现细节，只暴露公开接口。**
+---
+
+6. 简述多态性说明了什么。
+   **答案：多态性说明同一个操作在不同对象类中可以有不同的实现。它允许用统一的接口处理不同类型的对象。**
+---
+
+7. 简述重载与覆盖的区别。
+   **答案：重载(overload)是在同一类中同名方法参数不同；覆盖(override)是子类重新定义父类的方法，签名完全相同。**
+
+## 五、分析题
+
+某银行办理取款手续：储户把存折和取款单一并交给出纳员检验。出纳员核对账目，发现存折有效性问题、取款单填写问题、账目与取款单不符等则停止取款。检查通过后登记存折和账目，交付现金。
+(1) 确定"取款"用例描述。
+(2) 识别对象。
+(3) 识别对象属性。
+(4) 识别对象行为，画状态-事件-响应图。
+(5) 定义类结构。
+
+**答案：**
+(1) 用例描述：出纳员检验存折、核对账目→有问题则停止并告知→通过后登记信息、交付现金。
+(2) 对象：存折、账目（储户、出纳员、取款单、现金被筛选掉）。
+(3) 存折属性：存折号码、户主姓名、开户日期、存折类型、开户行；账目属性：存折号码、交易类型、交易金额、交易日期。
+(4) 存折行为：有效性检查()、打印取款信息()；账目行为：与取款单一致性检查()、修改账目信息()。
+(5) 存折类：属性(私有)、方法(保护)；账目类：属性(私有)、方法(保护)。
+
+
+# 第3章 用例图
+
+## 一、填空题（8题）
+
+1. 用例图的组成元素包括（ ___ ）、（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：参与者(角色) / 用例 / 系统边界 / 关联**
+---
+
+2. （ ___ ）用于描述系统的全部功能。
+   **答案：用例图**
+---
+
+3. 用例之间的关系分为（ ___ ）、（ ___ ）和（ ___ ）三种。
+   **答案：包含 / 扩展 / 泛化**
+---
+
+4. （ ___ ）是指用例的规模，即主事件流和子事件流综合步骤的大小。
+   **答案：用例粒度**
+---
+
+5. 参与者是系统的（ ___ ），用例是系统的（ ___ ）。
+   **答案：组成部分 / 系统外部**
+---
+
+6. 用例分析不仅包括用例图，还包括（ ___ ）和（ ___ ）。
+   **答案：用例 / 活动 / 类和对象**
+---
+
+7. 用例建模的主要步骤：（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）。
+   **答案：确定系统边界 / 确定参与者和用例 / 细化用例 / 编写用例描述 / 审核用例模型**
+---
+
+8. 参与者可分为三种类型：（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：人 / 外部系统 / 外部设备**
+
+## 二、选择题（10题）
+
+1. 用例图中的关系类型包括( )。 A.包含 B.扩展 C.泛化 D.实现
+   **答案：ABC**
+---
+
+2. 用例的核心是( )。 A.用例名 B.参与者 C.交互行为 D.系统边界
+   **答案：C**
+---
+
+3. 关于包含关系正确的是( )。 A.包含用例一定执行 B.可选执行 C.箭头基本用例指向包含用例 D.箭头包含用例指向基本用例
+   **答案：A**
+---
+
+4. 关于扩展关系正确的是( )。 A.扩展用例一定执行 B.条件执行 C.箭头基本用例指向扩展用例 D.箭头扩展用例指向基本用例
+   **答案：B**
+---
+
+5. 系统边界的作用是( )。 A.确定系统要实现的功能 B.确定谁是参与者 C.确定用例粒度 D.以上都是
+   **答案：D**
+---
+
+6. 用例粒度决定了( )。 A.用例模型复杂度 B.用例间通信成本 C.系统耦合复杂度 D.以上都是
+   **答案：D**
+---
+
+7. 参与者之间泛化关系表示( )。 A.特殊参与者继承普通参与者能力 B.普通参与者继承特殊参与者 C.两者是同一个 D.互不相关
+   **答案：A**
+---
+
+8. 用例描述的核心至少包括( )。 A.用例名参与者 B.前置后置条件 C.主事件流子事件流 D.以上全部
+   **答案：D**
+---
+
+9. 用例模型的组成是( )。 A.用例图 B.用例描述 C.用例图+用例描述 D.参与者+用例
+   **答案：C**
+---
+
+10. 下列哪项不是用例之间的关系( )。 A.包含 B.扩展 C.泛化 D.实现
+   **答案：D**
+
+## 三、判断题（2题）
+1. ( ) 用例图可以反映系统的非功能需求。
+   **答案：错**
+---
+
+2. ( ) 用例是独立于实现的，只描述用户看到的系统功能。
+   **答案：对**
+
+## 四、简答题（重点8题）
+
+1. 用例之间的关系有哪三种？试对比分析。
+   **答案：包含=包含用例一定执行；扩展=扩展用例受条件约束不能单独执行；泛化=子用例可覆盖父用例功能且可单独执行。**
+---
+
+2. 用例分析获取用户需求是否有缺陷？
+   **答案：有。只能反映功能需求不能反映非功能需求，需用补充规约弥补。**
+---
+
+3. 参与者和用例之间的关联关系箭头方向代表什么含义？
+   **答案：箭头指向用例=参与者使用用例；箭头指向参与者=用例传递处理结果给参与者。**
+---
+
+4. 用例的核心是什么？如何体现？
+   **答案：核心是用例和参与者之间的交互行为，由用例描述表达。**
+---
+
+5. 用例描述的核心是什么？
+   **答案：至少6部分——用例名、参与者、前置条件、后置条件、主事件流、子事件流。**
+---
+
+6. 系统边界的作用是什么？
+   **答案：确认系统要实现的功能。边界不同，功能、参与者、需求都不同。**
+---
+
+7. 用例粒度是什么？有何作用？
+   **答案：用例规模（主事件流和子事件流综合步骤大小）。决定模型复杂度、通信成本、系统耦合复杂度。**
+---
+
+8. 用例之间为什么没有实现关系？
+   **答案：用例与实现无关，只描述用户看到的系统功能。用例到类的映射在分析与设计阶段完成。**
+
+## 五、分析题（3道代表）
+
+题1：销售点系统 —— 参与者：管理员、销售员、电话操作员。用例：加载存货、保存存货、记录销售、处理电话订单、更新存货清单、核实信用卡支付、核实支票支付。关系：记录销售和处理电话订单包含更新存货清单；核实支付扩展销售。电话操作员泛化自销售员。
+
+题6：电话公司交互式网络系统 —— 图中A=浏览客户信息、B=修改个人信息、C=登录、D=删除客户信息。
+
+题10：企业订餐系统COS —— 补全用例：查看今日特价菜、注册工资支付、生成付费请求、管理菜单。参与者A1=工资系统，A2=菜单管理员。
+
+
+# 第4章 类图与对象图
+
+## 一、填空题（10题）
+
+1. 对象图中的（ ___ ）是类的特定实例，（ ___ ）是类之间关系的实例。
+   **答案：对象 / 链**
+---
+
+2. 类之间的关系包括（ ___ ）关系、（ ___ ）关系、（ ___ ）关系和（ ___ ）关系。
+   **答案：依赖 / 泛化 / 关联 / 实现**
+---
+
+3. 类中方法的可见性包含3种：（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：公有类型(public) / 私有类型(private) / 受保护类型(protected)**
+---
+
+4. 共享聚合整体端的重数应该是（ ___ ）。
+   **答案：\***
+---
+
+5. 组合聚合整体端的重数必须是（ ___ ）。
+   **答案：1**
+---
+
+6. 接口是一个没有（ ___ ）而只有（ ___ ）的类。
+   **答案：属性 / 方法**
+---
+
+7. 对象的三大模型分别是（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：对象静态模型 / 对象动态模型 / 系统功能模型**
+---
+
+8. 建立对象静态模型的步骤：（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）。
+   **答案：确定对象和类 / 定义类的接口 / 定义类之间的关系 / 建立类图 / 建立系统包图**
+---
+
+9. 类的表示包括（ ___ ）、（ ___ ）、（ ___ ）和（ ___ ）等成分。
+   **答案：类名 / 属性 / 操作 / 约束**
+---
+
+10. 类的三要素是（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：名称 / 属性 / 操作**
+
+## 二、选择题（16题）
+
+1. 类通常可分为实体类、( )和边界类。 A.父类 B.子类 C.控制类 D.祖先类
+   **答案：C**
+---
+
+2. 两个类之间存在部分和整体的关系则是( )。 A.依赖 B.泛化 C.聚合 D.实现
+   **答案：C**
+---
+
+3. 两个类之间存在一般和特殊的关系则是( )。 A.关联 B.依赖 C.实现 D.泛化
+   **答案：D**
+---
+
+4. 接口和它的实现类之间存在( )。 A.关联 B.依赖 C.实现 D.泛化
+   **答案：C**
+---
+
+5. 类图中#表示的可见性是( )。 A.Public B.Protected C.Private D.Package
+   **答案：B**
+---
+
+6. 类图中( )关系表达整体与部分的关系。 A.泛化 B.实现 C.依赖 D.聚合
+   **答案：D**
+---
+
+7. UML中关联的多重性是指( )。 A.一个类有多个方法被调用 B.一个类的实例能与另一个类的多个实例相关联 C.一个类被调用的次数 D.两个类有相同的方法和属性
+   **答案：B**
+---
+
+8. 一个类的方法的参数数据类型是另一个类的定义则两class间存在( )。 A.关联 B.依赖 C.实现 D.泛化
+   **答案：B**
+---
+
+9. 一个类的部分对象与另一个类的部分对象存在属性值上的联系时两者存在( )。 A.关联 B.依赖 C.实现 D.泛化
+   **答案：A**
+---
+
+10. UML中类的主要版型有( )。 A.边界类 B.控制类 C.实体类 D.以上都是
+   **答案：D**
+---
+
+11. 封装是指把对象的( )结合在一起组成独立对象。 A.属性和操作 B.信息流 C.消息和事件 D.数据集合
+   **答案：A**
+---
+
+12. 封装是一种( )技术使对象的生产者和使用者分离。 A.工程化 B.系统维护 C.信息隐藏 D.产生对象
+   **答案：C**
+---
+
+13. 面向对象方法中的( )机制使子类自动拥有父类全部属性和操作。 A.约束 B.对象映射 C.信息隐藏 D.继承
+   **答案：D**
+---
+
+14. 类的定义包含( )。 A.类的属性 B.类要执行的操作 C.类的编号 D.属性的类型
+   **答案：ABD**
+---
+
+15. 下面选项中不是面向对象特征的是( )。 A.抽象 B.继承 C.封装 D.泛化
+   **答案：D**
+---
+
+16. 个人客户与客户之间是( )关系。 A.关联 B.泛化 C.依赖 D.聚合
+   **答案：B**
+
+## 三、判断题（10题）
+
+1. ( ) 类与对象的关系可理解为模板与具体实例的关系。
+   **答案：对**
+---
+
+2. ( ) 类是现实世界中客观存在的事物或实体。
+   **答案：错**
+---
+
+3. ( ) 类是具有相同属性和服务的一组对象的集合。
+   **答案：对**
+---
+
+4. ( ) 对象的属性都有值，类的属性没有值。
+   **答案：对**
+---
+
+5. ( ) 类的可见性描述其属性和操作是否对其他类可见。
+   **答案：对**
+---
+
+6. ( ) 类的作用域限定了能共享类的属性和操作的对象数目。
+   **答案：对**
+---
+
+7. ( ) CRC方法是经典的寻找类的方法。
+   **答案：对**
+---
+
+8. ( ) 类之间的关联关系和依赖关系在很多场合下不用区分。
+   **答案：错**
+---
+
+9. ( ) 多重性只存在于关联关系中在聚合关系中不存在。
+   **答案：错**
+---
+
+10. ( ) 接口可以被实例化。
+   **答案：错**
+
+## 四、简答题（5题）
+
+1. 简述类与对象之间的关系及关联与链之间的关系。
+   **答案：对象是类的实例，链是关联的实例。**
+---
+
+2. 简述对象静态模型在UML软件开发过程中的地位。
+   **答案：描述系统静态结构是系统开发模型的核心模型定义系统对谁做的问题。**
+---
+
+3. 简述类的属性描述有哪些成分。
+   **答案：[可见性] 属性名 [:类型] [多重性] [=初始值] [{约束特性}]**
+---
+
+4. 简述类的操作描述有哪些成分。
+   **答案：[可见性] 操作名 [(参数列表)] [:返回类型] [{约束特性}]**
+---
+
+5. 举例说明什么是关联类。
+   **答案：关联类是描述关联属性的类。如Company和Person之间的Contract类有salary属性不属于任一方而属于关联本身。**
+
+## 五、分析题（4道代表）
+
+题1：超市购买商品系统 —— 类图含6个类：销售终端、出纳员、购物单、顾客、商品项目、商品，标注关联与多重性。
+
+题3：关系分类 —— 文件包含记录=聚合；多边形由有序点集成=组成（相同生存期）；某学生选了某教授的课=关联。
+
+题8：研究生三种角色 —— 最合理设计是使用接口PersonRole，三个角色类实现该接口。保证同时只有一种角色，利用多态和接口特性。
+
+题9：书店库存管理系统 —— 由Station类负责创建Transaction类最合理。LineItem和Payment与Transaction是多对1增加耦合；Sale是Transaction子类，子类创建父类不合理。
+
+
+# 第5章 顺序图与协作图
+
+## 一、填空题（17题）
+
+1. 消息有4种类型：（ ___ ）、（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：调用消息(同步消息) / 异步消息 / 简单消息 / 返回消息**
+---
+
+2. （ ___ ）图和（ ___ ）图用来表达对象之间的交互。
+   **答案：顺序 / 协作**
+---
+
+3. 进程是一个（ ___ ）能够与其他进程并发执行。
+   **答案：动作流**
+---
+
+4. 线程是（ ___ ）的一个动作流能够与其他线程并发执行。
+   **答案：进程**
+---
+
+5. （ ___ ）是一个拥有进程或线程的对象能够初始化控制活动。
+   **答案：主动对象**
+---
+
+6. （ ___ ）是一个必须由其他对象发来的消息进行触发才执行动作的对象。
+   **答案：被动对象**
+---
+
+7. 交互图中每一个交互都有（ ___ ）和（ ___ ）。
+   **答案：发送者 / 接收者**
+---
+
+8. （ ___ ）图将交互关系表示为二维图纵向是时间轴横向代表各对象的角色。
+   **答案：顺序**
+---
+
+9. 消息的组成包括（ ___ ）、（ ___ ）、（ ___ ）。
+   **答案：发送者 / 接收者 / 活动**
+---
+
+10. （ ___ ）是一条垂直的虚线表示顺序图中对象在一段时间内的存在。
+   **答案：生命线**
+---
+
+11. 协作图中类元角色描述了一个（ ___ ）关联角色描述了（ ___ ）。
+   **答案：对象 / 协作关系中的链**
+---
+
+12. （ ___ ）通过各对象之间的组织交互关系及对象彼此之间的连接表达交互。
+   **答案：协作图**
+---
+
+13. （ ___ ）是对对象操作的执行表示一个对象直接或通过从属操作完成操作的过程。
+   **答案：激活**
+---
+
+14. 顺序图中对象用包围名称的（ ___ ）标记名称带有（ ___ ）用冒号隔开。
+   **答案：矩形框 / 下画线**
+---
+
+15. 交互图对在一次交互过程中的（ ___ ）和（ ___ ）的链建模。
+   **答案：对象 / 对象**
+---
+
+16. 协作图中的链是两个或多个对象之间的（ ___ ）是（ ___ ）的实例。
+   **答案：独立连接 / 关联**
+---
+
+17. 协作图中（ ___ ）使用带有标签的箭头表示附在连接发送者和接收者的链上。
+   **答案：消息**
+
+## 二、选择题（重点16题）
+
+1. 顺序图和协作图主要用于对用例图中( )的建模。 A.数据流 B.控制流 C.消息流 D.数据字典
+   **答案：B**
+---
+
+2. 顺序图的组成是( )。 A.对象 B.生命线 C.激活 D.消息
+   **答案：ABCD**
+---
+
+3. UML中强调控制流时间顺序的是( )。 A.顺序图 B.协作图 C.定时图 D.交互概述图
+   **答案：A**
+---
+
+4. 在顺序图中返回消息的符号是( )。 A.直线箭头 B.虚线箭头 C.直线 D.虚线
+   **答案：B**
+---
+
+5. 关于协作图的描述不正确的是( )。 A.强调参加交互对象的组织 B.是顺序图的一种特例 C.有消息流的顺序号 D.Rose中可按F5从顺序图生成
+   **答案：B**
+---
+
+6. 组成协作图的元素包括( )。 A.对象 B.消息 C.发送者 D.链
+   **答案：ABD**
+---
+
+7. 关于顺序图的描述正确的是( )。 A.对消息时间顺序的可视化表示 B.更详细描述用例需求 C.描述对象按时间顺序的交互过程 D.横向是时间轴
+   **答案：ABC**
+---
+
+8. 消息序列可用两种图来表示分别是( )。 A.状态图和顺序图 B.活动图和协作图 C.状态图和活动图 D.顺序图和协作图
+   **答案：D**
+---
+
+9. 协作图的作用体现在( )。 A.显示对象空间组织结构 B.表现类操作的实现 C.反映具体语境的逻辑表达 D.描述时间顺序
+   **答案：ABC**
+---
+
+10. 关于控制焦点的概念描述不正确的是( )。 A.生命线上的矩形条 B.对象的生存期 C.对象方法的执行 D.对象执行动作的时间段
+   **答案：B**
+---
+
+11. 消息4.2.1[x>3]:p=find(specs)中: 4.2.1是消息序号 [x>3]是警戒条件 p是返回值 find是消息名 specs是参数列表
+---
+
+12. 关于调用消息和异步消息正确的是( )。 A.异步消息发出后停前期活动 B.调用消息发出后继续前期活动 C.异步消息必有返回消息且需表达 D.调用消息必有返回消息且无须表达
+   **答案：D**
+---
+
+13. 生命线是UML中( )的组成部分。 A.类图 B.状态图 C.活动图 D.顺序图
+   **答案：D**
+---
+
+14. 下面( )属于UML语言的交互图。 A.行为图 B.状态图 C.实现图 D.顺序图
+   **答案：D**
+---
+
+15. 顺序图的用途包括( )。 A.显示并发进程和激活 B.描述控制流整体序列 C.显示难于在协作图中描述的事件序列 D.以上都是
+   **答案：D**
+---
+
+16. 开始编写代码时交互图可用来提供( )。 A.消息发送顺序 B.消息发送条件 C.对象状态转移 D.多重性信息
+   **答案：AB**
+
+## 三、判断题（10题）
+
+1. ( ) 交互模型包括顺序图和协作图两种形式。
+   **答案：对**
+---
+
+2. ( ) 顺序图中的建模元素包括对象生命线控制焦点和消息。
+   **答案：对**
+---
+
+3. ( ) 在顺序图中可表达对象的销毁在协作图中不能。
+   **答案：错**
+---
+
+4. ( ) 从属流是从同一点出发的多条消息指向不同对象。
+   **答案：错**
+---
+
+5. ( ) 异步消息的接收者和发送者是同步工作的。
+   **答案：错**
+---
+
+6. ( ) 调用消息和异步消息主要区别在于控制流是否在完成之前被中断。
+   **答案：对**
+---
+
+7. ( ) 顺序图和协作图可以相互转换。
+   **答案：对**
+---
+
+8. ( ) 顺序图中必须用消息序号表达嵌套协作图中则不是。
+   **答案：错**
+---
+
+9. ( ) 顺序图中可使用交互架构表达条件和循环消息。
+   **答案：对**
+---
+
+10. ( ) 顺序图和协作图可描述用例的实现步骤。
+   **答案：对**
+
+## 四、简答题（重点5题）
+
+1. 简述顺序图和协作图的区别。
+   **答案：顺序图强调消息的时间顺序有生命线和控制焦点；协作图强调参与交互对象的空间关系有路径和消息序号。**
+---
+
+2. 调用消息和异步消息的区别是什么。
+   **答案：调用消息发出后等待接收者返回才继续(同步)；异步消息发出后不等待继续执行(并发)。**
+---
+
+3. 消息的语法格式分为几个部分不可缺少的是哪个。
+   **答案：[前置条件][警戒条件][序号][返回值:=]消息名([参数列表])。消息名必不可少。**
+---
+
+4. 从消息表达式中如何看出嵌套循环条件发送。
+   **答案：嵌套=小数点序号(1.1,1.1.1)；循环=星号*(3.1*)；条件=方括号警戒条件([x>0])。**
+---
+
+5. 何时建顺序图何时建协作图。
+   **答案：关注控制焦点和时间顺序则用顺序图；关注对象空间关系和并发则用协作图。**
+
+## 五、分析题（重点3题）
+
+题1：Account类方法 —— 必须实现withdraw和checkBalance方法。
+
+题6：指纹门禁系统 —— 补全(1)中断事件()(2)读取用户指纹()(3)读取用户开锁权限()(4)读取锁的安全级别()(5)判断用户是否有权限开锁()。
+
+题7：促销系统 —— 补全(1)getCategories()(2)getCommodities()(3)createPromotion()(4)addCommodities()。
+
+
+# 第6章 状态图与活动图
+
+## 一、填空题（16题）
+
+1. 状态图由（ ___ ）的各个状态和连接这些状态的（ ___ ）组成展示（ ___ ）与（ ___ ）。
+   **答案：对象 / 转移 / 状态 / 状态转移**
+---
+
+2. （ ___ ）用于描述模型元素的实例行为。
+   **答案：状态图**
+---
+
+3. 状态可分为（ ___ ）和（ ___ ）。
+   **答案：简单状态 / 复合状态**
+---
+
+4. （ ___ ）代表上次离开组合状态时的最后一个活动子状态用含字母（ ___ ）的小圆圈表示。
+   **答案：历史状态 / H**
+---
+
+5. 状态图中（ ___ ）的发生能够触发状态的改变。
+   **答案：事件**
+---
+
+6. （ ___ ）的所有或多数状态都是动作状态或活动状态。
+   **答案：活动图**
+---
+
+7. （ ___ ）的状态必须与它所表示的参数和结果的类型匹配。
+   **答案：一个对象流**
+---
+
+8. （ ___ ）是原子动作或操作的执行状态不能被外部事件触发的中断。
+   **答案：动作状态**
+---
+
+9. 活动状态可以有内部转移可以有（ ___ ）动作和（ ___ ）动作。
+   **答案：入口 / 出口**
+---
+
+10. 活动图中活动状态按职责分为不同组称为（ ___ ）。
+   **答案：泳道**
+---
+
+11. 顺序状态表明状态之间的转移是（ ___ ）的。
+   **答案：串行**
+---
+
+12. 状态图也可使用（ ___ ）转移符号表示并发子状态。
+   **答案：同步并发**
+---
+
+13. 活动图中（ ___ ）也称为对象流。
+   **答案：带箭头的虚线**
+---
+
+14. 活动图中活动状态的转移（ ___ ）由事件触发一个活动执行完毕（ ___ ）进入下一个活动。
+   **答案：不需要 / 可以直接**
+---
+
+15. 活动图可以描述对象的动态行为也可以描述（ ___ ）。
+   **答案：用例**
+---
+
+16. 状态图和活动图描述了系统中某一（ ___ ）的一系列状态变化。
+   **答案：对象**
+
+## 二、选择题（20题）
+
+1. 事件可分类为( )。 A.信号事件 B.变化事件 C.调用事件 D.时间事件
+   **答案：ABCD**
+---
+
+2. 属于复合状态的有( )。 A.顺序 B.并发 C.同步 D.异步
+   **答案：AB**
+---
+
+3. 对反应型对象建模一般使用( )。 A.状态图 B.顺序图 C.活动图 D.类图
+   **答案：A**
+---
+
+4. 构成状态图基本模型元素的是( )。 A.状态 B.转移 C.初始状态 D.链
+   **答案：ABC**
+---
+
+5. 构成活动图基本模型元素的是( )。 A.泳道 B.动作 C.对象 D.活动
+   **答案：ABD**
+---
+
+6. 活动图中开始状态标记使用( )。 A.菱形 B.直线箭头 C.实心黑圆 D.空心圆
+   **答案：C**
+---
+
+7. UML中用( )来描述过程或操作的工作步骤。 A.状态图 B.活动图 C.用例图 D.部署图
+   **答案：B**
+---
+
+8. ( )技术是将活动图中的活动状态进行分组。 A.泳道 B.分支 C.分叉与汇合 D.转移
+   **答案：A**
+---
+
+9. 状态图可表示( )在生存期间的行为。 A.一组对象 B.一个对象 C.多个参与者 D.几个子系统
+   **答案：B**
+---
+
+10. 状态图描述对象的状态转移是由不同的( )驱动的。 A.事件 B.对象 C.参与者 D.数据
+   **答案：A**
+---
+
+11. ( )转移符号可分解控制为并行线程或将多线程合并。 A.状态 B.对象 C.活动 D.同步并发
+   **答案：D**
+---
+
+12. 活动图中活动状态间的转移不是由( )触发的。 A.对象 B.事件 C.参与者 D.系统
+   **答案：B**
+---
+
+13. UML需求分析建模中应用( )来细化用例图中的用例。 A.活动图 B.状态图 C.部署图 D.组件图
+   **答案：A**
+---
+
+14. 活动图中分叉和汇合用来描述( )。 A.多进程并发处理 B.对象时序 C.类关系 D.系统架构
+   **答案：A**
+---
+
+15. 描述系统控制机制如设备控制器( )最有用。 A.交互图 B.活动图 C.状态图 D.类图
+   **答案：C**
+---
+
+16. 描述复杂算法( )最有用。 A.活动图 B.状态图 C.类图 D.用例图
+   **答案：A**
+---
+
+17. 对企业内工作流程建模( )最有用。 A.交互图 B.类图 C.活动图 D.部署图
+   **答案：C**
+---
+
+18. 哪个UML视图描述对象的生命周期( )。 A.类图 B.状态图 C.协作图 D.顺序图
+   **答案：B**
+---
+
+19. 可清楚表达并发行为的图形是( )。 A.类图 B.状态图 C.活动图 D.顺序图
+   **答案：C**
+---
+
+20. 汽车有静止和运动状态运动含加速匀速减速子状态共( )状态。 A.2 B.4 C.5 D.6
+   **答案：D**
+
+## 三、判断题（10题）
+
+1. ( ) 行为模型包括顺序图协作图状态图和活动图。
+   **答案：对**
+---
+
+2. ( ) 状态图描述对象在生命周期中随事件发生而改变状态的过程。
+   **答案：对**
+---
+
+3. ( ) 状态可用对象属性值表征也可用一段持续活动表征。
+   **答案：对**
+---
+
+4. ( ) 状态可分为简单状态和复杂状态。
+   **答案：对**
+---
+
+5. ( ) 复合状态必须包含开始子状态和结束子状态。
+   **答案：对**
+---
+
+6. ( ) 转移是状态之间的关系统转移过程中必须执行一个动作。
+   **答案：对**
+---
+
+7. ( ) 活动图中分支和分叉都可表达并发行为。
+   **答案：错**
+---
+
+8. ( ) 活动图与SA中的流程图完全一样。
+   **答案：错**
+---
+
+9. ( ) 状态图和活动图可以互相转换。
+   **答案：错**
+---
+
+10. ( ) 在工具支持下状态图和活动图可实现代码自动生成。
+   **答案：对**
+
+## 四、简答题（7题）
+
+1. 简述状态图和活动图的区别。
+   **答案：状态图重点描述一个对象的状态及转移；活动图重点描述系统工作流程和并发行为。活动图是状态图特殊形式。**
+---
+
+2. 状态图必须要有终态吗举例。
+   **答案：不必。如电话对象只要不坏始终在等待状态永不进终态。**
+---
+
+3. 转移的组成有哪些。
+   **答案：起始状态、目标状态、触发事件、警戒条件、转移动作。**
+---
+
+4. 分支和分叉的区别是什么。
+   **答案：分支根据条件只选一条路径；分叉同时产生多条并发执行路径。**
+---
+
+5. 泳道的功能是什么。
+   **答案：将活动按职责分组每个泳道代表一个责任区。**
+---
+
+6. 历史状态有几种区别是什么。
+   **答案：浅历史状态(只记最外层)和深历史状态(可记任意深度)。**
+---
+
+7. 事件有几种类型信号事件的特点。
+   **答案：4种——调用、信号、变化、时间。信号事件由其他对象异步发送信号类间可泛化扩展性强。**
+
+## 五、分析题（4题）
+
+题2：简单电梯状态图 —— 初始-第一层楼-[上行]向上移动-[到达]等待命令-[上行/下行]移动-[到达]等待命令。
+
+题4：ISPDialer类状态图 —— 组合状态DialingISP-WaitingForDialtone-Dialing-WaitingForCarrier-Connected或NotConnected-结束。
+
+题5：防盗报警系统状态图 —— activate-SystemActive-初始化(并发)-监控(并发)-火警/入侵-报警-复位或结束。
+
+题12：网上药店处方状态图 —— 处方已提交-审核中-准许付款-付款-邮寄-结束。分支：信息无效/无效处方/超时-取消。
+
+
+# 第7章 组件图与部署图
+
+## 一、填空题（12题）
+
+1. 组件是系统中遵从一组（ ___ ）且提供（ ___ ）的物理部件。
+   **答案：接口 / 实现**
+---
+
+2. （ ___ ）用于对系统的静态实现视图建模。
+   **答案：组件图**
+---
+
+3. 组件可分为（ ___ ）、（ ___ ）和（ ___ ）三种。
+   **答案：源代码 / 二进制代码 / 可执行代码**
+---
+
+4. 系统体系结构分为（ ___ ）和（ ___ ）。
+   **答案：逻辑体系结构 / 物理体系结构**
+---
+
+5. （ ___ ）描述处理器设备和软件组件运行时的体系结构。
+   **答案：部署图**
+---
+
+6. （ ___ ）由节点和节点之间的联系组成。
+   **答案：部署图**
+---
+
+7. 软件体系结构分为（ ___ ）和（ ___ ）。
+   **答案：软件系统体系结构 / 硬件系统体系结构**
+---
+
+8. 结点之间结点与（ ___ ）之间的联系包括通信关联依赖关联等。
+   **答案：组件**
+---
+
+9. （ ___ ）是一种只包含从其他包中引入的元素的组件。
+   **答案：虚包**
+---
+
+10. 组件具有两种特征：（ ___ ）和（ ___ ）。
+   **答案：代码特征 / 身份特征**
+---
+
+11. （ ___ ）是软件逻辑体系中定义的概念和功能在物理架构中的实现。
+   **答案：组件**
+---
+
+12. 部署图由（ ___ ）和（ ___ ）组成。
+   **答案：节点 / 节点之间的联系**
+
+## 二、选择题（10题）
+
+1. 组成组件图的元素有( )。 A.接口 B.组件 C.发送者 D.依赖关系
+   **答案：ABD**
+---
+
+2. ( )是系统中遵从一组接口且提供实现的物理部件。 A.部署图 B.组件 C.类 D.接口
+   **答案：B**
+---
+
+3. 系统体系结构描述系统各部分的结构接口及通信( )。 A.机制 B.形式 C.原理 D.结构
+   **答案：A**
+---
+
+4. UML可描述硬件间互联关系也能描述硬件单元上( )的分布。 A.对象 B.软件 C.系统体系结构 D.数据
+   **答案：B**
+---
+
+5. ( )是对系统用例类对象接口及交互协作进行描述。 A.系统体系结构 B.软件逻辑体系结构 C.硬件物理体系结构 D.系统框架
+   **答案：B**
+---
+
+6. ( )是对系统组件结点配置进行描述。 A.软件逻辑体系结构 B.系统体系结构 C.系统框架 D.硬件物理体系结构
+   **答案：D**
+---
+
+7. UML的两种物理表示图形是( )和( )。 A.组件图 B.对象图 C.类图 D.部署图
+   **答案：AD**
+---
+
+8. 组件图中可包含的建模元素有( )。 A.接口 B.包 C.约束 D.依赖关系
+   **答案：ABCD**
+---
+
+9. 银行业务系统部署图分析正确的是( )。 A.GUI类部署在Branch Client B.表示三层体系结构 C.业务逻辑部署在Financial App Server D.业务逻辑部署在Branch Client
+   **答案：ABC**
+---
+
+10. 部署图的组成元素包括( )。 A.处理器 B.设备 C.组件 D.连接
+   **答案：ABD**
+
+## 三、判断题（10题）
+
+1. ( ) 组件也称构件就是可被替换的类。
+   **答案：错**
+---
+
+2. ( ) 软件物理设计中采用的基本单位是类不是组件。
+   **答案：错**
+---
+
+3. ( ) 可根据部署文件源代码文件可执行代码文件来判断组件。
+   **答案：对**
+---
+
+4. ( ) 类的关系决定了组件之间的关系。
+   **答案：对**
+---
+
+5. ( ) 接口可作为把组件绑定在一起的黏合剂。
+   **答案：对**
+---
+
+6. ( ) 一个组件可仅含一个类也可含多个类。
+   **答案：对**
+---
+
+7. ( ) 部署图中结点分为处理机和设备区别在于是否有计算能力。
+   **答案：对**
+---
+
+8. ( ) 部署图中结点之间存在依赖关系。
+   **答案：对**
+---
+
+9. ( ) UML正向工程和逆向工程都基于部署图操作。
+   **答案：错**
+---
+
+10. ( ) 正向逆向工程基于类之间的依赖关系生成代码。
+   **答案：对**
+
+## 四、简答题（4题）
+
+1. 简述建模包含组件的作用。
+   **答案：组件是软件系统部署的基本单元将可重用模块封装成可替代的物理单元。**
+---
+
+2. 组件图和部署图的区别是什么。
+   **答案：组件图显示各组件间的依赖关系；部署图描述硬件环境中这些组件的位置安排。**
+---
+
+3. 什么是结点意义是什么。
+   **答案：结点代表有计算能力的物理设备可驻留组件实例。分处理机和设备两种。**
+---
+
+4. 结点有实例吗可驻留哪些元素。
+   **答案：结点可有实例代表具体物理设备。可驻留组件实例。**
+
+## 五、分析题（2题）
+
+题2：学生管理系统组件图 —— 组件：MainSystem、Form、DataManager、Student、SystemManager及依赖关系。
+
+题4：网上书店系统部署图 —— Web浏览器(IE)--HTTP--Web服务器(Tomcat)--TCP/IP--数据库服务器(Oracle)--TCP/IP--应用程序(MainSystem)。
+
+
+# 第9章 数据建模
+
+## 一、填空题（8题）
+
+1. 关系数据库不能直接存取（ ___ ）须将（ ___ ）映射为二维表格列对应（ ___ ）行对应（ ___ ）。
+   **答案：持久对象 / 暂时对象 / 属性 / 实例或对象**
+---
+
+2. UML（ ___ ）可用于设计（ ___ ）。
+   **答案：类图 / 数据库**
+---
+
+3. 数据库设计涉及3个阶段：（ ___ ）、（ ___ ）、（ ___ ）。
+   **答案：概念设计 / 逻辑设计 / 物理设计**
+---
+
+4. 数据表之间确定性关系是指（ ___ ）构成子表中（ ___ ）的一部分。
+   **答案：外键 / 主键**
+---
+
+5. 数据表之间非确定性关系是指外键（ ___ ）子表中主键的一部分。
+   **答案：不是**
+---
+
+6. 一个（ ___ ）映射为一个（ ___ ）属性变列对象变行。
+   **答案：类 / 表格**
+---
+
+7. 在将UML类图映射成数据库时主要使用（ ___ ）及其之间的（ ___ ）。
+   **答案：实体类 / 关系**
+---
+
+8. 对于关系数据库（ ___ ）是数据库中全体数据的逻辑结构和特征的描述。
+   **答案：模式(Schema)**
+
+## 二、选择题（6题）
+
+1. 持久对象是( )其构造过程的对象。 A.依赖于 B.区别于 C.独立于 D.都不是
+   **答案：C**
+---
+
+2. 在UML数据建模中主要使用( )进行转换。 A.用例图 B.类图 C.对象图 D.组件图
+   **答案：B**
+---
+
+3. 将类图映射成关系数据表时主要使用( )。 A.边界类 B.控制类 C.实体类 D.抽象类
+   **答案：C**
+---
+
+4. 数据库中数据库概念对应UML中( )版型。 A.DataBase B.Schema C.Table D.Domain
+   **答案：A**
+---
+
+5. 必须在( )中创建数据库对象。 A.Use Case View B.Logical View C.Component View D.Deployment View
+   **答案：C**
+---
+
+6. 必须在( )中创建模式。 A.Use Case View B.Logical View C.Component View D.Deployment View
+   **答案：B**
+
+## 三、判断题（10题）
+
+1. ( ) 数据库设计主要用E-R图所以UML无须提供数据建模方法。
+   **答案：错**
+---
+
+2. ( ) 数据库设计核心阶段是物理设计。
+   **答案：错**
+---
+
+3. ( ) UML提供版型符号对应数据库基本概念。
+   **答案：对**
+---
+
+4. ( ) 对象模型和数据模型可相互转换。
+   **答案：对**
+---
+
+5. ( ) 实体类类图可对应成E-R图反之亦然。
+   **答案：对**
+---
+
+6. ( ) Rational Rose中对象模型可自动生成数据表。
+   **答案：对**
+---
+
+7. ( ) 类之间泛化关系不能生成数据表间对应关系。
+   **答案：错**
+---
+
+8. ( ) 非确定性关系不会造成子表随父表删除而删除。
+   **答案：对**
+---
+
+9. ( ) 表间关系主要体现在父表通过外键联系子表。
+   **答案：错**
+---
+
+10. ( ) 对象模型转数据模式时类的持久性不做要求。
+   **答案：错**
+
+## 四、简答题（5题）
+
+1. 对象模型转数据模型时类为什么要设成Persistent。
+   **答案：表示该类需永久保存(实体类)转换时才会生成对应数据库表。**
+---
+
+2. 数据表间非确定性关系和确定性关系是什么。
+   **答案：确定性关系中外键是子表主键一部分删父表则子表也删；非确定性关系中外键不是子表主键一部分删父表不影响子表。**
+---
+
+3. 如何存储永久类之间多对多关系。
+   **答案：新建关联表将两端主键作为外键放入关联表。**
+---
+
+4. 数据表的外键起什么作用。
+   **答案：建立表与表间关联关系引用另一个表的主键。**
+---
+
+5. 举例说明类间关联关系与数据表间联系。
+   **答案：Customer(1)---(0..*)Order则Order表加外键customer_id指向Customer表主键。**
+
+## 五、分析题
+
+图书借阅系统数据建模 —— 从用例图到实体类类图(罚款信息/借阅记录/图书流通细目/图书信息)到Rational Rose转换成的数据模型图(4个表及Identifying/Non-Identifying关系)。
+
+
+# 第11章 Rational统一过程
+
+## 一、填空题（10题）
+
+1. RUP静态结构使用（ ___ ）、（ ___ ）、（ ___ ）和（ ___ ）4种元素表达。
+   **答案：角色 / 活动 / 制品 / 工作流**
+---
+
+2. RUP的5种视图：（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：逻辑视图 / 进程视图 / 部署视图 / 实现视图 / 用例视图**
+---
+
+3. RUP为架构提供（ ___ ）、（ ___ ）和（ ___ ）的系统性方法。
+   **答案：设计 / 开发 / 验证**
+---
+
+4. RUP开发过程使用一种（ ___ ）结构表达。
+   **答案：二维**
+---
+
+5. RUP动态结构通过对（ ___ ）、（ ___ ）及（ ___ ）等描述表示。
+   **答案：周期 / 迭代过程 / 里程碑**
+---
+
+6. RUP 4个阶段：（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）。
+   **答案：初始阶段 / 细化阶段 / 构造阶段 / 移交阶段**
+---
+
+7. 核心过程工作流(6个)：（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）。
+   **答案：业务建模 / 需求捕获 / 分析与设计 / 实现 / 测试 / 部署**
+---
+
+8. 核心支持工作流(3个)：（ ___ ）、（ ___ ）、（ ___ ）。
+   **答案：配置与变更管理 / 项目管理 / 环境**
+---
+
+9. RUP特点：（ ___ ）、（ ___ ）和（ ___ ）。
+   **答案：用例驱动的 / 以体系结构为中心的 / 迭代和增量开发**
+---
+
+10. RUP 6个最佳实践：（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）、（ ___ ）。
+    **答案：迭代增量开发 / 管理需求 / 基于构件的体系结构 / 可视化建模 / 持续验证质量 / 控制变更**
+
+## 二、选择题（6题）
+
+1. RUP最佳实践包括( )。 A.瀑布式 B.迭代式 C.基于构件的架构 D.质量验证
+   **答案：BCD**
+---
+
+2. 迭代过程4个连续阶段有( )。 A.初始 B.分析 C.细化 D.构造
+   **答案：ACD**
+---
+
+3. 以架构为中心的开发需关心架构的( )。 A.目的 B.绘制软件 C.表示 D.过程
+   **答案：ACD**
+---
+
+4. 有效需求管理指( )。 A.应对复杂项目 B.良好用户满意度 C.减少需求错误 D.减少交流
+   **答案：ABCD**
+---
+
+5. 实现RUP步骤有( )。 A.评估当前状态 B.建立明确目标 C.执行过程实现 D.评价过程实现
+   **答案：ABCD**
+---
+
+6. RUP以( )为中心。 A.用例 B.对象 C.类 D.程序
+   **答案：A**
+
+## 三、判断题（10题）
+
+1. ( ) RUP是Rational Unified Process缩写。
+   **答案：对**
+---
+
+2. ( ) RUP核心概念含角色活动制品工作流过程。
+   **答案：错**
+---
+
+3. ( ) RUP生命周期是二维结构横轴时间纵轴开发过程。
+   **答案：对**
+---
+
+4. ( ) RUP最突出特点是用户驱动。
+   **答案：错**
+---
+
+5. ( ) 最佳实践包括迭代增量开发和基于构件的体系结构。
+   **答案：对**
+---
+
+6. ( ) 4阶段按次序初始构造细化移交。
+   **答案：错**
+---
+
+7. ( ) 核心工作流9个其中6个是过程工作流。
+   **答案：对**
+---
+
+8. ( ) RUP可指导敏捷开发模式。
+   **答案：对**
+---
+
+9. ( ) 每阶段都由一个或多个连续迭代组成。
+   **答案：对**
+---
+
+10. ( ) RUP不适合多循环开发模式。
+   **答案：错**
+
+## 四、简答题（7题）
+
+1. RUP的4个阶段是什么。
+   **答案：初始(确定项目范围)、细化(设计架构)、构造(开发所有功能)、移交(部署给用户)。**
+---
+
+2. RUP的9个核心工作流是什么。
+   **答案：6过程——业务建模、需求、分析与设计、实现、测试、部署；3支持——配置与变更管理、项目管理、环境。**
+---
+
+3. RUP如何解决4W。
+   **答案：角色(Role)解决Who；活动(Activity)解决How；制品(Artifact)解决What；工作流(Workflow)解决When。**
+---
+
+4. 简述RUP产生的模型和文档。
+   **答案：模型——用例、分析、设计、配置、实现、测试。文档——技术文档(需求/设计/实现/配置信息集)和管理文档(风险/进度/测试计划)。**
+---
+
+5. 简述RUP的特点。
+   **答案：用例驱动、以体系结构为中心、迭代和增量开发。**
+---
+
+6. 简述RUP的6个最佳实践。
+   **答案：迭代式开发、管理需求、基于构件的体系结构、可视化建模、验证质量、控制变更。**
+---
+
+7. 简述RUP裁剪。
+   **答案：RUP是通用框架需根据项目裁剪。步骤：确定工作流-确定制品-确定阶段间演进-确定迭代计划-规划工作流内部结构。**
+
+
+---
+
+> **刷题建议**：先做填空和选择判断，做完一章对一章答案。简答和分析题最后集中攻克。**总题量约250道**。
diff --git a/速查手册/UML九图速查.md b/速查手册/UML九图速查.md
new file mode 100644
index 0000000..a86cd98
--- /dev/null
+++ b/速查手册/UML九图速查.md
@@ -0,0 +1,101 @@
+# UML九图速查手册
+
+> **用途**：考前快速回顾9种UML图的核心特征  
+
+---
+
+## 📊 九种UML图一句话定位
+
+| 想表达什么？ | 用什么图？ |
+|--------------|-----------|
+| 系统能干什么？ | **用例图** |
+| 系统里有哪些类？它们什么关系？ | **类图** |
+| 某一刻对象的具体情况？ | **对象图** |
+| 对象之间怎么按时间顺序交互？ | **顺序图** |
+| 对象之间怎么在空间上协作？ | **协作图** |
+| 一个对象的状态怎么变化？ | **状态图** |
+| 一个业务流程步骤怎么走？ | **活动图** |
+| 代码文件之间怎么依赖？ | **组件图** |
+| 软件部署在哪些硬件上？ | **部署图** |
+
+---
+
+## 🔗 九图分类
+
+```
+UML图
+├── 功能模型：用例图
+├── 静态模型（结构）：类图、对象图、包图
+├── 动态模型（行为）：顺序图、协作图、状态图、活动图
+└── 物理模型（实现）：组件图、部署图
+```
+
+---
+
+## 📋 九图完整对比表
+
+| 图类型 | 分类 | 描述几个对象？ | 强调 | 核心元素 |
+|--------|------|:---:|------|----------|
+| **用例图** | 功能 | 多 | 系统功能全景 | 参与者、用例、系统边界 |
+| **类图** | 静态结构 | 多 | 类的定义和关系 | 类、属性、操作、关系 |
+| **对象图** | 静态结构 | 多 | 某一时刻的快照 | 对象、属性值、链 |
+| **包图** | 静态结构 | 多 | 类的分组组织 | 包、依赖、泛化 |
+| **顺序图** | 动态交互 | 多 | 消息的时间顺序 | 对象、生命线、控制焦点、消息 |
+| **协作图** | 动态交互 | 多 | 对象的空间位置 | 对象、链、消息（带序号） |
+| **状态图** | 动态行为 | **1个** | 状态如何变迁 | 状态、转移、事件 |
+| **活动图** | 动态行为 | 多 | 流程步骤 | 活动、分支、泳道、分叉 |
+| **组件图** | 物理实现 | 多 | 代码文件组织 | 组件、接口、依赖 |
+| **部署图** | 物理实现 | 多 | 硬件拓扑 | 结点、组件、连接 |
+
+---
+
+## 🎨 各图关键语法速查
+
+### 用例图
+- 参与者 = 火柴人 🧑
+- 用例 = 椭圆 ○
+- 系统边界 = 方框 □
+- 关系：包含 `<<include>>` (必然)、扩展 `<<extend>>` (条件)
+
+### 类图
+- 类 = 三格矩形（类名|属性|操作）
+- 可见性：`+`公有 `-`私有 `#`受保护
+- 六大关系：关联(实线)、聚合(空心菱形)、组合(实心菱形)、依赖(虚线)、泛化(空心三角)、实现(虚线空心三角)
+
+### 顺序图
+- 对象 + 生命线(虚线) + 控制焦点(矩形条) + 消息(箭头)
+- 调用消息 = 实心箭头，异步消息 = 开放箭头
+- 嵌套：1 → 1.1 → 1.1.1
+
+### 协作图
+- 对象 + 链(实线) + 消息(带序号)
+- 必须标注消息序号！没有时间轴
+
+### 状态图
+- 状态 = 圆角矩形，转移 = 箭头
+- 事件/ [条件] / 动作
+- 初始状态 ● → 终态 ⊙
+
+### 活动图
+- 活动 = 圆角矩形
+- 分支 = 菱形 ◇
+- 分叉/汇合 = 粗横线
+- 泳道 = 纵向分区
+
+### 组件图
+- 组件 = 带<<component>>的矩形
+- 关系主要是依赖（虚线箭头）
+
+### 部署图
+- 结点 = 3D立方体
+- 通信路径 = 实线
+
+---
+
+## 📐 MVC版型速查
+
+| 版型 | 图标 | 职责 | 例子 |
+|------|------|------|------|
+| <<boundary>> 边界类 | 带竖线的圆 | 与外界交互 | 登录页面、购物车页面 |
+| <<control>> 控制类 | 带箭头的圆 | 协调逻辑 | 订单处理、支付验证 |
+| <<entity>> 实体类 | 带横线的圆 | 持久化数据 | 用户、订单、商品 |
diff --git a/速查手册/设计原则与术语速查.md b/速查手册/设计原则与术语速查.md
new file mode 100644
index 0000000..662ef3f
--- /dev/null
+++ b/速查手册/设计原则与术语速查.md
@@ -0,0 +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) |