基于反模式检测研究论析.docx

基于反模式检测研究论析.docx

《基于反模式检测研究论析.docx》由会员分享，可在线阅读，更多相关《基于反模式检测研究论析.docx（4页珍藏版）》请在冰豆网上搜索。

基于反模式检测研究论析

基于反模式检测研究论析

一、静态检测技术

1.手动检测

手动检测是最原始的检测方式，整个检测过程没有相关自动化工具的支持，主要体现为对相关文档或代码的阅读分析7]。

通过预先定义一系列规则，分析人员根据这些规则来判断软件中是否存在缺陷。

文献[3]将关注点从软件系统的实现转向抽象的设计如类图、序列图、状态图等。

文献[4]和文献5]主要关注需求的缺陷检测，其中需求是以SCR状态机形式表示的。

文献[6]也关注需求的缺陷检测，但其需求是以自然语言的形式描述的。

文献[7]将检测的重点放在用户接口上。

手动检测过程中，分析人员可结合实际情况及自身对设计的理解来进行分析判断，避免了反模式检测的不确定性。

不足之处是该方法需要对整个系统进行分析，随着系统规模的扩大，系统的复杂性也随之增加，这将是一个非常耗时的过程，显然这种方法不适用于大规模系统。

2.基于抽象语法树的检测

基于抽象语法树的反模式检测方法首先通过对源代码进行词法和语法分析，产生反模式的中间表示形式即抽象语法树AST（Abstractsyntaxtree）。

文献[8]提出了一种使用抽象语法树检测代码克隆的方法，通过比较语法树结构的相似度来检测克隆的表达式、语句以及数据声明。

文献[9,10]从软件演化的角度出发，跟踪代码在软件的多个版本中的历史信息，识别具有相同起源的克隆，但是由于现有的遗留系统很少会保留这些信息，该方法的适用性不强。

代码味道用于识别面向对象系统中的问题类。

基于AST的方法适合对类中的代码味道进行识别，但对类之间的代码味道识别效果不好。

3.基于度量的检测

基于度量的检测方法利用软件度量对反模式的表现症状进行表示，通过对度量设置相应的阈值，并以规则的形式来表示，从而完成反模式的检测。

下面介绍几种代表性的方法。

Ciupke提出一种针对遗留系统进行分析的方法[12]。

该方法通过对遗留系统的源码进行分析得到系统的实际设计模型，将频繁出现的缺陷问题以谓词演算的形式表示，再通过系统设计模型与实际设计模型进行比较来定位软件中的缺陷问题。

这种检测方法适用于遗留系统，采用的大多为简单的度量，如一个类不能包含超过6个对象，继承树的深度不能大于6等等，对于复杂的反模式则难以检测到。

检测策略（detectionstrategy）是Marinescu提出的一种检测设计缺陷的方法[13]。

所谓检测策略，即针对具体存在的问题选择合适的度量进行表示，组成一组反模式描述规则，然后根据反模式规则指定相应的解析模版，即针对具体问题设置合适的阈值。

文中对9种设计缺陷定义了相应的检测规则。

该方法的优势在于能根据异常的度量值清楚地知道导致系统缺陷的原因，而不需要对这些异常度量值进行分析推理来找出问题的原因。

DCPPMatrix一种利用设计变化传播概率矩阵来检测反模式的方法[14]。

这种方法适用于检测shotgunsurgerybadsmell（霰弹式修改）及divergentchangebadsmell（发散式变化）这两种软件缺陷。

霰弹式修改指的是一个变化将会引发多个类的修改，会对系统造成波动影响。

发散式变化指的是某个类受到多种变化的影响。

这是一种定量的检测方法，它通过分析软件一个组件的变化对其它组件的影响来达到检测反模式的目的。

这种方法的优势是可以根据矩阵来了解软件的波动影响，在此基础上也能够评估软件的复杂性与可维护性。

能够鉴别软件开发中一个产品是否容易受到其它变化的影响，这点对于大型系统来说是非常重要的。

DECOR是Moha等人提出的一种检测代码味道的方法。

该方法从描述反模式的一些经典文献出发，通过对自然语言描述的反模式进行领域分析，提取相关的关键词，从而制定描述设计缺陷或反模式的规则。

这种规则用BNF文法加以形式化并以规则卡的形式表示，缺陷的检测则通过特定的元模型解析器来生成相应的检测算法。

该方法能够检测4种反模式：

Blob（胖球），FuncationalDecomposition（功能分解），SpaghettiCode（面条代码）、SwissArmyKnife（瑞士军刀）及15种代码味道。

该方法依据自然语言描述的反模式来完成反模式的形式化描述，这个过程不依赖于特定的表示语言或解析模型，在不同的平台下只需实现检测算法就能完成反模式检测，但采用的固定的规则模版限制了反模式的描述能力和可扩展性。

Khomh和Vaucher等人提出了基于贝叶斯信念网络（BBN）的反模式检测方法[16]。

该方法利用文献[15]中的规则卡构建贝叶斯信念网络，通过贝叶斯分类方法计算一个类是否是反模式的概率。

这样质量分析人员可以根据概率的大小来优先验证那些有可能是反模式的类。

这种方法借助于历史检测数据，能够处理检测过程中的检测结果的不确定性以及边缘值的判定问题，而且可以根据检测结果来不断校正数据模型，从而提高检测的准确率。

但是规则卡的表达能力有限，并且在有较多复合规则的情况下，构建BBN时产生较多的中间节点，BBN的调整会带来额外的开销，此外，不完整的训练数据集也会影响检测结果的准确率，影响了该方法的实用性。

4.可视化检测

Dhambri和Sahraoui提出了一种基于系统3D图的检测方法[17,18]。

该方法通过逆向工程工具PADL及度量提取工具POM获取系统的结构关系及度量属性的值，使用软件可视化框架VERSO产生大规模面向对象系统的3D表示图，如图1所示。

每个小盒子的颜色、高度、角度等分别表示软件的不同度量属性。

然后结合图形及预定义的检测算法完成反模式的检测。

该方法目前能够检测的反模式包括Blob，MisplacedClass（遗失类），FunctionalDecomposition，SwissArmyKnife（瑞士军刀），DivergentChange，ShotgunSurgery。

ABS（AntipatternsidentificationusingB-Splines）是Khomh和Antoniol等人提出的一种基于B样条曲线的反模式表示方法[19]。

如图2所示，图中两条曲线分别表示构造的反模式曲线及类的实际曲线，通过计算两条曲线之间的相似度来判断该类是否是反模式。

这两种方法是自动检测和手动检测方法的折衷，它们结合了系统上下文信息和检测人员的经验知识，解决了完全的自动化检测方法难以结合外部信息的难题，也相对提升了完全手动验证的效率低下问题。

5.基于本体描述的检测

SPARSE是Settas等人提出的一种基于OWL本体的反模式检测方法[20]。

该方法采用本体描述反模式的根源、症状、后果及这些因素与其他反模式之间的关系。

语义关系被翻译成产生式规则，根据系统的表现症状并结合反模式知识库的信息便能检索软件系统中存在的反模式。

这种方法能够对WEB上出现的31种反模式进行表示。

这种方法适用于根据反模式的表现症状来确定造成这种情况的反模式。

因为各种反模式之间是有关联的，一个反模式的存在通常会伴随着其他反模式的存在。

一个反模式可能表现出与其它反模式相同的症状。

该方法不足之处在于随着反模式种类的增多，反模式本体增多，有可能会造成反模式本体描述产生冲突、重复或不一致的现象。

2动态检测技术静态检测技术依赖于源代码或设计文档，但在对应用系统进行维护和优化时并不能保证得到源码或所需的文档。

而且随着构件技术的发展，许多软件系统通过组装已有的商用构件进行开发，这意味着获得系统完整的源代码或设计文档更为困难。

动态反模式检测主要依赖系统运行时获取的信息，由于这类反模式通常给系统性能带来不良的影响，也被称为性能反模式。

目前的反模式检测研究大都集中在静态检测，对动态反模式检测的研究则甚少，主要有以下几种方法。

Mos和Murphy等人研发了一种面向JEE应用的性能监测工具COMPAS（ComponentPerformanceAssuranceSolutions）[21]。

该工具拦截EJB之间的调用并监测每个方法调用的响应时间，并生成UML模型，用户针对模型输入不同的负载来测量不同场景下系统的性能，通过该方法可以检测系统中存在的性能瓶颈。

类似的方法有Guo和Liao等人研发的工具JPManager[22]及Meyerhfer等人提出的针对J2EE系统的性能监控方法TestEJB[23]，它们用于帮助开发人员识别系统中的性能瓶颈。

Parsons等人针对企业级系统提出了一种EJB性能反模式的检测方法及性能诊断工具PAD（PerformanceAntipatternDetection）[24]。

该方法是一种基于运行时系统的检测方法，通过采集系统的构件部署信息及系统运行时刻的信息，利用数据挖掘算法找出这些信息中存在的关联关系和模式。

这些关联关系作为事实被加载到规则引擎，反模式也被定义为一系列规则，通过推理引擎完成规则的推理，即完成反模式的检测。

该方法主要是针对基于构件的企业级系统的反模式检测，能够检测由于系统部署和设计引起的反模式，此外，该方法结合了数据挖掘技术，能够识别出系统中潜在的性能反模式和性能缺陷。

MarcoCrasso等人开发了一个提高Java企业级应用系统性能的工具JEETuningExpert[25]。

该方法也是在系统运行时进行性能反模式检测，通过Java反射机制拦截EJB之间的调用关系并跟踪调用的堆栈信息，这些信息以日志的形式保存在XML文件中。

通过预先分析构件之间的交互行为预定义基于Drools的检测规则，接着对XML文件进行解析提取出对应的信息与预定义的规则进行匹配，满足规则的事实表明该事实是一个反模式。

该方法重点在于为开发人员提供检测之后的重构指导策略，目前该方法仅支持4种性能反模式的检测。

北京大学张磊，王玮琥等人提出了一种基于运行时软件体系结构的JEE反模式检测工具[26，27]。

该方法通过监测系统运行时体系结构来采集与应用系统相关的信息，其中包括静态信息如主机、构件等的属性信息，动态信息如构件方法调用、主机内存消耗等。

采用MOF模型对反模式进行描述，反模式的检测逻辑则根据反模式的关注点和表现形式来制定。

通过执行反模式检测逻辑所对应的QVT程序找出存在的反模式。

这种方法优势在于将反模式描述与反模式检测进行分离，这种方法适合于检测与构件调用相关的反模式，对于与构件内部逻辑的相关的反模式则无法检测。

二、相关工具介绍

Analyst4J是一个JAVA代码静态分析引擎，使用C&K度量集对输入的JAVA文件进行度量，支持对TheBlob，FunctionalDecomposition，SpaghettiCode这三种反模式及多种代码味道的识别[27]。

Aspect[29]、LCLINT[30]、EXTENDEDSTATICCHECKER[31]使用程序验证技术来识别代码味道，这些工具需要工程师在代码中增加注释来协助验证系统的正确性。

SemmleCode是一个代码分析工具[32]，通过SemmleCode工程师可以使用声明式查询语言QL对源代码进行查询从而检测出代码味道。

PMD能够检测JAVA源码中违反设计原则的地方，也允许使用JAVA或XPATH来定义新的代码味道的检测规则，但是该类工具需要用户对JAVA或XPATH比较熟悉[33]。

DependencyFinder是对JAVA程序编译后的字节码文件进行分析的工具集，它的核心是一个依赖分析工具，通过它可以提取组件之间的依赖图并进行分析[34]。

VizzAnalyzer是一个软件质量分析工具，通过阅读软件代码、设计需求及文档进行软件的质量分析[35]。

CROCOPAT对面向对象系统进行结构化分析，从而发现系统中的设计模式及编码上的问题[36]。

模型监测器BLAST[37]、MOPS[38]则使用模型检查技术检查C语言系统中违背安全属性的代码问题。

目前也有一些与性能检测相关的工具。

SABER检测J2EE应用系统编码中的错误，并提供信息来解释编码为什么存在缺陷[39]。

文献[40，41]介绍了两种性能管理工具JProfiler及Borland，能够检测出某些编程上的失误，比如内存泄漏等。

SMALLLINT针对SmallTalk代码来检测编码问题[42]。

FINDBUGS能检测JAVA系统的正确性以及与性能相关的缺陷[43]。

三、结束语

反模式检测的目的是为了及时对系统做出重构，改善软件的质量。

目前反模式检测技术主要分为两类：

静态检测和动态检测。

静态检测的信息源于系统设计文档、源代码、版本库等，动态检测则主要是利用运行时系统的信息（构件调用序列、资源消耗等）进行分析。

静态检测技术在实际中应用较多的属于手动检测和基于度量的检测。

手动检测检测结果可靠，但是效率较为低下，适合分析较小规模的系统。

基于软件度量的检测方法较为成熟，这种方法容易理解且实现简单，但有一定的局限性，即检测结果是否准确在很大程度上依赖于度量属性的选取和阈值的设置。

基于抽象语法树的检测能够识别代码克隆，但构造树的代价较高，寻找树相似的匹配算法复杂度高，不适用于较大型的系统。

可视化检测是一种较直观的检测方法，但检测的过程中可能会融入太多的主观性。

基于本体描述的检测的本质更偏向于反模式的推理，即根据反模式的表现症状来推断它最有可能属于的反模式种类。

动态检测技术作为对静态检测方法的补充，能够识别系统中可能存在的性能反模式。

目前在动态反模式检测方面的研究甚少，大都面向JEE应用系统。

这些方法中一些能够检测出系统中可能存在的潜在的性能问题和性能反模式，一些检测方法能够检测出预定义的性能反模式。

但动态检测是基于运行时系统的，它自身的数据采集过程会带来性能上的消耗。

通过上述对反模式检测技术的分析，可知目前的检测方法存在如下不足：

1）反模式描述的能力不足。

目前对反模式描述的研究大都就简避繁，仅仅针对一些常见的且容易被描述的反模式，并且每种反模式描述方法也仅适用于特定的几种反模式。

2）反模式检测的高漏报率和误报率。

阈值的设置通常是基于经验性的，通常难以提供经过实证的阈值，导致了检测结果的漏报和误报，妨碍了检测结果的适用性和可靠性。

3）检测过程难以结合系统的上下文信息。

反模式的判定与系统所处的上下文有关，也与专家的经验知识相关，未充分考虑这些因素的影响也会造成检测结果的漏报和误报。

4）开放式的系统带来了检测上的困难。

目前的基于构件的系统大多由商业构件组装而成，难以获得系统的源代码或设计文档，而且构件也可能基于不同的编程语言，这也给反模式的检测带来了困难。

5）检测工具的效果难以进行评估和对比。

反模式的检测结果受组织机构的特点、人员经验及所熟悉的技术类型等的影响，可能产生不一致的检测结果。

而且系统中真正存在的反模式数目是未知的，因此难以对检测方法的有效性做出评价。

（本文图略）

本文作者：

盛津芳胡培培王斌单位：

中南大学信息科学与工程学院