系統建模經常讓人覺得像是在迷宮般的方框與箭頭中穿行。雖然結構圖定義了系統由什麼組成，行為圖則定義了系統的動作。在這些圖中，狀態機圖最為突出，是捕捉系統動態行為的主要工具。它不僅僅是流程圖，更是一台邏輯引擎，決定了系統如何隨時間對事件作出回應。理解這些圖中的隱藏邏輯，對於確保系統設計的穩健性至關重要。
本指南探討 SysML 狀態機的運作機制。我們將超越基本語法，深入分析決定系統可靠性的架構決策。從嵌套層次結構到並行區域，每個細節都至關重要。建模的精確性直接轉化為實現的精確性。
為什麼狀態機定義了系統的完整性 🔒
現代系統很少是線性的。它們以模式運作，處理異常，並保留對過去事件的記憶。單純的步驟序列無法捕捉到一個系統必須根據當前狀態暫停、恢復或以不同方式回應的複雜性。狀態機提供了描述這些條件的正式方法。
在建模複雜系統時，僅依賴活動圖可能會導致模糊不清。活動圖顯示流程，但本身並不會自動追蹤狀態。狀態機則透過明確定義系統在任何時刻的狀態來彌補這一缺憾。這種區別對於安全關鍵系統、嵌入式控制器和分散式架構至關重要。
使用狀態機的主要優勢包括：
- 明確的狀態定義： 系統可能處於的每種條件都以視覺方式明確標示。
- 事件驅動的邏輯： 變化的觸發條件與轉移之間有明確的關聯。
- 歷史記憶保留： 在進入時能夠記住先前的配置。
- 並發性： 建模多個同時發生的獨立行為。
SysML 狀態機的核心結構 🏗️
要解碼邏輯，必須理解基本的構建模塊。狀態機由狀態和轉移組成。這些元素透過事件和守衛進行互動。對每個組件的清晰理解可以防止建模錯誤傳播到設計階段。
狀態與初始點
狀態代表系統在滿足不變式、等待事件或執行活動期間所處的條件。旅程從初始點開始。這是一個實心黑圓圈，表示系統的起始狀態。從此處出發，必須產生第一個轉移，以定義進入行為。
轉移與事件
轉移連接一個狀態到另一個狀態。它代表狀態的改變。要發生轉移，通常需滿足三個條件：
- 事件： 必須有某件事發生（例如，信號到達、計時器超時）。
- 守衛條件： 必須求值為真的布林表達式。
- 效果： 轉移過程中執行的動作（例如，記錄資料、發送訊息）。
進入與退出動作
狀態通常在進入或離開時需要特定行為。這些行為被定義為進入與退出動作。
- 進入動作 (/entry)： 狀態變為活躍時立即執行。
- 離開動作 (/exit)： 離開狀態前立即執行。
- 執行活動： 系統處於該狀態期間持續執行的動作。
考慮一個系統進入「校準」狀態的情境。進入動作可能用於初始化感測器。執行活動可能執行持續檢查。離開動作可能用於儲存校準資料。若無這些區別，操作的時序將變得不明確。
精確管理狀態歷史 🕰️
SysML 最強大的功能之一是追蹤歷史的能力。當系統離開一個複雜狀態並稍後返回時，它會從頭開始重新啟動，還是從離開的位置繼續？此決定定義了系統在間歇性運作下的行為。
淺層歷史與深層歷史
歷史狀態使系統能夠記住過去的配置。共有兩種不同類型：
- 淺層歷史： 記住複合狀態中的頂層狀態。若系統返回，它將進入最後一次的頂層子狀態，忽略更深層級。
- 深層歷史： 記住整個嵌套路徑。若系統返回，它將重新進入當時所在的精確子狀態，包括所有嵌套層級。
此區別對於經歷複雜模式切換的系統至關重要。深層歷史狀態可確保操作上下文得以保留，從而減少重新初始化程序的需求。
歷史狀態的實作
在圖中，歷史狀態以內部帶有「H」的圓圈表示。它通常透過事件觸發的轉移與狀態相連。淺層與深層歷史的選擇必須明確記錄，因為這會影響系統的恢復邏輯。
透過正交區域實現並發 ⚡
系統很少僅在單一維度下運作。例如車輛系統會同時管理驅動、煞車與導航。這些行為通常彼此獨立，卻發生在同一個系統實例中。SysML 透過正交區域來處理此類情況。
分割與合併狀態
為模擬並發，一個狀態會被厚線分隔為多個區域。此線作為分割點。當系統進入複合狀態時，所有區域會同時激活。合併線則標示這些區域同步的位置。
正交建模的優點
- 解耦： 不同的關注點被分別建模。
- 清晰性： 降低單一單體狀態機的複雜度。
- 可擴展性： 可在不破壞現有邏輯的情況下新增並發行為。
然而，並發會引入同步風險。設計者必須確保跨區域的共享資源能正確管理，以避免競爭條件。
何時使用狀態機與活動圖 ⚖️
狀態機圖與活動圖之間經常會產生混淆。兩者都描述行為，但其範圍不同。選擇正確的工具取決於所建模邏輯的性質。
| 功能 | 狀態機圖 | 活動圖 |
|---|---|---|
| 主要關注點 | 系統模式與條件 | 流程流與演算法 |
| 狀態保留 | 明確（當前狀態的記憶） | 隱含（變數儲存資料） |
| 事件處理 | 反應式（由外部觸發驅動） | 主動式（由資料流驅動） |
| 並發 | 透過區域原生支援 | 透過分叉/合併支援 |
| 最適合 | 控制邏輯、模式、狀態 | 工作流程、資料處理 |
當系統必須等待事件或維持特定模式時，使用狀態機。當重點在於操作順序或資料轉換時，使用活動圖。通常需要混合方法，其中活動觸發狀態機的轉換。
常見的建模陷阱，應避免 ⚠️
即使是經驗豐富的建模者也可能引入模糊性。避免常見錯誤可確保模型始終保持為可靠的規格。
1. 狀態過於細緻
為每個微小的變數變更創建狀態，會導致圖形過於密集，難以閱讀。狀態應代表系統的重要條件，而非每個中間資料點。
2. 缺少預設轉換
每個狀態都應考慮意外事件。如果某狀態未定義特定事件，系統行為將未定義。應實作預設轉換或一般狀態處理機制來管理例外情況。
3. 順環依賴
在沒有保護條件的情況下創建立即迴圈的轉換可能導致無限執行。確保迴圈具有明確的退出條件或保護條件。
4. 忽略進入/退出效果
在狀態內放置邏輯但未定義進入或退出效果，可能會隱藏副作用。應始終明確說明狀態啟用或停用時發生的情況。
5. 控制與資料流程的混合
狀態機不是資料流程圖。雖然它們可以觸發資料操作，但主要邏輯應以控制為導向。將資料操作保留在活動圖或序列圖中。
將狀態邏輯整合至結構模型 🔗
狀態機並非孤立存在。它會與系統的結構模型互動。狀態機必須引用其他圖表中定義的零件、埠和訊號。
連結至零件
轉移通常會觸發系統特定零件上的操作。例如，「啟動引擎」的轉移可能會觸發「引擎控制器」零件上的操作。這種連結確保行為建立在實際或邏輯架構之上。
訊號傳播
狀態機中的事件通常是訊號。這些訊號必須定義為訊息流程或介面規格。確保訊號定義與接收者的期望相符，對於互操作性至關重要。
明確系統行為的最佳實務 📝
為維持模型的清晰度與權威性，請遵循以下指引。
- 命名一致性：轉移使用動作動詞（例如：「RequestStart」、「AbortProcess」），狀態使用名詞（例如：「Idle」、「Processing」）。
- 視覺層級：使用複合狀態來分組相關邏輯。不要在頂層塞入過多轉移。
- 守衛清晰度：保持守衛條件簡單。若條件複雜，應在其他地方定義為屬性或函數。
- 文件記錄：為複雜狀態添加註解，說明特定設定背後的設計理由。
- 審查迴圈：定期與利害關係人共同審查狀態機，確保邏輯符合運作需求。
複雜邏輯的進階模式 🚀
超越基礎層面，SysML 允許使用模式來處理複雜的場景。
虛擬狀態
虛擬狀態用於在不增加層級架構的情況下分組狀態。它們有助於視覺上整理圖表，而不影響邏輯轉移。這能讓圖表保持整潔，同時維持邏輯分組。
巨態
巨態是作為父機器中單一狀態的複合狀態。它們適用於抽象化。您可以將複雜的狀態機定義為巨態，並從更高層級的圖表中引用它。
子機器狀態
子機器狀態允許您引用整個外部狀態機。這促進了重用。若多個系統共享相同的驗證邏輯，可將其建模一次為子機器，並在需要時引用。
實作原則的結論 📊
系統的邏輯嵌入於其行為之中。透過掌握狀態機的細節，建模者能夠建立穩健、可維護且清晰的規格。從抽象需求到具體實作的過渡，正是由這些圖表所連結。
專注於清晰性而非複雜性。使用層次結構來管理深度。使用歷史記錄來管理記憶。使用並發性來管理並行性。當這些原則被一致應用時，系統行為將變得可預測且可靠。圖表成為一份活文件，引導開發與測試。
隨著系統的演進，持續優化模型。靜態模型會迅速過時。動態的建模過程可確保系統邏輯始終與實際運作情況保持一致。