基于SysML模型的需求建模及测试方法

黄 晨，于 倩，左万娟，陈华南，王小丽

(1. 北京控制工程研究所，北京 100190； 2. 北京轩宇信息技术有限公司，北京 100190)

航天领域星船系统受限于资源的局限性，大多数系统为嵌入式系统，嵌入式系统具有强实时性等特点，对系统时序的要求和限制非常严格，部分设计受限于系统硬件资源，需要软硬件协同高效配合来保证系统的正确性，系统的任务执行时间、 功能的计算时间、 响应时间等都是通过时间约束来保证[1]，因此时间性能指标的测试是系统测试非常重要的一项测试内容. 在测试时，应考虑和测试各种场景的系统运行情况，如系统负载最大，多任务并发访问，执行路径深度最大等等. 传统的嵌入式系统测试都是采用非形式化的需求规格说明，由人工进行分析后形成非形式化的自然语言描述的需求，这种方式成本较低，但是容易产生歧义，不容易发现需求遗漏，很多问题通常是在设计、 测试的后期才能发现. 基于模型的测试方法通过测试左移，能够更早地发现系统设计、 需求分析中存在的问题，以及不完整性、 模糊性和不一致性[2]. 使用建模语言进行需求建模，能够将抽象数学模型转化为易于理解和可以描述的通用性语言，如UML统一建模语言[3]，Perit网[4]等. 系统大部分功能都可以采用建模的方式进行描述，再通过形式化的方法验证模型的正确性[5,6]，并根据模型自动生成测试用例[7]. 基于UML的状态机图、 活动图、 时序图等各种图形化的建模语言已经在系统需求分析中得到广泛应用，文献[8]采用SysML状态图表示系统的行为模型，通过体系结果和业务需求对行为模型进行验证. 为实现基于模型的测试有效投入工程应用，需要建立能够覆盖嵌入式系统各项测试类型的需求模型，本文用建模的方式描述系统的运行场景和需求，针对与时间相关性能指标的模型给出分析方法，说明应如何分析和建模，基于多种覆盖准则可由模型自动生成性能测试的用例集，以满足性能测试要求.

1 建模语言及表示方法

1.1 SysML建模语言

目前，从建模语言的表示形式大致可以分为3种类型： 非形式化、 半形式化、 形式化. 非形式化方法是指采用自然语言描述的方法，这种方法描述系统需求相对比较简单，但是如果描述不清楚，会存在二义性，并且容易遗漏需求； 半形式化方法是一种受限制的描述方法，采用自然语言加特定的符号进行描述，可以是一种带有受限制句子结构和具有特殊意义的关键字的自然语言或图表. 这种方法相对于自然语言更加形式化； 形式化方法是一种基于数学的形式化描述语言，优点是能够提高描述的正确性，减少二义性和不一致性，增强可读性，缺点是表示极为复杂. 系统建模语言SysML(Systems Modeling Language)是目前国际上系统工程领域最新的标准建模语言，是统一建模语言UML在系统工程领域的延伸和扩展，是一种半形式化的图形建模语言，使用自然语言描述约束和详细语义，是对象管理组织OMG在对UML2.5的子集进行重用和扩展的基础上，针对系统工程领域中系统设计与建模的特点，提供了可视化、 图形化的系统建模支持语言，广泛应用于复杂系统建模，涵盖了从系统需求到设计阶段的各项要求，广泛运用于航空航天软件开发过程[9]. 基于MOF定义的4层元模型结构，SysML建模语言位于元模型层，在元模型层定义的抽象语法的基础上，定义了模型描述语言的模型，提供了表达系统的各种包、 模型元素的定义类型、 标记值和约束等，它与特定的应用领域有关. 元模型为SysML的所有元素在语法和语义上提供了简单、 一致、 通用的定义性说明，使开发在语义上取得一致，在一定程度上消除了人为表达方式所造成的影响[10]. 通过ISO-AP233数据交换标准和XMI模型交换标准，语法上支持各种系统工程工具之间的互操作[11]. SysML为系统提供定了4种类型模型和9种图的完整语义. 4种类型是： 结构模型、 行为模型、 需求模型和参数模型； 9种图是： 模块定义图、 内部模块图、 包图、 活动图、 序列图、 用例图、 状态机图、 参数图和需求图. 结构模型强调系统的层次以及对象之间的相互连接关系，包括类和装配. 行为模型强调系统中对象的行为，包括它们的活动、 交互和状态历史. 需求模型强调需求之间的追溯关系以及设计对需求的满足关系. 参数模型强调系统或部件的属性之间的约束关系.

1.2 状态机图

状态机图主要描述一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转移. 可以清晰描述对象之间是如何交互和通信的，尤其是通信发送消息的时间关系非常清晰. 状态机图有一个或多个状态，零个或多个转移组成. 状态和转移描述了一个对象在其生命周期里的行为. 状态是对象生命周期中的一个条件或状况，在此期间对象满足某些条件，执行某些活动或等待某些事件. 状态机图是Harel的经典状态图的变体，状态机图的处理原则是，在下一个时间处理之前，必须保证上一个事件已经被处理完毕； 当发生转移冲突时遵循底层优先的策略，转移所在层次越低，执行优先级越高[12].

1.2.1 抽象语法

本文所指的状态机为行为状态机，通过类图的方式表示状态机类元之间的关系，用来描述状态机图的抽象语法. 状态机类元包括： 状态机、 区域、 节点、 转移、 触发、 约束、 参考连接点、 伪状态、 状态、 行为等，这些类元之间存在的关系包括： 关联、 继承、 复合等.

图1 状态机类元抽象语法

1.2.2 图元符号及含义[12]

对状态机图的基本图元语义进行解释说明.

1) 状态(State)

是指在对象的生命期中的一个条件或状况，在此期间对象将满足某些条件、 执行某些动作或等待某些事件.

每个状态可以没有或者由多个活动组成，这些活动都是非原子活动，在执行过程中可被中断，可以表示为

〈behavior-type〉[′ /′〈behavior-expression〉],

(1)

其中，behavior-type行为类型是行为发生的场景，有3种：

entry： 进入当前状态时执行的动作；

do： 在当前状态下，一个持续进行的动作或行为，或者特定表达式；

exit： 退出当前状态时执行的动作.

状态可以分为3类： 简单状态、 复合状态和子机状态.

简单状态(simple State)是指其中没有嵌套状态的状态，可以分为3个分区： 命名分区、 内部行为分区和内部转移分区.

复合状态(composite State)： 至少包括一个区域，可以是只有一个区域的简单复合状态，可以是具有多个区域的正交状态.

子机状态(submachine State)： 指的是整个状态机，认为它是在状态中嵌套的.

2) 伪状态(PseudoState)

伪状态是指包含多种类型暂态节点的抽象概念. 伪状态主要用于连接多个转移组成更加复杂的复合转移. 伪状态包含多种类型，有初始状态、 终止状态、 浅历史状态、 深历史状态、 分叉、 合并、 选择、 连接、 进入点、 退出点、 终止[13].

3) 转移(Transition)

状态机模型中的转移元素属于非常重要的元素之一. 是两个状态之间的一种关系，它指明对象在第一个状态中执行一定的动作，并当特定事件发生或特定的条件满足时进入第二个状态，转移描述了一个或者多个状态之间是如何发生转换的. 转移也存在优先级，转移可以没有或者有多个事件，一个事件对应一个触发，触发能够导致状态的转移. 连接源状态和目标状态之间的弧线就是转移，可以表示为如下形式

{〈trigger〉}*[′ [′〈guard〉′]′]

[/〈behavior-expression〉] ,

(2)

其中，trigger是触发事件，表示在时间和空间上占有一定位置的有意义的事件. 转移可以没有触发事件或者有多个事件. 分为4类： 信号事件(信号用于对象间异步传递的信息包，它没有任何操作，只有自身携带的信息，通过信号来触发，有接收信号事件和发送信号事件)、 调用事件(请求在类语境的实例上调用特定的操作)、 时间事件(相对时间关键字after说明事件被触发的临界时间，绝对时间关键字at)和改变事件(关键字when说明事件改变所满足的条件). 多个触发事件时间采用‘,’进行连接.

guard表示守护条件，是一个布尔表达式，如果表达式值为真，则转换可以发生； 如果表达式为假，则转换不能发生. 每一个转移可以没有或者有多个守卫条件.

behavior-expression表示由匹配触发的事件和守卫条件满足后发生的事件所造成的特定影响，是一个行为表达式，可以不写.

转移有3种类型： 外部转移，局部转移和内部转移.

外部转移： 指转移从其源顶点退出，如果顶点为状态时，转移的发生会导致执行相关状态的退出动作.

局部转移： 与外部转移相反，转移不会从包含它的状态中退出，转移发生时包含局部转移的状态的退出动作不会执行，但是，局部转移的源顶点和目标顶点不能相同，只能应用于复合状态.

内部转移： 是局部转移的一种特殊情况，也叫作自转移，具有相同的源顶点和目标顶点. 当这种转移执行时，不会执行入口和出口动作. 内部转移只能用于状态顶点.

1.2.3 形式化语义

在此采用形式化方法定义状态机语法，状态机多元组表示为[14]

STD=(S,B,ε,V,P,N,X,D,subStates,T),

(3)

其中，S表示状态的集合，包括伪状态；B表示行为描述的集合；ε表示事件的集合；V={V1,…VNv}表示Nv(Nv∈Ν)变量的集合；P：S→Pr将每个状态关联上属性Pr={简单非终止状态，复合状态，终止状态，初始状态，历史状态}；N∶S→((B∪{ø})×List(F))将每个状态关联入口行为；F表示对应变量V的指定函数列表；X∶S→((B∪{ø})×List(F)关联退出行为的状态；D∶S→((B∪{ø})×List(F))关联do行为的状态；subStates：S→2s关联每个状态直接子状态的集合；T表示状态转移t的集合，t=(S1,e,g,(b,f),sLevel,S2).S1,S2⊆S，分别表示源状态和目标状态，约束限制条件为：S1和S2仅包含一个状态(两个状态之间的转移)，或者超过1个状态(合并和分叉转移)； 如果S1或者S2包含超过一个状态，复合状态不同区域的直接子状态必须要有一个直接子状态，复合状态不能有比状态还要多的区域个数；e∈ε∪{noEvent}，noEvent表示没有触发事件的转移；g是守卫条件，表示V中变量的布尔表达式； (b,f)∈((B∪{ø})×List(F))表示触发转移后会执行的行为动作；sLevel∈S为包含转移的状态优先级，属于S1∪S2的任意状态，都属于sLevel的子状态.

2 需求建模及用例生成

在工程应用中，性能测试是嵌入式系统测试过程中必测的、 非常重要的一个测试类型，各项性能指标的确定与系统设计要求紧密结合，功能中如果涉及到时间相关指标要求的，应作为性能指标进行测试，并分析系统的设计是否满足时间设计要求. 嵌入式系统软件任务正常执行过程中被外部中断事件打断的场景、 看门狗喂狗最长时间间隔的测试、 某系统初始化时间最大值的测试、 以及隐含性能需求等，都应作为性能指标进行测试.

2.1 测试要求

嵌入式系统的性能指标一般包括以下几方面测试要求：

1) 时间间隔： 是指系统在进行两个处理操作之间需要保证的时间间隔. 嵌入式系统一般存在设计下限或者上限的指标要求.

2) 处理时间： 系统进行某个处理或者某一系列操作的时间要求. 嵌入式系统受限于软件严格的时序设计，如果处理时间超过限制，会导致后续处理不及时，丢失外部指令等情况发生. 对于并发访问时也需要通过严格的时序设计保证系统运行的正确性，因此也存在类似的指标要求，例如中断函数处理时间的要求.

3) 响应时间： 是指从接收到某个事件，到做出反应的时间. 要求能及时反应外部事件的请求,在规定时间内完成对该事件的处理，并控制所有实时设备和实时任务，协调一致地运行.

2.2 测试方法

目前，嵌入式软件时间性能指标的测试通常是采用代码插桩和人工分析相结合的方式，系统运行受限于当前运行工况和场景，代码执行的路径无法完全确定和预知，很多时候需要统计软件在最深的执行路径或最大强度负载情况下的运行情况，或者统计所有工况下的某段时间性能实测值，取多次测试的最大值、 最小值或者平均值作为实际测试结果.

采用图形化的建模语言、 描述方式能够非常清晰，明确的表示需求的物理意义和处理逻辑. 在测试系统性能时，分析方法如下：

1) 时间间隔测试： 状态机模型中的时间类型事件需要作为时间性能指标进行测试,所建立的需求模型中存在after(x)的时间类型转移事件，均应作为性能指标测试，如果出现when，at等事件类型的关键字时，也需要注意是否需要作为性能指标进行测试.

2) 处理时间测试： 可以统计测量连续两次发生同一个状态的时间间隔或者处理时间.

3) 响应时间测试： 构造极限和极大强度负载运行场景，测试软件响应某个事件的响应延迟时间.

2.3 用例生成

根据建立的性能需求状态机模型，提取其中生成测试用例所需的信息，生成测试用例. 首先生成抽象测试操作序，再将抽象路径与时间或者状态、 操作关键字、 数据等进行关联，生成实际的测试用例. 根据转移上的事件作为测试输入，状态中执行的动作作为预期输出，建立从需求到用例设计的对应关系.

生成的抽象测试序的完备性决定了测试用例覆盖的充分性，基于状态机图生成的操作序需要保证状态覆盖、 转换覆盖和路径全覆盖.

将状态机图中的状态用数字进行编号，转移用小写英文字母编号，选取一条典型路径，可以表示为1(a)2(b)3(d)4(e)1.

图2 抽象序列执行路径示意图Fig.2 Abstract sequence execution path diagram

建立的模型如果是多层、 并发等更为复杂的情况下，通过人工方式筛选可达路径也容易存在遗漏造成测试不充分，可通过静态的数据筛选方式，生成所有可执行路径，以保证各项测试的完备性和充分性.

3 建模实例分析

根据嵌入式系统的性能指标要求，采用建模的方式对性能需求进行描述.

3.1 时间间隔测试

需求描述： 某接口芯片采集模拟量为12 b AD芯片，芯片量程为0 V～10 V，数据转换最大时间为35 μs. 片选地址为XXH，AD转换启动地址为XXH，写0表示启动AD转换. 数据采集地址为XXH(8位有效，为采集12位数据的高8位)和(XX+1)H(高4位有效，为采集12位数据的低4位).

每路采集处理的过程如下：

A． 选通片选，向模拟选通地址XXH写入片选信号；

B． 通过地址XXH或P口设置通道号；

C． 向地址XXH写入0，启动AD转换器；

D． 等待一段时间35 μs转换完成后，先从地址XXH读取高8位结果、 读取地址(XX+1)H内容高4位作为采集数据的低4位，拼接成12位有效数据作为采集结果.

E． 对AD采集数据进行补偿处理，连续采集多次后进行滤波.

分析： 上述需求中要求从启动AD转换到转换完成需要等待一段时间，约35 μs，软件再读取采集数据，保证AD芯片从接收到启动信号到转换完成有充足的时间.

性能指标要求： 从启动AD转换到开始采集AD数据之间的等待时间需要大于35 μs. 建立需求模型如图3 所示.

图3 时间间隔需求模型Fig.3 Time interval requirement model

测试场景： 测试软件正常采集数据下，软件两个操作(向地址XXH写入0，读取地址XXH，(XX+1)H数据)之间的时间间隔最小值是否大于35 μs.

3.2 处理时间测试

受限于系统严格的时序控制，某段功能或者代码的执行时间需要满足一定的设计要求才能保证执行逻辑的正确性.

需求描述： 周期性触发某外部中断周期为100 ms，中断服务子程序中设置遥测数据组织标志为真，看主程序中周期性进行判断数据组织标志是否为真，是则进行遥测数据组织并发送，否则不组织发送.

分析： 软件按照一定的时间间隔周期性执行主程序，如果主程序执行处理时间超过中断的触发周期，主程序还未及时处理中断设置的遥测数据组织标志就接收到新的遥测数据组织标志，会导致少进行一次遥测数据组织发送.

性能指标要求： 主程序执行时间应小于100 ms. 选取主程序执行过程中的某个状态，建立需求模型如图4 所示.

图4 处理时间需求模型Fig.4 Processing time demand model

主程序执行一次有可能会经历不同的场景和状态，图4 的性能指标需要测试的是主程序的最大执行路径，可以选择状态变化最多，或者选择最为耗时的一个迁移状态机作为当前性能测试的模型，也可以将主程序所有功能的状态机图，统计所有用例中相邻两个周期进入同一个状态的时间间隔作为主程序的处理时间.

测试场景： 制造主程序执行过程中计算算法耗时最长，状态转移最多的场景，测试主程序连续两次进入同一个状态，执行同一个操作的最大时间是否小于100 ms.

3.3 响应时间测试

在测试时间最大值时，很难保证测试的场景是一条最大路径，采用建模的方式能够更容易分析所加负载最多的一条路径是怎么触发的，从而测试最长响应时间的测试场景.

需求描述： 软件接收到某条指令并及时处理该条指令.

分析： 软件通过中断接收指令，将指令放入队列缓存区，或者按照优先级排序，按照队列的指令顺序依次执行或者按照队列中的指令优先级排序，优先执行高优先级指令.

性能指标要求： 软件从接收指令到响应执行该指令需要保证在50 ms以内，否则，50 ms后接收到新的指令后，如果指令队列长度有限，会回卷覆盖之前的指令，导致旧的指令未执行就被新的指令覆盖. 建立需求模型如图5 所示.

图5 响应时间需求模型Fig.5 Response time demand model

从图5 模型中可分析得到： 在接收到新指令时，如果之前的指令队列长度最长时，会导致当前新指令响应时间最长.

测试场景： 制造指令队列长度最大值的场景，并在该场景下发送指令x，测试从接收到指令x到执行指令x之间的响应时间最大值是否小于50 ms.

4 结束语

明确SysML状态机抽象语法，图元符号和含义，对嵌入式系统典型性能需求进行测试，说明需求建模和用例生成方法，总结基于状态机模型的3种性能指标测试方法，通过实例化方法建立模型，描述性能需求场景. 从工程化的角度将状态机模型应用到实时嵌入式软件测试过程中，覆盖性能测试类型，未来还将继续研究从状态机模型中自动提取各种测试类型的方法，保证测试覆盖性，实现模型驱动测试在航天领域的全面工程化应用，提升测试自动化程度.