本發(fā)明是一種嵌入式軟件安全性自動(dòng)化驗(yàn)證系統(tǒng)及其驗(yàn)證方法，屬于軟件安全性分析領(lǐng)域。

背景技術(shù)：

嵌入式軟件在航空航天等領(lǐng)域廣泛應(yīng)用，越來越多的功能采用軟件實(shí)現(xiàn)。近年來，隨著軟件復(fù)雜性的提高，軟件失效導(dǎo)致的故障頻繁發(fā)生，因此保障嵌入式軟件的安全性已成為近年來軟件工程領(lǐng)域的研究熱點(diǎn)。歐美成熟經(jīng)驗(yàn)表明，開展軟件安全性分析工作是提升軟件質(zhì)量的有效方法，主要工作包括嵌入式軟件安全需求的提取與規(guī)約、面向標(biāo)準(zhǔn)的嵌入式軟件開發(fā)、嵌入式軟件安全需求驗(yàn)證三部分內(nèi)容。

嵌入式軟件需求驗(yàn)證是安全性分析中的關(guān)鍵環(huán)節(jié)，形式化驗(yàn)證和軟件測(cè)試是嵌入式軟件安全需求驗(yàn)證的主要方法。這兩種方法各有利弊，形式化驗(yàn)證能夠在軟件需求分析和設(shè)計(jì)的早期階段發(fā)現(xiàn)模型漏洞，縮短研發(fā)周期，且通過形式化驗(yàn)證能夠挖掘由多個(gè)控制功能之間的數(shù)據(jù)交互、時(shí)序約束、并發(fā)組合等復(fù)雜邏輯關(guān)系引發(fā)的軟件需求缺陷。但是形式化方法本身的復(fù)雜性對(duì)工程人員提出了很高的要求，使得當(dāng)前在國內(nèi)普及使用非常困難。此外，形式化驗(yàn)證的分析對(duì)象是軟件模型，無法發(fā)現(xiàn)軟件模型與具體實(shí)現(xiàn)不一致而導(dǎo)致的軟件缺陷。在國內(nèi)，軟件測(cè)試仍然是提高對(duì)軟件安全性的最有效的手段，軟件測(cè)試通常在研制的中后期開展，被測(cè)軟件被安裝在真實(shí)的硬件設(shè)備中運(yùn)行，不僅能找出代碼實(shí)現(xiàn)的局部方法錯(cuò)誤等細(xì)枝末節(jié)問題，還能找出由于軟件實(shí)現(xiàn)與模型在邏輯上的背離而導(dǎo)致的重大安全性問題。但軟件測(cè)試過程中由于測(cè)試用例的覆蓋率有限，難以窮盡對(duì)整個(gè)系統(tǒng)的測(cè)試，而安全苛求系統(tǒng)的運(yùn)行通常與外部環(huán)境有關(guān)，其執(zhí)行往往具有不確定性，測(cè)試極為困難，因此軟件測(cè)試方法不能從根本上保證系統(tǒng)的安全性。

目前，形式化驗(yàn)證方法由于理論性較強(qiáng)，在嵌入式軟件研制過程中較少開展。而對(duì)于軟件測(cè)試，雖然有部分測(cè)試平臺(tái)出現(xiàn)，但普及程度較低。大多采用人工測(cè)試的方式，對(duì)于復(fù)雜的軟件系統(tǒng)，測(cè)試效率低，并且無法發(fā)現(xiàn)多狀態(tài)并發(fā)、多功能沖突等導(dǎo)致的軟件問題。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明正是針對(duì)上述現(xiàn)有技術(shù)領(lǐng)域中存在的不足而設(shè)計(jì)提供了一種嵌入式軟件安全性自動(dòng)化驗(yàn)證系統(tǒng)及其驗(yàn)證方法，其目的是根據(jù)形式化驗(yàn)證和軟件測(cè)試的特點(diǎn)和互補(bǔ)性，將這兩種技術(shù)手段相融合，結(jié)合國內(nèi)工程實(shí)際和研制要求，綜合考慮分析要素和工程限制，提出一種符合國內(nèi)研制現(xiàn)狀的種嵌入式軟件安全性自動(dòng)化驗(yàn)證系統(tǒng)及其驗(yàn)證方法，提高國內(nèi)嵌入式軟件需求驗(yàn)證水平。

本發(fā)明的目的是通過以下技術(shù)方案來實(shí)現(xiàn)的：

本發(fā)明技術(shù)方案提出了一種嵌入式軟件安全性自動(dòng)化驗(yàn)證系統(tǒng)，其特征在于：該系統(tǒng)包括：

A軟件需求建模模塊(1)，其功能是根據(jù)待驗(yàn)證軟件的ICD文件和需求規(guī)格說明對(duì)待驗(yàn)證軟件進(jìn)行形式化描述，形成軟件需求模型文件，該軟件需求建模模塊(1)包括：

ICD建模模塊(2)，其功能是描述待驗(yàn)證軟件運(yùn)行的外部交聯(lián)環(huán)境，包括與外部設(shè)備之間的交聯(lián)關(guān)系、總線類型及通信協(xié)議，形成ICD模型數(shù)據(jù)；

軟件形式化建模模塊(3)，其功能是在ICD模型數(shù)據(jù)的基礎(chǔ)上，采用UML和OCL形式化語言描述待驗(yàn)證軟件的內(nèi)部行為，包括狀態(tài)遷移及功能邏輯，最終形成軟件需求模型文件；

該軟件需求建模模塊(1)中，ICD建模模塊(2)與軟件形式化建模模塊(3)連接，由ICD建模模塊(2)向軟件形式化建模模塊(3)傳輸ICD模型數(shù)據(jù)；

B安全性驗(yàn)證規(guī)則數(shù)據(jù)庫(4)，其功能是存儲(chǔ)安全性驗(yàn)證規(guī)則，并提供查詢、匹配、更新、維護(hù)的接口；

C形式化驗(yàn)證模塊(5)，分別與軟件需求建模模塊(1)和安全性驗(yàn)證規(guī)則數(shù)據(jù)庫(4)連接，由軟件需求建模模塊(1)向形式化驗(yàn)證模塊(5)傳輸軟件需求模型文件，由安全性驗(yàn)證規(guī)則數(shù)據(jù)庫(4)向形式化驗(yàn)證模塊(5)提供驗(yàn)證的依據(jù)，即安全性驗(yàn)證規(guī)則，該形式化驗(yàn)證模塊(5)的功能是基于安全性驗(yàn)證規(guī)則數(shù)據(jù)庫(4)中的安全性驗(yàn)證規(guī)則，對(duì)軟件需求建模模塊(1)形成的軟件需求模型文件進(jìn)行形式化驗(yàn)證，形成形式化驗(yàn)證結(jié)果；

D安全性測(cè)試模塊(6)，分別與軟件需求建模模塊(1)、安全性驗(yàn)證規(guī)則數(shù)據(jù)庫(4)和形式化驗(yàn)證模塊(5)相連接，由軟件需求建模模塊(1)向安全性測(cè)試模塊(6)提供軟件需求模型文件，由安全性驗(yàn)證規(guī)則數(shù)據(jù)庫(4)向安全性測(cè)試模塊(6)提供安全性驗(yàn)證規(guī)則，由形式化驗(yàn)證模塊(5)向安全性測(cè)試模塊(6)提供形式化驗(yàn)證結(jié)果，該安全性測(cè)試模塊(6)的功能是根據(jù)的軟件需求模型文件和形式化驗(yàn)證結(jié)果以及安全性驗(yàn)證規(guī)則生成測(cè)試用例并通過翻譯進(jìn)行用例格式轉(zhuǎn)換，以適應(yīng)不同測(cè)試執(zhí)行平臺(tái)的需要，該安全性測(cè)試模塊(6)包括：

測(cè)試用例生成模塊(7)，其功能是生成XML格式的測(cè)試用例；

測(cè)試用例翻譯模塊(8)，其功能接收測(cè)試用例生成模塊(7)生成的XML格式的測(cè)試用例，并將其翻譯成其它格式的測(cè)試用例，其它格式包括自然語言格式、腳本語言格式。

本發(fā)明技術(shù)方案還提出用于上述嵌入式軟件安全性自動(dòng)化驗(yàn)證系統(tǒng)的驗(yàn)證方法，其特征在于：該方法的步驟如下：

步驟一、通過對(duì)待驗(yàn)證軟件運(yùn)行的外部交聯(lián)環(huán)境，包括與外部設(shè)備之間的交聯(lián)關(guān)系、總線類型及通信協(xié)議的描述，建立ICD模型數(shù)據(jù)；

步驟二、在ICD模型數(shù)據(jù)的基礎(chǔ)上，采用OCL形式化語言描述待驗(yàn)證軟件的內(nèi)部行為，包括狀態(tài)遷移及功能邏輯，建立軟件需求模型文件；

步驟三、將已有的軟件失效原因，歸納形成安全性驗(yàn)證規(guī)則，建立安全性驗(yàn)證規(guī)則數(shù)據(jù)庫；步驟四、基于安全性驗(yàn)證規(guī)則數(shù)據(jù)庫中的安全性驗(yàn)證規(guī)則，對(duì)軟件需求模型文件進(jìn)行形式化驗(yàn)證，獲得形式化驗(yàn)證結(jié)果；

步驟五、根據(jù)軟件需求模型文件、形式化驗(yàn)證結(jié)果以及安全性驗(yàn)證規(guī)則，生成XML格式的安全性測(cè)試用例；

步驟六、對(duì)XML格式的安全性測(cè)試用例進(jìn)行格式轉(zhuǎn)換，生成測(cè)試執(zhí)行時(shí)所需要的用例格式。

本發(fā)明的優(yōu)點(diǎn)與積極效果在于：

(1)采用本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)，結(jié)合了形式化驗(yàn)證和軟件測(cè)試兩種方法，實(shí)現(xiàn)了在研制早期對(duì)軟件需求模型進(jìn)行形式化驗(yàn)證，在研制中后期，為軟件測(cè)試提供了測(cè)試用例，彌補(bǔ)了現(xiàn)有單一方法的不足，增強(qiáng)了驗(yàn)證的充分性；

(2)采用本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)大大降低了用戶的使用門檻，易于推廣，軟件需求建模模塊中采用的UML和OCL形式化語言是相關(guān)領(lǐng)域從業(yè)人員普遍掌握的技術(shù)，驗(yàn)證系統(tǒng)的適用人員無需掌握復(fù)雜的形式化驗(yàn)證算法；

(3)采用本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)實(shí)現(xiàn)了形式化驗(yàn)證和安全性測(cè)試用例生成的自動(dòng)化，用戶只需構(gòu)建軟件需求模型文件和選擇采用的安全性驗(yàn)證規(guī)則，驗(yàn)證工作由系統(tǒng)自動(dòng)完成；

(4)本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)中安全性驗(yàn)證規(guī)則數(shù)據(jù)庫的提出，為工程經(jīng)驗(yàn)的積累及使用提供了切實(shí)可行的方法，有利于建立具有自主知識(shí)產(chǎn)權(quán)的領(lǐng)域失效數(shù)據(jù)庫，通過經(jīng)驗(yàn)數(shù)據(jù)的不斷積累，對(duì)后期研制的指導(dǎo)作用不斷增強(qiáng)；

(5)本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)降低了工程實(shí)施難度，對(duì)復(fù)雜的發(fā)控軟件進(jìn)行建模時(shí)取得良好效果；

(6)本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)基于安全性驗(yàn)證規(guī)則的形式化驗(yàn)證更有針對(duì)性，避免使用窮舉遍歷的方法導(dǎo)致的空間爆炸問題；

(7)本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)獲得的形式化驗(yàn)證結(jié)果預(yù)置條件明確，輸入數(shù)值精準(zhǔn)，可操作、可實(shí)施，便于發(fā)現(xiàn)問題時(shí)人工復(fù)現(xiàn)及回放；

(8)本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)建模時(shí)采用標(biāo)準(zhǔn)的UML建模語言，符合相關(guān)國軍標(biāo)標(biāo)準(zhǔn)，構(gòu)建的模型可以直接用于軟件需求分析及設(shè)計(jì)中，避免了多次重復(fù)建模；

(9)本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)在需求建模時(shí)采用了相同的建模元素，形式化驗(yàn)證和安全性測(cè)試的對(duì)象是具有統(tǒng)一格式的軟件需求模型，所以能夠編寫通用的形式化驗(yàn)證算法和測(cè)試用例生成算法，因此該方法能夠應(yīng)用于各領(lǐng)域嵌入式軟件安全性驗(yàn)證中，具有很好的通用性。

附圖說明

圖1是本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)的框圖

圖2是本發(fā)明技術(shù)方案中軟件需求建模模塊構(gòu)建流程圖

圖3是本發(fā)明技術(shù)方案中軟件外部交聯(lián)環(huán)境及接口示意圖

圖4是本發(fā)明技術(shù)方案中狀態(tài)圖基于OCL的形式化描述示例

圖5是本發(fā)明技術(shù)方案中安全性驗(yàn)證規(guī)則數(shù)據(jù)庫的形成和使用過程

圖6是本發(fā)明技術(shù)方案中基于安全性驗(yàn)證規(guī)則的模型檢測(cè)算法示例

圖7是本發(fā)明技術(shù)方案中狀態(tài)功能關(guān)聯(lián)后的需求模型示例

具體實(shí)施方式

以下將結(jié)合附圖和實(shí)施例對(duì)本發(fā)明技術(shù)方案作進(jìn)一步地詳述：

參見附圖1所示，本發(fā)明技術(shù)方案所述的嵌入式軟件安全性自動(dòng)化驗(yàn)證系統(tǒng)，其特征在于：該系統(tǒng)包括：

A軟件需求建模模塊1，其功能是根據(jù)待驗(yàn)證軟件的ICD文件和需求規(guī)格說明對(duì)待驗(yàn)證軟件進(jìn)行形式化描述，形成軟件需求模型文件，該軟件需求建模模塊1包括：

ICD建模模塊2，其功能是描述待驗(yàn)證軟件運(yùn)行的外部交聯(lián)環(huán)境，包括與外部設(shè)備之間的交聯(lián)關(guān)系、總線類型及通信協(xié)議，形成ICD模型數(shù)據(jù)；

軟件形式化建模模塊3，其功能是在ICD模型數(shù)據(jù)的基礎(chǔ)上，采用OCL形式化語言描述待驗(yàn)證軟件的內(nèi)部行為，包括狀態(tài)遷移及功能邏輯，最終形成軟件需求模型文件；

該軟件需求建模模塊1中，ICD建模模塊2與軟件形式化建模模塊3連接，由ICD建模模塊2向軟件形式化建模模塊3傳輸ICD模型數(shù)據(jù)；

參見附圖2所示，軟件需求建模模塊1是基于SafeTrip的建模工具通過以下步驟來實(shí)現(xiàn)的，其中：

ICD建模模塊2的建模步驟為：

1.如圖3所示，以航空發(fā)動(dòng)機(jī)控制軟件為例，構(gòu)建外部交聯(lián)環(huán)境模型，具體過程如下：

1.1使用建模工具，繪制待驗(yàn)證軟件所在系統(tǒng)以及與之相連的系統(tǒng)，；

1.2根據(jù)ICD文件使用總線連接待測(cè)軟件所在系統(tǒng)與其他系統(tǒng)；

1.3配制總線的接口信息，接口信息包括兩部分：一部分是接口通信信息，即外部交聯(lián)接口模型針對(duì)軟件與外部交聯(lián)設(shè)備之間的各種常見接口類型(例如ARINC 429，CAN，離散量、模擬量等)的通訊格式與內(nèi)容，主要包括接口名稱、接口類型、總線通信所需的波特率、路由尋址、優(yōu)先級(jí)、傳輸速率等。另一部分是輸入輸出接口的約束條件。根據(jù)軟件需求文檔，明確各接口自身及相互之間的邏輯、時(shí)序約束條件。邏輯條件主要包括與、或、非、互斥等。時(shí)序條件包括前序、后序、并發(fā)、延時(shí)、計(jì)時(shí)等。

2構(gòu)建總線傳輸數(shù)據(jù)模型，具體過程如下：

在外部交聯(lián)環(huán)境模型的基礎(chǔ)上，將總線數(shù)據(jù)拆分成數(shù)據(jù)幀和幀變量。并詳細(xì)描述數(shù)據(jù)幀和幀變量的屬性?？偩€數(shù)據(jù)包含一個(gè)或多個(gè)數(shù)據(jù)幀、數(shù)據(jù)幀具有傳輸方向，傳輸周期、數(shù)據(jù)幀長度等屬性。每個(gè)數(shù)據(jù)幀包含多個(gè)幀變量，幀變量具有變量類型(整型、浮點(diǎn)型、字符型等)、長度等屬性。

軟件形式化建模模塊3的建模步驟為：

1.構(gòu)建內(nèi)部數(shù)據(jù)元素和接口數(shù)據(jù)元素

接口數(shù)據(jù)元素和內(nèi)部數(shù)據(jù)元素是軟件內(nèi)部可識(shí)別的具有物理意義的變量，如高度、速度、油門桿角度，是后續(xù)功能模型和狀態(tài)轉(zhuǎn)移模型的操作對(duì)象，變量屬性包含描述物理意義的信息，如數(shù)據(jù)單位、分辨率、誤差、有效區(qū)間，接口數(shù)據(jù)元素描述了軟件的對(duì)外交互行為，通過總線傳輸數(shù)據(jù)模型映射獲得，如數(shù)據(jù)幀中的前兩個(gè)short類型的幀變量可以映射成表示高度的Height接口數(shù)據(jù)元素,映射表達(dá)式為：Height＝Var1<<8+Var2。這里的映射表示的是值的映射，映射關(guān)系采用數(shù)學(xué)表達(dá)式，實(shí)現(xiàn)時(shí)可采用MuParser等工具以支持基于復(fù)雜運(yùn)算的映射和解析，除了完成值的映射，接口數(shù)據(jù)元素獲得了數(shù)據(jù)幀的周期等邏輯和時(shí)序信息，并將這些信息引入軟件內(nèi)部模型中，內(nèi)部數(shù)據(jù)元素由軟件內(nèi)部處理時(shí)的中間結(jié)果和臨時(shí)變量構(gòu)成，從需求文檔中獲得；

構(gòu)建接口數(shù)據(jù)元素和內(nèi)部數(shù)據(jù)元素的方式為：在SafeTrip工具中選擇新建相應(yīng)元素，然后配置元素的數(shù)據(jù)單位、分辨率、誤差、有效區(qū)間，接下來配置該數(shù)據(jù)元素關(guān)聯(lián)的數(shù)據(jù)幀變量，并使用MuParser表達(dá)式描述數(shù)據(jù)元素與幀變量的對(duì)應(yīng)關(guān)系。

2.參見附圖4所示，基于UML狀態(tài)圖和OCL的形式化狀態(tài)遷移模型

有了接口數(shù)據(jù)元素和內(nèi)部數(shù)據(jù)元素，可以采用標(biāo)準(zhǔn)UML中的狀態(tài)圖對(duì)軟件運(yùn)行的狀態(tài)與方式進(jìn)行建模，構(gòu)建狀態(tài)遷移模型，為了進(jìn)行安全性分析，需要采用OCL對(duì)象約束語言對(duì)狀態(tài)圖中的狀態(tài)轉(zhuǎn)移進(jìn)行形式化描述，標(biāo)準(zhǔn)UML中，狀態(tài)轉(zhuǎn)移的語法格式為：事件名[警戒條件]/動(dòng)作表達(dá)式^發(fā)送子句，OCL對(duì)狀態(tài)圖的形式化擴(kuò)展主要包括以下幾方面：

變化事件。變化事件是指如果一個(gè)布爾表達(dá)式中的變量發(fā)生變化，使得該表達(dá)式的值相應(yīng)地變化，從而滿足某些條件的事件。與警戒條件不同，當(dāng)事件發(fā)生時(shí)，警戒條件只計(jì)算一次，如果條件為假，狀態(tài)轉(zhuǎn)移將不會(huì)發(fā)生。當(dāng)變化事件發(fā)生時(shí)，警戒條件可能阻塞，等待警戒條件滿足后進(jìn)行狀態(tài)遷移；

警戒條件。OCL表達(dá)式可以用于狀態(tài)警戒條件的描述，描述位置為觸發(fā)轉(zhuǎn)移發(fā)生的事件之后的方括號(hào)內(nèi)；

動(dòng)作表達(dá)式實(shí)參。狀態(tài)圖中的動(dòng)作包含操作的調(diào)用和發(fā)送事件，通常需要攜帶參數(shù)，為了滿足安全性分析的需要，此處參數(shù)需要明確指定實(shí)參，而不能使用形參。此時(shí)，需要使用OCL表達(dá)式明確指定實(shí)參；

發(fā)送子句。狀態(tài)圖遷移動(dòng)作表達(dá)式指出了當(dāng)狀態(tài)轉(zhuǎn)移被激活時(shí)(對(duì)象狀態(tài)發(fā)生轉(zhuǎn)移時(shí))，對(duì)象本身需要執(zhí)行的動(dòng)作。有時(shí)對(duì)象能自己執(zhí)行所有的功能，需要其它對(duì)象的幫助，從而對(duì)象就需要發(fā)送消息給其它對(duì)象。此時(shí)需要利用發(fā)送子句。而OCL可以用于描述發(fā)送子句的目標(biāo)對(duì)象；

3.功能層次模型

對(duì)軟件運(yùn)行的狀態(tài)進(jìn)行建模以后，開始進(jìn)行功能分解，構(gòu)建軟件功能層次模型。以發(fā)動(dòng)機(jī)中數(shù)字電子控制系統(tǒng)核心機(jī)軟件為例，軟件功能可以分解為發(fā)動(dòng)機(jī)控制和故障監(jiān)控功能，發(fā)動(dòng)機(jī)控制功能可以進(jìn)一步分解為燃油控制、導(dǎo)葉控制、開關(guān)控制。而故障監(jiān)控功能可以分解為信號(hào)自檢、回路監(jiān)控和消喘功能；

使用SafeTrip建模工具構(gòu)建功能層次模型時(shí)，在功能層次建模模塊中，逐個(gè)添加功能分解獲得的功能模塊，為每個(gè)功能模塊添加名稱、功能標(biāo)識(shí)。然后使用連接線連接父功能和子功能，連接方向?yàn)橛筛腹δ苤赶蜃庸δ堋?/p>

4.建立狀態(tài)功能關(guān)聯(lián)

功能分解完成后，需要建立功能與狀態(tài)的關(guān)聯(lián)關(guān)系，分解后的功能與狀態(tài)是多對(duì)多的關(guān)系，同一狀態(tài)中可能有多個(gè)功能并發(fā)執(zhí)行，同一功能可能出現(xiàn)在多個(gè)不同的狀態(tài)中，進(jìn)行功能狀態(tài)關(guān)聯(lián)后，允許檢查功能狀態(tài)組合等復(fù)雜邏輯特性引發(fā)的軟件失效。功能與狀態(tài)的關(guān)聯(lián)關(guān)系在軟件需求規(guī)格說明中描述，其中，要求的狀態(tài)和方式描述了軟件運(yùn)行時(shí)的狀態(tài)，CSCI能力需求描述了與狀態(tài)對(duì)應(yīng)的各個(gè)功能。SafeTrip提供了由狀態(tài)關(guān)聯(lián)功能和由功能關(guān)聯(lián)狀態(tài)兩種方式，具體構(gòu)建時(shí)按照軟件需求規(guī)格說明描述的關(guān)聯(lián)關(guān)系，通過鼠標(biāo)右鍵點(diǎn)擊狀態(tài)關(guān)聯(lián)軟件功能，也可以右鍵點(diǎn)擊功能關(guān)聯(lián)軟件狀態(tài)。

5.基于UML操作圖和OCL的形式化功能模型

采用UML和OCL對(duì)象約束語言對(duì)軟件功能進(jìn)行建模，實(shí)現(xiàn)對(duì)軟件內(nèi)部處理流程的形式化描述。為了進(jìn)行安全性分析，將功能模型拆分為軟件外部輸入接口(Input)-功能處理過程(Process)-外部輸出接口(Output)(簡寫為IPO)這三項(xiàng)需求元素，構(gòu)成了軟件運(yùn)行時(shí)的動(dòng)態(tài)失效鏈。失效鏈中的任何一個(gè)環(huán)節(jié)(即外部輸入接口、功能處理過程、外部輸出接口)出現(xiàn)故障，經(jīng)過失效鏈的傳遞，最終都有可能導(dǎo)致軟件發(fā)生失效，進(jìn)而對(duì)系統(tǒng)產(chǎn)生影響。

功能的外部輸入接口和外部輸出接口從接口數(shù)據(jù)元素和內(nèi)部數(shù)據(jù)元素中選取并進(jìn)行關(guān)聯(lián)。功能處理過程采用UML中的活動(dòng)圖表示，與狀態(tài)遷移模型中的狀態(tài)圖類似，采用OCL對(duì)象約束語言對(duì)活動(dòng)圖進(jìn)行擴(kuò)展：

指定對(duì)象實(shí)例。使用OCL表達(dá)式指定執(zhí)行某一活動(dòng)的對(duì)象實(shí)例，使用方法類似于狀態(tài)中的發(fā)送子句中的目標(biāo)對(duì)象；

決策條件和同步條件描述。使用方法類似于上文狀態(tài)圖中警戒條件；

指定實(shí)際參數(shù)。使用方法與狀態(tài)圖類似。

B安全性驗(yàn)證規(guī)則數(shù)據(jù)庫4，其功能是存儲(chǔ)安全性驗(yàn)證規(guī)則，并提供查詢、匹配、更新、維護(hù)的接口；

安全性驗(yàn)證規(guī)則數(shù)據(jù)庫4的構(gòu)建方式參照?qǐng)D5所示：

首先，需要搜集失效數(shù)據(jù)，數(shù)據(jù)來源主要包括型號(hào)軟件安全性分析項(xiàng)目中發(fā)現(xiàn)的軟件失效模式；軟件自測(cè)試、第三方測(cè)試、型號(hào)鑒定測(cè)評(píng)、定型測(cè)評(píng)過程中發(fā)現(xiàn)的軟件問題；在進(jìn)行軟件測(cè)試過程中，與軟件開發(fā)人員交流時(shí)獲取的研制過程中發(fā)現(xiàn)的需求缺陷；以及其他可獲取的事故案例數(shù)據(jù)，如外場試飛過程發(fā)現(xiàn)的問題，已經(jīng)發(fā)生的相關(guān)領(lǐng)域的典型事故案例(德國漢莎航空公司空難、美國火星探測(cè)器墜毀等)。

獲取失效數(shù)據(jù)后，需要進(jìn)行分析以找到引發(fā)問題的失效原因。接下來，以聯(lián)合航空751號(hào)班機(jī)空難為例，闡述獲取安全性驗(yàn)證規(guī)則的過程。此次空難原因是起飛前除冰不徹底，飛機(jī)積冰脫落導(dǎo)致引擎喘振，飛行員試圖減小油門從而減小引擎喘振，但飛機(jī)上裝有的自動(dòng)推力恢復(fù)系統(tǒng)，反而使推力增大加劇了事故嚴(yán)重程度。獲取失效現(xiàn)象后，首先需要對(duì)失效原因進(jìn)行總結(jié)歸納，挖掘失效原因中蘊(yùn)含的深層次失效機(jī)理，使得最終形成的安全性驗(yàn)證規(guī)則能夠應(yīng)用到各類型軟件的安全性需求分析工作中。經(jīng)過分析發(fā)現(xiàn)，問題的深層次原因是系統(tǒng)重啟狀態(tài)中的多個(gè)功能對(duì)同一個(gè)變量賦予不同的值，導(dǎo)致賦值沖突。接下來，對(duì)該失效機(jī)理進(jìn)一步擴(kuò)展，根據(jù)UML狀態(tài)圖可知，狀態(tài)圖中可以存在并發(fā)狀態(tài)，多個(gè)并發(fā)狀態(tài)中可能出現(xiàn)多個(gè)功能對(duì)同一個(gè)變量出現(xiàn)賦值沖突的情況，賦值沖突由單個(gè)狀態(tài)擴(kuò)展到整個(gè)系統(tǒng)運(yùn)行時(shí)的多個(gè)并發(fā)狀態(tài)。最終獲得如下安全性驗(yàn)證規(guī)則：“整個(gè)系統(tǒng)運(yùn)行過程中，存在多個(gè)功能同時(shí)對(duì)一個(gè)變量進(jìn)行輸出，導(dǎo)致賦值沖突”。使用上述方法積累安全性驗(yàn)證規(guī)則，其中部分規(guī)則如下：輸入接口數(shù)據(jù)元素的取值為有效區(qū)間外的異常值、輸出接口數(shù)據(jù)元素輸出數(shù)據(jù)速率大于總線傳輸速率、功能處理未覆蓋輸入接口數(shù)據(jù)元素的整個(gè)有效區(qū)間、同一個(gè)狀態(tài)的多個(gè)遷出條件同時(shí)滿足、狀態(tài)多個(gè)遷出轉(zhuǎn)移條件未覆蓋條件變量的完整的取值區(qū)間、狀態(tài)圖中存在不可達(dá)狀態(tài)、狀態(tài)圖中遷移前狀態(tài)和遷移后狀態(tài)對(duì)同一個(gè)變量賦予不同的值等。上述安全性驗(yàn)證規(guī)則中所蘊(yùn)含的失效可能引發(fā)系統(tǒng)危險(xiǎn)，是后續(xù)開展模型檢測(cè)和安全性測(cè)試的依據(jù)。

為了便于數(shù)據(jù)庫查詢、匹配、更新和維護(hù)，將分析得到的安全性驗(yàn)證規(guī)則進(jìn)行分類：分別是功能輸入接口失效、功能輸出接口失效、獨(dú)立功能失效、組合功能失效、狀態(tài)失效等。最終形成了安全性驗(yàn)證規(guī)則數(shù)據(jù)庫。同時(shí)，可以根據(jù)需要對(duì)所分析的業(yè)務(wù)領(lǐng)域中的對(duì)象，構(gòu)建系統(tǒng)層次樹，如飛機(jī)系統(tǒng)可以分為導(dǎo)航系統(tǒng)、飛控系統(tǒng)、液壓系統(tǒng)等，每個(gè)系統(tǒng)又可以進(jìn)一步分為子系統(tǒng)。最終，可以將安全性驗(yàn)證規(guī)則與具體的系統(tǒng)關(guān)聯(lián)，以便于查詢使用。

C形式化驗(yàn)證模塊5，分別與軟件需求建模模塊1和安全性驗(yàn)證規(guī)則數(shù)據(jù)庫4連接，由軟件需求建模模塊1向形式化驗(yàn)證模塊5傳輸軟件需求模型文件，由安全性驗(yàn)證規(guī)則數(shù)據(jù)庫4向形式化驗(yàn)證模塊5提供驗(yàn)證的依據(jù)，即安全性驗(yàn)證規(guī)則，該形式化驗(yàn)證模塊5的功能是基于安全性驗(yàn)證規(guī)則數(shù)據(jù)庫4中的安全性驗(yàn)證規(guī)則，對(duì)軟件需求建模模塊1形成的軟件需求模型文件進(jìn)行形式化驗(yàn)證，形成形式化驗(yàn)證結(jié)果；

形式化驗(yàn)證模塊5的構(gòu)建方式如下：

軟件安全性自動(dòng)分析的實(shí)現(xiàn)過程是針對(duì)每條安全性驗(yàn)證規(guī)則的語義，使用計(jì)算機(jī)程序編寫一個(gè)模型檢測(cè)算法。模型檢測(cè)算法根據(jù)安全性驗(yàn)證規(guī)則的語義對(duì)需求模型進(jìn)行遍歷，算法依據(jù)時(shí)序關(guān)系、判斷條件、轉(zhuǎn)移條件、取值有效區(qū)間等信息，對(duì)復(fù)雜的軟件需求模型進(jìn)行靜態(tài)掃描，找出安全性驗(yàn)證規(guī)則中指定的所有可能引發(fā)系統(tǒng)危險(xiǎn)的失效模式；

需求模型構(gòu)建過程中，對(duì)不同軟件內(nèi)外部行為描述的方法是一致的，所獲得的模型是采用的建模元素構(gòu)建的無歧義的形式化模型。安全性驗(yàn)證規(guī)則獲取的過程中，獲得的每條規(guī)則采用獨(dú)立的標(biāo)識(shí)，分析規(guī)則的語義也是無歧義的。以上兩點(diǎn)確保了實(shí)現(xiàn)模型檢測(cè)算法的可行性和算法的通用性；

接下來，以“整個(gè)系統(tǒng)運(yùn)行過程中，存在多個(gè)功能同時(shí)對(duì)一個(gè)變量進(jìn)行輸出，導(dǎo)致賦值沖突”分析規(guī)則為例，給出模型檢測(cè)算法的實(shí)現(xiàn)方法描述以及實(shí)現(xiàn)算法的偽代碼；

模型檢測(cè)算法描述：

第一步，通過遍歷狀態(tài)模型，找到系統(tǒng)中并發(fā)的狀態(tài)，系統(tǒng)中可能存在多組并發(fā)狀態(tài)，需要對(duì)每一組施加以下算法；

第二步，通過需求模型中的狀態(tài)功能關(guān)聯(lián)關(guān)系，遍歷出每個(gè)狀態(tài)下同時(shí)運(yùn)行的功能；

第三步，通過功能模型，找到每個(gè)功能的輸入輸出接口數(shù)據(jù)元素；

第四步，檢查是否存在多個(gè)功能具有相同的輸出接口數(shù)據(jù)元素；

第五步，對(duì)具有相同輸出接口數(shù)據(jù)元素的功能，檢查對(duì)輸出接口數(shù)據(jù)元素的賦值操作是否可能同時(shí)發(fā)生。即檢查多個(gè)功能模型中，從活動(dòng)圖起點(diǎn)到接口賦值操作所在活動(dòng)的路徑上的決策條件是否可能同時(shí)發(fā)生。偽代碼如附圖6所示。

在模型檢測(cè)過程中，需要對(duì)發(fā)現(xiàn)軟件失效的安全性驗(yàn)證規(guī)則以及產(chǎn)生失效的狀態(tài)和功能進(jìn)行存儲(chǔ)，安全性測(cè)試用例生成時(shí)需要根據(jù)這些安全性驗(yàn)證規(guī)則需要生成有針對(duì)性的測(cè)試用例，進(jìn)一步確認(rèn)模型是否進(jìn)行了有效修改，避免失效的出現(xiàn)。

D安全性測(cè)試模塊(6)，分別與軟件需求建模模塊1、安全性驗(yàn)證規(guī)則數(shù)據(jù)庫4和形式化驗(yàn)證模塊5相連接，由軟件需求建模模塊1向安全性測(cè)試模塊(6)提供軟件需求模型文件，由安全性驗(yàn)證規(guī)則數(shù)據(jù)庫4向安全性測(cè)試模塊(6)提供安全性驗(yàn)證規(guī)則，由形式化驗(yàn)證模塊5向安全性測(cè)試模塊(6)提供形式化驗(yàn)證結(jié)果，該安全性測(cè)試模塊(6)的功能是根據(jù)的軟件需求模型文件和形式化驗(yàn)證結(jié)果以及安全性驗(yàn)證規(guī)則生成測(cè)試用例并通過翻譯進(jìn)行用例格式轉(zhuǎn)換，以適應(yīng)不同測(cè)試執(zhí)行平臺(tái)的需要，該安全性測(cè)試模塊(6)包括：

測(cè)試用例生成模塊(7)，其功能是生成XML格式的測(cè)試用例；

測(cè)試用例翻譯模塊(8)，其功能接收測(cè)試用例生成模塊(7)生成的XML格式的測(cè)試用例，并將其翻譯成其它格式的測(cè)試用例，其它格式包括自然語言格式、腳本語言格式。

測(cè)試用例生成模塊(7)的實(shí)現(xiàn)方式為：

根據(jù)上文的需求建模過程可以看出，本發(fā)明技術(shù)方案構(gòu)建的安全性自動(dòng)化驗(yàn)證系統(tǒng)采用狀態(tài)圖描述系統(tǒng)生命周期，表現(xiàn)系統(tǒng)所具有的各種狀態(tài)和狀態(tài)遷移，以及影響系統(tǒng)狀態(tài)的事件，主要描述了系統(tǒng)從一個(gè)狀態(tài)到另一個(gè)狀態(tài)變化遷移的控制流。每個(gè)狀態(tài)中的業(yè)務(wù)邏輯采用活動(dòng)圖進(jìn)行描述，一個(gè)狀態(tài)中可能存在多個(gè)功能，而狀態(tài)圖可以分為區(qū)域，而區(qū)域又包括退出或者當(dāng)前執(zhí)行的子狀態(tài)。說明組合狀態(tài)在某一時(shí)刻可以同時(shí)達(dá)到多個(gè)子狀態(tài)。將狀態(tài)和功能進(jìn)行關(guān)聯(lián)后，形成的最終的模型圖。附圖7是一個(gè)簡單的需求模型圖，首先，使用狀態(tài)圖描述了系統(tǒng)各個(gè)狀態(tài)，包括狀態(tài)1和狀態(tài)2，其中，狀態(tài)1是一個(gè)組合狀態(tài)，包含兩個(gè)并發(fā)的子狀態(tài)，分別是狀態(tài)1-1和狀態(tài)1-2。其中，每個(gè)狀態(tài)關(guān)聯(lián)一個(gè)或多個(gè)使用活動(dòng)圖描述的功能，圖中狀態(tài)1-1關(guān)聯(lián)了功能1和功能2，狀態(tài)1-2關(guān)聯(lián)了功能3，狀態(tài)2關(guān)聯(lián)了功能4。

生成安全性測(cè)試用例時(shí)，結(jié)合了基于狀態(tài)圖和活動(dòng)圖的測(cè)試用例方法，安全性測(cè)試用例包括兩類，分別是通用的安全性測(cè)試用例和基于安全性驗(yàn)證規(guī)則的有針對(duì)的安全性測(cè)試用例。

通用安全性測(cè)試用例的生成方法：首先，進(jìn)行狀態(tài)測(cè)試時(shí)，采用基于狀態(tài)圖生成方法，首先將具有層次結(jié)構(gòu)的狀態(tài)圖轉(zhuǎn)換為單層狀態(tài)圖，然后使用廣度優(yōu)先遍歷算法遍歷整個(gè)狀態(tài)圖，確保每個(gè)狀態(tài)被遍歷，這樣生成了多個(gè)測(cè)試場景。每個(gè)狀態(tài)可以作為一個(gè)測(cè)試場景，狀態(tài)中關(guān)聯(lián)的多個(gè)功能的活動(dòng)圖表示此場景的所有的被測(cè)的操作序列。每個(gè)功能的操作序列就是一個(gè)測(cè)試案例。接下來采用基于活動(dòng)圖的測(cè)試用例生成方法，生成安全性測(cè)試用例。使用上述方法生成了通用的安全性測(cè)試用例。

基于安全性驗(yàn)證規(guī)則的安全性測(cè)試用例生成方法：首先，步驟三中在進(jìn)行模型檢測(cè)時(shí)，存儲(chǔ)了引發(fā)軟件失效的安全性驗(yàn)證規(guī)則以及所在的狀態(tài)及功能。生成用例時(shí)，首先構(gòu)造預(yù)置條件到達(dá)目標(biāo)狀態(tài)，然后根據(jù)安全性驗(yàn)證規(guī)則的含義，遍歷活動(dòng)圖產(chǎn)生測(cè)試用例。

測(cè)試用例翻譯模塊(8)的實(shí)現(xiàn)方式為：

通過安全性測(cè)試用例生成模塊，生成了XML格式的測(cè)試用例，安全性用例翻譯模塊的工作主要是進(jìn)行格式替換。狀態(tài)遷移模型和活動(dòng)圖中遷移條件均采用接口數(shù)據(jù)元素和內(nèi)部數(shù)據(jù)元素進(jìn)行描述。因而，生成的XML格式用例中的操作對(duì)象也是接口數(shù)據(jù)元素和內(nèi)部數(shù)據(jù)元素。由于在需求建模時(shí)每個(gè)接口數(shù)據(jù)元素和內(nèi)部數(shù)據(jù)元素都有兩類名稱，分別是人工可識(shí)別的變量名和英文變量名，且英文變量名符合腳本語言變量命名規(guī)范。這就為用例格式轉(zhuǎn)換提供可可行的方案。測(cè)試用例包含多個(gè)步驟，每個(gè)步驟包含兩個(gè)核心要素，分別是操作時(shí)間和此時(shí)刻對(duì)變量的操作。安全性用例翻譯模塊的工作是按照目標(biāo)格式的要求，對(duì)XML用例中的時(shí)間和變量操作進(jìn)行格式替換。翻譯成人工執(zhí)行的用例時(shí)，將變量名替換為人工可識(shí)別的變量名，翻譯成測(cè)試腳本格式的用例時(shí)，將變量名替換為英文變量名。翻譯成其它格式的XML用例時(shí)，保留原變量名，對(duì)用例格式重新進(jìn)行組織即可。

上述嵌入式軟件安全性自動(dòng)化驗(yàn)證系統(tǒng)的驗(yàn)證方法的步驟如下：

SafeTrip建模工具、形式化驗(yàn)證模塊以及安全性測(cè)試模塊安裝部署在同一臺(tái)Windows 7系統(tǒng)的PC上，安全性驗(yàn)證規(guī)則數(shù)據(jù)庫實(shí)現(xiàn)時(shí)采用Oracle數(shù)據(jù)庫，部署在單獨(dú)的數(shù)據(jù)服務(wù)器上，PC與數(shù)據(jù)服務(wù)器采用網(wǎng)線連接。

步驟一、打開PC機(jī)的SafeTrip建模軟件，根據(jù)上文所述的ICD建模步驟，構(gòu)建ICD模型，形成ICD模型數(shù)據(jù)；

步驟二、在ICD模型數(shù)據(jù)的基礎(chǔ)上，采用OCL形式化語言描述待驗(yàn)證軟件的內(nèi)部行為，包括狀態(tài)遷移及功能邏輯，建立軟件需求模型文件；

步驟三、打開數(shù)據(jù)服務(wù)器，將已有的軟件失效原因，歸納形成安全性驗(yàn)證規(guī)則，存放在Oracle數(shù)據(jù)庫中；

步驟四、在形式化驗(yàn)證模塊中，導(dǎo)入軟件需求模型文件和Oracle數(shù)據(jù)庫中的安全性驗(yàn)證規(guī)則，對(duì)軟件需求模型文件進(jìn)行形式化驗(yàn)證，獲得形式化驗(yàn)證結(jié)果；

步驟五、打開測(cè)試用例生成模塊，導(dǎo)入軟件需求模型文件、形式化驗(yàn)證結(jié)果以及Oracle數(shù)據(jù)庫中的安全性驗(yàn)證規(guī)則，生成XML格式的安全性測(cè)試用例；

步驟六、對(duì)XML格式的安全性測(cè)試用例進(jìn)行格式轉(zhuǎn)換，生成測(cè)試執(zhí)行時(shí)所需要的用例格式。包括人工執(zhí)行所需要的自然語言用例、基于測(cè)試腳本的測(cè)試工具平臺(tái)所需要的腳本語言格式用例、嵌入式仿真自動(dòng)化測(cè)試平臺(tái)需要的其他XML格式用例以及其他的格式用例。

步驟七、執(zhí)行步驟六中生成的測(cè)試用例，對(duì)被驗(yàn)證軟件進(jìn)行軟件測(cè)試。