先講結論
UML 有 14 種圖，但實戰中 90% 的設計溝通只需要這 5 種：
- Class Diagram（類別圖）— 結構設計
- Sequence Diagram（循序圖）— 流程設計
- Use Case Diagram（用例圖）— 需求確認
- State Machine Diagram（狀態機圖）— 狀態管理
- Activity Diagram（活動圖）— 流程文件
其他 9 種不是不存在，而是它們解決的問題在現代開發情境中通常有更輕量的替代方案，或者只有特定領域才用得到。
UML 是什麼
UML（Unified Modeling Language）是 1997 年由 Booch、Rumbaugh、Jacobson 三人在 Rational Software 整合的圖形化建模語言，後來成為 OMG 的國際標準。
UML 2.x 版本定義了 14 種圖，分成三大類：
| 類型 | 圖形 | 核心問題 |
|---|---|---|
| 結構圖（Structural） | Class / Component / Object / Package / Deployment / Composite Structure / Profile | 系統由什麼組成 |
| 行為圖（Behavioral） | Use Case / Activity / State Machine | 系統做什麼 |
| 互動圖（Interaction） | Sequence / Communication / Timing / Interaction Overview | 元件怎麼互動 |
結構圖（Structural Diagrams）
Class Diagram 類別圖
用途：描述類別的屬性、方法、以及類別間關係。物件導向設計的核心工具。
主要元素：
類別：矩形三欄（類別名稱 / 屬性 / 方法）
關係符號：
──────→ 關聯（Association）
──────▷ 繼承（Inheritance / Generalization）
- - - -▷ 實現（Realization / implements interface）
◇────── 聚合（Aggregation）部分可獨立存在
◆────── 組合（Composition）部分不可獨立存在
- - - -→ 依賴（Dependency）
多重性標示：
1 → 恰好一個
0..1 → 零或一個
* → 零或多個
1..* → 一個或多個
0..n → 零到 n 個
現代工具：PlantUML、Mermaid Class Diagram、draw.io
classDiagram class Order { +int id +string status +decimal total +createOrder() +cancelOrder() } class OrderItem { +int quantity +decimal unitPrice } class Product { +int id +string name +decimal price } class User { +int id +string email } User "1" --> "0..*" Order : 下 Order "1" *-- "1..*" OrderItem : 包含 Product "1" <-- "0..*" OrderItem : 被購買
何時畫：設計物件模型時、做 Code Review 前、跨 domain 溝通時。
Component Diagram 元件圖
用途：描述系統由哪些元件組成，以及元件間的依賴關係。
適用場景：微服務架構的服務依賴關係、套件/模組邊界設計。
注意：現代架構文件常用 C4 Model（Context / Container / Component / Code）取代，視覺上更直觀。
Deployment Diagram 部署圖
用途：描述軟體部署在哪些硬體節點上，以及節點間的通訊。
適用場景：系統驗收文件、基礎設施設計評審。現代替代方案：架構圖（AWS 服務圖、K8s 拓樸圖）。
Object Diagram 物件圖
用途：Class Diagram 在某個時間點的快照，展示實際物件實例和值。
實戰價值：偏低。主要用於教學，說明類別圖的具體例子。
Package Diagram 套件圖
用途：描述程式碼的命名空間/套件結構。
實戰價值：Java/C# 等強型別語言專案中偶爾使用。現代替代方案：直接看目錄結構。
Composite Structure Diagram 複合結構圖
用途：描述類別內部結構與協作關係。
實戰價值：低，只有嵌入式或框架開發偶爾出現。
Profile Diagram 輪廓圖
用途：擴展 UML 本身的元素，用於定義特定領域的 UML 語意。
實戰價值：幾乎只有工具廠商和 MDA 工具鏈開發者需要。
行為圖（Behavioral Diagrams）
Use Case Diagram 用例圖
用途：描述系統與外部參與者（Actor）的互動，識別系統邊界。
主要元素：
Actor（人形圖示） → 外部使用者或系統
Use Case（橢圓） → 系統可以做的事
───────────────── 關聯（Actor 使用 Use Case）
«include» → A 必定包含 B（絕對執行）
«extend» → A 在某條件下擴展 B（有條件執行）
實戰範例：
會員系統的 Use Cases：
Actor：訪客、登入會員、管理員
訪客：
- 瀏覽商品
- 搜尋商品
- 註冊帳號
登入會員：
- 查看訂單
- 建立訂單（«include» 確認庫存）
- 取消訂單（«extend» 申請退款）
管理員：
- 管理商品
- 查看所有訂單
何時畫：需求階段，與 PO/PM 確認功能範圍時。Agile 中常用 User Story 取代，但 Use Case 對系統邊界的視覺化更清楚。
Activity Diagram 活動圖
用途：描述業務流程或演算法的步驟，支援條件分支、並行、同步。
主要元素：
● → 起點（Filled circle）
◉ → 終點（Bull's eye）
□ → 動作節點（Action node）
◇ → 決策節點（Decision node）
══════ → 分叉/合併（Fork/Join，並行控制）
[條件] → 轉移守衛（Guard condition）
與 Flowchart 的差異：Activity Diagram 是 UML 標準，支援並行控制（swimlane、fork/join）；傳統 Flowchart（ISO 5807）較適合單一執行緒流程。
實戰範例：
訂單結帳流程：
開始
→ 確認購物車
→ [庫存充足?]
├─ 是 → 建立訂單 → 扣除庫存（並行）
│ → 發送確認信（並行）
│ → 合併 → 回傳成功
└─ 否 → 顯示庫存不足
結束
何時畫：AS-IS/TO-BE 業務流程文件、多角色協作流程、帶有並行處理的系統流程。
State Machine Diagram 狀態機圖
用途：描述物件在生命週期中的狀態轉換。
主要元素：
● → 初始狀態
□ → 狀態節點（state）
→ → 轉換（transition），帶觸發事件和守衛條件
◉ → 終止狀態
轉換語法：事件名稱 [守衛條件] / 動作
實戰範例（訂單狀態）：
stateDiagram-v2 [*] --> pending : 建立訂單 pending --> confirmed : 付款成功 pending --> cancelled : 取消訂單 / 使用者取消 pending --> cancelled : 付款失敗 confirmed --> shipped : 出貨 shipped --> delivered : 確認收貨 delivered --> refunded : 申請退款 [7天內] cancelled --> [*] delivered --> [*] refunded --> [*]
何時畫：有明確狀態機器的物件（訂單、審核流程、連線狀態）、前後端都需要理解狀態語意時。
互動圖（Interaction Diagrams）
Sequence Diagram 循序圖
用途：描述物件間按時間順序的訊息交換，是微服務架構設計中最常用的圖。
詳細說明與實戰範本見 Sequence Diagram 範本。
重點符號：
actor → 人形
participant → 方框（系統/服務）
->> → 同步呼叫
-->> → 回應
-) → 非同步（fire and forget）
activate/deactivate → 生命線啟動/結束
alt/opt/loop → 條件/選擇/迴圈
Communication Diagram 通訊圖
用途：同樣描述物件間的互動，但強調物件網路結構而非時間順序。
與 Sequence Diagram 差異：兩者在語意上等價，但視角不同。Sequence Diagram 看的是「時間軸上發生了什麼」；Communication Diagram 看的是「哪些物件互相呼叫」。
實戰價值：低，Sequence Diagram 幾乎取代了它。
Timing Diagram 時序圖
用途：描述物件狀態隨時間變化的精確時序，類似電路時序圖。
適用場景：嵌入式系統、即時系統（Real-time system）、硬體通訊協定。
實戰價值：一般後端/前端開發極少用到。
Interaction Overview Diagram 互動概觀圖
用途：結合 Activity Diagram 和 Sequence Diagram，描述控制流程中的互動片段。
實戰價值：低，過於複雜，實戰中幾乎不見。
工具選擇
| 工具 | 適合圖形 | 特點 |
|---|---|---|
| Mermaid | Class / Sequence / State / Activity / ER | 文字語法、可內嵌 GitHub / Notion / VS Code |
| PlantUML | 所有 UML | 文字語法、支援最完整 |
| draw.io | 所有圖形 | 視覺化拖拉、可存 XML |
| Lucidchart | 所有圖形 | 商業工具、協作佳 |
| Excalidraw | 草圖 | 手繪風格、快速白板 |
推薦工作流：
- 需求討論 → Excalidraw 白板草圖
- 設計文件 → Mermaid（版本控制友善）
- 企業文件/驗收 → draw.io 或 Lucidchart
實戰決策樹
你要表達什麼？
│
├─ 結構/組成
│ ├─ 類別/物件關係 → Class Diagram
│ ├─ 服務/模組依賴 → Component Diagram 或 C4 Container
│ └─ 部署架構 → Deployment Diagram 或 AWS 架構圖
│
├─ 功能/需求範圍
│ └─ 系統能做什麼 → Use Case Diagram
│
├─ 流程/步驟
│ ├─ 單一流程（無並行）→ Flowchart
│ ├─ 多角色/並行流程 → Activity Diagram
│ └─ 狀態轉換 → State Machine Diagram
│
└─ 互動/呼叫順序
└─ 跨系統/服務呼叫 → Sequence Diagram