李文鵬,王建彬,林澤琦,趙俊峰+,鄒艷珍,謝 冰
1.北京大學 信息科學技術學院,北京 100871
2.高可信軟件技術教育部重點實驗室,北京 100871
3.北京大學(天津濱海)新一代信息技術研究院,天津 300450
面向開源軟件項目的軟件知識圖譜構建方法*
李文鵬1,2,3,王建彬1,2,3,林澤琦1,2,3,趙俊峰1,2,3+,鄒艷珍1,2,3,謝 冰1,2,3
1.北京大學 信息科學技術學院,北京 100871
2.高可信軟件技術教育部重點實驗室,北京 100871
3.北京大學(天津濱海)新一代信息技術研究院,天津 300450
LI Wenpeng,WANG Jianbin,LIN Zeqi,et al.Software knowledge graph building method for open source project.Journal of Frontiers of Computer Science and Technology,2017,11(6):851-862.
軟件復用是軟件開發中避免重復勞動的解決方案。開源軟件的源代碼、郵件列表、缺陷報告和問答文檔等軟件資源中蘊含了規模龐大、結構復雜、語義關聯豐富的軟件知識。如何獲取知識、組織知識,以及如何在軟件復用過程中方便地檢索軟件知識是亟待解決的問題。為了解決這些問題,面向開源軟件項目,構建了軟件知識圖譜,并提供了基于軟件知識圖譜的軟件知識檢索。主要工作包括:針對4種不同類型的軟件資源,提出了軟件知識實體的提取原則與方法;提出了軟件知識實體之間關聯關系構建的方法;實現了兩種軟件知識檢索機制,并以文字列表和圖形可視化相結合的方式展現檢索結果;設計了軟件知識圖譜構建框架。基于上述工作,設計并實現了一個面向開源軟件項目的軟件知識圖譜構建工具。實例證明,所構建的軟件知識圖譜可以更好地幫助軟件開發人員進行軟件知識的檢索與應用。
軟件復用;開源軟件;軟件知識圖譜;圖數據庫
軟件復用是軟件開發中避免重復勞動的解決方案。通過軟件復用,可以提高軟件開發的效率和質量[1]。軟件復用成功的基本前提是存在大量可復用的軟件構件,并且復用者在復用之前可以方便、有效地找到合適的可復用構件[2]。開源軟件是一種有效的軟件復用模式[3]。開源軟件的蓬勃發展,極大地豐富了可復用的軟件構件。
開源軟件的源代碼、郵件列表、缺陷報告和問答文檔等軟件資源中蘊含了規模龐大、結構復雜、語義關聯豐富的軟件知識,這些知識能夠幫助軟件開發人員理解軟件功能,進行軟件復用。然而,如何組織、利用這些知識卻面臨諸多挑戰:
(1)軟件規模增長引發的軟件知識爆炸問題。隨著軟件規模的增長和軟件復雜度的提高,在軟件的開發與復用過程中所需要理解與掌握的知識越來越多,使得復用者的學習成本越來越高。
(2)不同類型軟件資源導致的軟件理解問題。軟件資源的類型多種多樣,不同類型的軟件資源中的軟件知識的特征也各不相同。
(3)軟件知識難以直觀地服務于軟件開發人員。從不同類型的軟件資源中抽取出的軟件知識實體數量龐多,而且知識實體之間關系錯綜復雜,需要提供一種方便用戶檢索和瀏覽知識的機制。
為了有效地組織軟件資源,更好地進行軟件復用,本文面向開源軟件項目構建了軟件知識圖譜。軟件知識圖譜是指由不同類型的軟件資源的軟件知識圖有機融合構成的用以描述某一軟件的知識體系。軟件知識圖是指由同一類型軟件資源的軟件知識實體及其之間的關聯關系所構成的圖。軟件知識實體指的是軟件資源中可區分的、可辨識的且具有一定語義關系的單元體,而軟件知識實體之間關聯關系指的是兩兩軟件知識實體之間具有某種類型的二元關系。本文工作主要包括:
(1)提出了軟件知識實體的提取原則與方法。分別從軟件源代碼、缺陷報告、郵件列表和問答文檔4種軟件資源中提取了相應的軟件知識實體。
(2)提出了軟件知識實體之間關聯關系構建的方法。分析了同一類型軟件資源中的軟件知識實體關聯關系的構建方法與不同類型軟件資源中軟件知識實體之間的關聯關系。
(3)設計了形式化檢索和文本檢索兩種軟件知識檢索機制,并以文字列表和圖形可視化相結合的方式展現檢索結果。
(4)設計了軟件知識圖譜構建框架,該框架由軟件知識提取模塊、軟件知識融合模塊、軟件知識圖譜存儲管理模塊與軟件知識檢索模塊構成。
基于上述工作,本文設計并實現了一個面向開源軟件項目的軟件知識圖譜構建工具,并以Lucene-Core為例,通過應用實例展示了本文工作的有效性和合理性。
從軟件資源中提取知識的相關研究有:Cubranic等人[4]開發了工具Hipikat來幫助復用者檢索開源軟件的各種資源,其中主要涉及缺陷、特征描述、開發者論壇中的帖子與其他項目相關的文檔這4類資源。Hipikat為一個指定項目收集資源和挖掘各類資源之間的關聯關系,建立了項目的資源數據庫。復用者可以在該庫中進行檢索,系統將返回與之文本相似度較高的各種資源及其之間的關聯關系,方便復用者學習。但是Hipikcat對于每類軟件資源僅提取了對應的文本信息,未對軟件資源做進一步的知識提取。Gopinath等人[5]從軟件項目的代碼中提取出包、類、接口和方法信息,定義了項目、包、類、接口、方法等本體,將所有項目的本體存儲在同一個本體網里,以幫助開發者復用已有的軟件。McMillan等人[6]構建了代碼中函數之間的調用關系圖,用于在代碼搜索系統中幫助使用者檢索函數以及使用示例。
DBPedia從維基百科(Wikipedia)的詞條里擷取出結構化的知識(RDF格式),并以語義網的形式將擷取的知識整合在一起[7]。DBPedia支持用戶進行語義化查詢維基百科相關資源的屬性和資源之間的關系。谷歌的知識圖譜將谷歌索引的所有事物、人物和地點,例如地標性建筑、名人、球隊、電影、藝術品等,刻畫成實體,并建立這些實體之間的關聯關系。早期的知識圖譜建立在諸如Freebase、維基百科、維基數據以及美國中央情報局出版的《世界概況》等著名公開數據源上,其包括了5億多個對象實體以及350億條這些對象實體之間的關聯關系。近期,谷歌又通過機器學習和數據挖掘方法[8-12],從索引的網頁中自動發現新的實體和實體關系,從而擴大并完善了知識圖譜[13]。這些研究主要涉及通用領域,較少涉及軟件相關的知識。本文根據軟件資源的特點研究軟件資源中的軟件知識提取和管理,并構建軟件知識圖譜。
有關代碼和文檔之間的可追蹤性(traceability)的工作很多,本文關注這一研究方向中的代碼元素識別和關聯技術。Bacchelli等人[14]開發了Miler工具,用以從郵件列表中提取出包含的代碼元素。該工具的主要思想是:先解析出軟件項目的代碼,再結合駝峰命名法(camel-case)和正則表達式匹配來識別代碼元素。Miler區分大小寫,可以較為準確地識別出組合詞(如IndexReader)和單項詞元素(如Index)。其中組合詞的識別準確率最高,而單項詞元素可能是自然語言中的單詞,需要添加一定的規則進而準確地識別單項詞元素。Dagenais等人[15]開發了Reco-Doc工具,用于對API的相關學習資料建模,并從中提取出包含的代碼元素,進而建立API和相關學習資料之間的可追蹤性。RecoDoc結合了部分程序分析和正則匹配技術提取代碼元素;同時還制定了一些啟發式規則,結合上下文環境提取代碼元素。
軟件資源中的軟件知識實體豐富多樣,它們之間的關聯關系也是錯綜復雜。為此需要采用合適的模型表達軟件知識實體以及軟件知識實體之間的關聯關系。屬性圖模型能夠很好地利用屬性表達結點和關系豐富的信息,因此本文采用屬性圖模型進行軟件知識圖譜的構建。屬性圖模型的特征[16]如下:屬性圖模型是由結點、有向邊和屬性組成的;結點上包含屬性,屬性可以任何鍵值對的形式存在;每條邊都擁有一個方向、一個標簽、一個開始結點和一個結束結點;就像結點一樣,邊也是有屬性的。
基于屬性圖模型,本文的軟件知識圖譜采用如下機制統一地表示從軟件資源中提煉的結構化軟件知識:圖中每個結點對應一個軟件知識實體;圖中的每條有向邊代表一個語義關聯;每個軟件知識實體中的鍵值對與實體所對應的結點屬性一一對應;每個結點或邊由全局標識符唯一標識。
屬性圖模型是很多圖數據庫的底層實現模型。DB-Engines排名前5的圖數據庫[17]依次分別是Neo4j(http://neo4j.com/)、OrientDB(http://orientdb.com/)、Titan(http://thinkaurelius.github.com/titan/)、Virtuoso(http://virtuoso.openlinksw.com/)和ArangoDB(https: //www.arangodb.com/)。考慮到存儲模型、查詢語言、圖數據庫成熟度等因素,由于Neo4j原生支持屬性圖模型,具有豐富的查詢語言,使用用戶多,成熟度高,本文選擇Neo4j作為軟件知識圖譜的底層存儲。
在構建面向開源項目軟件知識圖譜時,需要解決以下3個問題:
(1)軟件知識實體提取。軟件資源的類型是多種多樣的,包括軟件源代碼、郵件列表、缺陷報告、相關問答文檔等各種不同的資源類型。同一類型的軟件資源、數據來源也可能不同,如缺陷報告可能來自JIRA、BugZilla或Lighthouse。不同的軟件資源中,軟件知識實體的形式與特點也各不相同。
(2)軟件知識實體關聯關系建立。同一類型的軟件資源中所提取的軟件知識實體之間存在各種關聯關系,由軟件資源自身特點決定;從不同類型的軟件資源中提取的軟件知識實體也存在關聯關系,如郵件中可能引用一個缺陷報告。
(3)軟件知識檢索與展現。如何利用軟件知識圖譜向軟件開發人員提供其所需的知識,并針對不同精度需求提供不同方式的檢索。
本文面向開源軟件項目的軟件知識圖譜構建工具的總體框架如圖1所示。
面向開源項目軟件知識圖譜構建工具的輸入是開源項目的源代碼、缺陷報告、郵件列表和問答文檔等軟件資源。首先從這些軟件資源中提取出各自的軟件知識圖,稱之為軟件知識提??;然后建立軟件知識實體關聯關系,將來自不同類型軟件資源獨立的軟件知識圖有機地組織在一起,形成軟件知識圖譜;最后建立知識檢索與展現機制,面對用戶的精確檢索和模糊檢索需求,在軟件知識圖譜之上提供形式化檢索和文本檢索兩種檢索機制。

Fig.1 Framework diagram of software knowledge graph圖1 軟件知識圖譜框架圖
基于上述的總體解決方案,下面將對軟件知識實體提取、軟件知識實體關聯關系建立和軟件知識檢索與展現3個問題進行詳細的闡述。
4.1 軟件知識實體提取
4.1.1 面向軟件源代碼的軟件知識實體提取
本文主要面向Java開源項目,因此研究面向Java源代碼的軟件知識實體提取。根據Java語言規范,Java代碼是由包、類、接口、域、方法、語句等代碼元素構成。為了進一步豐富代碼結構化的知識,本文將域和方法提取為軟件知識實體,具體實體屬性內容如表1所示。

Table 1 Information of software knowledge entities in code表1 代碼中的軟件知識實體信息表
本文使用Eclipse JDT的ASTParser將每個Java文件解析成一個抽象語法樹(abstract syntax tree,AST)。AST使用樹狀結構表示代碼的抽象語法結構,樹上每個結點都對應代碼中的一種結構。
代碼中的每個元素都對應抽象語法上的一個結點,使用Visitor設計模式遍歷所有結點提取如表1所示的包、類、接口、域和方法軟件知識實體以及對應的屬性信息,并將這些軟件知識實體保存至代碼實體池中。另外,ASTParser只能將塊注釋關聯至對應的代碼元素,而對于行注釋信息則不能自動對應到相應的代碼元素上。對于行注釋信息,需單獨處理,根據其在文件中的位置與相應的代碼實體綁定。
4.1.2 面向缺陷報告的軟件知識實體提取
開源軟件項目中常用的缺陷報告系統有JIRA、 BugZilla和Lighehouse,它們的差異在于不同系統中信息的豐富程度不同,本文通過取這些缺陷報告系統信息的超集來解決這個問題。如JIRA的缺陷報告中有缺陷類型信息,而Bugzilla中沒有該信息,那么超集為包含該信息,只是從Bugzilla中提取該信息時為null。
缺陷報告可以看作是“問題-解決方案-反饋-參與者”型的軟件資源。對于這類資源,可以將每個問題、解決方案、反饋以及相應的參與者單獨提取為一個軟件知識實體。因此將“缺陷報告”、“補丁”、“缺陷報告評論”以及相應的參與者單獨提取為軟件知識實體,如表2所示。

Table 2 Information of software knowledge entities in issue表2 缺陷報告中的軟件知識實體信息表
JIRA中每一個缺陷報告對應一個JSON(Java-Script object notation)和多個文本格式的補丁文件(如果有補丁文件)。其中JSON文件中包含了除補丁外所有與缺陷報告相關的信息。本文使用開源JSON解析工具GSON解析JSON文件,從每一個JSON文件中獲取對應缺陷報告實體、補丁實體、缺陷報告評論實體和缺陷報告用戶實體的信息,利用文件解析工具FileUtils解析相應的補丁文件設置補丁的“補丁內容”信息。
4.1.3 面向郵件列表的軟件知識實體提取
開源軟件項目的郵件列表歸檔通常使用Mbox格式。一封郵件天然就是可區分可辨識的且具有一定語義的單元體,可以將單獨的一封郵件提取為軟件知識實體。具體屬性如表3所示。

Table 3 Information of software knowledge entities in mail表3 郵件列表中的軟件知識實體信息表
開源軟件提供的郵件列表歸檔的格式多樣,本文考慮Mbox格式。每個Mbox文件由多封郵件構成,本文使用Mime4j解析出每一封郵件,以及每封郵件對應的標識符、主題、發送日期、發送者、接收者和郵件內容。
為了獲取郵件“用戶實體”的信息,本文通過正則匹配從發送者和接收者信息中解析出名稱和郵件地址。但是,Mbox中的用戶名稱位置不盡相同,而且表示形式多樣。針對這種情況,本文為發現的每一種特殊形式設計一個正則表達式,盡可能提高準確度。
4.1.4 面向問答文檔的軟件知識實體提取
問答文檔是“問題-解決方案-反饋-參與者”型的軟件資源,可以將問題、答案、評論以及相應的參與者單獨提取為軟件知識實體,如表4所示。

Table 4 Information of software knowledge entities in Q&Adocument表4 問答文檔中的軟件知識實體信息表
本文問答信息獲取自問答網站Stack Overflow的數據Stack Overflow Dump,解析Dump得到Posts、Comments和Users等幾個XML文件,利用XML解析器SARParser解析Posts提取出問題和答案實體;解析Comments提取出問答評論實體;解析Users提取出問答用戶實體。
4.2 軟件知識實體關聯關系建立
軟件知識實體之間具有大量語義豐富的關聯關系:同一軟件資源內部的軟件知識實體之間的關聯關系,這些關系往往是特有的、與類型相關的,需要針對具體的資源類型建立起這些語義關聯關系;跨不同軟件資源的軟件知識實體之間的關聯關系,本文考慮3類:(1)代碼元素關聯,一個軟件知識實體所包含的信息中直接提及了同項目中的某一個代碼元素;(2)引用關聯,一個軟件知識實體通過超鏈接或唯一標識符的形式引用另一個軟件知識實體;(3)用戶關聯,同一用戶在不同軟件知識實體中扮演不同角色。
4.2.1 同一資源的軟件知識實體關聯關系建立
本文建立的軟件知識實體之間的關聯關系如表5~表8所示。其中關系均采用集合論表示,如“實現= {(類,接口)}”中實現關系集合包括類與接口之間的實現關系。

Table 5 Relationship information of code entities表5 軟件代碼實體之間的關聯關系表
軟件代碼中多數關系蘊含在已提取出的軟件知識實體屬性中。對于“依賴”和“調用”關系,需要利用ASTParser將代碼解析到每一個語句。

Table 6 Relationship information of issue entities表6 缺陷報告實體之間的關聯關系表

Table 7 Relationship information of mail entities表7 郵件列表實體之間的關聯關系表

Table 8 Relationship information of Q&Adocument entities表8 問答文檔知識實體之間的關聯關系表
“作者關系”蘊含在知識實體屬性中,而對于“補丁關系”、“缺陷報告評論關系”、“重復關系”而言,需要在解析過程中,記錄下對應關系類型的映射,根據每一條映射為實體添加關聯關系。
“發送者”、“接收者”關系蘊含在郵件實體的“接收者”屬性中;“回復”關系需要在解析Mbox時記錄下包含“In-Reply-To”信息的郵件的標識符以及對應的“In-Reply-To”信息,通過標識符定位具體的郵件實體,并在兩個郵件實體之間建立“回復”關系。
“答案關系”、“評論關系”、“作者關系”蘊含在知識實體屬性中,對于“重復關系”,解析PostLinks得到重復關系對應的問題標識符對,在對應的問題實體間建立一條“重復關系”。
4.2.2 不同資源的軟件知識實體關聯關系建立
對于不同類型軟件資源中的軟件知識實體,本文主要建立3種不同的關聯關系:代碼元素關聯、引用關聯和用戶關聯。
4.2.2.1 代碼元素關聯
代碼元素關聯是指建立軟件代碼中的軟件知識實體與其他類型軟件資源中軟件知識實體之間的關聯關系。如果一個非代碼軟件知識實體的屬性信息提及了同項目的一個代碼元素(類、接口、域或方法),則在該軟件知識實體與該代碼元素對應的軟件知識實體之間建立一條語義關聯關系。本文稱這種語義關聯關系為“代碼引用”關系,可以看作一種特殊的“引用”關聯關系。代碼元素關聯識別方法根據RecoDoc[15]技術實現,具體方法如下:
(1)通過基于模式匹配的方法實現對自然語言文本中的詞項進行分類。該工作將自然語言文本中的詞項劃分成兩類:自然語言詞項與代碼詞項。這一劃分通過與若干自定義的詞項模式進行自動比對(如駝峰命名模式、常量大寫模式等),適應于對大部分常見代碼風格的軟件項目分析。
(2)通過上下文分析的方法實現對代碼元素的歧義消除。該工作對代碼元素的歧義消除利用了上下文分析技術,其基礎是代碼元素在文檔中出現的局部性,即在相近的文檔實體中被引用的代碼實體亦多是相近的。
(3)通過基于注釋分析的方法實現對識別結果的精化。對于上下文信息不足的代碼詞項,該工作利用待消除歧義的代碼實體所涉及的注釋,度量它與文檔實體間的相似性,進而對識別結果進行精化。
4.2.2.2 引用關聯
(1)識別出可被引用(超鏈接或全局唯一標識符引用)的軟件知識實體。
(2)分析每一類可被引用的軟件知識實體對應的超鏈接或全局唯一標識符的模式。
(3)對于每一個具體的、可被引用的軟件知識實體ei,逐一分析每個軟件知識實體ej,若ej包含符合ei超鏈接或全局唯一標識符模式的字符串,則建立一條從ej到ei的“引用”關系。
4.2.2.3 用戶關聯
用戶關聯是指同一用戶在不同軟件知識實體中扮演不同角色的關聯關系。比如,某個郵件的發送者也是某個缺陷報告的創建者。本文根據郵件地址與用戶名等信息,識別并關聯不同類型軟件資源中的同一用戶,進而間接建立不同類型軟件資源的軟件知識實體之間的關聯關系。本文稱這種語義關聯關系為“同一用戶”關系。建立用戶關聯的方法如下:
(1)識別出包含用戶的軟件資源。
(2)按照是否包含郵件地址信息,將用戶分成兩類。
(3)對于包含郵件地址的用戶,直接通過郵件地址關聯不同類型軟件資源中的用戶。
(4)對于不包含郵件地址的用戶,基于“在不同軟件資源中討論同一項目、用戶名稱相同且唯一的兩個用戶是同一個人”的假設,通過用戶名稱關聯不同類型軟件資源中的用戶。
5.1 形式化檢索與展現
本文軟件知識圖譜的底層存儲支持系統為Neo4j。Neo4j提供了一個聲明式的、易讀的圖查詢語言Cypher,可直接使用Cypher檢索軟件知識。
Cypher語法對于自定義的關系、結點的標簽和結點、關系的屬性名是區分大小寫的。當關系名稱和結點的標簽名稱較長時,輸入拼寫正確的名稱是困難的,對使用者是不友好的。本文借鑒Eclipse進行代碼補全的思想,根據上下文環境實時推薦代碼元素,開發了Cypher補全工具,使得用戶輸入查詢語句時可以根據上下文推薦關系、結點的標簽和屬性名。
5.2 文本檢索與展現
本文將所有軟件知識實體的核心文本內容(表9)單獨提取成一個個的文檔,并建立起文檔與軟件知識實體之間的關聯關系;然后為每個文檔建立倒排索引。在用戶進行檢索時,返回TopK(本文K= 100)個與檢索語句相關的文檔,然后根據文檔與軟件知識實體之間的關聯關系,得到TopK個與檢索語句相關的軟件知識實體。展示內容包含核心內容及相應上下文信息。

Table 9 Core attributes of software knowledge entities表9 軟件知識實體核心內容屬性表
本章首先介紹以Lucene-Core項目為例構造的軟件知識圖譜的情況,接著展示Cypher自動補全的效果,最后展示軟件知識檢索效果。
6.1 實例展示
Lucene-Core軟件知識圖譜的軟件知識實體和關聯關系數量統計情況如表10、表11所示。
6.2 軟件知識檢索與展現
6.2.1 代碼補全展示
圖2和圖3展示了本文Cypher補全工具對結點標簽信息、結點屬性信息補全的情況。
6.2.2 檢索IndexReader類所有的子孫類


Table 10 Software knowledge entities in Lucene-Core表10 Lucene-Core軟件知識實體統計表

Table 11 Relationships of software knowledge entities in Lucene-Core表11 Lucene-Core軟件知識實體關聯關系統計表

Fig.2 Auto-completion of node label圖2 結點標簽補全示意圖

Fig.3 Auto-completion of node attribute圖3 結點屬性自動補全示例圖

Fig.4 Search result in text list about“descendent classes of IndexReader”圖4 “IndexReader類所有的子孫類”文字列表檢索結果
文字列表檢索結果(部分結果)、圖形可視化檢索結果分別如圖4和圖5所示。由圖4中紅框部分可知,LeafReader的父類是IndexReader。圖5展示了所有直接或間接繼承IndexReader的類,其中最上面的結點為IndexReader,向下每一行表示Index同一繼承深度的子孫類,繼承關系由邊上的“EXTEND”表示。
6.2.3 檢索與IndexReader類相關的重復Bug信息


Fig.5 Search result in graph about“descendent classes of IndexReader”圖5 “IndexReader類所有的子孫類”圖形可視化檢索結果

Fig.6 Search result in text list about“bug duplications of IndexReader”圖6 “IndexReader類相關的重復Bug信息”文字列表結果

Fig.7 Search result in graph about“bug duplications of IndexReader”圖7 “IndexReader類相關的重復Bug信息”圖形可視化結果
文字列表檢索結果、圖形可視化檢索結果分別如圖6和圖7所示。圖6列出了IndexReader類和具有重復Bug信息的兩個缺陷報告,其中藍色高亮對應的是IndexReader類,紅色高亮表示其類型是Bug,綠色高亮展示了檢索結果Issue與“IndexReader”的相關性。圖7邊上LEX_LEVEL_REFER是由代碼元素關聯建立的“代碼引用關系”,DUPLICATE表示缺陷報告之間的“重復關系”。
7.1 本文工作總結
本文的主要工作包括:
(1)提出了軟件知識實體的提取原則與方法,并分別針對4種不同類型的軟件資源提取了軟件知識實體。
(2)提出了軟件知識實體之間關聯關系構建的方法,分析了同一類型軟件資源中軟件知識實體之間關聯關系的類型及特點,給出了同一類型軟件資源中的軟件知識實體關聯關系的構建方法;接著以代碼結構為核心,引用關聯和用戶關聯為輔助的方式,建立了不同類型軟件資源中軟件知識實體之間的關聯關系。
(3)設計了兩種軟件知識檢索機制,并以文字列表和圖形可視化相結合的方式展現檢索結果。本文利用Neo4j的聲明式查詢語言Cypher提供形式化檢索,并通過開發Neo4j的服務器擴展程序提供了Cypher補全工具,以幫助用戶方便地進行形式化檢索;利用ElasticSearch對軟件知識中的文本信息建立索引,并提供文本檢索功能。
(4)設計了軟件知識圖譜構建框架,該框架由軟件知識提取模塊、軟件知識融合模塊、軟件知識圖譜存儲管理模塊與軟件知識檢索模塊構成,分別提供軟件知識實體提取、軟件知識實體之間的關聯關系建立、軟件知識圖融合、軟件知識圖譜存儲以及基于軟件知識圖譜檢索等功能。
本文設計并實現了一個面向開源軟件項目的軟件知識圖譜構建工具,并以Lucene-Core為例,通過實例展示了本文工作的有效性和合理性。
7.2 未來工作展望
本文工作還需進一步的改進,主要包括:
(1)融合形式化檢索和文本檢索的接口。
(2)改善形式化檢索的圖形化展示。改善基于兩個方面,一方面是檢索結點之間的關聯關系補全,另一方面是結點擴展。
(3)提供面向開發人員的API接口。
(4)研究軟件知識圖譜的內容更新機制。
(5)考慮軟件知識的版本信息。
[1]Yang Fuqing,Mei Hong,Li Keqin.Software reuse and software component technology[J].Acta Electronica Sinica,1999, 27(2):68-75.
[2]Yang Fuqing.Software reuse and its correlated techniques[J]. Computer Science,1999,26(5):1-4.
[3]Brown A W,Booch G.Reusing open-source software and practices:the impact of open-source on commercial vendors [C]//LNCS 2319:Proceedings of the 7th International Conference on Software Reuse,Austin,USA,Apr 15-19,2002. Berlin,Heidelberg:Springer,2002:123-136.
[4]?ubrani? D,Murphy G C.Hipikat:recommending pertinent software development artifacts[C]//Proceedings of the 25th International Conference on Software Engineering,Portland,USA,May 3-10,2003.Washington:IEEE Computer Society,2003:408-418.
[5]Gopinath G,Sagayaraj S.To generate the ontology from Java source code[J].International Journal of Advanced Computer Science andApplications,2011,2(2):111-116.
[6]McMillan C,Grechanik M,Poshyvanyk D,et al.Portfolio: finding relevant functions and their usage[C]//Proceedings of the 33rd International Conference on Software Engineering, Honolulu,USA,May 21-28,2011.New York:ACM,2011: 111-120.
[7]Lehmann J,Isele R,Jakob M,et al.DBpedia—a large-scale, multilingual knowledge base extracted from Wikipedia[J]. Semantic Web,2015,6(2):167-195.
[8]Bordes A,Gabrilovich E.Constructing and mining Webscale knowledge graphs:WWW 2015 tutorial[C]//Proceedings of the 24th International Conference on World Wide Web,Florence,Italy,May 18-22,2015.New York:ACM, 2015:1523.
[9]Dong X L,Gabrilovich E,Heitz G,et al.From data fusion to knowledge fusion[J].Proceedings of the VLDB Endowment,2014,7(10):881-892.
[10]Dong X,Gabrilovich E,Heitz G,et al.Knowledge vault:a Web-scale approach to probabilistic knowledge fusion[C]// Proceedings of the 20th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining,New York,Aug 24-27,2014.New York:ACM,2014:601-610.
[11]Dong X L,Gabrilovich E,Murphy K,et al.Knowledgebased trust:estimating the trustworthiness of Web sources[J]. Proceedings of the VLDB Endowment,2015,8(9):938-949.
[12]West R,Gabrilovich E,Murphy K,et al.Knowledge base completion via search-based question answering[C]//Proceedings of the 23rd International Conference on World Wide Web,Seoul,Korea,Apr 7-11,2014.New York:ACM, 2014:515-526.
[13]Zhang Jing,Tang Jie.The focus of the next generation of search engine:knowledge map[J].The Chinese Society of Computer Communication,2013,9(4):64-88.
[14]Bacchelli A,Lanza M,Robbes R.Linking e-mails and source code artifacts[C]//Proceedings of the 32nd International Conference on Software Engineering,Cape Town,South Africa,May 1-8,2010.New York:ACM,2010:375-384.
[15]Dagenais B,Robillard M P.Recovering traceability links between an API and its learning resources[C]//Proceedings of the 34th International Conference on Software Engineering, Zurich,Switzerland,Jun 2-9,2012.Piscataway,USA:IEEE, 2012:47-57.
[16]Robinson I,Webber J.Eifrem E.Graph databases[M].Sebastopol,USA:O'Reilly Media Press,2013:26-27.
[17]DB-engines ranking of graph DBMS[EB/OL].(2016-04) [2016-06-27].http://db-engines.com/en/ranking/graph+dbms.
附中文參考文獻:
[1]楊芙清,梅宏,李克勤.軟件復用與軟件構件技術[J].電子學報,1999,27(2):68-75.
[2]楊芙清.軟件復用及相關技術[J].計算機科學,1999,26 (5):1-4.
[13]張靜,唐杰.下一代搜索引擎的焦點:知識圖譜[J].中國計算機學會通訊,2013,9(4):64-88.

LI Wenpeng was born in 1993.He is an M.S.candidate at Peking University.His research interest is software engineering.
李文鵬(1993—),男,山東萊蕪人,北京大學碩士研究生,主要研究領域為軟件工程。

WANG Jianbin was born in 1991.He is an M.S.candidate at Peking University.His research interest is software engineering.
王建彬(1991—),男,河北邯鄲人,北京大學碩士研究生,主要研究領域為軟件工程。

LIN Zeqi was born in 1992.He is a Ph.D.candidate at Peking University.His research interest includes software engineering,software reuse,knowledge engineering and data mining,etc.
林澤琦(1992—),男,福建莆田人,北京大學博士研究生,主要研究領域為軟件工程,軟件復用,知識工程,數據挖掘等。

趙俊峰(1974—),女,福建泉州人,2005年于北京大學軟件與理論專業獲得博士學位,現為北京大學信息科學技術學院副教授,CCF高級會員,主要研究領域為軟件工程,知識工程,服務計算等。發表學術論文30余篇,主持或承擔過國家自然科學基金項目、國家863項目、北京重大科技成果轉換項目等近20項。

ZOU Yanzhen was born in 1976.She received the Ph.D.degree in software and software theory from Peking University in 2010.Now she is an associate professor at Peking University,and the member of CCF.Her research interests include software engineering,software reuse and information retrieval,etc.
鄒艷珍(1976—),女,遼寧蓋州人,2010年于北京大學軟件與理論專業獲得博士學位,現為北京大學信息科學技術學院副教授,CCF會員,主要研究領域為軟件工程,軟件復用,信息檢索等。

XIE Bing was born in 1970.He received the Ph.D.degree from School of Computer,National University of Defense Technology in 1998.Now he is a professor and Ph.D.supervisor at Peking University,and the senior member of CCF.His research interests include software engineering and formal methods,etc.
謝冰(1970—),男,湖南湘潭人,1998年于國防科技大學計算機學院獲得博士學位,現為北京大學信息科學技術學院軟件所教授、博士生導師,CCF高級會員,主要研究領域為軟件工程,形式化方法等。發表學術論文50余篇,主持國家863重點項目多項,獲國家科技進步二等獎。
Software Knowledge Graph Building Method for Open Source Project*
LI Wenpeng1,2,3,WANG Jianbin1,2,3,LIN Zeqi1,2,3,ZHAO Junfeng1,2,3+,ZOU Yanzhen1,2,3,XIE Bing1,2,3
1.School of Electronics Engineering and Computer Science,Peking University,Beijing 100871,China
2.Key Laboratory of High Confidence Software Technologies,Ministry of Education,Beijing 100871,China
3.Peking University Information Technology Institute(Tianjin Binhai),Tianjin 300450,China
+Corresponding author:E-mail:zhaojf@pku.edu.cn
Software reuse is a solution to reduce the duplication of efforts during software development and improve the efficiency and quality of the process.Open source projects’source code,mailing lists,issue reports,Q&A documents and other software resources contain software knowledge with complex structure and rich semantic association on a large scale.How to obtain and organize software knowledge and retrieve it effectively in the process of software reuse have become urgent problems.In order to solve these problems,this paper constructs software knowledge graph,whose goal is to organize and manage the structural knowledge of a software project,and provides software knowledge graph based knowledge retrieval.The contributions of this paper are as follows:Providing the extraction principles and methods of software knowledge entities,and extracting software knowledge entities from four different kinds of software resources respectively;Providing the methods of building the relationships between software knowledge entities;Providing two software knowledge retrieval mechanisms,and displaying the retrievalresults by the combination of word list and graph visualization;Designing the implementation framework of software knowledge graph.On the basic of the work above,this paper designs and implements a software knowledge graph building tool for open source project.Instances prove that software knowledge graph can help developers to better retrieve and use knowledge.
software reuse;open source software;software knowledge graph;graph database
eng was born in 1974.She
the Ph.D.degree in software and software theory from Peking University in 2005.Now she is an associate professor at Peking University,and the senior member of CCF.Her research interests include software engineering,knowledge engineering and service computing,etc.
A
TP301
關聯是指建立一個軟件知識實體與其引用的軟件知識實體之間的關聯關系。如果一個軟件知識實體包含的信息中包含另一個軟件知識實體對應的超鏈接或全局唯一的標識符,則在該軟件知識實體與包含的軟件知識實體之間建立一條語義關聯關系。本文稱這種語義關聯關系為“引用”關系。建立引用關聯的步驟如下:
*The National Natural Science Foundation of China under Grant No.61472007(國家自然科學基金);the National Science Fund for Distinguished Young Scholars of China under Grant No.61525201(國家杰出青年科學基金).
Received 2016-08,Accepted 2016-10.
CNKI網絡優先出版:2016-10-31,http://www.cnki.net/kcms/detail/11.5602.TP.20161031.1652.022.html