創建清晰且有效的視覺模型是穩健系統設計的基石。當利益相關者和開發人員查看圖表時，他們需要明確理解系統的功能，而不會產生歧義。用例圖正是為了這個目的，用以捕捉參與者與系統之間的互動。然而，如果底層邏輯不穩固，創建這些圖表往往會導致混淆。本指南提供了一種結構化的方法，確保您的圖表準確、易讀且具有價值。
🛠️ 第一階段：定義系統邊界
在繪製任何一個方框或小人圖形之前，您必須先明確範圍。系統邊界定義了系統內部與外部的內容。這種區分至關重要，因為它決定了哪些元素屬於功能需求，哪些是外部影響因素。
- 識別核心系統：明確標示代表系統的矩形。避免使用「系統」之類模糊的標籤。應使用具體名稱，例如「支付處理模組」或「庫存管理系統」。
- 標記外部實體：矩形以外的任何內容都是參與者或外部系統。請確保這些內容不被畫在邊界內，除非它們是子系統。
- 釐清資料流：雖然用例圖不會明確顯示資料流，但邊界暗示了資料進入和離開功能邏輯的位置。
若沒有明確的邊界，參與者可能看起來是在與內部細節互動，而非與提供的服務互動。這將導致模型過於細緻，難以維護。
👥 第二階段：正確識別參與者
參與者代表與用例系統互動的人或系統所扮演的角色。他們是動作的啟動者或輸出的接收者。正確識別參與者往往是圖表繪製中最常見的錯誤來源。
什麼是參與者？
參與者是一種角色，不一定是特定的人。一個人可以扮演多個角色，而一個角色也可以由多個人扮演。例如，「經理」是參與者，而不是「約翰·史密斯」。此外，參與者也可以是另一個系統，例如外部 API 或遺留資料庫。
- 主要參與者：他們啟動互動以達成特定目標。他們是系統的使用者。
- 次要參與者：這些是主系統為完成任務而互動的系統或服務。它們提供資料或服務，但不會啟動用例。
- 通用與具體：避免列出具體個人。應使用基於角色的名稱，例如「客戶」、「管理員」或「第三方服務」。
常見的參與者錯誤
| 錯誤的方法 | 正確的方法 |
|---|---|
| 標示「約翰·多」 | 標示「註冊使用者」 |
| 將參與者放置在系統邊界內 | 將參與者放置在系統邊界外 |
| 為每個畫面創建參與者 | 為功能角色創建參與者 |
| 忽略系統與系統之間的參與者 | 將外部 API 當作參與者納入 |
透過遵循基於角色的命名與正確的放置方式，即使人員更動，圖表仍能保持穩定。
🎯 第三階段：定義使用案例
使用案例代表一個完整的功能單元，能為參與者提供價值。它不是單一動作，而是一連串達成目標的動作。使用案例的命名規範對於清晰表達至關重要。
命名規範
使用案例的名稱應為動詞短語，從參與者的角度描述動作。應簡潔明瞭，但又具備足夠的描述性，能獨立表達意義。
- 動詞-物件格式：範例包括「處理訂單」、「產生報表」或「更新個人資料」。除非指特定文件而非動作，否則應避免使用名詞如「訂單處理」。
- 以目標為導向：請問自己：「參與者想要達成什麼目標？」如果答案是「支付帳單」，使用案例應為「支付帳單」，而非「支付帳單畫面」。
- 範圍一致性：確保所有使用案例處於相同的抽象層級，不要將高階目標（如「管理帳戶」）與低階步驟（如「輸入密碼」）混在一起。
細節程度檢核
若使用案例過於廣泛，會變得模糊；若過於狹窄，則會造成混亂。一個良好的準則是：使用案例應能在單一會話中由參與者完成，或代表一個明確的商業交易。複雜的工作流程應拆解為較小的使用案例，並透過關係連結。
🔗 第四階段：繪製關係
使用案例圖的威力在於參與者與使用案例之間，以及使用案例彼此之間的關係。這些線條傳達了系統的邏輯。
關聯
連接參與者與使用案例的實線表示該參與者與該功能互動。每個參與者至少應有一個關聯，每個使用案例也至少應有一個參與者。
- 方向性： 雖然通常繪製為雙向，但邏輯流程通常從發起請求的參與者開始。
- 多個參與者： 單一使用案例可連結至多個參與者。例如，「檢視報表」可能連結至「經理」與「審計員」。
包含關係
包含關係表示一個使用案例總是包含另一個使用案例的行為。被包含的使用案例是基礎使用案例達成目標所必需的。可將其視為子程序。
- 何時使用： 當多個使用案例共享共通功能時使用。例如，「驗證使用者」可能被包含在「登入」、「重設密碼」與「變更憑證」中。
- 符號表示： 通常以虛線箭頭表示，標籤為「<<include>>」，由基礎使用案例指向被包含的使用案例。
延伸關係
擴展關係表示選擇性行為。擴展的用例在特定條件下向基本用例添加功能。這對於錯誤處理或選擇性功能非常有用。
- 何時使用：用於異常或變體情況。例如，“發送通知”可能僅在付款失敗時擴展“下訂單”。
- 條件性： 始終明確定義擴展點或條件。基本用例在沒有擴展的情況下也能正常運作。
泛化
泛化用於繼承。特化的參與者或用例會繼承一般化參與者或用例的行為。這可減少圖表中的重複。
- 參與者繼承： 如果「高級用戶」繼承自「註冊用戶」，則無需再次繪製「註冊用戶」的所有關聯。
- 用例繼承： 如果「生成月度報告」是「生成報告」的一種特定類型，可以使用泛化來顯示層次結構。
🚫 第五階段：避免常見陷阱
即使經驗豐富的建模者也會犯錯。以下是常見錯誤的檢查清單及其解決方法，以確保圖表品質。
| 陷阱 | 影響 | 解決方案 |
|---|---|---|
| 重疊的參與者 | 對誰做什麼感到混淆 | 明確區分參與者；若角色相似，可使用泛化 |
| 循環依賴 | 破壞流程的邏輯循環 | 審查包含/擴展邏輯；確保基本用例是自包含的 |
| 關係過多 | 圖表變得難以閱讀 | 整合共同行為；使用註釋說明詳細邏輯 |
| 遺漏參與者 | 系統視圖不完整 | 審查所有功能需求；確保每個用例都有啟動者 |
| 介面混淆 | 將使用者介面與邏輯混為一談 | 保持圖表專注於功能，而非螢幕佈局 |
| 未使用的使用案例 | 模型中的無用程式碼 | 定期審查；移除沒有參與者或依賴關係的使用案例 |
🔍 第六階段：驗證清單
在最終確定圖表之前，請逐一核對此驗證清單。這可確保模型穩健，並準備好交付給開發團隊。
- 完整性：每個使用案例是否至少有一個參與者？
- 一致性：所有參與者名稱是否與術語表一致？
- 清晰度：系統邊界是否明確標示？
- 準確性：關係（包含/擴展）是否邏輯上符合需求？
- 可讀性：佈局是否乾淨？線條是否無謂地交叉？
- 可擴展性：是否能在不破壞現有結構的情況下新增使用案例？
- 一致性：圖表是否與高階業務目標一致？
- 文件記錄：複雜的使用案例是否已透過註解或描述進行文件記錄？
🔄 第七階段：隨時間管理變更
需求會不斷演變，軟體很少是靜態的。使用案例圖必須視為一個活文件，反映系統的當前狀態。維護此文件與創建它同等重要。
版本控制
追蹤變更。當新增、修改或移除使用案例時，請更新圖表版本。這有助於審計並理解系統的演變過程。
影響分析
當需求變更時，分析其對圖表的影響。若引入新參與者，請檢查現有使用案例是否需要修改。若移除使用案例，請確保沒有其他使用案例透過包含關係依賴於它。
利害關係人審查
定期與利害關係人一起審查圖表。他們可以判斷模型是否仍符合他們對系統的心智模型。此反饋迴圈可確保圖表保持相關性。
📏 第八階段：確保清晰與一致性
視覺的一致性有助於理解。如果圖表看起來雜亂無章，其背後的邏輯也可能被視為雜亂無章。
- 對齊：對齊參與者與用例。使用格線或間距來建立結構化的佈局。
- 色彩使用：雖然在原始 HTML 中需避免使用 CSS 樣式，但在實際的建模工具中，可考慮使用色彩來區分主要與次要參與者，或突出顯示已棄用的用例。
- 標籤：確保所有標籤清晰可讀。除非是標準的產業術語，否則避免使用縮寫。
- 間距：在元件周圍留出足夠的空間，以防止線條與文字重疊。
🧩 與其他模型整合
用例圖很少單獨使用。當與其他建模技術整合時，效果最佳。
- 順序圖：使用順序圖來詳細說明特定用例內的互動流程。
- 類圖：使用類圖來定義用例中涉及的物件。
- 狀態圖：使用狀態圖來展示參與用例的物件的生命週期。
透過連結這些模型，您可以在不使用例圖本身過於雜亂的情況下，建立系統的全面視圖。用例圖仍作為理解功能性的入門點，而其他圖表則提供實作細節。
🏁 最終審查步驟
在分發圖表之前，進行最後一次合理性檢查。
- 將每個標籤大聲朗讀，以確保語法上合理。
- 確認沒有參與者是孤立且未連接的。
- 檢查 include/extend 關係是否未被混用。
- 確保系統邊界涵蓋所有預期的功能。
- 確認圖表能適配單一頁面，或邏輯性地分頁。
遵循此結構化檢查清單，可確保您的圖表不僅是圖片，更是有效的溝通工具。它們彌補了商業需求與技術實現之間的差距。透過專注於角色、目標與關係，您將建立出經得起時間與變革考驗的模型。
請記住，目標是清晰。如果利益相關者能看著圖表就理解系統的功能，您就成功了。持續聚焦於價值，保持結構邏輯性，並隨著需求演變持續維護圖表。