軟體形式化方法概述

來源:互聯網
上載者:User

       友情提示:本文理論性和專業性較強,如果木有接觸過該領域,讀起來可能會有一點點吃力,!本文是Sunny結合多份資料綜合整理而成,有點淩亂,見諒!

 

       軟體形式化方法(Formal Method)在軟體開發中一直都受到多方面的爭議。持肯定態度的擁護者認為形式化方法會引起軟體開發的革命,另一些持否定態度者則懷疑甚至反對將數學引入軟體開發過程中。

       形式化開發方法的一些爭議或缺陷主要體現在:

       (1) 形式化方法中所包含的數學理論,限制了大多數程式設計人員的學習和使用;

       (2) 認為採用形式化方法會延誤項目開發週期、增加開發費用

       (3) 許多流行的形式化方法對於較小規模的項目是有效,但卻很難應用於一些大型系統

       (4) 形式化方法不能確保開發出完全正確的軟體;

       (5) 缺乏對軟體生命週期內各個階段提供全面支援的形式化方法;

       等。

 

      從廣義上講,形式化方法是藉助數學的方法來解決軟體工程領域的問題,主要包括建立精確的數學模型以及對模型的分析活動。狹義的講,形式化方法是運用形式化語言,進行形式化的規格描述、模型推理和驗證的方法。就形式化建模而言,形式化表示必須包含一組定義其文法語義的形式化規則。這些規則可用於分析給定的運算式是否符合文法規定,或證明該運算式具有某種性質。

 

       關於形式化方法:悲觀者的角度

       形式化方法是為數學家準備的

       形式化方法僅供從事形式化研究的人使用

       從事形式化研究的人僅使用形式化方法

       形式化方法的運用將延緩軟體開發進度

       形式化方法的運用將提高軟體開發成本

       形式化方法僅應用於開發安全要求極高的系統

       形式化方法僅被用於無關緊要的系統,且缺少工具支援

 

       關於形式化方法:樂觀者的角度      

       運用形式化方法將開發出完美的軟體

       形式化方法可以替換傳統的軟體工程方法

 

      形式化方法的出發點是數學邏輯方法,其目的是開發可靠的軟體產品。從軟體開發來講,形式化方法目前並非軟體開發的主流。從軟體發展看,早期的軟體是用於數值計算,程式語言側重於函數和演算法的描述,後來資料庫的應用和資料結構逐漸層得重要。現在的軟體更為複雜,因此,對象、組件、介面、通訊、開放等成為非常重要的概念。從軟體工程方法來講,有一套描述這些概念的辦法,比如說用圖形、表格、邏輯、自然語言等,交叉使用以描述一個系統的各個方面。因此換一個角度來考慮,我們也可以以目前常用的軟體開發方法為出發點,研究怎樣將這些方法形式化,使軟體系統的描述精確化,以減少可能的誤解所帶來的問題;或以目前常用的軟體開發過程為出發點,研究怎樣在軟體開發過程中增加一些形式化方法的應用,以提高軟體的可靠性。

 

       形式化方法可以分為形式化描述和建立在形式化描述基礎之上的形式化開發。形式化的描述就是用形式化的語言(具有嚴格的文法語義定義的語言)做描述。形式化的軟體開發,就是用形式化的語言來描述軟體需求和特徵,並且通過推理驗證來保證最終的軟體產品是否滿足這些需求和具備這些特徵。這樣的驗證當然得建立在嚴格的文法語義的基礎之上的。在實際應用中,這是不容易做到的。形式化方法研究的目的就是希望能夠提供更好的理論、方法和工具,擴大形式化方法的應用範圍和使用價值。

 

       形式化方法的意義在於它能協助發現其它方法不容易發現的系統描述的不一致、不明確或不完整,有助於增加軟體開發人員對系統的理解,因此形式化方法是提高軟體系統,特別是Safety-Critical系統的安全性與可靠性的重要手段。最早的形式化方法是邏輯與邏輯推理,它的目標是使推理機械化。從廣義上講,這一目標受到許多挫折,比如說邏輯系統的不完備性(incompleteness)、邏輯系統的不可判定性(undecidability)、自動推理的難處理性(intractability)。但是在一些實際應用上,邏輯方法和自動推理還是起著非常大的作用。

 

       形式化方法在軟體開發中能夠起到的作用是多方面的。首先是對軟體需求的描述,軟體需求的描述是軟體開發的基礎。比如說一般非形式化的描述很可能導致描述的不明確和不一致,如果描述的不明確和不一致將導致設計、編程的錯誤,將來的修改所要付出的代價就非常大了,如果導致的錯誤沒有被發現,則影響程式的可靠和使用。形式化方法則要求描述的明確性,而描述的不一致性也就相對易於發現。其次是對軟體設計的描述。軟體設計的描述和軟體需求的描述一樣重要,形式化方法的優點對於軟體需求的描述同樣適用於軟體設計的描述,另外由於有了軟體需求的形式化描述,我們可以檢驗軟體的設計是否滿足軟體的要求。對於編程來講,我們可以考慮自動代碼產生。對於一些簡單的系統,形式化的描述有可能直接轉換成可執行程式,這就簡化了軟體開發過程,節約了資源和減少了出錯的可能性。另外,形式化方法可以用於程式的驗證,以保證程式的正確性。對於測試來講,形式化方法可用於測試案例的自動產生,這可以節約許多時間和在一定程度上保證測試案例的覆蓋率。

 

 

       形式化方法原則上就是用數學與邏輯的方法描述和驗證軟體。從描述上講,一方面是系統或程式的描述,另一方面是性質的描述。這些可以用一種或多種語言來描述。這些語言套件括命題邏輯,一階邏輯,高階邏輯,代數,狀態機器,並髮狀態機,自動機,計算樹邏輯,線性時序邏輯,進程代數, π-演算, μ-演算,特殊的程式語言,以及程式語言的子集等。從驗證來講,主要有兩類方法,一類是以邏輯推理為基礎,另一類則以窮盡搜尋為基礎。邏輯推理有 natural deduction, sequent calculus, resolution 以及Hoare-logic 等方法,窮盡搜尋方法統稱為模型檢測。這類方法與系統或程式以及系統性質的表示有很大的關係,比如說符號模型檢測,其基本原理是用命題邏輯公式表示狀態轉換關係,用不動點演算法計算狀態的可達性以及這些狀態是否滿足某些性質。

 

       形式化方法的應用在電路設計和協議設計上都取得了很大的成績,但是對於軟體來講還有很多沒有解決的問題。軟體的描述要比電路和協議複雜,一個軟體描述所包含的狀態空間通常來講可以是無限的,因此驗證的難度很大。邏輯推理的不足之處在於推理的難度,對於稍微複雜的系統,自動化的推理就難以勝任。人為的推理有很大的缺點,除了費時費力外,比如說一個定理推不出來,並不能說明這個定理不成立,很可能是推理方法和策略應用不當。模型檢測的好處在於它有全自動化的檢測過程,並且如果一個性質不滿足,它能給出這個性質不滿足的理由,我們即可據此對我們的系統描述進行改進。模型檢測的困難首先是它所能檢測的是有限狀態模型。這樣對於一般軟體來講,需要有一個從任意狀態到有限狀態的建模過程,並且這樣的一個模型的狀態空間會面臨組合爆炸的問題。

 

       形式驗證一般被稱為形式化驗證方法,是相對於傳統的驗證(類比、模擬和測試)而言的。形式化驗證方法的主要思路就是使用數學的公式、定理和系統來驗證一個系統的正確性等。目前的形式化驗證方法可以用於驗證硬體系統、軟體系統和其他系統,而且形式化驗證的技術目前也已經發展到不但可以驗證系統的功能正確性(有沒有錯誤),而且可以驗證系統的效能指標(功耗、散熱、延遲等等)。形式化驗證方法主要可以分為三種:定理證明、模型檢測和等價性驗證。定理證明的基本原理是選定一個數學邏輯體系,並用其中的公式來描述(如軟、硬體)系統和系統性質刻畫,然後在一定的數學邏輯(如hol邏輯)體系中依據此體系的公理、定理、推導規則和系統描述公式,看看能不能推匯出系統的性質刻畫公式,如果可以的話驗證成功。模型檢測的原理比較簡單但是非常實用,它將(如軟、硬體)系統建模成有限狀態系統(一般成為keripke結構),系統的性質刻畫用時序邏輯公式表示(CTL,LTL等),而後在此模型上來驗證性質刻畫的正確性,模型檢測於定理證明相比是有很大優勢的,他可以全自動地驗證,不需要人工幹預,而定理證明則在一些關鍵推導路徑中需要數學家控制。還有一種是等價性驗證,等價性驗證其實是一種半形式話的技術,同前兩種驗證正確性的技術不同,它驗證的是設計的一致性,即不同設計階段的設計是否功能相同,這種技術中一般採用符號的方法和增量的方法,而且由於這種方法和硬體電路緊密結合,所以電路驗證的一些傳統方法也大量應用於此中方法中來,比如ATPG技術等。如大家使用的Synopsys的Formality本質上就是一個等價性驗證器。形式化驗證是非常有用的,只是國內作這一行的人太少。大家可以看看Synopsys和Cadence兩家公司,它們都是從形式化驗證起家的,然後轉到目前流行的將設計和驗證統一在一起,即“設計驗證”領域。

    

   

       軟體形式化方法研究內容:
    形式化語言(形式化描述、形式規約):怎樣描述軟體系統及其行為模式;更好地刻畫軟體系統的性質,比如說,通訊、分布、開放、移動;各種語言的應用、比較,語言與語言之間的轉換;開發相應的軟體工具。

    形式化驗證(形式驗證):怎樣驗證軟體系統符合給定的行為模式;更有效地驗證軟體系統的性質,比如說,自動化、速度快、記憶體需求少;各種方法的應用、比較;開發相應的軟體工具。

 

    具體來說,軟體形式化方法包括以下幾個主要研究方向:

    (1) 基礎概念:複合、抽象、重用模型、數學理論組合、資料結構及演算法。需要對如何複合方法、複合規格、複合模型、複合理論、複合證明等進一步的理解;需要開發出將整體特性分解為易於驗證的局部特性的有效方法;實際系統在規格和驗證之前都要進行某種程度上的抽象,需要研究出評判抽象層次合理與否的方法;重用不僅可以提高開發效率,而且可以提高軟體的可靠性,應當研究可重用模型和理論;許多安全關鍵反應式系統是數字和類比混合的,需要連續和離散兩個範疇內數學基礎支撐的混雜系統理論和技術支撐;大規模、複雜軟體中搜尋空間是巨大的,需要研究出新的資料結構和演算法。

    (2) 形式化方法與物件導向方法的結合:這已經成為軟體工程領域的一個研究熱點,例如:Statecharts、Petri網、Z語言、VDM等,以及與物件導向方法結合產生的Objectcharts、物件導向Petri網、Object-Z、Z++、VDM++等。這方面的研究體現在兩個方面:利用物件導向結構來提高形式符號的表達能力;使用形式化方法來分析物件導向的語義或提高這些標記符號的表達對象概念的能力。形式化方法和其他傳統軟體開發方法相結合以達到取長補短的目的,也是值得研究的課題。

    (3) 工具開發:具有良好使用者介面、易於學習和操作簡單的形式化方法支撐工具,對於形式化方法的推廣應用是大有裨益的。追求通用的完善的形式化方法及其支撐工具是不現實的,側重於如下某一個或幾個方面準則的特色方法和工具是未來研究的重點。這些準則包括:一旦開始使用之後儘早得到明顯的效益;效益隨著開發人員的瞭解深入和熟練而增加;單一規格可以在軟體開發生命週期的多個階段取得效益;能和其他通用程式設計語言或方法互動使用;工具應當像編譯器那樣便於使用、輸出,也易於閱讀;概念和工具應當易於入門和學習掌握;軟體特性分析有所側重;支援漸進軟體開發,允許部分規格和驗證。此外,特定問題域的形式化方法及其工具研究也是非常重要的。

【作者:劉偉   http://blog.csdn.net/lovelion

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.