李佳鋒 聶坤明 胡春燕 周武

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

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

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

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

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

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

1 相關(guān)研究

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

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

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

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

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

2 基于UML 的工作流建模

2.1 UML 活動圖與工作流模型的映射

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

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

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

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

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

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

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

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

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

2.2.1 集成建模需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.1 柔性建模需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通過插件匹配模塊解析插件描述信息, 并從插件本體庫中匹配到匹配度最高的插件, 再將該插件的調(diào)用信息寫入流程定義文件中, 工作流引擎解析流程定義文件實(shí)現(xiàn)插件的調(diào)用. 因此,插件描述對本文的集成工作有重要的作用, 對類圖進(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ù)庫(Database Type)、當(dāng)前環(huán)境所能提供的最高CPU 頻率(CPU Frequency)、執(zhí)行插件時允許的最大內(nèi)存(Memory)、執(zhí)行插件時允許的最大硬盤容量組成. 通過TaskId 唯一確定插件與活動的對應(yīng)關(guān)系.

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

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

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

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

圖2 動態(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)的需求.

通過對類圖的擴(kuò)展實(shí)現(xiàn)對各作戰(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 人工活動構(gòu)造型

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

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

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

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

圖5 自動活動構(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 個圖元, 分別代表不同的組織結(jié)構(gòu)內(nèi)容, 3 個圖元分別是: OrganizationTop 模塊、OrganizationDepartment 模塊和Organization-Person模塊3 種類型.

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

2)OrganizationDepartment 模塊是次頂層, 它描述了指揮所中各組織實(shí)體的相關(guān)信息, 包括實(shí)體的名稱以及該實(shí)體所對應(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 指揮控制工作流柔性建模

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

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

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

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

流程柔性體現(xiàn)在根據(jù)工作流模型和實(shí)際情況動態(tài)選擇相應(yīng)的流程分支, 因此, 對分支與合并元圖元擴(kuò)展實(shí)現(xiàn)工作流模型中的條件網(wǎng)關(guān), 如圖7 所示.在條件網(wǎng)關(guān)中共有兩個屬性, 分別是gatewayID 和gatewayName. gatewayID 具有唯一性,用于標(biāo)識每一個條件網(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 時間建模構(gòu)造型

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

圖8 時間約束Fig.8 Time constraint

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

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

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

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

圖10 火力旅打擊移動目標(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 所示,該圖中包含人工活動(User Activity)和自動活動(Auto Activity);描述了活動的執(zhí)行者(leiDa、muBiao 等)和活動的時間約束;明確了是否需要調(diào)用插件; 明確了活動節(jié)點(diǎn)對應(yīng)實(shí)際情況的可用性;描述了動態(tài)信息的流轉(zhuǎn). 以目標(biāo)探測為例, 目標(biāo)探測是由leiDa 執(zhí)行的人工活動, 需要調(diào)用插件完成活動,接收前置活動發(fā)送的偵察指令,向后置活動發(fā)送敵方目標(biāo)信息,該活動必須在50 min內(nèi)完成,若在流程流轉(zhuǎn)到該活動30 min 后,仍未開始執(zhí)行,則對leiDa 進(jìn)行提醒,若50 min 后活動仍未結(jié)束,則進(jìn)入相應(yīng)處置方案.

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

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

圖12 改進(jìn)的UML 活動圖示例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)建了旅-營-連-指戰(zhàn)員的結(jié)構(gòu). 在讀取該模型對應(yīng)的XML 文件后,根據(jù)定義的標(biāo)簽讀取相應(yīng)的內(nèi)容, 并將其添加到工作流引擎數(shù)據(jù)庫中相應(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ò)展的控制流中增加的動態(tài)流轉(zhuǎn)信息和時間約束信息如圖17 所示,動態(tài)流轉(zhuǎn)信息描述了從順序流的源頭流向順序流末端的信息; 時間約束信息描述了當(dāng)前活動對時間的約束.

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

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

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

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

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

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

5 結(jié)論

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