體系結構第13章

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、以記錄在每個段中的動作。組織的需求將決定如何改編,具體的開發(fā)過程。 GRAPPLE主要適用于面向對象系統(tǒng)。因此每個段中的動作主要是生成面向對象的工作產(chǎn)品。GRAPPLE中有下列段： 1．需求收集。 2．分析。 3 ．設計。 4．開發(fā)。 5．部署。 這5個段組成的過程簡稱為RADDD或RAD3 。,在第3段以后，項目經(jīng)理將所有工

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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