基于Sirius的SysML活动图建模和仿真设计与实现

2022-10-19周晨初陆明珠彭祺擘叶晓平刘玉生

丽水学院学报 2022年5期

王强，周晨初，陆明珠，彭祺擘，叶晓平，刘玉生

（1.上海卫星工程研究所，上海 201109；2.西安航天动力研究所，陕西西安 710100；3.浙江大学CAD&CG国家重点实验室，浙江杭州 310058；4.中国航天员科研训练中心，北京，100094；5.丽水学院工学院，浙江丽水 323000）

随着当今社会科学技术的飞速发展，复杂系统设计和验证的难度日益增大，传统基于文档的系统工程已远远无法满足需要，基于模型的系统工程（Model-Based System Engineering,MBSE）应运而生，已经受到学术界和工业界的广泛关注[1-3]，正成为复杂装备系统设计与方案论证的不二之选[4-10]。SysML是MBSE建模实践的标准语言[11]，而活动图是用来表达系统动态行为信息的3种核心SysML图之一，用来表达随着时间推移行为和事件的发生顺序。目前国外的相关软件工具有Cameo System Modeler[12]、Visual Paradigm for UML[13]、Sparx Systems Enterprise Architect[14]；国内的有内蒙古大学的SysModeler[15]和浙江大学的M-Design[16-18]。近年来，Web化SysML工具得到了广泛的重视，国外的GenMyModel团队开发了一款Web版的在线UML建模平台。ProcessOn[19]虽然是国内团队开发的专业作图和协作平台，但是ProcessOn只支持UML部分图的绘图功能，不支持SysML和UML建模功能。浙江大学MBSE团队对桌面版软件和Web技术进行充分调研之后，设计和实现了Web版的M-Design[12，20-21]。

笔者针对基于MBSE的图形化系统工程建模软件领域存在的开发工作量大、周期长、对SysML标准的支持和功能完整性不足等问题，采取了模型驱动开发（Model-Driven Development，MDD）的模式，提出了基于模型驱动架构Sirius的SysML活动图建模与仿真功能实现方法。

1 活动图建模功能的设计与实现

1.1 活动图建模功能总体架构

通过分析活动图建模软件的核心问题、Sirius框架提供的环境和工具，结合用户的需求，本文设计并实现了基于Sirius的活动图建模软件，总体框架如图1所示。

图1 活动图建模软件总体架构

在模型层面，在充分理解活动图语法语义的基础上使用Eclipse Ecore Tool定义M2层活动图的抽象语法，用于创建M1层活动图模型。在视图层面，通过配置Styling元素规定图形元素的外观，用户以Eclipse UI作为操作界面与模型层和视图层交互。具体来说，用户通过由属性视图说明（Properties View Description）定义的属性视图（Properties View）反映模型的属性，并对属性直接进行修改。用户通过Tools元素定义的一系列的动作实现对图形元素的创建、删除、修改等操作。作为建模软件的根基，模型和视图通过Mapping元素实现二者的映射关系。

1.2 定义元模型

OMG定义的模型驱动架构（Model-Driven Architecture,MDA），是一种实现内聚模型驱动技术规范的重要方法和规划。其中，UML、MOF和OMG其他相关规范通过模型创建与转换在MDA中具有重要的作用。

根据MOF四层架构理论，本文将活动图建模功能在M3、M2、M1三层进行抽象。如图2所示：最上层M3层是由Eclipse Modeling Project提供的元模型层——Ecore层，定义了基本的建模语言用来描述类（classes）、属性（attributes）、数据类型（data types）和关系（relations）；M3层下面的M2层定义了SysML活动图抽象语法用于创建M1层活动图模型。之所以本文没有抽象出M0层，是因为活动图建模软件没有实例层，系统模型的实例层通常指一个实际系统。

图2 活动图建模软件抽象结构

活动图的抽象语法是使用UML活动图元模型定义的，该元模型使用了MOF规范中可识别、受约束、用于构建元模型的UML子集中的构造方法[4]。其好处在于能确保UML模型能够保存在MOF资源库中，在MOF资源库中用户可以使用MOF特征对其进行操纵，并使用遵循MOF XMI映射规范的XML文件来进行交换。从而实现MOF和UML之间的融合，促进MDA内部规范的一体化。

准确定义活动图的抽象语法主要解决了3个问题：（1）建模的正确性；（2）与外界打通，与XML格式进行交换；（3）准确定义的元模型方便仿真操作语义的扩展。由于整个建模平台都是对底层元模型进行可视化，因此需要导入或者自定义元模型，通常可以使用Eclipse提供的Ecore Tools进行自定义元模型。

如图3所示，活动图的元模型可以分为5个部分：活动、控制节点、对象节点、可执行节点、活动组。元模型作为整个建模软件的根基，整个建模软件需要始终保障用户对模型的操作符合UML/SysML语法和语义约束，即提供模型正确性检查。

图3 活动图抽象语法

1.3 基于Sirius框架的活动图建模编辑器构建

1.3.1 SysML活动图具体元素创建

基于Sirius进行SysML活动图具体创建的优势在于：利用它提供的Viewpoint Specification Model（VSM），软件开发人员可以正确地描述图形编辑器的结构、样式和行为。为了将语义模型与模型的具体表现形式建立联系，需要编辑VSM元素中的Mapping。Mapping是指用来标识哪些语义模型元素应该在表示中呈现和应该以何种表现形式呈现映射关系。不同的表示提供了不同类型的映射。虽然映射存在于VSM里面，但在具体的表示中将生成新的实例。基于元模型，Sirius提出将以下4种表现形式进行可视化：

1）Node：不包含子对象的元素。

2）Border Node：在形态上可以附着在其他Container上用来表示某种关系。

3）Container：包含子对象的元素。

4）Relation：可视化两个对象之间的关系的元素。

为了规定节点是如何在图上展示的，需要声明一个样式（Style），如图4所示。而对于7种控制节点，样式也截然不同，为了达到根据模型元素判定样式的目的，基于Sirius提供的Conditional Style组件和AQL语句来实现以模型元素为条件进行样式判定，如图5所示。

图4 样式选择界面

图5 Conditional Style组件

1.3.2 动态行为的定义

对于图形元素，一般均要进行增删改操作。笔者拟基于Sirius框架提供的工具（Tools）来实现。笔者以创建ControlNode中的InitialNode为例来说明如何运用一个创建新节点的工具。InitialNode创建工具的树级层次的总览，如图6所示。

图6 InitialNode创建工具总览

首先通过对InitialNode的语义进行分析，根据UML2规范，InitialNode可以创建在Activity、StructuredActivityNode、ActivityPartition里面，对于不同的外层元素，需要采取不同的操作，从而使元素的创建符合语义；其次使用Sirius框架提供的If操作，它会在当前上下文中计算条件表达式，当结果为“真”的时候，才会执行包含的子操作。例如当外层元素的模型元素是uml.ActivityPartition的时候，将调用findParentActivity方法，递归寻找父级元素（图7）并将上下文改为父级元素，继续创建uml.InitialNode模型元素。

图7 findParentActivity()代码实现

这里如何保持语义一致性是一个关键问题。为此，将顶层元素的ownedNode属性设置为当前InitialNode，再通过Create Instance操作在用户模型中添加一个新的模型元素而完成，其操作配置细节如图8所示。

图8 Create Instanc操作的配置细节

2 SysML活动图仿真功能的设计与实现

SysML模型仿真整体上可以分为3个范畴：模型执行、模型调试和模型测试。模型执行是其中的核心和基础步骤。为了调试和测试模型，首先要使得模型变得可以执行，也就是为模型定义操作语义。

2.1 基于运行概念的活动图仿真操作语义设计

1.3.1 节所述，定义SysML活动图模型的目的并不是为了被执行，所以缺乏完整的、精确的操作语义。操作语义包含2个部分：（1）运行时概念（runtime concepts）：捕获执行模型的状态；（2）计算步骤（steps of computation）：活动图元素遵循的演绎规则，即可执行模型是如何从一个状态向另一个状态转换的。本节通过对元模型的抽象语法进行删减和必要的扩展来定义正在执行模型的状态——运行时概念，并对其计算步骤进行设计。

图9展现了活动图的运行时概念。运行时概念用灰色表示，普通元类用白色表示。笔者将运行时概念分为以下4类：（1）活动节点之间的令牌流（token flow）；（2）变量的当前值；（3）活动图的运行轨迹；（4）活动图的输入值。

图9 运行时概念的抽象语法

当所有被需要的控制令牌都能够通过输入控制流得到，则活动节点被执行。当活动节点执行完成之后，控制令牌通过输出控制流传递给接下来的节点。运行时概念令牌（Token）和其子类ControlToken、ForkedToken定义了在执行过程中令牌如何被表示。因此，ForkedToken来源于ForkNode的执行，将一个控制流分为多个并行流。令牌通常情况下归属于活动节点（作为ActivityNode的heldTokens引用），通过活动边传递给后续节点（作为ActivityEdge的offers引用）。令牌传递的表示是由运行时概念Offer来定义。

活动的Variables由初始值进行初始化（作为Variable的InitialValue引用），如果变量的值发生改变则被设置为变量的当前值（Variable的currentValue引用）。变量的当前值会在活动执行过程中随着OpaqueAction的执行而更新。为了能够捕捉活动图运行轨迹信息，定义运行时概念“Trace”用来维护执行过的活动节点的有序列表（作为executedNodes引用）。

对于活动的输入变量（Activity的inputs引用），定义运行时概念Input和InputValue来表示活动的执行需要处理的输入值。

定义运行时概念是对活动图元模型的扩展，例如新增属性、引用扩展元模型中的元类或者在元模型中新增元类。在接下来的计算步骤设计中，将直接把运行时概念引入到活动图元模型中。

2.2 计算步骤设计

活动图的计算步骤设计流程如图10所示，定义如下：

图10 活动图计算步骤设计的流程图

1）变量初始化：活动接收输入值（元类InputValue）根据输入值初始化当前值（Variable的currentValue引用），局部变量的当前值也根据输入值进行初始化（Variable的initialValue引用）。

2）将活动节点设为运行状态（Running），该活动节点包含的所有节点都被设为运行状态（Running）（ActivityNode的running属性）。

3）执行初始节点：活动的初始节点被设置为执行状态（Executed）。执行初始节点包含以下几个步骤：

a.创建一个控制令牌。

b.将该控制令牌传递给初始节点（ActivityNode的heldTokes引用）。

c.通过输出控制流将该控制令牌传递给后续节点（ActivityEdge的offers引用）。每一个活动有且只有一个初始节点。

4）判定后续的激活节点：当某个活动节点被设置为运行状态且所有输入控制流都提供令牌时，该节点被激活。如果是MergeNode，仅仅需要其中一个输入控制流提供令牌，就可以被激活。

5）选择和执行激活节点：需要从所有激活节点中选择一个执行，执行一个激活节点可以分为以下3步：

a.消费令牌。所有通过输入控制流提供的令牌都被消费掉，对于输入控制流来说，ActivityEdge的offers引用被置空。在消费控制令牌时，控制令牌从前序节点移除掉（ActivityNode的heldToken引用）。在消费ForkedToken时，ForkedToken的剩余提供令牌数减去1（remaining OfferCount），只有当剩余提供令牌数等于零的时候（ForkedToken的每一个后续节点都处理完ForkedToken），ForkedToken才被移除掉。

b.执行节点的行为。消费令牌之后，根据节点的类型，不同的节点行为将被执行。在某些情况下，可能会产生新的控制令牌，添加给当前节点（ActivityNode的heldTokes属性），并通过节点的输出控制流传递给后续节点。

c.记录运行轨迹。执行完的节点会被添加到活动维护的Trace引用中。

不同活动节点的行为语义定义如下：

a.OpequeActions：OpequeAction中定义的表达式将按照顺序执行。表达式的语义包括将定义的运算符运用到操作变量上，并将结果赋给当前值变量。在执行完所有的表达式之后，针对每一个输出控制流都创建一个控制令牌，并传递给后续节点。

b.ForkNode：ForkNode针对每一个输入令牌都会创建一个ForkedToken，ForkedToken的baseToken引用指向该输入令牌；创建的ForkedToken都由输出控制流传递给后续节点。

c.DecisionNode：DecisionNode会判断输出控制流的守卫条件是否满足，而输入令牌会提供给守护条件满足的边。需要注意的是：只有一个守护条件能够被满足。

d.JoinNode和MergeNode：JoinNode和MergeNode会把输入令牌提供给所有的输出控制流。

e.ActivityFinalNode：ActivityFinalNode会终止包含它的活动的执行，活动中所有节点都被设置为终止。

6）重复第四步和第五步直到终止，也就是没有活动节点处于激发状态。

3 实例分析

研究目标主要包括SysML活动图建模与仿真操作的语义设计与实现。在建模方面，支持用户通过该软件，以图形的形式与系统进行交互，最终完成活动图的建模工作。本节将通过多个案例对提出的方法进行验证。

首先以一个支付活动为样例来验证活动图建模平台的基础功能和建模功能，该支付活动涵盖了活动图建模所需要的所有基本元素和功能。图11是一个活动图，它描述了用户注册银行账户并完成支付的活动。图中将该活动分为两个子活动：用户注册活动和支付相关活动。账号分为两种：内部账号和外部（普通）账号。内部账户的支付流程更加复杂，需要经理进行审批和提交。图中使用了活动分区/泳道将两个子活动分配到不同的结构：用户和银行。不同动作之间使用Pin、Pout作为输入输出，Pin接收控制流（ControlFlow），Pout输出控制流。该支付活动定义了两个变量：类型为Boolean的输入变量internal和局部变量external。局部变量external初始化值为false。另外，活动包括：1个初始节点、1个决定节点、1个分支节点、1个集合节点、1个合并节点、1个活动终止节点、2个活动分区及由15个控制流边连接的8个不透明动作。同时不透明动作register定义了一个表达式，external!=internal，决定节点的输出边定义了两个变量作为守护条件。为验证上述支付系统活动图的正确性，笔者设计了单元测试，具体包括两部分：针对外部账户和内部账户执行路径。部分单元测试代码如图12所示。

图11 支付系统活动图

图12 部分单元测试代码

最后进行运行，其测试结果如图13所示。由图13可知，仿真过程显示其设计正确。

图13 支付系统活动图仿真测试结果

为了更充分地验证本活动图建模软件对不同元素的支持，用图14所示的活动图进一步验证。这是《SysML精粹》第六章执行Hohmann转换的活动。Hohmann转换是将飞船从较低轨道送往较高轨道通常使用的方法。当卫星在两个相同轨道面且轨道半径比例相差不大的圆形轨道间时，Hohmann转换是最省燃料的轨道转换方式。

图14 Hohmann转换活动图

利用本活动图建模软件对流式遥测活动进行建模，技术活动图如图15所示。该活动的关键在于合并节点。在该活动中，触发Create Virtual Channel Frame活动的3个调用行为动作会并发执行，它们彼此独立输出类型为Virtual Channel Frame的对象令牌，这些令牌将先后到达合并节点，每个令牌到达之后会立刻提供给输出边，并作为紧接动作的输出。此动作将继续输出类型为Transfer Frame的单个令牌流。