軟體架構依賴於清晰性。當需求模糊時，產生的程式碼會變得脆弱。在早期設計階段，最重要的實體之一就是用例模型。它彌補了利益相關者需求與技術實現之間的差距。然而，這些模型經常因錯誤而建立，導致開發週期後期出現混淆。 📉
有缺陷的用例圖不僅看起來雜亂無章，還會造成歧義。開發人員可能開發出不需要的功能，而關鍵功能則被忽略。本指南提供了一種系統化的方法來識別並修正這些缺陷。我們將檢視模型的結構，找出常見的陷阱，並建立驗證協議。目標是確保每一項互動都精確定義。 ⚙️
🔍 理解用例的結構
在進行故障排除之前，必須先理解其預期結構。用例模型從外部實體的角度，代表系統的功能需求。它不是技術藍圖，而是一種行為模型。核心組成部分包括：
- 參與者：與系統互動的實體。可以是人類使用者，也可以是其他系統。
- 用例：系統為參與者執行的具體目標或任務。
- 系統邊界：一個方框，用來區分系統內部與外部的內容。
- 關係：連接參與者與用例，以及用例與其他用例的線條。
當這些元素中的任何一個出現錯位時，模型就會失去其效用。錯誤通常源自於混淆了「誰」與「什麼」，或誤解了系統的責任範圍。 🧩誰與什麼或誤解系統的責任。 🧩
⚠️ 常見缺陷：參與者模糊
最常見的混淆來源是參與者。參與者代表的是角色，而非特定的人或硬體設備。然而，建模者經常將具體的職稱誤認為是角色，或將系統組件視為使用者。這會導致範圍蔓延和溝通誤解。
❌ 問題：具體與抽象
如果圖表中列出John Smith作為參與者，這是錯誤的。John Smith 是一個實例。角色是管理員。如果 John 離職公司，需求並不會消失。系統仍然需要一名管理員來執行該功能。基於特定個人建立模型，會使設計與人員綁定，而非與功能綁定。
❌ 問題：系統作為參與者
另一個錯誤是繪製一個代表系統本身的參與者。在用例情境中，系統無法與自身互動。它與外部實體互動。如果模型顯示系統與資料庫互動，這只是內部實作細節，而非用例。此細節應出現在類圖或序列圖中，而非這裡。
✅ 解決方案：明確定義角色
為修正此問題，請審查每一個小人圖。請提出以下問題：
- 這個實體是否位於系統邊界之外？
- 這個實體是否發起請求或接收結果？
- 這是一個特定的人，還是一類人？
如果實體是特定的人，請將其重命名為其職位。如果實體是內部的，請從參與者清單中移除。這可確保即使人員變動或內部架構調整，圖表仍保持有效。🛡️
📏 常見錯誤：系統邊界混淆
系統邊界定義了專案的範圍。方框內的所有內容都在您的控制之下，方框外的所有內容都是環境。這裡的錯誤會導致範圍蔓延或規格不完整。📐
❌ 問題：責任外洩
一個常見錯誤是將本應位於邊界內的用例放置在邊界外。例如，如果一個產生報表用例被繪製在系統方框之外，這意味著系統不會產生它。然而，系統必須為報表生成資料。這個用例應位於內部。相反地，如果發送電子郵件位於內部，但系統僅觸發外部電子郵件伺服器，該操作可能被視為互動而非內部功能。
❌ 問題：遺漏外部依賴
相反地，有時模型未能顯示提供資料的外部參與者。如果系統依賴第三方 API 進行使用者驗證，該 API 應被表示為參與者或系統邊界互動。忽略此依賴關係會導致模型不完整。
✅ 解決方案：邊界測試
對每個用例應用邊界測試。問：系統執行此動作，還是外部實體執行此動作？
- 系統動作： 在方框內。（例如：驗證密碼）
- 外部動作： 在方框外。（例如：使用者輸入密碼）
確保所有互動都跨越邊界線。參與者必須與用例連接。如果某個用例沒有連接而孤立存在，則為孤兒用例，很可能不必要。
🔗 常見錯誤：關係管理失當
用例很少孤立存在。它們彼此相關。主要關係為包含, 延伸，以及一般化。錯誤使用這些連接器會導致需求中的邏輯錯誤。
❌ 問題：混淆 Include 和 Extend
這是建模中最技術性的錯誤。兩種關係都連接使用案例，但它們的用途不同。
- Include：強制行為。使用案例 A必須執行使用案例 B 以完成其目標。它是一個子集。（例如，下訂單 包含 驗證付款).
- Extend：選擇性行為。使用案例 A可能在特定條件下執行使用案例 B。它增加了功能。（例如，下訂單 延伸 套用折扣).
如果你使用Include來表示選擇性步驟，就會強制系統總是執行這些步驟，即使不需要。如果你使用Extend來表示強制步驟，可能會導致功能在開發過程中被跳過。
❌ 問題：循環依賴
使用案例不應彼此形成循環依賴。如果使用案例 A 包含使用案例 B，而使用案例 B 又包含使用案例 A，則流程將無法明確界定。這會產生一個邏輯悖論，導致開發中斷。
✅ 解決方案：關係驗證表
使用以下檢查清單，在最終確定圖表前驗證關係。
| 關係類型 | 強制還是選擇性？ | 依賴方向 | 範例 |
|---|---|---|---|
| 包含 | 強制性 | 基本案例取決於包含的案例 | 登入包含驗證憑證 |
| 擴展 | 選擇性 | 擴展案例取決於基本案例 | 結帳擴展禮品包裝 |
| 泛化 | 繼承 | 子類繼承父類行為 | 訪客使用者是一種使用者 |
檢視連接兩個使用案例的每一條線。如果連接是強制性的，必須是包含（Include）。如果是條件性的，必須是擴展（Extend）。立即移除任何循環箭頭。 🔀
📉 常見缺陷：範圍偏移
當使用案例過於詳細或過於抽象時，就會發生範圍偏移。使用案例應代表單一且可衡量的目標。它不應是流程，也不應是模糊的概念。
❌ 問題：將使用案例當作流程
一個常見的錯誤是使用暗示長流程的動詞短語來命名使用案例。例如，管理員工資料範圍過廣。它暗示了建立、更新、刪除和檢視。這實際上是四個不同的使用案例。
當使用案例範圍過廣時，測試將變得困難。當範圍過窄時（例如，按一下按鈕 A），這只是一次互動，而非目標。
❌ 問題：忽略非功能需求
使用案例著重於功能。然而，效能、安全性與可靠性是約束條件。雖然這些不會以獨立的使用案例形式出現，但會影響使用案例的定義。例如，處理交易必須定義為在 2 秒內完成的約束。如果模型忽略此點，技術實現將失敗。
✅ 解決方案：單一目標原則
將單一目標原則應用於每個使用案例。從參與者的觀點來看，這個使用案例是否能在一步內完成？如果不能，就將其拆分。🧱
- 不良範例： 管理庫存
- 良好：新增庫存項目
- 良好：更新庫存項目
- 良好：移除庫存項目
這種細節程度確保開發人員能準確估算工作量。同時也讓測試變得更容易。每個使用案例都成為一個獨立的測試案例。
🛡️ 驗證與審查流程
建立模型是一回事；驗證模型是另一回事。有缺陷的模型必然會在編碼階段暴露，導致返工。結構化的審查流程可降低此風險。
1. 利益相關者走查
向業務利益相關者展示圖表，請他們追蹤流程。這個故事對他們來說是否合理？如果他們無法解釋使用案例的功能，表示圖表仍不夠清晰。他們不應依賴技術術語來理解圖表。
2. 開發人員可行性檢查
請資深開發人員審查模型。他們可以發現業務分析師可能忽略的技術限制。例如，若使用案例需要即時資料同步，模型應反映延遲的影響。
3. 一致性檢查
確保與其他圖表的一致性。如果類圖顯示一個使用者實體，使用案例圖必須包含一個使用者參與者。如果資料庫結構變更，使用案例不應改變，除非業務目標改變。保持功能模型的穩定性。
📋 修正檢查清單
當你發現缺陷時，請遵循此修正順序。不要試圖一次修復所有問題。應將錯誤隔離。
- 步驟 1：驗證參與者。 它們是角色嗎？是外部的嗎？將具體名稱改為通用角色。
- 步驟 2：檢查邊界。 根據責任範圍，將使用案例移入或移出。
- 步驟 3：審查關係。 將錯誤的 Includes 改為 Extends，或反之亦然。打破循環依賴。
- 步驟 4：細化粒度。 將廣泛的使用案例拆分為具體目標。
- 步驟 5：記錄約束條件。針對特定使用案例附加的效能或安全需求，添加註解。
🚀 預防策略
模型定型後，要如何防止未來的錯誤？預防需要紀律與標準作業程序。
建立命名慣例
採用嚴格的命名慣例。所有使用案例應以動詞開頭，以名詞結尾（例如，取得發票）。所有參與者應為代表角色的名詞（例如，會計）。這種一致性讓掃描圖表變得更容易。
早期定義範圍
在繪製第一個方框之前，定義系統邊界。列出明確不在範圍內的項目。如果需求落在邊界之外，應記錄為外部相依性，而非使用案例。這可防止設計階段出現範圍蔓延。
迭代精化
不要期望第一稿就完美無缺。使用案例建模是迭代的。從高階概覽開始，後續迭代中逐步增加細節。這讓你在投入時間建立詳細關係之前，就能發現範圍錯誤。
標準化關係
團隊應共同決定「包含與延伸」的意義。有些團隊將「包含」視為強制，另一些團隊則視為常見。應就標準定義達成共識，以避免團隊成員之間產生混淆。將此定義記錄在專案術語表中。
🧩 實際情境分析
考慮一個電子商務系統正在被建模的情境。初步草圖顯示一個稱為處理付款的使用案例。它包含驗證卡片與付帳戶。它還延伸至應用優惠券.
分析：
- 處理付款範圍過廣。應拆分為啟動付款 和 確認付款.
- 驗證卡片是必要步驟。請保留為包含。
- 應用優惠券是可選的。請保留為延伸。
- 參與者應為顧客，而非買家.
透過細化此內容，開發團隊便能明確知道應撰寫何種程式碼。啟動付款使用案例觸發介面。確認付款使用案例處理交易。應用優惠券邏輯是可選的，僅在條件滿足時執行。
📝 模型完整性之最終思考
使用案例模型是一種溝通工具。其價值在於能為複雜需求帶來清晰度。當模型有缺陷時，溝通便會中斷。修復這些缺陷不僅僅是正確繪製線條；更在於確保商業邏輯正確無誤。
透過遵守嚴格的界限、準確定義角色並驗證關係，您將建立穩固軟體開發的基礎。現在花在修復模型上的努力，將在實作階段節省大量時間。專注於目標，而非語法。確保圖表真實反映系統的行為。🎯
定期審查模型可確保其與不斷演變的需求保持一致。隨著專案的擴展，重新檢視使用案例。移除過時的案例並新增新的案例。讓模型保持活躍。靜態模型會變成古董。動態模型才會持續成為指南。🌱