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

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

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

PeterCoad和

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

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

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

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

EventInitialize

ObjectTerminate

ObjectWaitfor

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

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