面向操作系統可靠性保障的開源軟件供應鏈?

梁冠宇,武延軍,吳敬征,趙 琛

1(中國科學院 軟件研究所,北京 100190)

2(中國科學院大學,北京 100190)

3(計算機科學國家重點實驗室(中國科學院 軟件研究所),北京 100190)

1 研究背景

傳統的軟件可靠性研究重點關注單個軟件在規(guī)定時間間隔內和規(guī)定條件下,系統或部件執(zhí)行所要求功能的能力[1].單個軟件的可靠性研究,通常會將軟件拆分為多個獨立的模塊,之后基于不同的模型,結合軟件模塊間的關系以及各個模塊自身的故障率進行分析,得出軟件最終的可靠性評估結果[2].

然而,隨著開源協作模式的不斷發(fā)展,軟件的構成和開發(fā)過程都發(fā)生了巨大的變化.現今,軟件開發(fā)更加關注敏捷和高效,基礎功能通常會優(yōu)先考慮復用相關的開源軟件,開發(fā)者僅需要進行必要的擴展和改進即可.這種模式可以有效降低軟件開發(fā)的成本,加速軟件迭代,降低開發(fā)門檻,加快響應需求的速度.Octoverse(https://octoverse.github.com/,收集Github 個人開發(fā)者活動數據,并從多個維度進行描述)年度報告顯示,截至2019 年底,平均有超過360 萬個開源倉庫對前50 的開源項目有依賴,平均每個開源項目包含180 個包依賴,超過35 萬名開發(fā)者參與排名前1 000 的開源項目,總貢獻超過500 萬次.此外,有超過130 萬名開發(fā)者在2019 年首次為開源軟件做出貢獻.從以上數據不難看出,在開源協作模式下,軟件之間的依賴關系將會變得更為普遍和繁雜.

操作系統是指管理計算機硬件資源和軟件資源的系統程序集合,包括內核及其他系統工具[3].由Linux 內核衍生出的操作系統發(fā)行版(如Ubuntu、CentOS、Android 等),統稱為Linux 發(fā)行版,它們將眾多實現不同功能的開源軟件,以軟件包的形式與Linux 內核有機地整合在一起,以滿足終端用戶不同的使用需求[4].DistroWatch(https://distrowatch.com/,專注于收集和探討開源操作系統發(fā)行版的最新信息)的數據顯示,較為常用的Linux 發(fā)行版,僅一個版本就需要維護數以萬計的軟件包以支撐自身的功能和生態(tài)(如Ubuntu 18.04 涉及29 207 個軟件包、Debian Unstable 涉及32 453 個軟件包等),即便是通過剪裁構建而成的較為精簡的系統,也包含近百個軟件包.在沒有工具幫助的情況下,按照正確的順序和依賴關系安裝軟件包,需要具備必要的專業(yè)知識,以及進行瑣碎的準備工作.為應對這一問題,軟件包管理工具作為Linux 發(fā)行版的必備組件,依據功能將開源軟件拆分或合并為不同的軟件包,并維護它們之間的依賴關系,以有效地減輕用戶管理軟件的負擔.此外,為方便用戶構建符合自定義需求的Linux 發(fā)行版,包管理工具作為構建工具的核心組件,幫助用戶理清需要添加的軟件模塊間的依賴關系.除了基于包管理工具實現的構建工具外,Linux 社區(qū)發(fā)起了Linux From Scratch(LFS)項目,旨在指導用戶如何從零開始構建操作系統,以及依靠包管理工具提供包依賴關系并實現不同系統構建,LFS 衍生出ALFS(automated Linux from scratch)項目,為用戶提供自動化構建工具.此外,還出現了Yocto 等更為高級的Linux 發(fā)行版定制化構建項目,幫助Linux 發(fā)行版版本構建者屏蔽底層硬件架構的差異性.

如上所述,在開源協作模式下,Linux 操作系統發(fā)行版蘊含著復雜的軟件依賴關系,這使其可靠性不僅依賴內核本身,而且需要關注其他構筑起整個生態(tài)的開源軟件.盡管包管理工具能夠維護軟件包之間的依賴關系,但這些關系的可靠性更多地依賴于人工管理和維護,基于這些信息對開源協作模式下的大型復雜基礎軟件及其生態(tài)做出可靠性評估存在較大的局限性.相應地,已有的系統構建工具同樣僅關注構建功能本身,少有考慮最終構建生成的操作系統及其生態(tài)是否可靠.在已有的研究中,文獻[5]同樣關注到這樣的軟件組織形態(tài),稱在這種形態(tài)下形成的復雜網絡為開源供應鏈,并提出開源供應鏈所面臨的三大挑戰(zhàn):(1)個體開發(fā)者學習成本進一步增大;(2)群體協作更加復雜;(3)生態(tài)可持續(xù)性受到的威脅持續(xù)增加.除了這些挑戰(zhàn),當構建一款操作系統發(fā)行版時,開源軟件供應鏈可靠性還面臨著軟件本身特有的挑戰(zhàn),即:(1)軟件來源、許可和供應者的多樣性;(2)軟件質量的波動性和傳導性;(3)知識產權訴訟、出口管制等導致的供應中斷;(4)可持續(xù)維護和發(fā)展等.這些挑戰(zhàn)是影響現今開源操作系統及其供應關系可靠性的重要因素.

針對這些挑戰(zhàn),本文提出一種基于知識的面向開源協作模式下軟件供應可靠性的管理方法.首先面向開源軟件生態(tài)實現本體設計,并構建開源軟件知識圖譜,實現知識的提取、存儲和管理.以開源軟件圖譜所蘊涵的知識為驅動,結合傳統的供應鏈管理方法,面向開源軟件供應鏈提出一組可靠性管理方法,最終構成一套開源軟件供應鏈管理系統,應對上述挑戰(zhàn).本文第1 節(jié)對整體研究背景進行闡述.第2 節(jié)介紹本文涉及的相關領域成果.第3 節(jié)詳細介紹本文提出的開源軟件供應鏈系統.首先,進一步闡述開源軟件供應鏈的定義.之后,描述整個系統架構、數據管理和構建過程,以及可靠性管理方法.此外,還對基于軟件供應鏈實現的操作系統構建工具加以闡述,指出相對于已有構建工具(LFS和Yocto)有哪些優(yōu)勢.第4 節(jié)重點描述我們?yōu)轵炞C本文提出的方法而實現的原型系統,并以面向RISC-V 構建原生操作系統為例,對當前系統功能進行驗證,并對面向該操作系統維護的開源軟件供應鏈進行可靠性評估.最后總結全文,并對未來的改進及研究方向進行探討.

2 相關工作

2.1 供應鏈及供應鏈管理

供應鏈的概念最早面向企業(yè)管理領域提出,最早可以追溯到20 世紀60 年代“物料需求計劃(marterial requirement planning,簡稱MRP)”.由于當時的企業(yè)產能較低,供需矛盾主要聚焦在資源上,MRP 的提出主要是為了解決原材料庫存與產品零部件投產量之間的計劃問題,以最少的投入和關鍵路徑作為其基本出發(fā)點.隨著企業(yè)間的競爭越來越激烈,企業(yè)對自身資源管理范圍也向著更加廣闊和精細化的方向發(fā)展,MRP 中單純面向物料的管理已無法滿足需求,于是企業(yè)進一步將物料和資金、人力、設備等資源關聯起來,進行更加全面的計劃和控制,使得MRP 進化為MRPII,即“制造資源計劃(manufacturing resource planning)”.隨著20 世紀90 年代信息化技術的引入,又提出了新的企業(yè)管理計劃——“企業(yè)資源計劃(enterprise resources planning,簡稱ERP)”,并成為大型企業(yè)管理的標配.供應鏈管理作為ERP 的核心,主要用以幫助企業(yè)明確業(yè)務流程,有效解決傳統企業(yè)管理中常見的機構人員重疊、資源利用率低等問題.

時至今日,根據目標需求、應用環(huán)境等的不同,有很多關于供應鏈的不同定義.其中,英國供應鏈管理專家Martin Christopher 在1998 年給出的定義具有較高的公共認可度,他將供應鏈定義為“供應鏈是一種由多個組織參與組成的網絡,在這個網絡中,組織以上下游的關系相互關聯,他們在不同的生產活動或過程中,以產品或者服務的形式為最終客戶產品貢獻價值”[6].

結合供應鏈的定義,我們可以更抽象地將供應鏈看作是一種生產資料的整合方式,它會盡可能全面地收集鏈上各方的數據,方便進行全局的分析和統籌,而對供應鏈數據的維護,以及對供應計劃的優(yōu)化等操作,可以統稱為供應鏈管理.Ellram 對供應鏈管理的定義得到了較為廣泛的認同——“供應鏈管理是供應商和消費者之間集成了控制和計劃的材料及產品流”[7].管理供應鏈系統的任務涉及很多方面,而核心任務主要涉及兩個方面,即性能管理和風險管理.Simchi-Levi 準確地描述了供應鏈性能管理——“供應鏈管理是通過一系列方法有效地整合供應商、制造商、倉儲、商鋪等資源,使企業(yè)能夠準確控制商品生產和分發(fā)的數量,同時確保必要的資源在正確的時間出現在正確的地點,使得供應鏈系統在滿足服務需求的同時,能夠最小化整體的開銷”[8].通過評估整體花銷和最終產出的關系,即可量化地描述一個供應鏈系統的性能.

供應鏈風險管理主要是為了應對工業(yè)界的發(fā)展趨勢,這些趨勢包括越來越多的外包,更低的供應量基數,更精確的控制時間,更短的產品生命周期等,它們都極大地增加了企業(yè)供應鏈系統的風險[9,10].為了使供應鏈系統的風險可控,供應鏈風險管理將定制一系列策略實現對風險的識別、評估、處理和監(jiān)控[11-13].其中,風險識別作為首要任務,是開展其他任務的基礎[14].目前,各項研究中已經提出很多風險識別相關的策略,并且一部分已經在實際應用中得到驗證.風險評估通常基于數據或者專家經驗做出判斷[15],供應鏈系統中的風險通常不是孤立出現的,因此需要綜合考慮多個風險間的關聯關系,并根據策略模型評定它們的風險級別,即處理的優(yōu)先級[16].具體的風險處理方式依賴于針對供應鏈所處的環(huán)境,大致可以分為接受、避免、轉嫁、分擔和緩解[17].由于供應鏈的風險并非靜態(tài)不變的,因此需要時刻監(jiān)控以發(fā)現風險的發(fā)展動向,并作為調整處理策略的依據,由此也可以看出,風險的監(jiān)控不僅高度依賴于前3 項任務的結果,同時也需要具備一定的實時性[18].

本文的目標是維護可靠的開源軟件供應鏈,為實現自主構建可靠的開源操作系統提供技術支撐.結合上文所述的供應鏈管理方法,以及第1 節(jié)中對開源軟件供應鏈可靠性風險特征的描述,本文將更加關注如何實現開源軟件供應鏈的可靠性風險管理.在未來的工作中,我們將在風險可控的前提下,提升供應鏈管理的性能.

2.2 知識圖譜

關于知識圖譜并沒有一個明確的定義,大多數時候它能夠與信息科學中的“本體論”這一概念混用[19].最早在2012 年,Google 公司在其信息檢索系統的技術介紹[20]中首先使用“知識圖譜”這一名詞,之后的一系列相關研究中,“知識圖譜”被越來越廣泛地使用.一種相對認可度較高的定義是:知識圖譜是對實體描述的集合,這些實體具有內部的關聯關系,它們可以是真實世界中的對象、事件、某種具體的情況或者抽象的概念等,其中,(1)這些描述必須具有統一的結構,確保能夠同時允許人類和計算機以高效且明確的方式對其進行處理;(2)這些描述組成了一個網絡,且相互補充,使得每個實體都是其相鄰實體描述的一部分[21].

一般情況下,知識圖譜都具備以下組成部分.

·實體:知識網絡中具體的實例或對象;

·類別:符合某一特征或概念的實體的集合;

·屬性:用于描述實體的特征;

·關系:類別或者實體間的連接方式;

·事件:當屬性或者關系發(fā)生改變時產生.

此外,還具備以下特征.

·支持結構化查詢語言訪問;

·以圖的形式維護網狀數據;

·所維護的數據具備形式化語義,支持數據理解和推理;

·具備邏輯形式化,支持生成新的信息、強制一致性以及進行自動化分析;

·具備動態(tài)性,所維護的數據支持自動或人工的持續(xù)集成和持續(xù)更新.

本文選擇以實體圖為起點維護開源軟件供應鏈,不斷擴充內容,最終構建成一個開源軟件領域專用的知識圖譜,為后續(xù)工作奠定基礎.

2.3 常見的構建方法和工具

靈活、可定制是開源軟件的一大特性,開源操作系統亦是如此.然而,以Linux 系統為例,開源操作系統的復雜性使其定制工作的難度大為提升,相應地,也出現了不少開源項目旨在解決這一問題.由于篇幅有限,我們在本節(jié)中將重點介紹兩個較為有代表性的項目——LFS 和Yocto.

2.3.1 LFS

LFS 項目創(chuàng)建的目的,是為用戶提供一個從源代碼開始,一步一步構建定制Linux 操作系統的指導,希望在此過程中能夠幫助用戶理解系統內部的工作機制.本質上,LFS 可以被看作是一個框架,用戶可以根據自己的需求,添加和刪減功能,最終構建出一個壓縮度更高且定制性更強的系統.此外,LFS 強大的靈活性也可以幫助用戶加入自定義的安全組件,增強最終構建生成系統的安全性.為了增強整個項目的通用性,LFS 還有其他幾個子項目.

·BLFS(beyond Linux from scratch):以LFS 為基礎,指導用戶配置和構建包含更豐富功能軟件包的Linux 系統,如圖形化界面(LFS 構建生成的系統不包含圖形化界面);

·ALFS:如前文所述,該項目希望提供一個可擴展的系統構建器和包安裝器,以實現系統的自動構建;

·CLFS(cross Linux from scratch):在LFS 的基礎上,指導用戶通過交叉編譯技術實現面向不同體系架構來構建Linux 操作系統.

可以看出,LFS 及其子項目教育和指導的意義遠大于工程實用的意義,項目自身也明確聲明,用戶根據項目指導構建而成的操作系統不是最精簡的.要想構建出符合工程需求的系統鏡像,用戶不僅需要完全掌握LFS,能夠靈活應用其提供的框架,同時需要具備足夠的系統知識,才能保證正確的配置構建.雖然存在ALFS 這樣面向工程的項目,但是社區(qū)活躍度不高等因素導致其發(fā)展并未達到預期.在軟件包依賴(供應)關系方面,LFS 僅僅羅列了數量有限的軟件包作為示例,而更多的軟件包及其之間的關系則需要用戶自己去發(fā)掘和管理,供應關系可靠性的管理和驗證更是基本屬于空白,若將構建生成的系統直接投入生產環(huán)境使用,還存在極大的可靠性隱患.

2.3.2 Yocto

該開源項目的初衷,是為了幫助用戶構建基于Linux 的定制嵌入式操作系統,脫胎于OpenEmbedded 項目,后者專注于提供構建系統,目前Yocto 項目中的構建系統仍然延用OpenEmbedded 項目提供的構建系統,并由雙方共同維護.靈活性是Yocto 項目最為看重的特性之一,項目本身由3 個重要組件組成,即工具庫、發(fā)行版構建模板(名為Poky)以及前文提到的OpenEmbedded 構建系統.內容豐富的工具庫可以幫助用戶實現諸如自動化構建和測試、多芯片支持、編譯流程驗證、嵌入式系統組件信息驗證等功能,并支持不同用戶之間共享工具.發(fā)行版構建模板是一個完整的構建樣例,用戶可以通過該模板學習Yocto 的使用方法.此外,通過定制修改該模板的內容,用戶也可以構建定制化的系統發(fā)行版.

使用Yocto,用戶需要首先定義目標架構、構建策略、補丁等配置細節(jié);之后構建系統會根據配置獲取目標源碼,并根據策略在本地完成編譯構建,最終打包為指定的軟件包格式(如deb、rpm 或者ipk);當所有的軟件包構建完成,且通過了所有的檢測項,構建系統會將所有的軟件包打包成定制的軟件源;最后,基于該軟件源創(chuàng)建目標根文件系統鏡像.

從上述流程可以看出,前期用戶定義配置對于整個構建流程至關重要.Yocto 抽象出recipe、layer 等概念,對不同功能的構建配置實現封裝,用于簡化特性定制和功能復用,盡管如此,Yocto 仍然存在較為陡峭的學習曲線.此外,值得注意的是,在Yocto 中,構建配置所描述軟件包之間的依賴關系(即本文所稱的供應關系),需要由用戶自定義或直接繼承其他用戶共享的已有配置,但卻缺少有效的工具實現供應關系可靠性的監(jiān)督和檢查.

3 開源軟件供應鏈

3.1 定 義

正如前文所述,當下開源模式盛行,各大IT 行業(yè)巨頭都在開源方面投入了大量的人力和財力,這也為他們贏得了諸如市場認可度、技術發(fā)展主導權等諸多益處.例如,微軟公司曾經以Windows、Office 等閉源軟件而知名,近兩年已在開源社交網站Github 創(chuàng)建超過3 200 個開源倉庫,共吸引了超過4 300 名開發(fā)者參與其中,產出多達20 款成熟的開源軟件工具.在這種趨勢下,軟件開發(fā)的模式也發(fā)生變化,從之前的單人/單組織獨立開發(fā),變成現在的多人/多組織協作.在軟件模塊化設計的加持下,基于他人已發(fā)布的開源軟件模塊,構建自己定制軟件的開發(fā)模式逐漸成為主流,開源操作系統就是這種模式的典型產物.因此,基于開源軟件這種特殊的生產方式,同時結合第2.1 節(jié)中描述的供應鏈定義,可以得出:開源軟件供應鏈的核心即是將開源軟件模塊間的依賴關系,看作是一種對操作系統構建的供應關系.為了更直觀地描述,可以進行如下概念映射.

·商品:交付給最終用戶的軟件,本文即特指大型復雜操作系統及相關軟件包;

·制造商:設計實現開源軟件模塊的個人或組織;

·供應商:提供開源軟件服務的公司或個人;

·倉儲:集中托管開源軟件的倉庫.

從概念映射可以看出,相較于傳統的軟件依賴關系模型,開源軟件供應鏈能夠更全面地描述軟件的構成,除去構成軟件本身的各個模塊外,還引入了模塊的開發(fā)者、維護者以及獲取源等維度.構建開源軟件供應鏈的初衷,即是為了解決在當前模式下,如何保證開源軟件可靠性的問題.以供應鏈的視角看待開源軟件,我們能夠以一種新的視角來審視大型復雜軟件的構成,使我們更有可能發(fā)現軟件潛在的可靠性風險,以應對文獻[5]中提出的挑戰(zhàn).

定義1(面向操作系統可靠性保障的開源軟件供應鏈).一個擴展的有限自動機A=(Q,O,Σ,ρ,q0,F),其中,

·Q={S1,S2},表示有限的狀態(tài)集合,其中,S1表示可靠狀態(tài),S2表示不可靠狀態(tài);

·O=O1∪O2∪···∪On,表示各Linux 發(fā)行版提供的軟件包集合,其中,On表示某一種Linux 發(fā)行版;

·Σ={ωi|ωi∈Oj},表示有限的輸入集合,其中,ω表示屬于發(fā)行版Oj的開源軟件包;

·可靠性管理方法ρ:Σ→{0,1},判斷軟件包是否可靠;

·狀態(tài)轉換函數δ:Q×ρ(Σ)→Q,狀態(tài)轉換關系如圖1 所示;

·q0=S1,表示初始狀態(tài);

·F={S1},表示接受狀態(tài)集合;

·L()A={ω|ρ(ω)=1,ω∈Oj},表示面向某一Linux 發(fā)行版Oj,可靠的開源軟件供應鏈.

Fig.1 The state diagram of supply chain system of open source software圖1 開源軟件供應鏈狀態(tài)圖

基于定義1,本文研究的問題轉化為設計一種可靠性管理方法ρ,從軟件包集合Σ中篩選出符合輸出狀態(tài)集合F的軟件包子集,組成面向Linux 發(fā)行版的可靠的開源軟件供應鏈.為實現這一目標,我們結合傳統供應鏈管理積累的經驗以及知識圖譜對數據豐富的表達能力,構建了一套以開源軟件圖譜為核心的開源軟件供應鏈系統,整體架構如圖2 所示,各組件職責如下.

·圖形化界面(GUI):直觀地展示開源軟件供應鏈系統,方便用戶獲取豐富的信息,包括開源軟件之間的依賴關系圖、開源軟件的可靠性分析圖表等;

·應用編程接口(API):以服務接口的形式對外提供開源軟件供應鏈系統的能力,如供應關系獲取、開源軟件可靠性分析等;

·數據源(data source):系統以軟件包管理器作為數據源,提取開源軟件間的供應關系,同時通過Github 等上游倉庫抽取開源軟件的補充信息,如軟件自身的演化信息、作者信息等,以豐富供應鏈系統中的數據信息;

·數據源驅動程序(data source driver):為采集不同的數據源的數據,提供不同驅動程序,驗證采集到的數據,并轉換為統一的格式方便系統存儲和管理;

Fig.2 The architecture of supply chain system of open source software圖2 開源軟件供應鏈系統架構圖

·實體圖(entity graph):系統的核心數據結構——以實體圖的形式維護所有數據信息,實體種類除了開源軟件外,還包括人員、公司(或組織)等多種其他類型,實體間的關系也豐富多樣,包括供應、開發(fā)、維護、從屬等,以直觀的形式建模整個開源世界的供應關系,本文將在第3.2 節(jié)詳細介紹這部分內容;

·控制器(controller):負責協調和分發(fā)后臺任務,包括數據分析和狀態(tài)監(jiān)控;

·分析器(analyzer):以插件的形式實現,負責執(zhí)行指定的分析任務,如軟件可靠性分析等;

·事件通知器(notifier):以插件的形式實現,負責當系統生成事件時(如監(jiān)控發(fā)現異?；蛘叽嬖跐撛陲L險),發(fā)送通知至指定的位置.

3.2 數據管理

本節(jié)重點介紹開源軟件供應鏈系統的數據管理實現.如前文所述,系統以實體圖的形式組織和維護供應鏈相關信息,相比于其他數據組織形式,實體圖能夠更加直觀地反映實體間的關系,蘊含更加豐富的語義信息,便于理解數據本身并推導出新的事實.隨著數據體量的不斷增大和數據內容的不斷豐富,最終目標是將其建設成為一個關于開源軟件供應鏈的知識圖譜.

3.2.1 本體設計

本體設計是知識圖譜構建的首要步驟,在該步驟中,我們需要抽象定義圖譜中所包含的實體類型,并梳理它們之間的關系,最終以圖的形式將它們組織起來.為了限制知識圖譜的規(guī)模和復雜性,在本文中,我們限定知識圖譜在開源軟件領域.如圖3 所示,當前我們共定義了五大實體類型.

Fig.3 The ontology design of knowledge graph of open source software圖3 開源軟件知識圖譜本體設計

·軟件(software):軟件是開源軟件圖譜的核心實體類型,根據開源軟件的協作模式,我們進一步分為包(package)和操作系統(OS)兩個實體子類型,和軟件實體類型是“isA”的關系,其中,包是軟件中最小粒度的實體,而操作系統是由多個包組裝而成的,因此它們之間存在“hasComponent”的關系,而包之間的供應關系通過“hasSupplier”來描述,包自身的演化關系通過“hasPreversion”來描述;

·開源協議(license):該實體類型描述某一種具體的開源協議,軟件必須“obey”一種或多種開源協議,它限制了開源軟件的使用方式,對開源軟件的可用性存在潛在的影響,因而使得開源軟件供應鏈存在潛在的可靠性風險;

·地理位置(location):該實體類型描述某一個具體的地理位置,和組織或者人員是一對多的關系,由于任何一個軟件都至少由一個組織或個人維護,進而使得軟件包本身帶有地理位置的屬性,通常情況下,組織或個人需要遵守當地的法律,而當由于政治等因素導致某個國家通過法律手段,限制某個組織或個人對其所擁有開源軟件的開放等級時,開源軟件間現有的供應關系極可能遭到破壞;

·組織(organization):該實體類型描述某一個具體的組織,可以是開源組織,或者是提供開源軟件的公司,它們對某些開源軟件有實際的控制權,因此存在“hasController”的關系.同時,它們“l(fā)ocateAt”某一個具體的地理位置,需要遵守當地的法律法規(guī);

·人員(human):該實體類型描述某一個具體的開發(fā)或維護人員,它們既可以是以個人名義,亦或者屬于(“hasEmployee”)某一個具體的組織為開源軟件做出貢獻,因此它們和軟件之間存在“hasContributor”的關系.同時,某個人員可能以個人名義對某個開源軟件有實際控制權,因此,它們與軟件之間也可能存在“hasController”的關系.

為了簡潔起見,圖3 中僅展示了基本的實體類型和它們之間的關系,省略了每個實體類型所包含的屬性,這一部分內容將在第4.1 節(jié)中給出進一步的描述.

3.2.2 構建過程

構建本文提出的開源軟件知識圖譜,主要分為兩個步驟,如圖4 所示,具體如下.

Fig.4 The data flow diagram for contructing the knowledge graph of open source software圖4 開源軟件知識圖譜數據流圖

1)基礎圖譜構建

這一步驟以現有包管理器(RPM(常用包管理工具,Red Hat、Fedora、openSUSE、CentOS 等主流操作系統發(fā)行版的核心組件)、APT(常用包管理工具,Debian、Ubuntu 等主流操作系統發(fā)行版的核心組件)等)作為數據源,以目標構建的操作系統中提供核心功能的軟件包作為“種子”,通過挖掘“種子”軟件包的供應鏈條,即可得到基本的供應關系圖譜,同時為每個軟件包實例填充基本的屬性信息.需要注意的是,在此過程中,會判斷某一軟件實體是否已經存在,若存在,則不會重復添加.該基礎圖譜僅包含軟件包基本信息,如“name”“size”等,而“features”“maintainers”等屬性的信息則無法獲取,因此需要通過第2 步來完善和擴展整個圖譜的“知識量”.

2)擴展補充信息

這一步驟基于第1 步生成的基礎圖譜,分3 個子步驟完成信息擴充.

(a)從基礎圖譜中,遍歷每個Package 類型實體,提取上游(upstream)軟件的主頁地址;

(b)訪問每個上游軟件的主頁,抽取源碼獲取方式,即開源代碼倉庫地址,如GitHub 中的倉庫地址等;

(c)訪問上游代碼倉庫,抽取軟件的歷史版本信息,包括每個版本的版本號、累計提交信息(即自身演化歷史)、參與開發(fā)人員信息、版本特性、已知問題等,若個別信息不全,則需在上一步從主頁中抽取補充.

正如第2.2 節(jié)所述,知識圖譜的重要特性之一即是具備動態(tài)性.對開源軟件知識圖譜而言,圖4 所描述的流程可以理解為一次完整的更新過程,隨著新“種子”的不斷補充,圖譜的“知識量”也會不斷擴充,為整個開源軟件供應鏈的可靠性管理提供充分的數據支持,同時為未來工作打下堅實的基礎,如提供智能化的操作系統自主構建服務.

3.3 可靠性風險管理

如前文所述,本文關注的可靠性并非一般意義上單體軟件的可靠性,而是在當前開源軟件模式下,由于文獻[5]所描述的三大挑戰(zhàn)而引入的開源軟件生態(tài)可靠性風險.結合供應鏈風險管理的4 個主要任務——即識別、評估、處理和監(jiān)控(我們認為在開源軟件供應鏈風險管理中,識別和評估兩個任務的界限較為模糊,故本文將其合并為一個任務),我們在系統中設計并實現了相關的策略和功能,在實現可靠性風險管理的同時,在一定程度上解決開源軟件供應鏈面臨的三大挑戰(zhàn).

3.3.1 識別和評估

為識別供應鏈中的可靠性風險,我們提出一種開源軟件可靠性的度量模型,使系統能夠量化地描述軟件可靠性,具體度量項及描述見表1.在度量模型中,主要分為兩大部分,即軟件包本身及其所依賴的供應鏈,這一模型也是為了直觀地表述我們對現代軟件構成的認識,即可靠性不僅依賴軟件本身的一些指標,同時也與其復雜的依賴項密切相關.在模型中,我們除了關注常規(guī)的度量項,如社區(qū)活躍度、開源協議等,還重點關注了開源軟件的地理屬性,包括參與貢獻人員、維護(或擁有)者的國籍分布,以及供應鏈中其他依賴項的國籍分布,這是為了能夠更直觀地描述,由于政治因素而引入的潛在的可靠性風險.同時,我們還關注軟件包的可替代性,顯而易見,無法被替代的軟件包將成為整個供應鏈中較為脆弱的一環(huán).

Table 1 Reliability metrics of open source software表1 開源軟件可靠性度量

在本文提出的系統中,結合第2.2.2 節(jié)中描述的本體設計可以看出,度量模型中的基礎項,如軟件包的歸屬、所遵循的開源協議等,已經存在于開源圖譜中,而其他進階數據,如可替代性、各類分布等則需要基于基礎數據加工得到.最終,基于度量模型提供的數據,我們通過可靠性評分的形式,量化地描述任一軟件的可靠性.據我們所知,目前并沒有相關公開的基準數據集.因此,為了保證我們的系統對開源軟件可靠性評價的客觀性和公正性,在當前系統中,我們采用多種方法綜合考量的方式得到最終可靠性評分,并基于該評分實現開源軟件供應可靠性風險的識別和評估.

基于開源圖譜和度量模型,我們設計并實現了圖5 所描述的數據流程,以得到對軟件的可靠性評分.在目前的系統中,將可靠性評分限定在0～5 分,以小數表示中間分值,并保留小數點后兩位,如3.47.可靠性評分的計算過程如下:

Fig.5 The data flow diagram for generating evaluation of software’s reliability圖5 可靠性評分數據流圖

(1)更新途徑1 如公式(1)所示,e表示通過從互聯網上抽取相關事件信息,包括軟件直接相關的信息(如明確表示了限制使用或不再維護,或者在事實上已經處于無人維護的狀態(tài))、軟件歸屬國籍的政治因素(如存在出口管制,明確限制某些國家的組織或個人使用,或者明確限制某些用途)等,f表示具體的分值計算方法,因計算過程可與監(jiān)控任務復用,故在第3.3.3 節(jié)中具體描述,此外,由公式(4)可以看出,當某一軟件其供應關系中包含了該受事件影響的軟件包,其可靠性評分也會受到相應的影響;

(2)顯然,僅僅通過途徑1 獲取的可靠性評分依據將十分有限,對于尚未獲得初始評分的軟件包,我們基于度量模型提供的數據對軟件包進行聚類,如公式(2)所示,這使得具有類似“可靠性特征”的軟件包能夠歸為一類,之后即可基于相似度為尚未獲得評分的軟件賦予初始化評分;

(3)在途徑1 能夠獲取的數據極端稀少的情況下,通過途徑2 賦予的初始化評分,其參考價值十分有限,因此在途徑3 中,我們允許用戶基于系統提供的度量信息,對任一軟件的可靠性進行評分,并最終綜合全部用戶的評分,得到某一個軟件的可靠性評分,如公式(3)所示,可以看出,考慮到用戶不同的專業(yè)水平,我們在綜合所有評分時,使用加權平均的方式,用戶的專業(yè)水平與其評分的權值成正相關,通過這一途徑,我們能夠從大眾對生態(tài)可靠性的認知中,獲取符合大多數人標準的可靠性評價,提升整個數據集的參考價值;

(4)基于度量模型,軟件自身的可靠性依賴于其供應鏈中軟件的可靠性,因此,當其他途徑更新了軟件的可靠性評分后,需要對該軟件所屬供應鏈上的軟件進行更新,我們以評分發(fā)生更新的軟件為起點,沿著供應關系逆向遍歷開源圖譜并更新途經軟件的可靠性評分,考慮到可靠性風險并不隨供應路徑的加長,而呈現衰減或增強趨勢,故我們以算數平均的方式計算新的可靠性評分,如公式(4)所示.這樣不僅可以保證計算的簡潔性,同時也可以直觀地表達其影響的傳播,進一步地,還可以反映出多種風險疊加的后果.為了保證每一次更新過程能夠收斂,我們規(guī)定只有前3 種更新途徑會觸發(fā)該更新過程.

3.3.2 處 理

如前文所述,供應鏈風險處理大致可以分為接受、避免、轉嫁、分擔和緩解.考慮到開源軟件供應鏈的特殊性,我們主要從可靠性風險的等級出發(fā),針對接受、避免和緩解這3 類提出風險處理方案.具體的風險等級劃分見表2,我們將風險等級劃分為低、中、高3 個等級.評分在3.5 分以上的軟件包風險較低,處理優(yōu)先級較低,可以采用暫時接受的處理方式;評分在1.5～3.5 分之間的軟件包屬于中等風險,需要采用必要的措施緩解風險;評分不足1.5 分的軟件存在高可靠性風險,必須以最高優(yōu)先級進行處理,做到完全避免.

Table 2 Risk level of reliability表2 可靠性風險等級

在本文提出的系統中,不會直接采取措施處理捕獲到的可靠性風險,而是會為改善軟件及其供應鏈的可靠性提供決策支持.具體地,系統在展示軟件可靠性度量信息的同時,會依據可靠性評分,由低到高推薦該軟件的供應鏈中需要被優(yōu)化風險的軟件包.配合第2.3.1 節(jié)中的評分機制和第2.3.3 節(jié)描述的監(jiān)控機制,系統將根據優(yōu)化的結果重新評估軟件的可靠性,最終使得被優(yōu)化軟件包所在供應鏈的可靠性風險降低.

3.3.3 監(jiān) 控

供應鏈系統是一個動態(tài)系統,鏈上各個節(jié)點的狀態(tài)會不斷動態(tài)地發(fā)生變化,相比一般的產品,軟件天然具有快速迭代的特性,開源軟件供應鏈的變化周期將進一步縮短,不確定因素更多.因此,可靠性風險管理的時效性顯得尤為重要,若不能及時捕獲對可靠性風險有影響的事件,會導致系統對風險產生錯誤的評估.結合第3.1 節(jié)中描述的系統架構,我們基于多個組件配合實現可靠性風險監(jiān)控流程,如圖5 所示(數據流程如圖5 中虛線部分所示).整個流程分為3 個階段,在數據采集階段,面向不同數據源(見表3)實現相應的驅動程序,分別負責采集相關數據,并以時序數據的形式保存;在數據分析階段,分析器程序基于歷史數據和最新捕獲的數據進行事件提取(在下文中詳述);若發(fā)現有效事件,則會觸發(fā)事件處理器分發(fā)至相應的處理流程,在目前的系統中,會觸發(fā)可靠性評估子流程,評估結果將反饋給監(jiān)控時序數據,用于優(yōu)化事件提取子流程的精確度.

Table 3 Risks to be monitored表3 風險監(jiān)控

在當前系統中,我們基于規(guī)則實現事件提取.結合我們提出的度量信息模型,總結了如表3 所示的6 種風險,表中同時展示了每種風險對應的度量信息模型中相關的屬性以及相關的數據來源.如前文所述,我們根據不同風險的不同數據源,實現了相應的數據驅動,因此也可以方便地為每種風險數據信息打上標簽,用于標識風險類型.事件提取子流程如圖6 所示,首先基于標簽判斷風險事件類型,若是表3 所示的前兩種風險類型,則基于關鍵字實現信息提取,主要包括軟件名稱和情感詞,對照系統預制的情感詞表即可得到影響因子;若為后4 種風險,同樣通過關鍵字匹配提取軟件名稱,之后通過對比歷史信息或計算得到的統計數據,即可得到風險的影響因子,具體的統計指標見表3,需要說明的是,當前指標是根據我們的經驗指定的,可以認為是經驗初始值,在未來的工作中,我們將根據系統收集的數據對指標進行調整.影響因子的意義是為了描述監(jiān)控到的事件對于軟件可靠性風險起正向影響還是負向影響,若事件結果能夠幫助降低風險,則認為影響是正向的;否則,認為影響是負向的.為簡化計算,當前,正、負向因子均取值為1,未考慮不同事件的影響力,隨著數據的積累和系統的完善,在未來工作中我們會通過引入權重的方式,進一步客觀地描述每一事件對軟件可靠性風險的影響.

Fig.6 The flow diagram for monitoring risks of reliability圖6 可靠性風險監(jiān)控流程

如圖7 所示,事件提取流程最終輸出的結果包括軟件包的名稱、事件類型以及影響因子.圖6 中的事件處理階段接收到以上信息后,按照以下公式更新可靠性評分:

為計算事件影響的可靠性評分,我們?yōu)槊總€軟件包維護了兩個變量——V和N.其中,V為數組,記錄每種風險事件捕獲后的影響因子累計結果,每一項初始值為1(為確保公式(6)計算結果在沒有任何負面影響時為滿分),公式(5)描述了累計結果更新規(guī)則,vi和v′i分別表示某一種風險事件累計值更改前和更改后的值,e表示本次捕獲到的該事件的影響因子.另一個變量N表示捕獲事件的次數,公式(6)描述了受事件影響的可靠性分值更新規(guī)則,式中,p表示最終分值,vi與式(5)中的含義相同,n表示風險類型的數量,Pmax表示滿分的分值(即當前所設置的5).當N為0 時,即未捕獲過相關事件,顯然,該途徑對可靠性分值沒有任何貢獻,故p值為0;當N大于0 時,通過累加所有風險的影響因子累計值得到總的可靠性評分,為保證最后的計算分值在區(qū)間[0,Pmax]內,添加正則項.顯然,當捕獲到負面事件時,根據公式(6)計算得到的結果將小于Pmax,且最終分值與捕獲到負面事件的數量呈負相關.結合第3.3.1 節(jié)更新途徑4 所描述的更新規(guī)則,監(jiān)控任務捕獲到的面向不同風險類型的事件,最終會對軟件的可靠性評分產生正面或者負面的影響.

Fig.7 The flow diagram for extracting events圖7 事件提取流程

3.4 基于可靠供應鏈構建操作系統

雖然以LFS 和Yocto 為代表的面向操作系統構建的開源項目,已經在一定程度上滿足了用戶構建定制化操作系統的需求,但仍然存在很多不足和需要改進的地方,尤其是在軟件生態(tài)可靠性方面.為解決可靠性問題,我們提出一種基于開源軟件供應鏈實現的構建方法[22],該方法使用本文提出的開源軟件供應鏈替換現有構建工具中軟件依賴關系管理方法.具體地,開源軟件供應鏈主要有以下貢獻.

·降低學習門檻:開源軟件供應鏈管理系統維護了軟件之間的供應關系,包括不同軟件之間的供應關系,以及從上游源碼到具體打包格式的供應關系.通過系統提供的檢索功能,用戶可以輕松獲取供應關系信息,不再需要構建人員花費大量精力去記憶這些信息,進而能夠保證用戶快速、準確、高效地完成工作;

·降低維護成本:開源軟件供應鏈管理系統能夠以圖形化的方式展示供應鏈信息,幫助用戶更直觀地管理供應關系,提升工作效率;

·提升生態(tài)可靠性:開源軟件供應鏈管理系統通過內部實現的可靠性風險管理相關機制,為用戶提供識別、評估、處理和監(jiān)控可靠性風險的功能,有效降低目標構建系統軟件生態(tài)的可靠性風險,提升可靠性.

4 實驗驗證及結果

4.1 系統實現

基于圖1 所示的系統架構圖,我們將系統按照功能組件進行拆分并分別實現,本節(jié)將從中挑出一些重要的實現細節(jié)加以描述.為了便于管理和維護,各組件以容器的形式部署在Kubernetes 集群上,我們使用4 臺配置相同的服務器搭建該集群,單臺服務器的配置見表4.

Table 4 Hardware configuration表4 硬件配置

實體圖是系統實現的重要組成部分,基于圖3 描述的本體設計,我們將其映射為圖8 所示的數據結構.具體地,我們嚴格按照面向對象的設計思想,將每個實體視作一個類,并為每個類定義相關的屬性和類型.在圖中,我們以不同形式的箭頭描述了類間的關系.其中,Entity 和 Relation 是基礎類型;空心箭頭表示繼承關系,即Software、License、Organization、Location、Human 繼承實現Entity,而Package 和OS 繼承實現Software;虛線單箭頭表示依賴關系,描述類屬性對其他類及其屬性的依賴關系;實線單箭頭表示關聯關系,即圖中Relation 通過from 和to 屬性分別指向關聯Entity 的key 屬性,將兩個不同的Entity 實例連接起來,以表示兩個Entity 之間存在某種Relation.

Fig.8 The data structure of knowledge graph of open source software圖8 開源軟件知識圖譜數據結構

在我們的實現中,使用圖數據庫保存知識圖譜數據.根據G2(當用戶尋找最優(yōu)解決方案時,G2(https://www.g2.com/)通過多維數據分析給出客觀的建議,幫助用戶做出決策)的推薦,在眾多候選的圖數據庫中,我們鎖定在排名前二的Neo4j(圖數據庫,2007 年發(fā)布第1 個版本,使用Java 語言開發(fā)實現)和ArangoDB(圖數據庫,2011 年發(fā)布第1 個版本,使用C++和Javascript 語言開發(fā)實現)兩款工具上,通過進一步比較,雖然Neo4j 的工程采用度更高,但在開放性方面,前者的社區(qū)版本(Neo4j 分為商用版本和社區(qū)版本)在橫向擴展能力上嚴重受限;相比之下,后者完全開源,因此我們選擇更具開放性的ArangoDB.基于ArangoDB 提供的數據訪問接口,我們根據實際的業(yè)務需求,參照RESTful[23]標準實現一套接口,用于其他組件檢索和更新實體圖.

由于開源軟件體量巨大,可以預見,開源軟件知識圖譜將包含海量的數據.為便于用戶探索和獲取相關知識,并進行直觀的數據分析工作,我們通過圖形化界面實現開源軟件供應鏈可視化,降低使用門檻.在實現供應鏈可視化時,需要同時兼顧全局信息的完整性和局部細節(jié)的明確性,然而,對開源操作系統發(fā)行版而言,供應鏈通常包含幾百甚至上萬個節(jié)點,這與有限的屏幕尺寸形成一組尖銳的矛盾.考慮到每一個開源軟件供應鏈其實都可以看作是一個有向無環(huán)圖(directed acyclic graph,簡稱DAG)[24].因此,在可視化供應鏈時,我們利用DAG 的特性,基于拓撲排序算法[25]實現供應鏈分層,即每屏只需要展示一層供應鏈節(jié)點的細節(jié),有效克服屏幕尺寸帶來的可視化供應鏈容量限制.同時,為了保留供應鏈的全局信息,我們會為每個供應鏈提供分層結構的全局縮略圖,在用戶查看某一層供應鏈細節(jié)時,在全局縮略圖中做相應標識,保證用戶獲取完整的信息.

此外,系統中的控制器、分析器和事件處理器均采用插件式實現,允許以插件的形式擴展系統相關功能,保證系統的靈活性和可擴展性.

4.2 可用性驗證

為驗證系統可用性,我們以一個面向RISC-V(一種基于精簡指令集(RISC)原則的開放指令集架構(ISA),由加州大學伯克利分校發(fā)起,常解釋為“開源硬件”)構建的精簡Linux 操作系統為例,為其構建并維護開源軟件供應鏈.該精簡操作系統以基本的文本編輯為使用場景,經過剪裁,確認僅需要保留bash、coreutil、passwd、systemdudev、util-linux、vim-minimal 這6 個核心軟件包.為便于檢索,類似第1.2.3 節(jié)所描述的構建過程,我們?yōu)樵摬僮飨到y加入了一個特殊的軟件實體,并將這6 個軟件包作為其供應依賴實體,將這些信息輸入系統即可將該操作系統的軟件實體加入到開源軟件圖譜中.提取該例所構建系統的軟件供應鏈時,只需要以該實體為起點進行檢索即可,最終生成開源軟件供應鏈共包含有112 個軟件包,相關統計數據如圖9 所示,包括開源協議分布、軟件維護者地理分布以及貢獻人員地理分布.

Fig.9 Statistics of open source supply chain圖9 供應鏈統計數據

通過開源協議分布數據可以看出,在該供應鏈中,LGPLv2+、GPLv2+、GPLv3+、BSD、MIT 這幾種協議的采用率較高,占到總數的73.2%.其中,采用率最高的是LGPLv2+,該種類型協議約束下的開源軟件允許商業(yè)軟件直接使用,但是不允許修改源代碼;GPLv2+和GPLv3+的采用率次之,總體來說,GPL 類協議約束下的開源軟件,允許使用和修改源代碼,但不允許修改后的代碼作為閉源商業(yè)軟件的一部分發(fā)布和銷售;BSD 和MIT 兩種協議約束更為寬松,既允許使用和修改,也允許商業(yè)發(fā)售.整體來看,目前大部分開源軟件所采用的協議以鼓勵開放和共享為主,同時,對于無條件索取的行為也在進一步加以限制.對于國內大部分軟件產品的供應鏈可靠性來說,若不盡快調整我們對開源的認知和態(tài)度,構建更加可靠的軟件生態(tài),這些限制無疑將在未來給開源軟件供應可靠性帶來巨大的挑戰(zhàn).

此外,從圖8 的兩個地理分布相關的圖例中,可以明顯地看出,在構建操作系統這類基礎軟件所需的開源軟件包中,無論是在項目維護者還是直接參與貢獻的人員中,我國的比例都相對較低.造成這種現象的原因,一方面可能是因為國內開源文化起步較晚,大部分從業(yè)人員或相關公司都對開源的理解有限,與此同時,基礎軟件開發(fā)也存在門檻相對較高且投入成本較大等現實問題,這些因素綜合起來導致整體參與度不高;另一方面,也可能是我國的開源貢獻人員在這些開源軟件中缺少話語權,很多建議和貢獻都很難被采納,因而導致貢獻度較低.顯然,較低的主導權和參與度會對開源軟件供應鏈的可靠性帶來巨大的風險.

根據第3.3.1 節(jié)描述的可靠性評分生成過程,在本實驗中,由于缺少途徑1 相關數據,我們主要依賴途徑3,為了盡可能地保證數據的客觀、有效,我們邀請了4 位長期從事基礎軟件可靠性和安全性研究的博士,10 位具備碩士學位或5 年以上工作經驗的相關專業(yè)從業(yè)者參與實驗,以及10 位有2 年以上開源軟件使用經驗的在讀研究生,所有評分參與者均依據系統提供的統計數據和自己的經驗進行打分.考慮到3 類人員不同的專業(yè)能力,為他們分別分配了0.5、0.3 和0.2 的權值.配合途徑2 和途徑4 的機制,系統最終收斂得到該供應鏈的可靠性評分.最終評分占比如圖10 中藍色柱形(“事件發(fā)生前”)所示,其中低風險為27.68%,中等風險為70.54%,高風險為1.79%.結合供應鏈統計數據,我們發(fā)現,參與人員的評分結果更加關注地理分布和開源協議類型這兩個指標的數據,評分較低的軟件包均歸屬于來自美國的組織或個人,同時采用的開源協議類型約束相對較大.這說明參與評分的人員對政治風險以及開源協議約束相對關注.進一步觀察后發(fā)現,活躍程度和可替代性等指標所起到的指導作用有限,是因為當前實驗用例中,目標系統的供應鏈在這些指標的數據并無明顯差異.

Fig.10 The proportion of reliability score圖10 可靠性評分占比

為驗證系統關于途徑1 以及事件監(jiān)控相關的能力,我們特意在系統評分穩(wěn)定后,通過事件注入的方式,注入事件“GNU 組織限制中國企業(yè)使用bash”.該事件中,“GNU”“bash”均為系統用于事件提取的關鍵字,“限制”是負向影響事件的關鍵字,當系統捕獲該事件后,系統對整個供應鏈的可靠性評分做出調整,結果如圖10 中橙色柱形(“事件發(fā)生后”)所示.從結果可以看出,由于負向事件的捕獲,系統對供應鏈中“bash”軟件包節(jié)點的可靠性評估做出相應的調整,同時,由于系統的更新機制,依賴“bash”的軟件包,其可靠性評分也相應做出調整.

5 總結

Linux 發(fā)行版、Android 等大型復雜操作系統的核心功能和生態(tài)都建立在大量開源軟件的基礎上,這些開源軟件構成了操作系統構建的供應鏈.事實證明,開源軟件也存在“斷供”的風險,如果供應鏈出現問題,那么操作系統構建和運行的基礎不再可靠.因此,開源操作系統能夠可持續(xù)、高質量發(fā)展的前提是保證開源軟件供應鏈可靠.本文通過借鑒傳統供應鏈方法,引入開源軟件供應鏈管理體系,建立開源軟件知識圖譜,從多角度分析評估開源軟件包及供應鏈的可靠性程度,更加全面地風險評價和消除建議,為大型復雜操作系統找出構建的關鍵環(huán)節(jié),也暴露出生態(tài)的脆弱環(huán)節(jié).本文提出的方法和系統也可以用于大數據、云平臺等其他復雜基礎設施軟件,并為這些軟件的定制化、智能化奠定供應鏈基礎.總體來看,本文有以下幾點貢獻.

·開源軟件知識圖譜:基于本文描述的構建方法,我們構建了一個面向開源軟件的知識圖譜,隨著知識的積累,該圖譜將維護海量開源軟件供應關系及軟件相關實體信息,為相關分析提供有力的數據支撐,同時也可以為大眾了解開源軟件世界開辟一條新的路徑;

·一種軟件供應可靠性管理方法:面向開源協作模式,我們通過構建開源軟件知識圖譜,以知識為核心,結合傳統的供應鏈管理方法,提出一組面向開源軟件供應鏈的可靠性管理方法;

·一種可靠性評估數據集的構建方法:不論學術界還是工業(yè)界,據我們所知,當前尚不存在大規(guī)?；鶞蕯祿捎糜谠u估開源軟件供應鏈的可靠性,基于本文提出的度量模型和評分方法,系統在使用過程中,將積累生成一個可以用于可靠性評估的有效數據集.

雖然軟件工程管理和供應鏈管理兩個研究領域已有大量的研究成果,但是作為交叉領域的軟件供應鏈管理尚處于萌芽階段,受限于已有成果,本文提出的系統仍有很多可以改進的地方.在未來的工作中,我們希望能夠在以下幾個方面作進一步的探索和研究.

·改進事件提取方法:當前系統采用基于關鍵字的事件提取方法,在提取效率和準確性方面都存在一定限制,在未來的研究中,可以考慮引入更為先進的自然語言處理模型提升效果;

·改進可靠性評估方法:當前系統在使用中,能夠積累大量有效的標注數據,在未來的研究中,可以基于這些數據挖掘度量模型中不同維度對于可靠性評估的貢獻值,進一步提升評估模型的準確性,提升可靠性評估的智能化程度;

·擴展開源軟件知識圖譜:當前系統構建的知識圖譜重點關注開源軟件供應關系的可靠性,在未來的研究中,可以考慮與已有的面向其他開源軟件領域知識的知識圖譜進行融合,使開源軟件知識圖譜具有更強的通用性.