體系結(jié)構(gòu)第13章

1、第十三章 在開發(fā)過程中運(yùn)用UML,已經(jīng)學(xué)習(xí)過UML的各種圖，下面是該學(xué)習(xí)開發(fā)過程的時(shí)候了。UML是一個(gè)有力的工具，但是卻不能孤立地使用它。它必須被用于軟件開發(fā)過程。本章將介紹開發(fā)過程方法學(xué)，它是用于理解UML使用環(huán)境的工具。具體將學(xué)習(xí)： ● 開發(fā)過程的重要性。 ● 為什么傳統(tǒng)的開發(fā)方法學(xué)不適用于當(dāng)今的系統(tǒng)開發(fā)。,● GRAPPLE開發(fā)過程。 ● 如何在開發(fā)過程中使用UML。

2、 如果一個(gè)組織為了在競(jìng)爭(zhēng)中取得優(yōu)勢(shì)，需要新增一個(gè)計(jì)算機(jī)系統(tǒng)，那么必須補(bǔ)充新的硬件和軟件。還必須進(jìn)行系統(tǒng)開發(fā)，而且開發(fā)的越快越好。 假如你是系統(tǒng)開發(fā)工作的決策者。那么就要建立一個(gè)項(xiàng)目開發(fā)小組并使小組成員就位，這個(gè)項(xiàng)目開發(fā)小組包括項(xiàng)目經(jīng)理、建模設(shè)計(jì)師、系統(tǒng)分析員、程序員和系統(tǒng)工程師。 換一個(gè)角度，如果你是該系統(tǒng)的一個(gè)客戶。那么從你的角度希望開發(fā)小組能為你提供什么工作,產(chǎn)品呢?項(xiàng)目經(jīng)理如何向你做報(bào)告呢

3、?當(dāng)然，最后你還要看到正在運(yùn)行的系統(tǒng)。但在這之前，你需要明確開發(fā)組確實(shí)已經(jīng)理解你要解決的問題和你所要求的對(duì)問題的解決方案。這時(shí)你就需要能看到一個(gè)正在進(jìn)展的系統(tǒng)，并且想知道在某一時(shí)刻的開發(fā)進(jìn)度。這些是客戶共同關(guān)心的，并且所有系統(tǒng)開發(fā)項(xiàng)目都應(yīng)該包含對(duì)時(shí)間、金錢及前景的評(píng)估。,13.1 開發(fā)過程方法學(xué)：傳統(tǒng)的和現(xiàn)代的,當(dāng)然客戶希望開發(fā)組立刻就匆匆投入編碼。但是，他們到底要對(duì)什么編碼還沒完全搞清楚。,開發(fā)組必須要經(jīng)歷一個(gè)結(jié)構(gòu)化的系統(tǒng)的開發(fā)過程

4、。在開發(fā)過程中所經(jīng)歷的步驟的結(jié)構(gòu)和性質(zhì)就是開發(fā)過程方法學(xué)(methodology)。在進(jìn)行程序設(shè)計(jì)前開發(fā)人員必須要充分理解所要解決的問題。這就需要專門有人負(fù)責(zé)需求的分析。進(jìn)行了需求的分析之后，編碼就可以開始了嗎?不，還必須有人將分析產(chǎn)品轉(zhuǎn)化為設(shè)計(jì)產(chǎn)品。然后程序員再根據(jù)設(shè)計(jì)產(chǎn)品編制代碼，這些代碼在經(jīng)過測(cè)試和部署后，最終成為目標(biāo)系統(tǒng)。13.1.1 傳統(tǒng)的開發(fā)過程方法學(xué) 上面對(duì)開發(fā)過程中各個(gè)階段的簡(jiǎn)單描述可能會(huì)使你覺得開發(fā)

5、過程中的各個(gè)活動(dòng)是按照時(shí)間順序一個(gè),接著一個(gè)順序展開的。事實(shí)上，早期的開發(fā)方法就是采取這種方式。下圖說明了一種曾經(jīng)造成廣泛影響的開發(fā)方法模型。它被稱為“瀑布(waterfall)”模型，在瀑布方法中，分析、設(shè)計(jì)、編碼和部署階段是一個(gè)接著一個(gè)按照順序進(jìn)行的。前一個(gè)階段完成后，下一個(gè)階段才能開始。 這種開發(fā)方式具有一些明顯的缺點(diǎn)。首先，這種方式下的開發(fā)過程被分割開來。分析員將分析結(jié)果轉(zhuǎn)交給設(shè)計(jì)人員，設(shè)計(jì)人員再把設(shè)計(jì)結(jié)果交給開

6、發(fā)人員。采用這種工作方式的話，那么這三個(gè)組的成員在一起工作和共享重要信息的機(jī)會(huì)就很少。,這種方法的另一個(gè)問題是它不利于在項(xiàng)目開發(fā)過程中對(duì)問題的逐步理解(通常，對(duì)問題的理解是隨著開發(fā)過程的深入而增強(qiáng)的，甚至是在分析之后)。如果，過程不能回溯到早期階段，那么在后期萌發(fā)的好的思想將不能被利用。在開發(fā)過程中塞進(jìn)新的見解是非常困難的。重新進(jìn)行分析和設(shè)計(jì)(同時(shí)引入對(duì)問題的更進(jìn)一步理解)會(huì)大大增加項(xiàng)目獲得成功的機(jī)會(huì)。13.1.2 新的開發(fā)過程方法

7、學(xué) 與傳統(tǒng)的瀑布方法明顯不同，當(dāng)代軟件工程強(qiáng)調(diào)開發(fā)階段的無縫集成。例如，系統(tǒng)分析員和設(shè)計(jì),人員，通常要往返進(jìn)行分析和設(shè)計(jì)，為程序設(shè)計(jì)人員提供堅(jiān)實(shí)的基礎(chǔ)。程序設(shè)計(jì)人員反過來也要與分析人員和設(shè)計(jì)人員交互，共享重要的見解，修改設(shè)計(jì)，充實(shí)代碼。 這種方法的優(yōu)點(diǎn)是，隨著對(duì)問題理解的深入，項(xiàng)目小組能夠引進(jìn)新的思想，建立起更完善的系統(tǒng)。這種方法的阻力是一些故步自封的人想要看到中間階段達(dá)到一個(gè)清晰的結(jié)尾。有時(shí)，項(xiàng)目經(jīng)理可

8、能對(duì)客戶說出這樣的話來：“分析已經(jīng)完成，我們將要進(jìn)行設(shè)計(jì)，兩二天后就開始編碼”。 這種做法充滿了危險(xiǎn)。在開發(fā)過程的各個(gè)階段,之間設(shè)置人為的障礙會(huì)最終導(dǎo)致所開發(fā)的系統(tǒng)不是客戶想要的。 傳統(tǒng)方法還有另外一個(gè)問題：瀑布方法的追隨者通常將過多的項(xiàng)目開發(fā)時(shí)間用于編碼。其直接結(jié)果是寶貴的系統(tǒng)分析和設(shè)計(jì)時(shí)間被編碼所侵吞。,13.2 開發(fā)過程中必須做什么,在計(jì)算機(jī)程序設(shè)計(jì)的早期，分析問題，設(shè)計(jì)解決方案，編制程序代碼都是

9、由一個(gè)人完成的?，F(xiàn)在卻完全同了。為了開發(fā)各種復(fù)雜的系統(tǒng)，今天的企業(yè)需要群組工作方式。為什么呢?由于知識(shí)越來越,專業(yè)化，一個(gè)人不可能知道一個(gè)企業(yè)的全部方面，理解問題，設(shè)計(jì)解決方案，將解決方案轉(zhuǎn)化成程序代碼，在硬件上部署這些程序代碼，并能確保所有的軟硬件構(gòu)件都能很好地協(xié)同工作。 項(xiàng)目小組中必須包括的成員有：系統(tǒng)分析員，他們與客戶交流，理解客戶的問題；設(shè)計(jì)人員，他們?cè)O(shè)計(jì)問題的解決方案；程序設(shè)計(jì)人員，將解決方案編制成代碼以及將代

10、碼部署到硬件上運(yùn)行的系統(tǒng)工程師。一個(gè)開發(fā)過程必須要考慮到所有這些角色，合理地利用他們，為開發(fā)過程的每個(gè)階段分配時(shí)間。開發(fā)過程還必須產(chǎn)生一指明過程進(jìn)度以及形成職責(zé)跟蹤的工作產(chǎn)品。,最后，開發(fā)過程必須確保每個(gè)階段的工作不是分離的。相反，必須在開發(fā)過程中得到反饋信息以增加在開發(fā)過程中采納新思想的容易程度?；€：能容易地修改系統(tǒng)的藍(lán)圖，然后再修改系統(tǒng)，而不是在修改了系統(tǒng)再去改變系統(tǒng)藍(lán)圖。 一些公司認(rèn)為，在開發(fā)過程中，一定要構(gòu)造出

11、一組開發(fā)階段，每個(gè)階段都產(chǎn)生大量的書面制品。因?yàn)橐恍┥虡I(yè)可用的開發(fā)方法學(xué)的做法就是這樣的，讓項(xiàng)目經(jīng)理填寫大量的表格。 產(chǎn)生這種情況的一個(gè)原因是源于一種方法能夠適用于所有開發(fā)過程的錯(cuò)誤思想。每個(gè)組織都是,獨(dú)一無二的。一個(gè)組織有他自己的文化、標(biāo)準(zhǔn)、歷史和人員。適用于跨國大公司的軟件開發(fā)方法用在一個(gè)小公司時(shí)，很可能失敗，反過來也一樣。在開發(fā)過程中制定大量的書面制品就有助于將一個(gè)開發(fā)方法學(xué)運(yùn)用于某個(gè)組織，這種觀念是錯(cuò)誤的。

12、 因此，一個(gè)開發(fā)方法學(xué)必須要能夠做到： ● 保證開發(fā)小組對(duì)所要解決的問題有個(gè)堅(jiān)實(shí)的理解。 ● 要考慮到開發(fā)小組是由不同角色組成。 ● 能夠在小組的不同角色成員之間培育良好的通信關(guān)系。,● 考慮到跨越階段的開發(fā)過程的反饋信息。 ● 開發(fā)出能夠向客戶反映出開發(fā)進(jìn)度的工作產(chǎn)品，但是要避免產(chǎn)生過多的紙面制品。 應(yīng)該注意的是，如果采用某種開發(fā)過程能

13、夠在一個(gè)短的時(shí)間周期內(nèi)開發(fā)出一個(gè)完善的產(chǎn)，那么它就是一個(gè)好的開發(fā)過程。,13.3 GRAPPLE,我們將介紹和使用能夠適應(yīng)對(duì)開發(fā)過程多方面的挑戰(zhàn)的快速應(yīng)用工程指導(dǎo)原則(Guidelines for Rapid APPLication Engineering，GRAPPLE)。GRAPPLE內(nèi),的思想并不是什么新穎思想。它只是吸取了許多其他方法的精髓。發(fā)明UML的三位科學(xué)家還建立了Rational統(tǒng)一開發(fā)過程(RUP)，在這之前，他們每

14、個(gè)人還有自己的開發(fā)過程方法學(xué)。這些開發(fā)過程方法學(xué)的思想與GRAPPLE類似。Steve McConnell的Rapid Development(Microsoft出版杜，1996)這本書，介紹了適于快速開發(fā)的很多好的做法。 GRAPPLE名字的第一個(gè)字Guidline(指導(dǎo)原則)是非常重要的：這說明GRAPPLE并不是寫在教科書中的一個(gè)開發(fā)方法學(xué)。相反，它是一組可自適應(yīng)的，靈活的開發(fā)思想?？梢园阉闯墒情_發(fā)過程的簡(jiǎn)要骨架

15、。,我們將它作為開發(fā)背景，以說明在這個(gè)背景中如何使用UML。 經(jīng)過適當(dāng)?shù)耐晟坪脱a(bǔ)充，GRAPPLE可以適用于許多種不同組織(但也許不是全部組織)的軟件開發(fā)過程。它為項(xiàng)目經(jīng)理留有余地，以使讓他們發(fā)揮自己的創(chuàng)造力和好的思想來適應(yīng)自己的組織，減少不必要的一些開發(fā)步驟。,13.4 RAD3 ：GRAPPLE的結(jié)構(gòu),GRAPPLE由5個(gè)段(segment)組成，使用“段”而不是“階段”(stage)為的是說明不是通常意義上的那種

16、,一個(gè)階段完成后，下一個(gè)階段才能開始。每個(gè)段又由許多動(dòng)作(action)組成。每個(gè)動(dòng)作能夠產(chǎn)生一個(gè)工作產(chǎn)品，并且每個(gè)動(dòng)作都是一個(gè)特定的執(zhí)行者(player)的職責(zé)。 在許多情況下，項(xiàng)目經(jīng)理都可以根據(jù)工作產(chǎn)品生成一個(gè)要提交給客戶的報(bào)告。工作產(chǎn)品實(shí)際上就是項(xiàng)目開發(fā)過程中的各種紙件。 項(xiàng)目經(jīng)理可以在每個(gè)段中增加動(dòng)作來改編GRAPPLE。另一種改編方式是深入到一個(gè)更深的層次，把每個(gè)動(dòng)作進(jìn)一步劃分為多個(gè)子動(dòng)作。還可

17、以記錄在每個(gè)段中的動(dòng)作。組織的需求將決定如何改編,具體的開發(fā)過程。 GRAPPLE主要適用于面向?qū)ο笙到y(tǒng)。因此每個(gè)段中的動(dòng)作主要是生成面向?qū)ο蟮墓ぷ鳟a(chǎn)品。GRAPPLE中有下列段： 1．需求收集。 2．分析。 3 ．設(shè)計(jì)。 4．開發(fā)。 5．部署。 這5個(gè)段組成的過程簡(jiǎn)稱為RADDD或RAD3 。,在第3段以后，項(xiàng)目經(jīng)理將所有工

18、作產(chǎn)品轉(zhuǎn)化為一個(gè)設(shè)計(jì)文檔，將該設(shè)計(jì)文檔交給客戶和開發(fā)人員。當(dāng)所有的RAD3段都完成后，要結(jié)合所有的工作產(chǎn)品來生成系統(tǒng)的定義文檔。 在所有這些段開始之前，客戶必須已經(jīng)為該系統(tǒng)制作了一個(gè)業(yè)務(wù)案例。還要求開發(fā)組的成員特別是分析員盡可能多的閱讀相關(guān)文檔資料。 讓我們先更仔細(xì)地考察每個(gè)段，并著眼于在每個(gè)段中如何應(yīng)用UML。,13.5 需求收集,如果給每個(gè)段指派一個(gè)重要性的級(jí)別的話。那么這一段是第一重要的。如果不理

19、解客戶需要什么，那么你就無法構(gòu)造出正確的系統(tǒng)。如果你不理解客戶的領(lǐng)域和他想讓你解決的問題，那么所有的用例分析都無濟(jì)于事。13.5.1 發(fā)現(xiàn)業(yè)務(wù)過程 開發(fā)過程的起點(diǎn)是獲得對(duì)客戶業(yè)務(wù)過程的理解，特別是獲得要使用目標(biāo)系統(tǒng)的客戶的理解，這是一個(gè)好的思想。要獲得這種理解，分析員應(yīng)與客戶,或者客戶指定的具有業(yè)務(wù)知識(shí)的人面談，與他們一起一步一步地討論相關(guān)過程。 分析員獲得了一套客戶業(yè)務(wù)領(lǐng)域的詞匯，這套客戶所使用的詞

20、匯是初期的重要成果。在下一個(gè)動(dòng)作中，分析員要用這些詞匯與客戶進(jìn)一步面談。 工作產(chǎn)品是一個(gè)或者一組能夠捕獲業(yè)務(wù)過程中的步驟和判定點(diǎn)的活動(dòng)圖。13.5.2 領(lǐng)域分析 這個(gè)動(dòng)作類似于與籃球教練交談的那個(gè)例子。它可以與前一個(gè)動(dòng)作同時(shí)進(jìn)行。目標(biāo)是獲得盡可能深刻地理解客戶的領(lǐng)域。注意，這個(gè)動(dòng)作和前一個(gè)動(dòng)作是,針對(duì)領(lǐng)域中的概念，不是分析要最終建立的系統(tǒng)。分析員必須能夠在客戶的世界里游刃有余，因?yàn)榉治鰡T在開發(fā)組中最終

21、要擔(dān)當(dāng)客戶的使者。 分析員與客戶會(huì)談的主要目標(biāo)是理解客戶領(lǐng)域中的主要實(shí)體。在分析員與客戶交談的過程中，另一個(gè)小組的成員做記錄(最好是在一個(gè)裝有字處理軟件包的膝上型電腦上做記錄)，對(duì)象建模人員構(gòu)造高層類圖。如果有多于一個(gè)的組員做記錄，那就更好。 對(duì)象建模人員聽取名詞，然后開始為每個(gè)名詞建立一個(gè)類。最終，一些名詞可能成為類中的屬性。對(duì)象建模人員還要聽取動(dòng)詞，它們可能成為類中的操作。,此時(shí)，基于計(jì)算機(jī)的自動(dòng)建模

22、工具可能會(huì)派上大用場(chǎng)。 工作產(chǎn)品是一個(gè)高層的類圖和會(huì)談?dòng)涗洝?3.5.3 識(shí)別協(xié)作系統(tǒng) 當(dāng)今企業(yè)中的計(jì)算機(jī)系統(tǒng)中不是孤立地存在于真空中。它們必須與其他系統(tǒng)協(xié)作。在開發(fā)過程的早期，開發(fā)組要找出新建的系統(tǒng)要依賴哪些老系統(tǒng)，哪些老系統(tǒng)要依賴新建的系統(tǒng)。這個(gè)動(dòng)作備受系統(tǒng)工程師關(guān)注，因?yàn)樗獮闇?zhǔn)備新建的系統(tǒng)建立部署圖。圖中每個(gè)節(jié)點(diǎn)是一個(gè)系統(tǒng)，節(jié)點(diǎn)之間的連線是系統(tǒng)之間的通信關(guān)系，節(jié)點(diǎn)中還要表示出駐留在節(jié)點(diǎn)中的軟件

23、構(gòu)件和構(gòu)件間的依賴關(guān)系。,13.5.4 發(fā)現(xiàn)系統(tǒng)需求 因?yàn)檫@個(gè)動(dòng)作名字中有“需求”兩個(gè)字，因此這個(gè)動(dòng)作極其重要。在這個(gè)動(dòng)作中，開發(fā)組要經(jīng)歷第一次聯(lián)合應(yīng)用開發(fā)會(huì)議(Joint Application Development session，JAD session)，在整個(gè)GRAPPLE中還有好幾個(gè)這種JAD session。 JAD session的參加者是來自客戶所在組織的決策者、可能的用戶，以及開發(fā)組

24、的成員。還要有個(gè)協(xié)調(diào)者來緩和會(huì)議氣氛。協(xié)調(diào)者的任務(wù)是引出組織決策者和用戶對(duì)系統(tǒng)的需求。至少要有兩個(gè)人做會(huì)議記錄，對(duì)象建模人員應(yīng)該在會(huì)議中細(xì)化他以前所建立的類圖。,會(huì)議得到的工作產(chǎn)品是一個(gè)包圖。每個(gè)包代表了一個(gè)系統(tǒng)功能的高層領(lǐng)域(例如，“協(xié)助顧客”)。每個(gè)包中包括了一組用例(例如，“獲取顧客歷史信息”和“與顧客交互”)。 系統(tǒng)的復(fù)雜性決定了會(huì)議的時(shí)間長(zhǎng)度。一般很少短于半個(gè)工作日，有時(shí)長(zhǎng)達(dá)一個(gè)工作周的時(shí)間。客戶的組織必須要舍

25、得在會(huì)議的時(shí)間上投資。 為什么要使用JAD session來開發(fā)系統(tǒng)需求呢?為什么不與每個(gè)人單獨(dú)會(huì)談呢?我們說過，當(dāng)今系統(tǒng)開發(fā)的一個(gè)挑戰(zhàn)是短的開發(fā)周期。單獨(dú)會(huì)談可能耗時(shí)數(shù)周或者更長(zhǎng)的時(shí)間。因?yàn)楸徽业娜瞬灰欢傆袝r(shí)間。,如果等他們有時(shí)間了再會(huì)談，那么就白白浪費(fèi)了寶貴的系統(tǒng)開發(fā)時(shí)間。單獨(dú)會(huì)談時(shí)可能會(huì)產(chǎn)生意見上的分歧，解決這些分歧又要浪費(fèi)更多的時(shí)間。將所有的人召集起來開會(huì)的作用顯然要超過和每個(gè)單獨(dú)的人開會(huì)的作用，這樣對(duì)每會(huì)議參

26、加者都有好處。13.5.5 將結(jié)果提交給客戶 當(dāng)開發(fā)組完成了所有需求動(dòng)作，項(xiàng)目經(jīng)理就要將這些動(dòng)作的結(jié)果提交給客戶。有一些組織在這個(gè)時(shí)候可能需要客戶對(duì)這些結(jié)果認(rèn)可，然后才能繼續(xù)開發(fā)過程。其他一些組織可能要根據(jù)這些結(jié)果做成本估算。這個(gè)動(dòng)作的工作產(chǎn)品視不同的組織而不同。,13.6 分析,在這一段里，開發(fā)組深入分析需求段獲得的結(jié)果并增進(jìn)對(duì)問題的理解。事實(shí)上，分析段的部分工作在需求段就已經(jīng)開始，例如對(duì)象建模者在需求段JAD

27、session時(shí)就應(yīng)該開始細(xì)化類圖了。13.6.1 理解系統(tǒng)的用法 這個(gè)動(dòng)作是一個(gè)高層用例分析，在一個(gè)與可能的用戶的JAD session中，開發(fā)組與用戶一同工作找出發(fā)起每個(gè)用例的參與者以及從這些用例中獲益的參與者，這些用例是在需求段JAD session中發(fā)現(xiàn)的。協(xié)調(diào)者協(xié)調(diào)會(huì)議氣氛，并且要有兩個(gè)小組成員做,記錄。在有過幾個(gè)項(xiàng)目的經(jīng)驗(yàn)后，協(xié)調(diào)者有可能發(fā)展成為用例分析員。 開發(fā)小組還要嘗試開發(fā)出新用例。

28、產(chǎn)生的工作產(chǎn)品是一組用例圖，圖中說明了用例和用例的參與者，以及帶著構(gòu)造型(《extends》和《include》)的用例之間的依賴關(guān)系。13.6.2 充實(shí)用例 在這個(gè)動(dòng)作中，開發(fā)組繼續(xù)和用戶一同工作。目標(biāo)是分析出每個(gè)用例中的步驟序列。這個(gè)動(dòng)作的JAD session可以是前一個(gè)動(dòng)作的JAD session的繼續(xù)。注意：對(duì)用戶來說，這個(gè)通常是最困難的,JAD session。他們往往不習(xí)慣將一個(gè)操作分解成各個(gè)組成步驟并

29、列舉出所有可能的這種步驟。工作產(chǎn)品是對(duì)每個(gè)用例步驟的文本描述。13.6.3 細(xì)化類圖 在JAD session期間，對(duì)象建模者聽取所有討論并繼續(xù)細(xì)化類圖。在這時(shí)，對(duì)象建模者應(yīng)當(dāng)在類圖中加入關(guān)聯(lián)名、抽象類、多重性、泛化和聚集等。工作產(chǎn)品是一個(gè)細(xì)化了的類圖。13.6.4 分析對(duì)象狀戀變化 對(duì)象建模者進(jìn)一步細(xì)化模型，要展示出對(duì)象狀態(tài)的變化。工作產(chǎn)品是一個(gè)狀態(tài)圖。,13.6.5 定義對(duì)象之間的交互

30、 開發(fā)組有了一組用例圖和細(xì)化了的類圖后，就該定義對(duì)象之間如何交互了。對(duì)象建模者開發(fā)一組順序圖和協(xié)作圖來描繪對(duì)象之間的交互。狀態(tài)變化應(yīng)當(dāng)被包括在內(nèi)。這些圖形成了該動(dòng)作的工作產(chǎn)品。13.6.6 分析與協(xié)作系統(tǒng)的集成 系統(tǒng)工程師要找出與協(xié)作系統(tǒng)集成的具體細(xì)節(jié)，這個(gè)過程是與前面的過程同步進(jìn)行的。比如何種類型的通信?何種網(wǎng)絡(luò)體系結(jié)構(gòu)?如果系統(tǒng)要訪問數(shù)據(jù)庫，那么一個(gè)數(shù)據(jù)庫分析員要決定這些數(shù)據(jù)庫(物理的和邏輯的)的體系結(jié)

31、構(gòu)。這個(gè)動(dòng)作的工作產(chǎn)品是,詳細(xì)的系統(tǒng)部署圖和(如果有必要的話)數(shù)據(jù)模型。,13.7 設(shè)計(jì),在本段中，開發(fā)組使用分析段的結(jié)果來設(shè)計(jì)系統(tǒng)的解決方案。設(shè)計(jì)和分析都可以往返進(jìn)行直到設(shè)計(jì)完成。事實(shí)上，在一些方法學(xué)中，分析和設(shè)計(jì)被做為一個(gè)階段。13.7.1 開發(fā)和細(xì)化對(duì)象圖 程序員根據(jù)類圖產(chǎn)生一些必要的對(duì)象圖。他們檢查每個(gè)操作并開發(fā)對(duì)應(yīng)操作的活動(dòng)圖去充實(shí)對(duì)象圖。活動(dòng)圖將是開發(fā)段中編碼的基礎(chǔ)。工作產(chǎn)品是,上述對(duì)象圖和活動(dòng)圖。1

32、3.7.2 開發(fā)構(gòu)件圖 在本動(dòng)作中，程序員是重要角色。這個(gè)段的任務(wù)是可視化的描繪出構(gòu)件和構(gòu)件之間的關(guān)系。構(gòu)件圖是本動(dòng)作的工作產(chǎn)品。13.7.3制定部署計(jì)劃 當(dāng)構(gòu)件圖完成后，系統(tǒng)工程師就開始編制系統(tǒng)的部署以及系統(tǒng)與其他協(xié)作系統(tǒng)集成的計(jì)劃。系統(tǒng)工程師要繪制系統(tǒng)的部署圖，圖中要表明每個(gè)節(jié)點(diǎn)中駐留了哪些構(gòu)件。這個(gè)動(dòng)作的工作產(chǎn)品是部署圖。,13.7.4 設(shè)計(jì)和開發(fā)用戶界面原型 這個(gè)動(dòng)作要包括另

33、一個(gè)與用戶的JAD session。盡管屬于設(shè)計(jì)段的一部分，這個(gè)會(huì)議也可以是早期與用戶進(jìn)行的JAD session的繼續(xù)——說明了分析和設(shè)計(jì)之間的相互作用。 用戶界面應(yīng)當(dāng)考慮到所有用例的完成。為了執(zhí)行這個(gè)動(dòng)作，一個(gè)GUI分析員與用戶一起開發(fā)紙面上的用戶界面原構(gòu)件原型(按鈕，檢查框、下拉列表、菜單等等)，當(dāng)用戶對(duì)界面構(gòu)件滿意后，開發(fā)人員就開發(fā)顯示器上的用戶界面原型，拿給用戶讓他們認(rèn)可。工作產(chǎn)品是屏幕界面原型的快照。,13.

34、7.5 測(cè)試設(shè)計(jì) 用例是進(jìn)行測(cè)試設(shè)計(jì)的依據(jù)。目標(biāo)是評(píng)價(jià)所開發(fā)出的軟件是否能夠做所期望的事——也就是說，它能夠?qū)崿F(xiàn)用例所描述的事情。更好的做法是再請(qǐng)一位開發(fā)組之外的測(cè)試專家為自動(dòng)測(cè)試工具開發(fā)測(cè)試腳本。這些測(cè)試腳本構(gòu)成本動(dòng)作的工作產(chǎn)品。13.7.6 開始編制文檔 系統(tǒng)最終用戶和系統(tǒng)管理員使用的文檔不要太早就開始編制。編制文檔的專業(yè)人員與開發(fā)人員一起共同編制文檔，制定出每個(gè)文檔的高層結(jié)構(gòu)。文檔的結(jié)構(gòu)就是工

35、作產(chǎn)品。,13.8 開發(fā),該段是由程序員負(fù)責(zé)的。有了充分的分析和設(shè)計(jì)結(jié)果，這個(gè)段的工作就能快速平穩(wěn)地進(jìn)行。13.8.1 編制代碼 根據(jù)掌握的類圖、對(duì)象圖、活動(dòng)圖和構(gòu)件圖，程序員編制實(shí)現(xiàn)系統(tǒng)的代碼。這一動(dòng)作的工作產(chǎn)品是編制出的代碼。13.8.2 測(cè)試代碼 測(cè)試專家(不是開發(fā)人員)運(yùn)行測(cè)試腳本，評(píng)價(jià)代碼是否做了預(yù)期的工作。測(cè)試結(jié)果是這個(gè)動(dòng)作的,工作產(chǎn)品。這個(gè)動(dòng)作中產(chǎn)生的信息要反饋到前面的動(dòng)作中，反過

36、來也是如此，直到代碼通過了所有層次的測(cè)試。 13.8.3 構(gòu)建用戶界面和用戶界面到代碼的連接及測(cè)試 這個(gè)動(dòng)作向著用戶認(rèn)可的用戶界面原型靠近。GUI專家構(gòu)建用戶界面并將界面連接到代碼。要進(jìn)一步的測(cè)試，確保用戶界面工作正確。工作產(chǎn)品是帶有用戶界面的功能系統(tǒng)。13.8.4 完成文檔 在開發(fā)段中，文檔專家與程序員并行工作，確保,文檔及時(shí)完成和交付。該動(dòng)作的工作產(chǎn)品是文檔。,13.9 部署,當(dāng)開發(fā)完成后，系統(tǒng)

37、就要被部署到適當(dāng)?shù)挠布线\(yùn)行并要與協(xié)同系統(tǒng)集成起來。盡管如此，這一段中的第一個(gè)動(dòng)作在開發(fā)段開始以前就可以開始。13.9.1 編制備份和恢復(fù)計(jì)劃 由系統(tǒng)工程師編制計(jì)劃，以防系統(tǒng)崩潰。這個(gè)動(dòng)作的工作產(chǎn)品是備份和恢復(fù)計(jì)劃。計(jì)劃中要詳細(xì)說明如何備份系統(tǒng)以及系統(tǒng)崩潰后如何恢復(fù)。13.9.2 在硬件上安裝最終系統(tǒng) 系統(tǒng)工程師在必要的開發(fā)人員協(xié)助下，將最終,開發(fā)好的系統(tǒng)部署到合適的計(jì)算機(jī)上運(yùn)行。工作產(chǎn)品是完全部

38、署好的計(jì)算機(jī)系統(tǒng)。13.9.3 測(cè)試安裝后的系統(tǒng) 最后，開發(fā)組還要對(duì)安裝好的系統(tǒng)測(cè)試。它是否能執(zhí)行預(yù)期的事?備份和恢復(fù)機(jī)制起作用了嗎?測(cè)試的結(jié)果將決定系統(tǒng)是否需要進(jìn)一步精化，并且測(cè)試結(jié)果組成了工作產(chǎn)品。13.9.4 慶祝 開發(fā)組慶祝一個(gè)新系統(tǒng)的誕生，這個(gè)動(dòng)作的工作產(chǎn)品就是這個(gè)新系統(tǒng)。,13.10 GRAPPLE總結(jié),如果我們回過頭來看GRAPPLE中的段和動(dòng)作，將會(huì)看到GRAPPLE的運(yùn)動(dòng)方式是

39、從一般到具體——從不精確到精確。它開始于一個(gè)對(duì)領(lǐng)域的概念理解，然后是系統(tǒng)的高層功能，接著繼續(xù)深入每個(gè)用例、細(xì)化模型，最后設(shè)計(jì)、開發(fā)和部署系統(tǒng)。 你還將注意到在分析和設(shè)計(jì)段中的動(dòng)作比開發(fā)段中的動(dòng)作多。也就是說，強(qiáng)調(diào)對(duì)系統(tǒng)的設(shè)計(jì)?；舅枷胧潜M可能多地花時(shí)間在前端的分析和設(shè)計(jì)上下工夫，為的是能使編碼平穩(wěn)地進(jìn)行。這看上去好象有點(diǎn)背離系統(tǒng)這個(gè)主題。但在實(shí)際開發(fā)中，編碼,只是系統(tǒng)開發(fā)過程的小部分。分析的越充分，就越能接近目標(biāo)。

40、 正如前而所述，GRAPPLE只是一個(gè)開發(fā)過程的簡(jiǎn)單骨架。我們并沒有涉及一些重要問題的細(xì)節(jié)，例如測(cè)試的層次。我們還省略了一些重要的細(xì)節(jié)：中間工作產(chǎn)品存放在哪里，如何存放?如何處理在任何時(shí)候都非常重要的配置管理問題? 我們沒有討論這些問題是因?yàn)樗鼈兣c我們正在學(xué)習(xí)的UML不直接相關(guān)。下面對(duì)這些細(xì)節(jié)問題做—個(gè)簡(jiǎn)單的回答。工作產(chǎn)品(已經(jīng)完成的或者正在進(jìn)行中的)可以被存儲(chǔ)在位于組織局域網(wǎng)中的一個(gè)數(shù)據(jù)倉庫,中。一種可選擇的

41、方案是安裝一個(gè)集中控制的數(shù)據(jù)倉庫軟件包來控制各個(gè)用戶對(duì)每個(gè)工作產(chǎn)品項(xiàng)的讀出和寫入。這也是配置管理問題的基本解決方案。數(shù)據(jù)倉庫技術(shù)至盡仍然在不斷發(fā)展，當(dāng)然還有別的可供選擇的方案。 以后，我們將進(jìn)入案例學(xué)習(xí)部分，一個(gè)應(yīng)用了UML和GRAPPLE的例子。,13.11 小結(jié),開發(fā)過程方法學(xué)將一個(gè)系統(tǒng)開發(fā)項(xiàng)目的開發(fā)過程分為階段和動(dòng)作。沒有開發(fā)過程方法學(xué)的指導(dǎo)，,開發(fā)過程就會(huì)產(chǎn)生混亂，開發(fā)者無法理解到底他要解決的是什么問

42、題，因而系統(tǒng)也不可能滿足用戶的需求。早期的開發(fā)過程方法學(xué)采用嚴(yán)格的“瀑布”順序，即分析、設(shè)計(jì)、編碼和測(cè)試。 這種順序的開發(fā)過程方法學(xué)機(jī)械地分割了開發(fā)過程，因此一個(gè)開發(fā)組不能對(duì)項(xiàng)目的生命周期產(chǎn)生的問題增加理解。它還將主要的開發(fā)工作量分配給了編碼，浪費(fèi)了分析和設(shè)計(jì)階段的寶貴時(shí)間。 這一章介紹了GRAPPLE(快速應(yīng)用工程指導(dǎo)原則)，它是一個(gè)開發(fā)過程的骨架。GRAPPLE由5個(gè)段組成：需求收集、分析、設(shè)計(jì)、開發(fā)