摘 要:相對于單一種類的代碼異味,異味共存對程序更具危害性。針對Android特有代碼異味,現(xiàn)有研究主要關注單一種類異味的檢測,忽略異味共存對Android應用程序的負面影響。為識別共存的Android特有代碼異味,提出融合靜態(tài)程序分析與集成學習的Android代碼異味共存檢測方法。作為初步研究,識別忽略類成員變量的方法異味與缺少低內(nèi)存處理程序異味的共存。首先,提出基于靜態(tài)程序分析的Android代碼異味共存檢測方法和正負樣本自動生成方法并實現(xiàn)工具 ASSD。該工具的輸出為后續(xù)集成學習模型提供豐富的訓練樣本。然后,針對單一機器學習模型泛化能力有限的問題,提出一種軟投票集成學習模型,識別共存的Android代碼異味。該模型不僅可以集成傳統(tǒng)機器學習模型,還可以集成改進的深度學習模型。實驗結果表明,所提方法優(yōu)于已有基于靜態(tài)程序分析的檢測方法,F(xiàn)1值提升了26.1百分點。此外,基于傳統(tǒng)機器學習的軟投票集成學習模型優(yōu)于基于深度學習的軟投票集成學習模型,F(xiàn)1值提升了6.1百分點。所提方法可以實現(xiàn)Android代碼異味共存的檢測。
關鍵詞:Android代碼異味共存;軟投票;集成學習;靜態(tài)程序分析
中圖分類號:TP311"" 文獻標志碼:A
文章編號:1001-3695(2025)04-027-1167-10
doi: 10.19734/j.issn.1001-3695.2024.09.0331
Detecting Android-specific smell co-occurrences based on program static analysis and ensemble learning
Wang Zhenqi, Bian Yixin, Ma Ruonan, Bi Boyu, Wang Jinxin
(College of Computer Science amp; Information Engineering, Harbin Normal University, Harbin 150025, China)
Abstract:Compared to individual types of code smells, the co-occurrence of code smells causes greater harm to programs. Existing research on Android-specific code smells primarily detects single types of smells, neglecting the negative impact of co-occurring smells on Android applications. To address this gap, this paper proposed a co-occurrence detection method for Android smells, which integrated static program analysis and ensemble learning. This initial study identified the co-occurrence of the no low memory resolver smell and member ignoring method smell. Firstly, this paper developed a co-occurrence detection method for Android smells based on static program analysis, along with an automatic generation method for positive and negative samples, and implemented an ASSD tool based on these methods. The tool provided rich training samples for the subsequent ensemble learning model. Then, this paper introduced a soft-voting ensemble learning model to detect Android smell co-occurrence, addressing the limited generalization capability of individual machine learning models. This model not only integrated traditional machine learning models but also improved deep learning models. Experimental results show that this method outperforms the existing detection methods based on static analysis, with a 26.1 percentage point increase in the F1-score. Additionally, the soft-voting ensemble model based on traditional machine learning outperforms the deep learning-based model, achieving a 6.1 percentage point improvement in the F1-score. This method enables effective detection of Android smell co-occurrence.
Key words:Android code smell co-occurrence; soft voting;ensemble learning; static program analysis
0 引言
代碼異味(code smell)是軟件系統(tǒng)中結構不良的代碼段,最早由Martin Fowler提出[1]。代碼異味常被視作軟件開發(fā)過程中的一種技術債務[2]。它的存在不僅增加了代碼的復雜度,也加大了開發(fā)人員理解和維護代碼的難度,影響軟件擴展性與版本演化。因此,代碼異味通過重構解決,以“償還技術債務”。
傳統(tǒng)桌面應用程序中的代碼異味被稱為面向?qū)ο螅╫bjected oriented,OO)代碼異味[3]。隨著技術的發(fā)展,代碼異味的概念已經(jīng)擴展到多個領域,尤其是Android平臺。Android應用程序使用相同的編程語言(即Java、Kotlin和JavaScript)開發(fā),但其硬件(如CPU、內(nèi)存)和軟件架構(如API、事件處理機制)與桌面應用程序存在顯著差異。這使得Android應用程序中的代碼異味更為復雜且多樣化[4,5]。2014年,Reimann等人[6]發(fā)現(xiàn)在Android應用程序中存在Android特有代碼異味,并給出了詳細的異味列表。
代碼異味共存,即同一方法或類中存在多種異味的情況,會增加程序維護的難度并提升bug出現(xiàn)的概率[7]。研究發(fā)現(xiàn),Android應用中存在Android特有代碼異味共存、面向?qū)ο蟠a異味與Android異味共存以及面向?qū)ο蟠a異味共存[4]三種類型的異味共存。這些異味共存增加了程序的復雜性,并影響其性能和穩(wěn)定性,本文重點研究Android特有代碼異味共存。根據(jù)文獻[4],在Android應用程序中,三對Android特有代碼異味的共存頻率較高。作為初步研究,本文選擇其中一對作為研究對象。這對代碼異味是缺少低內(nèi)存處理程序異味(no low memory resolver, NLMR)和忽略類成員變量的方法異味(member-ignoring method, MIM)。MIM異味是指某類中的方法未使用該類的成員變量,這種異味不僅常見,而且增加了應用的能耗并降低了可維護性[8] 。而NLMR異味出現(xiàn)在activity未實現(xiàn)onLowMemory()方法時,系統(tǒng)內(nèi)存不足會導致程序異常終止[9]。這兩種異味在程序性能、內(nèi)存管理和能耗方面可能產(chǎn)生協(xié)同負面影響。
目前,能夠檢測Android特有代碼異味的工具是DAAP和aDoctor。前者主要針對單一異味的檢測,準確率較高,但無法識別異味共存[10];后者雖能識別異味共存,但其準確性不足,且工具源代碼未公開[11]。此外,傳統(tǒng)靜態(tài)分析方法在閾值設定和規(guī)則選擇上具有主觀性,導致檢測結果存在差異[12]。以上現(xiàn)有檢測工具在處理異味共存時或準確性不足,或無法應對共存異味帶來的復雜情況。因此,為了檢測MIM和NLMR異味的共存,本文提出一種結合靜態(tài)程序分析與集成學習的檢測方法。主要貢獻如下:
a)提出一種基于靜態(tài)程序分析的方法識別共存的Android特有代碼異味。
b)提出一種樣本自動生成方法,該方法能將檢測結果自動分開,生成正負樣本。結合a)的方法,實現(xiàn)從異味檢測到樣本分離自動完成,并開發(fā)工具ASSD(Android-specific smell detection)。工具的輸出為后續(xù)集成學習模型提供豐富的訓練樣本。
c)提出一種基于軟投票的集成學習方法識別共存的Android代碼異味。該模型不僅可以集成傳統(tǒng)機器學習模型,還可以集成深度學習模型。
d)提出一種結合靜態(tài)程序分析與集成學習結合的Android代碼異味共存檢測方法。
1 相關工作
1.1 Android特有代碼異味
Android特有代碼異味是Android應用程序中結構不良的代碼段[6,11]。2014年Reimann等人[6]提出“質(zhì)量異味”的概念。雖然這些異味不影響功能,但對系統(tǒng)質(zhì)量(如能耗、穩(wěn)定性、啟動時間等)有負面影響[4]。由于移動應用的資源有限(如內(nèi)存、CPU、網(wǎng)絡、電池)以及特殊的應用結構和API,這些異味比傳統(tǒng)桌面應用的更復雜[5]。為了研究這種異味,學者們提出了多種Android特有異味的檢測方法。Palomba等人[11]結合文本比較和代碼度量,開發(fā)了aDoctor檢測工具,可識別15種異味并發(fā)現(xiàn)異味共存,但其源代碼未公開。文獻[13]對工具aDoctor進行了功能擴展,重構與能耗相關的5種異味。Rasool等人[10]結合啟發(fā)式規(guī)則與代碼度量,識別25種異味,開發(fā)了工具DAAP,且公開源代碼,便于后續(xù)研究。
1.2 代碼異味共存
代碼異味共存是指在同一個類或方法中出現(xiàn)多種代碼異味,研究表明,相對于單一種類的代碼異味,代碼異味共存對程序更具危害性[4]。文獻[14]發(fā)現(xiàn)異味共存增加了代碼理解難度。Palomba等人[7]指出受多種異味影響的類,變更和故障的概率分別高出350%和400%。Palomba等人[15,16]進一步研究了異味共存的頻率和原因。Hamdi等人[4]研究表明,34%的Android類受到多種Android異味影響,26%的類受到多種OO異味影響,51%的類受到OO和Android異味的影響。在Android應用中存在Android特有代碼異味共存、面向?qū)ο蟠a異味與Android特有代碼異味共存、OO代碼異味共存[4]三種類型的異味共存。作為初步研究,本文研究兩種共存頻率較高的Android特有代碼異味:忽略類成員變量的方法異味和缺少低內(nèi)存處理程序異味。
1.3 本文研究的異味
1.3.1 忽略類成員變量的方法異味
忽略類成員變量的方法異味是一種Android特有的代碼異味[9],也是存在于Android應用程序中數(shù)量最多的異味,備受學術界關注[17,18]。田迎晨等人[19]提出關鍵程度值量化方法,評價代碼異味的重要程度。關鍵程度越高的異味,表示其對應用程序的影響越大,在重構過程中應該處于更高的優(yōu)先級。根據(jù)此方法,MIM是眾多Android特有代碼異味中關鍵程度最高的異味。MIM的存在對Android應用程序的能耗及可維護性產(chǎn)生負面影響。MIM是指某個類中的方法,該方法既非空方法,也非靜態(tài)方法,同時也不包含子類覆蓋父類的方法,但該方法沒有訪問其所屬類的屬性。圖1所示為一段含有MIM異味的代碼實例。代碼第3行,在類ExampleClass中,方法doSomeing()沒有使用類中定義的屬性變量mValue。
1.3.2 缺少低內(nèi)存處理程序異味
通常情況下,移動操作系統(tǒng)的RAM較小且沒有SWAP空間釋放內(nèi)存。Android提供一種機制幫助系統(tǒng)管理內(nèi)存。當所有后臺進程被終止時,可以調(diào)用可重寫的方法Activity.onLowMemory()。即在終止托管服務和前臺UI進程之前,程序員希望避免殺死它們。這個方法用于清理緩存或不必要的資源。如果沒有實現(xiàn)這個方法,可能導致程序異常終止。這種異味被命名為缺少低內(nèi)存處理程序(no low memory resolver,NLMR)異味。因為不包含onLowMemory()方法的Activity類的子類才有這種異味,所以為了便于說明這種異味,圖2所示代碼為不含有這種異味的代碼段。如圖2所示,代碼第4行,類MyActivity中包含了可覆蓋的onLowMemory()方法。如果這段代碼沒有實現(xiàn)這個方法,則被認為是異味。
1.3.3 MIM和NLMR異味的共存
圖3所示為MIM與NLMR共存的一段代碼實例。代碼第3行的doSomeing()方法中沒有使用其所在類MyActivity中定義的方法mValue。因此,含有MIM異味。同時,在類MyActivity中沒有onLowMemory()方法。所以,這段代碼同時受到兩種異味的干擾。
1.4 基于靜態(tài)程序分析的異味檢測方法
程序靜態(tài)分析是一種在程序源代碼或編譯后的中間代碼級別對程序進行分析的方法,不需要實際執(zhí)行程序。其目的是通過對代碼的靜態(tài)結構、語法、語義等方面的分析,檢測和識別潛在的代碼問題。靜態(tài)程序分析是代碼異味檢測常用的檢測方法。目前已有的檢測Android代碼異味的工具DAAP[17]和aDoctor[6]都采用這種方法。盡管DAAP在單一種類異味檢測方面表現(xiàn)出色,但其不能檢測異味共存。
基于靜態(tài)分析的方法主要采用兩種方式進行異味檢測:a)使用一系列依賴于結構參數(shù)(即軟件度量)的閾值來檢測代碼異味,以分類描述特定代碼異味的癥狀;b)通過預定義的規(guī)則或啟發(fā)式方法來檢測代碼異味。這些方法的主要局限是它們的性能嚴重依賴于閾值和/或組合規(guī)則[12]。直到現(xiàn)在,專家們對于標準值和規(guī)則仍然沒有達成一致意見[12]。為了緩解這些局限性,機器學習引起研究人員的興趣。
1.5 基于機器學習的代碼異味檢測方法
1.5.1 基于傳統(tǒng)機器學習的代碼異味檢測方法
近年來,機器學習的研究與應用取得了巨大進步,特別是在圖像、文本和自然語言處理領域。目前,研究人員已將機器學習應用于軟件工程領域,解決相關問題,如軟件測試[19]、源代碼表示[20]、源代碼質(zhì)量分析、重構[17]、代碼異味檢測等方面[6]。研究表明,機器學習算法具有檢測復雜代碼異味的能力[21]。Khomh等人[18]使用貝葉斯信念網(wǎng)絡模型對代碼異味進行檢測。文獻[22]使用16種傳統(tǒng)機器學習模型對四種OO代碼異味進行檢測,并對比不同算法的識別效果。文獻[23]將決策樹與遺傳算法相結合對代碼異味進行檢測。文獻[20]使用多層感知器(MLP)檢測了六種代碼異味,效果很好。文獻[24]將SVM算法與K均值聚類相結合檢測四種OO代碼異味,并給出重構策略。
1.5.2 基于深度學習的代碼異味檢測
文獻[25]為檢測上帝類異味,使用基于卷積神經(jīng)網(wǎng)絡的方法,該方法提高了異味識別的準確性。文獻[26]使用循環(huán)神經(jīng)網(wǎng)絡、卷積神經(jīng)網(wǎng)絡和自編碼器檢測四種OO異味,并指出,依賴代碼度量進行模型訓練可能會限制模型獲取源代碼的其他特征,進而影響模型效果。此外,即使度量標準相同,不同的閾值設定也會導致檢測結果的差異[18]。因此,文獻[26]選擇程序文本信息作為模型的輸入。本文受到文獻[26]的啟發(fā),使用程序文本信息作為訓練模型的輸入。研究表明,使用程序源代碼作為模型輸入的特征集可以使模型在檢測代碼異味時更具靈活性,即模型可以更容易適應不同種類的代碼異味[12]。
1.5.3 基于集成學習的代碼異味檢測
研究顯示,無論是傳統(tǒng)機器學習模型還是深度學習模型,沒有一種模型能適合檢測所有的代碼異味[23,26,27],而且單一機器學習模型泛化能力有限[27]。因此,可以利用集眾多模型長處的集成學習方法進行代碼異味檢測[27]。集成學習是一種結合多個模型完成任務的機器學習方法。集成學習利用特定的策略組合多個基分類器構建相對穩(wěn)定和準確的模型。與單個分類器相比,集成學習能取得更好的結果和更強的泛化能力。通常情況下,集成學習遵循兩個原則:a)基分類器的準確率高于隨機猜測;b)基分類器之間具有多樣性[28]。
集成學習策略主要分為boosting、bagging和stacking三種。本文使用的軟投票分類器屬于bagging的一種,相比于boosting方法,投票分類器更容易實現(xiàn)并行化處理,因為各個基分類器之間是獨立的,可以同時進行預測,在處理大規(guī)模數(shù)據(jù)時,投票分類器效率更高。與stacking方法相比,投票分類器更加簡單直觀,不需要進行多層的模型堆疊,也不需要額外的元模型來組合基模型的預測結果。這使得投票分類器在實踐中更易于實現(xiàn)和調(diào)整,更好地適應不同的數(shù)據(jù)分布和模型復雜度。
投票機制分為軟投票和硬投票兩種。硬投票方法是基于所有類別的投票概率之和最大的類別作出預測。軟投票(soft voting,SV)是一種合并多個模型預測結果的方法,可提高集成模型的整體性能。在軟投票中,集成通過對每個基本分類器的類別預測進行多數(shù)投票來對新輸入進行分類,其中每個基本分類器的投票權重與該輸入的預測類別概率成比例。這意味著對于特定類別具有更高概率的基本分類器,在該類別上的投票權重將高于具有較低概率的分類器。軟投票通常被認為比硬投票更穩(wěn)健和準確。在已有集成學習研究中,大多數(shù)學者選擇軟投票方式進行集成[27]。
以上使用機器學習算法檢測異味的方法都取得了較好的效果。然而,關注的都是單一種類的傳統(tǒng)面向?qū)ο蟠a異味,缺少針對Android特有代碼異味的研究。本文提出一種靜態(tài)程序分析與集成學習結合的方法,檢測Android代碼異味的共存。
2 Android代碼異味共存檢測方法
2.1 方法概述
本文提出的Android代碼異味共存檢測方法如圖4所示。首先,以開源的Android應用程序作為代碼語料庫,使用工具ASSD對語料庫中的源程序進行MIM和NLMR異味共存檢測。工具ASSD不僅可以檢測出代碼異味共存的類,而且可以自動將正樣本(含有MIM和NLMR異味共存的類)和負樣本(不含MIM和NLMR異味共存的類)提取出來生成文本文件(文件格式為.java),作為標簽樣本集,即正樣本集合與負樣本集合。接著,使用工具Tokenizer將標簽樣本集中的源代碼轉(zhuǎn)換為整數(shù),以數(shù)字向量的形式作為集成學習模型的輸入。集成學習分類器的預期輸出為樣本的標簽(即是否為MIM和NLMR異味共存)。經(jīng)過多次訓練驗證,最終獲得效果最佳的分類器模型,然后通過測試集測試分類器性能,并給出代碼異味的檢測結果。
2.2 數(shù)據(jù)集構建
2.2.1 實驗對象獲取
本文實驗所需代碼語料庫取自GitHub。GitHub 是一個版本控制和協(xié)作的代碼托管平臺。倉庫(repository)是GitHub上存儲和管理代碼項目的基本單位。GitHub提供了倉庫這樣的容器來托管代碼項目,用戶可以通過GitHub在這些倉庫中進行各種操作和交互[20]。由于目前已有的Android代碼異味檢測工具只能檢測使用Java語言開發(fā)的應用程序,所以本文選擇由Java語言開發(fā)的Android應用程序作為代碼語料庫。
從GitHub按照以下標準進行代碼語料庫的篩選。首先,應用程序代碼庫至少為1 000 KB[6]。其次,應用程序的星標數(shù)必須大于500。星標數(shù)表示應用程序的被關注程度和被喜愛程度,這個指標間接地反映了程序質(zhì)量。最后,Java應用程序最后一次更新日期應晚于2023年4月1日,Kotlin應用程序最后一次更新日期應晚于2023年11月1日。更新時間表示應用程序活躍程度和維護頻率。通常來說,一個經(jīng)常更新的項目代表著活躍的開發(fā)者社區(qū)和持續(xù)的改進工作。因此,對于許多用戶來說,更新時間是選擇是否使用該程序的一個重要考量因素。按照以上標準對GitHub進行搜索(條件可表示為Android APP language:Java size:gt;=1 000 stars:gt; 500 pushed:gt;2023-04-01),得到70個Java項目。表1所示為其中7個Java應用程序的信息。全部信息已上傳到https://github.com/nauhob/SLDetection。
2.2.2 使用靜態(tài)程序分析檢測共存的Android代碼異味
在已有的Android特有代碼異味檢測工具中,DAAP檢測的異味種類最多,檢測準確性最高。它能夠檢測包括MIM和NLMR在內(nèi)的25種Android特有代碼異味。而且,DAAP源代碼完全公開,使用者可以根據(jù)需求在其原有的功能上進行拓展,因此本文選擇DAAP作為基礎工具。但DAAP只能檢測單一種類的代碼異味,無法檢測MIM與NLMR異味共存。為了給后續(xù)集成學習模型快速、準確地提供大量樣本。本文提出基于程序靜態(tài)分析的代碼異味共存檢測方法,并實現(xiàn)工具ASSD。該工具對DAAP的功能進行拓展,使其不僅能夠檢測MIM和NLMR異味的共存,并且能自動分離正負樣本(ASSD沒有改變單一種類異味的檢測規(guī)則)。圖5所示為基于靜態(tài)程序分析的Android代碼異味共存檢測及正負樣本生成過程,圖中虛線內(nèi)所示為原DAAP工具的處理過程,虛線外的功能是本文擴展的功能。
如圖5所示,首先,DAAP的輸入是Java源代碼,經(jīng)過JavaParser進行語法解析,生成抽象語法樹。然后,依據(jù)異味查找規(guī)則遍歷語法樹,得到檢測結果。為了實現(xiàn)Android代碼異味的共存檢測,本文使用了嵌套的哈希表結構來存儲每次檢測結果,哈希表結構如圖6所示。這個結構由外層哈希表(map1)和內(nèi)層哈希表(map2)兩個層次的哈希表組成。
a)內(nèi)層哈希表(map2)。這個哈希表用于記錄單個類中各種代碼異味的出現(xiàn)次數(shù)。它的每個鍵是一個代碼異味的名稱,而對應的值是這種異味在該類中出現(xiàn)的次數(shù)。例如,如果一個類中出現(xiàn)了5次“忽略類成員變量的方法”異味,那么“忽略類成員變量的方法”異味將作為鍵,5作為值,存儲在map2中。
b)外層哈希表(map1)。這個哈希表用于記錄不同類路徑下的所有代碼異味信息。它的每個鍵是一個類的路徑,而對應的值是與該類相關的內(nèi)層哈希表(map2)。這樣,可以通過類的路徑快速定位到該類的所有代碼異味信息。具體來說,每當檢測到一個代碼異味時,首先確定這個異味屬于哪個類,然后,在map2中查找這個類對應的記錄,如果不存在,就新建一個。接著,在map2中更新這個異味的計數(shù),如果這個異味是第一次出現(xiàn),就初始化計數(shù)為1,否則就將計數(shù)加1。當完成了一個類的所有代碼異味檢測后,得到了這個類對應的map2,它包含了這個類中所有代碼異味的名稱和出現(xiàn)次數(shù)。然后,將這個map2作為值,與類的路徑(作為鍵)一起存儲到map1中。通過這種嵌套哈希表的結構,可以清晰地組織和存儲每個類中的代碼異味信息,并且可以方便地進行查詢和分析。例如,如果想要知道某個特定類中有哪些代碼異味以及它們的數(shù)量,只需要查找map1中對應的類路徑,然后查看對應的map2即可。同樣,如果想要分析代碼異味的共存情況,可以通過查看不同類的map2實現(xiàn)。
這種結構不僅使得數(shù)據(jù)的存儲和檢索變得高效,而且也提供了一種靈活的方式來處理和分析代碼異味數(shù)據(jù)。通過這種嵌套的哈希表結構,算法能夠高效地實現(xiàn)代碼異味共存的檢測。檢測算法如算法1所示。
算法1 Android代碼異味共存檢測算法
輸入:AndroidResource。
輸出:map1。
for each CLASS in AndroidResource
LegacyClass ← JavaParser(class)
for each detectionEngine in DetectionEngines
map1← detectionEngine.detect(LegacyClass)
// map1lt;classRoute, map2lt;codeSmell, numbergt;gt;
end for
end for
output the contents of map1 to a table
本文使用的Android異味檢測工具ASSD (Android-specific smell detector)不僅可以分別檢測MIM和NLMR異味,還可以檢測兩者的共存,并自動生成共存異味的樣本集合。工具ASSD實現(xiàn)了從共存異味檢測到樣本生成完全自動化,算法2所示為異味共存的正負樣本自動生成算法。
算法2 正負樣本自動生成算法
輸入:smellySets, nonsmellySets。
輸出:smellyFiles, nonsmellyFiles。
String folderPath = DRIVE + \"\\AndroidApp\"
File file = new File(folderPath + \"\\\" + smellyName)
if !file.exists() then
file.mkdirs()
end if
String filepath = folderPath + \"\\\" + smellyName + \"\\\" + filename + \".java\"
BufferedWriter bw = new BufferedWriter(new FileWriter(filepath))
for each method in smellySets do
bw.write(method)
end for
bw.close()
File file_1 = new File(folderPath + \"\\\" + nonsmellySets)
if !file_1.exists() then
file_1.mkdirs()
end if
String filepath_1 =folderPath + \"\\Not_\" + smellyName + \"\\\" + filename + \".java\"
BufferedWriter bw_1 = new BufferedWriter(new FileWriter(filepath_1))
for each method in nonsmellySets do
bw_1.write(method)
end for
bw_1.close()
2.3 生成數(shù)字向量
工具ASSD的輸出結果是程序代碼,而集成學習模型的輸入是數(shù)字向量。因此本文借鑒文獻[26]的研究,選擇Tokenizer工具轉(zhuǎn)換源代碼,生成數(shù)字向量。這種轉(zhuǎn)換可以允許集成學習模型從整個程序文本中學習更廣泛的特征,不再局限于度量信息。圖7所示為一段Java源代碼由Tokenizer轉(zhuǎn)換成相對應的整數(shù)。
本文方法的輸入如式(1)所示。
Tokenizedcode={ele(m1),…,ele(mn)}input={Tokenizedcode}
(1)
其中:ele(mi)為轉(zhuǎn)換后的數(shù)字向量。代碼文本信息作為集成學習模型輸入的特征數(shù)據(jù)集,數(shù)據(jù)集格式如圖8所示。
經(jīng)過Tokenizer轉(zhuǎn)換后生成的代碼文本特征包含大量信息,這些信息可能包含一些對分類無用的特征,并且有些特征可能會干擾分類的性能與精度。其次,大量的特征加重了模型學習的負擔,增加了模型訓練的時間,同時也會使模型變得更復雜。因此,為了提高集成學習模型的檢測性能,本文對Tokenizer提取的代碼文本信息進行了特征選擇,丟棄與學習任務不相關的特征。經(jīng)過分析,Tokenizer在提取代碼信息時,80%樣本的特征數(shù)不超過88個,因此,最后樣本特征數(shù)選定為88個。超過88個特征數(shù)的樣本將被剔除,樣本中元素少于88個以全零向量來做補零擴展。另外,對樣本數(shù)據(jù)集進行修剪,發(fā)現(xiàn)99%的特征值不會超過9 999,因此本文丟棄特征值超過9 999的異常樣本,避免單個樣本對整體模型的影響。相對于代碼異味而言,現(xiàn)實情況中存在不平衡數(shù)據(jù)分布,在實際軟件項目中,出現(xiàn)代碼異味的頻率相對較低,因此收集到的樣本中,正樣本的數(shù)量少于負樣本,并且異味共存的正負樣本差異更大。本文選用的70個APP中,正樣本10 688個,負樣本44 677個。為了保證訓練集中正負樣本的平衡,本文在集成學習訓練集上使用欠采樣方法,即在負樣本中隨機抽選出與正樣本大約1∶1的數(shù)量,本文中的集成學習訓練集正樣本8 640個,負樣本8 832個。在對比實驗中,深度學習模型需要更大的數(shù)據(jù)集來學習,以此提高模型的泛化能力、魯棒性和穩(wěn)定性等,因此本文使用重采樣方法為CNN和RNN模型提供更大的訓練集數(shù)據(jù),即上采樣復制一份正樣本。本文深度學習模型訓練集正樣本17 280個,下采樣負樣本,從而使正負樣本平衡。
2.4 基于軟投票的集成學習方法
集成學習是一種機器學習方法,目的是通過結合多個學習器的預測結果提高整體的預測準確性和魯棒性。在集成學習中,可以使用各種不同的學習算法和模型構建多個基學習器,然后通過某種投票或加權平均的方式將它們的預測結果結合起來,生成最后的預測結果。集成學習的核心思想是“集眾家之長”,即通過結合多個學習器,規(guī)避單個學習器的局限性和不足,以獲得更加準確和穩(wěn)健的預測結果。常見的集成學習方法包括bagging、boosting、stacking等。集成學習在實際應用中被廣泛使用,特別是在數(shù)據(jù)集較小或者存在噪聲的情況下,通常能夠顯著提高模型的性能。本文使用基于軟投票的集成學習方法識別共存的異味。本文提出的集成學習方法既可以集成傳統(tǒng)機器學習模型,也可以集成深度學習模型。
2.4.1 集成方法
為了有效地融合傳統(tǒng)機器學習模型和深度學習模型,本文采用了軟投票的方式。在軟投票策略中,每個基學習器會輸出其預測類別的概率分布。通過將這些概率分布加權平均,得到每個類別的最終預測概率。最終的類別預測則由最高概率所對應的類別確定。
在具體的實現(xiàn)過程中,本文對不同模型的輸出進行了適當?shù)募訖嗵幚?。傳統(tǒng)機器學習模型通常在小規(guī)模數(shù)據(jù)集上的表現(xiàn)較為穩(wěn)定,因此其權重可以根據(jù)其在交叉驗證過程中的表現(xiàn)動態(tài)調(diào)整;而深度學習模型具有更強的表征能力,適合處理復雜模式,因此其權重可以相對提高,以反映其在大數(shù)據(jù)上的潛在優(yōu)勢。
在模型融合的具體實現(xiàn)過程中,首先對所有傳統(tǒng)機器學習模型和深度學習模型進行獨立訓練,并對各模型的輸出進行概率化處理。接著,根據(jù)各模型在驗證集上的表現(xiàn)賦予不同的權重。最終,將各模型輸出的預測概率按加權平均進行融合,輸出最終的預測結果。公式如下:
Pfinal(class)=∑ni=1wi×Pi(class)
(2)
其中:Pfinal(class)是最終的預測概率;Pi(class)是第i個基學習器的預測概率;wi是該學習器的權重;n為基學習器的總數(shù)。通過這種軟投票的集成方法,不同模型的優(yōu)勢得以互補,以提高代碼異味共存情況的識別精度。模型集成過程如圖9所示。模型集成過程由六個步驟組成:
a)數(shù)據(jù)預處理。在集成學習開始之前,首先需要對數(shù)據(jù)進行預處理,以確保數(shù)據(jù)適用于訓練模型。本文使用基于靜態(tài)程序分析的方法對異味進行檢測,將檢測結果送入集成學習模型。
b)訓練基分類器。在基于軟投票的集成學習中,需要訓練多個基分類器。這些分類器可以是不同類型的機器學習模型,比如支持向量機、決策樹、神經(jīng)網(wǎng)絡等。每個分類器都在相同的訓練數(shù)據(jù)集上進行訓練。本文集成傳統(tǒng)機器學習模型使用的三種模型是隨機森林、極端隨機樹和基于直方圖的梯度提升。本文集成深度學習模型使用的兩種模型是卷積神經(jīng)網(wǎng)絡和循環(huán)神經(jīng)網(wǎng)絡。
c)軟投票過程。在傳統(tǒng)的硬投票中,每個基分類器會對測試樣本進行類別預測,然后通過多數(shù)投票的方式來決定最終的類別。而在軟投票中,每個基分類器不僅提供類別預測,還提供預測的概率分布。這意味著每個分類器會輸出一個概率向量,表示測試樣本屬于每個類別的概率。
d)聚合預測概率。對于每個測試樣本,將所有基分類器輸出的概率向量進行聚合。通過計算每個類別概率的平均值來實現(xiàn)。例如,如果有五個基分類器,它們對某個測試樣本屬于類別A的概率預測分別是0.2、0.3、0.1、0.6和0.1,那么軟投票集成模型會計算這五個概率的平均值,得到類別A的最終預測概率。
e)確定最終預測。在聚合了所有基分類器的概率之后,選擇概率最高的類別作為集成模型的最終預測。如果一個樣本被預測屬于多個類別,集成模型將選擇具有最高綜合概率的類別。
f)模型評估。最后,需要對集成模型的性能進行評估,通過在獨立的測試集上計算模型的準確率、召回率、F1分數(shù)等指標來實現(xiàn)。評估結果可以幫助了解模型的性能,并根據(jù)需要進行調(diào)整。
2.4.2 傳統(tǒng)機器學習基分類器
針對傳統(tǒng)機器學習模型,本文參考文獻[29]。其研究結果顯示,隨機森林、極端隨機樹和基于直方圖的梯度提升三種傳統(tǒng)機器學習模型在腦卒中的檢測中,其有效性超過了其他模型。因此,本文選擇這三個傳統(tǒng)機器學習模型作為基學習器。每個基分類器詳細信息如下:
a)隨機森林(random forest,RF)[12]:一種用于機器學習中分類和回歸的集成學習方法,是決策樹的一種融合方法,其中創(chuàng)建了一組決策樹,并將它們的輸出組合起來進行最終預測。隨機森林算法在訓練期間創(chuàng)建多個決策樹(也稱為“森林”),并在決策樹的每個分裂點選擇特征的子集,而不是像傳統(tǒng)決策樹算法那樣使用所有特征。這是通過使用稱為自助聚合或bagging的技術來實現(xiàn),這有助于減少決策樹中可能出現(xiàn)的方差和過擬合。隨機森林分類器通常是由決策樹組成的集成,其中每棵樹的訓練都在數(shù)據(jù)的另一個子集上進行,最終的預測取決于森林中所有樹的一致性,每棵樹都做出了預測。森林中的每棵樹都在數(shù)據(jù)的不同隨機子集上進行訓練,并且在樹的每個分裂點都使用了一組隨機的特征子集。這種隨機化有助于減少森林中樹之間的關聯(lián),提高整體性能。隨機森林易于使用,可以處理大量特征和分類變量,與單個決策樹相比,發(fā)生過擬合的概率較低。
b)極端隨機樹(extremely randomized trees,ERT)[12]:機器學習中隨機森林算法的一種變體。它使用與集成決策樹相同的概念,但構建樹的方法略有不同。在隨機森林中,決策樹是通過在每個分裂點重復選擇一組隨機特征,并選擇根據(jù)某個標準(例如,信息增益或基尼不純度)給出最佳分裂的特征來構建。相比之下,ERT將隨機化推到了更高的層次,并在每個分裂點隨機選擇每個特征的閾值,而不是根據(jù)標準選擇最佳閾值。這種額外的隨機化使ERT能夠?qū)⒏嗟碾S機性和多樣性引入到集合中,使其不太容易過擬合,并且對數(shù)據(jù)中的噪聲更具魯棒性。此外,它使算法訓練速度更快,因為它不需要為每個特征找到最佳閾值。ERT用于分類和回歸任務,而且相對快速和易于使用。
c)基于直方圖的梯度提升(histogram-based gradient boosting,HBGB)[12]:機器學習中梯度提升算法的一種變體。梯度提升實際上是一種強大的集成技術,它通過結合多個弱模型的預測來構建模型,其中每個模型都是為了糾正整個集合中早期模型的錯誤而訓練的。HBGB利用直方圖來近似數(shù)據(jù)的潛在分布,而不是傳統(tǒng)方法中使用單棵決策樹。它為每個特征構建一個直方圖,并且對于每個特征,都使用直方圖將數(shù)據(jù)分成不同的箱子,然后對每個箱子應用決策樹模型。這使得算法能夠更準確地逼近數(shù)據(jù)的潛在分布,從而帶來更好的性能。HBGB特別適用于具有大量特征的數(shù)據(jù)集,或者數(shù)據(jù)高度傾斜或具有離群值的情況,因為它可以比傳統(tǒng)的梯度提升更好地處理這些類型的分布。它也相對快速和易于使用,并且可以并行化以加速訓練。
2.4.3 深度學習基分類器
在軟件工程領域,近幾年深度學習在代碼異味檢測方面取得了顯著進展。文獻[25]在其研究中使用卷積神經(jīng)網(wǎng)絡檢測上帝類異味,取得了很好的效果。文獻[26]使用三種不同的深度學習模型(循環(huán)神經(jīng)網(wǎng)絡、卷積神經(jīng)網(wǎng)絡和自編碼器),檢測包括四種面向?qū)ο蟠a異味,結果顯示,深度學習能夠檢測傳統(tǒng)面向?qū)ο蟠a異味,但每種模型適合檢測的異味是不同的。因此,為了對比集成傳統(tǒng)機器學習模型與深度學習模型的檢測結果,本文在以上兩項研究的基礎上,提出改進的CNN和改進的RNN兩種深度學習模型。使用這兩種模型檢測共存的Android代碼異味。模型結構如圖10所示,圖(a)為改進的CNN模型結構,圖(b)為改進的RNN模型結構。改進的CNN模型由嵌入層、卷積層、最大池化層、dropout層、flatten層和兩個全連接層六層組成。改進的RNN模型由嵌入層、長短時記憶網(wǎng)絡(long short-term memory,LSTM)、flatten層以及全連接層構成。
利用相同訓練集進行多次訓練驗證,選取最優(yōu)的參數(shù),從而使模型性能達到最佳水平。表2為改進的CNN和RNN模型的超參數(shù)。
3 實驗設計與驗證
3.1 研究問題
本文通過解答以下五個研究問題(research questions,RQ),評估所提方法的有效性。
RQ1:集成傳統(tǒng)機器學習模型的方法能否檢測出Android特有代碼異味的共存?如果可以,與單一種類傳統(tǒng)機器學習模型的檢測效果相比,哪種更出色?
RQ2:相對于現(xiàn)有基于靜態(tài)程序分析的異味共存檢測方法,本文提出的集成傳統(tǒng)機器學習方法的檢測效果是否優(yōu)于已有方法?
RQ3:本文方法集成傳統(tǒng)機器學習模型與單一種類深度學習方法的檢測效果相比,哪種更好?
RQ4:集成傳統(tǒng)機器學習模型與集成深度學習模型的檢測效果相比,哪種集成方式的檢測效果更好?
RQ5:本文方法構建樣本數(shù)據(jù)集的過程耗時多少(包括2.2.2節(jié)所述使用靜態(tài)程序分析檢測異味共存的時間與2.3節(jié)所述生成數(shù)字向量的時間)?訓練集成學習模型和利用已訓練好的模型進行預測的過程中,所需的時間分別是多少?
3.2 模型評價指標
本文使用查準率(precision)、查全率(recall)和F1值(F1-score)來評估不同分類器的性能,表示為
precision=TPTP+FP
(3)
recall=TPTP+FN
(4)
F1-score=2×precision×recallprecision+recall
(5)
其中:TP(true positive)真陽性,表示實際含有異味,同時預測正確的樣本;FP(1 positive)假陽性,表示實際不含異味但被預測為有異味的樣本;FN(1 negative)假陰性,表示不含異味但被預測為包含異味的樣本;TN(true negative)真陰性,正確預測不存在代碼異味的樣本。查準率(precision)表示在預測為正的樣本中,預測正確的比率;查全率(recall)表示在實際為正的樣本中,預測正確的比例;F1值綜合考慮查準率和召回率,是兩者的平衡。通過計算這些評估指標,可以客觀地評估不同分類器在檢測異味共存方面的有效性和區(qū)別。這些指標提供了分類器的準確性和召回率的衡量,以及兩者的綜合表現(xiàn)。
3.3 實驗設計
針對RQ1,本文利用2.3節(jié)所述的包含70個應用程序的訓練數(shù)據(jù)集,進行多次訓練驗證以及參數(shù)優(yōu)化后輸入軟投票模型,采用十折交叉驗證對模型進行驗證,使用查準率、查全率和F1值對六種檢測方法進行比較。這六種傳統(tǒng)機器學習模型分別為:樸素貝葉斯(naive Bayes, NB)、貝葉斯網(wǎng)絡(Bayes net, BN)、決策樹(decision tree, DT)、隨機樹(random tree,RT)、隨機森林(random forest, RF)、基于規(guī)則的歸納算法(JRip)。
針對RQ2:本文選擇了13個開源應用程序用作測試集,這13個開源項目使用2.2.1節(jié)的標準篩選而來,并且與訓練集的70個應用程序沒有交集,表3所示為13個應用程序的詳細信息。然后與基于靜態(tài)程序分析的Android特有代碼異味檢測工具aDoctor進行對比,aDoctor是目前已有研究中能夠檢測Android特有代碼異味共存的工具[6]。為了評估它的查準率、查全率以及F1值,由人工對aDoctor檢測的13個應用程序進行分析,以驗證aDoctor檢測的MIM和NLMR代碼異味共存實例是否正確,這個過程大約花費了80 h。最后通過查準率、查全率和F1值這三個指標對集成學習模型和aDoctor進行對比。
針對RQ3:本文參考文獻[25],提出改進的CNN和RNN兩種深度學習模型,利用2.3節(jié)所述的訓練數(shù)據(jù)集,進行多次訓練驗證以及參數(shù)優(yōu)化。使用相同的測試數(shù)據(jù)集作為模型輸入,利用查準率、查全率和F1值三個評價指標,對集成傳統(tǒng)機器學習的方法和深度學習方法的檢測結果進行評估。
針對RQ4:本文選用改進的CNN和RNN兩種深度學習模型進行集成,利用2.3節(jié)所述的訓練數(shù)據(jù)集,進行多次訓練驗證以及參數(shù)優(yōu)化,使用相同的測試數(shù)據(jù)集作為模型輸入。利用查準率、查全率和F1值三個評價指標,對集成不同模型種類的集成學習模型的MIM和NLMR共存檢測結果進行評估。
針對RQ5:研究顯示,模型復雜性是選擇模型時需要考慮的一個重要因素,因為復雜模型需要額外的資源消耗(例如存儲和計算時間成本)[12]。深度學習模型比傳統(tǒng)機器學習模型復雜。因此,在評估機器學習模型特別是深度學習模型時,時間復雜性是一個重要的度量指標[12]。這個研究問題定量地揭示了所提方法的訓練和測試時間。本文實驗所用電腦配置如下:32 GB RAM,AMD Ryzen 7 5800X。為了分析本文方法的時間性能,在實驗過程中記錄了生成數(shù)據(jù)集以及分類器訓練和測試過程的耗時情況(以分鐘為單位)。
3.4 實驗結果分析
RQ1:集成傳統(tǒng)機器學習模型的方法能否檢測出Android特有代碼異味的共存?如果可以,與傳統(tǒng)機器學習模型的檢測效果相比,哪種更出色?
表4為檢測結果。軟投票與六種傳統(tǒng)機器學習模型的查準率、查全率和F1值都較高,其中本文模型取得了最高的檢測性能。實驗結果表明,利用軟投票集成學習方法檢測MIM和NLMR兩種異味的共存是可行的。
七種模型的檢測結果的順序為:本文模型gt;RFgt; JRip gt;BN gt;DTgt;RTgt;NB。文獻[28]使用16種傳統(tǒng)機器學習模型檢測四種面向?qū)ο蟮拇a異味,但是,它只考慮了單個異味,沒有考慮異味的共存。在與本文相同的五種模型中,它們的結果為: DTgt; RFgt; JRipgt; NBgt;BN。由此可見,傳統(tǒng)機器學習模型在檢測不同種類、不同狀態(tài)(單一種類異味或異味共存)時,不同模型的檢測性能存在差異。
RQ2: 相對于現(xiàn)有基于靜態(tài)程序分析的異味共存檢測方法,本文集成傳統(tǒng)機器學習的方法的檢測效果是否優(yōu)于已有方法?
表5為本文方法與檢測工具aDoctor的檢測結果。
如表5所示,本文使用的軟投票模型檢測結果優(yōu)于現(xiàn)有基于靜態(tài)程序分析的Android代碼異味共存檢測工具aDoctor,其相對于aDoctor,F(xiàn)1值平均提高了26.1百分點(97.7%-71.6%)。
RQ3:本文提出的集成傳統(tǒng)機器學習模型的方法與深度學習方法的檢測效果相比,哪種更好?
表6為集成傳統(tǒng)機器學習模型和兩種改進的深度學習模型的測試結果。兩種深度學習模型CNN和RNN的綜合性能(F1值)分別為82.5%和84.9%,低于軟投票方法。
結合表4、6可知,在檢測MIM與NLMR這兩種Android代碼異味共存時,CNN與RNN模型的效果低于單一種類的機器學習模型,比如RNN的F1值。
RQ4:集成傳統(tǒng)機器學習模型與集成深度學習模型的檢測效果相比,哪種集成方式的檢測效果更好?
表7為集成機器學習模型的軟投票分類器和集成深度學習模型的軟投票分類器的對比測試結果。兩種集成學習模型綜合性能(F1值)分別為97.7%和91.6%,可以看出集成了本文所提到的三種機器學習模型的軟投票分類器效果更好。
RQ5:表8為生成訓練集時,7個應用程序的時間消耗(以分鐘為單位)。如表8所示,耗時最多的是獲取樣本數(shù)據(jù)的過程。從70個應用程序獲取訓練數(shù)據(jù),消耗308 min,平均每個項目4.4 min。
表9為集成不同模型的軟投票在訓練過程和測試過程的耗時情況(以秒為單位)。
如表8所示,與耗費接近3個多小時的訓練集生成過程相比,兩種軟投票分類器在數(shù)據(jù)集上的訓練時間分別為13.7 s和407.7 s。測試過程中,軟投票分類器有著很好的時間性能,其中集成了機器學習的軟投票分類器時間性能更佳。
4 討論
4.1 本文研究的兩種異味共存的必要性和目標
本文研究Android特有代碼異味共存。根據(jù)文獻[4]的結果,在Android應用程序中,三對Android特有代碼異味的共存頻率較高[4]。作為初步研究,本文選擇其中一對作為研究對象。這對代碼異味是NLMR和MIM。原因如下:a)相對于單一種類的代碼異味,異味共存對程序更具危害性[16]?!叭鄙俚蛢?nèi)存處理程序”異味可能導致在資源有限的情況下,系統(tǒng)無法有效處理請求,影響用戶體驗,而“忽略類成員變量的方法”異味可能導致代碼邏輯不清晰,降低可讀性和可維護性。b)探索兩種異味的共存現(xiàn)象,可以揭示它們?nèi)绾螀f(xié)同影響Android應用程序的性能,特別是在內(nèi)存有限的移動設備上。這一研究不僅有助于理解如何更好地重構代碼以優(yōu)化性能,還為開發(fā)自動化工具提供了依據(jù)。c)目前學術界主要集中在傳統(tǒng)面向?qū)ο螅∣O)代碼異味的研究,忽視Android應用中代碼異味共存的現(xiàn)象。深入探究Android代碼異味的共存問題,對于應用程序的開發(fā)者和研究人員,具有重要的學術價值和實踐意義。對于研究人員,這些發(fā)現(xiàn)可以作為深入探討Android異味與傳統(tǒng)代碼異味之間聯(lián)系的起點,同時,研究成果可以幫助他們在設計異味重構方法時,考慮到這些異味之間的依賴關系。開發(fā)出實用可靠的移動應用重構工具。對于Android開發(fā)者,現(xiàn)有研究的不足導致開發(fā)者在實際應用中難以有效地解決多個異味共存的問題。識別這些共存關系有助于人們集中精力優(yōu)先重構那些共存頻率高的代碼異味,從而節(jié)省時間與精力,提升其應用程序的質(zhì)量。d)研究顯示[4],三對共存的Android特有代碼異味中,忽略類成員變量的方法異味與缺少低內(nèi)存處理程序異味的共存,其support(支持度)、confidence(置信度)和lift(提升度)的值都是最高的,分別為:support = 0.094,confidence= 0.719,lift= 1.716(參考文獻[4]中表VI)。因此,作為初步研究,本文針對這兩種異味的共存展開研究。
4.2 本文模型是否可以適用于檢測其他種類的代碼異味
在實際應用中,人們希望采用一種通用的模型架構,這種架構能夠?qū)λ锌紤]的代碼異味保持一致的良好性能,這會使得工具的實現(xiàn)變得更加簡單[26]。
作為初步研究,本文模型可以檢測忽略類成員變量的方法異味與缺少低內(nèi)存處理程序異味的共存。在代碼異味檢測領域,傳統(tǒng)的靜態(tài)程序分析方法是檢測代碼異味的主要手段,但是,機器學習方法是否適用于檢測多種代碼異味,尚屬未知。文獻[26]表明,機器學習模型的性能是根據(jù)異味種類不同而不同。比如,在處理復雜方法異味時,循環(huán)神經(jīng)網(wǎng)絡的性能超過了卷積神經(jīng)網(wǎng)絡模型;然而,在其他類型的代碼異味時,例如依戀情結異味,兩種模型并沒有達到預期的表現(xiàn)。文獻[26]認為,每種代碼異味都展現(xiàn)出不同的特征,它們的檢測機制也不同。因此,考慮到問題的本質(zhì),不太可能存在一種通用的模型架構,能夠作為檢測眾多種類代碼異味的萬能解決方案,并始終保持良好的性能。
在未來的工作中,將探索更多種類代碼異味的檢測方法,并研究代碼異味共存的重構方法。最終目的是提高應用軟件的質(zhì)量。
4.3 與已有集成學習方法的比較
目前使用集成學習方法檢測代碼異味的較新方法是文獻[27],其使用集成學習方法檢測四種OO代碼異味,而且是單一種類異味的檢測。本文研究Android特有代碼異味的共存,兩者研究對象不同。此外,本文借鑒文獻[25,26],首先使用靜態(tài)程序分析方法檢測程序中的代碼異味,然后經(jīng)過處理后,輸入集成學習模型。而文獻[27]未采用靜態(tài)分析方法,直接使用CK代碼度量作為模型的輸入。文獻[26]指出,依賴代碼度量進行模型訓練可能會限制模型獲取源代碼的其他特征,進而影響模型效果。此外,即使度量標準相同,不同的閾值設定也會導致檢測結果的差異。因此,文獻[26]選擇程序文本信息作為模型的輸入。本文模型受此啟發(fā),使用程序文本信息作為輸入。由于以上原因,本文模型未與文獻[27]進行對比。"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
5 結束語
本文采用靜態(tài)程序分析與集成學習結合的方法檢測Android應用程序中兩種特定代碼異味共存情況,即忽略類成員變量的方法異味(MIM)與缺少低內(nèi)存處理程序異味(NLMR)的共存。通過分析Android應用程序的源代碼,結合不同代碼異味之間的依賴關系,提取了類級別的MIM與NLMR異味共存實例。本文采用軟投票集成了隨機森林、極端隨機樹和基于直方圖的梯度提升三種傳統(tǒng)機器學習分類器進行檢測。為了評估集成學習模型的檢測結果,與傳統(tǒng)機器學習模型、深度學習模型CNN、RNN和已有代碼異味共存檢測工具aDoctor[11]進行比較。使用查準率、查全率和F1值這三個指標進行對比評價。實驗結果顯示,集成學習模型能夠有效檢測MIM與NLMR兩種異味的共存,而且其檢測效果優(yōu)于aDoctor工具、CNN和RNN以及傳統(tǒng)機器學習模型。而同樣是集成學習的情況下,集成了機器學習模型的軟投票分類器優(yōu)于集成了深度學習模型的軟投票分類器。本文提出的靜態(tài)程序分析與集成學習相結合的Android代碼異味檢測模型,旨在為代碼異味共存檢測提出一種新的思路。
在后續(xù)的研究工作中,將使用本文模型檢測更多種類代碼異味,并探索更多異味的檢測方法,同時研究代碼異味共存的重構方法,最終目的是提高移動應用軟件的質(zhì)量。
參考文獻:
[1]
Saca M A. Refactoring improving the design of existing code[C]// Proc of the 37th Central America and Panama Convention. Pisca-taway, NJ: IEEE Press, 2017: 1-3.
[2]Zazworka N, Shaw M A, Shull F, et al. Investigating the impact of design debt on software quality[C]// Proc of the 2nd Workshop on Managing Technical Debt. New York: ACM Press, 2011: 17-23.
[3]Wu Zhiqiang, Chen Xin, Lee S U. A systematic literature review on Android-specific smells[J].Journal of Systems and Software," 2023, 201: 111677.
[4]Hamdi O, Ouni A,AlOmar E A, et al. An empirical study on code smells co-occurrences in Android applications[C]// Proc of the 36th IEEE/ACM International Conference on Automated Software Engineering Workshops. Piscataway, NJ: IEEE Press, 2021: 26-33.
[5]Mannan U A, Ahmed I,Almurshed R A M, et al. Understanding code smells in Android applications[C]// Proc of IEEE/ACM International Conference on Mobile Software Engineering and Systems. Piscataway, NJ: IEEE Press, 2016: 225-236.
[6]Reimann J, Brylski M,Assmann U. A tool-supported quality smell catalogue for Android developers[J/OL]. Softwaretechnik-Trends.(2014). https://dl.gi.de/handle/20.500.12116/40859.
[7]Palomba F,Bavota G, Di Penta M, et al. On the diffuseness and the impact on maintainability of code smells: a large scale empirical investigation[J].Empirical Software Engineering," 2018, 23(3): 1188-1221.
[8]Palomba F, Di Nucci D, Panichella A,et al. On the impact of code smells on the energy consumption of mobile applications[J].Information and Software Technology," 2019, 105: 43-55.
[9]Hecht G. An approach to detect Android antipatterns[C]// Proc of the 37th IEEE International Conference on Software Engineering. Piscataway, NJ: IEEE Press, 2015: 766-768.
[10]Rasool G, Ali A. Recovering Android bad smells from Android applications[J].Arabian Journal for Science and Engineering," 2020, 45(4): 3289-3315.
[11]Palomba F, Di Nucci D, Panichella A,et al. Lightweight detection of Android-specific code smells: the BDoctor project[C]// Proc of the 24th International Conference on Software Analysis, Evolution and Reengineering. Piscataway, NJ: IEEE Press, 2017: 487-491.
[12]Alazba A, Aljamaan H, Alshayeb M. CoRT: Transformer-based code representations with self-supervision by predicting reserved words for code smell detection[J].Empirical Software Engineering," 2024, 29(3): 59.
[13]Maiga A, Ali N, Bhattacharya N,et al. SMURF: a SVM-based incremental anti-pattern detection approach[C]// Proc of the 19th Wor-king Conference on Reverse Engineering. Piscataway, NJ: IEEE Press, 2012: 466-475.
[14]Yamashita A, Moonen L. Exploring the impact of inter-smell relations on software maintainability:an empirical study[C]// Proc of the 35th International Conference on Software Engineering. Piscataway, NJ: IEEE Press, 2013: 682-691.
[15]Palomba F, Oliveto R, De Lucia A. Investigating code smell co-occurrences using association rule learning: a replicated study[C]// Proc of IEEE Workshop on Machine Learning Techniques for Software Quality Evaluation. Piscataway, NJ: IEEE Press, 2017: 8-13.
[16] Palomba F,Bavota G, Di Penta M, et al. A large-scale empirical study on the lifecycle of code smell co-occurrences[J].Information and Software Technology," 2018, 99: 1-10.
[17]Di Nucci D, Palomba F, Tamburri D A, et al. Detecting code smells using machine learning techniques: are we there yet?[C]// Proc of the 25th International Conference on Software Analysis, Evolution and Reengineering. Piscataway, NJ: IEEE Press, 2018: 612-621.
[18]Khomh F, Vaucher S, Guéhéneuc Y G, et al. A Bayesian approach for the detection of code and design smells[C]// Proc of the 9th International Conference on Quality Software. Piscataway, NJ: IEEE Press, 2009: 305-314.
[19]田迎晨, 李柯君, 王太明, 等. 代碼壞味研究綜述[J]. 軟件學報, 2023, 34(1): 150-170. (Tian Yingchen, Li Kejun, Wang Taiming, et al. Survey on code smells[J].Journal of Software," 2023, 34(1): 150-170.)
[20]Kim D K. Finding bad code smells with neural network models[J].International Journal of Electrical and Computer Engineering," 2017, 7(6): 3613.
[21]Al-Shaaby A, Aljamaan H, Alshayeb M. Bad smell detection using machine learning techniques: a systematic literature review[J].Ara-bian Journal for Science and Engineering," 2020, 45(4): 2341-2369.
[22]Walter B, FontanaF A, Ferme V. Code smells and their collocations: a large-scale experiment on open-source systems[J]. Journal of Systems and Software, 2018, 144: 1-21.
[23]Amorim L, Costa E, Antunes N, et al. Experience report: evaluating the effectiveness of decision trees for detecting code smells[C]// Proc of the 26th International Symposium on Software Reliability Engineering. Piscataway, NJ: IEEE Press, 2015: 261-269.
[24]Kaur A, Jain S, Goel S. A support vector machine based approach for code smell detection[C]// Proc of International Conference on Machine Learning and Data Science. Piscataway, NJ: IEEE Press, 2017: 9-14.
[25]卜依凡, 劉輝, 李光杰. 一種基于深度學習的上帝類檢測方法[J].軟件學報, 2019, 30(5): 1359-1374. (Bu Yifan, Liu Hui, Li Guangjie. God class detection approach based on deep learning[J].Journal of Software," 2019, 30(5): 1359-1374.)
[26]Sharma T, Efstathiou V,Louridas P, et al. Code smell detection by deep direct-learning and transfer-learning[J]. Journal of Systems and Software, 2021, 176: 110936.
[27]黃晨峻,高建華.融合特征選擇與多模型軟投票集成學習的代碼異味檢測方法[J].小型微型計算機系統(tǒng),2025,46(2):504-512. (Huang Chenjun, Gao Jianhua. Code smell detection method integrating feature selection and multi-model soft voting ensemble learning[J]. Journal of Chinese Computer Systems, 2025,46(2):504-512.)
[28]Arcelli F F, Mntyl M V, Zanoni M,et al. Comparing and experimenting machine learning techniques for code smell detection[J].Empirical Software Engineering," 2016, 21(3): 1143-1191.
[29]Srinivas A,Mosiganti J P. A brain stroke detection model using soft voting based ensemble machine learning classifier[J].Measurement: Sensors," 2023, 29: 100871.
[30]Aniche M, Maziero E, Durelli R,et al. The effectiveness of supervised machine learning algorithms in predicting software refactoring[J].IEEE Trans on Software Engineering," 2022, 48(4): 1432-1450.
[31]邊奕心, 李禹齊, 張子恒, 等. 深度學習策略下緩慢循環(huán)異味檢測方法[J].小型微型計算機系統(tǒng), 2024, 45(2): 490-497. (Bian Yixin, Li Yuqi, Zhang Ziheng, et al. Slow loop smell detection method by deep learning strategy[J].Journal of Chinese Computer Systems," 2024, 45(2): 490-497.)
[32]邊奕心, 王露穎, 趙松, 等. Android應用程序中代碼異味共存現(xiàn)象的實證研究[J].計算機應用研究, 2022, 39(9): 2763-2767. (Bian Yixin, Wang Luying, Zhao Song, et al. Empirical study on code smell co-occurrences in Android applications[J].Application Research of Computers," 2022, 39(9): 2763-2767.)