1 引用
F. Lv, H. Zhang, J. Lou, S. Wang, D. Zhang and J. Zhao, "CodeHow: Effective Code Search Based on API Understanding and Extended Boolean Model (E)," 2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE) , Lincoln, NE, 2015, pp. 260-270.
2 摘要
在多年的軟件開發中，已經積累了大量的源代碼。目前已經提出了很多代碼搜索工具，以通過在大型代碼庫上執行自由文本查詢來幫助程序員重用先前編寫的代碼。但是，經驗告訴我們，這些代碼搜索工具的準確性通常不盡人意。主要原因之一是現有的工具缺乏查詢理解能力。在本文中，提出了叫做CodeHow的方法，這是一種可以識別用戶查詢所引用的潛在API的代碼搜索技術。瞭解了潛在的相關API之後，CodeHow通過應用擴展的Boolean模型擴展了API的查詢並執行了代碼檢索，該模型考慮了文本相似性和潛在API對代碼搜索的影響。我們將CodeHow的後端部署為Microsoft Azure服務，並將前端實現為Visual Studio擴展。我們在由Github下載的26K C#項目組成的大規模代碼庫對CodeHow進行評估。實驗結果表明，對第一個結果進行檢查時，CodeHow的精度得分為0.794（即，第一個返回結果的79.4％是相關的代碼段）。結果還顯示CodeHow優於傳統的代碼搜索工具。此外，我們對Microsoft開發人員進行了對照實驗和調查。結果證實了CodeHow在編程實踐中的有用性和有效性。
3 技術介紹
3.1 CodeHow總的結構
圖1展示了CodeHow的總體結構。CodeHow通過從開源存儲庫（例如Codeplex，Github）和組織的本地存儲庫中收集項目來構建代碼庫。收集項目後，CodeHow對源代碼執行預處理（分詞，詞幹提取等），並使用Elastic Search對代碼進行索引。
圖1 CodeHow的結構
給定用戶查詢，CodeHow首先將其提供給API理解組件（3.2），以找出與查詢相關的潛在API。然後，檢索組件（3.3）使用潛在的API擴展用戶查詢，並從代碼庫中檢索相關的代碼段。原始代碼段包含類方法（函數）的源代碼，該方法可能很冗長，並且與無關的代碼混合在一起。為了使返回的代碼段緊湊且易於理解，CodeHow應用了靜態切片技術來刪除不相關的代碼，並向用戶展示切片後的代碼段。
CodeHow的後端部署為Microsoft Azure雲服務。Elastic Search引擎在五個Azure虛擬機（包括1個主節點和4個從節點）上運行。CodeHow的前端實現為Microsoft Visual Studio擴展，可以幫助Visual Studio用戶在編程期間搜索代碼。圖2給出了CodeHow用戶界面的屏幕截圖。
CodeHow的獨特功能是其API理解和代碼檢索組件，分別在3.2和3.3中進行了詳細描述。
圖2 CodeHow用戶界面截圖
3.2 CodeHow中的API理解
CodeHow試圖瞭解用戶想要查詢的潛在API。圖3顯示了提出的API理解方法的概述。對於API庫（例如Microsoft .NET Framework），CodeHow首先從其聯機文檔中收集每個API的描述。獲取API的描述後，CodeHow計算文本描述和查詢之間的相似度以及API名稱和查詢之間的相似度。然後，它將每個API的兩個相似性值組合在一起，並返回與查詢匹配的潛在相關API。下面是API理解的詳細過程。
圖3 API理解框架
3.2.1 API富集和預處理
我們通過從在線文檔中獲取API描述來豐富API，包括完整的合格API名稱，摘要和說明（完整描述）。下面是一個例子，表1顯示了從聯機MSDN文檔中獲得的.NET API File.ReadLines的描述。我們將每個API描述都視為一個文檔，並將其用於匹配用戶查詢。
表1
對於自由文本查詢和API描述，我們執行三個預處理步驟：文本規範化，去除停用詞和詞幹抽取。目的是將文本分解成可以通過信息檢索技術分析的術語。
首先，執行文本標準化，這涉及到刪除標點符號和分詞。其次，去除停用詞。最後，我們執行詞幹提取，將詞尾變化或派生的詞還原為常見的詞根形式。例如，單詞“reading”和“reads”被簡化為詞根形式“read”。我們使用標準的PorterStemmer執行此詞幹處理步驟。
3.2.2 識別相關API
現在，我們描述如何識別與用戶查詢相關的API。該過程由兩個組件組成：文本匹配組件和名稱匹配組件。
在文本匹配（Text Matching）組件中，對於庫中的每個API ，我們使用標準向量空間模型（VSM）計算查詢和API描述之間的文本相似性分數。每個文檔d被視為向量。向量中的每個值對應於d中項t的權重。權重是根據元素頻率和逆文檔頻率來計算的。使用餘弦相似度計算相似度。文本相似度最高的前k個API將作為候選結果返回。我們將從文本匹配組件的計算中獲得的結果API定義為APItext。
在名稱匹配(Name Matching)組件中，我們計算用戶查詢與API的全限定名（FQN）之間的相似度。對於庫中的每個API，我們使用VSM計算查詢與API的FQN之間的相似性得分，並返回前k個候選API。我們將從名稱匹配組件的計算中獲得的結果API定義為APIname。
我們定義同時出現在APIname和APItext中的API的分數要高於只出現在APIname或APItext中的API。我們通過定義一種評分標準，對每個API進行綜合打分，最後返回分數較高的API作為最終的查詢結果。
3.3 代碼檢索
源代碼可以作為普通文本進行處理。傳統的信息檢索技術可以根據用戶查詢和代碼段之間的相似度來搜索與用戶查詢相關的代碼段。通過上述的API理解過程，可以識別與用戶查詢潛在相關的API。這些潛在的API信息可以補充常規的基於文本的代碼檢索。在我們的工作中，我們提出了一種綜合檢索方法，該方法同時考慮了文本相似性和API信息。在本節中，我們描述查詢的構造以及給定查詢的代碼段的檢索。
3.3.1 查詢擴展
對於一個代碼片段，我們考慮三個特徵：（1）相關API：代碼段包含的API。（2）方法主體：方法主體，其中包含實現功能的源代碼。（3）方法名稱：方法全限定名（FAN），它簡要概述了該方法的功能。
我們首先把查詢項切分為由關鍵詞構成的集合，然後構造一個布爾表達式以檢索與查詢項相匹配的代碼片段。結合上述API理解階段得到的與查詢項相關的APIs，把每個API看作關鍵詞，用類似的方式構建和APIs相同數量的布爾查詢表達式，從而達到擴展查詢的目的。
上述構建的多個表達式都可以用於搜索代碼段。因此，一個代碼段可以由以上多個查詢表達式檢索到，我們認為可以由多個查詢表達式檢索的代碼段更為重要。圖 4 是該查詢方法的一個例子。
圖4 擴展查詢示例
3.3.2 將擴展布爾模型應用於代碼搜索
為了基於查詢檢索相關的代碼片段，我們採用擴展布爾模型，它是標準布爾模型和向量空間模型之間的中間層。在標準布爾模型中，當兩個查詢詞通過“與”連接詞關聯時，兩個詞都必須存在才能檢索文檔。當使用“或”連接詞時，至少必須存在一個查詢詞。因此，標準布爾模型通常太嚴格（沒有返回結果），或者太籠統（返回了太多結果）。此外，它不考慮元素權重和對查詢結果排名。向量空間模型通過加權查詢和文檔項以及計算查詢和文檔之間的相似度，消除了標準布爾模型的許多缺點。但是，VSM（向量空間模型）也有侷限性。它不支持由複雜的AND和OR關係組成的結構化查詢。此外，由於元素頻率的差異，VSM在代碼搜索的上下文中可能導致結果不準確。例如，給定一個兩項查詢“A B”，VSM可能更喜歡包含A和B的代碼段，而不是同時包含A和B的代碼段，而這兩個代碼段均不那麼頻繁出現。但是，查詢項A可能與代碼搜索無關。擴展布爾模型結合了向量空間模型和布爾模型的特徵，並對查詢和文檔之間的相似性進行排序。
4 論文貢獻
- 提出了一種代碼搜索技術，該技術可以理解用戶查詢所引用的API，並同時考慮文本相似性和潛在的API。
- 建議應用擴展布爾模型，以結合文本相似性和潛在API對代碼搜索的影響。
- 已經實現了CodeHow，並將其部署為可伸縮的雲服務。實驗結果表明CodeHow優於傳統的代碼搜索工具。
5 致謝
本文由南京大學軟件學院2020級碩士張威翻譯轉述。 感謝國家重點研發計劃（2018YFB1403400）和國家自然科學基金（61690200）支持！
閱讀更多 慕測科技 的文章
