鞠文煜 付 昕 /
(上海飛機設計研究院,上海201210)
系統(tǒng)是由一組實體和這些實體之間的關(guān)系所構(gòu)成的集合,其功能要大于這些實體各自功能之和[1]。按照系統(tǒng)的概念,強調(diào)的是實體和實體之間的關(guān)系,實體構(gòu)成了系統(tǒng)的表現(xiàn)形式。更為重要的是,系統(tǒng)是為了實現(xiàn)功能而被建立,系統(tǒng)的功能主要由一系列的文檔來描述和定義,通過系統(tǒng)工程的流程保證相關(guān)需求和功能被正確實施。然而,由于文檔被自然語言書寫,表達不直觀,對于不同角色對系統(tǒng)的理解將存在差異,進而產(chǎn)生錯誤。對于復雜系統(tǒng)所包含的信息,其信息量巨大,超過了人們理解。這時就需要一種方法將復雜系統(tǒng)表現(xiàn)出來,將表現(xiàn)出的系統(tǒng)特征進行研究。基于模型的系統(tǒng)工程就是解決該問題的方法之一。
系統(tǒng)模型是現(xiàn)實系統(tǒng)的應用、模仿和抽象,它以某種確定的形式,提供關(guān)于該系統(tǒng)的信息,反應系統(tǒng)某一方面的屬性和特征[2]。本文定義的基于模型的系統(tǒng)工程建模,并不是替代目前所有的建模方法和建模技術(shù)?;谀P偷南到y(tǒng)工程建模,強調(diào)的是模型的系統(tǒng)集成者,通過基于模型的系統(tǒng)工程建模,將不同領(lǐng)域的模型整合在一起,通過系統(tǒng)的方法從不同的視角,綜合評估系統(tǒng),以得到系統(tǒng)的最優(yōu)解決方案。
一個復雜系統(tǒng)工程項目的成功,需要眾多背景不同的人員參與其中。比如,系統(tǒng)工程師主要解決如何徹底地理解客戶的需要,并將客戶的需要轉(zhuǎn)化成為系統(tǒng)的需求與功能;根據(jù)系統(tǒng)需求與功能,以及系統(tǒng)設計的約束,選取最佳的解決方案,確定系統(tǒng)給出的架構(gòu)。軟件工程師關(guān)心的則是軟件需要完成的任務、功能及軟件的約束。硬件工程師考慮的是硬件的運行環(huán)境,子硬件模塊的成本、質(zhì)量、功耗等硬件物理特性。用戶則關(guān)心系統(tǒng)如何幫助用戶解決問題,是否滿足客戶的需要,系統(tǒng)使用是否簡潔明了等直接感受。由于不同的角色關(guān)心的問題不同,表達方式、文化背景差異大,因此需要一套有效的方法將系統(tǒng)通過不同的視角,以簡潔明了的形式展現(xiàn)給相關(guān)人員,在系統(tǒng)實際被生產(chǎn)出來前,各方面充分了解需求,進行溝通,并形成最佳的系統(tǒng)解決方案。
系統(tǒng)模型用于表現(xiàn)物理實體的特征和細節(jié),根據(jù)表現(xiàn)方式的不同,一般系統(tǒng)模型可分為圖形模型、數(shù)學模型、邏輯模型等方式。系統(tǒng)模型一般用于描述系統(tǒng)的運行場景,系統(tǒng)的需求、組成、架構(gòu)、行為等方面;通過不同形式的系統(tǒng)建模幫助系統(tǒng)設計人員更好地表現(xiàn)系統(tǒng),分析系統(tǒng),確認需求,讓不同專業(yè)的工程師一起更好地溝通,支持系統(tǒng)更好的設計。
系統(tǒng)建模不僅能解決傳統(tǒng)系統(tǒng)工程溝通等問題,還可以清楚地表征系統(tǒng)給的各方面特性,評估系統(tǒng)設計,分析系統(tǒng)性能需求和其他特性,在早期確認系統(tǒng)設計滿足需求,利用模型對用戶展開虛擬培訓,并縮短系統(tǒng)開發(fā)時間。對于成熟系統(tǒng),系統(tǒng)模型在做更改影響分析、協(xié)同設計及維護系統(tǒng)需求追溯性方面也有著優(yōu)勢。
基于模型的系統(tǒng)工程近年來有了很快的發(fā)展,對象管理組織(Object Management Group,簡稱OMG)和系統(tǒng)工程國際委員會(International Council on System Engineering,簡稱INCOSE)推薦使用系統(tǒng)建模語言(System Modeling Language,以下簡稱SysML)[3]進行系統(tǒng)建模,描述系統(tǒng)的架構(gòu)、需求、行為以及特性。SysML規(guī)范定義了系統(tǒng)建模語言的語法,以及所有圖像所代表的意義,這樣就保證了所有系統(tǒng)工程師使用準確的清晰無誤的語言對系統(tǒng)進行統(tǒng)一描述。系統(tǒng)建模語言關(guān)系如圖1所示[4]。
圖1 SysML九種視圖關(guān)系
基于SysML建模首先定義系統(tǒng)的范圍,通過用例設計明確系統(tǒng)的活動。在需求捕獲階段識別干系人,并通過用例圖(黑盒)的方式,明確干系人的使用場景,針對每個使用場景,根據(jù)系統(tǒng)的行為編制系統(tǒng)的活動圖(黑盒),在活動圖編制過程中識別系統(tǒng)外部的輸入和輸出。通過用例圖和活動圖的編制,完成功能定義。在完成了用例圖(黑盒)和活動圖(黑盒)后,系統(tǒng)的行為和系統(tǒng)外部輸入輸出已被初步定義,這時就可以形成系統(tǒng)的框圖,使用用例圖、活動圖和框圖這三種類型的建模模型就可以完成對上一層級需求的確認。
經(jīng)評審后的框圖、用例圖、活動圖,作為系統(tǒng)設計的輸入,重新識別干系人和用例,把用例和活動分解,在系統(tǒng)內(nèi)部設立不同的功能模塊,并明確每個功能模塊的作用,形成系統(tǒng)的內(nèi)部框圖,根據(jù)系統(tǒng)內(nèi)部框圖的模塊將系統(tǒng)活動圖重新定義,完成整個系統(tǒng)的活動定義。然后根據(jù)系統(tǒng)化的系統(tǒng)活動圖設計系統(tǒng)的時序圖,定義系統(tǒng)內(nèi)部各模塊的功能和系統(tǒng)的運行機制;在定義系統(tǒng)時序圖后,完成系統(tǒng)狀態(tài)機圖定義,檢查每個系統(tǒng)狀態(tài)是否合理并符合預期,當系統(tǒng)狀態(tài)機圖完成后,已基本可以確認系統(tǒng)設計是否滿足功能要求,總結(jié)其他系統(tǒng)需求,形成系統(tǒng)需求圖。以上工作完成后,就可以將設計好的系統(tǒng)架構(gòu)、系統(tǒng)內(nèi)部模型、系統(tǒng)用例模型、系統(tǒng)活動模型、系統(tǒng)時序模型、系統(tǒng)狀態(tài)機模型和系統(tǒng)需求模型進行初步設計評審。
在詳細設計階段,軟硬件設計人員和系統(tǒng)設計人員將針對初步設計階段形成的系統(tǒng)模型,完成系統(tǒng)功能分配,將系統(tǒng)功能分配至軟硬件及補充系統(tǒng)的包圖。針對系統(tǒng)運行的各種內(nèi)部和外部參數(shù),采用系統(tǒng)參數(shù)圖進行定義,形成標準的基于XMI(XML-based Metadata Interchange,簡稱XMI)的參數(shù)集,以及接口的邏輯框圖。最后根據(jù)完成的系統(tǒng)包圖和系統(tǒng)參數(shù)圖,對之前形成的系統(tǒng)架構(gòu)、系統(tǒng)內(nèi)部模型、系統(tǒng)用例模型、系統(tǒng)活動模型、系統(tǒng)時序模型、系統(tǒng)狀態(tài)機模型和系統(tǒng)需求模型進行更新和細化。
在生產(chǎn)和制造階段,由于SysML和統(tǒng)一建模語言(Unified Modeling Language,簡稱UML)有一定的共通性,軟件設計人員可以利用之前建立的系統(tǒng)模型,進而繼續(xù)建立軟件模型,建立好的軟件模型可以提供給系統(tǒng)作為軟件設計確認的證據(jù)。另外由于SysML采用基于XMI的架構(gòu)性語言,一般建模工具對于SysML建立的模型均提供XMI接口,可以利用工具生成基于XMI架構(gòu)的測試腳本。
如果在系統(tǒng)改進階段,由系統(tǒng)建模工具提供統(tǒng)一的管理方法,確定優(yōu)化項目后,可以很方便地確定受影響的模塊,分析更改影響的結(jié)果,并提供初步的確認和驗證。
隨著基于模型的系統(tǒng)工程的迅速發(fā)展,各公司對系統(tǒng)工程建模均有一定的研究,其中,泰勒斯公司基于IEEE 1220標準,開發(fā)并定制了其特有的系統(tǒng)建模工具Capella,并形成了符合其自身特點的架構(gòu)分析和設計集成方法,即Arcadia方法論。
Arcadia方法將系統(tǒng)建模的過程分為運營分析、系統(tǒng)分析、邏輯分析、物理分析和終端產(chǎn)品結(jié)構(gòu)分解共五層[5],如圖2所示。Arcadia方法在SysML的基礎(chǔ)上做了擴展和定制,從而形成了具有定制特征的建模語言,通過SysML的拓展和定制,Arcadia方法補充了運營理念、目標和系統(tǒng)任務分析。
圖2 Arcadia方法建模關(guān)系圖
與SysML不同,通過使用Arcadia方法建模,無需明確系統(tǒng)邊界。Arcadia方法結(jié)合了美國國防部架構(gòu)框架(Department of Defense Architecture Framework,簡稱DoDAF)[6]的相關(guān)理念,首先定義的是用戶需要系統(tǒng)完成的任務,也就是用戶需要具備的運行能力。在運行分析階段,只分析用戶遇到的問題、用戶的需要以及用戶的潛在需求。這時并不需要確定系統(tǒng)的邊界,當系統(tǒng)出現(xiàn)在運營分析中,就限定了給用戶的解決方案,也就沒有辦法評估相關(guān)方案是否是最佳的解決方案。運營分析的對象是用戶、用戶在運營中的角色、用戶完成的活動,分析的內(nèi)容是用戶活動是否存在問題和不足、是否有改進的空間。
運行分析完成后,系統(tǒng)工程師需要將不同用戶的需求進行整理和分析,分析后得到統(tǒng)一的系統(tǒng)需求和系統(tǒng)模型。在系統(tǒng)分析階段,研究的是系統(tǒng)如何滿足用戶的需求,提供具體的解決方案,通過運行能力的細化,明確系統(tǒng)在用戶運營分析中需要完成的任務,總結(jié)抽象系統(tǒng)需要具備的能力,定義系統(tǒng)需要完成的活動,考慮運行約束給系統(tǒng)活動帶來的限制,最終形成系統(tǒng)需求。在系統(tǒng)分析階段,還需要考慮系統(tǒng)活動完成所需的輸入條件,也就是系統(tǒng)的外部接口。
邏輯分析是系統(tǒng)功能的細化,將系統(tǒng)功能分解為子功能,并在系統(tǒng)層面實現(xiàn)系統(tǒng)子功能的整合與分配。邏輯分析還解決系統(tǒng)內(nèi)部約束、系統(tǒng)內(nèi)部功能、功能關(guān)系、具體實現(xiàn)的技術(shù)以及潛在技術(shù)等方面問題。在邏輯層面,實現(xiàn)詳細的系統(tǒng)分析,考慮系統(tǒng)的約束,平衡系統(tǒng)性能、安全性和可靠性等指標,以求得到最佳的系統(tǒng)方案。系統(tǒng)分析和邏輯分析共同完成系統(tǒng)功能定義,系統(tǒng)需求分解與分配,形成系統(tǒng)定義。
物理分析是定義系統(tǒng)的具體實現(xiàn)方式,考慮系統(tǒng)的物理特性,以達到系統(tǒng)在質(zhì)量、功耗、成本等物理層面的最優(yōu)設計。物理分析和終端產(chǎn)品分析適用于不同的系統(tǒng)對象和系統(tǒng)組織形式。物理分析過程考慮的是系統(tǒng)如何實現(xiàn),包括物理約束的系統(tǒng)架構(gòu)選擇,物理連接形式,各部件實現(xiàn)的功能等。
物理層向下分解,還可以將物理實現(xiàn)再分解至各個構(gòu)型項的物理實現(xiàn),也就是終端產(chǎn)品分解結(jié)構(gòu)定義,這個層級解決的是軟硬件分配和集成的過程,一般是軟、硬件工程師關(guān)注的重點。
基于SysML方法建模與Arcadia方法建模對比分析見表1。
表1 基于SysML方法建模與Arcadia方法建模對比分析表
使用Arcadia方法的建模工具Capella建模,無需對系統(tǒng)建模理論做研究,僅需按照Arcadia方法本身以及工具提供的建模思路進行,對于經(jīng)驗不足的系統(tǒng)設計者,更容易掌握并開展系統(tǒng)建模設計。
SysML系統(tǒng)建模語言,由軟件面向?qū)ο笤O計的UML語言演化而來,為了保證系統(tǒng)和軟件良好的兼容性,部分SysML中的定義與沿用了UML語言的圖形和表現(xiàn)形式。然而由于系統(tǒng)工程師和軟件工程師的視角不同,背景知識也不同,使用SysML進行系統(tǒng)建模對系統(tǒng)工程師要求較高。由于SysML對UML的繼承性,SysML提供了更嚴格的定義和豐富的關(guān)系,但是在系統(tǒng)層面,相關(guān)定義過于復雜,不利于不同專業(yè)人員之間打破壁壘進行溝通。
航空系統(tǒng)多數(shù)為大型復雜系統(tǒng),在建模時,應考慮系統(tǒng)的復雜度,而系統(tǒng)建模工作能幫助系統(tǒng)管理復雜度。Arcadia方法將系統(tǒng)模型分成不同的視角,不同的分析角度,這樣就可以讓不同專業(yè)的人以不同的復雜度進行評估。
基于SysML建模使用用例圖和活動圖定義系統(tǒng),明確系統(tǒng)的范圍;使用Arcadia方法進行建模,不僅關(guān)注系統(tǒng)如何實現(xiàn)需求,而且可以分析系統(tǒng)的運行理念,讓系統(tǒng)設計者更好地理解用戶的需要,并定義系統(tǒng)運行理念,為后續(xù)用戶培訓、文檔編制打好基礎(chǔ)。
基于SysML的建模工具相對于Arcadia方法的建模工具更為豐富,本文對IBM(International Business Machines Corporation,簡稱IBM)公司的Raphsody工具和Capella工具進行對比,具體見表2。
表2 Raphsody工具與Capella工具對比分析表
SysML建模有嚴格的層級定義,不能支持不同層級的建模分析嵌套。使用Arcadia方法只需考慮最終實現(xiàn),方法更為靈活。Capella工具提供高效精準的模型自動轉(zhuǎn)化功能和追蹤功能,最終系統(tǒng)模型將不同的功能統(tǒng)一到一張圖中,表達更為直觀。而Raphsody工具不支持不同分析模型的轉(zhuǎn)換,需要建模人員進行分解和定義。
在系統(tǒng)建模初期,應建立系統(tǒng)建模的目標,并定義哪些系統(tǒng)模型需要被定義,這些系統(tǒng)模型解決什么問題,各個模型之間的關(guān)系是什么。Arcadia給出了各個分析之間的關(guān)系,而SysML由于適用于更廣泛的用途,針對不同分析的模型,各種圖之間的關(guān)系并不清楚。
Capella工具基于Java編制,提供了豐富的接口,用戶可以根據(jù)具體實際需要進行靈活定制。Raphsody本身功能豐富強大,但是可擴展性較差。部分其他基于SysML工具提供高于Raphsody的可擴展性,如EA(Enterprise Architect)工具。
Capella將系統(tǒng)建模方法Arcadia融入到工具設計中,工具使用者在建模過程中學習和實踐Arcadia建模方法。而其他基于SysML的建模工具,并沒有將建模方法指導融入到建模工具中,工具使用者需要建立一套適合自己的建模方法,將SysML定制化以限定系統(tǒng)建模的范圍和約束。
系統(tǒng)工程建模強調(diào)的是模型的系統(tǒng)集成,通過基于模型的系統(tǒng)工程建模,將不同領(lǐng)域的模型整合在一起,通過系統(tǒng)的方法和不同的視角,綜合評估系統(tǒng),以得到系統(tǒng)的最優(yōu)解決方案。好的系統(tǒng)模型應該能清楚直觀地表示系統(tǒng)設計,特別通過系統(tǒng)模型顯示出可能發(fā)生的設計缺陷;打破系統(tǒng)設計者、用戶和系統(tǒng)實現(xiàn)者之間的壁壘,從而有效溝通;應具有標準的、統(tǒng)一的術(shù)語和格式定義;另外,通過建模,不同的用戶可以從自己的視角找到問題所在,比如建模一致性,系統(tǒng)性能和軟、硬件實現(xiàn)的沖突,系統(tǒng)性能與項目成本的沖突,技術(shù)成熟度和項目進度的沖突等。
配合已有的業(yè)務流程,系統(tǒng)模型還應可以從模型轉(zhuǎn)化成為其他工作的輸入,比如轉(zhuǎn)化成為系統(tǒng)需求文檔,方便需求的傳遞;可以通過不同層級的仿真或建模確認系統(tǒng)可否實現(xiàn)。通過系統(tǒng)模型逐漸積累設計經(jīng)驗,可以降低風險。
本文對比發(fā)現(xiàn)Arcadia方法建模在系統(tǒng)架構(gòu)和系統(tǒng)運行方面有著較好的優(yōu)勢,對系統(tǒng)建模者本身要求也較低,比較適合解決系統(tǒng)層面的問題。通過Arcadia方法和基于SysML方法建立的系統(tǒng)模型,無法實現(xiàn)高仿真度的運行,后續(xù)還需開展工作結(jié)合特定領(lǐng)域的模型進行系統(tǒng)仿真。