面向復(fù)雜系統(tǒng)需求分析的DSL構(gòu)建

廖萬(wàn)斌, 曹云峰, 王新堯

(南京航空航天大學(xué)航天學(xué)院, 江蘇 南京 211106)

0 引 言

近年來(lái),隨著我國(guó)的科技水平不斷提高,航空、航天領(lǐng)域的設(shè)計(jì)與研制技術(shù)都開(kāi)始走在了世界前列,這意味著需要面臨越來(lái)越多正向設(shè)計(jì)方面的難題。而航空航天領(lǐng)域中所涉及的系統(tǒng)和體系,都是十分龐大的,隨著其復(fù)雜性的不斷增加,其研發(fā)過(guò)程以及研發(fā)的組織團(tuán)隊(duì)的復(fù)雜性也不斷上升,這又給整個(gè)工程帶來(lái)了新的困難。

面對(duì)這個(gè)問(wèn)題,國(guó)際系統(tǒng)工程學(xué)會(huì)(International Council on Systems Engineering, INCOSE)在2007年提出了基于模型的系統(tǒng)工程(model-based system engineering, MBSE)方法。其基于模型的特性,可以通過(guò)形式化的建模方法,更好地在團(tuán)隊(duì)中支持復(fù)雜系統(tǒng)整個(gè)生命周期的研發(fā)。

在系統(tǒng)的整個(gè)生命周期中,最重要的就是需求分析的部分,尤其是對(duì)于正向設(shè)計(jì)來(lái)說(shuō)。整個(gè)系統(tǒng)的后續(xù)研發(fā)工作都是基于需求的牽引來(lái)進(jìn)行的,一旦需求出錯(cuò),后續(xù)的工作做得再好也失去了意義。

而傳統(tǒng)的MBSE方法所提倡的是使用通用的建模語(yǔ)言,例如系統(tǒng)建模語(yǔ)言(system modeling language, SysML)來(lái)支持整個(gè)系統(tǒng)全生命周期的研發(fā)活動(dòng)。但是,這種通用的建模語(yǔ)言通常是基于完整的方法論,內(nèi)聚性很強(qiáng),團(tuán)隊(duì)中不同領(lǐng)域的研發(fā)人員對(duì)其的學(xué)習(xí)過(guò)程很困難,這阻礙了MBSE方法在工業(yè)實(shí)踐中的落地。同時(shí),SysML中對(duì)于需求分析與建模的支持也不足。

系統(tǒng)工程中的很多方法都脫胎于軟件工程領(lǐng)域。而在軟件工程中,近些年對(duì)于領(lǐng)域特定語(yǔ)言(domain specific language, DSL)的關(guān)注也多了起來(lái),但實(shí)際上DSL已經(jīng)存在了很長(zhǎng)時(shí)間。DSL是指針對(duì)特定領(lǐng)域需要而構(gòu)建的語(yǔ)言,往往是形式化的,這意味著其可以由計(jì)算機(jī)處理。同時(shí),領(lǐng)域特定的特點(diǎn)也使其更容易上手與使用，其提供一些通用語(yǔ)言所沒(méi)有的功能,同時(shí)又因?yàn)檩^窄的適用范圍而獲得了更簡(jiǎn)潔的表示。這些優(yōu)勢(shì)使得DSL在模型驅(qū)動(dòng)的需求工程中能得到很好的應(yīng)用。

在需求分析方面,對(duì)模型驅(qū)動(dòng)方法的研究并不多。2010年Ameller等指出,模型驅(qū)動(dòng)的發(fā)展側(cè)重于非功能性需求(non-functional requirement, NFR)是不夠的,這種情況至今沒(méi)有太大改善。在今年的研究中,Ameller等發(fā)現(xiàn),在模型驅(qū)動(dòng)的發(fā)展實(shí)踐中,大多數(shù)人關(guān)注功能性需求(functional requirements, FR),而專注于NFR的研究很少使用模型驅(qū)動(dòng)思維。在功能要求分析中,Karagoz等使用SysML模型支持系統(tǒng)需求的分析。目標(biāo)圖也是一種方法,Khan等和Chung等在相關(guān)研究中使用了以目標(biāo)為導(dǎo)向的方法。

在系統(tǒng)工程中引入DSL和多架構(gòu)建模、特定域的建模概念方面也取得了一些成果。Kurtev等研究了DSL在模型驅(qū)動(dòng)工程中的應(yīng)用,結(jié)果表明模型驅(qū)動(dòng)工程及DSL方法在復(fù)雜系統(tǒng)中表現(xiàn)良好。王贊超等為系統(tǒng)工程中的需求建模而構(gòu)建了DSL,但所構(gòu)建的DSL非常簡(jiǎn)單,只針對(duì)需求建模的部分,對(duì)于SysML中使用的需求圖沒(méi)有太大優(yōu)勢(shì)。

本文將針對(duì)需求工程中對(duì)需求分析以及建模的需求,構(gòu)建需求分析語(yǔ)言(requirement analyze language, RAL),以彌補(bǔ)SysML的不足。以下為本文的組織:第1節(jié)從下至上地分析RAL在模型驅(qū)動(dòng)工程中的底層需求;第2節(jié)依據(jù)方法論從整體視點(diǎn)由上至下地分析RAL的需求;第3節(jié)為DSL的構(gòu)建方法;第4節(jié)依托具體問(wèn)題介紹所構(gòu)建的DSL對(duì)模型驅(qū)動(dòng)開(kāi)發(fā)的支持以及其擴(kuò)展性;最后是對(duì)本文的總結(jié)。

本文的主要貢獻(xiàn)如下:

(1) 從具體的工程以及方法論,即自下而上與自上而下兩個(gè)層面分析了模型驅(qū)動(dòng)工程中進(jìn)行需求分析的需要。

(2) 依托具體需求構(gòu)建了相應(yīng)的DSL,具有良好的對(duì)模型驅(qū)動(dòng)開(kāi)發(fā)的支持。

(3) 以RAL為例,提供了一種DSL的構(gòu)建思路。

1 工程需求

本節(jié)中結(jié)合實(shí)際工程需求,從底層分析RAL在實(shí)際工程中應(yīng)用時(shí)有哪些需要。

在民航領(lǐng)域,系統(tǒng)工程的實(shí)踐已經(jīng)有一定的積淀。根據(jù)ARP 4754A標(biāo)準(zhǔn),在民航飛機(jī)的生命周期中,在需求分析之前與之后的環(huán)節(jié)分別是功能分析過(guò)程與設(shè)計(jì)綜合過(guò)程。由此可以確定需求分析環(huán)節(jié)的輸入與輸出:輸入為利益攸關(guān)方的需要以及功能清單、功能架構(gòu)等,輸出為產(chǎn)品需求集。盡管輸入已經(jīng)有了功能清單等,但依舊需要基于內(nèi)部的需求分析來(lái)生成最終的功能性需求。

1.1 FR

對(duì)FR的分析需要將其形式化,這就涉及到過(guò)程建模。Shaked等聯(lián)系開(kāi)發(fā)過(guò)程設(shè)計(jì)(development process design, DPD)本體,對(duì)DPD工程方法提出了7點(diǎn)基于本體論的需求:

A1. DPD應(yīng)由活動(dòng)、工件、復(fù)合工件狀態(tài)來(lái)組成過(guò)程;

A2. DPD應(yīng)支持對(duì)活動(dòng)的定性、無(wú)分支、程序性描述;

A3. DPD應(yīng)支持對(duì)并行過(guò)程的詳細(xì)描述;

A4. DPD應(yīng)允許描述開(kāi)發(fā)活動(dòng)的附加/建設(shè)性觀點(diǎn);

A5. DPD應(yīng)反映過(guò)程范圍;

A6. DPD應(yīng)鼓勵(lì)多層次方法。即應(yīng)支持不同層級(jí)方案之間的向前、向后一致性;

A7. DPD應(yīng)適應(yīng)變化以及不確定性和有目的的創(chuàng)造性。

同時(shí),為了更好地定義過(guò)程模型,需要考慮過(guò)程模型本體。過(guò)程模型主要用于3個(gè)目的:描述實(shí)際事件、提供描述性過(guò)程、解釋性地提供過(guò)程的原理。Rolland由此提出了過(guò)程模型應(yīng)具有的理想特征:

B1. 理想狀態(tài)下,過(guò)程模型應(yīng)提供廣泛的粒度;

B2. 過(guò)程模型應(yīng)提供適應(yīng)變化的機(jī)制;

B3. 開(kāi)發(fā)過(guò)程模型應(yīng)能夠重用之前用于設(shè)計(jì)類似組件或系統(tǒng)的模型元素;

B4. 過(guò)程模型應(yīng)與相關(guān)過(guò)程本體清晰對(duì)應(yīng)。

而根據(jù)中國(guó)商用飛機(jī)有限責(zé)任公司在工程過(guò)程的系統(tǒng)工程實(shí)踐,可以總結(jié)出需求分析過(guò)程中對(duì)FR的處理主要在于以下幾個(gè)方面:

C1. 應(yīng)定義影響需求的內(nèi)外部約束;

C2. 應(yīng)定義環(huán)境;

C3. 功能性需求定義中應(yīng)列出所有的功能;

C4. 功能性需求定義中應(yīng)列出產(chǎn)品或系統(tǒng)的特征;

C5. 功能性需求定義中應(yīng)能聯(lián)系功能與特征。

結(jié)合DPD過(guò)程方法的7點(diǎn)需求、過(guò)程模型應(yīng)具有的4點(diǎn)理想特征,以及根據(jù)需求分析過(guò)程中對(duì)FR的分析要求對(duì)其進(jìn)行適當(dāng)裁剪與修正,可以導(dǎo)出RAL中對(duì)FR分析視點(diǎn)、視圖構(gòu)成的需求。綜合需求將數(shù)個(gè)細(xì)分的簡(jiǎn)潔需求拆分,末尾的括號(hào)中標(biāo)明了需求的來(lái)源。

應(yīng)由活動(dòng)、工件、復(fù)合工件狀態(tài)來(lái)組成過(guò)程(A1,B4),REQ即requirements,表示需求。

REQ1. 視圖應(yīng)支持活動(dòng)表示;

REQ2. 視圖應(yīng)支持工件表示;

REQ3. 視圖應(yīng)支持復(fù)合工件狀態(tài)表示;

REQ4. 視圖應(yīng)支持影響需求的內(nèi)外部約束表示(A4,B4,C1);

REQ5. 視圖應(yīng)支持環(huán)境表示(A4,B4,C2)。

應(yīng)能提供不同層級(jí)的視點(diǎn)來(lái)描述產(chǎn)品或系統(tǒng)的功能以及特征(A5,A6,B1,C3,C4)。

REQ6. 視點(diǎn)應(yīng)支持不同層級(jí)的表示;

REQ7. 不同層級(jí)的視點(diǎn)應(yīng)指明適用范圍;

REQ8. 不同層級(jí)的視點(diǎn)中應(yīng)包含全部的功能;

REQ9. 不同層級(jí)的視點(diǎn)中應(yīng)包含全部的產(chǎn)品或系統(tǒng)特征。

應(yīng)能并行表示功能與特征并建立聯(lián)系(A3,C5)。

REQ10. 視圖應(yīng)支持功能與特征的并行表示;

REQ11. 視圖應(yīng)支持工件之間的聯(lián)系表示。

由此得到RAL在FR描述方面的需求集。

1.2 NFR

產(chǎn)品或系統(tǒng)的NFR跟隨FR而產(chǎn)生,相互聯(lián)系,NFR可以支持功能更好地實(shí)現(xiàn)。因此,在NFR描述方面,重點(diǎn)在于NFR與FR之間的聯(lián)系。

在增量軟件開(kāi)發(fā)以及一些敏捷性工程中,FR的優(yōu)先級(jí)需要重點(diǎn)考慮。但是在常規(guī)工程中,由于NFR間復(fù)雜的關(guān)系,NFR之間的優(yōu)先級(jí)關(guān)系更值得討論。

與FR不同,NFR之間可能會(huì)存在沖突。Roy等將NFR之間的沖突考慮進(jìn)了對(duì)FR之間的排序中,并且基于此生成了集群圖來(lái)表征其間的關(guān)系。同時(shí),需求之間也會(huì)存在依賴關(guān)系。Martakis等進(jìn)行的一項(xiàng)調(diào)查表明,很多項(xiàng)目中沒(méi)有采取任何措施來(lái)應(yīng)對(duì)這種依賴關(guān)系,使得這種需求依賴帶來(lái)的風(fēng)險(xiǎn)被放大了。

面對(duì)這些問(wèn)題,RAL在NFR分析方面的需求也就明確了:

REQ12. 視圖應(yīng)支持FR與NFR的并行表示;

REQ13. 視圖應(yīng)支持FR與NFR之間的關(guān)系表示;

REQ14. 視圖應(yīng)支持NFR之間的沖突表示;

REQ15. 視圖應(yīng)支持NFR之間的優(yōu)先級(jí)表示。

1.3 需求管理

面對(duì)一個(gè)復(fù)雜系統(tǒng),在設(shè)計(jì)階段需求管理的重要性不言而喻。這一階段許多需求尚未成型,不同層級(jí)的需求經(jīng)常發(fā)生變動(dòng)和修改。因此，基于需求管理的需要,總結(jié)出以下需求:

REQ16. 需求應(yīng)具有唯一的標(biāo)識(shí)符;

REQ17. 需求的來(lái)源應(yīng)可識(shí)別;

REQ18. 需求應(yīng)是可追溯的。

2 方法論需求

語(yǔ)言通常是與一套方法論相聯(lián)系的。對(duì)一種語(yǔ)言來(lái)說(shuō),尤其是一種領(lǐng)域特定的語(yǔ)言,存在其想要描述的目標(biāo)。例如,超文本標(biāo)記語(yǔ)言(hyper text markup language, HTML)作為一種DSL,其目的為表示網(wǎng)絡(luò)文檔。而具體語(yǔ)言的組織方法則與其框架有關(guān),其關(guān)系如圖1所示。

圖1 視點(diǎn)與視圖Fig.1 Viewpoint and views

要明確需要構(gòu)建什么樣的語(yǔ)言,就要先確定框架以及對(duì)應(yīng)的視點(diǎn)和視圖。

構(gòu)建語(yǔ)言的過(guò)程中,如果僅著眼于底層,試圖依靠一點(diǎn)一滴的細(xì)節(jié)拼湊起整個(gè)框架的話,最后的結(jié)果將會(huì)不盡人意。在面對(duì)復(fù)雜系統(tǒng)時(shí),這一點(diǎn)尤為明顯，完全依靠還原論的思想是不嚴(yán)謹(jǐn)?shù)摹Ｒ虼?需要同時(shí)進(jìn)行自上而下的審視,兼顧整體論的思想對(duì)DSL的構(gòu)建加以輔助。本節(jié)根據(jù)RAL承載的方法論,總結(jié)并確定RAL的需求,由此對(duì)模型元素進(jìn)行形式化。

首先,為了更加地直觀以及易于上手,RAL采用圖形化的方式進(jìn)行建模,即RAL采用圖形化表示的具體語(yǔ)法。

盡管RAL在進(jìn)行FR分析時(shí)需要進(jìn)行過(guò)程建模,但是這與單純的業(yè)務(wù)建模,例如業(yè)務(wù)流程建模與標(biāo)注(business process modeling notation, BPMN),還是有著很大的不同的。RAL進(jìn)行建模的最終目的是為了更好地確定FR,功能與過(guò)程是密不可分的,因此，RAL不應(yīng)當(dāng)將對(duì)象與過(guò)程割裂開(kāi)來(lái)。也就是說(shuō),RAL不應(yīng)是單純的面向?qū)ο蟮恼Z(yǔ)言,這一點(diǎn)與SysML不同,而這也將從根本上確定RAL的特征。

另一個(gè)明顯的特征是,RAL需要描述過(guò)程,需要描述FR與NFR之間的關(guān)系,也就是說(shuō),RAL具有一種以上的視圖。

作為一種建模語(yǔ)言,其是否形式化、形式化的程度有多深也是應(yīng)當(dāng)關(guān)注的議題。由于存在盡可能精確的要求,最大程度上的形式化是十分必要的。然而,并非所有的事物都可以形式化,涉及到需求時(shí)就尤為如此。因此,RAL在涉及具體的需求時(shí)仍需要自然語(yǔ)言在一定程度上的參與,在其他方面則需要以圖形化的方式盡量地形式化。

綜上,即得到了RAL整體視角上的4個(gè)特征。其要點(diǎn)在于確立了對(duì)象與狀態(tài)并存的規(guī)范,賦予RAL更加豐富的表達(dá)。

2.1 功能分析視圖

在系統(tǒng)功能的視點(diǎn)上,與之對(duì)應(yīng)的是功能分析視圖。

(1) 方法與視圖

功能作為一種動(dòng)態(tài)特征,可以進(jìn)一步體現(xiàn)為通過(guò)某個(gè)過(guò)程來(lái)使對(duì)象的復(fù)合狀態(tài)發(fā)生改變的行為。此過(guò)程的輸入為系統(tǒng)的功能清單,所以在分析環(huán)節(jié)開(kāi)始時(shí),功能應(yīng)以未細(xì)化的狀態(tài)出現(xiàn)。因此,功能分析過(guò)程的第一步應(yīng)為系統(tǒng)功能清單以及架構(gòu)的形式化表示。

在此基礎(chǔ)之上,應(yīng)在同一層級(jí)完善系統(tǒng)的一些狀態(tài)變化,確定功能的輸入輸出以及主體,為功能到過(guò)程的分解做準(zhǔn)備。

下一步,在功能中用具體的過(guò)程填充,功能清單中的功能在這個(gè)階段進(jìn)一步細(xì)化,才能夠生成FR。因此,功能/需求分解尤為重要。令decomposition(,)表示是的一個(gè)子功能需求,則功能需求分解應(yīng)滿足:

(?,,)decomposition(,)∧decomposition(,)→decomposition(,)

(1)

(?)～decomposition(,)

(2)

(?,)decomposition(,)→～decomposition(,)

(3)

(?,,)decomposition(,)∧decomposition(,)→=∨decomposition(,)∨decomposition(,)

(4)

且最重要的是,功能需求分解應(yīng)符合以下原則:① 分解后產(chǎn)生的功能需求應(yīng)與原需求保持語(yǔ)義一致;② 分解過(guò)程中無(wú)冗余功能需求產(chǎn)生。令exp()為功能需求的邏輯表達(dá),即

(?)decomposition(,)∧…∧decomposition(,)→exp()=exp()∧…∧exp()

(5)

因此,為了滿足以上原則,分解須在單獨(dú)的子視圖中進(jìn)行。并且,為了確保子視圖中的分解在語(yǔ)義上與父視圖保持一致,子視圖的建立應(yīng)首先確定功能的邊界以及功能的輸入輸出,由此來(lái)限定子視圖的語(yǔ)義。

最后,根據(jù)所建立的各級(jí)視圖,提取系統(tǒng)的各級(jí)FR。

(2) 視圖元素

設(shè)系統(tǒng)功能集為。同時(shí),由REQ4與REQ5,視圖中的實(shí)體元素還應(yīng)包括環(huán)境因素與內(nèi)外部約束,設(shè)其集合分別為與。

在對(duì)開(kāi)發(fā)過(guò)程模型進(jìn)行研究時(shí),Browning發(fā)現(xiàn)需要非常多的屬性來(lái)對(duì)開(kāi)發(fā)情況進(jìn)行描述。而根據(jù)Shaked等對(duì)BPMN、對(duì)象過(guò)程方法(object process methodology, OPM)以及軟件開(kāi)發(fā)過(guò)程元模型( software process engineering meta-model, SPEM) 3種較為先進(jìn)的語(yǔ)言的研究評(píng)價(jià),其在表達(dá)工件的復(fù)合狀態(tài)方面都有明顯的欠缺。作為MBSE 6種方法論之一,同樣并非面向?qū)ο蠓椒ǖ腛PM,其建模元素中僅包含3種實(shí)體:對(duì)象、狀態(tài)與過(guò)程。并且對(duì)象僅能在不同的狀態(tài)間切換,同時(shí)僅能處于一種狀態(tài),這對(duì)于復(fù)雜系統(tǒng)的功能表示是不夠的。因此，RAL在支持復(fù)合狀態(tài)表示的同時(shí),過(guò)程的輸入輸出也應(yīng)可以為復(fù)合態(tài)。若存在對(duì)象,其狀態(tài)與屬性分別屬于其狀態(tài)集與屬性集。則其復(fù)合狀態(tài)集CS=∪。那么僅涉及此對(duì)象的過(guò)程應(yīng)可表示為

cs=(cs)

(6)

最后,由本視圖得到的輸出應(yīng)是系統(tǒng)的FR。因需求管理的需要,亦即REQ18、REQ19,需求亦應(yīng)作為一種實(shí)體加入視圖當(dāng)中,令其集合為FR。

除了實(shí)體之外,分析過(guò)程還涉及到關(guān)系,在視圖中即表現(xiàn)為實(shí)體之間的連接。同OPM一樣,連接應(yīng)分為結(jié)構(gòu)性連接以及過(guò)程性連接。結(jié)構(gòu)性連接相對(duì)簡(jiǎn)單,表明實(shí)體之間基本的結(jié)構(gòu)關(guān)系,例如包含關(guān)系、特化關(guān)系等,是一種靜態(tài)的描述。而過(guò)程性連接則表現(xiàn)為一種動(dòng)態(tài)的行為,主要包含支持性連接與變換連接。

由以上分析,結(jié)合需求集,可得系統(tǒng)功能視圖的形式化表示:

(7)

式中：∈為環(huán)境因素;∈為內(nèi)外部約束;∈為對(duì)象;cs∈CS為復(fù)合狀態(tài);∈為功能;∈為過(guò)程;sl∈SL為結(jié)構(gòu)性連接;pl∈PL為過(guò)程性連接;∈FR為系統(tǒng)FR。

對(duì)應(yīng)方法論的要求,這個(gè)視圖需要分不同層級(jí)來(lái)表示,這與REQ6相對(duì)應(yīng)。在不同的層級(jí)上對(duì)系統(tǒng)的功能進(jìn)行表示,一定程度上也可以體現(xiàn)復(fù)雜系統(tǒng)的涌現(xiàn)性。依據(jù)REQ7,功能與過(guò)程實(shí)體應(yīng)連接至各自的子視圖。對(duì)應(yīng)方法論有:

(8)

式中：∈為功能或過(guò)程的輸入輸出邊界。同時(shí),若令為不同層級(jí)視圖的集合,則有:

={|∈N}

(9)

且因REQ8與REQ9,對(duì)應(yīng)有:

=∪∪…∪

(10)

CS=CS∪CS∪…∪CS

(11)

2.2 NFR視圖

通過(guò)系統(tǒng)功能視點(diǎn)的分析,系統(tǒng)的FR應(yīng)當(dāng)已經(jīng)被提取出來(lái)。要繼續(xù)則需要通過(guò)系統(tǒng)需求的視點(diǎn),這個(gè)視點(diǎn)應(yīng)包括由FR到NFR的NFR分析視圖以及對(duì)NFR進(jìn)行排序的優(yōu)先級(jí)視圖。

(1) 方法與視圖

2010年曾有研究指出,模型驅(qū)動(dòng)開(kāi)發(fā)中對(duì)NFR的關(guān)注不足,至今這種情況依舊沒(méi)有太大的改善。在模型驅(qū)動(dòng)開(kāi)發(fā)的實(shí)踐中,人們多數(shù)關(guān)注的是FR,而關(guān)注NFR的研究又很少利用模型驅(qū)動(dòng)的思想。

在分析NFR時(shí),一部分來(lái)源于環(huán)境因素以及系統(tǒng)內(nèi)外部約束的限制,在視圖中需要體現(xiàn)這兩種實(shí)體對(duì)系統(tǒng)的影響。另一部分NFR直接來(lái)源于FR,其目的在于支援FR更好地達(dá)成。在分析的過(guò)程中,這部分的視圖在功能分析視圖的基礎(chǔ)上構(gòu)建,這樣能更直觀地看到各個(gè)過(guò)程。同時(shí),加入系統(tǒng)的邊界以及非功能性需求元素,設(shè)其集合為SB與NFR,并且加入新的連接類型以支援需求間關(guān)系的表示。

(2) 視圖元素

由以上分析,結(jié)合需求集,可得系統(tǒng)NFR分析視圖的形式化表示:

(12)

式中：sb∈SB為系統(tǒng)邊界;nfr∈NFR為系統(tǒng)NFR。

最后在優(yōu)先級(jí)視圖中,只需要展現(xiàn)需要排序的NFR,并且以連接體現(xiàn)其間的優(yōu)先關(guān)系即可。即

(13)

式中：∈為優(yōu)先關(guān)系連接。

3 DSL構(gòu)建

DSL同樣是一門語(yǔ)言,而任何語(yǔ)言的構(gòu)成都需要定義語(yǔ)言的語(yǔ)義以及語(yǔ)法。如圖2所示,形式化建模需要包含語(yǔ)義與語(yǔ)法,而語(yǔ)法分為具體語(yǔ)法與抽象語(yǔ)法,語(yǔ)義則分為語(yǔ)義映射與語(yǔ)義定義域。

圖2 領(lǐng)域建模概念Fig.2 Domain modeling concepts

具體語(yǔ)法用于說(shuō)明語(yǔ)言中特定部分所代表的含義,可分為文本化表示以及圖形化表示。文本化表示的例子有Java中“import”代表導(dǎo)入包,而SysML中的火柴人則代表參與者就是一個(gè)圖形化表示的例子。

抽象語(yǔ)法則更為重要,其定義了語(yǔ)言的結(jié)構(gòu),語(yǔ)言的組成元素及其組合的規(guī)則。通常這可以由元模型來(lái)定義。

語(yǔ)義的定義域指明模型的含義。語(yǔ)義的映射則指明這種含義的賦予規(guī)則。

確定視點(diǎn)與視圖等后,就可以根據(jù)以上規(guī)則來(lái)進(jìn)行RAL的構(gòu)建。

3.1 抽象語(yǔ)法

為了進(jìn)行圖形化語(yǔ)言的構(gòu)建,本文在GOPPRR(groph object properby port role relationship)的元元模型的基礎(chǔ)上定義RAL的抽象語(yǔ)法,此元元模型來(lái)自于MetaCase公司。

GOPPRR的元元模型包含6種元素,如圖3所示。

圖3 GOPPRR元元模型Fig.3 GOPPRR meta model

其中，圖由其他5種元素組合而成;對(duì)象是一種基本元素,可以與其他對(duì)象連接;屬性不能單獨(dú)存在,依附于其他元素以表達(dá)其特性;端口依附于對(duì)象上,表達(dá)對(duì)象用于連接的元素;角色依附于連接上,表達(dá)連接的對(duì)象在關(guān)系中充當(dāng)?shù)慕巧?關(guān)系通過(guò)角色連接對(duì)象的端口,表達(dá)對(duì)象之間的交互方式。

基于RAL的需要,在GOPPRR的基礎(chǔ)上,加入重疊作為元元模型的一種元素。擴(kuò)展后的元元模型即為GOPPRRE(extended)元元模型。

重疊是指通過(guò)對(duì)象之間的位置重疊,表達(dá)對(duì)象之間關(guān)系，如圖4所示。

圖4 重疊Fig.4 Overlapping

3.2 具體語(yǔ)法及語(yǔ)義

本節(jié)將介紹RAL中建模元素的具體語(yǔ)法以及對(duì)應(yīng)的語(yǔ)義。具體語(yǔ)法的設(shè)計(jì)在MetaEdit+平臺(tái)上完成。

RAL具有3大類實(shí)體,分別為對(duì)象、狀態(tài)以及過(guò)程。對(duì)象類實(shí)體分為環(huán)境、內(nèi)外部約束、物理實(shí)體、需求這4類。這4類實(shí)體可以借由屬性元素直接包含各自的一些固有屬性，如圖5所示。

圖5 對(duì)象類實(shí)體Fig.5 Object class entity

狀態(tài)類實(shí)體則描述復(fù)合狀態(tài),分為相對(duì)穩(wěn)定的屬性實(shí)體以及狀態(tài)實(shí)體，如圖6所示。

圖6 狀態(tài)類實(shí)體Fig.6 State class entity

過(guò)程類實(shí)體則描述動(dòng)態(tài)的過(guò)程，分為功能以及過(guò)程,過(guò)程類實(shí)體具有自己的子圖，如圖7所示。

圖7 過(guò)程類實(shí)體Fig.7 Process class entity

除去實(shí)體之外的建模元素是連接，連接分為結(jié)構(gòu)性連接以及過(guò)程性連接。具體語(yǔ)法、語(yǔ)義如表1與表2所示。

表1 結(jié)構(gòu)性連接Table 1 Structural connection

表2 過(guò)程性連接Table 2 Process connection

具體語(yǔ)法與語(yǔ)義確定之后,依托RAL的分析方法也清晰了起來(lái)。

首先，依據(jù)功能清單,使用式(7)中的元素建立各級(jí)功能分析視圖,這一步不涉及任何過(guò)程,忠于功能清單的表示。接下來(lái)將功能由過(guò)程細(xì)化,將涉及到的對(duì)象、關(guān)系等元素填充進(jìn)視圖中，然后從表達(dá)清晰的視圖中提取系統(tǒng)功能需求。

接著,使用式(12)中的元素,依據(jù)系統(tǒng)功能需求建立需求分析視圖,將環(huán)境因素與內(nèi)外部約束添加進(jìn)視圖中,并分析其對(duì)功能實(shí)現(xiàn)的影響;然后依據(jù)視圖提取NFR。

其中,功能/需求分解視圖的優(yōu)勢(shì)在于,依據(jù)方法論,將子功能/需求視作黑盒,在實(shí)施分解工作之前優(yōu)先確立系統(tǒng)邊界以及輸入輸出,由此指引后續(xù)分解的進(jìn)行,來(lái)確保分解過(guò)程符合式(1)～式(5)的規(guī)范。

4 實(shí)例分析

本節(jié)將使用RAL進(jìn)行一些分析,通過(guò)具體問(wèn)題來(lái)體現(xiàn)其對(duì)模型驅(qū)動(dòng)設(shè)計(jì)的支持。

4.1 問(wèn)題描述

RAL的構(gòu)建初衷就是為了更好地支持模型驅(qū)動(dòng)開(kāi)發(fā),也就是彌補(bǔ)MBSE中需求分析環(huán)節(jié)基于模型的需要。本節(jié)將使用RAL對(duì)有人機(jī)與無(wú)人機(jī)協(xié)同作戰(zhàn)系統(tǒng)做實(shí)例分析,同時(shí)將Karagoz等使用SysML的方法作為比較。

具體描述為:乙方有兩架戰(zhàn)斗機(jī)入侵甲方領(lǐng)域,甲方派遣一架有人機(jī)指揮控制兩架無(wú)人機(jī)執(zhí)行攔截攻擊任務(wù)為背景。其中,有人機(jī)只執(zhí)行指揮任務(wù),2架無(wú)人機(jī)攜帶中遠(yuǎn)距空空導(dǎo)彈實(shí)施對(duì)空攔截。作戰(zhàn)任務(wù)清單如下:

在T0～T1時(shí)間段內(nèi),總指揮控制中心接受預(yù)警信息,并發(fā)布任務(wù)給有人機(jī)及無(wú)人機(jī)地面站;

在T1～T2時(shí)間段內(nèi),從有人機(jī)和無(wú)人機(jī)接受任務(wù)命令開(kāi)始,對(duì)進(jìn)行有人機(jī)和無(wú)人機(jī)執(zhí)行任務(wù)飛行前準(zhǔn)備和檢測(cè),同時(shí)進(jìn)行機(jī)場(chǎng)的飛行前準(zhǔn)備;

在T2～T3時(shí)間段內(nèi),有人機(jī)、無(wú)人機(jī)從有人機(jī)機(jī)場(chǎng)、無(wú)人機(jī)機(jī)場(chǎng)起飛、爬升至聚集點(diǎn),無(wú)人機(jī)開(kāi)始編隊(duì)飛行,有人機(jī)以安全距離跟隨飛行;

在T3～T4時(shí)間段內(nèi),無(wú)人機(jī)進(jìn)入任務(wù)區(qū),將探測(cè)到的乙方情報(bào)反饋給有人機(jī),有人機(jī)保持遠(yuǎn)距戰(zhàn)區(qū),無(wú)人機(jī)在有人機(jī)的領(lǐng)導(dǎo)指揮下攻擊對(duì)抗乙方戰(zhàn)機(jī);

在T4～T5時(shí)間段內(nèi),目標(biāo)摧毀信息傳回機(jī)載設(shè)備和地面指揮中心,進(jìn)行評(píng)估。

4.2 具體分析

取T3～T4時(shí)間段進(jìn)行分析。由功能架構(gòu)可以初步建立如圖8(a)所示功能分析圖。這個(gè)階段的視圖由功能清單與架構(gòu)直接轉(zhuǎn)化而來(lái),是輸入的形式化表達(dá)。這一階段的任務(wù)在使用SysML進(jìn)行分析時(shí)尚可以由活動(dòng)圖完成,如圖8(b)所示。

圖8 頂層功能分解Fig.8 Top level function decomposition

在此基礎(chǔ)上將進(jìn)行功能的細(xì)化,如圖9所示。在此階段的視圖中,加入了各個(gè)對(duì)象的狀態(tài),以及狀態(tài)之間的轉(zhuǎn)換,功能對(duì)狀態(tài)之間的要求等。而這部分在Karagoz等的分析中是缺失的,因?yàn)镾ysML中狀態(tài)與對(duì)象是分離開(kāi)的,如果想要表示狀態(tài)之間的轉(zhuǎn)換,需要單獨(dú)的狀態(tài)圖來(lái)完成,這使得對(duì)應(yīng)關(guān)系在分析中缺失,這種分離對(duì)分析設(shè)計(jì)工作是不利的。由此可以體現(xiàn)出,RAL在針對(duì)需求分析的表達(dá)上因具有對(duì)象與狀態(tài)并存的特性,對(duì)系統(tǒng)的描述更加清晰。

圖9 功能分析圖(階段2)Fig.9 Functional analysis diagram (phase 2)

圖10為圖9中指揮功能的子視圖。此視圖依據(jù)前文所分析的分解過(guò)程原則對(duì)指揮功能加以分解。首先確立系統(tǒng)邊界,并使輸入輸出與上一級(jí)功能嚴(yán)格對(duì)應(yīng)。可以看到，視圖中標(biāo)明了功能的輸入輸出邊界,并且與父視圖嚴(yán)格對(duì)應(yīng)。視圖中左邊的部分是功能的輸入,右邊的部分為功能的輸出,這一步首先限定了子視圖功能的語(yǔ)義,使得子圖表示的功能在語(yǔ)義上能與上一層級(jí)的功能保持一致。依據(jù)輸入輸出進(jìn)行子視圖的構(gòu)建,能避免分解不徹底或者產(chǎn)生冗余,體現(xiàn)了RAL針對(duì)功能/需求分解的輔助功能。

圖10 功能分析子視圖(階段3)Fig.10 Functional analysis diagram (phase 3)

而使用SysML方法進(jìn)行的分解工作，如圖11所示。依舊使用活動(dòng)圖進(jìn)行分解,同時(shí)只能進(jìn)行簡(jiǎn)單的活動(dòng)順序表示,分解過(guò)程中難以保持功能分解的原則。同時(shí)可以看到,SysML的功能分解,重點(diǎn)在于完成任務(wù)的順序,關(guān)注的是時(shí)間跨度上的變化;而本文采用的方法著眼點(diǎn)在于功能的實(shí)現(xiàn),因?yàn)檫@是FR產(chǎn)生的根源。

圖11 SysML的低層次功能分解Fig.11 Low level functional decomposition of SysML

最后,根據(jù)視圖以及各層級(jí)的子視圖,提取出系統(tǒng)的各層級(jí)功能性需求,完成功能分析視圖。如圖12為從指揮功能中提取的功能性需求。經(jīng)過(guò)不同層級(jí)的縮放,可以實(shí)現(xiàn)不同層級(jí)需求的表示,越是高層級(jí)的需求便越不會(huì)限制具體的設(shè)計(jì),這對(duì)正向設(shè)計(jì)來(lái)說(shuō)十分關(guān)鍵。同時(shí),每一層級(jí)的需求不僅能追溯至上一層級(jí),也能追溯至具體的功能與過(guò)程。在產(chǎn)品開(kāi)發(fā)早期,概念會(huì)經(jīng)常發(fā)生變更,需求也能馬上根據(jù)其進(jìn)行迭代。

圖12 功能分析視圖(階段4)Fig.12 Functional analysis view (phase 4)

在使用SysML的方法中,具體的需求使用需求圖表示。需求圖只能表示需求之間的關(guān)系,與上一過(guò)程是分離開(kāi)的,在追溯性上有欠缺。同時(shí)也不支持多層級(jí)的縮放,面對(duì)復(fù)雜系統(tǒng)時(shí)會(huì)顯得不清晰。

NFR則來(lái)自于FR以及環(huán)境因素、系統(tǒng)內(nèi)外部約束。在Karagoz等的方法中,主要只考慮了外部約束,并且這部分的分析較為簡(jiǎn)單,使用表格的形式進(jìn)行,沒(méi)有模型的支持,如表3表示。但在RAL中,這3種因素都可以形式化地表示出來(lái),如圖13所示。在細(xì)化過(guò)程的基礎(chǔ)上,添加進(jìn)內(nèi)外部約束和環(huán)境因素,及其與功能之間的關(guān)系，之后便可以更為直觀地分析出NFR。

表3 使用SysML方法中的NFR頂層分析[23]Table 3 Top level analysis of NFR in the method using SysML[23]

圖13 NFR分析視圖Fig.13 NFR analysis view

同時(shí),借由GOPPRRE元元模型靈活的表達(dá)能力,RAL也具有良好的擴(kuò)展性。經(jīng)過(guò)增加語(yǔ)法,可以完成NFR的沖突表示,如圖14所示。具體含義與判別等可參考文獻(xiàn)[17],示例僅對(duì)NFR的沖突進(jìn)行表示。

圖14 NFR沖突表示Fig.14 NFR conflict representation

在對(duì)比分析中可以看出,RAL在需求分析工作中體現(xiàn)了極強(qiáng)的針對(duì)性。首先,其能同時(shí)描述對(duì)象與狀態(tài),便于對(duì)功能進(jìn)行分析;第二,其功能/需求分析視圖能更好地輔助分解原則的貫徹;第三,相比SysML,能實(shí)現(xiàn)分析過(guò)程中需求的追溯;最后,其具有優(yōu)異的擴(kuò)展性,便于適應(yīng)不同的工程實(shí)際。

5 結(jié) 論

由本文的第1～第3節(jié)可以看出，本文提出的構(gòu)建思路如下：從底層著眼可以解決具體應(yīng)用時(shí)的可用性與適應(yīng)性問(wèn)題,而從頂層向下的視點(diǎn)則可以使得構(gòu)建的語(yǔ)言與具體的方法論緊密貼合,同時(shí)兼顧還原論與整體論的思想,可以體現(xiàn)復(fù)雜系統(tǒng)的涌現(xiàn)性。

最終的對(duì)比中也可以看出,相較于使用SysML的方法,本文所構(gòu)建的DSL在模型驅(qū)動(dòng)工程的需求分析中具有更強(qiáng)的針對(duì)性,對(duì)需求分析過(guò)程中狀態(tài)與對(duì)象分離以及需求分解易出現(xiàn)不徹底或者冗余的問(wèn)題給出了相應(yīng)的解決方法,并且在各個(gè)環(huán)節(jié)都有形式化模型的支持,能更好地確保需求分析工作的正確進(jìn)行。