paulwong

RUP overview

作者:李訓軍博士

隨著現代信息產業的蓬勃發展,軟件開發已經成為一項浩大繁複的工程。 就像是建造一座宏偉的宮殿, 從計劃、設計到施工, 每一個環節都必須嚴格把關, 稍有不慎, 整個工程就會失敗。 據統計, 僅在美國, 每年就有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的知識和經驗也是現在求職市場所需求的熱門技能。

posted on 2010-03-25 18:17 paulwong 阅读(304) 评论(0)  编辑  收藏 所属分类: RUP


只有注册用户登录后才能发表评论。


网站导航: