考慮系統(tǒng)調(diào)用和失效模式的軟件可靠性模型

薛利興，左德承，張 展

XUE Lixing,ZUO Decheng,ZHANG Zhan

哈爾濱工業(yè)大學(xué) 計算機科學(xué)與技術(shù)學(xué)院，哈爾濱 150001

School of Computer Science and Technology,Harbin Institute of Technology,Harbin 150001,China

1 引言

可靠性通常是軟件質(zhì)量要求中的一個關(guān)鍵指標(biāo)，同時也是保證軟件在使用過程中正確運行的度量[1]。隨著各種各樣的計算機設(shè)備已經(jīng)成為日常生活中重要的組成部分，人們發(fā)現(xiàn)軟件的失效不再只是軟件工程師的事情，還會給我們帶來種種不便甚至更嚴(yán)重的后果。因此，可靠性越來越受到人們的重視，尤其是在一些關(guān)鍵應(yīng)用之中。

當(dāng)前的軟件開發(fā)多數(shù)是基于組件或模塊進(jìn)行的，但軟件整體并不是各個模塊的簡單相加，每個模塊都可能對全局的可靠性產(chǎn)生不同的影響。軟件可靠性分析利用軟件的整體架構(gòu)、軟件運行剖面、以及每個模塊的可靠性搭建數(shù)學(xué)模型，進(jìn)而分析軟件整體的可靠性。模型一方面可以在設(shè)計階段根據(jù)架構(gòu)、控制流、已知組件可靠性數(shù)據(jù)或預(yù)估的可靠性對軟件整體的可靠性進(jìn)行預(yù)測；另一方面也可以應(yīng)用在軟件的驗證和運行階段，通過各種測試方法得到每個模塊的可靠性和實際運行環(huán)境中的使用剖面，再代入數(shù)學(xué)模型得到軟件的可靠性，從而評估軟件是否達(dá)到了預(yù)期的要求。

在過去的幾十年之中，基于模塊的軟件可靠性研究領(lǐng)域已經(jīng)取得了不少的成果。然而，在這些研究中，都是將軟件獨立在運行環(huán)境之外，只是純粹地、抽象地考慮軟件自身代碼的可靠性，完全忽略了軟件所依賴的操作系統(tǒng)及運行環(huán)境對可靠性的影響。

事實上，在現(xiàn)代以操作系統(tǒng)負(fù)責(zé)支撐應(yīng)用軟件運行環(huán)境以及用戶操作環(huán)境的計算機系統(tǒng)中，軟件中的每個模塊或多或少都要進(jìn)行系統(tǒng)調(diào)用，例如資源分配、文件讀寫等。而系統(tǒng)調(diào)用的執(zhí)行與用戶軟件自身代碼的執(zhí)行處在不同的特權(quán)級別（privilege level），用戶軟件代碼執(zhí)行處于最低的特權(quán)級別（常稱為用戶態(tài)），操作系統(tǒng)代碼執(zhí)行處于較高的級別（常稱為內(nèi)核態(tài)）。特權(quán)級別由處理器硬件進(jìn)行約束和控制，越高的特權(quán)級別就擁有越多的訪問權(quán)限和控制權(quán)限，同時也導(dǎo)致發(fā)生在較高特權(quán)級別的錯誤有可能帶來更嚴(yán)重的后果。以Intel x86架構(gòu)處理器和Linux操作系統(tǒng)為例，Linux操作系統(tǒng)使用了0號和3號兩個級別，分別執(zhí)行操作系統(tǒng)的內(nèi)核代碼和應(yīng)用軟件[2]，如圖1所示。發(fā)生在3號特權(quán)級別（內(nèi)核態(tài)）的錯誤最多使應(yīng)用軟件本身崩潰，不會影響操作系統(tǒng)及其他應(yīng)用軟件的運行；而發(fā)生在0號特權(quán)級別（用戶態(tài)）的錯誤可以引發(fā)操作系統(tǒng)失效，使整個計算機系統(tǒng)處于不可用狀態(tài)。

圖1 x86處理器特權(quán)級別與Linux使用情況

由上可以看出：（1）盡管系統(tǒng)調(diào)用所執(zhí)行的代碼并不屬于目標(biāo)軟件本身，但其可靠性對整個目標(biāo)軟件可靠性的影響不可忽視；（2）系統(tǒng)調(diào)用執(zhí)行在較高的特權(quán)級別之中，可能會給系統(tǒng)帶來完全不同的失效模式；（3）當(dāng)數(shù)據(jù)錯誤發(fā)生傳播、通過調(diào)用接口傳播到系統(tǒng)調(diào)用過程中，可能會引發(fā)后果更嚴(yán)重的失效。因此，在分析軟件可靠性的過程中不應(yīng)該忽略軟件所依賴的系統(tǒng)調(diào)用及其相關(guān)的因素。

本文將軟件所依賴的系統(tǒng)調(diào)用引入軟件可靠性分析模型，依據(jù)系統(tǒng)調(diào)用處于不同特權(quán)等級會引發(fā)不同失效定義了軟件的多種失效模式，同時考慮了軟件不同模塊之間的錯誤傳播及軟件失效模式之間的相互轉(zhuǎn)化，建立了一種考慮軟件運行環(huán)境的軟件可靠性分析模型。具體地，首先在經(jīng)典模型基礎(chǔ)上逐步將系統(tǒng)調(diào)用過程、多種失效模式及錯誤傳播加入到模型之中，對模型進(jìn)行擴展和細(xì)化，最終得到更加精確的軟件可靠性分析模型。在模型建立后，在一個軟件實例中展示了該模型的使用方法，并給出了獲得模型中各個參數(shù)的具體方法。

2 軟件可靠性相關(guān)研究

根據(jù)Avizienis等人的定義[3]，失效（failure）是指一個系統(tǒng)不能按照所規(guī)定的功能正確提供服務(wù)；錯誤（error）是指可能導(dǎo)致系統(tǒng)出現(xiàn)失效情況的狀態(tài)，一般可以理解為計算、觀察或測量值與真實的、規(guī)定的或理論上正確的值之間的差異；故障（fault）通常被認(rèn)為是產(chǎn)生錯誤的根本原因，包含軟硬件設(shè)計缺陷、軟件代碼漏洞、外界環(huán)境干擾等多方面因素。系統(tǒng)不能正確提供服務(wù)可能以不同的方式表現(xiàn)出來，這些不同的表現(xiàn)方式通常被稱為失效模式（failure mode）。

可靠性（reliability）表示系統(tǒng)能夠持續(xù)提供正確服務(wù)的能力，可以定義可靠性為一種概率性的度量指標(biāo)，即能夠正確完成其功能的概率，其數(shù)值可以表示為1減去失效的概率。可靠性是軟件質(zhì)量的重要度量，廣泛受到程序員、工程師和研究人員的重視，相關(guān)的研究成果也是層出不窮。這些研究主要可以分為兩大類：軟件可靠性增長模型、軟件可靠性分析/預(yù)測模型。

軟件可靠性增長模型是在軟件的調(diào)試過程中，將軟件整體看作一個黑盒模型，通過測試獲得軟件失效數(shù)據(jù)，進(jìn)而預(yù)測軟件的平均失效時間（Mean Time To Failure，MTTF）[4-6]。黑盒模型只關(guān)注軟件接口與外界環(huán)境的交互，對軟件的內(nèi)部結(jié)構(gòu)毫不關(guān)心，因此軟件可靠性增長模型無法獲得失效數(shù)據(jù)以外的其他數(shù)據(jù)，一旦軟件發(fā)生微小的修改或升級，整個測試過程需要重新進(jìn)行。

隨著軟件規(guī)模的不斷增加和對軟件重用性的強調(diào)，模塊化軟件開發(fā)逐漸普及，軟件中的模塊經(jīng)常被更換或升級，以黑盒測試為基礎(chǔ)的軟件可靠性增長模型略顯力不從心。研究者開始將目光投向了考慮軟件內(nèi)部架構(gòu)的白盒方法，提出了軟件可靠性分析/預(yù)測模型。

Cheung最早提出了基于軟件架構(gòu)的可靠性建模方法[7]。他采用馬爾可夫過程來抽象軟件不同模塊之間的控制流，通過對離散時間馬爾可夫過程的分析計算得出軟件的可靠性，并強調(diào)較少的執(zhí)行可靠性低的模塊同樣能夠提高軟件整體的可靠性。Cheung的模型得到了后續(xù)研究人員的廣泛認(rèn)可。Wang等研究者擴展了Cheung所提出的模型，對順序執(zhí)行、并行執(zhí)行、后備容錯等多種軟件執(zhí)行模式進(jìn)行了建模[8]。

Sharma等人將可靠性分析與性能分析巧妙地結(jié)合起來[9]。Reussner等人將外部服務(wù)調(diào)用引入了模型之中，并考慮了外部服務(wù)與本地連接渠道的可靠性，使其方法可以運用到分布式軟件可靠性分析之中[10]。在上述的這些模型和方法當(dāng)中，都只假設(shè)只存在一種失效模式，也沒有考慮軟件中的錯誤傳播。

Cortellessa和Grassi提出了模塊失效未必導(dǎo)致整個軟件失效的觀點，將錯誤傳播的問題納入到模型的考慮范圍內(nèi)[11]。Pham在并行執(zhí)行、后備容錯、循環(huán)等軟件執(zhí)行模式的基礎(chǔ)上加入了錯誤傳播的考查，并采用UML的方法表示軟件的架構(gòu)[12]。

軟件的執(zhí)行離不開底層操作系統(tǒng)等運行環(huán)境的支持。在實際情況中，由于軟件的系統(tǒng)調(diào)用和硬件特權(quán)級別的保護(hù)使得系統(tǒng)在運行過程中呈現(xiàn)出不同的失效模式。本文同樣在Cheung模型基礎(chǔ)之上展開研究，根據(jù)軟件的實際運行環(huán)境，將軟件進(jìn)行的系統(tǒng)調(diào)用和多種失效模式納入考慮范圍，同時也考慮了軟件模塊之間的錯誤傳播以及失效模式相互轉(zhuǎn)化的問題，力爭建立更加貼近實際情況的軟件可靠性分析模型。

3 可靠性分析模型

首先假設(shè)軟件中沒有系統(tǒng)調(diào)用且只有一種失效模式，根據(jù)Cheung提出的方法基于離散時間馬爾可夫過程建立基本的可靠性分析模型；隨后，考慮帶有系統(tǒng)調(diào)用情況，將基本模型擴展成帶有系統(tǒng)調(diào)用的軟件可靠性分析模式；最后，再對軟件中的多種失效模式和錯誤傳播行為進(jìn)行建模，得到更加精確的模型。

3.1 無系統(tǒng)調(diào)用的基本模型

根據(jù)Cheung的方法[7]，使用狀態(tài)圖來表示軟件的行為：一個狀態(tài)表示一個模塊的執(zhí)行，從一個狀態(tài)到另一個狀態(tài)的轉(zhuǎn)移概率由軟件運行剖面和模塊可靠性計算得到。這樣一來，軟件的可靠性就可以由狀態(tài)的執(zhí)行順序和各個獨立狀態(tài)的可靠性來決定。假設(shè)軟件下一個被執(zhí)行的狀態(tài)（模塊）只與當(dāng)前正在執(zhí)行的狀態(tài)（模塊）有關(guān)，與之前的執(zhí)行順序沒有任何關(guān)系，整個狀態(tài)圖和狀態(tài)轉(zhuǎn)移過程就構(gòu)成了一個離散時間馬爾可夫過程。

假設(shè)軟件中有n個模塊，分別記為 M1，M2，…，Mn，每一個模塊對應(yīng)狀態(tài)圖中的一個節(jié)點（即狀態(tài)圖中的一個狀態(tài)）。對于其中任意的兩個節(jié)點Mi和Mj，有向邊(Mi，Mj)表示軟件控制流存在從模塊Mi轉(zhuǎn)移到模塊Mj的可能性，且用概率Pij表示發(fā)生這種控制流轉(zhuǎn)移的可能性。也就是說，當(dāng)模塊Mi執(zhí)行完畢后，接下來執(zhí)行模塊Mj的概率是Pij。若狀態(tài)圖中不存在有向邊(Mi，Mj)，表示模塊Mi執(zhí)行完畢后下一個執(zhí)行的模塊不會是Mj，此時Pij=0。Pij可以通過實驗統(tǒng)計來獲得，用t(i，j)表示多次實驗中從模塊Mi到模塊Mj控制流轉(zhuǎn)移的平均次數(shù)，Pij可以表示為：

需要注意的是，在狀態(tài)圖中Pij并不是從狀態(tài)Mi轉(zhuǎn)移到狀態(tài)Mj的轉(zhuǎn)移概率。在軟件運行過程中，只有模塊Mi正確執(zhí)行，控制流才有可能跳轉(zhuǎn)到下一個模塊Mj。設(shè)Ri為狀態(tài) Mi的可靠性，用 p(i，j)表示從狀態(tài) Mi轉(zhuǎn)移到狀態(tài)Mj的轉(zhuǎn)移概率，則

不失一般性，假設(shè)軟件有唯一的入口和出口，分別為 M1和 Mn。集合{M1，M2，…，Mn}是離散時間馬爾可夫過程的狀態(tài)集合，其中M1是初始狀態(tài)、Mn為終止?fàn)顟B(tài)，P=[p(i，j)]為狀態(tài)轉(zhuǎn)換矩陣。

pk(i，j)表示經(jīng)過k次轉(zhuǎn)移從狀態(tài) Mi到達(dá)狀態(tài) Mj的概率，則經(jīng)過k次轉(zhuǎn)移從狀態(tài)Mi到達(dá)狀態(tài)Mj的可靠性可以表示為：

軟件的可靠性是從初始狀態(tài)M1到達(dá)終止?fàn)顟B(tài)Mn的概率，發(fā)生轉(zhuǎn)移的次數(shù)可能是0到正無窮（其中0是一種M1=Mn的特例）。因此，軟件的可靠性R可以表示為：

設(shè)矩陣U=[u(x，y)]為：

其中I為單位矩陣，由線性代數(shù)相關(guān)知識可以得到：

同時，顯然可知：

將其代入公式（5），可得：

綜上，只要得到狀態(tài)轉(zhuǎn)移矩陣后，可以根據(jù)公式（7）和公式（9）得到軟件的可靠性。

3.2 考慮系統(tǒng)調(diào)用的可靠性模型

在現(xiàn)實中，多數(shù)的軟件模塊中或多或少進(jìn)行了系統(tǒng)調(diào)用。盡管在宏觀上看軟件中只是一個模塊的執(zhí)行，但從微觀看執(zhí)行過程存在著模塊自身代碼與系統(tǒng)調(diào)用交替執(zhí)行的不同階段，如圖2所示。對于含有系統(tǒng)調(diào)用的模塊，其可靠性不僅與自身代碼有關(guān)，還與其依賴的系統(tǒng)調(diào)用密不可分。

圖2 帶有系統(tǒng)調(diào)用的模塊執(zhí)行過程

直觀上，帶有系統(tǒng)調(diào)用模塊的可靠性貌似應(yīng)該由自身代碼的可靠性與系統(tǒng)調(diào)用的可靠性相乘得到。然而，由于使用者的不同或任務(wù)不同，模塊中系統(tǒng)調(diào)用的次數(shù)可能存在一定的隨機性，將二者的可靠性簡單相乘并不能反映真實情況；同時將系統(tǒng)調(diào)用的失效隱藏在模塊內(nèi)部，很難發(fā)現(xiàn)模塊脆弱的真正原因。此外，系統(tǒng)調(diào)用的代碼并不屬于模塊本身，代碼風(fēng)格迥異，亦可能并不開源，測試方法也完全不同，應(yīng)予以分別進(jìn)行考慮。因此，將系統(tǒng)調(diào)用從模塊內(nèi)部中提取出來，作為調(diào)用返回模式[8，13]（call-and-return style）來進(jìn)行處理。也就是說，將每個系統(tǒng)調(diào)用都看成軟件中的一個獨立的特殊模塊，即執(zhí)行完畢后控制流確定（返回調(diào)用模塊）的模塊。

設(shè)模塊Mi內(nèi)部調(diào)用了Ai個不同系統(tǒng)調(diào)用，其中Ai為非負(fù)的整數(shù)，i=1，2，…，n，則整個系統(tǒng)的狀態(tài)圖中增加了個狀態(tài)，即共有個模塊。需要注意的是，增加的這些系統(tǒng)調(diào)用中有可能是調(diào)用的同一個系統(tǒng)調(diào)用，但由于其執(zhí)行完畢的返回控制流不同（返回不同的模塊），在這里將它們看成不同的模塊。

對于新的狀態(tài)圖中兩個任意的節(jié)點Mi和Mj，控制流轉(zhuǎn)移概率P～ij的獲得方法依然可以按照公式（1）來計算。每個模塊的可靠性用R～i表示，從狀態(tài)Mi轉(zhuǎn)移到狀態(tài)Mj的轉(zhuǎn)移概率 p～(i，j)構(gòu)造方法如下：

第一種情況是模塊Mi內(nèi)部調(diào)用系統(tǒng)調(diào)用Mj，由于系統(tǒng)調(diào)用發(fā)生在模塊Mi執(zhí)行過程中，無論Mi是否可靠都要按概率進(jìn)行系統(tǒng)調(diào)用，因此不需要考慮Mi的可靠性；第二種情況是系統(tǒng)調(diào)用Mj執(zhí)行完畢返回調(diào)用模塊Mi，由于調(diào)用結(jié)束后控制流已經(jīng)是確定的，只要系統(tǒng)調(diào)用正確執(zhí)行，必然返回Mi，轉(zhuǎn)移概率等于Mj的可靠性；第三種情況模塊Mi和Mj都不是系統(tǒng)調(diào)用模塊，必須在Mi正確執(zhí)行且控制流有轉(zhuǎn)向Mj可能性的前提下才能發(fā)生狀態(tài)轉(zhuǎn)移。

這樣，就得到了新的離散時間馬爾可夫過程，其狀態(tài)空間為{M1，…，Mn…，Mn+A1+…+An}，轉(zhuǎn)移矩陣為 P～=[p～(i，j)]。該帶有系統(tǒng)調(diào)用的可靠性模型同樣只考慮了一種失效模式且不考慮錯誤傳播，軟件可靠性計算方法與3.1節(jié)中無系統(tǒng)調(diào)用的基本模型相同，這里不再贅述。

3.3 失效模式和錯誤傳播建模

在上述考慮系統(tǒng)調(diào)用的可靠性模型基礎(chǔ)上，嘗試對軟件中的多種失效模式和錯誤傳播進(jìn)行建模。為方便起見，重新假設(shè)軟件抽取系統(tǒng)調(diào)用模塊后在狀態(tài)圖中共形成n個模塊，集合SELF表示所有抽取系統(tǒng)調(diào)用后的自身代碼模塊，用集合CALL表示所有系統(tǒng)調(diào)用模塊，SELF∪CALL={M1，M2，…，Mn}。同時假設(shè)軟件出口模塊和入口模塊均唯一，分別為 M1和 Mn，M1，Mn∈SELF。各模塊之間的控制流轉(zhuǎn)移概率Qij依然可以通過公式（1）計算得到。

由于常見的操作系統(tǒng)只使用了兩個特權(quán)級別，分別對應(yīng)操作系統(tǒng)的內(nèi)核態(tài)和用戶態(tài)，可引發(fā)兩種不同的失效：用戶態(tài)失效和內(nèi)核態(tài)失效，分別編號為1和2。同時，為了敘述方便和表示方法的統(tǒng)一，將未發(fā)生失效作為一種特殊的失效模式，標(biāo)號為0。設(shè)在任一個模塊Mi內(nèi)部，這三種失效模式都可能發(fā)生相互轉(zhuǎn)換，且定義函數(shù) fi(x，y)為模塊Mi內(nèi)各失效模式的轉(zhuǎn)換概率：

其中 0≤x，y≤2，并且函數(shù)fi(x，y)滿足

當(dāng)x和 y數(shù)值變化時，fi(x，y)可以表示模塊 Mi的一些屬性和錯誤傳播行為：fi(0，0)表示模塊Mi可靠性；fi(0，1)與 fi(0，2)分別表示 Mi發(fā)生用戶態(tài)失效和內(nèi)核態(tài)失效的概率；fi(1，1)與 fi(2，2)分別表示用戶態(tài)失效和內(nèi)核態(tài)失效透過模塊Mi的概率。

在考慮了失效模式之后，便無法使用一個節(jié)點表示一個模塊中的所有狀態(tài)，此時需要對每個節(jié)點進(jìn)行擴展。對于任意的模塊Mi，其輸入有三種失效模式；由于考慮了錯誤傳播，失效模式可以在模塊內(nèi)部發(fā)生相互轉(zhuǎn)化，模塊Mi的輸出也可能存在三種失效模式。因此，將模塊Mi在狀態(tài)圖中的1個節(jié)點擴展成6=（3+3）個節(jié)點：3個節(jié)點分別表示模塊Mi在輸入為三種不同失效模式下的執(zhí)行過程，記為 MIi={MIi1，MIi2，MIi3}，分別表示模塊Mi輸入為未失效、用戶態(tài)失效、內(nèi)核態(tài)失效的執(zhí)行過程；另外3個節(jié)點表示模塊Mi執(zhí)行完畢所處的失效模式，記為 MOi={MOi1，MOi2，MOi3}，分別表示模塊 Mi執(zhí)行完畢的狀態(tài)為未失效、用戶態(tài)失效、內(nèi)核態(tài)失效。擴展后的節(jié)點如圖3所示。

圖3 模塊節(jié)點的擴展

特別地，對于模塊Mi在執(zhí)行過程中進(jìn)行系統(tǒng)調(diào)用模塊 Mj的情況，在 Mi的執(zhí)行狀態(tài) MIiα中按概率轉(zhuǎn)移到狀態(tài)MIjα執(zhí)行系統(tǒng)調(diào)用；MIjα執(zhí)行完畢后發(fā)生狀態(tài)轉(zhuǎn)移到MOjβ（若執(zhí)行過程中失效模式?jīng)]有改變則α=β，否則α≠β）；在進(jìn)入狀態(tài)MOjβ后，就表示系統(tǒng)調(diào)用執(zhí)行完畢，將必然返回調(diào)用模塊Mi，轉(zhuǎn)移到狀態(tài)MIiβ。圖4是一個帶有系統(tǒng)調(diào)用節(jié)點擴展的例子，圖4（a）是局部的控制流，模塊 M1進(jìn)行了系統(tǒng)調(diào)用，調(diào)用模塊M3，圖4（b）是擴展后的狀態(tài)圖。

圖4 帶有系統(tǒng)調(diào)用節(jié)點的擴展實例

用這些狀態(tài)構(gòu)造一個離散時間馬爾可夫過程用來分析軟件的可靠性，狀態(tài)空間為：

狀態(tài)轉(zhuǎn)移矩陣為Q=[q(s，t)]，具體構(gòu)造如下：

第一種情況是模塊Mi進(jìn)行調(diào)用系統(tǒng)調(diào)用模塊Mj，調(diào)用概率與Mi的失效模式無關(guān)，等于控制流轉(zhuǎn)移的概率；第二種情況是執(zhí)行系統(tǒng)調(diào)用Mi過程中發(fā)生的失效模式轉(zhuǎn)換；第三種情況是系統(tǒng)調(diào)用模塊Mi執(zhí)行完畢后返回模塊Mj，執(zhí)行完畢后必然返回；第四種情況是在模塊Mi執(zhí)行過程中發(fā)生的失效模式轉(zhuǎn)換；第五種情況是模塊Mi執(zhí)行完畢繼而執(zhí)行模塊Mj，此時不會再發(fā)生系統(tǒng)調(diào)用，轉(zhuǎn)入模塊Mj的概率是轉(zhuǎn)入該模塊的控制流轉(zhuǎn)移概率與所有可能轉(zhuǎn)入模塊的控制流概率之和的比值；對于其他情況，狀態(tài)轉(zhuǎn)移的概率為0。

在該模型中，軟件的可靠性是從初始狀態(tài)M1，0到達(dá)終止?fàn)顟B(tài)MOn，0的概率，其推導(dǎo)方法與3.1節(jié)中相同，這里不再贅述。

4 應(yīng)用實例

選取了Linux操作系統(tǒng)下一個自己編寫的簡單系統(tǒng)來演示如何應(yīng)用上述的可靠性分析模型，軟件結(jié)構(gòu)如圖5所示。

圖5 軟件基本結(jié)構(gòu)

在這個實例中，軟件有兩種失效：自身崩潰和操作系統(tǒng)失效，分別編號為1、2，且均為停止運行失效；軟件正確執(zhí)行編號為失效模式0。

表1 模塊M1實驗數(shù)據(jù)

表2 模塊M2實驗數(shù)據(jù)

表3 模塊M3實驗數(shù)據(jù)

表4 模塊M4實驗數(shù)據(jù)

表5 模塊M5實驗數(shù)據(jù)

表6 模塊M6實驗數(shù)據(jù)

表7 模塊M7實驗數(shù)據(jù)

表8 模塊M8實驗數(shù)據(jù)

表9 模塊M9實驗數(shù)據(jù)

4.1 系統(tǒng)調(diào)用與控制流數(shù)據(jù)

系統(tǒng)調(diào)用和控制流的獲取采用實驗統(tǒng)計的方法獲得。在運行軟件的同時，使用OProfile等系統(tǒng)分析工具跟蹤記錄軟件中各模塊的控制流轉(zhuǎn)移情況和發(fā)生次數(shù)、各模塊內(nèi)部系統(tǒng)調(diào)用情況和調(diào)用次數(shù)。在軟件長時間運行之后，根據(jù)得到的數(shù)據(jù)計算后可得控制流的轉(zhuǎn)移概率。

具體地，得到的程序控制流如圖6所示，其中，自身代碼集合 SELF={M1， M2， M3， M4} ，系統(tǒng)調(diào)用集合CALL={M5，M6，…，M11}，這 11 個模塊的控制流轉(zhuǎn)移概率為：

圖6 軟件的控制流

4.2 失效數(shù)據(jù)

對于系統(tǒng)調(diào)用模塊Mi(i=5，6，…，11)，只可能發(fā)生失效模式2，即運行過程中只會出現(xiàn)失效模式0和失效模式2，且失效模式2不會向其他失效模式轉(zhuǎn)換。借助CMU的Ballista測試[14]來獲得每個系統(tǒng)調(diào)用的失效率 fi(0，2)，而每個系統(tǒng)調(diào)用模塊的可靠性 fi(0，0)=1-fi(0，2)。

另一方面，對于自身代碼模塊 Mi(i=1，2，…，4)運行在用戶態(tài)不可能出現(xiàn)失效模式2，且失效模式1也不會向其他失效模式再次轉(zhuǎn)換。采用算法BR進(jìn)行大量的隨機測試獲得 fi(0，1)，而 fi(0，0)=1-fi(0，1)。

算法（BR）

（1）對于每個模塊 Mi∈SELF，執(zhí)行步驟2～7；

（2）生成 Mi的測試用例集合TESTi；

（3）計數(shù)器TotalCount和 FailCount初始化為0；

（4）對于每個測試用例α∈TESTi，執(zhí)行步驟5～6；

（5）以α為輸入運行 Mi，同時遞增TotalCount；

（6）若模塊Mi失效，根據(jù)輸出信息判斷失效原因，若不是系統(tǒng)調(diào)用引起，遞增FailCount；

（7）根據(jù)計數(shù)器的數(shù)值計算模塊Mi的失效率

通過實驗得到的數(shù)據(jù)如表1～11所示。

表10 模塊M10實驗數(shù)據(jù)

4.3 可靠性結(jié)果

根據(jù)已經(jīng)獲得的各項參數(shù)，可以建立一個66×66的稀疏狀態(tài)轉(zhuǎn)移矩陣。應(yīng)用Matlab進(jìn)行矩陣的計算，最終該軟件在Linux環(huán)境下運行的可靠性為0.472。

表11 模塊M11實驗數(shù)據(jù)

5 結(jié)束語

本文在經(jīng)典的軟件可靠性分析/預(yù)測模型基礎(chǔ)上考慮了運行環(huán)境對可靠性的影響，將軟件中的系統(tǒng)調(diào)用從軟件自身模塊中抽取出來作為特殊的模塊并考慮了多種失效模式，提出了一種更貼近實際的軟件可靠性分析模型。盡管在應(yīng)用過程中，該模型的狀態(tài)空間比傳統(tǒng)模型有所增加，但狀態(tài)轉(zhuǎn)移矩陣為稀疏矩陣，只需要計算特定的非零元素即可，同時可以應(yīng)用Matlab等數(shù)學(xué)軟件進(jìn)行矩陣的輔助計算。

此外，由于不同的操作系統(tǒng)中內(nèi)核代碼可靠性各不相同，軟件運行的可靠性也隨之受到影響，該模型可以有效體現(xiàn)出不同操作系統(tǒng)對軟件可靠性的影響。同時，該模型適用于常見的系統(tǒng)架構(gòu)和Windows、Linux、MacOS、Unix等常見的操作系統(tǒng)，在為特定軟件選擇運行環(huán)境時也可具有一定的應(yīng)用價值。

[1]Laprie J C.Dependability of computer systems：concepts，limits，improvements[C]//SixthInternational Symposium on Software Reliability Engineering，Oct 24，1995—Oct 27，1995.California：IEEE，1995：2-11.

[2]Intel.Intel 64 and IA-32 architectures software developer’s manual[M].California：Intel，2013.

[3]Avizienis A，Laprie J C，Randell B，et al.Basic concepts and taxonomy of dependable and secure computing[J].IEEE Transactions on Dependable and Secure Computing，2004，1（1）：11-33.

[4]Lyu M R.Handbook of software reliability engineering[M].New York：McGraw-Hill，1996：71-117.

[5]Goel A L.Software reliability models：assumptions，limitations，and applicability[J].IEEE Transactions on Software Engineering，1985，SE-11（12）：1411-1423.

[6]Ramamoorthy C V，Bastani F B.Software reliability：status and perspectives[J].IEEE Transactions on Software Engineering，1982，SE-8（4）：354-371.

[7]Cheung R C.A user-oriented software reliability model[J].IEEE Transactions on Software Engineering，1980，SE-6（2）：118-125.

[8]Wang W，Pan D，Chen M.Architecture-based software reliability modeling[J].Journal of Systems and Software，2006，79（1）：132-146.

[9]Sharma V S，Trivedi K S.Quantifying software performance，reliability and security：an architecture-based approach[J].Journal of Systems and Software，2007，80（4）：493-509.

[10]Reussner R H，Schmidt H W，Poernomo I H.Reliability prediction for component-based software architectures[J].Journal of Systems and Software，2003，66（3）：241-252.

[11]Cortellessa V，Grassi V.A modeling approach to analyze the impact of error propagation on reliability of component-based systems[C]//10th International ACM SIGSOFT Symposium on Component-Based Software Engineering，Jul 9，2007—Jul 11，2007.Germany：Springer，2007，4608：140-156.

[12]Thanh-Trung P，Defago X.Reliability prediction for component-based systems：incorporating errorpropagation analysis and different execution models[C]//12th International Conference on Quality Software，Aug 27，2012—Aug 29，2012.Washington DC：IEEE，2012:106-115.

[13]Wang Wenli，Wu Y，Chen Mei-Hwa.An architecture-based software reliability modeling[C]//1999 Pacific Rim International Symposium on Dependable Computing，Dec 16，1999—Dec 17，1999.Washington DC：IEEE，1999：143-150.

[14]Koopman P，Devale J.The exception handling effectiveness of POSIX operating systems[J].IEEE Transactions on Software Engineering，2000，26（9）：837-848.

[15]Nomizu K.Fundamentals of linear algebra[M].New York：McGraw-Hill，1966.