一种C4ISR系统元模型构建方法

摘要

本发明公开了一种C4ISR系统元模型构建方法，其特征在于，包括如下步骤：（1）分析C4ISR领域特征，抽取C4ISR系统体系结构中的基本概念，及C4ISR概念与元模型元素之间的映射关系；（2）命名领域专用元模型元素；（3）建立元模型元素之间的关联；（4）建立领域元模型，描述元模型元素语法和语义特征。本发明建立的C4ISR领域元模型表示方法是一种领域专用建模方法，元模型由领域专用元素组成，这些元素不依附于任何仿真专用概念或环境。在设计表示法及其定义的元模型元素时，考虑到概念建模领域的特定需要，允许定义使命空间已有概念。

说明书

技术领域

本发明涉及一种领域元模型构建方法，特别是一种基于C4ISR系统的元模型构建 方法。

背景技术

在军事领域，对军事系统信息化的需求一直处在用自然语言定性描述的阶段，主 观因素较多，没有形成一套科学规范的工程方法。

随着对需求工程重要性的再次认识，开始使用一些工程手段进行军事需求的分析。 借鉴软件工程领域形成的一些概念建模技术，例如面向对象的建模技术、结构化方法 等，逐渐应用于对军事信息系统的需求分析中。但是军事信息化系统，尤其是C4ISR 系统（C4代表指挥，控制，通讯，计算机，四个字的英文开头字母均为“C，”所以称 “C4。”“I”代表情报；“S”代表电子监听；“R”代表侦察。C4ISR是军事术语,意为自动化 指挥系统。它是现代军事指挥系统中，7个子系统的英语单词的第一个字母的缩写,即 指挥Command、控制Control、通信Communication、计算机computer、情报Intelligence、 监视Surveillance、侦察Reconnaissance。），是一种巨大的复杂系统，涉及部门众多、 领域广泛，对系统的现状进行清晰的描述都比较十分困难；而军事需求是以当前系统 现状为基础的，未来战争中究竟需要什么样的军事系统、如何完成作战使命，是军事 专家、作战人员和技术人员都难以准确回答的问题。为了建设满足军事需求的信息化， 军事人员、系统分析和设计人员必须通力合作，形成对军事需求完整、详尽、准确的 形式化描述，保证所开发的系统完成作战使命。

统一建模语言（Unified Modeling Language，UML）是一个通用的可视化建模语言， 在军事系统信息化建设中，UML的应用十分广泛。美国国防部体系结构框架（DoDAF） 和英国国防部体系结构框架（MODAF）都引入了面向对象的思想，利用UML来建模。 由于UML是一个通用的建模语言，不具备领域特有性，所以使用UML对某个特定领 域建模时，不但需要熟练掌握UML建模流程，又要具有丰富的领域知识。而且UML 语义比较抽象，模型建立后难以验证领域的有效性和正确性。

特定领域建模（Domain-Specific Modeling，DSM）是近年来软件工程提出的一种 新的方法学，用于设计和开发系统，以模型和领域为中心的开发方法称为软件工程的 研究热点。DSM能够将特定领域的共性和变化特征抽象到比模型层更高的一层-元模型 层，通过统一的元模型定义领域专用语言（Domain-Specific Language，DSL）。定义 DSL的过程就是特定领域元模型构建的过程。通过元模型建模，对特定领域进行抽象 描述，定义DSL特有的语法和语义。

元模型（Meta Object Facility，MOF）是描述模型特定语言的模型，定义了一组相 关的架构、语义和限制条件。MOF是OMG采用的定义元数据的技术和表达元数据的 方法，用来定义面向对象元模型的基本元素、语法和结构。MOF框架的核心层为元- 元模型层，及描述元模型的模型，通过类、属性和关联等元素定义元模型。MOF和 UML之间的主要区别是前者旨在元数据建模，后者则是对象建模。

对象约束语言OCL用来描述对象的约束和相互之间的关联关系，用于面向对象的 分析与设计。由于通常的元模型描述方法通常不够精细，难以提供与规范有关的所有 相关部分，比如缺少描述模型中对象的附加约束，这些约束常常是用容易引起歧义的 自然语言描述的。相对而言，OCL是一种容易理解和使用的形式语言，能够使模型更 加精确。

因此，如何能够开发出一种便于理解、表示的模型成为整个C4ISR系统构建的重 要的第一步，决定着整个系统的走向，是一个重要的技术难点。

发明内容

发明目的：本发明所要解决的技术问题针对现有技术针对在C4ISR领域中建模时 出现的缺乏领域专用建模法、表示法不足以表现领域特征、领域专家在理解表示法面 临困难等不足，提供一种C4ISR系统元模型构建方法，该方法无需领域专家具备很多 建模语言方面的知识，能同时便于领域专家和建模者理解。

为了解决上述技术问题，本发明公开了一种C4ISR系统元模型构建方法，包括如下步 骤：

（1）分析C4ISR领域特征，抽取C4ISR系统体系结构中的基本概念，及C4ISR 概念与元模型元素之间的映射关系；

（2）命名领域专用元模型元素；

（3）建立元模型元素之间的关联；

（4）建立领域元模型，描述元模型元素语法和语义特征。

本发明所述步骤（1）中，C4ISR系统体系结构中的基本概念包括使命、任务、目 标、事件、活动、数据项、能力、命令控制单元、执行者。

本发明所述步骤（2）中，C4ISR概念与元模型元素之间采用n对1映射关系，这 种映射关系是多对一的映射关系，一到n个C4ISR概念对应一个元模型元素。其中使 命概念在元模型中用使命元素表示；任务、活动和事件概念在元模型中用任务元素表 示；目标概念用目标元素表示；数据项和能力概念用实体元素表示；命令控制单元概 念用使用者元素表示；执行者概念用角色元素表示。

本发明包括以下步骤：

（a1）定义实体：实体从工作文档的语句中得到，由组成实体特征的属性和能力 定义；

（a2）定义使命和任务：将使命空间中的最高层任务定义为使命，根据使命对任 务进行逻辑分组，把最相关的任务划分到相同使命下，同时定义每项使命的目标和度 量标准，每项任务的工作产品；

（a3）定义行动者和角色：将行动者关联实体，将角色附属于一个行动者。

本发明使命包括以下属性：输入列表，输出列表，前置条件，后置条件，目标列 表，角色列表，通过负责或实现关系与使命相连的角色列表，度量列表；使命元素包 括三个约束条件：一项使命至少有一个相关角色，一项使命至少与一个目标相关，一 项使命可以没有自包含或自归纳的关系；

目标有两个属性：度量列表、执行标准；目标元素有一个约束条件，目标应至少 与一项度量标准相关；

实体包括三条属性：属性、能力、关联列表；

使用者包括一条属性：角色列表；

角色包括两个属性：任务列表、拥有列表；角色元素包括一个约束条件，一个角 色应至少有一个使用者作为所有者。

本发明所述步骤（2）或步骤（3）中，对模型元素、元模型元素之间的关联的附 加约束条件用对象OCL约束语言表示。

本发明通过现有成熟的C4ISR体系结构、军事领域专家及条令条例、军事著作文 献、期刊、标准数据等知识确定C4ISR领域的概念。

本发明通过建立C4ISR概念与模型专用元素的映射关系，来确定领域专用元模型 元素。利用对象约束语言OCL用来描述对象的约束和相互之间的关联关系的特性，来 描述模型元素和关联关系的约束。针对核心设计元素，选取UML中与之相近的元类继 承加以扩展，重新定义元素的语法和语义。

有益效果：本发明建立的C4ISR领域元模型表示方法是一种领域专用建模方法， 元模型由领域专用元素组成，这些元素不依附于任何仿真专用概念或环境。在设计表 示法及其定义的元模型元素时，考虑到概念建模领域的特定需要，允许定义使命空间 已有概念。另外，它在某些地方重用了UML元模型元素，但是在核心元素设计上重新 定义了元素的语法和语义，同时利用OCL语言约束模型元素和关联，使之更加适合 C4ISR领域的表示。

附图说明

下面结合附图和具体实施方式对本发明做更进一步的具体说明，本发明的上述和/ 或其他方面的优点将会变得更加清楚。

图1是C4ISR概念与元模型元素之间的映射关系图。

图2是元模型元素的关联图。

图3是C4ISR系统的领域特征元模型图。

图4是C4ISR系统使命空间图。

图5是C4ISR系统任务流程图。

具体实施方式

本发明首先根据现有成熟的C4ISR体系结构、军事领域专家及条令条例、军事著 作文献、期刊、标准数据抽取的C4ISR领域概念。为了和国外相应C4ISR概念对照， 如表1所示，概念分为中文名称和英文名称。

表1C4ISR领域概念

中文名称 英文名称 使命 Mission 任务 Task 目标 Objective 事件 Event 活动 Activity 数据项 Data items 能力 Capability 命令控制单元 Command and control unit 执行者 Executor

使命表示针对仿真目标的一系列有序任务。任务是使命的细化，可在不同使命间 重复利用；目标代表使命或任务的目的，每项使命应至少有一个有意义的目标；活动 为完成使命任务必须开展的活动；事件是在任务执行过程中发生的引起事态变化的状 态结果；数据项指实体之间交互的信息；能力代表实体可能执行的功能；命令控制单 元指能够发布命令的设施或指挥员；执行者指能够完成指挥命令的单元或执行人员。

C4ISR概念与元模型元素之间的映射关系如图1所示，是一种n对1关系。“使命” 概念在元模型中用“使命”元素表示；“任务”，“活动”和“事件”概念在元模型中用 “任务”元素表示；“目标”概念用“目标”元素表示；“数据项”和“能力”概念用 “实体”元素表示；“命令控制单元”概念用“使用者”元素表示；“执行者”概念用” 角色”元素表示。除了映射的几个元模型元素，还需定义“度量标准”和“工作产品” 元素以描述“目标”和“任务”元素。下面描述元模型元素的语义，属性及其约束。 OCL的基础是集合论和三值逻辑，并且它有一个形式化的数学语义，因此它可以明确 无歧义地表示模型元素。

使命代表了仿真系统应实现的最高级的任务。使命可以通过包含或归纳关系与其 它使命连接。一项使命应与将要开发的仿真系统工作文档指定的仿真目标或高级需求 相关。使命有以下几点属性：

（1）输入列表：通过输入关系与使命相连的工作产品列表。

（2）输出列表：通过产生关系与使命相连的工作产品列表。

（3）前置条件：使命执行必需的。

（4）后置条件：在使命执行之后发生。

（5）目标列表：与使命相连的目标列表。

（6）角色列表：通过负责或实现关系与使命相连的角色列表。

（7）度量列表：通过量化关系与使命相连的度量列表。

使命元素有三个约束条件，每个约束条件可用OCL语言描述如下：

（1）一项使命应至少有一个相关角色：

context Mission self.roleList.size()>0

（2）一项使命应至少与一个目标相关：

context Mission self.objectiveList.size()>0

（3）一项使命可能没有自包含或自归纳的关系：

context Includes S=self.source AND T=self.Target implies not(S=T)

context Generalizes S=self.source AND T=self.Target implies not(S=T)

任务是使命的细化，可在不同使命间重复利用。任务与使命有相同的结构，但另 外还存在一些属性：

（1）是否为扩展点：用来确定任务是不是扩展点的布尔值。

（2）扩展点标识：用来识别和引用为扩展点的任务。

任务元素有两个约束条件，每个约束条件可用OCL语言描述如下：

（1）一项任务应与至少一个角色相关

context Task self.roleList.size()>0

（2）一项任务应至少与一个目标相关

context Task self.objectiveList.size()>0

目标代表使命或任务的目的，与仿真目标相关。每项使命应至少有一项有意义的 目标。目标的执行情况要视目标相关度量标准而定。目标有两个属性：

（1）度量列表：与目标相连的度量标准列表。

（2）执行标准：基于度量列表的标准或者公式，通过计算决定任务或使命的执行情 况。

目标元素有一个约束条件，每个约束条件可用OCL语言描述如下：

（1）目标应至少与一项度量标准相关。

Objective self.measureList.size()>0

度量标准是一个可计量的元素，定义用来决定目标的执行情况。目标如满足所有 相连的度量标准，则被认为是成功的。度量标准有一个属性：

（1）单位：可计量的度量标准单位，如米、小时、数量等。

度量标准元素有一个约束条件，每个约束条件可用OCL语言描述如下：

（1）度量标准应至少与一个目标相关。

context Measure exists o:Objective in objectives where o.measureList.includes(self)

工作产品表示完成任务所必须的任何输入或产生的任何输出。工作产品可能由任 务产生，并在该任务的环境中被消费掉，也可以被另一个任务消费掉。工作产品的生 成并不一定意味着工作产品就是由任务创建的，也可能是一种修改。工作产品没有附 加属性，也没有约束条件。

实体用来表示使命空间中任意逻辑或物理的实体，它可能是需要存储的具有可辨 识特征的任意项，例如人员，地点，组织，物资，对象或者概念实体是最常用的元模 型元素。实体有三条属性：

（1）属性：实体本身拥有的属性列表。

（2）能力：实体拥有的能力列表。能力代表实体可能执行的功能。例如坦克实体可 能具有以下能力：“越野”、“爬坡”、“涉水”、“发射炮弹”等。这些能力是参与任务所 必须具备的。

（3）关联列表：指向实体的关联的列表。

使用者是代表使命空间内指挥单位的抽象元素。使用者可代表人类或任何其他活 动的实体。使用者是从实体导出的。它不能执行任务，但定义执行任务的角色时要用 到。使用者有一条属性：

（1）角色列表：使用者拥有的角色列表。

角色代表“负责”或“实现”一项任务或使命的活动的使用者，用来代表可执行 任务或使命的人类或其他活动的实体。角色有两个属性：

（1）任务列表：通过“负责”或“实现”关系与角色相连的使命和任务列表。

（2）拥有列表：通过“拥有”关系与角色相连的使用者列表。

角色元素有一个约束条件，每个约束条件可用OCL语言描述如下：

（1）一个角色应至少有一个使用者作为所有者

context Role self.ownerList.size()>0

图2为元模型元素的关联图，定义了元素之间的八种关联关系。下面描述这八种 关键的语义，属性及其约束。

负责关联代表的是角色和任务或使命之间的关系。与任务或使命有这种关系连接 的角色要负责该任务或使命的执行。负责关联有一个约束条件，每个约束条件可用OCL 语言描述如下：

（1）负责关联中，角色是源端，任务或使命是目标端。

context ResponsibleFor self.source.isTypeOf(Role)AND(self.target.isTypeOf(Task)OR  self.target.isTypeOf(Mission))

实现关联代表的是角色和任务或使命之间的关系。与任务或使命有这种关系连接 的角色要实现该任务或使命的执行。实现关联有一个约束条件，每个约束条件可用OCL 语言描述如下：

（1）实现关联中，角色是源端，任务或使命是目标端。

context Realizes self.source.isTypeOf(Role)AND(self.target.isTypeOf(Task)OR  self.target.isTypeOf(Mission))

扩展关联指定了扩展使命（源）定义的行为如何、何时插入被扩展使命（目标） 定义的行为中。这种关系指定了一项使命（目标）的行为可被另一项使命（通常是补 充性的）的行为扩展。扩展在被扩展使命定义的一个或多个具体的扩展点进行。

被扩展使命的定义、意义皆与扩展使命无关。另一方面，一般扩展使命定义的行 为自身无需有意义。相同的扩展使命可扩展不止一项使命。此外，扩展使命自身也可 以被扩展。

扩展关联有两个约束条件，每个约束条件可用OCL语言描述如下：

（1）扩展关联中，一项使命为源端，另一项使命为目标端。

context Extends self.source.isTypeOf(Mission)AND(self.target.isTypeOf(Mission))

（2）扩展关联中，不能有相同的使命既是源端又是目标端。

context Extends Mission1=self.source AND Mission2=self.target implies not  (Mission1=Mission2)

包含关联定义了一项使命容纳另一项使命定义的行为。包含是两项使命之间的一 种定向关系，指被包含使命（目标）的行为被插入到包含使命（源）的行为中。包含 使命可能仅取决于被包含使命的结果（值），这个结果（值）是通过执行被包含使命而 获得。被包含使命并非选择性，而是包含使命正确执行所必需的。

两项使命之间的包含关联意味着包含使命定义的行为被包含在基本使命的行为 中。包含关联意图用在当两个或两个以上使命的行为有共同部分的时候。共同部分将 被提取到一个单独的使命中，供所有含有这部分共同体的基本使命执行包含。被包含 使命的执行与子程序调用类似。被包含使命的所有行为都在被包含使命中的单一位置 执行，之后再继续进行包含使命。包含关联有两个约束条件，每个约束条件可用OCL 语言描述如下：

（1）包含关联中，一项使命为源端，一项使命为目标端

context Includes self.source.isTypeOf(Mission)AND(self.target.isTypeOf(Mission))

（2）包含使命中，不能有相同使命既是源端又是目标端

context Includes Mission1=self.source AND Mission2=self.target implies not  (Mission1=Mission2)

完成关联定义的是使命或任务与目标之间的关系。使命或任务可能有许多目标， 当完成所有目标时，该使命或任务将被视为成功。完成关联有两个约束条件，每个约 束条件可用OCL语言描述如下：

（1）完成关联中，使命或任务是源端，目标为目标端

context Achieves(self.source.isTypeOf(Task)OR self.source.isTypeOf(Mission))AND  (self.target.isTypeOf(Objective))

输入关联用来表示执行任务所需的工作产品。一项任务可能要求输入许多个工作 产品。输入是一种工作产品为源端、任务为目标端的定向关系。完成关系有一个约束 条件，可用OCL语言描述如下：

（1）输入关联中，工作产品为源端，任务为目标端

context InputTo self.source.isTypeOf(WorkProduct)AND(self.target.isTypeOf(Task))

生产关联用来代表任务执行后或期间的工作产品。任务输出可能会有许多个工作 产品。生产是一种任务为源、工作产品为对象的定向关系。生产关联有一个约束条件， 可用OCL语言描述如下：

（1）生产关联中，任务为源端、工作产品为目标端。

context Produces self.source.isTypeOf(Task)AND(self.target.isTypeOf(WorkProduct))

量化关联用来代表目标和度量标准之间的关系。目标的执行情况通过评估目标相 连的度量标准来决定，由量化关联表示。量化关联有一个约束条件，可用OCL语言描 述如下：

（1）量化关联中，目标为源端，度量标准为目标端。

context QuantifiedBy self.source.isTypeOf(Objective)AND  (self.target.isTypeOf(Measure))

图3为C4ISR系统的领域特征元模型，该元模型展示了元模型元素之间的继承关 系，关联和规则。

使命和任务之间是一种多对多关系。一项任务必须至少属于一项使命，一项使命 必须至少包括一项任务。任务之间存在组成关联，每个个体扮演任务节点（task Node） 的角色。一项任务可能包括许多子任务，也可能是许多项任务的一部分。一项任务可 能生产一份工作产品，零份或多份工作产品可能会输入进一项任务中。

使命和任务都可能有一个或多个目标，通过完成关联起来。目标和度量标准之间 是一种多对多关系。每个目标可用一条或多条度量标准来量化。一条度量标准必须与 至少一个目标相关。一项使命可通过包含关联或扩展关联与其它使命关联。

一个角色实现或负责一项或多项使命。一个角色实现或负责一项或多项任务。角 色和使用者之间的这种多对多关系意味着一个角色可能属于许多个使用者，一个使用 者也可能拥有许多个角色。一个使用者可以地位高于许多其他使用者，也可以是许多 其他使用者的下属。

使用者从实体继承而来。一个实体可能拥有许多属性、能力、零个或一个状态机 （State Machine）。状态机用来表示实体的行为，状态是一个对象在生命过程中的一 种情况或状况，期间它满足某些情况、执行某些活动、或等待某些事件。状态被包含 在状态机中，状态机描述了一个对象随时间发展对事件的响应历史。一个实体可能通 过关联（Association）、聚集（Aggregation）或泛化（Generalization）等关系与 另一个实体相关。

实施例

图4和图5为本发明在C4ISR系统实例应用实施例图。系统有三个使命：监视， 侦查和通信。监视使命有一个目标：实施监视，由4个度量标准。度量模型元素包括 定义度量单元和在目标模型元素中定义目标完成的标准。度量标准包括覆盖边界的长 度，覆盖的时间，探测/识别/认可率，覆盖的密度和花费。这些标准用尺标可以用“公 里”，“分钟”，“认可的威胁数目”/“探测的威胁数目”，“覆盖边界的面积”和“金钱花 费多少”作为度量单元。使命的表现可以检查这些度量标准来识别。当所有成功阈值 都满足时，认为该使命成功完成。如果“覆盖边界长度超过12km”，“时间消耗小于20 分钟”，“探测/识别/认可率超过60%”，“覆盖密度超过80%”和“金钱消耗小于10000” 同时满足，认为监视目标是成功的。

图5用任务流图表示使命的细节，利用宽度优先迭代法表示任务流图。从一个使 命开始，描述最高层任务流图，包括任务和相关的工作产品。在第一次迭代中目标， 度量标准和角色没有出现。接着依次来描述这个任务流图中的任务。

图5描述的是“分析侦查信息任务细节”。初始状态后的同步标识意为这个任务由 三个任务同时执行的。由于没有制定并行任务执行的起始事件，这些任务可能同时开 始，也可能有一些延迟。“综合视觉侦查信息”后的决定点表示由条件查询决定的分支。 每个分支的防护条件必须标记，以防这些条件冲突。首次迭代时建模者定义了任务， 这些任务的控制流，同步点和决定点。第二次迭代主要定义角色和与这些任务相连的 工作产品。任务和工作产品之间有两个预先确定的关联类型：“产生”和“输入”。“分 析和评估视觉侦查信息”任务产生了工作产品“视觉侦查”。

本发明提供了一种C4ISR系统元模型构建方法，具体实现该技术方案的方法和途 径很多，以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技 术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进 和润饰也应视为本发明的保护范围。本实施例中未明确的各组成部分均可用现有技术 加以实现。