代碼變更中抽取類重構模式的識別①

孫美榮,楊春花

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

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

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

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

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

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

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

1 識別方法

1.1 抽取類模式示例

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

圖1 抽取類模式示例

1.2 識別方法

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

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

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

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

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

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

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

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

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

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

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

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

1.3 抽取類模式識別

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

1)代碼變更抽取

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

2)代碼變更分組

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

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

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

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

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

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

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

圖2 抽取類思想

2 算法

編寫抽取類重構模式識別的偽代碼算法.

1 輸入:一次提交的版本號revision_id 2 輸出:重構模式集合P3 獲取revision_id中所有的代碼文件集F4 for eachf∈Fdo 5 獲取f的前相鄰版本fold6 依據(jù)fold和f,獲取所有的變更集合C7 對集合C進行分組得到集合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行返回所有識別成功的重構模式集.

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ù)庫中.

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

表1 開源項目詳細信息表

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

3.2 結果及實驗分析

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

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

圖3 left.java

圖4 right.java

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

圖5 實驗結果

表2 實驗結果

4 結束語

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

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