文|蘇蕁墨
編輯|蘇蕁墨
前言
隨著對軟體應用程式的依賴性越來越大，軟體可靠性分析是不可避免的。軟體可靠性被定義為揭示系統在特定環境中在特定時間內正確（無故障）執行所需服務或功能的能力的概率。
故障是影響軟體需求的不正確結果或意外行為。可靠性預測模型參與預防軟體故障，這些故障可能會在安全關鍵應用程式甚至業務中導致關鍵事件和災難性後果。
根據可靠性測量生命周期，可以在開發早期、測試後期或部署後採取措施，開發中使用的數據是評估數據，而測試數據和真實世界數據用於後期測量。
執行早期測量以發現薄弱的設計點，另一方面，後來的測量用於組件認證和系統發布決策。
用於後期測量（測試和部署後）的可靠性模型是相似的，因為輸入數據和目標之間沒有太大差異。
例如，早期的可靠性模型著重於解決與編碼前操作數據短缺和精確建模系統行為的方式相關的問題。
後來的模型主要關注預測模型的準確性，而沒有太多考慮數據獲取和系統行為建模的方法，本著研究面向早期可靠性測量，因為它通過避免重建整個系統或重複測試，在時間和預算方面最具成本效益。
白盒模型的不同設計
在設計時可靠性預測的背景下，已經為早期設計階段開發了各種模型。這些模型可以分為灰盒和白盒。
在灰盒模型中，系統可靠性是基於組件的可靠性來預測的，而無需了解組件的內部行為。使用現有的黑盒技術之一估計組件的可靠性。
相比之下，白盒模型基於描述其內部行為的架構設計來構建用於估計單個組件可靠性的技術，提出的模型有助於並支持基於架構的白盒模式。
此外，所提出的模型不依賴於組件的可靠性，而是更深入地研究組件的內部行為。參與場景內交互的各個組件的操作被考慮以獲得場景的可靠性。
術語可伸縮性是指對大型和複雜的軟體系統進行建模。軟體系統的規模及其複雜性取決於系統操作的數量和場景而不是組件的數量。
系統的複雜性是通過計算各個場景中的操作數量來衡量的。計算成本的增加總是這兩個因素的結果。
為了計算複雜場景的可靠性，需要有足夠的空間來容納操作以及這些操作之間的轉換，場景的數量會影響計算成本，因為還需要很大的空間來解決通過場景組合構建的最終模型。
可擴展性問題是當前可靠性模型所忽視的主要問題之一，計算成本的增加是與可伸縮性相關的問題。
解決可擴展性問題通常會導致狀態空間變大，從而導致計算成本增加，在中提出的方法中，考慮了可擴展性和計算成本降低。
它通過將場景截斷為基於分層組織的子場景來解決可伸縮性問題。同時，單獨計算每個子場景的可靠性導致計算成本降低。
該研究發表於引入了一種依賴於狀態空間壓縮的計算成本降低解決方案，然而，提出的方法不同，當中的方法不依賴於需求規範作為場景綜合的主要來源。
通過提供考慮場景大小和場景數量的合適場景建模，開發可擴展的行為建模方法可以在增強可靠性預測的可擴展性方面發揮核心作用。
確切地說，可靠性方法應該通過對系統的場景進行簡潔明了的描述來解決可擴展性問題，從而導致場景更少。
同時，通過引入合適的可靠性計算策略，可以在可擴展性和計算成本之間取得平衡，針對過程和面向對象編程等傳統編程技術設計的軟體可靠性模型無法分析現代軟體方法的可靠性。
目前的軟體，如CBS和SOA，需要新的可靠性分析方法來區分順序應用程式和並發應用程式。
在順序應用程式中，執行轉換按順序從一個場景移動到另一個場景，而在並發應用程式中，執行轉換移動到並發運行的多個場景。
因此，與並發軟體相比，預測順序軟體的可靠性是不同的，大多數都沒有過多關注並發應用程式的性質及其所需的建模。
行為建模工具分別命名為富架構定義語言 (RADL)、Palladio 組件模型 (PCM) 和具有概率轉換的通信自動機 (CAWPT)。
這些行為建模工具生成有限狀態機 (FSM) 或馬爾可夫模型 (MM) 的符號作為輸出，可靠性是基於離散時間馬爾可夫鏈（DTMC）或連續時間馬爾可夫鏈（CTMC）計算的。
但是，與其他工具不同，這些工具不可下載或作為商業產品，此外，可以控制時間相關行為系統建模的序列圖不屬於任何這些模型。
它使用非常相似的序列圖 ( SD ) 或消息序列圖 (MSC )，SD 和 MSC 使用連結來促進從系統規範到 MM 的轉換。
SD 和 MSC 是強大的場景描述工具，然而，我們提出的模型中呈現的s-TS場景語言類似於 SD 和 MSC。
此外，它通過簡潔明了地描述場景，為可擴展性增強提供了更多解決方案，MM 表示法直接用於生成概率依賴圖 (PDG)，以對組件之間的交互進行建模，並基於 PDG 通過算法計算可靠性。
行為建模需要能夠促進從系統規範到 MM 的轉變的工具。此外，我們需要可擴展性和時間相關的行為建模能力。
首選建模工具來提供系統開發人員熟悉的類似 UML 的符號。例如，介紹了與促進從系統規範到 MM 的轉換有關的解決方案。
這樣的解決方案對於系統架構師對模型的真實解釋是必需的。此外，提出的更多場景劃分和壓縮策略需要支持可擴展性。
擬議的模型有幾個活動，詳見圖1. 這些活動分為兩個主要階段。
第一階段說明行為建模和場景可靠性計算所需的
活動。 第二階段描述場景的組合機制和系統可靠性的確定。
如圖所示圖1，模型活動首先使用s-TS描述系統場景，使用運行時，示例說明了第一階段的活動，簡而言之，我們之前的工作中描述的幾個行為建模步驟應用於階段1。
狀態機將為場景中的所有組件實例構建。然後，與每個組件實例相關的故障概率是通過分別處理其 FSM 來計算的。
因此，場景可靠性的計算在有限的狀態空間內進行，以降低計算成本。組件的故障概率揭示了組件在場景中的重要性。
場景的可靠性使用操作配置文件信息計算。在階段 1 結束時，根據組件的故障概率計算整個場景的故障概率。
獨立處理組件行為的重要性有助於構建全局系統行為模型，而無需組件的內部狀態（組件交互），這在大型軟體系統中會導致狀態空間爆炸問題。
在第 2 階段，圖1，對於順序應用程式，系統可靠性是根據場景發生概率表計算的。在並發應用程式中，多項式分布用於生成場景的組合概率以計算組合可靠性。
這些活動的最終結果是並發執行假設下的系統可靠性。
使用s-TS作為帶有系統約束注釋的場景描述語言來描述系統場景可以迫使系統架構師了解這些場景所隱含的需求和系統行為。
這是由於s-TS語言通過條件、觸發和先發制人的行為表徵識別不同行為方向之間明確的因果關係。
它最重要的特性是通過簡潔緊湊的方式描述軟體場景來增強可擴展性，從而減少場景。
然而，場景的壓縮會增加場景內的狀態數量，增加計算成本，這可以通過在基於組件實例的可靠性計算中將每個場景截斷成小單元來避免。
實驗運行過程的示例
ATM密碼驗證場景（如圖 2) 被選為一個正在進行的例子來說明所提出的模型。如下圖所示圖 2，所選擇的場景由名為 UI、ATM 和 Bank 的三個組件組成。
此外，圖中顯示的場景（圖3）自動軌道車系統的模型也在本節中用作補充性持續示例來說明行為建模。
然而，ATM的重置場景將描述場景可靠性的計算。此外，在說明系統可靠性度量中，ATM 系統用於表示順序軟體應用程式，而軌道車系統用於並發應用程式。
場景準備從使用s-TS對場景建模開始，類似於大多數現有的觸發場景描述語言，它源自名為標籤偏序 (LPO) 的時序圖的基本語法。
s-TS使用額外的結構來使場景更加緊湊和簡潔。因此，任何序列圖語法中的系統場景描述都可以被認為是s-TS場景的輸入。
它是一種可以緊湊、簡潔地描述或組合場景的工具，圖 3c 顯示了一個s-TS場景，它是組合中所示場景的結果圖 3a,b 是時序圖中描述的。
儘管場景中的所有組件都被同時注釋和傳播，而不是像那樣只有一個組件實例。
這裡，目標行為模型代表整個場景的行為，而在中，構建的行為模型代表一個組件的行為。
圖 4b 顯示了密碼驗證的場景，如圖所示圖 4在注釋和傳播之後。每個組件實例都根據其狀態變量進行獨立注釋，如圖中所示圖 4A。
將準備好的s-TS場景轉換為 FSM。一旦s-TS的系統場景將準備好的s-TS場景轉換為 FSM。
一旦s-TS的系統場景被注釋和傳播，它將準備好轉換為 FSM。這些 FSM 代表場景的行為。此過程將場景中描述的每個組件實例轉換為 FSM。
例如，給定一個s-TS，讓F是從s-TS中的實例獲得的 FSM，這個想法是將每個狀態向量值轉換為 FSM 中的一個狀態。
因此，對應於組件實例中的狀態向量值的正常狀態由s表示。同時也表示第一狀態向量值。
一個分支狀態向量值，則組件實例的發送消息和重放消息由T表示為一個轉移關係。圖 5顯示從中所示場景轉換的密碼驗證場景的 FSM圖 4b.
結語
s-TS描述的場景可以參與發現與組件交互相關的不一致。這些不一致會導致錯誤，例如接口和前置條件和後置條件的簽名不匹配。
在基於組件的模型中，組件之間的交互是通過組件所需和提供的服務來管理的，這些服務由組件的操作來實現。
因此，這些錯誤的所有類型都可以抽象並封裝在操作的失敗概率中，組件的故障概率被合併為一個指標。
在本文中，作為組件故障實例的操作故障被用作等式（2）的輸入；因此，計算出來的應該會更準確。
從s-TS描述的場景規範中，可以準確地確定為每個特定組件的交互調用的操作。
因此，回到等式（1），可以通過表示場景中調用操作的失敗概率來替換它來進行修改，等式（1）經過修改後，可以描述如下：