統一建模語言(UML)用例圖是建模系統功能需求的強大工具。它們展示了參與者(使用者或外部系統)如何透過用例與系統互動,用例代表特定功能。用例圖中的兩個關鍵關係——包含和擴展——透過結構化與模組化行為來管理複雜性。本教程提供對這些關係的詳細說明,包括其目的、特徵與實際應用,並附有範例以確保清晰易懂。
在UML用例圖中, 包含和擴展關係可讓您將複雜的用例分解為較小、可重用或可選的元件。這些關係能提升模組化程度,減少重複,並改善圖表的清晰度。

包含關係(<<包含>>):代表必須執行的行為,總是作為基礎用例的一部分執行。它將多個用例之間共享的共同功能提取為可重用元件。
擴展關係(<<擴展>>):代表在特定條件下擴展基礎用例的可選或條件性行為,使基礎用例專注於其核心功能。
兩種關係均使用虛線箭頭連接用例,並以標籤標示<<包含>>或<<擴展>>。箭頭的方向至關重要,因為它反映了用例之間的依賴關係。
該包含包含關係用於將多個使用案例中的共通且必要的行為提取至單一可重用的使用案例中。這促進了重用性,並透過避免功能重複來簡化基礎使用案例。
必要:當執行基礎使用案例時,包含的使用案例總是會被執行。
可重用:包含的使用案例是一個獨立且完整的功能,可被多個基礎使用案例使用。
簡化圖表:透過提取共通步驟,基礎使用案例能保持簡潔且專注。
方向:箭頭從基礎使用案例指向包含的使用案例,表示基礎使用案例依賴於包含的使用案例。
一條標示為<<包含>>的虛線箭頭將基礎使用案例與包含的使用案例連接起來。
考慮一個線上購物系統,其中顧客可以下訂單或取消訂單。這兩個使用案例都要求顧客登入至系統。
基礎使用案例: 下訂單, 取消訂單
包含的使用案例: 登入
說明: 登入是下訂單和取消訂單的必要步驟。為了避免在兩個使用案例中重複登入功能,該功能被提取為一個獨立的登入使用案例,由兩者所包含。
圖示表示:
[下訂單] ----<<包含>>----> [登入]
[取消訂單] ----<<包含>>----> [登入]
在圖書館系統中,使用者可以借書或還書。兩個流程都需要驗證使用者.
基本使用案例: 借書, 還書
包含的使用案例: 驗證使用者
說明: 驗證使用者身分(例如檢查其圖書證)是借書和還書的必要步驟。這個驗證使用者 使用案例被包含以避免重複。
圖示表示:
[借書] ----<<包含>>----> [驗證使用者]
[還書] ----<<包含>>----> [驗證使用者]
當多個使用案例共享一個共同且必要的步驟時。
當您希望透過提取可重用的功能來簡化使用案例描述時。
當被包含的使用案例本身具有獨立意義時(例如,登入 或 驗證使用者 可被理解為獨立的功能)。
這個延伸延伸關係用於模擬僅在特定情況下才執行的選擇性或條件性行為。它讓基本使用案例能專注於其核心功能,同時以模組化方式添加選擇性行為。
選擇性/條件性:延伸的使用案例僅在滿足特定條件時才會執行。
依賴性:延伸的使用案例本身無獨立意義,必須依賴基本使用案例。
延伸點:基本使用案例可定義特定點,讓延伸行為得以插入。
方向:箭頭從延伸的使用案例指向基本使用案例,表示延伸的使用案例會向基本使用案例添加行為。
一條標示為「<<extend>> 將擴展用例與基本用例連接,通常附有註解說明條件或擴展點。
在自動櫃員機系統中,基本用例是提款。一個可選行為,列印收據,若使用者要求列印收據時才會發生。
基本用例: 提款
擴展用例: 列印收據
條件:使用者在提款後選擇列印收據。
說明:列印收據並非必要,僅在使用者明確要求時才會發生。列印收據用例在「使用者要求收據」這個擴展點上擴展提款「使用者要求收據」。
圖示表示:
[列印收據] ----<<extend>>----> [提款]rn(註:條件 = 使用者要求收據)
在線上課程平台中,使用者可以參加測驗。一個可選行為,請求提示,當使用者在回答問題時遇到困難時發生。
基本使用案例: 參加測驗
擴展使用案例: 請求提示
條件:使用者在測驗過程中請求提示。
說明:請求提示是可選的,取決於使用者的需求。這個請求提示 使用案例在「使用者需要協助」這個擴展點上擴展參加測驗於擴展點「使用者需要協助」。
圖示表示:
[請求提示] ----<<擴展>>----> [參加測驗]
(注意:條件 = 使用者需要協助)
當行為是可選的,或取決於特定條件時。
當您希望保持基本使用案例專注於其主要功能時。
當擴展使用案例若無基本使用案例則無意義時(例如,列印收據 在沒有提款).
下表總結了包含 與擴展關係以指導其使用:
|
標準 |
包含(<<包含>>) |
擴展(<<擴展>>) |
|---|---|---|
|
此行為是否為強制性的? |
是,總是作為基本用例的一部分執行 |
否,僅在特定條件下執行 |
|
此行為能否獨立存在? |
是,它是一個完整且可重用的功能 |
否,它依賴於基本用例 |
|
它是否出現在多個用例中? |
是,可在多個用例中共享 |
通常僅適用於單一用例 |
|
目的 |
促進重用並簡化基本用例 |
模組化地新增選擇性或例外行為 |
|
箭頭方向 |
基本用例 → 包含的用例 |
擴展 → 基本用例 |
讓我們在餐廳管理系統中應用這兩種關係,以說明它們在實際情境中的應用。
餐廳系統允許顧客點餐以及預訂桌位。系統還處理其他行為,例如付帳 和 要求外帶.
點餐。顧客從菜單點餐。
預訂桌位。顧客預訂桌位用於用餐。
驗證顧客。驗證顧客的身份(例如透過會員帳戶)。
付帳。顧客支付其訂單(對於點餐).
要求外帶。可選的請求,將訂單打包以便外帶。
包含。兩者皆點餐 和 預訂桌位 都需要驗證顧客 來驗證顧客的身份。點餐 也包含支付賬單因為訂購後必須支付。
擴展: 訂購食物可以由……擴展請求外帶如果顧客選擇外帶食物。
[訂購食物] ----<<包含>>----> [驗證顧客]
[訂購食物] ----<<包含>>----> [支付賬單]
[預訂桌位] ----<<包含>>----> [驗證顧客]
[請求外帶] ----<<擴展>>----> [訂購食物]
(註:條件 = 顧客請求外帶)
驗證顧客包含在兩者之中訂購食物和預訂桌位因為這是存取系統的必要步驟。
支付賬單包含在訂購食物因為完成訂單需要支付。
請求外帶擴展訂購食物因為這是一種可選行為,僅在顧客請求外帶時才會發生。
謹慎使用包含:僅當行為被多個用例共享,或能顯著簡化基礎用例時,才將其提取為包含的用例。過度使用包含會使圖示混亂。
為擴展明確定義擴展點:明確指定擴展行為適用於基礎用例中的條件或點,以避免歧義。
保持用例的專注性:確保基本用例保持簡單,並專注於其主要目標,使用包含 用於必要步驟,而擴展 用於可選步驟。
驗證包含關係的可重用性:被包含的用例應具有實際意義,並可在不同情境中重用。
避免圖示過於複雜:僅在能增加清晰度時使用包含 和擴展,複雜的關係可能會讓利益相關者感到困惑。
混淆包含與擴展:
陷阱:將包含 用於可選行為,或將擴展 用於必要行為。
解決方案:務必確認該行為是否為必要(使用包含),或為條件性(使用擴展).
過度使用關係:
陷阱:創建過多的包含或擴展關係,使得圖表難以閱讀。
解決方案:僅在能減少重複或提升清晰度時才使用這些關係。
模糊的擴展條件:
陷阱:未明確指定擴展關係的條件,導致混淆。
解決方案:務必包含條件或擴展點的註解或描述。
包含不可重用的行為:
陷阱:建立僅由一個基本用例使用的包含用例。
解決方案:確保包含的用例可重用,或能顯著簡化基本用例。
在包含與擴展關係在UML用例圖中對於管理複雜性與確保模組化至關重要。包含 關係透過提取必要且共用的行為來促進重用性,而延伸 關係透過建模選擇性或條件性行為,使基本使用案例保持專注。透過理解其目的、特性和最佳實務,您可以建立清晰、可維護且有效的使用案例圖,以向利益相關者傳達系統功能。