CN108804818A - 一种基于face架构的软件系统建模方法 - Google Patents

Abstract

本发明提出一种基于标准架构FACE的软件系统建模方法，包括系统组件化、数据建模、系统I/O服务建模及组件传输服务建模等方法。本发明提出的建模方法可以指导我国航空电子系统架构的建模，可以作为FACE架构下的系统建模相关工具链及平台的研制的理论依据进行实际应用。本发明有利于提高软件质量和开发效率，增强软件可移植性，节约开发成本，便于系统的快速集成，缩短系统的开发周期，推动国内航空领域统一的开放式软件架构标准的形成。本发明可运用于高可信、高可靠、高安全领域，例如，航空领域、航天领域等软件密集产业。

Description

一种基于FACE架构的软件系统建模方法

技术领域

本发明涉及基于FACE架构的软件系统建模方法。

背景技术

新一代航空电子系统的任务重要度及功能复杂度越来越高，同时电子信息技术和计算机技术飞速发展，以及高度综合化的设计要求为航空电子系统带来了很多挑战，其中机载软件和硬件绑定紧密、系统升级困难、重用性差是导致航空电子系统开发代价高的关键因素。我国第四代机航空电子系统仍属针对一组特定的需求由单一开发商提供服务，导致系统升级程序繁琐，所研发的硬件和软件在不同型号或各种类似功能的航空平台上无法重复使用。目前航空电子系统普遍存在软件与硬件平台、操作系统和网络架构的高耦合问题，导致系统软件升级困难、可移植性与可重用性差。

根据航空电子系统的发展特征，为了保证航空电子系统软件的可靠性、提高软件在全生命周期中的可维护性和可移植性，缩短软件系统开发周期，将航空电子应用软件与机载实时操作系统的接口标准化，实现底层软件与上层应用软件隔离，以便更好地适应系统结构升级和功能扩展的需求，国际开放组织(The Open Group)于2014年发布了FACE(Future Airborne Capability Environment，未来机载能力环境)架构。FACE技术描述了与硬件无关的标准化软件COE(Common Operational Environment)，以及与模块化软件组件相关的架构段需求，并定义了将这些架构段链接在一起的关键接口。

国内看到了FACE架构在航空电子系统中的应用前景，在2017年的航空基金明确提出该类课题的探索和研究项目。但是国内的相关论文大都是对FACE架构的介绍，对FACE架构在航空电子系统中的应用和实现均未提出明确的实施方法和设计思路。

本专利结合新一代航空电子系统软件发展需求，在研究FACE标准、软件架构理念以及数据架构的基础上，从系统角度提出FACE架构下的软件系统的组件化建模方法，将FACE架构应用到实际航空电子系统开发过程中。

发明内容

要解决的技术问题

本发明主要解决如何基于FACE标准架构软件系统建模的问题，包括系统组件化方法、面向组件端口和消息类型的数据建模、组件与外设通讯的I/O服务建模及组件间传输服务建模。为此，本发明提出了一种基于标准架构FACE的软件系统建模方法。

技术方案

FACE为航空电子系统提供了系统架构的标准，本发明结合架构的标准和构成要素，从系统角度，通过逐步系统功能细化，以各功能或子功能到FACE组件的映射方法为线索，提出架构下的层次化、组件化建模方法，具体建模过程如图1所示。

1)根据软件系统需求，对系统功能结构进行划分。首先将一个系统划分为若干子系统，然后将一个子系统划分若干子系统或功能，一个功能细化为多个子功能，使系统功能尽可能的细化，将最终的系统功能划分结果用树表示。

2)将树中节点映射为不同类型和用途的FACE组件。首先给出特定平台组件(PSSS组件)以及可移植组件(PCS组件)的生成方法，然后确定组件的端口，以及组件间消息传输方式，最后，采用UML协作图对系统建模的组件及组件间通讯进行表示。

3)对2)中生成的每个组件的端口及其消息传输类型进行数据建模。每一个组件相关的数据建模通过概念数据模型、逻辑数据模型、平台数据模型以及可移植单元数据模型进行逐层、逐级细化，直至给出每个数据实体的详细属性信息及属性的类型为止。

4)对2)中每个特定平台组件与外部设备进行通讯的输入输出(I/O)服务进行配置和建模。

5)对2)中每个特定平台组件与应用层可移植组件，以及应用层可移植组件之间的数据通讯的传输服务进行配置和建模。

基于上述原理，本发明的技术方案为：

所述一种基于FACE架构的软件系统建模方法，其特征在于：包括以下步骤：

步骤1：系统功能分析：

根据系统需求对系统功能进行迭代分析，将一个系统划分为若干子系统，单个子系统划分为若干子系统或功能，一个功能细化为多个子功能，使系统功能细化；将最终的系统功能分析结果用系统功能树表示；

系统功能树包含两种类型的节点：系统节点和功能节点；其中系统节点分为根节点以及子系统节点；根节点能够包含若干个子系统节点；一个子系统节点能够包含子系统节点和功能节点；一个功能节点能够包含若干功能节点；

步骤2：系统功能组件化：

步骤2.1：将系统功能树中所有的功能节点均映射为系统组件，并根据是否直接与外部设备交换数据细化每一个系统组件；细化组件时，新增组件的个数与直接同该组件交换数据的外部设备的个数相关：

(1)当组件不与外部设备直接进行数据交换时，不用新增组件；

(2)当组件与一个外部设备直接进行数据交换时，不用新增组件；

(3)当组件与n个外部设备直接进行数据交换时，新增n(n>1)个组件；

步骤2.2：按照以下组件划分规则，对所有系统组件进行划分，划分为特定平台组件PSSS或者可移植组件PCS：

(1)若组件直接或间接与外部设备相关，则组件为PSSS组件；

(2)若组件用于提供系统级健康监控、集中式配置服务、流媒体服务或者日志服务，则组件为PSSS组件；

(3)若组件用于提供图形相关服务，组件为PSSS组件；

(4)其他独立于外部设备以及在各个平台之间可以直接复用的组件为PCS组件；

步骤2.3：根据实际应用需求，确定系统中各组件之间交换的数据信息以及数据信息传输方向；

步骤2.4：确定组件间的传输方式、组件与外部设备驱动之间的传输方式以及组件与操作系统之间的传输方式：

组件、操作系统以及外部设备驱动之间的传输方式满足以下规则：

(1)PSSS组件与外部设备驱动之间通过I/O服务接口IO传输；

(2)PSSS组件之间通过传输服务接口TS传输；

(3)PSSS组件与PCS组件之间通过TS接口传输；

(4)PCS组件之间通过TS接口传输；

(5)PSSS组件与操作系统之间通过操作系统接口OS、FACE语言运行时环境接口RT或FACE框架接口FW传输。

步骤2.5：将系统功能的组件化建模结果用UML协作图表示；

步骤3：概念数据模型建模：面向概念数据模型元素，参考FACE组件协作图中组件间的数据交互信息，建立概念数据模型，建模结果用UML类图表示：概念数据模型元素包括概念实体、概念联系、可观察量以及概念视图；

步骤4：逻辑数据模型建模：面向逻辑数据模型元素，通过引入物理平台细节来细化概念数据模型，建模逻辑数据模型，建模结果使用UML类图表示；逻辑数据模型元素包括逻辑实体、逻辑关联、测量、以及逻辑视图；

步骤5：平台数据模型建模：面向平台数据模型元素，通过引入具体计算平台相关的物理细节，细化逻辑数据模型，建模平台数据模型，建模结果使用UML类图表示；平台数据模型元素包括平台实体、平台关联、平台视图以及与平台相关物理数据类型；

步骤6：可移植单元模型建模：面向系统组件、逻辑平台视图以及组件的输入输出端口，设计组件的消息类型与消息传输接口，构建可移植单元模型，建模结果使用UML类图表示；

步骤7：I/O配置文件建模：面向PSSS组件与外部设备驱动的I/O连接，对I/O配置文件进行建模，建模结果用XML格式的文件表示；

步骤8：组件间传输服务建模：结合FACE组件协作图，分析系统组件之间的消息传输特性，对传输服务层进行建模，建模结果用传输服务配置文件表示。

进一步的优选方案，所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤3中概念数据模型建模的具体过程为：

步骤3.1：创建概念实体：

分析步骤2得到的FACE组件协作图的实际应用场景，确定概念模型实体的个数并创建相应的UML类；将每一个实体映射为UML类图中的一个类；

步骤3.2：创建可观察量：

分析实体的可观察信息，确定概念数据模型的可观察量并创建相应的UML类；将每一个可观察量映射为UML类图中的一个类；

步骤3.3：确定概念实体与可观察量之间的关系：

根据实际应用场景，将可观察量进行组合作为概念实体的属性，以完善概念实体；在UML类图中，将可观察量的类作为概念实体的类的成员；

步骤3.4：确定概念实体之间的关系：

参考FACE组件协作图，面向组件的数据流向，根据组件的输出对输入的依赖关系，确定实体间的关联实体并绘制UML类图中各类之间的关联关系，并在UML类图中为概念实体的类之间建立依赖关系。

进一步的优选方案，所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤4中逻辑数据模型建模的具体过程为：

步骤4.1：创建逻辑测量：根据实际应用中传输的数据信息，为概念模型的每一个可观察量创建一个能够表示该可观察值的逻辑测量；根据该逻辑测量的标准组成对每一个逻辑测量进行细化；将每一个逻辑测量映射为UML类图中的一个类；UML类图中测量类依赖可观察类；

步骤4.2：创建逻辑实体：细化概念模型，为概念数据模型中每一个实体创建相应逻辑数据模型实体，实体特征通过引用逻辑测量来表示；将每个逻辑实体映射为UML类图中的一个类；UML类图中逻辑实体类依赖概念实体类；

步骤4.3：创建逻辑视图：通过创建逻辑视图定义要由组件接收和发送的消息内容：将每一个逻辑视图映射为UML类图的一个类，逻辑视图的类依赖概念实体的类。

进一步的优选方案，所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤5中平台数据模型建模的具体过程为：

步骤5.1：进行面向接口定义语言IDL的数据类型映射：根据FACE创建的所有逻辑数据模型中的测量值确定测量系统，为测量系统的每个度量确定具体物理数据类型；平台数据模型支持的物理数据类型直接对应于接口描述语言IDL数据类型；在UML类图中每一个平台表示映射为一个类，该类依赖逻辑数据模型中对应测量表示的类；

步骤5.2：创建平台实体：细化逻辑模型中的逻辑实体，创建与逻辑实体一一对应的平台实体，实现逻辑模型中的相应实体元素；在UML类图中每一个平台实体映射为一个类，平台实体的类依赖逻辑实体的类；

步骤5.3：创建平台视图：创建流入和流出组件的消息的平台视图；将平台实体的特征投影到视图中；在UML类图中每一个平台视图映射为UML类；平台视图的类依赖逻辑视图的类，并依赖平台实体类。

进一步的优选方案，所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤6中可移植单元模型建模的具体过程为：

步骤6.1：创建可移植单元：将一个组件构建为一个可移植单元模型，可移植单元模型的类型由组件类型确定：如果组件为特定平台组件，则构建的可移植单元模型为特定平台可移植数据模型；如果组件为可移植组件，则构建的可移植单元模型为与平台无关的可移植数据模型；将每一个可移植单元模型映射为UML类图中的一个类；

步骤6.2：创建消息端口：根据组件的数据输入流与输出流，确定该可移植单元模型的端口数量，为可移植单元创建消息端口并建模每个端口的特征；将每一个消息端口映射为UML类图中的一个类，端口特征映射为类中的附加信息；并在类图建立可移植单元的类与端口的类之间的依赖关系，可移植单元的类依赖所有端口的类；

步骤6.3：设置消息类型：将平台数据模型中的平台视图映射到消息端口，以描述使用该端口所传递的消息；在UML类图中建立端口的类与平台视图的类之间的依赖关系，端口的类依赖该平台视图的类。

进一步的优选方案，所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤7中I/O配置文件建模的具体过程为：

步骤7.1：从系统功能的组件化建模阶段得到的FACE组件协作图中，找出所有与外部设备驱动直接进行数据交换的PSSS组件，为每个PSSS组件创建一个I/O配置文件；

步骤7.2：从FACE组件协作图中，确定一个PSSS组件与外部设备的I/O连接数量，I/O连接的数量为FACE组件协作图中与该组件进行数据交互的外部设备的有向箭头个数；并参照配置文件格式对该PSSS组件的每一个I/O连接进行配置。

进一步的优选方案，所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤8中组件间传输服务建模的具体过程为：

步骤8.1：参考系统功能的组件化建模阶段得到的FACE组件协作图，为每个系统组件创建一个传输服务配置文件；

步骤8.2：从FACE组件协作图中，根据组件使用TS进行数据传输的数据流的数量确定组件的传输服务连接数量，并参照配置文件格式对该PSSS组件的每一个传输服务连接进行配置。

有益效果

通过本发明，可以实现基于FACE标准架构的软件建模，包括系统组件化、数据建模、系统I/O服务建模及组件传输服务建模等方法。本发明提出的建模方法可以指导我国航空电子系统架构的建模，可以作为FACE架构下的系统建模相关工具链及平台的研制的理论依据进行实际应用。本发明有利于提高软件质量和开发效率，增强软件可移植性，节约开发成本，便于系统的快速集成，缩短系统的开发周期，推动国内航空领域统一的开放式软件架构标准的形成。本发明可运用于高可信、高可靠、高安全领域，例如，航空领域、航天领域等软件密集产业。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1：FACE架构下的系统建模方法步骤示意图；

图2：系统功能树；

图3：FACE软件架构及传输接口；

图4：FACE组件协作图示意；

图5：实施例中系统功能结构图；

图6：实施例中功能、组件以及外设映射关系；

图7：实施例中飞机作战辅助系统的组件协作图；

图8：实施例中飞机作战辅助系统的分区示意图；

图9：实施例中概念数据模型类图；

图10：实施例中部分逻辑数据模型类图；

图11：实施例中部分平台数据模型类图；

图12：实施例中可移植单元数据模型类图；

图13：实施例中定位组件(Navigation Sensor1)的I/O连接配置；

图14：实施例中定位组件(Navigation Sensor1)传输服务配置信息。

具体实施方式

本发明结合架构的标准和构成要素，从系统角度，通过逐步系统功能细化，以各功能或子功能到FACE组件的映射方法为线索，提出架构下的层次化、组件化建模方法，具体建模过程如图1所示。

步骤1：系统功能分析：根据系统需求对系统功能进行迭代分析，将一个系统划分为若干子系统，一个子系统划分若干子系统或功能，一个功能细化为多个子功能，使系统功能尽可能的细化。将最终的系统功能分析结果用系统功能树表示，如图2所示。

系统功能树包含两种类型的节点：系统节点和功能节点，其中系统节点分为系统节点(或根节点)以及子系统节点。一个系统节点可包含若干个子系统节点；一个子系统节点既可以包含子系统节点，也可以包含功能节点；一个功能节点可包含若干功能节点。其中，系统节点采用椭圆表示，功能节点采用方框表示。

步骤2：系统功能组件化

1)将系统功能树中所有的叶子功能节点均映射为系统组件，并根据是否直接与外部设备交换数据细化每一个系统组件，即为系统新增组件。细化组件时，新增组件的个数与直接与该组件交换数据的外部设备的个数相关。

(1)当组件不与外部设备直接进行数据交换时，不用新增组件；

(2)当组件与一个外部设备直接进行数据交换时，不用新增组件；

(3)当组件与n个外部设备直接进行数据交换时，新增n(n>1)个组件；

2)FACE组件包含特定平台组件(PSSS组件)以及可移植组件(PCS组件)。参照组件划分规则，对所有系统组件进行划分，划分为PSSS组件或者PCS组件。系统组件类型划分遵循以下规则：

(1)若组件直接或间接与外部设备相关(因为也存在组件与外部设备不相关的情况)，则组件为PSSS组件；

(2)若组件用于提供系统级健康监控、集中式配置服务、流媒体服务或者日志服务，则组件为PSSS组件；

(3)若组件用于提供图形相关服务，组件为PSSS组件；

(4)其他独立于外部设备以及在各个平台之间可以直接复用的组件为PCS组件；

3)根据实际应用需求，确定系统中各组件之间交换的数据信息以及数据信息传输方向；

4)确定组件间的传输方式、组件与外部设备驱动之间的传输方式以及组件与操作系统之间的传输方式。图3显示了FACE软件架构及其组件之间的传输接口信息。

组件、操作系统以及外部设备驱动之间的传输方式满足以下原则：

(1)PSSS组件与外部设备驱动之间通过I/O服务接口(IO)传输；

(2)PSSS组件之间通过传输服务接口(TS)传输；

(3)PSSS组件与PCS组件之间通过TS接口传输；

(4)PCS组件之间通过TS接口传输；

(5)PSSS组件与操作系统之间可通过操作系统接口(OS)、FACE语言运行时环境接口(RT)或FACE框架接口(FW)传输。

5)系统功能的组件化建模结果用UML协作图(引入组件的概念，后文又称为FACE组件协作图)表示。图4显示了一个典型的FACE组件协作图。

FACE组件协作图包含组件、数据流向、消息类型、传输方式(TS/IO)以及外部设备共五部分。其中组件用方框表示，数据流向用带箭头的直线表示，消息类型与传输方式用斜线分隔后标注在直线旁，组件类型标注在组件的方框中用括号括起来，外部设备用椭圆表示。

步骤3：概念数据模型建模：面向概念实体、概念联系、可观察量以及概念视图等概念数据模型元素，参考FACE组件协作图中组件间的数据交互信息，建立概念数据模型，建模结果用UML类图表示。

概念数据模型建模方法如下：

1)创建概念实体。分析FACE组件协作图的实际应用场景，确定概念模型实体的个数并创建相应的UML类。一般实体个数为该组件与其他组件或外部设备驱动进行交互的不同消息类型的个数。将每一个实体映射为UML类图中的一个类。

2)创建可观察量。分析实体的可观察信息(例如：高度、方向)，确定概念数据模型的可观察量并创建相应的UML类。将每一个可观察量映射为UML类图中的一个类。

3)确定概念实体与可观察量之间的关系。根据实际应用场景，将可观察量进行组合作为概念实体的属性，完善概念实体；在UML类图中，将可观察量的类作为概念实体的类的成员。

4)确定概念实体之间的关系。参考FACE组件协作图，面向组件的数据流向，根据组件的输出对输入的依赖关系，确定实体间的关联实体并绘制UML类图中各类之间的关联关系，例如，一个输出端口的消息类型B依赖输入端口的消息类型A，那么消息类型B对应的概念实体与消息类型A建立关联关系。在UML类图中为概念实体的类之间建立依赖关系。

步骤4：逻辑数据模型建模：面向逻辑实体、逻辑关联、测量、以及逻辑视图等逻辑数据模型元素，通过引入物理平台相关细节来细化概念数据模型，建模逻辑数据模型，建模结果使用UML类图表示。逻辑数据模型建模方法如下：

1)创建逻辑测量。根据实际应用中传输的数据信息，为概念模型的每一个可观察量创建一个能够表示该可观察值的逻辑测量。根据该逻辑测量的标准组成对每一个逻辑测量进行细化。例如，一个表示空间位置信息的可观察量，用WGS84坐标系来表示；WGS84包含x轴、y轴、z轴，每个轴也需要进行表示。将每一个逻辑测量映射为UML类图中的一个类。UML类图中测量类依赖可观察类。

2)创建逻辑实体。细化概念模型，为概念数据模型中每一个实体创建相应逻辑数据模型实体，实体特征通过引用逻辑测量来表示。将每个逻辑实体映射为UML类图中的一个类。UML类图中逻辑实体类依赖概念实体类。

3)创建逻辑视图。通过创建逻辑视图来定义要由组件接收和发送的消息内容。将每一个逻辑视图映射为UML类图的一个类，逻辑视图的类依赖概念实体的类。

步骤5：平台数据模型建模：面向平台实体、平台关联、平台视图以及与平台相关的物理数据类型等平台数据模型元素，通过引入具体计算平台相关的物理细节，细化逻辑数据模型，建模平台数据模型，建模结果使用UML类图表示。平台数据模型建模方法如下：

1)进行面向接口定义语言IDL的数据类型映射。FACE创建的所有逻辑数据模型中测量的平台(物理)表示，即为逻辑模型中的测量值确定测量系统，为测量系统的每个度量确定具体物理数据类型。平台数据模型支持的物理数据类型直接对应于接口描述语言(IDL)数据类型(例如，布尔型，八位字节，字符型，宽字符型等)。在UML类图中每一个平台表示映射为一个类，该类依赖逻辑数据模型中对应测量表示的类。

2)创建平台实体。细化逻辑模型中的逻辑实体，创建与逻辑实体一一对应的平台实体，实现逻辑模型中的相应实体元素，即将逻辑实体中对应的属性映射为度量表示属性。在UML类图中每一个平台实体映射为一个类，平台实体的类依赖逻辑实体的类。

3)创建平台视图。在特定平台实现逻辑视图，即创建流入和流出组件的消息的平台视图；将平台实体的特征投影到视图中，以定义消息内容。在UML类图中每一个平台视图映射为UML类。平台视图的类依赖逻辑视图的类，并依赖平台实体类。

步骤6：可移植单元模型建模：面向系统组件、逻辑平台视图以及组件的输入输出端口，设计组件的消息类型与消息传输接口，构建可移植单元模型，建模结果使用UML类图表示。可移植单元模型建模方法如下：

1)创建可移植单元。将一个组件构建为一个可移植单元模型，可移植单元模型的类型由组件类型确定。如果组件为特定平台组件，那么构建的可移植单元模型为特定平台可移植数据模型；如果组件为可移植组件，那么构建的可移植单元模型为与平台无关的可移植数据模型。将每一个可移植单元模型映射为UML类图中的一个类。

2)创建消息端口。根据组件的数据输入流与输出流，确定该可移植单元模型的端口数量，为可移植单元创建消息端口并建模每个端口的特征(传输速率、语言、配置文件、端口类型等)。将每一个消息端口映射为UML类图中的一个类，端口特征映射为类中的附加信息；并在类图建立可移植单元的类与端口的类之间的依赖关系，可移植单元的类依赖所有端口的类。

3)设置消息类型。将平台数据模型中的平台视图映射到消息端口，以描述使用该端口所传递的消息。在UML类图中建立端口的类与平台视图的类之间的依赖关系，端口的类依赖该平台视图的类。

至此，为每一个组件相关的数据建模通过概念数据模型、逻辑数据模型、平台数据模型以及可移植单元数据模型进行逐层、逐级细化，完成组件所有端口及其消息类型对应的数据模型的建模，进而为系统的每一个组件涉及到消息数据类型以及端口进行数据建模，从而实现整个系统的数据建模。

步骤7：I/O配置文件建模方法：面向PSSS组件与外部设备驱动的I/O连接，对I/O配置文件进行建模，建模结果用XML格式的文件表示。具体建模过程参考以下步骤：

1)从系统功能的组件化建模阶段得到的FACE组件协作图中，找出所有与外部设备驱动直接进行数据交换的PSSS组件，为每个PSSS组件创建一个I/O配置文件。

2)从FACE组件协作图中，确定一个PSSS组件与外部设备的I/O连接数量，I/O连接的数量就是FACE组件协作图中与该组件进行数据交互的外部设备的有向箭头的个数。从连接名称、连接类型以及端口等I/O连接属性，参照配置文件格式对该PSSS组件的每一个I/O连接进行配置。每个I/O连接需要对以下19项数据进行设置：

(1)ConnectionName：I/O连接的名称。命名最好体现该使用该连接的组件和外设的信息便于理解。

(2)ConnectionType：I/O连接类型，指定用于传输服务连接的基础传输机制。

(3)ConnectionDirection：I/O连接方向，该元素值可以为消息发送端(Source)、消息接收端(Destination)以及双向传输(Bidirectional)。

(4)CreateConnection：是否创建I/O连接，该元素值可以为创建连接(true)以及不创建连接(false)。

(5)PortName：端口名称。当I/O连接的传输类型为采样端口或者队列端口，设置端口名称；否则，端口名称为空。

(6)MessageSize、MessageRange、RefreshPeriod：I/O连接传输消息大小、允许传输的消息数量以及消息保存有效时间。

(7)Reliability：I/O连接的可靠性。若为可靠性传输，则元素值为“Reliable”；若连接为非可靠传输，则元素值为“No-Reliable”。

(8)ReadWriteBehavior：设置读写行为的方式。若连接类型为队列端口或者采样端口，那么元素值可设置为Queuing(表示队列读写)MessageRange设置为连接传输所需缓冲的消息最大数量。若接传输机制选择采样端口，那么元素值设置为Sampling(表示采样读写)。

(9)QueueDiscipline：设置队列方式。元素值可为先进先出(FIFO)、优先队列方式(PRIORITY)。

(10)ConnectionDomain：若连接选择Socket进行传输时，根据Socket支持的协议族以及实际需求，设置元素值。若传输协议选择本地通信，元素值设为AF_UNIX或者AF_LOCAL。若选择IPv4协议，元素值设置为AF_INET。

(11)SocketType若连接选择Socket进行传输时，根据实际需求，设置套接字的类型；否则，元素值为空。

(12)Stream：默认协议是TCP，提供一个顺序确定的，可靠的，双向基于连接的传输并支持带外数据。

(13)DGram：数据报套接字，默认协议是UDP，提供不可靠非连接的传输。

(14)SeqPacket：有序分组套接字，默认协议是SCTP，提供一个顺序确定的，可靠的，双向基于连接的传输，并保留消息边界。(表明发送两个数据包，只能分两次读入)

(15)ReceiveFlag、SendFlag：POSIX套接字的接收和发送标志。

(16)SourceAddress、DestinationAddress、SourcePort、DestinationPort：I/O连接的源IP地址、目的IP地址、源端口以及目的端口。若PSSS组件为消息发送方，源IP地址和端口号为空，设置目的IP地址和端口号。若PSSS组件为消息接收方，目的IP地址和端口号为空，设置源IP地址和端口号

(17)IOType：I/O设备类型。目前常用的I/O类型有串行(SERIAL)、ARINC_429总线协议、MIL_STD_1553总线协议、直接I/O(DISCRETE)、模拟I/O(ANALOG)等方式。

(18)Thread：I/O连接所属的线程对象。

(19)ThreadName、Priority、SchedulingPolicy、ThreadRate、ThreadStackSize：每个线程的名称、优先级、调度策略、线程速率以及堆栈大小。

步骤8：组件间传输服务建模：结合FACE组件协作图，分析系统组件之间的消息传输特性，对传输服务层进行建模，建模结果用传输服务配置文件表示。也就是说，对传输服务层的建模就是对传输服务配置文件的建模。

为全面的描述传输服务信息，FACE标准对传输服务连接需配置的数据信息进行分析总结，确定传输服务配置文件的数据应包含传输连接名称、传输机制、传输方向以及可靠性等数据信息，并提供配置文件格式定义。配置文件数据信息具体参考TechnicalStandard for Future Airborne Capability Environment(FACE^TM),Edition 2.1第264到265。配置文件格式具体参考Reference Implementation Guide for FACE^TMTechnicalStandard,Edition 2.1第325页。

面向系统组件之间的传输服务连接，对传输服务配置文件进行建模，建模结果用XML格式的文件表示。具体建模过参考以下步骤：

1)参考系统功能的组件化建模阶段得到的FACE组件协作图，为每个系统组件创建一个传输服务配置文件。

2)从FACE组件协作图中，确定一个系统组件的传输服务连接数量，传输服务连接的数量就是FACE组件协作图中该组件使用TS进行数据传输的数据流的数量(数据流包括输入流和输出流)。基于连接名称、连接类型以及消息大小等传输服务连接属性，参照配置文件规范对该PSSS组件的每一个传输服务连接进行配置。每个I/O连接需要对以下19项数据进行设置：

(1)Connection Name：连接名称，传输服务通过该参数匹配到特定的请求连接。

(2)Connection Type：连接类型，指定用于传输服务连接的基础传输机制。该参数可扩展，以便根据需求添加新的传输机制。

(3)Connection Direction：连接方向，用于指定连接行为，有助于区分连接类型(例如：发布/订阅类型或客户端/服务器)。

(4)Connection Domain、Socket Type：连接域、套接字，两参数属于TSS内部参数，特定于POSIX套接字传输机制。连接域用于区分UNIX或Internet套接字；套接字类型用于确定协议类型(TCP或UDP)。如果使用其他网络协议(例如，实时传输协议——RTP)，则需调整参数值。

(5)Receive Flag、Send Flag：接收标志、发送标志，仅用于配置POSIX套接字连接。

(6)SourceAddress、DestinationAddress、Source Port、Destination Port：源地址、目的地址、源端口、目的端口，是POSIX套接字特定的配置属性。它们用于确定连接的IP地址和端口号。每个源和目标必须有一个IP地址和端口；一个源可以对应多个目标，多个源可对应到一个目标。这些属性不适用于ARINC连接的源端口和目标端口。

(7)ReadWriteBehavior：读写行为，用于指示连接是否应以与ARINC 653采样端口或排队端口类似的方式进行操作。使用此属性不需要使用ARINC 653传输机制。

(8)MaxMessageSize：最大消息尺寸，用于指定在连接上的发送数据的最大尺寸。该值由系统集成商在配置传输服务连接时确定，具体组成为数据的最大尺寸、TSS标题尺寸。

(9)Message Range：消息范围，用于描述分发能力所需缓冲的消息最大数量。它仅在ReadWriteBehavior被配置排队时使用。

(10)MessagesAssociated：关联信息，实质为全局唯一标识符(GUIDs)列表，用于标识在配置中的传输消息。

(11)QueueDiscipline：队列管制，描述了连接的排队行为。该属性可以设置为先进先出(FIFO)或优先级。排队缓冲区的处理在POSIX和ARINC中是不同的。POSIX是基于优先级的，ARINC是基于FIFO的。对于ARINC这个属性会影响被阻塞的进程。优先级排队考虑到一些数据可能比其他数据更重要的可能性。数据可以根据优先级放入队列中。此属性仅在ReadWriteBehavior配置为排队时有效。

(12)DataTransformRequired：数据循环需求，是一个布尔值，用于指示是否需要转换此连接上的数据，以便正确执行传输服务。

(13)Refresh Period：刷新周期，用于指示消息的有效时间。

(14)Reliability：可靠性，指示数据传输是否必须得到保证或尽力而为。提供本地保证传送的传输机制可以用于尽力而为的要求，无需进一步的配置或开发；如果需要保证交付，则必须使用基础保证交付传输机制。

(15)Filter Specification过滤规范，该参数值是一个可选的配置项目，并且只能用于生产者/发布者TS库上。筛选规范值由结构化查询语言(SQL)字符串定义。如果使用对象管理组(OMG)DDS，则将过滤器内置到传输机制中。如果不使用OMG DDS，并且需要过滤规范功能，那么TSS开发人员需要TS库内部实现一个SQL解析器和过滤器。

(16)Thread List、Priority、Scheduling Policy、Thread Rate、Thread StackSize：线程列表、优先级、调度策略、线程速率、线程堆栈大小，这些属性与TSS可能需要的线程及其相关属性有关。如果连接使用回调向组件提供数据以分离套接字的网络堆栈处理或提供不同的质量服务管理功能时，这些属性可能是必需的。

现结合应用实例对本发明做进一步描述：

一个简单的飞机作战辅助系统，通过外部惯性测量单元(IMU)、嵌入式全球定位设备、嵌入式惯性导航设备以及机载雷达收集飞机飞行数据(高度、速度等信息)，分析外部设备传递过来的信息，可视化显示相关战术，为飞行员在特定的环境中提供战术辅助。

1)功能组件化

对飞机作战辅助系统进行功能需求分析，得到如图5所示的系统功能树形结构图。飞机作战辅助系统包含一个信息收集子系统和一个战术展示子系统。信息收集子系统包含机载雷达通信功能和导航管理功能。战术展示子系统包含战术状态管理功能以及战术显示功能。

根据系统功能组件化建模方法，飞机作战辅助系统的功能组件化过程如下：

(1)将飞机作战辅助系统中的子节点功能映射为四个组件：与雷达进行交互的雷达组件、与导航相关外设交互的导航管理组件、存储战术信息的战术状态管理组件以及战术显示组件。

(2)雷达组件与一个系统外部雷达进行数据交互，一个雷达组件足够完成与雷达的交互，可不用新增组件；导航管理功能从三个外部设备获取数据信息，新增定位组件、导航组件以及惯性测量组件三个系统组件。至此，系统组件共包括七个组件分别是：雷达组件(Radar Component)、导航管理组件(Navigation Management)、战术状态管理组件(Tactical Situation Management)、战术显示组件(Tactical Display)、定位组件(Navigation Sensor1)、导航组件(Navigation Sensor2)、惯性测量组件(NavigationSensor3)。图6展示了飞机作战辅助系统功能、组件的映射关系以及组件与外设的关系。其中Rador表示一个雷达设备，IMU表示一个惯性测量单元设备GI1与EGI2表示全球导航定位系统。

(3)将与外部设备直接进行交互的雷达组件、定位组件、导航组件、惯性测量组件划分为PSSS组件，将依赖于外部设备导航信息的导航管理组件划分为PSSS组件，将提供图形服务的战术显示组件划分为PSSS组件，将存储战术信息的与平台无关的战术状态管理组件划分为PCS组件。

(4)根据用户需求，确定飞机作战辅助系统各组件之间的数据流向；根据飞机作战辅助系统各组件的组件类型，确定组件间的传输方式。最终分析结果用组件协作图表示，如图7所示。

2)操作系统选型以及操作系统分区

选取ARINC653标准的操作系统，将操作系统划分为两个ARINC653标准的分区。一个分区包含系统所有的PSSS组件，提供与平台相关功能；一个分区包含PCS组件，提供可移植功能。由于两个分区间的传输就是PSSS组件与PCS组件之间的传输，因此分区间采用TS服务进行数据传输。图8展示了飞机作战辅助系统的分区情况。

3)数据模型建模

飞机作战辅助系统共包含7个系统组件，需要为系统的每一个组件进行数据建模。以下以导航管理系统的数据建模为例详细介绍数据建模过程。

(1)概念数据模型建模

a)创建概念数据模型实体(Entity)

导航管理组件从多个来源获取位置、状态等信息参数，输出一个综合估计。从该功能场景可得到以下实体：嵌入式全球定位系统/惯性导航系统(EGI)、惯性测量单元(IMU)、导航管理功能(NavManagementFunction)。

b)建模每个实体元素的可观察量(Observable)

面向实体的唯一性，创建UniqueIdentifier的可观察量，用于描述每个实体的id；对于EGI实体，面向飞机的位置信息，创建Position、Orientation两个可观察量，用于描述飞机的位置和方向；对于IMU实体，引用创建的Position可观察量，用于描述飞机位置信息；对于NavManagementFunction实体，引用创建Position、Orientation可观察量，描述导航功能的输出信息。

c)建模结果用UML类图表示，如图9所示。该概念模型类图包含两个Entity类(实体)，一个Association类(关联)以及三个Observable类(可观察量)。

(2)逻辑数据模型建模

UniqueIdentifier只是概念模型中引入用来区分实体的概念，因此不用创建平台逻辑的度量。部分结果如图10所示。图中虚线框部分为概念数据模型类，其他部分为逻辑数据模型类。主要展示了可观察值Orientation和Angle细化为逻辑数据可测量BodyFramAttitudeMeasure和BodyFramAttitudeMeasureAxes，InertialMeasurementUnit概念实体元素实现为InertialMeasurementUnit逻辑实体，以及将InertialMeasure投影到IMU_DATA上定义逻辑消息类型。

(3)平台数据模型建模

参考平台数据建模步骤，进行平台数据建模，部分建模结果如图11所示。图中虚线框中为逻辑数据模型元素，其他为平台数据模型元素，平台数据模型支持的物理数据类型直接对应于接口描述语言(IDL)数据类型，即BodyFramAttitudeMeasureAxis建模为IDLprimitive类型。BodyFrameAttitudeMeasure建模为IDLStruct接口。InertialMeasurementUnit逻辑实体元素进一步被实现为InertialMeasurementUnit平台实体，以及将InertialMeasurementUnit平台实体投影到IMU_DATA上定义的平台消息类型。

(4)可移植单元数据模型建模

参考可移植单元数据模型建模步骤，进行建模，部分建模结果如图12所示。将特定平台组件NavigationManager对应的四个端口EGI1_Data、EGI2_Data、IMU_Data以及NAVData及其相应的消息类型与平台视图进行关联，这样就完成了组件NavigationManager所有端口及其消息类型对应的数据模型的建模。

4)I/O服务层建模

从系统组件协作图中发现与I/O设备直接进行交互的组件有4个，分别是雷达组件、定位组件、导航组件、惯性测量组件。因此，创建4个I/O服务配置文件，每个配置文件配置一个I/O连接。

以定位组件为例，定位组件以队列端口的方式从外部设备EGI1获取数据信息，传输总线类型为MIL_STD_1553，连接命名为Navigation_Sensor1_IO，图13显示了该定位组件完整的I/O连接配置信息。

5)传输服务层建模

1)从系统组件协作图中发现一共有7个系统组件，为每一个系统组件创建一个传输服务配置文件；

2)定位组件(Navigation Sensor1)配置1个连接，导航组件(NavigationSensor2)配置1个连接，惯性测量组件(Navigation Sensor3)配置1个连接，导航管理组件(Navigation Management)配置4个连接，雷达组件配置4个连接，战术状态管理组件(Tactical Situation Management)配置2个连接，战术显示组件(Tactical Display)配置2个连接。

以定位组件为例，定位组件以POSIX Socket向导航管理组件传输数据信息，传输连接名称为Navigation_Sensor1_To_NavM，使用IPv4网络协议。图14显示了完整的定位组件(Navigation Sensor1)传输服务配置信息。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在不脱离本发明的原理和宗旨的情况下在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (7)

1.一种基于FACE架构的软件系统建模方法，其特征在于：包括以下步骤：

步骤1：系统功能分析：

根据系统需求对系统功能进行迭代分析，将一个系统划分为若干子系统，单个子系统划分为若干子系统或功能，一个功能细化为多个子功能，使系统功能细化；将最终的系统功能分析结果用系统功能树表示；

系统功能树包含两种类型的节点：系统节点和功能节点；其中系统节点分为根节点以及子系统节点；根节点能够包含若干个子系统节点；一个子系统节点能够包含子系统节点和功能节点；一个功能节点能够包含若干功能节点；

步骤2：系统功能组件化：

步骤2.1：将系统功能树中所有的功能节点均映射为系统组件，并根据是否直接与外部设备交换数据细化每一个系统组件；细化组件时，新增组件的个数与直接同该组件交换数据的外部设备的个数相关：

(1)当组件不与外部设备直接进行数据交换时，不用新增组件；

(2)当组件与一个外部设备直接进行数据交换时，不用新增组件；

(3)当组件与n个外部设备直接进行数据交换时，新增n(n>1)个组件；

步骤2.2：按照以下组件划分规则，对所有系统组件进行划分，划分为特定平台组件PSSS或者可移植组件PCS：

(1)若组件直接或间接与外部设备相关，则组件为PSSS组件；

(2)若组件用于提供系统级健康监控、集中式配置服务、流媒体服务或者日志服务，则组件为PSSS组件；

(3)若组件用于提供图形相关服务，组件为PSSS组件；

(4)其他独立于外部设备以及在各个平台之间可以直接复用的组件为PCS组件；

步骤2.3：根据实际应用需求，确定系统中各组件之间交换的数据信息以及数据信息传输方向；

步骤2.4：确定组件间的传输方式、组件与外部设备驱动之间的传输方式以及组件与操作系统之间的传输方式：

组件、操作系统以及外部设备驱动之间的传输方式满足以下规则：

(1)PSSS组件与外部设备驱动之间通过I/O服务接口IO传输；

(2)PSSS组件之间通过传输服务接口TS传输；

(3)PSSS组件与PCS组件之间通过TS接口传输；

(4)PCS组件之间通过TS接口传输；

(5)PSSS组件与操作系统之间通过操作系统接口OS、FACE语言运行时环境接口RT或FACE框架接口FW传输。

步骤2.5：将系统功能的组件化建模结果用UML协作图表示；

步骤3：概念数据模型建模：面向概念数据模型元素，参考FACE组件协作图中组件间的数据交互信息，建立概念数据模型，建模结果用UML类图表示：概念数据模型元素包括概念实体、概念联系、可观察量以及概念视图；

步骤4：逻辑数据模型建模：面向逻辑数据模型元素，通过引入物理平台细节来细化概念数据模型，建模逻辑数据模型，建模结果使用UML类图表示；逻辑数据模型元素包括逻辑实体、逻辑关联、测量、以及逻辑视图；

步骤5：平台数据模型建模：面向平台数据模型元素，通过引入具体计算平台相关的物理细节，细化逻辑数据模型，建模平台数据模型，建模结果使用UML类图表示；平台数据模型元素包括平台实体、平台关联、平台视图以及与平台相关物理数据类型；

步骤6：可移植单元模型建模：面向系统组件、逻辑平台视图以及组件的输入输出端口，设计组件的消息类型与消息传输接口，构建可移植单元模型，建模结果使用UML类图表示；

步骤7：I/O配置文件建模：面向PSSS组件与外部设备驱动的I/O连接，对I/O配置文件进行建模，建模结果用XML格式的文件表示；

步骤8：组件间传输服务建模：结合FACE组件协作图，分析系统组件之间的消息传输特性，对传输服务层进行建模，建模结果用传输服务配置文件表示。

2.根据权利要求1所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤3中概念数据模型建模的具体过程为：

步骤3.1：创建概念实体：

分析步骤2得到的FACE组件协作图的实际应用场景，确定概念模型实体的个数并创建相应的UML类；将每一个实体映射为UML类图中的一个类；

步骤3.2：创建可观察量：

分析实体的可观察信息，确定概念数据模型的可观察量并创建相应的UML类；将每一个可观察量映射为UML类图中的一个类；

步骤3.3：确定概念实体与可观察量之间的关系：

根据实际应用场景，将可观察量进行组合作为概念实体的属性，以完善概念实体；在UML类图中，将可观察量的类作为概念实体的类的成员；

步骤3.4：确定概念实体之间的关系：

参考FACE组件协作图，面向组件的数据流向，根据组件的输出对输入的依赖关系，确定实体间的关联实体并绘制UML类图中各类之间的关联关系，并在UML类图中为概念实体的类之间建立依赖关系。

3.根据权利要求1所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤4中逻辑数据模型建模的具体过程为：

步骤4.1：创建逻辑测量：根据实际应用中传输的数据信息，为概念模型的每一个可观察量创建一个能够表示该可观察值的逻辑测量；根据该逻辑测量的标准组成对每一个逻辑测量进行细化；将每一个逻辑测量映射为UML类图中的一个类；UML类图中测量类依赖可观察类；

步骤4.2：创建逻辑实体：细化概念模型，为概念数据模型中每一个实体创建相应逻辑数据模型实体，实体特征通过引用逻辑测量来表示；将每个逻辑实体映射为UML类图中的一个类；UML类图中逻辑实体类依赖概念实体类；

步骤4.3：创建逻辑视图：通过创建逻辑视图定义要由组件接收和发送的消息内容：将每一个逻辑视图映射为UML类图的一个类，逻辑视图的类依赖概念实体的类。

4.根据权利要求1所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤5中平台数据模型建模的具体过程为：

步骤5.1：进行面向接口定义语言IDL的数据类型映射：根据FACE创建的所有逻辑数据模型中的测量值确定测量系统，为测量系统的每个度量确定具体物理数据类型；平台数据模型支持的物理数据类型直接对应于接口描述语言IDL数据类型；在UML类图中每一个平台表示映射为一个类，该类依赖逻辑数据模型中对应测量表示的类；

步骤5.2：创建平台实体：细化逻辑模型中的逻辑实体，创建与逻辑实体一一对应的平台实体，实现逻辑模型中的相应实体元素；在UML类图中每一个平台实体映射为一个类，平台实体的类依赖逻辑实体的类；

步骤5.3：创建平台视图：创建流入和流出组件的消息的平台视图；将平台实体的特征投影到视图中；在UML类图中每一个平台视图映射为UML类；平台视图的类依赖逻辑视图的类，并依赖平台实体类。

5.根据权利要求1所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤6中可移植单元模型建模的具体过程为：

步骤6.1：创建可移植单元：将一个组件构建为一个可移植单元模型，可移植单元模型的类型由组件类型确定：如果组件为特定平台组件，则构建的可移植单元模型为特定平台可移植数据模型；如果组件为可移植组件，则构建的可移植单元模型为与平台无关的可移植数据模型；将每一个可移植单元模型映射为UML类图中的一个类；

步骤6.2：创建消息端口：根据组件的数据输入流与输出流，确定该可移植单元模型的端口数量，为可移植单元创建消息端口并建模每个端口的特征；将每一个消息端口映射为UML类图中的一个类，端口特征映射为类中的附加信息；并在类图建立可移植单元的类与端口的类之间的依赖关系，可移植单元的类依赖所有端口的类；

步骤6.3：设置消息类型：将平台数据模型中的平台视图映射到消息端口，以描述使用该端口所传递的消息；在UML类图中建立端口的类与平台视图的类之间的依赖关系，端口的类依赖该平台视图的类。

6.根据权利要求1所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤7中I/O配置文件建模的具体过程为：

步骤7.1：从系统功能的组件化建模阶段得到的FACE组件协作图中，找出所有与外部设备驱动直接进行数据交换的PSSS组件，为每个PSSS组件创建一个I/O配置文件；

步骤7.2：从FACE组件协作图中，确定一个PSSS组件与外部设备的I/O连接数量，I/O连接的数量为FACE组件协作图中与该组件进行数据交互的外部设备的有向箭头个数；并参照配置文件格式对该PSSS组件的每一个I/O连接进行配置。

7.根据权利要求1所述一种基于FACE架构的软件系统建模方法，其特征在于：步骤8中组件间传输服务建模的具体过程为：

步骤8.1：参考系统功能的组件化建模阶段得到的FACE组件协作图，为每个系统组件创建一个传输服务配置文件；

步骤8.2：从FACE组件协作图中，根据组件使用TS进行数据传输的数据流的数量确定组件的传输服务连接数量，并参照配置文件格式对该PSSS组件的每一个传输服务连接进行配置。