何紅悅，王智學(xué)，梁豪默，王慶龍

(中國人民解放軍陸軍工程大學(xué)指揮控制工程學(xué)院，江蘇南京210007)

0 引 言

體系也稱為系統(tǒng)之系統(tǒng)(system of systems,SoS),是若干個(gè)能夠獨(dú)立運(yùn)行的系統(tǒng)為了實(shí)現(xiàn)一個(gè)共同的業(yè)務(wù)目標(biāo)而組合在一起的大規(guī)模集成系統(tǒng),具有復(fù)雜性、演化性、涌現(xiàn)性、規(guī)模性、可變性和網(wǎng)絡(luò)交互性等特征[1-2]。為了保證體系開發(fā)的合理性和有效性,在體系開發(fā)的早期,對(duì)其開展需求建模顯得尤為必要。

當(dāng)前對(duì)體系進(jìn)行需求建模主要采用體系結(jié)構(gòu)方法,即選擇一種體系結(jié)構(gòu)框架，如國防部建筑框架(department of defense architectural framework,DoDAF),UPDM、統(tǒng)一體系結(jié)構(gòu)框架(unified architecture framework,UAF)等做指導(dǎo),然后使用一種建摸語言(如:(unified modeling language,UML)[3]、(systems modeling language,SysML)[4]等)來描述相關(guān)的體系需求模型[5-6]。美軍的國防部建筑框架(ministry of defense architectural framework,DoDAF)[7]和英軍的(ministry of defense architectural framework,MODAF)[8]主要用于軍事領(lǐng)域的體系需求模型構(gòu)建。對(duì)象管理組織(object management group,OMG)則定義了2個(gè)體系結(jié)構(gòu)框架的統(tǒng)一概要——unified profile for DoDAF and MODAF(UPDM)用于指導(dǎo)企業(yè)體系的構(gòu)建,OMG又計(jì)劃將UPDM升級(jí)為UAF,UAF采用元模型來定義描述企業(yè)體系結(jié)構(gòu)所需要的模型元素與關(guān)系,體系建模人員可以采用UAF指導(dǎo)其體系模型的構(gòu)建[9]。先進(jìn)系統(tǒng)的綜合建模(comprehensive modeling for advanced systems of systems,COMPASS)項(xiàng)目開發(fā)了一種體系框架和相應(yīng)的建模過程指導(dǎo),使用SysML和COMPASS建模語言(COMPASS modeling language,CML)來構(gòu)建體系的相關(guān)模型[10]。但上述方法都沒有強(qiáng)調(diào)使命在體系需求建模中的重要作用,盡管他們中有些包含使命元素。使命是體系中各組成系統(tǒng)交互在一起的目的,是體系構(gòu)建的根本出發(fā)點(diǎn)。文獻(xiàn)[6-7]構(gòu)建了體系中使命的概念模型,然后基于該模型開發(fā)了mKAOS(missionKAOS)建模語言和工具[11,13],但該方法在使命分解中使用的是KAOS中的使命分解方法,沒有把使命的相關(guān)屬性考慮進(jìn)去,對(duì)分解的合理性和有效性難以分析。課題組前期研究了基于目標(biāo)或能力的指揮、控制、通信、計(jì)算、情報(bào)、監(jiān)視、偵察(即C4ISR)系統(tǒng)需求的相關(guān)模型構(gòu)建技術(shù),但也存在著目標(biāo)任務(wù)分解過程中沒有考慮相關(guān)屬性的問題,對(duì)分解結(jié)果難以進(jìn)行分析。

針對(duì)上述問題,本文主要圍繞基于本體的體系使命建模與分析展開研究。定義了體系中使命建模的概念模型,并設(shè)計(jì)了相應(yīng)的使命分解方法,在使命分解時(shí)引入了屬性參考,便于對(duì)結(jié)果進(jìn)行分析。然后采用本體技術(shù),將構(gòu)建的使命模型性轉(zhuǎn)化為網(wǎng)站網(wǎng)站本體語言描述邏輯(web ontology language description logic,OWL DL)本體,利用本體查詢技術(shù)來對(duì)使命模型展開分析。

1 使命概念模型

DoDAF中將使命定義為:“能夠明確表示要采取的行動(dòng)及任務(wù)的原因和目的;分配給某個(gè)個(gè)體或組織的職責(zé)”,沒有進(jìn)一步描述使命概念的相關(guān)屬性[7]。文獻(xiàn)[7]則定義了使命的5個(gè)關(guān)鍵屬性:優(yōu)先級(jí)、觸發(fā)、約束、參數(shù)和任務(wù),并通過使命模型、職責(zé)模型、對(duì)象模型、能力模型和涌現(xiàn)行為模型來描述體系的具體使命[12-13]。

使命是體系中子系統(tǒng)的任務(wù)在體系這一層次的綜合體現(xiàn)。體系中的某個(gè)使命是由部分子系統(tǒng)共同完成的,但不是這些子系統(tǒng)完成任務(wù)的簡單疊加,這些子系統(tǒng)互相協(xié)作,實(shí)施各自的活動(dòng),最終展現(xiàn)出來某個(gè)涌現(xiàn)行為,通過該涌現(xiàn)行為來實(shí)現(xiàn)相應(yīng)的使命。每個(gè)使命都有與之對(duì)應(yīng)的應(yīng)用場景和預(yù)期效果,不同使命之間存在分解、支持、沖突等關(guān)系。使命經(jīng)層層分解,最終分解為子系統(tǒng)的具體任務(wù),這些任務(wù)由子系統(tǒng)執(zhí)行某種活動(dòng)來實(shí)現(xiàn)。通過分析使命在體系需求建模中與其他概念的關(guān)系,構(gòu)建了使命的概念模型,如圖1所示。

圖1 使命概念模型Fig.1 Mission conceptual model

根據(jù)概念模型,將體系的使命定義為以下多元組:

定義1體系中的使命定義為多元組Mission=,其中

?name表示該使命的名稱;

?priority表示該使命的優(yōu)先級(jí),建模人員在進(jìn)行體系需求建模時(shí),可以根據(jù)需要定義使命優(yōu)先級(jí)的劃分范圍。

?starttime表示該使命的計(jì)劃開始時(shí)間,endtime表示該使命的計(jì)劃結(jié)束時(shí)間;

?Resource表示該使命涉及的全部資源的集合;

?Event表示該使命的觸發(fā)事件集合;

?Condition表示該使命的守護(hù)條件集合;

?Effect表示該使命的預(yù)期效果集合;

使命之間的分解、支持、沖突關(guān)系分別定義如下:

定義2使命m分解為多個(gè)使命m1，m2，…，mn，表示為:Decompose(m,{m1，m2，…，mn}),其中,m是mi的父使命,表示為Farther(m,mi),mi是m的子使命,表示為Son(mi,m),1

使命之間的支持關(guān)系可分為強(qiáng)支持和弱支持,強(qiáng)支持表示一個(gè)使命的實(shí)現(xiàn)必須依托于另一個(gè)使命的實(shí)現(xiàn),弱支持表示一個(gè)使命的實(shí)現(xiàn)不必依托于另一個(gè)使命的實(shí)現(xiàn),但另一個(gè)使命的實(shí)現(xiàn)可以增強(qiáng)該使命實(shí)現(xiàn)的最終效果。

定義3使命m1強(qiáng)支持使命m2表示為:SSupport(m1,m2)。

定義4使命m1弱支持使命m2表示為:WSupport(m1,m2)。

使命之間的沖突關(guān)系也可分為強(qiáng)沖突和弱沖突,強(qiáng)沖突表示兩個(gè)使命不可同時(shí)實(shí)現(xiàn),只能有一個(gè)實(shí)現(xiàn),弱沖突表示兩個(gè)使命可以同時(shí)出現(xiàn),但會(huì)減弱彼此的實(shí)現(xiàn)效果。

定義5使命m1強(qiáng)沖突使命m2表示為:SConflict(m1,m2)。

定義6使命m1弱沖突使命m2表示為:WConflict(m1,m2)。

2 使命分解方法

體系使命模型的構(gòu)建過程就是對(duì)體系中最高使命的分解細(xì)化過程。每個(gè)體系都有一個(gè)最高層的使命,通過對(duì)該使命進(jìn)行逐層分解,細(xì)化到體系中子系統(tǒng)能夠執(zhí)行的任務(wù),表明使命模型構(gòu)建完畢。最終的使命模型是一個(gè)以最高使命為根節(jié)點(diǎn)的使命分解樹,樹的各個(gè)非葉節(jié)點(diǎn)表示體系的各個(gè)使命,葉節(jié)點(diǎn)表示子系統(tǒng)執(zhí)行的任務(wù)。下面從分解模式、分解原則和分解樹構(gòu)建算法3個(gè)方面介紹使命分解方法。

2.1 分解模式

在面向目標(biāo)的需求分析中,對(duì)目標(biāo)的分解主要采用與/或分解模式。本文以該分解模式為基礎(chǔ),定義了體系中使命的3種分解模式。

定義7或分解模式,如果Decompose(m,{m1，m2，…，mn}),只要子使命mi實(shí)現(xiàn),父使命m就可以實(shí)現(xiàn),則稱m1，m2，…，mn為m的或分解。

定義8并行分解模式,如果Decompose(m,{m1，m2，…，mn}),所有子使命mi實(shí)現(xiàn)后,父使命m才實(shí)現(xiàn),并且子使命的實(shí)現(xiàn)是各自獨(dú)立完成的,沒有任何先后關(guān)系,則稱m1，m2，…，mn為m的并行分解。

定義9串行分解模式,如果Decompose(m,{m1，m2，…，mn}),所有子使命mi實(shí)現(xiàn)后,父使命m才實(shí)現(xiàn),并且mi-1結(jié)束后,mi才開始,則稱m1，m2，…，mn為m的串行分解。

2.2 分解原則

在使命的逐層分解過程中,為了保證各層使命之間在屬性值上的一致性,即子使命的屬性值不能與父使命的屬性值發(fā)生沖突,要求在使命分解過程中遵守以下原則:

(1) 優(yōu)先級(jí)原則

使命的優(yōu)先級(jí)是可以通過父使命傳遞給各個(gè)子使命的,如果使命m1的優(yōu)先級(jí)高于使命m2的優(yōu)先級(jí),則使命m1的子使命的優(yōu)先級(jí)不能低于使命m2的子使命的優(yōu)先級(jí)。在使命分解過程中,為了保持優(yōu)先級(jí)的傳遞性,要求每個(gè)子使命的優(yōu)先級(jí)不能高于父使命的優(yōu)先級(jí)。

(2) 時(shí)間原則

所有子使命的處理時(shí)間窗口應(yīng)在父使命的處理時(shí)間窗口之內(nèi)。在或分解模式和并行分解模式下,任意子使命mi的計(jì)劃開始時(shí)間不能早于父使命的計(jì)劃開始時(shí)間,計(jì)劃結(jié)束時(shí)間不能晚于父使命的計(jì)劃結(jié)束時(shí)間。在串行分解模式下,子使命m1的計(jì)劃開始時(shí)間不能早于父使命的計(jì)劃開始時(shí)間,子使命mn的計(jì)劃結(jié)束時(shí)間不能晚于父使命的計(jì)劃結(jié)束時(shí)間。

(3) 資源原則

所有子使命的資源集合的并集正好是父使命的資源集,即∪Resourcei(1≤i≤n)=Resource。

(4) 事件原則

在或分解模式和并行分解模式下,所有子使命的事件集合的并集正好是父使命的事件集,即∪Eventi(1≤i≤n)=Event。在串行分解模式下,子使命m1的事件集是父使命的事件集,即Event1=Event。

(5) 守護(hù)條件原則

所有子使命的守護(hù)條件集合的并集正好是父使命的守護(hù)條件集,即∪Conditioni(1≤i≤n)=Condition。

2.3 分解樹構(gòu)建算法

體系的使命分解由最高層的使命開始,最終分解得到以該使命為根節(jié)點(diǎn)的使命分解樹。使命分解樹構(gòu)建算法如下:

輸入體系的最高層使命m。

輸出使命分解樹T。

算法過程:

步驟1創(chuàng)建一個(gè)使命隊(duì)列Qm,將使命m添加到隊(duì)列Qm中,然后創(chuàng)建僅包含使命m的樹T;

步驟2從隊(duì)列Qm中取出一個(gè)使命m′;

步驟2.1如果使命m′可以分解,則使用相應(yīng)的分解模式,將使命m′分解為m1，m2，…，mn,將分解得到的使命添加到隊(duì)列Qm中,并將這些使命作為使命m′的子節(jié)點(diǎn)添加到使命樹T中,最后將使命m′從隊(duì)列Qm中刪去;

步驟2.2如果使命m′采用的是串行分解模式,在使命樹T中建立各個(gè)子節(jié)點(diǎn)的時(shí)序指針;

步驟2.3如果使命m′不可分解,則將使命m′映射到體系中子系統(tǒng)執(zhí)行的某個(gè)任務(wù)上,最后將使命m′從隊(duì)列Qm中刪去;

步驟2.4如果隊(duì)列不為空,則繼續(xù)執(zhí)行步驟2;

步驟3分析使命樹T中各個(gè)使命之間的支持、沖突關(guān)系,并將這些關(guān)系指針添加到使命樹T中。

步驟4返回構(gòu)建完成的使命分解樹T。

3 模型形式化

為了使用本體技術(shù)對(duì)構(gòu)建的使命模型進(jìn)行分析,需要將使命模型形式化為OWL DL表示的本體知識(shí)庫。OWL DL是一種本體描述語言,以描述邏輯SROIN為邏輯基礎(chǔ)。OWL DL本體分為類和實(shí)例兩部分。在形式化使命模型時(shí),需要將使命概念模型中的相關(guān)概念形式化為描述邏輯SROIN知識(shí)庫中的Tbox,即轉(zhuǎn)化為OWL DL本體的類定義;將使命模型中的各個(gè)使命形式化為描述邏輯SROIN知識(shí)庫中的Abox,即轉(zhuǎn)化為OWL DL本體的實(shí)例聲明。

根據(jù)使命模型分析的需要,從使命概念模型中提取的描述邏輯SROIN知識(shí)庫的類和關(guān)系分別如表1、表2所示。

表1 使命模型類列表

表2 使命模型關(guān)系列表

根據(jù)提取的類和關(guān)系及構(gòu)建的使命模型來構(gòu)建描述邏輯SROIN知識(shí)庫,即分別構(gòu)建知識(shí)庫的Tbox和Abox。下面介紹兩者的構(gòu)建算法,首先是構(gòu)建Tbox的算法:

輸入表1和表2。

輸出Tbox。

算法過程:

步驟1創(chuàng)建一個(gè)空Tbox;

步驟2對(duì)表1中的概念C,在Tbox中創(chuàng)建與C同名的類;

步驟3對(duì)表2中的關(guān)系R=(C1,C2),在知識(shí)庫Tbox中添加類公理C1??R.C2和C2??R～.C1,R～為R的逆關(guān)系;

步驟4對(duì)關(guān)系R在值域C2端的基數(shù)約束“0.1”、“1.*”、“1”,在知識(shí)庫Tbox中分別添加類公理C1?≤1R.C2(表示約束“0.1”,即和C1有R關(guān)系的C2個(gè)體最多有一個(gè))、C1?≥1R.C2(表示約束“1.*”,即和C1有R關(guān)系的C2個(gè)體至少有一個(gè))、C1?≤1R.C2(表示約束“1”,即和C1有R關(guān)系的C2個(gè)體僅有一個(gè))和C1?≥1R.C2(表示約束“1”,即和C1有R關(guān)系的C2個(gè)體僅有一個(gè));

步驟5對(duì)關(guān)系R在定義域C1端的基數(shù)約束“0.1”、“1.*”、“1”,在知識(shí)庫Tbox中分別添加類公理C2?≤1R～.C1(表示約束“0.1”,即和C2有R關(guān)系的C1個(gè)體最多有一個(gè))、C2?≥1R～.C1(表示約束“1.*”, 即和C2有R關(guān)系的C1個(gè)體至少有一個(gè))、C2?≤1R～.C1(表示約束“1”,即和C2有R關(guān)系的C1個(gè)體最僅有一個(gè))和C2?≥1R～.C1(表示約束“1”,即和C2有R關(guān)系的C1個(gè)體最僅有一個(gè)),R～為R的逆關(guān)系;

步驟6返回Tbox。

創(chuàng)建Abox的算法如下:

輸入使命模型

輸出Abox

算法過程:

步驟1創(chuàng)建一個(gè)空Abox;

步驟2遍歷使命模型中使命分解樹的每個(gè)使命節(jié)點(diǎn)m=,在Abox中添加個(gè)體聲明Mission(name)、Resource(resourcei)、Event(eventi)、Condition(conditioni)和Effect(effecti),添加關(guān)系聲明Priority(name,priority)、Starttime(name,starttime)、Endtime(name,endtime)、Trigger(eventi,name)、Constraint(conditioni,name)和Concern(name,resourcei),其中i表示對(duì)于集合Resource、Event、Condition中的任意一個(gè)元素都執(zhí)行該操作;

步驟3對(duì)于使命節(jié)點(diǎn)m和它的父節(jié)點(diǎn)m′,添加關(guān)系聲明Decompose(m′,m);如果m和其他使命節(jié)點(diǎn)m1之間存在支持、沖突、串行等關(guān)系,添加相應(yīng)的關(guān)系聲明SSupport(m,m1)、SConflict(m,m1)、WSupport(m,m1)、WConflict(m,m1)、Sequence(m,m1);

步驟4返回Abox。

OWL DL本體的邏輯基礎(chǔ)是描述邏輯SROIN[14],將構(gòu)建得到的知識(shí)庫Tbox和Abox使用OWL Dl語言描述出來,從而得到了使命模型的OWL DL本體。

4 模型分析

使命模型的優(yōu)劣會(huì)影響到體系后續(xù)的開發(fā)建設(shè)工作,因此需要對(duì)使命模型進(jìn)行分析,及早發(fā)現(xiàn)模型中的錯(cuò)誤。本文使命模型分析中主要關(guān)注兩個(gè)方面:一是使命分解中是否遵守了5個(gè)分解原則;二是分解的使命之間在沖突、支持和串行關(guān)系上是否存在矛盾。本文使用本體查詢方法來檢測(cè)使命模型中可能存在問題,將這些檢查問題轉(zhuǎn)換為用SPARQL(simple protocol and RDF query language)[15]表示的本體查詢規(guī)則,然后利用本體推理引擎Pellet,針對(duì)每條查詢規(guī)則對(duì)使命模型的OWL DL本體進(jìn)行查詢,查找模型中是否存在有問題的使命。具體查詢規(guī)則如下:

(1) 優(yōu)先級(jí)原則檢查,即檢查模型中是否存在違背優(yōu)先級(jí)原則的使命節(jié)點(diǎn),SPARQL查詢規(guī)則如下:

SELECT?m WHERE{?m rdf:type xmlns:Mission.? a xmlns:Decompose?m.?m xmlns:Priority?b.?a xmlns:Priority?c.?b swrl:bigger?c.}.

(2) 時(shí)間原則檢查,即檢查模型中是否存在違背時(shí)間原則的使命節(jié)點(diǎn),SPARQL查詢規(guī)則如下:

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?m xmlns:Starttime ?b. ?a xmlns: Starttime ?c. ?c swrl:bigger?b.};

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?m xmlns:Endtime ?b. ?a xmlns:Endtime ?c. ?b swrl:bigger?c.}。

(3) 資源原則檢查,即檢查模型中是否存在違背資源原則的使命節(jié)點(diǎn),SPARQL查詢規(guī)則如下:

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?m xmlns:Concern ?b. UNSAID {?a xmlns:Concern ?b.}.}。

(4) 事件原則檢查,即檢查模型中是否存在違背事件原則的使命節(jié)點(diǎn),SPARQL查詢規(guī)則如下:

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?b xmlns:Trigger?m. UNSAID {?b xmlns:Trigger ?a.}.}。

(5) 守護(hù)條件原則,即檢查模型中是否存在違背守護(hù)條件原則的使命節(jié)點(diǎn),SPARQL查詢規(guī)則如下:

SELECT ?m WHERE {?m rdf:type xmlns:Mission. ?a xmlns:Decompose ?m. ?b xmlns:Constraint ?m. UNSAID {?b xmlns:Constraint ?a.}.}。

(6) 模型中是否存在兩個(gè)使命,彼此之間既是支持關(guān)系,又是沖突關(guān)系,SPARQL查詢規(guī)則如下:

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:SSupport ?n. ?m xmlns:SConflict ?n.};

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:SSupport ?n. ?m xmlns:WConflict ?n.};

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:WSupport ?n. ?m xmlns:SConflict ?n.};

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:WSupport ?n. ?m xmlns:WConflict ?n.}。

(7) 模型中是否存時(shí)序沖突的使命組合,如果m1和m2之間存在時(shí)序關(guān)系,m3和m4之間存在時(shí)序關(guān)系,m1和m4之間存在強(qiáng)支持關(guān)系,m2和m3之間存在強(qiáng)支持關(guān)系,則m1和m2之間的時(shí)序關(guān)系與m3和m4之間的時(shí)序關(guān)系存在沖突。SPARQL查詢規(guī)則如下:

SELECT ?m ?n ?a ?b WHERE {?m xmlns:Support ?b. ?n xmlns:SSupport ?a. ?m xmlns:Sequence ?n. ?a xmlns:Sequence ?b.}。

(8) 模型中是否存在2個(gè)使命,彼此之間既是強(qiáng)支持關(guān)系,又是串行關(guān)系,但被支持使命在支持使命開始時(shí)就結(jié)束了,SPARQL查詢規(guī)則如下:

SELECT ?m ?n WHERE {?m rdf:type xmlns:Mission. ?n rdf:type xmlns:Mission. ?m xmlns:SSupport ?n. ?n xmlns:Sequence ?m.}。

5 案例分析

軍事電子信息系統(tǒng)是軍隊(duì)體系作戰(zhàn)的重要支撐,由多個(gè)相關(guān)業(yè)務(wù)領(lǐng)域的子系統(tǒng)構(gòu)成,是軍事和國防領(lǐng)域的一個(gè)體系[16]。以軍事電子信息系統(tǒng)中的區(qū)域防空指揮系統(tǒng)為例,采用本文的方法構(gòu)建其需求建模中的使命模型。如圖2所示為建模工具構(gòu)建的區(qū)域防空指揮系統(tǒng)的使命模型(項(xiàng)目組根據(jù)本文提出的方法開發(fā)了一個(gè)建模與分析工具)。

圖2 區(qū)域防空指揮系統(tǒng)使命模型Fig.2 Mission model of regional air defense command system

在該使命模型中,“獲取信息優(yōu)勢(shì)”和“目標(biāo)攔截”雖然是兩個(gè)獨(dú)立的使命,但獲取戰(zhàn)場的信息優(yōu)勢(shì)可以增大對(duì)入侵空域目標(biāo)的攔截成功率,因此在他們的子使命中,存在著相互關(guān)系。“獲取信息優(yōu)勢(shì)”中子使命“電子偵查”可以串行分解為3個(gè)順序關(guān)系的子使命:目標(biāo)識(shí)別、目標(biāo)定位和目標(biāo)跟蹤。目標(biāo)攔截子使命導(dǎo)彈攔截可以串行分解為兩個(gè)順序關(guān)系的子使命:發(fā)現(xiàn)目標(biāo)和導(dǎo)彈攔截。其中發(fā)現(xiàn)目標(biāo)需要目標(biāo)識(shí)別和目標(biāo)定位的強(qiáng)支持,導(dǎo)彈摧毀需要目標(biāo)跟蹤的強(qiáng)支持。由于目標(biāo)識(shí)別和目標(biāo)定位是順序關(guān)系,根據(jù)強(qiáng)支持關(guān)系的含義,目標(biāo)識(shí)別和發(fā)現(xiàn)目標(biāo)之間的強(qiáng)支持關(guān)系是多余的。通過本體查詢,使用查詢規(guī)則7,就可以檢查出存在的多余關(guān)系。

6 結(jié)束語

對(duì)體系進(jìn)行需求建模分析是體系早期獲得相關(guān)信息并用于輔助體系設(shè)計(jì)、分析與論證的重要手段,其中使命建模在體系需求建模中處于重要地位。本文研究了基于本體的體系使命建模與分析方法。從分析體系的使命概念模型入手,根據(jù)體系中使命概念模型,設(shè)計(jì)了體系使命模型的構(gòu)建方法。為了分析構(gòu)建后的使命模型,將模型形式化為OWL DL本體,并將分析檢查的內(nèi)容轉(zhuǎn)化為本體查詢規(guī)則,借助本體推理工具實(shí)現(xiàn)模型分析功能。針對(duì)不同的檢查內(nèi)容可以設(shè)計(jì)相應(yīng)的查詢規(guī)則,使得模型的分析具有靈活性和可擴(kuò)展性。