基于開源社區(qū)分析的API使用案例推薦服務(wù)

張佳琪，孫艷春*，黃罡

基于開源社區(qū)分析的API使用案例推薦服務(wù)

張佳琪1，2，孫艷春1，2*，黃罡1，2

（1.北京大學 信息科學技術(shù)學院，北京 100871； 2.高可信軟件技術(shù)教育部重點實驗室（北京大學），北京 100871）（?通信作者電子郵箱sunyc@pku.edu.cn）

目前有關(guān)API學習和代碼復用的研究主要集中在對于API調(diào)用頻繁模式的挖掘、組件化信息的提取以及根據(jù)用戶的需求和目標功能進行的個性化應用程序接口（API）推薦服務(wù)等方面。然而，作為缺少專業(yè)知識和經(jīng)驗技能來完成特定使用案例的軟件開發(fā)初學者，在閱讀官方文檔之外，往往需要真實的使用案例作為參考。現(xiàn)有代碼推薦研究大多為單片段式代碼，缺少跨函數(shù)的案例選擇，這不利于初學者學習構(gòu)建完整的使用場景或功能模塊；同時，從單個函數(shù)注釋中提取的語義描述也不足以構(gòu)建學習者對項目中完整功能實現(xiàn)方法的認識。為了解決上述問題，提出了一種基于開源社區(qū)分析的API使用案例推薦服務(wù)，并以軟件開發(fā)后端框架Spring Boot為例，構(gòu)建了跨函數(shù)的案例推薦輔助學習服務(wù)。隨后，通過調(diào)查問卷、專家驗證等方式驗證了所提出的API使用案例推薦服務(wù)的可行性和有效性。

代碼復用；應用程序界面；開源社區(qū)分析；推薦服務(wù)；使用案例

0 引言

目前，對于軟件開發(fā)學習者來說，可供選擇的學習渠道包括官方文檔、中英文博客、開源項目倉庫以及問答社區(qū)等。官方文檔的學習難度取決于文檔的組織方式和內(nèi)容編排，其理解在大多數(shù)情況下需要一定的領(lǐng)域知識，沒有該領(lǐng)域開發(fā)經(jīng)驗的學習者難以理解文檔作者展示的內(nèi)容。而博客教程傾向于碎片化學習，且缺少質(zhì)量評估，需要學習者擁有一定的搜索和選擇能力。問答社區(qū)內(nèi)容豐富，但初學者依然存在描述問題的困難，缺少從專業(yè)知識角度提出問題的能力。

相較于上述幾種學習方法，軟件開發(fā)初學者經(jīng)常需要借助實際的使用案例幫助理解特定工具或應用程序界面（Application Program Interface， API）的使用方法和調(diào)用規(guī)則。在開源社區(qū)海量的開源項目倉庫中，有廣闊的該類學習資源，但并未被很好地挖掘出來。軟件開發(fā)初學者依靠自身能力定位需要的API使用案例有一定的困難。

現(xiàn)有的代碼案例推薦服務(wù)研究中，傾向于構(gòu)建API功能描述或代碼功能描述，匹配用戶輸入，呈現(xiàn)給用戶片段式的代碼內(nèi)容。除官方文檔專業(yè)性強的描述文本外，片段式代碼的功能描述大多來自注釋。但在實際學習過程中，單函數(shù)的注釋并不能很好地體現(xiàn)代碼內(nèi)容在整體項目中的作用。本文面向擁有較少編碼經(jīng)驗且缺少軟件開發(fā)實戰(zhàn)經(jīng)驗的初學者，搜集了79份調(diào)查問卷，統(tǒng)計問卷參與者在單函數(shù)注釋對完成某一使用場景或功能的幫助效果上的意見，結(jié)果如表1所示。由表1可知，單片段的注釋傾向于表述函數(shù)承擔的細節(jié)任務(wù)，與項目實現(xiàn)的完整使用場景之間有一定的差別。

其次，軟件開發(fā)初學者缺少將不同代碼片段組建成完整功能模塊的能力。例如，如何將博客教程給出的碎片化功能函數(shù)實例，在實際項目中很好地組合復用，對于缺少經(jīng)驗的開發(fā)者來說有一定難度。又如，在面向?qū)ο缶幊踢^程中，開發(fā)者傾向于用不同代碼文件中定義的類成員函數(shù)共同實現(xiàn)項目的完整功能，單一片段的實例不足以幫助用戶理解它在整體項目中的復用方法。

表1　單函數(shù)注釋對完成某一使用場景或功能的幫助效果的問卷調(diào)查結(jié)果

為此，本文提出了一種基于開源社區(qū)分析的API使用案例推薦服務(wù)，為初學者提供快速定位特定API及某一使用場景案例，以及進行跨函數(shù)案例代碼學習的工具。

本文的主要工作包括：

1）提出了一種面向軟件開發(fā)初學者的API使用案例推薦服務(wù)，解決初學者學習軟件開發(fā)時難以獲取以使用場景為粒度劃分的參考案例的問題。

2）提出了一種基于開源社區(qū)分析的跨函數(shù)API使用案例構(gòu)造與分析方法，采用靜態(tài)代碼分析方法，從開源項目中抽取使用場景實例，進行面向用戶的評估與推薦。

1 相關(guān)工作

1.1　開源社區(qū)分析

迄今為止，以GitHub、Stack Overflow等平臺為研究對象的開源社區(qū)分析研究基本涵蓋到開發(fā)人員從入門到編碼、協(xié)作、測試的方方面面，其中包含了對于用戶、項目、問答內(nèi)容等不同方面的數(shù)據(jù)分析。一方面，研究人員利用現(xiàn)存的大量開源社區(qū)數(shù)據(jù)，針對用戶特性個性化推薦學習領(lǐng)域、協(xié)作人員，為待完成Issue或問答社區(qū)問題尋找可能的解答者，優(yōu)化社區(qū)人員體驗；另一方面，研究人員利用開發(fā)者已有的項目成果進行領(lǐng)域知識挖掘和文檔重構(gòu)，為開發(fā)者的學習、檢索和復用提供不同粒度的支撐。

Seker等［1］對于GitHub的已有研究進行了二次分析，對GitHub開源數(shù)據(jù)集GHTorrent上的重要研究內(nèi)容和較高質(zhì)量論文的主題分布進行了總結(jié)。最終，論文總結(jié)出四個主要主題：項目、用戶、數(shù)據(jù)及行為。每個主題都有多個相關(guān)子主題，如Issue、提交說明等，表明GitHub開源數(shù)據(jù)的流行研究方向和熱門課題。GHTorrent是目前使用最廣的GitHub開源數(shù)據(jù)集，在GitHub相關(guān)數(shù)據(jù)研究方面具有一定的代表性［2］。

在與開發(fā)者或?qū)W習者相關(guān)的研究課題中，主要研究內(nèi)容集中在開發(fā)者的輔助開發(fā)活動上。如陳丹等［3］對開源社區(qū)中已有開發(fā)者的合作行為模式做了分析，探索開發(fā)人員建立新合作關(guān)系的方式以及合作關(guān)系建立的影響因素。Rahman等［4］提出了一種代碼審核人員的推薦工具CORRECT，通過對開發(fā)人員跨項目的相關(guān)工作經(jīng)驗以及特定技術(shù)經(jīng)驗的分析，以推薦潛在的審核者。Montandon等［5］針對軟件開發(fā)者技術(shù)能力水平難以衡量的問題，提出了一種基于GitHub數(shù)據(jù)的特征聚類，實現(xiàn)在現(xiàn)今流行的庫和框架的開發(fā)人員中篩選專家級別的開發(fā)者的技術(shù)。此外，關(guān)聯(lián)多開源平臺進行數(shù)據(jù)分析與挖掘［6］，構(gòu)建開源社區(qū)數(shù)據(jù)集［7-8］，也是這方面研究的重要內(nèi)容。

綜合上述分析，對于軟件開發(fā)初學者而言，其學習需求并不需要很高專業(yè)度的人員才能滿足。如學習者通過博客和問答社區(qū)尋找答案，查找教程的過程中并不存在嚴格審查回答者技術(shù)能力的過程。其次，初學者在學習入門階段往往需要獨立學習，在獲得一定程度專業(yè)知識的基礎(chǔ)后再進行協(xié)作開發(fā)?，F(xiàn)有的開源社區(qū)分析研究并沒有在面向初學者的方向上幫助他們解決初步的入門問題，而是集中于提升其成為社區(qū)開發(fā)者后的開發(fā)體驗。

1.2　API推薦及代碼推薦

目前大量軟件開發(fā)集成工具包或API庫，給編碼人員的選擇帶來了一定的困難。如npm.js集成發(fā)布的JavaScript編程語言API，面對同一關(guān)鍵詞搜索下，同一功能的不同工具包，經(jīng)驗不足的學習者并不能快速確定目標并進行使用。

Zerouali等［9］的研究工作詳細分析了一個開源包的流行度衡量標準及影響因素，從GitHub、libraries.io和npm.js三個官方網(wǎng)站尋找指標數(shù)據(jù)，并分析它們之間的相關(guān)關(guān)系。但是結(jié)果表明，不同平臺的指標之間沒有太大的相關(guān)性，無法簡單通過單一指標得到普遍結(jié)果，需要經(jīng)過考量設(shè)計得到認可度高的評估選擇框架。

API推薦研究一般從開源問答社區(qū)、官方文檔和源代碼中提取有關(guān)API的語義，匹配用戶需求。張云帆等［10］的研究工作提出了一種基于自然語言語義相似度的推薦方法，通過查詢信息和描述信息的語義相似度進行推薦選擇。Lin等［11］設(shè)計了一種識別用戶查詢中包含潛在API的方法。從軟件源代碼中提取軟件實體概念以及它們之間的關(guān)系，填補互聯(lián)網(wǎng)上學習資源文檔中缺少的知識空白。

Huang等［12］的研究同樣致力于解決用戶查詢和API之間的匹配問題，將Stack Overflow和API文檔合并，利用Stack Overflow中的帖子補充API信息。類似的研究還有Nie等［13］提出的代碼搜索方法QECKRocchio。Xie等［14］的研究認為Stack Overflow問答社區(qū)涉及的API只包含大眾流行度較高的部分，而基于純文檔的API檢索又通常會產(chǎn)生較差的結(jié)果，所以試圖通過官方文檔構(gòu)建API功能描述輔助API檢索識別。

除此之外Shatnawi等［15-16］的研究認為，組件級別的代碼復用比原有的面向?qū)ο蟮膹陀酶佑行?。在組件粒度上的API方法具有其功能語義，并且在內(nèi)部結(jié)構(gòu)中展示出相互之間的依賴關(guān)系。Matos等［17］的研究從拆分大的API庫為小型API的目的出發(fā)，解決大型API復雜結(jié)構(gòu)使用戶很難快速學習和使用它們的問題。

在代碼推薦方面，楊程等［18］提出了一種基于多維特征的開源項目個性化推薦方法，從開源項目自身流行度、關(guān)聯(lián)項目技術(shù)相關(guān)度以及大眾貢獻者之間的社交關(guān)聯(lián)度這三個維度的特征衡量開發(fā)者和開源項目之間的關(guān)聯(lián)關(guān)系，為開發(fā)者提供個性化的項目推薦服務(wù)。Shen等［19］則設(shè)計了一種名為NLI2Code的抽象框架，通過基于庫文檔的功能特征提取、代碼模式挖掘及填補中間變量三步過程生成推薦代碼。Zimmerman等［20］則面向嘗試學習常見算法的新手程序員，基于圖形匹配和樹編輯的方法提出了一種識別正在編寫的代碼的可能目標，從而推薦編碼相關(guān)操作的框架。

綜合上述分析，現(xiàn)有API推薦研究的主流思想在于匹配用戶自然語言形式需求描述和API功能描述。通過開源代碼重新分析API之間的組合關(guān)系，挖掘可復用的使用模式是其中的核心研究內(nèi)容。代碼推薦則需要對可選項目給出一定的評價標準，可以是從API角度的調(diào)用分析，也可以是基于開發(fā)者本身、項目流行度等多維度特征設(shè)計出的評價指標，總體上多為單片段代碼推薦和生成，缺少跨函數(shù)的分析結(jié)果。對于代碼案例的功能描述，多從注釋獲取信息，片段性的解釋說明缺少對整體功能或場景的描述。對于初學者而言，這些不利于案例的理解與復用。

2 案例推薦服務(wù)的架構(gòu)

本文提出的案例推薦服務(wù)架構(gòu)如圖1所示。

圖1　案例推薦服務(wù)的系統(tǒng)架構(gòu)

2.1　案例構(gòu)造

2.1.1單函數(shù)片段抽取

在代碼或API推薦、檢索研究中，主要通過動詞短語的提取劃分功能或場景描述。本文對于使用場景的劃分，主要通過前后端交互的動詞形式監(jiān)聽接口實現(xiàn)。在實際開發(fā)過程中，開發(fā)者之間的協(xié)作要求和高質(zhì)量項目的嚴謹性，要求前后端交互的接口路徑名滿足一定的可理解性，并在語義上符合代碼實現(xiàn)內(nèi)容。因此，本文以后端項目為例，以前后端交互請求的接收為入口構(gòu)建案例。每一案例有統(tǒng)一明確的入口，其余用戶函數(shù)的調(diào)用也將符合該入口處的功能描述。

本文選擇Spring Boot框架實現(xiàn)的3 000個GitHub開源項目，識別監(jiān)聽接口注解代碼行并抽取其中的URL命名，通過駝峰命名法切詞并對特殊字符作額外處理，統(tǒng)計包含的動詞描述。在得到的結(jié)果中，選擇語義信息明確且擁有超過300個案例的動詞作為選定使用場景，得到的7個使用場景分類如表2。案例數(shù)量少于300的使用場景不能很好地滿足后續(xù)分析篩選的需要；同時，樣本數(shù)量在數(shù)據(jù)集中較少，也說明在開發(fā)過程中學習需求較低，我們優(yōu)先為初學者提供學習需求更大的場景選擇。

表2　不同使用場景下的案例數(shù)量

本文嘗試標注每一條識別到的注解所處的代碼文件，以及行標，以此匹配函數(shù)內(nèi)容。對于單個文件，通過抽象語法樹的分析和處理，將每一個函數(shù)方法按照一個整體剝離出來，識別每一行中各個元素的類別，并標注行數(shù)。對于這些含有文件即方法行數(shù)信息的函數(shù)處理結(jié)果，與注解相匹配，從而得到每個注解代表的請求入口函數(shù)片段。

抽取文件頭部引用的包及類，確定可選范圍，若是用戶類，則通過引入的名稱確定文件位置；若是API類，則留待后續(xù)API調(diào)用的提取和處理。同時，在代碼段內(nèi)，通過抽象語法樹分析每一行代碼，遍歷其中有關(guān)函數(shù)調(diào)用和類對象聲明部分，識別該代碼段是否引用了用戶函數(shù)。如果引用了用戶函數(shù)，則定位指示的用戶文件和用戶函數(shù)，從而得到將該函數(shù)片段加入同一案例代碼片段集合中。

每個使用場景分類下有多個候選案例，每個候選案例由一或多個代碼片段組成。對于每個代碼片段，抽取后續(xù)案例分析過程中需要的API調(diào)用信息。根據(jù)相關(guān)研究內(nèi)容及本文分析需要，給出以下節(jié)點和邊關(guān)系抽取規(guī)則：

1）節(jié)點分為以下幾種：API類對象聲明節(jié)點、API方法調(diào)用節(jié)點、參數(shù)生成和更改節(jié)點、用戶類對象聲明及更改節(jié)點。其中用戶類和用戶方法的節(jié)點便于不同文件代碼片段的關(guān)聯(lián)。

2）邊關(guān)系分為以下幾類：順序執(zhí)行連邊、依賴連邊、嵌套調(diào)用連邊。其中嵌套調(diào)用表示在一個方法中的參數(shù)部分調(diào)用了下一個方法。

根據(jù)以上規(guī)則，可將每個函數(shù)的代碼片段表示為圖結(jié)構(gòu)。如下所示代碼實例和圖2的調(diào)用圖實例表示，其中圖2為此代碼片段按照規(guī)則表示的調(diào)用圖。

@PostMapping（“/register”）

@ResponseBody

Public ResultVO register（User user）｛

userService.registerUser（user）；

return ResultUtils.success（）；｝

圖2　對象函數(shù)調(diào)用圖

2.1.2多函數(shù)片段融合

對于一個項目工程來說，一個使用場景的實現(xiàn)絕大多數(shù)情況下不可能單純通過一個函數(shù)完成，雖然我們的初步圖示在單個函數(shù)的粒度上構(gòu)建，但對于不同的函數(shù)的圖示，需要一個融合的過程。融合過程如圖3所示。在一個函數(shù)的圖結(jié)構(gòu)中，如果主體函數(shù)中識別到某個用戶函數(shù)的調(diào)用，則需要將該用戶函數(shù)的圖結(jié)構(gòu)加到主體函數(shù)圖結(jié)構(gòu)中。主體函數(shù)中，指向該用戶函數(shù)的節(jié)點，更改為指向用戶函數(shù)圖結(jié)構(gòu)的入口節(jié)點；主體函數(shù)中，該用戶函數(shù)指向的節(jié)點，改為由用戶函數(shù)圖結(jié)構(gòu)出口節(jié)點指向。圖3（b）中調(diào)用函數(shù)的節(jié)點在融合后消失，指向它的節(jié)點改為指向函數(shù)圖的入口節(jié)點，A函數(shù)圖的出口節(jié)點則改為指向原本主體函數(shù)中調(diào)用A函數(shù)的節(jié)點指向的節(jié)點。

圖3　融合前后的主體函數(shù)

2.2　案例分析

2.2.1案例相似度評估

基于抽象語法樹結(jié)構(gòu)統(tǒng)計特征向量［21］、基于調(diào)用序列挖掘頻繁模式挖掘［18，22-23］，都是常用的代碼流程圖降維分析方法。在此基礎(chǔ)上，Nguyen等［24］提出了更有彈性的圖方法進行模式挖掘和異常檢測任務(wù)。該團隊提出了具體的基于面向?qū)ο蟮脑创a構(gòu)建API方法調(diào)用圖規(guī)則和算法設(shè)計［25］。Gu等［26］的工作及Chen等［27］的工作都沿用了類似的思想，并采用了圖核［28］、圖卷積等方法進行API調(diào)用代碼分析。

本文采用圖核算法進行分析處理，沒有將圖結(jié)構(gòu)降維到向量空間的步驟，而是直接將核函數(shù)應用到圖結(jié)構(gòu)數(shù)據(jù)上，在很大程度上保留了結(jié)構(gòu)化信息，為跨函數(shù)代碼調(diào)用流程圖的分類和聚類提供重要的中間手段。

2.2.2聚類及推薦算法設(shè)計

在最短路徑核計算的相似度矩陣中，存在相似度基本為0的同一使用場景實現(xiàn)案例。對此，根據(jù)上述圖核計算得到的兩兩圖對之間的相似度矩陣，經(jīng)過譜聚類方法處理，采用類內(nèi)平均相似度比類間平均相似度作為判別指標初步劃分相似實現(xiàn)代碼，從而給用戶推薦每一相似實現(xiàn)方式集合下的最高推薦排序案例。

對于一個案例代碼，衡量它對于所屬類的代表性，本文參考Gu等［26］通過案例類內(nèi)中心性和特異性排序的方法，給出三個重要指標：

1）它在這個類別中的中心性，中心性越高，則該案例對于所屬類的代表作用越強。

2）它在這個類別中的特異性，特異性越高，它在這個類別中的代表性越低。比如一些不常調(diào)用的API，對于軟件開發(fā)初學者而言，增加了學習和理解的困難，因此需要降低它的推薦排名，盡量推薦更方便理解的開發(fā)案例。

3）在面向初學者時，API選擇的流行程度，越是被大多數(shù)項目選擇的API，在學習者學習使用場景開發(fā)時越有必要被推薦學習。

在按照上述推薦指標計算并排序得出的結(jié)果中，選擇每類得分前5的案例推薦給學習者。

2.3　案例推薦服務(wù)

初學者存在兩種類型的學習需求：第一種學習需求為選定目標API，學習其使用方式；第二種學習需求為不確定可用API，學習使用該框架或包進行場景或功能的實現(xiàn)。

本文設(shè)計的案例推薦服務(wù)允許用戶可選地指定API，并在已有的推薦排序結(jié)果中篩選符合項，給出包含該API應用的使用案例。同時，也為學習者提供從使用場景出發(fā)的案例推薦，學習者可以在學習過程中了解可用的API。

本文以Spring Boot為例，實現(xiàn)了API使用案例推薦服務(wù)初學者可以搜索指定的API、選擇使用場景并選擇學習該推薦服務(wù)所推薦的案例。圖4為推薦服務(wù)的案例學習界面，為用戶提供代碼片段、片段所在文件完整代碼及調(diào)用圖。用戶跳轉(zhuǎn)查看同意案例的不同片段，調(diào)用圖標注相應節(jié)點顏色。

圖4　推薦服務(wù)的案例學習界面

3 案例推薦服務(wù)驗證

3.1　用戶需求驗證

對于用戶需求的驗證，主要以調(diào)查問卷的形式進行，調(diào)查用戶對于實際案例輔助學習API效果的需求和本推薦服務(wù)所推薦的案例評價。

問卷面向某高校擁有一定編程經(jīng)驗的計算機專業(yè)本科生，共收集62份反饋結(jié)果，統(tǒng)計其中API學習方式使用情況和本文選取的使用場景是否符合用戶需求，具體結(jié)果如表3示。同時，給出本文推薦服務(wù)排序后選擇的推薦案例，統(tǒng)計有過后端開發(fā)經(jīng)驗的21人和沒有后端開發(fā)經(jīng)驗的41人的評價，結(jié)果如表4、表5所示。表中的“占比”均指相應項目評價人數(shù)占總調(diào)查人數(shù)的比例。

從表3～5可以看出，不論是后端框架的初學者還是已有一定技術(shù)知識儲備的學習者，本服務(wù)給出的推薦結(jié)果都有很高比例的認同，在幫助作用、代表性、可理解性上給出了較高評價。初學者在可理解性上的評價略低于有一定技術(shù)能力的學習者，有經(jīng)驗的學習者在幫助程度上的評價略低于初學者。這種調(diào)查結(jié)果符合預期，以及本推薦服務(wù)側(cè)重初學者的推薦特點。

表3　API學習方式和本文選取的使用場景的問卷收集部分結(jié)果

表4　無經(jīng)驗開發(fā)者評價結(jié)果

表5　有經(jīng)驗開發(fā)者評價結(jié)果

3.2　信息抽取驗證

本文信息抽取規(guī)則在已有研究的基礎(chǔ)上做了部分調(diào)整，用于后續(xù)分析處理。同時，以流程圖的形式隨案例一起推薦給用戶，輔助用戶理解案例內(nèi)容。本節(jié)主要審查本文抽取代碼行結(jié)果是否屬于案例及API使用的重點信息，審查中間過程。

選擇35個候選案例（每個場景分類下選擇5個），通過兩個對Java編程有三年以上經(jīng)驗且擁有后端開發(fā)經(jīng)驗的人員，標注他們所認為對該案例中體現(xiàn)API使用方法和邏輯框架的較重要的代碼行，代碼行數(shù)量為該案例中本文方法抽取結(jié)果行數(shù)上下浮動20%，比對結(jié)果如表6。其中的重合率為本文抽取的代碼行占標注者認為重要代碼行的比率。從表6結(jié)果可以看出，本文抽取內(nèi)容可以反映大部分案例代碼重點部分。標注結(jié)果和抽取結(jié)果差異性的造成有一定標注者總標注代碼行不確定的原因，使得選擇的代碼行比本文抽取內(nèi)容更精細或粗糙。

表6　信息抽取驗證結(jié)果

3.3　推薦結(jié)果驗證

第二部分驗證主要針對的是推薦服務(wù)的推薦結(jié)果是否具有代表性和可理解性，以及基于圖方法得出的結(jié)果與相關(guān)工作中采用特征向量抽取得到的結(jié)果相比是否具有更優(yōu)效果。由于選擇的Spring Boot后端框架項目代碼缺少量化的評價指標，因此選擇專家驗證的方式。

抽取本文推薦算法排序中排名最高的5個代碼案例，并在之后的代碼案例中隨機抽取20個。其次，在同樣的原始數(shù)據(jù)上通過特征向量主導的API特征向量抽取和處理得到推薦結(jié)果，并選擇同樣數(shù)量的驗證案例。由兩個有四年及以上Java編程經(jīng)歷，擁有Spring Boot開發(fā)實踐經(jīng)歷，且進行過三年及以上軟件開發(fā)實踐和實踐指導的人員對這些案例做出評價，具體評價指標如下：

1）選擇代碼案例中個人認為可理解性和代表性最佳的5個案例，并給出排序。結(jié)果顯示，案例與使用場景定義100%相符。這說明本文選擇的使用場景劃分方式能夠正確對應代碼案例內(nèi)容。

2）選擇代碼案例中個人認為可理解性和代表性最佳的10個案例，并給出排序，結(jié)果如表7所示，其中的命中率即專家在給出的推薦排序中，選中的服務(wù)推薦結(jié)果與最多可選中的推薦結(jié)果之比。由表7可知，本文基于圖方法得到的相似度度量和聚類排序，比通過特征向量抽取得到的結(jié)果認可度更高。后端API的開發(fā)實例，在保留結(jié)構(gòu)化信息的處理方法下，經(jīng)過篩選能得到更具有代表性的代碼案例。

表7　推薦案例專家驗證結(jié)果 單位： %

4 結(jié)語

本文提出了一種API學習案例推薦服務(wù)，相較于其他API及代碼推薦研究，本文沒有從單片段代碼出發(fā)進行分析挖掘，而是基于更大粒度的多函數(shù)功能模塊進行API推薦研究。同時，沒有通過單函數(shù)注釋抽取代碼功能描述，而是從監(jiān)聽請求入口，得到概括性語義特征。這種較高抽象粒度的場景選擇可以滿足初學者的大部分學習需求。例如，初學者嘗試構(gòu)建論壇式網(wǎng)絡(luò)應用，基本功能包括用戶的登錄注冊、帖子的發(fā)布刪除及搜索，均在本文所選使用場景的實現(xiàn)范圍之內(nèi)。

未來，我們將在以下方面進一步改進：首先，進一步細化使用場景的劃分。在實際學習過程中，學習者會有更細粒度的案例需求，如在學習注冊場景的實現(xiàn)時，允許指定常用注冊方式可以優(yōu)化用戶的體驗，提供更細粒度的幫助。其次，本文通過GitHub開源倉庫獲取候選案例，沒有經(jīng)過更精細的篩選，個別大型倉庫中同一類使用場景的案例數(shù)量較多，API用法相似，在相似性度量和聚類排序過程中存在一定優(yōu)勢，更易被選中作為推薦案例。在后續(xù)工作中，可以通過改進評價指標等方式彌補現(xiàn)有方法的不足。最后，本文選擇以Spring Boot為例實現(xiàn)推薦服務(wù)，而目前還有其他流行的API庫。結(jié)合多編程語言分析方法，可以在不同的前后端場景中實現(xiàn)案例構(gòu)造與分析處理。

[1] SEKER A， DIRI B， ARSLAN H， et al. Open source software development challenges： a systematic literature review on GitHub［J］. International Journal of Open Source Software and Processes， 2020， 11（4）： 1-26.

[2] GOUSIOS G， SPINELLIS D. GHTorrent： GitHub’s data from a firehose［C］// Proceedings of the 9th IEEE Working Conference on Mining Software Repositories. Piscataway： IEEE， 2012： 12-21.

[3] 陳丹，王星，何鵬，等. 開源社區(qū)中已有開發(fā)者的合作行為分析［J］. 計算機科學， 2016， 43（6A）：476-479， 501.（CHEN D， WANG X， HE P， et al. Towards understanding existing developers’ collaborative behavior in OSS communities［J］. Computer Science， 2016， 43（6A）：476-479， 501.）

[4] RAHMAN M M， ROY C K， REDL J， et al. CORRECT： code reviewer recommendation at GitHub for Vendasta technologies［C］// Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering. New York： ACM， 2016： 792-797.

[5] MONTANDON J E， SILVA L L， VALENTE M T. Identifying experts in software libraries and frameworks among GitHub users［C］// Proceedings of the IEEE/ACM 16th International Conference on Mining Software Repositories. Piscataway： IEEE， 2019： 276-287.

[6] MANES S S， BAYSAL O. How often and what StackOverflow posts do developers reference in their GitHub projects？［C］// Proceedings of the IEEE/ACM 16th International Conference on Mining Software Repositories. Piscataway： IEEE， 2019：235-239.

[7] BALTES S， DUMANI L， TREUDE C， et al. SOTorrent： reconstructing and analyzing the evolution of stack overflow posts［C］// Proceedings of the ACM/IEEE 15th International Conference on Mining Software Repositories. New York： ACM， 2018： 319-330.

[8] BALTES S， TREUDE C， DIEHL S. SOTorrent： studying the origin， evolution， and usage of stack overflow code snippets［C］// Proceedings of the IEEE/ACM 16th International Conference on Mining Software Repositories. Piscataway： IEEE， 2019： 191-194.

[9] ZEROUALI A， MENS T， ROBLES G， et al. On the diversity of software package popularity metrics： an empirical study of NPM［C］// Proceedings of the IEEE 26th International Conference on Software Analysis， Evolution and Reengineering. Piscataway： IEEE， 2019： 589-593.

[10] 張云帆，周宇，黃志球. 基于語義相似度的API使用模式推薦［J］. 計算機科學， 2020， 47（3）： 34-40.（ZHANG Y F， ZHOU Y， HUANG Z Q. Semantic similarity based API usage pattern recommendation［J］. Computer Science， 2020， 47（3）： 34-40.）

[11] LIN Z Q， ZOU Y Z， ZHAO J F， et al. Improving software text retrieval using conceptual knowledge in source code［C］// Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering. Piscataway： IEEE， 2017： 123-134.

[12] HUANG Q， XIA X， XING Z C， et al. API method recommendation without worrying about the task?API knowledge gap［C］// Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering. Piscataway： IEEE， 2018： 293-304.

[13] NIE L M， HE J， REN Z L， et al. Query expansion based on crowd knowledge for code search［J］. IEEE Transactions on Services Computing， 2016， 9（5）： 771-783.

[14] XIE W K， PENG X， LIU M W， et al. API method recommendation via explicit matching of functionality verb phrases［C］// Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. New York： ACM， 2020： 1015-1026.

[15] SHATNAWI A， SHATNAWI H， SAIED M A， et al. Identifying software components from object?oriented APIs based on dynamic analysis［C］// Proceedings of the 2018 ACM/IEEE 26th International Conference on Program Comprehension. New York： ACM， 2018：189-199.

[16] SHATNAWI A， SERIAI A， SAHRAOUI H， et al. Mining software components from object?oriented APIs［EB/OL］. （2016-06-02）［2021-05-06］. https：//arxiv.org/pdf/1606.00561.pdf.

[17] MATOS A S， FERREIRA FILHO J B， ROCHA L S. Splitting APIs： an exploratory study of software unbundling［C］// Proceedings of the 2019 IEEE/ACM 16th International Conference on Mining Software Repositories. Piscataway： IEEE， 2019： 360-370.

[18] 楊程，范強，王濤，等. 基于多維特征的開源項目個性化推薦方法［J］. 軟件學報， 2017， 28（6）： 1357-1372.（YANG C， FAN Q， WANG T， et al. Multi?feature based personal recommendation approach for open source project［J］. Journal of Software， 2017， 28（6）： 1357-1372.）

[19] SHEN Q， XIE B， ZOU Y Z， et al. NLI2Code： reusing libraries with natural language interface［C］// Proceedings of the 2019 International Conference on Software and Systems Reuse， LNCS 11602. Cham： Springer， 2019： 168-184.

[20] ZIMMERMAN K， RUPAKHETI C R. An automated framework for recommending program elements to novices［C］// Proceedings of the 30th IEEE/ACM International Conference on Automated Software Engineering. Piscataway： IEEE， 2015： 283-288.

[21] KIM J， LEE S， HWANG S W， et al. Enriching documents with examples： a corpus mining approach［J］. ACM Transactions on Information Systems， 2013， 31（1）： No.1.

[22] ZHONG H， XIE T， ZHANG L， et al. MAPO： mining and recommending API usage patterns［C］// Proceedings of the 2009 European Conference on Object?Oriented Programming， LNCS 5653. Berlin： Springer， 2009： 318-343.

[23] WANG J， DANG Y N， ZHANG H Y， et al. Mining succinct and high?coverage API usage patterns from source code［C］// Proceedings of the 10th Working Conference on Mining Software Repositories. Piscataway： IEEE， 2013： 319-328.

[24] NGUYEN T T， NGUYEN H A， PHAM N H， et al. Graph?based mining of multiple object usage patterns［C］// Proceedings of the 7th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering. New York： ACM， 2009： 383-392.

[25] NGUYEN T T， PHAM H V， VU P M， et al. Learning API usages from bytecode： a statistical approach［C］// Proceedings of the IEEE/ACM 38th International Conference on Software Engineering. New York： ACM， 2016： 416-427.

[26] GU X D， ZHANG H Y， KIM S. CodeKernel： a graph kernel based approach to the selection of API usage examples［C］// Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering. Piscataway： IEEE， 2019： 590-601.

[27] CHEN C， PENG X， XING Z C， et al. Holistic combination of structural and textual code information for context based API recommendation［J］. IEEE Transactions on Software Engineering， 2022， 48（8）： 2987-3009.

[28] BORGWARDT K M， KRIEGEL H P. Shortest?path kernels on graphs［C］// Proceedings of the 5th IEEE International Conference on Data Mining. Piscataway： IEEE， 2005： 74-81.

Recommendation service for API use cases based on open source community analysis

ZHANG Jiaqi1，2， SUN Yanchun1，2*， HUANG Gang1，2

（1，，100871，；2（），100871，）

Current research on Application Program Interface （API） learning and code reuse focuses on mining frequent API usage patterns， extracting component information， and recommending personalized API services based on user requirements and target functions. However， as beginners in software development who lack professional knowledge， experience and skills to implement specific use cases， they often need real code use cases as a reference except reading official documents. Most of the existing research about code recommendation is in single fragment mode. The lack of cross function case in case selection is not conducive for beginners to learn to build a complete use scenario or a functional module. At the same time， the semantic description extracted from a single function annotation is not enough for learners to understand the complete function implementation method of the project. To solve the above problems， an API use case recommendation service based on open source community analysis was proposed. Taking the software development back?end framework Spring Boot as an example， a cross function case recommendation assistant learning service was constructed. Then， the feasibility and effectiveness of the proposed API use case recommendation service was verified through questionnaires and expert verification.

code reuse; Application Program Interface (API); open source community analysis; recommendation service; use case

This work is partially supported by Beijing Outstanding Young Scientist Program （BJJWZYJH01201910001004）.

ZHANG Jiaqi， born in 1999， M. S. candidate. Her research interests include service computing， big data analysis.

SUN Yanchun， born in 1970， Ph. D.， associate professor. Her research interests include service computing， big data analysis.

HUANG Gang， born in 1975， Ph. D.， professor. His research interests include system software， self?adaption.

1001-9081（2022）11-3520-07

10.11772/j.issn.1001-9081.2021122070

2021?12?07；

2022?01?02；

2022?01?13。

北京高等學校卓越青年科學家項目（BJJWZYJH01201910001004）。

TP311

A

張佳琪（1999—），女，河北石家莊人，碩士研究生，主要研究方向：服務(wù)計算、大數(shù)據(jù)分析；孫艷春（1970—），女，遼寧沈陽人，副教授，博士，CCF高級會員，主要研究方向：服務(wù)計算、大數(shù)據(jù)分析；黃罡（1975—），男，湖南株洲人，教授，博士，CCF會員，主要研究方向：系統(tǒng)軟件、自適應。