面向專家示例的Stack Overflow本體構造和推理研究

阮書鶴 鐘林輝 高榮錦 祝艷霞 陳浩然 盧騰駿 夏子豪

摘 要：Stack Overflow是一個計算機領域的IT技術問答網站，為了獲取問答網站中的專家示例并將其應用于API挖掘中。首先采用Scrapy爬蟲框架技術獲取Stack Overflow問答網站中的結構化數據，并存儲在關系模式中；再使用本體建模工具Protégé構建本體，然后使用D2RQ工具實現對關系數據庫的知識抽取，將關系模式轉換為三元組形式的本體模型；同時，提出了一個面向專家示例的子本體抽取算法，用于從原本體中抽取出專家示例推理相關的子本體，并提出了若干條專家示例推理規則，能推導出專家所編寫的代碼示例。實驗結果證明，從Stack Overflow本體模型中抽取的專家示例能提高API調用序列挖掘的準確率。

關鍵詞：Stack Overflow問答網站； 本體； 本體構建； 專家示例推理規則； 專家示例

中圖分類號：TP391?? 文獻標志碼：A?? 文章編號：1001-3695（2023）12-033-3736-06

doi：10.19734/j.issn.1001-3695.2023.03.0145

Research on expert code example oriented ontology construction and reasoning for Stack Overflow

Abstract：Stack Overflow is an IT technology Q&A website in the computer field. In order to obtain expert examples in the Q&A website and apply them to API mining， this paper firstly used the Scrapy crawler framework technology to obtain structured data in the Stack Overflow Q&A website and store it in the relational model. Then it used the ontology modeling tool Protégé to build the ontology， and then used the D2RQ tool to achieve the knowledge extraction of the relational database， and transformed the relational model into the ontology model in the form of triplets. At the same time， this article proposed a sub ontology extraction algorithm for expert examples， and used it to extract sub ontologies related to expert example reasoning from the original ontology， and proposed several expert example reasoning rules that could derive expert examples. The experimental results demonstrate that extracting expert examples from the Stack Overflow ontology model can improve the accuracy of API call sequence mining.

Key words：Stack Overflow Q&A website; ontology; ontology construction; expert example reasoning rules; expert example

0 引言

用戶是Stack Overflow社區的參與者，在社區用戶可以發表帖子、提出相關問題、回答相關問題、對帖子進行投票、發表評論和編輯帖子等操作，實現用戶之間的交互和知識的分享。然而，目前針對Stack Overflow的本體建模研究還比較少，特別是面向特定領域的Stack Overflow本體建模尚未有研究，例如面向API領域，能挖掘出有價值的、專家書寫的代碼示例。因此，本文以Stack Overflow問答網站的數據信息為研究對象，利用本體建模工具Protégé構建Stack Overflow問答網站本體模型；然后，為了實現面向API領域的知識共享和利用，即通過規則推理方法獲取Stack Overflow問答網站中的專家示例，本文提出了一個Stack Overflow子本體抽取算法，篩選出API挖掘時所需的推導專家示例有關的本體；最后介紹了推理出有價值的專家示例的推理規則，并在API挖掘中的實驗驗證其過程及效果。

1 本體構建相關研究

領域本體指的是專業性的本體，其描述的是特定領域中概念與概念之間的關系。構建領域本體能夠更為合理有效地進行知識表示。

文獻［1］在基于構件的軟件配置管理模型的基礎上，設計了構件化軟件演化信息本體模型，提出了構件化軟件共同變化模式和相應的本體推理規則。文獻［2］通過Stack Overflow問答社區中的架構知識概念開發了一個本體，該本體捕獲了架構相關的信息，并支持實現從業者的需求和關注點。文獻［3］設計了構件化軟件演化信息本體模型，并提出了構件化軟件的共同變化模式和相應的本體推理規則。文獻［4］提出了一種基于多類軟件本體的惡意軟件語義描述模型，基于OWL本體的知識表示方法，通過軟件行為和軟件結構信息實現對惡意軟件語義的描述。文獻［5］提出了一個軟件安全模式的本體，對安全需求、安全模式以及應用環境進行語義建模，在此基礎上定義推理規則，利用Jena推理機實現了一個安全模式的查詢系統。文獻［6］建立了一個軟件安全性需求本體模型，實現了軟件安全性需求形式化建模和驗證的工具原型。文獻［7］提出了一個支持軟件知識共享的本體模型，根據軟件開發知識的內容、特點以及它們之間的關系，對軟件開發知識進行了形式化的表示，并創建了軟件開發知識本體和軟件開發知識本體規則。本文主要研究如何構建計算機領域的Stack Overflow問答網站本體，并通過規則推理方法得到專家示例。

2 Stack Overflow本體模型的構建

2.1 Stack Overflow本體構建流程

本文在七步法的基礎上提出的Stack Overflow本體構建的詳細流程如圖1所示。

在第一步中，本文明確了需要構建的本體模型的領域和范疇，即本文構建的是面向API挖掘和代碼示例的Stack Overflow問答網站本體模型。

在第二步中，本文查閱并借鑒了關于Stack Overflow問答網站知識圖構建的文獻，并從文獻［8］中借鑒了已有的研究內容，復用了部分作為本體內容。

在第三～六步中，本文通過分析爬取的Stack Overflow問答網站結構化數據，從中提取并列出本體中的重要概念和術語，從而完成了本體概念以及概念間層次關系、數據屬性關系、對象屬性關系的定義。在完成Stack Overflow本體模型的構建工作后，本文進行了本體模型的檢驗工作，即通過Protégé本體建模工具中自帶的HermiT推理機進行推理檢驗，從而修正并完善Stack Overflow本體模型。

在第七步中，本文通過D2RQ工具將存儲在關系數據庫中的數據轉換為三元組形式的本體數據，由此完成本體實例化的工作。

2.2 問答數據的獲取

本文為了能夠實時獲取最新的問答信息數據，采用Scrapy框架來爬取Stack Overflow帖子的詳情數據。通過Stack Overflow網頁中問題的標簽信息來篩選獲取Java相關技術框架，如Netty、Apachecamel、drools等代碼示例等信息。但是Stack Overflow社區中存在大量沒有用戶回答的待解決的問題帖，以及部分帖子只有自然語言描述的回答內容，回答用戶沒有編寫相關代碼示例。對于這類數據信息，本文將它們從數據樣本中刪除。此外，本文還對有代碼示例回答信息的帖子進行初步篩選，主要是通過正則表達式將較完整的代碼示例篩選出來。獲取的數據集如表1所示。

2.3 Stack Overflow問答社區本體模型的構建實現

Stack Overflow問答社區的本體模型描述了Stack Overflow問答社區中的各個概念之間的關系。文獻［8］面向開源軟件項目構建了一個軟件知識圖譜，其中有四種不同類型的軟件資源，包括了對問答文檔的軟件知識實體的提取以及問答文檔知識實體之間關系的建立。該文獻問答信息的獲取也是來自于Stack Overflow問答網站。本文借鑒了文獻［8］中建立的問答文檔知識圖，并在其研究結果的基礎上提出了自己的內容，再結合經典的領域本體的構建方法——七步法，最終完成了本體模型的構建。對于文獻［8］中提出的問答文檔知識圖和本文提出的Stack Overflow本體的不同之處，將在圖2進行表示。圖2中紅色實線標記的地方為本文不同于文獻［8］的內容，用藍色虛線標記的為文獻［8］獨有的內容，黑色實線標記為共有內容（參見電子版）。

2.3.1 概念

在本文構建的Stack Overflow問答社區本體模型中一共描述了16個概念，分別是文本回答（answer）類、代碼示例（code）類、評論（comment）類，以及它的兩個子類（回答評論（answer_comment）類和問題評論（question_comment）類）、問題（question）類、標簽（tag）類、用戶（user）類，以及它的四個子類（編輯用戶（editor）類、提問用戶（questioner）類、回答用戶（respondent）類、評論用戶（reviewer）類）。其中，編輯用戶類包含問題編輯用戶（question_editor）類和回答編輯用戶（answer_editor）類兩個子類，評論用戶類包含問題評論用戶（question_reviewer）類和回答評論用戶（answer_reviewer）類兩個子類。在圖2中，本文描述的概念都用紅色標記的矩形表示。文獻［8］的問答信息數據是通過下載第三方網站發布的數據包獲取的，提取出了問題、答案、問答評論、問答用戶共四個實體（圖2中被藍色虛線標記屬性的實體）。由于本文構建的是面向API挖掘領域的Stack Overflow本體模型，主要是為了能夠從本體模型中通過推理得到專家示例，所以問答帖的回答用戶信息和他們編寫的代碼示例信息是本文必須得到的重要信息內容。因此本文將答案實體類分為文本回答類和代碼示例類。表2為Stack Overflow問答社區本體模型主要概念的詳細介紹。

2.3.2 對象屬性關系

本模型包含15個對象屬性關系，分別是ask、associated_with、belong_to、comment及其子關系commentQuestion和commentAnswer、compile、write、corresponding_to、edit及其子關系editQuestion和editAnswer、hasComment及其子關系hasQuestion Comment和hasAnswerComment。表3介紹了主要的對象屬性關系。在圖2中，本文將對象屬性關系用紅色帶箭頭的實線和紅色英文字體標注。文獻［8］則只是定義了四個關聯關系，分別是問題和答案之間的“答案關系”，問題和問答評論以及答案和問答評論之間的“評論關系”，問題和問題間的“重復關系”，問答用戶和問題、問答用戶和答案、問答用戶和問答評論之間的“作者關系”。在圖2中，本文將這四個關聯關系用藍色虛線和藍色字體標注。

除了以上說明的15個對象屬性關系之外，每個對象屬性關系都有它們相對應的逆關系，例如ask的逆關系為beAskedBy，表示問題被問題用戶提出；belong_to的逆關系為包含（contain），表示一個標簽包含了多個具體的問題；comment的逆關系為beCommentedBy，表示評論被評論用戶提出；對象屬性關系中的associated_with 和corresponding_to相對特殊，它們具有對稱性（symmetric）。

2.3.3 數據屬性關系

本文根據獲取的Stack Overflow問答信息數據總結出的部分主要的數據屬性關系如表4所示。文獻［8］表述的問答文檔的軟件知識實體的屬性信息和本文表述的問答社區本體中的數據屬性關系大部分相同，其中問題實體的屬性有標題、內容、評分等，答案實體的屬性有答案內容、評分等，評論實體的屬性有評論內容、評分等，用戶實體的屬性有用戶顯示名稱、用戶聲望等，這些屬性的含義都與本文中所描述的相關數據屬性關系一致。在圖2中，屬性都由橢圓表示，其中黑色標記的橢圓為共有的屬性，藍色虛線標記的橢圓為文獻［8］中描述的而本文沒有的屬性，紅色實線標記的橢圓為本文提出的屬性。

2.4 基于關系數據庫的知識抽取

為了自動地構建獲取的數據（2.1節）與本體模式（2.2節）之間的映射關系，本文將獲取的問答社區數據信息存儲在MySQL關系數據庫中，并利用D2RQ工具來完成這一操作步驟。D2RQ是目前主流的關聯數據發布工具之一，通過類與屬性的映射實現關系數據庫向RDF關聯數據格式的轉換與發布，同時支持SPARQL語言的語義檢索與查詢［9］。本文利用D2RQ對關系數據庫進行知識抽取，即通過一個可個性化定制的D2RQ mapping file，這個映射文件通過一系列映射規則生成，再利用D2RQ引擎對映射文件中的規則進行解析，最后將關系數據庫中的數據轉換為RDF形式的三元組本體數據。

基于上一節中提到的本體概念模型，本文在MySQL關系數據庫中構建了與實體類相對應的數據表，如answer、question、code、questioner、respondent、tag等，數據表中的字段對應本體中的屬性；除此之外，本文另外單獨建了數據表來表示實體類中多對多的對象屬性關系，如數據表question_to_tag存儲的是問題類與標簽類之間的多對多關系。answer實體類的部分映射代碼如下所示。

# table answer

map：answer a d2rq：ClassMap; // 定義answer類

d2rq：dataStorage map：database;

d2rq：uriPattern "answer/@@answer.answer_id@@";

d2rq：class ：answer;

d2rq：classDefinitionLabel "answer";

map：answer_question_id__ref a d2rq：PropertyBridge;

d2rq：belongsToClassMap map：answer;

d2rq：property ：associated_with; // 對象屬性名

d2rq：refersToClassMap map：question;

d2rq：join"answer.question_id=>question.question_id";

3 面向專家示例的Stack Overflow子本體抽取算法

3.1 算法思想

子本體抽取是指從某個基礎性的源本體抽取出來的獨立完整的，且能滿足特定需要的子本體，其中源本體中被抽取的部分在子本體中被重用。為了便于后面本體推理研究工作中專家示例的推理，提出了一個Stack Overflow子本體抽取算法用于將本文推理專家示例時需要的本體內容（如代碼示例等）抽取出來。Stack Overflow子本體抽取算法對應的偽代碼如下：

算法 將Stack Overflow本體中對本文后續的專家示例推理工作用不到的概念及其實例、屬性以及實例間的關系進行刪除，得到一個便于專家示例推理的Stack Overflow子本體

輸入：n個概念節點元組T1=（null，conceptName），…，Tn；（1≤n≤16）。

輸出：本體連通子圖G1={G1.V，G1.E}。

begin

讀取Stack Overflow本體文件，Stack Overflow本體表示為S={C，R1，R2，H，P，K，D}，其中C為概念，D為概念與其下屬實例間的關系，P為屬性，H為實例，K為實例與屬性間的關系，R1為概念間的關系，R2為實例間的關系；

將Stack Overflow本體映射為連通圖G={G.V，G.E}，頂點G.V={C，H，P}，邊G.E={R1，R2，K，D}；

對概念C映射的節點添加標簽來進行分類，用概念名（conceptName）進行標記，其中概念節點表示為元組T=（null，conceptName），其下屬的實例節點表示為T′=（instance information，conceptName），該實例節點被標記的概念名就表示該節點歸屬哪一類，instance information存儲的是實例信息；

list need_list=new ArrayList（）; /*構造一個空列表用于存儲需要的本體概念節點*/

need_list.add（T）;

for（G） //遍歷連通圖G中的節點

for（need_list） //遍歷所需的本體概念列表

if（列表中T的概念名標簽和圖G中T的概念名標簽不匹配） //該節點不需要

findEntity（T′，T）; //找到此概念節點下屬的實例節點

findProperty（P，T′） //找到實例節點有關的屬性節點

deleteNode（P） //刪除屬性節點

deleteNode（T′） //刪除實例節點

deleteNode（T） //刪除此概念節點

return G1={G1.V，G1.E} ?/*得到新的連通子圖G1，G1.V，G1.E為本文保留的節點集和邊集*/

end if

end for

end for

end

該算法的輸入是概念節點元組T=（null，conceptName），輸出是用戶自己想要的Stack Overflow子本體連通圖G1={G1.V，G1.E}。算法首先通過讀取本體文件，根據本體模型將概念映射為節點，概念間的關系映射為邊來構建一個連通圖；隨后對連通圖中的節點進行標簽標記，以它們的概念名如用answer進行標記answer這個概念節點以及它下屬的各個實例節點；隨后用戶將自己需要的概念節點加入列表中，再根據列表和圖將用戶不需要的概念節點以及其下屬的實例節點和屬性節點進行刪除，形成新的原連通圖的子圖；最后將最終的連通子圖還原為子本體模型。

3.2 算法抽取結果

該算法是裁剪專家示例推理工作中不需要用到的冗余的本體內容，以此來抽取出一個便于專家示例獲取的Stack Overflow子本體。而在本文后續工作提出的專家示例規則推理方法中沒有用到的本體實體類有question_comment、answer、reviewer、question_reviewer、answer_reviewer。經過算法抽取出的便于專家示例規則推理方法推導的Stack Overflow子本體結構如圖3所示。

本文使用構建的本體數據進行Stack Overflow子本體抽取算法的驗證，主要統計了本體數據中的實例個數、關系的個數（實例與實例間的關系和實例與屬性間的關系的個數）、屬性個數、概念個數。Stack Overflow子本體抽取算法的抽取結果如表5所示。

4 專家示例推理規則及應用

本文根據提出的專家示例推理規則從本體數據模型中推理得到專家示例，再將專家示例應用于本研究團隊之前開發的BEMiner挖掘［10］中，以此驗證本文得到的專家示例是否有價值。

專家示例指的是問答網站中專家用戶編寫的高質量的代碼示例。Stack Overflow擁有一個協作編輯功能，允許整個社區共同編輯問題和答案。Stack Overflow問答社區的官方對協作編輯的描述為：一旦用戶獲得足夠的聲譽（2 000聲譽值以上），問答社區相信該用戶能夠編輯社區中的內容，如果該用戶看到了需要改進的地方，鼓勵用戶進行編輯改進。他們認為編輯對于保持問題和答案的清晰性、相關性和最新程度很重要。根據對Stack Overflow問答網站協作編輯功能的研究，本文初步認為被編輯過的帖子內容的質量可能比較好，判斷Stack Overflow中的代碼示例是專家示例有以下標準：a）被編輯后的代碼示例是高質量代碼示例且編輯的用戶是專家用戶；b）代碼示例解決的是一個高質量且受歡迎的問題，并且該問題是被一名專家用戶所編輯過的。此外Stack Overflow也存在一個投票機制，用戶可以對問答網站中的問題以及回答內容進行投票，而投票數高的內容則可以作為被許多用戶接受的高質量內容。

本文將Stack Overflow中的專家用戶定義為能夠提供高質量答案并且對問答社區作出了許多貢獻的用戶。Stack Overflow也有一個聲譽系統，聲譽系統用于衡量和鼓勵用戶對社區的貢獻，用戶的行為和專業知識會得到聲譽系統的認可和獎勵。用戶通過提出好的問題、回答有用的答案、對他人的答案或者回答的質量進行投票以及通過其他一些網站允許的活動來獲得聲譽。Stack Overflow社區官方對聲譽的解釋是：聲譽粗略地衡量了社區對用戶的信任程度。聲譽越高的用戶也可以享有更多的網站特權。除了通過問答獲得聲譽，用戶還會因一些特別的幫助或者貢獻而獲得相應的徽章。徽章分為青銅徽章、銀徽章和金徽章三種。用戶所獲的徽章在一定程度上也能反映用戶的專業知識水平以及對社區的貢獻程度。因此本文將聲譽值以及徽章數達到一定數量的用戶作為專家用戶。

4.1 專家示例推理規則

本文提出的專家示例推理規則是由基于Jena的自定義推理規則與基于度量的規則相結合的推理規則兩種基本推理規則構成，其中部分基于Jena自定義推理規則如下所示。

rule1：［（？c：beEditedAnswerBy ？e），（？c：associated_with ？q），（？q：belong_to ？t） ->（？c：is_candidate_expertCode_of ？t）］

規則1是關于被編輯過的回答的自定義規則。若代碼示例c已被回答編輯用戶編輯審查，且代碼示例c是關于解決問題q的代碼示例，問題q又屬于技術領域標簽t，那么可以推導出代碼示例c是關于技術領域標簽t的候選專家示例。

rule2：［（？q：beEditedQuestionBy ？e），（？q：belong_to ？t） ->（？q：isHQ_of ？t）

（？q：isHQ_of ？t） ->（？t：hasHQ ？q）

（？t：hasHQ ？q），（？q：associated_with ？c） ->（？t：has_candidate_expertCode ？c）］

規則2是根據高質量問題來獲取候選的專家示例。若問題q被問題編輯用戶e編輯審查過，且問題q屬于技術領域標簽t，則可以得出問題q是關于技術領域標簽t的高質量問題的新關系；問題q是關于技術領域標簽t的高質量問題關系的逆關系：技術領域標簽t擁有高質量問題q；若技術領域標簽t擁有高質量問題q，而高質量問題q擁有能夠解決問題的代碼示例c，那么技術領域標簽t擁有候選專家示例c。

上述基于Jena的推理規則得到的是候選的專家示例，而候選的專家示例還需經過度量規則的檢驗才能得到最終的專家示例。本文提出的度量規則主要是根據用戶的聲譽值和徽章數等屬性來判斷專家用戶，以及根據代碼示例的投票數屬性及計算其質量分數來作為代碼示例質量的參考標準，其中部分基于度量的推理規則如下所示。

rule3： ［IF （ae_reputation>=AVG（ae_AllReputation） AND ae_gold>=AVG（ae_AllGold） AND ae_silver>=AVG（ae_AllSilver） AND ae_bronze>=AVG（ae_AllBronze）） THEN expertUserList.add（answer_editor）.］

rule4：［IF （qe_reputation>=AVG（qe_AllReputation） AND qe_gold>=AVG（qe_AllGold） AND q_silver>=AVG（q_AllSilver） AND qe_bronze>=AVG（qe_AllBronze）） THEN expertUserList.add（question_editor）.］

規則3和4都是推導專家用戶的度量規則。規則3表示將聲譽值（ae_reputation）和徽章數（ae_gold、ae_silver、ae_bronze）都大于平均度量值的回答編輯用戶作為專家用戶；規則4則表示的是將聲譽值（qe_reputation）和徽章數（qe_gold、qe_silver、qe_bronze）都大于平均度量值的問題編輯用戶作為專家用戶。

rule5：［IF （questionVote>=AVG（allQuestionVote） AND answerCount>=AVG（allAnswerCount） AND bookmarkNum>=AVG（allBookmarkNum）） Then goodQuestionList.add（q），candidateExpertCodeList.add.add（code（q））.］

規則5表示將問題投票數、回答數和書簽數（questionVote、answerCount、bookmarkNum）都高于平均度量標準的問題作為受歡迎且高質量的問題，而能夠解決這類問題的代碼示例則作為候選專家示例。

rule6：［IF （Q>=AVG（Q） AND re_AnswerVote>=AVG（AnswerVote）） THEN candidateExpertCodeList.add（code）.］

規則6表示將代碼質量分數（Q）和回答投票數（Answer Vote）都高于其平均度量值的代碼示例作為候選專家示例。其中本文采用IntelliJ IDEA的自動化源代碼度量插件MetricsReloaded來計算代碼質量分數，主要通過Java代碼中的函數參數個數（PARA）、注釋率（COMF）、函數中非結構化語句的數量、函數中的可執行語句數（STMT）、圈復雜度（v（G））、基本復雜度（ev（G））、模塊設計復雜度（iv（G））等計算評估后得到。

根據以上六條基本推理規則，本文得到了兩條專家示例推理規則，具體如下所示。

R1：［IF （？c ：is_candidate_expertCode_of ？t） AND （ae_reputation>=AVG（ae_AllReputation） AND ae_gold>=AVG（ae_AllGold） AND ae_silver>=AVG（ae_AllSilver） AND ae_bronze>=AVG（ae_AllBronze）） AND （Q>=AVG（q） AND re_AnswerVote>=AVG（AnswerVote）） THEN ExpertCodeList.add（c）.］

專家示例推理規則R1是由rule1、rule3、rule6三條基本規則組合得到的，其表示的是若在本體中存在本體關系：代碼示例c是技術標簽t的候選專家示例，并且代碼示例c被專家用戶編輯過且編輯后的代碼示例的質量分數和投票數都較高，那么可以認為該回答編輯用戶審查過的那個代碼示例也是專家示例。

R2：［IF （？t ：has_candidate_expertCode ？c） AND （qe_reputation>=AVG（qe_AllReputation） AND qe_gold>=AVG（qe_AllGold） && q_silver>=AVG（q_AllSilver） AND qe_bronze>=AVG（qe_AllBronze）） AND （questionVote>=AVG（allQuestionVote） AND answerCount>=AVG（allAnswerCount） AND bookmarkNum>=AVG（allBookmarkNum）） THEN ExpertCodeList.add（c）.］

專家示例推理規則R2是由rule2、rule4和rule6三條基本規則組合得到的，表示若在本體中存在本體關系：技術標簽t擁有候選專家示例c，并且候選專家示例c所對應解決的問題是被專家用戶編輯過的高質量且受歡迎的問題，本文則將候選專家示例c作為專家示例并將其加入專家示例列表中。根據專家示例推理規則推導獲取到的專家示例如表6所示。

4.2 專家示例的應用

為了驗證通過推理規則得到的專家示例是否有價值，即是否能夠提升BEMiner方法的挖掘效果，本文將獲取的專家示例作為新的訓練集用于BEMiner挖掘方法中，測試集還是沿用的之前研究人員在GitHub中尋找的Netty、Apachecamel以及drools三種Java開源項目。應用的具體過程為：a）首先獲取一類Java技術框架專家示例數據，如Netty專家示例數據通過AST抽象語法樹提取出其中的API調用序列；b）提取出Netty開源項目中源程序的API調用序列；c）通過層次聚類算法聚類提取的專家示例API調用序列；d）聚好的類通過KNN分類算法來對源程序API調用序列分類；e）將分類結果用BIDE算法進行頻繁閉序列挖掘，以此來挖掘得到最終的API調用模式。

由于BEMiner和UPMiner方法都是基于傳統的序列模式的挖掘方法，所以本文在實驗比較上和經典的API挖掘工具UPMiner［11］進行挖掘結果的比較，主要是比較精確率（precision）［10］、召回率（recall）［10］以及Fmeasure［10］。具體的評估標準如式（1）～（3）所示。

其中：L為“黃金集”中的API調用序列集合，“黃金集”指的是從開源項目中人工篩選出的最完整且最精確的API調用序列集合；C表示基于專家示例的BEMiner方法所挖掘到的API調用序列集合；|L|表示“黃金集”中的API調用序列數量；|C|表示BEMiner挖掘結果中的API調用序列數量；|L∩C|表示挖掘結果與“黃金集”相匹配的API調用序列數量。若挖掘到的序列為“黃金集”中的子序列，且序列長度誤差不超過2，則認為該序列為挖掘出的且與“黃金集”相匹配的序列［10］。

BEMiner的示例聚類閾值、K值、分類閾值、頻繁閉序列閾值、源程序序列聚類閾值分別為0.6、3、0.3、0.1、0.2，UPMiner的頻繁閉序列閾值和源程序序列聚類閾值分別為0.1、0.2。實驗結果比較如表7、8所示。

本文設計三組基于不同Java技術框架的實驗，用于比較基于專家示例的BEMiner與UPMiner方法的API挖掘效果。實驗結果表明，經過本文構建的Stack Overflow問答網站本體推理得到的專家示例應用于BEMiner方法中得到的API挖掘結果無論是在精確率、召回率還是Fmeasure，基本都比UPMiner要高。而在沒有專家示例作為訓練集的情況下，BEMiner方法只是在召回率上高于UPMiner，精確率略低于UPMiner。因此專家示例可以在不降低召回率的情況下，更好地提升BEMiner方法的精確率。

5 結束語

Stack Overflow問答網站作為一個計算機領域的IT技術問答網站，其中包含了許多計算機領域相關的知識技術資源。為了達到復用Stack Overflow問答網站知識資源的目的，本文構建了Stack Overflow本體模型，為后續專家示例的獲取及在API挖掘上的應用奠定了基礎。在后續工作中，本文通過部分自定義專家示例推理規則在本體中推導出專家示例，并將專家示例應用于BEMiner挖掘方法。初步的實驗結果表明，由本文構建的Stack Overflow本體模型推導出的專家示例確實能夠提升API挖掘的效果。

參考文獻：

[1]鐘林輝，宗洪雁.基于本體的構件化軟件演化信息獲取及度量研究［J］.計算機科學，2015，42（1）：196-200，231.（Zhong Linhui，Zong Hongyan. Research on acquisition and measurement of ontologybased component software evolution information［J］.Computer Science，2015，42（1）：196-200，231.）

［2]Soliman M， Galster M， Riebisch M. Developing an ontology for architecture knowledge from developer communities［C］//Proc of IEEE International Conference on Software Architecture.Piscataway，NJ：IEEE Press，2017：89-92.

［3]鐘林輝，朱小征，宗洪雁，等.基于本體及模式驅動的構件化軟件共同變化識別研究［J］.計算機應用研究，2016，33（3）：773-778.（Zhong Linhui，Zhu Xiaozheng，Zong Hongyan，et al. Research on common change recognition of componentbased software based on ontology and patterndriven［J］.Application Research of Computers，2016，33（3）：773-778.）

［4]唐成華，侯夢迪，高慶澤，等.多類軟件本體的惡意軟件語義描述模型［J］.小型微型計算機系統，2021，42（11）：2433-2439.（Tang Chenghua，Hou Mengdi，Gao Qingze，et al. Malware semantic description model of multiclass software ontology［J］.Journal of Chinese Computer Systems，2021，42（11）：2433-2439.）

［5]關慧，金梓奕，李楊.基于安全模式的軟件安全本體模型及推理［J］.計算機工程與設計，2018，39（5）：1276-1282.（Guan Hui，Jin Ziyi，Li Yang. Software security ontology model and reasoning based on security patterns［J］.Computer Engineering and Design，2018，39（5）：1276-1282.）

［6]李震，劉斌，苗虹，等.基于本體的軟件安全性需求建模和驗證［J］.北京航空航天大學學報，2012，38（11）：1445-1449.（Li Zhen，Liu Bin，Miao Hong，et al. Ontologybased software safety requirements modeling and verification［J］.Journal of Beijing University of Aeronautics and Astronautics，2012，38（11）：1445-1449.）

［7]魯強，陳超，王智廣.一種支持軟件知識共享的本體模型研究［J］.計算機應用，2010，30（2）：402-405.（Lu Qiang，Chen Chao，Wang Zhiguang. Research on an ontology model supporting software knowledge sharing［J］.Journal of Computer Applications，2010，30（2）：402-405.）

［8]李文鵬，王建彬，林澤琦，等.面向開源軟件項目的軟件知識圖譜構建方法［J］.計算機科學與探索，2017，11（6）：851-862.（Li Wenpeng，Wang Jianbin，Lin Zeqi，et al. Software knowledge graph construction method for open source software projects［J］.Journal of Frontiers of Computer Science and Technology，2017，11（6）：851-862.）

［9]董坤，謝守美.基于關聯數據的MOOC資源語義化組織與聚合研究［J］.情報雜志，2016，35（6）：177182.（Dong Kun，Xie Shoumei. Research on semantic organization and aggregation of MOOC resources based on linked data［J］.Journal of Intelligence，2016，35（6）：177-182.）

［10]莫俊杰.基于示例的API調用模式挖掘方法研究［D］.南昌：江西師范大學，2021.（Mo Junjie. Research on API call pattern mining method based on example［D］.Nanchang：Jiangxi Normal University，2021.）

［11]Wang Jue， Dang Yingnong， Zhang Hongyu， et al. Mining succinct and highcoverage API usage patterns from source code［C］//Proc of the 10th Working Conference on Mining Software Repositories.Piscataway，NJ：IEEE Press，2013：319-328.