本篇开始之前先扯点闲话Q商业应用系l开发经历了三个阶段Q?br />
W一个阶D以计算Z心，分析设计围绕E序的运行效率，法优劣Q存贮优化来q行?0q代的大学课E讲的都是这些?br />
W二阶段以数据ؓ中心Q分析设计围l数据流q行Q以数据程来模拟业务流E。这也就是所谓的面向q程的分析模式?br />
W三阶段以hZ心，分析设计围绕人的业务需求，使用要求Q感受要求进行。这也就是现在的面象对象分析模式?br />
使用OOҎ建立商业模型必须先定义涉众。商业系l无论多复杂Q无Z么行业，其本质无非是人，事，物，规则。h是一切的中心Qh做事Q做事生物Q规则限制h事物。h驱动pȝQ事体现q程Q物记录l果Q规则则是控制。无论OO也好QUML也好Q复杂的表面下其实只是一个简单的规则Q系l分析员弄明白有什么hQ什么h做什么事Q什么事产生什么物Q中间有什么规则，再把人，事，物之间的关系定义出来Q商业徏模也基本完成了。这时候可以说Q系l分析员已经完全了解了用户需求，可以q入pȝ建模阶段了?br />
书归正传Q上笔者归U了一些典型的涉众cd及他们的普遍期望。接下来Q就是要他们这些期望定义出来。这个过E，是业务用例获取的过E。笔者可以跟大家分n的经验是通过以下步骤q行Q这些步骤ƈ非唯一正确Q对于经验不多的pȝ分析员来_q些步骤很有指导意义?br />
W者做了一个徏模实例，有需要有读者请到笔者的BLOG资源中心下蝲Q实例以上一所q网上图书馆需求ؓ蓝本建立了业务用例模型，之后的概忉|型、系l模型则抽取了其中的借阅q程作ؓ例子。不记得了可以后头找找?br />
建模W一步，从涉众中扑և用户。ƈ定义q些用户之间的关pR在ROSE中，应该使用business actor cd。参考上一的需求描qͼ下蝲实例
W二步，扑և每个用户要做的事Q即业务用例Q在ROSE中应使用Business use casecd。请参考《用例的cd与粒度》一文以帮助定用例的粒度。笔者强烈徏议ؓ每一个business actorl制一个业务用例图Q这能很好的体现以hZ心的分析模式Qƈ且不Ҏ漏掉business actor需要做的事。至于以参与者ؓ中心的视囑֮易漏掉某个业务用例的参与者的担心Q可以在W四步中得到消除。下载实?br />
W三步，利用业务场景囑ָ助分析业务流E，在ROSE中，q个阶段最好用活动图Activity diagram。在q个阶段Q业务场景图非常重要Q在l制q程中，pȝ分析员必采用第一步中定义的用户名字作为泳道名Q用第二步中定义的业务用例名作为活动名来绘制。必这么做的原因是Q如果你无法把利用已l定义出来的 business actor ?business use case完备的描l业务流E，那么一定是前面的定义出问题了，你需要回头审视是?business actor ?business use case定义不完善或错误。如果不是所有的business actor ?business use case 都被用到Q要么应该检查业务流E调研时漏了什么，要么应该查是否定义了一些无用的business actor ?business use case 。同Ӟl制业务场景图也非常有助于选择合适的用例_度q保持所有的用例都是同一_度。下载实?br />
W四步，l制用例场景图。与业务场景图不同的是，用例场景囑֏针对一个用例绘制该用例的执行过E。笔者仍然强烈推荐用activity diagram。在用例场景囄l制中，必须使用W一步中定义的业务用户作为泳道。必这么做的原因是Q它能帮助你发现在定义业务用例图时的错误Q比如是否漏掉了某个业务用例的潜在用者。不是每个业务用例都需要绘制场景图Q只有两三个步骤的业务用例是不必一定绘制业务用例图的，但仍焉要在业务用例规约文档中写明。下载实?br />
W五步，从第三步或第四步中绘制的zd图中扑ֈ每一步活动将使用到的或生的l果。这是找到物的过E。找到后Q应当徏立这些物之间的关pR在ROSE中，q称Z务实体模型。应该用business entity cd。下载实?br />
W六步，在上q过E中Q随时补充词汇表Glossary。将此过E中的所有业务词汇，专业词汇{一切在建模q程中用到的需要解释的名词。这份文档将成ؓ模型建立Z读者就模型达成一致理解的重要保证?br />
W七步，Ҏ上一中提到的业主，老板{涉众的期望审视建立好的模型Q确定业务范_军_哪些业务用例在系l徏设范围内。那些不打算U_范围内的业务用例有两U情况，一U是该业务用例是被调用一方，那么应该把它改ؓ boundary cdQ意味着来它是一个外部接口。另一U是该业务用例主动调用系l内业务用例Q那么应该将它改为business actorcd。与普通business actor不同的是Q由业务用例转换而成的business actor不是人，而通常是一个外部系l进E，因此应该在被调用的系l内业务用例与它之间增加一个boundary元素Q意味着我们的系l将样一个外部进E提供一个接口。严格来_那些需要纳入徏设范围的business use case 应当对应的生成一?business use case realizationQ?以后的设计工作将归纳到这些实现用例中。但W者觉得这一步ƈ非很关键的，实际中本Zl常省略q一步，而将协作图，象活动图Q类交互囄直接在business usecase下说明。不q本实例中笔者还是按照正规方法来建模的。下载实?br />
需要说明的是，上述的步骤ƈ非一ơ性完成的Q在每一个步骤中都可能导致对以前步骤的调整。即使徏模已l完成，当遇到变化或发现新问题时Q上q步骤应当从头到ֆ执行一ơ。这也是RUP倡导的P代开发模式?br />
l过以上的步骤，我们已经建立了一个完整的业务模型。但q决不是建模工作的全部，以上q程只说明了建立一个完整业务模型的q程Q不能说q样徏立了一个很好的业务模型。因Zq的q程中ƈ没有提及业务分析q程。分析过E全凭系l分析员的经验，对OO的理解和对行业业务的把握能力Q对原始业务模型q行归纳Q整理，抽象Q重构，以徏立一个更高效Q合理，扩展性更强的模型。这个过E无法以步骤说明。或总后笔者会专门针对模型分析写点东西。另外除了模型，q至需要写业务架构文档、用例规U和补充用例规约三种文档。因为模型虽然可以较好的体现业务架构Q但很不好表达业务规则和非业务需求，q些需要在文档中说明。例如用例的前置条g和后|条件就是一U业务规则。读者可以在RUP文档中找到这些文档的模板?img src ="http://www.aygfsteel.com/paulwong/aggbug/382215.html" width = "1" height = "1" />
]]>
RUPh較高認知度的原因之一恐怕是因為其提Rational軟g公司聚集了物件導向領域三位傑出專家Booch、Rumbaugh?JacobsonQ同時它又是物g向開發的行業標準語a——標準徏模語a(UML)的創立者。RUP是由Objectory過程演化而來。本文主要討?RUP的主要內容和牚w?br />
?RUP的二E開發模?br />
RUP可以用二E坐標來描述。橫軔R過時間i織Q是過程展開的生命週期特RQ體N發過E的動態i構Q用來描q它的術語主要包括週期 (Cycle)、階D?Phase)、P?Iteration)和里E碑(Milestone)Q縱总內容來組J為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括zd(Activity)、產?Artifact)、工作?Worker)和工作流(Workflow)?br />
?開發過程中的各個階D和里程?br />
RUP中的軟g生命週期在時間上被分解為四個順序的階段Q分別是Q初始階D?Inception)、細化階D?Elaboration)、構建階D?Construction)和交付階D?Transition)。每個階D늵束於一個主要的里程?Major Milestones)Q每個階D|質上是兩個里E碑之間的時間跨度。在每個階D늚i尾埯一ơ評C定這個階D늚目標是否已經滿。如果評估結果o人滿意的話，可以允許項目進入下一個階Dc?br />
初始階段(Inception Phase)
初始階段的目標是為系i徏立商業案例並定項目的邊界。為了達到該目的必須識別所有與pȝ交互的外部實體，在較高層ơ上定義交互的特性。本階段h非常重要的意，在這個階D中所關注的是整個項目進行中的業務和需求方面的主要風險。對於徏立在原有pȝ基礎上的開發項目來講Q初始階D可能很短?br />
初始階段i束時是W一個重要的里程：生命週期目標(Lifecycle Objective)里程。生命週期目標里程評僚w目基本的生存能力?br />
細化階段(Elaboration Phase)
細化階段的目標是分析問題領域Q徏立健全的體系i構基礎Q編製項目計劃，淘汰項目中最高風險的元素。為了達到該目的Q必須在理解整個系iq基礎上，體pȝ構作出決{，包括其範圍、主要功能和諸如性能{非功能需求。同時為項目建立支持環境Q包括創建開發案例，創徏模板、準則並準備工具?br />
細化階段i束時第二個重要的里程：生命週期i構(Lifecycle Architecture)里程。生命週期i構里程為pȝ的結構徏立了理基準並項目組能夠在構建階D中進行衡量。此刻，要檢驗詳細的pȝ目標和範圍、結構的選擇以及主要風險的解決方案?br />
構徏階段(Construction Phase)
在構建階D，所有剩的構g和應用程序功能被開發並集成為產品Q所有的功能被詳細測試。從某種意義上說Q構建階D|一個製造過E，光點放在管理資源及控制運作以優化成本、進度和質量?br />
構徏階段i束時是W三個重要的里程：初始功能(Initial Operational)里程。初始功能里E碑決定了產品是否可以在測試環境中進行部v。此刻，要確定軟件、環境、用戶是否可以開始系iq運作。此時的產品版本也常被稱為「beta」版?br />
交付階段(Transition Phase)
交付階段的重點是Z軟g最i用戶是可用的。交付階D可以跨幾ơP代，包括為發佈做準備的產品測試，基於用戶反饋的少量的調整。在生命週期的這一點上Q用戶反饋應主要集中在產品調_a置、安裝和可用性問，所有主要的i構問題應該已經在項目生命週期的早期階D解Z?br />
在交付階D늚i點是第四個里E碑Q產品發?Product Release)里程。此時，要確定目標是否實現，是否應該開始另一個開發週期。在一些情況下這個里E碑可能與下一個週期的初始階D늚i束重合?br />
?RUP的核心工作流(Core Workflows)
RUP中有9個核心工作流Q分?個核心過E工作流(Core Process Workflows)?個核心支持工作流(Core Supporting Workflows)。儘?個核心過E工作流可能使h惌v傳箔瀑布模型中的qր階D，但應注意q代過程中的階段是完全不同的Q這些工作在整個生命週期中一ơ又一ơ被a問?個核心工作流在項目中輪流被用，在每一ơP代中以不同的重點和D度重複?br />
商業建模(Business Modeling)
商業建模工作描qC如何為新的目標組J開g個構惻I並基於這個構惛_商業用例模型和商業對像模型中定義i織的過E，角色和K仅R?br />
需?Requirements)
需求工作流的目標是描述pȝ應該做什|並開發人員和用戶就這一描述達成p。為了達到該目標Q要需要的功能和約束進行提取、組J、文檔化Q最重要的是理解pȝ所解決問題的定和圍?br />
分析和設a?Analysis & Design)
分析和設a工作流需求轉化成未來pȝ的設a，為系i開g個健壯的i構並調整設a其與實現環境相匹配，優化其性能。分析設a的i果是一個設a模型和一個可選的分析模型。設a模型是源代的抽像Q由a計和一些描q組成。設a類被組J成h良好接口的設a包(Package)和設a子pȝ (Subsystem)Q而描q則體現了類的對象如何協同工作實珄例的功能?br />
a計zd以體pȝ構設a為中心Q體pȝ構由若干i構視圖來表達，i構視圖是整個設a的抽像和簡化，該視圖中省略了一些細Q重要的特點體珑־更加清晰。體pȝ構不僅僅是良好設a模型的承載媒介Q而且在系iq開發中能提高被創建模型的質量?br />
實現(Implementation)
實現工作的目的包括以層ơ化的子pȝ形式定義代碼的組J結構；以組件的形式(源文件、二進制文g、可埯文g)實現和像Q將開發出的ig作為單元進行測試以及集成由單個開D（或小i）所產生的結果，使其成為可執行的pȝ?br />
測試(Test)
測試工作要驗證像間的交互作用Q驗證軟件中所有組件的正確集成Q檢驗所有的需求已被正的實現, 識別並確認缺陷在軟g部v之前被提Z處理。RUP提出了P代的ҎQ意呌在整個項目中進行測試Q從而儘可能早地發現~陷Q從Ҏ上降低了修改~陷的成本。測試類似於三維模型Q分別從可靠性、功能性和pȝ性能來進行?br />
部v(Deployment)
部v工作的目的是成功的生成版本並將軟g分發i最i用戶。部|工作流描述了那些與Z軟g產品最i用戶具有可用性相關的zdQ包括：軟g打包、生成軟件本w以外的產品、安裝軟件、為用戶提供q助。在有些情況下，還可能包括計劃和進行beta測試版、移植現有的軟g和數據以及正式驗收?br />
配置和變更管?Configuration & Change Management)
配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的產物。配|和變更理工作提供了準則來管理演化系i׃的多個變體，跟蹤軟g創徏過程中的版本。工作流描述了如何管理並行開癹{分佈式開發、如何自動化創徏工程。同時也闡述了對產品修改原因、時間、h員保持審a記錄?br />
項目理(Project Management)
軟g項目理q各種可能產生衝突的目標，理風險Q克服各E約束併成功交付使用戶滿意的產品。其目標包括Q為項目的管理提供框Ӟ劃、h員配備、執行和監控項目提供實用的準則，為管理風險提供框架等?br />
環境(Environment)
環境工作的目的是向軟g開發i織提供軟g開發環境Q包括過E和工具。環境工作流集中於配|項目過E中所需要的zdQ同樣也支持開發項目規範的活動，提供了逐步的指手冊並介紹了如何在i織中實NE?br />
?RUP的P代開發模?br />
RUP中的每個階D可以進一步分解為q代。一個P代是一個完整的開發循環Q產生一個可埯的產品版本，是最i產品的一個子集，它增量式地發展，從一個P代過E到另一個P代過E到成為最i的pȝ?br />
傳箔上的項目i織是順序通過每個工作流Q每個工作流只有一ơ，也就是我們熟悉的瀑布生命週期。這樣做的i果是到實現末期產品完成並開始測試，在分析、設a和實現階段所遺留的隱藏問會大量出現Q項目可能要停止並開始一個OL錯誤修正週期?br />
一E更靈活Q風險更的Ҏ是多ơ通過不同的開發工作流Q這樣可以更好的理解需求，構造一個健壯的體系i構Q並最i交付一pd逐步完成的版本。這叫做一個P代生命週期。在工作中的每一ơ順序的通過Eq一ơP代。軟件生命週期是P代的連續Q通過它，軟g是增量的開發。一ơP代包括了生成一個可埯版本的開發活動，還有使用這個版本所必需的其他輔助成分，如版本描q、用戶文檔等。因此一個開DP代在某種意義上是在所有工作流中的一ơ完整的E過Q這些工作至包括：需求工作流、分析和a計工作、實珑ַ作流、測試工作流。其本n像一個小型的瀑布項目?br />
與傳iq瀑布模型相比較，q代過程h以下優點Q?br />
降低了在一個增量上的開支風險。如果開gh員重複某個P代，那麼損失只是這一個開發有誤的q代的花貅R?br />
降低了產品無法按照既定進度進入市場的風險。通過在開發早期就定風險Q可以儘早來解決而不x在開發後期匆匆忙忙?br />
加快了整個開發工作的進度。因為開gh員清楚問的焦點所在，他們的工作會更有效率?br />
由於用戶的需求並不能在一開始׃出完全的界定Q它們通常是在後續階段中不L化的。因此，q代過程這種模式佉K應需求的變化會更Ҏ些?br />
?^結
RUPh很多镯Q提高了團隊生產力，在P代的開發過程、需求管理、基於組件的體系i構、可視化軟g建模、驗證軟件質量及控制軟g變更{方面，針對所有關늚開發zd為每個開發成員提供了必要的準則、模板和工具指導Q並Z全體成員׃n相同的知識基C。它建立了簡潔和清晰的過E結構，為開發過E提供較大的通用性。但同時它也存在一些不I RUP只是一個開發過E，並沒有涵蓋軟仉E的全部內容Q例如它~少關於軟g運行和支持等斚w的內容；此外Q它沒有支持多項目的開發i構Q這在一定程度上降低了在開發i織內大圍實現重用的可能性。可以說RUP是一個非常好的開端，但並不完?
]]>
隨著現代信息產業的蓬勃發展，軟g開發已經成為一項浩大繁複的工程?像是徏造一座宏偉的宮殿Q?從計劃、設a到施工Q?每一個環都必須嚴格把關， E有不慎Q?整個工E就會失敗?據箔a， 僅在國Q?每年有180,000個信息技術項目， 耗資大約$2500億美元， 其中25-30%的項目會產?由此可見Q?由於理不善和設a上的失誤所造成的損失是巨大的。現代軟仉發的理和方法論得比以往M時候都更為重要?br />
軟g開發的過E由Ҏ論和工具構成Qprocess = methodology + toolsQ。正如裝配電子設備一樣，僅有工具可以勝任裝配Q務。但Z減少p和提高效率，人們往往採用水R作業，水R作業便是一E應用於da備裝配中的Ҏ論。目前，信息技術市場流行的Ҏ論有RUP(Rational Unified Process), The Zachman Framework, XP (Extreme Programming){。在這些Ҏ論中Q最行的要數RUP。RUP是由Rational Software公司首創的。因它與當前行的JAVA, J2EE技術和麵向象的設a思想QOOADQ緊密的i合在一P所以在大型的信息技術項目中得到了廣泛的應用。在這篇文章中，我們試圖對RUP的特點作一個初步的探討Q並且討論它是如何貫I在整個軟仉發的生命週期之中的?br />
RUP最重要的它有三大特點：1Q軟仉發是一個疊代過E，2Q軟仉發是由Use Case驅動的，3Q軟仉發是以構架設a（Architectural DesignQ為中心的?br />
按照傳箔的瀑布QWaterfallQ開發模式，軟g開發大致E歷如下qր步驟：商務需求分析（Business Requirement AnalysisQ，pȝ分析QSystem AnalysisQ，pȝa計QSystem DesignQ，開發實現QImplementationQ，測試QTestQ，gQDeploymentQ，pȝ支持QSupportingQ和pȝ變更理QChange ManagementQ。傳iq瀑布開發模式假定在進行新的開發過程時，上一個過E已E完成，而且不會回到上一個過E。初看v來，這似乎是一個非常合理，高效率的解決ҎQ但20多年的實t證明，這個開發模式存在著很大的弊病，原因是軟仉發是一個非常複雜的工程Q有諸多的因素媄響工E的效率和成敗。軟仉發需要許多不同背景的個h和團隊參與。由於這些複雜性，在軟仉發的整個生命週期中每一個階D都有可能留下隱患和錯誤。如果等到系i已E開發實珑֮畢，在測試階D늙現了重大問題Q這時的返工將會造成人力、物力、財力及時間上的巨大費。鑑g上的考慮QRUP弯軟g開發是一個疊代模型（Iterative ModelQ，RUP定義了四個階D?Phase)Q開?Inception)Q闡q?(Elaboration)Q徏?Construction)Q過?Transition)。其中每個階D都有可能經歷以上所提到的從商務需求分析開始的各個步驟，只是每個步驟的高峰期會發生在相應的階段。例如開發實珄高峰期是發生在徏造階Dc實際上這樣的一個開發方法論是一個二E模型。這種疊代模型的實珑֜很大E度上提供了及早發現隱患和錯誤的會Q因此被現代大型信息技術項目所採用?br />
RUP 的另一大特徉|Use Case 驅動。Use Case 是RUPҎ論中一個非帔R要的概念。簡單地說，一?Use Case是pȝ的一個功能。例如在一個基於電子商務的醫療pȝ中，病h可以坐在家裡通過E上瀏覽器與醫生約定看病的時?(Make appointment)Q這樣Q「Make appointment」就是系iq一個Use Case。在pȝ分析和系ipa中Q?Use Case被用來將一個複雜的龐大pȝ分割、定成一個個小的單元，這個小的單元就是Use Case,然後以每個小的單元為象進行開發。按?RUP, Use Case貫穿整個軟仉發的生命週期。在商務需求分析中Q客戶或用戶Use Case進行描述Q在pȝ分佈和系ipa過E中Q設a師Use Case進行分析Q在開發實現過程中，開發R程人員Use Case進行實現Q在測試過程中，測試人員Use Case進行檢驗?br />
RUP的第三大特R是它弯軟g開發是以構架Z心的。構架設a（Architectural DesignQ是pȝa計的一個重要組成部分。在構架a計過程中，a計?Architect)必須完成技術和運行q_的選取，整個項目的基礎框架(Framework)的設a，完成公q件的a計Q如審計(Auditing)pȝQ日?Log)pȝQ錯誤處?Exception Handling)pȝQ安?(Security)pȝ{。設a師必須系iq可擴展?Extensibility)Q安全?Security)Q可E護?(Maintainability)Q可延拓?Scalability)Q可重用?Reusability)和運行速度(Performance)提出可行的解決方案?br />
在RUPҎ論中Q不同的角色可以從不同的側面來認識同一個項目。RUP定義了?+1」個場?ViewQ： Use Case場景(Use Case View)Q邏輯場?Logic View)Q進程場景(process View)Q實珑֠?(Implementation View)和發佈場?Deployment View)。在Use Case場景中，客戶和商務分析員?Use Case進行描述Q在邏輯場景中，a計師對pȝ進行分析和設a，在進程場景中，a計師對pȝ可能出現的併發性，運行速度和分佈特性進行描述。實珑֠景則反映了程序開發員開發實現的過E。發佈場景是描述pȝ理員和i裝人員實施pȝg和管理的過程。值得弯的是Q系i構架的a計是在邏輯場景中描q的?br />
RUP還定了4個模型，即Use Case模型QUse Case ModelQ，分析模型 (Analysis Model)Q設a模?Design Model)和實現模?Implementation Model)。Use Case模型包含Use Case Diagram和Use Case文檔。Use Case模型是其他三個模型的基礎Q分析模型即是概忉|?(Conceptual Model)Q是pȝ分析所得到的結果，分析模型包含了類?Class Diagram)Q次序圖 (Sequence Diagram)以及zd?Activity Diagram)。設a模型則是構架設a和pȝa計的結果。當a計模型完成後，開發R程人員便可以進行R程了。設a模型主要包含了圖Q次序圖和狀態圖(State Chart Diagrams)。分析模型和a計模型看v來有a多怼之處Q但兩者的含義有本質的區別。分析模型D調的是問的圍Q但並不i出解決問題的方案，分析模型並不涉及具體的技術和q_。例如它並不關心是否應用 EJB或一般的JAVA BEANSQ系i是安裝在WebSphere或是在WebLogic。但是與之相反，a計模型要考慮這些細節Q而且要提供解決這些問題的全部方案。當然設a模型是建立在分析模型之上的Q分析模型中的一個類可直接映成a模型中的類Q但這種映射關係一般並不是一一應的，最後一個模型是實現模型。實現模型包含構件圖QComponent DiagramQ，從這個模型出|開發R程人員可以產生骨架源程?(Skeleton Source Code)Q也可以從源E序出發更新a計模型?br />
目前應用於系i分析和a計的工具主要有Rational Rose和Together Software Center (TogetherJ)。JAVA和J2EE的開發工hIBM Websphere Application Developer(WSAD), Borland Jbuilde和WebGain VisualCafe. WSAD和WebSphere Application Server應用在一P使得服務器端的排錯和pȝ的發布變得非常的Ҏ。Jbuilder和VisualCafe一般與WebLogic ServerR密i合在一赗目前WebSphere Server和WebLogic Server佔據了Application Server市場?6%Q其?WebSphere Server佔據?7%Q成為同產品的No.1。在單位測試和集成測試中Q廣泛應用的工具和框架有Junit, JunitPerf和Cactus.?br />
E上所qͼ軟g開發的方法論已經成為現代軟g工程過程中不可缺的一個重要部分。是目前在Java/J2EE和麵向對象的大型項目中廣泛被採用的一E方法論。他整個軟仉發的生命週期提供了基C框架和指導。RUP, UML/Rational Rose, Java/J2EE, WSAD, Websphere Application Server和Oracle這樣的技術、工具和q_的組合是目前a多公司、政府信息技術項目中採用的方案。因此，RUP的知識和E驗也是珑֜求職市場所需求的熱門技能?
]]>