關鍵詞 RUP UML 工作流 產品 行爲 角色 迭代 階段
1.Rational Unified Process 簡介
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工具的支持、不斷的升級與維護，迅速得到業界廣泛的認同，越來越多的組織以它作爲軟件開發模型框架。
2.二維的軟件開發模型
傳統的軟件開發模型瀑布式開發模型是一個單維的模型，開發工作劃分爲多個連續的階段。在一個時間段內，只能作某一個階段的工作比如，分析、設計或者實現。
在RUP中，軟件開發生生命週期根據時間和RUP的核心工作流劃分爲二維空間。
如下圖所示，時間維從組織管理的角度描述整個軟件開發生命週期，是RUP的動態組成部分。它可進一步描述爲週期（Cycle）、階段（phase）、Iteration(迭代)。核心工作流從技術角度描述RUP的靜態組成部分，它可進一步描述爲行爲（activities）、工作流（workflow）、產品（artifact）、角色（worker）。我們將分別在第三、第四節闡述這些概念。
從圖中的陰影部分表示的工作流可以看出，不同的工作流在不同的時間段內工作量的不同。值得注意的是，幾乎所有的工作流，在所有的時間段內均有工作量，只是工作程度不同而已。這與Waterfall process(瀑布式開發模型有明顯的不同。
3.靜態結構：方法描述
軟件開發過程描述了什麼時候，什麼人，做什麼事，以及怎樣實現某一特定的目標。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爲每一個行爲的實現步驟都作了詳盡的說明。
4.動態結構：迭代式開發
在時間維上，爲了能夠方便地管理軟件開發過程，監控軟件開發狀態，RUP把軟件開發週期劃分爲Cycles,每個Cycle生成一個產品的新的版本。每個Cycle都依次由四個連續的階段(pahse)組成，每個階段都應完成確定的任務。
起始階段（Inception）：定義最終產品視圖、商業模型並確定系統範圍。
演化階段（evaluation）：設計及確定系統的體系結構，制定工作計劃及資源要求。
構造階段（construction）：構造產品並繼續演進需求、體系結構、計劃直至產品提交。
提交階段(Transition)：把產品提交給用戶使用。
如下圖所示，在每個階段結束前都應有一個里程碑（MileStone）評估該階段的工作。如果未能通過該里程碑的評估，則決策者應該做出決定是應取消該項目，還是繼續做該階段的工作。
每一個階段都由一個或多個連續的迭代組成，每一個迭代都是一個完整的開發過程是一個具體的迭代工作流從頭到尾的執行。與核心工作流不同的是RUP並沒有也無法給出迭代工作流的具體實現步驟，它需要項目經理根據當前迭代所處的階段、以及上次迭代的結果，適當地對核心工作流中的行爲進行剪裁以實現一個具體的迭代工作流。
RUP的迭代開發過程是受控的，在項目計劃中就制定了項目迭代的個數、每個迭代的延續時間以及目標。在每一個迭代的起始階段都制定詳細的迭代計劃以及具體的迭代工作流。每次迭代過程都生成該次迭代的Release. 作爲下次迭代的基礎。在迭代結束前，都應執行測試工作，並仔細評估該迭代過程，爲下一次迭代做準備。迭代並不是重複地做相同的事，而是針對不同Use Case的細化和實現。
5.使用實例（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 驅動的。
6.以體系結構爲中心
多年以來，軟件設計人員一直強烈地感覺軟件體系結構是一個非常重要的概念。因爲它使得開發人員及用戶能夠更好地理解系統的邏輯結構、物理結構、系統功能及其工作機理，也使系統能夠更加容易修改及擴充。但是由於對體系結構的目的及其定義一直模糊不清，且表示方法的混亂一直影響着它的應用。
由於在項目的開發過程中不同的開發人員所關心的角度是不一樣的，因此軟件的體系結構應該是一個多維的結構，RUP採用如下圖所示的4+1View（視圖）模型，利用UML語言來描述軟件的體系結構。這5個視圖都是從相應的模型中抽取出對系統的結構、功能、健壯性及其可擴充性有重要意義的元素構成。是各模型的精華與核心部分。
Use Case 是驅動軟件的開發週期的原動力，但是分析與設計工作流是以軟件體系結構(Architecture)爲核心的。RUP的早期的迭代工作，特別是演化階段的重點就是確定和校驗軟件的體系結構。演化階段的MileStone的一個關鍵任務就是確定該系統的體系結構是否健壯、成熟以及穩定。
7.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級。
8.總結
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月至今在廣東省郵科院多媒體部工作。主要研究方向：軟件工程、系統分析與設計。
順便推薦一個非常好的RUP學習站點：http://www.woodpecker.org.cn:9081/doc/RationalUnifiedProcess.zh_cn/process/ovu_proc.htm