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

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

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

3(計(jì)算機(jī)科學(xué)國家重點(diǎn)實(shí)驗(yàn)室(中國科學(xué)院 軟件研究所),北京 100190)

1 研究背景

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

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

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

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

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

2 相關(guān)工作

2.1 供應(yīng)鏈及供應(yīng)鏈管理

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

時(shí)至今日,根據(jù)目標(biāo)需求、應(yīng)用環(huán)境等的不同,有很多關(guān)于供應(yīng)鏈的不同定義.其中,英國供應(yīng)鏈管理專家Martin Christopher 在1998 年給出的定義具有較高的公共認(rèn)可度,他將供應(yīng)鏈定義為“供應(yīng)鏈?zhǔn)且环N由多個(gè)組織參與組成的網(wǎng)絡(luò),在這個(gè)網(wǎng)絡(luò)中,組織以上下游的關(guān)系相互關(guān)聯(lián),他們?cè)诓煌纳a(chǎn)活動(dòng)或過程中,以產(chǎn)品或者服務(wù)的形式為最終客戶產(chǎn)品貢獻(xiàn)價(jià)值”[6].

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

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

本文的目標(biāo)是維護(hù)可靠的開源軟件供應(yīng)鏈,為實(shí)現(xiàn)自主構(gòu)建可靠的開源操作系統(tǒng)提供技術(shù)支撐.結(jié)合上文所述的供應(yīng)鏈管理方法,以及第1 節(jié)中對(duì)開源軟件供應(yīng)鏈可靠性風(fēng)險(xiǎn)特征的描述,本文將更加關(guān)注如何實(shí)現(xiàn)開源軟件供應(yīng)鏈的可靠性風(fēng)險(xiǎn)管理.在未來的工作中,我們將在風(fēng)險(xiǎn)可控的前提下,提升供應(yīng)鏈管理的性能.

2.2 知識(shí)圖譜

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

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

·實(shí)體:知識(shí)網(wǎng)絡(luò)中具體的實(shí)例或?qū)ο?

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

·屬性:用于描述實(shí)體的特征;

·關(guān)系:類別或者實(shí)體間的連接方式;

·事件:當(dāng)屬性或者關(guān)系發(fā)生改變時(shí)產(chǎn)生.

此外,還具備以下特征.

·支持結(jié)構(gòu)化查詢語言訪問;

·以圖的形式維護(hù)網(wǎng)狀數(shù)據(jù);

·所維護(hù)的數(shù)據(jù)具備形式化語義,支持?jǐn)?shù)據(jù)理解和推理;

·具備邏輯形式化,支持生成新的信息、強(qiáng)制一致性以及進(jìn)行自動(dòng)化分析;

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

本文選擇以實(shí)體圖為起點(diǎn)維護(hù)開源軟件供應(yīng)鏈,不斷擴(kuò)充內(nèi)容,最終構(gòu)建成一個(gè)開源軟件領(lǐng)域?qū)Ｓ玫闹R(shí)圖譜,為后續(xù)工作奠定基礎(chǔ).

2.3 常見的構(gòu)建方法和工具

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

2.3.1 LFS

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

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

·ALFS:如前文所述,該項(xiàng)目希望提供一個(gè)可擴(kuò)展的系統(tǒng)構(gòu)建器和包安裝器,以實(shí)現(xiàn)系統(tǒng)的自動(dòng)構(gòu)建;

·CLFS(cross Linux from scratch):在LFS 的基礎(chǔ)上,指導(dǎo)用戶通過交叉編譯技術(shù)實(shí)現(xiàn)面向不同體系架構(gòu)來構(gòu)建Linux 操作系統(tǒng).

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

2.3.2 Yocto

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

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

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

3 開源軟件供應(yīng)鏈

3.1 定 義

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

·商品:交付給最終用戶的軟件,本文即特指大型復(fù)雜操作系統(tǒng)及相關(guān)軟件包;

·制造商:設(shè)計(jì)實(shí)現(xiàn)開源軟件模塊的個(gè)人或組織;

·供應(yīng)商:提供開源軟件服務(wù)的公司或個(gè)人;

·倉儲(chǔ):集中托管開源軟件的倉庫.

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

定義1(面向操作系統(tǒng)可靠性保障的開源軟件供應(yīng)鏈).一個(gè)擴(kuò)展的有限自動(dòng)機(jī)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)轉(zhuǎn)換函數(shù)δ:Q×ρ(Σ)→Q,狀態(tài)轉(zhuǎn)換關(guān)系如圖1 所示;

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

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

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

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

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

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

·應(yīng)用編程接口(API):以服務(wù)接口的形式對(duì)外提供開源軟件供應(yīng)鏈系統(tǒng)的能力,如供應(yīng)關(guān)系獲取、開源軟件可靠性分析等;

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

·數(shù)據(jù)源驅(qū)動(dòng)程序(data source driver):為采集不同的數(shù)據(jù)源的數(shù)據(jù),提供不同驅(qū)動(dòng)程序,驗(yàn)證采集到的數(shù)據(jù),并轉(zhuǎn)換為統(tǒng)一的格式方便系統(tǒng)存儲(chǔ)和管理;

Fig.2 The architecture of supply chain system of open source software圖2 開源軟件供應(yīng)鏈系統(tǒng)架構(gòu)圖

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

·控制器(controller):負(fù)責(zé)協(xié)調(diào)和分發(fā)后臺(tái)任務(wù),包括數(shù)據(jù)分析和狀態(tài)監(jiān)控;

·分析器(analyzer):以插件的形式實(shí)現(xiàn),負(fù)責(zé)執(zhí)行指定的分析任務(wù),如軟件可靠性分析等;

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

3.2 數(shù)據(jù)管理

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

3.2.1 本體設(shè)計(jì)

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

Fig.3 The ontology design of knowledge graph of open source software圖3 開源軟件知識(shí)圖譜本體設(shè)計(jì)

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

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

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

·組織(organization):該實(shí)體類型描述某一個(gè)具體的組織,可以是開源組織,或者是提供開源軟件的公司,它們對(duì)某些開源軟件有實(shí)際的控制權(quán),因此存在“hasController”的關(guān)系.同時(shí),它們“l(fā)ocateAt”某一個(gè)具體的地理位置,需要遵守當(dāng)?shù)氐姆煞ㄒ?guī);

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

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

3.2.2 構(gòu)建過程

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

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

1)基礎(chǔ)圖譜構(gòu)建

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

2)擴(kuò)展補(bǔ)充信息

這一步驟基于第1 步生成的基礎(chǔ)圖譜,分3 個(gè)子步驟完成信息擴(kuò)充.

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

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

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

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

3.3 可靠性風(fēng)險(xiǎn)管理

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

3.3.1 識(shí)別和評(píng)估

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

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

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

基于開源圖譜和度量模型,我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了圖5 所描述的數(shù)據(jù)流程,以得到對(duì)軟件的可靠性評(píng)分.在目前的系統(tǒng)中,將可靠性評(píng)分限定在0～5 分,以小數(shù)表示中間分值,并保留小數(shù)點(diǎn)后兩位,如3.47.可靠性評(píng)分的計(jì)算過程如下:

Fig.5 The data flow diagram for generating evaluation of software’s reliability圖5 可靠性評(píng)分?jǐn)?shù)據(jù)流圖

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

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

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

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

3.3.2 處 理

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

Table 2 Risk level of reliability表2 可靠性風(fēng)險(xiǎn)等級(jí)

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

3.3.3 監(jiān) 控

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

Table 3 Risks to be monitored表3 風(fēng)險(xiǎn)監(jiān)控

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

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

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

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

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

3.4 基于可靠供應(yīng)鏈構(gòu)建操作系統(tǒng)

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

·降低學(xué)習(xí)門檻:開源軟件供應(yīng)鏈管理系統(tǒng)維護(hù)了軟件之間的供應(yīng)關(guān)系,包括不同軟件之間的供應(yīng)關(guān)系,以及從上游源碼到具體打包格式的供應(yīng)關(guān)系.通過系統(tǒng)提供的檢索功能,用戶可以輕松獲取供應(yīng)關(guān)系信息,不再需要構(gòu)建人員花費(fèi)大量精力去記憶這些信息,進(jìn)而能夠保證用戶快速、準(zhǔn)確、高效地完成工作;

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

·提升生態(tài)可靠性:開源軟件供應(yīng)鏈管理系統(tǒng)通過內(nèi)部實(shí)現(xiàn)的可靠性風(fēng)險(xiǎn)管理相關(guān)機(jī)制,為用戶提供識(shí)別、評(píng)估、處理和監(jiān)控可靠性風(fēng)險(xiǎn)的功能,有效降低目標(biāo)構(gòu)建系統(tǒng)軟件生態(tài)的可靠性風(fēng)險(xiǎn),提升可靠性.

4 實(shí)驗(yàn)驗(yàn)證及結(jié)果

4.1 系統(tǒng)實(shí)現(xiàn)

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

Table 4 Hardware configuration表4 硬件配置

實(shí)體圖是系統(tǒng)實(shí)現(xiàn)的重要組成部分,基于圖3 描述的本體設(shè)計(jì),我們將其映射為圖8 所示的數(shù)據(jù)結(jié)構(gòu).具體地,我們嚴(yán)格按照面向?qū)ο蟮脑O(shè)計(jì)思想,將每個(gè)實(shí)體視作一個(gè)類,并為每個(gè)類定義相關(guān)的屬性和類型.在圖中,我們以不同形式的箭頭描述了類間的關(guān)系.其中,Entity 和 Relation 是基礎(chǔ)類型;空心箭頭表示繼承關(guān)系,即Software、License、Organization、Location、Human 繼承實(shí)現(xiàn)Entity,而Package 和OS 繼承實(shí)現(xiàn)Software;虛線單箭頭表示依賴關(guān)系,描述類屬性對(duì)其他類及其屬性的依賴關(guān)系;實(shí)線單箭頭表示關(guān)聯(lián)關(guān)系,即圖中Relation 通過from 和to 屬性分別指向關(guān)聯(lián)Entity 的key 屬性,將兩個(gè)不同的Entity 實(shí)例連接起來,以表示兩個(gè)Entity 之間存在某種Relation.

Fig.8 The data structure of knowledge graph of open source software圖8 開源軟件知識(shí)圖譜數(shù)據(jù)結(jié)構(gòu)

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

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

此外,系統(tǒng)中的控制器、分析器和事件處理器均采用插件式實(shí)現(xiàn),允許以插件的形式擴(kuò)展系統(tǒng)相關(guān)功能,保證系統(tǒng)的靈活性和可擴(kuò)展性.

4.2 可用性驗(yàn)證

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

Fig.9 Statistics of open source supply chain圖9 供應(yīng)鏈統(tǒng)計(jì)數(shù)據(jù)

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

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

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

Fig.10 The proportion of reliability score圖10 可靠性評(píng)分占比

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

5 總結(jié)

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

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

·一種軟件供應(yīng)可靠性管理方法:面向開源協(xié)作模式,我們通過構(gòu)建開源軟件知識(shí)圖譜,以知識(shí)為核心,結(jié)合傳統(tǒng)的供應(yīng)鏈管理方法,提出一組面向開源軟件供應(yīng)鏈的可靠性管理方法;

·一種可靠性評(píng)估數(shù)據(jù)集的構(gòu)建方法:不論學(xué)術(shù)界還是工業(yè)界,據(jù)我們所知,當(dāng)前尚不存在大規(guī)?；鶞?zhǔn)數(shù)據(jù)集可用于評(píng)估開源軟件供應(yīng)鏈的可靠性,基于本文提出的度量模型和評(píng)分方法,系統(tǒng)在使用過程中,將積累生成一個(gè)可以用于可靠性評(píng)估的有效數(shù)據(jù)集.

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

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

·改進(jìn)可靠性評(píng)估方法:當(dāng)前系統(tǒng)在使用中,能夠積累大量有效的標(biāo)注數(shù)據(jù),在未來的研究中,可以基于這些數(shù)據(jù)挖掘度量模型中不同維度對(duì)于可靠性評(píng)估的貢獻(xiàn)值,進(jìn)一步提升評(píng)估模型的準(zhǔn)確性,提升可靠性評(píng)估的智能化程度;

·擴(kuò)展開源軟件知識(shí)圖譜:當(dāng)前系統(tǒng)構(gòu)建的知識(shí)圖譜重點(diǎn)關(guān)注開源軟件供應(yīng)關(guān)系的可靠性,在未來的研究中,可以考慮與已有的面向其他開源軟件領(lǐng)域知識(shí)的知識(shí)圖譜進(jìn)行融合,使開源軟件知識(shí)圖譜具有更強(qiáng)的通用性.