MBSE建模方法研究：業務、系統和軟件建模

金成杰，俎濤，張宏亮，段博

（1.上海中廣核工程科技有限公司，上海， 200241；2.北京火龍果網絡技術有限公司，北京， 100088）

0 引言

當前，隨著系統的復雜性越來越高，MBSE越來越被重視。MBSE講求在整個系統的開發過程中以模型描述各個階段的分析設計成果，并實現各個階段的模型的跟蹤。一個復雜系統的工程實踐中，一般存在三個分析設計：業務分析設計、系統分析設計、軟件設計。相應的也就需要建立三個模型：業務模型、系統模型、軟件模型。在實際項目中，很多人都存在這樣的困惑：

這些模型都有什么內容？

這些模型有哪些可以采用的建模語言？

這些模型如何緊密銜接，實現需求跟蹤？

本文將引入相關的建模規范，并結合工程范例研究相關的建模方法。

1 MBSE建模方法的現狀和遇到的問題

當前MBSE標準的最主要的建模語言是：

SysML：系統工程建模語言，用于對系統建模。

UML：軟件工程建模語言，用于對軟件建模。

但是缺乏明確的業務建模語言規范。而SysML和UML也是面向不同的層次，實際的系統分析設計中，系統和軟件都需要建模，而且還要緊密相關。所以，即使當前采用SysML和UML建模的工程師，也存在如下困惑：

業務建模都建模什么，用什么建模語言，如何建模？

SysML建立的系統模型和UML建立的軟件模型如何對接？

對于非功能需求（例如：性能）如何建模？

業務模型、系統模型、軟件模型如何緊密銜接？

2 MBSE建模解決方案

下面提供MBSE的建模解決方案：

采用UML作為基礎建模語言，根據建模的需要擴展出業務建模語言BML。

把BML和SysML建立模型映射，實現業務模型到系統模型的緊密銜接。

把SysML和UML建立模型映射，實現系統模型到軟件模型的緊密銜接。

建模者可以根據自己的建模需要，基于UML擴展特定的建模形式規范。

MBSE過程可以描述為角色、活動和模型，如圖2所示[1]：

圖2 MBSE過程中的模型

說明如下：

業務分析師進行業務分析，建立業務模型；

系統工程師進行系統分析，建立系統模型；

軟件工程師基于軟件分析設計、軟件開發和軟件測試，建立了軟件模型；

測試工程師基于模型對系統進行測試。

下面以目前正在實施的某核安保監控系統為例說明MBSE工程實踐中的建模方法。

3 業務建模方法

在系統分析之前，應梳理清楚業務。這就需要通過業務模型對業務進行清晰地描述。業務模型的構成通常如表1所示[2]。

表1 業務建模的內容

業務建模目前可以采用BPMN進行工作流建模，但是對于如上的完整業務模型并沒有對應的建模規范。而對業務模型的構成和現有的建模規范進行對比，可以看到UML具有描述業務模型的所有基本形式。所以可以對UML進行擴展，建立業務建模語言。

■3.1 業務域建模

業務域是指一個業務的問題空間，是邏輯層次的，其中含有業務人員、業務對象、系統。業務域的含義和UML包圖中的包含義一致，所以可以用包圖建模業務域。圖3是核安保系統的業務域模型。

圖3 業務域模型（UML包圖）

■3.2 業務角色和業務服務建模

每個業務域都存在業務角色和業務服務。業務角色就是對業務中的人的抽象，可以采用UML中用例圖中的Actor，Actor就是主要用于描述角色的抽象。業務服務本質上是一種行為，所以可以采用UML的活動圖中的Activity來描述。這樣，核安保系統的《業務域：訪客服務》的業務服務的模型可以描述如圖4所示。

圖4 訪客服務的業務流程（UML活動圖）

■3.3 業務流程建模

業務服務通過業務流程來實現，業務流程的建模要體現出：執行者、活動、活動之間的對象流[3]。這些要素和UML的活動圖的Partition、Activity和Object對應。所以可以采用UML的活動圖建模業務流程，核安保系統的《業務域：訪客服務》的《業務服務：辦理通行卡和使用》對應的業務流程圖建模如圖5所示。

圖5 通行卡辦理及使用流程（UML活動圖）

4 系統建模方法

在分析了業務并建立了相應的模型后，就需要對相應的系統建模。系統建模一般需要建模如表2所示[4]。

表2 系統建模的內容

系統建模一般采用SysML進行，下面以核安保系統為例說明。

■4.1 系統的構成建模

定義一個系統的構成，需要二個視圖：物理視圖和邏輯視圖。物理視圖為客觀存在的對象及其關系圖，而邏輯視圖則存在于人的頭腦中，是對物體、行為、數據、關系進行了概念抽象，以便更好地理解系統。對于整個系統的理解，常常需要把這兩個視圖對照閱讀。這就產生了一種需要—建立能夠同時描述物理和邏輯的綜合視圖，方法如下：

首先建立物理視圖，描述系統的實體和關系；然后建立邏輯視圖，描述事物、行為、關系等概念。再后建立一個復合視圖，把物理元素和概念進行關聯。物理視圖可以采用SysML的模塊定義圖建模[5]，邏輯視圖可以采用UML圖建模。復合視圖則需要做一些擴展：因為模塊（Block）和類（Class）在外觀上很像，所以對Block定義了一個新的構造型（Physical Block），并采用了能夠表達物理特點的長方體外形，這樣，就可以清晰地區分出物理模塊和邏輯類之間的外觀。圖6是核安保系統構成的復合視圖[6-7]。

圖6 系統構成復合視圖（SysML的BDD和UML的類圖）

系統構成復合視圖中的元素說明如表3所示。

表3 核安保系統的構成的復合視圖元素說明

■4.2 功能分析與建模

系統的功能可以采用SysML的用例圖建模，每個Actor代表一個用戶角色的抽象，每個Use Case代表一個用戶使用系統執行的功能[8]。應建立用例的逐級分解機制，頂級用例也稱為最大整體用例，是指一組完全獨立的功能，可以進一步分解為更小的功能用例；而最小用例是可以獨立執行的最小功能。圖7是核安保系統的保安這個角色的頂級用例模型。

圖7 保安的頂級用例模型（SysML用例圖）

■4.3 子系統分析與建模

系統可以分解為子系統，并把功能分配到各個子系統上，才能夠對系統的功能進行最終的定義。對子系統的建模，主要描述其提供的功能。可以采用SysML的模塊定義圖（BDD）進行建模。模塊表示子系統，屬性（Property）表述子系統具有的功能[9]。圖8是核安保系統的子系統功能定義圖。

圖8 子系統功能分配（SysML模塊定義圖）

■4.4 子系統的接口交互建模

在定義了子系統后，應該對子系統之間的接口進行建模，然后對接口進行詳細描述：接口的歸屬、接口的通信屬性、數據流和非功能需求[10]。圖9是描述核安保系統子系統接口的模塊定義圖（BDD）。

圖9 子系統接口圖（SysML模塊定義圖）

而對于子系統的接口交互，可以采用SysML的順序圖進行描述，圖10是核安保系統的接口交互建模示例。

圖1 復雜系統的MBSE 相關的模型和建模語言

圖10 子系統接口交互圖（SysML順序圖）

■4.5 非功能需求分析與建模

非功能需求包含兩個視角：用戶視角和系統視角。非功能需求的分析過程是從用戶視角到系統視角逐步細化的過程。因為涉及2個視角，所以有必要建立一個上下文圖：用SysML的用例圖描述用戶視角，用模塊定義圖（BDD）描述系統視角。圖11是核安保系統中門禁控制器的性能上下文圖。

圖11 門禁控制器的性能上下文圖（SysML的用例圖+模塊定義圖）

對于用戶視角的性能需求，描述如表4所示。

表4 門禁控制器的性能需求

對于系統視角的性能需求，把用例的場景分解為子系統和設備的交互過程，可以采用SysML的順序圖建模，圖12是門禁控制的系統性能分析圖。

圖12 門禁控制器的系統性能分析圖（SysML順序圖）

5 軟件設計與建模

軟件設計的建模包括如下表5所示[11]。

表5 軟件設計建模的內容

下面以核安保系統為例，說明軟件的建模方法。

■5.1 數據設計與建模

數據設計是對系統使用和存儲的數據進行定義，這是從概念到邏輯、再到物理的逐步落地的過程，相應的數據模型包括概念視圖、邏輯視圖和物理視圖。概念視圖只關注數據對象，不關注數據屬性。邏輯視圖則進一步關注數據對象的屬性，二者都可以采用UML類圖建模[12]，圖13是核安保系統的邏輯數據模型簡化示例。

圖13 核安保系統的邏輯數據模型—部分（UML類圖）

物理視圖關注數據的存儲空間及其網絡連接。可以采用UML的部署圖建模[13]，圖14是核安保系統的物理數據模型示例。

圖14 核安保系統的數據物理模型（UML部署圖）

■5.2 軟件框架結構設計與建模

軟件層次框架設計的目的是把問題分解為不同的層次，分別進行處理，提高開發的復用性和效率。

核安保系統的多個上位機子系統（監控子系統，管理子系統，服務子系統）具有類似的層次：

應用層：為用戶或客戶端提供應用功能；

服務層：為應用層提供服務；

業務對象層：提供數據對象及其相關的數據處理；

數據資源層：提供數據資源及其訪問服務。

層可以用包建模，其中的邏輯模塊可以采用類建模、實現模塊可以采用組件建模，所以完整的層次框架視圖需要結合UML的包圖、類圖和組件圖才能進行完整建模[14]。核安保系統的軟件層次模型如圖15所示。

圖15 核安保系統的軟件層次框架視圖（UML包圖+類圖+組件圖）

■5.3 軟件處理邏輯設計與建模

對于軟件處理流程分析的時候，需要描述清楚：活動由誰執行、活動的時序和數據流。采用UML的活動圖可以充分地描述以上流程信息[15]。圖16是核安保系統中非常復雜的一個功能“進門檢查”的處理流程的活動圖分解示例。首先是一級活動圖，描述進門檢查功能有哪些子系統協作，分別執行什么活動、傳遞什么數據。

圖16 一級軟件處理邏輯流程圖（UML活動圖）

然后對于有必要細化的活動可以建立下級流程描述，編排為可編程的基本處理單元：順序處理、判定分支處理、循環處理。圖17是“讀卡器檢查”的二級處理流程描述。

圖17

圖17 二級軟件處理邏輯流程圖（UML活動圖）

6 結論

MBSE是對復雜系統進行分析設計的有效方法，MBSE的全周期建模涉及業務、系統和軟件，需要建立三個層次建模規范，各種模型視圖建立映射關系，模型才能真正成為提高系統分析設計能力的載體。本文通過MBSE的業務、系統、軟件的建模需要，基于業界公認的建模規范UML和SysML，給出了業務、系統和軟件的建模方法和形式標準，并采用核安保系統為例，給出了具體的圖例和建模方法。這些可以為MBSE實踐者提供有意義的參考。

如上的MBSE建模方法已經通過實際工程項目—核安保系統的實施進行了驗證，相關的工作成果得到了用戶代表和開發代表的認可，一致認為提高了分析設計的能力和效率。

另外需要注意的是：在各個行業領域的建模內容會有所不同，所以本文提出的建模方法還可以結合具體行業應用的需要進一步具體化，使其對特定的領域更有針對性，這些工作可以作為后續研究的內容。