基于变更场景的体系结构元素的识别

彭钊

摘要：需求的变更影响分析对于软件系统的正确实现有着重要的意义。当前的需求变更影响分析研究方法主要集中于需求间以及需求到代码间，缺乏需求到体系结构元素之间的研究方法。其次传统的需求变更影响分析方法，在变更维护过程中，体系结构工程师需要对于变更源相关的每个体系结构元素（Architectural elements，AE）都要做出分析，这很容易造成变更影响状态爆炸。本文基于一阶逻辑相关理论以及一阶逻辑在需求间变更影响分析的应用，提出一种基于变更场景的需求变更到体系结构元素的识别，并通过一个案例来分析该方法。

关键词：需求变更影响分析;一阶逻辑;变更场景体系结构元素

中图分类号：TP311 文献标识码：A 文章编号：1007-9416（2020）05-0197-03

0引言

据调查，软件系统开发的预算中有85%到90%被用于软件系统的管理和维护，而这其中有50%被用于软件系统的变更管理。Ebert等人在文献[2J和文献[3]中通过调查得到一个结论：一个周期为一年的软件开发项目，就会有多于40%的需求发生了变更。为了尽可能的减少软件开发成本，需要尽早在软件开发周期中对变更进行管理。需求变更影响分析主要分为需求问、需求到AE以及需求到代码的变更影响分析三类。传统的方法对需求到AE之间的研究比较少，且传统的方法很容易造成变更影响状态爆炸。

需求到AE的变更影响状态爆炸：由于缺乏需求到体系结构追踪关系的语义，需求变更分析会产生大量的有关受影响的体系结构元素的误报。体系结构工程师需要对体系结构中的每—个元素进行分析，因此会造成变更影响爆炸从而忽略真正受影响的体系结构元素。

在绝大多数软件，尤其是安全关键的嵌入式软件中，需求变更影响分析有着重要的意义。很多重大的事故都是由于在软件系统的开发过程中，受变更影响的AE无法被正确识别所导致的。

综上所述，保证受影响得AE正确识别是软件开发过程中必不可少的。本文提出一种基于一阶逻辑的需求变更影响分析方法，基于一阶逻辑相关理论以及一阶逻辑在需求间变更影响分析中的应用，给出了一种基于变更场景的受影响AE的识别方法。

具体章节安排如下：第1节介绍了需求到体系结构变更影响分析的国内外研究现状;第2节介绍相关理论;第3节给出具体的方法说明;第4节用一个简单的案例说明文中方法的可行性。

1研究现状

目前，学术界对需求变更影响分析做了大量的研究。文献[6]中，通过sysML需求图描述系统的需求，通过sysML活动图、块图、内部块图和状态图描述系统的体系结构，利用一个静态切片算法，从而达到需求变更影响分析的目的。Sunny Wong等人在文献[7]中提供一种基于UML關系逻辑模型的需求变更影响分析方法。陈光颖等人在文献[8]中基于谓词逻辑和模型驱动方法，提供一种常见的需求间关系和需求到体系结构的追踪关系的形式化语义。Briand等人在文献[9]中提供了一种基于UML用例图的需求变更影响分析方法。

2相关理论

2.1基于一个需求描述定义的需求变更类型

本文用到的一个需求描述模型，基于该描述模型，本文把需求描述为一个由属性和约束条件构成的二元组，其中每个需求必定有1个或以上的属性，每个属性必定有0个或以上的约束条件。根据这个描述模型，本文把变更分为如下几种类型：增加需求、删除需求、增加需求关系、删除需求关系、更新需求关系、更新需求。

其中前面5种变更类型是显而易见，最后一种最为复杂，可分为如下表所示的6个子类型：删除/增加“一个属性”;删除/增加一个“约束条件”;“更新”属性/约束条件。

2.2基于变更场景的变更影响规则

定义：变更场景（change senafio）：对于任意两个需求之间，如果存在某种需求关系RLo对于这两个需求中的任意—个需求引入任意一种变更类型CT，此时二元组构成一种需求场景，一个确定的变更场景，必然会导致确定的变更影响。

基于2.1中的变更类型以及它们在一阶逻辑下的形式化语可以得出如表1所示的变更影响规则。

3基于变更场景的受影响AE方法

3.1重构与领域变更

本文基于变更的原理将需求变更分为重构（refactoring）和领域变更（domain change），其中语义保留变更与重构对应，语义修改变更与领域变更对应。需求的重构是指仅仅改善需求模型而不会改变整个系统的属性;需求的领域变更是指需求变更会改变系统的属性并且通常会改变满足这条需求的体系结构元素。例如：把一个需求R简单的分解为R1，R2……Rn，这种变更即为重构，因为这种变更并没有改变整个系统的属性，例如为需求R添加一个属性pt。

3.2基于变更类型的受影响AE识别

基于第2节中的变更类型，可以把受影响的AE是识别分为四大类：

（1）对于变更类型为“增加需求关系”“删除需求关系”“更新需求关系”的受影响AE的识别：如果变更类型为上述三种，那么满足变更需求的AE不会受到影响，因为这三种类型的需求变更属于重构，不会改变需求模型中的属性。

（2）对于变更类型为“为需求增加一个属性”的受影响AE的识别：如果添加的属性是新的系统属性，即之前的需求模型中不存在的属性，那么满足变更需求的AE必然会受到影响;如果添加的属性不是一个新的系统属性，那么满足变更需求的AE不会受到影响，因为对需求的描述中并没有对已存在的属性和添加的属性之间的显式依赖关系的描述，所以很多情况无法自动识别添加的属性是否是一个新的属性，此时就不能确定满足变更需求的AE是否受到影响，这种情况需要通过体系结构工程师来分析。

（3）对于变更类型为“增加需求”的受影响AE的识别：如果添加的需求中引入了新的系统属性，那么满足变更需求的AE必然会受到影响。如果添加的需求中没有引入新的系统属性，那么满足变更需求的AE不会受到影响。

（4）除上述（1）（2）（3）中的需求变更，其他需求变更类型“删除需求”“更新需求（不包括为需求增加一个属性）”会更新需求模型中的属性，因此满足更新的属性的体系结构元素会受到影响，变更的需求中某些属性有可能未更新，因此满足未更新的属性的体系结构元素不会受到影响，可以通过在需求模型中遍历变更的传播路径来确定是否有未受影响的属性集，如果有，确定受影响的属性的最小集。然后在确定受影响的体系结构元素。

3_3基于变更类型的受影响AE识别算法

对于受影响的AE的识别，本文给出一个算法来实现该函数。如图1为算法概述。

如图2为算法流程图。

判定条件1：变更类型为“增加需求关系”“删除需求关系”“更新需求关系”;

判定条件2：变更类型为“新增需求”;

判定条件3：已有需求和新增需求之间存在“refines”“partially refines”“contains”關系;

判定条件4：新增需求和已有需求之间存在“requires”“required”“refines”“partially refines”关系;

判定条件5：变更类型为“为已有需求增加一个属性”;

判定条件6：增加的属性是一个全新的，之前不存在的系统属性。

对于该算法，如果变更类型不属于判定条件1，2，5中的任意一种，则基于图3中的遍历规则调用算法1中的traverse PmpagalionPath函数，得到受影响的AE。

算法1：受影响的AE识别算法，如图3。

4案例分析

我们通过RPM（远程病患监护系统）中的两个需求来说明本文方法的可行陛：

有以下需求R1和R2：

R1：系统应该通过传感器把测量到的患者的血压存储到系统的存储器中。

R2：系统应该通过传感器把测量到的患者的中心静脉压存储到系统的存储器中。

对于上述关系，存在R2 refines R1，现在引入需求变更：除了测量中心静脉压之外，还需测量肺动脉压。添加需求R3：

R3：系统应该通过传感器把测量到的患者的肺动脉压存储到系统的存储器中。

对于上述关系，存在R3 refines R1，则需求R3必定对满足R1的AE产生影响，证明如图4所示。

5总结与展望

本文基于一阶逻辑相关理论以及一阶逻辑在需求问变更影响分析中的应用，定义了变更场景，并基于需求问变更影响分析规则，提供了一种对影响的AE识别分类方法，给出了相应的算法。

但本文依然存在很多不足，首先本文的方法仅支持识别受变更影响的体系结构元素模型，不支持变更在体系结构中的传播，即本文的方法只能是被受影响的体系结构元素，无法通过体系结构中引入变更并传播变更来对体系结构进行更改以解决体系结构元素不满足变更后的需求的问题。另一方面，在某些特定的情况下，本文的方法存在局限性，例如当变更类型为“增加一个需求”时，系统原有的需求中必须要有与新增需求有关系的需求，否则变更影响分析算法无法执行，即无法对该变更场景进行变更影响分析。