在物件導向分析與設計（OOAD）的複雜版圖中，物件的行為往往與其結構同樣關鍵。類別圖定義了物件「是什麼」是什麼」，而狀態圖則定義了物件「做什麼」做什麼」隨時間的變化。管理複雜的物件生命週期需要嚴謹的轉換建模方法，以確保系統在各種條件下都能以可預測的方式運作。本指南將探討狀態圖的機制，著重於它們如何為狀態變化決定功能性的動態系統帶來清晰度。
🎯 理解物件生命週期
軟體系統中的每個物件都存在於特定的持續時間內，從建立到銷毀經歷各個階段。這段旅程並非總是線性的。物件經常根據內部邏輯或外部事件在狀態之間來回轉換。若缺乏清晰的模型，這些轉換可能變得糾結，導致難以追蹤的錯誤。
考慮一個銀行交易系統。付款請求並非簡單地從「待處理」直接轉為「已完成」。它可能進入「處理中」、「失敗」、「已退款」或「爭議中」等狀態。每個狀態都帶有特定的權限與行為。例如，「已退款」的付款無法再次處理，而「待處理」的付款則可以被取消。
生命週期管理的關鍵面向包括：
- 狀態識別： 確定物件可以存在的不同模式。
- 事件觸發： 識別導致從一個狀態轉換到另一個狀態的因素。
- 保護條件： 定義轉換發生前必須滿足的邏輯約束。
- 動作： 指定進入、退出或完成狀態時執行的操作。
透過視覺化這些元素，架構師與開發人員能對系統行為達成共識。這種共享的心智模型能減少歧義，並促進利害關係人之間的溝通。
⚙️ 狀態圖的核心組件
狀態圖是有限狀態機（FSM）的視覺化表示。它由特定的符號與連接器組成，用以傳達控制流程。理解這些組件對於建構準確的模型至關重要。
1. 狀態
狀態代表物件生命週期中滿足某些條件、執行某些活動或等待某些事件的條件或情境。狀態通常以圓角矩形表示。
- 簡單狀態： 無法進一步分解的基本條件。
- 複合狀態： 包含子狀態的狀態，允許進行階層式建模。
- 初始狀態： 生命週期的起點，通常為實心黑圓。
- 終止狀態：生命週期的終止點，通常為另一個圓圈內的實心黑色圓圈。
2. 轉換
轉換定義了從一個狀態到另一個狀態的移動。它們由事件觸發，並可能涉及動作或保護條件。
- 事件：發生的事情（例如：使用者點擊、系統計時器、訊息到達）。
- 保護條件：一個布林表達式，必須評估為真，轉換才會發生。
- 動作：在轉換期間執行的操作（進入、退出或進行中）。
3. 匯集節點
匯集節點作為多個轉換匯聚或發散的路由點。它們用於管理複雜邏輯，同時避免在圖表中用冗餘箭頭造成混亂。
📋 狀態圖 vs. 類別圖 vs. 序列圖
要理解狀態圖在更廣泛的設計流程中的定位，將其與其他建模工具進行比較會有所幫助。下表概述了每種圖類型的主要重點與使用情境。
| 圖類型 | 主要重點 | 最佳使用情境 |
|---|---|---|
| 類別圖 | 結構與屬性 | 定義資料模型、關係與繼承。 |
| 序列圖 | 隨時間的互動 | 視覺化特定情境中物件之間的訊息流程。 |
| 狀態圖 | 內部行為 | 建模生命週期邏輯、限制與依賴狀態的行為。 |
雖然類別圖提供了骨架，但狀態圖提供了肌肉與神經系統。當物件的邏輯因其當前狀態而顯著變化時，狀態圖尤為寶貴。
🧩 為複雜性進行設計
簡單物件只有少數狀態和直觀的轉換。然而，複雜物件需要先進的建模技術以維持清晰度。當生命週期變得複雜時，僅依賴平面狀態圖會導致如義大利麵般雜亂的視覺效果，難以維護。
1. 階層式狀態（複合狀態）
複雜物件通常在更廣泛的狀態內具有子行為。例如，訂單物件可能處於「處理中」狀態。在「處理中」內部，它可能處於「驗證中」、「配送中」或「包裝中」。使用複合狀態可將這些子狀態歸類於父狀態之下。
- 優點：減少視覺雜亂並管理複雜性。
- 進入/退出動作：您可以定義在進入父狀態（在子狀態之前）和退出時（在子狀態之後）執行的動作。
2. 歷史狀態
當物件返回複合狀態時，通常需記住它上次停在哪裡。歷史狀態會保留最後活躍的子狀態。
- 淺層歷史：返回父狀態最後活躍的子狀態。
- 深層歷史：返回層級結構中某個子狀態最後活躍的子狀態。
3. 正交區域（並行）
某些物件會同時管理多個獨立的生命週期。例如，醫療裝置可能獨立追蹤「患者狀態」與「裝置電池」。正交區域允許您將狀態分割為多個獨立且並行運作的子區域。
- 實作：以虛線視覺化表示，將複合狀態分隔開來。
- 同步：轉換可能需要在區域之間發生，以協調行為。
🛠️ 設計流程
建立狀態圖並非隨意的繪圖行為，而是遵循結構化方法，以確保準確性與實用性。
步驟 1：識別物件
選擇需要生命週期管理的特定物件或實體。並非每個物件都需要狀態圖。請聚焦於具有顯著行為複雜性的實體。
步驟 2：定義初始與終止狀態
規劃生命週期的起點與終點。確保考慮到物件可能提前終止或遭中止的情境。
步驟 3：列出所有可能狀態
列出物件可持有的所有有效條件清單。請使用領域專家驗證此清單。常見陷阱包括遺漏狀態或將不同狀態混淆。
步驟 4：確定轉換與事件
繪製連接各狀態的箭頭。為每個箭頭標註觸發事件。請自問：「什麼導致此變更？」以及「此變更是否可能從任何狀態發生？」
步驟 5：新增保護條件
透過新增邏輯來精進轉換。若轉換僅在特定資料條件下發生，請以括號新增保護條件（例如：”[餘額 > 0]).
步驟 6：定義動作
指定副作用。哪些資料會被更新？哪些訊息會被傳送？哪些日誌會被寫入？這將圖表與實作邏輯連結起來。
⚠️ 常見陷阱與解決方案
即使是經驗豐富的設計師，在建立生命週期模型時也會遇到挑戰。及早識別這些陷阱，可大幅減少後續重構的工作量。
- 狀態爆炸：建立過多狀態，導致分支失控。
解決方案：使用複合狀態來歸納相似行為，並抽象化共通邏輯。 - 懸空轉換：留下沒有輸出轉換的狀態（死鎖）。
解決方案：檢視每個狀態，確保存在通往終止狀態或有效復原狀態的路徑。 - 隱含事件：假設事件會發生卻未加以定義。
解決方案：明確列出所有外部觸發器與內部觸發器。 - 重疊邏輯：多個轉換觸發相同動作卻未加以區分。
解決方案：在可能的情况下合併動作，或在狀態內使用進入/退出動作。
🧪 驗證與測試
狀態圖是一種規格。必須根據實際系統行為進行驗證。測試策略應與所定義的狀態和轉換相對應。
狀態覆蓋
確保測試案例涵蓋圖表中的每個狀態。這可驗證物件能否進入並停留在每個定義的狀態。
轉換覆蓋
測試連接每個狀態的每條箭頭。驗證事件是否觸發正確的轉換，並確認保護條件是否阻擋無效轉換。
例外處理
模擬出錯時的情況。為「錯誤」或「重試」情境新增狀態。強健的生命週期圖應能優雅地處理失敗。
🔄 實作模式
將狀態圖轉譯為程式碼需要嚴謹的方法。目標是保持邏輯與物件核心資料的解耦。
1. 狀態模式
狀態設計模式將每個狀態的行為封裝到獨立的類別中。主物件將行為委派給當前的狀態物件。這能將條件邏輯（if/switch）排除在主類別之外。
2. 開關-案例邏輯
對於較簡單的系統，狀態變數搭配開關-案例結構是有效的。雖然靈活性不如狀態模式，但對於線性流程而言更易於維護。
3. 事件佇列
複雜系統通常以非同步方式處理事件。實作事件佇列可確保轉換按發生順序處理，從而避免競態條件。
📈 維護與演進
軟體需求會改變，物件的生命週期也不例外。一份文件完善的狀態圖可作為隨著系統演進的活體產出物。
- 版本控制：將狀態圖視為程式碼。將其儲存於版本控制系統中，以追蹤隨時間的變更。
- 影響分析：新增狀態時，請檢查所有進入與離開的轉換，以確保一致性。
- 重構：若圖表過於密集，可將複合狀態拆解為獨立實體，或引入新的抽象。
💡 重點摘要
狀態圖是物件導向分析與設計中管理複雜物件生命週期的基礎工具。它們提供了一個清晰、視覺化的契約，說明物件如何隨時間表現行為。
透過專注於狀態、轉換與事件，團隊可以：
- 減少系統需求中的歧義。
- 早期識別死鎖與無法到達的狀態。
- 促進技術人員與非技術利害關係人之間的溝通。
- 將邏輯對應至視覺路徑，以提升測試覆蓋率。
採用此方法並不能消除複雜性，但能使其變得可管理。隨著系統成長，對結構化行為建模的需求也會增加。投入時間建立準確的狀態圖，將在系統可靠性與可維護性上獲得回報。
請務必保持圖表為最新狀態。過時的圖表比完全沒有圖表更糟。定期審查可確保模型持續真實反映系統的實際行為。