肖卓宇，黃 海，何 锫，李 港，楊道武，彭逸凡，董澤民

1.中南林業(yè)科技大學 涉外學院，長沙 410200

2.廣東第二師范學院 計算機科學系，廣州 510303

3.北京大學 高可信軟件技術(shù)教育部重點實驗室，北京 100871

4.廣州大學 計算機科學與教育軟件學院，廣州 510006

1 引言

設計模式常用于構(gòu)建可復用的解決方案，而自動檢測設計模式有助于研發(fā)人員在缺乏文檔支撐的情況下提高軟件質(zhì)量[1]。目前在程序理解、維護、重構(gòu)、逆向工程與再工程領(lǐng)域，設計模式檢測工具的應用被廣大研發(fā)人員所關(guān)注，但如何選擇合適的檢測工具成為困擾軟件從業(yè)人員的一個難題[2-3]。

Bernardi等人[4]提出通過圖形映射參與者，并以DSL匹配方法來檢測設計模式。Fontana等人[5-6]將設計模式的特征信息以EDP（elemental design pattern）、Clues等微結(jié)構(gòu)的形式表示，并通過這些微結(jié)構(gòu)來識別設計模式。Zanoni[7]與Chihada[8]等人將機器學習引入到設計模式檢測領(lǐng)域，二者皆側(cè)重特征值的訓練。許涵斌等人[9]提出通過查詢與匹配UML模型中的特征信息來恢復設計模式。古輝等人[10]通過鄰接表與聯(lián)通分量縮小搜索空間來優(yōu)化特征信息，進而識別設計模式。肖卓宇等人[11]結(jié)合形式概念分析與實例推理技術(shù)，通過余弦理論來優(yōu)化設計模式檢測結(jié)果。文獻[12]提出一種基于矩陣積分評估的設計模式檢測方法，旨在通過子圖同構(gòu)的方法來提升設計模式檢測效果。Ampatzoglou等人[13-14]通過實驗評估了部分主流檢測工具的模式實例基準庫。Petterson等人[15]提出設計模式變體、模式基準、測試用例選擇及F-score指標等是影響設計模式精確率的主要因素。

綜上所述，設計模式檢測領(lǐng)域現(xiàn)有工作主要存在以下幾個問題：（1）現(xiàn)有檢測方法與工具較少考慮設計模式變體；（2）缺乏對設計模式參與者角色共享實例的關(guān)注；（3）大部分檢測工具未公開，導致設計模式檢測結(jié)果無法驗證；（4）相似工具或低效工具重復開發(fā)；（5）待檢測系統(tǒng)規(guī)模較??；（6）待檢測系統(tǒng)設計模式實例基準缺乏或不夠完善；（7）較少有文獻對設計模式檢測工具的有效性進行詳細評估。

為此，本文給出一種評估設計模式檢測工具有效性的解決方案，比較并篩選了檢測工具與待檢測系統(tǒng)，完善了經(jīng)典開源系統(tǒng)設計模式實例基準數(shù)，側(cè)重關(guān)注設計模式變體、實例共享等指標，對8種主流檢測工具與9個開源系統(tǒng)進行了評估實驗，并以此為依據(jù)，總結(jié)了影響設計模式檢測結(jié)果精確性的有效性威脅，給出了合理性建議。

本文主要貢獻如下：（1）按特征屬性概述了現(xiàn)有主流設計模式檢測工具；（2）為便于交叉比較，篩選并歸納了具有代表性的檢測工具與待測試系統(tǒng)；（3）完善了主要開源系統(tǒng)的設計模式實例基準；（4）通過變體、實例共享等指標評估了現(xiàn)有工具；（5）總結(jié)了影響設計模式檢測精確率的有效性威脅，給出了合理性建議，避免相似工具重復開發(fā)。

本文組織結(jié)構(gòu)如下：第2章概述了現(xiàn)有設計模式檢測工具；第3章選擇評估實驗所需的檢測工具；第4章描述了待檢測開源系統(tǒng)的特征；第5章依據(jù)指標進行評估實驗；第6章總結(jié)了有效性威脅；第7章給出了合理化建議；第8章對全文工作進行了總結(jié)，并對未來工作進行了展望。

2 設計模式檢測工具概述與分類

自1995年Gamma等人[1]首次提出23種經(jīng)典的設計模式后，眾多研發(fā)人員將其應用到MIS（management information system）系統(tǒng)中，并取得了較好的效果，但如何復用這些設計模式成為困擾研究人員的難題。設計模式檢測工具有助于輔助軟件設計師借鑒經(jīng)典的設計框架，并以較低的成本、較好的效果完成軟件項目設計，進而為軟件項目重構(gòu)奠定堅實的基礎。

近20年來，眾多研究人員在設計模式檢測工具領(lǐng)域做出了貢獻，并宣稱取得了較好的檢測效果，事實上，大部分工具檢測結(jié)果的精確性與可靠性仍值得商榷。為此，本文收集了1996年至2015年以來近40種檢測工具的相關(guān)信息，并分析與整理了具有代表性的22種工具[16-37]。表1描述了主流工具的相關(guān)參數(shù)，涉及工具名、作者、發(fā)布日期、支持語言、表示形式、分析方法、測試系統(tǒng)、精確率、召回率等信息。其中分析方法包括靜態(tài)分析（static analysis，SA）、動態(tài)分析（dynamic analysis，DA）、語義分析（semantic analysis，SEA）。此外，由表1的編程語言字段可知，現(xiàn)有工具主要支持Java語言與C++語言，而分析表示形式字段發(fā)現(xiàn)眾多工具的輸入與輸出形式幾乎各不相同，這意味著較難實現(xiàn)工具間的兼容。綜上所述，本文總結(jié)了導致設計模式檢測工具差異的主要因素：（1）采用的檢測技術(shù)與方法；（2）檢測結(jié)果的評價指標；（3）待檢測源碼的輸入與輸出格式。由此可見，評估現(xiàn)有設計模式檢測工具是一項重要的工作，有助于避免同類型工具的重復研發(fā)，降低成本。

設計模式檢測工具按如下方法進行分類：

（1）基于相似度評分的設計模式檢測工具

該類工具傾向于將設計模式類圖轉(zhuǎn)換為矩陣形式，通過圖形理論計算設計模式矩陣與目標矩陣的歸一化聯(lián)系，能夠較好地檢測二者間完全匹配與完全不匹配的情形，通過閾值設定也能一定程度上檢測存在結(jié)構(gòu)差異的不完全匹配的情形，但對結(jié)構(gòu)相似的Composite/Decorator模式、Strategy/State模式等識別效果不理想。該類工具以DPIDT[16]、DP-Miner[25]、DPD[28]等為典型代表，對結(jié)構(gòu)型設計模式檢測效果較好，而對行為型與創(chuàng)建型設計模式的檢測效果略顯不足，能一定程度上識別多層結(jié)構(gòu)及設計模式實例共享問題，但難以識別設計模式變體。

（2）基于邏輯推理的設計模式檢測工具

該類工具側(cè)重邏輯演算的形式化和特征信息的謂詞表示?；谶壿嬐评淼墓ぞ吣芤欢ǔ潭壬献R別行為型與創(chuàng)建型設計模式，但識別精確率有待改進，易出現(xiàn)假陽性與假陰性結(jié)果，對設計模式變體問題幾乎無法檢測。此外，由于邏輯推理工具需依賴制定規(guī)則，導致該類工具不易于擴展。該類工具以FUJABA[34]、Pat[35]等為代表。

（3）基于機器學習的設計模式檢測工具

該類工具有較好的學習能力，能夠?qū)μ囟ǖ膶嵗M行訓練，從而獲取特征信息，并通過積累達到較好的檢測效果。相比基于邏輯推理與相似評分的工具，基于機器學習的工具能較好檢測不完整的設計模式實例，即設計模式與目標實例的部分匹配。但該類檢測工具需要通過人工形式進行調(diào)查分析，過度依賴專家經(jīng)驗。此外，還需對專家調(diào)查分析結(jié)果進行反饋，并對此不斷進行訓練，成本相對較高，且只對幾種特定的設計模式檢測效果較好，相比相似度評分工具，該類檢測工具能夠檢測某類特定的設計模式變體與設計模式實例共享實例。該類工具以DeMIMA[22]、JAPADET[24]、MARPLE[26]等為代表。

3 設計模式檢測工具選擇

導致設計模式檢測工具識別結(jié)果差異的原因是本文進行評估比較的動機。研究發(fā)現(xiàn)近似或精確匹配方法、算法，變體、實例共享、基準等是檢測結(jié)果差異的主要因素。故選擇合適的設計模式檢測工具進行實驗是有意義的，這有助于評估設計模式的檢測效果，并為設計模式復用奠定堅實的基礎。

Table 1 Overview of design pattern detection tools表1 設計模式檢測工具概述

本文篩選表1中設計模式檢測工具主要考慮到以下幾點：（1）眾多工具是否公開，未公開則不利于設計模式檢測結(jié)果的驗證；（2）檢測工具待識別的測試系統(tǒng)規(guī)模是否偏小，即是否只存在少量的設計模式實例；（3）工具是否僅能檢測個別設計模式，不具有多樣性；（4）工具是否需要將源碼通過第三方工具轉(zhuǎn)換成中間表示形式，然后使用插件技術(shù)來實現(xiàn)設計模式的恢復；（5）因現(xiàn)有的檢測工具主要支持Java與C++語言，為方便交叉比較，極少數(shù)支持Smalltalk、C等語言的工具暫不考慮?；谏鲜鰩c，本文最終選中的設計模式檢測工具見表2。表2總結(jié)了檢測工具的主要參數(shù)，如支持語言、平臺、是否開源、是否可移植等信息。

4 測試系統(tǒng)選擇

Pettersson等人[15]提出選擇合適的測試系統(tǒng)將有助于獲得精確有效且可信的設計模式檢測結(jié)果。考慮到現(xiàn)有工具對源碼支持的局限性，本文分別選擇支持Java語言與C++語言的經(jīng)典開源系統(tǒng)進行評估實驗。表3描述了支持Java語言開源系統(tǒng)的相關(guān)參數(shù)，涉及網(wǎng)址、文件大小、LOC（line of code）、空格數(shù)等信息。相似的支持C++語言開源系統(tǒng)的相關(guān)參數(shù)見表4。選擇待檢測開源系統(tǒng)的依據(jù)如下：（1）測試系統(tǒng)支持Java或C++語言且使用頻率較高；（2）測試系統(tǒng)常用于主流檢測工具恢復實驗，便于比較與其他檢測工具的差異；（3）測試系統(tǒng)大小各異且存在多種設計模式，以便于檢測結(jié)果的多樣性比較；（4）先前工作已獲得不同類型設計模式基準數(shù)的開源系統(tǒng)。

5 評估實驗設計與分析

評估選用表2中的6種Java及2種C++設計模式檢測工具，并分別對表3中的5種Java開源系統(tǒng)與表4中的4種C++開源系統(tǒng)進行實驗。Pettersson等人[15]提出設計模式變體、實例共享、基準等是影響檢測效率的重要因素。為此，本實驗側(cè)重關(guān)注標準設計模式數(shù)、設計模式變體數(shù)、設計模式實例共享數(shù)3個指標。3個實驗環(huán)境CPU為IntelCorei7-6700，主頻4.0 GHz；內(nèi)存為DDR4 16 GB；操作系統(tǒng)選用Windows7。

Table 2 Features of experimental tools表2 檢測工具特征表

Table 3 Open source system parameters based on Java表3 Java語言開源系統(tǒng)參數(shù)

Table 4 Open source system parameters based on C++表4 C++語言開源系統(tǒng)參數(shù)

5.1 評估設計模式實例

設計模式實例基準有助于研發(fā)人員對設計模式檢測結(jié)果進行交叉比較，是評估設計模式檢測工具優(yōu)劣的重要指標。為此，評估各種檢測工具的優(yōu)缺點需以基準、檢測結(jié)果的正確性等指標作為依據(jù)，但目前尚未有研究給出所有測試系統(tǒng)中設計模式實例的基準數(shù)及實例目錄所在位置。一些較小的測試系統(tǒng)能以手工的形式進行檢查，但對于較大的系統(tǒng)幾乎無法實現(xiàn)，為此需要將先前成果的基準作為候選基準，通過進一步的實驗來逐步完善，Pettersson等人[15]提出了這種思想，并定義為黃金標準。本文在同行學者先前研究成果基礎上，結(jié)合各個開源系統(tǒng)的設計模式實例基準[4,13,15-16,23]，并輔助以手工的形式來完善基準。表5與表6分別給出了Java與C++開源系統(tǒng)通過不同檢測工具評估的結(jié)果，加粗字體表示被檢測開源系統(tǒng)中設計模式實例的基準數(shù)。

GOF[1]將設計模式分為結(jié)構(gòu)型、行為型、創(chuàng)建型3類。表 5 中工具 DPD[28]、DeMIMA[22]、FT[18]檢測開源系統(tǒng)QuickUML2001中結(jié)構(gòu)型模式Adapter的結(jié)果依次為11、0、8，通過與Adapter的基準數(shù)10比較可知，不同工具檢測結(jié)果存在較大差異。而對于開源系統(tǒng)ApacheAnt 1.6.2的行為型模式Command，工具DPD[28]、PINOT[27]、MARPLE[26]檢測結(jié)果都為0，相對Command的基準10而言，這不是偶然的現(xiàn)象，因為這3種工具不具備動態(tài)分析機制。此外，對于開源系統(tǒng)ApacheAnt 1.6.2的創(chuàng)建型模式Prototype，工具DPD[28]、PINOT[27]、MARPLE[26]檢測結(jié)果皆為0，由于創(chuàng)建型模式識別需涉及時序問題，也需涉及動態(tài)機制，故檢測效果也不理想。此外，DPIDT[16]工具檢測JHotDraw5.1系統(tǒng)的Adapter等模式時，其檢測結(jié)果遠大于基準數(shù)，如Adapter基準為19，其檢測結(jié)果為35。為此，作者以手工的形式分析后發(fā)現(xiàn)，檢測結(jié)果存在較多假陽性結(jié)果。

綜上所述，檢測工具對Adapter等結(jié)構(gòu)型設計模式的識別效果相對較好，而對行為型與創(chuàng)建型模式的識別不夠理想。究其原因發(fā)現(xiàn)，結(jié)構(gòu)型模式使用繼承等靜態(tài)機制來組合類，而靜態(tài)機制能夠在編譯時確定，故結(jié)構(gòu)型模式相對容易被識別。行為型類模式使用繼承描述算法和控制流，而行為型對象模式則描述一組對象怎樣協(xié)作完成單個對象所無法完成的任務，二者都需涉及部分動態(tài)機制，故行為型模式識別難度高于結(jié)構(gòu)型模式[1]。創(chuàng)建型類模式將對象的部分創(chuàng)建工作延遲到子類，而創(chuàng)建型對象模式則將它延遲到另一個對象中，這導致除靜態(tài)與動態(tài)機制外，創(chuàng)建型模式還要涉及時序與語義機制，故識別難度較大[1]。

Table 5 Design pattern detection results of open source system based on Java表5 Java開源系統(tǒng)設計模式檢測結(jié)果

Table 6 Design pattern detection results of open source system based on C++表6 C++開源系統(tǒng)設計模式檢測結(jié)果

除檢測Java語言開源系統(tǒng)，本文還針對Galb++(2.4)等C++語言開源系統(tǒng)進行檢測。由表6可知，在檢測Galb++(2.4)系統(tǒng)的Adapter模式時，不同工具存在較明顯的差異，DPRE[36]與DPR[37]檢測結(jié)果數(shù)分別為6與4，相似的檢測Socket(1.10)系統(tǒng)的Bridge模式時，DPRE[36]與DPR[37]檢測結(jié)果數(shù)分別為0與1。究其原因發(fā)現(xiàn)，不同檢測方法對檢測結(jié)果的影響起著重要作用。此外，不能單純看到工具對某種設計模式檢測結(jié)果的正確率為100%則認定該檢測工具很優(yōu)秀，如Socket(1.10)系統(tǒng)的Adapter模式，這些檢測結(jié)果由于基準數(shù)較小，即使是100%的精確率也不具有代表性。事實上，當將其應用到遺產(chǎn)系統(tǒng)中仍可能出現(xiàn)較大的偏差。Libg++(2.7.2)系統(tǒng)的Bridge模式中DPRE[36]與DPR[37]檢測結(jié)果數(shù)分別為1與3，DPR[37]取得結(jié)果多于基準數(shù)。為此，作者以人工的形式檢查結(jié)果，發(fā)現(xiàn)存在2個假陽性結(jié)果。

此外，應關(guān)注到現(xiàn)有設計模式檢測工具對于C++開源系統(tǒng)的檢測存在局限性：（1）結(jié)合表1可見，現(xiàn)有設計模式檢測工具對C++語言的支持程度不及Java語言；（2）待檢測C++開源系統(tǒng)僅存在Adapter等5種設計模式，且數(shù)目較小，缺乏多樣性；（3）待檢測C++開源系統(tǒng)皆屬于中小型系統(tǒng)，檢測結(jié)果不具有代表性。

5.2 評估設計模式變體

設計模式變體易導致不精確的檢測結(jié)果，而傳統(tǒng)設計模式檢測工具較難識別設計模式變體，為此，設計模式變體檢測結(jié)果的精確率成為當前領(lǐng)域研究的熱點，也是衡量檢測工具是否優(yōu)異的重要指標。

Gamma等人[1]提出了23種經(jīng)典的設計模式，近20年來，研發(fā)人員應用這些設計模式到MIS系統(tǒng)中，并取得了較好的效果。但為了滿足客戶的個性化需求，現(xiàn)有的23種設計模式已經(jīng)力不從心，因此，近些年來，研發(fā)人員在不改變設計意圖的前提下對23種經(jīng)典的設計模式進行了修改。Pettersson等人[15]對此給出了新的定義，即設計模式“變體”。變體的識別效果影響設計模式檢測的精確率，也是目前領(lǐng)域內(nèi)研究的難點。目前國內(nèi)外對設計模式變體的研究尚處于理論階段，較少有可借鑒的文獻，為此，本文以人工的形式驗證QuickUML2001等4個Java開源系統(tǒng)中Adapter等11個模式的變體基準。表7中加粗字體表示每個待檢測系統(tǒng)的變體基準（variants benchmark，VBK）。

設計模式變體由標準GOF設計模式演化形成，其參與者角色或角色間聯(lián)系發(fā)生了一定形式的改變，但設計意圖未發(fā)生改變，故難以檢測設計模式變體。由表7可見，檢測工具對開源系統(tǒng)設計模式變體的識別效果不夠理想，如QuickUML2001中Command模式基準為2，而工具DPD[28]、PINOT[27]、FT[18]識別的結(jié)果依次為0、0、1。表8描述了QuickUML2001中這2個Command模式目錄位置，如第1個變體中扮演Command模式中Command角色的目錄位置位于diagram.SelectionModel.java，而 扮 演 ConcreteCommand角色的目錄位置位于diagram.AbstractSelection-Model.java，F(xiàn)T[18]能識別表8中的變體1。相似的是目前較少有工具支持C++語言開源系統(tǒng)，故在同行學者先前研究基礎上[33,36-37]，再以手工的形式驗證后給出表9中開源系統(tǒng)的變體基準。由表9中Galb++(2.4)系統(tǒng)的Adapter模式可知，DPRE[36]與DPR[37]變體檢測結(jié)果分別為6與4，與其基準數(shù)9存在較大的偏差。相似的DPRE[36]與DPR[37]工具檢測Libg++(2.7.2)系統(tǒng)的Decorator模式結(jié)果為12與12，與其基準21也存在較大偏差。究其原因發(fā)現(xiàn)Adapter與Decorator模式屬于GOF[2]設計模式分類中的結(jié)構(gòu)型模式，這類模式在不改變設計意圖的前提下易于修改，并能解決客戶的個性化需求。但目前眾多設計模式檢測工具開發(fā)者尚未關(guān)注到這個問題，以至于變體識別效果不理想。

5.3 評估設計模式實例共享

設計模式實例共享因為涉及參與者角色扮演多個設計模式角色的問題且類層次較復雜，故傳統(tǒng)設計模式檢測工具也較難識別設計模式共享實例。為此，設計模式共享實例檢測結(jié)果的精確率也成為當前領(lǐng)域研究的難點，也是衡量檢測工具是否優(yōu)異的重要指標。本文分析現(xiàn)有工具檢測結(jié)果發(fā)現(xiàn)，存在設計模式參與者同時扮演2個或多個設計模式角色的情況，即設計模式參與者角色共享設計模式，這類問題易導致結(jié)果誤差。本文在同行學者研究基礎上[4,15-16,23]，以手工形式進行驗證，確定實例共享基準（sharing instance benchmark，SBK）。

Table 7 Design pattern variants detection results of open source system based on Java表7 Java開源系統(tǒng)變體檢測結(jié)果

Table 8 Variant directory of command pattern表8command變體目錄

分析表10發(fā)現(xiàn)，4種工具檢測的結(jié)果與各自SBK基準數(shù)之間普遍存在差異，如JHotDraw5.1中Adapter與Command模式的共享實例基準是19與8，但通過工具DPD[28]發(fā)現(xiàn)共享實例的Adapter與Command模式分別為4與2。此外，深入研究后發(fā)現(xiàn)被檢測出的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角色。研究發(fā)現(xiàn)State與Strategy模式等也存在較多參與者角色共享設計模式的問題。為此，本文深入研究后發(fā)現(xiàn)，共享實例的設計模式普遍存在結(jié)構(gòu)相似的現(xiàn)象，后續(xù)工作中考慮將這些結(jié)構(gòu)相似的設計模式作為整體進行識別。

此外，本文也對C++開源系統(tǒng)的設計模式實例共享問題進行了評估實驗。由表12可見，設計模式參與者角色共享不同設計模式實例的情況也不容樂觀，如Galb++(2.4)系統(tǒng)中Adapter的基準為5，工具DPRE[36]與DPR[37]的檢測結(jié)果為2與1，成功率分別為40%與20%。而工具DPRE[36]與DPR[37]對于Libg++(2.7.2)系統(tǒng)中Decorator模式的識別結(jié)果分別6與4，精確率分別為60%與40%，通過手工驗證發(fā)現(xiàn)了假陽性結(jié)果。其余設計模式檢測結(jié)果數(shù)量的基數(shù)過小，存在偶然性，故其結(jié)果不具有代表性。

Table 9 Design pattern variants detection results of open source system based on C++表9 C++開源系統(tǒng)變體檢測結(jié)果

Table 10 Shared design pattern instances in Java open source system表10 Java開源系統(tǒng)共享設計模式實例情況表

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

Table 12 Shared design pattern instances in C++open source system表12 C++開源系統(tǒng)共享設計模式實例情況表

6 有效性分析

近些年來研究人員圍繞設計模式檢測工具開展了大量的工作，并取得了一定的成果，但同樣存在較多問題。為此，本文將設計模式檢測工具缺點與影響恢復結(jié)果精確率的注意事項總結(jié)為以下方面：（1）現(xiàn)有的大部分工具在檢測設計模式時選用不同系統(tǒng)作為實驗對象，故缺乏用于比較的基準系統(tǒng)，不利于檢測結(jié)果的比較；（2）檢測工具僅適合特定的程序語言，如Java、C++等，不具備通用性；（3）大部分工具僅檢測了部分結(jié)構(gòu)型設計模式，而回避了檢測難度較大的行為型及創(chuàng)建型模式；（4）大部分研究人員通過工具進行設計模式檢測時僅提供最終的精確率與召回率結(jié)果，沒有給出檢測結(jié)果所在具體位置及扮演何種角色等重要信息，不便于其他學者驗證；（5）大部分工具對設計模式變體缺乏關(guān)注；（6）檢測結(jié)果存在大量的假陽性及假陰性結(jié)果；（7）設計模式參與者角色共享模式實例情況難以檢測；（8）缺乏統(tǒng)一的輸入輸出形式，兼容性差，不利于結(jié)果的評估比較；（9）現(xiàn)有檢測工具較少能從語義的角度對具有相似結(jié)構(gòu)的設計模式進行區(qū)分；（10）現(xiàn)有工具大多固定檢測幾個例子，無法與其他方法的檢測結(jié)果進行交叉驗證；（11）部分檢測工具需要通過第三方工具將源碼轉(zhuǎn)換成中間表示形式，而后再使用插件技術(shù)來實現(xiàn)設計模式的恢復，這將導致檢測結(jié)果的精確率依賴于第三方工具的抽取能力。

7 建議

綜上所述，給出以下建議：（1）檢測工具應能夠通過標準的中間表示形式與其他檢測工具兼容；（2）檢測工具應具有可擴展性與靈活性；（3）檢測工具應該能夠支持多種編程語言；（4）檢測工具不能僅僅局限于開源系統(tǒng)的檢測，遺產(chǎn)系統(tǒng)也需關(guān)注；（5）檢測工具應該關(guān)注變體[38]及附加關(guān)系[39]導致的假陽性與假陰性結(jié)果；（6）對特征信息不易挖掘的情形，可依據(jù)專家經(jīng)驗進行調(diào)查，通過設計模式檢測工具以半自動的形式識別[40]；（7）可考慮結(jié)合圖論原理[41]與語義解決領(lǐng)域內(nèi)動態(tài)分析、時序等難以檢測的問題。

8 結(jié)束語

本文提出了一種評估設計模式檢測工具的策略，篩選了主流檢測工具及實驗測試系統(tǒng)，完善了基準數(shù)據(jù)，側(cè)重關(guān)注設計模式變體及實例共享等指標，并通過多種主流工具與開源系統(tǒng)進行評估實驗，總結(jié)了影響檢測結(jié)果精確率的有效性威脅，給出了合理性建議，有助于避免同類型設計模式檢測工具的重復研發(fā)，節(jié)約成本。未來工作將致力于重要指標的研究及檢測工具比較基準的完善，改進變體與模式實例共享檢測的精確率，完善基準庫的建設，并從多角度分類探討更多設計模式檢測工具的優(yōu)缺點，為后續(xù)工具開發(fā)奠定堅實的基礎。

[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]肖卓宇,何锫,余波,等.一種形式化上下無關(guān)文法關(guān)系驅(qū)動的設計模式檢測方法[J].工程科學學報,2016,38(10):1499-1508.

[9]許涵斌,張學林,鄭曉梅,等.一種基于結(jié)構(gòu)查詢的UML設計模式識別方法[J].計算機科學,2014,41(11):50-55.

[10]古輝,張煒星,金鵬,等.基于關(guān)聯(lián)度和特征約束的軟件設計模式識別方法[J].計算機科學,2015,42(2):173-176.

[11]肖卓宇,何锫,余波,等.基于FCA與CBR的設計模式檢測[J].山東大學學報:工學版,2016,46(2):22-28.

[12]肖卓宇,黎妍,何锫,等.基于矩陣積分評估的設計模式檢測研究[J].小型微型計算機系統(tǒng),2016,37(7):1428-1433.

[38]肖卓宇,何锫,楊鑫維,等.基于文法產(chǎn)生式優(yōu)化的設計模式識別方法[J].電子科技大學學報,2017,46(3):569-576.

[39]肖卓宇,何锫,黎妍.基于設計模式角色的附加關(guān)系檢測研究[J].計算機應用研究,2015,32(7):2042-2045.

[40]肖卓宇,何锫,余波.一種多階段交互式線索驅(qū)動的設計模式識別方法[J].北京航空航天大學學報,2017,43(9):1746-1756.