掌握用例圖中的擴展點：識別與實現 <> 段的指南

在統一建模語言（UML）, 用例圖是捕捉系統功能需求的強大工具。這些圖表的一個關鍵特性是 <<extend>> 關係，它允許在特定稱為擴展點的特定位置插入這些擴展點，這對於建立模組化、可重用且清晰的用例模型至關重要。本文提供了一個逐步指南，用以識別和實現擴展點，並通過實用範例來說明其在現實場景中的應用。

什麼是擴展點與 <<extend>> 關係？

一個擴展點是基於用例中的一個特定位置，可在其中插入額外的、可選的或條件性的行為（來自擴展用例）。<<extend>> 關係表示擴展用例在特定條件下向基於用例添加行為，而不改變其核心流程。這使得系統設計更具彈性，允許加入可選功能或變體，同時保持基於用例的獨立性和完整性。

例如，在電子商務系統中，基於用例「下訂單」可能包含一個擴展點，用於「套用折扣」，僅在使用者輸入有效的折扣碼時才觸發。基於用例在沒有折扣的情況下依然功能完整，但當適用時，擴展會使其增強。

為什麼擴展點很重要？

擴展點透過以下方式增強用例圖：

• 模組化行為：將可選或條件性行為分離到獨立的用例中，可提升清晰度與可重用性。
• 支援彈性：它們讓系統能夠容納變異，而不會使基於用例變得混亂。
• 提升可維護性：對可選行為的變更可以在不修改核心用例的情況下進行。
• 增強利益相關者溝通：明確命名的擴展點讓利益相關者更容易理解擴展發生的位置與原因。

然而，識別 <<extend>> 段的正確位置需要仔細分析。以下是我們概述的一種結構化方法，用以精確定位這些位置，並附上示例加以說明。

如何識別 <<extend>> 段的擴展點

以下是一份逐步指南，用以在用例中尋找並定義擴展點：

1. 分析基本用例流程

首先仔細審查主要成功情境以及替代流程基本用例的流程。尋找以下情況的步驟：

• 可能選擇性地發生額外行為（例如，使用者觸發的動作）。
• 根據特定情況，可能插入條件性動作。
• 可以在不影響核心流程的情況下加入變體或增強功能。

範例：在一個「登入系統」用例中，主要流程包括輸入憑證並進行驗證。一個可選步驟，例如「啟用雙重驗證」，可能是一個僅在使用者啟用此功能時才觸發的擴展點。

2. 識別可選或條件性行為

專注於用例中並非總是執行的部分。這些可能包括：

• 可選的使用者輸入（例如，在訂購流程中加入禮品包裝）。
• 異常情況（例如，處理付款失敗）。
• 由特定條件觸發的增強功能（例如，套用折扣碼）。

範例：在一個「預訂航班」用例中，旅客可能有機會「選擇座位偏好」（例如，靠窗或走道）。此步驟並非預訂的必要條件，但當選擇時可提升體驗，因此是擴展點的候選項目。

3. 定義有意義且命名明確的擴展點

每個擴展點都應具有清晰且具描述性的名稱，以反映其目的。這有助於開發人員和利益相關者理解擴展發生的位置與原因。

範例：在一個「處理付款」 使用案例中，一個命名為「驗證優惠券代碼」 明確表示擴展行為涉及檢查並套用優惠券，這只有在使用者提供優惠券時才會發生。

4. 確保基本使用案例的獨立性

基本使用案例必須保持完整且有意義而不需要擴展行為。擴展應增強或增加可選功能，而非對基本使用案例的成功至關重要。

範例：在一個「提交申請」 使用案例中，一個類似於「上傳額外文件」 允許候選人提供額外文件（例如證書）。即使沒有此步驟，申請流程仍可完成，但此擴展對部分使用者具有附加價值。

5. 善用建模工具

像 Visual Paradigm 之類的工具可簡化定義擴展點的過程。在 Visual Paradigm 中：

• 右鍵按一下基本使用案例，選擇新增擴展點，並指派一個描述性的名稱。
• 在使用案例的區段中記錄擴展點，以確保清晰明瞭。
• 將擴展的使用案例連結至特定的擴展點，以顯示其行為整合的位置。

範例：在 Visual Paradigm 中，針對一個「結帳」 使用案例，您可以定義一個稱為「指定運送指示」 的擴展點，並連結至一個擴展的使用案例「新增特殊運送備註」.

6. 應用實際情境

將擴展點與實際情境對應，可確保其與系統需求一致。透過考慮它們如何融入系統的工作流程與使用者互動，來測試您的選擇。

擴展點的實際範例

讓我們探討幾個現實世界的範例，以說明如何有效識別與實作擴展點。

範例 1：電子商務系統 – 下單

• 基本使用案例: 下單
  使用者選擇商品，輸入付款資訊，並確認訂單。
• 擴展點:
  1. 套用折扣: 當使用者在結帳時輸入有效的折扣碼時觸發。
  2. 指定運送指示: 若使用者希望加入特殊送達說明（例如：「請將包裹放在後門」），則觸發。
• 擴展使用案例:
  • 套用折扣: 驗證碼並調整訂單總額。
  • 新增特殊送達說明: 允許使用者輸入自訂指示。
• 理由: 這些擴展是可選的，僅在特定條件下發生（例如：有效的折扣碼或使用者偏好特殊說明）。即使沒有這些擴展，基本使用案例依然完整。

範例 2：銀行系統 – 提現

• 基本使用案例: 提現
  使用者插入卡片，輸入密碼，指定金額，並取得現金。
• 擴展點:
  1. 請求收據: 當使用者選擇接收交易憑證時觸發。
  2. 提款前檢查餘額: 當使用者選擇在提款前查看其帳戶餘額時觸發。
• 擴展用例:
  • 列印憑證: 產生並列印交易憑證。
  • 顯示帳戶餘額: 顯示使用者的當前餘額。
• 理由: 這些行為是可選的，不會影響核心提款流程，因此非常適合使用 <<extend>> 關係。

範例 3：線上學習平台 – 參加測驗

• 基本用例: 參加測驗
  學生登入後，選擇測驗，回答問題，並提交答案。
• 擴展點:
  1. 申請額外時間: 當學生有特殊安排允許額外時間時觸發。
  2. 儲存進度: 當學生選擇儲存答案並稍後繼續時觸發。
• 擴展用例:
  • 授予額外時間: 為符合資格的學生延長測驗時間。
  • 儲存並繼續測驗: 允許部分完成並於後續繼續。
• 理由: 這些擴展是條件性的（例如基於資格或使用者選擇），並在不影響基本用例的前提下加以增強。

範例 4：圖書館系統 – 借書

• 基本使用案例: 借書
  使用者搜尋書籍，選取後使用圖書館卡辦理借閱。
• 擴展點:
  1. 預約書籍: 當書籍無法取得且使用者希望預約時觸發。
  2. 支付逾期罰金: 當使用者有未清償的罰金，必須先清除才能借書時觸發。
• 擴展使用案例:
  • 建立預約: 將使用者加入該書的等候名單。
  • 清償罰金: 處理任何逾期罰金的付款。
• 理由: 這些動作是條件性的（例如書籍無法取得或未付罰金），並非每次借書流程都會發生。

定義擴展點的最佳實務

為確保擴展點的有效使用，請遵循以下最佳實務：

1. 保持名稱具描述性: 使用清晰且具體的名稱，例如「使用優惠券」或「選擇座位偏好」以避免歧義。
2. 驗證獨立性: 確認基本使用案例在沒有擴展行為的情況下仍能完整運作。
3. 記錄條件：指定擴展觸發的條件（例如：「如果使用者輸入有效的優惠券代碼」）。
4. 有效運用工具：利用如 Visual Paradigm 或 Enterprise Architect 之類的 UML 工具，以視覺化方式定義並連結擴展點。
5. 與利害關係人共同測試：與利害關係人審查擴展點，以確保其符合系統需求與使用者期望。

應避免的常見陷阱

• 濫用擴展：不要將 <<extend>> 用於必要行為；應改用 <<include>> 表示必要子流程。
• 模糊的擴展點：避免使用如「做某事」 之類的泛稱，這些名稱無法清楚傳達擴展的目的。
• 使基本使用案例過於雜亂：確保擴展確實為可選，以避免過度複雜化核心流程。
• 忽略條件：始終明確定義觸發擴展的具體條件，以維持清晰性。

在 UML 工具中視覺化擴展點

在 Visual Paradigm 等工具中，擴展點會記錄在基本使用案例的區段內。例如：

• 使用案例：下訂單
  • 擴展點:
    • 套用折扣（條件：使用者輸入有效的折扣代碼）
    • 指定運送說明（條件：使用者選擇加入送達備註）
• 擴展的使用案例透過 <<extend>> 關係連結至這些點，通常會附註說明觸發條件。

這種視覺化呈現可確保開發人員與利害關係人能輕易追蹤擴展如何以及在何處整合。

結論

在使用案例中正確識別插入 <<extend>> 段落的位置，需要深入理解系統的功能需求，並仔細分析基本使用案例的流程。透過專注於可選或條件性行為、賦予明確名稱，並確保基本使用案例的獨立性，即可建立模組化且彈性的使用案例模型。現實世界中的例子，例如電商系統中套用折扣，或在測驗中請求額外時間，都顯示了擴展點如何提升系統設計，而不會使核心功能變得混亂。

遵循本指南所列步驟——分析流程、識別可選行為、明確命名擴展點，並善用 UML 工具，您便能掌握定義擴展點的技巧。此方法不僅提升使用案例圖的清晰度與可維護性，更能確保系統能適應不斷演變的需求。