UML之外，还有三种更实用的图

标准是给别人看的，好用才是自己的。

---

UML的尴尬

上一章讲了UML 2.5定义了14种图。

但真实软件工程里，有三种图根本不在UML规范里，使用频率却比很多UML图高得多。

为什么？

因为UML追求标准完备，而工程追求简单好用。

---

1. 系统架构图

比组件图更自由。

画什么

• 系统的顶层组件
• 外部依赖
• 数据流方向

怎么画

方块、圆圈、数据库图标、云图标——随便用。

含义清晰就行，别管UML符号约束。

┌─────────┐      ┌─────────┐
│  Web    │─────→│  API    │
└─────────┘      └─────────┘
                      │
                      ↓
                ┌─────────┐
                │  MySQL  │
                └─────────┘

                ┌─────────┐
                │  Redis  │
                └─────────┘

什么时候用

任何项目的第一个图。

• 项目经理要汇报
• 新成员要上手
• 外部评审要过目

所有人都从架构图开始理解系统。

为什么比UML组件图好用

UML组件图有严格符号约束（lollipop、socket、port），学习成本高。

架构图怎么画都行，沟通效率第一。

---

2. 流程图

比活动图更简单。

画什么

• 开始、结束
• 处理步骤
• 判断分支

怎么画

     开始
       ↓
  提交订单
       ↓
  检查库存
       ↓
   ┌─────┴─────┐
有货？        无货？
  ↓            ↓
扣库存      提示缺货
  ↓            ↓
生成订单      结束
  ↓
  结束

什么时候用

• 描述算法逻辑
• 业务流程
• 决策树

为什么比UML活动图好用

UML活动图有并发语义（fork/join）、泳道维度——画起来麻烦，看起来费劲。

流程图就是白板上的那种图，没有额外概念，追求最大可读性。

---

3. 泳道图

流程图 + 角色分工。

画什么

把流程步骤按谁负责分配到不同泳道里。

跨泳道的箭头 = 交互和交接。

怎么画

┌─────────────┬─────────────┬─────────────┐
│    用户     │   订单服务   │   库存服务   │
├─────────────┼─────────────┼─────────────┤
│             │             │             │
│ 提交订单 ───│             │             │
│             │             │             │
│             │检查库存 ────│             │
│             │             │             │
│             │             │返回库存量───│
│             │             │             │
│             │生成订单 ─────│             │
│             │             │             │
│←──订单ID    │             │             │
│             │             │             │
└─────────────┴─────────────┴─────────────┘

什么时候用

跨团队协作流程。

比如在agent-wrapper系统中：

• 用户泳道：发起请求
• Agent Runtime泳道：调度、执行
• LLM Provider泳道：推理
• Tool Registry泳道：工具调用

一眼就能看出谁在什么时候干什么。

为什么比UML序列图好用

序列图强调时序，但角色关系不够直观。

泳道图把角色横向铺开，责任边界一目了然。

---

三种图，三个场景

图	用在哪	核心价值
系统架构图	项目启动、汇报、新人上手	全局视角，一眼看懂系统长什么样
流程图	算法、业务流程、决策树	逻辑清晰，不含额外概念
泳道图	跨角色协作、系统集成	责任明确，交接点清晰

---

为什么这三种图不在UML里？

因为UML追求形式化——

• 符号要有严格定义
• 语义要有精确规范
• 工具要能自动解析

但工程需要的是实用主义——

• 白板随手能画
• 会议即时能改
• 跨职能能看懂

标准是给别人看的，好用才是自己的。

---

AI时代怎么画？

以前画这些图要拖拽工具，现在AI生成飞快：

• 描述架构 → AI生成架构图
• 描述流程 → AI生成流程图
• 描述角色分工 → AI生成泳道图

工具推荐：

• Mermaid — Markdown直接嵌入，GitHub原生支持
• PlantUML — 文本生成图，IDEA插件友好
• draw.io — 可视化拖拽，导出格式全

---

实操建议

1. 先画架构图

任何项目，第一张图一定是架构图。

没有架构图，就没有全局视角。

2. 流程图别太深

超过三个判断分支，就拆成多个子流程。

太深的流程图，没人看得下去。

3. 泳道图控制角色数

超过5个泳道，图就乱了。

把相关的角色合并，或者拆成多个子图。

4. 用对工具

• 快速沟通 → Mermaid/PlantUML（文本即图）
• 正式文档 → draw.io（排版精美）
• 白板讨论 → 手画（拍照留存即可）

---

最后

UML是标准语言，但不是唯一语言。 " 真实工程里，这三种"非标准图"用得更多——

因为它们更简单、更直接、更接地气。

画图的目的是沟通，不是为了考UML证书。

能让人一眼看懂的图，就是好图。

---

关注公众号 Fen9Pi，聊聊软件工程的实用主义。