張佳琪，孫艷春*，黃罡

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

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

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

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

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

0 引言

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

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

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

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

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

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

本文的主要工作包括：

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

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

1 相關(guān)工作

1.1　開源社區(qū)分析

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

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

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

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

1.2　API推薦及代碼推薦

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

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

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

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

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

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

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

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

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

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

2.1　案例構(gòu)造

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

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

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

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

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

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

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

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

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

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

@PostMapping（“/register”）

@ResponseBody

Public ResultVO register（User user）｛

userService.registerUser（user）；

return ResultUtils.success（）；｝

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

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

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

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

2.2　案例分析

2.2.1案例相似度評(píng)估

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

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

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

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

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

1）它在這個(gè)類別中的中心性，中心性越高，則該案例對(duì)于所屬類的代表作用越強(qiáng)。

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

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

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

2.3　案例推薦服務(wù)

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

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

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

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

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

3.1　用戶需求驗(yàn)證

對(duì)于用戶需求的驗(yàn)證，主要以調(diào)查問卷的形式進(jìn)行，調(diào)查用戶對(duì)于實(shí)際案例輔助學(xué)習(xí)API效果的需求和本推薦服務(wù)所推薦的案例評(píng)價(jià)。

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

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

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

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

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

3.2　信息抽取驗(yàn)證

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

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

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

3.3　推薦結(jié)果驗(yàn)證

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

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

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

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

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

4 結(jié)語

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

未來，我們將在以下方面進(jìn)一步改進(jìn)：首先，進(jìn)一步細(xì)化使用場景的劃分。在實(shí)際學(xué)習(xí)過程中，學(xué)習(xí)者會(huì)有更細(xì)粒度的案例需求，如在學(xué)習(xí)注冊(cè)場景的實(shí)現(xiàn)時(shí)，允許指定常用注冊(cè)方式可以優(yōu)化用戶的體驗(yàn)，提供更細(xì)粒度的幫助。其次，本文通過GitHub開源倉庫獲取候選案例，沒有經(jīng)過更精細(xì)的篩選，個(gè)別大型倉庫中同一類使用場景的案例數(shù)量較多，API用法相似，在相似性度量和聚類排序過程中存在一定優(yōu)勢，更易被選中作為推薦案例。在后續(xù)工作中，可以通過改進(jìn)評(píng)價(jià)指標(biāo)等方式彌補(bǔ)現(xiàn)有方法的不足。最后，本文選擇以Spring Boot為例實(shí)現(xiàn)推薦服務(wù)，而目前還有其他流行的API庫。結(jié)合多編程語言分析方法，可以在不同的前后端場景中實(shí)現(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］. 計(jì)算機(jī)科學(xué)， 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] 張?jiān)品?，周宇，黃志球. 基于語義相似度的API使用模式推薦［J］. 計(jì)算機(jī)科學(xué)， 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] 楊程，范強(qiáng)，王濤，等. 基于多維特征的開源項(xiàng)目個(gè)性化推薦方法［J］. 軟件學(xué)報(bào)， 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。

北京高等學(xué)校卓越青年科學(xué)家項(xiàng)目（BJJWZYJH01201910001004）。

TP311

A

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