摘要   軟件工程經歷了從面向過程（Process-Oriented）到面向對象（Object-Oriented）的轉變，實踐證明了這種轉變的成功。相對軟件工程更為一般化的系統工程，也遇到了系統日益復雜的問題。基于模型的系統工程（MBSE，Model-Based Systems Engineering）是對建模（活動）的形式化應用（formalized applicationof modeling），以便支持系統要求、設計、分析、驗證和確認等活動，這些活動從概念設計階段開始，持續貫穿到設計開發以及后來的所有壽命周期階段。MBSE采用從統一建模語言（UML，Unified Modeling Language）發展而來的系統建模語言（Systems Modeling Language，SysML）來構建系統模型，其本質是面向對象的系統工程（Object-Oriented Systems Engineering，OOSE），也將獲得類似面向對象的軟件工程（Object-Oriented Software Engineering，OOSWE）的優勢，而且MBSE的工作流程，應以面向對象為指導原則來探索和實踐。

關鍵字   面向對象；基于模型的系統工程；系統建模語言；面向對象的系統工程

---

軟件工程中存在面向過程和面向對象兩種思路。我們又知道，軟件工程是系統工程的特例，SysML又源自于UML，系統工程是否也存在面向過程和面向對象之分呢？從傳統的系統工程（TraditionalSystems Engineering，TSE）發展到基于SysML的MBSE，是否也是系統工程思路的重大轉變——從面向過程到面向對象？MBSE又能否借鑒面向對象帶來的優勢去處理日益復雜的工程系統？本文作一簡要論述。

1   軟件工程從面向過程發展到面向對象的啟示

軟件工程已經從面向過程發展、轉變到了面向對象，那么，面向過程和面向對象各自的本質是什么？這種轉變又有什么意義？

1.1   面向過程的特點

傳統的軟件工程是面向過程的，就是把準備求解的問題按照算法進行分解^[1] ，從程序分解到子程序、函數、子函數，直至計算機自帶指令集中的最基本指令。比如求解5的正弦函數值，就要展開成泰勒級數，再分解成加減乘除的計算，再把這些分解后的運算步驟映射成計算機的指令，如取數、加和、存儲等，然后由軟件（此時即一系列的指令組合）指揮著計算機硬件去完成相應的各種操作。這與計算機誕生之初主要用于科學計算有關。

1.1.1  面向過程意味著狀態序列分解。

過程的本質是一組連續的狀態序列，狀態是對象在某個時間點上的特征取值的組合，如物體的運動過程，是其質點坐標、姿態等特征取值的變化。狀態序列類似拍電影時的一秒鐘有24個畫面，一個畫面對應著拍攝對象的一個狀態。對過程的分解、不斷細分，即狀態序列分解，也即狀態之間的時間間隔不斷縮小。

在計算機軟件的解題過程（如上文所提計算5的正弦函數值）中，計算機硬件的初始狀態與輸入值對應，目標狀態與計算結果對應，計算機的整個狀態變化過程，對應著一步步的計算過程。也就是說，計算機的解題過程，就是計算機硬件的一系列連續狀態變化過程。計算機軟件就是根據人對解題過程的分析、設計，來對計算機硬件的狀態變化過程、狀態序列進行描述，在指令層次，就是計算機的控制器發出對鍵盤、存儲器、運算器等硬件的一系列指令，而一條指令，又對應著計算機硬件狀態的一次狀態切換。

面向過程的軟件開發思路，是把安裝了軟件的計算機當作一個系統，把它從數值輸入到結果輸出的整個計算和處理過程（也是整個狀態變化過程）進行分解，得到更小的狀態變化過程，直至這些小的狀態變化過程和計算機所能夠完成的狀態變化過程相對應，即執行一條指令，計算機的狀態發生一次切換。因此，面向過程的軟件開發也就是軟件開發中的算法分解。

1.1.2   數據和操作相分離。

面向過程的思路把程序分為數據和操縱處理數據的過程（函數）兩部分，軟件體現為算法＋數據結構兩大部分，并且以算法為中心（往往以算法是否高效來衡量程序員水平的高低）。這種思路和做法，把數據和處理數據的過程（函數）分開，相當于把對象的屬性（狀態）與狀態變化（行為）強行地分開，這顯然有悖常理。因為有什么樣的屬性，才會有什么樣的狀態變化，狀態變化是存在路徑依賴的，是在前一時刻狀態的基礎上發生的。任何一個對象、事物都是其靜態屬性和動態屬性的統一，是結構決定功能，是慢變過程決定功能這一快變過程。把數據和對數據的過程（函數）在邏輯上分開與割裂，就容易造成整個設計思維的割裂。而在面向對象的軟件開發中，不存在數據處理的概念，沒有函數的概念，只有對象的調用及對象的狀態變化。

1.1.3   問題描述和解決方案描述語言之間的巨大差別。

計算機軟件所要解決的現實世界中的問題、難題，如大型銀行的信息系統，包括了各種終端、數據庫、服務器、單機等，每天處理天文數量級的業務，并和各種外部公司的信息系統交互數據，如證券公司、保險公司、業務伙伴、第三方支付軟件等，信息系統的復雜度非常高。而且，問題往往都用自然語言來提出、思考并記錄，并不是用計算機的編程語言。自然語言是主語謂語賓語都全的語言，正如姚振武在《人類語言的起源與古代漢語的語言學意義》中所說：最初的思維形式、語言形式、邏輯形式是三位一體的：其底層就是“本體—屬性”的概念，其語言表達就是“指稱—陳述”的分化（有時按一般的習慣，粗略地稱為“名詞—動詞”）^[2]。而編程語言是無主語，只有謂語和賓語的語言^[3]。上文所說的軟件開發的過程分解、算法，是計算機動作的分解，也就是默認計算機是這些動作、功能、指令的主語，過程分解就是對動詞進行分解。而當我們用計算機來模擬現實世界時，現實世界有很多的“主語”，它們有自己的狀態變化規律和行為規律，如銀行信息系統外部的各種企業用戶、個人用戶等。我們在開發軟件時，就不得不在計算機語言和描述現實世界的自然語言之間進行繁瑣的轉換。隨著軟件系統的日益復雜，這種轉換是軟件開發難度激增的重要原因。

1.2   面向過程方法面臨的挑戰

1.2.1   系統越來越復雜

現實世界中對象的行為豐富多彩，而計算機本身的行為、動作只有那么數百種，即計算機自身的指令集（如RISC，Reduced Instruction Set Computer，精簡指令集計算機），因此，必須借助復雜的算法，把現實世界中對象的行為（如銀行系統中各類主體的行為）變換到計算機指令的組合，這個難度可想而知。

1.2.2   難以應對用戶的需求蠕變

軟件用戶的需求即對應著計算機系統狀態變化過程中一頭一尾兩個狀態（比如A狀態變化到B狀態），當需求變化時（可能是A狀態變化到C狀態），即狀態序列的兩端發生了變化，那么功能分析、狀態序列分解的結果也會變化，相應的軟件功能模塊也會發生較大的變化。面向過程的軟件開發中，系統有明確的邊界，因為只有先確定系統的范圍和邊界，才能明確并不斷分解系統的狀態序列，使之計算機的基本指令靠攏。因此，面向過程思路受初始狀態、最終狀態，也即用戶需求（對應著從初始狀態變化到最終狀態）的影響很大，這種思路開發出的軟件，不易擴充和修改，難以應對用戶需求蠕變。

1.2.3   人們對復雜事物的認識必然要經歷一個不斷深入的過程

面向過程的軟件代碼是對數據結構中各個數據進行加工處理的，要首先確定數據結構，而且數據結構的不同維度之間還存在一定的耦合關系。而一旦數據結構改變，有關的操作乃至整個程序都需要重新組織和設計，代碼就要重新編寫。數據結構的實質是事物的特征組合（如學生信息系統中，關注學生的年齡、學號、成績等特征），也就是說，數據結構的變化意味著數據結構所描述的對象不是原來那類對象了（如學生信息系統中，所關注的特征變化后，很可能不再是在校學生而是往屆校友了），那么對象的變化方式（代碼、函數）自然也不同了。

同時，事物可能很龐大、很復雜，其特征值的維度也可能很多，面向過程的設計思想，試圖一下子就完全把握對象的所有方面的特征，這似乎不太現實。因為人們對這些事物的認識是循序漸進、逐漸深入的，今天發現了事物的一個特征，明天又要新增某個需要關注的特征，這也是需求、問題的認識過程。

面向對象的思路反其道而行之，就是承認我們對事物、對象的“無知”，慢慢從“無知”走向“有知”，就是逐步地明確對象的特征及對象的操作、變化方式。并且隨著我們對事物認識的深入，而不斷地給事物增加特征、增加特征的變化方式，這個過程就是認識不斷地深入的過程，也是逐步的特化（Specialization）的過程。

1.3   面向對象和面向過程的對比

面向對象的軟件工程是先從編程語言開始的，如C++、Java，直至UML。面向對象的軟件開發，采取數據結構＋算法的方式，從以前的算法為中心，轉變為數據結構為中心。其主要特點是：

?  對象＝數據結構＋算法

?  程序＝（對象＋對象＋對象……）＋消息

?  消息的作用就是對對象的控制。

Orient的含義是“把興趣對著……、集中在……”，因此，“Object-Oriented”的意思是“以對象導向，把興趣集中在對象上”。以對象為主要的興趣點，并不是說不再關注過程，而是以對象為關注點、為分析思路，然后用對象的動作、操作，來組成系統的變化過程，讓系統發生各種各樣的狀態變化，使系統能夠滿足用戶的需要。正如著名的UML專家GradyBooch在《面向對象分析與設計》一書中所說 ：“如果過程和函數是動詞，數據是名詞，那么面向過程語言的程序就是圍繞動詞組織的，面向對象的程序就是圍繞名詞組織的”^[4]。

在軟件開發時，我們可以把軟件所要描述、計算的現實世界中的事物、實體（如學生信息系統中的每一個學生）看成是對象，并與計算機中的實體（內存、硬盤上的一段代碼，也即描述對象的一段代碼）進行對應，現實世界中的對象叫做問題空間的對象，計算機中的實體叫做解空間對象。

1.3.1   面向對象的語言彌補了問題空間和解空間之間的鴻溝

軟件開發中描述問題的自然語言和解決問題的編程語言之間，存在著巨大的語言鴻溝，這個鴻溝，表面上看是符號的區別（一個是自然語言，一個是程序語言），實質上是概念上的鴻溝：前者是現實世界中某一個問題領域的概念，后者是解空間即計算機中的概念，如計算機的指令、內存等。

人們不斷發明新的編程語言來縮小人機溝通語言之間的鴻溝，先是二進制的機器語言（要計算機服從指揮、幫助人們做事，就必須用計算機能夠“聽懂”的語言），在此之上又發明了匯編語言、高級語言，以此來填補自然語言和機器語言之間的“語言鴻溝”^[1]。面向對象的軟件工程的語言變成Java、C++或者UML，使得人機溝通語言之間的鴻溝日趨縮小，但核心是思路也即頭腦中組織概念的方式更加一致：都是一系列的對象及對象之間通過消息實現控制。

1.3.2   彌補了需求分析和設計的鴻溝

軟件不能真正滿足用戶需要，主要源于兩個方面：一是不能徹底理解用戶需求，二是用戶需求在不斷的變化，即需求蠕變。軟件工程有句笑話：殺死一個程序員的好辦法，就是把需求改三回，因為用戶也有一句經常說的名言，也是一副對聯：這個問題很簡單，技術細節我不管，橫批：趕快上線。那么用戶為什么要改需求？實際上他也沒辦法，因為用戶對自己的需求也有一個認識的過程，同時用戶本身所處的環境（如交易對手、外部接口環境等）也在不斷地變化，因此，軟件開發過程中，需求蠕變是不可避免的。

面向對象的軟件工程中，需求方和研制方使用同一種語言——UML來描述，可以有效彌補需求和設計的鴻溝。采用業務建模、用例等方法，進而進行系統用例的建模，這是用戶和設計者雙方都能夠理解的語言和建模方式，便于雙方進行溝通。

面向對象的軟件工程，相對于面向過程的軟件工程有諸多優勢，尤其是在復雜軟件開發中，本文不再贅述。

2   面向對象方法學及其對工程系統設計思路的啟示

本節對面向對象的軟件工程進行更為一般化的概括，闡述面向對象方法學并分析其特點。

2.1   從面向對象的軟件工程到更為抽象的面向對象方法學 

面向對象的軟件工程與面向過程的軟件工程，在編程語言、建模語言上的區別是表面上的，核心是思維方式的轉變，也即頭腦中組織問題域和解域的相關概念的方式，是以實體為主線還是以過程為主線。

2.1.1   面向對象的軟件工程的啟示：對象分解而不是過程分解

客觀世界是由許多各種各樣的對象所組成的，每種對象都有各自的內部狀態和運動規律，不同對象間的相互作用和聯系就構成了各種不同的系統，構成了我們所面對的客觀世界。把客觀世界中的一個實體抽象為問題域中的對象（Object）。對象具有狀態，一般用數據值來描述對象的狀態。從動態觀點看，對對象施加的操作就是該對象的行為。通常，客觀世界中的實體既具有靜態的屬性又具有動態的行為^[5]。

         

                 

圖1   用自動機模擬對象 

從動態角度或對象的實現機制來看，對象是一臺自動機，具有內部狀態S，操作fi（i＝1，2，……n），且與操作fi對應的狀態轉換函數為gi（i＝1，2，……n）。轉換是不及物動詞，操作是及物動詞，對輸入的X進行加工，輸出是fi（X，S），如圖1所示。此時的輸入相當于是對對象的操作fi進行了調用，同時，對象的狀態由S轉換成S'。比如碎紙機處于“待機狀態”S，輸入是一張A4紙，同時調用了碎紙機的操作“粉碎紙張”，輸出是碎紙屑。

2.1.2   面向對象方法學的提出

對象是一種普遍適用的基本邏輯結構，是一個以有組織的形式含有信息的實體。它既可以表示一個抽象的概念，也可以表示一個具體的模塊，既可以表示軟件，也可以表示硬件。因此，面向對象的方法學既提供了一個分析、設計和實現系統的統一方法，又提供了描述、設計和實現硬件和軟件系統的統一框架。

面向對象方法學盡可能地模擬人的思維方式，并且和方法學相適應的面向對象技術也提供了這樣的可能性：即可以隨著對某個系統的需求逐步具體的過程而逐步地設計和實現這個系統。

面向對象方法學在概念和表示方法上的一致性，保證了在各開發活動之間直接地平滑過渡。面向對象的軟件工程中，分析、設計、編碼等開發活動之間并不存在明顯的邊界。分析和設計之間要多次迭代，這就意味著兩個團隊的人員要不斷地交流。交流就要用某種語言，語言就要包含相應的概念，語言就是對概念的組織，那么按照對象分解的思路進行概念組織，還是按照功能分解的思路進行分解和組織，會極大地影響交流的效果：按照對象分解思路，使得各方更容易溝通。

2.1.3   從認識論層次看面向對象方法學

恩格斯在《路德維希?費爾巴哈和德國古典哲學的終結》中指出：“必須先研究事物，而后才能研究過程。必須先知道一個事物是什么，而后才能覺察這個事物中所發生的變化”。因此，我們在認識和研究客觀世界時應從“對象”入手，然后再轉向“過程”。經驗也告訴我們，在客觀世界以及作為它的映射的軟件系統中，“過程”和“操作”是不穩定的、多變的，而“對象”和“數據結構”則相對穩定得多了。因此，如以“過程”入手（或以“過程”為中心）來設計軟件，則思維成果的可重用性必然較差，而以“對象”或“數據結構”入手（或以“對象”或“數據結構”為中心），則軟件的主體結構比較穩定，其所得的思維成果的可重用性就有可能較好。但又必須考慮到對進一步轉向研究“過程”的可能和方便^[6]。

《大英百科全書》描述了分類學理論中有關人類認識現實世界所普遍采用的3個構造法則：區分對象及其屬性；區分整體對象及其組成部分；形成并區分不同對象的類。面向對象思想正是根據以上3個常用的構造法而建立起來的。在實際應用中，它采用對象及其屬性，整體和部分，類、成員和它們之間的區別等3個法則來對系統進行分析和設計，遵循了分類學理論的基本原理^[7]。

2.2   面向對象方法學對工程系統設計思路的啟示

從軟件（計算機系統）開發這個特殊，走到一般化的工程系統研制，看軟件開發中的面向對象能不能為工程系統開發所用？

在面向對象的軟件工程中，人們采用面向對象的思路對問題空間中的客體進行抽象，軟件、計算機只負責記錄、處理這些對象的屬性信息，并不實際改變它們的屬性。而工程系統包括處理物質能量的部分和處理信息數據的部分，后者的代表是計算機系統。工程系統的設計，最重要的是搞清楚系統的零部件之間是如何相互作用的，如何通過零部件的相互作用實現系統的功能，所以就產生一個思路：能不能把系統的零部件也當作對象，在計算機建模環境中模擬出零部件的所有動作（即屬性變化），并且讓這些動作的組合能夠實現系統功能。最后，再把這些我們已經知道了其屬性變化的零部件實現出來（車間加工、市場上直接采購等）。

2.2.1   問題空間和解決方案空間的同構

工程師要想研制出工程系統去要解決用戶所面臨的問題，就需要從問題領域跨越到解決方案領域。兩個領域有不同的知識（概念及其關系），兩個領域的人相互理解比較困難。

問題空間中存在的是對象。問題空間的本質是對象的狀態不符合人的需求，人們對這個狀態不滿意，因此解決問題的實質就是使對象的狀態從不滿意變化到滿意。無論是工程系統開發，還是軟件開發（計算機系統開發），都是要解決人們在現實世界中的問題，也就是幫助人們從目前的狀態（不滿意狀態）走向目標狀態（滿意狀態）。人們要解決現實世界中的問題，就必須先對這個問題進行認識和定義。通常來說，人們對現實世界的認識方式都是面向對象的，也就是先看到物，再看到物的變化所形成的過程、物的行為，也就是人們認識世界的方式是面向對象的。對計算機計算5的正弦函數值來說，是從輸入值對應的狀態（按下鍵盤的5這個鍵），變化到輸出結果對應的狀態（屏幕上顯示出結果），這兩個狀態在內存中有分別的對應。對碎紙機來說，是從整張紙這種不滿意的狀態，變化到“粉碎的”這種滿意的狀態。因此，問題空間必然對應著一組對象，每個對象當然可以再分解為小的對象。

解決方案空間中存在的當然也是對象，如零部件、各種商用現貨等。解決方案就是通過對解空間中對象的操作、讓解空間中的對象之間相互作用來解決問題。

既然問題空間和解空間中存在的都是對象，而面向過程的開發方法（如上文所說的面向過程的軟件開發），卻采用面向過程的思路進行從問題空間到解空間的映射，例如進行功能分解得到功能架構、再由功能架構轉換到物理架構等，這是一種思路上的扭曲，造成了問題空間和解空間無法同構（相同的分解結構），無法按照面向對象思路進行層層分解。只有采用面向對象的思路，才能實現從問題空間向解空間的映射同構。因此，在分析問題、分析需求時，設計解決方案時，應堅持以對象為中心的思路，即面向對象的思路，以便實現問題空間和解空間的同構。

2.2.2   各方人員之間的相互理解溝通變得容易

無論是開發軟件還是開發導彈，從用戶需求到系統架構，到設計方案到實現過程和維護過程，實際是人的思維成果的轉化，是站在不同視角的人，對系統進行認識而得到的不同視圖，是不同視圖在不同人之間進行傳遞，而思維成果必然以某種語言來表示，而且要具體落實到某種建模載體（紙張、實物模型或計算機上的圖示、圖形等）上，以便整個團隊進行交流、溝通。如果從問題空間、到解決方案空間，用戶、系統架構師、設計師都采用面向對象思路來工作（當然要借助類似UML、SysML這樣的語言及相應的軟件），則大家的溝通會非常地順暢。

 

3  MBSE是面向對象的，而TSE是面向過程的

在對比了軟件工程中的面向過程和面向對象，來看更一般的系統工程中的面向過程和面向對象。

3.1   TSE是面向過程的

我們把目前型號研制中正在使用的系統工程稱作傳統的系統工程（TSE），它是面向過程的。就是把工程系統在運行中從初始狀態到最終狀態的變化過程，進行層層的狀態序列細分，直至簡單的狀態變化，并且可以根據該狀態變化找到合適的硬件來實現（例如分解到控制電路閉合的電源開關）。這個分解過程，與軟件工程中把計算機作為一個整體進行狀態序列分解，是同一個思路。

從歷史來看，系統工程從誕生之日起，就一直在采用面向過程、功能導向的設計方法，和軟件工程的結構化編程及功能分解的方法是一樣的^[8]。比如1969年的Mil-std 499及后續的Mil-std 499A、Mil-std 499B均提出進行功能分析，其中499B明確提出了系統工程過程（其中的第二步是功能分解與分配）。直至1998年發布的EIA 632，才提出在進行“邏輯解決方案表示”時，可以用功能分析方法，也可以用面向對象的分析方法。此時，軟件工程界的面向對象已經得到廣泛應用（UML在1997年11月發布了1.1版）。

TSE把目的系統當作一個大的過程，對應著一頭一尾兩個狀態，那么中間的狀態都是什么，就需要面向過程的分解來把這些狀態找出來。此時把系統當作一個有輸入和輸出的過程，每一對輸入輸出，對應著一頭一尾兩個系統狀態，這兩個狀態又對應著輸入物的狀態，如ATM機的輸入物是銀行 卡、密碼信息，輸出物是卡片、鈔 票、打印憑條、提示信息等。

功能分解類似寫報告的分級標題，層層分解。比如第一層分成1.0、2.0、3.0、4.0，每一個相當于一個大的子過程、一個大的步驟，比如ATM機的2.0步驟，就是“接受并發送操作申請”。但是這一步驟仍然在物理上無法直接實現，那就對2.0繼續分解，分解到2.1、2.2、2.3、2.4、2.5這5個步驟（如圖2所示），然后看這幾個步驟能不能直接找到硬件來完成，如果不能，則繼續分解，直到最底層，比如分解到了2.1.1.1、2.1.1.2這一層次（可形象的稱為是四級標題），這些動作就比較簡單，可以交給簡單的零部件來完成。比如最簡單的情形，2.1.1.1就是一個開關動作，對應著開和關兩種狀態（從開到關，也構成了一個狀態序列），那么，就可以交給一個現成的零部件——開關（switch）來實現；再比如，向服務器發送賬戶信息，則可以交給天線來完成。

圖2   自動取款機的功能分解示意圖（功能流方框圖FFBD）

在分解的過程中，1.0、1.1、1.1.1等這些層次，實質上是沒有內容的，只是不同層次的一個概括，最終內容都在最底層的動作。比如1.1.1，分解成1.1.1.1－1.1.1.7這7個動作，這7個動作完成了則1.1.1的動作也就完成了。然后再向上逐級地匯總，1.1.1－1.1.4的動作完成了，則1.1的動作也完成了。如此匯總，直至整個系統的動作的完成。

當系統開始運行時，首先執行1.1.1.1這個動作，其它的動作不執行，也就是對應1.1.1.1這個動作的零部件的狀態發生變化，其它的零部件的狀態不變化，那么從宏觀上看整個系統，它的狀態雖然只是在這個局部發生了變化，但是系統的狀態仍然是發生了變化，在系統層面，也是兩個狀態，對外體現了系統的一個動作（完整功能的一小部分）。那么，當后續的1.1.1.2等一系列的動作執行時，系統的狀態就一直在發生變化，這樣，等系統把所有“四級標題”的動作執行完（比如最后一個是4.4.5.8），則系統就運行了一遍，完成了系統的功能。

這種面向過程的分解的弊端，類似前文所述面向過程的軟件工程的弊端，不再贅述。

3.2   系統工程應該也可以從面向過程發展到面向對象

目前工程系統越來越復雜，主要是因為其外部用戶眾多、使用方式多變、軟件密集等。計算機控制從本質上增加了系統的復雜性，這也是系統工程的重要關注點。在軟件密集型、賽博物理系統中，軟件所發揮的功能由原來的7％增長到70％^[9]；型號研制涉及的專業知識門類多，需要考慮的專業工程多；與新老系統的互操作性的要求和系統的可擴展性的要求，這些都是系統和項目日益復雜的原因。

以賽博物理系統的開發為例，越來越像是復雜軟件的開發，可以借鑒復雜軟件的思路來開發復雜工程系統。此時，把復雜工程系統中除計算機之外的硬件，如發動機、伺服機構等當作型號計算機的外部設備。同時，已經有了系統建模語言這種從面向對象的軟件工程建模語言（UML）發展而來、針對系統（不再區分軟硬件）的通用性語言，因此，面向對象的系統工程是可以實現的。

3.3   MBSE的實質是OOSE

系統工程作為“創造系統的方法和技術”，作為復雜工程系統研制組織管理的技術，當然包括系統建模技術和系統建模的組織管理技術，因為管理的基礎是溝通，復雜工程中溝通的基礎是系統模型，系統模型的基礎是系統建模技術，系統建模工作中包含著系統建模技術，即建模語言、建模思路和建模工具^[10]。

MBSE是面向對象的系統工程（OOSE），而TSE是面向過程的系統工程（POSE），兩者的區別，和OOSWE與POSWE的區別是相同的。TSE轉向MBSE，關鍵是設計思路的轉變，建模語言和工具從屬于設計思路的轉變。設計本身是一個思維過程、建模過程，而且是很多人（包括用戶、分析者、設計者、實現者、試驗者、維護者等）共同參與的團隊思維過程。而設計思維又和設計語言密切相關，SysML則是這種面向對象的設計語言、建模語言，同時也有一系列支持SysML的建模環境（如NoMagic公司的Cameo SystemModeler等）。

3.3.1   面向對象的系統工程的工作流程

面向對象的系統工程的思路，就是在工程系統的不同層次（例如地空導彈屬于包含了雷達、指揮控制系統、導彈在內的作戰大系統的一部分），順序地使用系統建模語言的八種圖形，即需求圖－用例圖－參數圖－塊定義圖－活動圖或順序圖－內部塊圖－狀態機圖（如圖3所示）。第一步：明確用戶對目的系統的要求，創建需求圖 。第二步：從用戶對目的系統的要求中提取出用例，創建用例圖。第三步：用參數圖表示具體的要求的指標。需求圖中定量指標，交給參數圖。第四步：確定目的系統包含哪些分系統，用塊定義圖表示。第五步：用活動圖或順序圖描述參與者和目的系統的一個完整的交互過程，把第二步所畫的用例圖具體化，變成用例場景。第六步：用內部塊圖把各個部件之間的連接關系以及各種流明確下來。第七步：對那些有狀態機行為的部件再進一步說明。

圖3   以對象為中心的設計過程與SysML圖形

完成上述7個步驟后，則完成了對要研制的對象（如地空導彈本身）的定義：包括屬性和操作兩大方面；屬性就是對象的各方面的特征，當然也是建模者、軟件開發者感興趣的、與開發活動有關的特征。操作用于修改類的屬性或執行某些動作，通常也稱為功能。然后對該對象進行進一步的分解，繼續使用上述步驟，直至得到貨架產品或預研成熟或預計能夠成熟的部件。

3.3.2   SysML的9種圖形在描述對象時的關系

系統建模語言的九種圖形，在面向對象的開發思路中發揮各自的作用，圍繞著塊定義圖來不斷完善信息。塊定義圖主要顯示工程系統的層次關系，顯示對象本身的靜態屬性、動態屬性；內部塊圖主要表示工程系統各個元素如何連接在一起，以及各個元素之間的各種物質流、能量流和信息流，各個元素的外部接口等；狀態機圖展示對象在各種刺激下的動作與狀態變化，用來檢查對象的操作是否完備；時序圖則用生命線代表相應的對象，表示對象之間的消息傳遞；參數圖以約束塊來連接有關對象的值屬性，并把對象所服從的相關物理規律、數值關系表示出來，如牛頓第二定律的相關數值關系。

3.4   從面向對象視角認識MBSE相對于TSE的優勢

MBSE的優勢實質就是OOSE的優勢，或者說MBSE的優勢表面看是因為采用了系統建模語言，更深層次是面向對象相對于面向過程的優勢。

3.4.1   便于復雜工程系統開發時的原始性創新

工程開發，比如開發飛機，必須從需求出發，目前我國飛機工業設計水平低，從第一步的需求分析時就水平低，難以準確全面理解飛機用戶的各種需求（如飛行員、空乘、各類乘客、飛機維護人員、后勤人員、機場空管、適航認證部門等），并且把這些需求傳遞到設計環節。采用MBSE方法，可以把上述各種需求的主體（如飛行員、空乘等）以及和飛機有連接和交互關系的元素都看成是對象，分析這些對象之間的各種信息和物質能量交互，以此來分析各類利益相關者對飛機的需求。

3.4.2   適宜處理軟件密集型系統，實現軟硬件的和諧開發

目前的型號研制，是先把系統的初步設計完成之后，才形成型號軟件的需求說明書，一旦軟件的開發中遇到某些不易克服的問題，則會對系統的總體方案形成巨大的沖擊。MBSE在對系統進行逐級地分塊時，并不區分軟件和硬件，直至最底層才把邏輯部件分配給相應的硬件部件、軟件部件和操作程序等，這樣有助于系統功能在軟件硬件之間的合理和優化分配，能夠獲得更加優化、平衡的系統模型。我們可以像使用UML對復雜軟件建模、編程那樣，使用SysML對整個系統（含軟件）進行“編程”、調試、優化，直至非常完善之后再發圖進行硬件生產，定下軟件部分的規格進行軟件編碼實現。

3.4.3   需求分析和設計過程的可視化

和UML用于軟件開發類似（程序員的思路可以通過他所建立的UML模型來理解，而不再是一行一行的代碼），用SysML對工程系統進行設計，這種設計思路同樣是可視化、易理解的，并且便于溝通和知識復用。

其他方面的優勢還包括：全系統仿真、需求蠕變的應對、便于研制單位的知識管理和知識復用^[11]，具體請參見《基于模型的系統工程的基本原理》一文。

4   結論

軟件工程的發展歷程啟示我們，面向對象的系統工程（OOSE）是系統工程的發展趨勢。系統工程從面向過程到面向對象，對于當前的復雜工程系統研制具有重大意義，這是戰略層次的轉變。相應在戰術層次，MBSE的具體工作流程可以五花八門，但能夠充分發揮面向對象方法學優勢的，才是好的方法。

從面向對象角度看，MBSE的重大意義在于：把人對現實世界的認知思路和人在進行工程系統研制開發時的建模思路、建模技術（語言、工具、方法）一致起來，從而解決人在認知、建模、分析、設計中的瓶頸，整體提升人對現實世界的認知水平、認知速度，并進一步提升工程系統設計和研制水平。在我國研究借鑒MBSE、SysML這些方法論、語言及相關工具時，有必要從設計思路、設計語言等層次來加深對MBSE的理解，這些相對抽象、枯燥的分析，有助于我們對MBSE原理、作用的認識，有助于我們更好地應用MBSE。

 

參考文獻（References）

[1]      邵維忠，楊芙清.面向對象的系統分析（第二版）[M]，北京：清華大學出版社，2007

[2]      姚振武. 人類語言的起源與古代漢語的語言學意義[J]. 語文研究, 2010(1):6-20.

[3]      張孝詳. Java就業培訓[M]，北京：清華大學出版社，2003

[4]      GradyBooch等著.王海鵬/潘加宇譯.面向對象分析與設計（第3版）[M]，北京：人民郵電出版社，2009

[5]      王崑聲，袁建華，陳紅濤，等．國外基于模型的系統工程方法研究與實踐［J］．中國航天，2012(11):52－60．

[6]      汪成為.面向對象分析、設計與應用[M]，北京：國防工業出版社，1992

[7]      黃志堅.工程系統概論：系統論在工程技術中的應用[M]，北京：北京大學出版社，2010，122

[8]      陳紅濤, 袁建華, 趙滟. 系統工程的昨天、今天和明天[C]// 中國系統工程學會學術年會.2014.

[9]      ALEXANDERKOSSIAKOFF. Systems Engineering Principles and Practice[M] , John Wiley &Sons,New Jersey,2012

[10]    陳紅濤, 侯俊杰, 趙滟,等. 工程系統工程的基本原理和未來發展[C]// 中國系統工程學會學術年會. 2016.

[11]    陳紅濤, 鄧昱晨, 袁建華,等. 基于模型的系統工程的基本原理[J].中國航天, 2016, 32(3):18-23..

 

文章來源：系統工程方法