lec09統(tǒng)一建模語言UML和Rational統(tǒng)一過程RUP

1、第九講 統(tǒng)一建模語言UML和Rational統(tǒng)一過程RUP現(xiàn)代軟件開發(fā)面臨著要盡快將產(chǎn)品推向市場和開發(fā)高質(zhì)量、低成本產(chǎn)品的矛盾。要成功解決軟件開發(fā)中的矛盾，必須將軟件開發(fā)作為一種團隊活動。為了有效組織開發(fā)和進行交流，團隊中不同參與者統(tǒng)一使用公共的過程、公共的表達語言、以及支持該語言和過程的工具。Rational統(tǒng)一過程（RUP）就是這樣一種公共過程，而且已經(jīng)在多個軟件開發(fā)組織的實踐中被證實可以有效解決上述矛盾。統(tǒng)一建模語言（UML）則可以作為開發(fā)團隊的公共語言。UML不是完整的開發(fā)方法，UML規(guī)范也沒有定義標準的過程，而RUP則是有效使用UML的指南。本講著重介紹UML和RUP的基本概念，并描

2、述了如何在RUP的指導下用UML建模。一引言現(xiàn)代軟件開發(fā)中存在著一個基本矛盾：一方面，開發(fā)組織需要將產(chǎn)品盡快推向市場；另一方面，推出的軟件系統(tǒng)必須兼具高質(zhì)量和低成本。要在這二者之間取得平衡很困難：倉促地將一個軟件系統(tǒng)推向市場，其質(zhì)量肯定會受到影響；但是過分注重質(zhì)量可能會需要過多的時間才能將軟件交給用戶。要解決這個矛盾，首先要認識到軟件開發(fā)已經(jīng)發(fā)生了本質(zhì)的變化。以前，許多信息系統(tǒng)的體系結構相當簡單：上層的應用程序建立在中間層上，中間層則封裝了業(yè)務規(guī)則和數(shù)據(jù)存??；中間層建立在持久存儲之上，通常表現(xiàn)為一個關系數(shù)據(jù)庫，這個數(shù)據(jù)庫實質(zhì)上就是系統(tǒng)的中心。Client/Server體系結構的出現(xiàn)有助于實現(xiàn)這

3、種三層分離的體系，并且易于有效控制系統(tǒng)的變更。特別地，在保持系統(tǒng)狀態(tài)不變的情況下可以快速創(chuàng)建和修改應用，可以引入新的業(yè)務規(guī)則而不影響系統(tǒng)的穩(wěn)定，也可以隨著時間以新的和不可預知的方式來進行數(shù)據(jù)挖掘。這種穩(wěn)定的體系結構使得許多組織以相應的形式組織他們的開發(fā)團隊：分析人員和最終領域專家一起將用戶的要求轉化為需求，數(shù)據(jù)建模人員建立滿足用戶功能需求的領域模型，應用開發(fā)人員則迅速建造滿足系統(tǒng)行為需求的新系統(tǒng)。然而，隨著Web的出現(xiàn)，軟件開發(fā)的世界發(fā)生了不可逆轉的改變。首先，傳統(tǒng)C/S結構的系統(tǒng)中，用戶的數(shù)目是可以控制的，通常是數(shù)百或者數(shù)千。而Web上一個系統(tǒng)的用戶可能數(shù)以百萬計，并且大多不在系統(tǒng)開發(fā)組織的

4、控制之中。再者，在傳統(tǒng)的C/S系統(tǒng)中，應用和數(shù)據(jù)在概念上距離相當小，而Web上的許多系統(tǒng)都是由數(shù)千個可移動的部件組成，其中有使用腳本語言的，有經(jīng)過編譯的，使用的機制與傳統(tǒng)的關系型存儲大相徑庭。第三，在C/S系統(tǒng)中，變更是不可避免的，但可以適度地控制；而在Web上，變更是持續(xù)的，并且在系統(tǒng)體系結構和實現(xiàn)技術的每個層次上都會發(fā)生。最后，在C/S系統(tǒng)中，參與系統(tǒng)開發(fā)的人員相對較少，而在Web上除了傳統(tǒng)的軟件開發(fā)團隊以外，還有許多新的參與者，從內(nèi)容創(chuàng)建人員、信息架構構造人員到網(wǎng)絡設計人員，大家共同合作進行E-軟件的開發(fā)。另外，傳統(tǒng)上著重處理大量數(shù)據(jù)的系統(tǒng)在實現(xiàn)上是相對同構的，主要使用Cobol語言。而

5、Web的出現(xiàn)改變了一切。在Web上一個這樣的系統(tǒng)可能在服務器端使用Cobol、C+或Java，或者少量的腳本語言和4GL，在客戶端使用傳統(tǒng)的語言如VB和Java。有時也會使用諸如XML這樣的語言，而且XML本身就是作為一種在Web上表示結構化數(shù)據(jù)的通用語言出現(xiàn)的。除了面對這些龐雜的編程語言，開發(fā)隊伍還必須處理眾多的技術，如Micosoft的WinDNA，Sun的EJB等，這些技術提供給開發(fā)人員的編程模型也各不相同。對于一個組織而言，開發(fā)隊伍的成員能夠以一種通用的方式溝通是至關重要的，不同的參與者對系統(tǒng)的設計和實現(xiàn)有不同的看法，只有使用通用的語言表達，才可能統(tǒng)一開發(fā)團隊的活動。因此，要成功解決軟

6、件開發(fā)中的矛盾，必須將軟件開發(fā)作為一種團隊活動，團隊中從事開發(fā)和部署的不同參與者統(tǒng)一使用公共的過程、公共的表達語言、以及支持該語言和過程的工具。Rational統(tǒng)一過程（Rational Unified Process，RUP）就是這樣一種公共過程，而且已經(jīng)在多個軟件開發(fā)組織的實踐中被證實可以有效解決上述矛盾。RUP提供在開發(fā)機構中分派任務和責任的紀律化方法，它的目標是在可預見的日程和預算的前提下，確保滿足最終用戶需求的高質(zhì)量產(chǎn)品。RUP是風險和用例驅動的過程，它鼓勵系統(tǒng)可執(zhí)行版本的迭代和增量式交付，其迭代以用例為依據(jù)。除此之外，RUP還是體系結構優(yōu)先的過程，系統(tǒng)的體系結構在早期就穩(wěn)定下來，以

7、便對設計進行驗證，在后續(xù)的迭代中逐步進行精化。統(tǒng)一建模語言UML（Unified Modelling Languae，UML）可以作為開發(fā)團隊的公共語言。UML是一種直觀化、明確化、構建和文檔化軟件系統(tǒng)產(chǎn)物的圖形化語言。UML最主要的目標是成為所有建模人員可以使用的通用建模語言，它包含了當前主流建模技術的概念，并針對許多當前軟件開發(fā)的問題，如大規(guī)模、分布、并發(fā)和團隊開發(fā)等。UML不是完整的開發(fā)方法，不包括逐步的開發(fā)流程。對于軟件開發(fā)來說，良好的開發(fā)過程非常重要。UML規(guī)范沒有定義標準的過程，但是可以用于迭代的開發(fā)過程，并支持現(xiàn)有的大多數(shù)面向對象的開發(fā)過程。而RUP則是有效使用UML的指南。下面

8、將分別介紹統(tǒng)一建模語言和Rational統(tǒng)一過程。二統(tǒng)一建模語言UML UML是一種可視化的建模語言，結合了Booch、Objectory和OMT方法，同時吸收了其它大量方法學的思想，提供了一種表示的標準。1997年OMG采納UML作為軟件建模語言的標準，可以應用于不同的軟件開發(fā)過程。下面介紹UML涉及的一些基本概念。1視圖（Views）UML用模型來描述系統(tǒng)的靜態(tài)結構和動態(tài)行為。為了捕捉要構建的軟件系統(tǒng)的所有決策信息，需要從團隊中不同參與者的角度出發(fā)，為系統(tǒng)的體系結構建模，形成不同的系統(tǒng)視圖。要描述一個軟件系統(tǒng)，下面的五種視圖尤為重要：（1）用例視圖（Use case view）用例視圖定義

9、系統(tǒng)的外部行為，是最終用戶、分析人員和測試人員所關注的。用例視圖定義了系統(tǒng)的需求，是描述系統(tǒng)設計和構建的其它視圖的基礎，即用例驅動。用例視圖也稱為用戶模型視圖。（2）邏輯視圖（Logic view）邏輯視圖描述邏輯結構，該邏輯結構支持用例視圖描述的功能，它描述了問題空間中的概念以及實現(xiàn)系統(tǒng)功能的機制，如類、包、子系統(tǒng)等，因而是編程人員最關心的。邏輯視圖又稱作結構模型視圖或靜態(tài)視圖。（3）實現(xiàn)視圖（Implementation view）實現(xiàn)描述用于組建系統(tǒng)的物理組件，如可執(zhí)行文件、代碼庫和數(shù)據(jù)庫等系統(tǒng)程序員所看到的軟件產(chǎn)物，是和配置管理以及系統(tǒng)集成相關的信息。實現(xiàn)視圖又稱為組件視圖（Compo

10、nent view）。（4）過程視圖（Process view）過程視圖描述將系統(tǒng)分解為過程和任務，以及這些并發(fā)元素之間的通信與同步。過程視圖對于系統(tǒng)集成人員特別重要，因為他們需要考慮系統(tǒng)的性能和吞吐量等。過程視圖也稱為并發(fā)視圖、動態(tài)視圖或者協(xié)作視圖等。（5）配置視圖（Deployment view）描述系統(tǒng)的物理網(wǎng)絡布局，是系統(tǒng)工程師和網(wǎng)絡工程師所感興趣的。又稱作物理視圖。2圖（Diagrams）每個視圖都由一個或者多個圖組成，一個圖是系統(tǒng)體系結構在某個側面的表示，所有的圖在一起組成系統(tǒng)的完整視圖。UML提供了九種不同的圖，分為靜態(tài)圖和動態(tài)圖兩大類。靜態(tài)圖包括用例圖、類圖、對象圖、組件圖和配

11、置圖，動態(tài)圖包括序列圖、狀態(tài)圖、協(xié)作圖和活動圖。（1）用例圖（Use case diagram）：用例圖描述系統(tǒng)的功能，由系統(tǒng)、用例和角色（Actor）三種元素組成。圖中顯示若干角色以及這些角色和系統(tǒng)提供的用例之間的連接關系。用例是系統(tǒng)對外提供的功能的描述，是角色和系統(tǒng)在一次交互過程中執(zhí)行的相關事務的序列。角色是與系統(tǒng)、子系統(tǒng)或類交互的外部人員、進程或事物。用例之間存在擴展、使用和組合三種關系。角色之間可以用通用化關系將某些角色的共同行為抽象為通用行為。在UML中，用例圖是用例視圖的重要組成部分。（2）類圖（Class diagram）類圖用來表示系統(tǒng)中的類以及類與類之間的關系，描述系統(tǒng)的靜態(tài)

12、結構，用于邏輯視圖中。類是對象的抽象描述。所謂對象就是可以控制和操作的實體，類是具有共同的結構、行為、關系、語義的一組對象的抽象。類的行為和結構特征分別通過操作和屬性表示。類與類之間有多種關系，如關聯(lián)、依賴、通用化、聚合等。關系提供了對象之間的通信方式。關聯(lián)關系用于描述類與類之間的連接，通常是雙向的。通用化又稱繼承，是通用元素和具體元素之間的一種分類關系，具體元素完全擁有通用元素的信息，并且還可以附加其它信息。聚合關系具有較強的耦合性，描述整體與部分的關系。依賴關系描述兩個模型元素之間語義上的連接關系，其中一個元素是獨立的，另一個元素依賴于獨立的模型元素，獨立元素的變化將影響到依賴元素。（3）

13、對象圖（Object diagram）對象圖是類圖的示例，類圖表示類和類與類之間的關系，對象圖則表示在某一時刻這些類的具體實例以及這些實例之間的具體連接關系，可以幫助人們理解比較復雜的類圖。對象圖也可以用于顯示類圖中的對象在某一點的連接關系。對象圖常用于用例視圖和邏輯視圖中。（4）狀態(tài)圖（Statechart diagram）狀態(tài)圖主要用來描述對象、子系統(tǒng)、系統(tǒng)的生命周期。通過狀態(tài)圖可以了解一個對象可能具有的所有狀態(tài)、導致對象狀態(tài)改變的事件、以及狀態(tài)轉移引發(fā)的動作。狀態(tài)是對象操作的前一次活動的結果，通常由對象的屬性值來決定。事件指的是發(fā)生的且引起某些動作執(zhí)行的事情。狀態(tài)的變化稱作轉移，與轉移相

14、連的動作指明狀態(tài)轉移時應該做的事情。狀態(tài)圖是對類描述的事物的補充說明，用在邏輯視圖中描述類的行為。（5）序列圖（Sequence diagram）面向對象系統(tǒng)中對象之間的交互表現(xiàn)為消息的發(fā)送和接收。序列圖反映若干個對象之間的動態(tài)協(xié)作關系，即隨著時間的流逝，消息是如何在對象之間發(fā)送和接收的。序列圖表現(xiàn)為二維的形式，其中的縱坐標軸顯示時間，橫坐標軸顯示對象。序列圖中重點反映對象之間發(fā)送消息的先后次序，常用在邏輯視圖中。（6）協(xié)作圖（Collaboration diagram）協(xié)作圖主要描述協(xié)作對象之間的交互和鏈接。協(xié)作圖和序列圖同樣反映對象間的動態(tài)協(xié)作，也可以表達消息序列，但重點描述交換消息的對象

15、之間的關系，強調(diào)的是空間關系而非時間順序。（7）活動圖（Activity diagram）活動圖顯示動作及其結果，著重描述操作實現(xiàn)中所完成的工作以及用例實例或對象中的活動?；顒訄D中反映了一個連續(xù)的活動流，常用于描述一個操作執(zhí)行過程中所完成的工作。活動圖也有其它的用途，如顯示如何執(zhí)行一組相關的動作，以及這些動作如何影響它們周圍的對象，說明一次商務活動中的工人、工作流、組織和對象是如何工作的，等等。（8）組件圖（Component diagram）組件圖用來反映代碼的物理結構。組件可以是源代碼、二進制文件或可執(zhí)行文件，包含邏輯類的實現(xiàn)信息。實現(xiàn)視圖由組件圖構成。（9）配置圖（Deployment

16、diagram）配置圖用來顯示系統(tǒng)中軟件和硬件的物理架構。圖中通常顯示實際的計算機和設備及它們之間的關系。配置圖用來構成配置視圖，描述系統(tǒng)的實際物理結構。3模型元素可以在圖中使用的概念統(tǒng)稱為模型元素。模型元素用語義、元素的正式定義或確定的語句的準確含義來定義。模型元素在圖中用相應的符號表示，即視圖元素。一個模型元素可以用在多個不同的圖中，但總是具有相同的含義和符號表示，并且出現(xiàn)的方式應符合一定的規(guī)則。除了類、對象、消息等概念外，模型元素之間的連接關系如關聯(lián)、依賴、通用化也是模型元素。另外，模型元素也包括消息、動作和版型等。4通用機制通用機制用于為圖附加一些無法用基本的模型元素表示的信息，如注釋

17、（note）、修飾（adornment）和規(guī)格說明（specification）等。在圖的模型元素上添加修飾為模型元素附加一定的語義。這樣，建模人員就可以方便地區(qū)別類型與實例。無論建模語言怎樣擴展，它都不可能適用于描述任何事物。UML提供的注釋能力能夠在模型中添加一些模型元素無法表示的額外信息，對某個元素作出解釋或說明。模型元素具有的一些性質(zhì)是以數(shù)值方式體現(xiàn)的。一個性質(zhì)用一個名字和一個值表示，又稱作加標簽值（tagged value）。UML中預定義了許多性質(zhì)，一般作為模型元素實例的附加規(guī)格說明。這種規(guī)范說明方式是非正式的，不直接顯示在圖中。5擴展機制為了使建模人員根據(jù)需要對基本建模語言進行一

18、定的擴展，UML提供了版型（stereotype）、加標簽值和約束（constrains）等擴展機制。版型機制是指在已有的模型元素基礎上建立一種新的模型元素。版型比現(xiàn)有元素多一些特別的語義，其使用場所和產(chǎn)生版型的原始元素相同。版型的存在避免了UML語言過于復雜化，同時也使UML能夠適應各種需求。加標簽值也稱為性質(zhì)。除了UML語言中預定義的性質(zhì)外，用戶還可以為元素定義一些附加信息，即定義性質(zhì)。約束是對元素的限制。通過約束限定元素的用法或元素的語義。通過擴展機制可以擴展UML以適用于某種具體的方法、過程或組織。6UML建模用UML語言建造系統(tǒng)模型時，并不是只建立一個模型。在系統(tǒng)開發(fā)的每個階段都要建

19、造不同的模型，建造這些模型的目的也不同。需求分析階段建造的模型用來捕獲系統(tǒng)的需求、描繪與真實世界相應的基本類和協(xié)作關系。設計階段的模型是分析模型的擴充，為實現(xiàn)階段作指導性的、技術上的解決方案。實現(xiàn)階段的模型是真正的源代碼，編譯后就變成了程序。最后的配置模型則是在物理架構上解釋系統(tǒng)是如何展開的。UML盡可能地結合了世界范圍內(nèi)面向對象項目的成功經(jīng)驗，因而它的價值在于它體現(xiàn)了世界上面向對象方法實踐的最好經(jīng)驗，并以建模的形式將它們打包，以適應開發(fā)大型復雜系統(tǒng)的要求。但需要說明的是，UML作為一種建模語言，目的是為不同領域的人們提供統(tǒng)一的交流標準，其本身并不能保證系統(tǒng)的質(zhì)量。使用UML建模，必須依照某種

20、方法或過程進行。在眾多的軟件設計和實現(xiàn)的經(jīng)驗中，最突出的有兩條，一是注重系統(tǒng)體系結構的開發(fā)，一是注重過程的迭代和遞增性。盡管UML本身沒有定義任何過程，但UML對任何使用它的方法或過程提出的要求是：支持用例驅動、以體系結構為中心以及遞增和迭代地開發(fā)。三Rational統(tǒng)一過程RUP如上所述，UML提供了為系統(tǒng)進行面向對象建模的機制，但沒有指定應用UML的過程和方法。UML的設計目標之一是在盡可能多的領域內(nèi)得到廣泛的應用，但要想成功使用UML，科學的過程是必要的。合理的過程能夠有效測度工作進程，控制和改進工作效率。簡單地說，軟件工程過程描述做什么、怎么做、什么時候做以及為什么要做，描述了一組以某

21、種順序完成的活動。過程的結果是一組有關系統(tǒng)的文檔，例如模型和其它一些描述，以及對最初問題的解決方案。過程描述的一個重要部分是定義如何使用人力、及其、工具和信息等資源的一些規(guī)則來完成某個確定的目標，為用戶的問題提供解決方案。目前比較流行的有幾種主要的過程，包括Rational的統(tǒng)一過程、OPEN過程和面向對象軟件過程（OOSP）。其中RUP是由Booch等方法學家以Rational的Objectory為核心提出的，因此在這個過程中使用UML是很自然的。下面主要對RUP進行簡單介紹。RUP是Ratinal公司開發(fā)的過程產(chǎn)品，是軟件工程化的過程。RUP提供了在開發(fā)機構中分派任務和責任的紀律化方法。它

22、的目標是在可預見的日程和預算的前提下，確保滿足最終用戶需求的高質(zhì)量產(chǎn)品。1軟件開發(fā)的六大經(jīng)驗RUP反映了現(xiàn)代軟件開發(fā)過程中的最佳實踐經(jīng)驗，使用RUP作為指南，部署這些最佳實踐為開發(fā)隊伍提供了大量的關鍵優(yōu)勢。目前軟件開發(fā)實踐中得到的六個最佳經(jīng)驗是： 迭代的軟件開發(fā) 需求管理 使用基于構件的體系結構 可視化軟件建模 驗證軟件質(zhì)量 控制軟件的變更Rational統(tǒng)一過程的核心是為軟件開發(fā)團隊提供指南、文檔模板和工具，以使整個團隊能夠最有效地利用這些最佳的軟件開發(fā)經(jīng)驗：（1）迭代的軟件開發(fā)當今的軟件系統(tǒng)十分復雜，很難按照首先定義整個問題、設計整個系統(tǒng)、構建軟件、最后測試產(chǎn)品的順序線性進行。而是需要一種

23、迭代的方法，通過不斷地細化來增進對問題的理解，在多個迭代的基礎上遞增地得到一個有效的解決方案。RUP支持迭代開發(fā)，在生命周期的每個階段都注重風險最高的問題，顯著地降低項目的風險系數(shù)。這種迭代的方法通過可見的進展情況、可執(zhí)行版本來促進最終用戶的參與和反饋，從而有助于降低開發(fā)過程中的風險。而且，因為每個迭代結束時都提交一個可執(zhí)行的系統(tǒng)版本，使開發(fā)團隊能夠始終將注意力放在產(chǎn)品上，經(jīng)常性的階段檢查也確保項目按計劃進行。迭代方法還很容易容納需求、特色或規(guī)劃上的改變。（2）需求管理RUP描述了如何啟發(fā)、組織所需要的功能和約束，以及如何為它們建立文檔，如何跟蹤和建檔折衷方案和決策，并且易于表達商業(yè)需求和交流

24、。過程所規(guī)定的用例和場景已經(jīng)被證明是表達功能性需求以及保證其驅動軟件的設計、實現(xiàn)和測試，使最終系統(tǒng)更充分地滿足用戶需要的最佳方法。它們提供了貫穿整個開發(fā)和所提交系統(tǒng)的一致且可跟蹤的線索。（3）使用基于構件的體系結構RUP側重在利用資源進行規(guī)模開發(fā)之前，注重體系結構早期的開發(fā)和基線。它描述了如何設計一個能適應變化、直觀、有利于系統(tǒng)復用的靈活的體系結構。RUP支持基于構件的軟件開發(fā)。構件是完成一個明確功能的模塊或子系統(tǒng)。RUP提供了一個系統(tǒng)的方法用新的和已有的構件定義體系結構。（4）為軟件建立可視化模型統(tǒng)一過程告訴我們?nèi)绾慰梢暬貫檐浖Ｒ员磉_體系結構和構件的結構和行為。這樣，就可以隱藏細節(jié)，使

25、用圖形化的基本模塊來寫代碼。使用抽象可視化有助于進行不同方面的溝通，顯示出系統(tǒng)元素是如何組織在一起的；保證各部件與代碼一致；維護設計和實現(xiàn)的一致性；促進無二義性的交流。UML正是成功進行可視化建模的基礎。（5）驗證軟件質(zhì)量軟件性能和可靠性的低下是影響軟件使用的最重要的因素。因此應該根據(jù)基于可靠性、功能、應用性能和系統(tǒng)性能的需求對軟件的質(zhì)量進行評估。RUP可以幫助進行這些類型的規(guī)劃、設計、實現(xiàn)、執(zhí)行和評估。質(zhì)量評估嵌入在整個過程的每個活動中，讓所有的人員都參與，使用目標試題和準則，而不再只是事后工作，也不由單獨的小群體各自完成。（6）控制對軟件的變更對變更進行管理的能力確保每個變化都是可接受的，

26、而在變更不可避免的環(huán)境中，跟蹤變更的能力是最根本的。統(tǒng)一過程描述了如何控制、跟蹤和監(jiān)視變更，從而保證迭代開發(fā)過程的成功。它也指導人們?nèi)绾瓮ㄟ^控制所有對軟件制品（如模型、代碼、文檔等）的變更，從而隔離來自其它工作空間的變更，以此為每個開發(fā)人員建立安全的工作空間。它還描述了如何自動化集成和建立管理，從而使一個團隊的工作團結一致。2過程的二維空間統(tǒng)一過程可以在二維空間中描述，如圖1所示。圖1 過程在二維空間中的組織 水平軸代表時間，顯示了過程動態(tài)的一面，是用周期（cycle）、階段（phase）、迭代（iteration）、里程碑（milestone）等術語來描述的。 垂直軸代表過程靜態(tài)的一面：是用

27、活動（activity）、產(chǎn)品（artifact）、工人（worker）和工作流（workflow）描述的。3過程和迭代過程隨著時間動態(tài)組織，把軟件的生存期劃分為一些周期，每個周期都影響新一代產(chǎn)品。RUP把一個開發(fā)周期劃分為四個連續(xù)的階段： 初始階段（Inception phase） 細化階段（Elaboration phase） 構造階段（Construction phase） 交付階段（Transition phase）每個階段的結果都是一個里程碑。里程碑是一個時間點，在這個時間點上必須做出重要的決策，達到一些關鍵的目標。每個階段都有明確的目標。（1）初始階段初始階段的目標是，為系統(tǒng)建立商

28、業(yè)用例，確定項目的邊界。為了達到這些目的，必須找出所有與系統(tǒng)交互的外部實體，并在較高的層次定義這些交互的特性。包括識別所有用例并描述一些有意義的用例。商業(yè)用例包括成功的準則、風險評估、對所需資源的估計以及顯示主要里程碑日期的階段規(guī)劃。初始階段的主要成果是： 前景文檔：對核心項目要求、關鍵性質(zhì)、主要限制的一般性的前景說明； 初始的用例模型（完成1020） 初始的項目術語表 初始的商業(yè)用例，包括商業(yè)環(huán)境、一驗收規(guī)范以及成本預測 初始的風險評估 項目規(guī)劃，其中明確階段和迭代 商業(yè)模型，根據(jù)需要可選 一個或多個原型初始階段結束時是第一個里程碑：生命周期目標里程碑。對初始階段進行評估的準則是： 風險承擔

29、人對項目范圍定義和成本/進度估計達成共識 需求由主要的用例無二義地表達出來 成本/進度估計、優(yōu)先級、風險和開發(fā)過程的可信度 開發(fā)出來的體系結構原型的深度和廣度 實際支出與計劃支出的比較如果項目沒有通過這個里程碑，就應該考慮取消或者重新思考。（2）細化階段細化階段的目標是分析問題領域，建立一個健全的體系結構基礎，編制項目規(guī)劃，淘汰項目中風險最高的元素。為了達到這些目標，必須對系統(tǒng)有一個廣泛的認識。體系結構的決策必須建立在對整個系統(tǒng)的有一個理解的基礎上，包括系統(tǒng)的范圍、主要功能和非功能需求等。細化階段是四個階段中最關鍵的。在這個階段的最后，就認為已經(jīng)完成最困難的工程，可以進行項目的結算：決定是否把

30、它提交到構造和交付階段。對大多數(shù)項目來說，這也相當于從低風險的運作到高成本、高風險運作的過渡。盡管過程必須能夠適應不斷的變化，但是細化階段的活動必須保證體系結構、需求和規(guī)劃有足夠的穩(wěn)定性，充分降低風險，從而才能夠預算出整個開發(fā)過程的成本和進度。在細化階段，根據(jù)項目的范圍、大小和創(chuàng)新性，可能在一個或多個迭代中，建立一個可執(zhí)行的體系結構。這一工作至少要解決初始階段中找出的最重要的用例，而它們通常也揭示了項目的主要技術風險。雖然目標是為產(chǎn)品質(zhì)量組件建立一個不斷演化的原型，但也不排除開發(fā)一個或多個拋棄型的原型，來降低某些風險，或給投資人、客戶或最終用戶演示。細化階段的成果是： 用例模型（至少完成80）

31、：識別出了所有的用例和角色，以及大多數(shù)用例的描述 一些增加的需求，包括非功能性需求以及任何與特定用例無關的需求 軟件體系結構描述 可執(zhí)行的體系結構原型 修訂后的風險表和商業(yè)用例 整個項目的開發(fā)計劃，包括粗略項目規(guī)劃，顯示迭代過程以及相應的評估準則 更新的開發(fā)用例，指定要使用的過程 初步的用戶手冊（可選）細化階段結束時是第二個重要的里程碑：生命周期體系結構里程碑。此時檢查系統(tǒng)詳細的目標和范圍，體系結構的選擇以及對主要風險的解決。細化階段的評估準則包括對以下問題的回答： 產(chǎn)品的前景是否穩(wěn)定？ 體系結構是否穩(wěn)定？ 可執(zhí)行的演示是否強調(diào)了主要的風險元素，并且已經(jīng)解決？ 構造階段的規(guī)劃是否已經(jīng)足夠詳細和

32、準確，是否有可信的評估支持？ 如果用當前的規(guī)劃來開發(fā)整個系統(tǒng)，并且使用當前的體系結構的話，是否所有的風險承擔人對當前的前景都達成一致？ 是否實際的資源支出與計劃的支出都是可接受的？如果項目不能通過這個里程碑，則將取消或重新考慮。（3）構造階段在構造階段，將開發(fā)所有剩余的構件和應用部件，對它們進行測試，并集成到產(chǎn)品中。從某種意義上說，構造階段是一個制造過程，重點是管理資源、控制運作、優(yōu)化成本、進度和質(zhì)量。從這個意義來說，管理層是從初始和細化階段對智力產(chǎn)品的開發(fā)轉向構造和交付階段對可應用產(chǎn)品的開發(fā)。對于許多大規(guī)模的項目可以分散地進行并行增量地構造。這些并行活動可以顯著加速可應用版本的開發(fā)速度，但也

33、增加了資源管理和工作流同步的復雜性。健壯的體系結構和易于理解的規(guī)劃是息息相關的。換言之，體系結構最重要的一個質(zhì)量因素就是它是否容易構造，這也是為什么在細化階段強調(diào)平衡開發(fā)體系結構和規(guī)劃的原因之一。構造階段的產(chǎn)品是一個可以立即提交給最終用戶使用的產(chǎn)品，它至少應該包括： 在特定平臺上集成的軟件產(chǎn)品 用戶手冊 對當前版本的描述構造階段結束是第三個里程碑：初始運行能力。此時要決定軟件、節(jié)點和用戶是否已經(jīng)準備好運行，并且項目沒有出現(xiàn)任何高風險問題。這個版本通常叫做beta版。構造階段的評估準則包括對以下問題的回答： 這個產(chǎn)品版本是否足夠穩(wěn)定和成熟，可以在用戶群中發(fā)布嗎？ 是否所有的風險承擔人都已經(jīng)準備好

34、向用戶提交？ 實際的資源支出和計劃的支出的比值是否仍然可接受？如果項目沒有達到這個里程碑，必須推遲發(fā)布。（4）交付階段交付階段的目的是把軟件產(chǎn)品交付給用戶群。一旦產(chǎn)品提交給最終用戶，通常會產(chǎn)生新的要求，如繼續(xù)開發(fā)新版本，修正一些問題，或者完成某些被推遲的功能部件。當基線足夠成熟，能夠向最終用戶領域發(fā)布時，就進入了交付階段。這通常需要系統(tǒng)的一些可以使用的子集已經(jīng)達到一定的質(zhì)量要求，并且有用戶文檔，從而使交付產(chǎn)生積極的效果。包括： beta測試確認新系統(tǒng)達到用戶的預期 與被取代的舊系統(tǒng)并行操作 功能性數(shù)據(jù)庫的轉換 用戶和維護人員培訓 向市場、分銷商和銷售人員進行新產(chǎn)品的展示。交付階段側重向用戶提交

35、軟件的活動，這個階段包括幾個典型的迭代，如beta版本，通用版本以及對用戶的反饋作出響應等，都需要可觀的精力。但是，在生命周期的這一點上，用戶反饋可能主要限于產(chǎn)品調(diào)整、配置、安裝和可用性問題上。交付階段的主要目標包括： 使用戶可以自我?guī)椭?使風險承擔人合作，使展開基線完整，并與前景評估準則一致這一階段根據(jù)產(chǎn)品的不同，可以非常簡單，也可以極其復雜。交付階段的終點是第四個重要的項目里程碑：產(chǎn)品發(fā)布里程碑。在這個點上，要確定是否已經(jīng)達到目標，能否開始另一個開發(fā)周期。交付階段主要的評估準則包括對以下問題的回答：·用戶是否滿意？·是否能夠接受實際的和計劃的資源支出的比？（5）迭代RU

36、P中的每個階段都可以進一步分解為迭代。迭代是一個完整的開發(fā)循環(huán)，它的結果是可執(zhí)行產(chǎn)品的一個版本，是正在開發(fā)的最終產(chǎn)品的一個子集，從一個迭代到另一個迭代，不斷遞增地成長，直到最后成為最終系統(tǒng)。相對于傳統(tǒng)的瀑布過程，迭代過程具有以下優(yōu)點： 在早期就降低風險 對變更易于進行控制 更高的可復用性 項目團隊在開發(fā)過程中可以學習 更好的整體質(zhì)量4過程的靜態(tài)結構軟件工程過程定義誰在做什么、怎么做以及什么時候做，RUP用四個主要的建模元素表達：·工人（Workers）誰·活動（Activities）怎么做·產(chǎn)品（Artifacts）做什么·工作流（Workflows）什

37、么時候做（1）活動、產(chǎn)品和工人 工人：工人定義了個體或一個作為團隊工作小組的行為和責任。工人是個體在項目中的一個角色，一個人可以擔任多個角色。分配給工人的責任包括完成某一系列活動以及擁有某一組產(chǎn)品。 活動：某個工人的活動是承擔這一角色的人必須完成的一組工作?；顒佑忻鞔_的意圖，通常用創(chuàng)建或更新某些產(chǎn)品來表示，這些產(chǎn)品包括模型、類、規(guī)劃等。每個活動都分配給一個特定的工人?；顒拥牧６韧ǔ膸讉€小時到幾天不等，通過涉及一個工人，影響一個或少量產(chǎn)品?；顒討摽梢宰鳛橐?guī)劃和進展的元素，如果太小，它就被忽略；如果太大，就不得不用活動的一部分來表示進展。例如規(guī)劃一個迭代是工人項目經(jīng)理的活動，找出用例和角色是工

38、人系統(tǒng)分析員的活動，執(zhí)行性能測試是工人性能測試員的活動，等等。 產(chǎn)品。產(chǎn)品是一個過程所生產(chǎn)、修改或使用的一段信息。產(chǎn)品是項目切實的成果，是項目為生產(chǎn)出最終的產(chǎn)品而制造或使用的東西。產(chǎn)品是工人為了完成一個活動而用的輸入，也是活動的輸出或成果。用面向對象設計的術語來說，活動是在活動對象上的操作，產(chǎn)品則是活動的參數(shù)。產(chǎn)品可以具有不同的形式，如·模型，如用例模型或設計模型·模型元素，如類，用例或子系統(tǒng)·文檔，如商業(yè)用例或軟件體系結構文檔·源代碼·可執(zhí)行程序（2）工作流僅僅把所有的工人、活動和產(chǎn)品都列舉出來還不能夠組成過程，另外還需要一種有效的方式，把產(chǎn)

39、生有價值結果的活動序列描述出來，并顯示工人之間的交互。工作流是一個產(chǎn)生具有可觀察的結果活動序列。UML中，可以用一個序列圖、協(xié)作圖或活動圖來表示工作流。需要注意的是，工作流中不能表示出活動之間所有的相關性，通常，兩個活動之間的相關性會比圖中顯示出來的更緊密，尤其是當它們涉及同一個工人或個人時。因此不能把工作流解釋成由人機械執(zhí)行的程序。下面介紹開發(fā)過程中最基本的工作流，稱為核心工作流。5核心工作流（Core Workflows）RUP中有九種核心過程工作流，把工人和活動劃分為不同的邏輯組合。核心過程工作流被劃分為六個核心“工程”工作流： 商業(yè)建模工作流 需求工作流 分析和設計工作流 實現(xiàn)工作流

40、測試工作流 展開工作流三個核心“支持”工作流： 項目管理工作流 配置和變更管理工作流 環(huán)境工作流這里的六個核心工程工作流不同于傳統(tǒng)瀑布過程中的幾個順序階段。迭代過程的階段是不同的，在整個生命周期中，這些工作流被重復訪問。在一個項目實際的完整的工作流中，這九個核心工作流是相互交錯的，并且在每個迭代中都以不同的重點和強度重復。（1）商業(yè)建模大多數(shù)商業(yè)工程項目的主要問題在于軟件工程和商業(yè)工程這兩個領域無法進行交流，導致商業(yè)工程的輸出無法正確地用作軟件開發(fā)的輸入，反之亦然。RUP通過為這兩個領域提供一個共同的語言和過程，同時說明如何創(chuàng)建和維護商業(yè)和軟件模型之間直接的可跟蹤性來解決這個問題。在商業(yè)建模中

41、，我們用所有的商業(yè)用例來為商業(yè)過程建立文檔，這確保所有的風險承擔人可以對機構到底需要支持什么樣的商業(yè)過程達成共識。對商業(yè)用例的分析是為了理解商業(yè)到底是如何支持商業(yè)過程的，這些是用商業(yè)對象模型來建檔的。許多項目并不進行商業(yè)建模。（2）需求需求工作流的目標是描述系統(tǒng)應該做什么，并且允許開發(fā)人員和客戶就這個描述達成共識。為了達到這個目的，我們提取、組織、文檔化需要的功能和約束，跟蹤并記錄所做的折衷和決策。（3）分析和設計分析和設計工作流的目標是說明在實現(xiàn)階段是如何實現(xiàn)系統(tǒng)的。建立的系統(tǒng)要： 在特定環(huán)境下，完成用例描述中指定的任務和功能 滿足所有需求 其構造確保它是健壯的（如果功能需求發(fā)生變化時，易于

42、更改）。分析與設計的結果是設計模型以及一個可選的分析模型。設計模型是源代碼的一個抽象，也就是說，設計模型的作用是一個“藍圖”，描述了如何對源代碼進行組建和編制。設計模型由設計類和一些描述組成，設計類被組織成具有良好接口的設計包和設計子系統(tǒng)，而描述則體現(xiàn)了類的對象如何協(xié)同工作實現(xiàn)用例的功能。設計活動以體系結構為中心，構建和確認這個體系結構是早期迭代最主要的重點。體系結構用結構視圖來表示，這些視圖表達了主要的結構設計決策。從本質(zhì)上，體系結構視圖是整個設計的抽象或簡化，丟掉細節(jié)，使重要的特征明顯地表現(xiàn)出來。體系結構對于開發(fā)好的設計模型以及對于提高系統(tǒng)開發(fā)過程中任何模型的質(zhì)量而言，都是重要的載體。（4

43、）實現(xiàn)實現(xiàn)的目的是： 通過分層次地組織實現(xiàn)子系統(tǒng)來定義代碼的結構 用構件（源文件、二進制文件、可執(zhí)行文件等）的形式來實現(xiàn)類 對所開發(fā)的構件進行單元進行測試 把每個實現(xiàn)人員（團隊）的工作成果集成到一個可執(zhí)行的系統(tǒng)中系統(tǒng)是通過實現(xiàn)構件實現(xiàn)的。RUP描述了如何重用已有構件，或實現(xiàn)新的良定義責任的構件，使系統(tǒng)更易于維護，提高可重用性。構件被構造成實施子系統(tǒng)。子系統(tǒng)以帶有附加結構或管理信息的目錄形式表示。（5）測試測試的目的是： 驗證對象之間的交互 驗證是否恰當?shù)丶闪塑浖乃袠嫾?驗證是否所有需求被正確實現(xiàn) 在發(fā)布軟件之前，找到錯誤并改正RUP是用迭代的方法，意味著在整個項目中都在進行測試，從而允許

44、盡可能早地發(fā)現(xiàn)錯誤，從根本上降低修改錯誤的成本。測試分別從可靠性、功能性、應用性能和系統(tǒng)性能三個方面進行。對每個方面都描述了如何經(jīng)歷規(guī)劃、設計、實現(xiàn)、執(zhí)行和評估的測試生命周期。另外，描述了何時及如何引入測試自動化的策略。測試自動化對迭代方法尤其重要，在每個迭代結束和產(chǎn)品新版本開始時都要進行回歸測試。（6）發(fā)布、展開發(fā)布工作流的目的是為了成功地開發(fā)出產(chǎn)品版本，并把軟件提交給它的最終用戶。包括一系列的活動： 制作軟件的外部版本 軟件打包 分發(fā)軟件 為用戶提供幫助和支持在許多情況下還包括： 規(guī)劃和實施beta測試 移植現(xiàn)有軟件或數(shù)據(jù) 正式接受盡管發(fā)布活動大部分集中在交付階段，但許多活動還需要在較早階

45、段就進行準備。（7）項目管理軟件項目管理是平衡競爭目標、管理風險和戰(zhàn)勝困難、成功地提交一個滿足客戶和用戶需要的產(chǎn)品的藝術。這一工作流側重于一個迭代開發(fā)過程的特定內(nèi)容，目標是： 為管理軟件密集型項目提供框架 為項目的規(guī)劃、人員管理、運行和監(jiān)督提供實用的指南 提供一個管理風險的框架這個工作流并不是成功的秘訣，它只是提供了一個能夠有效提高項目管理質(zhì)量的項目管理方法。（8）配置和變更管理在配置和變更管理這個工作流中，描述了如何控制由共同完成同一項目的許多人制造出來的大量產(chǎn)品。控制有助于避免混亂，保證各個產(chǎn)品不會因為以下問題產(chǎn)生沖突：·同時更新當一個或多個工人單獨地做同一個產(chǎn)品時，最后一個人可

46、能會破壞前面人的工作·有限的通知當多個人共享的幾個產(chǎn)品中的錯誤被更正時，可能有些人沒有得到有關修改的通知·多個版本大多數(shù)大程序都是以版本不斷進化的形式開發(fā)的。一個版本可能提供給用戶使用，另一個用來測試，而第三個用來繼續(xù)開發(fā)。如果其中任何一版中發(fā)現(xiàn)問題，就需要把修改的信息傳播給其它版本。在這個工作流中，將盡可能對重復工作、無效的改變進行控制和監(jiān)視，以避免由此產(chǎn)生的混亂。它主要提供一些管理多個軟件版本的指南、跟蹤在繼續(xù)開發(fā)版本、保證按照用戶定義的規(guī)格說明進行開發(fā)、強制采取節(jié)點專用開發(fā)政策。它對如何并行開發(fā)、在多節(jié)點上開發(fā)以及使建造過程自動化進行了描述。這些在迭代開發(fā)過程中尤其重

47、要。另外，該工作流還描述了如何進行審核跟蹤，把誰、什么時候、為什么對什么產(chǎn)品做的什么修改記錄下來。另外，它還包括變更需求管理，也就是如何報告和管理故障，以及如何使用故障數(shù)據(jù)來跟蹤進展和發(fā)展傾向。（9）環(huán)境環(huán)境工作流的目的是為軟件開發(fā)組織提供軟件開發(fā)環(huán)境提供開發(fā)團隊需要的過程和工具支持。該工作流的重點是在項目環(huán)境中，配置過程的活動。另外就是描述如何在一個機構內(nèi)實現(xiàn)過程。環(huán)境工作流還包含一個開發(fā)工具包，提供一些定制過程的指南、模板和工具。四在RUP指導下的UML建模如上所述，UML作為一種建模語言并沒有指定建模的步驟和方法，需要以一定的過程為指導進行。使用UML的過程應該是以架構為中心、用例驅動、支持迭代和遞增的開發(fā)過程。RUP具備了使用UML的過程的特征，因而在RUP的指導下可以進行有效的UML建模。1以體系結構為中心體系結構是系統(tǒng)的映射，它定義了系統(tǒng)的不同組成部分、它們之間的關系和交互、通信機制、以及如何修改系統(tǒng)組件、如