模型驅(qū)動的雷達信號處理系統(tǒng)軟件開發(fā)

李路野 程知敬

摘要

以雷達信號處理系統(tǒng)為研究背景，提出了一種模型驅(qū)動的軟件開發(fā)流程，該方法采用模型驅(qū)動架構(gòu)思想，基于系統(tǒng)建模語言（SysML，SystemsModelingLanguage）構(gòu)造需求工程、概要設(shè)計、詳細設(shè)計、軟件實現(xiàn)和軟件測試等各個階段的模型，并闡述了軟件開發(fā)流程中各主要模型輸出物之間的關(guān)聯(lián)關(guān)系。

【關(guān)鍵詞】模型驅(qū)動 軟件開發(fā) 雷達信號處理

1 引言

傳統(tǒng)的信號處理系統(tǒng)軟件開發(fā)以編碼為中心，在需求分析與設(shè)計初期通常采用文檔進行描述。當(dāng)編碼開始時，這些文檔只能起到一些輔助或約束作用，并且隨著項目推進，開發(fā)人員所編寫的代碼與文檔之間的同步性變得越來越弱，甚至沒有關(guān)聯(lián)。

基于模型的軟件開發(fā)，其核心思想是將模型作為軟件開發(fā)過程中的主要產(chǎn)物，而將自動模型轉(zhuǎn)換作為軟件開發(fā)過程中不同階段產(chǎn)物生成的主要手段。模型對待開發(fā)的目標(biāo)系統(tǒng)從不同角度進行高層次的抽象描述，從而使業(yè)務(wù)邏輯與具體軟件實現(xiàn)相分離，這極大提高了軟件開發(fā)的生產(chǎn)力，降低了溝通和變更成本，因此，已逐漸成為軟件開發(fā)的一種主流方法。

2 國內(nèi)外研究現(xiàn)狀

2014年，對象管理組織提出的模型驅(qū)動架構(gòu)2.0（MDA，ModelDrivenArchitecture），是一種指導(dǎo)軟件開發(fā)的方法和思想，支持軟件設(shè)計和模型的可視化、存儲和轉(zhuǎn)換。MDA的核心是模型，因此需要有相應(yīng)的建模語言來支撐其建模和驗證。統(tǒng)一建模語言（UML，Unified Modeling Language）由于其具有極好的擴展性和開放性，在軟件工程領(lǐng)域取得了較大的成功。國際系統(tǒng)工程學(xué)會和對象管理組織UML2.0的基礎(chǔ)上進行重用和面向系統(tǒng)工程的擴展，定義了一種新的系統(tǒng)建模語言標(biāo)準(zhǔn)SysML。

MDA的核心技術(shù)之一是模型轉(zhuǎn)換，是一種將某個模型轉(zhuǎn)換到系統(tǒng)中另一個模型的過程。模型轉(zhuǎn)換的方法有很多，比如基于規(guī)則的模型轉(zhuǎn)換、基于模板的代碼生成技術(shù)、基于元模型間映射的模型轉(zhuǎn)換、基于模式的模型轉(zhuǎn)換等。ATLAS轉(zhuǎn)換語言（ATL，ATLASTransformationLanguage）是一種基于規(guī)則的模型轉(zhuǎn)換語言，既有描述性語言的特征，又含有命令式語言的內(nèi)容。

3 模型驅(qū)動的雷達信號處理軟件開發(fā)流程

參考模型驅(qū)動軟件工程研究與應(yīng)用領(lǐng)域的前沿思想和方法，并結(jié)合雷達信號處理系統(tǒng)軟件開發(fā)的實際情況，將基于模型的軟件開發(fā)流程劃分為需求工程、概要設(shè)計、詳細設(shè)計、軟件實現(xiàn)以及軟件測試五個階段，其流程順序及相關(guān)產(chǎn)物如圖1所示。以下對各階段進行詳細說明。

3.1 需求工程

需求工程主要包括需求開發(fā)與需求管理兩部分，其中需求開發(fā)主要為了確定最初的需求基線，需求管理主要面向需求的變更及其傳播。在此，我們主要討論需求開發(fā)相關(guān)步驟，其又細分為需求獲取、需求分析、需求建模、需求確認(rèn)與驗證四個階段，如圖2所示。由于模型驅(qū)動架構(gòu)最主要的功能是將軟件工程過程中的產(chǎn)物以模型來表示，并以模型轉(zhuǎn)換為手段驅(qū)動整個開發(fā)過程的開展，因此，圖2同時展示了各階段設(shè)計產(chǎn)物及其之間的關(guān)系。

3.1.1 需求獲取

需求獲取主要是通過調(diào)研獲得清晰、準(zhǔn)確的客戶需求，這些需求既包括來自于企業(yè)外部的需求，也包括來自于企業(yè)內(nèi)部各部門的需求;需求的種類包括功能需求、性能需求、環(huán)境需求、可靠性、安全性等多個方面。

需求獲取的方法主要以問卷、面談等直接交流的方式獲得，其結(jié)果可以以條目化文本的方式進行呈現(xiàn)，并使用需求管理工具進行創(chuàng)建與管理。在創(chuàng)建和管理需求時，我們需要為條目化需求指定唯一的編號，并指定需求之間的層級、追蹤等關(guān)系，并及時更新需求的狀態(tài)，如已評審、已設(shè)計、己實現(xiàn)等。

3.1.2 需求分析

需求分析主要是對從需求獲取階段收集而來的用戶需求進行提煉、分析和審查，形成工程人員可理解的系統(tǒng)需求。

對于面向過程的軟件系統(tǒng)來說，結(jié)構(gòu)化分析是當(dāng)前軟件開發(fā)方法中最成熟、應(yīng)用最廣泛的需求分析方法之一。其基本思想是“分解”和“抽象”：通過自頂向下的分解逐漸對系統(tǒng)進行求精，通過抽象來明確系統(tǒng)最本質(zhì)的屬性，從而反映“做什么”的功能。

結(jié)構(gòu)化分析可以借助于數(shù)據(jù)流圖、控制流圖、狀態(tài)轉(zhuǎn)換圖等工具分析軟件的處理流程，借助于實體關(guān)系圖、數(shù)據(jù)字典等分析軟件使用或產(chǎn)生的所有數(shù)據(jù)對象及其之間的關(guān)系。

3.1.3 需求建模

需求建模主要是對需求分析過程中產(chǎn)生的層次化的系統(tǒng)需求用形式化、無二義的模型進行表達。SysML提供了豐富的、可擴展的建模元素，可視化的模型展示，并通過建模工具保證模型間的一致性，從而便于系統(tǒng)的表達、呈現(xiàn)和維護，也是自動化分析與設(shè)計的基礎(chǔ)。因此，需求模型既可以記錄需求，也可以輔助需求分析。

在SysML的多種圖中，我們可以采用以下圖對需求的各個方面進行描述：

（1）需求圖：它是條目化需求的可視化表示，可以清晰展示需求以及需求與項目中其他產(chǎn)物之間的關(guān)系。

（2）用例圖：描述了系統(tǒng)的各種使用場景以及系統(tǒng)在使用過程中與外部參與者之間的交互。

（3）順序圖：描述系統(tǒng)在完成某一用例過程中與外部參與者之間的交互序列。

（4）活動圖：描述系統(tǒng)完成某一用例的基本流程。

（5）塊定義圖：對系統(tǒng)所涉及到的數(shù)據(jù)進行建模。

3.1.4 需求確認(rèn)與驗證

需求確認(rèn)主要是確保系統(tǒng)需求以及需求模型正確記錄和反映了用戶的實際需求。這通常需要用戶或代表用戶的內(nèi)部人員參與，主要是為了確保需求正確描述了系統(tǒng)應(yīng)該實現(xiàn)的任務(wù)，并且完整記錄了系統(tǒng)應(yīng)該實現(xiàn)的所有任務(wù)。

對需求模型自身的正確性的檢查可以采用靜態(tài)模型驗證或動態(tài)仿真的方式來完成。靜態(tài)模型驗證采用形式化的模型檢查手段和工具，檢查需求模型本身的邏輯是否存在問題;動態(tài)仿真通常需要將需求模型轉(zhuǎn)換為某一可執(zhí)行的仿真模型（例如雷達信號處理系統(tǒng)仿真常用的Matlab數(shù)字樣機），通過觀察仿真的執(zhí)行過程和結(jié)果來檢查需求。

需求的驗證主要是驗證己實現(xiàn)的軟件系統(tǒng)是否符合系統(tǒng)需求。該活動貫穿整個軟件系統(tǒng)生命過程，在每個設(shè)計階段完成后，其設(shè)計產(chǎn)物模型都需要與需求模型進行對比，以保證其與需求的一致性。與需求確認(rèn)類似，它也可以采用靜態(tài)或動態(tài)兩種方式來完成。

3.2 概要設(shè)計

概要設(shè)計的目的是以需求工程所產(chǎn)生的需求模型為出發(fā)點，將系統(tǒng)劃分為獨立的小粒度模塊，從而將這些模塊交付給不同的團隊進行實現(xiàn)。如圖3所示，它可以分為數(shù)據(jù)設(shè)計、架構(gòu)設(shè)計、接口設(shè)計以及架構(gòu)評估幾個方面。

3.2.1 數(shù)據(jù)設(shè)計

數(shù)據(jù)設(shè)計主要是將需求分析階段產(chǎn)生的數(shù)據(jù)信息轉(zhuǎn)化為軟件實現(xiàn)所需的數(shù)據(jù)結(jié)構(gòu)。我們可以采用SysML塊定義圖對這些數(shù)據(jù)結(jié)構(gòu)進行建模。塊定義圖中的最主要的建模元素為塊（Block），它可以具有子塊、值屬性、端口等豐富的屬性描述，從而對數(shù)據(jù)從多個方面進行刻畫。

3.2.2 架構(gòu)設(shè)計

架構(gòu)設(shè)計主要是將需求分析中識別到的功能分配給相應(yīng)的軟件模塊進行實現(xiàn)。軟件模塊在SysML中可以采用塊（Block）進行定義。Block是一種面向?qū)ο蟮哪Ｐ驮?，具有封裝性和繼承性，Block之間存在包含、繼承、引用等多種關(guān)系，從而形成層次化的系統(tǒng)架構(gòu)模型。

功能的表達通常采用活動圖來描述，因此，架構(gòu)設(shè)計的結(jié)果便是將活動圖中表示的功能分配給軟件系統(tǒng)中代表軟件模塊的Block。

3.2.3 接口設(shè)計

接口設(shè)計主要是設(shè)計軟件模塊之間以及軟件與外部環(huán)境之間的交互。在SysML中，接口可以被建模為軟件模塊的端口（Port）。軟件模塊之間的靜態(tài)連接關(guān)系可以通過內(nèi)部塊圖（IBD）來表示。此外，軟件模塊之間通過接口實現(xiàn)的動態(tài)通信可以通過順序圖來描述。

需求模型中的活動圖和順序圖中可以提取部分模塊交互模型。

3.2.4 架構(gòu)評估

軟件架構(gòu)設(shè)計的結(jié)果往往不是唯一的，同一個功能可能會有多種不同的解決方案，從而產(chǎn)生多種不同的模塊設(shè)計方案。對這些架構(gòu)方案的評估可以從模塊的內(nèi)聚性、模塊間的耦合性、模塊數(shù)量、模塊規(guī)模、數(shù)據(jù)結(jié)構(gòu)復(fù)雜度以及一些已知的性能參數(shù)等方面進行綜合評估，進而確定少數(shù)幾個可行架構(gòu)方案作為詳細設(shè)計的輸入。

3.3 詳細設(shè)計

詳細設(shè)計主要是對模塊內(nèi)部邏輯和結(jié)構(gòu)進行設(shè)計，從而確定完成每個模塊功能所需的算法和數(shù)據(jù)結(jié)構(gòu)。

由于軟件概要設(shè)計產(chǎn)生的模型為平臺無關(guān)模型（Platform Independent Model），即與具體開發(fā)語言無關(guān)的模型，因此，在詳細設(shè)計開始之前，我們首先需要確定開發(fā)所使用的語言。對于本企業(yè)來說，C語言即為所選定的開發(fā)平臺。由于該平臺為面向過程的編程語言，因此，其詳細設(shè)計主要包括數(shù)據(jù)結(jié)構(gòu)設(shè)計、模塊行為設(shè)計和模塊接口設(shè)計三部分內(nèi)容，如圖4所示。

3.3.1 模塊數(shù)據(jù)設(shè)計

模塊數(shù)據(jù)設(shè)計主要是對概要設(shè)計中產(chǎn)生的數(shù)據(jù)結(jié)構(gòu)進行進一步細化，為編程做好充分準(zhǔn)備。這些數(shù)據(jù)結(jié)構(gòu)可以采用SysML中的塊定義圖進行建模。它可以從概要設(shè)計中的數(shù)據(jù)模型部分生成。

3.3.2 模塊行為設(shè)計

模塊行為設(shè)計主要是為了每個模塊確定其核心算法，從而設(shè)計出模塊的詳細的過程性描述。模塊的行為設(shè)計結(jié)果可以采用SysML中的活動圖或狀態(tài)機圖進行描述?；顒訄D主要展示了模塊對于輸入的處理流程，狀態(tài)機圖展示了模塊對于外部事件的響應(yīng)。模塊的行為模型可以從概要設(shè)計模型部分自動提取。

3.3.3 模塊接口設(shè)計

模塊接口設(shè)計主要是對模塊的接口的細節(jié)進行確定，包括輸入數(shù)據(jù)、輸出數(shù)據(jù)、接口參數(shù)類型等。接口可以采用SysML中的Port進行表示，它是數(shù)據(jù)流入流出的端口。其上可流動的數(shù)據(jù)類型可以通過Port的類型來描述。模塊的接口模型可以從概要設(shè)計中的接口設(shè)計部分提取。

3.4 軟件實現(xiàn)

軟件實現(xiàn)主要是在詳細設(shè)計的基礎(chǔ)上，對軟件進行編碼實現(xiàn)。

3.4.1 代碼生成

基于選定開發(fā)語言的特性，我們可以從軟件設(shè)計模型自動生成部分軟件實現(xiàn)代碼。通常，SysML的Block可以生成軟件模塊的靜態(tài)結(jié)構(gòu)定義，而活動圖和狀態(tài)機圖可以生成軟件模塊的內(nèi)部算法代碼。如果軟件設(shè)計模型中的模塊已經(jīng)有對應(yīng)的C語言模塊來實現(xiàn)，則直接調(diào)用該模塊即可。

3.4.2 軟件編碼

代碼生成通常只能產(chǎn)生軟件程序框架，開發(fā)人員還需編寫代碼以實現(xiàn)完整的可運行的軟件系統(tǒng)。

3.5 軟件測試

嚴(yán)格來講，軟件測試活動應(yīng)當(dāng)貫穿整個開發(fā)過程始終，在任何開發(fā)產(chǎn)物生成后，都應(yīng)當(dāng)開展軟件測試活動從而確保產(chǎn)物的正確性。軟件測試包括以下4個方面：

（1）單元測試：測試某個代碼塊的正確性

（2）集成測試：測試幾個有連接關(guān)系的模塊集成在一起工作時的正確性。

（3）系統(tǒng)測試：對整個系統(tǒng)進行端到端的測試，從而確保整個系統(tǒng)的正確性。

（4）驗收測試：確定最終完成的系統(tǒng)滿足用戶的最終需求。

建模語言以及模型驅(qū)動開發(fā)對軟件測試可提供的支持體現(xiàn)在對測試用例及其流程進行模型化描述，從需求模型或設(shè)計模型自動提取測試用例模型等方面。

4 總結(jié)

上述章節(jié)主要以開發(fā)過程為主線，展示了模型驅(qū)動的軟件開發(fā)流程。由于模型驅(qū)動架構(gòu)的核心是模型以及模型之間的轉(zhuǎn)換關(guān)系，因此，本部分以模型為主線，對開發(fā)各階段所產(chǎn)生的模型及其之間的關(guān)系進行總結(jié)。圖5展示了整個基于模型的軟件開發(fā)流程中的主要模型產(chǎn)物及其之間的關(guān)系。

（1）在這些模型中，需求模型是整個流程的起點，也是聯(lián)系各種模型的核心，它由需求分析人員通過分析，基于模板庫中的需求模塊手動建立。

（2）由于需求模型與Matlab數(shù)字樣化機中的模塊存在較為直接的對應(yīng)關(guān)系，因此，可以由需求模型自動轉(zhuǎn)換生成Matlab仿真模型，用于對需求模型進行正確性和完整性的確認(rèn)。需求模型的建立與Matlab數(shù)字樣機的生成，均屬于需求工程階段的范疇。

（3）平臺無關(guān)的概要設(shè)計模型可以從需求模型部分轉(zhuǎn)換而來，設(shè)計人員可以在自動生成的設(shè)計模型的基礎(chǔ)上開展進一步設(shè)計。這些工作在概要設(shè)計階段完成。

（4）基于模型轉(zhuǎn)換或模塊檢索機制，可以從概要設(shè)計模型自動生成基于C語言的平臺相關(guān)詳細設(shè)計模型。設(shè)計開發(fā)人員對該詳細設(shè)計模型進行完善和補充，并在此基礎(chǔ)上自動生成C語言代碼。這部分工作對應(yīng)于軟件開發(fā)流程中的詳細設(shè)計和軟件實現(xiàn)部分。

（5）從需求模型可以提取部分測試用例模型，并基于此生成測試用例，從而服務(wù)于軟件測試階段的完成。

上述模型生成主要通過模型轉(zhuǎn)換機制實現(xiàn)，該機制的核心思想是在模型之間建立單向或雙向的映射關(guān)系。因此，模型轉(zhuǎn)換實質(zhì)上建立了模型之間的對應(yīng)關(guān)系，基于這種對應(yīng)關(guān)系，可以實現(xiàn)相關(guān)模型之間的變動傳遞和維護。由于模型直接對應(yīng)于開發(fā)的最終產(chǎn)物，例如需求模型對應(yīng)于Matlab數(shù)字樣機，C語言平臺詳細設(shè)計模型對應(yīng)于C語言代碼，測試用例模型對應(yīng)于測試用例，因此，模型的變動也可以直接體現(xiàn)在這些開發(fā)產(chǎn)物中。

參考文獻

[1]OMG，"Model Driven Architecture（MDA）：MDA Guide rev.2.0"，OMG Documentormsc/2014-06-01，2014，http：//www.omg.org/mda.

[2]蔣嚴(yán)冰，刑春曉，“模型驅(qū)動的體系結(jié)構(gòu)研究綜述”，南京大學(xué)學(xué)報（自然科學(xué)），pp.360-366，2005（41）.

[3]Chaudron MRV，Nugroho A，"A surveyinto the rigor of UML use and itsperceived impact on quality andproductivity"，ACM-IEEE InternationalSymposium on Empirical SoftwareEngineering and Measurement，2008.

[4]OMG，“SysML Specification"，2007.https：//www.omg.org/spec/SysML.

[5]JouaultF，Kurtev I，"TransformingModels with ATL”，ModelTransformations in Practice Workshopat MODELS，pp.128-138，2005.