UML 統一塑模語言：什麼時候該畫什麼圖
UML 的價值不是圖本身，而是畫圖時逼你想清楚的那些問題。
先破除一個迷思
很多人對 UML 的印象是：
- 「那是瀑布式開發用的東西，敏捷不需要」
- 「畫圖很花時間，不如直接寫 code」
- 「只有 SA 或架構師才需要會」
這些都是誤解。UML 的本質是 一套標準化的視覺語言，讓你可以用圖形表達程式碼的結構和行為。你不需要畫出完美符合規範的 UML 圖，但你需要知道：什麼樣的問題，用什麼樣的圖最容易想清楚。
UML 的兩大類別
graph TD A[UML 圖] --> B[結構圖<br/>靜態的：東西長什麼樣] A --> C[行為圖<br/>動態的：東西怎麼運作] B --> B1[Class Diagram] B --> B2[Component Diagram] B --> B3[Deployment Diagram] C --> C1[Use Case Diagram] C --> C2[Sequence Diagram] C --> C3[Activity Diagram] C --> C4[State Diagram] style B fill:#2196F3,color:#fff style C fill:#4CAF50,color:#fff
結構圖回答：系統的零件有哪些？它們之間的關係是什麼？ 行為圖回答：這些零件怎麼互動？在什麼條件下做什麼事？
最實用的 5 種圖（按使用頻率排序）
1. Sequence Diagram（循序圖）— 最常用
回答的問題： 一個操作從頭到尾，各個元件之間怎麼互動？
使用者 → 前端 → API Gateway → Auth Service → Database
│ │ │ │ │
│ 點擊登入 │ │ │ │
│────────→│ POST /login │ │ │
│ │────────→│ 驗證 token │ │
│ │ │─────────→│ 查詢使用者 │
│ │ │ │───────→│
│ │ │ │←───────│
│ │ │←─────────│ │
│ │←────────│ │ │
│←────────│ │ │ │
什麼時候該畫：
- 跨多個服務的操作流程
- Debug 時追蹤「request 到底經過了哪些地方」
- Code review 時解釋複雜的呼叫鏈
思維價值： 畫 Sequence Diagram 會逼你想清楚：每一步的 request 和 response 是什麼？哪裡可能超時？哪裡需要錯誤處理？
2. Class Diagram（類別圖）— 最基本
回答的問題： 程式碼的結構是什麼？物件之間是什麼關係？
┌───────────────┐ ┌───────────────┐
│ User │ │ Order │
├───────────────┤ ├───────────────┤
│ - id: number │ │ - id: number │
│ - name: string │ │ - status: enum │
│ - email: string│ │ - total: number│
├───────────────┤ ├───────────────┤
│ + login() │ 1──N│ + submit() │
│ + logout() │ │ + cancel() │
└───────────────┘ └───────────────┘
什麼時候該畫：
- 設計 domain model 的時候
- 理解一個新 codebase 的核心物件關係
- 重構前，先看清楚現有結構
思維價值： 關係的類型很重要——是「擁有」(has-a)、「是一種」(is-a)、還是「使用」(uses)？畫出來後你會發現很多模糊的設計決策。
3. State Diagram（狀態圖）— 最容易忽略但最有用
回答的問題： 一個物件有哪些狀態？怎麼在狀態之間轉換？
stateDiagram-v2 [*] --> Draft Draft --> Submitted : 使用者提交 Submitted --> Approved : 主管核准 Submitted --> Rejected : 主管退回 Rejected --> Draft : 使用者修改 Approved --> InProgress : 開始執行 InProgress --> Completed : 執行完成 InProgress --> Cancelled : 使用者取消 Completed --> [*] Cancelled --> [*]
什麼時候該畫：
- 任何有「狀態」的核心物件（訂單、工單、申請表、文章）
- 你發現 code 裡有很多
if (status === 'xxx')的時候 - Bug 報告裡出現「不應該出現的狀態」
思維價值： 狀態圖會逼你回答：每個狀態可以往哪走？不可以往哪走？什麼條件觸發轉換？這正是最常出 bug 的地方。
4. Use Case Diagram（使用案例圖）— 最適合溝通
回答的問題： 系統有哪些使用者角色？每個角色能做什麼事？
┌─────────────────────────────────┐
│ 電商系統 │
│ │
│ (瀏覽商品) (下訂單) │
│ ↑ ↑ │
訪客 ────┘ 客戶 ──┤ │
│ ├── (查看訂單) │
│ └── (評價商品) │
│ │
│ 管理員 ──┬── (管理商品) │
│ └── (管理訂單) │
└─────────────────────────────────┘
什麼時候該畫：
- 專案初期定義系統範圍
- 權限設計（RBAC）
- 跟非技術人員溝通
思維價值： 逼你從使用者角度出發，而不是從技術角度。「系統能做什麼」和「使用者需要做什麼」是不同的問題。
5. Activity Diagram（活動圖）— 流程圖的進化版
回答的問題： 一個業務流程的步驟是什麼？有哪些分支和並行？
graph TD A[收到訂單] --> B{庫存足夠?} B -->|是| C[扣庫存] B -->|否| D[通知缺貨] C --> E[產生出貨單] C --> F[發送確認信] E --> G[出貨] F --> G G --> H[更新訂單狀態]
什麼時候該畫：
- 複雜的業務流程（審批、結帳、退貨）
- 有並行操作的場景
- 用文字描述不清楚的流程
你不需要畫的圖
UML 有 14 種圖，但在實務中你幾乎不會用到：
- Object Diagram — Class Diagram 的實例化，debug 用 console.log 更直接
- Package Diagram — 看資料夾結構就好
- Communication Diagram — Sequence Diagram 能表達同樣的事
- Timing Diagram — 除非你做嵌入式系統
原則：只在「文字或 code 說不清楚」的時候才畫圖。
工具推薦
| 工具 | 特色 | 適合場景 |
|---|---|---|
| Mermaid | 用文字語法生成圖、可嵌入 Markdown | 日常文件、筆記（Quartz 原生支援） |
| PlantUML | 文字語法、圖類型最齊全 | 詳細的 SA 文件 |
| draw.io | 拖拉式、免費 | 簡報、需要美觀的正式文件 |
| Excalidraw | 手繪風格、即時協作 | 白板討論、探索性設計 |
務實建議： 日常用 Mermaid（直接寫在 Markdown 裡）就夠了。只有需要正式交付文件時才用 draw.io 或 PlantUML。
反思問題
- 你上次畫圖是什麼時候？ 如果想不起來，可能代表你一直在用「寫 code 來思考」——這在簡單問題上沒問題，但複雜問題需要先視覺化。
- 你的系統裡，最核心的物件有狀態圖嗎？ 如果沒有，試著畫一次，你很可能會發現幾個沒處理的狀態轉換。
- 你能不能在 5 分鐘內用 Mermaid 畫出一個功能的 Sequence Diagram？ 這是衡量你對系統互動理解程度的好指標。
- 什麼時候「不畫圖」才是對的？ 如果一句話能說清楚，就不需要圖。過度文件化跟不文件化一樣有害。