RUP 軟體開發方法論

随着現代資訊産業的蓬勃發展，軟體開發已經成為一項浩大繁複的工程。就象是建造一座宏偉的宮殿，從計劃、設計到施工，每一個環節都必須嚴格把關，稍 有不慎，整個工程就會失敗。據統計，僅在美國，每年就有180,000個資訊技術項目，耗資大約$2500億美元，其中25-30%的項目會流産。由此可 見，由于管理不善和設計上的失誤所造成的損失是巨大的。現代軟體開發的管理和方法論顯得比以往任何時候都更為重要。

軟體開發的 過程由方法論和工具構成（process = methodology + tools）。正如裝配電子裝置一樣，僅有工具就可以勝任裝配任務。但為了減少失誤和提高效率，人們往往采用流水線作業，流水線作業便是一種應用于電子設 備裝配中的方法論。目前，資訊技術市場流行的方法論有RUP（Rational Unified Process）, The Zachman Framework, XP(Extreme Programming)等。在這些方法論中，最流行的要數RUP。RUP是由Rational Software公司首創的。因它與目前流行的JAVA, J2EE技術和面向對象的設計思想（OOAD）緊密的結合在一起，是以在大型的資訊技術項目中得到了廣泛的應用。在這篇文章中，我們試圖對RUP的特點作 一個初步的探讨，并且讨論它是如何貫穿在整個軟體開發的生命周期之中的。

RUP最重要的它有三大特點：1）軟體開發是一個疊代過程，2）軟體開發是由Use Case驅動的，3）軟體開發是以構架設計（Architectural Design）為中心的。

按 照傳統的瀑布（Waterfall）開發模式，軟體開發大緻經曆如下幾個步驟：商務需求分析（Business Requirement Analysis），系統分析（System Analysis），系統設計（System Design），開發實作（Implementation），測試（Test），釋出（Deployment），系統支援（Supporting）和系統 變更管理（Change Management）。

傳統的瀑布開發模式假定在進行新的開發過程時，上一個過程已經完成，而且不 會回到上一個過程。初看起來，這似乎是一個非常合理，高效率的解決方案，但20多年的實踐證明，這個開發模式存在着很大的弊病，原因是軟體開發是一個非常 複雜的工程，有諸多的因素影響工程的效率和成敗。軟體開發需要許多不同背景的個人和團隊參與。由于這些複雜性，在軟體開發的整個生命周期中每一個階段都有 可能留下隐患和錯誤。如果等到系統已經開發實作完畢，在測試階段發現了重大問題，這時的返工将會造成人力、物力、财力及時間上的巨大浪費。

鑒 于以上的考慮，RUP強調軟體開發是一個疊代模型（Iterative Model），RUP定義了四個階段（Phase）：開端（Inception），闡述（Elaboration），建造（Construction）， 過渡（Transition）。其中每個階段都有可能經曆以上所提到的從商務需求分析開始的各個步驟，隻是每個步驟的高峰期會發生在相應的階段。例如開發 實作的高峰期是發生在建造階段。實際上這樣的一個開發方法論是一個二維模型。這種疊代模型的實作在很大程度上提供了及早發現隐患和錯誤的機會，是以被現代 大型資訊技術項目所采用。

RUP 的另一大特征是Use Case 驅動。Use Case是RUP方法論中一個非常重要的概念。簡單地說，一個Use Case就是系統的一個功能。例如在一個基于電子商務的醫療系統中，病人可以坐在家裡通過網上浏覽器與醫生約定看病的時間（Make appointment），這樣，“Make appointment”就是系統的一個Use Case。在系統分析和系統設計中，Use Case被用來将一個複雜的龐大系統分割、定義成一個個小的單元，這個小的單元就是Use Case,然後以每個小的單元為對象進行開發。按照RUP, Use Case貫穿整個軟體開發的生命周期。在商務需求分析中，客戶或使用者對Use Case進行描述，在系統分布和系統設計過程中，設計師對Use Case進行分析，在開發實作過程中，開發程式設計人員對Use Case進行實作，在測試過程中，測試人員對Use Case進行檢驗。

RUP 的第三大特征是它強調軟體開發是以構架為中心的。構架設計（Architectural Design）是系統設計的一個重要組成部分。在構架設計過程中，設計師(Architect)必須完成對技術和運作平台的選取，整個項目的基礎架構 （Framework）的設計，完成對公共元件的設計，如審計（Auditing）系統，日志（Log）系統，錯誤處理（Exception Handling）系統，安全（Security）系統等。設計師必須對系統的可擴充性（Extensibility），安全性（Security），可 維護性（Maintainability），可延拓性（Scalability），可重用性（Reusability）和運作速度 （Performance）提出可行的解決方案。

在RUP方法論中，不同的角色可以從不同的側面來認識同一個項目。 RUP定義了“4+1”個場景(View）：Use Case場景(Use Case View)，邏輯場景(Logic View)，程序場景(process View)，實作場景(Implementation View)和釋出場景(Deployment View)。在Use Case場景中，客戶和商務分析員對Use Case進行描述，在邏輯場景中，設計師對系統進行分析和設計，在程序場景中，設計師對系統可能出現的并發性，運作速度和分布特性進行描述。實作場景則反 映了程式開發員開發實作的過程。釋出場景是描述系統管理者群組裝人員實施系統釋出和管理的過程。值得強調的是，系統構架的設計是在邏輯場景中描述的。

RUP 還定義了4個模型，即Use Case模型（Use Case Model），分析模型(Analysis Model)，設計模型(Design Model)和實作模型(Implementation Model)。Use Case模型包含Use Case Diagram和Use Case文檔。Use Case模型是其他三個模型的基礎，分析模型即是概念模型(Conceptual Model)，是系統分析所得到的結果，分析模型包含了類圖(Class Diagram)，次序圖(Sequence Diagram)以及活動圖(Activity Diagram)。設計模型則是構架設計和系統設計的結果。當設計模型完成後，開發程式設計人員便可以進行程式設計了。設計模型主要包含了類圖，次序圖和狀态圖 (State Chart Diagrams)。分析模型和設計模型看起來有許多相似之處，但兩者的含義有本質的差別。分析模型強調的是問題的範圍，但并不給出解決問題的方案，分析 模型并不涉及具體的技術和平台。

例如它并不關心是否應用EJB或一般的JAVA BEANS，系統是安裝在WebSphere或是在WebLogic。但是與之相反，設計模型要考慮這些細節，而且要提供解決這些問題的全部方案。當然設 計模型是建立在分析模型之上的，分析模型中的一個類可直接映射成為設計模型中的類，但這種映射關系一般并不是一一對應的，最後一個模型是實作模型。實作模 型包含構件圖（Component Diagram），從這個模型出發，開發程式設計人員可以産生骨架源程式(Skeleton Source Code)，也可以從源程式出發更新設計模型。

　

目前應用于系統分析和設計的工具主要有Rational Rose和Together Software Center(TogetherJ)。JAVA和J2EE的開發工具有IBM Websphere Application Developer(WSAD), Borland Jbuilde和WebGain VisualCafe. WSAD和WebSphere Application Server應用在一起，使得伺服器端的排錯和系統的釋出變得非常的容易。Jbuilder和VisualCafe一般與WebLogic Server緊密結合在一起。目前WebSphere Server和WebLogic Server占據了Application Server市場的66%，其中WebSphere Server占據了37%，成為同類産品的No.1。在機關測試和內建測試中，廣泛應用的工具和架構有Junit, JunitPerf和Cactus.。

綜上所述，軟體開發的方法論已經成為現代軟體工程過程中不可缺少的一個重要部分。 是目前在Java/J2EE和面向對象的大型項目中廣泛被采用的一種方法論。他對整個軟體開發的生命周期提供了基礎架構和指導。RUP, UML/Rational Rose, JAVA/J2EE, WSAD, Websphere Application Server和Oracle這樣的技術、工具和平台的組合是目前許多公司、政府資訊技術項目中采用的方案。是以，RUP的知識和經驗也是現在求知是場所需 求的熱門技能。