论文《Evaluating the impact of design pattern and anti-pattern dependencies on changes》笔记

Evaluating the impact of design pattern and anti-pattern dependencies on changes and faults

评估设计模式和反模式依赖项对变更和故障的影响

Abstract

一方面，设计模式是针对反复出现的设计问题的解决方案，旨在提高重用性，灵活性和可维护性。但是，许多先前的工作发现，某些模式（Observer and Singleton）与大型代码结构相关联，并认为它们更容易出错。另一方面，反模式（anti-patterns）描述了设计和实现问题的糟糕解决方案，这些问题突出了软件系统设计中的弱点，并且可能减慢维护速度并增加故障风险。已经发现它们会对变更和故障倾向产生负面影响。参与设计模式和反模式的类具有与其他类的依赖关系，例如静态和共同变更依赖关系，这可能会将问题传播到其他类。我们通过研究静态和共更改依赖关系的存在与（1）错误倾向，（2）更改类型以及（3）依赖类型之间的关系来研究此类依赖关系在面向对象系统中的影响。这些类表现出的缺点。我们分析了39个版本的ArgoUML，JFreeChart和XercesJ中的6个设计模式和10个反模式，并调查了与设计模式或反模式具有依赖性的类比其他类具有更高的错误几率。

我们表明，在这三个系统的几乎所有版本中，具有反模式依赖关系的类比其他类更容易出错，而对于具有设计模式依赖关系的类却并非总是如此。我们还观察到，结构更改是最常见的更改，它会影响具有反模式依赖性的类。软件开发人员可以利用有关设计模式和反模式依赖项影响的知识，将测试和审查活动更好地集中于风险最大的类，并充分传播更改。

object-oriented systems （面向对象系统）

 

1 Introduction

开发人员将设计模式用作针对面向对象设计问题的重复设计解决方案，这些问题可以改善其类的几个质量属性，例如可重用性，灵活性以及最终的可维护性。然而，最近的工作，例如，(Aversano et al. 2009;2011年Gatrell和Counsell）已经表明，在某些系统中，某些设计模式类，例如参与复合设计模式的类)比非设计模式类更容易出错。同样，开发人员在解决面向对象系统中反复出现的设计问题时可能会引入较差的解决方案。这些不良的解决方案以反模式的形式记录下来（Webster 1995）。在设计中使用反模式实例会对代码质量产生负面影响（Moha等2010），因为反模式类比其他类更易更改且容易出错（Khomh等，2012）。

但是，以前的工作都没有通过它们的静态和共更改依赖性来分析设计模式和反模式实例的存在对系统其他类别的故障带来的影响。软件系统中类之间的静态依赖关系通常是使用，关联，聚合和组合关系（Gueh´eneuc和Albin-Amiot 2004）。当开发人员在更改类时也必须更改其他类时，存在Co-change依赖项（或时间依赖项）。尚不清楚与静态模式或co-change与反模式和设计模式实例相关的类如何与错误关联。

 

Conjecture（猜想）

因此，我们推测，与系统中的其他类相比，与反模式和设计模式类具有依赖关系的类可能更频繁地参与到故障修复更改中，并且故障可能通过它们的依赖关系从反模式和设计模式类传播到其他类。

Context

我们在之前的工作（Jaafar等人，2013a，b）中表明，应该更多地关注参与反模式实例的类与其他类之间的静态和co-change依赖。在本文中，我们对ArgoUML，JFreeChart和XercesJ的另外10个版本进行了重复研究，以评估结果的推广性。 我们还提出了有关参与设计模式实例的类与其他类之间的静态和共更改依赖性的影响的新结果。

因此，我们通过以下三个贡献扩展了我们先前的工作（Jaafar等，2013b）。 首先，我们扩展了我们的方法，以分析具有依赖于设计模式的类的故障倾向。第二，我们通过提供细粒度分析和一些可行的建议来提供有关我们发现的更多详细信息。 第三，我们研究影响与反模式或设计模式类具有依赖关系的类的变化和故障的类型。我们研究结构变化（Gerlec and Hericko 2012），定义为将面向对象的组成部分（例如，类，方法，字段）转换为变化类型的变化。 我们将数据故障，接口故障，逻辑故障，描述故障和语法故障作为故障类型进行研究。

Research Questions

我们以两种方式分析反模式和设计模式类以及其他类之间的静态和共更改依赖性。从数量上讲，我们调查与静态模式或设计模式实例具有静态关系（使用，关联，聚合和组成关系）的类是否比其他类更容易出错。然后，我们调查与反模式类或设计模式类共同更改的类是否比其他类更容易出错。定性地，我们分析影响这些类别的变化和缺陷的类型。 因此，我们提出以下研究问题：

– RQ1：与反模式类具有静态关系的类是否比其他类更容易出错？

– RQ2：与反模式类共同更改的类是否比其他类更容易出错？

– RQ3：与设计模式类具有静态关系的类是否比其他类更容易出错？

– RQ4：与设计模式类共同更改的类是否比其他类更容易出错？

– RQ5：静态和共更改依赖关系会传播哪些类型的更改和故障？

我们对ArgoUML的11个发行版，JFreeChart的9个发行版和XercesJ的19个发行版进行了研究，并研究了这些发行版之间发生的更改和修复错误的更改。 我们在这些系统中检测到六个设计模式和10个反模式的实例，以在考虑变化和故障的同时通过它们的静态和共更改依赖性研究反模式与设计模式类和其他类之间的关系。

本文的主要结果是：（1）具有反模式类的静态依赖确实对更改和故障具有负面影响；（2）具有反模式和设计模式类的co-change依赖性对更改和故障具有相似的负面影响。我们还将讨论影响与反模式和设计模式类相关的类的变化和故障类型。 依赖于反模式类的类更容易受到逻辑错误和结构更改的影响。 依赖于设计模式类的类更容易受到代码添加更改和语法错误的影响。

最后，我们展示了考虑与反模式和设计模式类一起考虑静态和共更改依赖性的好处，以提高对类故障倾向性的预测的准确性，以及关于本研究及其结果的有用性和局限性的其他讨论。 我们表明，考虑反模式的依赖性可以改善容易出错的类的预测。

第2节介绍了我们的方法。 第三部分描述了实证研究。

第4节介绍了研究结果，而第5节则分析了结果以及对其有效性的威胁。 然后，第6节将我们的研究与以前的工作联系起来。 最后，第7节总结了研究并概述了未来的工作。

2 Methodology

本节介绍了我们的方法论以及提取和分析进行实证研究所需的数据所必需的步骤。给定一个面向对象的程序，我们使用DECOR（Moha等，2010）提取反模式实例，并使用DeMIMA（Gueh，eneuc和Antoniol 2008）提取设计模式实例。当我们专注于这些模式的依赖性时，我们使用PADL2提取静态关系，并使用Macocha（Jaafaret等人，2011年）检测协变。 最后，我们分析了反模式和设计模式依赖性对故障倾向性的影响，并研究了此类依赖性传播的变化和故障类型。

2.1 Identifying Anti-pattern Classes（识别反模式类）

我们使用DECOR（Moha等人2010）来指定和检测反模式实例。DECOR基于对文献中定义的反模式的全面域分析，并提供了特定领域的语言来指定代码气味和反模式以及自动检测其发生的方法。DECOR使用规则来描述具有不同类型属性的反模式：词法（即类名），结构性（即声明公共静态变量的类），内部（即方法数量）以及属性之间的关系（即 ，类之间的使用，关联，聚合和组合关系）。 使用这种语言，DECOR描述了几种反模式。

在下文中，我们考虑来自Brown等人的10种反模式实例（1998年），在表1中进行了描述。我们选择这些反模式是因为它们代表了数据，复杂性，大小以及类提供的功能方面的问题（Khomh等人，2012）。我们也使用这些反模式，因为在先前的工作中已经使用和分析了它们（Khomh等人，2012； Moha等人，2010）。 定义和规范超出了本文的范围，可在其他地方获得（Romano等，2012； Brown等，1998）。

我们会对不一致的反模式进行预处理（由于最终的错误和检测工具的不确定性），以消除误报。我们手动验证DECOR检测到的每次出现的反模式，以验证分析集的正确性。 这种预处理降低了我们错误回答研究问题的风险。 但是，我们的结果仍可能会受到假阴性的影响，即受检测方法召回率低的影响。 但是，检测到的反模式实例的样本足以支持我们的结论。

2.2 Identifying Design Pattern Classes（识别设计模式类）

我们使用DeMIMA（Gueh eneuc和Antoniol´2008）来指定和检测设计模式的实例。DeMIMA通过首先识别与二进制类关系有关的惯用法来获得源代码的惯用模型，从而确保设计模式与源代码之间的可追溯性。然后，使用该模型，它可以标识设计模式的解决方案并生成系统的设计模型。 因此，DeMIMA使从源代码中恢复两种类型的设计选择成为可能:与类之间的关系有关的习惯用法和描述类的组织的设计主题。

Table 1 List of anti-patterns considered in this study（可以放进去解释反模式类都有啥）

设计模式最初分为以下几类：创造模式，结构模式和行为模式（Gamma等，1994）。创建模式描述了以适当方式创建对象的创建机制。 它们使代码功能独立于对象的创建，组合和表示方式。结构模式通过提供关联类的简单方法来简化设计。 他们关注类和对象如何组成更大的结构。 最后，行为模式描述了对象之间的通用通信模型。 他们关注算法和对象之间的职责分配，以提高软件系统的灵活性。

在下文中，我们重点介绍属于这三类的六个设计模式的实例：两个创建模式（Factory方法和原型），两个结构模式（Composite和Decorator）以及两个行为模式（Command和Observer），分别是 表2中简要定义，而其他地方则有完整定义（Gueh'eneuc和Antoniol 2008； Gamma等人1994）。除了属于不同的类别外，我们选择了这六种设计模式，因为初步的研究表明，我们可以识别出足够的实例来进行我们的研究。实际上，在被分析的系统的版本中并不存在其他一些设计模式。如果能够识别出足够多的设计模式实例，那么未来的工作可以复制我们对其他设计模式的研究。

Table 2 List of design patterns considered in this study

2.3 Identifying Anti-patterns and Design-Pattern Static Relationships

（识别反模式和设计模式静态关系）

DeMIMA依赖于一组用于单向二进制类关系的规范化（Gueh'eneuc和Albin-Amiot'2004）。 形式化根据四种独立于语言的属性定义了关系，这些属性可从系统的静态和动态分析得出：排他性，消息接收者的类型，生存期和多样性。 因此，我们还使用DeMIMA来检测类（包括反模式类）之间的关系。

我们使用开源的Ptidej工具套件3来识别反模式和设计模式类以及类之间的静态关系。 Ptidej工具套件实现了DECOR和DeMIMA，并使用了PADL（Gueh eneuc和Antoniol´2008）元模型。 它解析系统的源代码以构建模型，其中包括在任何面向对象的系统中找到的所有组成部分：类，接口，成员类和接口，方法，字段，继承和二进制类关系。

首先，我们确定不同分析系统中所有反模式实例和感兴趣的设计模式。 然后，我们在这些实例中检测其余类的依赖关系。因此，与属于反模式或设计模式实例的两个类B和C有依赖关系的类a，被认为与反模式或设计模式有依赖关系。

First of all, we identify all the instances of the anti-patterns and design patterns of interest in the different analyzed systems. Then, we detect the dependencies of the classes in these instances with the rest of the classes. Thus, a class A having dependencies with two classes B and C, which belong to an instance of an anti-pattern or design pattern, is considered as having a dependency with the anti-pattern or design pattern.

2.4 Identifying Anti-pattern and Design-Pattern Co-changes

（识别反模式和设计模式的共同变更）

我们使用Macocha（Jaafar等人，2011年）来挖掘软件存储库，并使用反模式或感兴趣的设计模式实例来标识co-change类。在Macocha中，更改包含几个属性：更改的类名称，更改日期，开发人员已提交更改。Macocha将CVS / SVN更改日志作为输入。首先，它使用k最近邻算法（Dasarathy 1991）计算不同变化周期的持续时间。 其次，它将变更周期中的变更分组。 第三，创建一个描述每个变更时期每个类的演变的概要文件;第四，使用这些概要文件来计算类的稳定性，然后识别共同更改的类。

First, it calculates the duration of different change periods using the k-nearest neighbor algorithm (Dasarathy 1991). Second, it groups changes in change periods. Third, it creates a profile that describes the evolution of each class in each change period.Fourth, it uses these profiles to compute the stability of the classes and, then, to identify co-changed classes.

与Aversano等人（2007）相似，如果C与至少一个参与X的类共同变化，则我们假设C类与设计模式或反模式X的实例共同变化。如果S与至少一个参与A的类具有使用，关联，聚集或组成关系，则该类S与设计模式或反模式实例A具有静态关系。

2.5 Identifying Faults in Classes

故障倾向性是指一类是否在系统生命周期中进行了至少一个故障修复。 错误修复记录在错误报告中，该报告描述了系统中不同类型的问题。 它们通常发布在问题跟踪系统中，即，针对三个已研究系统的Bugzilla，由用户和开发人员警告其社区有关其功能方面的未决问题； 这些系统中的问题处理不同类型的变更请求：修复错误，重组等。

3 Study Definition Design

本节描述了我们的实证研究的设计。 我们在研究中详细介绍了方法和分析的对象系统。 然后，我们讨论我们的研究问题和分析方法。

我们研究的目的是评估与反模式或设计模式类具有静态或共更改依赖性的类是否比其他类具有更高的可能性来参与更改和故障。质量重点是通过检测和分析反模式和设计模式对故障和更改的影响来提高可维护性并减少维护工作。 我们研究的背景是系统的理解和维护。

3.1 Object Systems

我们将研究应用于三个Java系统：ArgoUML，4 JFreeChart，5和XercesJ.6。我们使用这些系统是因为它们是开源的，属于不同的领域，跨越数年和不同的版本，并且具有成百上千的类。 表3总结了有关这些系统的一些统计信息。

Table 3 Descriptive statistics of the object systems

表格介绍：

ArgoUML是Java中的UML图表系统，并根据开源BSD许可发布。 在我们的研究中，我们在2008年9月27日至2011年12月15日之间的时间间隔内总共提取了4,480张快照。

JFreeChart是创建图表的Java开源框架。 对于我们的研究，我们考虑了从2007年6月15日（版本1.0.6）到2009年11月20日（版本1.0.13α）的观察间隔，其中提取了2,010张快照。

XercesJ是处理XML文档的软件库的集合。 它是用Java开发的，由Apache Foundation管理。 为了进行分析，我们从2003年10月14日到2006年11月23日的时间间隔从1.0.4版到2.9.0版中提取了159,196张快照。

表4和表5显示了co-change类的比例以及参与本文所考虑的反模式和设计模式的类之间的静态关系。他们表明所选系统与研究相关，因为这些系统中的某些类别确实会发生共同变化，并且与反模式和设计模式类具有静态关系。

表4：反模式依赖关系的比例（CC：反模式类与其他类的共更改依赖关系； SR：反模式静态关系）表5：设计模式依赖关系的比例（CC：设计模式类与其他类的共更改依赖关系； SR：设计模式静态关系）

3.2 Research Questions

我们将研究分为三个步骤：首先，我们调查在三个分析系统中，与反模式类共同更改或具有静态关系（使用，关联，聚合和组成关系）的类是否比其他类更容易出错 ：

–对于RQ1：与反模式类具有静态关系的类是否比其他类更容易出错？ 我们检验以下零假设：

– HRQ10：与反模式实例具有静态关系的类和其他类所承载的故障比例相同。 如果我们拒绝零假设HRQ10，则意味着在分析的系统中，与反模式具有静态关系的类所承载的故障比例与其他类所具有的故障比例不相同。

-对于RQ2：与反模式类共同更改的类是否比其他类更容易出错？ 我们检验以下零假设：

– HRQ20：涉及具有共同变更依赖关系的类别与反模式实例和其他类别的故障比例相同。 如果我们拒绝零假设HRQ20，则与反模式共变的类所承载的故障比例与与反模式互不变化的类所承载的故障比例不同。

 

其次，我们调查与设计模式实例共同更改类或具有静态关系的类是否比其他类更容易出错。

–对于RQ3：与设计模式类具有静态关系的类是否比其他类更容易出错？ 我们检验以下零假设：

– HRQ30：与设计模式实例和其他类具有静态关系的类所承载的故障比例是相同的。 如果我们拒绝零假设HRQ30，则与设计模式具有静态关系的类所承载的故障比例与其他类所承载的故障比例不相同。

–对于RQ4：与设计模式类共同更改的类是否比其他类更容易出错？ 我们检验以下零假设：

– HRQ40：涉及具有共同变更依赖关系的类别与设计模式实例和其他类别的故障比例相同。 如果拒绝原假设HRQ40，则与设计模式共同变化的类别所携带的故障比例与其他类别所不同。

 

第三，我们进行了定性研究，以探索与反模式或设计模式实例相关的类所携带的变化和错误的类型。 因此，我们回答以下研究问题：

–对于RQ5：静态和共更改相关性会传播哪些类型的更改和故障？ 我们研究依赖于反模式实例或设计模式实例的类是否经历了特定的结构更改（Gerlec和Hericko 2012）（属性的添加/删除/更改，方法的添加/删除或方法签名的更改） 而不是非结构性更改，即在不更改类结构的情况下添加/删除/更改行。 我们还将研究此类是否具有特定类型的错误（数据错误，接口错误，逻辑错误，描述错误和语法错误）。

3.3 Analysis Method

我们使用R统计环境执行第4节中报告的分析。 我们使用Fisher精确检验（Sheskin 2007），因为它是一种重要性检验，被认为比其他对数似然比或Pearson's Chi-Squared检验（Pedersen 1996）更适合稀疏和偏斜的数据样本。 实际上，此测试对于将两个不同组中的对象进行分类而得到的分类数据很有用。 在我们的研究中，我们研究了对反模式或设计模式类别的静态或共更改依赖性的发生与故障风险之间关系的重要性。

我们还计算了比值比（Sheskin 2007），该比值表示事件发生的可能性。比值比显示了预测变量和兴趣响应之间的关联强度。确实，它的优点是在样例对照，随访和横断面研究中它是不变的，因此可以用来直接比较不同研究设计的发现。同样，在我们的研究中，优势比可以直接从逻辑回归的回归系数中计算出来。最后，如果所分析的现象很少见，并且从人群中随机选择病例和对照，则它是一个很好的风险比估计值（Rothman等，2004）。比值比定义为一个事件在一个样本中发生的几率p的比值，即，与反模式具有静态关系的类被识别为容易在另一事件中发生的同一事件的几率q的几率样本，即，将其他类别识别为容易发生故障的可能性。

因此，如果每个组中事件的概率是p（例如故障类别）和q（不是故障类别），则优势比为：

大于1的比值表示该事件在第一个样本中的可能性更大，而小于1的比值表示该事件在第二个样本中的可能性更大。

4 Study Results

在本节中，我们通过报告经验结果以及一些典型示例和其他观察结果来回答每个研究问题。 表6、7、8和9总结了我们在故障倾向方面的发现。

4.1 RQ1：与反模式类具有静态关系的类是否比其他类更容易出错？

表6报告了ArgoUML，JFreeChart和XercesJ的数量：（1）与反模式类具有静态关系并被确定为有缺陷的类的数量； （2）与反模式类具有静态关系的类，并标识为干净的（即无缺陷）； （3）与反模式类没有静态关系的类，并标识为错误类； （4）与反模式类没有静态关系的类，标识为干净的。考虑到不同分析系统中的所有类别，我们还在反模式类别和其他类别之间分离了表6中的结果。 之所以进行这种分离，是因为很难分辨观察结果是由于类别属于反模式的事实还是由于它们取决于属于反模式的类别的事实引起的。

在测试HRQ10时，费舍尔精确测试和比值比的结果对所有三个系统都非常重要。对于这三个系统，p值小于0.05，并且具有静态关系的类与某些反模式类发生错误(即，比值比)大约是其他类有错误的可能性的两倍。

因此，我们可以肯定地回答RQ1如下：与反模式类具有静态关系的类比其他类明显更容易出错。

Other Observations ：

当我们将第2节中描述的代码列表和更改指标作为输入并研究仅基于这些指标的模型与基于这些指标加上反模式静态关系的模型之间的故障倾向性在统计上有显着差异时，我们发现不可能完全排除与反模式具有静态关系的类与其他具有相似复杂性，更改历史和代码大小的类之间的故障预测在统计上没有显着差异的可能性。但是，如果我们根据不同的反模式对结果进行分组（请参阅第5节中的表14），则会观察到与属于Blob，ComplexClass和SwissArmyKnife反模式的类具有静态关系的类比其他类型更容易出错。 类具有相似的复杂性，更改历史记录和代码大小。我们将在第5节中提供更多详细信息和讨论。

 

表6：具有与反模式具有静态关系的类（SR：静态关系，AP：反模式）的ArgoUM JFreeChart和XercesJ的权变表和Fisher测试结果

表7：与反模式共同变更的类的ArgoUML，JFreeChart和XercesJ的权变表和Fisher测试结果（AP：反模式）

表8：对于与设计模式具有静态关系的类（SR：静态关系，DP：设计模式），ArgoUML，JFreeChart和XercesJ的列联表和Fisher测试结果

表9：与设计模式共同变更的类的ArgoUML，JFreeChart和XercesJ的列联表和Fisher测试结果

4.2 RQ2: Are Classes that Co-change with Anti-pattern Classes more Fault-prone than other Classes?

表7列出了ArgoUML，JFreeChart和XercesJ的列联表，其中列出了（1）与反模式类共同更改并被识别为故障的类的数量；（2）与反模式类共同更改并被标识为 清洁; （3）其他有缺陷的类别； （4）其他分类为清洁级。

在这三个系统中，我们检测到大多数反模式类的共同变更情况。 在ArgoUML中，我们观察到与其他反模式类相比，参与Blob，LongMethod和RefusedParentBequest反模式的类与其他类的变化更大。 在JFreeChart和XercesJ的发展过程中，参与Blob反模式的类与其他类的变化最大。

测试HRQ20时，费舍尔精确测试和比值比的结果非常显着。对于所有三个系统，p值均小于0.05，并且与某些反模式类共同更改的类遇到故障的可能性比其他类遇到故障的可能性高大约两倍半。

我们还可以肯定地回答RQ2，如下所示：与反模式类共同更改的类比其他类更容易出错。

Other Observations：

在ArgoUML中，我们检测到其类与其他类共同更改的ClassDataShouldBePrivate，ComplexClass和LongParameterList反模式的某些实例。 但是，我们没有检测到属于这些反模式的任何类，这些类与JFreeChart和XercesJ中的其他类共同更改。 我们也没有检测到与XercesJ中LongMethod类共同更改的类。最后，我们观察到与反模式类共同更改的类比具有相似复杂性，更改历史记录和代码大小的其他类明显更容易出错（请参见第5节中的表14）。

 

4.3 RQ3: Are Classes that have Static Relationships with Design Pattern Classes more Fault-prone than other Classes?

表8报告了对于ArgoUML，JFreeChart和XercesJ，（1）类的数量与设计模式具有静态关系并被标识为错误； （2）与设计模式具有静态关系并被确定为干净的类； （3）与设计模式没有静态关系并被确定为错误的类； （4）与设计模式没有静态关系并被确定为干净的类。考虑到不同分析系统中的所有类，我们还将设计模式实例中的类与其余类之间的表6中的结果分开。 我们执行这种区分是因为很难分辨我们的观察是由于类本身属于设计模式实例还是由于它们依赖于设计模式实例而引起的。

测试HRQ30时，费舍尔精确测试的结果和比值比对于所有三个与设计模式具有静态关系且不属于设计模式的类的系统均不重要。 对于这三个系统，p值大于0.05：具有静态关系的类与设计模式类有故障的可能性几乎等于其他类有故障的可能性。

因此，我们对RQ3的回答如下：与设计模式类具有静态关系的类不会比其他类明显更容易出错。

Other Observations：

设计模式类可以与反模式类具有静态关系。 我们认为，开发人员试图通过将其类与特定的设计模式类相关联来克服反模式的负面影响。 这种方法可以减少反模式对软件系统的影响，因此，从长远来看，开发人员可以消除这些反模式。 未来的研究应分析这种设计选择对变更和故障的利弊。

例如，在XercesJ v1.0.4中，类org.apache.xerces.validators.common.XMLValidator.java是一个过于复杂的类。 开发人员尝试为此类的所有可能用途提供服务。 在他们的尝试中，他们添加了大量接口签名以满足所有可能的需求。 开发人员可能对XMLValidator.java并没有明确的抽象或目的，这表现为其接口缺乏重点。 因此，此类是SwissArmyKnife。 这种反模式是有问题的，因为复杂的界面难以让其他开发人员理解，并且掩盖了类的意图和用法。 这也使得调试，记录和维护类变得困难。

我们注意到该类与org.apache.xerces.validators.dtd.DTDImporter.java类具有使用关系，该类属于Command设计模式。 使用Command类可以更轻松地构造在选择时委托或执行方法调用的常规组件，而无需了解方法的所有者或方法参数。 因此，开发人员可以通过相关的Command使用XMLValidator.java来封装SwissArmyKnife，该命令封装了所有必需的信息。

4.4 RQ4: Are Classes that Co-change with Design Pattern Classes more Fault-prone than other Classes?

表9给出了ArgoUML，JFreeChart和XercesJ的列联表，该表报告了（1）与设计模式共同更改并被识别为故障的类的数量； （2）与设计模式共同变化的班级，并确定为干净的； （三）其他有缺陷的类别； （4）其他分类为清洁级。

在测试HRQ40时，费舍尔精确测试的结果和比值比的结果对于与设计模式共同更改而不属于设计模式的一组类别非常重要。对于所有三个系统，p值均小于0.05，且似然性 与某些设计模式类共同更改的类遇到故障的可能性比其他类高大约一半半。

因此，我们对RQ4的肯定回答如下：与设计模式类共同更改的类比其他类更容易出错。

Other Observations：

在这三个系统中，我们观察到，如果不能正确维护与设计模式的共更改依赖关系，则它们可能导致系统故障。 例如，chart.Title.java类属于JFreeChart中的Observer设计模式。该类与chart.event.ChartChangeEvent.java类共同更改。 在JFreeChart的Bugzilla数据库中，错误ID7728报告说：“在将构造函数参数title设置为null的情况下创建JFreeChart时出现问题，因此，修改title时不会发送ChartChangeEvent。 这些结果可以帮助为开发人员提供他们应该仔细考虑的类列表，以确保正确进行更改传播并提高可维护性。

我们的分析结果还表明，与设计模式具有依赖性的类之间的关系及其在系统演进过程中的故障倾向性。 可以从以前的工作中获得这种连接，例如（Vokac 2004; Gatrell and Counsell 2011）。 但是，设计模式的静态关系并不能提高基于复杂性指标和变更指标的故障预测模型的精度。 我们将在第5节中对此进行讨论，并提供更多解释。

我们为所有研究的设计模式检测共同变更情况。特别是，我们观察到Composite和Observer类与其他类的共同变化要比分析设计模式的其他实例中的其他类更多。这两种设计模式的规范和使用促进了主题和观察者之间以及组件和组件之间的共同更改依赖性。观察者设计模式定义一个称为主题的对象，该对象维护其依赖项的列表（称为观察者），并通常通过调用其方法之一来自动将状态更改通知它们。 chart-.Title.java类属于JFreeChart中的Observer设计模式，并且与chart.event.ChartChangeEvent.java类共同更改。复合类维护组件的集合。通常，通过遍历该集合并为集合中的每个组件调用适当的方法来实现复合方法，如ArgoUML中与WizAssocComposite.java共同更改的CrNodeInsideElement.java（复合类）

4.5 RQ5: What Types of Changes and Faults are Propagated by Static and Co-change Dependencies?

为了确定由于对反模式和设计模式的依赖性而传播的更改和故障的类型，我们挖掘了软件存储库，例如更改日志和Bugzilla。 我们使用diff查询每个研究系统的SVN，diff是比较文件并生成差异列表的工具。 我们记录了diff报告的已添加，删除或更改的代码行。 我们通过分析差异列表和手动提交的日志消息来确定变更的类型。 我们还通过分析消息日志和Bugzilla中的相应注释来调查故障类型。 该方法易于实现，因为它很容易从版本控制系统（例如SVN）中提取增量。 然后，我们报告通过依赖于反模式和设计模式传播的更改和故障的类型。

表10报告了ArgoUML，JFreeChart和XercesJ（具有反模式依赖项的类的变化最频繁（超过50％的情况））的类型，我们观察到大多数具有反模式依赖项的类都共享结构 变化。实际上，与反模式具有依赖性的类通常会受到影响其接口的更改的影响。 例如，与LongMethod，ComplexClass和LongParameterList反模式具有静态关系的类比任何其他更改操作都要进行更多的重构操作，这可能是因为此类太大了，必须使用自动化工具来划分它们并使它们易于管理。 还观察到与MessageChains和SwissArmyKnife反模式具有静态关系的类很复杂，它们提供或调用了太多服务，它们更有可能经历结构更改，从而可能破坏其复杂性。

表10：具有静态和共更改依赖性且带有反模式的类的最常见更改类型

表11报告了ArgoUML，JFreeChart和XercesJ对于具有静态和共更改依赖关系且具有反模式的类，故障的类型更多（超过类的50％）。 与反模式类具有依赖关系并具有故障的大多数类共享特定类型的故障。 例如：Blob，ComplexClass和LongParameterList反模式使用比平均类更多的复杂方法来表征类。 因此，添加新功能或解决问题的开发人员更有可能触及这些类及其依赖性。 此类维护活动会增加此类类别涉及逻辑故障的风险，例如无限循环和无限递归（超过故障的50％）。 这一观察结果证实了福勒和布朗关于此类分类的警告（布朗等，1998）。

表12报告了ArgoUML，JFreeChart和XercesJ的情况，即与六个分析的设计模式具有静态关系和共更改依赖关系的类的更频繁的更改类型是方法添加/删除。 设计模式是软件设计中反复出现的问题的解决方案，有助于提高可重用性，可维护性，可理解性和健壮性（Gamma等，1994）。 因此，对设计模式具有依赖性的类较少受到结构更改（例如重构）的影响。 例如，命令设计模式接口通常只定义一种方法，通常是execute（），因此可以预期不会受到结构更改的影响。

设计模式并不总是能够提高系统质量，因此应谨慎使用。 在RQ3中，我们观察到与设计模式的静态关系不会影响故障倾向。 在RQ4中，我们观察到共变更依赖性对故障倾向性有影响。 我们还报告说，这些共同变更依赖性主要涉及“复合”和“观察者”设计模式。

表13报告了ArgoUML，JFreeChart和XercesJ的情况，即与Composite和Observer设计模式相关的类的故障的更常见类型是逻辑故障。 我们还观察到，对于与Decorator，Factory方法，Prototype和Command具有依赖关系的类，更常见的故障类型是语法错误。 对于其余的设计模式，我们发现依赖于故障的类主要与这些类的内部质量有关，例如无效的指令或错误的数据类型。

 

因此，我们对RQ5的回答如下：依赖于反模式类的类更容易受到逻辑故障和结构更改的影响。 依赖于设计模式类的类更容易受到代码添加和语法错误的影响。

Other Observations

根据这项研究的发现，对于具有静态关系或与LongMethod的依赖关系的类，不可能对故障和更改的类型进行分类。 有两个观察可以解释这个事实。 首先，我们观察到参与此反模式实例的班级数量很少。 其次，此反模式使用长方法并使用全局变量进行处理来表征类。 因此，具有与这种反模式实例的依赖性的类通常太少并且具有惰性类的结构，即，几乎没有理由改变。

4.6 Improvement in Fault Prediction Models

先前的研究（Zimmermann和Nagappan 2008； Hassan 2009）表明，大小，复杂性和历史指标是系统故障的良好预测指标。 因此，我们决定研究静态和/或共更改依赖性是否可以提供其他有用信息，以补充这些传统的故障预测指标。 我们的研究比较了两种用于预测类中是否存在故障的模型：（1）一种仅使用静态代码指标，以及（2）一种使用静态代码指标以及具有反模式或设计模式的依存关系。

首先，我们使用七个度量标准来使用支持向量机（SVM）建立故障预测模型。 有多种机器学习技术可用于构建此类模型。 我们之所以使用支持向量机，是因为该技术已在文献中得到广泛使用并显示出良好的效果（Ostrand等，2005； Moser等，2008）。

度量标准是：（1）每个类的代码行数； （2）一个类的方法调用次数； （3）一类方法中嵌套块的深度； （4）一个类中方法的参数个数； （5）一类中方法的McCabe圈复杂度； （六）一类领域的数目； （7）一个类的方法数量。 我们之所以选择这七个指标，是因为它们过去已成功用于预测故障（Nagappan和Ball，2005年）

其次，我们基于具有反模式和设计模式的类的静态和共更改相关性在以前的模型度量基础上进行了研究，以研究此类相关性是否可以改善故障预测。 指标由四个变量组成，这些变量必须采用整数值（0、1、2，...）。 第一个变量指示类与设计模式类之间的静态关系数。 第二个变量指示一个类和设计模式类之间的共更改依赖项的数量。 第三个变量指示类和反模式类之间的静态关系的数量。第四个变量指示类和反模式类之间的共更改依赖性的数量。 该模型输出一类具有一个或多个释放后故障的可能性。

我们使用基于似然比检验的显着性检验（Hosmer and Lemeshow 2000）（通常用于逻辑回归）来检验预测故障时两个模型的性能之间的差异（差异）。表14报告了使用反模式或设计模式相关性改进故障预测的情况。它表明具有不同反模式和设计模式的依赖项不能始终带来改进。如果考虑所有反模式和设计模式，则不可能绝对排除故障预测中没有统计上显着差异的可能性。但是，如果考虑特定的反模式，则可以发现使用静态和共更改依赖关系可以提高模型的精度。

实际上，我们观察到，对于LOC而言具有高复杂度的反模式（例如Blob和ComplexClass），添加静态关系分析可以提高模型的精度。类似地，当考虑具有大量方法调用的反模式（例如MessageChains和SwissArmyKnife）时，添加共更改关系分析可提高模型的精度。

表14：仅基于静态代码指标的模型与基于静态代码指标以及反模式和设计模式相关性的模型之间的故障预测差异

这些结果令人鼓舞，因为它们表明，即使仅使用静态代码指标构建的朴素模型，考虑到反模式依赖性也可以改善容易出错的类的预测。 因此，我们以这种保守而简单的调查得出结论，即关于故障通过静态和协变相关性传播的知识，对于改进类中故障的预测非常有用，应在以后的工作中进一步研究。

5 Discussion

现在我们讨论实证研究的结果。 对于每个研究问题，我们都会报告对我们发现的解释，并将其与相关工作进行比较。 最后，我们讨论了对我们研究有效性的威胁。

首先，我们通过表4和表5观察到，不同的反模式和设计模式与被分析系统中其他类别的静态关系的比例不同。 这些差异不足为奇，因为这些系统是在三个不相关的上下文中，在不同的过程中，由不同的开发人员开发的。 表4和表5突出了评估系统质量时分析和报告反模式和设计模式依赖性的重要性。

我们无法找到与本研究中分析的六个设计模式具有静态关系与故障倾向之间的相关性，这一事实不足为奇。 它证实了使用设计模式的主要好处是它们对软件质量的积极影响，例如可重用性，灵活性和可维护性（Gamma等，1994）。

5.1 Dependencies Between Anti-patterns and Design Patterns

现在，我们讨论对结果有效性的威胁（Yin 2002）。

Construct validity

威胁涉及理论与观察之间的关系。 在我们的上下文中，它们主要是由于测量中引入的误差。 我们知道，我们的研究中使用的检测方法包括对反模式和设计模式的定义的一些主观理解。 但是，我们有兴趣分析“在DECOR中定义的反模式”（Moha等人2010）和“在DeMIMA中定义的反模式”（Gueh´eneuc和Antoniol´2008）。 同样，我们用于识别宏观共同变更的方法可能错过了真实的共同变更并报告了错误的共同变更。

但是，反模式，设计模式和共同变更检测方法的精度和召回率值是我们同意接受的问题。 Moha等人（2010年）报告说，当的反模式DECOR检测算法可确保100％的查全率，在最坏的情况下，其精度会超过31％，平均精度会超过60％。Gueh´eneuc和Antoniol（ ´2008）报告说，DeMIMA可以以100％的召回率和34％以上的精度检测设计模式。 同时，为了检测类之间的关系船，DeMIMA通过关系定义保证了100％的召回率和精确度（Gueh´eneuc和Albin-Amiot´2004）。 采用Macocha进行宏观共同变更的方法可确保96％的召回率，并且其准确度大于85％（Jaafar等人，2011年）。 未来需要进行调查，以评估检测方法选择对我们结果的影响程度。

参与反模式实例（分别是设计模式实例）的类与参与其他反模式实例（或设计模式实例）的类可以具有依赖关系（静态关系和/或共更改依赖）。因此，本文报道的测试涵盖了与反模式实例（或设计模式实例）具有依赖性的类，无论这些类是否可能属于其他模式。然而，我们在第4节中给出了对参与反模式或设计模式的类以及其他类分别进行的依赖项影响分析的结果。如果被分析的类具有一个以上的模式/反模式的依赖项，则将通过分析来避免这种影响，以最小化交互作用的噪声。在这种情况下，Yamashita和Moonen（2013）报告说，这种相互作用会影响维护和代码质量。例如，他们揭示了位于同一工件中的气味如何相互影响，并影响了可维护性。

我们通过关联故障报告并提交给该类来计算类的故障倾向性。 故障修复记录在故障报告中，该报告描述了系统中不同类型的问题。 我们使用更改日志文件和故障报告中的ID /日期将故障/问题与更改进行匹配。 我们检查独立更改，这些更改被意外合并到同一提交中。 我们还手动研究了该代码，以确保提交消息中记录的错误修复与SVN / CVS日志文件中报告的类更改有关。

Internal validity

威胁涉及基于研究得出的因果结论的保证程度。首先，本文介绍的研究是一项探索性研究。因此，我们不要求因果关系（Yinn 2002），而是将反模式和设计模式依赖性的存在与变化和故障的发生联系起来。但是，我们试图通过查看特定的更改，提交说明和更改历史来进行解释，以解释其中的某些依赖性可能是导致更改/问题/故障的原因。我们还知道，一方面，反模式可以相互依赖，并且可以通过逻辑回归模型构建过程来选择不相关的反模式子集。另一方面，过错是一种暂时性，而参与反模式或设计模式则是相当长期的持久性。在先前的工作（Jaafar等人，2013a）中，我们分析了相同软件系统（ArgoUML，JFreeChar和XercesJ）中反模式和设计模式相关性的易变性，并得出结论，它们在这些系统的所有版本中仍然存在。因此，有时与类具有依赖关系的反模式没有错误，有时也有错误。在这项研究中，就像以前的工作（Khomh等人，2012年）一样，我们分析了更改和故障的倾向性，我们宣称如果一个类至少涉及一个解决故障的更改，那么它就是一个错误类。确实，我们考虑了在检测到结构/共更改相关性之后发生的更改和故障。例如，我们不能明确地宣称co更改是缺陷修复的结果或正在导致缺陷。但是我们报告了这些依赖关系的存在，以及下一次发生变化和故障的情况。

威胁涉及重复这项研究的可能性。 我们试图提供所有必要的细节来复制我们的研究。 此外，ArgoUML，JFreeChart和XercesJ的源代码存储库以及本研究中使用的反模式和设计检测方法都是可公开获得的。 第2节中详细描述了分析过程。本研究中使用的所有数据均可在线获得

6 Related Work（部分）

在过去的几年中，已经开发出不同的方法来解决检测设计模式，指定反模式以及研究其对变更和故障倾向的影响的问题。

6.1 Anti-patterns Definition and Detection（反模式定义与检测）

Webster（1995）于1995年撰写了有关面向对象开发中的“反模式”的第一本书。 在这本书中，作者报告说，反模式描述了一种经常使用的解决方案，该解决方案会产生无效或确定的负面后果。

我们与上述所有作者共享这样的想法，即反模式检测是一种评估代码质量的有趣方法，尤其是研究反模式的存在及其关系是否会使源代码更难以维护。

6.2 Design Pattern Definition and Detection

6.3 Anti-patterns and Design Patterns Static Relationships

6.4 Co-change Dependencies

这种模式模拟了以下事实：对一个工件的更改可能意味着对其他各种工件的大量更改。

6.5 Fault-proneness

 

7 Conclusion

我们的推测是，与反模式和设计模式类具有静态和共更改依赖性的类可能比其他类更频繁地参与更改和故障，因为更改和故障可能会从反模式和设计模式类传播到其他类通过它们的依赖关系。

我们进行了定量研究，回答了四个研究问题，并报告说：

– Classes having static or co-change dependencies with anti-pattern classes have significantly more faults than other classes.

–与设计模式类具有共同更改（co-change）依赖关系的类比其他类具有更多的错误，但与设计模式类具有静态关系的类则没有。

–与其他类型的类相比，具有反模式类的相关性的类更可能发生结构更改。

–与设计模式类具有依赖性的类比在类中更容易发生代码添加更改。

–特定类型的故障在某些反模式和设计模式中更为普遍：例如，Blob和Complex Class主要传播逻辑故障。

我们确认我们的猜想在本研究的背景下是有效的，因此，研究人员可以使用这些结果（1）改进故障预测模型，如我们在第5节中简要说明的（2）了解软件系统的发展，（3）检测可能影响具有这种依赖性的类的故障和变化的类型。开发人员可以使用这些结果来分配维护任务，并将测试工作重点放在与反模式和设计模式类具有依赖性的类上。

作为这项研究的局限性，我们使用了一组特殊但具有代表性的设计模式和反模式。不同的设计模式和反模式可能导致不同的结果。 此外，我们研究中使用的指标列表并不完整。因此，使用其他指标可能会产生不同的结果。但是，我们认为可以在任何模式和指标列表上测试相同的方法。因此，未来的工作包括（1）将我们的研究复制到其他系统上以评估其结果的一般性；（2）研究变更日志文件，邮件列表和发布报告，以寻找存在反抗之间的因果关系的证据。 模式或设计模式和问题，以及（3）分析系统不同版本之间此类依存关系的演变。