UML 是一套"标准化的图形记号"，专门用来在写代码之前描述系统。 它的来历是"三套画法合流"（Booch + OMT + OOSE），1997 年被 OMG 采纳为国际标准；它的定位是表达工具（不是编程语言、不是开发方法）；它的日常用途是沟通、设计、留档三件事。记住一句就够：UML 让"想法"变成"大家都能看懂的图"。
9.3 导言讲了"为什么需要画图"（想法在脑子里，别人看不见）。本节把 UML 这个工具摸清底细：它从哪来、是干什么用的、边界在哪。它和 9.2.3 的关系很近——UML 里最核心的类图，画的正是"封装/继承"这些结构：- 私有、+ 公开就是封装；一根空三角箭头就是继承。本节先把 UML 当作一个整体来认识，具体怎么读类图留给 9.3.2。
一、来历：三套画法合流
UML 不是凭空造出来的，它是"合并同类项"的产物。
时间线：
| 时间 | 发生了什么 |
|---|---|
| 1980s~1990s 初 | 面向对象兴起，各路专家各画各的图：Booch 方法、Rumbaugh 的 OMT、Jacobson 的 OOSE 等 |
| 1994~1995 | Booch 与 Rumbaugh 在 Rational 公司合并各自的方法；随后 Jacobson 加入 |
| 1996 | 三位联合发布初版；同年向业界公开征求意见（一大批公司参与） |
| 1997 | UML 1.0 提交给 OMG（对象管理组织），被采纳为国际标准 |
| 2005 前后 | UML 2.0 发布，图形种类更丰富（目前主流版本） |
为什么必须合流：三套画法各自都能用，但互不相通——换个项目、换个公司，同一张图要重新学一遍符号。这就是"方言太多"的困境。
三位的头衔也顺便记住：Booch、Rumbaugh、Jacobson 被业界合称"三友"（Three Amigos），UML 之父这一称号通常一起给他们三位。
关于 OMG：Object Management Group（对象管理组织），一个制定标准的国际联盟。UML 归它管，所以它是一个"标准"，不是一个"软件产品"。
二、定位：它是"记号系统"，不是"开发方法"
这是本节最需要掰清的一件事。UML 和"怎么开发软件"是两个层面的事：
| UML | 开发方法 / 过程 | |
|---|---|---|
| 回答什么问题 | "用什么符号画图" | "按什么步骤、什么规矩做项目" |
| 例子 | 类图用方框、继承用空三角箭头 | 瀑布模型、敏捷开发、RUP |
| 能单独换吗 | 能。UML 可以配合各种开发方法使用 | 能。用瀑布还是敏捷，都可以用 UML 画图 |
打个比方：UML 像是"工程制图的符号标准"（粗实线表示可见轮廓、虚线表示隐藏轮廓……），而"开发方法"像是"施工的组织流程"（先勘测、再设计、再施工）。两者各管一摊，能自由组合。
三、它能帮你做三件事
| 用途 | 说明 | 场景 |
|---|---|---|
| 沟通 | 让程序员、需求方、测试看着同一张图说话 | 评审会上，指着类图讨论"这个属性该放哪个类" |
| 设计 | 在写代码前把结构想清楚，试错成本低 | 改图上一条线，比改代码里几十行便宜得多 |
| 留档 | 把设计保存下来，将来接手的人能快速看懂 | 半年后回来看这个系统，图还在，不用重新啃代码 |
注意第三件事的价值：代码能说明"怎么做"，但很难说明"为什么这么分"。结构性的意图，图能记住。
四、它的边界：做不到什么
| UML 做不到 | 说明 |
|---|---|
| 不能替代代码 | 画得再好，还是要人写实现 |
| 不能保证设计正确 | 它只说"你画的是什么"，不说"你画得好不好" |
| 不能替代文字说明 | 具体算法、边界条件、异常规则，图里塞不进去，仍要文字 |
| 不是越全越好 | 十几类图不必都画，多数项目只用得上两三张 |
用得好的关键：只画有必要的图。 一个班的学生作业，画一张类图就够了；一个几十人的项目，才需要类图 + 用例图 + 时序图配着来。
五、UML 2.x 的图家族（先认脸，9.3.2 细讲）
结构图（回答"有哪些东西"）：
| 图 | 画什么 |
|---|---|
| 类图 | 类、属性、方法、类之间的关系——最常用 |
| 对象图 | 某一时刻有哪些具体的对象（类的实例快照） |
| 包图 | 把类分组打包（相当于文件夹） |
| 组件图 | 系统由哪些可替换的模块组成 |
| 部署图 | 软件装在哪台机器上（物理部署） |
行为图（回答"它们怎么动"）：
| 图 | 画什么 |
|---|---|
| 用例图 | 谁能用系统做什么（需求阶段主力） |
| 时序图 | 对象之间按时间顺序怎么来回发消息 |
| 活动图 | 流程/步骤（像流程图，能表达并行与分支） |
| 状态图 | 一个对象在哪些状态之间切换（订单：待付款→已付款→已发货） |
| 协作图 | 强调对象之间的连接关系下的消息往来 |
零基础的第一优先级：类图（结构）＋ 用例图（需求）＋ 时序图（配合）。其余认识名字就行。
六、动手 Demo：给"自动售货机"写设计草稿
不写代码，只做 UML 的第一步：找角色 + 列职责。需求一句话描述：
"顾客投币，售货机检查金额够不够，够了就出货并找零。"
第一步：把"名词"圈出来（9.2.2 教的方法）
顾客、售货机、钱币、商品
第二步：给每个角色列"有什么 / 会什么"（先不管对错，列出来再说）
| 候选类 | 属性（有什么） | 方法（会什么） |
|---|---|---|
| 顾客 | 手里的钱 | 投币、取货、拿走找零 |
| 售货机 | 库存、售价 | 收币、判断金额、出货、找零 |
| 商品 | 名称、价格、剩余数量 | 出货（数量 -1） |
| 钱币 | 面额 | ——（先留空） |
看到什么算成功：你能对着这张表说出"主要就是售货机在干活，顾客只是发起者"——这句话就已经是设计判断了。
30 秒实验：问自己两个问题——
- "找零"该写在"顾客"还是"售货机"身上？ → 售货机。因为找零改的是售货机自己的钱箱（9.2.2 的判据："这件事主要改谁的数据，就写在谁身上"）。
- "钱币"这个类有必要吗？
→ 先看需求。如果只关心"金额够不够"，一个
double insertMoney就够了，不需要单独的类；如果还要记录"哪张钞票、有没有假币"，才值得建类。 "这个类有必要吗"——这是建模时最该反复问的一句话。
七、常见误区
- "UML 是一种编程语言 / 一种开发方法"——都不是。它是图形记号标准（描述工具），既不写代码，也不规定你的项目流程。
- "学 UML 就是背十几张图"——没必要。先精两张（类图、用例图），其余用到再学。背完不会用，等于没学。
- "图画得越全越专业"——恰恰相反。画无用的图是浪费（而且很快会过时）。必要、够用、能沟通才是标准。
- "UML 是 Rational / 某公司的私有工具"——不是。它是 OMG 这个国际组织维护的公开标准，很多工具都支持。
- "不画 UML 就没法做面向对象设计"——可以。UML 是表达手段；表达手段可以换（白板草图、Excel 表格列职责，都能起到类似作用）。但"先把结构想清楚再写代码"这个习惯，才是真正不能省的那一步。
自测三问（点开对答案）
1. UML 这个标准的来历是什么？由哪个组织维护？——由 Booch、Rumbaugh、Jacobson 三位的画法**合流**而来，**1997 年被 OMG（对象管理组织）采纳为国际标准**（后来演进到 UML 2.x）。 2. UML 和"开发方法"是什么关系？——**两个层面的事**：UML 是**画图的记号标准**（表达工具），开发方法是**做项目的流程**（瀑布/敏捷等）。**两者可以自由组合，互不替代。** 3. UML 最有价值的三件事是什么？它的边界在哪？——**沟通、设计、留档**；边界是**不能替代代码、不能保证设计正确、不能替代文字细节**，而且**不是越全越好**。- ☐ 9.3.2 统一建模语言的结构（下一节）
相关笔记
- 统一建模语言 —— 上一节：为什么要画图
- 统一建模语言的结构 —— 下一节：图家族全貌 + 类图怎么读
- 面向对象的特点 —— 类图上那些符号（
-/+/继承箭头）背后的概念 - 面向对象编程 —— "找名词"的方法：本节 Demo 用的就是它
- 🔷 C++基础 · 索引 —— 全课路线图