薛利興,左德承,張 展
XUE Lixing,ZUO Decheng,ZHANG Zhan
哈爾濱工業(yè)大學 計算機科學與技術學院,哈爾濱 150001
School of Computer Science and Technology,Harbin Institute of Technology,Harbin 150001,China
可靠性通常是軟件質量要求中的一個關鍵指標,同時也是保證軟件在使用過程中正確運行的度量[1]。隨著各種各樣的計算機設備已經成為日常生活中重要的組成部分,人們發(fā)現(xiàn)軟件的失效不再只是軟件工程師的事情,還會給我們帶來種種不便甚至更嚴重的后果。因此,可靠性越來越受到人們的重視,尤其是在一些關鍵應用之中。
當前的軟件開發(fā)多數(shù)是基于組件或模塊進行的,但軟件整體并不是各個模塊的簡單相加,每個模塊都可能對全局的可靠性產生不同的影響。軟件可靠性分析利用軟件的整體架構、軟件運行剖面、以及每個模塊的可靠性搭建數(shù)學模型,進而分析軟件整體的可靠性。模型一方面可以在設計階段根據(jù)架構、控制流、已知組件可靠性數(shù)據(jù)或預估的可靠性對軟件整體的可靠性進行預測;另一方面也可以應用在軟件的驗證和運行階段,通過各種測試方法得到每個模塊的可靠性和實際運行環(huán)境中的使用剖面,再代入數(shù)學模型得到軟件的可靠性,從而評估軟件是否達到了預期的要求。
在過去的幾十年之中,基于模塊的軟件可靠性研究領域已經取得了不少的成果。然而,在這些研究中,都是將軟件獨立在運行環(huán)境之外,只是純粹地、抽象地考慮軟件自身代碼的可靠性,完全忽略了軟件所依賴的操作系統(tǒng)及運行環(huán)境對可靠性的影響。
事實上,在現(xiàn)代以操作系統(tǒng)負責支撐應用軟件運行環(huán)境以及用戶操作環(huán)境的計算機系統(tǒng)中,軟件中的每個模塊或多或少都要進行系統(tǒng)調用,例如資源分配、文件讀寫等。而系統(tǒng)調用的執(zhí)行與用戶軟件自身代碼的執(zhí)行處在不同的特權級別(privilege level),用戶軟件代碼執(zhí)行處于最低的特權級別(常稱為用戶態(tài)),操作系統(tǒng)代碼執(zhí)行處于較高的級別(常稱為內核態(tài))。特權級別由處理器硬件進行約束和控制,越高的特權級別就擁有越多的訪問權限和控制權限,同時也導致發(fā)生在較高特權級別的錯誤有可能帶來更嚴重的后果。以Intel x86架構處理器和Linux操作系統(tǒng)為例,Linux操作系統(tǒng)使用了0號和3號兩個級別,分別執(zhí)行操作系統(tǒng)的內核代碼和應用軟件[2],如圖1所示。發(fā)生在3號特權級別(內核態(tài))的錯誤最多使應用軟件本身崩潰,不會影響操作系統(tǒng)及其他應用軟件的運行;而發(fā)生在0號特權級別(用戶態(tài))的錯誤可以引發(fā)操作系統(tǒng)失效,使整個計算機系統(tǒng)處于不可用狀態(tài)。
圖1 x86處理器特權級別與Linux使用情況
由上可以看出:(1)盡管系統(tǒng)調用所執(zhí)行的代碼并不屬于目標軟件本身,但其可靠性對整個目標軟件可靠性的影響不可忽視;(2)系統(tǒng)調用執(zhí)行在較高的特權級別之中,可能會給系統(tǒng)帶來完全不同的失效模式;(3)當數(shù)據(jù)錯誤發(fā)生傳播、通過調用接口傳播到系統(tǒng)調用過程中,可能會引發(fā)后果更嚴重的失效。因此,在分析軟件可靠性的過程中不應該忽略軟件所依賴的系統(tǒng)調用及其相關的因素。
本文將軟件所依賴的系統(tǒng)調用引入軟件可靠性分析模型,依據(jù)系統(tǒng)調用處于不同特權等級會引發(fā)不同失效定義了軟件的多種失效模式,同時考慮了軟件不同模塊之間的錯誤傳播及軟件失效模式之間的相互轉化,建立了一種考慮軟件運行環(huán)境的軟件可靠性分析模型。具體地,首先在經典模型基礎上逐步將系統(tǒng)調用過程、多種失效模式及錯誤傳播加入到模型之中,對模型進行擴展和細化,最終得到更加精確的軟件可靠性分析模型。在模型建立后,在一個軟件實例中展示了該模型的使用方法,并給出了獲得模型中各個參數(shù)的具體方法。
根據(jù)Avizienis等人的定義[3],失效(failure)是指一個系統(tǒng)不能按照所規(guī)定的功能正確提供服務;錯誤(error)是指可能導致系統(tǒng)出現(xiàn)失效情況的狀態(tài),一般可以理解為計算、觀察或測量值與真實的、規(guī)定的或理論上正確的值之間的差異;故障(fault)通常被認為是產生錯誤的根本原因,包含軟硬件設計缺陷、軟件代碼漏洞、外界環(huán)境干擾等多方面因素。系統(tǒng)不能正確提供服務可能以不同的方式表現(xiàn)出來,這些不同的表現(xiàn)方式通常被稱為失效模式(failure mode)。
可靠性(reliability)表示系統(tǒng)能夠持續(xù)提供正確服務的能力,可以定義可靠性為一種概率性的度量指標,即能夠正確完成其功能的概率,其數(shù)值可以表示為1減去失效的概率。可靠性是軟件質量的重要度量,廣泛受到程序員、工程師和研究人員的重視,相關的研究成果也是層出不窮。這些研究主要可以分為兩大類:軟件可靠性增長模型、軟件可靠性分析/預測模型。
軟件可靠性增長模型是在軟件的調試過程中,將軟件整體看作一個黑盒模型,通過測試獲得軟件失效數(shù)據(jù),進而預測軟件的平均失效時間(Mean Time To Failure,MTTF)[4-6]。黑盒模型只關注軟件接口與外界環(huán)境的交互,對軟件的內部結構毫不關心,因此軟件可靠性增長模型無法獲得失效數(shù)據(jù)以外的其他數(shù)據(jù),一旦軟件發(fā)生微小的修改或升級,整個測試過程需要重新進行。
隨著軟件規(guī)模的不斷增加和對軟件重用性的強調,模塊化軟件開發(fā)逐漸普及,軟件中的模塊經常被更換或升級,以黑盒測試為基礎的軟件可靠性增長模型略顯力不從心。研究者開始將目光投向了考慮軟件內部架構的白盒方法,提出了軟件可靠性分析/預測模型。
Cheung最早提出了基于軟件架構的可靠性建模方法[7]。他采用馬爾可夫過程來抽象軟件不同模塊之間的控制流,通過對離散時間馬爾可夫過程的分析計算得出軟件的可靠性,并強調較少的執(zhí)行可靠性低的模塊同樣能夠提高軟件整體的可靠性。Cheung的模型得到了后續(xù)研究人員的廣泛認可。Wang等研究者擴展了Cheung所提出的模型,對順序執(zhí)行、并行執(zhí)行、后備容錯等多種軟件執(zhí)行模式進行了建模[8]。
Sharma等人將可靠性分析與性能分析巧妙地結合起來[9]。Reussner等人將外部服務調用引入了模型之中,并考慮了外部服務與本地連接渠道的可靠性,使其方法可以運用到分布式軟件可靠性分析之中[10]。在上述的這些模型和方法當中,都只假設只存在一種失效模式,也沒有考慮軟件中的錯誤傳播。
Cortellessa和Grassi提出了模塊失效未必導致整個軟件失效的觀點,將錯誤傳播的問題納入到模型的考慮范圍內[11]。Pham在并行執(zhí)行、后備容錯、循環(huán)等軟件執(zhí)行模式的基礎上加入了錯誤傳播的考查,并采用UML的方法表示軟件的架構[12]。
軟件的執(zhí)行離不開底層操作系統(tǒng)等運行環(huán)境的支持。在實際情況中,由于軟件的系統(tǒng)調用和硬件特權級別的保護使得系統(tǒng)在運行過程中呈現(xiàn)出不同的失效模式。本文同樣在Cheung模型基礎之上展開研究,根據(jù)軟件的實際運行環(huán)境,將軟件進行的系統(tǒng)調用和多種失效模式納入考慮范圍,同時也考慮了軟件模塊之間的錯誤傳播以及失效模式相互轉化的問題,力爭建立更加貼近實際情況的軟件可靠性分析模型。
首先假設軟件中沒有系統(tǒng)調用且只有一種失效模式,根據(jù)Cheung提出的方法基于離散時間馬爾可夫過程建立基本的可靠性分析模型;隨后,考慮帶有系統(tǒng)調用情況,將基本模型擴展成帶有系統(tǒng)調用的軟件可靠性分析模式;最后,再對軟件中的多種失效模式和錯誤傳播行為進行建模,得到更加精確的模型。
根據(jù)Cheung的方法[7],使用狀態(tài)圖來表示軟件的行為:一個狀態(tài)表示一個模塊的執(zhí)行,從一個狀態(tài)到另一個狀態(tài)的轉移概率由軟件運行剖面和模塊可靠性計算得到。這樣一來,軟件的可靠性就可以由狀態(tài)的執(zhí)行順序和各個獨立狀態(tài)的可靠性來決定。假設軟件下一個被執(zhí)行的狀態(tài)(模塊)只與當前正在執(zhí)行的狀態(tài)(模塊)有關,與之前的執(zhí)行順序沒有任何關系,整個狀態(tài)圖和狀態(tài)轉移過程就構成了一個離散時間馬爾可夫過程。
假設軟件中有n個模塊,分別記為 M1,M2,…,Mn,每一個模塊對應狀態(tài)圖中的一個節(jié)點(即狀態(tài)圖中的一個狀態(tài))。對于其中任意的兩個節(jié)點Mi和Mj,有向邊(Mi,Mj)表示軟件控制流存在從模塊Mi轉移到模塊Mj的可能性,且用概率Pij表示發(fā)生這種控制流轉移的可能性。也就是說,當模塊Mi執(zhí)行完畢后,接下來執(zhí)行模塊Mj的概率是Pij。若狀態(tài)圖中不存在有向邊(Mi,Mj),表示模塊Mi執(zhí)行完畢后下一個執(zhí)行的模塊不會是Mj,此時Pij=0。Pij可以通過實驗統(tǒng)計來獲得,用t(i,j)表示多次實驗中從模塊Mi到模塊Mj控制流轉移的平均次數(shù),Pij可以表示為:
需要注意的是,在狀態(tài)圖中Pij并不是從狀態(tài)Mi轉移到狀態(tài)Mj的轉移概率。在軟件運行過程中,只有模塊Mi正確執(zhí)行,控制流才有可能跳轉到下一個模塊Mj。設Ri為狀態(tài) Mi的可靠性,用 p(i,j)表示從狀態(tài) Mi轉移到狀態(tài)Mj的轉移概率,則
不失一般性,假設軟件有唯一的入口和出口,分別為 M1和 Mn。集合{M1,M2,…,Mn}是離散時間馬爾可夫過程的狀態(tài)集合,其中M1是初始狀態(tài)、Mn為終止狀態(tài),P=[p(i,j)]為狀態(tài)轉換矩陣。
pk(i,j)表示經過k次轉移從狀態(tài) Mi到達狀態(tài) Mj的概率,則經過k次轉移從狀態(tài)Mi到達狀態(tài)Mj的可靠性可以表示為:
軟件的可靠性是從初始狀態(tài)M1到達終止狀態(tài)Mn的概率,發(fā)生轉移的次數(shù)可能是0到正無窮(其中0是一種M1=Mn的特例)。因此,軟件的可靠性R可以表示為:
設矩陣U=[u(x,y)]為:
其中I為單位矩陣,由線性代數(shù)相關知識可以得到:
同時,顯然可知:
將其代入公式(5),可得:
綜上,只要得到狀態(tài)轉移矩陣后,可以根據(jù)公式(7)和公式(9)得到軟件的可靠性。
在現(xiàn)實中,多數(shù)的軟件模塊中或多或少進行了系統(tǒng)調用。盡管在宏觀上看軟件中只是一個模塊的執(zhí)行,但從微觀看執(zhí)行過程存在著模塊自身代碼與系統(tǒng)調用交替執(zhí)行的不同階段,如圖2所示。對于含有系統(tǒng)調用的模塊,其可靠性不僅與自身代碼有關,還與其依賴的系統(tǒng)調用密不可分。
圖2 帶有系統(tǒng)調用的模塊執(zhí)行過程
直觀上,帶有系統(tǒng)調用模塊的可靠性貌似應該由自身代碼的可靠性與系統(tǒng)調用的可靠性相乘得到。然而,由于使用者的不同或任務不同,模塊中系統(tǒng)調用的次數(shù)可能存在一定的隨機性,將二者的可靠性簡單相乘并不能反映真實情況;同時將系統(tǒng)調用的失效隱藏在模塊內部,很難發(fā)現(xiàn)模塊脆弱的真正原因。此外,系統(tǒng)調用的代碼并不屬于模塊本身,代碼風格迥異,亦可能并不開源,測試方法也完全不同,應予以分別進行考慮。因此,將系統(tǒng)調用從模塊內部中提取出來,作為調用返回模式[8,13](call-and-return style)來進行處理。也就是說,將每個系統(tǒng)調用都看成軟件中的一個獨立的特殊模塊,即執(zhí)行完畢后控制流確定(返回調用模塊)的模塊。
設模塊Mi內部調用了Ai個不同系統(tǒng)調用,其中Ai為非負的整數(shù),i=1,2,…,n,則整個系統(tǒng)的狀態(tài)圖中增加了個狀態(tài),即共有個模塊。需要注意的是,增加的這些系統(tǒng)調用中有可能是調用的同一個系統(tǒng)調用,但由于其執(zhí)行完畢的返回控制流不同(返回不同的模塊),在這里將它們看成不同的模塊。
對于新的狀態(tài)圖中兩個任意的節(jié)點Mi和Mj,控制流轉移概率P~ij的獲得方法依然可以按照公式(1)來計算。每個模塊的可靠性用R~i表示,從狀態(tài)Mi轉移到狀態(tài)Mj的轉移概率 p~(i,j)構造方法如下:
第一種情況是模塊Mi內部調用系統(tǒng)調用Mj,由于系統(tǒng)調用發(fā)生在模塊Mi執(zhí)行過程中,無論Mi是否可靠都要按概率進行系統(tǒng)調用,因此不需要考慮Mi的可靠性;第二種情況是系統(tǒng)調用Mj執(zhí)行完畢返回調用模塊Mi,由于調用結束后控制流已經是確定的,只要系統(tǒng)調用正確執(zhí)行,必然返回Mi,轉移概率等于Mj的可靠性;第三種情況模塊Mi和Mj都不是系統(tǒng)調用模塊,必須在Mi正確執(zhí)行且控制流有轉向Mj可能性的前提下才能發(fā)生狀態(tài)轉移。
這樣,就得到了新的離散時間馬爾可夫過程,其狀態(tài)空間為{M1,…,Mn…,Mn+A1+…+An},轉移矩陣為 P~=[p~(i,j)]。該帶有系統(tǒng)調用的可靠性模型同樣只考慮了一種失效模式且不考慮錯誤傳播,軟件可靠性計算方法與3.1節(jié)中無系統(tǒng)調用的基本模型相同,這里不再贅述。
在上述考慮系統(tǒng)調用的可靠性模型基礎上,嘗試對軟件中的多種失效模式和錯誤傳播進行建模。為方便起見,重新假設軟件抽取系統(tǒng)調用模塊后在狀態(tài)圖中共形成n個模塊,集合SELF表示所有抽取系統(tǒng)調用后的自身代碼模塊,用集合CALL表示所有系統(tǒng)調用模塊,SELF∪CALL={M1,M2,…,Mn}。同時假設軟件出口模塊和入口模塊均唯一,分別為 M1和 Mn,M1,Mn∈SELF。各模塊之間的控制流轉移概率Qij依然可以通過公式(1)計算得到。
由于常見的操作系統(tǒng)只使用了兩個特權級別,分別對應操作系統(tǒng)的內核態(tài)和用戶態(tài),可引發(fā)兩種不同的失效:用戶態(tài)失效和內核態(tài)失效,分別編號為1和2。同時,為了敘述方便和表示方法的統(tǒng)一,將未發(fā)生失效作為一種特殊的失效模式,標號為0。設在任一個模塊Mi內部,這三種失效模式都可能發(fā)生相互轉換,且定義函數(shù) fi(x,y)為模塊Mi內各失效模式的轉換概率:
其中 0≤x,y≤2,并且函數(shù)fi(x,y)滿足
當x和 y數(shù)值變化時,fi(x,y)可以表示模塊 Mi的一些屬性和錯誤傳播行為:fi(0,0)表示模塊Mi可靠性;fi(0,1)與 fi(0,2)分別表示 Mi發(fā)生用戶態(tài)失效和內核態(tài)失效的概率;fi(1,1)與 fi(2,2)分別表示用戶態(tài)失效和內核態(tài)失效透過模塊Mi的概率。
在考慮了失效模式之后,便無法使用一個節(jié)點表示一個模塊中的所有狀態(tài),此時需要對每個節(jié)點進行擴展。對于任意的模塊Mi,其輸入有三種失效模式;由于考慮了錯誤傳播,失效模式可以在模塊內部發(fā)生相互轉化,模塊Mi的輸出也可能存在三種失效模式。因此,將模塊Mi在狀態(tài)圖中的1個節(jié)點擴展成6=(3+3)個節(jié)點:3個節(jié)點分別表示模塊Mi在輸入為三種不同失效模式下的執(zhí)行過程,記為 MIi={MIi1,MIi2,MIi3},分別表示模塊Mi輸入為未失效、用戶態(tài)失效、內核態(tài)失效的執(zhí)行過程;另外3個節(jié)點表示模塊Mi執(zhí)行完畢所處的失效模式,記為 MOi={MOi1,MOi2,MOi3},分別表示模塊 Mi執(zhí)行完畢的狀態(tài)為未失效、用戶態(tài)失效、內核態(tài)失效。擴展后的節(jié)點如圖3所示。
圖3 模塊節(jié)點的擴展
特別地,對于模塊Mi在執(zhí)行過程中進行系統(tǒng)調用模塊 Mj的情況,在 Mi的執(zhí)行狀態(tài) MIiα中按概率轉移到狀態(tài)MIjα執(zhí)行系統(tǒng)調用;MIjα執(zhí)行完畢后發(fā)生狀態(tài)轉移到MOjβ(若執(zhí)行過程中失效模式沒有改變則α=β,否則α≠β);在進入狀態(tài)MOjβ后,就表示系統(tǒng)調用執(zhí)行完畢,將必然返回調用模塊Mi,轉移到狀態(tài)MIiβ。圖4是一個帶有系統(tǒng)調用節(jié)點擴展的例子,圖4(a)是局部的控制流,模塊 M1進行了系統(tǒng)調用,調用模塊M3,圖4(b)是擴展后的狀態(tài)圖。
圖4 帶有系統(tǒng)調用節(jié)點的擴展實例
用這些狀態(tài)構造一個離散時間馬爾可夫過程用來分析軟件的可靠性,狀態(tài)空間為:
狀態(tài)轉移矩陣為Q=[q(s,t)],具體構造如下:
第一種情況是模塊Mi進行調用系統(tǒng)調用模塊Mj,調用概率與Mi的失效模式無關,等于控制流轉移的概率;第二種情況是執(zhí)行系統(tǒng)調用Mi過程中發(fā)生的失效模式轉換;第三種情況是系統(tǒng)調用模塊Mi執(zhí)行完畢后返回模塊Mj,執(zhí)行完畢后必然返回;第四種情況是在模塊Mi執(zhí)行過程中發(fā)生的失效模式轉換;第五種情況是模塊Mi執(zhí)行完畢繼而執(zhí)行模塊Mj,此時不會再發(fā)生系統(tǒng)調用,轉入模塊Mj的概率是轉入該模塊的控制流轉移概率與所有可能轉入模塊的控制流概率之和的比值;對于其他情況,狀態(tài)轉移的概率為0。
在該模型中,軟件的可靠性是從初始狀態(tài)M1,0到達終止狀態(tài)MOn,0的概率,其推導方法與3.1節(jié)中相同,這里不再贅述。
選取了Linux操作系統(tǒng)下一個自己編寫的簡單系統(tǒng)來演示如何應用上述的可靠性分析模型,軟件結構如圖5所示。
圖5 軟件基本結構
在這個實例中,軟件有兩種失效:自身崩潰和操作系統(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ù)
系統(tǒng)調用和控制流的獲取采用實驗統(tǒng)計的方法獲得。在運行軟件的同時,使用OProfile等系統(tǒng)分析工具跟蹤記錄軟件中各模塊的控制流轉移情況和發(fā)生次數(shù)、各模塊內部系統(tǒng)調用情況和調用次數(shù)。在軟件長時間運行之后,根據(jù)得到的數(shù)據(jù)計算后可得控制流的轉移概率。
具體地,得到的程序控制流如圖6所示,其中,自身代碼集合 SELF={M1, M2, M3, M4} ,系統(tǒng)調用集合CALL={M5,M6,…,M11},這 11 個模塊的控制流轉移概率為:
圖6 軟件的控制流
對于系統(tǒng)調用模塊Mi(i=5,6,…,11),只可能發(fā)生失效模式2,即運行過程中只會出現(xiàn)失效模式0和失效模式2,且失效模式2不會向其他失效模式轉換。借助CMU的Ballista測試[14]來獲得每個系統(tǒng)調用的失效率 fi(0,2),而每個系統(tǒng)調用模塊的可靠性 fi(0,0)=1-fi(0,2)。
另一方面,對于自身代碼模塊 Mi(i=1,2,…,4)運行在用戶態(tài)不可能出現(xiàn)失效模式2,且失效模式1也不會向其他失效模式再次轉換。采用算法BR進行大量的隨機測試獲得 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)調用引起,遞增FailCount;
(7)根據(jù)計數(shù)器的數(shù)值計算模塊Mi的失效率
通過實驗得到的數(shù)據(jù)如表1~11所示。
表10 模塊M10實驗數(shù)據(jù)
根據(jù)已經獲得的各項參數(shù),可以建立一個66×66的稀疏狀態(tài)轉移矩陣。應用Matlab進行矩陣的計算,最終該軟件在Linux環(huán)境下運行的可靠性為0.472。
表11 模塊M11實驗數(shù)據(jù)
本文在經典的軟件可靠性分析/預測模型基礎上考慮了運行環(huán)境對可靠性的影響,將軟件中的系統(tǒng)調用從軟件自身模塊中抽取出來作為特殊的模塊并考慮了多種失效模式,提出了一種更貼近實際的軟件可靠性分析模型。盡管在應用過程中,該模型的狀態(tài)空間比傳統(tǒng)模型有所增加,但狀態(tài)轉移矩陣為稀疏矩陣,只需要計算特定的非零元素即可,同時可以應用Matlab等數(shù)學軟件進行矩陣的輔助計算。
此外,由于不同的操作系統(tǒng)中內核代碼可靠性各不相同,軟件運行的可靠性也隨之受到影響,該模型可以有效體現(xiàn)出不同操作系統(tǒng)對軟件可靠性的影響。同時,該模型適用于常見的系統(tǒng)架構和Windows、Linux、MacOS、Unix等常見的操作系統(tǒng),在為特定軟件選擇運行環(huán)境時也可具有一定的應用價值。
[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.