基于知識圖譜的軟件平臺知識表示方法研究

尚福華 丁秋予 蔣毅文 曹茂俊 杜睿山

(東北石油大學(xué)計(jì)算機(jī)與信息技術(shù)學(xué)院 黑龍江 大慶 163318)

Graph database

0 引 言

隨著軟件系統(tǒng)的開發(fā)規(guī)模不斷擴(kuò)大，軟件需求日益增多與復(fù)雜化，大型軟件平臺的開發(fā)被提出了更高的要求[1-2]。在軟件平臺開發(fā)過程中知識起著重要的指導(dǎo)與借鑒作用，對知識的高效利用與循環(huán)使用能夠有效提高軟件開發(fā)的質(zhì)量和效率[3]。

本項(xiàng)目組在對測井領(lǐng)域大型軟件平臺“一體化測井平臺CIFLog”[4](下面簡稱為CIFLog)進(jìn)行開發(fā)的過程中，發(fā)現(xiàn)在CIFLog軟件平臺生態(tài)中開發(fā)人員與軟件平臺之間的知識流動存在如下問題：軟件開發(fā)人員要想直接獲取代碼知識需要不斷地從軟件平臺的廣泛代碼信息中進(jìn)行繁雜的數(shù)據(jù)查找與提取，并自行對其進(jìn)行分析、凝練才能獲取具有較大價(jià)值密度的知識。在發(fā)生人員流動時(shí)，以上現(xiàn)象則會帶來更大的影響。

基于上述現(xiàn)象，本文調(diào)研了其他的大型平臺，如Tencent Open Source、Alibaba Open Platform、DevCloud、GitHub等，雖然以上平臺具有規(guī)范化的說明文檔，對項(xiàng)目的關(guān)鍵性組成成分有所說明，但并未詳盡地包含項(xiàng)目的所有組成成分，僅僅能滿足開發(fā)人員對于關(guān)鍵性接口的檢索需要，而無法幫助開發(fā)人員很好地對整個(gè)平臺或項(xiàng)目進(jìn)行理解，軟件平臺開發(fā)人員與項(xiàng)目之間的知識流動不順暢的問題仍然存在。

目前國內(nèi)外軟件工程領(lǐng)域?qū)τ谲浖R管理方面的研究主要分為用戶需求表示、軟件開發(fā)知識建模和軟件開發(fā)知識管理等三個(gè)方面，如文獻(xiàn)[1]對構(gòu)建代碼知識圖譜方面進(jìn)行了深入的研究，文獻(xiàn)[5]提出了構(gòu)建軟件知識共享本體模型，文獻(xiàn)[6]構(gòu)建了Lucene-Core知識圖譜，文獻(xiàn)[7]設(shè)計(jì)并構(gòu)建了以用戶需求為驅(qū)動的知識管理模型，文獻(xiàn)[8]介紹了KBSA(Knowledge-based software assistant)的研究進(jìn)展等。然而目前有關(guān)軟件知識管理方面的研究并未關(guān)注如何改善開發(fā)人員與軟件平臺或項(xiàng)目之間的知識流動，也沒有對大型軟件平臺的知識抽取與形式化表示等進(jìn)行深入研究與剖析。

通過以上研究和實(shí)際項(xiàng)目的驅(qū)動，本文對目前大型軟件平臺存在的問題總結(jié)如下：

1) 軟件規(guī)模增長的同時(shí)帶來的是軟件知識激增[9]，使得軟件開發(fā)人員用來理解與掌握軟件知識的學(xué)習(xí)成本增加；

2) 軟件平臺包含的數(shù)量龐大的實(shí)體數(shù)量與錯(cuò)綜復(fù)雜的實(shí)體關(guān)系等知識[10]無法直接明了地提供給開發(fā)人員使用；

3) 軟件平臺中蘊(yùn)含的深層次且關(guān)聯(lián)關(guān)系復(fù)雜的知識無法難以被充分利用等。

基于上述問題，本文提出通過構(gòu)建軟件平臺知識圖譜改善開發(fā)人員與項(xiàng)目之間的知識傳遞，幫助開發(fā)人員了解軟件平臺，更好地基于軟件平臺進(jìn)行開發(fā)工作。軟件平臺知識圖譜由軟件平臺開發(fā)源碼中的知識實(shí)體與關(guān)聯(lián)關(guān)系組成，用于描述軟件平臺的知識體系。軟件平臺知識圖譜中的知識實(shí)體是指源代碼中具有語義且相互之間存在二元關(guān)聯(lián)關(guān)系的個(gè)體單元。

1 基于軟件平臺知識圖譜的知識傳遞

1.1 軟件平臺知識圖譜的知識流動

如上所述，我們提倡通過構(gòu)建軟件平臺知識圖譜的方式來解決編程人員在需要知識或者信息時(shí)，需要親自從廣泛的代碼中進(jìn)行繁雜的查找的問題。軟件平臺知識圖譜的目標(biāo)是將項(xiàng)目中可能循環(huán)使用的軟件平臺知識抽取出來，并對其進(jìn)行層次清晰地表示，以此幫助開發(fā)人員進(jìn)行準(zhǔn)確的知識定位與獲取，并且?guī)椭_發(fā)人員更好更快地了解軟件平臺，提高軟件開發(fā)人員中對軟件平臺知識的利用率。

軟件平臺知識圖譜實(shí)現(xiàn)的前提在于對軟件平臺知識的整理與表示，以由Java語言開發(fā)的CIFLog軟件平臺為例：軟件平臺開發(fā)中的最大單元為項(xiàng)目，其次是包，包中包含類，在類的內(nèi)部定義與調(diào)用方法等。開發(fā)源代碼中的知識層次清晰，知識圖譜能夠很好地將軟件平臺知識的層次性描述出來，更加貼近軟件平臺知識自身的條理，并且由于在軟件平臺中的知識不屬于常識知識的范疇，有著編程規(guī)范的約束，意味著軟件平臺知識能夠較好地支持關(guān)系梳理，且不容易產(chǎn)生歧義。

通過構(gòu)建軟件平臺知識圖譜，對軟件平臺知識進(jìn)行了體系化的梳理，大幅減少了開發(fā)人員在進(jìn)行知識檢索時(shí)要做大量繁雜的跳轉(zhuǎn)、關(guān)鍵字檢索與篩選的工作?；谲浖脚_知識圖譜，開發(fā)人員只需面向整理好的軟件平臺知識圖譜發(fā)出數(shù)據(jù)請求，知識圖譜則會進(jìn)行相應(yīng)知識節(jié)點(diǎn)與關(guān)系的檢索。并且由于知識圖譜的網(wǎng)狀結(jié)構(gòu)可以清晰地找到知識之間的關(guān)聯(lián)關(guān)系，因此反饋的知識不僅僅局限于靶向知識，而有能力將開發(fā)人員可能需要的其他內(nèi)容也傳遞出來供其使用，比如開發(fā)人員需要某種類，軟件平臺知識圖譜則會返回指定類，并將其屬性一并展示。

軟件平臺知識圖譜的內(nèi)部知識流動以及知識圖譜與開發(fā)人員之間的知識流動如圖1所示。首先從軟件平臺開發(fā)源代碼中進(jìn)行組件關(guān)聯(lián)關(guān)系和代碼結(jié)構(gòu)的抽取，然后建立軟件平臺知識實(shí)體之間的關(guān)聯(lián)關(guān)系，將軟件平臺知識實(shí)體有機(jī)組合在一起，形成軟件平臺知識圖譜；軟件平臺知識存儲在知識庫中，與軟件平臺知識圖譜建立關(guān)聯(lián)，以實(shí)現(xiàn)知識更新；最后基于知識庫與軟件平臺知識圖譜建立檢索機(jī)制，滿足開發(fā)人員的文本檢索和形式化檢索兩種檢索需要。

圖1 知識圖流動圖

1.2 軟件平臺知識圖譜的構(gòu)建

軟件平臺開發(fā)項(xiàng)目中蘊(yùn)含豐富的知識實(shí)體與復(fù)雜的關(guān)聯(lián)關(guān)系，這些特性對軟件平臺知識圖譜的構(gòu)建提出了挑戰(zhàn)。基于以上問題，本文選擇了在對軟件平臺知識實(shí)體節(jié)點(diǎn)、實(shí)體間關(guān)聯(lián)關(guān)系和屬性的表示上具有更好表現(xiàn)力的屬性圖模型來完成軟件平臺知識圖譜的構(gòu)建?；趯傩詧D模型對軟件平臺知識的表示如下：屬性圖中的節(jié)點(diǎn)對應(yīng)著不同的軟件平臺知識實(shí)體，每個(gè)節(jié)點(diǎn)擁有唯一的標(biāo)識符，節(jié)點(diǎn)與節(jié)點(diǎn)之間由有向邊連接，每條邊代表著一個(gè)語義關(guān)聯(lián)且具有唯一標(biāo)識符。

軟件平臺知識圖譜的構(gòu)建流程如圖2所示，具體包括以下五個(gè)步驟：

1) 軟件平臺知識圖譜Schema層的構(gòu)建，本文采用自頂向下的方式構(gòu)建軟件平臺知識圖譜的Schema層；

2) 軟件平臺知識抽取，即從軟件平臺開發(fā)源碼中進(jìn)行知識實(shí)體、屬性及關(guān)系的抽?。?/p>

3) 軟件平臺知識表示，在獲取到新知識之后需要對其進(jìn)行體系化的表示，本文使用屬性圖模型進(jìn)行知識表示；

4) 軟件平臺知識融合，軟件平臺開發(fā)是一個(gè)階段性的過程，軟件平臺更新升級時(shí)有新的知識產(chǎn)生，在獲取到新知識后需要對其進(jìn)行整合；

5) 軟件平臺知識存儲，本文使用OrientDB圖數(shù)據(jù)庫完成對知識圖譜的存儲及形式化檢索。

圖2 軟件平臺知識圖譜的構(gòu)建流程

2 軟件平臺知識圖譜的構(gòu)建實(shí)例

2.1 Schema層的設(shè)計(jì)與構(gòu)建

構(gòu)建軟件平臺知識圖譜需要首先構(gòu)建Schema層。本文中采用自頂向下的方式應(yīng)用本體技術(shù)構(gòu)建軟件平臺知識圖譜的概念層，并對其進(jìn)行屬性的定義與約束。本文定義了四大基本類：Project(項(xiàng)目)、Package(包)、Class_code(類)、Method(方法)。對四大基本類的屬性定義如下：

Attribute Information

Project={(Name),(Location),(JRE),(Project layout)}

Pacakage={(Source folder),(Name)}

Class_code={(Source folder),(Package name),(Outer type),(Name),(Modifier),(Super class),(Interface),(Association)}

Method={(Class),(Access type),(Return type),(Name),(Method body),(Return value)(Association)}

根據(jù)四大基本類，定義了三種語義關(guān)系：

1) E_HasPackage(有包)：指代項(xiàng)目與包之間的關(guān)系；

2) E_HasClass_Code(有類)：指代包與類之間的關(guān)系；

3) E_HasMethod(有方法)：指代類與方法之間的關(guān)系。

需要注意的是，在軟件過程中，代碼編寫時(shí)的類間關(guān)系(Class_code Relationship)是較為重要的一部分，也是我們對編程人員進(jìn)行知識反饋時(shí)的重要依據(jù)，根據(jù)人工智能的主要理論范式之一——聯(lián)結(jié)主義[11]，對概念之間的關(guān)系強(qiáng)弱程度進(jìn)行標(biāo)注，更便于后續(xù)推理與人工神經(jīng)網(wǎng)絡(luò)的學(xué)習(xí)，因此在本研究中將編程中的類間關(guān)系單獨(dú)列舉出來，分為Dependency relationship(依賴關(guān)系)、Association relationship(關(guān)聯(lián)關(guān)系)、Aggregation relationship(聚合關(guān)系)、Composition relationship(組合關(guān)系)、Inheritance ship(繼承關(guān)系)。這些關(guān)系的耦合度依次增強(qiáng)且在語義上有所區(qū)別，需要結(jié)合上下文環(huán)境進(jìn)行分析。除此之外，本文還對方法參數(shù)(Method parameter)、調(diào)用關(guān)系(Call relationship)和返回值(Return value)等關(guān)系的屬性進(jìn)行了定義。

對于軟件平臺實(shí)體之間的關(guān)聯(lián)關(guān)系定義如下：

Correlation Information

Dependency relationship={(Class,Class),(Class,Interface)}

Association relationship={(Class,Class),(Class,Interface),(Class,Interface),(Method,Method)}

Aggregation relationship={(Class,Class)}

Inheritance relationship={(Class,Class),(Interface,Interface)}

Realize relationship={(Class,Interface)}

Call relationship={(Method,Method)}

Inclusion relationship={(Package,Class),(Package,Interface),(Class,Method),(Interface,Method)}

Method parameter={(Method,Class),(Method,Interface)}

Return value={(Method,Class),(Method,Interface)}

2.2 知識抽取

本文使用QDox[12]工具從軟件平臺開發(fā)代碼中抽取了類、接口和方法定義，在獲取到以上信息的基礎(chǔ)上再通過遞歸的方式進(jìn)行剩余信息的獲取。將java文件或者包含java文件的文件夾加載到QDox后執(zhí)行迭代，采用不同的方法從源代碼中提取不同種類的元數(shù)據(jù)，包括給定源中的包、包中的所有可用類、類中定義的方法、方法內(nèi)的返回類型、方法可用的所有參數(shù)和返回方法的類型等。

QDox的輸出信息以字符串的形式存儲元數(shù)據(jù)，隨后將抽取到的元數(shù)據(jù)根據(jù)Schema層定義的頂層框架進(jìn)行相應(yīng)的實(shí)體填充。本文面向CIFLog3的HWGeoModel模塊抽取出的部分實(shí)體信息如表1、表2所示。

表1 HWGeoModel模塊實(shí)體統(tǒng)計(jì)表

表2 HWGeoModel模塊實(shí)體關(guān)聯(lián)關(guān)系統(tǒng)計(jì)表

2.3 知識表示

知識圖譜是一種圖的網(wǎng)絡(luò)結(jié)構(gòu)，因此知識圖譜模型可以使用W3C提出的RDF或者屬性圖來進(jìn)行表示，本文選用支持圖數(shù)據(jù)庫的屬性圖模型來對軟件平臺知識進(jìn)行形式化表示。

圖3描述了一個(gè)OrientDB的屬性圖模型，開發(fā)代碼中的類“GeoModelUtils”與方法“GetWgWell”之間的關(guān)系是“E_HasMethod”。其中：@rid是唯一標(biāo)志符；@class是實(shí)體類型，也就是對應(yīng)的概念類；out對應(yīng)的是頭節(jié)點(diǎn)即“Class_code”節(jié)點(diǎn)；in對應(yīng)的是尾節(jié)點(diǎn)也就是“Method”節(jié)點(diǎn)；“Name”等鍵值對應(yīng)的則是對于對應(yīng)節(jié)點(diǎn)屬性的描述。

圖3 屬性圖實(shí)例

2.4 軟件平臺知識融合

知識融合是軟件平臺知識圖譜必須考慮的重點(diǎn)。雖然本文中的數(shù)據(jù)源僅為軟件平臺本身，但由于軟件平臺需要不斷更新，知識圖譜的構(gòu)建過程就避免不了直面知識之間的沖突與不一致性，因此在進(jìn)行知識融合之前要進(jìn)行知識評估的操作。本文采用基于模糊集理論的知識評估方法[13]對軟件平臺知識集合X={x1,x2,…,xN}進(jìn)行評估，主要經(jīng)歷gλ模糊測量、知識融合和最優(yōu)決策三個(gè)步驟。

gsp(Y)=P(Y|Y)

(1)

2) 知識融合。知識融合通過式(2)的模糊積分實(shí)現(xiàn)[14-15]，其計(jì)算不同知識源提供的知識的最大一致化程度，模糊積分中的隸屬函數(shù)實(shí)現(xiàn)對知識源觀測值的模糊化，隸屬函數(shù)根據(jù)實(shí)際情況進(jìn)行選取。設(shè)軟件平臺知識實(shí)體集合為X={x1,x2,…,xN}，其Borel域?yàn)棣?，h為軟件平臺知識的隸屬函數(shù)，h:X→[0,1]，則在A?X上的模糊積分的計(jì)算公式如下：

(2)

g需滿足以下條件：

(3)

3) 最優(yōu)決策。對于軟件平臺知識實(shí)體集合X={x1,x2,…,xN}，最優(yōu)決策是指通過融合處理后最優(yōu)判斷的估計(jì)結(jié)果。經(jīng)過以上步驟，發(fā)現(xiàn)Y對g(Y)的值有著正向影響，因此有知識融入判別式：

(4)

經(jīng)過以上有關(guān)模糊積分的計(jì)算就完成了軟件平臺知識質(zhì)量評估，并找到置信度最高的知識作為正確知識，并對數(shù)據(jù)庫中存儲的知識實(shí)體進(jìn)行知識節(jié)點(diǎn)的完善和更新。

2.5 知識存儲

本研究選用OrientDB圖數(shù)據(jù)庫進(jìn)行數(shù)據(jù)存儲，選用它的原因在于其支持多種模式，可以對圖形、文檔、關(guān)系等進(jìn)行較好的存儲和形式化表示，也可以為圖數(shù)據(jù)庫的管理提供橋梁，同時(shí)它支持SQL語句和類SQL語句。應(yīng)用OrientDB對從軟件開發(fā)代碼中獲取到的實(shí)例層數(shù)據(jù)進(jìn)行知識整合和存儲時(shí)需要先創(chuàng)建模式，根據(jù)前面對Schema層的定義，創(chuàng)建概念類包括項(xiàng)目(C_Project)、包(C_Package)、代碼類(C_Class)、方法(C_Method)、有包(E_HasPackage)、有類(E_HasClass_Code)、有方法(E_HasMethod)。

創(chuàng)建好模式之后則需要根據(jù)Schema層定義的類載入節(jié)點(diǎn)信息以及節(jié)點(diǎn)之間的關(guān)系。在導(dǎo)入數(shù)據(jù)信息時(shí)為了防止重復(fù)的節(jié)點(diǎn)信息和重復(fù)的關(guān)系，使用SQL查詢語句進(jìn)行是否重復(fù)的判斷，并進(jìn)行去重處理。

2.6 知識圖譜可視化

OrientDB支持的圖結(jié)構(gòu)可以滿足開發(fā)人員對知識的檢索。在OrientDB上可以直接使用SQL語句進(jìn)行知識查找，查找結(jié)果將以圖形的形式表示出來，包括節(jié)點(diǎn)與關(guān)系，同時(shí)對不同的知識類別的展示有顏色上的區(qū)別。

圖4列出了在CIFLog知識圖譜中對水平井解釋模塊“HWGeoModel”的圖形可視化檢索結(jié)果，包括其下包含的包、其存儲位置，以及與其有關(guān)聯(lián)關(guān)系的其他模塊。圖4中間的三個(gè)節(jié)點(diǎn)代表CIFLog中的模塊，從左到右分別是多井評價(jià)模塊、水平井解釋模塊和數(shù)據(jù)管理模塊，外圈顏色深淺不同的實(shí)體分別代表多井評價(jià)模塊、水平井解釋模塊和數(shù)據(jù)管理模塊下的包。

圖4 “HWGeoModel”模塊形式化檢索結(jié)果

圖5為編程人員對“GeoModelUtils類”的圖形可視化查找結(jié)果，圖中顯示了與該類有關(guān)的其他元數(shù)據(jù)，如：所屬包、調(diào)用的方法、屬性(圖中顯示的是其存儲路徑)，以及與“GeoModelUtils”調(diào)用了相同方法的類以及他們之間的關(guān)系。圖中“wellData”、“getWgWellLog”和“getWgWellLog”三者之間的關(guān)系如下：“wellData”調(diào)用了“getWgWellLog”方法，然后將其返回值返回給“GeoModelUtils”繼續(xù)使用。

圖5 “GeoModelUtils類”形式化檢索結(jié)果

圖6為對水平井解釋模塊下的“cif.hwgeomodel.wizards”包的檢索結(jié)果，圖中列出了該包中包含的類(Class_code)，以及其所屬的項(xiàng)目。

圖6 “cif.hwgeomodel.wizards”包形式化檢索結(jié)果

3 結(jié) 語

本文針對軟件平臺開發(fā)過程開發(fā)人員難以直接利用軟件平臺知識的問題，提出構(gòu)建軟件平臺知識圖譜的方法，并構(gòu)建了CIFLog軟件平臺知識圖譜實(shí)例對該方法進(jìn)行了驗(yàn)證。實(shí)驗(yàn)證明，構(gòu)建軟件平臺知識圖譜能夠?qū)浖脚_開發(fā)知識進(jìn)行體系化的表示，極大地提高了軟件開發(fā)人員對平臺結(jié)構(gòu)知識的理解和使用，方便了開發(fā)人員基于軟件平臺的開發(fā)工作。

軟件平臺知識圖譜的構(gòu)建是一個(gè)階段性的過程，隨著軟件平臺的更新，知識圖譜也應(yīng)做出變化。軟件平臺知識圖譜需要改進(jìn)的地方還有很多，比如軟件平臺的知識獲取方法、軟件平臺知識學(xué)習(xí)以及知識更新機(jī)制等。