Posted inUML

掌握UML用例關係：«include» 與 «extend» 的威力與陷阱

在軟體需求與系統建模的世界中，UML（統一建模語言)仍然是呈現系統行為的基石。在其最強大卻經常被誤解的功能中，包括«include» 以及«extend» 用例之間的關係。這些機制旨在減少重複, 管理變異性，以及增強模組化用例模型中。然而，它們的濫用非常普遍——導致圖示過於複雜，利益相關者產生混淆，並失去對使用者價值的關注。

 

 

本文提供一份全面、實用且具專家支持的指南用以理解、應用並避免 «include» 與 «extend» 常見陷阱。我們將探討它們的真正語意，並進行並列比較，檢視它們為何陷入與資料流程圖（功能分解）相同的陷阱，同時提供現代最佳實務適用於2025–2026年團隊——特別是那些在敏捷、精益或混合環境中工作的團隊。

🔹 核心語意：«include» 與 «extend» 的真正含義真正代表什麼

✅ «include»：強制重用——「始終必要」的子流程

定義:
«include»關係代表一個被提取出來以在多個使用案例中重用的強制性、總是執行子流程，被提取出來以在多個使用案例中重用。

📌 關鍵特性：

  • 總是執行：包含的使用案例每次呼叫基礎使用案例時都會執行。

  • 若無此包含行為，基礎使用案例將不完整：若無包含的行為，基礎使用案例無法達成其目的。

  • 依賴方向：箭頭指向從基礎 → 包含.

  • 獨立意義：包含的使用案例通常單獨並無意義——只有作為更大流程的一部分時才有意義。

  • 類比：如同程式中的函式呼叫或副程式在程式設計中——對主程式而言是不可或缺的。

🧠 傳統記憶法：

「要執行登入，你必須驗證使用者.”
「要執行提款現金，您必須驗證PIN.”

這些是不可妥協的步驟。沒有驗證，您無法登入。沒有驗證PIN，您無法提款。

💡 何時使用：

  • 當一個常見、複雜且可重用的行為出現在兩個或更多使用案例中。

  • 範例：

    • 驗證使用者

    • 記錄稽核軌跡

    • 發送通知

    • 驗證輸入格式

✅ 經驗法則：僅當重用的行為為重要, 非微不足道，且出現在≥2–3使用案例中。

✅ «extend»：選擇性變體 – 「條件性附加元件」

定義:
「擴展」關係定義了可選的、條件性的或變體的行為，其插入到一個特定的擴展點基礎用例中。

📌 關鍵特徵：

  • 條件性執行：僅在特定情況下運行。

  • 基礎用例可獨立完整：正常流程在沒有擴展的情況下也能運作。

  • 依賴方向：箭頭指向從擴展 → 基礎（反向）。

  • 獨立意義：擴展用例幾乎從不具備獨立意義——只有在上下文中才有意義在上下文中.

  • 類比：如同一個鉤子, 外掛程式，或AOP（面向方面程式設計）建議—它在指定的點添加行為。

🧠 古典記憶法：

「在執行時預訂航班，您可能需要可能想要選擇偏好的座位.”
「在執行時使用信用卡付款，您可能需要可能必須輸入3D安全碼.”

這些是可選的增強功能——非核心流程所必需。

💡 使用時機：

  • 用於模擬替代路徑, 例外情況，或可選功能.

  • 當一個使用案例具有變異行為根據條件（例如：使用者角色、系統狀態、偏好）而定。

  • 範例：

    • 套用折扣（擴展下訂單)

    • 申請退款（擴展處理付款)

    • 產生PDF收據（擴展完成交易)

✅ 經驗法則：僅在必要時使用«擴展»——僅適用於有意義的變體具有明確的擴展點.

🔍 快速比較：«包含» vs «擴展»

面向 «包含» «擴展»
執行 總是 有時／依條件
基本用例是否可獨立完成？ ❌ 否——取決於被包含的內容 ✅ 是——無需擴展即可完成
依賴方向 基礎 → 包含 擴展 → 基礎
箭頭方向 指向被包含的用例 指向基礎用例
主要目標 重用必要且共用的步驟 處理選擇性/變異流程
類比 函數呼叫 / 子程序 鉤子 / 插件 / AOP建議
是否具有獨立意義？ 很少 幾乎從不
最適合 可重用、複雜且橫切的關注點 條件性、選擇性或替代行為

⚠️ 「分解陷阱」：為何用例圖會偏離軌道

就像DFD（資料流程圖）會受到功能分解陷阱，用例圖也容易陷入同樣致命的疾病: 過度分解.

📉 DFD 功能分解陷阱（回顧）：

  • 團隊不斷將流程拆分成越來越小的泡泡。

  • 圖表爆炸成數十個微小且低階的函數。

  • 這原始目的——為用戶提供價值——被遺失了。

  • 最後看起來像偽碼或內部演算法設計，而非使用者行為。

🧨 使用案例「功能分解病」：

  • 每一個微小步驟都變成一個獨立的使用案例：

    • 輸入使用者名稱

    • 輸入密碼

    • 點擊登入按鈕

    • 驗證格式

    • 顯示錯誤訊息

  • 「包含」被應用大量地以分解每個動作。

  • 結果：一個深層層級的使用案例層級（A → B → C → D…），且沒有明確的參與者目標。

  • 圖表變得難以維護, 令人困惑，且對利益相關者而言毫無用處對利益相關者而言毫無用處。

❌ 紅旗: 如果你的用例圖包含超過15到20個用例，或者如果大多數基本用例長度為2到4個步驟你很可能陷入陷阱。

🛠️ 為何會發生：常見的陷阱與誤解

陷阱 解釋 如何避免
濫用 «include» 將每個子步驟都視為可重用的用例。 僅在以下情況使用 «include»重要, 可重用, 跨切面行為（例如：驗證、記錄日誌）。
混淆箭頭方向 將 «include» 箭頭畫反（基底 ← 包含）或將 «extend» 箭頭畫正向。 請記住：include = 基底 → 包含; extend = 擴展 → 基底.
使用 «extend» 表示替代方案 將替代流程建模為內部一個用例的 «extend»，而非使用文字上的替代方案。 使用 文字型替代流程 用於大多數變體。將「延伸」保留給 真正的可選延伸.
建立包含鏈 A → B → C → D → E… 避免過深的鏈。如果需要多個包含，建議 重構為單一可重用的使用案例.
模糊的延伸點 在沒有明確且命名的插入點的情況下加入「延伸」關係。 定義 明確的延伸點 （例如「付款確認後」）在基本使用案例中。
圖表雜亂 太多使用案例與關係 → 視覺干擾。 保持圖表 小型、聚焦且以參與者為中心。每個子系統使用多個圖表。
利益相關者混淆 非技術性利益相關者覺得「包含／延伸」難以理解。 使用 文字型情境 或 使用者故事地圖 以確保清晰。
設計層級的建模 建模內部架構（例如「呼叫資料庫」）而非使用者目標。 專注於 角色價值——而非實作。
無止境的爭論 團隊爭論「是使用 include 還是 extend？」，而不是撰寫情境描述。 使用實用的啟發法和優先考慮清晰度而非形式.

✅ 2025–2026 年最佳實務：現代化、敏捷的方法

需求工程的環境已經改變。敏捷、精益及以產品為導向的團隊正越來越遠離繁重的 UML 圖表，轉而採用輕量、以價值為導向技術。

🎯 核心原則：著重於角色價值，而非內部結構

❗ 在新增任何 «include» 或 «extend» 之前，請問這個問題:
「這個關係是否有助於使用者理解目標，還是僅僅在拆解系統？」

✅ 推薦的現代實務：

1. 節制使用 «include» — 僅用於主要的可重用行為

  • 僅用於跨領域關注點出現在多個使用案例中。

  • 範例：

    • 驗證使用者

    • 發送電子郵件通知

    • 記錄安全事件

    • 應用商業規則

❌ 避免：輸入使用者名稱, 按一下提交, 驗證電子郵件格式

2. 優先使用文字替代流程，而非「擴展」

  • 而非：

    「擴展」：選擇偏好座位 → 訂購航班

  • 使用：

    使用案例：訂購航班
...
替代流程：
  1. 使用者選擇「偏好座位」選項。
  2. 系統顯示座位圖。
  3. 使用者選擇座位。
  4. 系統套用座位偏好。

✅ 為什麼？文字流程具有更容易閱讀, 更具彈性，且較不易被誤用.

3. 保持使用案例圖簡潔且專注

  • 每個參與者或子系統.

  • 限制為5–10 個使用案例每個圖表。

  • 使用套件圖或環境圖以顯示高階結構。

4. 問：「使用者故事地圖是否能更有效地傳達此內容？」

  • 如果你使用了 10 個以上的 «包含»/«延伸» 關係，建議以以下方式取代此圖：

    • 一個使用者故事地圖

    • 一個情境導向的表格

    • 一個簡單的流程圖並標示關鍵路徑

🔄 現代趨勢：許多敏捷團隊完全避免使用使用案例圖或僅在高階探索時使用僅用於高階探索.

5. 僅在有意義的變體中使用 «extend»

  • 將 «extend» 保留給可選的、非核心功能，例如：

    • 是很少使用

    • 是依情境而定

    • 是獨立的與核心目標無關

✅ 範例：
處理付款（基礎）
應用 3D 安全驗證（擴展）——僅在銀行要求時使用

❌ 避免：
輸入卡號 → 驗證卡片 → 處理付款（所有步驟都應屬於同一個使用案例）

📊 總結：«include» 與 «extend» 的黃金法則

規則 指引
1. «include» = 必需 僅用於必要且可重用出現在至少兩個使用案例中的步驟。
2. «extend» = 可選 僅在以下情況下使用條件性、變體或罕見行為。
3. 基本用例必須完整 «extend»：基本用例可獨立運作。«include»：若無此用例，基本用例則不完整。
4. 保持簡單 若用例在「include」/「extend」後僅有少於4至6個步驟，表示你已過度分解。
5. 重視可讀性 文字情境 > 複雜圖示。
6. 避免鏈式結構 不可出現 A → B → C → D 的情況。應重構為一個可重用的用例。
7. 了解你的受眾 利益相關者不關心「include」箭頭——他們關心的是價值.
8. 提問：「這是一個使用者目標，還是內部步驟？」 若這不是使用者的目標，很可能不應出現在用例中。

🎯 最終想法：工具，而非陷阱

«include» 和 «extend» 是強大的工具——而非僵化的規則。它們的設計目的在於：

  • 減少重複

  • 管理變異性

  • 提升可維護性

但如同DFD 中的功能分解，它們會變成危險的武器當被濫用時。真正的危險並非這些關係本身——而是忽略用戶的目標.

🔥 記住:
用例並非技術流程。
它是一則關於用戶想要達成目標的故事——以及系統如何協助。

若有疑問，請問自己:

「使用者在不了解UML的情況下，是否能理解這一點？」
若否，請簡化。
若是，你就在正確的軌道上。

📚 進階閱讀與參考資料

  • UML規格（OMG）: www.omg.org/spec/UML

  • 馬丁·福勒 – 用例建模: 分析模式 & UML精要

  • 伊瓦爾·雅各布森 – 物件優勢：用例的基礎性著作

  • 敏捷建模（AM）由史考特·W·安布勒著

  • 使用者故事地圖由傑夫·帕頓著 – 為複雜圖表的現代替代方案

✅ 一句話規則

使用「include」進行強制重用，使用「extend」進行選擇性變體——但僅在真正增加價值時才使用。否則，保持簡單。

因為最終，目標並不是繪製完美的UML圖表——而是要建立能為真實用戶帶來實際價值的系統。

📌 作者註（2025–2026）:
隨著團隊轉向以產品為中心, 以價值為導向，以及協作式開發模式，傳統UML圖表的角色正在演變。「include」和「extend」仍然有用——但僅在節制、清晰且有明確目的的情況下使用僅在節制、清晰且有明確目的的情況下使用。讓它們服務於使用者，而非圖表本身。