Rational Unified Process（以下簡稱RUP） 是一套軟體工程方法，主要由 Ivar Jacobson的 The Objectory Approch 和 The Rational Approch發展而來。同時，它又是文件化的軟體工程產品，所有RUP的實施細節及方法導引均以Web文件的方式整合在一張光碟上，由Rational公司開發、維護並銷售，當前版本是5.0。RUP又是一套軟體工程方法的框架，各個組織可根據自身的實際情況，以及專案規模對RUP進行裁剪和修改，以制定出合乎需要的軟體工程過程。

RUP 吸收了多種開發模型的優點，具有很好的可操作性和實用性。從它一推出市場，憑藉Booch、Ivar Jacobson、以及Rumbagh 在業界的領導地位以及與統一建模語言（Unified Model Language , 以下簡稱UML）的良好整合、多種CASE工具的支援、不斷的升級與維護，迅速得到業界廣泛的認同，越來越多的組織以它作為軟體開發模型框架。

二維的軟體開發模型

傳統的軟體開發模型瀑布式開發模型是一個單維的模型，開發工作劃分為多個連續的階段。在一個時間段內，只能作某一個階段的工作比如，分析、設計或者實現。

在RUP中，軟體開發生生命週期根據時間和RUP的核心工作流劃分為二維空間。

如下圖所示，時間維從組織管理的角度描述整個軟體開發生命週期，是RUP的動態組成部分。它可進一步描述為週期（Cycle）、階段（phase）、Iteration(迭代)。核心工作流從技術角度描述RUP的靜態組成部分，它可進一步描述為行為（activities）、工作流（workflow）、產品（artifact）、角色（worker）。



從圖中的陰影部分表示的工作流可以看出，不同的工作流在不同的時間段內工作量的不同。值得注意的是，幾乎所有的工作流，在所有的時間段內均有工作量，只是工作程度不同而已。這與Waterfall process(瀑布式開發模型)有明顯的不同。

靜態結構：方法描述

軟體開發過程描述了什麼時候，什麼人，做什麼事，以及怎樣實現某一特定的目標。RUP採用以下四個基本模型元素組織和構造系統開發過程。

角色 : the who

行為 : the how

產品 : the what

工作流 : the when



角色描述某個人或一個小組的行為與職責。一個開發人員可以同時是幾個角色，一個角色也可以由多個開發人員共同承擔。RUP預先定義了很多角色，例如：Architect、Use-Case Designer、Course Developer、Implementer …，並對每一個角色的工作和職責都作了詳盡的說明。

行為是一個有明確目的的獨立工作單元。產品是行為生成、建立或修改的一段資訊。它是行為的輸入同時又是它的輸出結果。產品以多種形式存在，例如：模型（Model）、原始碼、可執行檔案、文件等。

模型是從某一個角度對系統的完全描述。RUP的很大一部分工作就是設計和維護一系列的模型，這其中有Use Case Model、Business Model、 Analysis Model、Design Model等。所有的這些模型都以UML描述，因此它們是標準的併為多種CASE工具支援。RUP並不鼓勵寫在字面上的文擋，產品應儘可能地在CASE工具中建立和修改併為版本管理工具跟蹤和維護，它們在整個軟體開發週期中動態地增加和修改。當然也可以根據需要為模型生成報告（Reports），但它們是靜態的，是某一時刻模型的快照不需要維護和修改。

工作流描述了一個有意義的連續的行為序列，每個工作流產生一些有價值的產品，並顯示了角色之間的關係。RUP主要提供兩種組織工作流的方式：核心工作流（Core Workflow）和迭代工作流（Iteration Workflow）。

核心工作流從邏輯上把相關角色和行為劃分為組，以描述RUP的邏輯組成部件。它們相當於模板一樣，並不在開發過程中真正的執行。迭代工作流是RUP的一個具體的實現過程，它們對核心工作流進行裁剪，是核心工作流的具體實現。每類工作流都會同一個或多個模型打交道。

RUP有九個核心的工作流。以下簡單描述這些工作流的目的：

商業建模（Business Modeling）：理解待開發系統的組織結構及其商業運作，確保所有參與人員對待開發系統有共同的認識。

需求分析（Requirements）：定義系統功能及使用者介面，使客戶知道系統的功能，開發人員知道系統的需求，為專案預算及計劃提供基礎。

分析與設計（Analysis and Design）：把需求分析的結果轉化為實現規格。

實現（Implementation）：定義程式碼的組織結構、實現程式碼、單元測試、系統整合。

測試（Test）：校驗各自子系統的互動與整合。確保所有的需求被正確實現並在系統釋出前發現錯誤。

釋出（Deployment）：打包、分發、安裝軟體，升級舊系統；培訓使用者及銷售人員，並提供技術支援。制定並實施beta測試。 配置管理（Configuration and Change Management）：跟蹤並維護系統所有產品s的完整性和一致性。

專案管理（Project Management）：為計劃、執行和監控軟體開發專案提供可行性的指導；為風險管理提供框架。

環境（Environment）：為組織提供過程管理和工具的支援。

由於版面所限，無法詳細解釋每一個工作流。前六個核心工作流的名字，很可能使人們同Waterfall Process的順序工作階段相混淆。但我們知道核心工作流並不是具體的實現，而核心工作流中的某些行為有可能在軟體開發週期中，一遍又一遍地在迭代工作流中得以細化。

下圖是需求分析工作流的具體例子，RUP為每一個行為的實現步驟都作了詳盡的說明。



動態結構：迭代式開發

在時間維上，為了能夠方便地管理軟體開發過程，監控軟體開發狀態，RUP把軟體開發週期劃分為Cycles,每個Cycle生成一個產品的新的版本。每個Cycle都依次由四個連續的階段(pahse)組成，每個階段都應完成確定的任務。

起始階段（Inception）：定義最終產品檢視、商業模型並確定系統範圍。

演化階段（evaluation）：設計及確定系統的體系結構，制定工作計劃及資源要求。

構造階段（construction）：構造產品並繼續演進需求、體系結構、計劃直至產品提交。

提交階段(Transition)：把產品提交給使用者使用。

如下圖所示，在每個階段結束前都應有一個里程碑（MileStone）評估該階段的工作。如果未能通過該里程碑的評估，則決策者應該做出決定是應取消該專案，還是繼續做該階段的工作。



每一個階段都由一個或多個連續的迭代組成，每一個迭代都是一個完整的開發過程是一個具體的迭代工作流從頭到尾的執行。與核心工作流不同的是RUP並沒有也無法給出迭代工作流的具體實現步驟，它需要專案經理根據當前迭代所處的階段、以及上次迭代的結果，適當地對核心工作流中的行為進行剪裁以實現一個具體的迭代工作流。

RUP的迭代開發過程是受控的，在專案計劃中就制定了專案迭代的個數、每個迭代的延續時間以及目標。在每一個迭代的起始階段都制定詳細的迭代計劃以及具體的迭代工作流。每次迭代過程都生成該次迭代的Release. 作為下次迭代的基礎。在迭代結束前，都應執行測試工作，並仔細評估該迭代過程，為下一次迭代做準備。迭代並不是重複地做相同的事，而是針對不同Use Case的細化和實現。

使用例項（Use Case）驅動

傳統的面向物件開發方法因為缺乏貫穿整個開發過程的線索，因此很難闡述清楚一個軟體系統是如何實現其功能的。在RUP中，Use Case Model就是這樣一個線索它是整個軟體開發過程的基礎。

Use Cases Model是需求分析工作流的結果,它從使用者的角度描述該系統應該實現的功能。利用Use Case Model 可以有效地界定系統範圍及其行為, 併為使用者及開發人員認同。Use Case Model 主要由Use Cases 和演員（Actors）構成。Use Case是系統執行的一系列行為，併為Actor生成一些有意義的結果。Actor是所有與本系統有互動的外部系統，可以是人、其他軟體系統等。下圖是一個Use Case Mode的例子：



Use Case作為分析與設計工作流的輸入，是實現分析與設計模型的基礎。設計模型作為實現工作流的規格說明書，它自然要實現Use Case 模型所定義的功能。同樣在測試工作流中，Use Case Model 組成測試例項，用來有效地校驗整個系統的正確性。另外，Use Case還是使用者手冊的基礎、並驅動整個迭代開發過程的運作，所以我們說Rational Unified Process是由Use Case 驅動的。

以體系結構為中心

多年以來，軟體設計人員一直強烈地感覺軟體體系結構是一個非常重要的概念。因為它使得開發人員及使用者能夠更好地理解系統的邏輯結構、物理結構、系統功能及其工作機理，也使系統能夠更加容易修改及擴充。但是由於對體系結構的目的及其定義一直模糊不清，且表示方法的混亂一直影響著它的應用。

由於在專案的開發過程中不同的開發人員所關心的角度是不一樣的，因此軟體的體系結構應該是一個多維的結構，RUP採用如下圖所示的4+1View（檢視）模型，利用UML語言來描述軟體的體系結構。這5個檢視都是從相應的模型中抽取出對系統的結構、功能、健壯性及其可擴充性有重要意義的元素構成。是各模型的精華與核心部分。



Use Case是驅動軟體的開發週期的原動力，但是分析與設計工作流是以軟體體系結構(Architecture)為核心的。RUP的早期的迭代工作，特別是演化階段的重點就是確定和校驗軟體的體系結構。演化階段的MileStone的一個關鍵任務就是確定該系統的體系結構是否健壯、成熟以及穩定。

RUP的優點

迭代式開發方法是一個不斷的減除風險的過程,每一次的迭代過程都選擇最關鍵的也是風險最大的Use Cases執行。因此風險在迭代過程中不斷地被發現、消滅。

迭代式開發方法能夠更容易地管理需求的變化，整個開發過程由一次次的獨立的迭代所組成，專案經理能夠比較容易地調整迭代過程，使最終產品實現變化的需求。大部分的產品都存在CASE工具中，併為配置工作流所管理，使得所有開發人都能夠及時地知道這種變化，制定相應的對策。

開發人員以及專案相關人員能夠及時地從迭代過程中得到反饋資訊，並能夠及時修改以前工作中的失誤，有效地監控開發過程，並對迭代工作流進行校正，這對一個時間跨度很長的專案具有重要的意義。

以Use Case驅動、體系結構為中心使得開發人員比較容易地控制整個系統的開發過程，管理它的複雜性、維護它的完整性。

體系結構中定義清晰、功能明確的元件為基於元件式的開發、大規模的軟體複用的提供有力的支援，並是專案管理中計劃與人員安排的依據。

Rational公司提供了豐富的CASE工具支援RUP。比如：視覺化建模工具Rational Rose;需求管理工具Requisite Pro; 版本管理工具Clear Case ; 文件生成 SoDa; 測試工具：SQA, Perfomence等。由於RUP採用標準的UML描述系統的模型基體系結構，因此可以利用很多第三方廠家提供的產品。

RUP能夠達到軟體工程研究所制定的CMM（Capability Maturity Model）模型的2級或3級。

總結

Rational Unified Process 是新一代的軟體工程方法。與早期的瀑布式開發模型相比，它具有迭代式的增量開發、使用例項驅動、 以軟體體系結構為核心三個鮮明特點，這使得RUP非常適宜於開發複雜、技術難度大、需求多變、高風險的專案。RUP又是可裁剪的軟體開發過程框架，各組織可以根據自身及專案特點對RUP進行裁減，在某些情況下RUP甚至可以蛻化為瀑布式開發模型。

參考文獻

Rational 公司. Rational Unified Process. 版本（5.0）.

Philippe Kruchten . The Rational Unified Process An Introduction.

作者簡介

孫劍暉，1971年4月生，男，籍貫浙江，工程師，工學碩士。1993年7月本科畢業於北方交通大學計算機系，1996年7月研究生畢業於暨南大學計算機系。1996年7月至今在廣東省郵科院多媒體部工作。主要研究方向：軟體工程、系統分析與設計、Internet業務管理計費系統、資料倉庫決策支援系統。

2004年10月19日10:56:48 http://www-900.ibm.com/developerworks/cn/rational/r-rup-implementer/