劉宏韜 劉 偉,2 胡志剛

1(中南大學(xué)軟件學(xué)院 湖南 長(zhǎng)沙 410075)2(湖南中醫(yī)藥大學(xué)管理與信息工程學(xué)院 湖南 長(zhǎng)沙 410208)

基于抽象語法樹的數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)研究

劉宏韜1劉 偉1,2胡志剛1

1(中南大學(xué)軟件學(xué)院 湖南 長(zhǎng)沙 410075)2(湖南中醫(yī)藥大學(xué)管理與信息工程學(xué)院 湖南 長(zhǎng)沙 410208)

數(shù)據(jù)泥團(tuán)是一種常見的代碼味道，它將帶來重復(fù)代碼和維護(hù)難度增加等問題。針對(duì)大部分已有的代碼味道自動(dòng)檢測(cè)工具無法檢測(cè)數(shù)據(jù)泥團(tuán)，且檢測(cè)類型不全面等問題，提出一種基于抽象語法樹的數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)方法。該方法在已有檢測(cè)工具的基礎(chǔ)上，增加了新的數(shù)據(jù)泥團(tuán)類型，并加入了剔除冗余數(shù)據(jù)泥團(tuán)和提取子數(shù)據(jù)泥團(tuán)等步驟。通過對(duì)4個(gè)開源項(xiàng)目進(jìn)行數(shù)據(jù)泥團(tuán)實(shí)驗(yàn)，結(jié)果表明方法具有較高的精確率，與Stench Blossom、inFusion等工具的數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)功能相比，能夠檢測(cè)出一些其他工具無法檢測(cè)的數(shù)據(jù)泥團(tuán)。同時(shí)，該方法具有較好的性能，執(zhí)行時(shí)間與系統(tǒng)規(guī)模成正比。

代碼味道 數(shù)據(jù)泥團(tuán) 抽象語法樹 源代碼解析 重構(gòu)

0 引 言

代碼味道是指源代碼中存在的一些不良實(shí)現(xiàn)方案。軟件工程大師Martin Fowler和Kent Beck在文獻(xiàn)[1]中初次使用“代碼味道”一詞來描述這些不良實(shí)現(xiàn)方案，文獻(xiàn)中定義了22種常見的代碼味道，包括數(shù)據(jù)泥團(tuán)、重復(fù)代碼、霰彈式修改等。此后，一些新的代碼味道[2]被學(xué)者和研究人員陸續(xù)提出。檢測(cè)、去除代碼味道對(duì)于提高代碼質(zhì)量具有非常重要的意義[3]，去除代碼味道能夠改善代碼的可維護(hù)性，因此應(yīng)當(dāng)對(duì)程序代碼中的代碼味道進(jìn)行檢測(cè)和合理重構(gòu)，在不改變程序外部行為的前提下改善代碼的質(zhì)量。

開發(fā)人員往往在對(duì)代碼味道進(jìn)行重構(gòu)之前，人工審查代碼、檢測(cè)代碼味道，這樣的方式效率低下，且正確率不高。近年來，自動(dòng)檢測(cè)代碼味道已成為軟件工程領(lǐng)域的一個(gè)研究熱點(diǎn)。Liu等人[4-5]對(duì)泛化重構(gòu)機(jī)會(huì)檢測(cè)進(jìn)行了研究，并基于概念關(guān)系、實(shí)現(xiàn)相似性等開發(fā)了一款重構(gòu)時(shí)機(jī)檢測(cè)工具。Maneerat等人[6]提出了從軟件設(shè)計(jì)模型的角度檢測(cè)代碼味道，將7種機(jī)器學(xué)習(xí)的算法運(yùn)用于數(shù)項(xiàng)代碼味道數(shù)據(jù)集，并根據(jù)27個(gè)度量指標(biāo)檢測(cè)7種代碼味道，并對(duì)各種機(jī)器學(xué)習(xí)算法在代碼優(yōu)化方面的性能進(jìn)行了評(píng)估。此外，針對(duì)檢測(cè)代碼味道這一問題也誕生了一些自動(dòng)化工具。PMD[7]可以檢查源代碼中存在的過大類、重復(fù)代碼等代碼味道，它允許用戶自定義檢測(cè)這些代碼味道的閾值；CheckStyle[8]能夠探測(cè)代碼大小是否違規(guī)、類的設(shè)計(jì)是否良好，也能找出過長(zhǎng)函數(shù)、過長(zhǎng)參數(shù)列等代碼味道。

本文將以源代碼中數(shù)據(jù)泥團(tuán)代碼味道為研究對(duì)象，提出了一種精確率及性能俱佳的數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)算法，有助于軟件開發(fā)人員快速精準(zhǔn)地發(fā)現(xiàn)項(xiàng)目中存在的數(shù)據(jù)泥團(tuán)代碼味道，為進(jìn)一步的數(shù)據(jù)泥團(tuán)重構(gòu)提供有力支持。

1 數(shù)據(jù)泥團(tuán)和抽象語法樹

1.1 數(shù)據(jù)泥團(tuán)

數(shù)據(jù)泥團(tuán)[1]是22種常見代碼味道之一，它指代那些經(jīng)常捆綁出現(xiàn)的數(shù)據(jù)，如多個(gè)類中出現(xiàn)了相同的數(shù)個(gè)屬性，或多個(gè)方法中出現(xiàn)了相同的數(shù)個(gè)參數(shù)。對(duì)于類屬性數(shù)據(jù)泥團(tuán)，應(yīng)當(dāng)使用提煉類,將數(shù)據(jù)提煉到一個(gè)獨(dú)立對(duì)象；對(duì)于方法參數(shù)數(shù)據(jù)泥團(tuán)，應(yīng)當(dāng)使用引入?yún)?shù)對(duì)象。數(shù)據(jù)泥團(tuán)的存在將增加系統(tǒng)的耦合度，自動(dòng)檢測(cè)并重構(gòu)數(shù)據(jù)泥團(tuán)，對(duì)數(shù)據(jù)實(shí)施集中式管理，可以提高代碼的可維護(hù)性和可復(fù)用性，進(jìn)而增強(qiáng)系統(tǒng)內(nèi)聚性，降低耦合度，并提高代碼的可讀性、可擴(kuò)展性等。Fontana等人[9]對(duì)現(xiàn)有的代碼味道自動(dòng)檢測(cè)工作進(jìn)行研究，發(fā)現(xiàn)對(duì)于數(shù)據(jù)泥團(tuán)這一代碼味道，目前僅有inFusion[10]和Stench Blossom[11]兩款工具能作出自動(dòng)檢測(cè)。

1.2 抽象語法樹

數(shù)據(jù)泥團(tuán)的檢測(cè)工作基于對(duì)抽象語法樹AST(Abstract Syntax Tree)的分析，將指定項(xiàng)目源代碼轉(zhuǎn)換成抽象語法樹之后，再收集數(shù)據(jù)泥團(tuán)檢測(cè)的相關(guān)信息。抽象語法樹是一種常用的程序代碼的中間表示形式。

本文使用Java語言為例，Eclipse JDT提供了Eclipse AST[12]用于將Java源代碼解析為抽象語法樹，并能對(duì)其進(jìn)行節(jié)點(diǎn)的創(chuàng)建、修改。Eclipse AST中ASTNode類作為所有Java語法結(jié)構(gòu)節(jié)點(diǎn)的父類，它的子類如TypeDeclaration(類聲明)、MethodDeclaration(方法聲明)等都對(duì)相應(yīng)的語法結(jié)構(gòu)進(jìn)行了明確地描述，并提供了大量的方法用于訪問該節(jié)點(diǎn)的屬性，如類名、方法參數(shù)列表等。此外，還提供了一個(gè)ASTVisitor類用于定義AST的抽象訪問者，在該類中聲明了一組訪問各類AST節(jié)點(diǎn)的方法，用于對(duì)各種類型的節(jié)點(diǎn)實(shí)施相應(yīng)的操作。

2 數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)算法

考慮到檢測(cè)數(shù)據(jù)泥團(tuán)后的重構(gòu)流程，本文所檢測(cè)的單個(gè)數(shù)據(jù)泥團(tuán)將包含兩部分：

(1) 數(shù)據(jù)集 (Datum) 單個(gè)數(shù)據(jù)泥團(tuán)所包含的數(shù)據(jù)。

(2) 位置集 (Location) 該數(shù)據(jù)泥團(tuán)出現(xiàn)的位置。

本文主要針對(duì)數(shù)據(jù)類型、名稱(部分包括初始值)完全相同的情況，數(shù)據(jù)泥團(tuán)中的數(shù)據(jù)將以如表1格式的字符串進(jìn)行存儲(chǔ)。

表1 數(shù)據(jù)字符串格式

數(shù)據(jù)集來自對(duì)類屬性和方法參數(shù)的收集、計(jì)算和篩選，其中篩選主要依據(jù)以下兩項(xiàng)度量指標(biāo)：

(1) 重復(fù)度 (Repeat) 數(shù)據(jù)泥團(tuán)出現(xiàn)的次數(shù)。

(2) 規(guī)模 (Size) 數(shù)據(jù)泥團(tuán)的大小。

考慮到使用者檢測(cè)數(shù)據(jù)泥團(tuán)需求的不同，數(shù)據(jù)泥團(tuán)的重復(fù)度下限(minRepeat)和規(guī)模下限(minSize)兩項(xiàng)閾值將作為參數(shù)傳入，若一候選數(shù)據(jù)泥團(tuán)重復(fù)度和規(guī)模均不小于重復(fù)度下限和規(guī)模下限(即Repeat≥minRepeat & Size≥minSize)，則將其判定為一個(gè)數(shù)據(jù)泥團(tuán)，使用者可以根據(jù)需求自定義重復(fù)度和規(guī)模閾值以查找所需的數(shù)據(jù)泥團(tuán)。

圖1 數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)流程圖

數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)流程如圖1所示，其中步驟解釋如下：

(1) 將源代碼解析為AST。

(2) 收集數(shù)據(jù)信息 遍歷AST中每一個(gè)類節(jié)點(diǎn)(TypeDeclaration)、匿名類節(jié)點(diǎn)(AnonymousClassDeclaration)和方法節(jié)點(diǎn)(MethodDeclaration)，對(duì)符合規(guī)模下限的類屬性和方法參數(shù)進(jìn)行整理，得到數(shù)據(jù)信息列表。數(shù)據(jù)信息包含數(shù)據(jù)集和位置兩部分，數(shù)據(jù)集即所對(duì)應(yīng)的類屬性或方法參數(shù)以表1中的字符串格式存儲(chǔ)的字符串集合，位置即所對(duì)應(yīng)的類或方法所在的位置。

(3) 構(gòu)建候選數(shù)據(jù)泥團(tuán)集 對(duì)數(shù)據(jù)信息列表中的每?jī)蓚€(gè)數(shù)據(jù)信息p和q進(jìn)行集合運(yùn)算，將符合規(guī)模下限的結(jié)果存儲(chǔ)為數(shù)據(jù)泥團(tuán)A，得到候選數(shù)據(jù)泥團(tuán)集。其中A.datum = p.datum ∩ q.datum。之后需對(duì)候選數(shù)據(jù)泥團(tuán)集按照數(shù)據(jù)集的規(guī)模，從大到小排序，以確保規(guī)模較大的數(shù)據(jù)泥團(tuán)優(yōu)先被檢測(cè)。

(4) 合并重復(fù)數(shù)據(jù)泥團(tuán) 對(duì)于候選數(shù)據(jù)泥團(tuán)集中的每?jī)蓚€(gè)候選數(shù)據(jù)泥團(tuán)A和B，如果A和B兩者數(shù)據(jù)集相同，則將B的位置集合并到A的位置集中，并從候選數(shù)據(jù)泥團(tuán)集中刪除B。

(5) 剔除冗余數(shù)據(jù)泥團(tuán) 假設(shè)候選數(shù)據(jù)泥團(tuán)集中存在{a, b}和{b, c}，它們都存在于方法func(a, b, c)，若將{a, b}確定為數(shù)據(jù)泥團(tuán)并封裝為數(shù)據(jù)類A，則原參數(shù)列表將被修改為func(A, c)，參數(shù)列表中將不再存在數(shù)據(jù)泥團(tuán){b, c}，因此需要從候選數(shù)據(jù)泥團(tuán)中刪除{b, c}。

(6) 提取子數(shù)據(jù)泥團(tuán) 假設(shè)重復(fù)度閾值為2，func(a, b, c)中存在的數(shù)據(jù)泥團(tuán){a, b}被封裝成數(shù)據(jù)類A，原參數(shù)列表將被修改為func(A, c)，若{A, c}仍為滿足閾值要求的數(shù)據(jù)泥團(tuán)并被封裝為類B，則需將{a, b}作為{A, c}的子數(shù)據(jù)泥團(tuán)，即在重構(gòu)時(shí)B繼承A，且原參數(shù)列表修改為func(B)。

(7) 篩選數(shù)據(jù)泥團(tuán) 根據(jù)輸入的規(guī)模下限和重復(fù)度下限對(duì)候選數(shù)據(jù)泥團(tuán)集進(jìn)行篩選，以得到最終數(shù)據(jù)泥團(tuán)檢測(cè)結(jié)果。

數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)算法偽代碼如表2所示。

表2 自動(dòng)檢測(cè)算法偽代碼

該算法根據(jù)所處理內(nèi)容的不同，可劃分為兩個(gè)部分進(jìn)行時(shí)間復(fù)雜度的分析。第一部分為數(shù)據(jù)信息的收集，該部分主要將代碼源文件轉(zhuǎn)換到抽象語法樹并進(jìn)行遍歷進(jìn)而收集數(shù)據(jù)信息，因此不難得知數(shù)據(jù)信息收集過程的時(shí)間復(fù)雜度為O(n)，n為源代碼文件的數(shù)量，即理論上運(yùn)行時(shí)間隨著源代碼文件數(shù)量的增加而線性增加。第二部分為數(shù)據(jù)泥團(tuán)的檢測(cè)，該部分主要針對(duì)第一部分中所收集的數(shù)據(jù)信息進(jìn)行集合運(yùn)算等一系列的處理，根據(jù)算法分析可知時(shí)間復(fù)雜度基本為O(n2)，n為第一部分中所收集的數(shù)據(jù)信息的數(shù)量，即理論上運(yùn)行時(shí)間與數(shù)據(jù)信息數(shù)的平方成正比。

3 實(shí)驗(yàn)結(jié)果分析

本文算法已嵌入到前期研究工作所開發(fā)的一款Eclipse插件SCORT[13]中。為了測(cè)試數(shù)據(jù)泥團(tuán)的自動(dòng)檢測(cè)效果，本文選取了同樣具有數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)功能的工具inFusion和Stench Blossom與SCORT進(jìn)行比較，三款工具檢測(cè)效果如表3所示。

表3 數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)工具對(duì)比

由檢測(cè)效果可知：Stench Blossom[14]作為Eclipse插件，其檢測(cè)結(jié)果實(shí)時(shí)呈現(xiàn)在編輯器中，效率較慢，且只能針對(duì)當(dāng)前編譯單元(即當(dāng)前打開的文件)進(jìn)行檢測(cè)，檢測(cè)效果一般；inFusion作為一款定期升級(jí)的商業(yè)軟件，檢測(cè)效果較好，且能針對(duì)整個(gè)工程進(jìn)行檢測(cè)，與SCORT檢測(cè)效果相近，SCORT所檢測(cè)的數(shù)據(jù)泥團(tuán)類型更為全面。為了驗(yàn)證本文所述數(shù)據(jù)泥團(tuán)的自動(dòng)檢測(cè)算法的執(zhí)行效率和正確性，本文選取四個(gè)開源項(xiàng)目進(jìn)行實(shí)驗(yàn)，并為了與檢測(cè)效果相近的inFusion工具對(duì)比，因此使用與inFusion相同的閾值(即minRepeat=3、minSize=5)。本文選取了四個(gè)開源Java 項(xiàng)目，這四個(gè)項(xiàng)目規(guī)模和類型不一，基本信息如表4所示。

表4 待測(cè)項(xiàng)目基本信息

3.1 數(shù)據(jù)泥團(tuán)檢測(cè)算法執(zhí)行效率實(shí)驗(yàn)

實(shí)驗(yàn)首先使用SCORT工具對(duì)四個(gè)項(xiàng)目進(jìn)行數(shù)據(jù)泥團(tuán)的檢測(cè)，并對(duì)算法執(zhí)行時(shí)間進(jìn)行分析。對(duì)于每一個(gè)項(xiàng)目，數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)算法均執(zhí)行5次，然后分別計(jì)算算法兩個(gè)部分的平均時(shí)間。數(shù)據(jù)泥團(tuán)檢測(cè)實(shí)驗(yàn)在一臺(tái)安裝Windows 7操作系統(tǒng)的PC機(jī)上進(jìn)行，其配置為：雙核2.00 GHz，2 GB DDR2 RAM。數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)算法包括數(shù)據(jù)信息的收集和數(shù)據(jù)泥團(tuán)的檢測(cè)兩個(gè)部分，表4中四個(gè)待測(cè)項(xiàng)目的數(shù)據(jù)信息收集平均時(shí)間如表5所示。

表5 數(shù)據(jù)信息收集平均時(shí)間

由表5可知，隨著系統(tǒng)規(guī)模的增大(源文件數(shù)量的增加)，數(shù)據(jù)信息收集的平均執(zhí)行時(shí)間也逐步增加，以源代碼文件數(shù)為X軸，數(shù)據(jù)信息收集程序的執(zhí)行時(shí)間為Y軸，可得圖2所示源文件數(shù)-數(shù)據(jù)信息收集執(zhí)行時(shí)間圖。

圖2 源文件數(shù)-數(shù)據(jù)信息收集執(zhí)行時(shí)間圖

圖2中虛線為對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行擬合的線性趨勢(shì)線，擬合方程為y=6.3957x+574.97，R2=0.9996。在數(shù)據(jù)信息收集部分，主要是將項(xiàng)目中的所有源文件轉(zhuǎn)換為抽象語法樹，并在抽象語法樹中根據(jù)條件收集數(shù)據(jù)信息，因此該部分執(zhí)行時(shí)間與源文件數(shù)量關(guān)系密切。因此從圖2中可以看到，執(zhí)行時(shí)間與系統(tǒng)規(guī)模(源文件數(shù)量)成正比，隨系統(tǒng)規(guī)模的增大執(zhí)行時(shí)間增加，整體呈現(xiàn)線性關(guān)系，算法具有良好的性能。

考慮到數(shù)據(jù)泥團(tuán)的檢測(cè)部分算法執(zhí)行速度較快，因此該部分實(shí)驗(yàn)將時(shí)間精確到納秒進(jìn)行統(tǒng)計(jì)，并在表4中四個(gè)項(xiàng)目的基礎(chǔ)上追加六個(gè)開源項(xiàng)目，總共十個(gè)開源項(xiàng)目的數(shù)據(jù)泥團(tuán)檢測(cè)部分執(zhí)行時(shí)間如表6所示。

表6 數(shù)據(jù)泥團(tuán)檢測(cè)平均時(shí)間

由表6可知，隨著算法第一部分所收集的數(shù)據(jù)信息的數(shù)量增加，數(shù)據(jù)泥團(tuán)檢測(cè)的平均執(zhí)行時(shí)間也逐步增加，以數(shù)據(jù)信息數(shù)為X軸，數(shù)據(jù)泥團(tuán)檢測(cè)程序的執(zhí)行時(shí)間為Y軸，可得圖3所示數(shù)據(jù)信息數(shù)-數(shù)據(jù)泥團(tuán)檢測(cè)執(zhí)行時(shí)間圖。

圖3 數(shù)據(jù)信息數(shù)-數(shù)據(jù)泥團(tuán)檢測(cè)執(zhí)行時(shí)間圖

圖3中虛線為對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行擬合的線性趨勢(shì)線，擬合方程為y=263.87x2+218990x+6E+06，R2=0.9719。在數(shù)據(jù)泥團(tuán)檢測(cè)部分，主要是對(duì)前段算法所收集的數(shù)據(jù)信息進(jìn)行集合運(yùn)算，因此執(zhí)行時(shí)間與該項(xiàng)目所收集的數(shù)據(jù)信息關(guān)系密切。從圖3中的趨勢(shì)線可以看到，執(zhí)行時(shí)間與數(shù)據(jù)信息數(shù)的平方成正比?？傮w看來，本文中的數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)算法執(zhí)行效率與系統(tǒng)規(guī)模成正比，執(zhí)行時(shí)間隨著系統(tǒng)規(guī)模的增加而增加，算法具有較好的執(zhí)行效率。

3.2 數(shù)據(jù)泥團(tuán)檢測(cè)算法性能實(shí)驗(yàn)

為了更好地評(píng)價(jià)數(shù)據(jù)泥團(tuán)檢測(cè)結(jié)果，本文使用精確率(Precision)和召回率(Recall)來分析算法的性能，并結(jié)合人工審查判斷檢測(cè)結(jié)果是否正確，精確率和召回率分別表示為：

Precision=TP/(TP+FP)

(1)

Recall=TP/(TP+FN)

(2)

其中，真陽性TP(True Positive)表示工具檢測(cè)到的正確數(shù)據(jù)泥團(tuán)數(shù)量；假陽性FP(False Positive)表示工具檢測(cè)到的錯(cuò)誤數(shù)據(jù)泥團(tuán)數(shù)量，即人工審查后發(fā)現(xiàn)檢測(cè)出的數(shù)據(jù)泥團(tuán)是錯(cuò)誤的；假陰性FN(False Negative)表示工具沒有檢測(cè)到，但人工審查后發(fā)現(xiàn)應(yīng)當(dāng)作為數(shù)據(jù)泥團(tuán)檢測(cè)的數(shù)量。通過對(duì)檢測(cè)出的數(shù)據(jù)泥團(tuán)進(jìn)行逐個(gè)審查可以得到TP和FP值。

而對(duì)于FN值，由于人工查找正確的數(shù)據(jù)泥團(tuán)難度較大，因此，實(shí)驗(yàn)將既有成熟的代碼檢測(cè)工具inFusion檢測(cè)結(jié)果視為人工查找到的正確的數(shù)據(jù)泥團(tuán)。SCORT和inFusion對(duì)表4中四個(gè)項(xiàng)目的數(shù)據(jù)泥團(tuán)檢測(cè)結(jié)果如表7所示。

表7 SCORT與inFusion的數(shù)據(jù)泥團(tuán)檢測(cè)結(jié)果

根據(jù)表7得到TP、FP和FN值，并計(jì)算出相應(yīng)的精確率和召回率，結(jié)果如表8所示。

表8 數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)精確率與召回率

對(duì)于SCORT和inFusion兩款工具檢測(cè)結(jié)果的差異，以及召回率進(jìn)行分析。表7中，兩款工具對(duì)于項(xiàng)目TinyUML的檢測(cè)結(jié)果相同；在項(xiàng)目Ice Hockey Manager的檢測(cè)結(jié)果中，SCORT檢測(cè)到了2個(gè)類屬性數(shù)據(jù)泥團(tuán)，而inFusion由于沒有該項(xiàng)功能，因此沒有檢測(cè)結(jié)果；項(xiàng)目Abbot的檢測(cè)結(jié)果中，SCORT檢測(cè)到7個(gè)數(shù)據(jù)泥團(tuán)，剔除了4個(gè)inFusion結(jié)果中存在的冗余數(shù)據(jù)泥團(tuán)，另外檢測(cè)出3個(gè)來自于重寫方法的數(shù)據(jù)泥團(tuán)，這些方法所在的類存在于同一繼承樹；項(xiàng)目Robocode的檢測(cè)結(jié)果中，SCORT檢測(cè)到13個(gè)數(shù)據(jù)泥團(tuán)，剔除了3個(gè)inFusion結(jié)果中存在的冗余數(shù)據(jù)泥團(tuán)，另外檢測(cè)出1個(gè)來自于重寫方法的數(shù)據(jù)泥團(tuán)，以及1個(gè)類屬性數(shù)據(jù)泥團(tuán)。

經(jīng)分析發(fā)現(xiàn)，檢測(cè)結(jié)果存在差異的主要原因?yàn)镾CORT與inFusion工具所使用的算法的目的和對(duì)“數(shù)據(jù)泥團(tuán)”概念的認(rèn)識(shí)不一。inFusion工具目的在于度量和評(píng)估軟件的質(zhì)量，且它所檢測(cè)的數(shù)據(jù)泥團(tuán)僅為方法參數(shù)；SCORT目的在于檢測(cè)重構(gòu)時(shí)機(jī)，便于日后的重構(gòu)工作，因此將冗余數(shù)據(jù)泥團(tuán)情況進(jìn)行處理，并且SCORT所檢測(cè)的數(shù)據(jù)泥團(tuán)包括了方法參數(shù)和類成員屬性。對(duì)于來自同一繼承樹的類成員屬性，以及來自重寫方法的參數(shù)，本文都認(rèn)為是需重構(gòu)的數(shù)據(jù)泥團(tuán)。SCORT相較于inFusion所檢測(cè)的數(shù)據(jù)泥團(tuán)類型更為全面，更符合數(shù)據(jù)泥團(tuán)的定義。

4 結(jié) 語

代碼味道的自動(dòng)探測(cè)與優(yōu)化對(duì)于提高軟件質(zhì)量具有重要意義，但針對(duì)“數(shù)據(jù)泥團(tuán)”這一代碼味道的檢測(cè)算法和工具較少。本文研究了一套基于抽象語法樹的數(shù)據(jù)泥團(tuán)自動(dòng)檢測(cè)算法，該算法在以往研究成果的基礎(chǔ)上增加了檢測(cè)類成員屬性所組成的數(shù)據(jù)泥團(tuán)，并提出剔除冗余數(shù)據(jù)泥團(tuán)、提取子數(shù)據(jù)泥團(tuán)，為日后的自動(dòng)重構(gòu)工作做好鋪墊。

通過對(duì)4個(gè)開源項(xiàng)目進(jìn)行數(shù)據(jù)泥團(tuán)檢測(cè)實(shí)驗(yàn)，結(jié)果表明，該方法精確率非常高，能夠正確檢測(cè)出源代碼中所有的數(shù)據(jù)泥團(tuán)，實(shí)驗(yàn)項(xiàng)目的數(shù)據(jù)泥團(tuán)檢測(cè)精確率可達(dá)100%，并消除了所有的假陽性實(shí)例，與已有方法相比，其結(jié)果更全面；算法執(zhí)行效率較高，執(zhí)行時(shí)間與系統(tǒng)規(guī)模成正比，適用于各種規(guī)模的系統(tǒng)。

本文算法將類成員屬性與方法參數(shù)分開處理，且以字符串形式完全匹配而進(jìn)行數(shù)據(jù)泥團(tuán)的檢測(cè)，但在實(shí)際軟件開發(fā)過程中有著同時(shí)存在于屬性和參數(shù)的數(shù)據(jù)泥團(tuán)，或變量名并不完全相同的數(shù)據(jù)泥團(tuán)，在后續(xù)工作中，將逐步改進(jìn)上述問題。此外，還將實(shí)現(xiàn)對(duì)數(shù)據(jù)泥團(tuán)的自動(dòng)重構(gòu)，例如將其自動(dòng)封裝為數(shù)據(jù)類。

[1] Fowler M. Refactoring: improving the design of existing code[M]. Massachusetts: Addison-Wesley, 1999.

[2] Kerievsky J. Refactoring to patterns[M]. Massachusetts: Addison-Wesley, 2004.

[3] Emden E V, Moonen L. Java quality assurance by detecting code smells[C]//Proceedings of the Ninth Working Conference on Reverse Engineering (WCRE' 02), 2002: 97-106.

[4] Liu H, Ma Z, Shao W, et al. Schedule of bad smell detection and resolution: a new way to save effort[J]. IEEE Transactions on Software Engineering, 2012, 38(1): 220-235.

[5] Liu H, Niu Z, Ma Z, et al. Identification of generalization refactoring opportunities[J]. Automated Software Engineering, 2013, 20(1): 81-110.

[6] Maneerat N, Muenchaisri P. Bad-smell prediction from software design model using machine learning techniques[C]//Computer Science and Software Engineering (JCSSE), 2011 Eighth International Joint Conference on. IEEE, 2011: 331-336.

[7] Dangel A, Pelisse R. PMD[CP/OL]. (2013-05-01) [2013-05-04]. http://sourceforge.net/projects/pmd/.

[8] Burn O. CheckStyle[CP/OL]. (2012-10-12) [2013-05-04]. http://sourceforge.net/projects/checkstyle/.

[9] Fontana F A, Braione P, Zanoni M. Automatic detection of bad smells in code: An experimental assessment[J]. Journal of Object Technology, 2012, 11(2): 1-38.

[10] Intooitus SRL. inFusion[CP/OL]. (2012-10-31) [2013-05-04]. http://www.intooitus.com/products/infusion.

[11] Murphy-Hill E. Stench Blossom[CP/OL]. http://people.engr.ncsu.edu/ermurph3/tools.html.

[12] Thomas K, Eye M G, Olivier T. Eclipse corner article: abstract syntax tree[EB/OL]. (2006-11-20) [2013-05-04]. http:// www.eclipse.org/articles/article.php?file=Article-JavaCodeManipulation_AST/index.html.

[13] 劉偉, 劉宏韜, 胡志剛. 代碼缺陷與代碼味道的自動(dòng)探測(cè)與優(yōu)化研究[J]. 計(jì)算機(jī)應(yīng)用研究, 2014, 31(1): 170-176.

[14] Murphy-Hill E, Black A P. An interactive ambient visualization for code smells[C]//Proceedings of the 5th International Symposium on Software Visualization. ACM, 2010: 5-14.

RESEARCH OF AUTOMATIC DETECTION FOR DATA CLUMPS BASED ON ABSTRACT SYNTAX TREE

Liu Hongtao1Liu Wei1,2Hu Zhigang11(SchoolofSoftware,CentralSouthUniversity,Changsha410075,Hunan,China)

2(SchoolofManagementandInformationEngineering,HunanUniversityofChineseMedicine,Changsha410208,Hunan,China)

Data Clumps is a common code smell, it will lead to issues such as duplicated code and increased difficulty in maintenance. As most existing code smell automatic detection tools fail to detect data clumps, and the detection type is not complete, a data clumps automatic detection based on abstract syntax tree is proposed. On the basis of existing detection tools, adding new types of data clumps to the algorithm, with some new steps as redundant data elimination and sub-data clumps extraction. Experiments are executed on 4 open source projects. Results show that the approach has high accuracy, and it is able to detect data clumps which other tools failed to detect, such as Stench Blossom, inFusion, etc. In addition, this approach has good efficiency and the execution time is directly proportionate to the size of system.

Code smell Data clumps Abstract syntax tree Source code parsing Refactoring

2015-12-03。國(guó)家自然科學(xué)基金項(xiàng)目(61272148)。劉宏韜，碩士生，主研領(lǐng)域：軟件工程。劉偉，高工。胡志剛，教授。

TP311.5

A

10.3969/j.issn.1000-386x.2017.01.003