代碼變更中抽取類重構(gòu)模式的識別①

孫美榮,楊春花

(齊魯工業(yè)大學(xué)(山東省科學(xué)院)信息學(xué)院,濟(jì)南 250353)

重構(gòu)[1,2]是一種有紀(jì)律、經(jīng)過訓(xùn)練、有條不紊的程序整理方法,是現(xiàn)代軟件開發(fā)和維護(hù)中用于提高軟件可維護(hù)性和軟件質(zhì)量的常用手段,在代碼整理過程中可以將不小心引入的錯誤降低.

現(xiàn)代的軟件開發(fā)一般基于版本管理系統(tǒng)進(jìn)行,軟件工程師為了維護(hù)系統(tǒng)或提高系統(tǒng)的性能,每天會提交大量的代碼.文獻(xiàn)[3]指出代碼變更伴隨著軟件系統(tǒng)的整個生命周期,不斷的代碼變更,會使軟件的復(fù)雜度大幅度的提高[4].代碼變更是指日常的bug修復(fù)、代碼重構(gòu)、功能增加,這使得代碼評審者[5]和軟件工程師在理解代碼時不得不人工對代碼進(jìn)行探查,以區(qū)分哪些變更的代碼是重構(gòu),哪些不是.

而且日志描述往往反映不了代碼變更的真正行為,廖湘科等人在《大規(guī)模軟件系統(tǒng)日志研究綜述》[6]中,通過對軟件(Apache,Squid,PostgreSQL,SVN以及Coreutils等)系統(tǒng)的失效報告進(jìn)行隨即檢測,發(fā)現(xiàn)77%的系統(tǒng)失效都是常見的錯誤診斷,而57%的錯誤是沒有進(jìn)行日志記錄.

文獻(xiàn)[7] 對微軟54位資深開發(fā)人員進(jìn)行的調(diào)研,發(fā)現(xiàn)96%的人認(rèn)為日志在軟件開發(fā)和維護(hù)中有重要作用,認(rèn)為日志是了解變更代碼的主要信息來源,然而業(yè)界人員對日志的重視度不高,且代碼變更書寫不規(guī)范,導(dǎo)致評審員和維護(hù)人員花費大量的時間去定位及分析這些代碼變更.因此,為了使得變更的代碼易于理解,及提高代碼質(zhì)量,將重構(gòu)模式從代碼變更中隔離出來是非常必要的.

重構(gòu)模式的識別是在變更后的代碼中尋找符合特定重構(gòu)模式的代碼修改,是重構(gòu)的反過程.劉陽等人[8]提出了一種重構(gòu)檢測算法,是基于版本元素匹配原理,對函數(shù)抽取重構(gòu)進(jìn)行了識別,但是并沒有涉及其它類型的重構(gòu)模式.

本文通過對四個開源項目的變更代碼進(jìn)行探查,抽取類是最為常見的重構(gòu)模式.因此,本文對抽取類重構(gòu)模式進(jìn)行了研究,提出了識別的算法.

1 識別方法

1.1 抽取類模式示例

抽取類(Extract Class)[9]重構(gòu)模式,一般用于處理過長的類.一個類如果包含過多的功能及屬性,會導(dǎo)致這個類過于臃腫.為了提高類的高內(nèi)聚,低耦合,就會將一些不必要的或不經(jīng)常用的方法提煉到另一個類中,來為這個類服務(wù).如圖1是一個用類圖形式表示的抽取類模式示例.類Person中過多的屬性oficeAreaCode和officeNumber以及功能代碼getTelephoneNumber()被抽取到了一個新類TelephoneNumber中,且在移動代碼的地方對新增加類方法的引用.

圖1 抽取類模式示例

1.2 識別方法

根據(jù)上述抽取類模式的例子,不難發(fā)現(xiàn),抽取類模式變更具備如下3個特性:

① 變更文件中的某些屬性及方法被刪除;

② 文件中刪除的屬性和方法移動到其它類文件中;

③ 在原文件刪除代碼的位置有對被移動方法的引用.

其中,①和③的判定需要基于變更代碼塊的語法信息進(jìn)行識別,因此我們借用了ChangeDistiller1https://bitbucket.org/sealuzh/tools-changedistiller/src/工具獲得一個變更文件中所有的代碼變更,如聲明對象:ADDITIONAL_OBJECT_STATE、插入語句:STATEMENT_INSERT、刪除語句:STATEMENT_DELETE、移除屬性:REMOVED_OBJECT_STATE.它是BeatFluri等人[10,11]編寫的一個 Tree differ 算法,將對變更前后抽象語法樹進(jìn)行對比,獲取分類變更.它可以區(qū)別多種方法類型的變化或類等級上的變化.

而特性②的判定需要基于文本的相似性進(jìn)行識別.我們借助了Levevshtein2https://en.wikipedia.org/wiki/Levenshtein_di stance.算法,即文本相似性判斷.Levevshtein是一種計算兩個字符串間差異程度的字符串度量(string metric)算法,即一個單詞變成另一個單詞要求的最少單個字符編輯數(shù)量(如:刪除、插入和替換).那么兩個字符串的相似度算法:

Similarity=(Max(x,y)-Levenshtein)/Max(x,y)

其中,x和y為源串和目標(biāo)串的長度,本文x指刪除的代碼語句,y指在新類文件中的代碼行.注意:本文研究的是重構(gòu)模式識別,不是字符串的相似性,所以并沒有對該算法進(jìn)行改進(jìn).

識別方法的具體流程如下:

1)利用ChangeDistiller獲取兩個相鄰文件的所有變更類型的詳細(xì)信息如:變更類型、變更內(nèi)容、變更內(nèi)容所屬的雙親;

2)根據(jù)每條變更所屬雙親實體進(jìn)行分組,將相同雙親實體分到一個組內(nèi),并對每個組內(nèi)的所有刪除的語句和增加的語句按行號進(jìn)行排序,其中代碼行號通過讀取文本行獲得;

3)依據(jù)重構(gòu)模式的特性從2)所得分組中,借用Levevshtein算法進(jìn)行相似度匹配(刪除語句和新增文件的代碼行),查找相應(yīng)的元素,具體過程見下節(jié).

1.3 抽取類模式識別

圖2顯示了該算法的框架,具體流程如下文.

1)代碼變更抽取

通過ChangeDistiller獲取所有的代碼變更,包括聲明對象、刪除的語句、原方法中新增的語句等.一個代碼變更由變更類型(ChangeType)、變更實體(ChangeEntiy)和變更雙親實體(ParentEntity)構(gòu)成.

2)代碼變更分組

通過上述步驟1),每條變更可獲得一個元組的集合C={

3)代碼塊抽取判定步驟,

將每組CS分為兩部分,令刪除部分為ldelete和增加部分為ladd,即CS=cg.ldelete+cg.ladd.

① 若父類實體是類等級上的變更.判斷cg.ladd是否為新增類文件的聲明對象,若是則,再判斷cg.ldelete是否為該新增類文件的屬性;

② 若父類實體是方法變更.cg.ladd是否為新增類文件的方法,若是則,再判斷cg.ldelete是否為該方法的方法體;

①、②的過程我們借用了文本相似性工具Levevshtein對相應(yīng)元素進(jìn)行判定,若以上步驟成立,則成功識別一個抽取類重構(gòu)模式.

方法擴展:新文件fnew獲取及相關(guān)操作,1)新增文件fnew是根據(jù)本次提交的revision_id與上次revision_id–1進(jìn)行比較獲得,若revision_id–1中的文件集不包含文件f,則認(rèn)為文件f為新增文件fnew;2)通過Java的反射機制獲取新增類文件的屬性fnew.field、方法fnew.method、類名fnew.class.

圖2 抽取類思想

2 算法

編寫抽取類重構(gòu)模式識別的偽代碼算法.

1 輸入:一次提交的版本號revision_id 2 輸出:重構(gòu)模式集合P3 獲取revision_id中所有的代碼文件集F4 for eachf∈Fdo 5 獲取f的前相鄰版本fold6 依據(jù)fold和f,獲取所有的變更集合C7 對集合C進(jìn)行分組得到集合CG8 獲取所有屬性的變更組集合CGfieldCG10 for eachcg CGdo 11 for eachfnew∈Fdo 9 獲取所有方法的變更組集合CGmethodCG

12 ifcg CGfield13 for eachcg CGfield14 獲取CGfield.CS中所有的新增語句cg.CS.ladd15 獲取CGfield.CS中所有的刪除語句cg.CS.ldelete16 ifcg.CS.ladd.entity=“FIELD”17 ∩Levevshtein(cg.CS.ladd.parententity,fnew.class)18 ifcg.CS.ldelete.entity=“FIELD”19 ∩Levevshtein(cg.CS.ldelete.conten t,fnew.field)20 end if 21 end if 22 end for 23 else ifcg CGmethod24 for eachcg CGmethoddo 25 獲取CGmethod.CS中所有的新增語句cg.CS.ladd26 獲取CGmethod.CS中所有的刪除語句cg.CS.ldelete

27 ifcg.CS.ladd.entity=“RERURN_STATEMENT”28 ∩Levevshtein(cg.CS.ladd.parententity,fnew.method)29 ifcg.CS.ldelete.entity=“RERURN_STATEMENT”30 ∩Levevshtein(cg.CS.ldelete.content,fnew)31 end if 32 end if 33 end for 34 end if 35 end if 36 成功識別一個抽取類模式p 37 end for 38 end for 39 end for 40P=P∪{p}

算法偽代碼中第4行指遍歷集合F中的所有文件f;第5行通過ChangeDistiller可知f是否為變更文件;第8行指獲得集合CG中的屬性集合;第9行指獲取集合CG中的方法集合;16～19指在變更類型為“FIELD”的情況下,判斷屬性是否移動到fnew中;27～30 指在變更類型為“RERURN_STATEMENT”情況下,判斷刪除的方法及方法體是否移動到新文件fnew中,且在刪除代碼的位置有對該方法的引用;第36行若以上步驟為真,則成功識別一個抽取類模式;第40行返回所有識別成功的重構(gòu)模式集.

3 實驗驗證

3.1 數(shù)據(jù)源

我們通過minigit3https://github.com/SoftwareIntrospectionLab/MininGit工具獲取了四個開源項目jEdit4https://github.com/linzhp/jEdit-Clone,eclipse JDT Core5https://github.com/eclipse/eclipse.jdt.core,Apache maven6https://github.com/apache/maven/,and googleguice7https://github.com/google/guice/,在某段時間的變更歷史,該工具將該時間段內(nèi)所有的變更信息(包括所有提交的版本、每個版本的日志、源文件等)抽取到了MySQL數(shù)據(jù)庫中.

我們前期通過人工分析變更日志和源代碼探查,判定了一些存在重構(gòu)模式的版本.項目的信息及人工判定的重構(gòu)版本數(shù)據(jù)見表1.

表1 開源項目詳細(xì)信息表

通過人工檢測4個開源項目,獲得抽取類重構(gòu)模式的數(shù)目分別為:jEdit中含有24個版本,maven中含有69個版本,goole_guice中含有22個版本,eclipse中含有6個版本.

3.2 結(jié)果及實驗分析

圖3、4是取自項目maven版本68ca923 中DefaultMetadataResolutionReques.java(left.java)和DefaultRepositoryRequest.java(right.java)的部分變更內(nèi)容;其中減號表示刪除代碼行,加號表示增加代碼行.圖5是該算法對這一變更檢測的信息輸出.其中ChangeDistiller獲取聲明對象FIELD、刪除代碼,以及文本讀取代碼塊行號.

該實驗對表1中的數(shù)據(jù)進(jìn)行驗證,通過實驗后檢測得到的實驗結(jié)果,見表2.

圖3 left.java

圖4 right.java

通過表2可以得出,該試驗進(jìn)行的抽取類模式識別,其平均準(zhǔn)確率為82.6%,準(zhǔn)確率在77.3%～91.6%之間略有波動.準(zhǔn)確率沒有達(dá)到100%的原因與借用的代碼相似性比較算法有關(guān).因為被測文本是重構(gòu)代碼變更文本,所以被提取的代碼塊并不是簡單的復(fù)制/粘貼.程序員在進(jìn)行代碼重構(gòu)時,為了提高代碼質(zhì)量的可理解性、可維護(hù)性和可擴展性,被提取的代碼行中的有些元素可能被替換,如新增方法中的參數(shù)、局部變量等,但整個操作并不會改變軟件功能.因此,對本文反過程重構(gòu)模式識別中代碼塊提取過程會有些影響.

圖5 實驗結(jié)果

表2 實驗結(jié)果

4 結(jié)束語

我們提出了一種基于變更類型和文本相似性比較的重構(gòu)模式識別方法,并設(shè)計和實現(xiàn)了對抽取類(Extract Class)模式的識別.通過實驗驗證,該方法可以比較準(zhǔn)確地識別Extract Class模式.

除了Extract Class模式,該方法還適用于其它存在代碼移動的重構(gòu)模式,如Extract Superclass,Move Interface等.后續(xù)工作包括將該方法應(yīng)用于這些模式的識別.