一种面向软件演化的代码可替换性评估方法
【专利摘要】本发明公开了一种面向软件演化的代码可替换性评估方法，对演化原因进行分析与定位，包括以下步骤：根据源代码构造相应的抽象语法树；在抽象语法树上提取表示依赖关系的边，构造出代码耦合关系图；基于程序耦合关系定义一种度量代码可替换性指标，对代码中模块的可替换性进行计算；针对演化版本中代码的可替换性发生改变的包进行分析，识别出导致代码可替换性变化的元素。该发明的评估方法不但可以自动分析源代码，度量代码的可替换性，指出代码中的核心框架，而且对演化过程中发生改变的原因进行分析定位实现了演化评估的自动化。
【专利说明】
一种面向软件演化的代码可替换性评估方法
技术领域
[0001] 本发明提出了一种面向软件演化的代码可替换性评估方法，主要利用代码中耦合 关系对代码的可替换性演化原因进行识别，属于软件维护与演化领域。
【背景技术】
[0002] 在软件的生命周期中，不断对软件进行升级、更改，以适应新的需求。而对软件的 更改往往都是在一些外部压力下进行的，如客户或行业竞争。这些更改势必会破坏程序原 有的结构，提高程序复杂度，降低代码的质量。结果导致软件的维护成本显著提高，对软件 的升级将变得更加困难。任何软件开发方法和工具都不能避免这个问题，对软件的修复工 作越晚进行，软件维护成本越高，直至维护代价超过重新开发整个系统的代价。为了解决这 个难题，需要一种技术能够跟踪软件中代码可替换性的变更，提高软件的内部质量。
[0003] 软件演化是软件工程领域正逐步受到重视的研究方向，并将得到越来越多的关 注。软件演化过程的目标就是在不违反系统约束的条件下，对软件系统的演化流程进行管 理，从而使演化后的软件系统能够在功能满足用户的需求，同时它所展现出来的质量属性 也维持在一个令人满意的水平上。
[0004] 识别程序中哪些地方变更导致代码可替换性发生变化的真实原因是演化分析中 的难点目前，只进行一个代码版本的可替换性度量，或者只提供代码变更信息而没有与代 码的可替换性相关联，不能提供真实的影响可替换性变更的信息。因此，自动地识别可替换 性变更原因对软件演化与维护的分析非常重要。
【发明内容】
[0005] 技术问题:本发明提供一种能够自动化识别演化过程中导致代码可替换性变更的 演化原因，提取代码演化中可替换性变更的演化对象的面向软件演化的代码可替换性评估 方法。
[0006] 技术方案:本发明的面向软件演化的代码可替换性评估方法，包括以下步骤：
[0007] 步骤一，根据源代码，将软件版本中的每个类构造为抽象语法树；
[0008] 步骤二，在所述步骤一构建的抽象语法树上进行解绑定处理，得到底层的依赖关 系，然后提取表示依赖关系的边，构造出代码耦合关系图；
[0009] 步骤三，基于代码耦合关系图，以包的传入耦合度和传出耦合度为基础，根据下式 计算度量软件代码中每个包的可替换性指标：
[0010] C = EC/(AC+EC)
[0011] 其中，EC代表对包的传出耦合的度量，表示依赖该包的外部包的数目，即传出耦合 集中元素的个数；
[0012] AC代表对包的传入耦合的度量，表示被该包依赖的外部包的数目，即传入耦合集 中元素的个数；
[0013] C代表该包的可替换性的评估，取值为[0-1];
[0014] 步骤四，比较软件代码中的包在各个演化版本中的可替换性指标，对于可替换性 指标发生改变的包进行变更原因分析，识别出导致代码可替换性变化的元素。
[0015] 进一步的，本发明方法中，所述步骤一构建的抽象语法树包含代码基本架构的解 析树信息，以及在方法调用处与被调方法之间建立起绑定关系。
[0016] 进一步的，本发明方法中，所述步骤二构造的代码耦合关系图具有层次特性，由类 层次耦合关系到包层次耦合关系图自下而上构造。
[0017] 进一步的，本发明方法中，所述步骤四中的变更原因分析，是针对可替换性发生变 更的包，在步骤二构造的代码耦合关系图中定位识别出导致代码可替换性变化的元素。
[0018] 有益效果:本发明方法通过Eclipse JDT生成的抽象语法树获取耦合关系，主要用 于解决代码可替换性度量的精确性以及可替换性演化原因分析问题，与现有技术相比，具 有以下优点：
[0019] (1)利用Eclipse JDT中ASTParser生成的抽象语法树，通过在解绑定技术的基础 上所获得的包耦合关系图比现有技术所获得的耦合关系更加精确和完整。传统的耦合关系 的获取通常是通过包的声明域进行耦合关系的获取，当代码中包的声明缺省时，会使得耦 合关系获取的缺失。我们的技术通过代码解绑定技术，获取在代码中底层所使用的类型，用 来生成代码在类层次的耦合关系，进而逐层向上生成包层次耦合关系，可以保证包耦合关 系获取的准确性和完整性。
[0020] (2)利用从下而上的耦合关系，为可替换性的分析提供了不同的粒度。通过在类的 耦合关系的基础上所获得的包耦合关系图，比现有技术所获得的耦合关系能够包含更多信 息更加完整。传统的方法在对可替换性结果展示时只显示到包层次的内容，不能够显示出 包中具体发生耦合关系的类。我们的技术所获的包的可替换性是建立在类粒度的耦合关系 上的，因此可以对包的耦合关系进行更细粒度的查询，能够展示出可替换性评估值在类层 次的形成原因。
[0021] (3)利用代码的耦合关系提供了软件演化的原因分析。通过我们在类层次所获取 的低层次的耦合关系传入传出耦合集，能够对软件演化过程中导致可替换性变化的原因进 行分析;传统的评估工具只有针对代码整体变更的分析，并不具有针对可替换性的演化分 析，我们的方法通过获取项目演化过程中新旧版本的耦合集，通过新旧版本的传入传出耦 合集的匹配，从而定位出与可替换性相关的演化原因。
【附图说明】
[0022]图1面向软件演化的代码可替换性评估体系结构；
[0023]图2 JcouplingEvaluator总体工作流程图；
[0024]图3抽象语法树；
[0025]图4代码耦合关系图。
【具体实施方式】
[0026]下面结合实施例和说明书附图对本发明作进一步的说明。
[0027]实施例中项目Proj中有版本Verl及其演化版本Ver2，Verl中共有七个包，分别为 pi. 1-pl .7，Ver2中对应的包为ρ2.1_ρ2.7。使用工具JcouplingEvaluator进行评估，其总体 工作流程图如图2所示。包括以下步骤：
[0028] 步骤一，根据源代码，将软件版本中的每个类构造为抽象语法树;将实施例中版本 Verl的源代码构造相应的抽象语法树，其抽象语法树如图3所示；
[0029] 抽象语法树(Abstract Syntax Tree,AST)作为程序的一种中间表示形式，在代码 解析、程序分析等诸多领域有广泛的应用。它将java源代码映射为树的形式:每个java源文 件被表示成AST节点树。Eclipse AST是Eclipse JDT的一个重要组成部分，定义在包 org. eel ipse. jdt. core. dom中，用来表示JAVA语言中的所有语法结构。
[0030] Eclipse AST的总体结构：
[0031 ] (1)、org .eclipse, jdt. core · dom. AST( AST节点类），Eel ipse AST的工厂类，用于 创建表示各种语法结构的节点。
[0032] (2)、org · eclipse · jdt · core · dom. ASTNode及其派生类（AST类），用于表不JAVA语 言中的所有语法结构，在实际使用中常作为AST上的节点出现。
[0033] (3)、〇坪.〇(：11卩86.」(11:.(3〇代.(1〇111.厶31'\^8；[1:01'(厶31'\^8；[1:01'类）4(311卩86厶31'的访 问者类，定义了统一的访问AST中各个节点的方法。
[0034] (4)、org .eclipse, jdt. core · dom. ASTParser(ASTPar ser 类），用于解析包含 java 源代码的程序，并返回一个AST。其返回的结果包含了源代码字符的范围。
[0035] 该图的源代码中包含一个类，类中包含四个成员变量和四个成员方法构成。其中 绑定技术用于获取成员变量的SimpleType节点和MethodDeclaration节点的 MethodInvocation节点中所使用的类型信息，借助EclipseAST中的绑定技术将外部类型 信息同时加载进抽象语法树，以便于节点数据类型信息的获取。
[0036] 步骤二，在所述步骤一构建的抽象语法树上进行解绑定处理，得到底层的依赖关 系，然后提取表示依赖关系的边，构造出代码耦合关系图；
[0037] 代码中的耦合关系图中有以下两种关系:传入耦合:如果特定类依赖于其他类，那 么就称它对其他类具有传入耦合关系;传出耦合:如果其他类依赖于特定类，那么就称特定 类对其他类具有传出耦合关系。
[0038] 类内根据抽象语法树上的语句节点上抽取耦合信息，其中语句节点包括声明节点 和方法调用节点；从语句节点中获取类的传出耦合类，例如类A中声明或调用中使用了类B， 类B对于类A则是传出耦合关系，类A对于类B则是传入耦合关系。
[0039]包耦合关系在类耦合关系的基础上，根据类所属的包信息，获取属于同一个包中 的类的传入耦合集合和传出耦合集合，形成包层次的耦合关系图。
[0040] 根据步骤一中所构造的AST树，对其中的节点进行解绑定(resol veBinding)处理， 可获得所依赖的类型信息，如类型名称以及所属包名。根据解绑定所获得的依赖信息，遍历 后将元素放入相应耦合集中。在实例中，包pl. 5中的类使用了 pi.4中的类，即表示pi.4为 pl .5的传出親合元素，放入pi .5的传出親合集ACSet中，pi .5为pi .4的传入親合元素，放入 P1.4的传入耦合集ECSet中。访问结束后，可获得Ver 1中各个包的传入耦合集合传出耦合 集，结果如下表所示：
[0042]表格中所记录的数字为各个耦合集中元素个数。
[0043]步骤三，基于代码耦合关系图，以包的传入耦合度和传出耦合度为基础，根据下式 计算度量软件代码中每个包的可替换性指标：
[0044] 代码可替换性主要跟模块之间的耦合度相关。模块之间的耦合分为传入耦合和传 出耦合。传入耦合是指依赖于一个包的其他包的数量;传出耦合是指一个包所依赖的包的 数量。一个包的传出耦合越大，它就越依赖于其他包，该包的变更对其他包的影响较小，但 面对关联包的更改时它容易受到连锁反应的影响。一个包的传入耦合越大，则该包被依赖 度越高，它发生更改或被替换的代价也就越大。代码可替换性中定义了如下两个集合：
[0045] 定义1传入耦合集:对于包P中的所有类集C，如果代码其他包p中的类依赖于类c， 且c e C，则p属于传入耦合集中一个元素，这些元素的集合为P包的传入耦合集ACSet。
[0046] 定义2传出耦合集:对于包P中的所有类集C，对于类c(c eC)，如果类c依赖于其他 的类c'，且d C:,c'所在的包p属于传出耦合中的一个元素，这些元素的集合为P包的传出 耦合集ECSet。
[0047] 通过可提换性度量模型，对Java软件中包的可替换性的度量评估方法，通过度量 传出耦合在耦合关系中所占据的比例对包的可替换性进行量化评价。
[0048] 该模型统计每个包所依赖包的个数及依赖于该包的包数目，并根据传出耦合在总 体耦合中所占比值大小判断该包的可替换性强弱。高的传出耦合比例表示传入耦合较低， 对象不具有太多的职责，易于进行替换；反之，高的传入耦合比例表示对象具有太多的职 责，在进行替换时候要格外小心。
[0049] 根据步骤二中的传出耦合与传入耦合，对每个包的可替换性进行计算，结果如下 表所示。
[0051 ] C表示Verl中包的可替换性值。
[0052]对项目的演化版本Ver2重复步骤一至步骤三，进行可替换性度量，同样计算出可 替换性度量值。Ver2中各个包的传入耦合集合传出耦合集表如下所示：
[0055]可替换性结果如下表所示：
[0057] 可替换性度量值越接近1，说明该包传入耦合相对较少，容易被替换;值越接近0， 说明该包传入耦合较多，难以被替换。
[0058] 步骤四，比较软件代码中的包在各个演化版本中的可替换性指标，对于可替换性 指标发生改变的包进行变更原因分析，识别出导致代码可替换性变化的元素。
[0059] 在软件演化过程中，如果代码包的可替换性度量值改变了，表示代码在演化过程 中所进行的修改导致了包的耦合关系发生了改变，例如增加、删除或修改。
[0000] 代码可替换性变更原因差异分析Diff(verl，ver2)具体步骤如下如下：
[0061 ]第一步:获取项目verl中各个包的可替换性；
[0062]第二步:获取项目ver2中各个包的可替换性；
[0063] 第三步:对比verl和ver2中各个包的可替换性数值，记录发生改变的包；
[0064] 第四步：定位在verl和ver2中发生变更的包，记为P与P'，P有传入親合集ACSet与 传出耦合集ECSet，P'有传入耦合集ACSet'与传出耦合集ECSet';
[0065] 第五步:对比ACSet与ACSet'中元素，若存在元素 aeACSet且:ai ACSch'，则表示元 素 a的传入親合关系在ver2中被删除，若元素戒ACSet且aeACSet'，贝lj表示中ver2中增加 了与元素 a的传入親合关系。记录变更信息到Diff(verl，ver2)中；
[0066] 第六步:对比ECSet与ECSet'中元素，若存在元素 e e ECSet且eG ECSet'，则表示元 素 e的传出耦合关系在ver2中被删除，若元素试ECSet且eEECSet'，则表示中ver2中增加 了与元素 e的传出親合关系。记录变更信息到Diff(verl，ver2)中。
[0067] 在如上实例中Verl到Ver2版本的演化过程中包pi. 4到p2.4的可替换性发生了变 化，其可替换性由0.73变为0.75。对比两个版本中pi. 4和p2.4的传入耦合集和传出耦合集， 记pi .4的传入親合集和p2.4的传入親合集分别为ACSet和ACSet'，实例中ACSet = ACSet'， 两者的传入耦合集在演化过程中没有发生变化;记Pi.4的传出耦合集和p2.4的传出耦合集 分别为ECSet和ECSet'，实例中ECSet中为8个元素，ECSet'中有9个元素，传出耦合耦合集在 演化过程中存在元素技ECSet且eeECSet'，则表示中Ver2中增加了元素 e的传出耦合关 系。
[0068] 记录包中增加的变更信息到Diff (Verl，Ver2)中；通过依次遍历Verl和Ver2中对 应的包得到可替换性的变化原因。
[0069] 上述实施例仅是本发明的优选实施方式，应当指出：对于本技术领域的普通技术 人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和等同替换，这些对本发明 权利要求进行改进和等同替换后的技术方案，均落入本发明的保护范。
【主权项】
1. 一种面向软件演化的代码可替换性评估方法，其特征在于，该方法包括以下步骤： 步骤一，根据程序源代码，将软件版本中的每个类构造为抽象语法树； 步骤二，在所述步骤一构建的抽象语法树上进行解绑定处理，得到底层的依赖关系，然 后提取表示依赖关系的边，构造出代码耦合关系图； 步骤三，基于代码耦合关系图，以包的传入耦合度和传出耦合度为基础，根据下式计算 度量软件代码中每个包的可替换性指标C: C = EC/(AC+EC) 其中，EC代表对包的传出耦合的度量，表示依赖该包的外部包的数目，即传出耦合集中 元素的个数； AC代表对包的传入耦合的度量，表示被该包依赖的外部包的数目，即传入耦合集中元 素的个数； 可替换性指标C代表对该包的可替换性的评估，取值为[0-1]; 步骤四，比较软件代码中的包在各个演化版本中的可替换性指标，对于可替换性指标 发生改变的包进行变更原因分析，识别出导致代码可替换性变化的元素。2. 根据权利要求1所述的面向软件演化的代码可替换性评估方法，其特征在于，所述步 骤一构建的抽象语法树包含代码基本架构的解析树信息，以及在方法调用处与被调方法之 间建立起绑定关系。3. 根据权利要求1所述的面向软件演化的代码可替换性评估方法，其特征在于，所述步 骤二构造的代码耦合关系图具有层次特性，由类层次耦合关系到包层次耦合关系图自下而 上构造。4. 根据权利要求1、2或3所述的面向软件演化的代码可替换性评估方法，其特征在于， 所述步骤四中的变更原因分析，是针对可替换性发生变更的包，在步骤二构造的代码耦合 关系图中定位识别出导致代码可替换性变化的元素。
【文档编号】G06F11/36GK105867906SQ201610164659
【公开日】2016年8月17日
【申请日】2016年3月22日
【发明人】李必信, 苗意盎, 廖力, 刘辉辉
【申请人】东南大学