軟件工程課件：面向?qū)ο筌浖こ谭椒▽W

面向?qū)ο筌浖こ谭椒▽W7.1面向?qū)ο蟮母拍?.2從認識論看面向?qū)ο蠓椒ǖ男纬?.3面向?qū)ο蠓椒ǖ幕靖拍?.4統(tǒng)一過程與統(tǒng)一建模語言7.5迭代和增量過程7.6小結(jié)習題7

知識點

面向?qū)ο?OO)的基本概念，統(tǒng)一過程(RUP)，UML，迭代和增量過程。

難點

迭代和增量過程。

基于工作過程的教學任務(wù)

通過本章的學習，了解什么是面向?qū)ο螅粡恼J識論看面向?qū)ο蠓椒ǖ男纬?，深入理解面向?qū)ο蠓椒ǖ膬?nèi)涵；了解面向?qū)ο蟮幕靖拍詈突咎卣鳎涣私釻ML，重點掌握RUP模型的基本原理；了解迭代和增量過程，為后續(xù)要描述的工作流服務(wù)。

用傳統(tǒng)的結(jié)構(gòu)化方法開發(fā)的軟件，其穩(wěn)定性、可修改性和重用性都比較差，這是因為結(jié)構(gòu)化方法的本質(zhì)是功能分解，從代表目標系統(tǒng)整體功能的單個處理著手，自頂向下不斷把復雜的處理分解為子處理，一層一層地分解下去，直到只剩下容易實現(xiàn)的子處理，然后用相應的工具來描述各個處理。因此，結(jié)構(gòu)化方法是圍繞實現(xiàn)處理功能的“過程”來構(gòu)造系統(tǒng)的。

但是，用戶需求的變更大部分是針對功能的，因此這種變更對于基于過程的設(shè)計來說是災難性的。用這種方法設(shè)計出來的系統(tǒng)結(jié)構(gòu)常常是不穩(wěn)定的，用戶需求的變更往往造成系統(tǒng)結(jié)構(gòu)的較大改變，從而需要花費很大代價才能實現(xiàn)這種變更。面向?qū)ο蠓椒軌蚋玫貞獙ψ兏?，開發(fā)出穩(wěn)定性好、容易修改和便于重用的系統(tǒng)。

7.1面向?qū)ο蟮母拍?/p>

面向?qū)ο笫且环N新興的程序設(shè)計方法，或者說它是一種新的程序設(shè)計范型，其基本思想是使用對象、類、封裝、繼承、聚合、關(guān)聯(lián)、消息、多態(tài)、重載等基本概念來進行程序設(shè)計。自20世紀80年代以來，面向?qū)ο蠓椒ㄒ焉钊氲接嬎銠C軟件領(lǐng)域的幾乎所有分支，遠遠超出了程序設(shè)計語言和編程技術(shù)的范疇。

面向?qū)ο?Object-Oriented，OO)不僅是一些具體的軟件開發(fā)技術(shù)與策略，而且是一整套關(guān)于如何看待軟件系統(tǒng)與現(xiàn)實世界的關(guān)系，用什么觀點來研究問題并進行求解，以及如何進行系統(tǒng)構(gòu)造的軟件方法學。

面向?qū)ο蠓椒ǖ某霭l(fā)點和基本原則：盡可能模擬人類習慣的思維方式，使開發(fā)軟件的方法與過程盡可能接近人類認識世界并解決問題的方法與過程。即：使描述現(xiàn)實世界問題的問題空間(也稱為問題域)與實現(xiàn)解法的解空間(也稱為求解域)在結(jié)構(gòu)上盡可能一致。結(jié)構(gòu)化方法采用了許多符合人類思維習慣的原則與策略(例如自頂向下、逐步求精)，面向?qū)ο蠓椒ǜ鼜娬{(diào)運用人類在日常的邏輯思維中經(jīng)常采用的思想方法與原則，例如抽象、分類、繼承、聚合、封裝等，這使得軟件開發(fā)人員能更有效地思考問題，并以其他人也能看得懂的方式把自己的認識表達出來。

具體地講，面向?qū)ο蠓椒ㄓ邢旅嬉恍┲饕攸c：

從問題域中客觀存在的事物出發(fā)來構(gòu)造軟件系統(tǒng)，用對象作為對這些事物的抽象表示，并以對象作為系統(tǒng)的基本構(gòu)成單位；

事物的靜態(tài)特征(即可以用一些數(shù)據(jù)來表達的特征)用對象的屬性表示，事物的動態(tài)特性(即事物的行為)用對象的操作表示；

對象的屬件與操作結(jié)合，構(gòu)成一個獨立的實體，對外屏蔽其內(nèi)部細節(jié)(封裝性)；

對事物進行分類，把具有相同屬性和相同操作的對象歸為一類，類是相似對象的抽象描述，每個對象是類的一個實例；

通過在不同程度上運用抽象的原則(較多或較少地忽略事物之間的差異)，可以得到一般類和特殊類。特殊類繼承一般類的屬性與操作，面向?qū)ο蠓椒ㄖС謱@種繼承關(guān)系的描述與實現(xiàn)，從而簡化系統(tǒng)的構(gòu)造過程及其文檔；

復雜的對象可以用簡單的對象組合而成(聚合)；

對象之間通過消息進行通信，以實現(xiàn)對象之間的動態(tài)聯(lián)系；

用關(guān)聯(lián)表達某些類之間對用戶業(yè)務(wù)有特定意義的實例關(guān)系。

從上面可以看到，在用面向?qū)ο蠓椒ㄩ_發(fā)的系統(tǒng)中，以類的形式進行描述并由這些類創(chuàng)建的對象為基本構(gòu)成單位來構(gòu)造系統(tǒng)。這些對象對應著問題域中的各項事物，它們內(nèi)部的屬性與操作刻畫了事物的靜態(tài)特征和動態(tài)特性。對象類之間的繼承、聚合、關(guān)聯(lián)、消息等關(guān)系如實地表達了問題域中事物之間實際存在的各種關(guān)系。因此，無論是系統(tǒng)的構(gòu)成成分，還是通過這些成分之間的關(guān)系而體現(xiàn)的系統(tǒng)結(jié)構(gòu)，都可直接地映射問題域。

通過以上的介紹，對什么是面向?qū)ο笥辛艘粋€大致的了解。而對于“面向?qū)ο蟆?，有以下幾種定義：

一種使用對象(將屬性與操作封裝為一體)、消息傳遞、類、繼承、多態(tài)和動態(tài)綁定來開發(fā)問題域模型之解的范型；

一種基于對象、類、實例和繼承等概念的技術(shù)；

用對象作為建模的原子；

用來描述一些基于下述概念的東西：封裝、對象(對象的標識、屬性和操作)、消息傳遞、類、繼承、多態(tài)、動態(tài)綁定；

用來描述一種把軟件組織成對象集合的軟件開發(fā)策略，對象中既包含數(shù)據(jù)也包括操作。

面向?qū)ο蠓椒ㄗ钪饕膽梅秶允擒浖_發(fā)。在軟件生命周期的各個階段(包括需求、分析、設(shè)計、實現(xiàn)、測試與維護)，以及與軟件開發(fā)有關(guān)的各個領(lǐng)域(如人機界面、數(shù)據(jù)庫、軟件復用、分布式計算、形式化方法、CASE工具與環(huán)境等)，都受到面向?qū)ο蠹夹g(shù)的重大影響，形成或正在形成以面向?qū)ο鬄樘厣男吕碚摵托录夹g(shù)。因此，如果在這個范圍討論問題，可將面向?qū)ο蠓椒ǘx為：

面向?qū)ο蠓椒ㄊ且环N運用對象、類、繼承、封裝、聚合、關(guān)聯(lián)、消息、多態(tài)性等概念來構(gòu)造系統(tǒng)的軟件開發(fā)方法。

7.2從認識論看面向?qū)ο蠓椒ǖ男纬?/p>

對問題域的正確認識是軟件開發(fā)工作的首要任務(wù)，沒有對問題域的正確認識，就不可能產(chǎn)生一個正確的系統(tǒng)。而描述只是把開發(fā)人員對問題域的認識表達出來，最終產(chǎn)生機器能夠理解和執(zhí)行的系統(tǒng)實現(xiàn)。

7.2.1軟件開發(fā)—對事物的認識和描述

軟件開發(fā)是對問題域求解的過程。按照軟件工程學對軟件生命周期的劃分，軟件開發(fā)過程包括需求、分析、設(shè)計、實現(xiàn)、測試和維護等主要階段。從認識論的角度看，整個軟件開發(fā)過程又可歸結(jié)為兩項主要活動，即人們對所要解決的問題域及其相關(guān)事物的認識和基于這種認識所進行的描述。

所謂“認識”，是指在要處理的問題域內(nèi)，通過人的思維對該問題域客觀存在的事物，以及要解決的問題產(chǎn)生正確的認識和理解，包括弄清事物的屬性、行為及其關(guān)系，并找出解決問題的方法。

所謂“描述”，是指用一種語言把人們對問題域的認識、對問題及其解決方案的認識描述出來，最終描述必須使用計算機讀得懂的語言，即編程語言。

粗略地劃分，可以把分析與設(shè)計視為對問題及其解決方案的認識，把實現(xiàn)視為對解決方案的描述。細致地劃分，分析和設(shè)計階段本身也包括描述，即按特定的軟件開發(fā)方法所提供的建模概念和表示法來建立分析模型和設(shè)計模型，并產(chǎn)生相關(guān)的文檔；實現(xiàn)階段也包括一定的認識和理解活動，特別是在傳統(tǒng)的軟件開發(fā)方法中，分析文檔和設(shè)計文檔不能很好地映射問題域，程序員在書寫程序之前，往往需要在分析、設(shè)計文檔的幫助下，對程序要描述的事物進行再認識。

7.2.2語言的鴻溝

開發(fā)人員對問題域的認識是人類的一種思維活動。人類的任何思維活動都是借助于熟悉的某種自然語言進行的。而系統(tǒng)的最終實現(xiàn)必須用計算機能夠閱讀和理解的編程語言來對系統(tǒng)進行描述，人們習慣使用的自然語言和計算機能夠執(zhí)行的編程語言之間存在著很大的差距，這種差距稱為“語言的鴻溝”，實際上也就是認識和描述之間的鴻溝(見圖7-1)。

語言的鴻溝意味著什么呢？一方面，人借助自然語言對問題域所產(chǎn)生的認識遠遠不能被機器理解和執(zhí)行；另一方面，機器能夠理解的編程語言又很不符合人的思維方式。開發(fā)人員需要跨越兩種語言之間的鴻溝，即從思維語言過渡到描述語言，這種過渡并沒有一種準確可靠的方法，因此往往要耗費開發(fā)人員的許多精力，也是很多錯誤的發(fā)源地。

圖7-1認識和描述之間的鴻溝

7.2.3面向?qū)ο缶幊陶Z言的發(fā)展使鴻溝變小

隨著機器語言、匯編語言、高級語言等編程語言從低級向高級的發(fā)展，語言的鴻溝也在逐漸變小。面向?qū)ο蟮木幊陶Z言(Object-OrientedProgrammingLanguage,OOPL)與以往各種語言有著根本的不同，其設(shè)計目標就是為了能更直接地描述問題域中客觀存在的事物(即對象)及其關(guān)系，主要體現(xiàn)在以下幾點：

(1)客觀世界(問題域)是由具體事物構(gòu)成的。每個事物有自己的靜態(tài)特征(可以由一組數(shù)據(jù)表示)和動態(tài)特性(事物的行為或功能，可以由一組操作表示)。

(2)客觀世界中的事物既具有共同性又具有特殊性。人類認識客觀世界的基本方法之一是對事物進行分類，即：根據(jù)事物的共性把事物歸結(jié)為某些類；考慮一個類中一部分事物的特殊性可得到這個類的子類，子類既有父類的普遍性又有自己的特殊性。

(3)客觀世界中較為復雜的事物往往是由一些比較簡單的事物構(gòu)成的，例如，一架飛機由機艙、機翼和發(fā)動機等構(gòu)成。OOPL中提供了描述這種組成關(guān)系的功能，即聚合。

(4)客觀世界中的每個事物通常是一個獨立的整體，它的許多內(nèi)部細節(jié)是外部不必關(guān)心的。OOPL的封裝機制把對象的屬性和操作結(jié)合為一個整體，屏蔽了對象的內(nèi)部細節(jié)。

(5)客觀世界中各事物之間存在著某些關(guān)系，例如，在教師和課程之間，需要指明哪些教師承擔了哪些課程。OOPL用關(guān)聯(lián)來表示類之間的這種關(guān)系。

(6)客觀世界中的一個事物可能與其他事物存在某種行為上的聯(lián)系，例如，采購員購入一次貨物要引起會計的一次賬目處理。OOPL用消息表示對象之間的動態(tài)聯(lián)系。

綜上所述，面向?qū)ο蟮木幊陶Z言使程序能夠比較直接地反映客觀世界的本來面目，并且使軟件開發(fā)人員能夠運用人類日常思維方法來進行軟件開發(fā)。

圖7-2表示，隨著編程語言由低級向高級發(fā)展，它們與自然語言之間的鴻溝在逐漸變小。

在圖7-1和圖7-2中，從編程語言到計算機之間的深色陰影表示這部分工作是由機器自動完成的，基本不需要開發(fā)人員花費精力了。自然語言與問題域之間的淺色陰影表明這樣的意思：雖然人們借助自然語言來認識和理解問題域?qū)儆谌祟惖娜粘Ｋ季S活動，不存在語言的鴻溝，但是不能說這一區(qū)域已經(jīng)不存在問題。第一個問題是：雖然人人都會運用某種自然語言，但不一定都能正確地認識客觀世界，因為認知需要有正確的思維方法。第二個問題是：在軟件開發(fā)過程中，要求人們比在日常生活中對問題域有更深刻、更準確的理解，這需要許多以軟件專業(yè)知識為背景的思維方法。這些問題正是軟件工程學所要解決的。

圖7-2編程語言的發(fā)展使語言的鴻溝變小

7.2.4軟件工程學的作用

軟件開發(fā)是對問題域的認識和描述，那么軟件工程學起什么作用呢？從認識事物方面看，它在分析階段提供了一些對問題域的分析和認識方法；從描述事物方面看，它在分析和設(shè)計階段提供了一些從問題域逐步過渡到編程語言的描述手段。這如同在語言的鴻溝上鋪設(shè)了一些平坦的路段，但是在傳統(tǒng)的軟件工程方法中，這些路段并不連續(xù)，也就是說，并沒有完全填平語言之間的鴻溝(如圖7-3所示)。而在面向?qū)ο蟮能浖こ谭椒ㄖ?，從面向?qū)ο蟮姆治?Object-OrientedAnalysis,OOA)到面向?qū)ο蟮脑O(shè)計(Object-OrientedDesign,OOD)，再到面向?qū)ο蟮膶崿F(xiàn)(Object-OrientedImplementation,OOI)，都是緊密銜接的，填平了語言之間的鴻溝。

圖7-3沒有完全填平語言鴻溝的傳統(tǒng)軟件工程方法

1.傳統(tǒng)的軟件工程方法

傳統(tǒng)的軟件工程方法指面向?qū)ο蠓椒ǔ霈F(xiàn)之前的各種軟件工程方法，這里主要討論結(jié)構(gòu)化方法所起的作用。

1)需求分析

傳統(tǒng)的軟件工程方法中的需求分析對問題域的認識和描述不是以問題域中的固有事物作為基本單位，并保持原貌，而是打破了各項事物之間的界限，在全局范圍內(nèi)以功能、數(shù)據(jù)或數(shù)據(jù)流為中心來進行分析。例如，功能分解法把整個問題域看成一些功能和子功能；數(shù)據(jù)流法則把整個問題域看成一些數(shù)據(jù)流和加工。所以這些方法的分析結(jié)果不能直接映射問題域，而是經(jīng)過了不同程度的轉(zhuǎn)化和重新組合。因此，傳統(tǒng)的分析方法容易隱藏一些對問題域的理解偏差，與后續(xù)開發(fā)階段的銜接也比較困難。

2)總體設(shè)計和詳細設(shè)計

傳統(tǒng)的軟件工程方法中的設(shè)計文檔很難與分析文檔對應，原因是二者的概念體系不一致。結(jié)構(gòu)化分析的結(jié)果—數(shù)據(jù)流圖和結(jié)構(gòu)化設(shè)計的結(jié)果—模塊結(jié)構(gòu)圖是基于兩種不同的概念體系。數(shù)據(jù)流圖中的一個數(shù)據(jù)流，既不能對應模塊結(jié)構(gòu)圖中的模塊的數(shù)據(jù)，也不能對應模塊間的調(diào)用關(guān)系，數(shù)據(jù)流圖中的一個加工也未必對應模塊結(jié)構(gòu)圖中的一個模塊。分析與設(shè)計之間在概念體系上的不一致稱為“分析與設(shè)計的鴻溝”，它給從分析到設(shè)計的過渡帶來了較大的困難。

所謂“從分析到設(shè)計的轉(zhuǎn)換”，實際上并不存在可靠的轉(zhuǎn)換規(guī)則，而是帶有人為的隨意性，往往因為工程人員的理解錯誤而埋下隱患。分析與設(shè)計的鴻溝帶來的另一個后果是，設(shè)計文檔與問題域的原貌相差更遠了，因為其中經(jīng)過了兩次扭曲：一次發(fā)生在分析階段，一次發(fā)生在從分析到設(shè)計的“轉(zhuǎn)換”階段。當程序員手持設(shè)計文檔進行編程時，已經(jīng)難以透過這些文檔看到問題域的原貌了。

3)實現(xiàn)、測試和維護

從理論上講，從設(shè)計到實現(xiàn)、從實現(xiàn)到測試、從運行到維護應能較好地銜接，即在這些階段之間不存在明顯的鴻溝。但是，由于分析方法的缺陷很容易產(chǎn)生對問題域的錯誤理解，而分析與設(shè)計的鴻溝很容易造成設(shè)計人員對分析結(jié)果的錯誤轉(zhuǎn)換，所以在實現(xiàn)時程序員往往需要對分析和設(shè)計人員已經(jīng)認識過的事物重新進行認識，并可能產(chǎn)生不同的理解。在實際開發(fā)過程中常?？吹?，后期開發(fā)階段的人員不斷地發(fā)現(xiàn)前期階段的錯誤，并按照自己的理解進行工作，所以每兩個階段之間都會出現(xiàn)不少變化，其文檔不能很好地銜接。

無論如何，各種傳統(tǒng)的軟件工程方法的歷史作用是毋庸置疑的。它們在自然語言和編程語言之間的鴻溝上鋪設(shè)了一些平坦的路段(盡管還不太連貫)，其作用與不足，也為面向?qū)ο蠓椒ㄌ峁┝擞幸娴慕梃b。

2.面向?qū)ο蟮能浖こ谭椒?/p>

面向?qū)ο蟮能浖こ谭椒ㄊ敲嫦驅(qū)ο罄碚撛谲浖こ填I(lǐng)域的全面運用。它包括面向?qū)ο蟮姆治?OOA)、面向?qū)ο蟮脑O(shè)計(OOD)、面向?qū)ο蟮膶崿F(xiàn)(OOI)、面向?qū)ο蟮臏y試(Object-OrientedTest,OOT)和面向?qū)ο蟮能浖S護(Object-OrientedSoftwareMaintenance,OOSM)等主要內(nèi)容，如圖7-4所示。

圖7-4面向?qū)ο蟮能浖こ谭椒?/p>

1)面向?qū)ο蟮姆治?/p>

OOA強調(diào)直接以問題域中客觀存在的事物來識別系統(tǒng)中的對象。用對象的屬性和操作分別描述事物的靜態(tài)特征和動態(tài)特性。問題域中有哪些與需求有關(guān)的事物，OOA模型中就應該有哪些對象，對象及其屬性和操作的命名都強調(diào)與客觀事物保持一致。此外，OOA模型也保持了問題域中各項事物之間關(guān)系的原貌。

這包括：把有相同屬性和相同操作的對象歸結(jié)為一類；用一般—特殊結(jié)構(gòu)描述一般類與特殊類之間的關(guān)系，即繼承關(guān)系；用整體—部分結(jié)構(gòu)描述事物間的組成關(guān)系，即聚合關(guān)系；用關(guān)聯(lián)表示事物之間的靜態(tài)聯(lián)系；用消息表示事物之間的動態(tài)聯(lián)系?？梢钥吹?，無論是對問題域中的單個事物，還是對各項事物之間的關(guān)系，OOA模型都保留著它們原有的基本面貌，而沒有加以轉(zhuǎn)換和扭曲，也沒有打破原有的界限而重新組合，所以，OOA模型能夠很好地映射問題域。

2)面向?qū)ο蟮脑O(shè)計

OOA與OOD的職責劃分是：OOA針對問題域和系統(tǒng)責任，運用OO方法，建立一個能直接映射問題域、滿足用戶需求的OOA模型，不考慮與系統(tǒng)實現(xiàn)條件有關(guān)的因素(例如，采用什么編程語言、圖形用戶界面、數(shù)據(jù)庫等)，從而使OOA模型獨立于具體的實現(xiàn)；OOD是在OOA模型基礎(chǔ)上，針對具體的實現(xiàn)條件，運用OO方法進行系統(tǒng)設(shè)計，其中既包括全局性的設(shè)計決策，也包括對象細節(jié)的完善。根據(jù)具體的實現(xiàn)條件，一方面要對OOA模型做某些必要的修改和調(diào)整，將其結(jié)果作為OOD的組成部分；另一方面要增加若干新的組成部分，以解決人機交互、控制驅(qū)動及數(shù)據(jù)存儲等方面的問題。

OOA與OOD采用一致的概念和表示法，這是面向?qū)ο蠓治雠c設(shè)計優(yōu)于傳統(tǒng)軟件工程方法的重要原因之一。這使得從OOA到OOD不存在轉(zhuǎn)換，只有局部的修改或調(diào)整，并增加幾個與實現(xiàn)有關(guān)的獨立部分。因此，OOA與OOD之間不存在傳統(tǒng)方法中分析與設(shè)計之間的那種鴻溝，二者能夠緊密銜接，從而大大降低了從OOA過渡到OOD的難度、工作量和出錯率。

3)面向?qū)ο蟮膶崿F(xiàn)

面向?qū)ο蟮膶崿F(xiàn)又稱為面向?qū)ο蟮木幊?Object-OrientedProgramming,OOP)，是使面向?qū)ο蟮能浖_發(fā)最終落到實處的重要階段?，F(xiàn)在，在OOA、OOD和OOP一系列的軟件工程階段中，OOP的分工就比較簡單了：認識問題域和設(shè)計系統(tǒng)成分的工作已經(jīng)在OOA和OOD階段完成，OOP的工作只是用一種面向?qū)ο蟮木幊陶Z言把OOD模型中的每個成分編寫為程序代碼而已。

OOP階段產(chǎn)生的程序能夠緊密地對應OOD模型；OOD模型中一部分對象類對應OOA模型，其余部分的對象類對應與實現(xiàn)有關(guān)的因素；OOA模型中全部類及對象都對應問題域中的事物。這樣的映射關(guān)系不但提高了開發(fā)工作的效率和質(zhì)量，而且對開發(fā)以后的維護工作有更長遠的意義。

4)面向?qū)ο蟮臏y試

面向?qū)ο蟮臏y試(OOT)是指：對于用OO技術(shù)開發(fā)的軟件，在測試過程中繼續(xù)運用OO技術(shù)，進行以對象概念為中心的軟件測試。

用OO技術(shù)開發(fā)的軟件含有大量與OO方法相關(guān)的概念、原則以及與之有關(guān)的語法與語義信息。在測試過程中發(fā)掘并利用這些信息，繼續(xù)運用OO的概念與原則來組織測試，可以更準確地發(fā)現(xiàn)程序錯誤并提高測試效率。有利于OOT的另一個因素是對象的繼承性，對父類的測試完成之后，子類的測試重點只是那些新定義的屬性和操作。

對于用OOA和OOD建立模型并由OOPL編程的軟件，OOT可以發(fā)揮更強的作

用—通過捕捉OOA和OOD模型信息，檢查程序與模型不匹配的錯誤，這一點是傳統(tǒng)軟件工程方法難以達到的。

從這些方面可以看出，面向?qū)ο蟮能浖こ瘫葌鹘y(tǒng)的軟件工程更有優(yōu)勢，更適合開發(fā)大型、復雜的系統(tǒng)，是目前軟件開發(fā)的主流技術(shù)。

7.3面向?qū)ο蠓椒ǖ幕靖拍?/p>

面向?qū)ο蠓椒ǜ鼜娬{(diào)運用人類在日常的邏輯思維中經(jīng)常采用的思想方法與原則，例如抽象、分類、繼承、聚合、封裝等，使用這些方法和原則，將對象抽象成類，用類之間的繼承、聚合、關(guān)聯(lián)、消息等關(guān)系表達問題域中事物之間實際存在的各種關(guān)系。下面就來了解面向?qū)ο蟮幕靖拍詈吞卣鳌?/p>

7.3.1面向?qū)ο蟮幕靖拍?/p>

1．對象

對象是要研究的任何事物。從一本書到一家圖書館，簡單的整數(shù)到整數(shù)列，龐大的數(shù)據(jù)庫、極其復雜的自動化工廠、航天飛機等都可看作對象，它不僅能表示有形的實體，也能表示無形的(抽象的)規(guī)則、計劃或事件。對象由數(shù)據(jù)(描述事物的屬性)和作用于數(shù)據(jù)的操作(體現(xiàn)事物的行為)構(gòu)成一個獨立的整體。從程序設(shè)計者的角度看，對象是一個程序模塊，從用戶的角度看，對象提供了他們所希望的行為。對內(nèi)的操作通常稱為方法。一個對象請求另一對象為其服務(wù)的方式是發(fā)送消息。

2．類

類是對象的模板。類是對一組具有相同數(shù)據(jù)和相同操作的對象的定義，一個類所包含的方法和數(shù)據(jù)描述一組對象的共同屬性和行為。類是在對象之上的抽象，對象則是類的具體化，是類的實例。類可以有子類，也可以有其他類，形成類的層次結(jié)構(gòu)。

3．消息

消息是對象之間進行通信的一種規(guī)格說明，一般由三部分組成：接收消息的對象、消息名及參數(shù)列表。

7.3.2面向?qū)ο蟮闹饕卣?/p>

1．封裝性

封裝是一種信息隱藏技術(shù)，它體現(xiàn)了類的說明，是對象的重要特性。封裝將數(shù)據(jù)和加工數(shù)據(jù)的方法(函數(shù))封裝為一個整體，成為獨立性很強的模塊，使用戶只能見到對象的外部特性(對象能接受哪些消息，具有哪些處理能力)，而對象的內(nèi)部特征(保存內(nèi)部狀態(tài)的私有數(shù)據(jù)和實現(xiàn)加工能力的算法)對用戶是隱藏的。封裝的目的在于把對象的設(shè)計者和對象的使用者分開，使用者不必知曉行為實現(xiàn)的細節(jié)，只須使用設(shè)計者提供的消息來訪問對象即可。

2．繼承性

繼承性是子類共享父類數(shù)據(jù)和方法的機制，由類的派生功能實現(xiàn)，一個類直接繼承父類的全部描述，同時能進行修改和擴充。

繼承具有傳遞性。繼承分為單繼承(一個子類只有一個父類)和多重繼承(一個子類可以有多個父類)。類的對象是各自封閉的，如果沒有繼承性機制，則類對象中數(shù)據(jù)、方法就會出現(xiàn)大量重復。繼承不僅支持系統(tǒng)的可重用性，而且還促進系統(tǒng)的可擴充性。

3．多態(tài)性

對象根據(jù)接收的消息而做出動作。同一消息為不同的對象接收時可產(chǎn)生完全不同的行動，這種現(xiàn)象稱為多態(tài)性。利用多態(tài)性，用戶可發(fā)送一個通用的信息，而將所有的實現(xiàn)細節(jié)留給接收消息的對象來處理，這樣，同一消息就可以調(diào)用不同的實現(xiàn)方法。例如，將print消息發(fā)送給一張圖或表時調(diào)用的打印方法與將同樣的print消息發(fā)送給一個正文文件而調(diào)用的打印方法會完全不同。

多態(tài)性的實現(xiàn)受繼承性的支持，利用類繼承的層次關(guān)系，把具有通用功能的協(xié)議(方法)存放在類層次的高層，而將實現(xiàn)這一功能的不同方法置于較低層次，這樣，在低層次上生成的對象就能對通用消息做出不同的響應。在OOPL中可通過在派生類中重定義基類方法(函數(shù))來實現(xiàn)多態(tài)性。

綜上可知，在OO方法中，對象和傳遞消息分別表現(xiàn)事物及事物間相互聯(lián)系的概念，類和繼承是適應人們一般思維方式的描述方式，方法是允許作用于該類對象上的各種操作，這種對象、類、消息和方法的程序設(shè)計方式的基本點在于對象的封裝性和類的繼承性。通過封裝將對象的定義和對象的實現(xiàn)分開，通過繼承體現(xiàn)類與類之間的關(guān)系，以及由此帶來的動態(tài)聯(lián)編和實體的多態(tài)性，就構(gòu)成了面向?qū)ο蟮幕咎卣鳌?/p>

7.4統(tǒng)一過程與統(tǒng)一建模語言

圖7-5軟件開發(fā)過程

7.4.1統(tǒng)一過程概述

統(tǒng)一過程(UnifiedProcess，UP)是一個軟件開發(fā)過程，軟件開發(fā)過程是一個將用戶需求轉(zhuǎn)化為軟件系統(tǒng)所需活動的集合，如圖7-5所示。

統(tǒng)一過程是基于構(gòu)件的，所構(gòu)造的軟件系統(tǒng)是由軟件構(gòu)件通過明確定義的接口相互連接而建造起來的。統(tǒng)一過程使用統(tǒng)一建模語言(UML)來建立軟件系統(tǒng)的所有模型，統(tǒng)一過程的突出特點是用例(usecase)驅(qū)動、以構(gòu)架為中心、迭代(iteration)和增量的。

1．用例驅(qū)動

軟件系統(tǒng)是為用戶服務(wù)的。因此，要想構(gòu)造一個成功的軟件系統(tǒng)，就必須了解預期用戶的希望和需要是什么。

用戶使用自動取款機(AutomaticTellerMachine,ATM)就是一個交互的例子，用戶插入銀行卡，然后對取款機屏幕上出現(xiàn)的詢問信息做出恰當?shù)膽?，便可以提取一定?shù)額的現(xiàn)金。作為對用戶的取款卡和應答的響應，系統(tǒng)執(zhí)行一系列有序的動作，提供給用戶一個有價值的結(jié)果，即取出現(xiàn)金。這種交互就是一個用例。

用例向用戶提供系統(tǒng)的功能，用例獲取的是功能需求，所有用例合在一起構(gòu)成用例模型，描述了系統(tǒng)的全部功能，用來代替?zhèn)鹘y(tǒng)的系統(tǒng)功能說明。傳統(tǒng)的系統(tǒng)功能說明回答了這樣一個問題，即“系統(tǒng)應該做什么？”；而用例方法則刻畫出了“系統(tǒng)應該為每個用戶做什么？”，這就要求從系統(tǒng)對用戶提供的價值方面來考慮問題，而不僅僅限于提供強大的功能。

用例不只是一種確定系統(tǒng)需求的工具，還能驅(qū)動系統(tǒng)設(shè)計、實現(xiàn)和測試的進行，也就是說，用例可以驅(qū)動開發(fā)過程?；谟美Ｐ?，開發(fā)人員可以創(chuàng)建一系列用例的設(shè)計和實現(xiàn)模型，開發(fā)人員也可以審查后續(xù)建立的模型是否與用例模型一致，測試人員測試實現(xiàn)以確保實現(xiàn)模型的構(gòu)件正確實現(xiàn)了用例。因此，用例不僅啟動了開發(fā)過程，而且使其結(jié)合為一個整體。

用例雖然可以驅(qū)動過程，但不能孤立地選擇用例，它們與系統(tǒng)構(gòu)架是協(xié)調(diào)發(fā)展的。也就是說，用例驅(qū)動系統(tǒng)構(gòu)架，系統(tǒng)構(gòu)架反過來影響用例的選擇。因此，系統(tǒng)構(gòu)架和用例會隨著生命周期的延續(xù)而逐漸完善。

2．以構(gòu)架為中心

軟件構(gòu)架包含了系統(tǒng)中最重要的靜態(tài)特征和動態(tài)特性。構(gòu)架技術(shù)是根據(jù)企業(yè)的需要逐漸發(fā)展起來的，受用戶和其他項目相關(guān)人員需求的影響，在用例中得到反映；而且，構(gòu)架技術(shù)也受其他許多因素的影響，如軟件應用平臺(例如計算機體系結(jié)構(gòu)、操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、網(wǎng)絡(luò)通信協(xié)議等)、是否有可重用的構(gòu)件(例如圖形用戶界面框架)、如何考慮實施問題、如何與遺留系統(tǒng)集成以及非功能性需求(例如性能、可靠性)等。構(gòu)架刻畫了系統(tǒng)的整體設(shè)計，省略了細節(jié)部分，突出了系統(tǒng)的重要特征。

用例和構(gòu)架是如何相關(guān)的呢？每種產(chǎn)品都有功能和表現(xiàn)形式兩方面的特征，只具備其中的一個方面是不夠的，對這兩個方面必須權(quán)衡才能得到成功的產(chǎn)品，這里的功能與用例對應，表現(xiàn)形式與構(gòu)架對應。用例和構(gòu)架之間是相互影響的，這是一個“雞與蛋”的問題。一方面，用例在實現(xiàn)時必須適合構(gòu)架；另一方面，構(gòu)架必須預留空間以實現(xiàn)現(xiàn)在或?qū)硭枰挠美Ｊ聦嵣?，?gòu)架和用例必須并行演化。

因此，構(gòu)架設(shè)計師通過某種表現(xiàn)形式來描述系統(tǒng)。這種表現(xiàn)形式(即構(gòu)架)的設(shè)計必須使系統(tǒng)能夠演化，不僅要考慮系統(tǒng)的初始開發(fā)，而且要考慮系統(tǒng)將來的擴展。要想找到這樣的表現(xiàn)形式，構(gòu)架設(shè)計師必須全面了解系統(tǒng)的主要功能(即主要用例)。主要用例的數(shù)量可能只占所有用例的5%～10%，但卻十分重要，它們構(gòu)成了系統(tǒng)的核心功能。

3．迭代和增量的過程

開發(fā)商業(yè)軟件產(chǎn)品是一項艱巨的任務(wù)，可能會持續(xù)幾個月甚至一年以上。因此，通常將一個大項目劃分為較小的部分或一系列小項目，每個小項目能夠進行一次迭代并產(chǎn)生一個增量。迭代指工作流中的步驟，而增量是指產(chǎn)品中增加的部分。要想獲得最佳效果，迭代過程必須是受控的，也就是說，必須按照計劃好的步驟有選擇地執(zhí)行。

在每次迭代過程中，開發(fā)人員標識并詳細描述有關(guān)的用例，以選定的構(gòu)架為向?qū)韯?chuàng)建設(shè)計，用構(gòu)件來實現(xiàn)設(shè)計，并驗證這些構(gòu)件是否滿足用例。如果一次迭代達到了目標，開發(fā)工作便可以進入下一次迭代。如果一次迭代未能達到預期的目標，開發(fā)人員必須重新審查前面的方案，并嘗試新的方法。

用例驅(qū)動、以構(gòu)架為中心以及迭代和增量開發(fā)的概念是同等重要的，構(gòu)成了統(tǒng)一過程的核心。構(gòu)架提供一種結(jié)構(gòu)來指導迭代過程中的工作，而用例則確定目標并驅(qū)動每次迭代工作的進行。

7.4.2統(tǒng)一過程生命周期

統(tǒng)一過程是由一系列循環(huán)組成的系統(tǒng)生命周期，如圖7-6所示，每次循環(huán)都向用戶提供一個產(chǎn)品版本或增量。

圖7-6由循環(huán)組成的產(chǎn)生到消亡的過程生命周期

每次循環(huán)都包括四個階段：初始、細化、構(gòu)造和移交，每個階段進一步細分為上面提到的多次迭代過程，如圖7-7所示。

圖7-7一次循環(huán)所包含的階段和迭代

1.產(chǎn)品

產(chǎn)品也稱工件或制品。每次循環(huán)都產(chǎn)生系統(tǒng)的一個新版本，每個版本都是一個準備交付的產(chǎn)品，包括由能夠編譯和運行的構(gòu)件所體現(xiàn)的源代碼、各種手冊和相關(guān)的制品。完成的產(chǎn)品不僅要滿足各種用戶的需求，還要滿足所有產(chǎn)品相關(guān)人員的各種需求。因此，軟件產(chǎn)品不應該僅僅是可以運行的程序。

完成的產(chǎn)品包括功能需求、用例、非功能性需求和測試用例，還包括構(gòu)架和可視化的模型(即用UML建立的模型化制品)。通過這些元素，所有產(chǎn)品相關(guān)人員(客戶、用戶、分析人員、設(shè)計人員、實現(xiàn)人員、測試人員和管理人員等)能夠詳細描述、設(shè)計、實現(xiàn)、測試和使用系統(tǒng)。而且，正是這些元素才使產(chǎn)品相關(guān)人員能夠使用迭代來更新系統(tǒng)。

盡管對用戶來說可執(zhí)行的構(gòu)件是最重要的制品，但是只有這些是遠遠不夠的，因為環(huán)境在不斷變化。操作系統(tǒng)、數(shù)據(jù)庫和作為基礎(chǔ)的計算機都在不斷發(fā)展，此外，隨著更深入地了解任務(wù)，需求本身可能會發(fā)生變化。為了高效地完成這一循環(huán)過程，開發(fā)人員需要該軟件產(chǎn)品的所有制品，如圖7-8所示。

圖7-8所示模型表示模型之間具有跟蹤依賴關(guān)系，虛線表示了用例模型和其他模型之間的跟蹤依賴關(guān)系。

用例模型：包含所有用例及其與參與者之間的關(guān)系；

分析模型：有兩方面的作用，即更詳細地提煉用例，將系統(tǒng)的行為初步分配給提供行為的一組對象；

設(shè)計模型：將系統(tǒng)靜態(tài)結(jié)構(gòu)定義為子系統(tǒng)、類和接口，并定義由子系統(tǒng)、類和接口之間的協(xié)作所實現(xiàn)的用例；

實施模型：定義計算機的物理節(jié)點和構(gòu)件到這些節(jié)點的映射；

實現(xiàn)模型：包括構(gòu)件(表現(xiàn)為源代碼)和類到構(gòu)件的映

射；

測試模型：描述用于驗證用例的測試用例。

圖7-8統(tǒng)一過程的模型

當然，該模型還包括構(gòu)架的表示，還可能包括描述系統(tǒng)業(yè)務(wù)情境的領(lǐng)域模型或業(yè)務(wù)模型。

所有這些模型都是相關(guān)的，表達的是系統(tǒng)的某個側(cè)面，合起來描述整個系統(tǒng)。模型元素到其他模型的鏈表明了模型中的元素前后之間存在跟蹤依賴關(guān)系。例如，用例可以跟蹤到用例的分析、設(shè)計、實現(xiàn)和部署，再跟蹤到測試用例，這有助于系統(tǒng)的理解和修改。

2.階段

每次循環(huán)都要經(jīng)歷一定的時間，可分為四個階段，如圖7-9所示。通過模型，所有與產(chǎn)品相關(guān)的人員都可以看到每個階段中要發(fā)生的事情。每個階段，管理人員或開發(fā)人員又可以將本階段工作進一步細分為多次迭代過程以及每次迭代所產(chǎn)生的增量，每個階段都以里程碑作為結(jié)束標志。

圖7-9左側(cè)列出了開發(fā)過程的工作流—需求、分析、設(shè)計、實現(xiàn)和測試。曲線圖近似描述了工作流在每個階段中的完成情況。每個階段通常又進一步細分為多次迭代過程或小項目。典型的迭代過程經(jīng)歷全部五種工作流，圖7-9中標出了細化階段的一次迭代。

(1)初始階段(InceptionPhase)：提出將一個想法開發(fā)為最終產(chǎn)品的構(gòu)想，指出產(chǎn)品的業(yè)務(wù)實例。本質(zhì)上，該階段回答下面的問題：

系統(tǒng)為主要用戶提供的基本功能是什么？

系統(tǒng)的構(gòu)架看起來是什么樣子的？

開發(fā)產(chǎn)品的計劃如何？開銷多大？

圖7.9RUP統(tǒng)一軟件開發(fā)過程

(2)細化階段(ElaborationPhase)：詳細說明產(chǎn)品的絕大多數(shù)用例，并設(shè)計系統(tǒng)構(gòu)架。系統(tǒng)構(gòu)架和系統(tǒng)本身的關(guān)系是至關(guān)重要的，構(gòu)架就像是由皮膚所覆蓋的骨架，在皮膚和骨骼之間只有很少量骨架產(chǎn)生基本動作的肌肉(即軟件)，系統(tǒng)則是包括了骨架、皮膚和肌肉的整個軀體，所以，構(gòu)架表示為系統(tǒng)中所有模型的不同視圖，合起來表示整個系統(tǒng)，這意味著構(gòu)架包括了用例模型、分析模型、設(shè)計模型、實現(xiàn)模型和實施模型的視圖。實現(xiàn)模型的視圖包含了一些構(gòu)件，以證明構(gòu)架是可以運行的。在這個階段所確定的關(guān)鍵用例都要在這個階段具體化，該階段的結(jié)果是構(gòu)架基線(通過評審的構(gòu)架)。

細化階段末期，項目經(jīng)理要規(guī)劃完成項目的活動，估算完成項目所需的資源。關(guān)鍵問題是：用例、構(gòu)架和計劃是否足夠穩(wěn)定可靠，風險是否得到充分控制，以便能夠按照合同的規(guī)定完成整個開發(fā)任務(wù)。

(3)構(gòu)造階段(ConstructionPhase)：將構(gòu)造最終產(chǎn)品—為骨架(構(gòu)架)增加肌肉(完成的軟件)。這個階段，構(gòu)架基線逐漸開發(fā)成完善的系統(tǒng)，初始階段形成的構(gòu)想演化成一個準備移交給用戶的產(chǎn)品。這個階段，會消耗所需的大部分資源。盡管開發(fā)人員可能發(fā)現(xiàn)更好的構(gòu)造系統(tǒng)的方法，可能會建議構(gòu)架設(shè)計師對構(gòu)架進行細微變動，系統(tǒng)構(gòu)架仍然是穩(wěn)定可靠的。這個階段末期，產(chǎn)品將包括管理層和客戶對發(fā)布的版本達成共識的所有用例。產(chǎn)品不可能是完全沒有缺陷的，很多缺陷將在移交階段發(fā)現(xiàn)和改正。里程碑處要回答的問題是，早期交付給客戶的產(chǎn)品是否完全滿足了用戶的需求？

(4)移交階段(TransitionPhase)：包括了產(chǎn)品進入β版本的整個階段。β版本期間，少數(shù)有經(jīng)驗的用戶試用產(chǎn)品并報告產(chǎn)品的缺陷和不足，開發(fā)人員則改正所報告的問題，并將部分改進建議嵌入到通用版本中。移交階段包括制作手冊、用戶培訓、提供在線支持以及改正缺陷等活動。

3.統(tǒng)一過程是一個綜合的過程

統(tǒng)一過程是基于構(gòu)件的，采用可視化建模標準，即統(tǒng)一建模語言(UML)，依賴三個關(guān)鍵內(nèi)容——用例、構(gòu)架以及迭代和增量開發(fā)。要使這些思想能夠發(fā)揮作用，需要一個包括多方面的過程，要考慮到生命周期、階段、工作流、風險緩解、質(zhì)量控制、項目管理和配置管理等。統(tǒng)一過程建立了集成所有這些方面的框架，在框架下，工具廠商和開發(fā)人員可以借助生產(chǎn)工具來支持過程自動化，支持專門的工作流，構(gòu)造所有不同的模型，完成跨越生命周期和所有模型的集成工作。

7.4.3統(tǒng)一建模語言

可視化建模技術(shù)在軟件開發(fā)中正日益扮演著越來越重要的角色。為了便于交流，選擇一種合適的建模語言就顯得至關(guān)重要，統(tǒng)一建模語言就是一種最佳的選擇。

統(tǒng)一建模語言(UnifiedModelingLanguage，UML)是對象管理組織(ObjectManagementGroup,OMG)制定的一個通用的、可視化的建模語言標準，可以用來可視化(Visualize)、描述(Specify)、構(gòu)造(Construct)和文檔化(Document)軟件密集型系統(tǒng)的各種工件(Artifacts)。

它是由信息系統(tǒng)和面向?qū)ο箢I(lǐng)域的三位著名的方法學家GradyBooch、JamesRumbaugh和IvarJacobson(threeAmigos，三友)提出的。這種建模語言已經(jīng)得到了工業(yè)界的廣泛支持和應用，目前已經(jīng)成為ISO國際標準。在選擇UML建模時，需要注意以下幾個方面的問題：

(1)

UML不是一種程序設(shè)計語言，而是一種可視化的建模語言。它比C++、Java這樣的程序設(shè)計語言抽象層次更高，可以適用于任何面向?qū)ο蟮某绦蛟O(shè)計語言。

(2)

UML不是工具或知識庫的規(guī)格說明，而是一種建模語言規(guī)格說明，是一種表示模型的標準。

(3)

UML不是過程，也不是方法，但允許任何一種過程和方法使用它。

UML的產(chǎn)生經(jīng)歷了一個漫長的發(fā)展歷程。從20世紀80年代初期開始，眾多的方法學家都在嘗試用不同的方法進行面向?qū)ο蟮姆治雠c設(shè)計。許多方法開始在一些項目中發(fā)揮作用，如Booch、OMT、Shlaer/Mellor、Odell/Martin\RDD\Objectory等。到了20世紀90年代中期出現(xiàn)了比較完善的面向?qū)ο蠓椒ǎ挠蠦ooch94、OMT-2、OOSE、Fusion等，那時面向?qū)ο蠓椒ㄒ呀?jīng)成為軟件分析和設(shè)計方法的主流。

1994年10月，GradyBooch和JamesRumbaugh開始致力于這一工作。他們首先將Booch93和OMT-2統(tǒng)一起來，并于1995年10月發(fā)布了第一個公開版本，稱之為統(tǒng)一方法UM(UnifiedMethod)0.8。1995年秋，OOSE的創(chuàng)始人IvarJacobson加盟這一工作。經(jīng)過Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分別發(fā)布了兩個新的版本，即UML0.9和UML0.91，并將UM重新命名為UML(UnifiedModelingLanguage)。之后，UML在OMG的管理下不斷發(fā)展，相繼推出了1.2、1.3、1.4、1.5、2.0、2.1.1、2.1.2、2.2、2.3、2.4、2.4.1等多個版本，并最終成為ISO國際標準，其中UML1.4.2對應于ISO/IEC19501:2005國際標準，而UML2.1.2及后續(xù)版本對應于ISO/IEC19505-1:2012(基礎(chǔ)結(jié)構(gòu))和ISO/IEC19505-2:2012(上層結(jié)構(gòu))。UML的發(fā)展過程可用圖7-10來表示。

UML是一種定義良好、易于表達、功能強大且普遍適用的建模語言，融入了軟件工程領(lǐng)域的新思想、新方法和新技術(shù)，其作用域不限于支持面向?qū)ο蟮姆治雠c設(shè)計，還支持從需求分析開始的軟件開發(fā)的全過程。

圖7-10UML的產(chǎn)生和發(fā)展歷程

作為一種建模語言，UML包括UML語義和UML表示法兩個部分。

(1)

UML語義：描述基于UML的精確元模型定義。元模型為UML的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明，使開發(fā)者能在語義上取得一致，消除了因人而異的最佳表達方法所造成的影響。此外，UML還支持對元模型的擴展定義。

(2)

UML表示法：定義UML符號的表示法，為開發(fā)者或開發(fā)工具使用這些圖形符號和文本語法為系統(tǒng)建模提供了標準。這些圖形符號和文字所表達的是應用級的模型，在語義上是UML元模型的實例。

標準建模語言UML的重要內(nèi)容可以由五類圖來定義。

(1)用例圖(UseCaseDiagram)，從用戶角度描述系統(tǒng)功能，并指出各種功能的操作者。

(2)靜態(tài)圖(StaticDiagram)，包括類圖、對象圖和包圖。

(3)行為圖(BehaviorDiagram)，描述系統(tǒng)的動態(tài)模型和組成對象間的交互關(guān)系。行為圖包括：狀態(tài)圖、活動圖、順序圖和通信圖。

(4)交互圖(InteractiveDiagram)，描述對象間的交互關(guān)系。其中順序圖顯示對象之間的動態(tài)合作關(guān)系，強調(diào)對象之間消息發(fā)送的順序，同時顯示對象之間的交互；通信圖描述對象之間的協(xié)作關(guān)系，通信圖跟順序圖相似，顯示對象間的動態(tài)合作關(guān)系。除顯示信息交換外，通信圖還顯示對象以及它們之間的關(guān)系。如果強調(diào)時間和順序，則使用順序圖；如果強調(diào)上下級關(guān)系，則選擇通信圖。這兩種圖合稱為交互圖。

(5)實現(xiàn)圖(ImplementationDiagram)。實現(xiàn)圖主要包含構(gòu)件圖和部署圖。

從應用的角度看，當采用面向?qū)ο蠹夹g(shù)設(shè)計系統(tǒng)時，首先是描述需求；其次根據(jù)需求建立系統(tǒng)的靜態(tài)模型，以構(gòu)造系統(tǒng)的結(jié)構(gòu)；第三步是描述系統(tǒng)的行為。其中在第一步與第二步中所建立的模型都是靜態(tài)的，包括用例圖、類圖(包含包)、對象圖、構(gòu)件圖和部署圖等五個圖形，是標準建模語言UML的靜態(tài)建模機制。

第三步中所建立的模型或者可以執(zhí)行，或者表示執(zhí)行時的時序狀態(tài)或交互關(guān)系，包括狀態(tài)圖、活動圖、順序圖和通信圖等圖形，是標準建模語言UML的動態(tài)建模機制。因此，標準建模語言UML的主要內(nèi)容也可以歸納為靜態(tài)建模機制和動態(tài)建模機制兩大類。

UML的目標是以面向?qū)ο髨D的方式來描述任何類型的系統(tǒng)，具有很寬的應用領(lǐng)域。其中最常用的是建立軟件系統(tǒng)的模型，但也同樣可以用于描述非軟件領(lǐng)域的系統(tǒng)，如機械系統(tǒng)、企業(yè)機構(gòu)或業(yè)務(wù)過程，以及處理復雜數(shù)據(jù)的信息系統(tǒng)、具有實時要求的工業(yè)系統(tǒng)或工業(yè)過程等。總之，UML是一個通用的標準建模語言，可以對任何具有靜態(tài)結(jié)構(gòu)和動態(tài)行為的系統(tǒng)進行建模，它適用于以面向?qū)ο蠹夹g(shù)來描述任何類型的系統(tǒng)，而且適用于系統(tǒng)開發(fā)的不同階段，從需求規(guī)格描述直至系統(tǒng)完成后的測試和維護。

7.5迭代和增量過程

軟件過程要做到更有效，則需要有一系列非常清晰的里程碑，以便為項目經(jīng)理和項目組的其他人員提供一個準則，以此來認可產(chǎn)品周期是否可以從一個階段進入下一個階段。

在每個階段中，過程需要經(jīng)歷一系列的迭代和增量來滿足這些準則。

(1)初始階段的根本準則是可行性，通過下面的方式達到：

確定并降低影響系統(tǒng)可行性的關(guān)鍵風險；

通過用例建模將需求的關(guān)鍵子集轉(zhuǎn)化為候選構(gòu)架；

在寬限條件下，對成本、工作量、進度和產(chǎn)品質(zhì)量進行初步估計；

在寬限條件下，開始對值得做的項目創(chuàng)建業(yè)務(wù)案例。

(2)細化階段的根本準則是在經(jīng)濟框架內(nèi)構(gòu)造系統(tǒng)的能力，通過下面的方式達到：

確定并降低對系統(tǒng)構(gòu)造有重大影響的風險；

確定代表待開發(fā)功能的大部分用例；

將候選構(gòu)架擴展為可執(zhí)行的基線部分；

制定足夠詳細的項目計劃來指導構(gòu)造階段；

在較嚴的條件下進行估計，以便調(diào)整項目的商業(yè)報價；

對值得做的項目確定業(yè)務(wù)案例的最終方案。

(3)構(gòu)造階段的根本準則是使系統(tǒng)能夠在用戶環(huán)境下完成最初的操作，需要通過一系列迭代，得到周期性的構(gòu)造和增量。這樣在完成該階段時，系統(tǒng)可行性便會以可執(zhí)行的形式明確表現(xiàn)出來。

(4)移交階段的根本準則是得到一個達到最終操作能力的系統(tǒng)，通過下面的方式達到：

修改產(chǎn)品以緩解在早期階段沒有發(fā)現(xiàn)的問題；

修正缺陷。

一般來說，統(tǒng)一過程的目標之一是使構(gòu)架設(shè)計師、開發(fā)人員和其他項目相關(guān)人員了解到早期階段的重要性。

7.5.1為什么采用迭代和增量的開發(fā)方法

采用迭代和增量的開發(fā)方法的目的是為了得到更好的軟件，詳細來說，就是為了達到用來控制開發(fā)的主里程碑和次里程碑。下面是更多的理由：

為了盡早處理關(guān)鍵風險和重要風險；

為了建立一個構(gòu)架來指導軟件開發(fā)；

為了更好地處理不可避免的需求以及其他變化而提供一個框架；

為了隨時間而遞增地構(gòu)建系統(tǒng)，而不是在臨結(jié)束時才一下子建成一個系統(tǒng)，那時候的改變需要付出很大的代價。

為了提供一個開發(fā)過程，使所有工作人員可以更高效地工作。

1．降低風險

與任何工程活動一樣，軟件開發(fā)也會遇到風險。在軟件開發(fā)中，應盡可能早地確定風險并迅速做出處理來解決這個問題。風險是會導致?lián)p失或危害的一種潛在的可能性，風險是構(gòu)成危險的因素、事件、要素或進程，其危害程度是不確定的，一旦發(fā)生會造成損失。在軟件開發(fā)中，可以將風險定義為一個需要關(guān)注的問題，在一定程度上可能會危及項目的成功。下面是幾個風險的例子。

最初考慮的對象請求代理可能無法處理每秒鐘1000個“遠程客戶賬戶”對象的查詢請求；

實時系統(tǒng)可能需要一些沒有在細化階段確定的數(shù)據(jù)輸入，可能需要通過大量的但無法確定細節(jié)的計算來處理這些數(shù)據(jù)，可能在一個較短但目前尚不能確定的時間內(nèi)發(fā)出一個命令信號；

電話交換系統(tǒng)可能必須在幾毫秒內(nèi)響應由電信業(yè)務(wù)公司定義的各種輸入。

統(tǒng)一過程是風險驅(qū)動方法的，而不是文檔驅(qū)動或代碼驅(qū)動的，在前兩個階段(初始和細化階段)中便致力于解決主要風險，在構(gòu)造階段的早期按照風險的重要順序逐個解決其余的風險。在早期階段通過迭代來標識、管理并降低風險。因此，未經(jīng)確定的或忽略的風險不會在后期突然出現(xiàn)并危害整個項目。

風險的處理能力和開發(fā)時間之間的關(guān)系如圖7-11所示。從圖中可以發(fā)現(xiàn)，迭代開發(fā)從最初的迭代開始便著手降低關(guān)鍵風險，到達構(gòu)造階段時，已經(jīng)沒有什么重大風險了，工作得以順利進行。相反，使用瀑布模型，重大風險直到代碼集成階段“大爆發(fā)”時才得到處理。

圖7-11風險的處理能力和開發(fā)時間之間的關(guān)系

2．獲得健壯的構(gòu)架

得到一個健壯的構(gòu)架是早期階段迭代的結(jié)果。例如，在初始階段，尋找一個能滿足關(guān)鍵需求、克服關(guān)鍵風險和解決開發(fā)中主要問題的核心構(gòu)架；在細化階段，進一步建立構(gòu)架基線，以指導后續(xù)的開發(fā)。

這些階段的投資還比較少，能夠負擔得起確保構(gòu)架健壯性的迭代。例如，在細化階段的第一次迭代后，可以對構(gòu)架進行初步評估，如果發(fā)現(xiàn)需要對構(gòu)架進行改變以滿足重要用例的需要和非功能性需求，還能負擔得起。

如果沿用瀑布方法，到發(fā)現(xiàn)需要對構(gòu)架進行改變時，已經(jīng)在開發(fā)上投資太多以致于改變構(gòu)架會導致嚴重的經(jīng)濟損失，而且已臨近合同的交付日期，由于成本和進度的制約，不能主動對構(gòu)架進行大的改變。在細化階段側(cè)重于創(chuàng)建構(gòu)架，可以避免這種進退兩難的局面。在生命周期早期，便將構(gòu)架穩(wěn)定在基線級，此時，成本仍然比較低，而且在進度上還有伸縮的余地。

3．處理不斷變化的需求

在早期階段，系統(tǒng)部分地運行可使用戶和其他項目相關(guān)人員提供建議并指出可能忽略的需求；當項目計劃、預算和進度表還沒有最終確定下來時，開發(fā)人員很容易進行修正。在單向的瀑布模型中，用戶直到集成和測試階段才能看到可運行的系統(tǒng)，這時，即使是那些有價值或看起來很小的改變，幾乎總會不可避免地增加投資或拖延進度。因此，迭代生命周期更易于客戶在開發(fā)周期中盡早了解需要增加或改變的需求，也使開發(fā)人員更容易進行相應的修改。歸根到底，按照一系列迭代進行系統(tǒng)構(gòu)造、響應反饋或進行修改只是對一個增量進行的修改或改變，不會影響其他部分。

4．允許靈活改變

采用迭代和增量的方法，開發(fā)人員可以解決前期構(gòu)造中發(fā)現(xiàn)的問題，并能立刻做出改變來糾正這些問題。使用這種方法，可以逐漸發(fā)現(xiàn)問題，開發(fā)人員可以及時糾正這些問題。在瀑布模型中，在“爆發(fā)”的集成階段大量涌現(xiàn)出的錯誤報告經(jīng)常會中斷項目的進展。如果這種中斷很嚴重，項目可能會終止，開發(fā)人員由于壓力而垂頭喪氣，項目經(jīng)理焦頭爛額，其他管理人員也手足無措。相反，一系列可運行的構(gòu)造結(jié)果會給所有人帶來成就感。

5．實現(xiàn)持續(xù)的集成

在每次迭代的最后，項目組要明確已經(jīng)降低了一些風險。每次迭代后，項目組均交付遞增的功能，使項目相關(guān)的所有人員都能清楚地了解項目的進展情況。即使開發(fā)人員在早期迭代過程中未能得到計劃的結(jié)果，仍有時間在后續(xù)的內(nèi)部版本中重試和改進模型。

圖7-12中的粗線表明迭代開發(fā)是如何進行的。在進度表的開始，這時的項目代碼只有2%到4%，將一個增量(或構(gòu)造)組合起來。這種嘗試會出現(xiàn)一些問題，由圖中進度線的下降表示，但很快會得到解決，項目繼續(xù)向前進行。此后，項目進行頻繁的構(gòu)造，每次構(gòu)造都可能導致進程中一次暫時的停頓，與整個產(chǎn)品的最終集成相比，增量相對較小，所以恢復起來很快。

圖7-12迭代增量開發(fā)與瀑布方法發(fā)現(xiàn)問題能力的對比

如圖7-12所示，在瀑布方法中(細線)，開發(fā)人員直到完成了需求、分析和設(shè)計才開始實現(xiàn)工作。即使實現(xiàn)過程進展順利，因為沒有中間構(gòu)造來說明其工作有誤，實際上問題隱藏得很深，直到集成和測試階段才完全暴露出來(后期暴露設(shè)計問題)。在迭代開發(fā)中，實現(xiàn)開始得較早，頻繁的構(gòu)造不僅能盡早發(fā)現(xiàn)問題，而且發(fā)現(xiàn)的問題數(shù)量不大，也易于處理。

在瀑布方法中，接近交付日期時一次性的集成暴露出大量問題。此時，因為問題太多和不可回避的交付期限，導致很多問題的修正無法考慮周全，查找并糾正問題常常耽擱了按計劃日期交付。因此，迭代開發(fā)能夠比瀑布方法在更少的規(guī)劃時間內(nèi)完成，而且，“瀑布項目”的產(chǎn)品可能是脆弱和難以維護的。

6．盡早得到相關(guān)的知識

經(jīng)過幾次迭代之后，開發(fā)組的每個人都對不同工作流的含義有了深入的理解，他們知道有了需求后該做什么，分析后該做什么，大大降低了“分析停頓”(分析花費的時間太多)的風險。

此外，培訓新的人員會更容易，因為他們能夠通過工作本身得到訓練，無須設(shè)置專門的培訓來幫助他們理解過程，他們可以直接進入與任務(wù)相關(guān)的工作。如果新手不能理解要點或做錯了，對整個項目的最后進度也不會造成重大影響，因為在進行下次構(gòu)造時問題就會顯現(xiàn)出來。

迭代方法還有助于項目處理非技術(shù)性風險，如組織風險。例如，開發(fā)人員可能沒有盡快了解下面的問題：

如何使用對象請求代理建立應用程序；

如何使用測試或配置管理工具；

如何根據(jù)軟件開發(fā)過程進行工作。

通過階段性的迭代工作，開發(fā)人員能更好地滿足實際用戶需要和降低風險。通過增量式構(gòu)造，所有有關(guān)人員都能夠注意開發(fā)的進展程度。通過減少后期困難，加速上市時間。此外，迭代方法不僅對開發(fā)人員，而且最終對用戶和經(jīng)理都是有益的，經(jīng)理通過關(guān)注完成的迭代能夠看到實際的進展。

7.5.2迭代方法是風險驅(qū)動的

風險是威脅或阻礙項目成功的不定因素，是項目經(jīng)理不希望發(fā)生的事件(如進度延期、成本超支或放棄)的可能性，這些事件一旦發(fā)生，會造成損失。

根據(jù)風險及其重要性的先后順序確定、排序并執(zhí)行迭代。在以下幾種情況下都需要處理風險：在評價新技術(shù)時；為滿足客戶的需要(無論是功能性的還是非功能性的)而工作時；在早期階段建立一個健壯的構(gòu)架時(允許進行改變而不必冒重新設(shè)計某些部分的風險)。的確，通過迭代可以減少風險。

其他重要的風險是性能(速度、容量、準確度)、可靠性、可用性、系統(tǒng)界面統(tǒng)一性、適應性和可移植性等方面的問題，這類風險直到實現(xiàn)和測試底層功能時才暴露出來。這就是為什么需要通過迭代首先在初始和細化階段，然后一直到編碼和測試階段都要探查風險的原因，這樣做的目的就是在早期迭代中確定風險。

降低風險是初始和細化階段迭代工作的核心。在構(gòu)造階段，風險在很大程度上已經(jīng)降低到了一個常規(guī)的級別，已經(jīng)能夠由一般的開發(fā)活動來解決。組織迭代過程時，應設(shè)法對其進行排序，以使每個構(gòu)造可以在前一個構(gòu)造的基礎(chǔ)上建造。這樣可以設(shè)法避免風險，特別是那些因迭代順序不妥而造成的風險。

7.5.3通用迭代過程

開發(fā)人員在每個階段面臨的挑戰(zhàn)不一樣，因此，開發(fā)周期中不同階段的迭代過程明顯不同。這里從通用的觀點介紹迭代的基本概念。

1．迭代是什么

這里，把一次迭代看作是一個能夠產(chǎn)生內(nèi)部版本的袖珍項目——或多或少要經(jīng)歷所有的核心工作流，是一種使用和生產(chǎn)制品的工作人員之間的協(xié)作。在統(tǒng)一過程中，分為核心工作流和迭代工作流?，F(xiàn)在，已經(jīng)知道有五種核心工作流：需求、分析、設(shè)計、實現(xiàn)和測試。這些核心工作流只是出于教學目的，幫助描述迭代工作流的。因此，關(guān)于核心工作流的構(gòu)成沒有什么奇妙的。采用另外一組核心工作流可能同樣簡單，例如把分析和設(shè)計結(jié)合在一起的核心工作流。核心工作流用來簡化對具體工作流的描述，就像抽象類有助于描述具體類一樣。具體的工作流就是迭代工作流。

在圖7-13中，描述了迭代工作流的一般元素。每次迭代都經(jīng)歷五種核心工作流，而且都是從規(guī)劃開始、以評估結(jié)束。每次迭代都重用了核心工作流的描述，只是處于不同時期的處理方式不同。

早期迭代側(cè)重于了解問題和技術(shù)。在初始階段，迭代過程關(guān)注的是獲得一個業(yè)務(wù)案例；在細化階段，迭代的目的是進行構(gòu)架基線的開發(fā)；在構(gòu)造階段，迭代過程通過每次迭代中的一系列構(gòu)造創(chuàng)建產(chǎn)品，直到得到準備交付給用戶組織的產(chǎn)品。每次迭代都按照同樣的模式，如圖7-13所示。

特別應該注意的一個活動是回歸測試。在完成一次迭代前，要確保不會破壞以前迭代中實現(xiàn)的系統(tǒng)的其他部分?；貧w測試在迭代、增量的生命周期中尤為重要，因為每次迭代都會對前面的增量進行相當?shù)难a充和修改。如果沒有合適的測試工具，完成如此大規(guī)模(因為每次迭代都會產(chǎn)生一個構(gòu)造)的回歸測試是不現(xiàn)實的。

項目經(jīng)理在當前迭代目標未達到之前不應該同意開始下一次迭代，否則，就會導致必須改變計劃來適應新的情況。

圖7-13每次迭代要經(jīng)歷的五種核心工作流

2．規(guī)劃迭代過程

迭代開發(fā)比瀑布方法需要更多的規(guī)劃和考慮。在瀑布模型中，在降低風險和確定構(gòu)架前就預先制定好所有的計劃，制定的計劃基于很多不確定性，因而缺少真實性。相反，迭代方法在初始階段并不對整個項目進行詳細規(guī)劃，只是對最初的幾步進行規(guī)劃，直到在細化階段建立了事實的基礎(chǔ)，項目組才試圖對構(gòu)造和移交階段進行規(guī)劃。當然，前兩個階段也有工作計劃，但不太詳細。

除了在項目的剛開始，通常規(guī)劃工作要考慮以前的迭代結(jié)果、與新的迭代相關(guān)的用例選取、出現(xiàn)在下一次迭代中的風險現(xiàn)狀以及模型集合的最新版本等，以要發(fā)布的內(nèi)部版本作為結(jié)束。

3．確定迭代次序

自然界的進化是在沒有預先進行規(guī)劃的情況下發(fā)生的，而軟件迭代卻不能這樣?？梢哉J為，用例設(shè)定了開發(fā)的目標，構(gòu)架建立了開發(fā)的模式。根據(jù)用例和構(gòu)架，開發(fā)人員就可以規(guī)劃出進行產(chǎn)品開發(fā)的順序。

在一次迭代將要結(jié)束而另一次迭代即將開始時，迭代過程可能出現(xiàn)交疊，如圖7-14所示，在結(jié)束前一次迭代并準備發(fā)布時，可以開始規(guī)劃并提早進行下一次迭代的工作。但是不能交疊得太多，因為上一次迭代畢竟是下一次迭代的基礎(chǔ)。結(jié)束一次迭代意味著在開發(fā)組內(nèi)已經(jīng)獲得了一次結(jié)果，即對這次迭代中的所有軟件進行了集成并在內(nèi)部發(fā)布。

圖7-14迭代過程出現(xiàn)的交疊

在很大程度上，規(guī)劃的迭代次序依賴于技術(shù)因素，但最重要的目標是確定工作順序，以便能盡早做出最重要的決定，即涉及新技術(shù)、用例和構(gòu)架的決定。

7.5.4一次迭代產(chǎn)生一個增量結(jié)果

一個增量是一次迭代的內(nèi)部版本與下一次迭代的內(nèi)部版本之間的差別。

在迭代結(jié)束時，表示系統(tǒng)的模型集合處于一種特定的狀態(tài)，這種狀態(tài)或狀況稱為基線(baseline)。每種模型都已經(jīng)達到一條基線，每個基本模型的元素處于基線狀態(tài)。例如，每次迭代最后的用例模型都包含了一個用例集合，代表迭代過程已經(jīng)實現(xiàn)需求的程度。這個集合中的一些用例已經(jīng)完成了，而另一些用例只是部分完成。

同時，設(shè)計模型已經(jīng)達到了與用例模型一致的基線狀態(tài)。設(shè)計模型的子系統(tǒng)、接口和用例實現(xiàn)也處于彼此相互一致的基線狀態(tài)。為了在項目中有效地處理多條基線，開發(fā)組織需要在一條基線中維持所有制品一致的和兼容的版本。在迭代開發(fā)時，不能過分強調(diào)配置管理工具的有效性。

在迭代序列內(nèi)的任一點，有些子系統(tǒng)已經(jīng)完成了，它們包含所規(guī)定的功能，而且已經(jīng)得以實現(xiàn)并經(jīng)過了測試，其他的子系統(tǒng)只是部分完成，還有一些子系統(tǒng)仍然空著，盡管確實有樁程序(stubs)，也可以運行并與其他子系統(tǒng)集成在一起。因此，用更精確的術(shù)語來說，一個增量是兩次相繼的基線之間的差別。

在細化階段已經(jīng)建立了構(gòu)架基線，確定對構(gòu)架有重要影響的用例，然后把這些用例按照協(xié)作來實現(xiàn)，這是確定大多數(shù)子系統(tǒng)和接口(至少是對構(gòu)架有意義的子系統(tǒng)和接口)的方法。只要確定了大多數(shù)的子系統(tǒng)和接口，就可以增添“血肉”，編寫實現(xiàn)代碼。其中，有些工作在發(fā)布構(gòu)架基線前就完成了，并將繼續(xù)貫穿于所有的工作流，但是