本篇屬于基于模型的系統工程(MBSE)專題系列第02篇內容，我們聊聊MBSE方法論之OOSEM相關內容。

閱讀之前強烈建議參考之前系列文章:

為什么MBSE是系統復雜性應對之道

在上一篇MBSE開篇文章，我們聊到了MBSE基本概念及其重要性，以模型驅動開發過程是MBSE核心內容，為了建立模型我們需要相應的方法論，建模語言以及工具。今天我們主要來聊聊MBSE相關的方法論。

所謂的方法論就是以解決問題為目標的一種通用理論體系，告訴我們以什么的方式，步驟或流程去解決問題。MBSE方法論其實比較多，業界不同企業或組織提出了不同的方法論，比較常見的包括:

• OOSEM
  

• Arcadia
  

• Harmony SE
  

• State Analysis
  

• Object Process Methodology (OPM)
  

• MagicGrid
  

• Vitech

但不管這些方法論如何變化，其本質都是基于V模型，都是從系統需求獲取及定義，到系統架構設計，再到詳細設計及驗證等，只是不同的方法論在這個過程中側重點以及采取的方法不完全相同而言。

當然，并不是所有的MBSE方法論在汽車行業都有應用，我會挑幾個比較有代表性，且比較有借鑒意義的方法論給大家介紹。

我們今天先來來聊聊MBSE方法論之OOSEM。

01

OOSEM核心

面向對象的系統工程方法(Object-Oriented Systems Engineering Method, OOSEM)是INCOSE提出的MBSE方法論，其核心特點在于:

• 需求的捕獲，以需求為基礎，建立架構模型。

• SE基本方法論結合面向對象(Object-Oriented)的軟硬件設計方法。

所謂面對對象的方法，就和我們學習的面對對象的編程思想一致，它和面向過程的方法相對，強調類的聲明，繼承，接口抽象等，將具有相似特性的個體進行抽象，封裝，以此來降低系統復雜性，增強復用性。

舉個簡單的例子: 

汽車有四個輪子，這四個輪子，組成，結構，大部分特性都一致，這時候我們只需要定義車輪這樣一個父類，并定義其共有屬性，不同的屬性我們可以通過類的實化，得到具體的實體，這個實體繼承父類特性，接口，操作等，這樣就可以避免建立4個類似的對象，有效降低系統復雜性，增加復用性。

一般來說，面向對象的方法其實多用于具體軟件和硬件的開發，在系統階段雖然也有涉及，但沒有那么明顯，所以OOSEM核心的面向對象這部分內容個人認為更適合軟件或硬件開發，正是因為這樣，OOSEM有助于后續軟硬件的集成和驗證，有效降低集成及驗證的工作量，其他部分內容基本和SE方法論保持一致。

02

OOSEM開發活動

OOSEM主要開發活動如下圖所示: 

圖片來源: INCOSE

其中，斜線下方是MBSE共有的或最基本的活動，斜線上方是OOSEM主要開發活動，該過程主要包括:

1

Stakeholder需求獲取: 

收集產品利益相關者，如用戶，決策者，投資者，法規等，對產品的需求，包括了功能及非功能相關的產品需求，該需求通常通俗易懂。

2

系統需求獲取: 

根據Stakeholder需求，對其進行拆分細化，導出特定系統對應的需求。

3

系統邏輯架構定義: 

對系統進行邏輯拆分，形成子邏輯系統，邏輯組件，以滿足系統需求。

4

系統備選物理架構合成: 

描述系統物理組成及聯系，包括具體的軟件，硬件，便于邏輯組件映射到系統物理架構。

為了支持上述OOSEM建模過程，INCOSE最初使用UML(Unified Modeling Language)作為其建模語言，但由于UML多針對軟件開發，缺少對系統開發的支持，所以INCEO在UML基礎上推出了面向系統的建模語言，即SysML(Systems Modeling Language)，以此來支持復雜系統的分析、定義、設計、和驗證過程。

SysML是非常重要的統一化建模語言，它定義了不同的視圖類型，結構視圖，需求視圖，活動視圖等等，每個視圖包含不同的組件元素和相應的關系，例如: 關聯，依賴，泛化，聚合，實現等，面向對象的建模思想也反映在建模語言中，可以很好地支持上述OOSEM建?；顒?。

上述提到的OOSEM活動都以UML或SysML建模為主。一般來說，: 

• 需求獲取或定義，多采用需求視圖或用例圖表達。

• 邏輯架構和物理架構多采用類圖或結構視圖表達架構靜態關系，即組成，接口等，多采用流程圖，活動圖，狀態圖等表達架構動態關系。

具體細節在建模語言部分我們再聊。

此外，OOSEM還有一個特殊的地方，即從系統需求直接建立系統邏輯架構，根據系統需求對系統進行邏輯組件拆分，然后對邏輯架構進行應用場景分析，導出邏輯組件的功能，接口等。這和大部分MBSE方法論相比，稍微有點不同，大部分MBSE方法論都是通過對需求進行用例或場景分析，首先導出系統功能，然后依據系統功能建立邏輯架構。

其實這二者并不矛盾，很多時候邏輯組件和功能組件是等效的，很難區分。個人認為如果對系統結構組成比較熟悉，或已有邏輯架構，則可直接根據需求建立或補充邏輯架構。而對于相對比較陌生的對象，或軟件為主的系統，先導出功能，依據功能建立邏輯架構更方便。

03

邏輯架構

OOSEM開發活動中需求的獲取，架構的設計屬于SE基本內容，邏輯架構的出現是一大亮點，但它并不是OOSEM的特有的過程和產物，基本上所有的MBSE均有涉及，它主要目的在于:

1

以我們容易理解的方式，對系統進行抽象，形成滿足需求的邏輯解決方案，為后續技術實現方案的確定提供基礎。

2

避免技術實現方式(實現條件約束)和細節的干擾，從系統化的角度對系統進行分解，組織系統功能實現。

3

通過邏輯抽象，邏輯架構降低了需求變更對系統設計的影響，提高系統復用性，有助于需求變更管理。

4

技術解決方案中立，便于不同技術的應用和評估。

那到底到底什么是邏輯架構？為了方便朋友們理解，舉個簡單的例子:

就拿汽車驅動系統為例，當我們從物理架構角度去看，對于傳統汽車，它包括了具體的發動機，變速器，各自的控制單元等基本部件，對于電動汽車而言，它對應得就是電機，減速器等。而從邏輯架構的角度看，不管傳統還是電動汽車，它們邏輯組件基本相同，都需要一個動力提供源，一個動力傳遞裝置等，在我們還不了解發動機，電機，變速器這些具體技術實現手段前，邏輯架構其實更符合我們對事物認知的方式。

所以對于邏輯架構，我們不需要明確系統具體實現方式，屬于技術解決方案中立的架構，更多的是從功能實現角度去考量應該采用哪些必要的邏輯組件去實現相應功能，這樣邏輯組件在后續開發過程中，會被進一步具象化，被拆分成多個或合并成一個物理組件，這個就是所謂的邏輯架構映射到物理架構。

此外，邏輯架構的存在也符合現在電子電氣架構不斷集中化的趨勢。隨著技術發展，分布式控制單元不斷被集成，這時候雖然物理架構不斷發生變化，而邏輯架構卻相對穩定不變，這時候可以從邏輯架構的層面入手，將其作為基線進行分析，通過邏輯架構和物理架構之類的映射關系，可以大大降低分析難度，提高系統設計的靈活性和可拓展性。

個人認為邏輯架構的出現是MBSE應對系統復雜性的重要體現之一，這也是抽象的魅力，這也是一個架構師必備技能之一。

寫在最后:

MBSE方法論之OOSEM我們就聊完了，包括其核心，邏輯架構，流程活動，語言等，希望能夠給朋友們理解MBSE應對系統復雜性帶來新的理解 。

END

文章來源：AUTO世代