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

李佳锋 聂坤明 胡春燕 周武

1．中国航天科工集团有限公司第四研究院北京航天晨信科技有限责任公司北京102300

随着信息技术和科学技术的飞速发展, 与以往战争相比,现代战争不论在战争形态,还是在运行规律方面都发生了翻天覆地的变化, 信息化战争越来越复杂,不再是平台对平台的对抗,而是体系与体系的对抗[1−2]. 指挥控制系统是为完成作战任务服务的应用系统, 随着信息系统在军事领域的应用以及军事技术的不断发展, 使得指挥控制的地位与作用不断提升, 争夺指挥控制的优势成为现代战争对抗最为激烈的焦点. 指挥流程强调指挥相关的工作流程,是由一系列相对明确、先后有序、首尾衔接的若干阶段或基本环节所构成的一个特定的过程, 是指挥者从事指挥活动的基本程序, 能够反映不同指挥模式下的作战指挥活动规律[3]. 指挥控制系统面向特定作战需求定制而成,功能使命单一、流程固定,各系统间集成难度大. 指挥控制系统根据新的指挥作战需求添加相应的功能,“边建设、边验证”的发展途径导致现有的指挥控制系统围绕各级各类指挥所定制设计,每个系统的功能固定、流程固定, 形成了一个个“烟囱”. 一旦原有的指挥关系、指挥规则或指挥模式发生变化, 流程间的紧耦合性导致需要将原有的指挥控制系统推倒重建,大大浪费了人力、物力和财力. 随着装备水平的提升和国际形势的变化,未来的任务使命趋于多样化,而现有的指挥控制系统,软件架构不同, 内部功能耦合度高, 不易深度集成, 依靠在“烟囱”间架设“桥梁”的方式,存在同步效率低和联动性差的问题.

指挥控制系统的部署环境也是多样化的, 指挥控制系统既可能部署在固定的指挥大厅里, 也可能部署在空间狭小、设施简陋的指挥车里. 所以没有一种指挥控制系统能够满足所有指挥控制系统形态的需求, 但是针对各形态均开发相应的系统存在成本高、浪费大和周期长等问题.面向多样化需求的灵活重构能力是未来指挥控制系统的必备能力[4−5].

为了满足指挥控制系统面向多样化任务灵活重构的需求, 提出基于工作流引擎的指挥控制软件插件集成方法, 由工作流引擎驱动指挥控制软件插件的动态集成. 其中,工作流过程建模是工作流技术应用的重要环节, 工作流引擎根据构建的模型来解析和执行流程.

在现有的指挥控制软件工作流建模方法中, 缺少对于时间要素的建模, 不能够准确表示对作战活动的时间约束, 无法满足指挥控制软件的应用需求,尤其是对于时敏目标的打击, 要求在有限的时间内完成决策、机动、锁定、攻击和毁伤评估等所有作战活动,某一环节出现超时问题会导致流程无法运转.现有的建模方法由于柔性不足, 导致无法很好地对突发流程等情况进行处理,而在战场环境下,需要对于各种可能的情况进行处理, 迫切需要实现业务流程的柔性变化. 为了实现工作流驱动的指挥控制软件插件集成,需要实现插件的动态匹配,由于工作流模型中缺少插件的相关描述信息, 无法实现指挥控制软件的自动集成. 信息是流程流转的关键,也是指挥控制过程中不可缺少的一部分. 本文将从时间建模、柔性建模、信息建模和插件描述信息建模4 个方面对现有的指挥控制软件工作流建模方法进行扩展.

本文以UML 活动图为核心,针对UML 活动图存在的问题、指挥控制软件插件集成需求和工作流柔性需求,提出改进的基于UML 的工作流建模方法.针对泳道存在不易修改、不易理解等问题,提出在活动节点中添加活动执行者信息来简化组织结构关系;针对活动图活动节点单一的问题, 根据工作流模型的特点,将活动节点分为人工活动和自动活动;针对活动节点缺少时间信息的问题, 在顺序流中添加时间信息, 加强活动执行时间的约束(最长持续时间、最晚结束时间), 并提高流程柔性; 针对活动图缺少调用外部程序的相关信息,提出对类图进行扩展,使用类图描述对应活动节点所需插件的相关描述信息;针对现有模型无法满足战场实时变化引起的指挥控制流程中活动节点实时变化的问题, 提出在活动节点中定义一个与当前活动对应的状态信息字段, 实现节点的柔性化, 并尽可能考虑更多的可能性实现流程的柔性化. 针对现有指挥控制工作流模型中缺少信息建模的问题, 提出动态和静态信息融合的信息模型, 支持通过动态信息模型了解流程中的信息流转, 通过静态信息模型判断所建流程模型能否满足信息订阅的需求.

1 相关研究

现有的建模技术包括基于图形符号的建模技术、基于数学的建模技术和基于图形符号且基于数学的建模技术Petri 网及其扩展[5]. UML 是一种通用的可视化建模语言, 是面向对象分析与设计的标准, 能够为系统业务流程提供可视化的分析与设计[6],从而阐明系统“要做什么—>由谁去做—>如何去做—>何时做—>做的顺序怎么样”这样一个核心问题.

流程模型是对业务流程定义的基本元素和规则的抽象,并加以一般性描述,用于指导业务流程管理与插件集成的过程建模. 流程一般由开始节点、结束节点、控制节点以及若干个活动节点组成[7].

目前在各种领域已经有许多可视化的流程建模方法, 主要的流程建模方式有基于Petri 网建模、基于事件驱动的过程链建模、事务流程建模、基于语言模型的流程建模、基于活动网络的流程建模、基于状态机的流程建模和基于UML 的流程建模[8].

使用UML 对工作流过程进行建模,已有不少同行做过相关的工作.有的同行仅使用UML 完成工作流建模,有的同行根据UML 在工作流建模中存在的不足,提出了改进的方法. 马云龙针对UML 易于理解、可视化以及UML 动态特定与工作流业务流程相吻合的特点,使用多种UML 视图完成工作流模型的构建[9]. 朱璇等使用UML 模型实现了联合作战方案计划的可视化视图建模, 构建了时间视图、信息视图和空间视图, 将多维复杂的战场数据信息进行简明表述, 实现了战场数据信息的高效表达[10]. 吴雷等针对传统软件建模方法无法满足企业资源计划(Enterprise Resource Planning,ERP)业务模型到模型驱动架构(Model Driven Architecture, MDA)下模型转换的需求, 对工作流定义元模型进行改进并基于UML 的轻量级扩展机制,建立了UML Profile 通过实例论证了模型理论的可行性[11]. 郝可针对传统业务流程不可重入,难以完全适应战场变化,提出流程节点,体现业务流程的柔性变化,并给出了引入流程节点后业务流程的柔性变化以及相应的规则, 与现有的模型相比较,其更适合战场环境,但是对日志数据的利用度不高, 而且没有给出实际的建模方法和工具[12]. 魏然为了满足指挥控制流程对任务动态更改的需求,缩短流程执行周期,针对传统工作流中节点静态、固化的现状,对任务状态空间进行分析,提出对流程节点增加部分提交状态, 实现流程任务的多次提交,通过仿真实验,验证了该方法提升了流程的并行性和动态性[13].

上述针对UML 活动图的改进方法解决了使用UML 构建工作流过程模型的部分问题,但是这些改进尚不能满足本文在建模过程中完成时间建模、柔性建摸、信息建模以及插件描述建模的需求.

2 基于UML 的工作流建模

2.1 UML 活动图与工作流模型的映射

工作流的建模过程是对动态的业务过程建模,是围绕活动进行的, 活动是其最小且不可分割的基本元素.在UML 的动态模型中, 活动图主要由状态和转换两种元素组成, 描述了一组顺序或并发执行的活动, 以及活动到活动之间的流转关系, 活动状态可代表工作流中一个步骤或者一个操作的执行.UML 活动图的元素和工作流过程定义元素有许多相似之处,因此,UML 活动图能够实现对工作流模型的描述, 本文拟将活动图作为工作流过程建模的主要模型.

现有的UML 活动图元素与工作流模型间的映射关系如下[14]:

1)将UML 活动图中的动作状态映射为工作流过程模型中的活动节点.

2)将UML 活动图中的初始状态和终止状态映射为工作流过程模型中的开始节点和结束节点.

3)将UML 活动图中的表示活动间转移的控制流映射为工作流过程模型中活动节点间的顺序流.

4)将UML 活动图中的分支与合并元素映射为工作流过程模型中的条件网关和并行网关分散图元.

5)将UML 活动图中的分叉和汇合元素映射为工作流过程模型中的并行网关的汇聚图元.

通过以上UML 活动图元素和工作流元素之间的映射,描述了工作流的多种属性和相应的状态,但是仍不能完全满足指挥控制软件插件集成需求和工作流柔性需求.

2.2 指挥控制软件插件集成建模需求

2.2.1 集成建模需求

为了实现指挥控制软件的动态集成, 采用基于插件的集成方法, 在指挥控制软件插件开发和入库的前提下,利用工作流引擎驱动,实现基于规则的功能模块动态按需加载. 将指挥控制工作流模型中的活动节点与指挥控制软件插件关联, 在指挥控制流程执行过程中,通过获取关联的插件信息,实现对相应插件的调用并完成任务.因此,需要实现指挥控制软件插件的集成建模.

1)插件描述需求. 工作流在执行的时候会与外部应用有一定的交互, 这种交互的实现需要知道交互应用的相关信息, 以保证在工作流执行过程中能够正确调用相应的外部应用, 并完成任务. 在UML活动图中缺少被调用应用的相关图元, 本文提出一种通过对类图进行扩展的方法, 完成对所调用外部插件的描述. 在插件描述的构造型中添加对应活动节点的信息, 从而建立指挥控制软件插件与活动节点的对应关系. 插件描述信息从不同的方面对插件进行系统的描述,如:插件的功能信息、插件的接口信息和插件运行所需的环境信息.

a)插件的功能信息包括功能名称和是否拥有图形界面.

b)插件的接口信息包括输入的参数类型列表和返回的参数类型等.

c)插件的环境信息包括硬件环境和软件环境两部分. 硬件环境由最低计算机配置(内存和硬盘等)和网络要求等组成; 软件环境由操作系统和数据库等组成.

2)信息建模需求. 作战信息需求是为武器装备、作战部队和指挥控制系统提供的作战所需信息的总和. 信息建模是实现指挥控制软件插件集成的重要支撑. 针对目前的工作流建模方法中缺少信息建模的问题,提出扩展UML 描述作战信息的方法, 实现对动态信息和静态信息的刻画.

3)角色建模需求. 在工作流模型中,角色是必不可少的一部分,是活动的执行者. 在指挥控制流程执行过程中, 工作流引擎通过解析工作流模型将插件调用信息发送给登录用户与活动执行者一致的插件平台客户端,因此,需要指定活动的执行者. 在UML活动图中活动执行者的指定是通过泳道实现的, 存在不易修改的问题,本文放弃泳道图元,在活动节点中添加角色信息.

2.2.2 指挥控制软件插件集成建模需求与工作流模型的映射

通过对UML 活动图和类图的扩展,增加以下映射关系:

1)通过对UML 类图的改进, 实现插件描述图元,映射为工作流过程模型中的扩展信息.

2)通过对控制流的扩展实现动态信息建模, 并结合插件描述信息中的输入输出参数映射为工作流过程模型中的流程变量.

3)将UML 活动图中的动作状态划分为人工动作和自动动作, 并分别映射成工作流过程模型中的人工活动和自动活动.

4)舍弃UML 活动图的泳道,通过对人工动作状态的扩展实现角色的确定, 将其映射成工作流过程模型中的角色.

5)通过UML 组织结构图描述人员、角色、部门和职务间的关系, 并且映射成工作流过程模型所需的人员、组和权限关系.

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

2.3.1 柔性建模需求

在现代战争中, 战场环境充斥着不确定性和偶然性[15],战场态势是瞬息万变的,已有的指挥控制工作流建模方法中的业务流程都是固定的, 不能根据实际的战场情况灵活变化, 难以实现指挥控制系统的敏捷性和适应性. 因此,提出柔性的机动指挥控制工作流建模方法.

指挥控制工作流的柔性体现在流程应对指挥控制业务节点变更和调整的便利性, 能够针对不同的突发情况, 根据实际情况对已有的指挥控制业务工作流模型的流程实例进行及时调整, 以满足当前流程的突发情况, 实现指挥控制系统的敏捷性和自适应性. 本文将从节点柔性、流程柔性和时间柔性3 方面进行考虑.

1)节点柔性. 节点柔性是指根据当前战场态势判断该活动节点对应的任务是否需要执行, 若活动节点对应任务可不执行或当前活动节点对应的作战实体已损毁,则直接跳过该活动,根据指挥控制工作流模型的定义执行下一活动. 在工作流建模中通过定义与每个活动节点对应的布尔类型流程变量实现节点柔性,并且使用该参数来确定活动是否执行.

基于节点柔性能够实现基于同一指挥控制工作流模型的指挥控制流程动态定制, 指挥员能够在启动流程时,或者流程运行过程中,根据实际情况跳过某些任务节点,提高流程执行效率,来满足不同情况下流程高效运转的需求. 例如在指挥控制工作流中,如果打击目标的信息已经明确, 则可跳过侦察活动,直接流转至下一活动.

2)流程柔性. 流程柔性是指在建模时考虑各种可能的情况,实现任务分支全覆盖,能够根据流程执行过程中某些流程变量的值动态选择满足条件的分支, 实现在指挥控制流程执行过程中动态选择流程流转方向,以适应不同的实际情况. 以打击目标可用兵力计算插件为例, 所调用的插件与具体的打击目标类型相关, 如针对水面舰艇类目标使用打击水面舰艇类的可用兵力计算插件, 打击空中目标则使用打击空中目标类的可用兵力计算插件. 在工作流模型中使用条件网关完成不同打击目标类型对应不同可用兵力计算插件的建模, 实现在流程运行过程中根据打击目标类型,动态选择相应的分支,满足同一指挥控制工作流模型适应多任务的需求.

3)时间柔性. 在信息化战争中,作战双方体系与体系的对抗已成为战场对抗的基本特征. 体系作战对指挥决策过程有极强的时间限制, 要求在有限的时间内作出响应[16], 当某一任务无法在规定时间内完成时,不可能无限制等待下去,需要有相应的处理预案. 而现有的指挥控制流程并没有对时间进行建模, 所以无法对任务执行时间作出准确判断. 因此,本文增加时间信息的建模, 根据任务特点自定义设置最晚开始时间和持续时间等时间约束关系, 当任务执行者无法在规定时间内完成任务时, 将作出相应的处理,以此提高流程执行效率和模型柔性,避免因某一任务出现问题而导致整个流程无法运转.

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

指挥控制模型柔性需求与工作流模型的映射关系如下:

1)对人工活动和自动活动进一步扩展, 实现活动节点柔性. 在工作流模型中,每个活动节点都有与活动名对应的流程变量, 该值描述了对应的活动是否需要在已创建的流程实例中执行.

2)流程柔性在工作流模型中体现为不同条件的分支,映射为条件网关,通过对不同流程分支的组合,满足多任务需求,以适应实际情况.

3)通过对UML 活动图中控制流的扩展,实现对时间信息的建模, 映射为工作流过程模型中的边界定时器事件,实现时间计时.

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

UML 构造型是在已定义好的UML 模型元素的基础上构造出一个新的模型元素,为UML 增加新事物.使用UML 的构造型扩展机制能够满足指挥控制软件插件集成需求和指挥控制工作流模型柔性需求.

3.1 指挥控制软件插件集成建模

指挥控制软件插件集成建模阐述了基于UML扩展机制的工作流图元实现, 主要有插件信息描述图元、动态信息描述图元、静态信息描述图元和组织结构描述图元, 满足指挥控制软件插件集成建模的需求.

3.1.1 插件描述信息构造型

通过插件匹配模块解析插件描述信息, 并从插件本体库中匹配到匹配度最高的插件, 再将该插件的调用信息写入流程定义文件中, 工作流引擎解析流程定义文件实现插件的调用. 因此,插件描述对本文的集成工作有重要的作用, 对类图进行扩展实现插件信息的描述. 插件描述的构造型如图1 所示.

图1 插件描述构造型的声明和使用Fig.1 Declaration and utilization of plug-in description stereotypes

用“Plug-in Description” 表示插件描述. 根据插件的描述模型分别构建相应的属性, 如所需功能名(FunctionName)、是否需要图形界面(GUI)、输入参数(Input)、输出参数(Output)、操作系统(Operation System)、所用的数据库(Database Type)、当前环境所能提供的最高CPU 频率(CPU Frequency)、执行插件时允许的最大内存(Memory)、执行插件时允许的最大硬盘容量组成. 通过TaskId 唯一确定插件与活动的对应关系.

3.1.2 信息模型构造型

1)动态信息构造型

动态信息模型用于描述指挥控制流程运行过程中各活动节点间的输入输出信息, 以及指挥控制工作流以外的输入和输出信息.

指挥控制工作流模型动态信息的描述通过扩展控制流实现. 由于活动节点的输入参数和输出参数在插件描述中已有体现, 所以不在动态信息模型中重复构建, 动态信息模型构造型如图2 所示, InfoFlowName 表示从上一活动节点流向下一活动节点的信息.

图2 动态信息模型构造型的声明和使用Fig.2 Declaration and utilization of dynamic information model stereotypes

2)静态信息构造型

静态信息模型用于描述各作战实体间的信息发布和信息订阅, 帮助建模人员直观地了解各实体的基本情况, 辅助判断所建工作流模型能否满足信息正常流转的需求.

通过对类图的扩展实现对各作战实体发布信息和订阅信息的描述, 构造型如图3 所示. Name 定义了作战实体的名称, InputInfo 定义了实体需要订阅的信息,OutputInfo 定义了实体所能发布的信息.

图3 静态信息模型构造型的声明和使用Fig.3 Declaration and utilization of static information model stereotypes

3.1.3 人工活动构造型

人工活动构造型的声明和使用如图4 所示,用“User Activity” 来表示人工活动, 共有5 个属性,分别是TaskName、TaskId、AssigneeName/Group-Name、State 和Plugin. 其中, TaskName 表示当前活动的活动名; TaskId 用于唯一标识当前活动; AssigneeName/GroupName 用于指定可执行当前活动的用户或用户组;Plugin 用于描述活动对应的任务是否需要调用插件,true 表示需要调用插件;false 表示不需要调用插件.

图4 人工活动构造型的声明和使用Fig.4 Declaration and utilization of user activity stereotypes

3.1.4 自动活动构造型

自动活动构造型的声明和使用如图5 所示, 与人工活动构造型基本一致, 删除人工活动中的执行者,增加调用外部应用程序的相关描述.

图5 自动活动构造型的声明和使用Fig.5 Declaration and utilization of auto activity stereotypes

3.1.5 组织结构构造型

根据组织结构的层次关系, 将组织结构模型划分为3 个图元, 分别代表不同的组织结构内容, 3 个图元分别是: OrganizationTop 模块、OrganizationDepartment 模块和Organization-Person模块3 种类型.

1)OrganizationTop 模块是顶层结构, 它描述了当前指挥所的相关信息, 如它的上级指挥所和下级指挥所,描述了不同指挥所间的指挥关系.

2)OrganizationDepartment 模块是次顶层, 它描述了指挥所中各组织实体的相关信息, 包括实体的名称以及该实体所对应的信息.

3)OrganizationPerson 模块是最底层, 它描述了人员的相关信息和相应的席位.

使用3 层的组织结构模型描述了指挥所中人员所属的部门组织和席位, 为定义指挥控制流程模型中的角色提供参考.

OrganizationPerson 的构造型如图6 所示, Name定义了人员名,Seat 定义了人员的席位.

图6 组织结构构造型的声明和使用(指战员)Fig.6 Declaration and utilization of organizational structure stereotypes(staff)

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

指挥控制工作流柔性建模针对指挥控制工作流建模柔性需求, 在UML 扩展机制的基础上, 实现节点柔性、流程柔性和时间约束图元.

3.2.1 节点柔性构造型

节点柔性通过在图4 的人工活动构造型和图5的自动活动构造型中定义State 属性实现. State 属性定义了活动节点的状态, 其值为布尔值.true 表示该活动需要被执行, false 表示该活动节点对应的任务因可不执行或无法完成而跳过, 该状态默认均为true,可在流程启动时或流程执行过程中更改.

3.2.2 流程柔性构造型

流程柔性体现在根据工作流模型和实际情况动态选择相应的流程分支, 因此, 对分支与合并元图元扩展实现工作流模型中的条件网关, 如图7 所示.在条件网关中共有两个属性, 分别是gatewayID 和gatewayName. gatewayID 具有唯一性,用于标识每一个条件网关;gatewayName 定义了条件网关的名称.

图7 条件网关构造型的声明和使用Fig.7 Declaration and utilization of exclusive gateway structure stereotypes

3.2.3 时间建模构造型

采用扩展控制流的方法实现时间约束信息的建模,如图8 所示. 通过对控制流上事件的扩展实现对时间约束的建模,共有3 个属性,分别是EndTime 最晚结束时间、DurationTime 最长持续时间和UnitOf-Time 时间单位. 最晚结束时间是指流程执行过程中在该活动停留的最长时间; 最长持续时间是指完成该活动所需的最长时间. 根据这两个参数,便可根据活动的执行情况对活动执行者进行通知提醒, 避免错过活动; 若无法在最长持续时间内完成任务则执行预先定义的情况处置活动.

图8 时间约束Fig.8 Time constraint

3.3 工作流建模工具设计与实现

使用UML 建模工具完成对UML 元模型的扩展,实现基于UML 的工作流建模. 根据已有UML 建模软件的易用性和生成模型对应的可扩展标记语言文件的直观性和高可读性,选择Papyrus 作为工作流建模工具.

根据UML 的扩展机制以及Papyrus 的实现方法,共扩展了多种模型,如表1 所示,在Papyrus 中的实现如图9 所示.

表1 基于UML 的工作流扩展型Table 1 Workfl w extension based on UML

图9 使用Papyrus 扩展的图元(部分)Fig.9 Extended primitives using Papyrus(part)

基于扩展后的模型能够实现指挥控制工作流建模, 将构建的模型映射成BPMN2.0 规范后, 便能够被工作流引擎解析和执行.

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

4.1 案例背景

以美军火力旅指挥控制流程为案例背景[17], 采用本文提出的工作流建模方法, 并使用扩展后的工作流建模工具完成指挥控制工作流模型构建.

火力旅攻击移动目标的指挥控制流程大致如下:火力旅指挥所在接收到战备警报之后, 全旅进入战备状态,侦察雷达对目标进行搜索,雷达一旦发现敌对目标,则向目标连发送目标点迹信号,目标连在接收到相应的信号之后, 将信号发送给指挥所中的目标分配台,分配台完成敌方目标对应航迹计算、初始诸元计算和威胁评估分析, 并将结果发送到火力旅指挥所,由指挥员根据评估结果作出相应的决策,选择打击目标,并将目标信息发送给火力控制台,由火力控制台完成敌对目标的地理位置计算和精确的诸元计算, 最后由指挥员完成火力分配并将火力分配指令下发各导弹发射营, 指挥员根据雷达对目标监视获得的目标态势情况下达指令, 完成火力打击任务.流程图如图10 所示.

在图10 的流程描述中,可将组织结构分为目标侦察连、旅指挥所和导弹发射营等. 涉及的插件功能有通信、目标探测、目标接收和航迹计算等.

图10 火力旅打击移动目标流程图Fig.10 Flow chart of fir brigade hitting moving targets

静态信息建模如图11 所示,描述了目标侦察连和旅指挥所所能发布的消息和订阅的消息.

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

采用本文提出的方法构建火力旅指挥控制工作流模型,部分视图如图12 所示,该图中包含人工活动(User Activity)和自动活动(Auto Activity);描述了活动的执行者(leiDa、muBiao 等)和活动的时间约束;明确了是否需要调用插件; 明确了活动节点对应实际情况的可用性;描述了动态信息的流转. 以目标探测为例, 目标探测是由leiDa 执行的人工活动, 需要调用插件完成活动,接收前置活动发送的侦察指令,向后置活动发送敌方目标信息,该活动必须在50 min内完成,若在流程流转到该活动30 min 后,仍未开始执行,则对leiDa 进行提醒,若50 min 后活动仍未结束,则进入相应处置方案.

在该模型中,共有6 个任务和1 个条件分支. 在收到战备警报后流程正式开始执行, 根据时间约束信息,在规定时间内由雷达完成目标探测任务、目标连完成目标接收任务. 根据捕获的目标的类型执行不同的任务,若目标为移动目标,则调用相应指挥控制软件插件进行航迹计算和诸元计算. 在上述任务完成之后,将相关信息上报指挥所;若目标为固定目标,则直接将相关信息上报指挥所.

在图12 中,由于每一个活动都需要调用插件完成相应的任务,所以在插件描述模型中,为每一个活动创建对应的插件描述图元, 并写入相应的属性信息, 如图13 所示. 通过插件描述图元和活动图元的TaskId 属性建立插件描述图元和活动图元间的对应关系,因此,TaksId 具有唯一性.

图12 改进的UML 活动图示例Fig.12 Improved UML activity diagram

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

4.2 基于UML 的工作流建模实现

根据火力旅的指挥关系和组织结构, 构建的部分组织结构模型如图14 所示,使用扩展的组织结构3 层模型构建了旅-营-连-指战员的结构. 在读取该模型对应的XML 文件后,根据定义的标签读取相应的内容, 并将其添加到工作流引擎数据库中相应的数据表中.

图14 在Papyrus 中的组织结构模型（部分）Fig.14 Organizational structure model in Papyrus(part)

根据构建的作战实体静态信息, 使用扩展后的UML 类图描述如图15 所示.

图15 在Papyrus 中的静态信息模型Fig.15 Static information model in Papyrus

根据图12 构建的火力旅指挥控制工作流模型,使用Papyrus 构建的指挥控制工作流模型如图16所示.

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

在工作流模型中扩展的控制流中增加的动态流转信息和时间约束信息如图17 所示,动态流转信息描述了从顺序流的源头流向顺序流末端的信息; 时间约束信息描述了当前活动对时间的约束.

图17 工作流建模中信息流的体现Fig.17 Information fl w in workfl w modeling

为了体现节点柔性,在流程定义时,为每个活动定义了一个变量用于标识根据实际情况该活动是否需要执行. 该变量的值可在流程启动时或流程执行过程中变更, 在执行活动前先查询对应变量的值再决定活动是否执行,如图18 所示.

图18 实现节点柔性对应的参数Fig.18 Corresponding parameters of node fl xibility

使用Papyrus 构建的插件描述模型如图19 所示,该模块的ID 与对应的流程活动节点的ID 一致. 通过解析对应的XML 文件,获得活动对应的插件描述信息, 根据该描述信息使用插件匹配模块匹配到相应的插件, 并将插件调用的信息如插件名和版本号添加到流程文件中对应活动的扩展节点中, 便于工作流引擎的调用相应的插件.

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

以上述案例为背景, 构建基于工作流引擎的指挥控制软件插件集成系统, 开展基于工作流引擎的指挥控制软件插件集成验证. 使用本文提出的面向指挥控制软件集成的工作流建模方法并根据UML模型与BPMN2.0 模型的映射关系,实现指挥控制工作流模型与工作流语言的映射. 由Activiti 工作流引擎实现指挥控制工作流模型的解析、执行和插件的集成调用,并根据时间约束执行相应的操作.使用插件匹配模块,根据插件描述信息得到相应的插件,并将插件的调用信息以扩展元素的形式写入到流程定义文件中. 工作流引擎通过读取流程定义文件得到流程任务所要调用的插件的名称和版本, 根据该名称和版本完成插件的集成调用. 结果表明,提出的建模方法能够满足指挥控制软件基于插件的流程集成和流程柔性的需求.

5 结论

根据UML 活动图在工作流建模中的优势、实践过程中存在的不足和已有的指挥控制工作流模型的不足, 提出了改进的UML 活动图工作流建模方法,在活动节点中增加执行活动的用户信息,以避免使用泳道带来的修改不便; 根据指挥控制软件插件集成需求, 提出对UML 类图进行扩展,实现插件描述图元、静态信息图元和组织结构图元, 扩展UML活动图实现动态信息图元;根据工作流柔性需求,扩展UML 活动图实现节点柔性、流程柔性和时间柔性. 最后在对UML 建模工具进行扩展的基础上,通过对美军火力旅指挥控制流程的建模, 验证了提出的面向流程集成的指挥控制软件工作流建模的可行性. 但是在信息建模部分还不够完善, 后续将进一步研究.