Arcadia建模方法與SysML建模方法比較研究

鞠文煜 付 昕 /

(上海飛機設計研究院，上海201210)

0 引言

系統是由一組實體和這些實體之間的關系所構成的集合，其功能要大于這些實體各自功能之和[1]。按照系統的概念，強調的是實體和實體之間的關系，實體構成了系統的表現形式。更為重要的是，系統是為了實現功能而被建立，系統的功能主要由一系列的文檔來描述和定義，通過系統工程的流程保證相關需求和功能被正確實施。然而，由于文檔被自然語言書寫，表達不直觀，對于不同角色對系統的理解將存在差異，進而產生錯誤。對于復雜系統所包含的信息，其信息量巨大，超過了人們理解。這時就需要一種方法將復雜系統表現出來，將表現出的系統特征進行研究。基于模型的系統工程就是解決該問題的方法之一。

系統模型是現實系統的應用、模仿和抽象，它以某種確定的形式，提供關于該系統的信息，反應系統某一方面的屬性和特征[2]。本文定義的基于模型的系統工程建模，并不是替代目前所有的建模方法和建模技術。基于模型的系統工程建模，強調的是模型的系統集成者，通過基于模型的系統工程建模，將不同領域的模型整合在一起，通過系統的方法從不同的視角，綜合評估系統，以得到系統的最優解決方案。

1 基于模型的系統工程背景簡介

一個復雜系統工程項目的成功，需要眾多背景不同的人員參與其中。比如，系統工程師主要解決如何徹底地理解客戶的需要，并將客戶的需要轉化成為系統的需求與功能；根據系統需求與功能，以及系統設計的約束，選取最佳的解決方案，確定系統給出的架構。軟件工程師關心的則是軟件需要完成的任務、功能及軟件的約束。硬件工程師考慮的是硬件的運行環境，子硬件模塊的成本、質量、功耗等硬件物理特性。用戶則關心系統如何幫助用戶解決問題，是否滿足客戶的需要，系統使用是否簡潔明了等直接感受。由于不同的角色關心的問題不同，表達方式、文化背景差異大，因此需要一套有效的方法將系統通過不同的視角，以簡潔明了的形式展現給相關人員，在系統實際被生產出來前，各方面充分了解需求，進行溝通，并形成最佳的系統解決方案。

系統模型用于表現物理實體的特征和細節，根據表現方式的不同，一般系統模型可分為圖形模型、數學模型、邏輯模型等方式。系統模型一般用于描述系統的運行場景，系統的需求、組成、架構、行為等方面；通過不同形式的系統建模幫助系統設計人員更好地表現系統，分析系統，確認需求，讓不同專業的工程師一起更好地溝通，支持系統更好的設計。

系統建模不僅能解決傳統系統工程溝通等問題，還可以清楚地表征系統給的各方面特性，評估系統設計，分析系統性能需求和其他特性，在早期確認系統設計滿足需求，利用模型對用戶展開虛擬培訓，并縮短系統開發時間。對于成熟系統，系統模型在做更改影響分析、協同設計及維護系統需求追溯性方面也有著優勢。

2 基于SysML建模方法介紹

基于模型的系統工程近年來有了很快的發展，對象管理組織(Object Management Group，簡稱OMG)和系統工程國際委員會(International Council on System Engineering，簡稱INCOSE)推薦使用系統建模語言(System Modeling Language,以下簡稱SysML)[3]進行系統建模，描述系統的架構、需求、行為以及特性。SysML規范定義了系統建模語言的語法，以及所有圖像所代表的意義，這樣就保證了所有系統工程師使用準確的清晰無誤的語言對系統進行統一描述。系統建模語言關系如圖1所示[4]。

圖1 SysML九種視圖關系

基于SysML建模首先定義系統的范圍，通過用例設計明確系統的活動。在需求捕獲階段識別干系人，并通過用例圖(黑盒)的方式，明確干系人的使用場景，針對每個使用場景，根據系統的行為編制系統的活動圖(黑盒)，在活動圖編制過程中識別系統外部的輸入和輸出。通過用例圖和活動圖的編制，完成功能定義。在完成了用例圖(黑盒)和活動圖(黑盒)后，系統的行為和系統外部輸入輸出已被初步定義，這時就可以形成系統的框圖，使用用例圖、活動圖和框圖這三種類型的建模模型就可以完成對上一層級需求的確認。

經評審后的框圖、用例圖、活動圖，作為系統設計的輸入，重新識別干系人和用例，把用例和活動分解，在系統內部設立不同的功能模塊，并明確每個功能模塊的作用，形成系統的內部框圖，根據系統內部框圖的模塊將系統活動圖重新定義，完成整個系統的活動定義。然后根據系統化的系統活動圖設計系統的時序圖，定義系統內部各模塊的功能和系統的運行機制；在定義系統時序圖后，完成系統狀態機圖定義，檢查每個系統狀態是否合理并符合預期，當系統狀態機圖完成后，已基本可以確認系統設計是否滿足功能要求，總結其他系統需求，形成系統需求圖。以上工作完成后，就可以將設計好的系統架構、系統內部模型、系統用例模型、系統活動模型、系統時序模型、系統狀態機模型和系統需求模型進行初步設計評審。

在詳細設計階段，軟硬件設計人員和系統設計人員將針對初步設計階段形成的系統模型，完成系統功能分配，將系統功能分配至軟硬件及補充系統的包圖。針對系統運行的各種內部和外部參數，采用系統參數圖進行定義，形成標準的基于XMI(XML-based Metadata Interchange，簡稱XMI)的參數集，以及接口的邏輯框圖。最后根據完成的系統包圖和系統參數圖，對之前形成的系統架構、系統內部模型、系統用例模型、系統活動模型、系統時序模型、系統狀態機模型和系統需求模型進行更新和細化。

在生產和制造階段，由于SysML和統一建模語言(Unified Modeling Language，簡稱UML)有一定的共通性，軟件設計人員可以利用之前建立的系統模型，進而繼續建立軟件模型，建立好的軟件模型可以提供給系統作為軟件設計確認的證據。另外由于SysML采用基于XMI的架構性語言，一般建模工具對于SysML建立的模型均提供XMI接口，可以利用工具生成基于XMI架構的測試腳本。

如果在系統改進階段，由系統建模工具提供統一的管理方法，確定優化項目后，可以很方便地確定受影響的模塊，分析更改影響的結果，并提供初步的確認和驗證。

3 Arcadia方法介紹

隨著基于模型的系統工程的迅速發展，各公司對系統工程建模均有一定的研究，其中，泰勒斯公司基于IEEE 1220標準，開發并定制了其特有的系統建模工具Capella，并形成了符合其自身特點的架構分析和設計集成方法，即Arcadia方法論。

Arcadia方法將系統建模的過程分為運營分析、系統分析、邏輯分析、物理分析和終端產品結構分解共五層[5]，如圖2所示。Arcadia方法在SysML的基礎上做了擴展和定制，從而形成了具有定制特征的建模語言，通過SysML的拓展和定制，Arcadia方法補充了運營理念、目標和系統任務分析。

圖2 Arcadia方法建模關系圖

與SysML不同，通過使用Arcadia方法建模，無需明確系統邊界。Arcadia方法結合了美國國防部架構框架(Department of Defense Architecture Framework，簡稱DoDAF)[6]的相關理念，首先定義的是用戶需要系統完成的任務，也就是用戶需要具備的運行能力。在運行分析階段，只分析用戶遇到的問題、用戶的需要以及用戶的潛在需求。這時并不需要確定系統的邊界，當系統出現在運營分析中，就限定了給用戶的解決方案，也就沒有辦法評估相關方案是否是最佳的解決方案。運營分析的對象是用戶、用戶在運營中的角色、用戶完成的活動，分析的內容是用戶活動是否存在問題和不足、是否有改進的空間。

運行分析完成后，系統工程師需要將不同用戶的需求進行整理和分析，分析后得到統一的系統需求和系統模型。在系統分析階段，研究的是系統如何滿足用戶的需求，提供具體的解決方案，通過運行能力的細化，明確系統在用戶運營分析中需要完成的任務，總結抽象系統需要具備的能力，定義系統需要完成的活動，考慮運行約束給系統活動帶來的限制，最終形成系統需求。在系統分析階段，還需要考慮系統活動完成所需的輸入條件，也就是系統的外部接口。

邏輯分析是系統功能的細化，將系統功能分解為子功能，并在系統層面實現系統子功能的整合與分配。邏輯分析還解決系統內部約束、系統內部功能、功能關系、具體實現的技術以及潛在技術等方面問題。在邏輯層面，實現詳細的系統分析，考慮系統的約束，平衡系統性能、安全性和可靠性等指標，以求得到最佳的系統方案。系統分析和邏輯分析共同完成系統功能定義，系統需求分解與分配，形成系統定義。

物理分析是定義系統的具體實現方式，考慮系統的物理特性，以達到系統在質量、功耗、成本等物理層面的最優設計。物理分析和終端產品分析適用于不同的系統對象和系統組織形式。物理分析過程考慮的是系統如何實現，包括物理約束的系統架構選擇，物理連接形式，各部件實現的功能等。

物理層向下分解，還可以將物理實現再分解至各個構型項的物理實現，也就是終端產品分解結構定義，這個層級解決的是軟硬件分配和集成的過程，一般是軟、硬件工程師關注的重點。

4 Arcadia方法與基于SysML方法建模對比分析

基于SysML方法建模與Arcadia方法建模對比分析見表1。

表1 基于SysML方法建模與Arcadia方法建模對比分析表

使用Arcadia方法的建模工具Capella建模，無需對系統建模理論做研究，僅需按照Arcadia方法本身以及工具提供的建模思路進行，對于經驗不足的系統設計者，更容易掌握并開展系統建模設計。

SysML系統建模語言，由軟件面向對象設計的UML語言演化而來，為了保證系統和軟件良好的兼容性，部分SysML中的定義與沿用了UML語言的圖形和表現形式。然而由于系統工程師和軟件工程師的視角不同，背景知識也不同，使用SysML進行系統建模對系統工程師要求較高。由于SysML對UML的繼承性，SysML提供了更嚴格的定義和豐富的關系，但是在系統層面，相關定義過于復雜，不利于不同專業人員之間打破壁壘進行溝通。

航空系統多數為大型復雜系統，在建模時，應考慮系統的復雜度，而系統建模工作能幫助系統管理復雜度。Arcadia方法將系統模型分成不同的視角，不同的分析角度，這樣就可以讓不同專業的人以不同的復雜度進行評估。

基于SysML建模使用用例圖和活動圖定義系統，明確系統的范圍；使用Arcadia方法進行建模，不僅關注系統如何實現需求，而且可以分析系統的運行理念，讓系統設計者更好地理解用戶的需要，并定義系統運行理念，為后續用戶培訓、文檔編制打好基礎。

5 建模工具對比分析

基于SysML的建模工具相對于Arcadia方法的建模工具更為豐富，本文對IBM(International Business Machines Corporation，簡稱IBM)公司的Raphsody工具和Capella工具進行對比，具體見表2。

表2 Raphsody工具與Capella工具對比分析表

SysML建模有嚴格的層級定義，不能支持不同層級的建模分析嵌套。使用Arcadia方法只需考慮最終實現，方法更為靈活。Capella工具提供高效精準的模型自動轉化功能和追蹤功能，最終系統模型將不同的功能統一到一張圖中，表達更為直觀。而Raphsody工具不支持不同分析模型的轉換，需要建模人員進行分解和定義。

在系統建模初期，應建立系統建模的目標，并定義哪些系統模型需要被定義，這些系統模型解決什么問題，各個模型之間的關系是什么。Arcadia給出了各個分析之間的關系，而SysML由于適用于更廣泛的用途，針對不同分析的模型，各種圖之間的關系并不清楚。

Capella工具基于Java編制，提供了豐富的接口，用戶可以根據具體實際需要進行靈活定制。Raphsody本身功能豐富強大，但是可擴展性較差。部分其他基于SysML工具提供高于Raphsody的可擴展性，如EA(Enterprise Architect)工具。

Capella將系統建模方法Arcadia融入到工具設計中，工具使用者在建模過程中學習和實踐Arcadia建模方法。而其他基于SysML的建模工具，并沒有將建模方法指導融入到建模工具中，工具使用者需要建立一套適合自己的建模方法，將SysML定制化以限定系統建模的范圍和約束。

6 結論與展望

系統工程建模強調的是模型的系統集成，通過基于模型的系統工程建模，將不同領域的模型整合在一起，通過系統的方法和不同的視角，綜合評估系統，以得到系統的最優解決方案。好的系統模型應該能清楚直觀地表示系統設計，特別通過系統模型顯示出可能發生的設計缺陷；打破系統設計者、用戶和系統實現者之間的壁壘，從而有效溝通；應具有標準的、統一的術語和格式定義；另外，通過建模，不同的用戶可以從自己的視角找到問題所在，比如建模一致性，系統性能和軟、硬件實現的沖突，系統性能與項目成本的沖突，技術成熟度和項目進度的沖突等。

配合已有的業務流程，系統模型還應可以從模型轉化成為其他工作的輸入，比如轉化成為系統需求文檔，方便需求的傳遞；可以通過不同層級的仿真或建模確認系統可否實現。通過系統模型逐漸積累設計經驗，可以降低風險。

本文對比發現Arcadia方法建模在系統架構和系統運行方面有著較好的優勢，對系統建模者本身要求也較低，比較適合解決系統層面的問題。通過Arcadia方法和基于SysML方法建立的系統模型，無法實現高仿真度的運行，后續還需開展工作結合特定領域的模型進行系統仿真。