Posted inUnified Modeling Language Use Case Modeling Visual Paradigm

UML使用案例圖中包含與擴展關係的完整指南

統一建模語言（UML）使用案例圖是建模系統功能需求的強大工具。它們展示了參與者（使用者或外部系統）如何透過使用案例與系統互動，使用案例代表特定功能。使用案例圖中的兩個關鍵關係——包含和擴展——透過結構化與模組化行為來管理複雜性。本教程提供對這些關係的詳細說明，包括其目的、特徵與實際應用，並附有範例以確保清晰易懂。

什麼是包含與擴展關係？

在UML使用案例圖中, 包含和擴展關係可讓您將複雜的使用案例分解為較小、可重用或選擇性的元件。這些關係能提升模組化程度，減少重複，並改善圖表的清晰度。

Include” and “Extend” Use Cases - Visual Paradigm Blog

  • 包含關係（<<包含>>)：代表必須執行的行為，總是作為基礎使用案例的一部分執行。它將多個使用案例之間共用的常見功能提取為可重用元件。

  • 擴展關係（<<擴展>>)：代表在特定條件下擴展基礎使用案例的選擇性或條件性行為，使基礎使用案例能專注於其核心功能。

兩種關係均使用虛線箭頭連接使用案例，並以標籤標示<<包含>>或<<擴展>>。箭頭的方向至關重要，因為它反映了使用案例之間的依賴關係。

包含關係（<<包含>>)

目的

該包含包含關係用於將多個使用案例中的共通且必要行為提取至單一可重用的使用案例中。這促進了重用性，並透過避免功能重複來簡化基礎使用案例。

特徵

  • 必要：當執行基礎使用案例時，包含的使用案例總是會被執行。

  • 可重用：包含的使用案例是一個獨立且完整的功能，可被多個基礎使用案例使用。

  • 簡化圖表：透過提取共通步驟，基礎使用案例能保持簡潔且專注。

  • 方向：箭頭從基礎使用案例指向包含的使用案例，表示基礎使用案例依賴於包含的使用案例。

符號

  • 一條標示為<<包含>>的虛線箭頭將基礎使用案例連接到包含的使用案例。

範例 1：線上購物系統

考慮一個線上購物系統，其中顧客可以下訂單或取消訂單。這兩個使用案例都要求顧客登入至系統。

  • 基礎使用案例: 下訂單, 取消訂單

  • 包含的使用案例: 登入

  • 說明: 登入是下訂單和取消訂單的必要步驟。為了避免在兩個使用案例中重複登入功能，該功能被提取為一個獨立的登入使用案例，由兩者所包含。

圖示表示:

[下訂單] ----<<包含>>----> [登入]
[取消訂單] ----<<包含>>----> [登入]

範例 2：圖書館管理系統

在圖書館系統中，使用者可以借書或還書。兩個流程都需要驗證使用者.

  • 基本使用案例: 借書, 還書

  • 包含的使用案例: 驗證使用者

  • 說明: 驗證使用者身分（例如檢查其圖書證）是借書和還書的必要步驟。這個驗證使用者 使用案例被包含以避免重複。

圖示表示:

[借書] ----<<包含>>----> [驗證使用者]
[還書] ----<<包含>>----> [驗證使用者]

何時使用

  • 當多個使用案例共享一個共同且必要的步驟時。

  • 當您希望透過提取可重用的功能來簡化使用案例描述時。

  • 當被包含的使用案例本身具有獨立意義時（例如，登入 或 驗證使用者 可被理解為獨立的功能）。

延伸關係（<<延伸>>)

目的

這個延伸延伸關係用於模擬僅在特定情況下才執行的選擇性或條件性行為。它允許基本使用案例專注於其核心功能，同時以模組化方式添加選擇性行為。

特徵

  • 選擇性／條件性：延伸的使用案例僅在滿足特定條件時才會執行。

  • 依賴性：延伸的使用案例本身無意義，必須依賴於基本使用案例。

  • 延伸點：基本使用案例可定義特定點，以便插入延伸行為。

  • 方向：箭頭從延伸的使用案例指向基本使用案例，表示延伸的使用案例向基本使用案例添加行為。

符號

  • 一條標示為<<extend>> 將擴展用例與基本用例連接，通常附有註釋說明條件或擴展點。

範例 1：自動櫃員機系統

在自動櫃員機系統中，基本用例是提款。一個可選行為，列印收據，若使用者要求列印收據時才會發生。

  • 基本用例: 提款

  • 擴展用例: 列印收據

  • 條件：使用者在提款後選擇列印收據。

  • 說明：列印收據並非必要，僅在使用者明確要求時才會發生。列印收據用例在「使用者要求收據」這個擴展點上擴展提款「使用者要求收據」。

圖示表示:

[列印收據] ----<<extend>>----> [提款]rn（註：條件 = 使用者要求收據）

範例 2：線上課程平台

在線上課程平台中，使用者可以參加測驗。一個可選行為，請求提示，當使用者在問題上遇到困難時發生。

  • 基本使用案例: 參加測驗

  • 擴展使用案例: 請求提示

  • 條件：使用者在測驗期間請求提示。

  • 說明：請求提示是可選的，取決於使用者的需求。這個請求提示 使用案例在「使用者需要協助」的擴展點上擴展參加測驗於擴展點「使用者需要協助」。

圖示表示:

[請求提示] ----<<擴展>>----> [參加測驗]
（注意：條件 = 使用者需要協助）

何時使用

  • 當行為是可選的，或取決於特定條件時。

  • 當您希望保持基本使用案例專注於其主要功能時。

  • 當擴展使用案例在沒有基本使用案例的情況下毫無意義時（例如，列印收據 在沒有提款).

包含與擴展之間的主要差異

下表總結了包含 與擴展關係以指導其使用：

標準

包含（<<包含>>)

擴展（<<擴展>>)

此行為是否為強制性的？

是，總是作為基本用例的一部分執行

否，僅在特定條件下執行

此行為能否獨立存在？

是，它是一個完整且可重用的功能

否，它依賴於基本用例

它是否出現在多個用例中？

是，跨多個用例共享

通常僅適用於一個用例

目的

促進重用並簡化基本用例

模組化地添加可選或例外行為

箭頭方向

基本用例 → 包含的用例

擴展 → 基本用例

實務範例：餐廳管理系統

讓我們在餐廳管理系統中應用這兩種關係，以說明它們在實際情境中的應用。

情境

餐廳系統允許顧客點餐以及預訂桌位。系統還處理其他行為，例如付帳 和 要求外帶.

使用案例

  • 點餐。顧客從菜單點餐。

  • 預訂桌位。顧客預訂桌位用於用餐。

  • 驗證顧客。驗證顧客的身份（例如透過會員帳戶）。

  • 付帳。顧客支付其訂單（對於點餐).

  • 要求外帶。可選的請求，將訂單打包以便外帶。

關係

  • 包含。兩者皆點餐 和 預訂桌位 需要驗證顧客 以驗證顧客的身份。點餐 也包含支付賬單因為訂購後必須付款。

  • 擴展: 點餐可以被擴展為要求外帶如果顧客選擇外帶食物。

圖示表示

[點餐] ----<<包含>>----> [驗證顧客]
[點餐] ----<<包含>>----> [支付賬單]
[預訂桌位] ----<<包含>>----> [驗證顧客]
[要求外帶] ----<<擴展>>----> [點餐]
(注意：條件 = 顧客要求外帶)

說明

  • 驗證顧客被包含在以下兩者之中點餐以及預訂桌位因為這是存取系統的必要步驟。

  • 支付賬單被包含在點餐因為完成訂單需要付款。

  • 要求外帶擴展點餐因為這是一種可選行為，僅在顧客要求外帶時才會發生。

使用包含與擴展的最佳實務

  1. 謹慎使用包含：僅當某行為被多個用例共享，或能顯著簡化基礎用例時，才將其提取為包含的用例。過度使用包含會使圖示混亂。

  2. 為擴展明確定義擴展點：明確指定擴展行為適用於基礎用例中的條件或節點，以避免歧義。

  3. 保持用例的專注性：確保基礎用例保持簡單，並專注於其主要目標，使用包含 用於必要步驟，以及擴展 用於可選步驟。

  4. 驗證包含關係的可重用性：被包含的用例應具有意義，並可在不同情境中重用。

  5. 避免圖示過於複雜：使用包含 和擴展 僅在能增加清晰度時使用。複雜的關係可能會讓利益相關者感到困惑。

常見陷阱及其避免方法

  1. 混淆包含與擴展:

    • 陷阱：使用包含 來表示可選行為，或使用擴展 來表示必要行為。

    • 解決方案：務必確認該行為是否為必要（使用包含）或條件性（使用擴展).

  2. 過度使用關係:

    • 陷阱：創建太多包含或擴展關係，使得圖表難以閱讀。

    • 解決方案：僅在這些關係能減少重複或提升清晰度時才使用。

  3. 模糊的擴展條件:

    • 陷阱：未明確指定擴展關係的條件，導致混淆。

    • 解決方案：務必包含條件或擴展點的註解或描述。

  4. 包含不可重用的行為:

    • 陷阱：建立僅由一個基本用例使用的包含用例。

    • 解決方案：確保包含的用例可重用，或能顯著簡化基本用例。

結論

在包含與擴展關係在UML用例圖中對於管理複雜性與確保模組化至關重要。包含 關係透過提取必要且共用的行為來促進重用性，而延伸 關係透過模擬選擇性或條件性行為，使基本使用案例保持聚焦。透過理解其目的、特性和最佳實務，您可以建立清晰、可維護且有效的使用案例圖，以向利害關係人傳達系統功能。

參考