1.4 軟件工程方法論

1.4.1 軟件工程方法論的提出

長期以來，人們將軟件開發方法與軟件生命周期模型，甚至軟件開發方法與軟件過程改進模型混為一談，因而誤認為軟件生命周期模型或軟件過程改進模型就是軟件開發方法。例如，將迭代模型RUP（Rational Unified Process）和過程改善模型CMMI（Capability Maturity Model Integration）誤認為是軟件開發方法或軟件工程方法論。事實上，軟件開發方法與軟件生命周期模型是不同的，軟件開發方法與軟件過程改進模型就更不相同了。軟件開發方法學來自程序設計語言方法學，而軟件生命周期模型或軟件過程改進模型與程序設計語言方法學無關。

軟件生命周期模型是指在整個軟件生命周期中，軟件開發過程應遵循的開發路線圖。或者說，軟件生命周期模型是軟件開發全部過程、活動和任務的結構框架。

例如，瀑布模型、增量模型、螺旋模型、噴泉模型、XP模型、原型模型和RUP迭代模型，它們都有各自清晰的開發路線圖，規定了各自的開發過程、活動和任務的結構框架。這些軟件生命周期模型，將在后續的有關章節中詳細論述。

軟件開發方法是指在軟件開發路線圖中，開發人員對軟件需求、設計、實現、維護所采用的開發思想、開發技術、描述方法、支持工具等。

在軟件工程方法學方面，大體可分為程序設計方法學和軟件開發方法學，前者是關于小規模程序的設計方法學，后者是關于大規模軟件的開發方法學。

例如，在程序設計方法學中，最基本的方法有：面向過程程序設計方法，面向對象程序設計方法，面向元數據（Meta-data）程序設計方法。在軟件開發方法學中，最基本的方法有：面向過程方法、面向對象方法、面向元數據方法、形式化方法。它們都是軟件開發方法，都有各自的開發思想、開發技術、描述方法、支持工具等。

軟件工程中軟件開發方法的集合，稱為軟件工程方法論。

現在的問題是：到目前為止，軟件工程方法論中，到底包括哪幾種最基本的軟件開發方法？這幾種開發方法，到底存在什么關系？下面將回答這些問題。

1.4.2 面向過程的方法

面向過程的方法（Procedure-Oriented Method），來自于面向過程的程序設計語言，如匯編語言、C語言。面向過程方法包括面向過程的需求分析、設計、編程、測試、維護、管理等。

面向過程方法，習慣上稱為傳統軟件工程開發方法，或結構化方法。它包括結構化分析、結構化設計、結構化編程、結構化測試、結構化維護。面向過程方法，有時又稱面向功能的方法，即面向功能分析、設計、編程、測試、維護。由此可見，面向過程方法、面向功能方法、結構化方法，三者是同一個意思。

在軟件工程發展史上，曾經出現過的面向過程方法有：

（1）面向結構化數據系統的開發方法DSSD（Data Structured Systems Development）；

（2）面向可維護性和可靠性設計的Parnas方法；

（3）面向數據結構設計的Jackson方法；

（4）面向問題設計的PAM方法；

（5）面向數據流方法。

上述5種方法的詳細內容，利用百度或Google搜索引擎，都可以在網上查到。但是，不管在方法名字上如何稱呼，這5 種方法在宏觀上都屬于面向過程方法，支持這些方法的是面向過程的結構化編程語言。

面向過程方法設計中強調模塊化思想，采用“自頂向下，逐步求精”的技術對系統進行劃分，分解和抽象是它的兩個基本手段。面向過程方法編程時采用單入口單出口的控制結構，并且只包含順序、選擇和循環三種結構，目標之一是使程序的控制流程線性化，即程序的動態執行順序符合靜態書寫結構。

在面向過程的5種具體方法中，面向數據流方法最具有代表性。

面向數據流的設計方法，把數據流圖映射成軟件結構，數據流圖的類型決定了映射方法，數據流圖DFD（Data Flow Diagram）可以分為變換型數據流圖和事務型數據流圖。

（1）具有明顯的輸入、變換（加工）和輸出界面的數據流圖稱為變換型數據流圖。

（2）數據沿輸入通路到達一個處理模塊，這個處理模塊根據輸入數據的類型在若干動作序列中選出一個來執行，這類數據流圖稱為事務型數據流圖，并且稱這個模塊為事務中心。它完成如下任務：接收輸入數據；分析數據并確定數據類型；根據數據類型選取一條活動通路。

面向數據流的方法，在本書的后續章節中還會有進一步的介紹。

軟件的基礎是程序，沒有程序就沒有軟件，也就沒有軟件工程方法。對于軟件行業來說，某一種軟件工程方法往往來自于某一類程序設計語言。面向過程的方法，來自于20世紀60～70年代流行的面向過程的程序設計語言，如ALGOL，PASCAL，BASIC，FORTRAN，COBOL，C語言等，這些語言的特點是：用“順序、選擇（if-then-else）、循環（do-while或do-until）”三種基本結構來組織程序編制，實現設計目標。面向過程方法開始于20世紀60年代，成熟于70年代，盛行于80年代。該方法在國內曾經十分流行，大量應用，非常普及。

面向過程方法的優點是：以處理流程為基礎，簡單實用。其缺點是：只注重過程化信息，忽略了信息的層面關系及相互聯系。它企圖使用簡單的時序過程方法（順序、分支、循環三種結構），來描述關系復雜（隨機）的信息世界，因而對于關系復雜的信息系統來說，其描述能力不強，最后可能導致軟件設計、開發和維護陷入困難。

自從面向對象方法出現之后，在許多領域，面向過程方法逐漸被表述能力更強的面向對象方法所取代。當前，面向過程方法主要用在過程式的程序設計中，如對象方法（函數）、科學計算、實時跟蹤和實時控制的實現。

【例1-4】 面向過程方法在軍事領域的實時跟蹤監控系統中有很好的應用。如我方偵察衛星發射后其飛行軌跡的捕獲、測量、跟蹤和預報，導彈防御系統中敵方導彈發射后飛行軌跡的捕獲、測量、跟蹤和預報，其軟件系統都是采用面向過程的方法設計和實現的。使用面向過程的方法，系統的執行路徑可由系統自動控制，也就是程序自動控制，這是一切自動控制與跟蹤系統所必需的。

1.4.3 面向對象的方法

面向對象的方法（Object-Oriented Method），在不少教材中稱為現代軟件工程開發方法。該方法包括面向對象的需求分析、設計、編程、測試、維護、管理等。面向對象方法是一種運用對象、類、消息傳遞、繼承、封裝、聚合、多態性等概念來構造軟件系統的軟件開發方法。

面向對象方法的特點是，將現實世界的事物（問題域）直接映射到對象。分析設計時由對象抽象出類（Class），程序運行時由類還原到對象（Object）。

面向對象方法，源于20世紀80代年開始流行的面向對象的程序設計語言，如Java，C++，Delphi，Visual Basic語言等。面向對象方法的基本特點是，將對象的屬性和方法（即數據和操作）封裝起來，形成信息系統的基本執行單位，再利用對象的繼承特征，由基本執行單位派生出其他執行單位，從而產生許多新的對象。眾多的離散對象通過事件或消息連接起來，就形成了軟件系統。20 世紀80 年代末，微軟視窗操作系統的出現，使它產生了爆炸性的效果，大大加速了它的發展進程。90 年代中期，UML（Unified Modeling Language）和Rose（Rational object-oriented system engineering）的產生，標志著它逐步走向了成熟，并且開始普及。21世紀初，面向對象的兩類開發平臺是．Net平臺和J2EE平臺。

面向對象方法，實質上是面向功能方法在新形勢下（由功能重用發展到代碼重用）的回歸與再現，是在一種高層次上（代碼級）新的面向功能的方法論，它設計的“基本功能對象（類或構件）”，不僅包括屬性（數據），而且包括與屬性有關的功能（或方法，如增加、修改、移動、放大、縮小、刪除、選擇、計算、查找、排序、打開、關閉、存盤、顯示和打印等）。它不但將屬性與功能融為一體，而且對象之間可以繼承、派生以及通信。因此，面向對象設計，是一種新的、復雜的、動態的、高層次的面向功能設計。它的基本單元是對象，對象封裝了與其有關的數據結構及相應層的處理方法，從而實現了由問題空間到解析空間的映射。一句話，面向對象方法也是從功能入手，將功能與方法當作分析、設計、實現的出發點和最終歸宿。

面向對象方法的優點是：能描述無窮的信息世界，同時易于維護。其缺點是：對于習慣于面向過程方法的人，較難掌握。

面向對象方法是當前軟件界關注的重點，是軟件工程方法論的主流。面向對象的概念和應用已超越了程序設計和軟件開發，擴展到更寬的范圍。如交互式界面、應用結構、應用平臺、分布式系統、網絡管理結構、CAD技術、人工智能等領域。

業界流傳的面向方面的方法、面向主體的方法和面向架構的方法，都是面向對象方法的具體應用實例。

【例1-5】 互聯網上各種網站的設計、實現和維護，都是面向對象方法的案例。游戲軟件的設計、實現和維護，更是面向對象方法的杰作。

【例1-6】 面向對象方法在電子商務中的應用有：網站前臺界面的制作，信息的發布和處理，用戶在網上瀏覽和錄入信息等應用軟件都是利用面向對象的方法設計與實現的。個人網頁的制作也是面向對象方法的應用例子。窗口操作系統與互聯網的出現，為面向對象方法開辟了無限的前景。

1.4.4 面向元數據的方法

這里講的面向元數據的方法（Meta-data Oriented Method），既不是傳統軟件工程中的“面向數據流”方法，也不是傳統意義上的面向數據結構的Jackson方法，它們都是面向過程的方法，而且這兩種方法都出現在關系數據庫管理系統RDBMS（Relational Database Management System）成熟之前。所以這里講的面向元數據方法，就是面向meta-data的方法，它與面向過程方法截然不同。

面向元數據方法來源于面向元數據的程序設計思想，即關系數據庫語言的程序設計思想。當關系數據庫管理系統和數據庫服務器出現之后，面向元數據方法才被人們所發現與重視。當數據庫設計的CASE工具Power Designer、Oracle Designer和ER win出現之后，面向元數據設計方法才開始流行。

元數據（Meta-Data）是關于數據的數據，組織數據的數據，管理數據的數據。

這里的元數據，泛指一切組織數據的數據，如類的名稱、屬性和方法，實體的名稱、屬性和關聯，數據庫中的表名、字段名、主鍵、外鍵、索引、視圖，數據結構中存儲數據的框架等。但是，我們研究的重點，是指數據庫中的元數據。

面向元數據的方法，就是在軟件需求分析、設計、實現、測試、維護過程中，均以元數據為中心的軟件工程方法。

例如，數據庫概念設計中的實體名和屬性名，數據庫物理設計中的表名和字段名，它們就是元數據。而具體的某一個特定的實例，它們不是元數據，而是對象或記錄，是被元數據組織的數據。關系數據庫管理系統自帶的程序設計語言，提供了強大的面向關系表中數據的編程能力，典型的例子就是編寫存儲過程（Stored Procedure）和觸發器（Trigger）。Oracle數據庫管理系統自帶的編程工具Developer 2000，是一個面向元數據的編程工具。Oracle Designer加上Developer 2000，構成了一個完整的面向元數據的信息系統開發環境。

面向元數據方法包括面向元數據的需求分析、設計、編程、測試、維護。

（1）面向元數據的需求分析，是在需求分析時，找出信息系統所有的元數據，使其完全滿足信息系統對數據存儲、處理、查詢、傳輸、輸出的要求。也就是說，有了這些元數據，信息系統中的一切原始數據不但都被組織起來，而且能完全派生出系統中的一切輸出數據。

（2）面向元數據設計，是利用需求分析獲得的元數據，采用面向元數據的CASE工具，設計出信息系統的概念數據模型CDM（Conceptual Data Model）和物理數據模型PDM（Physics Data Model），以及從原始數據到輸出數據的所有算法與視圖。

（3）面向元數據編程，是在物理數據模型PDM的基礎上，根據信息系統的功能、性能、接口和業務規則，建立數據庫表和視圖，再利用數據庫編程語言，編寫出存儲過程和觸發器。

（4）面向元數據測試，是對數據庫表初始化并加載之后，運行相關的存儲過程和觸發器，測試信息系統的各種功能需求與性能指標。

（5）面向元數據維護，是對數據庫表中的記錄進行統計、分析、審計、復制、備份、恢復，甚至對表結構及視圖結構，進行必要的調整。

事實上，近20多年來，面向元數據方法已經是建設信息系統、數據庫、數據倉庫和業務基礎平臺的基本方法。概括起來，面向元數據的方法要點是：

（1）數據（Data）位于企業信息系統的中心。信息系統就是對數據的輸入、處理、傳輸、查詢和輸出。

（2）只要企業的業務方向和內容不變，企業的元數據就是穩定的，由元數據構成的數據模型（Data Model）也是穩定的。

（3）對元數據的處理方法是可變的。用不變的元數據支持可變的處理方法，即以不變應萬變，這是企業信息系統工程的基本原理。

（4）信息系統的核心是數據模型。數據模型包括概念數據模型CDM和物理數據模型PDM。數據模型的表示形式是E-R圖，它用CASE工具設計。例如，Power Designer，Oracle Designer或ER win，它們不但具有正向設計功能，而且具有逆向分析功能，這樣才能實現快速原型法。

（5）信息系統的編程方法主要是面向對象（除數據庫服務器層面上），其次才是面向元數據（在數據庫服務器層面上）和面向過程（在實現存儲過程和對象方法中）。

（6）用戶自始至終參與信息系統的分析、設計、實現與維護。

面向元數據方法的優點是：通俗易懂，特別適合信息系統中數據層（數據庫服務器）上的設計與實現。其缺點是：只能實現二維表格，不能實現窗口界面。

面向元數據方法，與關系數據庫管理系統緊密地捆綁在一起，只要面向對象數據庫不能完全替代關系數據庫，這種方法就不會終結。目前數據庫管理系統的發展趨勢是：在關系型數據庫的基礎上，將面向對象的某些特性（如繼承）添加上去，稱為“對象-關系型數據庫”，但本質上仍然是一個關系型數據庫。

【例1-7】 面向元數據的方法在電子商務中也有應用。網站后臺數據庫服務器上的數據處理和數據傳輸，其軟件都是利用面向元數據的方法設計與實現的。實際上，不管網絡應用系統是C/S結構還是B/S結構，在數據庫服務器（S）上對數據的分析、設計和實現，都自覺或不自覺地使用了面向元數據的方法。

＊1.4.5 形式化方法

1. 什么是形式化方法？

軟件工程的形式化方法（Formalized Method），是建立在嚴格數學基礎上、以邏輯推理為出發點、并且具有精確數學語義的開發方法。

軟件工程中的形式化方法是軟件工程的研究領域之一，其內容包括：有限狀態機、State charts、Petri網、通信順序進程、通信系統演算、一階邏輯、程序正確性證明、凈室軟件工程、時態邏輯、模型檢驗、Z形式規約語言、B語言和方法、VDM系統、Larch等。

作為一種以數學邏輯為基礎的方法，形式化方法以其嚴密性越來越受到眾多領域的重視，尤其是在安全性和可靠性作為關鍵問題的系統，如核電站、航空航天、鐵路運輸系統中得到了較為廣泛的應用。但是對于形式化方法在工業領域的實際應用問題，在軟件工程界，尤其是在系統開發人員當中，還存在著相當多的疑問。

1990年，J．A Hall回答了有關形式化方法的7個疑問，它們是：

（1）該方法可否保證軟件系統的完美無缺？答：形式化方法不能保證系統的完美無缺，也并不能減少系統所需的測試。用戶不能認為它是萬能的。

（2）它處理的只是程序正確性的證明？答：形式化方法不僅僅局限于對程序正確性的證明。

（3）它只適用于“安全第一”的系統？答：形式化方法不僅僅局限于“安全第一”的系統。

（4）它需要專業的數學知識？答：許多復雜問題的簡單形式化描述，以及若干項目的成功運作反駁了有關形式化方法需要專業的數學知識。

（5）它增加系統開發的成本？答：是的，增加了研發成本。

（6）用戶無法接受它？答：最終用戶以及非專業人員，在系統開發中的廣泛參與，說明了用戶對該方法的認可。

（7）無法應用于大型的實際系統？答：它在幾個大型實際系統中成功應用，已經引起了廣泛的關注，也否定了形式化方法無法應用于大型實際系統的說法。

1995年，Jonathan P Bowen進一步回答了隨著計算科學的發展，有關形式化方法的其他7個新疑問。

（8）該方法延遲開發進程？答：盡管一些應用形式化方法的項目由于各種原因被延遲，但是多數都因該方法的成功應用顯著地縮短了開發時間。

（9）它缺乏支持工具？答：隨著形式化方法領域的不斷壯大，對其支持的工具會越來越豐富。類似于CASE的集成工具也已經出現。

（10）它將代替傳統的工程設計方法？答：它與結構化軟件工程方法并不是相互對立，相反，二者的結合將會是有益的相互補充。

（11）只適用于軟件設計？答：該方法不僅適用于軟件開發，同樣適用于硬件設計，而且它使軟、硬件聯合設計成為可能。

（12）實際上并不需要它？答：盡管關于該方法的必要性有很多爭論，但不可否認的是，在一些領域中，它是必須的，而且這些領域將越來越廣泛。

（13）它缺乏支持？答：它正在為越來越多的人所接受與支持。在一些國家，該方法正逐漸步入大學的課堂。

（14）該方法的熱衷人員只使用形式化方法？答：必須承認，該方法并不是萬能的。在一些特定領域它并不適宜，用戶界面設計就是一例。

當然，上述回答是站在正方的立場上的。若站在反方的立場上，至少存在這樣一個事實：在當今社會上，很難找到幾個IT企業，他們在軟件需求、設計、實現、驗證中，系統地采用了形式化方法。

2. 形式化方法的優勢

隨著軟件系統的功能越來越多，規模越來越大，其開發的復雜度也越來越高，這樣一來，軟件中出現錯誤的概率也隨之增加，由于這些錯誤可能會帶來時間、財產甚至是人的生命的損失，因此軟件工程的一個主要目標就是希望軟件的可靠性不會隨著系統的復雜性增大而降低。與其他傳統的軟件開發方法相比，以數學為基礎的形式化方法有著無法比擬的嚴密性，它能夠幫助發現其他方法不容易發現的系統描述的不一致性、二義性或不完整性，有助于增加軟件開發人員對系統的理解。

形式化方法在軟件開發中能夠起到的作用是多方面的。首先是對軟件需求和設計的描述。系統分析人員將軟件需求和設計用形式化的語言，而不是自然語言描述出來，這樣做主要有兩方面的好處：對于開發人員而言，由于自然語言本身的局限，傳統的需求與設計描述是不規范的，可能存在歧義，容易被錯誤理解，一旦在這個環節出錯，那么編寫的代碼也不可避免地會出現錯誤；對于系統分析人員而言，在用形式化語言描述需求設計規范之后，可以利用模型檢查、定理證明等方法，來判斷軟件的設計是否一致、是否完整，并且預測系統是否會表現出預期的特點、做出正確的行為。這可以在早期發現軟件開發過程中的錯誤，并獲得及時改正。對于軟件開發來說，錯誤發現得越晚，修改成本就越高，越是大型復雜的系統，越是如此。形式化方法雖然在開發早期可能成本較高，但是卻可以大大降低后期的維護和驗證的費用。對于編程而言，還可以考慮自動代碼生成。對于一些簡單的系統，形式化的描述有可能直接轉換成可執行程序，這就簡化了軟件開發過程，節約了資源，減少了出錯的可能性。形式化方法還可以用于程序驗證，以保證程序的正確性。另外，對于測試來講，形式化方法可用于測試用例的自動生成，這既節省時間，又在一定程度上保證測試用例的覆蓋率。

下面通過一個簡單例子來看如何使用形式化的規格說明來對系統建模，并加以分析和驗證。

現考慮以下需求：一個裝冷卻水的水箱在低水位傳感器發出警告時需要向其中加水。每次加水都向水箱加9個單位的水。注意：

● 水箱最多能裝10個單位的水。

● 每次讀取水位的時間間隔會用掉1個單位的水。

● 低水位傳感器會在水箱剩下1個單位或不到1個單位的水時發出警報。

以上描述涉及兩個關鍵概念：水箱中的水位和水的使用量。我們可以將其形式化地描述如下：

（1）水位用整數表示，并且取值范圍為[0，10]。

（2）水的使用量用整型常數1表示。

水位描述的是在任一時間水箱內的水量，而水的使用量是每次間隔使用的水量。

基本的需求是如果水位為1個單位或者更少則向水箱加水，可以描述為：

（3）函數fill的輸入/輸出均為水位。如果輸入為L個單位的水，fill將在L等于或小于1時返回L+9，其余情況返回L。（這里定義了fill（L）函數，用于說明水箱中的加水動作。）

根據常識，這個系統中，一個時間間隔后新的水位應該是當前水位加上加入的水量減去這個時間間隔用掉的水量。設當前水位為L，則：

（4）level = L + fill（L）- usage

我們檢查這個規格描述是否與水位level的定義一致，也就是說，是否保證水位是0～10的一個整數。為了檢查在第（3）條說明中定義的fill是否滿足一致性，需要檢查以下兩條：

（5）對于所有的水位 L

（L ＜= 1）則（0 ＜= L + 9）并且（L + 9 ＜= 10）

（6）對于所有的水位 L

（0 ＜= L + fill（L）- usage）并且（L + fill（L）- usage ＜= 10）

這兩個條件可以用形式化方法工具自動推理生成。其中第（5）條可以如下證明：

（5.1）因為L ＞= 0，所以L+9 ＞= 0。

（5.2）因為L ＜= 1，所以L+9 ＜= 10。

但是第（6）個條件不能保證成立，當L = 9時

L + fill（L）= L + L -1 = 9 + 9-1 = 17（不滿足＜= 10）

因此，以上的某一步出現了錯誤。仔細檢查可以發現，第（4）條中關于一個時間間隔后的水位描述有問題：（4）level = L + fill（L）- usage（錯誤）。

這個描述與fill的定義不一致，因為fill返回的是水箱的新水位而不僅僅是加入的水量，因此我們將第（4）條改為

（4'）level = fill（L）- usage（正確）

那么第（6）條判斷就改為

（6'）對于所有的水位L

（0 ＜= fill（L）- usage）并且（fill（L）- usage ＜= 10）

這條判斷留給讀者自行驗證。為了讀者閱讀方便，例中用自然語言而不是形式化語言來描述，讀者可以通過相關參考書進一步研究如何用形式化語言來描述這個系統。

通過這個例子讀者可以看到，如何給出形式化的規格說明，如何檢查一致性，如何定義系統行為，如何進行證明。

形式化方法本身是一個很靈活的方法，決策者不需要決定是否在系統中完全采用或者完全不用這類方法，而可以根據自己的實際情況選擇在開發的某些階段，或者軟件的某些模塊某些功能點采用這一方法，也可以考慮將形式化方法與其他非形式化方法，如面向對象方法結合起來使用。

3. 形式化方法的局限性

首先，形式化方法可以應用于軟件開發的一些領域和階段，但是它也有自己的適用范圍。它基于離散數學，最適合對離散系統建模，尤其適用于包括很多邏輯交互的系統。如果一個系統包括很多不同的狀態，狀態之間的轉移根據布爾條件來確定，這樣的系統采用形式化方法收效明顯；而如果系統結構比較松散，沒有太多內在的邏輯關系，就算是形式化了，也得不到太大的好處。同時形式化方法很難應用到采用數值化算法，需要大量計算的問題當中，尤其是需要浮點運算的系統。

其次，目前形式化方法還只能解決中小規模的問題，如果系統規模較大，形式化方法的工作量會很大，并且有一定的難度。邏輯推理在形式化方法中占有很重要的位置，也是一個難點。邏輯推理主要包括模型檢測和定理證明。模型檢測是將系統建成一個有窮模型，然后檢測該模型是否具備希望的性質。簡單來說，就是在模型的狀態空間中進行窮舉搜索，主要的困難在于，當系統非常龐大時采用何種數據結構和算法才能有效地進行搜索。

再次，形式化方法雖然比其他方法更加嚴密準確，能夠通過數學推理對系統的特性做出證明，但是必須清醒地看到，即使一個系統完全采用了形式化方法，也不能說它就是百分之百正確的。因為在將非形式化的信息翻譯成形式化表示的過程中，以及將形式化的分析結果解讀成人們容易理解的信息的過程中都有可能出錯，同時在邏輯推理過程中，邏輯推理軟件本身也有可能出現錯誤。更何況由于形式化方法本身的能力以及軟件開發過程中提供的信息可能不全面，要在一個系統中完全采用形式化方法幾乎是不可能的事情。

4. 形式化方法的發展現狀

形式化方法的發展之路并非一帆風順，在它剛被提出的時期，由于符號系統過于艱深，工具也難于上手并且不夠完善，人們只在小型實驗中采用它。隨著形式化方法的不斷發展，出現了一些新的方法，如Z方法、VDM方法，既可以嚴格定義，學習起來也不太困難，并且與之相對應的軟件也開發得比較全面，形式化方法才漸漸被真正的軟件開發人員所接受。雖然形式化方法目前主要集中在安全性較高的一些領域，但是從實際效果來看，形式化方法確實可以改進軟件質量，提高開發效率。正所謂“磨刀不誤砍柴工”。雖然采用形式化方法在開發初期需要更多的時間，但是與在后期所節省的驗證維護的人力和時間相比，還是值得的，并且它也確實可以降低軟件的錯誤率，由此受到對安全性能要求高的用戶的推崇。

目前已知的采用過形式化方法的軟件開發領域包括：數據庫、醫療、核放射監控、保安系統、通信、交通控制等，均取得了不錯的效果。

5. 形式化方法小結

形式化方法包含了一組活動和一組模型，它們導致了計算機軟件的數學規約。數學規約就是應用一個嚴格的、數學符號體系來規范、開發和驗證軟件系統。

形式化方法提供了一種機制，能夠克服其他軟件工程方法難以克服的二義性、不完整性和不一致性。

形式化方法主要是關注軟件的功能和數據，而對軟件的時序、控制、界面和行為難于表示。

形式化方法不是通過專門的評審與審計來驗證軟件的正確性，而是通過對軟件的數學分析來驗證。因此，它能發現和糾正其他方法發現不了的錯誤。

形式化方法的理論基礎是離散數學中的集合運算和邏輯運算，支持形式化方法的基本概念是：

（1）數據不變式。一個在包含一組數據的系統執行過程中總保持為真的條件。

（2）狀態。系統訪問和修改的存儲數據。

（3）操作。系統中發生的動作以及對狀態數據的讀/寫，且一個操作是和兩個條件相關聯的：前置條件和后置條件。

從國外一些采用形式化方法開發的成功實例可以發現，形式化方法在嚴密的數學理論的支持下，確實能夠解決軟件工程中常見的一些問題。隨著形式化方法越來越成熟，相關可視化工具也越來越多，將形式化方法引入軟件開發的門檻會越來越低。雖然前進的道路很曲折，但是有著獨特魅力的形式化方法終會在軟件開發中得到越來越廣泛的應用。

＊1.4.6 面向業務基礎平臺的方法

業務基礎平臺（Business Framework）是近幾年開始使用的新名詞，是IT企業開發應用軟件的開發環境。近年來，許多軟件企業都有自己的業務基礎平臺。

屏蔽操作系統平臺、數據庫平臺的諸多技術細節，采用面向業務建模來實現軟件系統的方法，叫做面向業務基礎平臺方法。

該方法的特點是面向業務領域的與技術無關的開發模式。

面向業務基礎平臺開發方法在本質上仍然是面向元數據方法與面向對象方法的綜合運用實例，從軟件工程方法論的角度來講，人們并沒有將它作為一種單獨的基本方法。

該方法的優點：它有效彌合了開發人員和業務人員之間的溝通鴻溝，使開發人員更多地關注業務部分，開發者與用戶雙方集中精力弄清原始單證與輸出報表之間的關系，建立好系統業務模型，而不是關注實現的技術細節，從而提升了業務基礎平臺中構件的復用性，避免了開發人員開發相同構件的重復勞動，最終達到提高軟件開發速度與改進軟件產品質量的目的。

該方法的缺點：業務基礎平臺是面向業務行業領域的，不同行業領域之間的通用業務平臺標準尚未建立，也較難建立。因此，不同行業領域的軟件開發商，可能有各自不同的業務基礎平臺。

【例1-8】 北京某公司在業務基礎平臺的開發方面，處于國內領先水平。名稱為X3的業務基礎平臺，在許多大型企業與軟件公司得到了應用，取得了良好業績。

X3業務基礎平臺是從信息化的整體、全局數據庫和發展的角度出發，為保障信息化成功而提供的戰略支撐工具。該業務平臺為信息系統的規劃、設計、構建、集成、部署、運行、維護和管理等提供高可用性、高合理性的體系架構，真正實現“用戶主控，隨需而變，全局規劃，整體集成”的信息化戰略，用戶可以在很短的時間內構建起大型復雜的業務系統。

（1）X3業務基礎平臺構建的信息系統具有如下能力和優勢：

● 靈活調整和自由擴展。

● 組織機構和權限管理。

● 業務工作流。

● 表單和報表。

● 業務集成和業務門戶。

● 查詢、統計和決策分析。

● 快速實施和部署。

● 業務支撐架構。

● 快速構建和業務建模。

（2）X3業務基礎平臺基本思想，體現在圖1-1中。

X3業務基礎平臺是業務導向和驅動的軟件構架體系，現有的信息系統，可直接在技術平臺上構建。而基于業務基礎平臺的信息系統，是在更高級的、基于業務層面的基礎平臺上構建管理系統，這與現有信息系統相比有著本質的區別。

（3）X3業務基礎平臺實現原理與方法。

① 實現原理——應用與實現技術分離，如圖1-2所示。

它通過將業務模型資源與系統實現技術相分離，從根本上提升管理系統的技術無關性。

業務模型資源是隨用戶需求而變動的最頻繁的部分，通過分離業務與實現部分，可以做到業務模型資源變動時，不影響底層的實現技術，無須重新配置或升級運行環境。而運行環境的獨立，則可以保證應用能夠跨越實現技術，運行在不同的系統之上，隨時零成本遷移到新的實現技術。

② 實現方法——業務模型驅動（BMD），如圖1-3所示。

在實現方法上，X3業務基礎平臺采用“業務模型驅動”（BMD，Business Model Driven）的方法體系和工具集。業務模型驅動是一種全新的管理軟件架構和運行模式，它的基本思想是：用業務建模工具來開發管理軟件，用業務基礎平臺來運行管理軟件。

業務模型驅動體現了“以業務模型資源為中心”的思想，它要求用業務建模的開發模式，并將建模的結果業務模型應用資源作為管理軟件開發的主體產品。在BMD模式下，用戶是以業務模型應用資源為主要的目標對象，進行信息系統的設計、構造、發布、集成、維護和管理。

（4）X3業務基礎平臺的應用體會。

某公司2006年引進X3業務基礎平臺后，經過簡短的培訓就能運用自如了。例如，要開發一個固定資產管理系統，只要將該系統的基本表、代碼表、報表（又稱查詢統計表）的定義告訴X3，并用X3定義的業務模型將這些表安插到流程中去，固定資產管理系統就初步開發成功了。

1.4.7 軟件工程方法論小結

到目前為止，軟件工程方法論包涵面向過程方法、面向對象方法、面向元數據方法和形式化方法這4 種基本的軟件開發方法。至于面向業務基礎平臺的方法，它只是面向元數據方法與面向對象方法的具體應用實例，不能單獨作為一種基本方法。

在大型多層結構的信息系統建設中，這4 種方法的關系是：面向元數據方法用在數據庫服務器層面的系統設計與實現上，面向對象方法用在除數據庫服務器層面之外的其他層面的系統設計與實現上，面向過程方法用在其他兩種方法本身內部函數的設計與實現上，形式化方法用在某些核心程序的正確性證明上。由此出發，我們得出如下的認識。

（1）所謂“面向過程方法是傳統軟件工程方法，面向對象方法是現代軟件工程方法”的觀點是膚淺的。

（2）只要將“元數據”的概念稍加擴充，即元數據是所有軟件系統中組織數據的數據，那么，對于信息系統之外的其他領域，面向元數據方法也是適應的。

4種方法的比較如表1-5所示。

由此可見，4種開發方法各有生存時間和空間，不是互相孤立、毫無聯系、彼此對立的，而是互相補充、彼此相關的，所以它們在軟件開發領域能和平共處，互相促進，共同構成了一個多極化的、豐富多彩的和諧的軟件工程方法論世界。

到21世紀初，面向對象方法的開發平臺分為兩大類：以SUN和IBM公司為主的J2EE平臺和以微軟公司為主的．NET平臺。這兩種平臺，都是為了實現多層結構中的表示層與中間層上的開發。數據層上的開發，仍舊是用面向元數據的方法。中間層與數據層之間的連接，采取數據庫連結中間件ODBC或JDBC的方式實現。