第 2 章 · 系统分析与设计（UML · 设计模式）
考点梳理
2.1 需求工程要点
- 过程：获取 → 分析 → 规格说明（SRS）→ 验证；需求变更须走变更控制；
- 分类：功能需求（系统做什么）与非功能需求（性能、可用性、安全性等质量属性）——非功能需求是架构设计的核心输入。
2.2 UML 图（结构图 vs 行为图）
| 类别 | 图 | 用途 |
|---|---|---|
| 结构图 | 类图 | 类、属性、方法与关系（关联/聚合/组合/继承/依赖） |
| 结构图 | 对象图、构件图、部署图 | 实例快照、构件组织、物理部署 |
| 行为图 | 用例图 | 参与者与系统功能（需求阶段） |
| 行为图 | 时序图（顺序图）、协作图 | 对象间交互与消息顺序 |
| 行为图 | 活动图、状态图 | 业务流程/并发、对象状态变迁 |
记忆锚：类图看结构、用例看需求、时序看交互、活动看流程、状态看变迁。
2.3 设计模式三大类（高频）
| 类别 | 目的 | 典型模式 |
|---|---|---|
| 创建型 | 对象创建的解耦 | 工厂方法、抽象工厂、单例、建造者、原型 |
| 结构型 | 类/对象的组合结构 | 适配器、桥接、组合、装饰器、外观、享元、代理 |
| 行为型 | 对象间职责分配与算法 | 职责链、命令、解释器、迭代器、中介者、备忘录、观察者、状态、策略、模板方法、访问者 |
- 外观（Facade）：为子系统提供统一入口，简化调用；
- 适配器（Adapter）：转换接口以兼容不匹配的类；
- 策略（Strategy）：封装可互换算法，运行时切换；
- 观察者（Observer）：一对多依赖，状态变化自动通知（发布-订阅）。
2.4 基于架构的软件设计（ABSD/ADD 思路）
- ABSD：以功能分解 + 架构风格选择 + 软件模板为基础，自顶向下、递归细化；
- ADD（属性驱动设计）：从质量属性场景出发，逐步选择战术（tactics）满足属性需求；
- 核心思想：架构设计由需求（尤其质量属性）驱动，而非仅由功能驱动。
🧠 记忆工具箱
口诀速记
- 设计模式三类：创建（怎么new）、结构（怎么组合）、行为（怎么分工）；
- 常用模式一句话：外观给统一入口、适配器转接口、装饰器加功能、代理做控制、策略换算法、观察者做通知；
- 需求两类：功能（做什么）+ 非功能（做得怎样）——后者决定架构选型。
例题（带解析）
例题 1：某系统需要在不修改原有子系统代码的前提下，为其提供统一、简化的调用入口。最合适的设计模式是？ A. 适配器 B. 外观 C. 装饰器 D. 观察者 答案 B。解析：外观模式为复杂子系统提供统一的高层接口，简化客户端调用；适配器解决接口不兼容，装饰器动态增加职责。
例题 2：某系统支持多种计价算法并需在运行时切换。最合适的设计模式是？ A. 策略 B. 单例 C. 代理 D. 组合 答案 A。解析：策略模式把可互换算法封装为独立类并可在运行时切换；单例控制实例数量，代理控制访问，组合表达整体-部分结构。
⚠️ 易错提醒
- 聚合 vs 组合：聚合是弱整体-部分（生命周期独立），组合是强整体-部分（同生共死）；
- 装饰器 vs 代理：装饰器为增强功能，代理为控制访问（权限、延迟加载、远程调用）；
- 适配器 ≠ 桥接：适配器解决已有接口不匹配，桥接是设计期将抽象与实现分离；
- 非功能需求是架构设计的关键输入，案例题问"为什么这样设计"时优先从质量属性回答。