扩展SysML支持需求追踪模型的自动生成*

邓刘梦，沈国华,2+，黄志球,2，王 飞，葛晓瑜

1.南京航空航天大学 计算机科学与技术学院，南京 211106

2.软件新技术与产业化协同创新中心，南京 210016

1 引言

在嵌入式系统开发生命周期中，开发者经常会一次又一次地改变需求，而如何去捕获这些改变对系统的影响往往是一项复杂的任务。此外，对于长生命周期的软件，随着时间的推移，为了引入新硬件或为了纠正现有的缺陷，对其进行维护是必不可少的。对于安全关键系统而言，引入这些改变是尤为慎重的。例如，美国航空航天局等组织已经设立了变更委员会，要求对变更进行安全分析，并在委员会实施之前予以批准[1]。因为在这样的情况下，软件变更可能会在部署变更之前触发生命周期任务的重复，包括需求分析、设计、代码和测试的重复。能力成熟度集成模型（capability maturity model integration，CMMI）[2]明确地指出在开发过程中维护需求的可追踪性及制品之间的可追踪性是保障系统安全的重要前提[3]。ANSI/IEEE标准830—1984中首次提出了可追踪性的概念，其早期主要被用于在功能上提高系统的可重用性。需求可追踪性旨在管理需求链接和模型，可被定义为：“通过相关规范以及定义，朝着需求的起源或实现这两个方向，能够描述和追踪需求的整个生命周期”[4-5]。

在安全关键系统中，很多重大的失效都是由于系统需求在设计过程中没有被精确和完整地追踪而引起的，因此在开发过程中通常会使用特定开发标准对项目进行要求[6]，例如 DO-178B/C[7]、ISO 26262-6[8]、ECSS-E-40[9]等标准适用于航空航天、汽车医疗领域。这些标准详细规定了系统开发生命周期中需要实现的目标以保证软件的安全性，而可追踪性则是其中一个重要的目标。例如：DO-178B就指出“对于某些关键程度的系统，应提供源码到低级需求间的追踪关系以及对于低级需求完全实现的验证”。尽管缺乏追踪关系的系统不一定会产生安全性事故，但健全的追踪信息可以有效地关联不同开发阶段间的制品，并可以此很好地检验需求在其他阶段中的满足情况。这可以有效地降低因设计人员对需求的误解、遗漏以及更改而产生的安全性事故。因此，如何建立需求整个生命周期的可追踪性对于提升软件以及系统的安全性显得至关重要。

本文基于模型驱动工程（model-driven engineering，MDE）来解决安全关键系统中需求可追踪性这一问题，主要致力于安全关键系统开发过程中需求可追踪性的早期建立（即事先追踪）。采用模型驱动的方法进行系统开发，使得在开发早期即将追踪信息包含到模型中，避免了事后的恢复，提高追踪信息的准确性。模型驱动工程主要使用不同抽象层次的模型进行系统设计和开发，可以使用元建模（meta-modeling）构建适用于不同场景的模型。本文选取了系统建模语言（systems modeling language，SysML）作为建模语言对系统进行建模，SysML是一种图形化建模语言，它为软件体系结构建模提供了一套丰富的图表，支持各种复杂系统的详细说明、分析、设计和验证，弥补了统一建模语言（unified modeling language，UML）在系统工程领域建模的缺陷，已经成为工业界在系统工程设计与分析过程中的标准建模语言。目前SysML已经被NASA、欧洲航天局等机构广泛应用到实际的项目开发中。但是，其对于可追踪性的支持仍有局限，例如无法从需求追溯到它们的起源（包括利益相关者等）。此外，缺少针对SysML的特定追踪模型，用于对追踪信息的表述，使得潜在的追踪信息无法为工程师应用于实际的安全性分析中（如：需求变更的影响分析等）[10]。

本文的主要内容及贡献如下：

（1）对SysML模型进行了扩展，给出了扩展配置文件（profile），用于在安全关键系统开发中追踪信息的捕获。

（2）给出了一个用于表达追踪信息的元模型（meta-model），并利用模型转换（model transformation）自动化生成追踪模型。该追踪模型提供了描述需求与设计制品间追踪信息的能力。

本文的结构如下：第2章介绍MDE以及SysML，并在此基础上给出用于追踪信息捕获的SysML扩展模型；第3章给出用于追踪信息展示的追踪元模型以及用于自动化生成追踪模型的ATL（ATLAS transformation language）规则；第4章给出案例分析；第5章介绍相关工作并与本文方法进行比较；第6章总结全文并展望未来工作。

2 追踪信息捕获

本章主要对SysML进行介绍并由此引出用于追踪信息捕获的配置文件。

在模型驱动的软件工程中，可追踪性被认为是非常重要的。其中，模型转换、代码自动生成等技术理论上可以隐式地自动建立和维护软件设计和代码之间的追踪关系，但这种追踪关系一般是单向的，即顺着目标模型生成的方向。此外，需求的可追踪性涉及到需求工程，它主要用于确保开发模型，代码实现以及测试计划都满足项目的原始需求。在模型驱动工程中主要有以下两种方法对可追踪性的管理：

（1）通过自动化模型转换过程创建可追踪性链接；

（2）通过事件捕获来管理可追踪性链接。

2.1 SysML简介及方法概述

本文选取了SysML作为建模语言对系统进行建模，SysML是一种图形化建模语言，是对象管理组织（object management group，OMG）在对UML2.0的子集进行重用和扩展的基础上，提出的一种新建模语言。它致力于建模具有众多组件、难以描述、理解、预测、管理、设计以及更改的系统，并提供了表达个人需求及其组成的手段，已被学术界和工业界所广为接受，作为一种标准建模语言。

在安全关键系统中，系统的安全往往不仅限于纯粹软件的安全，软件设计存在缺陷会导致事故的发生，此外对于某些系统硬件的控制不当，同样也可能造成安全事故。故而，在系统开发中，开发者需要对安全相关（safety-related）的组件（包括软硬件部分）进行严格的安全性分析、验证。有效地保证需求到这些组件的可追踪性，将为后续的安全性分析提供巨大的帮助。

下面给出本文方法概述，如图1所示，主要分为两个阶段：第一阶段为对追踪信息的捕获。首先对SysML进行扩展，得到一个用于追踪建模的配置文件，使开发者建模过程中即可将追踪信息捕获到模型中。第二阶段为追踪信息的表达。通过第一阶段捕获到的追踪信息包含在SysML模型中，此时需要构建一个可以用于描述追踪信息的追踪元模型。接着通过模型转换将SysML模型转换到追踪模型。利用追踪模型以及图形化表达为开发者提供直观的追踪信息展示，使开发者可以利用这些信息对系统进行后续的安全性分析。

Fig.1 Automatic generation of trace model图1 追踪模型自动生成

2.2 SysML配置文件构造

SysML提供了多种建模图供开发者使用。本文中主要使用需求图（requirement diagram）和块定义图（block definition diagram）分别对需求和设计制品进行建模。SysML提供对于需求追踪的机制，其中<>类型提供了一个广泛意义上的追踪关系链接；<>、<>等提供了描述需求间相互关系的能力；<>、<>则用于描述需求与其他制品间的关系。但总体上，SysML提供的可追踪性能力非常有限，首先其不支持双向的追踪（只可从需求向下一阶段的制品进行追踪），其次缺乏面向特定目的以及领域的追踪能力，无法很好地满足安全关键领域中安全性分析的工作。为了有效捕获面向安全关键领域的可追踪性信息，首先需从元模型层面进行设计分析。

需求的追踪本质上是对需求间以及需求与其他设计制品间的关系进行刻画。那么首先要做的就是进行追踪信息的捕获（例如：需求的类型、需求的提出者、利益相关者等），这将决定可追踪性的粒度。在本文中利用SysML的扩展机制，对SysML进行扩展，使扩展后的模型可用于追踪信息的捕获。

关于SysML的扩展机制，官方主要提供了如下3个途径：

（1）基于UML构造型（stereotypes）；

（2）基于UML图表扩展（diagram extensions）；

（3）基于模型库（model libraries）。

SysML构造型机制通过用新的属性和约束来扩展现有的UML2构造型，从而定义新的建模元素；SysML图表扩展通过定义新的图表符号，用于补充从UML2中重用的图表符号；SysML模型库则用于描述可供重用的专用模型元素。上述这些方法最终都需通过配置文件实现[11]。

本文构建配置文件的方法如图2所示：首先对需要扩展的领域元素进行收集，本文中即为追踪信息（如：利益相关者、测试用例等）。接着对这些元素进行形式化，映射到SysML的元模型。进而利用EMF（eclipse modeling framework）工具将得到的元模型构建成SysML的配置文件，其表现形式为SysML图。配置文件中构造的模型元素可以通过标记定义（构造型的属性）和约束进行精化。其中约束可以使用对象约束语言（object constraint language）表示。

Fig.2 Phases of building SysML profile图2 SysML配置文件构建过程

当配置文件定义完成后，将其导入到建模的工具中，此时进行SysML模型开发即可选用扩展的配置文件。而建模得到的SysML模型将符合定义的配置文件要求，同时也将追踪信息捕获在模型中。针对安全关键系统的特性以及本团队的需要，下面给出本文中用于需求追踪的配置文件结构图。如图3所示，所有的构造型都是基于元类中类（class）的扩展。元类是UML配置文件中提供的一个类，可以通过一个或者多个构造型进行不同方向的扩展。而构造型则是用于创建配置文件的主要手段，它们通过扩展元类进行定义，然后作为模型元素应用于用户定制的模型中。

Fig.3 Profile for trace information capture图3 用于追踪信息捕获的配置文件

下面给出扩展的SysML模型的形式化描述：定义标记“├”代表扩展关系，ST为SysML中构造型的集合，MT为SysML中元类集合，则有ST├MT，即构造型可以通过扩展元类得到。定义标记“→”代表继承关系，如果a→b，b∈ST，那么a∈ST，即新构造型也可以通过继承原有的构造型生成。本文配置文件使用的构造型和元类集合分别为st、mt，故st⊂ST，mt⊂MT，并且有st={TestCase，Owner，Block，Requirement，Safety-relatedReq，ConstraintBlock}，mt⊂MT，mt={Class}。

原SysML中Requirement构造型只有id和text两个字段，分别对应每一需求的标识符和文本描述。针对安全关键系统加入Safety-relatedReq构造型用于表示对系统安全性相关的需求。该构造型是对SysML中Requirement构造型进行继承，并在此基础上添加Reqlevel属性，用于描述需求所对应的构件级别。

构造型Block和ConstraintBlock为SysML中原有的构造型，它是系统描述的单元。每个Block定义一组特征用于描述系统或开发者关切的其他元素。其中可能包括结构以及行为特征，例如属性和操作，用于表示系统可能出现的状态和行为。而ConstraintBlock提供了一种集成的机制，用于结合其他模型元素对系统的性能和可靠性进行分析（例如：数学表达式的约束）。

加入TestCase构造型，用于关联验证需求的测试用例，可指向状态图等。

加入Owner构造型（可能是个人或公司）用于关联需求的所有者或者其利益相关者。

3 追踪模型生成

在第2章中，完成了对SysML模型的扩展，使其可以捕获特定追踪信息。在本章中，将构建一个追踪元模型，用于追踪信息的表达。

3.1 追踪元模型构建

传统的可追踪信息模型（traceability information model，TIM）抽象定义了项目中追踪链的类型（trace link type）和被追踪软件制品类型（artifact type）等，为实际项目中追踪链的建立提供指导。而在安全关键系统开发过程中进行安全性分析时往往需要提供更为详细的信息，因此要求追踪模型可以为开发者提供如下的追踪信息：

（1）可以描述需求与设计制品之间的双向追踪关系以及需求与其他元素间的追踪关系；

（2）可以描述对不同类型的追踪元素。

下面首先给出追踪元模型的形式化描述[5]：M=(K,A)，即追踪模型由追踪链集合K和对应的追踪元素集合A构成。使用符号“→”描述追踪链，则追踪链K可表示为A→KA，即追踪链代表一组从源制品到目标制品的关系。定义函数fs：K→A映射每个追踪链对应的源制品；函数ft：K→A映射每个追踪链对Verify应的目标制品。例如：Requirement→TestCase，因此fs(Verify)=Requirement并且ft(Verify)=TestCase。

接着给出追踪元模型的图形化表示，如图4所示。其中，根元素为TraceModel，它可能包含多个TraceLink元素（追踪链）。TraceLink包含一个Tracetype（追踪类型）的属性（其值可能为Satisfy，Responsible Of或Verify，取决于关联的不同类型的制品）。TraceLink关联了TraceElement元素，对应一个源元素以及一个目标元素。TraceElement元素为对应包含追踪信息的元素：Requirement、Block、TestCase以及Stakeholder。

Fig.4 Trace meta-model图4 追踪元模型

3.2 模型转换

本节主要通过模型转换技术完成从SysML模型到追踪模型的转换，实现追踪模型的自动生成用于展示建模阶段捕获到的追踪信息。

模型转换是模型驱动架构中使用的关键技术，本文采用ATL和EMF工具实现模型转换。ATL是ATLAS研究组开发出的一种符合OMG查询/视图/转换（query/view/transformation，QVT）提案的模型转换语言。ATL是基于Eclipse模型框架的语言，其元模型、模型均用EMF文件描述，并使用了对象约束描述语言（object constraint language，OCL）定义规则。本质上，ATL属于基于规则的模型转换语言。

上面给出本文中使用的SysML模型到追踪模型的ATL转化规则，用于实现自动化生成追踪模型。代码功能如下：首先定义一个helper，用于判断制品的构造型值，其功能类似于函数，可在不同的模块中被调用。规则Safety-relatedReq2Req用于实现SysML模型中构造型Safety-relatedReq到追踪模型中Requirement的转换；规则Block2Artifact用于实现SysML模型中Block构造型到追踪模型中Block的转换，此时若有与其关联的需求，则将追踪链的类型设置为Satisfy；规则 Owner2Stakeholder和 Test2TestCase与规则Block2Artifact分别用于实现SysML模型中Owner和TestCase构造型追踪模型元素的转换，以及追踪链类型的设置。

4 案例分析

襟缝翼控制系统是飞控系统中控制襟翼和缝翼行为的重要组件，在起飞和降落过程中增加升力，提高失速临角。该单元直接影响着飞行的安全及稳定，保障其安全性至关重要[12]。本团队在前期工作中已通过模型检测技术实现了襟缝翼控制系统源代码层面的验证[13]，本文将关注该系统开发的可追踪性研究。

本文选取了如下所示的襟缝翼控制单元的部分需求[14]作为案例进行追踪关系的构建与验证：

R0：系统周期自检中，对硬件设备输出的有效性进行检测。

R1：系统的周期自检中，需要对风扇转速、处理器温度输出的有效性进行检测。

R2：系统应提供对处理器温度输出有效性的检测功能。

R3：系统应该提供对风扇转速输出有效性的检测功能。

Fig.5 Requirement diagram of slat control system图5 襟缝翼控制系统需求图

以上需求均为安全相关的需求，根据需求之间的关系可以得到：其中需求R1是对需求R0的精化；需求R2和需求R3则是对需求R1的分解。

使用扩展后的SysML对其进行建模，得到需求图如图5所示。

接着进行系统设计的建模，块CPU是对处理器的建模，它与需求R2存在着满足关系；而测试用例StateMachine1则是对需求R3的测试用例进行建模，它与需求R3存在验证关系。

图6为CPU模块的块定义图。它由一个传感器块和数据处理块组成，分别负责温度的探测和数据的交换。

Fig.6 Block definition diagram of CPU unit图6 CPU单元的块定义图

为了生成追踪模型，将建模得到的扩展模型以及追踪元模型同时导入EMF工具中并加入ATL代码，利用EMF工具对ATL代码进行编译执行，即可自动生成追踪模型。得到的实例文件如下所示。

第一个追踪链类型为Satisfy，对应的追踪元素为需求R2和设计制品CPU块定义图，代表该CPU块图用于实现需求R2；R3与StateMachine1的追踪链生成，其追踪类型为Verify，代表StateMachine1与需求R3存在着验证关系；R0和StaffA之间生成追踪链，类型为ResponsibleOf，代表StaffA是需求R0的利益相关者。

利用绘图软件对XML文件进行处理，得到如图7所示的图形化追踪模型，为追踪信息提供直观的展示。从生成的追踪模型文档以及图形化的模型可以观察到，通过配置文件扩展的SysML模型在建模时成功地捕获追踪信息，使用EMF工具实现模型转换后自动生成的追踪模型符合追踪元模型，具有表达追踪信息的能力。

Fig.7 Graphical representation of trace model图7 追踪模型的图形化表示

5 相关工作

本文的相关工作主要包括SysML的相关扩展以及需求追踪关系的建立方法。

5.1 SysML的扩展

SysML是在UML基础上扩展的，它本质上是一个UML的配置文件扩展。SysML扩展的主要目的为：通过扩展使建模语言获得原始模型不具备的分析能力和信息存储、表达能力。

目前基于SysML扩展的需求可追踪性领域中已有许多相关工作。文献[15]中Soares等人致力于强化需求表达中的可追踪性概念。作者在文中提供了SysML需求图和SysML需求表的扩展。提出了用户需求和追踪的分类，增强了需求和追踪一致性的检查。该工作仅扩展需求图和需求表，没有追踪类型以及元素的扩展，而本文中通过扩展SysML新构造型，提供了增加新追踪元素的能力。Paige等人在文献[16]中提出了一种通过可追踪性抽取来识别模型驱动过程中追踪链的方法，并提供了一种定义和实现此类追踪链的方法。

此外，基于SysML扩展进行系统建模和安全性分析的研究也是一个热点。Hause和Thom给出了一个在安全关键系统设计中使用UML和SysML的指南[17]。他们提供了用于建模安全完整性等级（safety integrity level，SIL）的构造型，确保系统构件关系满足相关的安全性需求。文献[18]提供了一个名为“SafeML”的SySML的配置文件，用于对安全关键系统中的安全相关信息进行建模。利用该配置文件对系统进行建模，可以模拟以及管理系统的风险。文献[18]提出了SecureUML配置文件，用于传达软件系统安全问题。它用于模拟基于角色的访问控制，以记录系统中用户和实体的访问权限。构造型可以对这些资源执行的角色、资源、动作进行建模，以及授权约束（使用逻辑谓词建模）。周书华等人在文献[19]中对SysML进行扩展来支持兼容Modelica的设计建模，最后实现了SysML与Modelica模型的自动转换，使得设计人员得以将设计模型自动转化为系统仿真模型进行仿真。曹德建等人[20]提出了一种将故障树分析扩展到SysML活动图模型的方法以及故障扩展SysML活动图的概念，统一了系统功能模型与安全需求分析模型。黄传林等人[21]提出一种结合MARTE语义信息的扩展SysML活动图模型，用于描述安全关键应用中的嵌入式系统动态行为的设计，设计了一个基于AMMA平台的面向扩展SysML活动图的模型转换与验证框架。

与本文工作相比，该类方法利用SysML的扩展能力致力于系统的建模与安全性分析，例如故障、风险分析等。其关注点在于系统建模和模型验证，追踪信息可能会被集成包含进系统模型，但缺少针对安全关键系统的特定追踪信息捕获以及专门用于表达追踪信息的模型。而本文重点则在于建模过程中追踪信息的捕获，以及专门用于表达追踪信息的模型生成。

总结如下，现有的SysML扩展工作可主要分为两类：一类旨在扩展模型语义或者结合形式化方法，进行系统安全性分析；另一类则不侧重于形式化方法的使用，而旨在信息的存储以及表达。本文聚焦于建模过程中的追踪信息捕获以及追踪信息的表达，本质上即通过扩展使SysML模型具备存储特定追踪信息的能力，可为后续安全性分析提供数据支持。本文配置文件的主要扩展内容如表1所示。

Table1 Main extension elements in profile表1 配置文件中主要的扩展元素

5.2 需求追踪关系的建立

关于需求追踪关系的建立方法，从事先和事后角度进行分类，主要有基于信息检索的事后恢复和基于模型驱动的事先建立方法。

基于信息检索的可追踪性恢复，主要利用IR模型计算需求文本与其他文本制品的相似度，然后通过设定阀值进行筛选，重新建立不同制品间的追踪链。

目前已有很多的模型采用IR的技术恢复追链接。文献[22]表明，该类型的可追踪链恢复过程与手动方法相比，明显更快，追踪链的准确性也得到了一定的提升。但是，最终开发者仍然需要做出关于候选链接有效性的最终决定。文献[23]利用自然语言文本的语法特性，分析需求文档和用例的语法结构，标注句子成分，根据制定的规则进行关系匹配。

在模型驱动的软件工程中，模型转换、代码自动生成等技术可以隐式地自动建立和维护软件设计模型、软件设计和代码之间的追踪关系。

目前有一些方法尝试将需求转换为UML或XML的形式化表达，然后实现一定程度的追踪链生成自动化。文献[24]提出一种称为REQDL（requirement description language）的领域特定语言用于描述需求，同时捕获双向的追踪信息并利用模型转换自动生成追踪模型。该文献侧重于构建新的需求描述语言，用于需求建模。文献[25]提出了一种半自动方法，用于维护需求和UML制品之间的追踪链，该方法基于捕获建模工具中的事件流。但该方法只可用于处理基于事件的UML制品，而本文的方法可以处理SysML中原有的所有结构以及行为制品，并具备将这些制品绑定到利益相关者的能力。

本文采用模型驱动的方法。不同于信息检索方法的追踪链的事后恢复，本文致力于追踪关系的事先建立。在基于信息检索的方法中常见问题为追踪链的错误恢复，即两个制品间本不存在追踪关系，经过信息检索方法处理后却建立了追踪链，该追踪链即为一个错误恢复的链接。安全关键系统要求高安全高可靠，而利用信息检索方法恢复的追踪链存在以上错误恢复的情况，因此信息检索方法不能很好地适用于该类系统的追踪关系建立。本文方法正向建立追踪关系，即首先进行需求分解和追踪关系的指派，再进行制品的设计，理论上将不会存在错误建立的追踪链（需排除人为指派错误的影响）。此外，在完成建模后可支持进一步采用模型检测（model checking）、形式化方法（formal method）等技术进行模型的验证以及分析，可以帮助开发者在开发早期发现问题，保障系统的安全性。

6 结束语

在航空航天等安全关键领域，嵌入式系统的需求追踪信息缺失将导致后期维护的困难加大，更可能直接导致由于需求未被满足而引发重大安全性事故。本文针对这一问题展开研究，给出了一种基于模型驱动工程的方法，用于安全关键系统中需求追踪的事先建立。通过对SysML配置文件的扩展、追踪元模型的构建以及模型转换技术的使用实现了追踪模型的自动化生成。该追踪模型提供了需求与设计制品间的追踪能力以及从需求向前追踪的能力。

未来的工作将着重于需求到代码的可追踪性研究以及追踪信息粒度的细化。