# 《UML 建模、设计与分析：从新手到高手》知识点全解

> AI生成｜2026年10月29日｜codebuddy｜原书：夏丽华《UML 建模、设计与分析：从新手到高手》，清华大学出版社，2019-04-01
> **我的阅读**：进度 100%｜累计 2小时18分钟｜开始 2024-03-20｜最近 2024-04-07｜读完 2024-04-04

**一句话总结**：把 UML 从"一堆图形符号"变成一条从需求到代码的可追溯链路——用用例锁定范围，用类图/对象图/包图固化静态结构，用活动图/顺序图/状态机描述行为，用组件图/部署图落到实现，再用 RUP 把这些图排进迭代节奏。

**适合谁 / 前置知识**：适合要写需求文档、做概要设计、需要和开发或客户对齐系统边界的学生与初中级工程师；书中示例涉及 C++，因此至少需要面向对象基础（类、对象、继承、多态）。不适合想要符号大全式速查手册的人（那更像 Fowler《UML 精粹》），也不适合只写业务代码、不参与设计沟通的人——对他们收益仅在"看懂别人给的图"。

## 一、全书地图

| 篇 | 章节 | 主题 | 在建模链路中的角色 |
| --- | --- | --- | --- |
| 准备篇 | 第1章 | UML 概述：认识 UML、UML 的组成、视图与通用机制、RUP、面向对象开发 | 建立语言与过程的总框架 |
| 准备篇 | 第2章 | 常用建模工具、Rational Rose 建模与基本操作、双向工程 | 把符号落到工具操作 |
| 基础篇 | 第3章 | 用例和用例图（构成、关系与描述、绘制、BBS 实例） | 需求：系统边界与外部交互 |
| 基础篇 | 第4章 | 类图（概念、泛化、依赖与实现、关联、绘制、BBS 实例） | 静态结构：领域类与设计类 |
| 基础篇 | 第5章 | 对象图和包图 | 静态结构：实例快照与模块分区 |
| 基础篇 | 第6章 | 活动图（元素、控制节点） | 行为：业务流程与操作逻辑 |
| 基础篇 | 第7章 | 顺序图（构成元素、建模与执行） | 行为：对象按时间协作 |
| 基础篇 | 第8章 | 通信图和时序图（操作消息、时间约束） | 行为：交互的结构视角与时限视角 |
| 基础篇 | 第9章 | 状态机图（转移、组合状态） | 行为：单个对象的生命周期 |
| 基础篇 | 第10章 | 组件图和部署图 | 实现视图：软件单元与物理节点 |
| 基础篇 | 第11章 | 组合结构图和交互概览图 | 结构细化与交互串联 |
| 应用篇 | 目录未完整列出 | 简介所列为：UML 与 RUP、对象约束语言、UML 扩展机制、UML 与数据库设计、基于 C++ 的 UML 模型实现、UML 与建模、Web 应用程序设计、嵌入式系统设计 | 把模型接到过程、约束、代码与具体领域 |

三条逻辑线交织：**语言线**（第1章打底，第3—11章逐图展开）、**过程线**（1.4 的 RUP 与应用篇的 RUP 呼应）、**落地线**（第2章工具与双向工程、应用篇的数据库/C++/Web/嵌入式）。要强调的是，第3—11章不是流水线工序，而是同一系统的不同切面：改一处需求，用例、类、顺序图可能同时要改。

## 二、核心知识点

### 1. UML 是建模语言，不是开发过程
**是什么**：UML 提供一套图形符号与语义（事物、关系、各种图），用于描述、可视化、构造和文档化软件系统；它不规定你按什么步骤、分几个阶段做。
**为什么重要**：把"语言"和"过程"混为一谈，最常见的后果是图画得很漂亮却不知道下一步做什么，或者以为用了 UML 就自动有了工程纪律。
**怎么用**：把 UML 当名词和语法，把 RUP 或敏捷当动词和流程。同一张类图，放在 RUP 细化阶段是架构基线，放在敏捷某一轮迭代里就是当轮设计草图，符号完全一样。
**常见误区**：把图种当检查清单，十几张图全画一遍。图是给人看的沟通工具，没有读者的图不必画。

### 2. 视图与通用机制：一个系统要多个切面才说得清
**是什么**：用一组互相补充的视图描述系统（常见的是逻辑视图、进程视图、实现视图、部署视图，再由用例视图串起来）；通用机制包括规格说明（图背后的文字）、修饰（可见性等）、通用划分，以及扩展机制——构造型 `<< >>`、标记值、约束。
**为什么重要**：任何单一图必然片面；扩展机制让 UML 在不改元模型的前提下适配具体领域，这是它活到今天的原因。
**怎么用**：给类打 `<<boundary>>`、`<<control>>`、`<<entity>>` 区分边界/控制/实体；用 `{约束}` 写"同一用户不可重复报名"。
**常见误区**：构造型随手起名、团队没有统一词汇表，图就退化成个人笔记。

### 3. 用例图：画的是边界，不是功能清单
**是什么**：参与者（Actor，可以是人或外部系统）、用例（系统提供给参与者的一個价值单元）、系统边界，以及它们之间的关系。
**为什么重要**：它回答"系统做什么、为谁做、不做什么"，是范围管理和验收测试的源头。
**怎么用**：先找参与者（谁用、谁维护、谁提供数据），再为每个参与者找他的目标，一个目标就是一个用例。BBS 例：游客、注册用户、版主、管理员；用例为发帖、删帖、置顶、封禁。
**常见误区**：把"登录""查询数据库"当用例——前者是多个用例的公共步骤，后者是实现细节；把系统内部模块画成参与者。

### 4. 用例关系与用例规约：图只是索引
**是什么**：用例之间有包含（include，抽取必然执行的公共片段）、扩展（extend，在特定条件下追加行为）、泛化；每个用例还应配一份文字规约：前置条件、基本流、备选流/异常流、后置条件。
**为什么重要**：图上看不出分支和失败路径，而需求缺陷绝大多数藏在备选流里。
**怎么用**：删帖用例的基本流写正常删除，备选流写"无权限""帖子已被删除""需通知作者"，每条备选流都要有终点。
**常见误区**：include 与 extend 的箭头画反（包含箭头指向被包含者，扩展箭头指向被扩展者）；用 include 表达"函数调用"；只交图不交流。

### 5. 类图：属性、操作与可见性
**是什么**：类由名称、属性、操作三格组成，可见性用 `+ - # ~` 表示 public/private/protected/package；抽象类与抽象操作用斜体。
**为什么重要**：类图是静态结构骨架，直接对应代码里的类型定义，是"模型能生成代码"的前提。
**怎么用**：属性写 `名称: 类型 = 默认值`，操作写 `名称(参数): 返回类型`；先画领域类（业务概念），再画设计类（加入技术职责）。
**常见误区**：把数据库字段一比一搬成属性却漏掉行为；把界面控件当领域类；属性里塞集合却不标多重性。

### 6. 六种关系与强度阶梯
**是什么**：依赖（虚线箭头，临时使用）、关联（实线，结构连接，可带导航性与多重性）、聚合（空心菱形，整体—部分，部分可独立存在）、组合（实心菱形，强整体—部分，生命周期绑定）、泛化（实线空心三角，is-a）、实现（虚线空心三角，类实现接口）。
**为什么重要**：关系强度决定耦合度和代码形态——是成员变量、方法参数、继承还是接口实现。
**怎么用**：BBS 中"用户—帖子"是 1 对多关联，"帖子—附件"适合组合，"版主—用户"是泛化，"控制器—服务"常是实现。
**常见误区**：聚合与组合凭感觉选；关联一律画双向（应默认单向优先）；把"只用一次"的依赖画成关联。

### 7. 对象图与包图：快照与分区
**是什么**：对象图是某一时刻的对象实例及它们之间的链接，写成 `对象名: 类名` 并可标属性值；包图用包及包间依赖组织大模型。
**为什么重要**：对象图能验证多重性与结构是否真的可实例化；包图控制复杂度，避免"一张图上百个类"。
**怎么用**：用对象图举例"用户 A 收藏了帖子 P1、P2"来验证 1..*；包按层（界面/业务/数据）或按子域划分，依赖箭头单向、不成环。
**常见误区**：包图只画框不画依赖；包间循环依赖，等于没有分层；对象图漏实例名，退化成一堆类框。

### 8. 活动图：流程与控制节点
**是什么**：用动作、控制流、对象流描述流程；控制节点包括初始/终止、判定（菱形）与合并、分叉（fork）与汇合（join）；泳道按负责者分区。
**为什么重要**：适合表达业务过程、用例内部逻辑和复杂算法步骤，是和业务方对齐"怎么走"的最佳图。
**怎么用**：发帖流程——登录校验 → 判定是否登录 → 填写内容 → 提交 → 分叉（存库 / 更新索引）→ 汇合 → 提示成功；泳道分用户、前端、后端。
**常见误区**：用它替代状态机（活动图说"做哪些步骤"，状态机说"对象处于什么状态"）；判定只有一个出边；fork 与 join 数量不配对。

### 9. 顺序图：时间轴上的交互
**是什么**：参与者与对象横向排列，生命线垂直向下，消息按时间自上而下；激活条表示执行期；组合片段 alt（分支）、opt（可选）、loop（循环）、par（并发）。
**为什么重要**：把一个用例场景展开成对象协作，能暴露职责分配错误和缺失的接口。
**怎么用**：为每个用例的"基本流 + 关键备选流"各画一张；消息名应能对应到目标类的操作，这正好反向校验类图。
**常见误区**：把所有分支塞进一张图（应拆场景或用 alt）；只画同步调用漏掉返回与异步；生命线上的对象在类图里找不到。

### 10. 通信图与时序图：同一语义的不同投影
**是什么**：通信图（旧称协作图）强调对象间的链接和编号消息，空间布局优先；时序图（timing diagram）强调状态或条件随时间的取值变化与时间约束。
**为什么重要**：通信图便于看"谁和谁有连接、耦合有多密"；时序图适合硬实时场景（如嵌入式）核对时限。
**怎么用**：先用顺序图理清时序，再用通信图看结构耦合；对有截止时间的信号用时序图标注约束。
**常见误区**：以为它们是不同模型（UML 中顺序图与通信图语义等价，可互转）；通信图消息编号混乱，读不出先后。

### 11. 状态机图：一个对象的生命周期
**是什么**：状态、转移（事件 `[守卫]` / 动作）、初态与终态、组合状态与并发状态；适合描述反应式对象，如订单、ATM、网络连接。
**为什么重要**：把散落在 if-else 里的状态判断显式化，从机制上排除非法迁移。
**怎么用**：ATM——空闲 → 插卡 → 验证（密码错误且次数 < 3 回到验证）→ 选择交易 → 出钞 → 退卡；守卫写 `[余额充足]`。
**常见误区**：给无状态的服务类硬画状态机；漏掉取消、超时、异常转移；不分 entry/do/exit 动作。

### 12. 组件图与部署图：从逻辑走到物理
**是什么**：组件图描述可替换的软件单元（构件）、它提供与所需的接口、端口；部署图描述节点（设备或执行环境）、节点上的制品以及节点间的通信连接。
**为什么重要**：逻辑模型回答不了"发布成几个包、跑在几台机器、走什么协议"，这两张图补上实现视图。
**怎么用**：BBS 拆成门户包、社区服务、检索服务；部署图写 Web 服务器、应用服务器、数据库服务器，并标注 HTTP 与数据库连接。
**常见误区**：组件图画成类图（组件是部署单元，粒度更粗）；部署图漏协议和网络边界；把"一台服务器"当成一个组件。

### 13. 组合结构图与交互概览图：细化与串联
**是什么**：组合结构图描述类或组件的内部结构——部件、端口、连接器，把黑盒打开成白盒；交互概览图用控制流把多个交互串起来，形成完整场景。
**为什么重要**：大系统只能"先分块、再逐块展开"，这两张图正是分层细化和场景编排的工具。
**怎么用**：给订单服务画内部结构（定价、库存、支付部件与端口）；用交互概览把"下单—支付—发货"三段交互连成一条流。
**常见误区**：一上来就画到最细（应逐层展开）；把交互概览当活动图画（它串的是交互，不是动作）。

### 14. RUP：用例驱动、以架构为中心、迭代增量
**是什么**：Rational 统一过程，按初始、细化、构建、转移四个阶段组织，每阶段包含多轮迭代；核心工作流覆盖业务建模、需求、分析与设计、实现、测试、部署，外加配置与变更管理、项目管理、环境。
**为什么重要**：它回答"什么时候画哪种图、画到什么程度"，把十几种图组织成有节奏的活动，而不是一次性交一堆文档。
**怎么用**：初始阶段用用例图和关键用例规约定范围；细化阶段用类图与顺序图做架构基线；构建阶段用组件图、部署图对接实现与测试。
**常见误区**：把 RUP 当瀑布（它是迭代的，每阶段有里程碑和退出准则）；企图一次把所有图做全再开工。

### 15. OCL、扩展机制与双向工程：让模型可校验、可落地
**是什么**：OCL 是附着在模型元素上的约束语言（`inv` 不变式、`pre`/`post` 前后置条件），补图形表达不了的规则；扩展机制让 UML 适配领域与工具；双向工程指模型正向生成代码与代码逆向同步回模型。
**为什么重要**：没有约束的模型只是草图；没有代码映射的模型很快与实现脱节。
**怎么用**：写 `context 用户 inv 唯一邮箱: ...`；给实体类打 `<<entity>>` 让生成器识别；用逆向工程把遗留代码导入模型做重构分析。
**常见误区**：业务规则只写进 Word 不进模型；指望双向工程全自动——通常需要生成标记，并小心不要覆盖手写代码。

## 三、关键概念速查表

| 概念 | 一句话解释 | 用在哪儿 |
| --- | --- | --- |
| 参与者（Actor） | 与系统交互的人或外部系统 | 用例图起点，界定系统边界 |
| 用例（Use Case） | 系统为参与者提供的一个完整价值单元 | 需求范围、验收测试依据 |
| include / extend | 必执行的公共片段 / 条件下追加的行为 | 复用用例步骤、描述可选需求 |
| 用例规约 | 前置条件 + 基本流 + 备选流 + 后置条件 | 把图补成可开发的需求 |
| 泛化 | is-a 关系，子类可替换父类 | 类层次、用例抽象 |
| 关联 / 多重性 | 类之间的结构连接及数量约束（1、0..1、1..*、*） | 表达"一个用户多条帖子" |
| 聚合 / 组合 | 弱整体—部分 / 生命周期绑定的强整体—部分 | 区分部件能否独立存在 |
| 依赖 | 临时使用，一方变化影响另一方 | 表达弱耦合、参数级引用 |
| 实现 | 类实现接口，虚线空心三角 | 面向接口编程 |
| 对象图 | 某时刻的实例与链接快照 | 验证多重性与结构可行性 |
| 包图 | 用包和包间依赖组织模型 | 分层、划分子域、控制复杂度 |
| 活动图 | 动作 + 控制流 + 对象流 + 泳道 | 业务流程、用例内部逻辑 |
| 顺序图 | 按时间排列的消息交互，含 alt/loop/opt | 展开用例场景、校验职责分配 |
| 通信图 | 以链接为中心、消息带编号的交互图 | 观察对象间耦合密度 |
| 时序图 | 状态/条件随时间变化的图 | 实时与嵌入式时限分析 |
| 状态机图 | 状态 + 转移（事件/守卫/动作） | 订单、ATM、连接等反应式对象 |
| 组件图 | 构件、提供/所需接口、端口 | 划分可替换的软件单元 |
| 部署图 | 节点、制品、节点间通信 | 上线拓扑、协议与网络边界 |
| 组合结构图 | 类或组件的内部部件与连接器 | 打开黑盒、分层细化 |
| 交互概览图 | 用控制流串联多个交互 | 编排跨用例的完整场景 |
| RUP | 四阶段、九工作流、用例驱动、迭代增量 | 决定何时画何种图 |
| OCL | 模型上的约束与前后置条件语言 | 表达图形画不出的业务规则 |
| 双向工程 | 模型生成代码、代码反哺模型 | 保持设计与实现一致 |

## 四、可复用的方法/框架

**建模五步法**：定范围（参与者 + 用例图）→ 定场景（核心用例写规约，基本流加备选流）→ 定结构（先领域类图，再设计类图）→ 定行为（按需选顺序图、活动图、状态机图）→ 定落地（组件图、部署图、代码映射）。每一步的产出都应能被下一步直接引用。

**选图判断清单**——只问一个问题："我这张图要回答什么？"
- 谁使用系统、系统边界在哪 → 用例图
- 系统里有哪些概念、它们怎么关联 → 类图
- 这个流程分几步、谁负责哪步 → 活动图
- 谁在什么时刻给谁发什么消息 → 顺序图 / 通信图
- 这个对象一生会经历哪些状态 → 状态机图
- 发布成什么、跑在哪里 → 组件图 / 部署图
一个问题一张图；答不上来就不画。

**关系强度自检**：临时用一下 → 依赖；长期持有 → 关联；整体没了部分也活不了 → 组合；部分可独立 → 聚合；is-a → 泛化；可替换实现 → 实现。

**模型质量四问**：这张图有明确读者吗？图与图之间的元素命名一致吗？备选流和异常路径覆盖了吗？能不能据此写出接口签名？

**粒度控制**：一张图的元素数量控制在一屏可读；超了就分包或分层展开，先组合结构图再逐块细化。

## 五、我的阅读轨迹

| 项目 | 数据 |
| --- | --- |
| 阅读进度 | 100% |
| 累计阅读时长 | 2小时18分钟 |
| 开始阅读 | 2024-03-20 |
| 最近阅读 | 2024-04-07 |
| 读完时间 | 2024-04-04 |

最近阅读时间晚于读完时间，属于读完后回看补记，不必当成数据异常。

**复习建议**：全书 19 章只用 2 小时 18 分读完，属于速读——符号大概率记住了，"什么时候用哪张图"的判断未必建立。重点回看三处：第4章（六种关系的强度差别）、第7—9章（顺序图/通信图/状态机图的选用边界）、1.4 节（RUP 各阶段与图的对应）。复习方式不是重读，而是拿一个小系统从用例图重画到部署图，画不动的地方再回查对应章节。

## 六、行动清单

- 选一个熟悉的小系统（博客或 BBS），画参与者与用例图，用例控制在 10 个以内。
- 为其中 2 个核心用例写规约，每个至少列出 3 条备选流。
- 画一张类图，标全所有多重性，再逐条核对关系强度是否用错。
- 为 1 个用例画顺序图，确保每条消息都能对应类图里的一个操作。
- 给一个有生命周期的对象（订单或账号）画状态机图，专门列出非法迁移。
- 用包图给模型分层，检查是否存在循环依赖并消除。
- 画组件图与部署图，在连接线上标出协议。
- 用 OCL 写 3 条不变式，替换文档里口语化的业务规则。

## 七、延伸阅读

1. **《UML 精粹》（Martin Fowler）**——先读。符号与用法的速查手册，补本书在图种细节上的省略，适合放在手边随查。
2. **《UML 和模式应用》（Craig Larman）**——次读。把用例、领域模型、GRASP 职责分配和迭代开发串成一条线，正好补上本书"图会画但不会设计"的缺口。
3. **《领域驱动设计》（Eric Evans）**——后读。把类图和包图向上抽象到限界上下文与聚合，适合中大型系统；没有前两本的图与职责基础，直接读容易空转。

顺序理由：先解决"符号怎么画"（精粹），再解决"职责怎么分"（Larman），最后解决"边界怎么划"（DDD）。倒过来读，会把战术图案误当成架构。