歡迎使用系統建模語言（SysML）的完整參考資料。無論您是初次接觸基於模型的系統工程（MBSE），還是正在優化現有的架構文件，理解核心結構都至關重要。本指南專注於兩個支柱：需求以及模塊定義。這些元素構成了任何系統模型的骨幹，確保了需求與實際建構之間的清晰區分。
系統建模需要精確性。模糊不清會導致整合失敗、成本超支與進度延遲。透過標準化捕捉需求與定義系統組件的方式，您能建立單一的可信來源。本文件避免使用特定軟體的術語，以確保在各種建模環境中皆具通用性。此文件專為尋求清晰與結構的工程師、架構師與分析師設計。
🧩 理解SysML基礎
SysML是一種通用的建模語言，旨在規範、分析、設計與驗證複雜系統。與專注於軟體的統一建模語言（UML）不同，SysML著眼於更廣泛的工程挑戰，包括硬體、軟體、人員與設施。該語言以九種圖表類型為基礎，分為四個類別。在本指南中，我們優先關注定義系統骨架的結構圖。
本速查表的主要目標是簡化初始設定流程。您無需立即掌握所有圖表類型。從需求與模塊開始，可幫助您先建立「什麼」，再定義「如何」。這種關注點的分離，正是有效系統工程的標誌。
📝 第一部分：有效建模需求
需求是系統驗證的基礎。它們描述系統必須具備的條件或能力。在SysML中，需求被視為一等公民，與其他圖表元素明確區分。這使得在整個專案生命週期中都能進行嚴謹的追蹤與可追溯性管理。
1.1 需求元素
需求模塊是一種特定類型的元素，用於捕捉利害關係人的需求。它不僅僅是文字，更是模型中的一個結構化物件。每個需求都攜帶特定屬性，用以定義其狀態與特徵。
- 識別碼：唯一的字串（例如：SYS-REQ-001）。這對於跨文件與模型的參考至關重要。
- 文字：需求的實際陳述。請保持簡潔且可測試。
- 優先級：定義重要性（例如：關鍵、高、中、低）。
- 驗證方法：您將如何證明需求已達成？選項包括測試、分析、檢視或示範。
- 狀態：追蹤生命週期狀態（例如：草稿、已批准、已驗證、基線）。
1.2 需求關係
需求很少孤立存在。它們彼此關聯，形成層級結構或依賴鏈。SysML提供了特定的關係來管理這些連結。
- 細化： 用於為更高層級的需求增加細節。子需求會明確說明父需求。
- 滿足： 將較低層級的需求連結至較高層級的需求。通常在解決方案元素（如模塊）滿足某項需求時使用。
- 衍生需求： 表示一個需求是從另一個需求衍生而來，通常是因父需求變更所致。
- 對齊： 表示兩個需求之間存在關聯，通常出現在不同專案或標準之間。
- 追蹤： 一種通用關係，用於將需求連結至其他元素，如模塊、用例或測試案例。
1.3 需求圖 (RD)
雖然 SysML 擁有多種圖表類型，但需求圖專門用於管理需求網路。它可讓您視覺化需求的流動及其依賴關係，而不會使結構圖變得混亂。
| 關係 | 方向 | 使用情境 |
|---|---|---|
| 細化 | 父 → 子 | 將複雜需求分解為具體行動。 |
| 滿足 | 模塊 → 需求 | 顯示設計元素如何滿足特定需求。 |
| 衍生需求 | 父 → 子 | 根據父需求的變更來更新子需求。 |
| 追蹤 | 彈性 | 將需求連結至驗證成果或其他系統元素。 |
🧱 第二部分：模塊定義圖 (BDD)
模塊定義圖是 SysML 中的主要結構圖。它定義了系統的組成、內部結構與外部介面。模塊代表構成系統的實體，可以是硬體、軟體、人員或設施。
2.1 定義模塊
一個區塊是結構的基本單位。它封裝了資料和行為。當您定義一個區塊時，您正在建立該組件的內容及其互動方式的合約。
- 屬性： 這些是區塊的屬性。它們定義了區塊所持有的資料或包含的子組件。屬性具有類型（例如，另一個區塊，或像整數或字串這樣的原始資料類型）。
- 操作： 這些定義了區塊可以執行的動作。雖然SysML允許行為建模，但區塊上的操作通常代表功能能力。
- 值： 分配給屬性的常數值。對於設定參數非常有用。
2.2 結構關係
區塊彼此連接以形成一個系統。這些連接定義了資料、能量或物質的流動。關係的類型決定了連接的強度。
- 組成： 一種強烈的所有權關係。零件無法在沒有整體的情況下存在。如果組合區塊被刪除，零件也會被刪除。視覺上，實心菱形代表這種關係。
- 聚合： 一種較弱的所有權關係。零件可以獨立於整體存在。視覺上，空心菱形代表這種關係。
- 關聯： 區塊之間沒有所有權的連接。它代表使用關係或資料流。視覺上，一條簡單的線代表這種關係。
- 一般化： 繼承。一個特化的區塊（子）從一個一般化的區塊（父）繼承屬性。視覺上，空心三角形代表這種關係。
2.3 區塊屬性與埠
介面對於定義區塊之間如何互動至關重要。您應避免將內部實作細節暴露給其他區塊。相反地，應使用埠。
- 流動埠： 代表物理量的流動（例如，電力、流體、資料）。它們定義了流入或流出區塊的流動方向。
- 標準埠： 代表功能介面。它們定義了區塊所提供的或需要的操作或服務。
- 代理埠： 用於代表區塊內部組件所提供的或需要的介面，並將其暴露給外部世界。
| 關係類型 | 基數 | 範例情境 |
|---|---|---|
| 組成 | 一對多 | 由活塞組成的引擎。 |
| 聚合 | 一對多 | 一隊車輛。 |
| 關聯 | 0..1 對多 | 指派給車輛的飛行員。 |
| 泛化 | 一對一 | 轎車是一種汽車。 |
🔗 第三部分：可追溯性與驗證
沒有可追溯性，建模就不完整。可追溯性將需求與滿足它們的設計元件連結起來。這確保了每一項需求都有對應的實現，且每一項實現都對應一個需求。
3.1 可追溯連結
可追溯關係連結任何兩個模型元件。在需求與模組的背景下，這是最重要的連結。它回答了以下問題：這個設計元件是否滿足該需求？
- 上游可追溯性：將設計元件回溯連結至需求。這確保設計是基於利害關係人的需求。
- 下游可追溯性：將需求連結至設計元件。這確保需求在架構中得到處理。
- 影響分析：若需求變更，可追溯連結會顯示哪些模組受到影響。這可降低修改過程中的意外副作用風險。
3.2 驗證與確認
可追溯性延伸至驗證。您必須將需求與驗證活動連結。這可確認系統按預期運作。
- 測試案例：將需求連結至特定的測試程序。一個需求應可追溯至至少一個測試。
- 分析：基於數學或模擬的驗證。
- 檢視：對模型或實體物件進行視覺或手動檢查。
若無這些連結，模型僅僅是一張圖紙。有了這些連結，它便成為經過驗證的規格說明。
⚙️ 第四部分：結構的最佳實務
採用一致的建模方法可避免混淆並確保可維護性。遵循這些指南，以保持您的模型乾淨且可用。
4.1 命名慣例
命名的一致性至關重要。為識別符和名稱使用標準格式。
- 前置詞： 使用前置詞來區分類型（例如，REQ- 代表需求，BLK- 代表模組）。
- 大小寫敏感性： 決定一種慣例（例如，CamelCase 或 snake_case），並堅持使用。
- 唯一性： 確保在同一命名空間內，沒有兩個元素共用相同的名稱。
4.2 層次結構與分解
不要建立平坦的結構。將複雜系統分解為可管理的子系統。
- 自上而下： 從系統層級開始，並分解為子系統。這有助於管理複雜性。
- 自下而上： 有時必須整合現有的組件。使用聚合將它們連結至頂層系統。
- 邊界： 明確定義每個模組的邊界。模組內部是什麼？外部又是什麼？
4.3 變更管理
系統需求會變更。您的模型必須能夠適應。
- 版本控制： 跟蹤需求與模組的變更。記錄變更的原因。
- 基線： 在關鍵里程碑建立基線。這讓您能夠回退或與先前狀態進行比較。
- 影響評估： 在刪除模組或需求之前，請檢查其追溯連結。刪除可能會破壞驗證鏈。
🛠️ 第五部分：應避免的常見陷阱
即使經驗豐富的工程師也可能陷入建模陷阱。早期識別這些問題可節省大量後續時間。
5.1 過度建模
在當前階段建立過於詳細的模型是一種常見錯誤。SysML 允許深入的細節，但並非總是必要。應專注於當前決策點所需的抽象層級。
5.2 混合關注事項
不應在相同圖表中不必要地混合行為與結構資訊。雖然 SysML 允許這樣做，但通常會導致混亂。將結構保留在 BDD 中，行為則保留在內部塊圖 (IBD) 或活動圖中。
5.3 忽略介面
在未定義介面的情況下定義塊會導致模型脫節。如果一個塊沒有定義埠或屬性，就無法整合。在連接塊之前，務必先定義介面。
5.4 不一致的可追溯性
在可追溯性上留下缺口是具有風險的。沒有滿足塊的需求是技術負債。沒有需求的塊是範圍蔓延。確保每個連結都有明確目的。
📊 第6部分：快速參考摘要
使用此摘要表格，快速找到符合您需求的正確圖表或元件。
| 目標 | 元件類型 | 圖表類型 |
|---|---|---|
| 定義系統需求 | 需求 | 需求圖 |
| 定義系統結構 | 塊 | 塊定義圖 |
| 定義內部連接 | 零件、埠、流 | 內部塊圖 |
| 定義功能流程 | 動作、流 | 活動圖 |
| 定義互動 | 訊息、狀態 | 序列圖 |
🧭 第7部分：工作流程整合
將 SysML 整合到您的工程工作流程中，需要觀點上的轉變。這不僅僅是繪圖，更是資訊管理。
7.1 採集階段
首先從捕捉利害關係人的需求開始。將這些需求轉換為 SysML 需求。立即分配唯一識別碼。不要等到需求明確後才開始建模結構。
7.2 定義階段
一旦需求明確，便定義模塊。建立高階BDD。使用埠定義介面。確保模塊符合功能需求。
7.3 精化階段
將模塊分解為子系統。使用組合來定義層次結構。將需求細化為低階規格。更新追溯連結以反映新的結構。
7.4 驗證階段
將需求連結至測試案例。如適用，執行模擬。驗證模塊屬性是否符合需求限制。將需求狀態更新為已驗證。
❓ 第8部分：常見問題
問：我可以在SysML中使用文字方塊嗎？
答：可以，但它們不是結構化元素。為了可追溯性，請始終使用需求元素。文字方塊僅用於不需要追蹤的註解或評論。
問：模塊與類之間有什麼區別？
答：SysML基於UML，因此它們相似。然而，SysML模塊是為系統工程設計的。它們專注於物理屬性、零件和流動，而UML類則專注於軟體邏輯和方法。
問：我該如何處理多個利益相關者？
答：使用套件按利益相關者組織需求。使用標籤分配所有權。確保可追溯性能讓您看到哪項需求滿足了哪位利益相關者的需要。
問：SysML僅適用於硬體系統嗎？
答：不是。SysML適用於軟體、服務、人員和設施。它是一種通用語言，適用於任何組成結構的複雜系統。
問：我該如何管理大型模型？
答：使用套件來劃分模型。避免將所有內容都放在根套件中。使用視圖僅向特定受眾展示模型的相關子集。
📝 最後想法
有效的系統建模依賴於語言標準的嚴謹應用。透過專注於需求與模塊定義，您將為系統架構奠定穩固的基礎。這些元素之間的關係推動了模型的完整性。
請記住，目標不是創造一個看起來令人印象深刻圖表，而是建立一個能清晰傳達的模型。清晰性降低風險。降低風險可節省時間與資源。本指南提供了達成清晰性的必要結構。
隨著系統的演進，持續精化您的模型。保持需求的更新。確保模塊定義的準確性。維持追溯連結。這種持續的維護，正是將靜態模型轉化為活躍工程資產的關鍵。
持續一致地應用這些原則。現代系統的複雜性要求如此。掌握SysML需求與模塊後，您將具備應對系統整合與設計挑戰的能力。