0 引言

机载软件由于其复杂的使用环境、不断改进的需求和技术要求以及法规的变化等等，使其软件更改在系统维护期间持续发生。民用飞机机载软件适航标准RTCA DO-178C对软件提出了更改控制要求^[1]，其中更改影响分析（change impact analysis，简称CIA）环节要求能够确定软件更改影响到的所有软件生命周期数据，并据此对软件的不同数据进行针对性修改，以避免更改不完整带来的软件缺陷。军用飞机及其他安全相关行业也对软件的更改影响分析有较高的要求，但在实践过程中，由于更改影响分析不完善带来的软件问题依然难以避免。

针对该问题，RTCA DO-178C给出了一种基于追踪关系的软件更改影响分析方法，该方法利用软件生命周期数据之间的追踪关系可以确定与当前软件更改内容相关的所有纵向生命周期资料，但对软件单元（如函数、模块或组件）之间的相互影响却并未覆盖。

对于机载系统而言，除了关注软件更改本身所涉及的生命周期数据的同步更改，更关键的是找出与被更改软件单元相关联的其他软件单元或其它相关系统的软件配置项。针对这种软件单元或软件配置项之间的更改影响分析，目前常见方法如下：

1）基于模型的影响分析方法^[2-4]。该方法使用基于模型的方法对软件需求和软件设计单元之间的关联关系进行建模，更适用于前期采用模型进行需求捕获或软件设计的情况。

2）基于语法依赖的影响分析方法^[5-7]。该方法以面向对象语言的语法特点为出发点，基于封装、继承等特性分析类、对象之间的依赖关系，适用于使用面向对象语言的情况。

3）基于动态执行行为的影响分析方法^[8]。该方法以程序执行过程中的运行行为为分析对象，使用插桩方式获取所需的执行关系，从而判断与更改软件单元有动态调用关系的受影响单元。

本文以机载软件为对象，将DO-178C中要求的追踪关系与软件单元之间的耦合关系相结合，最终划定软件更改的影响域，提高了软件影响分析的彻底性。

1 基于耦合关系分析的更改影响评估算法

1.1 基本概念定义

有向图使用节点和有向边构成模型来记录复杂系统变量之间的影响关系，在图像处理^[9]、故障搜索^[10]方面均有较多的应用。本文使用有向图作为耦合关系的载体，使用到的相关概念定义如下：

1）将进行更改影响分析之前，为解决软件生命周期过程中发现的软件缺陷或错误而计划更改的目标软件单元的集合定义为软件原始更改集，使用字母Minit表示。

2）将更改影响分析之后，确定的所有需更改的软件单元的集合定义为软件更改集，使用字母M表示，则Minit∈M。

3）定义更改有向图Gm=（M，R），用于表示软件更改集M中所有软件更改单元及其之间的耦合依赖关系。在图中，任意节点Mi表示一个需更改的软件单元，任意边Ri表示有向关系〈Mi，Mj〉，表示软件单元Mi由于使用了Mj提供的服务或使用了Mj修改后的数据而受到影响。推论可得：

设受影响集合Maffect = M-Minit，则:

$\forall \mathrm{M}\mathrm{i}\in \text{Maffect，}\exists \mathrm{M}\mathrm{j}\in \text{Minit}$，使得〈Mi，Mj〉∈R

定义4：定义基本有向图G=（V，E），用于表示软件更改之前，根据软件架构建立的所有软件单元集合V和软件单元之间的耦合依赖关系集合E。则由定义可知M∈V，R∈E，更改有向图Gm为基本有向图G的子图。

更改影响评估是以软件原始更改集为输入，从基本有向图中搜索确认更改有向图，并最终获取软件更改集的过程。

1.2 建立基本有向图

软件的耦合关系指的是软件不同单元之间的依赖关系^[11]，主要体现在以下几个方面：

1）软件单元之间的调用关系；

2）软件单元间的参数传递；

3）多于一个组件使用的全局变量；

4）软件执行过程被中断服务程序中断而产生的依赖关系^[12]，主要对实时性要求较高的软件单元可能产生影响。

在为耦合关系建立基本有向图之前，可以通过以下几个活动大幅降低软件单元之间的耦合程度，降低更改影响评估的复杂度。

1）标准约束：在标准文件中增加设计约束，可以大幅降低软件的耦合程度，由此提高软件更改影响分析的确定程度。可以考虑的因素包括但不限于：

a）限制全局变量的使用。如图1所示，软件单元与全局变量之间的读写关系一般包括一写一读、多写一读、一写多读、多写多读^[13]等。不用或者少用全局变量，能够减少不同软件单元读写同一全局变量带来的对软件代码执行结果的间接影响；如果确实需要使用全局变量，应至少将读写关系限制在一写一读、一写多读以内，禁止多写操作，同时在软件设计文档的数据字典说明中对全局变量的名称、用途和不同函数的使用关系进行详细描述，保证后续分析工作的正确执行。

b）限制同一变量在多处赋值的情况。同一变量被多个函数赋值，对不同函数间的执行顺序有较高的要求，一旦读写顺序发生变化，变量的赋值结果会发生不可预估的变化，属于执行次序的强耦合关系，应限制使用，降低更改影响评估的复杂度。

c）限制直接跳转语句的使用。直接跳转语句可能会打破原有函数间的执行次序，对执行次序的强耦合关系造成破坏（如上一条的赋值次序问题），从而使软件的执行过程出错或产生潜在漏洞。

d）限制中断嵌套。多优先级的软件中断嵌套在软件实际执行过程中会发生不确定的运行时嵌套，在软件运行前很难穷尽分析所有可能的嵌套关系，因此一旦中断服务程序的内容受到更改的影响，则该影响可能会被级联扩大，使软件的更改影响分析不能丧失预见性，导致潜在缺陷的产生。

2）软件架构设计：在软件架构设计时，明确组件间的接口、调用关系、调度策略、中断处理逻辑等。必要时采用控制流图、数据流图、时序图等图表方式表达；详尽的软件架构设计数据可以作为基本有向图建立的基础。

作为更改影响评估的基础，软件基本有向图的建立是不可缺少的，本文按照以下步骤建立基本有向图：

1）确定软件单元粒度。对于机载软件（不考虑面向对象语言）来说，软件单元根据实际情况可以按照软件配置项、软件部件或软件函数的粒度进行划分。由于基于耦合关系的更改影响分析更多地注重软件单元外部的影响，因此对软件单元内部的更改后回归测试需使用所有相关测试用例进行重新测试。一般建议以函数为软件单元进行基本有向图的分析建立。

2）确定软件单元集合V。根据软件设计文档或软件源代码，确定软件中涉及的所有软件单元（如软件函数）的集合。

3）确定软件单元之间的调用耦合关系。根据软件的控制流图或源代码，确定软件单元之间的每一个调用关系Ei，并根据调用与被调用关系确定有向图Ei的方向。

4）确定软件单元之间的数据耦合关系。根据软件数据字典或源代码，确认软件单元外部的所有数据列表，并遍历该数据列表，确认软件单元之间的读写影响关系Ej，并使读取该数据的软件单元指向所有写入该数据的软件单元。

5）设计数据结构存储有向图关系数据，数据结构形式如下：

Struct Edge {

  String SourceNode；

  String DestNode；

}

则Edge Ei={Vi，Vj}表示一条由Vi指向Vj的边。以结构数组的形式可以存储整个有向图中多个边的信息。

以以下代码段为例，根据以上方法建立有向图，如图2所示。

由该基本有向图产生的数据库存储数据如表1所示。

1.3 计算生成更改有向图和更改集

对于基本有向图G，在已知原始更改集Minit的情况下可知：

$\forall$Mj∈Minit，若$\exists$＜Ei，Mj＞∈E，则

Ei∈Maffect

由节点EiMj和有向边〈EiMj〉构成的子图是更改有向图Gm的一部分。

因此根据更改需求确定Minit后，对Minit进行遍历，$\forall$Mj∈Minit使用逆向搜索算法找到有向边对应的所有受影响节点集合Maffect，并与原始更改集合并形成最终的软件更改集M。算法以伪代码描述如下：

list M = Minit

for each Mi in M

list Edgelist=getData (“DestNode=Mi”)

 if Edgelist.count () 〈〉 0

  for each edge in Edgelist

   if (!M.exist (edge.SourceNode) )

   M.add (edge.SourceNode)

  End each

 End if

End each

算法输出节点集合M为软件更改集。

根据以上算法，假设图2中main函数需要更改，则经过影响分析后软件更改集M为（main，v2，v1），算法演进过程如图3所示，图中●表示软件更改集M中的节点，未加入该集合之前显示为○。图3（c）中黑色填充的节点和节点间的边构成了最终的更改有向图Gm。

图3（a）项中，将M初始化为假定需要更改的函数main，根据条件“DestNode=main”在表1所示库中搜索，得到有向边集合Edgelist={（v2，main）}，将节点v2加入集合M；

图3（b）项开始时，M={main，v2}，遍历至M的第二项，即v2。根据条件“DestNode=v2”在表1所示库中搜索，得到有向边集合Edgelist={（v1，v2）}，将节点v1加入集合M；

图3（c）项开始时，M={main，v2，v1}，遍历至M的第三项，即v1。根据条件“DestNode=v1”在表1所示库中搜索，得到有向边集合Edgelist={（main，v1）}，没有需要加入M的新节点，M此时遍历结束。

2 受影响软件生命周期资料的确认

上节所示算法给出的更改影响结果M为受影响软件单元的集合，属于软件源代码的一部分，但是按照DO-178C对民用飞机机载软件的要求，软件的更改应同步到所有受影响的软件生命周期资料。

本文以DO-178C中要求的软件追踪关系作为分析基础，以软件更改集M中涉及的每一项软件单元Mi为对象，进行生命周期数据的纵向拓展分析。

如图4所示为DO-178C中要求的软件生命周期数据的追踪关系。

1）建立软件追踪关系，具体活动包括：

a）软件需求分析阶段：建立软件高层需求与系统需求之间的双向追踪关系，建立追踪关系时应同时检查软件高层需求与系统需求之间的一致性和软件高层需求对系统需求的满足性，如有部分需求无法追踪至系统需求，应标识为派生需求，并提交安全性人员分析这些需求对系统安全性目标的影响。

b）软件设计阶段：建立软件低层需求与软件高层需求之间的双向追踪关系，建立追踪关系时应同时检查软件低层需求与软件高层需求之间的一致性和软件低层需求对软件高层需求的满足性，如有部分需求无法追踪至高层需求，应标识为派生需求，并提交安全性人员分析这些需求对系统安全性目标的影响。

c）软件编码阶段：建立软件源代码与软件低层需求之间的双向追踪关系，同时不允许有无法追踪的代码产生。

d）软件测试阶段：分别针对软件高层需求和软件低层需求编写测试用例，并在测试用例执行完成后建立软件高/低层需求与软件测试用例、软件测试用例与软件测试结果之间的双向追踪关系。

e）追踪关系的阶段评审：在软件需求评审、软件设计评审和软件编码的同行评审活动开展时，应同时针对该阶段产生的追踪关系进行评审，确保追踪关系的正确性。

根据追踪关系，确定与软件更改集M中每一项软件单元代码Mi有追踪关系的软件低层需求、高层需求以及相关测试用例，并根据更改内容实施这些相关资料的同步更改。

3 结论

软件更改影响分析向来是软件更改控制过程的难点问题，影响分析的不彻底也给航空和其它高安全领域的软件带来很多潜在的不安全因素。另外，精确的更改影响分析方法在软件开发阶段也能起到很好的缺陷预防作用^[14]。目前的更改影响分析过程主要依靠分析人员的经验，本文提出的方法把代码间的横向耦合关系和生命周期数据之间的纵向追踪关系相结合，提供了一种基于有向图的软件更改影响分析搜索算法，并给出了算法的基本数据存储结构和搜索逻辑。为软件更改过程的精确控制和彻底验证奠定了基础，对机载软件和其它高安全领域的软件更改过程有很高的参考价值。

参考文献