狀態機圖，通常稱為狀態圖，是可視化系統行為的關鍵工具。它們描繪出系統可能處於的各種狀態，以及導致系統從一種狀態轉換到另一種狀態的事件。無論您是在設計使用者介面、通訊協定，還是硬體控制器，理解實體的生命周期對於穩健的工程設計至關重要。
本指南提供了一種嚴謹的方法來構建狀態圖。我們將從最初的構想，逐步推進至最終完成並經過驗證的圖示。本指南未提及任何軟體工具，重點始終放在邏輯結構以及準確建模行為的方法論上。
理解核心元件 🧩
在繪製線條與形狀之前，您必須理解狀態機的術語。狀態圖不僅僅是流程圖；它代表時間與狀態。以下元素構成了任何圖示的基礎：
- 狀態： 系統在執行某項活動、等待事件或等待一段時間間隔期間所處的條件或情境。以圓角矩形表示。
- 轉移： 從一個狀態移動到另一個狀態的過程。由事件觸發。
- 事件： 在特定時間發生的某件事情，並觸發轉移。這可能是使用者點擊、感測器讀數，或系統訊號。
- 保護條件： 一個布林表達式，必須為真才能發生轉移。它作為事件的過濾器。
- 動作： 在進入、退出或執行轉移期間所執行的活動。
若未明確定義這些元件，圖示將變得模糊不清。在此處保持清晰可避免實作過程中的錯誤。
步驟 1：識別狀態 🏷️
構建狀態圖的第一步是列出系統可能處於的每一個狀態。這需要對系統需求有深入的理解。
應考慮的狀態類型
- 初始狀態： 系統的起始點。以實心圓形表示。應僅有一個初始狀態。
- 終止狀態： 系統的結束點。以一個較大圓形內的實心圓形表示。可以有多個終止狀態。
- 一般狀態： 系統的標準運作模式（例如：「閒置」、「處理中」、「錯誤」）。
- 複合狀態： 包含自身子狀態的狀態。透過將相關行為分組，有助於管理複雜性。
為確保完整性，請審查功能需求清單。針對每一項需求，請問：「此需求處於活躍狀態時，必須滿足什麼條件？」答案很可能就是一個狀態。
範例：自動販賣機邏輯
考慮一個簡單的自動販賣機。可能的狀態包括：
- 空閒（等待金錢）
- 金錢已投入
- 已選擇
- 正在發放
- 缺貨
明確列出這些狀態可防止在流程後續階段遺漏邊界情況。
步驟 2：定義轉移 🔗
一旦狀態被識別出來，你就必須確定系統如何在這些狀態之間移動。這包括識別觸發這些移動的事件。
將事件映射到動作
針對每個狀態，列出可能發生的事件。然後，決定結果：
- 停留在當前狀態： 此狀態下該事件無關或無效。
- 轉移到另一個狀態： 該事件觸發轉移。
- 執行一個動作： 轉移可能會執行特定功能（例如「列印收據」）。
在繪製之前，使用以下表格來組織你的轉移邏輯：
| 當前狀態 | 觸發事件 | 保護條件 | 目標狀態 | 動作 |
|---|---|---|---|---|
| 空閒 | 投入硬幣 | 無 | 金錢已投入 | 更新信用 |
| 金錢已投入 | 按按鈕 | 商品可取得 | 發放中 | 啟動馬達 |
| 金錢已投入 | 按一下按鈕 | 商品缺貨 | 閒置 | 退還硬幣 |
| 發放中 | 計時器已過期 | 無 | 閒置 | 清除顯示 |
以這種方式定義轉移，可確保每個事件都有明確的路徑。如果缺少轉移，則表示進入錯誤狀態或未處理的情境。
步驟 3：建立流程結構 🛣️
在狀態與轉移關係明確後，下一步是將它們以視覺與邏輯方式進行整理。此步驟涉及處理進入與離開的行為。
進入與離開點
每個狀態都可以有進入與離開的活動。這些是在系統進入或離開狀態時特別執行的動作。
- 進入動作 (/)：** 在進入狀態時立即執行。
- 離開動作 (exit/)：** 在離開狀態時立即執行。
- 執行動作 (do/)：** 在處於狀態期間持續執行。
例如，在「處理中」狀態下，進入動作可能是「初始化處理器」，執行動作可能是「計算資料」，而離開動作可能是「儲存結果」。
處理歷史記錄
複雜系統通常需要記住進入組合狀態前的位置。這可透過歷史轉移來管理：
- 淺層歷史： 回到父級組合狀態中最後一個活躍的狀態。
- 深層歷史： 回到層級結構中最後一個活躍的子狀態。
使用歷史轉移可簡化圖表，避免必須從每個可能的狀態畫線回到入口點。
步驟 4：利用層級結構管理複雜性 🏛️
隨著系統擴大，平面圖表會變得難以閱讀。層級結構允許您將狀態嵌套於其他狀態之中。
建立複合狀態
一個複合狀態包含子狀態。這對於將具有共同上下文的行為分組非常有用。例如，「付款」狀態可能包含「信用卡」、「現金」和「數位錢包」等子狀態。
繪製時：
- 在子狀態周圍繪製一個圓角矩形。
- 將外層矩形標記為複合狀態名稱。
- 確保進入複合狀態的轉移會進入初始子狀態。
- 確保從複合狀態離開的轉移源自最終子狀態。
正交區域
有時系統需要同時處於多個狀態。這透過在複合狀態內以虛線分隔的正交區域來表示。這允許並行處理邏輯，而不會產生錯綜複雜的轉移關係。
例如，在「執行中」的複合狀態中，您可能會為「音訊」設置一個正交區域，為「視訊」設置另一個。即使系統仍處於「執行中」狀態，這兩個區域仍可獨立改變狀態。
步驟 5：驗證與審查 ✅
最後一步是確保圖表準確反映需求，且無邏輯錯誤。
走查測試
進行一次腦力走查。從初始狀態開始，嘗試到達每個其他狀態。問自己：
- 我能到達每個狀態嗎？
- 我會卡在一個沒有出口的狀態嗎？
- 所有事件都已考慮到嗎？
- 邏輯是否能妥善處理錯誤？
應避免的常見錯誤
審查常見陷阱可避免日後大量返工。請參考此檢查清單：
| 錯誤類型 | 描述 | 解決方案 |
|---|---|---|
| 死結 | 一個除了自迴轉外沒有任何外出轉移的狀態。 | 確保每個狀態都有一條出口路徑。 |
| 無法到達的狀態 | 無法從起始點進入的狀態。 | 從初始狀態追蹤路徑。 |
| 模糊的轉移 | 同一狀態下由相同事件觸發的多個轉移。 | 使用守衛條件來區分。 |
| 缺少錯誤處理 | 無針對無效輸入的處理路徑。 | 新增「錯誤」或「重試」狀態。 |
實用應用 💡
狀態圖具有多樣性。以下是它們能提供價值的幾個情境：
- 使用者介面設計： 描繪導航流程、彈出對話框和表單狀態。
- 硬體控制： 管理電源狀態、馬達控制和感應器讀取。
- 通訊協定： 定義握手程序、連線狀態和逾時行為。
- 商業邏輯： 追蹤訂單狀態、核准工作流程和訂閱等級。
在每個情境中，圖表都扮演著設計師與開發人員之間的合約角色。它能減少歧義，並確保所有人理解預期的行為。
優化圖表以提升清晰度 🎨
邏輯正確後，應著重於呈現方式。若圖表難以閱讀，將無法有效使用。
- 減少線條交叉： 調整狀態排列，以減少線條交叉的數量。這能改善視覺流暢度。
- 一致的符號使用： 在文件中全程使用標準符號來表示狀態、事件和動作。
- 邏輯分組： 使用複合狀態或背景容器，以視覺方式將相關狀態分組。
- 註解： 加入簡要註解，以解釋無法單獨透過圖表表達的複雜邏輯。
概念定稿 🏁
建立狀態圖是一項精確性的練習。它需要將複雜行為拆解為明確且可管理的片段。透過遵循這些步驟，可確保最終模型準確、可維護且清晰。
請記住，圖表是活文件。隨著需求變更，狀態圖必須持續演進以反映新的現實。定期更新可避免文件淪為過時的遺產。
從狀態開始。繪製轉移。驗證邏輯。檢查錯誤。這種系統化的方法可確保高品質的狀態機設計，無需依賴複雜工具。