💡 主要要點
- 視覺化邏輯：狀態機圖提供了物件生命週期與時間演變行為的清晰視覺化呈現。
- 狀態管理：它們定義了特定條件（狀態）以及規則（轉移），用以規範狀態之間的移動。
- 事件驅動：只有當特定事件觸發轉移時，變更才會發生，確保系統回應受到控制。
- 並發：正交區域允許在單一狀態內同時建模多個獨立行為。
在統一建模語言（UML）領域中，很少有圖表能像狀態機圖一樣為動態系統提供如此高的精確度。雖然類圖描述結構，序列圖描述互動流程，但狀態機圖專注於單一物件的生命歷程。它們回答關鍵問題：此組件如何隨時間變化？在何種條件下會改變？當發生意外事件時會發生什麼？
理解這些圖表對於從事回應式系統、嵌入式軟體或複雜業務流程的系統架構師和開發人員而言至關重要。本指南探討狀態機建模的機制、進階功能與實際應用，且不依賴特定工具或供應商。
狀態機的核心元件 🏗️
狀態機圖由幾個基本元件組成。每個元件在定義系統行為方面都具有特定用途。掌握這些元件，便能建構出穩健的行為模型。
狀態
狀態代表物件生命週期中的一種條件或情境，在此期間物件可執行活動或等待事件。狀態以圓角矩形表示。狀態有幾種類型：
- 初始狀態：以實心黑圓點表示，標示狀態機的起始點。
- 終止狀態：以圓圈內的實心黑圓點表示，標示狀態機的終止。
- 簡單狀態：內部無結構的狀態。
- 複合狀態：包含子狀態的狀態。這允許在單一狀態內建立層次結構與複雜性。
- 子機器狀態：調用另一個狀態機圖的狀態，促進重用。
轉移
轉移定義了從一個狀態到另一個狀態的移動。它們由事件觸發，可能包含條件與動作。視覺上，轉移以從源狀態指向目標狀態的箭頭表示。
事件
事件是一種會觸發轉移的重要發生。事件可以是：
- 訊號事件： 異步通訊。
- 呼叫事件： 同步方法調用。
- 變化事件： 變為真的布林表達式。
- 時間事件： 基於時間長度或特定時鐘時間的條件。
動作與守衛
當轉移發生時，可能會執行動作。這些動作以關鍵字「action」表示。守衛條件是用方括號包圍的布林表達式「[condition]」。只有當守衛評估為真時，轉移才會發生。如果有多個可能的轉移，則會選擇第一個守衛為真的轉移。
進階建模技術 🧠
隨著系統變得越來越複雜，基本狀態和轉移通常已不夠用。進階功能可讓我們更細膩地模擬現實世界的場景。
正交區域
複雜物件通常會同時展現多種行為。正交區域允許將一個複合狀態分割成獨立的子機器。例如，一個「Phone」狀態可能有一個區域用於「Ringing」，另一個區域用於「Charging」。這些區域會並行運作，表示手機可以在充電時響鈴。這由一條虛線分割複合狀態來表示。
歷史狀態
歷史狀態會在複合狀態離開和重新進入時，保留該狀態的資訊。共有兩種類型：
- 深層歷史： 記住最後一個活躍的子狀態。
- 淺層歷史：記住了最後一個活躍的頂級子狀態。
這對於使用者介面或工作流程至關重要，當返回到一個複雜的畫面時，應能恢復先前的上下文，而無需重新初始化整個流程。
進入、離開與執行活動
在一個狀態內，可以觸發特定活動：
- 進入：進入狀態時僅執行一次。
- 離開：離開狀態時僅執行一次。
- 執行：狀態處於活躍狀態時持續執行。這對於輪詢、監控或維持循環非常有用。
狀態機與活動圖的比較 ⚖️
選擇正確的圖表類型至關重要。雖然兩者都用來模擬行為，但用途不同。下表說明了何時應使用哪一種。
| 功能 | 狀態機圖 | 活動圖 |
|---|---|---|
| 重點 | 物件生命週期與反應性 | 工作流程與控制流程 |
| 觸發條件 | 事件觸發轉移 | 前一項活動完成後觸發下一項 |
| 並發 | 正交區域 | 分叉/合併條 |
| 最適合應用於 | 嵌入式系統、通訊協定 | 商業流程、演算法 |
設計模式與實作 🛠️
在程式碼中實作狀態機需要仔細規劃，以避免產生類似意大利麵般的邏輯。幾種設計模式可協助達成此目的。
狀態模式
在物件導向程式設計中，狀態模式允許物件在其內部狀態改變時改變其行為。每個狀態都由一個類別來表示。這封裝了與狀態相關的邏輯，使主類別更為簡化。
表格驅動的狀態機
對於較簡單的系統，查閱表可以定義轉移。目前狀態和事件作為關鍵字，用來決定下一狀態和要執行的操作。這種方法在解析或協定處理方面非常高效。
應避免的常見陷阱 ⚠️
即使經驗豐富的建模者也可能陷入陷阱。記住這些常見問題，能提升圖表的品質。
- 狀態爆炸：創建太多狀態會使圖表難以閱讀。使用複合狀態來整合相關行為。
- 無法達成的狀態： 確保每個狀態都能從初始狀態到達。死路會讓維護者感到困惑。
- 遺漏的轉移： 為所有事件定義行為。如果事件在未預期的狀態下發生會怎麼樣？使用預設狀態或錯誤狀態。
- 複雜的守衛條件： 避免過於複雜的守衛條件。如果條件太難閱讀，可考慮將邏輯拆分成獨立的狀態。
實務範例：訂單處理 🛒
考慮一個電子商務訂單系統。訂單物件會經過多個狀態：
- 已建立： 訂單已儲存但尚未確認。
- 已付款： 付款已驗證。
- 已出貨： 貨物已發出。
- 已送達： 客戶已收到商品。
- 已取消： 流程已終止。
轉移由事件觸發，例如ConfirmPayment, ShipOrder，或請求取消。保護條件確保訂單在付款確認前無法發貨。一個執行活動可能在處於已建立狀態時監控付款狀態。
結論與最佳實務 ✅
狀態機圖是捕捉軟體組件動態行為的強大工具。它們提供了一種嚴謹的方法，用以定義系統如何隨時間對刺激做出反應。透過遵循標準的UML符號並著重於清晰性，團隊可以減少系統需求中的模糊性。
在建模時，應優先考慮可讀性。一個容易理解的圖表，比技術上完美卻令人困惑的圖表更有價值。使用複合狀態來管理複雜性，並利用歷史狀態來保留上下文。定期與利益相關者一起審查這些圖表，以確保它們符合實際的業務需求。
有效的建模能帶來更可靠的程式碼。當設計清晰時，實作會自然跟進，從而減少錯誤和維護成本。無論是設計交通號誌控制器還是客戶入口網站，狀態機都為複雜行為提供了結構化的途徑。