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

(東北石油大學計算機與信息技術學院 黑龍江 大慶 163318)

Graph database

0 引 言

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

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

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

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

通過以上研究和實際項目的驅動，本文對目前大型軟件平臺存在的問題總結如下：

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

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

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

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

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

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

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

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

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

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

圖1 知識圖流動圖

1.2 軟件平臺知識圖譜的構建

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

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

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

2) 軟件平臺知識抽取，即從軟件平臺開發(fā)源碼中進行知識實體、屬性及關系的抽??；

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

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

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

圖2 軟件平臺知識圖譜的構建流程

2 軟件平臺知識圖譜的構建實例

2.1 Schema層的設計與構建

構建軟件平臺知識圖譜需要首先構建Schema層。本文中采用自頂向下的方式應用本體技術構建軟件平臺知識圖譜的概念層，并對其進行屬性的定義與約束。本文定義了四大基本類：Project(項目)、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ù)四大基本類，定義了三種語義關系：

1) E_HasPackage(有包)：指代項目與包之間的關系；

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

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

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

對于軟件平臺實體之間的關聯(liá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ā)代碼中抽取了類、接口和方法定義，在獲取到以上信息的基礎上再通過遞歸的方式進行剩余信息的獲取。將java文件或者包含java文件的文件夾加載到QDox后執(zhí)行迭代，采用不同的方法從源代碼中提取不同種類的元數(shù)據(jù)，包括給定源中的包、包中的所有可用類、類中定義的方法、方法內的返回類型、方法可用的所有參數(shù)和返回方法的類型等。

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

表1 HWGeoModel模塊實體統(tǒng)計表

表2 HWGeoModel模塊實體關聯(lián)關系統(tǒng)計表

2.3 知識表示

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

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

圖3 屬性圖實例

2.4 軟件平臺知識融合

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

gsp(Y)=P(Y|Y)

(1)

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

(2)

g需滿足以下條件：

(3)

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

(4)

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

2.5 知識存儲

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

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

2.6 知識圖譜可視化

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

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

圖4 “HWGeoModel”模塊形式化檢索結果

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

圖5 “GeoModelUtils類”形式化檢索結果

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

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

3 結 語

本文針對軟件平臺開發(fā)過程開發(fā)人員難以直接利用軟件平臺知識的問題，提出構建軟件平臺知識圖譜的方法，并構建了CIFLog軟件平臺知識圖譜實例對該方法進行了驗證。實驗證明，構建軟件平臺知識圖譜能夠對軟件平臺開發(fā)知識進行體系化的表示，極大地提高了軟件開發(fā)人員對平臺結構知識的理解和使用，方便了開發(fā)人員基于軟件平臺的開發(fā)工作。

軟件平臺知識圖譜的構建是一個階段性的過程，隨著軟件平臺的更新，知識圖譜也應做出變化。軟件平臺知識圖譜需要改進的地方還有很多，比如軟件平臺的知識獲取方法、軟件平臺知識學習以及知識更新機制等。