RUP開發(fā)過程課件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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