RUP開發(fā)過程課件

1、第10章 RUP開發(fā)過程 什么是RUPRUP過程模型與特點 軟件開發(fā)的要素用例驅(qū)動過程以架構(gòu)為中心的過程迭代和增量過程【學習目標】軟件開發(fā)過程是指為生產(chǎn)某個軟件產(chǎn)品或系統(tǒng)，需要什么人在什么時候以何種方式進行何種活動的集合。傳統(tǒng)的瀑布式開發(fā)過程模型瀑布式開發(fā)過程模型存在的風險 滿足社會需求的軟件密集型系統(tǒng)在規(guī)模、復雜度、分布性和重要性上都在不斷地進行著擴張，這給傳統(tǒng)軟件開發(fā)過程帶來挑戰(zhàn)：系統(tǒng)的異構(gòu)性系統(tǒng)的分布性系統(tǒng)的復雜性系統(tǒng)的安全性系統(tǒng)交付的快速性大量遺留系統(tǒng)軟件開發(fā)項目失敗的共同癥狀：對于最終用戶的需求理解得不夠精確。不能處理需求變更。模塊之間不兼容。軟件不易維護和擴展。對項目的嚴重缺陷發(fā)現(xiàn)

2、較晚。軟件質(zhì)量低劣。軟件性能無法令人接受。團隊中人員按各自的開發(fā)方式工作，這使得對誰在何時、何處做什么不完全清楚，系統(tǒng)更改與重構(gòu)難以進行。一個不可靠的構(gòu)造和發(fā)布過程。 盡管各個項目失敗的原因是不同的，但是基本上大多數(shù)項目失敗是由于以下幾個原因的組合造成的：需求管理非規(guī)范。模糊和不精確的交流。脆弱的架構(gòu)。系統(tǒng)過度復雜。未檢測出需求、設計和實現(xiàn)中的不一致。測試不足。對項目狀況的評估過于主觀。未解決存在的風險。無法控制變化的傳播。自動化程度不足。10.1 RUP模型與特點一、RUP概念 統(tǒng)一軟件開發(fā)過程(RUP)是一種迭代的、可預測的方式來開發(fā)和維護高質(zhì)量軟件產(chǎn)品的活動集合，如下圖所示。RUP具有四

3、種作用：1）為開發(fā)團隊的活動順序提供指導。2）詳細說明開發(fā)涉及哪些制品以及何時開發(fā)。3）指導每一個開發(fā)人員和整個開發(fā)團隊的任務。4）為監(jiān)控和度量項目的產(chǎn)品和活動提供標準。迭代式開發(fā)過程模型二、RUP的精髓1. 軟件的迭代開發(fā)軟件迭代開發(fā)的特點： 在軟件開發(fā)的早期，強制性地進行風險控制，及時、高效地解決系統(tǒng)開發(fā)可能存在的風險。該模型的軟件開發(fā)方法是一種持續(xù)地發(fā)現(xiàn)、創(chuàng)造和實現(xiàn)的過程，每一次迭代過程都會使開發(fā)團隊以一種可預測和循環(huán)方式來完善項目產(chǎn)品。軟件迭代開發(fā)能夠解決什么？ 可以在生命周期早期發(fā)現(xiàn)嚴重的需求理解錯誤，這時還可以修正這些錯誤。 這種方法允許并鼓勵用戶反饋信息，從而抽取出系統(tǒng)的真正需求

4、。 這種方法使開發(fā)團隊將注意力集中到項目中最關鍵的問題上，并屏蔽掉那些分散注意力的問題。持續(xù)的、迭代的測試可以為項目狀況給出客觀評估。需求、設計和實現(xiàn)中的不一致能夠在早期被發(fā)現(xiàn)。在整個項目的生命周期中可以更加平均地分配整個團隊，尤其是可以平均分配測試團隊的工作量。團隊可以在過程中總結(jié)經(jīng)驗教訓，不斷地改善開發(fā)過程。在整個生命周期中，項目相關人員可以通過具體證據(jù)來了解項目情況。2. 需求管理軟件開發(fā)的挑戰(zhàn)：需求的改變 必須意識到需求在整個軟件項目的生命周期中會發(fā)生變化。另外，明確一個系統(tǒng)的真正需求是一個持續(xù)的過程。除了一些非常小的系統(tǒng)之外，開發(fā)人員在開發(fā)之前完全不可能詳盡地描述系統(tǒng)的需求。實際上，

5、當一個新的或者進化的系統(tǒng)改變時，用戶對系統(tǒng)需求的理解也會改變。需求管理的主要內(nèi)容：抽取、組織系統(tǒng)所需要的功能和約束并將其文檔化估計需求的變化并評估這些變化所帶來的影響跟蹤并記錄所做出的權(quán)衡和決定項目需求管理可提供一系列解決軟件開發(fā)問題的方案： 在需求管理中構(gòu)造原則性方法。 人員之間的交流建立在已定義的需求之上。 區(qū)分需求優(yōu)先級，并進行過濾與跟蹤。 對系統(tǒng)功能需求和性能需求做出客觀的評估。 盡早檢測出來需求中的不一致性。 借助適當?shù)墓ぞ咧С?，與外部文檔的自動鏈接，可以為系統(tǒng)的需求、屬性和軌跡提供庫支持。3. 架構(gòu)和組件的使用 在項目的整個生命周期中，每一個人（最終用戶、分析人員、開發(fā)人員、系統(tǒng)集

6、成人員、測試人員、文檔撰寫人員和項目經(jīng)理）在不同的時間以不同的角度來審視這個系統(tǒng)。一個系統(tǒng)的架構(gòu)就是最重要的可交付產(chǎn)品，它可以用來管理這些不同的視點，從而在系統(tǒng)的整個生命周期中控制系統(tǒng)迭代與增量開發(fā)過程?；诮M件的軟件架構(gòu) 一個系統(tǒng)的架構(gòu)包含關于以下元素：軟件系統(tǒng)的組織。組成系統(tǒng)的結(jié)構(gòu)元素以及它們之間的接口。它們的行為，通過這些元素之間的協(xié)作來說明。這些結(jié)構(gòu)元素和行為元素組合成為較大的子系統(tǒng)。指導組織的架構(gòu)風格：這些元素和它們的接口，它們的協(xié)作和組合。 建立一個富有彈性的架構(gòu)是非常重要的，因為它可以非常經(jīng)濟地提高軟件復用率，能在開發(fā)團隊中確定一個非常明確的劃分，分離硬件和軟件間易于變化的依賴，

7、從而提高可維護性。對于軟件架構(gòu)來講，基于組件的開發(fā)是一種非常重要的方法。基于組件的架構(gòu)模型標準：微軟的COM/COM+/DCOM對象管理組織（OMG）的CORBASUN公司的EJB 使用基于組件的架構(gòu)可以提供一系列的解決軟件開發(fā)根本問題的方案： 組件有利于創(chuàng)建靈活性強的架構(gòu)。 模塊化可以清晰地分離出系統(tǒng)中易于變化的元素。 通過應用標準化的框架（如COM+、EJB、CORBA）和商業(yè)上可獲取的組件使軟件復用更加容易。 組件為配置管理提供一個非常自然的基礎。 可視化建模工具為基于組件的開發(fā)提供自動化支持。4. 為軟件建立可視化模型系統(tǒng)的可視化模型建模的作用： 建模是非常重要的，它可以幫助開發(fā)團隊將

8、一個系統(tǒng)架構(gòu)的結(jié)構(gòu)和行為可視化、具體化，并可構(gòu)造系統(tǒng)架構(gòu)以及構(gòu)建文檔。建模通常使用一種標準的建模語言來實現(xiàn)，例如統(tǒng)一建模語言（UML），開發(fā)小組中的每個成員使用標準UML可以與其他人員進行清楚的、無二義性的交流?？梢暬５膬?yōu)點： 可視化建模工具可以比較方便地對這些模型進行管理，能夠在必要的時候隱藏或者展現(xiàn)一些細節(jié)。可視化建模還可以幫助你在系統(tǒng)的制品之間（如需求、設計和實現(xiàn)）保持一致性。簡而言之，可視化建模有助于提高開發(fā)團隊管理軟件復雜性的能力。 軟件可視化模型可以提供一系列解決軟件開發(fā)根本問題的方案：通過用例和場景模型可以無二義性地詳細說明行為。通過類圖模型可以無二義性地理解軟件設計?？梢暬?/p>

9、模型能暴露出架構(gòu)中的非模塊化與不靈活之處。可視化模型在必要時可以隱藏細節(jié)。無二義性的設計可以更容易地反映出不一致性?？梢暬９ぞ咛峁ML建模的支持。5. 對軟件質(zhì)量進行持續(xù)的驗證修復問題的代價 從上圖所示，在完成部署之后再去查找和修復軟件問題，所付出的代價要比在早期進行這項工作高出 1001000 倍。因此，從功能、可靠性、應用性能和系統(tǒng)性能等多方面持續(xù)地對系統(tǒng)質(zhì)量進行評估是非常重要的。對軟件質(zhì)量進行驗證可以提供一系列解決軟件開發(fā)根本問題的方案：對于項目狀況的評估是客觀而非主觀的，因為評價是基于測試結(jié)果而非書面文檔。這個客觀的評估可以暴露出需求、設計和實現(xiàn)中的不一致性。測試和驗證工作關注

10、的是高風險區(qū)域，因此增加了這些區(qū)域的質(zhì)量水平和效率?？梢员M早發(fā)現(xiàn)缺陷，從根本上降低修復它們的代價。自動化測試工具提供了對功能、可靠性和性能的測試。6. 控制軟件的變更控制軟件的需求變更是軟件密集型系統(tǒng)開發(fā)的一個關鍵挑戰(zhàn)： 想要將開發(fā)人員、開發(fā)團隊的活動和制品協(xié)調(diào)一致，就要建立用于管理軟件變更和其他開發(fā)制品變更的工作流。這樣就可以更好地基于項目的優(yōu)先級和風險分配資源，并在迭代過程中根據(jù)變更動態(tài)地管理工作與發(fā)現(xiàn)問題，并做出反應。 想要將迭代過程和發(fā)布協(xié)調(diào)一致，就要在每次迭代結(jié)束時建立并發(fā)布一個已測試過的基線。在每個發(fā)布版本元素之間和多重并行發(fā)布版本元素之間保持可跟蹤性，對于評估和動態(tài)管理變更造成的

11、影響是十分重要的。控制軟件的變更可以提供一系列解決軟件開發(fā)根本問題的方案：定義需求變更的工作流，且需求變更的工作流是可重復的。變更請求使交流更加清晰。獨立的工作空間減少了并行工作團隊成員之間的相互干涉。變更率統(tǒng)計為客觀評估項目狀況提供了很好的度量。工作空間包含了所有制品，這樣有利于保持一致性。變更的傳播是可評估和可控制的?？梢栽谝粋€健壯的、可定制的系統(tǒng)中維護變更。三、RUP的模型RUP是一種二維結(jié)構(gòu)的軟件開發(fā)過程模型，如下圖所示。1. 時間軸 在RUP中，項目生命周期被劃分為四個階段： （1）初始階段（Inception） （2）細化階段（Elaboration） （3）構(gòu)造階段（Constr

12、uction） （4）交付階段（Transition） 每個階段開始時都有特定的目標，結(jié)束時有里程碑。在每個階段中存在一個或多個迭代。在每個迭代中，可以有多個工作流。 1) 初始階段初始階段的目標：確定項目的軟件范圍和邊界條件識別出系統(tǒng)的關鍵用例展示系統(tǒng)的侯選架構(gòu)估計整個項目需要的費用和時間安排，并為細化階段給出詳細的計劃評估項目風險初始階段的主要活動：建立系統(tǒng)的業(yè)務模型捕獲系統(tǒng)的基本需求確定系統(tǒng)的邊界識別關鍵任務確定系統(tǒng)驗收標準進行項目風險評估進行項目資源的估計與效益分析制定項目開發(fā)計劃與重要里程碑。初始階段的里程碑生命期目標初始階段的制品： 項目藍圖文檔：系統(tǒng)的核心需求、關鍵特性與主要約束

13、 初始的用例模型（完成1020） 初始的項目術語表 業(yè)務用例模型，包括商業(yè)環(huán)境、驗收標準和財政預測 初始的風險評估 一個可以顯示階段和迭代的項目計劃 一個或多個原型 初始的架構(gòu)文檔初始階段的重點：初始階段的重點是需求分析與系統(tǒng)分析。如果需要構(gòu)造原型系統(tǒng)，則需做一些設計與實現(xiàn)。 可以用如下標準來評價初始階段是否成功： 風險承擔者是否贊成項目的范圍定義、成本以及進度估計。 是否通過主要用例證實對需求的理解。 成本與進度預測的評估以及優(yōu)先級、風險和開發(fā)過程的可信度。 所開發(fā)軟件原型的深度和廣度。 實際開支與計劃開支的比較。 架構(gòu)的輪廓是否合理 如果無法達到這些標準，可能取消項目或重新對項目進行仔細的

14、考慮。 2）細化階段細化階段的目標創(chuàng)建系統(tǒng)的架構(gòu)基線細化階段的主要活動：細化構(gòu)想，建立對大多數(shù)關鍵用例的確定理解分析問題域，建立堅實的架構(gòu)細化架構(gòu)并選擇組件捕獲80%的功能需求用例精化風險評估建立可執(zhí)行的軟件原型定義非功能需求制定過程迭代計劃和迭代的評價標準細化階段的里程碑生命期架構(gòu)細化階段的主要制品： 系統(tǒng)架構(gòu)基線 UML靜態(tài)模型 UML動態(tài)模型 UML用例模型 修訂的風險評估 修訂的用例 修訂的項目計劃 可執(zhí)行的原型細化階段的重點：細化階段主要關注需求、分析和設計工作流。每個工作流關注如下各項。需求精化系統(tǒng)范圍和需求分析確定構(gòu)造什么設計創(chuàng)建穩(wěn)定的架構(gòu)實現(xiàn)構(gòu)造架構(gòu)基線測試測試架構(gòu)基線 細化階

15、段的評價是通過回答下述問題來完成的： 軟件的構(gòu)想是否穩(wěn)定？ 架構(gòu)是否穩(wěn)定？ 可執(zhí)行的原型是否表明風險要素已被處理并可靠地解決了？ 構(gòu)造階段的計劃是否足夠詳細和精確？是否有可靠的基礎？ 如果在當前架構(gòu)上下文中執(zhí)行計劃并開發(fā)出整個系統(tǒng)，是否所有的風險承擔人都同意系統(tǒng)達到了當前的需求？ 實際的費用支出與計劃支出是否可以接受？ 如果無法達到這些標準，可能取消項目或?qū)椖窟M行重新考慮。 3）構(gòu)造階段構(gòu)造階段的目標將架構(gòu)基線演進為最終系統(tǒng)構(gòu)造階段的主要活動：資源管理、資源控制和過程優(yōu)化完成組件開發(fā)并根據(jù)已定義的評價準則進行測試利用構(gòu)想制定的準則對發(fā)布的產(chǎn)品進行評估構(gòu)造階段的重點：構(gòu)造階段主要關注系統(tǒng)的實現(xiàn)

16、工作流。每個工作流關注如下各項。需求揭示任何遺漏的需求分析完成分析模型設計完成設計模型實現(xiàn)構(gòu)造初始運作功能測試測試初始運作功能構(gòu)造階段的里程碑初始運作功能構(gòu)造階段的制品： 可運行的軟件系統(tǒng) UML模型 測試用例 用戶手冊 發(fā)布描述 構(gòu)造階段的結(jié)束是項目開發(fā)的第三個重要的里程碑。這個階段產(chǎn)生的版本通常被稱為版。 評價構(gòu)造階段需要回答以下問題： 軟件是否足夠穩(wěn)定和成熟，從而可以發(fā)布給用戶？ 是否所有的風險承擔人都準備好了向用戶交付軟件產(chǎn)品？ 實際費用與計劃費用的對比是否仍可被接受？ 如果項目無法達到這些要求，必須推遲進入交付階段。 4）交付階段交付階段的目標將開發(fā)完成的系統(tǒng)提交給客戶交付階段的主要

17、活動： 將軟件系統(tǒng)部署到用戶環(huán)境 修復軟件的缺陷 編制用戶手冊和其它文檔 培訓用戶和維護人員 提供用戶咨詢 交付階段的重點：交付階段主要關注系統(tǒng)的測試和配置工作流。每個工作流關注如下各項。設計如果測試中出現(xiàn)問題，修改設計。實現(xiàn)為用戶場地裁減軟件，修復在測試中發(fā)現(xiàn)的問題。測試測試及其在用戶現(xiàn)場驗收測試。配置將軟件系統(tǒng)部署到環(huán)境中，并配置相應參數(shù)。交付階段的里程碑產(chǎn)品發(fā)布交付階段的制品： 可運行的軟件產(chǎn)品 用戶手冊 用戶支持計劃評價交付階段需要回答以下問題： 用戶是否認可系統(tǒng)已經(jīng)成功部署？ 用戶是否積極使用該軟件產(chǎn)品？ 用戶是否認可產(chǎn)品支持策略？ 如果項目無法達到這些要求，必須推遲交付。2. 過程

18、組件軸 工作流（規(guī)程）是由活動構(gòu)成的活動序列。沿著過程組件軸，開發(fā)過程可以被劃分為核心過程工作流和核心支持工作流。核心過程工作流包含如下工作流： （1）業(yè)務建模（Business Modeling） 業(yè)務建模工作流活動是為了確定系統(tǒng)功能和用戶需要。 （2）需求分析（Requirements） 需求分析工作流活動是用來描述系統(tǒng)的功能性需求和非功能性需求。 （3）分析與設計（Analysis Design） 分析與設計工作流活動是用來描述如何設計與實現(xiàn)系統(tǒng)。分析的目的是捕捉系統(tǒng)的功能需求，分析和提取所開發(fā)系統(tǒng)的類以及描述它們的協(xié)作關系。設計的目的是通過考慮實現(xiàn)環(huán)境，將分析階段的模型擴展和轉(zhuǎn)化為可行

19、的技術實現(xiàn)方案。 （4）實現(xiàn)（Implementation） 實現(xiàn)工作流活動是用編程語言來實現(xiàn)系統(tǒng)，同時對已建立的模型作相應的修正。 （5）測試（Test） 測試工作流活動的目的是使用測試用例對系統(tǒng)軟件進行驗證與確認工作。 核心支持工作流可以被分為3個工作流： （l）項目管理（Project Management）進行項目的組織、規(guī)劃與實施等管理，最終使得軟件項目按計劃和約束條件完成。 （2）配置和變更管理（Configuration and Change Management）配置管理的任務是在實際運行環(huán)境中配置系統(tǒng)，產(chǎn)生可發(fā)布的軟件版本。變更管理的任務是對需求的變更進行控制與管理，并提供追

20、蹤管理。 （3）環(huán)境（Environment） 環(huán)境工作流的目的是為軟件開發(fā)團隊提供軟件開發(fā)環(huán)境（過程和工具）。（6）配置（Deployment） 配置工作流活動的目的是通過模型來描述所開發(fā)系統(tǒng)的軟硬件配置情況。四、RUP的特點 RUP綜合了以前的多種軟件開發(fā)過程的優(yōu)點，全面考慮了軟件開發(fā)的技術因素和管理因素，它是一種良好的開發(fā)過程模式。 RUP的主要特點如下： 1） 面向?qū)ο?從技術角度，RUP開發(fā)是基于面向?qū)ο蠹夹g，即它使用和支持面向?qū)ο蠹夹g的概念和方法。RUP要求建立的設計模型、實現(xiàn)模型都是對象模型。 2) Use Case驅(qū)動 系統(tǒng)的開發(fā)從問題領域的Use Case模型開始，Use C

21、ase模型表達了系統(tǒng)的需求，以后的各種工作圍繞著如何實現(xiàn)這個Use Case模型展開。RUP推薦Use Case驅(qū)動的軟件開發(fā)方法，當然也不排斥按常規(guī)方法進行需求分析和直接從對象模型著手進行開發(fā)工作。 3) 以架構(gòu)為中心 在系統(tǒng)的開發(fā)過程中，軟件架構(gòu)是系統(tǒng)開發(fā)的基本制品，系統(tǒng)的概念化、構(gòu)造和管理都是圍繞著系統(tǒng)的架構(gòu)進行的。 4) 螺旋上升式的開發(fā)過程 RUP遵循原型法的思想，開發(fā)過程由一連串迭代開發(fā)活動組成，漸增、循環(huán)重復，以及往返工程構(gòu)成了RUP的過程特色。5) 以質(zhì)量控制和風險管理為目標 質(zhì)量控制貫穿于開發(fā)的全過程。在RUP中的每一個階段或循環(huán)中，都要進行質(zhì)量評估，用質(zhì)量目標和質(zhì)量指標衡量

22、軟件系統(tǒng)的質(zhì)量。 從軟件項目立項之初便盡可能地認識項目開發(fā)將面臨的風險，風險管理貫穿于軟件開發(fā)的全過程。 6)與 UML配套 UML本身只是一種建立模型的語言，UML的概念和表示法與RUP相結(jié)合將形成一種強大的、高效的軟件系統(tǒng)開發(fā)方法和技術。當然，RUP也可以與其他的面向?qū)ο蟊硎竟ぞ呦嘟Y(jié)合使用。 7）適用性強 RUP適用于各類軟件系統(tǒng)的開發(fā)。從規(guī)模上說，RUP可用于大、中、小型軟件系統(tǒng)，從個人開發(fā)到數(shù)百人的團隊開發(fā)都可以使用RUP開發(fā)過程。從種類上說，常規(guī)的信息管理系統(tǒng)、分布式系統(tǒng)、并行系統(tǒng)、實時系統(tǒng)和基于Web的系統(tǒng)都可以使用RUP開發(fā)過程。 此外，RUP開發(fā)過程采用管理與技術相結(jié)合的二維方

23、法，特別適合處理需求易變動的高風險項目。10.2 RUP模型元素RUP模型涉及五個要素：角色：誰做活動：怎樣做制品：做什么工作流：什么時候做規(guī)程：上述四類元素的容器 它們之間的關系如下圖所示：一、角色 角色定義了個人或作為團隊一起工作的人們的行為和職責。借助角色執(zhí)行的活動來表達行為，并且每個角色都與一組內(nèi)聚的活動相聯(lián)系。“內(nèi)聚”在這里是指這些活動最好由一個人來執(zhí)行。每個角色職責通常與某一特定制品相聯(lián)系，制品通常由角色創(chuàng)造、修改和控制。人員與角色角色的類型二、活動 活動是扮演這個角色的人要執(zhí)行的工作單元，即將在項目語境中產(chǎn)生有意義結(jié)果的工作單元。活動有明確的目的，通常是生產(chǎn)或更新制品（如模型、類

24、或計劃）。 每個活動都被分配給一個特定的角色。 活動所用時間一般從幾個小時到幾天。它通常涉及和角色相關聯(lián)的一個人員，影響到一個或少數(shù)幾個制品?；顒討撌怯媱澓晚椖窟M展中一個非常有用的元素。如果它太小了，可以忽略不計，但是如果它太大了，進展將通過活動的不同部分來表述。一些活動的例子： 計劃迭代過程：由“角色：項目經(jīng)理”執(zhí)行。 尋找用例和活動者：由“角色：系統(tǒng)分析人員”執(zhí)行。 評審設計：由“角色：設計評審員”執(zhí)行。 執(zhí)行性能測試：由“角色：性能測試人員”執(zhí)行?；顒涌煞纸鉃椴煌牟襟E，步驟主要分為三類：思考步驟擔當角色的人員要理解任務的性質(zhì)，收集并檢驗輸入制品，然后闡明輸出結(jié)果。執(zhí)行步驟擔當角色的人

25、員生產(chǎn)或更新一些制品。評審步驟擔當角色的人員根據(jù)某些標準檢驗結(jié)果。并不是每次活動必須執(zhí)行所有的步驟，可以用可替換流的形式將它們表示出來。例如，“活動：尋找用例和活動者”可分解為以下7個步驟： 1）尋找活動者。 2）尋找用例。 3）描述活動者和用例之間的交互作用。 4）將用例和活動者打包。 5）用例圖表示用例模型。 6）開發(fā)用例模型的綜述。 7）評估結(jié)果。 步驟l乃是尋找部分，需要一些思考；步驟4的是執(zhí)行部分，包括得到用例模型結(jié)果；步驟7是評審部分，需要角色來評價結(jié)果，以評估完整性、健壯性、可理解性和其他質(zhì)量特性。三、制品制品是由過程生產(chǎn)、修改或使用的信息。制品是項目的有形產(chǎn)品，即項目在生產(chǎn)出最

26、終產(chǎn)品的過程中生產(chǎn)或使用它們。角色可以把制品作為執(zhí)行一項活動的輸入，同時這個活動的輸出或者結(jié)果也是制品。 制品有以下不同形式： 模型，如用例模型或設計模型。 模型元素，一個模型中的元素，如類、用例或子系統(tǒng)。 文檔，如一個業(yè)務案例或軟件架構(gòu)文檔。 源代碼。 可執(zhí)行文件。下圖表示了RUP過程的制品及其相互關系。RUP過程的制品RUP制品中的一部分是將來要交付給項目的投資者或最終用戶的，而另一部分則是供開發(fā)人員在開發(fā)過程中使用的。 在RUP過程中將建立如下8種模型制品： l業(yè)務模型 業(yè)務模型是對問題領域中的組織機構(gòu)及其業(yè)務的抽象。 2Use Case模型 Use Case模型表達系統(tǒng)的功能需求。 3

27、分析模型 分析模型描述一個將建造的系統(tǒng)。分析模型是可選項，只有對于復雜的系統(tǒng)才需要建立獨立的分析模型。 4設計模型 設計模型給出系統(tǒng)設計的具體解決方案。設計模型除了處理功能需求之外，還要處理非功能性需求以及解決方案中的對象問題。 5進程模型 進程模型表達系統(tǒng)的并發(fā)和同步機制。進程模型是可選項，一般對于多線程的并發(fā)系統(tǒng)才建立進程模型。 6部署模型 部署模型表達系統(tǒng)的硬件拓撲，以及系統(tǒng)軟件在硬件上的配置。 7組件模型 組件模型表達用于組裝物理系統(tǒng)的各個軟部件。 8測試模型 測試模型表達驗證系統(tǒng)的途徑。 上述這些模型可以用UML的圖形和說明來表示。 在RUP過程中還將產(chǎn)生如下文檔制品： 技術文檔包括

28、： 1）需求分析文檔，如軟件需求說明書、需求補充說明、業(yè)務案例（劇本）等。 2）設計文檔，如圖形界面、詞匯表、軟件設計說明書、數(shù)據(jù)庫設計說明書等。 3）實現(xiàn)文檔，如源程序清單、動態(tài)連接庫說明、用戶使用手冊。 項目管理文檔：風險表、軟件開發(fā)計劃、配置計劃、測試計劃等。10.3 RUP迭代開發(fā)迭代開發(fā)的思想： 試想一下，如何吃掉一頭大象？一定是一口一口地吃！如果瀑布過程方法對于那些短期的或沒什么新意與風險的項目是適用的，甚至是成功的，那么為什么不把長期的大型項目分解為可連續(xù)應用瀑布模型的幾個小部分？通過這種方法，你可以先分析一部分需求和風險，設計、實現(xiàn)并確認了這一部分后，再做更多的需求分析、設計、

29、實現(xiàn)和確認，如此進行下去，直至整個項目完成為止。這就是選代開發(fā)思想。順序開發(fā)與迭代開發(fā)的比較一次迭代就是產(chǎn)生的一個版本所需進行的一組工作流活動。與傳統(tǒng)的瀑布過程相比，迭代過程有以一下優(yōu)點：更早地緩解風險。更容易地管理變更。提高了復用的程度。在整個過程中項目組可以不斷地學習。提高整體產(chǎn)品質(zhì)量。迭代技術說明很容易，但是做到并不容易。因為它帶來的問題要比它解決的問題更多：它是如何將各階段的結(jié)果聚合成一個產(chǎn)品的？你如何避免在混亂中開始一個迭代的周期？在每個迭代開發(fā)周期中你選擇做什么？你將要考慮哪些需求并考慮什么樣的風險？這個方法怎樣解決我們在以前提出的主要問題？增量是指系統(tǒng)中一個較小的可管理的部分，它

30、們可作為系統(tǒng)構(gòu)建時可分解功能構(gòu)造塊，每次迭代時可至少產(chǎn)生一個這樣的功能構(gòu)造塊。RUP的解決辦法：將多次迭代組織為增量迭代，并分四個階段和里程碑進行控制。 RUP迭代過程可以組織為如下四個階段，如下圖所示。但這些階段不同于瀑布方法中的步驟，并不是指需求分析、設計、編碼、集成和測試等傳統(tǒng)的順序階段，這些階段與傳統(tǒng)的階段互不相關。這里的每個階段以一個重要里程碑結(jié)束。 讓我們更詳細地研究這4個階段。 初始階段 詳細說明最終產(chǎn)品的構(gòu)想及其業(yè)務用例并定義項目范圍。初始階段以生命周期目標里程碑結(jié)束。 細化階段 計劃必需的活動和需要的資源；詳細說明產(chǎn)品特性并設計架構(gòu)。細化階段以生命周期架構(gòu)里程碑結(jié)束。 構(gòu)造階

31、段 構(gòu)造產(chǎn)品，逐步完善構(gòu)想、架構(gòu)和計劃，直到產(chǎn)品已完全準備好移交給它的用戶群為止。構(gòu)造階段以最初運作能力里程碑結(jié)束。 移交階段 移交產(chǎn)品給用戶，這個階段包括制造、交付、培訓、支持及維護產(chǎn)品，直至用戶滿意為止。移交階段以產(chǎn)品發(fā)布里程碑結(jié)束，也是整個周期的結(jié)束。在不同開發(fā)階段中工作流的重點10.4 以架構(gòu)為中心的過程一、什么是架構(gòu) RUP有很大一部分內(nèi)容是關注系統(tǒng)建模。模型幫助我們理解問題并確定解決問題的辦法。模型是對現(xiàn)實的簡化，它能幫助我們把握整體上不易理解的大型復雜系統(tǒng)。選擇用什么模型以及用哪項技術來表示它們，對于我們考慮問題和確定解決方案有著至關重要的影響。但沒有任何一個模型能涵蓋軟件開發(fā)的

32、各個方面，所以需要多個模型來表示系統(tǒng)不同的方面。這些模型一定要仔細協(xié)調(diào)，以確保一致性和無冗余。 光有多個模型表示系統(tǒng)不同的方面是不夠的。這好比寓言中的盲人摸象。它們各自都不能把握系統(tǒng)的總體。因此，需要有一個在多個模型基礎上的視圖來對系統(tǒng)進行總體描述。這樣的視圖稱為架構(gòu)（或稱體系結(jié)構(gòu)）二、為什么需要架構(gòu)？理解系統(tǒng)組織開發(fā)重用系統(tǒng)進化系統(tǒng)三、RUP中的軟件架構(gòu)與建筑物類似，軟件系統(tǒng)需要有多個模型視圖（即架構(gòu)）來描述將構(gòu)造的系統(tǒng)。下圖給出了RUP軟件架構(gòu)的“4+1”視圖。 1邏輯視圖 這個架構(gòu)視圖著重描述系統(tǒng)的功能性需求，換句話說，就是描述這個系統(tǒng)能為最終用戶做些什么。邏輯視圖是設計模型的抽象，確定

33、了主要的設計包、子系統(tǒng)和類。2實現(xiàn)視圖 這個視圖從打包、分層、配置管理（所有權(quán)、版本策略等）的角度描述了處于開發(fā)環(huán)境中的靜態(tài)軟件模塊（源代碼、數(shù)據(jù)文件、組件、可執(zhí)行程序和其他相關的制品）的組織。實現(xiàn)視圖著重討論了如何使開發(fā)工作更簡易，以及如何管理軟件資產(chǎn)、重用、轉(zhuǎn)包合同和現(xiàn)成的組件。3進程視圖 這個視圖表述了系統(tǒng)在運行時的并發(fā)性任務、線程、過程及它們之間的交互作用。進程視圖討論了并發(fā)性和并行性、系統(tǒng)啟動和關機、容錯性和對象分布等問題，處理了如死鎖、響應時間、吞吐量以及功能和故障的隔離問題等。它主要關注系統(tǒng)的可伸縮性。 4部署視圖 這個視圖展示了不同的可執(zhí)行程序和其他運行時組件是如何映射到底層平

34、臺或計算節(jié)點上的。這里融合了軟件工程和系統(tǒng)工程，討論了如部署、安裝和性能等問題。 5用例視圖 這個視圖在架構(gòu)中扮演了一個很特殊的角色。它包含幾個關鍵場景或者用例。最初，在初始和細化階段用它們來驅(qū)動架構(gòu)的挖掘和設計，但是后來用它們來驗證不同的視圖。這幾個場景用于說明在軟件架構(gòu)文檔中其他視圖是如何工作的。 四、模型與架構(gòu)視圖之間的關系 模型是系統(tǒng)的完整表達，而架構(gòu)視圖只關注對于架構(gòu)來說重要的方面。架構(gòu)視圖好像是從不同模型中切下來的薄片。 對架構(gòu)來說，重要的元素包括： 主要業(yè)務實體類 類的架構(gòu)機制，如持續(xù)性機制和通信機制 模式和框架 層和子系統(tǒng) 接口 主要的過程或控制的線程 五、以架構(gòu)為中心的過程

35、當一個團隊已經(jīng)一致認可了一個適合于解決手頭問題的架構(gòu)的表示，那么接下來的問題就是把握架構(gòu)設計過程。 RUP定義了兩個關于架構(gòu)的主要制品： 軟件架構(gòu)描述，它描述了與項目有關的架構(gòu)視圖。 架構(gòu)原型，它用于驗證架構(gòu)并作為剩余部分開發(fā)的基線。 其他三個制品是：設計指南，由所做的架構(gòu)選擇決定，反映了模式和習慣用語的使用。在開發(fā)環(huán)境中的產(chǎn)品結(jié)構(gòu)，它建立在實現(xiàn)視圖的基礎之上?；趯崿F(xiàn)視圖結(jié)構(gòu)的開發(fā)團隊結(jié)構(gòu)。 RUP定義了一個角色：軟件架構(gòu)師，他負責該架構(gòu)。但是架構(gòu)師并不是唯一關心架構(gòu)的人，大多數(shù)開發(fā)團隊的成員都參與了架構(gòu)的定義和實現(xiàn)（尤其是在細化階段）： 設計人員關注架構(gòu)方面重要的類和機制，而不是類的細節(jié)。 集成人員主要關注如何消除集成主要的現(xiàn)成組件或復用組件時的風險。 測試人員測試架構(gòu)原型的性能和健壯性。 六、基于組件的開發(fā) 基于組件開發(fā)的思想： 為了建立快速滿足業(yè)務需求的高質(zhì)量系統(tǒng)，主張應用各種部件而不是手工開發(fā)每一個單個元素。我們從構(gòu)建同類型系統(tǒng)的組件中找到所需的一組正確的基本組件，同時也要自己開發(fā)一部分組件。有些組件是專門制造的；另一些組件則是通過搜尋和改造