uml建模實例講解

1、RUP過程與UML模型驅(qū)動開發(fā)方法在證券研發(fā)項目中的應用實踐新思維金融軟件研發(fā)中心 軟件構架師 胡協(xié)剛內(nèi)容提要軟件開發(fā)沒有銀彈統(tǒng)一通道平臺開發(fā)項目簡介項目的開發(fā)目錄結構與RUP核心工件貫穿全局的統(tǒng)一UML模型用前景文檔定義目標系統(tǒng)軟件構架文檔與4+1視圖契約式開發(fā)與單元測試自動化構建與持續(xù)集成迭代開發(fā)模式軟件開發(fā)沒有銀彈軟件項目復雜、不確定和高風險軟件因其固有的復雜、不確定和高風險等屬性，使得其開發(fā)活動非常難以控制軟件產(chǎn)品用于解決一個或多個領域的現(xiàn)實問題，不僅與其開發(fā)者本身直接相關，還牽涉到客戶、最終用戶、第三方伙伴等眾多涉眾，所謂眾口難調(diào)，但一個成功的軟件必須能滿足多方面的需求軟件所依賴的核

2、心技術、項目的開發(fā)方法、軟件過程、項目管理和團隊協(xié)作等，都是事關項目成敗的關鍵因素CMMI與RUP根據(jù)CMMI的定義，軟件過程要達到第三成熟度等級，需要實施十八個關鍵過程域；普通團隊雖然不一定向此標準看齊，但實際上仍然涉及到這十八個關鍵過程域所涵蓋的近百項活動，只不過可能實施的力度較小、質(zhì)量不高、或者忽略了活動本身的含義而已RUP與CMMI第三成熟度等級相對應，定義了九個核心準則（Discipline），和幾百項活動這還僅僅只是軟件過程的范疇，項目中人的管理、溝通以及具體的關鍵技術等等，其牽涉面將更廣軟件開發(fā)沒有銀彈諸多因素分屬不同的范疇，針對不同的問題，需要應用不同的技術、技能和方法，要求項

3、目成員擁有不同的知識、素質(zhì)與背景沒有一種方法或途徑能夠解決軟件項目中所有的問題，即所謂“沒有銀彈”，所以不要迷信存在所謂的一勞永逸的終極解決方案成功意味著多方面的艱苦努力軟件項目適用于“木桶原理”，要獲得成功，必須由所有成員在多個方面都付出艱苦的努力，包括完成一些繁瑣與枯燥的工作，并保證任何一個環(huán)節(jié)都不出重大問題在下面介紹的一個實際項目中，將會看到我們是如何通過裁減RUP過程來主導項目的開發(fā)活動，使用統(tǒng)一的UML模型來表達和溝通設計，利用共享的產(chǎn)品目錄結構來協(xié)同開發(fā)，并通過加強團隊建設，揚長避短，發(fā)揮各成員的長處等總之從多個方面來努力，方才最終達成項目成功的過程實例項目簡介證券統(tǒng)一通道平臺項目

4、項目的目標系統(tǒng)（統(tǒng)一通道平臺）是在證券公司總部和所有營業(yè)部網(wǎng)點統(tǒng)一部署的、適應不同網(wǎng)絡拓撲結構的、支持內(nèi)外網(wǎng)段物理安全隔離的、基于消息的通訊中間件平臺系統(tǒng)，用以支持熱自助、 委托等各類外圍客戶端系統(tǒng)，集中經(jīng)紀業(yè)務系統(tǒng)、傳統(tǒng)營業(yè)部柜臺系統(tǒng)等核心服務系統(tǒng)，以及銀行端銀證業(yè)務系統(tǒng)等第三方系統(tǒng)的透明接入UCS 輻射型拓撲部署結構項目開發(fā)過程概貌項目采用RUP的迭代開發(fā)生命周期模型，總計經(jīng)歷了六次迭代，持續(xù)約八個月，項目組成員36人，耗費共計685個工作人日，最終有效代碼30,471 行，千行代碼集成缺陷率低于1 使用Clearcase UCM實施配置管理，并基于此組織項目的產(chǎn)品目錄結構，囊括了RUP定

5、義的主要核心工件使用Rose開發(fā)了統(tǒng)一的UML模型，從上下文分析、功能用例模型、到設計模型、進程模型、部署模型等，涵蓋了項目大部分分析、設計成果，利用了Rose的正向工程生成大部分代碼框架目標系統(tǒng)的分析、設計、編碼完全實現(xiàn)面向?qū)ο箜椖块_發(fā)過程概貌continue項目以軟件構架文檔為中心，配合Rose模型、詳細設計文檔，使得產(chǎn)品的設計比較到位項目引入了契約式編程方法，編碼語言為標準c+，使用CppUnit測試框架進行較為廣泛的單元測試，對產(chǎn)品的質(zhì)量改進幫助很大使用Ant+Cpptasks工具初步實現(xiàn)了自動化構建與集成項目本身系公司的過程改進試點項目，集中了部門最優(yōu)秀的人員，大家都表現(xiàn)了良好的團隊

6、協(xié)作精神，建立了密切的私人關系作為試點項目，其成果，已經(jīng)作為模板工程在公司大力推廣項目的開發(fā)目錄結構開發(fā)（產(chǎn)品）目錄結構開發(fā)（產(chǎn)品）目錄結構的規(guī)劃原則：滿足不同角色，在不同的項目階段，對不同類型工件進行訪問的多種場景需求ClearCase Stream（流）的劃分：- PCHL_V1_Integration整個項目所有工件的最終整合場所，用于項目級基線構建、進行集成和確認集成測試- PCHL_V1_Working需求、設計、管理、過程等工作場所- PCHL_V1_Dev項目所有構件的開發(fā)場所- PCHL_V1_Testing測試組的測試場所- PCHL_V1_Release發(fā)布演示場所UCM工

7、程示例項目的開發(fā)目錄結構continue項目目錄參照RUP的工件集來組織Clearcase VOB的劃分：Infrastructures內(nèi)部開發(fā)的相對獨立、復用度強的基礎應用包，針對第三方產(chǎn)品進行封裝的調(diào)用接口等Libraries從組織外部獲取的源碼庫、開發(fā)組件等，主要來自于開放源碼；PCHL_Components項目組針對目標系統(tǒng)開發(fā)的構建于底層開發(fā)包、基礎設施之上的所有構件PCHL_SubSystems構建于底層開發(fā)包、基礎設施與所有構件之上的可執(zhí)行子系統(tǒng)（或系統(tǒng)），通常是目標系統(tǒng)的最終交付實體PCHL_System項目目標系統(tǒng)主體工件目錄，包含需求、設計、集成、測試等PCHL_Manag

8、ement項目的管理工件目錄PCHL_Supports項目的過程、環(huán)境、標準等支持工件目錄開發(fā)目錄結構示例項目產(chǎn)出的主要文檔證券統(tǒng)一通道平臺前景文檔證券統(tǒng)一通道平臺補充規(guī)約證券統(tǒng)一通道平臺軟件構架文檔XXXX詳細設計文檔軟件開發(fā)計劃測試計劃系統(tǒng)性能測試報告系統(tǒng)安裝與配置手冊外圍服務協(xié)議API應用開發(fā)手冊統(tǒng)一的UML模型OMG的模型驅(qū)動架構OMG主導的MDA（Model Driven Architecture）正在成為下一代軟件開發(fā)的主流模式基本的模型轉(zhuǎn)換關系：Computation Independent Model (CIM)- Platform Independent Model (PIM

9、)- Platform Specific Model (PSM)- Implementation貫穿全局的統(tǒng)一UML模型使用一個統(tǒng)一的可視化模型來表達項目的分析、設計思想，進而通過標準的語言（UML）來進行成員間的溝通，以減低傳遞過程中信息丟失和錯誤理解的風險利用建模工具（Rose）對雙向工程（Round Trip Engineering）的支持，初步實現(xiàn)MDA中平臺相關的模型到實施代碼框架的轉(zhuǎn)換（ PSM- Implementation）統(tǒng)一的Rose模型示例上下文分析模型示例需求模型示例層次結構模型示例詳細設計模型示例用例實現(xiàn)模型示例實施（構件）模型示例部署模型示例前景文檔與目標系統(tǒng)邊界用

10、前景文檔定義目標系統(tǒng)根據(jù)軟件應用的上下文（或業(yè)務建模），將要解決的領域問題，涉眾（特別是最終用戶）對產(chǎn)品的要求，相關的限制條件等，確定目標系統(tǒng)的定義確定系統(tǒng)的范圍，用特性來定義系統(tǒng)，并給出相關的優(yōu)先級順序功能性特性將映射到系統(tǒng)用例產(chǎn)品定位確定目標系統(tǒng)的市場背景列明系統(tǒng)將要解決的重大問題系統(tǒng)的概括定義涉眾/用戶及其需要標識目標系統(tǒng)的最終用戶與其他涉眾，以確定需求收集的來源分析用戶與涉眾的基本特點，以幫助獲取與辨別系統(tǒng)的需求列明用戶與涉眾針對目標系統(tǒng)的各類需要（needs），它們決定了最終系統(tǒng)需求產(chǎn)品概述明確地定義目標系統(tǒng)勾畫目標系統(tǒng)的上下文環(huán)境與邊界列明目標系統(tǒng)的主要（能力）特性及其提供給客戶的

11、利益明示目標系統(tǒng)當前所做的假定和其依賴的條件，它們將可能是未來引起需求變更的重要因素產(chǎn)品特性以特性（Feature）的方式定義目標系統(tǒng)的高層需求特性表達了目標系統(tǒng)為了實現(xiàn)用戶利益而必須具備的能力（Capability）特性是一種對外的服務，通常要求用戶提供一系列輸入以得到響應的結果其它高層需求設計約束限定了目標系統(tǒng)設計乃至實現(xiàn)方案的選擇范圍接口需求質(zhì)量范圍概略描繪了目標系統(tǒng)的重要質(zhì)量需求適用標準、硬件需求及環(huán)境需求等優(yōu)先級目標系統(tǒng)的產(chǎn)品特性優(yōu)先級大致可以分為：關鍵、重要和有用特性優(yōu)先級為項目開發(fā)順序的選擇提供了原始依據(jù)（當然目標系統(tǒng)各構件間的依賴關系對開發(fā)順序的影響更大）特性優(yōu)先級是用于實施需

12、求管理的重要內(nèi)容用例規(guī)約與補充規(guī)約用例詳述是對功能性特性的細化系統(tǒng)用例的整體結構適于用UML的Use Case模型表達在UML模型中使用序列圖描述所有的系統(tǒng)用例是一種有效的表達方式補充規(guī)約是對公共功能性需求和質(zhì)量等非功能性需求的細化軟件構架文檔與4+1視圖軟件構架表述構架描述（構架文檔）的用途表達（軟件）系統(tǒng)及其演化用于系統(tǒng)涉眾之間的交流以一致的方式來評估與比較軟件構架 用來計劃、管理與執(zhí)行系統(tǒng)開發(fā)的各項活動 表達系統(tǒng)的固有特性與支撐原則，以引導可接受的變更 驗證系統(tǒng)的實現(xiàn)符合構架描述充實軟件密集系統(tǒng)的構架知識庫（參考構架） 4+1視圖軟件系統(tǒng)本身包含的內(nèi)容太豐富且復雜，就像建筑一樣，人們無法

13、同時從一個角度看到其全貌，因此需要使用多個視圖（View）來表達系統(tǒng)的構架 視圖是視點（Viewpoint）的實例，并擁有一個或多個模型（Model）4+1視圖分別從外部功能，靜態(tài)結構，動態(tài)行為，運行時刻形態(tài)和物理部署拓撲等方面來描述目標軟件的構架構架設計目標與約束 構架設計的目標首先要滿足目標系統(tǒng)的關鍵功能需求 目標系統(tǒng)的質(zhì)量需求、接口要求等對構架往往產(chǎn)生決定性的影響項目開發(fā)策略，例如第三方構件的選用等是展開構架設計的重要基礎變更案例（Change Case）要求構架必須具備相應的可擴展性和適應性設計約束等則限定了構架方案選擇的范圍用例視圖 用例視圖從用戶使用的角度描述系統(tǒng)構架的基本外部行為

14、特性，通常包含業(yè)務用例模型與系統(tǒng)用例模型。通常應選取用例模型中對系統(tǒng)構架的內(nèi)容產(chǎn)生重大影響的應用場景與用例集合，這些用例代表了系統(tǒng)主要的核心功能，往往決定了系統(tǒng)構架的基本組成元素。系統(tǒng)概念模型 描述目標系統(tǒng)的關鍵構架機制與概念，主要表達系統(tǒng)為了滿足主要軟件需求，而采用的相關構架模式、以及引用的重要概念標準的RUP構架文檔模板中沒有這一部分，但是為了方便涉眾理解構架，可以增設此節(jié)邏輯視圖 邏輯視圖從系統(tǒng)內(nèi)在邏輯結構的角度描述系統(tǒng)的基本結構與動態(tài)行為，通常包括分析模型（Analysis Model）、設計模型（Design Model）以及數(shù)據(jù)模型（Data Model）等。設計模型說明了系統(tǒng)的組

15、成元素、組織架構和關系，并描述了各組成元素的協(xié)作以及狀態(tài)轉(zhuǎn)換關系等（通過用例實現(xiàn)Use Case Realization予以表達）。進程視圖 進程視圖從系統(tǒng)運行時刻的角度，描述系統(tǒng)劃分為進程、線程的結構，及其動態(tài)關系。模型主要說明進程、線程的分類，系統(tǒng)構架敏感的主要邊界類、控制類對象等在進程、線程中的分布，以及它們之間的創(chuàng)建、交互與消息通訊關系等 部署視圖部署視圖從系統(tǒng)軟硬件物理配置的角度，描述系統(tǒng)的網(wǎng)絡邏輯拓撲結構。模型包括各個物理節(jié)點的硬件與軟件配置，網(wǎng)絡的邏輯拓撲結構，節(jié)點間的交互與通訊關系等。同時還表達了進程視圖中的各個進程具體分配到物理節(jié)點的映射關系 實施視圖實施視圖從軟件編譯與構建

16、的角度，描述系統(tǒng)實施構件的組織結構與依賴關系（主要是編譯依賴）。模型包括實施子系統(tǒng)和構件結構，及其依賴關系。同時還表達了邏輯視圖中各個包和類分配到實施視圖中的子系統(tǒng)和構件的映射關系 契約式開發(fā)與單元測試契約無所不在軟件系統(tǒng)的本質(zhì)特征是由表及里、至頂而下的一種層次結構，其構成是所有相對獨立的構件或元素而將所有構件或元素組織成為一個有機整體的正是無所不在的契約在最表層，即系統(tǒng)與外部環(huán)境之間，是最終用戶與系統(tǒng)整體進行交互的契約（通?？梢猿橄蟪上到y(tǒng)用例）；次之，各子系統(tǒng)/構件之間，是它們相互通訊協(xié)作的契約；最后，類與類、類操作、以及獨立函數(shù)之間，是它們相互調(diào)用的契約軟件系統(tǒng)契約關系契約的內(nèi)容前置條件，

17、指在執(zhí)行某種操作（例如啟動用例的一條執(zhí)行路徑、調(diào)用類的一個方法等）之前，目標和其上下文必須共同滿足的條件（例如系統(tǒng)處于正常運行狀態(tài)、用戶賬號存在并未凍結、對象從其上下文獲取的資源處于可用狀態(tài)等）合法的輸入（例如發(fā)送給子系統(tǒng)的請求消息格式正確、取值在規(guī)定范圍內(nèi)等）期望的輸出（例如系統(tǒng)返回給用戶需要的查詢結果等）后置條件，指無論某種操作的執(zhí)行過程怎樣，結束后，目標和其上下文必須達到的狀態(tài)或滿足的條件（例如類的不變式不被打破、上下文資源被釋放、系統(tǒng)不出現(xiàn)不能預料的邊際效應等）契約式需求分析（Analysis for contract）如果以契約的觀點來觀察系統(tǒng)的外部行為，我們不妨在契約式設計之上再引

18、入契約式需求分析的概念，這樣契約式開發(fā)顯得更為完整用例本質(zhì)上是表述目標系統(tǒng)與其最終用戶之間交互的契約，它使得需求規(guī)格的定義變得更加精確和全面，而傳統(tǒng)的功能及質(zhì)量需求規(guī)格說明往往容易遺漏前置條件、輸入格式等重要細節(jié)用例強調(diào)實現(xiàn)體現(xiàn)了用戶利益的目標，在較低層面定義契約時，同樣可以顯式地描述諸如一個類操作的目標契約式設計（Design by contract）面向?qū)ο蟮姆治?、設計其首要問題就是類的劃分與職責分配類的職責被確定后，通過定義類的不變式，限定對象的有效狀態(tài)空間；通過定義類操作的前置、后置條件和輸入輸出，精確地描述類的行為契約同樣有助于精確地表達對象間的協(xié)作，因為這些協(xié)作步驟將遵從一系列的契

19、約契約式設計可以通過測試驅(qū)動開發(fā)等最佳實踐來驅(qū)使貫徹契約式編程契約式編程要求客戶（client）代碼在調(diào)用服務（server）代碼時也要遵守契約，意味著雙方共同承擔使運行獲得成功的責任，使得代碼間職責的分配更為均衡、合理，避免了服務代碼中防錯式設計的過度蔓延在代碼中加入判別契約是否被遵守的語句（例如assert），使得編碼中的缺陷（bug）能及時地暴露出來契約式編程結合測試先行、單元測試等最佳實踐，是實現(xiàn)高質(zhì)量構造（construct）的捷徑測試驅(qū)動開發(fā)XP推薦測試先行，即先編寫測試代碼，之后以通過所有測試為目標來驅(qū)動實現(xiàn)源碼的開發(fā)，這通常也稱作測試驅(qū)動開發(fā)先編寫測試代碼，使得實施員對目標源碼

20、的外部行為能先建立明確無誤的理解，并有助于盡早發(fā)現(xiàn)設計上的缺陷（趕在實現(xiàn)之前，畢竟編寫測試代碼的開銷較?。y試先行的實質(zhì)，就是先通過測試代碼最精確地表達目標代碼的契約（即定義其需求），隨后每次測試執(zhí)行都是為了驗證源碼是否滿足了契約單元測試單元測試比集成測試能更大限度地覆蓋單元的執(zhí)行路徑，是保證軟件質(zhì)量性價比最高的途徑單元測試代碼提供了目標代碼最直接、便利和相對獨立的運行上下文，方便代碼的調(diào)試和除錯單元測試在XUnit等測試框架的支持下，最容易實現(xiàn)測試的自動化，這也是回歸測試所依賴的重要基礎實施回歸測試，增強了項目的可視性，能及時提供反饋，極大地加強了開發(fā)的可控性單元測試編寫原則測試任何可能出錯

21、的地方，對于明顯不太可能出錯的方法（譬如set 和get這些非常簡單的方法），單元測試幾乎沒有意義注意測試邊界條件，比如未初始化、NULL、最大最小值等，防止實現(xiàn)時忘記處理它們?yōu)槟繕舜a編寫獨立的單元測試代碼，盡量不要與其它代碼產(chǎn)生依賴針對接口進行測試測試代碼示例CPPUNIT_TEST_SUITE_REGISTRATION(conversation_test);/ 單線程測試caller_conversationvoid conversation_test:singlethread_caller_conversation() typedef service1 single_service;

22、run_notify cur_notify(conversation_test:singlethread_caller_conversation); mock_manager test_manager; single_service svr(&test_manager); scope_guard _guard; _guard.register_todo(single_service:timed_join,&svr,DEFAULT_WAIT_MS); performance_time action; (); caller_tester single; for(int i=0 ; i 1000;

23、+i) (); cur_notify.watch(_WATCH_HELPER(i); (); cout use ms: ()endl;自動化構建與持續(xù)集成集成與構建軟件開發(fā)的目標是得到滿足需求的可運行的交付工件，即通常是將源碼等中間工件編譯、鏈接并集成而生成的一個建造（build）構建集成是一項看似簡單實際上充滿了陷阱的工作，在團隊開發(fā)的場景下，將牽涉到將不同成員開發(fā)的源碼等集成一體，解決各類沖突與依賴等復雜情況，這個過程直接依賴于軟件配置管理流程的支持一個合格的集成員需要掌握多項知識和技能 集成與構建的內(nèi)容配置項目集成的開發(fā)工具（列如msvc6/bcc55等編譯器）和自動構建工具（列如ant

24、/cpptasks）配置軟件配置管理環(huán)境（例如clearcase客戶端）制定不同構件間的編譯引用、庫鏈接等集成原則確定針對第三方開發(fā)包的源碼結構組織與構建步驟確定針對項目構件的源碼結構組織與構建步驟編制構建腳本制定集成計劃執(zhí)行實施單元測試提交集成冒煙測試流程構建計劃說明要在此迭代中實施哪些子系統(tǒng)/構件，并說明為及時做好集成準備而實施這些子系統(tǒng)的首選順序，這一順序取決于構件間的依賴關系 列明增量集成的工作版本（Working Version），每次迭代可能包含多個可測試的集成構造版本，它們決定了每次集成構建周期Ant構建腳本Ant配置文件描述了一個構建項目（project），它由一些屬性定義（property）和一個目標樹（target tree）組成；目標代表了一個期望的構建結果（例如生成一個鏈接好的可執(zhí)行文件），并表述了其依賴的其它目標，常見的構建目標有初始化（Init）、編譯（Compile）、單元測試（Test）、安裝（Install）、清除（Clean）等；每個目標包含了實現(xiàn)它而將要執(zhí)行的任務（task），Ant支持的任務種類非常豐富，例如源碼編譯、文件拷貝、執(zhí)行命令行操作等。Ant執(zhí)行示例源碼目錄組織原則 開發(fā)（產(chǎn)品）目錄提供了項目團隊進行開發(fā)、管理等活動的統(tǒng)一共享場所，它需要滿足不同涉眾（角色），在