面向指揮控制軟件集成的工作流建模方法

李佳鋒 聶坤明 胡春燕 周武

1．中國(guó)航天科工集團(tuán)有限公司第四研究院北京航天晨信科技有限責(zé)任公司北京102300

隨著信息技術(shù)和科學(xué)技術(shù)的飛速發(fā)展, 與以往戰(zhàn)爭(zhēng)相比,現(xiàn)代戰(zhàn)爭(zhēng)不論在戰(zhàn)爭(zhēng)形態(tài),還是在運(yùn)行規(guī)律方面都發(fā)生了翻天覆地的變化, 信息化戰(zhàn)爭(zhēng)越來(lái)越復(fù)雜,不再是平臺(tái)對(duì)平臺(tái)的對(duì)抗,而是體系與體系的對(duì)抗[1?2]. 指揮控制系統(tǒng)是為完成作戰(zhàn)任務(wù)服務(wù)的應(yīng)用系統(tǒng), 隨著信息系統(tǒng)在軍事領(lǐng)域的應(yīng)用以及軍事技術(shù)的不斷發(fā)展, 使得指揮控制的地位與作用不斷提升, 爭(zhēng)奪指揮控制的優(yōu)勢(shì)成為現(xiàn)代戰(zhàn)爭(zhēng)對(duì)抗最為激烈的焦點(diǎn). 指揮流程強(qiáng)調(diào)指揮相關(guān)的工作流程,是由一系列相對(duì)明確、先后有序、首尾銜接的若干階段或基本環(huán)節(jié)所構(gòu)成的一個(gè)特定的過(guò)程, 是指揮者從事指揮活動(dòng)的基本程序, 能夠反映不同指揮模式下的作戰(zhàn)指揮活動(dòng)規(guī)律[3]. 指揮控制系統(tǒng)面向特定作戰(zhàn)需求定制而成,功能使命單一、流程固定,各系統(tǒng)間集成難度大. 指揮控制系統(tǒng)根據(jù)新的指揮作戰(zhàn)需求添加相應(yīng)的功能,“邊建設(shè)、邊驗(yàn)證”的發(fā)展途徑導(dǎo)致現(xiàn)有的指揮控制系統(tǒng)圍繞各級(jí)各類指揮所定制設(shè)計(jì),每個(gè)系統(tǒng)的功能固定、流程固定, 形成了一個(gè)個(gè)“煙囪”. 一旦原有的指揮關(guān)系、指揮規(guī)則或指揮模式發(fā)生變化, 流程間的緊耦合性導(dǎo)致需要將原有的指揮控制系統(tǒng)推倒重建,大大浪費(fèi)了人力、物力和財(cái)力. 隨著裝備水平的提升和國(guó)際形勢(shì)的變化,未來(lái)的任務(wù)使命趨于多樣化,而現(xiàn)有的指揮控制系統(tǒng),軟件架構(gòu)不同, 內(nèi)部功能耦合度高, 不易深度集成, 依靠在“煙囪”間架設(shè)“橋梁”的方式,存在同步效率低和聯(lián)動(dòng)性差的問(wèn)題.

指揮控制系統(tǒng)的部署環(huán)境也是多樣化的, 指揮控制系統(tǒng)既可能部署在固定的指揮大廳里, 也可能部署在空間狹小、設(shè)施簡(jiǎn)陋的指揮車?yán)? 所以沒(méi)有一種指揮控制系統(tǒng)能夠滿足所有指揮控制系統(tǒng)形態(tài)的需求, 但是針對(duì)各形態(tài)均開(kāi)發(fā)相應(yīng)的系統(tǒng)存在成本高、浪費(fèi)大和周期長(zhǎng)等問(wèn)題.面向多樣化需求的靈活重構(gòu)能力是未來(lái)指揮控制系統(tǒng)的必備能力[4?5].

為了滿足指揮控制系統(tǒng)面向多樣化任務(wù)靈活重構(gòu)的需求, 提出基于工作流引擎的指揮控制軟件插件集成方法, 由工作流引擎驅(qū)動(dòng)指揮控制軟件插件的動(dòng)態(tài)集成. 其中,工作流過(guò)程建模是工作流技術(shù)應(yīng)用的重要環(huán)節(jié), 工作流引擎根據(jù)構(gòu)建的模型來(lái)解析和執(zhí)行流程.

在現(xiàn)有的指揮控制軟件工作流建模方法中, 缺少對(duì)于時(shí)間要素的建模, 不能夠準(zhǔn)確表示對(duì)作戰(zhàn)活動(dòng)的時(shí)間約束, 無(wú)法滿足指揮控制軟件的應(yīng)用需求,尤其是對(duì)于時(shí)敏目標(biāo)的打擊, 要求在有限的時(shí)間內(nèi)完成決策、機(jī)動(dòng)、鎖定、攻擊和毀傷評(píng)估等所有作戰(zhàn)活動(dòng),某一環(huán)節(jié)出現(xiàn)超時(shí)問(wèn)題會(huì)導(dǎo)致流程無(wú)法運(yùn)轉(zhuǎn).現(xiàn)有的建模方法由于柔性不足, 導(dǎo)致無(wú)法很好地對(duì)突發(fā)流程等情況進(jìn)行處理,而在戰(zhàn)場(chǎng)環(huán)境下,需要對(duì)于各種可能的情況進(jìn)行處理, 迫切需要實(shí)現(xiàn)業(yè)務(wù)流程的柔性變化. 為了實(shí)現(xiàn)工作流驅(qū)動(dòng)的指揮控制軟件插件集成,需要實(shí)現(xiàn)插件的動(dòng)態(tài)匹配,由于工作流模型中缺少插件的相關(guān)描述信息, 無(wú)法實(shí)現(xiàn)指揮控制軟件的自動(dòng)集成. 信息是流程流轉(zhuǎn)的關(guān)鍵,也是指揮控制過(guò)程中不可缺少的一部分. 本文將從時(shí)間建模、柔性建模、信息建模和插件描述信息建模4 個(gè)方面對(duì)現(xiàn)有的指揮控制軟件工作流建模方法進(jìn)行擴(kuò)展.

本文以UML 活動(dòng)圖為核心,針對(duì)UML 活動(dòng)圖存在的問(wèn)題、指揮控制軟件插件集成需求和工作流柔性需求,提出改進(jìn)的基于UML 的工作流建模方法.針對(duì)泳道存在不易修改、不易理解等問(wèn)題,提出在活動(dòng)節(jié)點(diǎn)中添加活動(dòng)執(zhí)行者信息來(lái)簡(jiǎn)化組織結(jié)構(gòu)關(guān)系;針對(duì)活動(dòng)圖活動(dòng)節(jié)點(diǎn)單一的問(wèn)題, 根據(jù)工作流模型的特點(diǎn),將活動(dòng)節(jié)點(diǎn)分為人工活動(dòng)和自動(dòng)活動(dòng);針對(duì)活動(dòng)節(jié)點(diǎn)缺少時(shí)間信息的問(wèn)題, 在順序流中添加時(shí)間信息, 加強(qiáng)活動(dòng)執(zhí)行時(shí)間的約束(最長(zhǎng)持續(xù)時(shí)間、最晚結(jié)束時(shí)間), 并提高流程柔性; 針對(duì)活動(dòng)圖缺少調(diào)用外部程序的相關(guān)信息,提出對(duì)類圖進(jìn)行擴(kuò)展,使用類圖描述對(duì)應(yīng)活動(dòng)節(jié)點(diǎn)所需插件的相關(guān)描述信息;針對(duì)現(xiàn)有模型無(wú)法滿足戰(zhàn)場(chǎng)實(shí)時(shí)變化引起的指揮控制流程中活動(dòng)節(jié)點(diǎn)實(shí)時(shí)變化的問(wèn)題, 提出在活動(dòng)節(jié)點(diǎn)中定義一個(gè)與當(dāng)前活動(dòng)對(duì)應(yīng)的狀態(tài)信息字段, 實(shí)現(xiàn)節(jié)點(diǎn)的柔性化, 并盡可能考慮更多的可能性實(shí)現(xiàn)流程的柔性化. 針對(duì)現(xiàn)有指揮控制工作流模型中缺少信息建模的問(wèn)題, 提出動(dòng)態(tài)和靜態(tài)信息融合的信息模型, 支持通過(guò)動(dòng)態(tài)信息模型了解流程中的信息流轉(zhuǎn), 通過(guò)靜態(tài)信息模型判斷所建流程模型能否滿足信息訂閱的需求.

1 相關(guān)研究

現(xiàn)有的建模技術(shù)包括基于圖形符號(hào)的建模技術(shù)、基于數(shù)學(xué)的建模技術(shù)和基于圖形符號(hào)且基于數(shù)學(xué)的建模技術(shù)Petri 網(wǎng)及其擴(kuò)展[5]. UML 是一種通用的可視化建模語(yǔ)言, 是面向?qū)ο蠓治雠c設(shè)計(jì)的標(biāo)準(zhǔn), 能夠?yàn)橄到y(tǒng)業(yè)務(wù)流程提供可視化的分析與設(shè)計(jì)[6],從而闡明系統(tǒng)“要做什么—>由誰(shuí)去做—>如何去做—>何時(shí)做—>做的順序怎么樣”這樣一個(gè)核心問(wèn)題.

流程模型是對(duì)業(yè)務(wù)流程定義的基本元素和規(guī)則的抽象,并加以一般性描述,用于指導(dǎo)業(yè)務(wù)流程管理與插件集成的過(guò)程建模. 流程一般由開(kāi)始節(jié)點(diǎn)、結(jié)束節(jié)點(diǎn)、控制節(jié)點(diǎn)以及若干個(gè)活動(dòng)節(jié)點(diǎn)組成[7].

目前在各種領(lǐng)域已經(jīng)有許多可視化的流程建模方法, 主要的流程建模方式有基于Petri 網(wǎng)建模、基于事件驅(qū)動(dòng)的過(guò)程鏈建模、事務(wù)流程建模、基于語(yǔ)言模型的流程建模、基于活動(dòng)網(wǎng)絡(luò)的流程建模、基于狀態(tài)機(jī)的流程建模和基于UML 的流程建模[8].

使用UML 對(duì)工作流過(guò)程進(jìn)行建模,已有不少同行做過(guò)相關(guān)的工作.有的同行僅使用UML 完成工作流建模,有的同行根據(jù)UML 在工作流建模中存在的不足,提出了改進(jìn)的方法. 馬云龍針對(duì)UML 易于理解、可視化以及UML 動(dòng)態(tài)特定與工作流業(yè)務(wù)流程相吻合的特點(diǎn),使用多種UML 視圖完成工作流模型的構(gòu)建[9]. 朱璇等使用UML 模型實(shí)現(xiàn)了聯(lián)合作戰(zhàn)方案計(jì)劃的可視化視圖建模, 構(gòu)建了時(shí)間視圖、信息視圖和空間視圖, 將多維復(fù)雜的戰(zhàn)場(chǎng)數(shù)據(jù)信息進(jìn)行簡(jiǎn)明表述, 實(shí)現(xiàn)了戰(zhàn)場(chǎng)數(shù)據(jù)信息的高效表達(dá)[10]. 吳雷等針對(duì)傳統(tǒng)軟件建模方法無(wú)法滿足企業(yè)資源計(jì)劃(Enterprise Resource Planning,ERP)業(yè)務(wù)模型到模型驅(qū)動(dòng)架構(gòu)(Model Driven Architecture, MDA)下模型轉(zhuǎn)換的需求, 對(duì)工作流定義元模型進(jìn)行改進(jìn)并基于UML 的輕量級(jí)擴(kuò)展機(jī)制,建立了UML Profile 通過(guò)實(shí)例論證了模型理論的可行性[11]. 郝可針對(duì)傳統(tǒng)業(yè)務(wù)流程不可重入,難以完全適應(yīng)戰(zhàn)場(chǎng)變化,提出流程節(jié)點(diǎn),體現(xiàn)業(yè)務(wù)流程的柔性變化,并給出了引入流程節(jié)點(diǎn)后業(yè)務(wù)流程的柔性變化以及相應(yīng)的規(guī)則, 與現(xiàn)有的模型相比較,其更適合戰(zhàn)場(chǎng)環(huán)境,但是對(duì)日志數(shù)據(jù)的利用度不高, 而且沒(méi)有給出實(shí)際的建模方法和工具[12]. 魏然為了滿足指揮控制流程對(duì)任務(wù)動(dòng)態(tài)更改的需求,縮短流程執(zhí)行周期,針對(duì)傳統(tǒng)工作流中節(jié)點(diǎn)靜態(tài)、固化的現(xiàn)狀,對(duì)任務(wù)狀態(tài)空間進(jìn)行分析,提出對(duì)流程節(jié)點(diǎn)增加部分提交狀態(tài), 實(shí)現(xiàn)流程任務(wù)的多次提交,通過(guò)仿真實(shí)驗(yàn),驗(yàn)證了該方法提升了流程的并行性和動(dòng)態(tài)性[13].

上述針對(duì)UML 活動(dòng)圖的改進(jìn)方法解決了使用UML 構(gòu)建工作流過(guò)程模型的部分問(wèn)題,但是這些改進(jìn)尚不能滿足本文在建模過(guò)程中完成時(shí)間建模、柔性建摸、信息建模以及插件描述建模的需求.

2 基于UML 的工作流建模

2.1 UML 活動(dòng)圖與工作流模型的映射

工作流的建模過(guò)程是對(duì)動(dòng)態(tài)的業(yè)務(wù)過(guò)程建模,是圍繞活動(dòng)進(jìn)行的, 活動(dòng)是其最小且不可分割的基本元素.在UML 的動(dòng)態(tài)模型中, 活動(dòng)圖主要由狀態(tài)和轉(zhuǎn)換兩種元素組成, 描述了一組順序或并發(fā)執(zhí)行的活動(dòng), 以及活動(dòng)到活動(dòng)之間的流轉(zhuǎn)關(guān)系, 活動(dòng)狀態(tài)可代表工作流中一個(gè)步驟或者一個(gè)操作的執(zhí)行.UML 活動(dòng)圖的元素和工作流過(guò)程定義元素有許多相似之處,因此,UML 活動(dòng)圖能夠?qū)崿F(xiàn)對(duì)工作流模型的描述, 本文擬將活動(dòng)圖作為工作流過(guò)程建模的主要模型.

現(xiàn)有的UML 活動(dòng)圖元素與工作流模型間的映射關(guān)系如下[14]:

1)將UML 活動(dòng)圖中的動(dòng)作狀態(tài)映射為工作流過(guò)程模型中的活動(dòng)節(jié)點(diǎn).

2)將UML 活動(dòng)圖中的初始狀態(tài)和終止?fàn)顟B(tài)映射為工作流過(guò)程模型中的開(kāi)始節(jié)點(diǎn)和結(jié)束節(jié)點(diǎn).

3)將UML 活動(dòng)圖中的表示活動(dòng)間轉(zhuǎn)移的控制流映射為工作流過(guò)程模型中活動(dòng)節(jié)點(diǎn)間的順序流.

4)將UML 活動(dòng)圖中的分支與合并元素映射為工作流過(guò)程模型中的條件網(wǎng)關(guān)和并行網(wǎng)關(guān)分散圖元.

5)將UML 活動(dòng)圖中的分叉和匯合元素映射為工作流過(guò)程模型中的并行網(wǎng)關(guān)的匯聚圖元.

通過(guò)以上UML 活動(dòng)圖元素和工作流元素之間的映射,描述了工作流的多種屬性和相應(yīng)的狀態(tài),但是仍不能完全滿足指揮控制軟件插件集成需求和工作流柔性需求.

2.2 指揮控制軟件插件集成建模需求

2.2.1 集成建模需求

為了實(shí)現(xiàn)指揮控制軟件的動(dòng)態(tài)集成, 采用基于插件的集成方法, 在指揮控制軟件插件開(kāi)發(fā)和入庫(kù)的前提下,利用工作流引擎驅(qū)動(dòng),實(shí)現(xiàn)基于規(guī)則的功能模塊動(dòng)態(tài)按需加載. 將指揮控制工作流模型中的活動(dòng)節(jié)點(diǎn)與指揮控制軟件插件關(guān)聯(lián), 在指揮控制流程執(zhí)行過(guò)程中,通過(guò)獲取關(guān)聯(lián)的插件信息,實(shí)現(xiàn)對(duì)相應(yīng)插件的調(diào)用并完成任務(wù).因此,需要實(shí)現(xiàn)指揮控制軟件插件的集成建模.

1)插件描述需求. 工作流在執(zhí)行的時(shí)候會(huì)與外部應(yīng)用有一定的交互, 這種交互的實(shí)現(xiàn)需要知道交互應(yīng)用的相關(guān)信息, 以保證在工作流執(zhí)行過(guò)程中能夠正確調(diào)用相應(yīng)的外部應(yīng)用, 并完成任務(wù). 在UML活動(dòng)圖中缺少被調(diào)用應(yīng)用的相關(guān)圖元, 本文提出一種通過(guò)對(duì)類圖進(jìn)行擴(kuò)展的方法, 完成對(duì)所調(diào)用外部插件的描述. 在插件描述的構(gòu)造型中添加對(duì)應(yīng)活動(dòng)節(jié)點(diǎn)的信息, 從而建立指揮控制軟件插件與活動(dòng)節(jié)點(diǎn)的對(duì)應(yīng)關(guān)系. 插件描述信息從不同的方面對(duì)插件進(jìn)行系統(tǒng)的描述,如:插件的功能信息、插件的接口信息和插件運(yùn)行所需的環(huán)境信息.

a)插件的功能信息包括功能名稱和是否擁有圖形界面.

b)插件的接口信息包括輸入的參數(shù)類型列表和返回的參數(shù)類型等.

c)插件的環(huán)境信息包括硬件環(huán)境和軟件環(huán)境兩部分. 硬件環(huán)境由最低計(jì)算機(jī)配置(內(nèi)存和硬盤等)和網(wǎng)絡(luò)要求等組成; 軟件環(huán)境由操作系統(tǒng)和數(shù)據(jù)庫(kù)等組成.

2)信息建模需求. 作戰(zhàn)信息需求是為武器裝備、作戰(zhàn)部隊(duì)和指揮控制系統(tǒng)提供的作戰(zhàn)所需信息的總和. 信息建模是實(shí)現(xiàn)指揮控制軟件插件集成的重要支撐. 針對(duì)目前的工作流建模方法中缺少信息建模的問(wèn)題,提出擴(kuò)展UML 描述作戰(zhàn)信息的方法, 實(shí)現(xiàn)對(duì)動(dòng)態(tài)信息和靜態(tài)信息的刻畫.

3)角色建模需求. 在工作流模型中,角色是必不可少的一部分,是活動(dòng)的執(zhí)行者. 在指揮控制流程執(zhí)行過(guò)程中, 工作流引擎通過(guò)解析工作流模型將插件調(diào)用信息發(fā)送給登錄用戶與活動(dòng)執(zhí)行者一致的插件平臺(tái)客戶端,因此,需要指定活動(dòng)的執(zhí)行者. 在UML活動(dòng)圖中活動(dòng)執(zhí)行者的指定是通過(guò)泳道實(shí)現(xiàn)的, 存在不易修改的問(wèn)題,本文放棄泳道圖元,在活動(dòng)節(jié)點(diǎn)中添加角色信息.

2.2.2 指揮控制軟件插件集成建模需求與工作流模型的映射

通過(guò)對(duì)UML 活動(dòng)圖和類圖的擴(kuò)展,增加以下映射關(guān)系:

1)通過(guò)對(duì)UML 類圖的改進(jìn), 實(shí)現(xiàn)插件描述圖元,映射為工作流過(guò)程模型中的擴(kuò)展信息.

2)通過(guò)對(duì)控制流的擴(kuò)展實(shí)現(xiàn)動(dòng)態(tài)信息建模, 并結(jié)合插件描述信息中的輸入輸出參數(shù)映射為工作流過(guò)程模型中的流程變量.

3)將UML 活動(dòng)圖中的動(dòng)作狀態(tài)劃分為人工動(dòng)作和自動(dòng)動(dòng)作, 并分別映射成工作流過(guò)程模型中的人工活動(dòng)和自動(dòng)活動(dòng).

4)舍棄UML 活動(dòng)圖的泳道,通過(guò)對(duì)人工動(dòng)作狀態(tài)的擴(kuò)展實(shí)現(xiàn)角色的確定, 將其映射成工作流過(guò)程模型中的角色.

5)通過(guò)UML 組織結(jié)構(gòu)圖描述人員、角色、部門和職務(wù)間的關(guān)系, 并且映射成工作流過(guò)程模型所需的人員、組和權(quán)限關(guān)系.

2.3 指揮控制工作流柔性建模需求

2.3.1 柔性建模需求

在現(xiàn)代戰(zhàn)爭(zhēng)中, 戰(zhàn)場(chǎng)環(huán)境充斥著不確定性和偶然性[15],戰(zhàn)場(chǎng)態(tài)勢(shì)是瞬息萬(wàn)變的,已有的指揮控制工作流建模方法中的業(yè)務(wù)流程都是固定的, 不能根據(jù)實(shí)際的戰(zhàn)場(chǎng)情況靈活變化, 難以實(shí)現(xiàn)指揮控制系統(tǒng)的敏捷性和適應(yīng)性. 因此,提出柔性的機(jī)動(dòng)指揮控制工作流建模方法.

指揮控制工作流的柔性體現(xiàn)在流程應(yīng)對(duì)指揮控制業(yè)務(wù)節(jié)點(diǎn)變更和調(diào)整的便利性, 能夠針對(duì)不同的突發(fā)情況, 根據(jù)實(shí)際情況對(duì)已有的指揮控制業(yè)務(wù)工作流模型的流程實(shí)例進(jìn)行及時(shí)調(diào)整, 以滿足當(dāng)前流程的突發(fā)情況, 實(shí)現(xiàn)指揮控制系統(tǒng)的敏捷性和自適應(yīng)性. 本文將從節(jié)點(diǎn)柔性、流程柔性和時(shí)間柔性3 方面進(jìn)行考慮.

1)節(jié)點(diǎn)柔性. 節(jié)點(diǎn)柔性是指根據(jù)當(dāng)前戰(zhàn)場(chǎng)態(tài)勢(shì)判斷該活動(dòng)節(jié)點(diǎn)對(duì)應(yīng)的任務(wù)是否需要執(zhí)行, 若活動(dòng)節(jié)點(diǎn)對(duì)應(yīng)任務(wù)可不執(zhí)行或當(dāng)前活動(dòng)節(jié)點(diǎn)對(duì)應(yīng)的作戰(zhàn)實(shí)體已損毀,則直接跳過(guò)該活動(dòng),根據(jù)指揮控制工作流模型的定義執(zhí)行下一活動(dòng). 在工作流建模中通過(guò)定義與每個(gè)活動(dòng)節(jié)點(diǎn)對(duì)應(yīng)的布爾類型流程變量實(shí)現(xiàn)節(jié)點(diǎn)柔性,并且使用該參數(shù)來(lái)確定活動(dòng)是否執(zhí)行.

基于節(jié)點(diǎn)柔性能夠?qū)崿F(xiàn)基于同一指揮控制工作流模型的指揮控制流程動(dòng)態(tài)定制, 指揮員能夠在啟動(dòng)流程時(shí),或者流程運(yùn)行過(guò)程中,根據(jù)實(shí)際情況跳過(guò)某些任務(wù)節(jié)點(diǎn),提高流程執(zhí)行效率,來(lái)滿足不同情況下流程高效運(yùn)轉(zhuǎn)的需求. 例如在指揮控制工作流中,如果打擊目標(biāo)的信息已經(jīng)明確, 則可跳過(guò)偵察活動(dòng),直接流轉(zhuǎn)至下一活動(dòng).

2)流程柔性. 流程柔性是指在建模時(shí)考慮各種可能的情況,實(shí)現(xiàn)任務(wù)分支全覆蓋,能夠根據(jù)流程執(zhí)行過(guò)程中某些流程變量的值動(dòng)態(tài)選擇滿足條件的分支, 實(shí)現(xiàn)在指揮控制流程執(zhí)行過(guò)程中動(dòng)態(tài)選擇流程流轉(zhuǎn)方向,以適應(yīng)不同的實(shí)際情況. 以打擊目標(biāo)可用兵力計(jì)算插件為例, 所調(diào)用的插件與具體的打擊目標(biāo)類型相關(guān), 如針對(duì)水面艦艇類目標(biāo)使用打擊水面艦艇類的可用兵力計(jì)算插件, 打擊空中目標(biāo)則使用打擊空中目標(biāo)類的可用兵力計(jì)算插件. 在工作流模型中使用條件網(wǎng)關(guān)完成不同打擊目標(biāo)類型對(duì)應(yīng)不同可用兵力計(jì)算插件的建模, 實(shí)現(xiàn)在流程運(yùn)行過(guò)程中根據(jù)打擊目標(biāo)類型,動(dòng)態(tài)選擇相應(yīng)的分支,滿足同一指揮控制工作流模型適應(yīng)多任務(wù)的需求.

3)時(shí)間柔性. 在信息化戰(zhàn)爭(zhēng)中,作戰(zhàn)雙方體系與體系的對(duì)抗已成為戰(zhàn)場(chǎng)對(duì)抗的基本特征. 體系作戰(zhàn)對(duì)指揮決策過(guò)程有極強(qiáng)的時(shí)間限制, 要求在有限的時(shí)間內(nèi)作出響應(yīng)[16], 當(dāng)某一任務(wù)無(wú)法在規(guī)定時(shí)間內(nèi)完成時(shí),不可能無(wú)限制等待下去,需要有相應(yīng)的處理預(yù)案. 而現(xiàn)有的指揮控制流程并沒(méi)有對(duì)時(shí)間進(jìn)行建模, 所以無(wú)法對(duì)任務(wù)執(zhí)行時(shí)間作出準(zhǔn)確判斷. 因此,本文增加時(shí)間信息的建模, 根據(jù)任務(wù)特點(diǎn)自定義設(shè)置最晚開(kāi)始時(shí)間和持續(xù)時(shí)間等時(shí)間約束關(guān)系, 當(dāng)任務(wù)執(zhí)行者無(wú)法在規(guī)定時(shí)間內(nèi)完成任務(wù)時(shí), 將作出相應(yīng)的處理,以此提高流程執(zhí)行效率和模型柔性,避免因某一任務(wù)出現(xiàn)問(wèn)題而導(dǎo)致整個(gè)流程無(wú)法運(yùn)轉(zhuǎn).

2.3.2 指揮控制模型柔性需求與工作流模型的映射

指揮控制模型柔性需求與工作流模型的映射關(guān)系如下:

1)對(duì)人工活動(dòng)和自動(dòng)活動(dòng)進(jìn)一步擴(kuò)展, 實(shí)現(xiàn)活動(dòng)節(jié)點(diǎn)柔性. 在工作流模型中,每個(gè)活動(dòng)節(jié)點(diǎn)都有與活動(dòng)名對(duì)應(yīng)的流程變量, 該值描述了對(duì)應(yīng)的活動(dòng)是否需要在已創(chuàng)建的流程實(shí)例中執(zhí)行.

2)流程柔性在工作流模型中體現(xiàn)為不同條件的分支,映射為條件網(wǎng)關(guān),通過(guò)對(duì)不同流程分支的組合,滿足多任務(wù)需求,以適應(yīng)實(shí)際情況.

3)通過(guò)對(duì)UML 活動(dòng)圖中控制流的擴(kuò)展,實(shí)現(xiàn)對(duì)時(shí)間信息的建模, 映射為工作流過(guò)程模型中的邊界定時(shí)器事件,實(shí)現(xiàn)時(shí)間計(jì)時(shí).

3 基于UML 的指揮控制工作流建模方法

UML 構(gòu)造型是在已定義好的UML 模型元素的基礎(chǔ)上構(gòu)造出一個(gè)新的模型元素,為UML 增加新事物.使用UML 的構(gòu)造型擴(kuò)展機(jī)制能夠滿足指揮控制軟件插件集成需求和指揮控制工作流模型柔性需求.

3.1 指揮控制軟件插件集成建模

指揮控制軟件插件集成建模闡述了基于UML擴(kuò)展機(jī)制的工作流圖元實(shí)現(xiàn), 主要有插件信息描述圖元、動(dòng)態(tài)信息描述圖元、靜態(tài)信息描述圖元和組織結(jié)構(gòu)描述圖元, 滿足指揮控制軟件插件集成建模的需求.

3.1.1 插件描述信息構(gòu)造型

通過(guò)插件匹配模塊解析插件描述信息, 并從插件本體庫(kù)中匹配到匹配度最高的插件, 再將該插件的調(diào)用信息寫入流程定義文件中, 工作流引擎解析流程定義文件實(shí)現(xiàn)插件的調(diào)用. 因此,插件描述對(duì)本文的集成工作有重要的作用, 對(duì)類圖進(jìn)行擴(kuò)展實(shí)現(xiàn)插件信息的描述. 插件描述的構(gòu)造型如圖1 所示.

圖1 插件描述構(gòu)造型的聲明和使用Fig.1 Declaration and utilization of plug-in description stereotypes

用“Plug-in Description” 表示插件描述. 根據(jù)插件的描述模型分別構(gòu)建相應(yīng)的屬性, 如所需功能名(FunctionName)、是否需要圖形界面(GUI)、輸入?yún)?shù)(Input)、輸出參數(shù)(Output)、操作系統(tǒng)(Operation System)、所用的數(shù)據(jù)庫(kù)(Database Type)、當(dāng)前環(huán)境所能提供的最高CPU 頻率(CPU Frequency)、執(zhí)行插件時(shí)允許的最大內(nèi)存(Memory)、執(zhí)行插件時(shí)允許的最大硬盤容量組成. 通過(guò)TaskId 唯一確定插件與活動(dòng)的對(duì)應(yīng)關(guān)系.

3.1.2 信息模型構(gòu)造型

1)動(dòng)態(tài)信息構(gòu)造型

動(dòng)態(tài)信息模型用于描述指揮控制流程運(yùn)行過(guò)程中各活動(dòng)節(jié)點(diǎn)間的輸入輸出信息, 以及指揮控制工作流以外的輸入和輸出信息.

指揮控制工作流模型動(dòng)態(tài)信息的描述通過(guò)擴(kuò)展控制流實(shí)現(xiàn). 由于活動(dòng)節(jié)點(diǎn)的輸入?yún)?shù)和輸出參數(shù)在插件描述中已有體現(xiàn), 所以不在動(dòng)態(tài)信息模型中重復(fù)構(gòu)建, 動(dòng)態(tài)信息模型構(gòu)造型如圖2 所示, InfoFlowName 表示從上一活動(dòng)節(jié)點(diǎn)流向下一活動(dòng)節(jié)點(diǎn)的信息.

圖2 動(dòng)態(tài)信息模型構(gòu)造型的聲明和使用Fig.2 Declaration and utilization of dynamic information model stereotypes

2)靜態(tài)信息構(gòu)造型

靜態(tài)信息模型用于描述各作戰(zhàn)實(shí)體間的信息發(fā)布和信息訂閱, 幫助建模人員直觀地了解各實(shí)體的基本情況, 輔助判斷所建工作流模型能否滿足信息正常流轉(zhuǎn)的需求.

通過(guò)對(duì)類圖的擴(kuò)展實(shí)現(xiàn)對(duì)各作戰(zhàn)實(shí)體發(fā)布信息和訂閱信息的描述, 構(gòu)造型如圖3 所示. Name 定義了作戰(zhàn)實(shí)體的名稱, InputInfo 定義了實(shí)體需要訂閱的信息,OutputInfo 定義了實(shí)體所能發(fā)布的信息.

圖3 靜態(tài)信息模型構(gòu)造型的聲明和使用Fig.3 Declaration and utilization of static information model stereotypes

3.1.3 人工活動(dòng)構(gòu)造型

人工活動(dòng)構(gòu)造型的聲明和使用如圖4 所示,用“User Activity” 來(lái)表示人工活動(dòng), 共有5 個(gè)屬性,分別是TaskName、TaskId、AssigneeName/Group-Name、State 和Plugin. 其中, TaskName 表示當(dāng)前活動(dòng)的活動(dòng)名; TaskId 用于唯一標(biāo)識(shí)當(dāng)前活動(dòng); AssigneeName/GroupName 用于指定可執(zhí)行當(dāng)前活動(dòng)的用戶或用戶組;Plugin 用于描述活動(dòng)對(duì)應(yīng)的任務(wù)是否需要調(diào)用插件,true 表示需要調(diào)用插件;false 表示不需要調(diào)用插件.

圖4 人工活動(dòng)構(gòu)造型的聲明和使用Fig.4 Declaration and utilization of user activity stereotypes

3.1.4 自動(dòng)活動(dòng)構(gòu)造型

自動(dòng)活動(dòng)構(gòu)造型的聲明和使用如圖5 所示, 與人工活動(dòng)構(gòu)造型基本一致, 刪除人工活動(dòng)中的執(zhí)行者,增加調(diào)用外部應(yīng)用程序的相關(guān)描述.

圖5 自動(dòng)活動(dòng)構(gòu)造型的聲明和使用Fig.5 Declaration and utilization of auto activity stereotypes

3.1.5 組織結(jié)構(gòu)構(gòu)造型

根據(jù)組織結(jié)構(gòu)的層次關(guān)系, 將組織結(jié)構(gòu)模型劃分為3 個(gè)圖元, 分別代表不同的組織結(jié)構(gòu)內(nèi)容, 3 個(gè)圖元分別是: OrganizationTop 模塊、OrganizationDepartment 模塊和Organization-Person模塊3 種類型.

1)OrganizationTop 模塊是頂層結(jié)構(gòu), 它描述了當(dāng)前指揮所的相關(guān)信息, 如它的上級(jí)指揮所和下級(jí)指揮所,描述了不同指揮所間的指揮關(guān)系.

2)OrganizationDepartment 模塊是次頂層, 它描述了指揮所中各組織實(shí)體的相關(guān)信息, 包括實(shí)體的名稱以及該實(shí)體所對(duì)應(yīng)的信息.

3)OrganizationPerson 模塊是最底層, 它描述了人員的相關(guān)信息和相應(yīng)的席位.

使用3 層的組織結(jié)構(gòu)模型描述了指揮所中人員所屬的部門組織和席位, 為定義指揮控制流程模型中的角色提供參考.

OrganizationPerson 的構(gòu)造型如圖6 所示, Name定義了人員名,Seat 定義了人員的席位.

圖6 組織結(jié)構(gòu)構(gòu)造型的聲明和使用(指戰(zhàn)員)Fig.6 Declaration and utilization of organizational structure stereotypes(staff)

3.2 指揮控制工作流柔性建模

指揮控制工作流柔性建模針對(duì)指揮控制工作流建模柔性需求, 在UML 擴(kuò)展機(jī)制的基礎(chǔ)上, 實(shí)現(xiàn)節(jié)點(diǎn)柔性、流程柔性和時(shí)間約束圖元.

3.2.1 節(jié)點(diǎn)柔性構(gòu)造型

節(jié)點(diǎn)柔性通過(guò)在圖4 的人工活動(dòng)構(gòu)造型和圖5的自動(dòng)活動(dòng)構(gòu)造型中定義State 屬性實(shí)現(xiàn). State 屬性定義了活動(dòng)節(jié)點(diǎn)的狀態(tài), 其值為布爾值.true 表示該活動(dòng)需要被執(zhí)行, false 表示該活動(dòng)節(jié)點(diǎn)對(duì)應(yīng)的任務(wù)因可不執(zhí)行或無(wú)法完成而跳過(guò), 該狀態(tài)默認(rèn)均為true,可在流程啟動(dòng)時(shí)或流程執(zhí)行過(guò)程中更改.

3.2.2 流程柔性構(gòu)造型

流程柔性體現(xiàn)在根據(jù)工作流模型和實(shí)際情況動(dòng)態(tài)選擇相應(yīng)的流程分支, 因此, 對(duì)分支與合并元圖元擴(kuò)展實(shí)現(xiàn)工作流模型中的條件網(wǎng)關(guān), 如圖7 所示.在條件網(wǎng)關(guān)中共有兩個(gè)屬性, 分別是gatewayID 和gatewayName. gatewayID 具有唯一性,用于標(biāo)識(shí)每一個(gè)條件網(wǎng)關(guān);gatewayName 定義了條件網(wǎng)關(guān)的名稱.

圖7 條件網(wǎng)關(guān)構(gòu)造型的聲明和使用Fig.7 Declaration and utilization of exclusive gateway structure stereotypes

3.2.3 時(shí)間建模構(gòu)造型

采用擴(kuò)展控制流的方法實(shí)現(xiàn)時(shí)間約束信息的建模,如圖8 所示. 通過(guò)對(duì)控制流上事件的擴(kuò)展實(shí)現(xiàn)對(duì)時(shí)間約束的建模,共有3 個(gè)屬性,分別是EndTime 最晚結(jié)束時(shí)間、DurationTime 最長(zhǎng)持續(xù)時(shí)間和UnitOf-Time 時(shí)間單位. 最晚結(jié)束時(shí)間是指流程執(zhí)行過(guò)程中在該活動(dòng)停留的最長(zhǎng)時(shí)間; 最長(zhǎng)持續(xù)時(shí)間是指完成該活動(dòng)所需的最長(zhǎng)時(shí)間. 根據(jù)這兩個(gè)參數(shù),便可根據(jù)活動(dòng)的執(zhí)行情況對(duì)活動(dòng)執(zhí)行者進(jìn)行通知提醒, 避免錯(cuò)過(guò)活動(dòng); 若無(wú)法在最長(zhǎng)持續(xù)時(shí)間內(nèi)完成任務(wù)則執(zhí)行預(yù)先定義的情況處置活動(dòng).

圖8 時(shí)間約束Fig.8 Time constraint

3.3 工作流建模工具設(shè)計(jì)與實(shí)現(xiàn)

使用UML 建模工具完成對(duì)UML 元模型的擴(kuò)展,實(shí)現(xiàn)基于UML 的工作流建模. 根據(jù)已有UML 建模軟件的易用性和生成模型對(duì)應(yīng)的可擴(kuò)展標(biāo)記語(yǔ)言文件的直觀性和高可讀性,選擇Papyrus 作為工作流建模工具.

根據(jù)UML 的擴(kuò)展機(jī)制以及Papyrus 的實(shí)現(xiàn)方法,共擴(kuò)展了多種模型,如表1 所示,在Papyrus 中的實(shí)現(xiàn)如圖9 所示.

表1 基于UML 的工作流擴(kuò)展型Table 1 Workfl w extension based on UML

圖9 使用Papyrus 擴(kuò)展的圖元(部分)Fig.9 Extended primitives using Papyrus(part)

基于擴(kuò)展后的模型能夠?qū)崿F(xiàn)指揮控制工作流建模, 將構(gòu)建的模型映射成BPMN2.0 規(guī)范后, 便能夠被工作流引擎解析和執(zhí)行.

4 指揮控制工作流建模案例

4.1 案例背景

以美軍火力旅指揮控制流程為案例背景[17], 采用本文提出的工作流建模方法, 并使用擴(kuò)展后的工作流建模工具完成指揮控制工作流模型構(gòu)建.

火力旅攻擊移動(dòng)目標(biāo)的指揮控制流程大致如下:火力旅指揮所在接收到戰(zhàn)備警報(bào)之后, 全旅進(jìn)入戰(zhàn)備狀態(tài),偵察雷達(dá)對(duì)目標(biāo)進(jìn)行搜索,雷達(dá)一旦發(fā)現(xiàn)敵對(duì)目標(biāo),則向目標(biāo)連發(fā)送目標(biāo)點(diǎn)跡信號(hào),目標(biāo)連在接收到相應(yīng)的信號(hào)之后, 將信號(hào)發(fā)送給指揮所中的目標(biāo)分配臺(tái),分配臺(tái)完成敵方目標(biāo)對(duì)應(yīng)航跡計(jì)算、初始諸元計(jì)算和威脅評(píng)估分析, 并將結(jié)果發(fā)送到火力旅指揮所,由指揮員根據(jù)評(píng)估結(jié)果作出相應(yīng)的決策,選擇打擊目標(biāo),并將目標(biāo)信息發(fā)送給火力控制臺(tái),由火力控制臺(tái)完成敵對(duì)目標(biāo)的地理位置計(jì)算和精確的諸元計(jì)算, 最后由指揮員完成火力分配并將火力分配指令下發(fā)各導(dǎo)彈發(fā)射營(yíng), 指揮員根據(jù)雷達(dá)對(duì)目標(biāo)監(jiān)視獲得的目標(biāo)態(tài)勢(shì)情況下達(dá)指令, 完成火力打擊任務(wù).流程圖如圖10 所示.

在圖10 的流程描述中,可將組織結(jié)構(gòu)分為目標(biāo)偵察連、旅指揮所和導(dǎo)彈發(fā)射營(yíng)等. 涉及的插件功能有通信、目標(biāo)探測(cè)、目標(biāo)接收和航跡計(jì)算等.

圖10 火力旅打擊移動(dòng)目標(biāo)流程圖Fig.10 Flow chart of fir brigade hitting moving targets

靜態(tài)信息建模如圖11 所示,描述了目標(biāo)偵察連和旅指揮所所能發(fā)布的消息和訂閱的消息.

圖11 火力旅信息建模（部分）Fig.11 Fire brigade information modeling(part)

采用本文提出的方法構(gòu)建火力旅指揮控制工作流模型,部分視圖如圖12 所示,該圖中包含人工活動(dòng)(User Activity)和自動(dòng)活動(dòng)(Auto Activity);描述了活動(dòng)的執(zhí)行者(leiDa、muBiao 等)和活動(dòng)的時(shí)間約束;明確了是否需要調(diào)用插件; 明確了活動(dòng)節(jié)點(diǎn)對(duì)應(yīng)實(shí)際情況的可用性;描述了動(dòng)態(tài)信息的流轉(zhuǎn). 以目標(biāo)探測(cè)為例, 目標(biāo)探測(cè)是由leiDa 執(zhí)行的人工活動(dòng), 需要調(diào)用插件完成活動(dòng),接收前置活動(dòng)發(fā)送的偵察指令,向后置活動(dòng)發(fā)送敵方目標(biāo)信息,該活動(dòng)必須在50 min內(nèi)完成,若在流程流轉(zhuǎn)到該活動(dòng)30 min 后,仍未開(kāi)始執(zhí)行,則對(duì)leiDa 進(jìn)行提醒,若50 min 后活動(dòng)仍未結(jié)束,則進(jìn)入相應(yīng)處置方案.

在該模型中,共有6 個(gè)任務(wù)和1 個(gè)條件分支. 在收到戰(zhàn)備警報(bào)后流程正式開(kāi)始執(zhí)行, 根據(jù)時(shí)間約束信息,在規(guī)定時(shí)間內(nèi)由雷達(dá)完成目標(biāo)探測(cè)任務(wù)、目標(biāo)連完成目標(biāo)接收任務(wù). 根據(jù)捕獲的目標(biāo)的類型執(zhí)行不同的任務(wù),若目標(biāo)為移動(dòng)目標(biāo),則調(diào)用相應(yīng)指揮控制軟件插件進(jìn)行航跡計(jì)算和諸元計(jì)算. 在上述任務(wù)完成之后,將相關(guān)信息上報(bào)指揮所;若目標(biāo)為固定目標(biāo),則直接將相關(guān)信息上報(bào)指揮所.

在圖12 中,由于每一個(gè)活動(dòng)都需要調(diào)用插件完成相應(yīng)的任務(wù),所以在插件描述模型中,為每一個(gè)活動(dòng)創(chuàng)建對(duì)應(yīng)的插件描述圖元, 并寫入相應(yīng)的屬性信息, 如圖13 所示. 通過(guò)插件描述圖元和活動(dòng)圖元的TaskId 屬性建立插件描述圖元和活動(dòng)圖元間的對(duì)應(yīng)關(guān)系,因此,TaksId 具有唯一性.

圖12 改進(jìn)的UML 活動(dòng)圖示例Fig.12 Improved UML activity diagram

圖13 插件描述信息Fig.13 Plug-in description information

4.2 基于UML 的工作流建模實(shí)現(xiàn)

根據(jù)火力旅的指揮關(guān)系和組織結(jié)構(gòu), 構(gòu)建的部分組織結(jié)構(gòu)模型如圖14 所示,使用擴(kuò)展的組織結(jié)構(gòu)3 層模型構(gòu)建了旅-營(yíng)-連-指戰(zhàn)員的結(jié)構(gòu). 在讀取該模型對(duì)應(yīng)的XML 文件后,根據(jù)定義的標(biāo)簽讀取相應(yīng)的內(nèi)容, 并將其添加到工作流引擎數(shù)據(jù)庫(kù)中相應(yīng)的數(shù)據(jù)表中.

圖14 在Papyrus 中的組織結(jié)構(gòu)模型（部分）Fig.14 Organizational structure model in Papyrus(part)

根據(jù)構(gòu)建的作戰(zhàn)實(shí)體靜態(tài)信息, 使用擴(kuò)展后的UML 類圖描述如圖15 所示.

圖15 在Papyrus 中的靜態(tài)信息模型Fig.15 Static information model in Papyrus

根據(jù)圖12 構(gòu)建的火力旅指揮控制工作流模型,使用Papyrus 構(gòu)建的指揮控制工作流模型如圖16所示.

圖16 Papyrus 中的工作流模型Fig.16 Workfl w model in Papyrus

在工作流模型中擴(kuò)展的控制流中增加的動(dòng)態(tài)流轉(zhuǎn)信息和時(shí)間約束信息如圖17 所示,動(dòng)態(tài)流轉(zhuǎn)信息描述了從順序流的源頭流向順序流末端的信息; 時(shí)間約束信息描述了當(dāng)前活動(dòng)對(duì)時(shí)間的約束.

圖17 工作流建模中信息流的體現(xiàn)Fig.17 Information fl w in workfl w modeling

為了體現(xiàn)節(jié)點(diǎn)柔性,在流程定義時(shí),為每個(gè)活動(dòng)定義了一個(gè)變量用于標(biāo)識(shí)根據(jù)實(shí)際情況該活動(dòng)是否需要執(zhí)行. 該變量的值可在流程啟動(dòng)時(shí)或流程執(zhí)行過(guò)程中變更, 在執(zhí)行活動(dòng)前先查詢對(duì)應(yīng)變量的值再?zèng)Q定活動(dòng)是否執(zhí)行,如圖18 所示.

圖18 實(shí)現(xiàn)節(jié)點(diǎn)柔性對(duì)應(yīng)的參數(shù)Fig.18 Corresponding parameters of node fl xibility

使用Papyrus 構(gòu)建的插件描述模型如圖19 所示,該模塊的ID 與對(duì)應(yīng)的流程活動(dòng)節(jié)點(diǎn)的ID 一致. 通過(guò)解析對(duì)應(yīng)的XML 文件,獲得活動(dòng)對(duì)應(yīng)的插件描述信息, 根據(jù)該描述信息使用插件匹配模塊匹配到相應(yīng)的插件, 并將插件調(diào)用的信息如插件名和版本號(hào)添加到流程文件中對(duì)應(yīng)活動(dòng)的擴(kuò)展節(jié)點(diǎn)中, 便于工作流引擎的調(diào)用相應(yīng)的插件.

圖19 插件描述圖元Fig.19 The plug-in description primitives

以上述案例為背景, 構(gòu)建基于工作流引擎的指揮控制軟件插件集成系統(tǒng), 開(kāi)展基于工作流引擎的指揮控制軟件插件集成驗(yàn)證. 使用本文提出的面向指揮控制軟件集成的工作流建模方法并根據(jù)UML模型與BPMN2.0 模型的映射關(guān)系,實(shí)現(xiàn)指揮控制工作流模型與工作流語(yǔ)言的映射. 由Activiti 工作流引擎實(shí)現(xiàn)指揮控制工作流模型的解析、執(zhí)行和插件的集成調(diào)用,并根據(jù)時(shí)間約束執(zhí)行相應(yīng)的操作.使用插件匹配模塊,根據(jù)插件描述信息得到相應(yīng)的插件,并將插件的調(diào)用信息以擴(kuò)展元素的形式寫入到流程定義文件中. 工作流引擎通過(guò)讀取流程定義文件得到流程任務(wù)所要調(diào)用的插件的名稱和版本, 根據(jù)該名稱和版本完成插件的集成調(diào)用. 結(jié)果表明,提出的建模方法能夠滿足指揮控制軟件基于插件的流程集成和流程柔性的需求.

5 結(jié)論

根據(jù)UML 活動(dòng)圖在工作流建模中的優(yōu)勢(shì)、實(shí)踐過(guò)程中存在的不足和已有的指揮控制工作流模型的不足, 提出了改進(jìn)的UML 活動(dòng)圖工作流建模方法,在活動(dòng)節(jié)點(diǎn)中增加執(zhí)行活動(dòng)的用戶信息,以避免使用泳道帶來(lái)的修改不便; 根據(jù)指揮控制軟件插件集成需求, 提出對(duì)UML 類圖進(jìn)行擴(kuò)展,實(shí)現(xiàn)插件描述圖元、靜態(tài)信息圖元和組織結(jié)構(gòu)圖元, 擴(kuò)展UML活動(dòng)圖實(shí)現(xiàn)動(dòng)態(tài)信息圖元;根據(jù)工作流柔性需求,擴(kuò)展UML 活動(dòng)圖實(shí)現(xiàn)節(jié)點(diǎn)柔性、流程柔性和時(shí)間柔性. 最后在對(duì)UML 建模工具進(jìn)行擴(kuò)展的基礎(chǔ)上,通過(guò)對(duì)美軍火力旅指揮控制流程的建模, 驗(yàn)證了提出的面向流程集成的指揮控制軟件工作流建模的可行性. 但是在信息建模部分還不夠完善, 后續(xù)將進(jìn)一步研究.