傳統(tǒng)設(shè)計(jì)方法面臨困境

為滿足戰(zhàn)斗機(jī)日益增長的功能和性能要求，現(xiàn)代的任務(wù)系統(tǒng)變得越來越復(fù)雜，大量采用數(shù)字技術(shù)、網(wǎng)絡(luò)技術(shù)、計(jì)算機(jī)技術(shù)等以完成越來越多的功能。系統(tǒng)設(shè)計(jì)者將面臨著設(shè)計(jì)內(nèi)容的增加，多變的新特征，模糊的設(shè)計(jì)參數(shù)以及用戶不斷增長的需求等大量復(fù)雜性設(shè)計(jì)的挑戰(zhàn)。面對如此復(fù)雜的系統(tǒng)，系統(tǒng)設(shè)計(jì)師所采用的設(shè)計(jì)方法和設(shè)計(jì)手段將直接影響到任務(wù)系統(tǒng)的功能和效率。

目前，航空電子系統(tǒng)的設(shè)計(jì)都是采用瀑布式的結(jié)構(gòu)化設(shè)計(jì)方法，設(shè)計(jì)規(guī)范和文檔以文本形式進(jìn)行描述的，雖有規(guī)范或標(biāo)準(zhǔn)加以定義和描述，但這些規(guī)范是否完整、準(zhǔn)確地反映了用戶的需求，同時(shí)這種描述的不唯一性和不可驗(yàn)證的方法常常導(dǎo)致系統(tǒng)設(shè)計(jì)與軟件設(shè)計(jì)人員之間，以及系統(tǒng)與子系統(tǒng)設(shè)計(jì)人員之間產(chǎn)生不同的理解。運(yùn)用傳統(tǒng)的設(shè)計(jì)方法，由于對系統(tǒng)設(shè)計(jì)描述的理解不一致，或者系統(tǒng)本身的設(shè)計(jì)錯(cuò)誤往往只能在系統(tǒng)綜合和測試時(shí)才能被發(fā)現(xiàn)，隨著工程階段的深入，要修正這些錯(cuò)誤或進(jìn)行設(shè)計(jì)更改所需的人力、物力、時(shí)間開銷將成倍增加，有時(shí)甚至?xí)婕跋到y(tǒng)方案的更改，從而嚴(yán)重影響系統(tǒng)的開發(fā)進(jìn)度。

采用圖形化的統(tǒng)一建模語言（UML）和系統(tǒng)建模語言（SysML）進(jìn)行的基于模型驅(qū)動(dòng)的開發(fā)方法提供了一種全新的迭代式系統(tǒng)設(shè)計(jì)流程，它允許用戶創(chuàng)建一個(gè)可視化的、圖形化的系統(tǒng)模型，清晰、準(zhǔn)確地反映指定系統(tǒng)預(yù)期的功能和行為，通過模型執(zhí)行進(jìn)行早期的、頻繁的需求驗(yàn)證和確認(rèn)，找到由于需求不明確而造成的代價(jià)高昂的錯(cuò)誤，并盡早地在設(shè)計(jì)階段中加以改正，確保所設(shè)計(jì)的系統(tǒng)是正確的、完整的和無二義性的。

基于統(tǒng)一建模語言（UML）和系統(tǒng)建模語言（SysML）的設(shè)計(jì)工具包括：SCAD、TAO和HarmonySE等多種如軟件，本文以HarmonySE為例對基于模型設(shè)計(jì)方法進(jìn)行描述

系統(tǒng)開發(fā)的生命周期模型

我們通常將系統(tǒng)的開發(fā)過程分為幾個(gè)階段，每個(gè)階段都包含需由工程設(shè)計(jì)小組完成的相關(guān)的過程及任務(wù)。有許多不同的生命周期模型來描述這種開發(fā)過程，比如螺旋式、瀑布式、“V”型設(shè)計(jì)方法等，這些流程都包含了從最初需求分析到最后具體實(shí)現(xiàn)的整個(gè)系統(tǒng)設(shè)計(jì)過程。著名的瀑布式生命周期模型將系統(tǒng)開發(fā)分為需求分析與規(guī)范、設(shè)計(jì)、實(shí)現(xiàn)、測試與維護(hù)等幾個(gè)階段，在過去的二十幾年間，這種開發(fā)模型圍繞著建模、可重用軟件代碼、自動(dòng)化綜合等出現(xiàn)了各種變化。目前基于模型驅(qū)動(dòng)的“V”型設(shè)計(jì)方法在系統(tǒng)或產(chǎn)品開發(fā)過程中已逐漸被接受和應(yīng)用。

“V”型設(shè)計(jì)方法包含了從自頂向下的系統(tǒng)設(shè)計(jì)到自下而上的系統(tǒng)綜合的全過程，覆蓋了任務(wù)系統(tǒng)開發(fā)的各個(gè)階段。

“V”型設(shè)計(jì)過程（如圖1所示）中，左邊一側(cè)對應(yīng)于系統(tǒng)設(shè)計(jì)自頂向下的分析過程，右邊一側(cè)對應(yīng)于系統(tǒng)驗(yàn)收測試自底向上的綜合過程。系統(tǒng)分析過程包含系統(tǒng)需求分析、系統(tǒng)功能分析、系統(tǒng)設(shè)計(jì)綜合和軟件/硬件分析、設(shè)計(jì)及實(shí)現(xiàn)等幾個(gè)連續(xù)的階段。其中系統(tǒng)工程的工作流是一個(gè)周期的迭代過程，并貫穿了需求分析、系統(tǒng)功能分析和設(shè)計(jì)綜合三個(gè)階段，這個(gè)過程在HarmonySE系統(tǒng)設(shè)計(jì)方法中是基于用例（Use Case）來實(shí)現(xiàn)的。

在設(shè)計(jì)過程的早期階段，我們并不關(guān)心系統(tǒng)的具體實(shí)現(xiàn)，主要是收集用戶對系統(tǒng)的需求，根據(jù)這些需求進(jìn)行歸納整理，轉(zhuǎn)換為系統(tǒng)的計(jì)劃和觀點(diǎn)（即系統(tǒng)需求），然后將這些需求明確地?cái)⑹龀梢?guī)范（即系統(tǒng)規(guī)范），我們只是關(guān)心系統(tǒng)需要做什么，需要完成什么。功能分解將規(guī)范中的系統(tǒng)需求表達(dá)成系統(tǒng)設(shè)計(jì)的抽象實(shí)體，實(shí)際上，功能分解的過程就是描述如何去實(shí)現(xiàn)這些功能。在系統(tǒng)設(shè)計(jì)階段，我們將精力集中到系統(tǒng)的實(shí)時(shí)限制以及各種功能完成的先后順序，我們?nèi)匀徊粫P(guān)心采用什么樣的處理器或可用到的存儲器等。在軟件/硬件分析、設(shè)計(jì)及實(shí)現(xiàn)階段，我們才關(guān)心諸如操作系統(tǒng)、處理器、內(nèi)存等最終的具體實(shí)現(xiàn)。這四個(gè)步驟帶給我們的是從概念化的系統(tǒng)到真正的產(chǎn)品。

在“V”型設(shè)計(jì)的系統(tǒng)綜合過程中，包含了從軟件/硬件的單元測試，到模塊綜合與測試，再到子系統(tǒng)綜合與測試，最終到系統(tǒng)驗(yàn)收測試。這個(gè)過程體現(xiàn)了“V”型設(shè)計(jì)中最重要的一點(diǎn)，即在系統(tǒng)分析/設(shè)計(jì)的每一個(gè)階段，都必須為今后的綜合和驗(yàn)收測試定義測試場景，并進(jìn)行測試定義。

系統(tǒng)需求捕獲和分析

系統(tǒng)需求捕獲和分析是任務(wù)系統(tǒng)設(shè)計(jì)的第一步，充分理解設(shè)計(jì)需求是進(jìn)行正確設(shè)計(jì)的重要基礎(chǔ)。經(jīng)過認(rèn)真分析飛機(jī)的戰(zhàn)技指標(biāo)要求，并與用戶進(jìn)行充分交流的基礎(chǔ)上，確定任務(wù)系統(tǒng)的使命，明確任務(wù)系統(tǒng)的主要功能性能，將用戶需求轉(zhuǎn)化為系統(tǒng)需求。系統(tǒng)需求是用戶需求的解決方案，是把能力觀點(diǎn)轉(zhuǎn)化為以方案為基礎(chǔ)的觀點(diǎn)。系統(tǒng)需求包括功能性需求和非功能性需求兩個(gè)方面，功能需求是外部可觀察到的系統(tǒng)的預(yù)期行為，非功能需求包括性能、可靠性、安全性、設(shè)計(jì)約束條件等特性。為了保證可追溯性，將建立系統(tǒng)需求與用戶需求之間相應(yīng)的可追溯性鏈接關(guān)系。

需求分析過程將明確任務(wù)系統(tǒng)與電源、環(huán)控、座艙、起落架、機(jī)電等飛機(jī)系統(tǒng)以及與飛控系統(tǒng)、武器、操作者、地面站、體系外成員等之間的接口，確定任務(wù)系統(tǒng)的主要輸入和輸出。在任務(wù)系統(tǒng)需求分析階段，飛行員操作程序（POP）將是任務(wù)系統(tǒng)設(shè)計(jì)的一個(gè)主要需求，它需要對座艙人機(jī)接口設(shè)備的功能、信息顯示和控制操作邏輯等進(jìn)行了定義。

系統(tǒng)需求定義完成后，下一個(gè)重要步驟則是根據(jù)系統(tǒng)需求，將系統(tǒng)的功能需求進(jìn)行分組，確定系統(tǒng)用例。HarmonySE系統(tǒng)設(shè)計(jì)方法以用例圖（Use Case Diagram）捕捉系統(tǒng)的需求，它以圖形化的方式表示系統(tǒng)內(nèi)部的一系列用例，它以一種技術(shù)人員和非技術(shù)人員都容易理解的方式來描述系統(tǒng)在功能上的特殊需求。每個(gè)系統(tǒng)用例描述了任務(wù)系統(tǒng)其中一個(gè)特定的系統(tǒng)操作流程，定義了由參與者感知到的行為以及參與者與用例之間的信息流。參與者可能是一個(gè)人、另一個(gè)系統(tǒng)或者是正在開發(fā)的系統(tǒng)外部的一個(gè)硬件。一旦系統(tǒng)級用例被確定，以及所有的功能性需求和相關(guān)的性能需求都被用例所覆蓋且都被確認(rèn)后，需要根據(jù)對系統(tǒng)架構(gòu)定義的重要度對系統(tǒng)用例進(jìn)行排序和分類，從而確定系統(tǒng)工程增量式迭代工作流的順序，經(jīng)過每輪設(shè)計(jì)迭代后，用例實(shí)現(xiàn)的優(yōu)先級也許會發(fā)生變化。

系統(tǒng)用例應(yīng)該分層次進(jìn)行構(gòu)架，遵循模塊化、自頂向下和易于修改的原則是合理可靠的。首先從頂層系統(tǒng)用例開始，采用結(jié)構(gòu)化的設(shè)計(jì)方法給出對整個(gè)任務(wù)系統(tǒng)的一般定義，然后分解成第一層的用例，每一個(gè)第一層的用例又被分解成再下一個(gè)層次的用例，直到最底層。為了達(dá)到易于理解的要求，在用例分層的過程中，應(yīng)遵循信息隱藏和解耦的原則，每下一層的用例都將包含比上一層用例更詳細(xì)的功能，每個(gè)用例的描述不應(yīng)含有其下一層用例描述的細(xì)節(jié)，并應(yīng)隱含那些不會影響同一層其他用例和上一層用例的信息，同一層用例描述的詳細(xì)程度也應(yīng)是一致的。易于修改可通過檢查用例結(jié)構(gòu)的穩(wěn)定性來驗(yàn)證，如果刪除任何用例，僅影響要?jiǎng)h除的用例和它所有的子用例的功能分配，而不需要對其余的用例所包含的功能做任何修改；修改功能應(yīng)當(dāng)僅影響含有該功能的用例和子用例；增加功能可用增加一個(gè)新的用例或在現(xiàn)有的用例中增加功能的方法，而不必改變現(xiàn)存的用例架構(gòu)。

需求分析階段的模型包含需求模型和系統(tǒng)用例模型。需求模型將需求分類直觀化，系統(tǒng)用例模型將需求分組到系統(tǒng)用例當(dāng)中，這些模型是不可執(zhí)行的。

系統(tǒng)功能分析過程

當(dāng)系統(tǒng)的需求明確以后，就明確了系統(tǒng)所要完成的任務(wù)和主要功能，為使我們能夠理解、描述和設(shè)計(jì)這個(gè)復(fù)雜的系統(tǒng)，需要將這些系統(tǒng)功能分解成具有層次結(jié)構(gòu)的更簡單部分，由此引出任務(wù)系統(tǒng)的功能分析過程。

在這個(gè)階段，整個(gè)任務(wù)系統(tǒng)仍然是作為飛機(jī)的一個(gè)功能模塊來考慮，即把任務(wù)系統(tǒng)當(dāng)做一個(gè)黑盒。功能分析階段的主要目的是將系統(tǒng)的功能性需求轉(zhuǎn)化為對系統(tǒng)功能或行為的一致性描述，這個(gè)分析過程是基于在需求分析階段所確定的用例，每個(gè)用例將被轉(zhuǎn)化為一個(gè)可執(zhí)行的模型。

功能分析過程中，通過黑盒活動(dòng)圖、順序圖和狀態(tài)圖對系統(tǒng)的功能和行為進(jìn)行描述，每個(gè)圖在描述用例行為的過程中都起到不同的作用?；顒?dòng)圖描述了用例所有的功能流，將所有的功能需求以行為/操作的方式進(jìn)行分組，并展示這些活動(dòng)是如何相互連接的；順序圖描述了一個(gè)特定的用例路徑，并定義了在操作和參與者之間的信息流。狀態(tài)圖集合了功能流和參與者相互之間行為的信息，將這些信息加入到系統(tǒng)狀態(tài)的內(nèi)容中，并根據(jù)外部不同優(yōu)先級別的觸發(fā)條件加入系統(tǒng)行為。因?yàn)闋顟B(tài)圖是用標(biāo)準(zhǔn)的語法規(guī)范進(jìn)行定義的，因此最終系統(tǒng)行為的正確性和完整性可以通過模型執(zhí)行來進(jìn)行驗(yàn)證。

根據(jù)功能分析過程中建立的黑盒用例場景，通過模型的執(zhí)行來對相關(guān)過程進(jìn)行分析，主要目的在于驗(yàn)證生成的順序是否滿足要求，而并非驗(yàn)證用例所包含的功能本身。一旦用例模型和其包含的功能需求被驗(yàn)證后，可能需要進(jìn)行“雨天”場景分析，專注于確定在初始需求分析階段未覆蓋到的系統(tǒng)故障或失效的場景。

如果在建模過程中確定了有新的或衍生出來的需求，那系統(tǒng)需求規(guī)范也需要進(jìn)行相應(yīng)的更新，并納入需求管理體系。

最終，系統(tǒng)功能分析過程的成果是生成帶基線的系統(tǒng)需求規(guī)范以及系統(tǒng)級的邏輯接口控制文件，定義系統(tǒng)與參與者之間的功能和邏輯接口。

系統(tǒng)的設(shè)計(jì)綜合過程

在系統(tǒng)需求分析和功能分析階段，任務(wù)系統(tǒng)都是被當(dāng)做一個(gè)黑盒來處理，所有的行為都是系統(tǒng)的行為，未涉及系統(tǒng)內(nèi)部的組成和架構(gòu)以及系統(tǒng)中每個(gè)子系統(tǒng)應(yīng)完成的功能和它們之間的交互關(guān)系，在設(shè)計(jì)綜合過程中將解決這些問題。在系統(tǒng)設(shè)計(jì)綜合過程，系統(tǒng)進(jìn)入白盒設(shè)計(jì)階段，工作的重心在于將系統(tǒng)的功能性需求和非功能性需求分配至一個(gè)確定的系統(tǒng)架構(gòu)中，該架構(gòu)可以在指定的性能限制約束下完成所需的功能，這個(gè)過程包括了架構(gòu)分析、架構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)三個(gè)方面的內(nèi)容。

在系統(tǒng)功能分析過程中定義了系統(tǒng)要做什么，但并沒有確定怎么去做。架構(gòu)分析的目標(biāo)就是確定在合理的范圍內(nèi)達(dá)到某個(gè)特定功能和能力的最佳方法。在架構(gòu)分析過程中，首先定義關(guān)鍵的系統(tǒng)功能，確定候選的解決方案，明確評估標(biāo)準(zhǔn)和權(quán)重，將這些標(biāo)準(zhǔn)和權(quán)重分配給候選的解決方案，經(jīng)過分析比較和論證，權(quán)衡各方面的因素，確定解決方案。當(dāng)所有的關(guān)鍵功能的解決方案都確定后，對這些解決方案進(jìn)行合并，確定滿足系統(tǒng)功能和能力的最佳的系統(tǒng)架構(gòu)。

架構(gòu)設(shè)計(jì)過程是將系統(tǒng)功能分析過程中所定義的功能和行為分配至系統(tǒng)架構(gòu)中的相關(guān)的功能子系統(tǒng)里，這個(gè)架構(gòu)可以是根據(jù)前面架構(gòu)分析得到結(jié)果，也可能是一個(gè)給定的系統(tǒng)架構(gòu)。這個(gè)功能和行為分配的過程是個(gè)迭代的過程，一般與各領(lǐng)域?qū)＜覅f(xié)作完成，可能存在很多不同的分配策略，不同的策略可能考慮不同的設(shè)計(jì)限制，例如在需求分析階段所獲取的性能和安全性需求。

詳細(xì)設(shè)計(jì)階段的重心在于定義端口與接口，以及在系統(tǒng)最底層架構(gòu)中每個(gè)功能子系統(tǒng)基于狀態(tài)的行為。在這個(gè)階段，活動(dòng)圖將產(chǎn)生“泳道”，用來將系統(tǒng)的行為操作劃分到子系統(tǒng)中，每個(gè)泳道代表任務(wù)系統(tǒng)下的一個(gè)子系統(tǒng)。順序圖也會根據(jù)新的活動(dòng)圖產(chǎn)生，描述某個(gè)場景下任務(wù)系統(tǒng)所包含的子系統(tǒng)的信息交互。設(shè)計(jì)綜合階段的狀態(tài)圖，也不再是針對整個(gè)任務(wù)系統(tǒng)的狀態(tài)，而是針對子系統(tǒng)的狀態(tài)表述。

HarmonySE系統(tǒng)設(shè)計(jì)方法中用結(jié)構(gòu)圖（Structure Diagram）來表述系統(tǒng)層級關(guān)系及接口，包括用塊定義圖（Block Definition Diagram）來描述任務(wù)系統(tǒng)與其包含的子系統(tǒng)之間的關(guān)系，用內(nèi)部塊圖（Internal Block Diagram）來詳細(xì)定義任務(wù)系統(tǒng)內(nèi)部子系統(tǒng)之間的接口關(guān)系，即ICD。

系統(tǒng)設(shè)計(jì)模型的一個(gè)非常自然的預(yù)期讀者就是軟件工程師，同時(shí)也是系統(tǒng)設(shè)計(jì)產(chǎn)物的交付對象之一。對于軟件工程師而言，結(jié)構(gòu)圖形象化地表述了他們所熟悉的子程序：層次結(jié)構(gòu)、輸入數(shù)據(jù)和輸出數(shù)據(jù)等。

模型的驗(yàn)證和確認(rèn)以及文檔生成

“V”型設(shè)計(jì)的一個(gè)特性是當(dāng)我們沿“V”過程的左邊向下進(jìn)行過程中，每一階段都必須定義今后系統(tǒng)綜合中使用的各種測試。按照我們的分析過程，這意味著在系統(tǒng)層次結(jié)構(gòu)的每一層，在進(jìn)入下一層之前，該層的模型必須經(jīng)過驗(yàn)證和確認(rèn)。

HarmonySE的模型不僅僅只是一個(gè)靜態(tài)圖，它是一個(gè)能進(jìn)行仿真并生成代碼的正式模型。進(jìn)行仿真時(shí)，仿真器對設(shè)計(jì)圖中處于激活狀態(tài)行為和功能加亮顯示，以此為設(shè)計(jì)者提供反饋。仿真時(shí)的一個(gè)重要工具是人機(jī)交互面板，用于驅(qū)動(dòng)或控制模擬過程，可以非常直觀地顯示仿真結(jié)果。此外，仿真器環(huán)境提供了所有傳統(tǒng)的調(diào)試裝置，如波形、監(jiān)視器和調(diào)試窗口等。這樣，系統(tǒng)設(shè)計(jì)者就能夠分析確定系統(tǒng)運(yùn)行是否正確，并獲得測試數(shù)據(jù)，這些數(shù)據(jù)將用于以后系統(tǒng)綜合和驗(yàn)收時(shí)的測試。在驗(yàn)證過程中，各種激勵(lì)和響應(yīng)能被記錄下來，這提供了用于綜合的按照輸入和期望輸出之間的關(guān)系所確定的測試用例定義。

任務(wù)系統(tǒng)的設(shè)計(jì)最終要變成設(shè)計(jì)文檔并連同設(shè)計(jì)模型一起提交給下一級軟件開發(fā)和子系統(tǒng)承制單位，最終變成嵌入式系統(tǒng)的可執(zhí)行代碼。HarmonySE的文檔生成工具能自動(dòng)摘錄包括圖形和文字在內(nèi)的所有模型數(shù)據(jù)，然后輸出成為標(biāo)準(zhǔn)的或用戶自定義的文檔，便于整理和歸類，這些文檔將作為子系統(tǒng)設(shè)計(jì)者和軟件設(shè)計(jì)工程師的主要的參考文件。

結(jié)束語

采用面向用戶需求的基于“V”型設(shè)計(jì)方法提供了一種全新的迭代式系統(tǒng)設(shè)計(jì)流程，以建模語言為核心的圖形化行為建模技術(shù)和快速原型生成技術(shù)，使系統(tǒng)設(shè)計(jì)工程師能夠在設(shè)計(jì)過程中實(shí)現(xiàn)對系統(tǒng)的功能要求、行為方式、控制方式等進(jìn)行可視化的調(diào)試和驗(yàn)證，及時(shí)發(fā)現(xiàn)并糾正錯(cuò)誤，避免在系統(tǒng)綜合和測試階段才發(fā)現(xiàn)上述問題，從而大大提高系統(tǒng)的設(shè)計(jì)效率，降低系統(tǒng)的開發(fā)和維護(hù)費(fèi)用。這種系統(tǒng)設(shè)計(jì)方法現(xiàn)已在美國和歐洲的高科技和軍事/航空領(lǐng)域中得到廣泛應(yīng)用。