系統建模語言，通常稱為SysML，是一種專為系統工程應用設計的專業化建模語言。它旨在捕捉、分析和設計複雜系統。無論您從事航空專案、汽車設計或軟體架構，理解術語對於利益相關者之間的清晰溝通至關重要。本指南解析該領域所使用的關鍵詞彙，幫助您清晰地掌握技術環境。
系統建模語言入門 🏗️
SysML擴展了統一建模語言（UML），以更好地滿足系統工程的需求。雖然UML主要著重於軟體，SysML則涵蓋系統的物理、資訊與行為面向。它依賴一組圖表與元件來描述系統的運作方式。掌握這些術語，使工程師能夠建立既精確又易懂的模型。
初學時，常會遇到縮寫與特定定義。本術語表涵蓋了您在圖表與文件中經常看到的最常見術語。目標不僅是提供定義，更著重於提供上下文，確保您理解每個術語在整體建模工作中的角色。
核心結構元件 🔨
系統的結構定義了其物理或邏輯組成。在SysML中，這主要透過「Block」來描述。Block代表一個結構單元，可以是組件、零件或系統本身。它是定義系統組成要素的基本構建模塊。
- Block： 具有明確定義介面與行為的結構單元。它封裝了功能與資料。
- Part： 在較大Block結構內的Block特定實例。它代表系統內部的一個組件。
- Property： 描述資料或特性的Block屬性。屬性可具有類型，例如整數或字串。
- 參考屬性： 連結至另一個Block實例的屬性。這建立了一種連結關係，但不包含所有權。
- 值屬性： 用來儲存簡單值（如數字或文字）的屬性，而非指向另一物件的參考。
理解Block與Part之間的差異至關重要。Block定義類型，而Part則定義配置中的具體實例。例如，「引擎」可能是一種Block類型，而「引擎」內的特定「車輛」則是Part。
理解需求 📝
需求定義了系統必須執行的動作或必須滿足的限制條件。它們是驗證與確認的基礎。在SysML中，需求被視為一等公民，允許與其他模型元件建立連結。
- 需求： 必須達成的條件或能力。它是一個可追溯至其他模型部分的特定元件。
- 追溯： 表示一個元件源自或滿足另一元件的關係。常被用來連結需求與設計元件。
- 細化： 一種關係，表示一個元素比另一個元素提供更詳細的資訊。例如，高階需求可能被細化為詳細規格。
- 滿足： 一種關係，顯示設計元素符合特定需求。
- 驗證： 一種關係，表示測試案例或活動確認需求已達成。
有效的需求管理可確保最終產品符合利害關係人的需求。使用追溯功能可讓工程師看見變更的影響。若需求變更，可向下追溯以了解哪些設計模組或行為會受到影響。
行為圖 🔄
行為描述系統在時間上或對事件的反應方式。SysML 支援多種圖表類型來視覺化此行為，每種類型根據互動的複雜程度而具有特定用途。
活動圖
活動圖專注於控制與資料的流程。它們類似於流程圖，但支援並行活動與物件流程。
- 活動： 由事件觸發的計算階段。它是活動圖中的主要元素。
- 控制流程： 活動發生的順序。它決定執行的順序。
- 物件流程： 活動之間資料或物件的移動。它顯示了產生與消耗的內容。
- 輸入端點： 活動接收資料或物件的點。
- 輸出端點： 活動傳送資料或物件的點。
狀態機圖
狀態機模擬元件可能處於的不同狀態，以及根據事件如何在狀態之間轉移。
- 狀態： 物件生命週期中的一種條件或情境，在此期間物件會執行某項活動或等待事件。
- 轉移： 從一個狀態移動到另一個狀態。轉移由事件觸發。
- 事件： 在特定時間發生的某件事，導致狀態轉移。它可以是訊號、呼叫、時間延遲或條件的改變。
- 保護條件： 一個布林表達式，必須為真才能發生轉移。
- 歷史： 一個偽狀態，會記住複合狀態的最後一個活躍子狀態。
序列圖
序列圖顯示物件之間在時間上的互動。它們對於理解系統各部分之間訊息傳遞的流程非常有幫助。
- 生命線： 表示類或物件在時間上的實例。
- 訊息： 從一個物件到另一個物件的通訊。它可以是同步或非同步的。
- 活動： 物件執行動作的期間。
- 合併片段： 互動的群組，例如迴圈或選擇性區段。
關係與連結 🔗
關係定義了元素之間如何互動。它們是將模型結合在一起的黏合劑。選擇正確的關係對於準確建模至關重要。
| 關係 | 描述 | 用例 |
|---|---|---|
| 關聯 | 一種結構關係，表示某一類型的物件與另一類型的物件相連。 | 一般性的連接，不具所有權。 |
| 聚合 | 整體-部分關係，其中部分可以獨立於整體存在。 | 弱所有權，例如部門擁有員工。 |
| 組合 | 強烈的整體-部分關係，其中部分無法在沒有整體的情況下存在。 | 強烈所有權，例如房屋擁有房間。 |
| 泛化 | 父母-子女關係，其中子類繼承父類的特徵。 | 類別層次結構或繼承。 |
| 實現 | 一種關係，其中一個元素實現另一個元素的介面。 | 介面實現。 |
聚合與組合經常被混淆。關鍵差異在於生命週期管理。在組合中，如果整體被銷毀，其部分也會被銷毀。在聚合中，部分會在整體被銷毀後仍然存活。
約束與參數 📏
並非所有資訊都能以視覺方式呈現。約束允許您加入必須遵守的規則。參數有助於定義與系統相關的數值。
- 約束區塊： 一種代表一組約束的區塊類型。它可以套用於其他模型元素。
- 約束屬性： 約束區塊內代表特定規則的屬性。
- 參數區塊： 用於定義系統參數的區塊。它包含可設定的變數。
- 參數屬性： 參數區塊內的屬性。這些通常用於尺寸設定或組態。
- OCL（物件約束語言）： 一種用於指定約束的正式語言。它允許精確的數學定義。
使用約束可確保模型符合物理法則或商業規則。例如，約束可能指出車輛的重量不能超過某個限制。參數允許您透過改變這些值來執行模擬，而無需更改結構。
主要圖表摘要 📊
為協助記憶，以下是該語言中可用的主要圖表類型摘要。每種圖表在建模生命週期中都具有獨特的用途。
| 圖表類型 | 重點 | 主要元素 |
|---|---|---|
| 區塊定義圖（BDD） | 結構與分類 | 區塊、關係、需求 |
| 內部區塊圖（IBD） | 內部結構 | 零件、屬性、流 |
| 需求圖 | 需求管理 | 需求、追溯、細化 |
| 用例圖 | 功能需求 | 參與者、用例、關係 |
| 活動圖 | 行為流程 | 活動、流程、池 |
| 狀態機圖 | 狀態轉移 | 狀態、轉移、事件 |
| 序列圖 | 時間上的互動 | 生命線、訊息、激活 |
| 參數圖 | 約束與方程式 | 約束、參數、變數 |
在實際情境中應用術語 🌍
了解定義僅是第一步。正確應用這些術語需要理解工作流程。典型的建模過程從需求開始。您可使用需求圖來定義系統需要執行的功能。
接下來，您使用方塊定義圖來定義結構。在此，您為主要組件建立方塊並定義它們之間的關係。您可能使用組合來顯示系統由子系統構成。然後，您使用內部方塊圖來展示這些組件如何內部連接。這正是定義資料流和介面的地方。
接下來建模行為。如果系統具有複雜邏輯，則適合使用狀態機圖。如果涉及流程，活動圖則更佳。序列圖有助於釐清操作期間特定部分之間的互動。
最後，使用參數圖加入約束。這確保物理限制得到遵守。在此整個過程中，追溯關係將所有內容連結回原始需求。這確保每個設計元素都具有由利益相關者定義的明確目的。
應避免的常見陷阱 ⚠️
即使經驗豐富的工程師在定義術語時也可能犯錯。了解常見錯誤有助於維持模型品質。
- 過度使用泛化：除非必要，否則不要建立過深的繼承層次。這會使模型變得複雜。
- 結構與行為混雜：將結構圖與行為圖分開。不要將行為邏輯放入方塊定義圖中。
- 忽略追溯：未能將需求與設計元素連結，會使驗證變得困難。
- 模糊的約束： 避免撰寫含糊不清的約束條件。使用OCL以確保精確性。
- 忽略參數： 未能定義參數會限制模擬或分析系統的能力。
詞彙總結 📚
掌握系統建模語言的詞彙是一段旅程。這需要練習並接觸實際模型。透過理解如模塊、需求和關係等核心詞彙，您將建立穩固的基礎。本詞彙表提供參考點，但真正的熟練來自於實際應用。
一致性至關重要。確保專案中詞彙的使用保持一致。當利害關係人理解這門語言時，溝通將更加順暢。這能減少錯誤並加速開發進程。現代系統的複雜性要求精確的建模，而準確的詞彙正是實現這一目標的工具。
當您繼續使用這些概念時，遇到不熟悉的詞彙可隨時參考本指南。元素之間的關係通常比定義本身更重要。專注於各部分如何連結以形成整體。這種整體觀點正是系統工程的精髓。