在基於模型的系統工程（MBSE）的領域中，清晰度是成功之關鍵。對於初次接觸系統建模語言（SysML）的新手而言，最常產生混淆的問題之一，便是「活動圖與序列圖」兩種圖表。雖然兩者皆用以描述行為，但其解決問題的角度根本不同。了解何時應使用哪一種工具，對於建立穩健且可維護的系統模型至關重要。
本指南將深入探討這兩種行為圖。我們將探討其符號、語義意義，以及何種情境下其中一種圖表會優於另一種。結束後，您將具備明確的框架，以選擇符合您工程需求的正確圖表。
理解SysML中的行為 🛠️
在區分特定圖表類型之前，我們必須先理解SysML所模擬的內容。SysML旨在捕捉需求、結構、行為與約束。其中，行為通常是最抽象的層面，它回答的問題是：「系統做什麼？」以及「它是如何執行的？」
SysML中的行為並非僅僅是一連串功能的清單。它代表系統在時間或狀態變化中的動態面向。為模擬此行為，SysML提供了多種圖表類型，其中活動圖與序列圖最為突出，用以描述操作邏輯。儘管它們經常互為補充，但並非可互相替代。
- 活動圖著重於流程中控制與資料的流動。
- 序列圖著重於各部分在時間軸上的互動。
活動圖：流程流動 🔄
活動圖是SysML行為建模的主力工具。它大量借鑒自UML，但已針對系統工程進行調整。其主要目的在於模擬系統或子系統的功能流程。基本上，它是一種結合系統工程語義的流程圖。
核心元件與符號 📝
活動圖由多個關鍵元件組成，用以定義工作如何在系統中流動：
- 起始節點：一個實心黑圓圈，表示流程的起點。每個活動應僅有一個起始節點。
- 活動狀態：一個圓角矩形，代表流程中的特定步驟或動作。這正是「工作」執行的地方。
- 控制流：一個有方向的箭頭，顯示步驟的順序。它決定了執行的順序。
- 物件流：一個虛線箭頭，表示資料或物料的移動。這對於追蹤動作之間的輸入與輸出至關重要。
- 節點：菱形圖形，用於合併或分割流程。它們用來處理決策點與平行分支。
- 泳道：水平或垂直的區隔，根據責任歸屬來分組活動（例如：「軟體」、「機械」、「操作員」）。
何時使用活動圖 🎯
活動圖在主要關注流程的邏輯時表現出色。當您需要時，應使用此圖表：
- 您需要描述一個複雜的演算法或決策樹。
- 您希望可視化資料或物料在系統中的流動。
- 您正在定義特定使用案例或任務情境的工作流程。
- 並行性是該流程的關鍵特徵（例如，並行處理資料流）。
- 您需要透過泳道展示不同利害關係人的責任。
例如，考慮起落架系統。活動圖可清楚顯示事件的順序：「伸出起落架」→「檢查位置」→「若鎖定，顯示正常」→「若未鎖定，重試」。控制流決定順序，而物件流可能顯示液壓壓力信號在泵與閥門之間的傳遞。
序列圖：互動時間軸 💬
雖然活動圖著重於流程，序列圖則著重於互動。它們模擬系統各部分如何相互溝通以達成目標。序列圖的定義特徵是明確表示時間。
核心元件與符號 📝
序列圖依賴一組不同的視覺元素來傳達時間與溝通：
- 生命線：垂直虛線，代表互動中的參與者（物件、組件或角色）。每條生命線頂部都有名稱。
- 激活條：生命線上的矩形，表示參與者處於活躍狀態或執行操作的時間。
- 訊息：生命線之間的水平箭頭，代表呼叫、訊號或回傳。它們是互動的核心機制。
- 合併片段：帶有標籤的方框，例如alt（替代），opt（選擇性），或par（並行），用於處理序列中的邏輯。
- 時間軸： 縱向方向代表時間的流逝。圖中位置較低的事件發生得較晚。
何時使用序列圖 🎯
當主要關注點是介面 以及 時序 時，應使用此圖表。當：
- 您需要定義兩個子系統之間的 API 或介面。
- 時序限制至關重要（例如，響應時間、延遲）。
- 您正在建模特定的訊息交換協議。
- 您需要展示物件在特定情境下的生命週期。
- 您正在根據需求驗證互動序列。
回到起落架的範例，序列圖將著重於訊號的交換。它會顯示「指令模組」向「液壓控制器」發送「伸出」訊息，隨後液壓控制器啟動「閥門」。它會明確顯示指令與液壓壓力到達致動器之間的延遲。這種時間上的細節在活動圖中很難呈現。
關鍵差異一目了然 📊
為了強化區別，我們可以從多個維度比較這兩種圖表。此表格突顯了它們在結構與語義上的差異。
| 特徵 | 活動圖 | 序列圖 |
|---|---|---|
| 主要關注點 | 控制與資料流 | 互動與時序 |
| 時間表示 | 隱含（節點順序） | 明確（縱軸） |
| 參與者 | 泳道或動作 | 生命線 |
| 流程機制 | 控制流 / 物件流 | 訊息（呼叫/信號） |
| 平行性 | 分割/合併節點 | 平行生命線 / par片段 |
| 最適合 | 流程邏輯、演算法 | 介面合約、協定 |
決策指南：該選擇哪種圖表？ 🧭
選擇正確的圖表並非出於偏好；而是要忠實反映系統的實際情況。請使用以下決策矩陣來引導您的建模工作。
- 提問：重點是否在函數的內部邏輯？
若是，請使用 活動圖。若該函數涉及分支邏輯、迴圈或複雜的資料轉換，活動圖能提供必要的細節層級。 - 提問：重點是否在不同部分之間的通訊？
若是，請使用 序列圖。若系統行為由部分A與部分B之間的互動方式所定義，序列圖能清楚呈現介面。 - 提問：時序限制是否至關重要？
若系統必須在X毫秒內回應，序列圖對於呈現延遲與處理時間至關重要。 - 提問：我是否需要追蹤物料或資料流？
活動圖在追蹤資源（物件流）的實體或數位移動方面更具優勢。序列圖追蹤的是資訊，不一定是實體物料。
同時使用兩者很常見。高階的活動圖可能定義任務流程，而序列圖則深入探討該流程中的特定互動。這種層級化方法可避免認知負荷過重，並維持模型的清晰度。
常見問題（Q&A） ❓
為進一步釐清細節，以下為在SysML建模過程中常見問題的解答。
Q1：我可以用序列圖取代活動圖嗎？
在某些簡單情況下，答案是肯定的。若一個流程僅涉及兩個組件交換單一訊息，序列圖已足夠。然而，隨著複雜度增加，序列圖會因生命線過多而變得混亂。活動圖在處理複雜內部邏輯時更具可擴展性。將一種圖表替換為另一種，通常會導致控制流程或時序資訊的遺失。
Q2：圖表是否必須完全一致？
是的，一致性對於MBSE的完整性至關重要。若活動圖顯示「檢查感測器」步驟，則代表該步驟的序列圖必須顯示發送至感測器的訊息。不一致會導致實作與測試階段產生模糊性。您應在活動圖的步驟與序列圖的互動之間維持可追溯性連結。
Q3：如何在SysML中建模並行處理？
在活動圖中，使用一個分割節點來創建多個並行流程，並使用一個分叉節點來將它們重新同步。在序列圖中，使用par合併片段來表示訊息在不同生命線之間同時傳送。雖然視覺表現不同，但邏輯意圖是一致的。
Q4：內部方塊圖（IBD）在此扮演什麼角色？
內部方塊圖定義了結構。它顯示了介面和連接器。序列圖使用IBD中定義的介面作為訊息的端點。活動圖使用IBD中定義的組件作為泳道或執行動作的物件。若未先在IBD中定義結構，就無法有效建立序列圖或活動圖。
Q5：序列圖能否顯示資料流？
無法以與活動圖相同的方式直接顯示。序列圖顯示的是訊息，其中包含資料。然而，它們不會明確顯示資料的轉換過程。若需顯示資料正在被修改（例如「計算值」→「儲存值」），活動圖更為合適。序列圖假設訊息攜帶載荷，但不會模擬載荷內部的轉換過程。
Q6：哪種圖表更適合用於需求驗證？
這取決於需求類型。若需求為行為性（「系統應循環切換模式……」），活動圖通常更適合用來驗證狀態轉換。若需求為介面導向（「系統應在100毫秒內傳送訊號……」），序列圖則是主要的驗證工具。
清晰度的最佳實務 ✨
為確保您的模型在專案整個生命周期中仍具可讀性與實用性，請遵循以下最佳實務。
- 限制範圍： 不要試圖在單一圖表中建模整個系統。將活動分解為子活動，將序列分解為具體情境。
- 節制使用泳道： 在活動圖中，過多的泳道會造成「義大利麵圖」。應依子系統或利害關係人分組，而非依單一組件分組，尤其當系統規模龐大時。
- 明確標示訊息： 在序列圖中，依訊息所觸發的動作命名。避免使用「傳送資料」等泛稱。應使用「傳送遙測資料」或「請求校準」等明確名稱。
- 維持可追溯性： 將圖表元素與需求連結。若活動節點與需求連結，請確保對應的序列訊息也已連結。如此可建立完整的驗證路徑。
- 一致的符號： 堅持使用一種符號標準（例如SysML 1.5或1.6）。除非為舊系統相容性所必要，否則不要任意混合使用UML與SysML符號。
將行為與結構整合 🔗
行為圖並非孤立存在。它們必須建立在系統結構之上。方塊定義圖（BDD）與內部方塊圖（IBD）提供了上下文。
建立活動圖時，動作應對應於BDD中定義於方塊上的操作。若您有一個命名為「啟動引擎」的動作，則結構圖中的「引擎方塊」上應有對應的操作。此對齊確保行為模型可執行，並可追溯至實際設計。
同樣地，序列圖中的生命線應對應於IBD中定義的方塊實例。這確保互動邏輯能直接映射至實際介面。若缺乏此整合，行為模型將僅僅是理論上的練習，而非實際的工程產物。
避免常見陷阱 ⚠️
即使是經驗豐富的建模人員也可能陷入陷阱。請對這些常見問題保持警覺。
- 重疊的關注點：不要以令人困惑的方式混合控制流與資料流。若涉及複雜的資料轉換，建議使用專用的資料流圖，或確保物件流與控制流明確區分。
- 忽略時間：活動圖通常不具時間性。除非加入特定的時間約束，否則不要假設它們代表實際的即時執行。應使用序列圖進行時間驗證。
- 過多的生命線：包含超過五條生命線的序列圖通常難以閱讀。應將互動分組，或使用子序列來管理複雜性。
- 遺漏錯誤處理： 兩種圖表類型通常只關注「順利路徑」。請確保使用「alt」片段來建模失敗情境，並在活動圖中加入判斷節點。alt片段來建模失敗情境，並在活動圖中加入判斷節點。
重點摘要 📌
在活動圖與序列圖之間做出選擇，是一項基於您需要傳達資訊性質的戰略決策。活動圖可呈現流程的邏輯與流程，非常適合描述內部系統行為與資料轉換。序列圖則能呈現元件之間的互動與時間關係，非常適合用於介面定義與協定驗證。
透過理解兩者的優勢與限制，您可以建立不僅精確，且能有效促進工程團隊溝通的SysML模型。使用活動圖來定義流程的「如何」，使用序列圖來定義互動的「何時」與「誰」。將兩者結合穩固的結構基礎，可建立一個全面且經得起時間考驗的MBSE模型。
請記住，建模是一個迭代的過程。您可從活動圖開始以理解流程，隨著設計逐漸成熟，再利用序列圖來細化互動。這種靈活性正是SysML標準的關鍵優勢。