第7章

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

知識(shí)點(diǎn)

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

難點(diǎn)

迭代和增量過(guò)程。

基于工作過(guò)程的教學(xué)任務(wù)

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

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

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

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

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

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

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

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

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

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

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

對(duì)事物進(jìn)行分類(lèi)，把具有相同屬性和相同操作的對(duì)象歸為一類(lèi)，類(lèi)是相似對(duì)象的抽象描述，每個(gè)對(duì)象是類(lèi)的一個(gè)實(shí)例；

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

復(fù)雜的對(duì)象可以用簡(jiǎn)單的對(duì)象組合而成(聚合)；

對(duì)象之間通過(guò)消息進(jìn)行通信，以實(shí)現(xiàn)對(duì)象之間的動(dòng)態(tài)聯(lián)系；

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

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

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

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

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

用對(duì)象作為建模的原子；

用來(lái)描述一些基于下述概念的東西：封裝、對(duì)象(對(duì)象的標(biāo)識(shí)、屬性和操作)、消息傳遞、類(lèi)、繼承、多態(tài)、動(dòng)態(tài)綁定；

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

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

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

7.2從認(rèn)識(shí)論看面向?qū)ο蠓椒ǖ男纬?/p>

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

7.2.1軟件開(kāi)發(fā)—對(duì)事物的認(rèn)識(shí)和描述

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

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

所謂“描述”，是指用一種語(yǔ)言把人們對(duì)問(wèn)題域的認(rèn)識(shí)、對(duì)問(wèn)題及其解決方案的認(rèn)識(shí)描述出來(lái)，最終描述必須使用計(jì)算機(jī)讀得懂的語(yǔ)言，即編程語(yǔ)言。

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

7.2.2語(yǔ)言的鴻溝

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

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

圖7-1認(rèn)識(shí)和描述之間的鴻溝

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

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

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

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

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

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

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

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

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

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

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

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

7.2.4軟件工程學(xué)的作用

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

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

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

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

1)需求分析

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

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

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

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

3)實(shí)現(xiàn)、測(cè)試和維護(hù)

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

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

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

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

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

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

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

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

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

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

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

3)面向?qū)ο蟮膶?shí)現(xiàn)

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

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

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

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

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

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

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

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

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

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

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

1．對(duì)象

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

2．類(lèi)

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

3．消息

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

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

1．封裝性

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

2．繼承性

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

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

3．多態(tài)性

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

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

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

7.4統(tǒng)一過(guò)程與統(tǒng)一建模語(yǔ)言

圖7-5軟件開(kāi)發(fā)過(guò)程

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

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

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

1．用例驅(qū)動(dòng)

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

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

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

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

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

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

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

用例和構(gòu)架是如何相關(guān)的呢？每種產(chǎn)品都有功能和表現(xiàn)形式兩方面的特征，只具備其中的一個(gè)方面是不夠的，對(duì)這兩個(gè)方面必須權(quán)衡才能得到成功的產(chǎn)品，這里的功能與用例對(duì)應(yīng)，表現(xiàn)形式與構(gòu)架對(duì)應(yīng)。用例和構(gòu)架之間是相互影響的，這是一個(gè)“雞與蛋”的問(wèn)題。一方面，用例在實(shí)現(xiàn)時(shí)必須適合構(gòu)架；另一方面，構(gòu)架必須預(yù)留空間以實(shí)現(xiàn)現(xiàn)在或?qū)?lái)所需要的用例。事實(shí)上，構(gòu)架和用例必須并行演化。

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

3．迭代和增量的過(guò)程

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

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

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

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

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

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

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

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

1.產(chǎn)品

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

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

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

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

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

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

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

實(shí)施模型：定義計(jì)算機(jī)的物理節(jié)點(diǎn)和構(gòu)件到這些節(jié)點(diǎn)的映射；

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

射；

測(cè)試模型：描述用于驗(yàn)證用例的測(cè)試用例。

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

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

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

2.階段

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

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

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

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

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

開(kāi)發(fā)產(chǎn)品的計(jì)劃如何？開(kāi)銷(xiāo)多大？

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

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

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

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

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

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

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

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

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

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

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

(1)

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

(2)

UML不是工具或知識(shí)庫(kù)的規(guī)格說(shuō)明，而是一種建模語(yǔ)言規(guī)格說(shuō)明，是一種表示模型的標(biāo)準(zhǔn)。

(3)

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

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

1994年10月，GradyBooch和JamesRumbaugh開(kāi)始致力于這一工作。他們首先將Booch93和OMT-2統(tǒng)一起來(lái)，并于1995年10月發(fā)布了第一個(gè)公開(kāi)版本，稱(chēng)之為統(tǒng)一方法UM(UnifiedMethod)0.8。1995年秋，OOSE的創(chuàng)始人IvarJacobson加盟這一工作。經(jīng)過(guò)Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分別發(fā)布了兩個(gè)新的版本，即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等多個(gè)版本，并最終成為ISO國(guó)際標(biāo)準(zhǔn)，其中UML1.4.2對(duì)應(yīng)于ISO/IEC19501:2005國(guó)際標(biāo)準(zhǔn)，而UML2.1.2及后續(xù)版本對(duì)應(yīng)于ISO/IEC19505-1:2012(基礎(chǔ)結(jié)構(gòu))和ISO/IEC19505-2:2012(上層結(jié)構(gòu))。UML的發(fā)展過(guò)程可用圖7-10來(lái)表示。

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

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

作為一種建模語(yǔ)言，UML包括UML語(yǔ)義和UML表示法兩個(gè)部分。

(1)

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

(2)

UML表示法：定義UML符號(hào)的表示法，為開(kāi)發(fā)者或開(kāi)發(fā)工具使用這些圖形符號(hào)和文本語(yǔ)法為系統(tǒng)建模提供了標(biāo)準(zhǔn)。這些圖形符號(hào)和文字所表達(dá)的是應(yīng)用級(jí)的模型，在語(yǔ)義上是UML元模型的實(shí)例。

標(biāo)準(zhǔn)建模語(yǔ)言UML的重要內(nèi)容可以由五類(lèi)圖來(lái)定義。

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

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

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

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

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

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

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

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

7.5迭代和增量過(guò)程

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

在每個(gè)階段中，過(guò)程需要經(jīng)歷一系列的迭代和增量來(lái)滿足這些準(zhǔn)則。

(1)初始階段的根本準(zhǔn)則是可行性，通過(guò)下面的方式達(dá)到：

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

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

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

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

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

確定并降低對(duì)系統(tǒng)構(gòu)造有重大影響的風(fēng)險(xiǎn)；

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

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

制定足夠詳細(xì)的項(xiàng)目計(jì)劃來(lái)指導(dǎo)構(gòu)造階段；

在較嚴(yán)的條件下進(jìn)行估計(jì)，以便調(diào)整項(xiàng)目的商業(yè)報(bào)價(jià)；

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

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

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

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

修正缺陷。

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

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

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

為了盡早處理關(guān)鍵風(fēng)險(xiǎn)和重要風(fēng)險(xiǎn)；

為了建立一個(gè)構(gòu)架來(lái)指導(dǎo)軟件開(kāi)發(fā)；

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

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

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

1．降低風(fēng)險(xiǎn)

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

最初考慮的對(duì)象請(qǐng)求代理可能無(wú)法處理每秒鐘1000個(gè)“遠(yuǎn)程客戶賬戶”對(duì)象的查詢(xún)請(qǐng)求；

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

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

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

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

圖7-11風(fēng)險(xiǎn)的處理能力和開(kāi)發(fā)時(shí)間之間的關(guān)系

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

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

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

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

3．處理不斷變化的需求

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

4．允許靈活改變

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

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

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

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

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

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

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

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

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

此外，培訓(xùn)新的人員會(huì)更容易，因?yàn)樗麄兡軌蛲ㄟ^(guò)工作本身得到訓(xùn)練，無(wú)須設(shè)置專(zhuān)門(mén)的培訓(xùn)來(lái)幫助他們理解過(guò)程，他們可以直接進(jìn)入與任務(wù)相關(guān)的工作。如果新手不能理解要點(diǎn)或做錯(cuò)了，對(duì)整個(gè)項(xiàng)目的最后進(jìn)度也不會(huì)造成重大影響，因?yàn)樵谶M(jìn)行下次構(gòu)造時(shí)問(wèn)題就會(huì)顯現(xiàn)出來(lái)。

迭代方法還有助于項(xiàng)目處理非技術(shù)性風(fēng)險(xiǎn)，如組織風(fēng)險(xiǎn)。例如，開(kāi)發(fā)人員可能沒(méi)有盡快了解下面的問(wèn)題：

如何使用對(duì)象請(qǐng)求代理建立應(yīng)用程序；

如何使用測(cè)試或配置管理工具；

如何根據(jù)軟件開(kāi)發(fā)過(guò)程進(jìn)行工作。

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

7.5.2迭代方法是風(fēng)險(xiǎn)驅(qū)動(dòng)的

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

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

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

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

7.5.3通用迭代過(guò)程

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

1．迭代是什么

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

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

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

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

項(xiàng)目經(jīng)理在當(dāng)前迭代目標(biāo)未達(dá)到之前不應(yīng)該同意開(kāi)始下一次迭代，否則，就會(huì)導(dǎo)致必須改變計(jì)劃來(lái)適應(yīng)新的情況。

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

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

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

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

3．確定迭代次序

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

在一次迭代將要結(jié)束而另一次迭代即將開(kāi)始時(shí)，迭代過(guò)程可能出現(xiàn)交疊，如圖7-14所示，在結(jié)束前一次迭代并準(zhǔn)備發(fā)布時(shí)，可以開(kāi)始規(guī)劃并提早進(jìn)行下一次迭代的工作。但是不能交疊得太多，因?yàn)樯弦淮蔚吘故窍乱淮蔚幕A(chǔ)。結(jié)束一次迭代意味著在開(kāi)發(fā)組內(nèi)已經(jīng)獲得了一次結(jié)果，即對(duì)這次迭代中的所有軟件進(jìn)行了集成并在內(nèi)部發(fā)布。

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

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

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

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

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

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

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

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