廖萬斌, 曹云峰, 王新堯

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

0 引 言

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

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

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

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

系統(tǒng)工程中的很多方法都脫胎于軟件工程領域。而在軟件工程中,近些年對于領域特定語言(domain specific language, DSL)的關注也多了起來,但實際上DSL已經存在了很長時間。DSL是指針對特定領域需要而構建的語言,往往是形式化的,這意味著其可以由計算機處理。同時,領域特定的特點也使其更容易上手與使用，其提供一些通用語言所沒有的功能,同時又因為較窄的適用范圍而獲得了更簡潔的表示。這些優(yōu)勢使得DSL在模型驅動的需求工程中能得到很好的應用。

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

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

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

本文的主要貢獻如下:

(1) 從具體的工程以及方法論,即自下而上與自上而下兩個層面分析了模型驅動工程中進行需求分析的需要。

(2) 依托具體需求構建了相應的DSL,具有良好的對模型驅動開發(fā)的支持。

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

1 工程需求

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

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

1.1 FR

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

A1. DPD應由活動、工件、復合工件狀態(tài)來組成過程;

A2. DPD應支持對活動的定性、無分支、程序性描述;

A3. DPD應支持對并行過程的詳細描述;

A4. DPD應允許描述開發(fā)活動的附加/建設性觀點;

A5. DPD應反映過程范圍;

A6. DPD應鼓勵多層次方法。即應支持不同層級方案之間的向前、向后一致性;

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

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

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

B2. 過程模型應提供適應變化的機制;

B3. 開發(fā)過程模型應能夠重用之前用于設計類似組件或系統(tǒng)的模型元素;

B4. 過程模型應與相關過程本體清晰對應。

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

C1. 應定義影響需求的內外部約束;

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

C3. 功能性需求定義中應列出所有的功能;

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

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

結合DPD過程方法的7點需求、過程模型應具有的4點理想特征,以及根據(jù)需求分析過程中對FR的分析要求對其進行適當裁剪與修正,可以導出RAL中對FR分析視點、視圖構成的需求。綜合需求將數(shù)個細分的簡潔需求拆分,末尾的括號中標明了需求的來源。

應由活動、工件、復合工件狀態(tài)來組成過程(A1,B4),REQ即requirements,表示需求。

REQ1. 視圖應支持活動表示;

REQ2. 視圖應支持工件表示;

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

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

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

應能提供不同層級的視點來描述產品或系統(tǒng)的功能以及特征(A5,A6,B1,C3,C4)。

REQ6. 視點應支持不同層級的表示;

REQ7. 不同層級的視點應指明適用范圍;

REQ8. 不同層級的視點中應包含全部的功能;

REQ9. 不同層級的視點中應包含全部的產品或系統(tǒng)特征。

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

REQ10. 視圖應支持功能與特征的并行表示;

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

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

1.2 NFR

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

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

與FR不同,NFR之間可能會存在沖突。Roy等將NFR之間的沖突考慮進了對FR之間的排序中,并且基于此生成了集群圖來表征其間的關系。同時,需求之間也會存在依賴關系。Martakis等進行的一項調查表明,很多項目中沒有采取任何措施來應對這種依賴關系,使得這種需求依賴帶來的風險被放大了。

面對這些問題,RAL在NFR分析方面的需求也就明確了:

REQ12. 視圖應支持FR與NFR的并行表示;

REQ13. 視圖應支持FR與NFR之間的關系表示;

REQ14. 視圖應支持NFR之間的沖突表示;

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

1.3 需求管理

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

REQ16. 需求應具有唯一的標識符;

REQ17. 需求的來源應可識別;

REQ18. 需求應是可追溯的。

2 方法論需求

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

圖1 視點與視圖Fig.1 Viewpoint and views

要明確需要構建什么樣的語言,就要先確定框架以及對應的視點和視圖。

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

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

盡管RAL在進行FR分析時需要進行過程建模,但是這與單純的業(yè)務建模,例如業(yè)務流程建模與標注(business process modeling notation, BPMN),還是有著很大的不同的。RAL進行建模的最終目的是為了更好地確定FR,功能與過程是密不可分的,因此，RAL不應當將對象與過程割裂開來。也就是說,RAL不應是單純的面向對象的語言,這一點與SysML不同,而這也將從根本上確定RAL的特征。

另一個明顯的特征是,RAL需要描述過程,需要描述FR與NFR之間的關系,也就是說,RAL具有一種以上的視圖。

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

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

2.1 功能分析視圖

在系統(tǒng)功能的視點上,與之對應的是功能分析視圖。

(1) 方法與視圖

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

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

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

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

(1)

(?)～decomposition(,)

(2)

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

(3)

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

(4)

且最重要的是,功能需求分解應符合以下原則:① 分解后產生的功能需求應與原需求保持語義一致;② 分解過程中無冗余功能需求產生。令exp()為功能需求的邏輯表達,即

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

(5)

因此,為了滿足以上原則,分解須在單獨的子視圖中進行。并且,為了確保子視圖中的分解在語義上與父視圖保持一致,子視圖的建立應首先確定功能的邊界以及功能的輸入輸出,由此來限定子視圖的語義。

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

(2) 視圖元素

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

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

cs=(cs)

(6)

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

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

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

(7)

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

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

(8)

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

={|∈N}

(9)

且因REQ8與REQ9,對應有:

=∪∪…∪

(10)

CS=CS∪CS∪…∪CS

(11)

2.2 NFR視圖

通過系統(tǒng)功能視點的分析,系統(tǒng)的FR應當已經被提取出來。要繼續(xù)則需要通過系統(tǒng)需求的視點,這個視點應包括由FR到NFR的NFR分析視圖以及對NFR進行排序的優(yōu)先級視圖。

(1) 方法與視圖

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

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

(2) 視圖元素

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

(12)

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

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

(13)

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

3 DSL構建

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

圖2 領域建模概念Fig.2 Domain modeling concepts

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

抽象語法則更為重要,其定義了語言的結構,語言的組成元素及其組合的規(guī)則。通常這可以由元模型來定義。

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

確定視點與視圖等后,就可以根據(jù)以上規(guī)則來進行RAL的構建。

3.1 抽象語法

為了進行圖形化語言的構建,本文在GOPPRR(groph object properby port role relationship)的元元模型的基礎上定義RAL的抽象語法,此元元模型來自于MetaCase公司。

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

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

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

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

重疊是指通過對象之間的位置重疊,表達對象之間關系，如圖4所示。

圖4 重疊Fig.4 Overlapping

3.2 具體語法及語義

本節(jié)將介紹RAL中建模元素的具體語法以及對應的語義。具體語法的設計在MetaEdit+平臺上完成。

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

圖5 對象類實體Fig.5 Object class entity

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

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

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

圖7 過程類實體Fig.7 Process class entity

除去實體之外的建模元素是連接，連接分為結構性連接以及過程性連接。具體語法、語義如表1與表2所示。

表1 結構性連接Table 1 Structural connection

表2 過程性連接Table 2 Process connection

具體語法與語義確定之后,依托RAL的分析方法也清晰了起來。

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

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

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

4 實例分析

本節(jié)將使用RAL進行一些分析,通過具體問題來體現(xiàn)其對模型驅動設計的支持。

4.1 問題描述

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

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

在T0～T1時間段內,總指揮控制中心接受預警信息,并發(fā)布任務給有人機及無人機地面站;

在T1～T2時間段內,從有人機和無人機接受任務命令開始,對進行有人機和無人機執(zhí)行任務飛行前準備和檢測,同時進行機場的飛行前準備;

在T2～T3時間段內,有人機、無人機從有人機機場、無人機機場起飛、爬升至聚集點,無人機開始編隊飛行,有人機以安全距離跟隨飛行;

在T3～T4時間段內,無人機進入任務區(qū),將探測到的乙方情報反饋給有人機,有人機保持遠距戰(zhàn)區(qū),無人機在有人機的領導指揮下攻擊對抗乙方戰(zhàn)機;

在T4～T5時間段內,目標摧毀信息傳回機載設備和地面指揮中心,進行評估。

4.2 具體分析

取T3～T4時間段進行分析。由功能架構可以初步建立如圖8(a)所示功能分析圖。這個階段的視圖由功能清單與架構直接轉化而來,是輸入的形式化表達。這一階段的任務在使用SysML進行分析時尚可以由活動圖完成,如圖8(b)所示。

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

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

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

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

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

而使用SysML方法進行的分解工作，如圖11所示。依舊使用活動圖進行分解,同時只能進行簡單的活動順序表示,分解過程中難以保持功能分解的原則。同時可以看到,SysML的功能分解,重點在于完成任務的順序,關注的是時間跨度上的變化;而本文采用的方法著眼點在于功能的實現(xiàn),因為這是FR產生的根源。

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

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

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

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

NFR則來自于FR以及環(huán)境因素、系統(tǒng)內外部約束。在Karagoz等的方法中,主要只考慮了外部約束,并且這部分的分析較為簡單,使用表格的形式進行,沒有模型的支持,如表3表示。但在RAL中,這3種因素都可以形式化地表示出來,如圖13所示。在細化過程的基礎上,添加進內外部約束和環(huá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

同時,借由GOPPRRE元元模型靈活的表達能力,RAL也具有良好的擴展性。經過增加語法,可以完成NFR的沖突表示,如圖14所示。具體含義與判別等可參考文獻[17],示例僅對NFR的沖突進行表示。

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

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

5 結 論

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

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