在物件導向分析與設計的領域中，很少有工具能像用例一樣提供如此清晰的視角。此方法彌補了抽象業務需求與具體系統行為之間的差距。執行全面的用例分析，可確保最終的軟體架構與使用者目標及營運限制相符。本指南詳細說明用例分析的流程，專注於結構、清晰度與準確性，且不依賴特定工具。
為什麼用例分析至關重要 🔍
在進入步驟之前，了解此分析的目的至關重要。用例描述系統執行的一系列動作，這些動作產生對參與者具有價值的可觀察結果。它不僅僅是一份功能清單，更是一份行為合約。
- 明確範圍： 它定義了系統的功能，更重要的是，也明確了系統不會做什麼。
- 提升溝通效率： 它成為利益相關者、分析師與開發人員之間的共同語言。
- 支援測試： 由用例衍生的場景，構成了功能測試策略的基礎。
- 降低風險： 早期識別邊界情況，可避免在實作階段產生昂貴的變更。
若無此分析，專案經常面臨範圍蔓延與期望不符的問題。重點始終放在「什麼」上，而非「如何」上，使設計能開放接受各種技術解決方案。
準備階段：收集需求 📝
有效的分析在繪製任何圖表之前就已開始。您必須從利益相關者、領域專家及現有文件中收集原始資訊。
分析的關鍵輸入
- 業務目標： 組織試圖達成什麼目標？
- 使用者故事： 從使用者角度描述互動的敘事。
- 法規限制： 決定系統行為的法律或合規要求。
- 現有流程： 目前工作是手動執行，還是透過舊系統完成？
收集這些輸入可確保用例反映實際情況。不要僅依賴高階摘要；應尋求日常作業流程的詳細描述。
第一步：識別參與者 👥
第一步是識別參與者。參與者代表由人類、另一個系統或時間觸發器所扮演的角色，這些角色會與系統互動。參與者位於系統邊界之外。
參與者的類型
| 參與者類型 | 描述 | 範例 |
|---|---|---|
| 人類參與者 | 在組織內執行某個角色的個人。 | 管理員、客戶、審計員 |
| 系統參與者 | 另一個提供或消耗資料的軟體系統。 | 付款網關、庫存資料庫 |
| 時間參與者 | 基於特定時間或排程的觸發器。 | 每晚備份、每月報表 |
在識別參與者時，避免命名具體個人。應著重於角色。例如，使用「審核員」，而不是「約翰·多」。這可確保即使人員變動，模型仍保持有效。
參與者識別中的常見錯誤
- 混淆參與者與使用者： 使用者可能扮演多個角色。應識別角色，而非個人。
- 系統內部組件： 不應將內部類別或模組列為參與者。它們屬於系統的一部分，而非系統外部。
- 遺漏系統參與者： 通常會忽略與外部 API 的互動。請確保所有資料交換都已納入考量。
步驟 2：定義使用案例與目標 🎯
一旦參與者確立後，您必須定義使用案例本身。使用案例代表以目標為導向的互動。當參與者啟動一個動作時開始，並在特定價值被交付時結束。
有效使用案例的標準
- 價值交付： 互動必須為參與者提供價值。
- 單一目標： 雖然一個使用案例可能包含多個步驟，但它應僅服務於一個主要目標。
- 系統邊界： 該動作必須在系統的控制範圍內發生。
針對每個使用案例，分配一個唯一的識別碼和明確的名稱。使用格式動詞 + 名詞（例如：「處理退貨」、「產生報表」）。此命名規範可促進文件中的一致性。
描述目標
針對每個使用案例，撰寫目標的簡要描述。此敘述說明互動的背景。應回答：「參與者試圖達成什麼？」以及「這為什麼重要？」
範例：
使用案例： 處理退貨
目標： 允許顧客退還產品以獲得退款。
參與者： 顧客
這種清晰性可避免設計階段產生歧義。若目標模糊，系統的實作很可能與使用者期望不符。
步驟 3：描述情境（主要與替代） 🔄
情境定義互動過程中所採取的具體步驟。它們是使用案例骨架上的敘事血肉。您應記錄主要成功情境與替代流程。
主要成功情境
此路徑代表一切順利進行的理想流程，通常稱為「快樂路徑」。每個步驟都應是原子性的，表示代表單一的工作單位。
- 參與者啟動使用案例。
- 系統驗證輸入。
- 系統更新內部狀態。
- 系統向參與者確認完成。
在此避免技術細節。不要說「執行 SQL 查詢」，而應說「系統擷取記錄」。重點在行為，而非實作。
替代流程
現實世界的互動經常偏離理想狀態。替代流程涵蓋例外、錯誤，以及參與者可能做出的不同選擇。
- 錯誤處理： 如果使用者輸入無效資料，會發生什麼情況？
- 分支： 如果使用者在決策點選擇了不同的選項，會怎麼樣？
- 終止： 如果使用者取消流程，會發生什麼情況？
清楚地記錄這些流程。參考發生偏離的步驟編號。這能確保開發人員明確知道應在何處放置錯誤處理邏輯。
步驟 4：結構化關係（包含/擴展） 🔗
隨著使用案例數量增加，管理它們變得更加複雜。關係有助於組織模型並減少重複。兩種主要關係是包含 和 擴展.
包含關係
一個 包含包含關係表示一個使用案例整合了另一個使用案例的行為。這用於提取共用功能。
- 何時使用： 當一組步驟在多個使用案例中重複出現時。
- 範例： 「下訂單」和「處理退貨」都需「驗證使用者」。你可以在兩者中都包含「驗證使用者」。
這可減少重複，並使維護更簡單。如果驗證邏輯變更，只需在一個地方更新即可。
擴展關係
一個 擴展擴展關係表示一個使用案例在特定條件下，向基礎使用案例添加可選行為。
- 何時使用： 當行為是可選或條件性的時候。
- 範例： 「套用折扣」僅在客戶擁有有效優惠券代碼時，才會擴展「下訂單」。
應謹慎使用這些關係。過度結構化會使模型更難閱讀。如果關係並非明確提升清晰度所必需，則保持使用案例的扁平化。
步驟 5：驗證與審查 ✅
分析在驗證完成前尚未結束。此步驟包括將用例與需求及參與者進行核對。
驗證清單
- 完整性：所有功能需求是否都至少由一個用例涵蓋？
- 一致性：參與者名稱與用例名稱在文件中是否一致？
- 可行性：系統是否能實際達成所定義的目標？
- 獨特性：是否存在可合併的重複用例？
與利益相關者進行審查。引導他們走過各個情境。如果他們無法跟上流程，則表示文件描述不夠清晰。根據反饋進行修改。
應避免的常見錯誤 ⚠️
即使經驗豐富的分析師也會犯錯。了解常見陷阱有助於維持品質。
1. 混合抽象層級
不要將高階的業務目標與低階的技術步驟混在一起。保持主流程聚焦於使用者的旅程。技術細節應留到設計階段，而非用例描述中。
2. 忽略非功能需求
雖然用例著重於功能，但仍應標註限制條件。例如，某個用例可能要求回應時間低於 2 秒。應將這些內容以註解或與用例相關的限制條件形式記錄下來。
3. 過度設計圖表
用例圖是一張地圖，而非實際領域。不要試圖在視覺模型中捕捉每一項細節。邏輯應由文字描述呈現。圖表應顯示關係與參與者，而非複雜的邏輯流程。
4. 忘記前置與後置條件
前置條件定義了用例開始前必須為真的狀態。後置條件定義了用例結束後的狀態。這些對於理解上下文至關重要。
| 條件類型 | 定義 | 範例 |
|---|---|---|
| 前置條件 | 執行前所需的狀態。 | 使用者已登入 |
| 後置條件 | 執行後保證的狀態。 | 訂單狀態為『已付款』 |
將使用案例與設計整合 🏗️
使用案例分析的最終產出不僅僅是文件；它更是設計的藍圖。使用案例推動了類圖和序列圖的建立。
從行為到結構
使用案例情境中的每一步通常對應到一個方法或類別互動。參與者可能對應到控制器類別。系統動作則對應到領域物件。
- 識別類別： 在使用案例描述中尋找名詞（例如：「訂單」、「客戶」、「發票」）。這些將成為候選類別。
- 識別方法： 在使用案例中尋找動詞（例如：「計算」、「儲存」、「驗證」）。這些將成為候選方法。
- 定義關係： 參與者與使用案例之間的互動暗示了類別之間的關聯。
此轉換確保架構能支援需求。如果一個使用案例無法輕易對應到設計元素，可能表示設計上有缺陷或遺漏了需求。
可追溯性
維持從需求到使用案例再到設計元素的可追溯性。這讓您能確認每個需求都已實作。若移除一個使用案例，請檢查其背後的需求是否仍有效。這可避免產生孤立的程式碼。
關鍵概念摘要 📊
總結來說，以下為有效使用案例分析的核心組成部分的快速參考。
- 參與者： 外部實體（人、系統、時間）。
- 使用案例： 以目標為導向、具備價值交付的互動。
- 流程： 步驟的順序（主要流程、替代流程）。
- 關係： 包含（必要）與擴展（可選）。
- 條件： 前置條件與後置條件。
遵循這些原則，您將建立一個穩固的物件導向分析基礎。結果是，系統更易於建構、測試與維護。專注於系統的行為，保持語言清晰，並頻繁驗證。這種方法能帶來成功的軟體交付，無需依賴流行語或炒作。
請記住，目標是清晰明確。如果一位利害關係人能閱讀您的使用案例並完全理解系統將執行的動作，那麼分析就成功了。