画图容易懂图难：UML到底有几种图？
画图容易懂图难：UML到底有几种图？
你以为UML就是类图？其实它有14种图。
一句话概括
UML（Unified Modeling Language）是软件界的通用图纸语言。 " 就像建筑有平面图、立面图、电路图一样，软件也有不同的"视角"——
静态长什么样（结构）
动态怎么跑（行为）
UML 2.5.1（2017年）定义了 14 种图，分两大类。
结构性图形：系统的骨架
描述"有哪些东西"、"怎么组织的"。
1. 类图（Class Diagram）
最常用。
描述类、接口、继承、关联——是面向对象设计的核心。
┌─────────────┐
│ User │
├─────────────┤
│ - id: Long │
│ - name: String│
├─────────────┤
│ + login() │
│ + logout() │
└─────────────┘2. 对象图（Object Diagram）
类图的"快照"——某一时刻，系统里有哪些对象、它们的状态是什么。
3. 组件图（Component Diagram）
描述系统的物理组成——有哪些模块、库、文件。
[订单服务] ──→ [数据库驱动]
│
└──→ [支付模块]4. 部署图（Deployment Diagram）
描述硬件拓扑——服务装在哪台机器上、网络怎么连。
┌─────────────┐
│ 应用服务器 │
│ ┌────────┐ │
│ │订单API │ │
│ └────────┘ │
└─────────────┘
│
↓
┌─────────────┐
│ 数据库服务器│
└─────────────┘5. 包图（Package Diagram）
描述模块的层级关系——哪个包在哪个包下面、依赖关系是什么。
6. 组合结构图（Composite Structure Diagram）
描述一个类内部是怎么组成的——一个类里面嵌套了哪些子组件。
7. 外廓图（Profile Diagram）
用于扩展UML——定义自己的 stereotype、tagged value，给特定领域定制。
行为性图形：系统的动态
描述"怎么运行"、"怎么交互"。
8. 用例图（Use Case Diagram）
从用户视角描述系统能干什么。
┌──────┐
│ 用户 │
└──┬───┘
│
├──→ 登录
├──→ 下单
└──→ 查询订单9. 活动图（Activity Diagram）
流程图。描述业务流程、算法步骤。
开始 → 提交订单 → 检查库存 → [有货] → 扣库存 → 生成订单 → 结束
↓
[无货] → 提示缺货 → 结束10. 状态机图（State Machine Diagram）
描述一个对象的生命周期——状态怎么流转、什么事件触发变化。
[待支付] ──支付成功──→ [已支付]
↑ ↓
取消订单 [已发货] ──确认收货──→ [已完成]11. 序列图（Sequence Diagram）
第二常用。
描述对象之间怎么交互——谁先调谁、返回什么、时序是什么。
用户 订单服务 库存服务
│ │ │
│──下单──→│ │
│ │──检查库存─→│
│ │←─────OK────│
│ │←────OK─────│
│←─订单ID─│ │12. 通信图（Communication Diagram）
跟序列图类似，但强调对象关系，不强调时序。
13. 时序图（Timing Diagram）
描述时间约束——某个事件在什么时候发生、持续多久。
14. 交互概览图（Interaction Overview Diagram）
活动图 + 序列图的混合体——在流程图的节点里嵌套交互细节。
现实中用哪些？
14种图里，真正常用的就几个：
| 图 | 使用频率 | 什么时候用 |
|---|---|---|
| 类图 | ⭐⭐⭐⭐⭐ | 设计阶段、代码review |
| 序列图 | ⭐⭐⭐⭐ | 接口设计、排查问题 |
| 用例图 | ⭐⭐⭐ | 需求分析、对齐理解 |
| 活动图 | ⭐⭐⭐ | 梳理业务流程 |
| 状态机图 | ⭐⭐ | 有复杂状态逻辑时 |
| 部署图 | ⭐⭐ | 架构设计、运维 |
| 组件图 | ⭐⭐ | 模块划分 |
其他图——知道就行，用时再查。
AI时代的UML
以前画UML是手艺活，现在有了AI工具：
PlantUML + Mermaid + AI辅助
你描述逻辑，AI生成图；你改需求，AI更新图。
但图背后的思考，AI替不了你：
- 类关系是继承还是组合？
- 这段流程是并行还是串行？
- 这个状态是主动流转还是被动触发？
实操建议
1. 不是所有图都要画
选能最清晰表达问题的那一个。
- 想表达"类怎么协作" → 序列图
- 想表达"流程怎么走" → 活动图
- 想表达"系统长什么样" → 类图/组件图
2. 别太细
UML是沟通工具，不是写代码。
把核心逻辑画清楚就行，太细反而没人看。
3. 用对工具
- PlantUML — 文本生成图，Git友好
- Mermaid — Markdown直接嵌入
- draw.io — 可视化拖拽
4. 跟代码保持一致
图过时了比没图更糟。
每次重构，顺手更新图；或者让AI从代码反向生成图。
最后
UML不是考试，是共同语言。
当你能在白板上随手画出一个清晰的序列图、类图——
产品经理能看懂，开发能对齐，测试能写用例。
这就是工程化的价值。
关注公众号 Fen9Pi，聊聊软件工程与AI。