设计模式检测工具有效性评估策略*

肖卓宇，黄 海，何 锫，李 港，杨道武，彭逸凡，董泽民

1.中南林业科技大学 涉外学院，长沙 410200

2.广东第二师范学院 计算机科学系，广州 510303

3.北京大学 高可信软件技术教育部重点实验室，北京 100871

4.广州大学 计算机科学与教育软件学院，广州 510006

1 引言

设计模式常用于构建可复用的解决方案，而自动检测设计模式有助于研发人员在缺乏文档支撑的情况下提高软件质量[1]。目前在程序理解、维护、重构、逆向工程与再工程领域，设计模式检测工具的应用被广大研发人员所关注，但如何选择合适的检测工具成为困扰软件从业人员的一个难题[2-3]。

Bernardi等人[4]提出通过图形映射参与者，并以DSL匹配方法来检测设计模式。Fontana等人[5-6]将设计模式的特征信息以EDP（elemental design pattern）、Clues等微结构的形式表示，并通过这些微结构来识别设计模式。Zanoni[7]与Chihada[8]等人将机器学习引入到设计模式检测领域，二者皆侧重特征值的训练。许涵斌等人[9]提出通过查询与匹配UML模型中的特征信息来恢复设计模式。古辉等人[10]通过邻接表与联通分量缩小搜索空间来优化特征信息，进而识别设计模式。肖卓宇等人[11]结合形式概念分析与实例推理技术，通过余弦理论来优化设计模式检测结果。文献[12]提出一种基于矩阵积分评估的设计模式检测方法，旨在通过子图同构的方法来提升设计模式检测效果。Ampatzoglou等人[13-14]通过实验评估了部分主流检测工具的模式实例基准库。Petterson等人[15]提出设计模式变体、模式基准、测试用例选择及F-score指标等是影响设计模式精确率的主要因素。

综上所述，设计模式检测领域现有工作主要存在以下几个问题：（1）现有检测方法与工具较少考虑设计模式变体；（2）缺乏对设计模式参与者角色共享实例的关注；（3）大部分检测工具未公开，导致设计模式检测结果无法验证；（4）相似工具或低效工具重复开发；（5）待检测系统规模较小；（6）待检测系统设计模式实例基准缺乏或不够完善；（7）较少有文献对设计模式检测工具的有效性进行详细评估。

为此，本文给出一种评估设计模式检测工具有效性的解决方案，比较并筛选了检测工具与待检测系统，完善了经典开源系统设计模式实例基准数，侧重关注设计模式变体、实例共享等指标，对8种主流检测工具与9个开源系统进行了评估实验，并以此为依据，总结了影响设计模式检测结果精确性的有效性威胁，给出了合理性建议。

本文主要贡献如下：（1）按特征属性概述了现有主流设计模式检测工具；（2）为便于交叉比较，筛选并归纳了具有代表性的检测工具与待测试系统；（3）完善了主要开源系统的设计模式实例基准；（4）通过变体、实例共享等指标评估了现有工具；（5）总结了影响设计模式检测精确率的有效性威胁，给出了合理性建议，避免相似工具重复开发。

本文组织结构如下：第2章概述了现有设计模式检测工具；第3章选择评估实验所需的检测工具；第4章描述了待检测开源系统的特征；第5章依据指标进行评估实验；第6章总结了有效性威胁；第7章给出了合理化建议；第8章对全文工作进行了总结，并对未来工作进行了展望。

2 设计模式检测工具概述与分类

自1995年Gamma等人[1]首次提出23种经典的设计模式后，众多研发人员将其应用到MIS（management information system）系统中，并取得了较好的效果，但如何复用这些设计模式成为困扰研究人员的难题。设计模式检测工具有助于辅助软件设计师借鉴经典的设计框架，并以较低的成本、较好的效果完成软件项目设计，进而为软件项目重构奠定坚实的基础。

近20年来，众多研究人员在设计模式检测工具领域做出了贡献，并宣称取得了较好的检测效果，事实上，大部分工具检测结果的精确性与可靠性仍值得商榷。为此，本文收集了1996年至2015年以来近40种检测工具的相关信息，并分析与整理了具有代表性的22种工具[16-37]。表1描述了主流工具的相关参数，涉及工具名、作者、发布日期、支持语言、表示形式、分析方法、测试系统、精确率、召回率等信息。其中分析方法包括静态分析（static analysis，SA）、动态分析（dynamic analysis，DA）、语义分析（semantic analysis，SEA）。此外，由表1的编程语言字段可知，现有工具主要支持Java语言与C++语言，而分析表示形式字段发现众多工具的输入与输出形式几乎各不相同，这意味着较难实现工具间的兼容。综上所述，本文总结了导致设计模式检测工具差异的主要因素：（1）采用的检测技术与方法；（2）检测结果的评价指标；（3）待检测源码的输入与输出格式。由此可见，评估现有设计模式检测工具是一项重要的工作，有助于避免同类型工具的重复研发，降低成本。

设计模式检测工具按如下方法进行分类：

（1）基于相似度评分的设计模式检测工具

该类工具倾向于将设计模式类图转换为矩阵形式，通过图形理论计算设计模式矩阵与目标矩阵的归一化联系，能够较好地检测二者间完全匹配与完全不匹配的情形，通过阈值设定也能一定程度上检测存在结构差异的不完全匹配的情形，但对结构相似的Composite/Decorator模式、Strategy/State模式等识别效果不理想。该类工具以DPIDT[16]、DP-Miner[25]、DPD[28]等为典型代表，对结构型设计模式检测效果较好，而对行为型与创建型设计模式的检测效果略显不足，能一定程度上识别多层结构及设计模式实例共享问题，但难以识别设计模式变体。

（2）基于逻辑推理的设计模式检测工具

该类工具侧重逻辑演算的形式化和特征信息的谓词表示。基于逻辑推理的工具能一定程度上识别行为型与创建型设计模式，但识别精确率有待改进，易出现假阳性与假阴性结果，对设计模式变体问题几乎无法检测。此外，由于逻辑推理工具需依赖制定规则，导致该类工具不易于扩展。该类工具以FUJABA[34]、Pat[35]等为代表。

（3）基于机器学习的设计模式检测工具

该类工具有较好的学习能力，能够对特定的实例进行训练，从而获取特征信息，并通过积累达到较好的检测效果。相比基于逻辑推理与相似评分的工具，基于机器学习的工具能较好检测不完整的设计模式实例，即设计模式与目标实例的部分匹配。但该类检测工具需要通过人工形式进行调查分析，过度依赖专家经验。此外，还需对专家调查分析结果进行反馈，并对此不断进行训练，成本相对较高，且只对几种特定的设计模式检测效果较好，相比相似度评分工具，该类检测工具能够检测某类特定的设计模式变体与设计模式实例共享实例。该类工具以DeMIMA[22]、JAPADET[24]、MARPLE[26]等为代表。

3 设计模式检测工具选择

导致设计模式检测工具识别结果差异的原因是本文进行评估比较的动机。研究发现近似或精确匹配方法、算法，变体、实例共享、基准等是检测结果差异的主要因素。故选择合适的设计模式检测工具进行实验是有意义的，这有助于评估设计模式的检测效果，并为设计模式复用奠定坚实的基础。

Table 1 Overview of design pattern detection tools表1 设计模式检测工具概述

本文筛选表1中设计模式检测工具主要考虑到以下几点：（1）众多工具是否公开，未公开则不利于设计模式检测结果的验证；（2）检测工具待识别的测试系统规模是否偏小，即是否只存在少量的设计模式实例；（3）工具是否仅能检测个别设计模式，不具有多样性；（4）工具是否需要将源码通过第三方工具转换成中间表示形式，然后使用插件技术来实现设计模式的恢复；（5）因现有的检测工具主要支持Java与C++语言，为方便交叉比较，极少数支持Smalltalk、C等语言的工具暂不考虑。基于上述几点，本文最终选中的设计模式检测工具见表2。表2总结了检测工具的主要参数，如支持语言、平台、是否开源、是否可移植等信息。

4 测试系统选择

Pettersson等人[15]提出选择合适的测试系统将有助于获得精确有效且可信的设计模式检测结果。考虑到现有工具对源码支持的局限性，本文分别选择支持Java语言与C++语言的经典开源系统进行评估实验。表3描述了支持Java语言开源系统的相关参数，涉及网址、文件大小、LOC（line of code）、空格数等信息。相似的支持C++语言开源系统的相关参数见表4。选择待检测开源系统的依据如下：（1）测试系统支持Java或C++语言且使用频率较高；（2）测试系统常用于主流检测工具恢复实验，便于比较与其他检测工具的差异；（3）测试系统大小各异且存在多种设计模式，以便于检测结果的多样性比较；（4）先前工作已获得不同类型设计模式基准数的开源系统。

5 评估实验设计与分析

评估选用表2中的6种Java及2种C++设计模式检测工具，并分别对表3中的5种Java开源系统与表4中的4种C++开源系统进行实验。Pettersson等人[15]提出设计模式变体、实例共享、基准等是影响检测效率的重要因素。为此，本实验侧重关注标准设计模式数、设计模式变体数、设计模式实例共享数3个指标。3个实验环境CPU为IntelCorei7-6700，主频4.0 GHz；内存为DDR4 16 GB；操作系统选用Windows7。

Table 2 Features of experimental tools表2 检测工具特征表

Table 3 Open source system parameters based on Java表3 Java语言开源系统参数

Table 4 Open source system parameters based on C++表4 C++语言开源系统参数

5.1 评估设计模式实例

设计模式实例基准有助于研发人员对设计模式检测结果进行交叉比较，是评估设计模式检测工具优劣的重要指标。为此，评估各种检测工具的优缺点需以基准、检测结果的正确性等指标作为依据，但目前尚未有研究给出所有测试系统中设计模式实例的基准数及实例目录所在位置。一些较小的测试系统能以手工的形式进行检查，但对于较大的系统几乎无法实现，为此需要将先前成果的基准作为候选基准，通过进一步的实验来逐步完善，Pettersson等人[15]提出了这种思想，并定义为黄金标准。本文在同行学者先前研究成果基础上，结合各个开源系统的设计模式实例基准[4,13,15-16,23]，并辅助以手工的形式来完善基准。表5与表6分别给出了Java与C++开源系统通过不同检测工具评估的结果，加粗字体表示被检测开源系统中设计模式实例的基准数。

GOF[1]将设计模式分为结构型、行为型、创建型3类。表 5 中工具 DPD[28]、DeMIMA[22]、FT[18]检测开源系统QuickUML2001中结构型模式Adapter的结果依次为11、0、8，通过与Adapter的基准数10比较可知，不同工具检测结果存在较大差异。而对于开源系统ApacheAnt 1.6.2的行为型模式Command，工具DPD[28]、PINOT[27]、MARPLE[26]检测结果都为0，相对Command的基准10而言，这不是偶然的现象，因为这3种工具不具备动态分析机制。此外，对于开源系统ApacheAnt 1.6.2的创建型模式Prototype，工具DPD[28]、PINOT[27]、MARPLE[26]检测结果皆为0，由于创建型模式识别需涉及时序问题，也需涉及动态机制，故检测效果也不理想。此外，DPIDT[16]工具检测JHotDraw5.1系统的Adapter等模式时，其检测结果远大于基准数，如Adapter基准为19，其检测结果为35。为此，作者以手工的形式分析后发现，检测结果存在较多假阳性结果。

综上所述，检测工具对Adapter等结构型设计模式的识别效果相对较好，而对行为型与创建型模式的识别不够理想。究其原因发现，结构型模式使用继承等静态机制来组合类，而静态机制能够在编译时确定，故结构型模式相对容易被识别。行为型类模式使用继承描述算法和控制流，而行为型对象模式则描述一组对象怎样协作完成单个对象所无法完成的任务，二者都需涉及部分动态机制，故行为型模式识别难度高于结构型模式[1]。创建型类模式将对象的部分创建工作延迟到子类，而创建型对象模式则将它延迟到另一个对象中，这导致除静态与动态机制外，创建型模式还要涉及时序与语义机制，故识别难度较大[1]。

Table 5 Design pattern detection results of open source system based on Java表5 Java开源系统设计模式检测结果

Table 6 Design pattern detection results of open source system based on C++表6 C++开源系统设计模式检测结果

除检测Java语言开源系统，本文还针对Galb++(2.4)等C++语言开源系统进行检测。由表6可知，在检测Galb++(2.4)系统的Adapter模式时，不同工具存在较明显的差异，DPRE[36]与DPR[37]检测结果数分别为6与4，相似的检测Socket(1.10)系统的Bridge模式时，DPRE[36]与DPR[37]检测结果数分别为0与1。究其原因发现，不同检测方法对检测结果的影响起着重要作用。此外，不能单纯看到工具对某种设计模式检测结果的正确率为100%则认定该检测工具很优秀，如Socket(1.10)系统的Adapter模式，这些检测结果由于基准数较小，即使是100%的精确率也不具有代表性。事实上，当将其应用到遗产系统中仍可能出现较大的偏差。Libg++(2.7.2)系统的Bridge模式中DPRE[36]与DPR[37]检测结果数分别为1与3，DPR[37]取得结果多于基准数。为此，作者以人工的形式检查结果，发现存在2个假阳性结果。

此外，应关注到现有设计模式检测工具对于C++开源系统的检测存在局限性：（1）结合表1可见，现有设计模式检测工具对C++语言的支持程度不及Java语言；（2）待检测C++开源系统仅存在Adapter等5种设计模式，且数目较小，缺乏多样性；（3）待检测C++开源系统皆属于中小型系统，检测结果不具有代表性。

5.2 评估设计模式变体

设计模式变体易导致不精确的检测结果，而传统设计模式检测工具较难识别设计模式变体，为此，设计模式变体检测结果的精确率成为当前领域研究的热点，也是衡量检测工具是否优异的重要指标。

Gamma等人[1]提出了23种经典的设计模式，近20年来，研发人员应用这些设计模式到MIS系统中，并取得了较好的效果。但为了满足客户的个性化需求，现有的23种设计模式已经力不从心，因此，近些年来，研发人员在不改变设计意图的前提下对23种经典的设计模式进行了修改。Pettersson等人[15]对此给出了新的定义，即设计模式“变体”。变体的识别效果影响设计模式检测的精确率，也是目前领域内研究的难点。目前国内外对设计模式变体的研究尚处于理论阶段，较少有可借鉴的文献，为此，本文以人工的形式验证QuickUML2001等4个Java开源系统中Adapter等11个模式的变体基准。表7中加粗字体表示每个待检测系统的变体基准（variants benchmark，VBK）。

设计模式变体由标准GOF设计模式演化形成，其参与者角色或角色间联系发生了一定形式的改变，但设计意图未发生改变，故难以检测设计模式变体。由表7可见，检测工具对开源系统设计模式变体的识别效果不够理想，如QuickUML2001中Command模式基准为2，而工具DPD[28]、PINOT[27]、FT[18]识别的结果依次为0、0、1。表8描述了QuickUML2001中这2个Command模式目录位置，如第1个变体中扮演Command模式中Command角色的目录位置位于diagram.SelectionModel.java，而 扮 演 ConcreteCommand角色的目录位置位于diagram.AbstractSelection-Model.java，FT[18]能识别表8中的变体1。相似的是目前较少有工具支持C++语言开源系统，故在同行学者先前研究基础上[33,36-37]，再以手工的形式验证后给出表9中开源系统的变体基准。由表9中Galb++(2.4)系统的Adapter模式可知，DPRE[36]与DPR[37]变体检测结果分别为6与4，与其基准数9存在较大的偏差。相似的DPRE[36]与DPR[37]工具检测Libg++(2.7.2)系统的Decorator模式结果为12与12，与其基准21也存在较大偏差。究其原因发现Adapter与Decorator模式属于GOF[2]设计模式分类中的结构型模式，这类模式在不改变设计意图的前提下易于修改，并能解决客户的个性化需求。但目前众多设计模式检测工具开发者尚未关注到这个问题，以至于变体识别效果不理想。

5.3 评估设计模式实例共享

设计模式实例共享因为涉及参与者角色扮演多个设计模式角色的问题且类层次较复杂，故传统设计模式检测工具也较难识别设计模式共享实例。为此，设计模式共享实例检测结果的精确率也成为当前领域研究的难点，也是衡量检测工具是否优异的重要指标。本文分析现有工具检测结果发现，存在设计模式参与者同时扮演2个或多个设计模式角色的情况，即设计模式参与者角色共享设计模式，这类问题易导致结果误差。本文在同行学者研究基础上[4,15-16,23]，以手工形式进行验证，确定实例共享基准（sharing instance benchmark，SBK）。

Table 7 Design pattern variants detection results of open source system based on Java表7 Java开源系统变体检测结果

Table 8 Variant directory of command pattern表8command变体目录

分析表10发现，4种工具检测的结果与各自SBK基准数之间普遍存在差异，如JHotDraw5.1中Adapter与Command模式的共享实例基准是19与8，但通过工具DPD[28]发现共享实例的Adapter与Command模式分别为4与2。此外，深入研究后发现被检测出的4个Adapter模式中的2个与全部2个Command模式存在参与者角色共享设计模式的情况，详见表11。如CH.ifa.draw.Standard.CreationTool角色同时扮演了Adapter模式中的adapter角色及Command模式中的command角色，相似的CH.ifa.draw.Standard.Handle-Tracke角色也同时扮演了Adapter模式中的adaptee角色及Command模式中的concretecommand角色。研究发现State与Strategy模式等也存在较多参与者角色共享设计模式的问题。为此，本文深入研究后发现，共享实例的设计模式普遍存在结构相似的现象，后续工作中考虑将这些结构相似的设计模式作为整体进行识别。

此外，本文也对C++开源系统的设计模式实例共享问题进行了评估实验。由表12可见，设计模式参与者角色共享不同设计模式实例的情况也不容乐观，如Galb++(2.4)系统中Adapter的基准为5，工具DPRE[36]与DPR[37]的检测结果为2与1，成功率分别为40%与20%。而工具DPRE[36]与DPR[37]对于Libg++(2.7.2)系统中Decorator模式的识别结果分别6与4，精确率分别为60%与40%，通过手工验证发现了假阳性结果。其余设计模式检测结果数量的基数过小，存在偶然性，故其结果不具有代表性。

Table 9 Design pattern variants detection results of open source system based on C++表9 C++开源系统变体检测结果

Table 10 Shared design pattern instances in Java open source system表10 Java开源系统共享设计模式实例情况表

Table 11 Analysis of shared instances forAdapter/Command表11Adapter与Command共享实例分析

Table 12 Shared design pattern instances in C++open source system表12 C++开源系统共享设计模式实例情况表

6 有效性分析

近些年来研究人员围绕设计模式检测工具开展了大量的工作，并取得了一定的成果，但同样存在较多问题。为此，本文将设计模式检测工具缺点与影响恢复结果精确率的注意事项总结为以下方面：（1）现有的大部分工具在检测设计模式时选用不同系统作为实验对象，故缺乏用于比较的基准系统，不利于检测结果的比较；（2）检测工具仅适合特定的程序语言，如Java、C++等，不具备通用性；（3）大部分工具仅检测了部分结构型设计模式，而回避了检测难度较大的行为型及创建型模式；（4）大部分研究人员通过工具进行设计模式检测时仅提供最终的精确率与召回率结果，没有给出检测结果所在具体位置及扮演何种角色等重要信息，不便于其他学者验证；（5）大部分工具对设计模式变体缺乏关注；（6）检测结果存在大量的假阳性及假阴性结果；（7）设计模式参与者角色共享模式实例情况难以检测；（8）缺乏统一的输入输出形式，兼容性差，不利于结果的评估比较；（9）现有检测工具较少能从语义的角度对具有相似结构的设计模式进行区分；（10）现有工具大多固定检测几个例子，无法与其他方法的检测结果进行交叉验证；（11）部分检测工具需要通过第三方工具将源码转换成中间表示形式，而后再使用插件技术来实现设计模式的恢复，这将导致检测结果的精确率依赖于第三方工具的抽取能力。

7 建议

综上所述，给出以下建议：（1）检测工具应能够通过标准的中间表示形式与其他检测工具兼容；（2）检测工具应具有可扩展性与灵活性；（3）检测工具应该能够支持多种编程语言；（4）检测工具不能仅仅局限于开源系统的检测，遗产系统也需关注；（5）检测工具应该关注变体[38]及附加关系[39]导致的假阳性与假阴性结果；（6）对特征信息不易挖掘的情形，可依据专家经验进行调查，通过设计模式检测工具以半自动的形式识别[40]；（7）可考虑结合图论原理[41]与语义解决领域内动态分析、时序等难以检测的问题。

8 结束语

本文提出了一种评估设计模式检测工具的策略，筛选了主流检测工具及实验测试系统，完善了基准数据，侧重关注设计模式变体及实例共享等指标，并通过多种主流工具与开源系统进行评估实验，总结了影响检测结果精确率的有效性威胁，给出了合理性建议，有助于避免同类型设计模式检测工具的重复研发，节约成本。未来工作将致力于重要指标的研究及检测工具比较基准的完善，改进变体与模式实例共享检测的精确率，完善基准库的建设，并从多角度分类探讨更多设计模式检测工具的优缺点，为后续工具开发奠定坚实的基础。

[1]Gamma E,Helm R,Johnson R,et al.Design pattern:elements of reusable object-oriented software[M].Boston:Addison-Wesley Longman Publishing Co,Inc,1995:1-22.

[2]Xiao Zhuoyu,He Pei,Yu Bo,et al.An approach for design pattern detection based on the formal context-free grammar relation driver[J].Chinese Journal of Engineering,2016,38(10):1499-1508.

[3]Scanniello G,Gravino C,Risi M,et al.Documenting designpattern instances:a family of experiments on source-code comprehensibility[J].ACM Transactions on Software Engineering and Methodology,2015,24(3):1-35.

[4]Bernardi M L,Cimitile M,Di Lucca G.Design pattern detection using a DSL-driven graph matching approach[J].Journal of Software:Evolution and Process,2014,26(12):1233-1266.

[5]Fontana F A,Maggioni S,Raibulet C.Design patterns:a survey on their micro-structures[J].Journal of Software:Evolution and Process,2013,25(1):27-52.

[6]Fontana F A,Maggioni S,Raibulet C.Understanding the relevance of micro-structures for design patterns detection[J].Journal of Systems and Software,2011,84(12):2334-2347.

[7]Zanoni M,Fontana F A,Stella F.On applying machine learning techniques for design pattern detection[J].Journal of Systems and Software,2015,88(5):102-117.

[8]Chihada A,Jalili S,Hasheminejad S M H,et al.Source code and design conformance,design pattern detection from source code by classification approach[J].Applied Soft Computing,2015,26(1):357-367.

[9]Xu Hanbin,Zhang Xuelin,Zhen Xiaomei,et al.Method of software design patterns identification based on correlation and feature constraints[J].Computer Science,2014,41(11):50-55.

[10]Gu Hui,Zhang Weixing,Jin Peng,et al.Method of software design patterns identification based on correlation and feature constraints[J].Computer Science,2015,42(2):173-176.

[11]Xiao Zhuoyu,He Pei,Yu Bo,et al.Design patterns detection based on FCA and CBR[J].Journal of Shandong University:Engineering Science,2016,46(2):22-28.

[12]Xiao Zhuoyu,Li Yan,He Pei,et al.Research on matrix grade evaluation based on design pattern detection[J].Journal of Chinese Computer Systems,2016,37(7):1428-1433.

[13]Ampatzoglou A,Michou O,Stamelos I.Building and mining a repository of design pattern instances:practical and research benefits[J].Entertainment Computing,2013,4(2):131-142.

[14]Ampatzoglou A,Charalampidou S,Stamelos I.Research state of the art on GoF design patterns:a mapping study[J].Journal of Systems and Software,2013,86(7):1945-1964.

[15]Pettersson N,Löwe W,Nivre J.Evaluation of accuracy in design pattern occurrence detection[J].IEEE Transactions on Software Engineering,2010,36(4):575-590.

[16]Yu Dongjin,Zhang Yanyan,Chen Zhenli.A comprehensive approach to the recovery of design pattern instances based on sub-patterns and method signatures[J].Journal of Systems and Software,2015,103(C):1-16.

[17]Binun A,Kniesel G.DPJF-design pattern detection with high accuracy[C]//Proceedings of the 16th European Conference on Software Maintenance and Reengineering,Szeged,Mar 27-30,2012.Washington:IEEE Computer Society,2012:245-254.

[18]Rasool G,Mäder P.A customizable approach to design patterns recognition based on feature types[J].Arabian Journal for Science and Engineering,2014,39(12):8851-8873.

[19]Guéhéneuc Y G,Guyomarc'h J Y,Sahraoui H.Improving design-pattern identification:a new approach and an exploratory study[J].Software Quality Journal,2010,18(1):145-174.

[20]Alnusair A,Zhao Tian.Towards a model-driven approach for reverse engineering design patterns[C]//Proceedings of the 2nd International Workshop on Transforming and Weaving Ontologies in Model Driven Engineering，Denver,Oct 4-9,2009.Piscataway:IEEE,2009:531-545.

[21]Stencel K,Wegrzynowicz P.Detection of diverse design pattern variants[C]//Proceedings of the 15th Asia-Pacific Software Engineering Conference,Beijing,Dec 3-5,2008.Washington:IEEE Computer Society,2008:25-32.

[22]Guéhéneuc Y G,Antoniol G.DeMIMA:a multilayered approach for design pattern identification[J].IEEE Transactions on Software Engineering,2008,34(5):667-684.

[23]Sartipi K,Hu Lei.Behavior-driven design pattern recovery[C]//Proceedings of the 12th International Conference on Software Engineering and Applications,Orlando,Nov 16-18,2008:179-185.

[24]Arcelli F,Perin F,Raibulet C,et al.Behavioral design pattern detection through dynamic analysis,TUD-SERG-2008-036[R].2008:11-16.

[25]Dong Jing,Lad D S,Zhao Yajing.DP-Miner:design pattern discovery using matrix[C]//Proceedings of the 14th Annual IEEE International Conference and Workshops on the Engineering of Computer-Based Systems,Tucson,Mar 6-29,2007.Washington:IEEE Computer Society,2007:371-380.

[26]Arcelli F,Christina L.Enhancing software evolution through design pattern detection[C]//Proceedings of the 3rd International IEEE Workshop on Software Evolvability,Paris,Oct 1,2007.Piscataway:IEEE,2007:7-14.

[27]Shi N,Olsson R A.Reverse engineering of design patterns from Java source code[C]//Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering,Tokyo,Sep 18-22,2006.Washington:IEEE Computer Society,2006:123-134.

[28]Tsantalis N,Chatzigeorgiou A,Stephanides G,et al.Design pattern detection using similarity scoring[J].IEEE Transactions on Software Engineering,2006,32(11):896-909.

[29]Ferenc R,Beszédes A,Fülöp L,et al.Design pattern mining enhanced by machine learning[C]//Proceedings of the 21st IEEE International Conference on Software Maintenance,Budapest,Sep 25-30,2005.Washington:IEEE Computer Society,2005:295-304.

[30]Philippow I,Streitferdt D,Riebisch M,et al.An approach for reverse engineering of design patterns[J].Software&Systems Modeling,2005,4(1):55-70.

[31]Wang Wei,Tzerpos V.Design pattern detection in Eiffel systems[C]//Proceedings of the 12th Working Conference on Reverse Engineering,Pittsburgh,Nov 7-11,2005.Washington:IEEE Computer Society,2005:165-174.

[32]Kirasić D,Basch D.Ontology-based design pattern recognition[C]//LNCS 5177:Proceedings of the 12th International Conference on Knowledge-Based Intelligent Information and Engineering Systems,Zagreb,Sep 3-5,2008.Berlin,Heidelberg:Springer,2008:384-393.

[33]Smith J M,Stotts D.SPQR:flexible automated design pattern extraction from source code[C]//Proceedings of the 18th IEEE International Conference on Automated Software Engineering,Montreal,Oct 6-10,2003.Washington:IEEE Computer Society,2003:215-224.

[34]Niere J,Schäfer W,Wadsack J P,et al.Towards patternbased design recovery[C]//Proceedings of the 24th International Conference on Software Engineering,Orlando,May 19-25,2002.New York:ACM,2002:338-348.

[35]Kramer C,Prechelt L.Design recovery by automated search for structural design patterns in object-oriented software[C]//Proceedings of the 20th Working Conference on Reverse Engineering,Monterey,Nov 8-10,1996.Washington:IEEE Computer Society,1996:208-215.

[36]Costagliola G,De Lucia A,Deufemia V,et al.Case studies of visual language based design patterns recovery[C]//Proceedings of the 10th European Conference on Software Maintenance and Reengineering,Mar 22-24,2006.Washington:IEEE Computer Society,2006:165-174.

[37]Antoniol G,Casazza G,Di Penta M,et al.Object-oriented design patterns recovery[J].Journal of Systems and Software,2001,59(2):181-196.

[38]Xiao Zhuoyu,He Pei,Yang Xinwei,et al.An optimization method for design pattern identification based on the grammar production[J].Journal of University of Electronic Science and Technology of China,2017,46(3):569-576.

[39]Xiao Zhuoyu,He Pei,Li Yan.Study on the additional relationships based on design pattens's roles[J].Application Research of Computers,2015,32(7):2042-2045.

[40]Xiao Zhuoyu,He Pei,Yu Bo.A multi-stage approach based on interactive clues driven for design pattern identification[J].Journal of Beijing University of Aeronautics and Astronautics,2017,43(9):1746-1756.

[41]Mayvan B B,Rasoolzadegan A.Design pattern detection based on the graph theory[J].Knowledge-Based Systems,2017,120:211-225.

附中文参考文献：

[2]肖卓宇,何锫,余波,等.一种形式化上下无关文法关系驱动的设计模式检测方法[J].工程科学学报,2016,38(10):1499-1508.

[9]许涵斌,张学林,郑晓梅,等.一种基于结构查询的UML设计模式识别方法[J].计算机科学,2014,41(11):50-55.

[10]古辉,张炜星,金鹏,等.基于关联度和特征约束的软件设计模式识别方法[J].计算机科学,2015,42(2):173-176.

[11]肖卓宇,何锫,余波,等.基于FCA与CBR的设计模式检测[J].山东大学学报:工学版,2016,46(2):22-28.

[12]肖卓宇,黎妍,何锫,等.基于矩阵积分评估的设计模式检测研究[J].小型微型计算机系统,2016,37(7):1428-1433.

[38]肖卓宇,何锫,杨鑫维,等.基于文法产生式优化的设计模式识别方法[J].电子科技大学学报,2017,46(3):569-576.

[39]肖卓宇,何锫,黎妍.基于设计模式角色的附加关系检测研究[J].计算机应用研究,2015,32(7):2042-2045.

[40]肖卓宇,何锫,余波.一种多阶段交互式线索驱动的设计模式识别方法[J].北京航空航天大学学报,2017,43(9):1746-1756.