一、靜態檢測技術

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)檢測工具的效果難以進行評估和對比。反模式的檢測結果受組織機構的特點、人員經驗及所熟悉的技術類型等的影響，可能產生不一致的檢測結果。而且系統中真正存在的反模式數目是未知的，因此難以對檢測方法的有效性做出評價。（本文圖略）

本文作者：盛津芳 胡培培 王斌 單位：中南大學 信息科學與工程學院