1.4.2　以面向對象的建模為基礎的開發模式

正如任何事物一樣，軟件也有其孕育、誕生、成長、成熟和衰亡的生命過程，我們稱其為“軟件的生命周期”。軟件的生命周期可以分為六個階段，即制定計劃、需求分析、設計、編碼、測試、運行和維護。軟件開發可以采用多種途徑進行開發。軟件開發模式是跨越整個軟件生命周期中系統開發、運行和維護所實施的全部工作的框架，它給出了軟件開發活動各個階段之間的關系。軟件項目可以遵循不同類型的開發過程，目前，可以將常見的軟件開發模式大致可分為如下的4種類型：

（1）在第一代軟件開發過程模式中，軟件需求是要求完全確定的，如瀑布模型等。這類開發模式的特點是軟件需求在開發階段已經基本上被完全確定，軟件生命周期的各項活動按順序固定，軟件開發按階段進行。其缺點是如果在開發后期要改正早期已經存在的問題，那么需要付出昂貴的代價，從用戶這個角度來講，開發需要等待較長時間才能夠看到軟件產品，這樣大大增加了軟件開發的風險系數。

（2）由于第一代軟件開發過程模式的改進，誕生了在開始階段只提供基本需求的漸進式開發模型，如噴泉模型和演化模型等。這類開發模型的特點是軟件開發的開始階段只需要提供基本的需求，軟件開發過程的各個活動是迭代的，所以也被稱為迭代式開發。通過迭代過程實現軟件的逐步演化，最終得到軟件產品。在此引入了風險管理，采取早期預防措施，增加了項目成功的幾率，提高了軟件質量；其缺點是由于在開始階段需求的不完全性，對于軟件的總體設計帶來了困難，從而也削弱了產品設計的完整性，這對風險技能管理水平帶來了很大的挑戰。

（3）以體系結構為基礎或基于構件的開發模型，如基于構件的開發模型和基于體系結構的開發模型等。這類模型的特點是首先利用獲取的需求分析結果來設計出軟件的總體結構，然后通過基于構件的組裝方法來構造軟件系統。這樣軟件體系結構的出現使得軟件的結構框架更清晰，有利于系統的設計、開發和維護。

（4）輕量級的開發模型，這種開發模型強調適應性而非預測性、強調以人為中心，而不以流程為中心，以及對變化的適應和對人性的關注，其特點是輕載、基于時間、緊湊、并行并基于構件的軟件開發過程。在所有的敏捷方法中，XP（eXtreme Programming）方法是最引人注目的一種輕型開發方法。

以下將簡單地分析瀑布模型、噴泉模型、基于構件的開發模型、XP（eXtreme Programming）方法等軟件開發模型。

1．瀑布模型

瀑布模型也被稱為生命周期模型，其核心思想是按照相應的工序將問題進行簡化，將系統功能的實現與系統的設計工作分開，便于項目之間的分工與協作，即采用結構化的分析與設計方法將邏輯實現與物理實現分開。瀑布模型將軟件生命周期劃分為項目計劃、需求分析、軟件設計、軟件實現、軟件測試、軟件運行和維護這6個階段，并且規定了它們自上而下的次序，如同瀑布一樣下落，每一個階段都是依次銜接的。采用瀑布模型的軟件開發過程如圖1-7所示。

瀑布模型是最早出現的軟件開發模型，在軟件工程中占有重要的地位，它提供了軟件開發的基本框架。它的過程是從上一項活動接收該項活動的工作對象作為輸入，利用這一輸入實施該項活動應完成的內容，然后給出該項活動的工作成果，并作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；否則返回到前一項，甚至更前面的活動。

瀑布模型為項目提供了按階段劃分的檢查點，這樣有利于在軟件開發過程中人員的組織及管理。瀑布模型讓項目人員在當前階段完成后，才去關注后續階段，這樣有利開發大型的項目。然而，軟件開發的實踐表明，瀑布模型也存在以下的缺陷：

（1）只有在項目生命周期的后期才能看到結果。

（2）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。在項目開發過程中缺乏足夠的靈活性，特別是對于需求不穩定的項目更加麻煩。

（3）在軟件需求分析階段，要完全的確定系統用戶需要的所有需求是一件比較困難的事情，甚至可以說是不太可能的。

盡管瀑布模型存在一定的缺陷，但是它對很多類型的項目而言依然是有效的，特別是在一些大型項目進行開發時依然有效。如果正確地使用瀑布模型，可以節省大量的時間和金錢。對于正在進行開發的項目而言，是否使用瀑布這一模型主要取決于開發者能否理解客戶的需求以及在項目的進程中這些需求的變化程度，對于能夠在前期進行確定需求分析的項目，瀑布模型還是有其價值的。

2．噴泉模型

噴泉模型是一種以對象為驅動、以用戶需求為動力的模型，主要用于描述面向對象的軟件開發過程。該模型認為軟件開發過程自下而上、周期的各階段是相互重疊和多次反復的，就像水噴上去又可以落下來，類似一個噴泉。各個開發階段沒有特定的次序要求，并且可以交互進行，可以在某個開發階段中隨時補充其他任何開發階段中的遺漏。采用噴泉模型的軟件開發過程如圖1-8所示。

噴泉模型主要用于面向對象的軟件項目，軟件的某個部分通常被重復多次，相關對象在每次迭代中隨之加入漸進的軟件成分，各項活動之間無明顯邊界。由于對象概念的引入，表達分析、設計及實現等活動只用對象類和關系，從而可以較容易地實現活動的迭代和無間隙。

噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型中的各個階段沒有明顯界限，開發人員可以同步進行開發。其優點是可以提高軟件項目的開發效率，節省開發時間，適應于面向對象的軟件開發過程。由于噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，由此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大。

3．基于構件的開發模型

基于構件的開發模型利用模塊化方法將整個系統模塊化，并在一定構件模型的支持下復用構件庫中的一個或多個軟件構件，通過組合手段高效率、高質量地構造應用軟件系統的過程。基于構件的開發模型融合了噴泉模型的許多特征，本質上是后者演化而來的，開發過程是迭代的。基于構件的開發模型由軟件的需求分析和定義、體系結構設計、構件庫建立、應用軟件的構建，以及測試和發布5個階段組成，采用這種開發模型的軟件開發過程如圖1-9所示。

構件作為重要的軟件技術和工具得到了極大地發展，這些新技術工具有Microsoft的DCOM、Sun的EJB，以及OMG的CORBA等。基于構件的開發活動從標識候選構件開始，通過搜查已有構件庫，確認所需要的構件是否已經存在。如果已經存在，則從構件庫中提取出來復用；否則采用面向對象的方法開發構件。之后，利用提取出來的構件通過語法和語義檢查，再將這些構件通過“膠合”代碼組裝到一起來實現最終系統，這個過程是迭代的。

基于構件的開發方法使得軟件開發不再一切從頭開發，開發的過程就是構件組裝的過程，維護的過程就是構件升級、替換和擴充的過程。它的優點是構件組裝模型催生了軟件的復用，提高了軟件開發的效率。構件可由一方定義其規格說明，再由另一方來實現，然后供給第三方使用。構件組裝模型允許多個項目同時開發，因而降低了費用，提高了可維護性，可實現分步提交軟件產品。

由于采用自定義的組裝結構標準，缺乏通用的組裝結構標準，因而引入了較大的風險。可重用性和軟件高效性不易協調，需要精干的有經驗的分析人員和開發人員，一般開發人員插不上手。客戶的滿意度低，并且由于過分依賴于構件，所以構件庫的質量影響著產品的質量。

4．XP方法

敏捷方法是20世紀90年代興起的一種輕量級的開發方法，到現在已經非常成熟，它強調適應性而非預測性、強調以人為中心，而不以流程為中心，以及對變化的適應和對人性的關注，其特點是輕載、基于時間、緊湊、并行并基于構件的軟件開發過程。在所有的敏捷方法中，XP（eXtreme Programming）方法是最引人注目的一種輕型開發方法，它規定了一組核心價值和方法，消除了大多數重量型開發過程中不必要的產物，建立了一個漸進型的開發過程。該方法將開發階段的四個活動（分析、設計、編碼和測試）混合在一起，在全過程中采用迭代增量開發、反饋修正和反復測試。它把軟件生命周期劃分為用戶故事、體系結構、發布計劃、交互、接受測試和小型發布6個階段，采用這種模型的軟件開發過程如圖1-10所示。

XP模型通過對傳統軟件開發的標準方法重新進行審視，提出了由一組規則組成的一些簡便易行的過程。由于這些規則是通過在實踐中觀察使軟件高效或緩慢的因素而得出的，因此它既考慮了保持開發人員的活力和創造性，又考慮了開發過程的有組織、有重點和持續性。XP模型是面向客戶的開發模型，重點強調用戶的滿意程度。開發過程中對需求改變的適應能力較強，即使在開發的后期，也可較高程度地適應用戶的改變。

XP開發模型與傳統模型相比具有很大的不同，其核心思想是溝通（Communication）、簡單（Simplicity）、反饋（Feedback）和進取（Aggressiveness）。XP開發小組不僅包括開發人員，還包括管理人員和客戶。該模型強調小組內成員之間要經常進行溝通和交流，在盡量保證質量的前提下力求過程和代碼的簡單化；來自客戶、開發人員和最終用戶的具體反饋意見可以提供更多的機會來調整設計，保證把握正確的開發方向；進取則包含于上述3個原則中。

XP開發方法中有許多新思路，如采用“用戶故事”代替傳統模型中的需求分析，“用戶故事”由用戶用自己領域中的詞匯，在不考慮任何技術細節的情況下，準確地表達自己的需求。XP模型的優點如下：

（1）采用簡單計劃策略，不需要長期計劃和復雜模型，開發周期短。

（2）在全過程采用迭代增量開發、反饋修正和反復測試的方法，軟件質量有保證。

（3）能夠適應用戶經常變化的需求，提供用戶滿意的高質量軟件。

上面講述的各種開發模型或方法，或許不能一概而論地作為面向對象的建模基礎之開發模式，但是在這些開發模型或方法中，都包含了軟件的需求分析、軟件的設計、軟件的開發、軟件的測試和軟件的部署。在每一個階段，可以借助于面向對象的建模和這些開發模型形成一套適合自己或企業的開發方式。

開發模式或方法畢竟是方法，如同在冷兵器時代的排兵布陣和火器時代的排兵布陣一樣，都有自己的技巧和策略，由于一個是面向過程而另一個是面向對象，這種的不同也就賦予了不同的方法論。在這些開發模型中，對于適用UML和面向對象的開發的代表就是Rational統一過程（Rational Unified Process，RUP），我們將在第4章詳細講解。