BlogJava-paulwong-随笔分类-RUPhttp://www.blogjava.net/paulwong/category/44411.htmlzh-cnWed, 04 Jul 2012 20:16:08 GMTWed, 04 Jul 2012 20:16:08 GMT60业务建模一般步骤和方法http://www.blogjava.net/paulwong/archive/2012/07/04/382215.htmlpaulwongpaulwongWed, 04 Jul 2012 10:16:00 GMThttp://www.blogjava.net/paulwong/archive/2012/07/04/382215.htmlhttp://www.blogjava.net/paulwong/comments/382215.htmlhttp://www.blogjava.net/paulwong/archive/2012/07/04/382215.html#Feedback0http://www.blogjava.net/paulwong/comments/commentRss/382215.htmlhttp://www.blogjava.net/paulwong/services/trackbacks/382215.html
本篇开始之前先扯点闲话，商业应用系统开发经历了三个阶段：

　　第一个阶段以计算为中心，分析设计围绕程序的运行效率，算法优劣，存贮优化来进行。90年代的大学课程讲的都是这些。

　　第二阶段以数据为中心，分析设计围绕数据流进行，以数据流程来模拟业务流程。这也就是所谓的面向过程的分析模式。

　　第三阶段以人为中心，分析设计围绕人的业务需求，使用要求，感受要求进行。这也就是现在的面象对象分析模式。

　　使用OO方法建立商业模型必须先定义涉众。商业系统无论多复杂，无论什么行业，其本质无非是人，事，物，规则。人是一切的中心，人做事，做事产生物，规则限制人事物。人驱动系统，事体现过程，物记录结果，规则则是控制。无论OO也好，UML也好，复杂的表面下其实只是一个简单的规则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人，事，物之间的关系定义出来，商业建模也就基本完成了。这时候可以说，系统分析员已经完全了解了用户需求，可以进入系统建模阶段了。

　　书归正传，上篇笔者归纳了一些典型的涉众类型及他们的普遍期望。接下来，就是要将他们这些期望定义出来。这个过程，就是业务用例获取的过程。笔者可以跟大家分享的经验是通过以下步骤进行，这些步骤并非唯一正确，对于经验不多的系统分析员来说，这些步骤很有指导意义。

　　笔者做了一个建模实例，有需要有读者请到笔者的BLOG资源中心下载，实例以上一篇所述网上图书馆需求为蓝本建立了业务用例模型，之后的概念模型、系统模型则抽取了其中的借阅过程作为例子。不记得了可以后头找找。

　　建模第一步，从涉众中找出用户。并定义这些用户之间的关系。在ROSE中，应该使用business actor 类型。参考上一篇的需求描述，下载实例

第二步，找出每个用户要做的事，即业务用例，在ROSE中应使用Business use case类型。请参考《用例的类型与粒度》一文以帮助确定用例的粒度。笔者强烈建议为每一个business actor绘制一个业务用例图，这能很好的体现以人为中心的分析模式，并且不容易漏掉business actor需要做的事。至于以参与者为中心的视图容易漏掉某个业务用例的参与者的担心，可以在第四步中得到消除。下载实例

　　第三步，利用业务场景图帮助分析业务流程，在ROSE中，这个阶段最好使用活动图Activity diagram。在这个阶段，业务场景图非常重要，在绘制过程中，系统分析员必须采用第一步中定义的用户名字作为泳道名，使用第二步中定义的业务用例名作为活动名来绘制。必须这么做的原因是，如果你无法把利用已经定义出来的 business actor 和 business use case完备的描绘业务流程，那么一定是前面的定义出问题了，你需要回头审视是否 business actor 和 business use case定义不完善或错误。如果不是所有的business actor 和 business use case 都被用到，要么应该检查业务流程调研时漏了什么，要么应该检查是否定义了一些无用的business actor 和 business use case 。同时，绘制业务场景图也非常有助于选择合适的用例粒度并保持所有的用例都是同一粒度。下载实例

　　第四步，绘制用例场景图。与业务场景图不同的是，用例场景图只针对一个用例绘制该用例的执行过程。笔者仍然强烈推荐使用activity diagram。在用例场景图的绘制中，必须使用第一步中定义的业务用户作为泳道。必须这么做的原因是，它能帮助你发现在定义业务用例图时的错误，比如是否漏掉了某个业务用例的潜在使用者。不是每个业务用例都需要绘制场景图，只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍然需要在业务用例规约文档中写明。下载实例

第五步，从第三步或第四步中绘制的活动图中找到每一步活动将使用到的或产生的结果。这是找到物的过程。找到后，应当建立这些物之间的关系。在ROSE中，这称为业务实体模型。应该使用business entity 类型。下载实例

　　第六步，在上述过程中，随时补充词汇表Glossary。将此过程中的所有业务词汇，专业词汇等一切在建模过程中使用到的需要解释的名词。这份文档将成为模型建立人与读者就模型达成一致理解的重要保证。

　　第七步，根据上一篇中提到的业主，老板等涉众的期望审视建立好的模型，确定业务范围，决定哪些业务用例在系统建设范围内。那些不打算纳入建设范围内的业务用例有两种情况，一种是该业务用例是被调用一方，那么应该把它改为 boundary 类型，意味着将来它是一个外部接口。另一种是该业务用例主动调用系统内业务用例，那么应该将它改为business actor类型。与普通business actor不同的是，由业务用例转换而成的business actor不是人，而通常是一个外部系统进程，因此应该在被调用的系统内业务用例与它之间增加一个boundary元素，意味着我们的系统将为这样一个外部进程提供一个接口。严格来说，那些需要纳入建设范围的business use case 应当对应的生成一个 business use case realization， 以后的设计工作将归纳到这些实现用例中。但笔者觉得这一步并非很关键的，实际中本人也经常省略这一步，而将协作图，象活动图，类交互图等直接在business usecase下说明。不过本实例中笔者还是按照正规方法来建模的。下载实例

　　需要说明的是，上述的步骤并非一次性完成的，在每一个步骤中都可能导致对以前步骤的调整。即使建模已经完成，当遇到变化或发现新问题时，上述步骤应当从头到尾再执行一次。这也是RUP倡导的迭代开发模式。

经过以上的步骤，我们已经建立了一个完整的业务模型。但这决不是建模工作的全部，以上过程只说明了建立一个完整业务模型的过程，不能说这样就建立了一个很好的业务模型。因为上述的过程中并没有提及业务分析过程。分析过程全凭系统分析员的经验，对OO的理解和对行业业务的把握能力，对原始业务模型进行归纳，整理，抽象，重构，以建立一个更高效，合理，扩展性更强的模型。这个过程无法以步骤说明。或许以后笔者会专门针对模型分析写点东西。另外除了模型，还至少需要写业务架构文档、用例规约和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构，但很不好表达业务规则和非业务需求，这些需要在文档中说明。例如用例的前置条件和后置条件就是一种业务规则。读者可以在RUP文档中找到这些文档的模板。

paulwong 2012-07-04 18:16 发表评论
]]>RUPhttp://www.blogjava.net/paulwong/archive/2010/03/26/316619.htmlpaulwongpaulwongFri, 26 Mar 2010 02:29:00 GMThttp://www.blogjava.net/paulwong/archive/2010/03/26/316619.htmlhttp://www.blogjava.net/paulwong/comments/316619.htmlhttp://www.blogjava.net/paulwong/archive/2010/03/26/316619.html#Feedback0http://www.blogjava.net/paulwong/comments/commentRss/316619.htmlhttp://www.blogjava.net/paulwong/services/trackbacks/316619.html 軟件過程是指實施於軟件開發和維護中的階段、方法、技術、實踐及相關產物(計劃、文檔、模型、代碼、測試用例和手冊等)的集合。行之有效的軟件過程可以提高開發軟件組織的生產效率、提高軟件質量、降低成本並減少風險。

RUP具有較高認知度的原因之一恐怕是因為其提出者Rational軟件公司聚集了物件導向領域三位傑出專家Booch、Rumbaugh和 Jacobson，同時它又是物件導向開發的行業標準語言——標準建模語言(UML)的創立者。RUP是由Objectory過程演化而來。本文主要討論 RUP的主要內容和特點。

二 RUP的二維開發模型

RUP可以用二維坐標來描述。橫軸通過時間組織，是過程展開的生命週期特徵，體現開發過程的動態結構，用來描述它的術語主要包括週期 (Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸以內容來組織為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括活動(Activity)、產物(Artifact)、工作者(Worker)和工作流(Workflow)。

三 開發過程中的各個階段和里程碑

RUP中的軟件生命週期在時間上被分解為四個順序的階段，分別是：初始階段(Inception)、細化階段(Elaboration)、構建階段(Construction)和交付階段(Transition)。每個階段結束於一個主要的里程碑(Major Milestones)；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。

初始階段(Inception Phase)

初始階段的目標是為系統建立商業案例並確定項目的邊界。為了達到該目的必須識別所有與系統交互的外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義，在這個階段中所關注的是整個項目進行中的業務和需求方面的主要風險。對於建立在原有系統基礎上的開發項目來講，初始階段可能很短。

初始階段結束時是第一個重要的里程碑：生命週期目標(Lifecycle Objective)里程碑。生命週期目標里程碑評價項目基本的生存能力。

細化階段(Elaboration Phase)

細化階段的目標是分析問題領域，建立健全的體系結構基礎，編製項目計劃，淘汰項目中最高風險的元素。為了達到該目的，必須在理解整個系統的基礎上，對體系結構作出決策，包括其範圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環境，包括創建開發案例，創建模板、準則並準備工具。

細化階段結束時第二個重要的里程碑：生命週期結構(Lifecycle Architecture)里程碑。生命週期結構里程碑為系統的結構建立了管理基準並使項目小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統目標和範圍、結構的選擇以及主要風險的解決方案。

構建階段(Construction Phase)

在構建階段，所有剩餘的構件和應用程序功能被開發並集成為產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個製造過程，其重點放在管理資源及控制運作以優化成本、進度和質量。

構建階段結束時是第三個重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑決定了產品是否可以在測試環境中進行部署。此刻，要確定軟件、環境、用戶是否可以開始系統的運作。此時的產品版本也常被稱為「beta」版。

交付階段(Transition Phase)

交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發佈做準備的產品測試，基於用戶反饋的少量的調整。在生命週期的這一點上，用戶反饋應主要集中在產品調整，設置、安裝和可用性問題，所有主要的結構問題應該已經在項目生命週期的早期階段解決了。

在交付階段的終點是第四個里程碑：產品發佈(Product Release)里程碑。此時，要確定目標是否實現，是否應該開始另一個開發週期。在一些情況下這個里程碑可能與下一個週期的初始階段的結束重合。

四 RUP的核心工作流(Core Workflows)

RUP中有9個核心工作流，分為6個核心過程工作流(Core Process Workflows)和3個核心支持工作流(Core Supporting Workflows)。儘管6個核心過程工作流可能使人想起傳統瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些工作流在整個生命週期中一次又一次被訪問。9個核心工作流在項目中輪流被使用，在每一次迭代中以不同的重點和強度重複。

商業建模(Business Modeling)

商業建模工作流描述了如何為新的目標組織開發一個構想，並基於這個構想在商業用例模型和商業對像模型中定義組織的過程，角色和責任。

需求(Requirements)

需求工作流的目標是描述系統應該做什麼，並使開發人員和用戶就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統所解決問題的定義和範圍。

分析和設計(Analysis & Design)

分析和設計工作流將需求轉化成未來系統的設計，為系統開發一個健壯的結構並調整設計使其與實現環境相匹配，優化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽像，由設計類和一些描述組成。設計類被組織成具有良好接口的設計包(Package)和設計子系統 (Subsystem)，而描述則體現了類的對象如何協同工作實現用例的功能。

設計活動以體系結構設計為中心，體系結構由若干結構視圖來表達，結構視圖是整個設計的抽像和簡化，該視圖中省略了一些細節，使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高被創建模型的質量。

實現(Implementation)

實現工作流的目的包括以層次化的子系統形式定義代碼的組織結構；以組件的形式(源文件、二進制文件、可執行文件)實現類和對像；將開發出的組件作為單元進行測試以及集成由單個開發者（或小組）所產生的結果，使其成為可執行的系統。

測試(Test)

測試工作流要驗證對像間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現, 識別並確認缺陷在軟件部署之前被提出並處理。RUP提出了迭代的方法，意味著在整個項目中進行測試，從而儘可能早地發現缺陷，從根本上降低了修改缺陷的成本。測試類似於三維模型，分別從可靠性、功能性和系統性能來進行。

部署(Deployment)

部署工作流的目的是成功的生成版本並將軟件分發給最終用戶。部署工作流描述了那些與確保軟件產品對最終用戶具有可用性相關的活動，包括：軟件打包、生成軟件本身以外的產品、安裝軟件、為用戶提供幫助。在有些情況下，還可能包括計劃和進行beta測試版、移植現有的軟件和數據以及正式驗收。

配置和變更管理(Configuration & Change Management)

配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流提供了準則來管理演化系統中的多個變體，跟蹤軟件創建過程中的版本。工作流描述了如何管理並行開發、分佈式開發、如何自動化創建工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。

項目管理(Project Management)

軟件項目管理平衡各種可能產生衝突的目標，管理風險，克服各種約束併成功交付使用戶滿意的產品。其目標包括：為項目的管理提供框架，為計劃、人員配備、執行和監控項目提供實用的準則，為管理風險提供框架等。

環境(Environment)

環境工作流的目的是向軟件開發組織提供軟件開發環境，包括過程和工具。環境工作流集中於配置項目過程中所需要的活動，同樣也支持開發項目規範的活動，提供了逐步的指導手冊並介紹了如何在組織中實現過程。

五 RUP的迭代開發模式

RUP中的每個階段可以進一步分解為迭代。一個迭代是一個完整的開發循環，產生一個可執行的產品版本，是最終產品的一個子集，它增量式地發展，從一個迭代過程到另一個迭代過程到成為最終的系統。

傳統上的項目組織是順序通過每個工作流，每個工作流只有一次，也就是我們熟悉的瀑布生命週期。這樣做的結果是到實現末期產品完成並開始測試，在分析、設計和實現階段所遺留的隱藏問題會大量出現，項目可能要停止並開始一個漫長的錯誤修正週期。

一種更靈活，風險更小的方法是多次通過不同的開發工作流，這樣可以更好的理解需求，構造一個健壯的體系結構，並最終交付一系列逐步完成的版本。這叫做一個迭代生命週期。在工作流中的每一次順序的通過稱為一次迭代。軟件生命週期是迭代的連續，通過它，軟件是增量的開發。一次迭代包括了生成一個可執行版本的開發活動，還有使用這個版本所必需的其他輔助成分，如版本描述、用戶文檔等。因此一個開發迭代在某種意義上是在所有工作流中的一次完整的經過，這些工作流至少包括：需求工作流、分析和設計工作流、實現工作流、測試工作流。其本身就像一個小型的瀑布項目。

與傳統的瀑布模型相比較，迭代過程具有以下優點：

降低了在一個增量上的開支風險。如果開發人員重複某個迭代，那麼損失只是這一個開發有誤的迭代的花費。

降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以儘早來解決而不至於在開發後期匆匆忙忙。

加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。

由於用戶的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。

六 總結

RUP具有很多長處：提高了團隊生產力，在迭代的開發過程、需求管理、基於組件的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面，針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模板和工具指導，並確保全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構，為開發過程提供較大的通用性。但同時它也存在一些不足： RUP只是一個開發過程，並沒有涵蓋軟件過程的全部內容，例如它缺少關於軟件運行和支持等方面的內容；此外，它沒有支持多項目的開發結構，這在一定程度上降低了在開發組織內大範圍實現重用的可能性。可以說RUP是一個非常好的開端，但並不完美。

paulwong 2010-03-26 10:29 发表评论
]]>RUP overviewhttp://www.blogjava.net/paulwong/archive/2010/03/25/316565.htmlpaulwongpaulwongThu, 25 Mar 2010 10:17:00 GMThttp://www.blogjava.net/paulwong/archive/2010/03/25/316565.htmlhttp://www.blogjava.net/paulwong/comments/316565.htmlhttp://www.blogjava.net/paulwong/archive/2010/03/25/316565.html#Feedback0http://www.blogjava.net/paulwong/comments/commentRss/316565.htmlhttp://www.blogjava.net/paulwong/services/trackbacks/316565.html
隨著現代信息產業的蓬勃發展，軟件開發已經成為一項浩大繁複的工程。 就像是建造一座宏偉的宮殿， 從計劃、設計到施工， 每一個環節都必須嚴格把關， 稍有不慎， 整個工程就會失敗。 據統計， 僅在美國， 每年就有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的知識和經驗也是現在求職市場所需求的熱門技能。

paulwong 2010-03-25 18:17 发表评论
]]>