火龍果UML建模方法與技術(shù)new

UML建模方法與技術(shù)2內(nèi)容提要技術(shù)發(fā)展背景UML的基本概念靜態(tài)建模動態(tài)建模物理架構(gòu)建模步驟Rose的使用兩個實例參考書與資源鏈接3技術(shù)發(fā)展背景[1]面向?qū)ο蟮暮x面向?qū)ο蠹夹g(shù)回顧UML的產(chǎn)生4技術(shù)發(fā)展背景[2]－面向?qū)ο蟮暮x面向?qū)ο笾杏芯艂€非常重要的概念：封裝（encapsulation）信息/實現(xiàn)的隱藏（information/implementationhiding）狀態(tài)保持（stateretention）對象標識（objectidentity）消息（message）類（class）繼承（inheritance）多態(tài)性（polymorphism）一般性（generality）5技術(shù)發(fā)展背景[3]－面向?qū)ο蟮暮x封裝，將屬性和操作包裝成一個單元，使得對狀態(tài)的訪問和修改只能通過封裝提供的接口進行。信息/實現(xiàn)的隱藏，將某些屬性或方法限制在封裝內(nèi)部使用，限制外部的可見性。狀態(tài)保持，對象能夠保持狀態(tài)，可以用于后續(xù)的處理。對象標識，每個對象可以作為軟件實體被標識和處理，每個對象都有一個對象標識符（objectidentifierOID）。消息，對象間發(fā)送請求的載體。6技術(shù)發(fā)展背景[4]－面向?qū)ο蟮暮x類，類是對象的類型（模版），對象是類的實例。繼承，子類隱式使用超類（或父類）的屬性和操作。多態(tài)性，子類覆蓋（overriding）父類的方法，它和重載（overloading）的區(qū)別在于重載是在同一個類中定義，利用參數(shù)的不同來進行動態(tài)綁定（dynamicbinding）。一般性，類的定義是參數(shù)化的或模版化的，提高了定義的通用性。7技術(shù)發(fā)展背景[5]－面向?qū)ο蠹夹g(shù)回顧面向?qū)ο蠹夹g(shù)是許多人歷經(jīng)多年研究積累的產(chǎn)物。類的概念，是面向?qū)ο蟮闹匾M成部分。Smalltalk，提出許多面向?qū)ο蠹夹g(shù)的核心概念，如：消息和繼承。Dijkstra的軟件正確性理念，提出了用抽象層構(gòu)造軟件的觀點。ADT抽象數(shù)據(jù)類型，奠定面向?qū)ο蟮幕A，支持信息的隱藏。Ada語言，提出了一般性和包兩個概念。C++語言，最廣泛使用的面向?qū)ο蟮恼Z言。Eiffel語言，融合了許多最佳的計算機科學思想和面向?qū)ο笏枷搿?技術(shù)發(fā)展背景[6]－UML的產(chǎn)生1988年到1992年是面向?qū)ο蠓椒▽W蓬勃發(fā)展的時期，人們從各自的經(jīng)歷和軟件開發(fā)的經(jīng)驗提出了各種面向?qū)ο蟮拈_發(fā)方法，代表的有：SallyShlaer和

SteveMellor以信息模型化方法作為基礎，并為目標系統(tǒng)增設了狀態(tài)模型和過程模型；

PeterCoad和

EdYourdon則在信息模型化、面向?qū)ο蟮某绦蛟O計語言和基于知識的系統(tǒng)的基礎上，建立了他們的OOA和OOD，主要工具是類與對象圖、對象狀態(tài)圖和服務圖；HP公司的Fusion開發(fā)方法。9技術(shù)發(fā)展背景[7]－UML的產(chǎn)生Wirfs-Brock的職責驅(qū)動設計(Responsibility-DrivenDesign)，也稱類-職責-協(xié)作Class-Responsibility-Collaboration(CRC)cards，用類所承擔的責任來描述系統(tǒng)，利用責任把封裝的概念帶到分析與設計活動中去；GradyBooch在Rational軟件公司開發(fā)Ada系統(tǒng)作了許多構(gòu)件(Component)，并以此由底向上構(gòu)筑大型軟件系統(tǒng)，即OOD方法；JimRumbaugh在通用電子(GeneralElectric)領(lǐng)導一個研究小組，提出了對象建模技術(shù)(OMT)方法，通過面向?qū)ο蟮娜N模型：對象模型、動態(tài)模型和功能模型，從不同角度對系統(tǒng)進行描述；10技術(shù)發(fā)展背景[8]－UML的產(chǎn)生IvarJacobson和他的Objectory公司開發(fā)了OOSE（ObjectOrientedSoftwareEngineering)面向?qū)ο蟮能浖こ蹋肬seCases來表達系統(tǒng)要求。1994年任職于Rational公司的GradyBooch首先聯(lián)合JimRumbaugh加盟Rational軟件公司開始了統(tǒng)一OO方法學和工具的歷程。以融合Booch和OMT方法的UML開發(fā)開始。1995年10月UML0.8發(fā)布。1995年秋，IvarJacobson和他的

Objectory公司加盟Rational，UML中加入了OOSE方法，使其有可能最集中地包容當今最適用的各種OO方法。1996年，UML0.9版本發(fā)布，1997年1月，UML1.0被提交給OMG組織，作為軟件建模語言的候選，1997年11月7日，UML1.1正式被OMG組織采納為業(yè)界標準。UML經(jīng)歷了1.2，1.3，1.4，目前UML2.0版本正在制定。11技術(shù)發(fā)展背景[9]－Rational三劍客JimRumbaughGradyBoochIvarJacobson12UML的基本概念[1]UML簡介UML的目標UML概念范圍13UML的基本概念[2]－UML簡介UML(UnifiedModelingLanguage)是一種構(gòu)建軟件系統(tǒng)和文檔的通用可視化建模語言。UML能與所有的開發(fā)方法一同使用，可用于軟件開發(fā)的整個生命周期。UML能表達系統(tǒng)的靜態(tài)結(jié)構(gòu)和動態(tài)信息，并能管理復雜的系統(tǒng)模型，便于軟件團隊之間的合作開發(fā)。UML不是編程語言，但支持UML語言的工具可以提供從UML到各種編程語言的代碼生成，也可以提供從現(xiàn)有程序逆向構(gòu)建UML模型。14UML的基本概念[3]－UML簡介UML并不是萬能的，它是一種離散的建模語言，對于特定的領(lǐng)域，比如：GUI、VLSI電路設計或基于規(guī)則的人工智能，用特定的語言和工具可能更合適。15UML的基本概念[4]－UML的目標最重要目標：UML是所有建模人員可以使用的通用建模語言。它包含主流建模方法的概念，從而可以替代現(xiàn)有的軟件分析和設計方法，比如：OMT,Booch,OOSE等。UML不是完整的開發(fā)方法，它不包括逐步的開發(fā)流程，但它提供所有必要的概念，具備足夠的表達能力。UML的另一個目標是：能盡量簡潔地表達系統(tǒng)的模型。16UML的基本概念[5]－UML概念范圍UML概念可以劃分為以下范圍：系統(tǒng)需求靜態(tài)結(jié)構(gòu)動態(tài)行為交互行為物理實現(xiàn)各種圖之間的關(guān)系模型組織擴展機制17UML的基本概念[6]－UML概念范圍系統(tǒng)需求用例視圖(UseCasesView)從外部用戶的角度來描述系統(tǒng)的行為，它將系統(tǒng)功能劃分為對用戶有意義的事務，這些事務被稱為用例，用戶被稱為執(zhí)行者，用例視圖也就是描述活動者在各個用例中的參與情況，它指導所有的行為視圖。18UML的基本概念[7]－UML概念范圍靜態(tài)結(jié)構(gòu):靜態(tài)視圖(StaticView)，一個模型必須首先定義各種事物的內(nèi)部特征和相互之間的關(guān)系，應用概念建模成類，類描述事物的屬性和以及在這些屬性上的操作。類之間可以存在不同的關(guān)系，比如泛化（繼承）、關(guān)聯(lián)和依賴等，靜態(tài)視圖表示成類圖，靜態(tài)視圖在某一時刻的快照稱為對象圖。19UML的基本概念[8]－UML概念范圍動態(tài)行為：狀態(tài)機視圖(StateMachineView)，通過對每個類的對象的生命周期進行建模，描述了對象時間上的動態(tài)行為。狀態(tài)機是由狀態(tài)和遷移組成的圖，狀態(tài)機通常附屬于類，描述類實例對接受事件的響應?；顒右晥D(ActivityView)是利用狀態(tài)機對運算和工作流進行建模的特殊形式。活動圖的狀態(tài)代表了運算執(zhí)行的狀態(tài)，而非一般對象的狀態(tài)，活動圖和流程圖很相似，不過它支持并發(fā)。20UML的基本概念[9]－UML概念范圍交互行為：交互視圖(InteractionView)，對象通過交互來實現(xiàn)行為，交互視圖通過協(xié)作來進行建模，協(xié)作具有結(jié)構(gòu)和行為兩個方面，結(jié)構(gòu)包含為行為方面而定義的一系列角色和關(guān)系，行為方面是綁定于角色的對象間的一系列交換的消息，這些消息在協(xié)作中稱為交互，消息序列可用兩種圖來表示：順序圖（重點在消息的時間順序）和協(xié)作圖（重點在交換消息的對象間的關(guān)系）。21UML的基本概念[10]－UML概念范圍物理實現(xiàn)：物理視圖(PhysicalView)，許多系統(tǒng)模型獨立于最終的實現(xiàn)，在實現(xiàn)方面，必須充分考慮系統(tǒng)的重用性和性能。UML有兩種視圖來表示系統(tǒng)的實現(xiàn)：實現(xiàn)視圖和部署視圖，實現(xiàn)視圖將可重用的系統(tǒng)片段打包成組件，部署視圖描述系統(tǒng)運行時資源的物理分布，這些資源稱為結(jié)點。22UML的基本概念[11]－UML概念范圍各種圖之間的關(guān)系靜態(tài)視圖（類圖，對象圖），物理視圖（實現(xiàn)視圖，部署視圖）是描述系統(tǒng)的靜態(tài)結(jié)構(gòu)。用例圖是描述系統(tǒng)的外部視圖?；顒訄D描述系統(tǒng)的外部/內(nèi)部視圖。交互視圖（順序圖，協(xié)作圖）描述系統(tǒng)的內(nèi)部視圖。狀態(tài)圖描述單個類的動態(tài)行為。23UML的基本概念[12]－UML概念范圍模型組織模型管理視圖(ModelManagementView)，任何大系統(tǒng)必須劃分為較小的單元，以使人們能在某一時刻只接觸有限的信息，不影響團隊間的并行工作。模型是利用包(Package)和包的依賴來進行管理的。包是UML模型中通用的層次組織結(jié)構(gòu)，包上的依賴總結(jié)了包內(nèi)容的依賴關(guān)系。24UML的基本概念[13]－UML概念范圍擴展機制擴展機制(ExtensionMechanisms)，UML能滿足絕大部分系統(tǒng)建模的需要，但任何語言都不是萬能的，它必須考慮一定的擴展機制，UML的擴展機制包括約束、標簽值和原型。這些擴展機制可以用來為特定領(lǐng)域剪裁UML的配置，這樣帶來一些好處：根據(jù)自身需要來使用建模語言。25靜態(tài)建模[1]一個模型必須首先定義各種事物的內(nèi)部特征和相互之間的關(guān)系，下面介紹一些基本的模型元素：分類：類（Class）接口（Interface）子系統(tǒng)（SubSystem）執(zhí)行者（Actor）用例（UseCases）組件（Component）結(jié)點（Node）注釋（Comment)關(guān)系：關(guān)聯(lián)（Association）泛化（Generalization）依賴（Dependency）實現(xiàn)（Realization）約束（Constraint)靜態(tài)視圖：類圖對象圖26靜態(tài)建模[2]－類類是具有相同屬性、操作和關(guān)系的對象集合的總稱。通常在UML中類被畫成矩形，包括三個部分：名稱、屬性和操作。名稱：每個類都必須有一個名字，用來區(qū)分其它的類。類名是一個字符串，稱為簡單名字。路徑名字是在類名前加包含類的包名為前綴。例如Wall、java::awt::Wall都是合法的類名。屬性：類可以有任意多個屬性，也可以沒有屬性。在類圖中屬性只要寫上名字就可以了，也可以在屬性名后跟上類型甚至缺省取值。

操作：操作是類的任意一個實例對象都可以調(diào)用的，并可能影響該對象行為的實現(xiàn)。

27靜態(tài)建模[3]－類類名屬性操作28靜態(tài)建模[4]－接口接口是未給出實現(xiàn)的對象行為的描述，接口包含操作，但沒有屬性，一個或多個類可以實現(xiàn)接口，每個類實現(xiàn)接口的操作。StringisEqual(String):BooleanHash():Integer…HashableComparable接口標記29靜態(tài)建模[5]－子系統(tǒng)（包）任何大系統(tǒng)都必須劃分為較小的單元，以便人們在某一時刻可以和有限的信息工作，使團隊的工作不相互影響。包可以包含各種模型元素和其它的包，包之間還可能存在一定的依賴。<<subsystem>>Finances<<subsystem>>Credits<<subsystem>>Accounts<<subsystem>>BankInterface30靜態(tài)建模[6]－子系統(tǒng)（包）子系統(tǒng)是具有獨立的說明和實現(xiàn)部分的包，它代表了與系統(tǒng)其它部分具有清晰接口的清晰單元，它通常代表了系統(tǒng)在功能或?qū)崿F(xiàn)范圍上的劃分。31靜態(tài)建模[7]－執(zhí)行者執(zhí)行者是與系統(tǒng)、子系統(tǒng)或類交互的外部人員，進程或事務。在運行時，具體人員會充當系統(tǒng)的多個執(zhí)行者，不同用戶可能會成為一個執(zhí)行者。StudentProfessorBillingSystemRegistrar32靜態(tài)建模[8]－用例用例是系統(tǒng)提供的外部可感知的功能單元，用例的目的是定義清晰的系統(tǒng)行為，但不解釋系統(tǒng)的內(nèi)部結(jié)構(gòu)。用例可以與執(zhí)行者關(guān)聯(lián)，也可以參與其他的多種關(guān)系，比如擴展、泛化和包含等。用戶的動態(tài)部分用交互視圖來描述，比如順序圖、協(xié)作圖。用例用橢圓來表示，用例名標在橢圓下方，用實線與同自身通信的用戶相連。MaintainCurriculum33靜態(tài)建模[9]－用例Registrar--maintainthecurriculumProfessor--requestrosterStudent--maintainscheduleBillingSystem--receivebillinginformationfromregistrationMaintainScheduleMaintainCurriculumRequestCourseRoster34靜態(tài)建模[10]－用例圖用例圖描述執(zhí)行者在各個用例中的參與情況。StudentRegistrarProfessorMaintainScheduleMaintainCurriculumRequestCourseRosterBillingSystem35靜態(tài)建模[11]－組件組件是可重用的系統(tǒng)片段，具有良好定義接口的物理實現(xiàn)單元。每個組件包含了系統(tǒng)設計中某些類的實現(xiàn)。組件設計的原則：良好的組件不直接依賴于其它組件，而是依賴于其它組件所支持的接口。這樣的好處是系統(tǒng)中的組件可以被支持相同接口的組件所取代。一個組件可能是源代碼、可執(zhí)行程序或動態(tài)庫。Student36靜態(tài)建模[12]－結(jié)點結(jié)點代表系統(tǒng)運行時的物理對象，結(jié)點通常擁有運算能力，它可以容納對象和組件實例。RegistrationDatabaseLibraryDormMainBuilding37靜態(tài)建模[13]－注釋注釋用于解釋設計的思路，便于理解。一個好的模型應該有詳盡的注釋。RepresentsanincorporatedentityCompany…注釋38靜態(tài)建模[14]－關(guān)系－關(guān)聯(lián)關(guān)聯(lián)描述了系統(tǒng)中對象和其它實例之間的離散的連接，關(guān)聯(lián)是有序的，它允許重復，關(guān)聯(lián)的實例是鏈。關(guān)聯(lián)至對象的連接點稱為關(guān)聯(lián)端點，很多信息被附在關(guān)聯(lián)端點上，它擁有角色名、重數(shù)（多少個類的實例可以關(guān)聯(lián)于另一個類的實例），可見性等。關(guān)聯(lián)有自己的名稱，可以擁有自己的屬性，這時關(guān)聯(lián)本身也是類，稱為關(guān)聯(lián)類。39靜態(tài)建模[15]－關(guān)系－關(guān)聯(lián)ManagesJobbossworkeremployeeemployer1..***0..1CompanyPersonJobSalary角色名重數(shù)關(guān)聯(lián)名稱關(guān)聯(lián)類二元關(guān)聯(lián)自關(guān)聯(lián)40靜態(tài)建模[16]－關(guān)系－關(guān)聯(lián)聚集（Aggregation）用來表達整體－部分關(guān)系的關(guān)聯(lián)。組合（Composition）是一種聚集，是關(guān)聯(lián)更強的形式。PolygonPoint13..*pointsContainsPolygonWindowSlider12ScrollbarHeader1Title11Panel1Body聚集組合41靜態(tài)建模[17]－關(guān)系－泛化泛化是一般化和具體化之間的一種關(guān)系。繼承就是一種泛化關(guān)系，更一般化的描述稱為雙親，雙親的雙親稱為祖先，更具體化的描述稱為孩子，在類的范疇，雙親對應超類，孩子對應子類。TreeOakElmBirch孩子雙親PersonStudentGraduate祖先42靜態(tài)建模[18]－關(guān)系－泛化多重繼承：一個孩子可以從多個雙親繼承屬性和方法。多重繼承可能存在沖突，因為被繼承的雙親可能存在相同的類聲明，這時，最好顯式解決沖突問題。AssistantTeacherStudent43靜態(tài)建模[19]－關(guān)系－依賴依賴指明兩個或兩個以上模型元素之間的關(guān)系。依賴有很多種類，比如：實現(xiàn)（realize）、使用、（usage）、實例化（instantiate）、調(diào)用（call），派生（derive）、訪問（access）、引入（import）、友元（friend）等等。<<subsystem>>ApplicationServer<<subsystem>>DataBase<<usage>>依賴類型44靜態(tài)建模[20]－關(guān)系－實現(xiàn)實現(xiàn)是依賴的一種，但由于它具有特殊意義，所以將它獨立講述。實現(xiàn)是連接說明和實現(xiàn)之間的關(guān)系。StringisEqual(String):BooleanHash():Integer…Comparable<<interface>>ComparableisEqual(String):BooleanHash():Integer…實現(xiàn)特殊的實現(xiàn)標記45靜態(tài)建模[21]－關(guān)系－約束約束用來表示各種限制，如關(guān)聯(lián)路徑上的限制，和屬性特征檢測（存在、所有）。PersonCommitteeMember-of約束Chair-of{subset}46靜態(tài)建模[22]－類圖靜態(tài)視圖是UML的基礎，靜態(tài)視圖表示為類圖，主要是描述類和類之間的關(guān)系。繼承關(guān)聯(lián)PersonHouseresidence0..*owner0..*Financial

Institutionclientcreditor0..*0..*Mortgageprincipalrateterm關(guān)聯(lián)類{ordered}0..*1BankTrust

Company47靜態(tài)建模[23]－對象圖對象圖是系統(tǒng)在某一時刻的快照。Smith:Personcottage:Househome:Housefirst:Mortgagesecond:MortgageRoyalBank:Bank鏈48動態(tài)建模[1]狀態(tài)機圖用例圖活動圖順序圖協(xié)作圖49動態(tài)建模[2]－狀態(tài)機圖狀態(tài)機圖是對單個類的對象的生命周期進行建模，描述了對象時間上的動態(tài)行為，每個對象被認為是事件驅(qū)動的孤立實體。狀態(tài)機圖是由狀態(tài)和躍遷組成的圖，通常狀態(tài)機附屬于類，描述類實例對接受事件的響應。事件表達對象間的調(diào)用、顯式信號、值的改變或時間的推移。調(diào)用事件、變更事件、信號事件、時間事件狀態(tài)描述對象生命周期的一段時間，可以是等待其它事件時所處的時間，或是執(zhí)行某一活動時所處的時間，狀態(tài)分為簡單狀態(tài)和復合狀態(tài)。50動態(tài)建模[3]－狀態(tài)機圖躍遷定義對象對某一事件發(fā)生的反應，通常，遷移具有觸發(fā)事件、躍遷條件、動作和目標狀態(tài)。躍遷的種類有外部躍遷和內(nèi)部躍遷。外部躍遷是最普通的躍遷，會發(fā)生狀態(tài)改變；內(nèi)部躍遷不發(fā)生狀態(tài)改變。躍遷有兩個隱式動作：進入動作和退出動作。無論何時進入和退出時都要執(zhí)行，這方便進入時進行初始化工作，退出時進行資源的釋放工作。51動態(tài)建模[4]－狀態(tài)機圖createdreadyHandle

EventInitialize

ObjectTerminate

ObjectWaitfor

Eventstart/^master.ready()poll/^master.ack()stop/初始狀態(tài)結(jié)束狀態(tài)狀態(tài)機狀態(tài)觸發(fā)事件動作表達式躍遷52動態(tài)建模[5]－用例圖用例圖描述各個執(zhí)行者在各個用例中的參與情況，描述系統(tǒng)為用戶所感知的外部視圖。用例圖的功能：捕獲系統(tǒng)用戶需求描述系統(tǒng)邊界指明系統(tǒng)外部行為指導系統(tǒng)開發(fā)者的功能開發(fā)系統(tǒng)建模的起點，指導所有的類圖和交互圖的設計產(chǎn)生測試用例，用戶文檔估計項目大小和進度。53動態(tài)建模[6]－用例圖用例可以參與多種關(guān)系：關(guān)聯(lián)、擴展、泛化和包含。CustomerSalesmanSupplierSupervisorSaleManagementSupply執(zhí)行者用例系統(tǒng)邊界54動態(tài)建模[7]－活動圖活動圖是用狀態(tài)機對工作流進行建模的特殊形式，它和流程圖很類似，不過它支持并發(fā)控制?；顒訄D一般不描述所有的運算細節(jié)，它顯示活動的流，但不顯示執(zhí)行活動的對象?；顒訄D處于系統(tǒng)的外部和內(nèi)部視圖之間，所以它可以作為設計的起點，為了完成設計，每個活動必須擴展成一個和多個操作，每個操作被指派給特定的對象來實現(xiàn)。將商業(yè)組織控制的活動劃分在一起，這類劃分可以通過分隔的區(qū)域來表達，由于它們的外觀，每個區(qū)域稱為泳道（swimlane）。55動態(tài)建模[8]－活動圖CustomerSalesStockroomRequestServicePayTakeOrderFillOrderDeliverOrderCollectOrder泳道56動態(tài)建模[9]－帶有對象流的活動圖CustomerSalesStockroomRequestServicePayTakeOrderFillOrderDeliverOrderCollectOrder泳道Order[Placed]Order[Entered]Order[Filled]Order[Delivered]對象57動態(tài)建模[10]－交互視圖對象行為是通過交互來實現(xiàn)的，交互是對象間為完成某一目的而進行的一系列消息交換。消息是對象間的單向通信，從發(fā)送者到接受者的攜帶信息的控制流。消息可能帶有值參。消息序列可用兩種圖表示：順序圖（重點在消息的時間順序）和協(xié)作圖（重點在交換消息的對象間的關(guān)系）。對協(xié)作圖來說，時間順序可以從順序號獲得。58動態(tài)建模[11]－順序圖順序圖用二維表來表示交互，縱向是時間軸，橫向是參與的角色以及它們交換的消息。角色的生命周期表現(xiàn)為生命線，一條垂直的線，在激活的時間段里是雙線，在狀態(tài)保持的時間里是虛線。消息表示為從一條生命線出發(fā)到另一條生命線的有向線，從上而下，表示消息的時間順序。59動態(tài)建模[12]－順序圖CallerOperatorCallee時間軸callacknumbercallacktalktransfer順序圖生命線激活狀態(tài)保持角色60動態(tài)建模[12]－協(xié)作圖協(xié)作圖包含分類角色和關(guān)聯(lián)角色，當它實例化時，對象被綁定到分類角色，鏈被綁定到關(guān)聯(lián)角色.關(guān)聯(lián)角色還可能被各種暫時性的鏈來充當，如過程參數(shù)和局部過程變量，鏈可以指定暫時性的原型：<<parameter>>、<<local>>或自身調(diào)用<<self>>。協(xié)作圖對實現(xiàn)協(xié)作的對象和鏈進行建模，而忽略其他對象。61動態(tài)建模[13]－協(xié)作圖StudentRegistrationFormRegistrationManager1:fillininfo2:submit3:add(smith,math)math4:add(smith)62動態(tài)建模[14]－協(xié)作圖通常在一個協(xié)作圖中每個對象分配一個符號，然而有時不同狀態(tài)的對象需要顯式指出，流將同一個對象的不同狀態(tài)版本關(guān)系在一起，使用<<become>>原型。流的<<copy>>原型不太常用。:Controller:Directory[closed]:Directory[open]1:expand()2:sort()1.1<<become>>流63物理架構(gòu)[1]實現(xiàn)視圖部署視圖64物理架構(gòu)[2]－實現(xiàn)視圖實現(xiàn)視圖描述可重用的系統(tǒng)組件以及組件之間的依賴。CourseCourseOfferingStudentProfessorCourse.dllPeople.dllCourseUserRegister.exeBilling.exeBillingSystem65物理架構(gòu)[3]－部署視圖部署視圖描述系統(tǒng)資源在運行時的物理分布，系統(tǒng)資源成為結(jié)點。RegistrationDatabaseLibraryDormMainBuilding66建模步驟[1]UML是一種建模語言而不是方法，這是因為UML中沒有過程的概念，而過程正是方法的一個重要組成部分。UML本身獨立于過程，這意味著用戶在使用UML進行建模時，可以選用任何適合的過程。一般采用的建模過程有：瀑布開發(fā)模型、迭代遞增開發(fā)模型。67建模步驟[2]－瀑布開發(fā)模型瀑布開發(fā)模型需求分析與設計編碼測試產(chǎn)品維護68建模步驟[3]－迭代遞增開發(fā)模型迭代遞增開發(fā)模型最初需求與分析設計編碼測試產(chǎn)品維護請求更多需求與分析69建模步驟[4]－UML建模過程基于UML的系統(tǒng)開發(fā)采取增量迭代開發(fā)模型。[1]需求最初需求規(guī)格說明應當由代表系統(tǒng)最終用戶的人員提供，內(nèi)容包括系統(tǒng)基本功能需求和對計算機系統(tǒng)的要求。[2]分析分析的任務是找出系統(tǒng)的所有需求并加以描述，同時建立模型，以定義系統(tǒng)中的關(guān)鍵領(lǐng)域類，應由系統(tǒng)用戶和開發(fā)人員合作完成。分析的第一步是定義用例，以描述所開發(fā)系統(tǒng)的外部功能需求。用例分析包括閱讀和分析需求說明，此時需要與系統(tǒng)的潛在用戶進行討論。70建模步驟[5]－UML建模過程[3]設計設計階段的任務是通過綜合考慮所有的技術(shù)限制，以擴展和細化分析階段的模型。設計階段可以分為兩個部分：結(jié)構(gòu)設計是高層設計，其任務是定義包（子系統(tǒng)），包括包間的依賴性和主要通信機制。我們希望得到盡可能簡單和清晰的結(jié)構(gòu)，各部分之間的依賴盡可能的少，并盡可能的減少雙向的依賴關(guān)系。第二部分是詳細設計，細化包的內(nèi)容，使編程人員得到所有類的一個足夠清晰的描述。71建模步驟[6]－UML建模過程結(jié)構(gòu)設計一個設計良好的系統(tǒng)結(jié)構(gòu)是系統(tǒng)可擴充和可變更的基礎。包實際上是一些類的集合。類圖中包括有助于用戶從技術(shù)邏輯中分離出應用邏輯（領(lǐng)域類），從而減少它們之間的依賴性。詳細設計詳細設計的目的是通過創(chuàng)建新的類圖、狀態(tài)圖和動態(tài)圖（順序圖、協(xié)作圖和活動圖），描述新的技術(shù)類，并擴展和細化分析階段的對象類。72建模步驟[7]－UML建模過程[4]實現(xiàn)構(gòu)造或?qū)崿F(xiàn)階段是對類進行編程的過程。可以選擇某種面向?qū)ο髮ο缶幊陶Z言（如Java）作為實現(xiàn)系統(tǒng)的軟件環(huán)境。Java很容易實現(xiàn)從邏輯視圖到代碼部件的映射，因為類到Java代碼文件之間是一一映射關(guān)系。在實現(xiàn)階段中，可以選取各種圖的說明來輔助編程，比如：類圖，狀態(tài)圖和動態(tài)圖等。73建模步驟[8]－UML建模過程[5]測試和配置完成系統(tǒng)編碼后，需要對系統(tǒng)進行測試，它通常包括：單元測試、集成測試、系統(tǒng)測試和驗收測試。

在單元測試中使用類圖和類的規(guī)格說明，對單獨的類或一組類進行測試；在集成測試中，使用組件圖和合作圖，對各組件的合作情況進行測試；在系統(tǒng)測試中，使用用例圖，以檢驗所開發(fā)的系統(tǒng)是否滿足例圖所描述的需求。系統(tǒng)的配置是實際地交付系統(tǒng)，包括文檔和組成模型等。74Rose的使用[1]ROSE是美國Rational公司的面向?qū)ο蠼９ぞ?，利用這個工具，我們可以建立用UML描述的軟件系統(tǒng)的模型，而且可以自動生成和維護C++、Java、VB、Oracle等語言和系統(tǒng)的代碼。ROSE的界面分為三個部分——Browser窗口、Diagram窗口和Document窗口。Browser窗口用來瀏覽、創(chuàng)建、刪除和修改模型中的模型元素；Diagram窗口用來顯示和創(chuàng)作模型的各種圖；而Document窗口則是用來顯示和書寫各個模型元素的文檔注釋。75R