了解RUP的基礎(chǔ)知識

RationalOOAD目標了解RUP的基礎(chǔ)知識能夠使用RationalRose能夠進行面向?qū)ο蟮姆治龊驮O(shè)計（OOAD）目錄1.RUP2.OO基礎(chǔ)3.Requirementsoverview4.Analysisanddesignoverview5.Architecturalanalysis6.Use-caseanalysisRUPRUP—RationalUnifiedProcessRUP是一個軟件工程過程（Softwareengineeringprocess)RUP提供了一種在開發(fā)組織內(nèi)分配任務(wù)和責任的紀律性方法。目標是確保按照預(yù)計的進度和預(yù)算，生產(chǎn)出滿足最終用戶需求的高質(zhì)量的軟件。BestPractices迭代式開發(fā)每個迭代是一個完整的過程，要產(chǎn)生可運行的結(jié)果根據(jù)風險決定迭代的次序管理需求使用組件體系結(jié)構(gòu)可視化建模（UML）不斷地驗證質(zhì)量（ContinuouslyVerifyQuality）測試各個方面：功能、可靠性、性能測試每一個迭代管理變更（ManageChange）RUP的四個階段（Phase）Inception定義項目的Scope20%UseCases建立項目的商業(yè)計劃Elaboration制定項目計劃掌握需求（80%）建立體系結(jié)構(gòu)基準Construction通過若干迭代，生成Beta版Transition提交給最終用戶階段、迭代和工作流的關(guān)系2.OO基礎(chǔ)模型（Model）模型是對現(xiàn)實的簡化建模就是獲取系統(tǒng)的關(guān)鍵部分可視化建模就是用標準的圖形表示法來建?？梢暬５暮锰幗y(tǒng)一的模式：用戶、分析員、設(shè)計師和實施員都用一個語言(UML)模型更能反映現(xiàn)實世界更精確的描述實體基于自然劃分的分解容易理解和維護把類組織成更有意義的元素，形成軟件構(gòu)架為不同的人提供不同級別的抽象促進復(fù)用(reuse)可以有一個類復(fù)用、多個類（或一個組件）的復(fù)用、應(yīng)用模式等復(fù)用方式不止是復(fù)用代碼，而是復(fù)用建立原始工件時需要的所有分析、設(shè)計、實現(xiàn)、測試、文檔化可視化建模讓你從復(fù)用的角度看，如果想復(fù)用工件，什么是可用的UMLUML(UnifiedModelingLanguage)是可視化、說明、構(gòu)建和文檔化軟件系統(tǒng)工件的標準語言UML可以做下面的建模數(shù)據(jù)建模業(yè)務(wù)建模對象建模組件建模UML可以用于可視化建模系統(tǒng)與外界的交互系統(tǒng)的行為系統(tǒng)的結(jié)構(gòu)系統(tǒng)的構(gòu)架系統(tǒng)的組件Views模型由不同的view和diagram構(gòu)建而成，描述了不同的視點和系統(tǒng)的構(gòu)建塊View是一個對特定涉眾有意義的模型的視點View是模型的“碎片”Rose中的“4+1view”LogicalView分析師設(shè)計師structureProcessView系統(tǒng)集成員PerformanceScalabilityThroughputImplementationView編程人員SoftwaremanagementUse-caseView最終用戶FunctionalityDeploymentView系統(tǒng)工程SystemtopologyDeliveryinstallationCommunicationViewsUse-caseView是其他view的“心臟”，因為它說明了系統(tǒng)做什么包括用例圖、用例事件流和補充規(guī)約，也可以包括活動圖它說明了塑造系統(tǒng)構(gòu)架需要的精力LogicalView支持系統(tǒng)的功能性需求包括用例實現(xiàn)、類圖和交互圖，也包括狀態(tài)圖和活動圖ProcessView闡述系統(tǒng)的性能、伸縮性和吞吐量包括形成系統(tǒng)并發(fā)和同步機制的線程和進程對于單處理環(huán)境是不必要的ComponentView（implementationView）說明開發(fā)的容易，軟件的管理、復(fù)用、子合同和off-the-shelf組件以分包、分層和配置管理的形式描述了靜態(tài)軟件模型的組織（源碼、數(shù)據(jù)文件、組件、可執(zhí)行體等）DeploymentView說明部署、安裝和性能的主題只用于分布式系統(tǒng)表示如何把各種執(zhí)行體和其他運行時組件映射要下層平臺或計算節(jié)點顯示一個部署對象（Object）對象代表了一個實體，可以是物理的（如一個卡車）、概念的（如一個化學過程）或軟件的（如一個鏈表）對象是一個有定義良好的邊界和標識，并封裝了狀態(tài)（State）和行為（Behavior）的實體狀態(tài)用屬性（attribute）和關(guān)系（relation）表示是對象可以處于的狀況對象的狀態(tài)隨時間變化行為用操作（Operation）、方法（Method）和狀態(tài)機（Statemachine）表示行為決定對象如何動作和做反應(yīng)對象的可見行為用一系列它相應(yīng)的消息來模型化標識（Identity）每個對象有唯一的標識例如，一個名叫JClark的教授的信息如下（她的狀態(tài)是tenured）：Name:JClark EmployeeID：567138(標識)Status:TenuredDiscipline:Finance行為SubmitFinalGrades

AcceptCourseOfferingTakesabbatical面向?qū)ο蟮幕疽?guī)則抽象（abstraction）對象區(qū)別于其他對象的本質(zhì)特征定義與使用者視點相關(guān)的邊界不是具體的表現(xiàn)，而是理想化的本質(zhì)封裝（Encapsulation）對用戶隱藏了實現(xiàn)，用戶只能通過接口與對象通信封裝通常叫“信息隱藏”封裝使對象的狀態(tài)不受用戶的影響，使用戶不受對象實現(xiàn)變化的影響模塊化（Modularity）把復(fù)雜的東西分成可管理的小塊幫助人們理解復(fù)雜的系統(tǒng)層次（Hierarchy）抽象級別的樹狀結(jié)構(gòu)可以分成：聚合（aggregation）層次、類（class）層次、包含（containment）層次、繼承（inheritance）層次、分割（partition）層次、特殊化（specialization）層次、類型（type）層次同一層的元素具有相同的抽象級別類類是對一系列具有相同屬性、操作、關(guān)系和語義的對象的描述對象是類的實例類定義了它的所有對象的結(jié)構(gòu)和行為的模板RequirementsOverviewIntroduction相關(guān)的活動查找主角（Actor）和用例（UseCase）建立用例模型結(jié)構(gòu)詳細說明用例獲取常用詞匯相關(guān)的工件用例模型（UseCaseModel）在Use-caseView中創(chuàng)建包括用例圖（UseCaseDiagram）和用例規(guī)約（UseCaseSpecifications），也可以包括活動圖用用例和主角描述系統(tǒng)的功能性需求的模型用例模型最主要的功能是和客戶/最終用戶交流系統(tǒng)的行為（behavior）是顧客和開發(fā)者之間的契約對于分析、設(shè)計和測試活動都是至關(guān)重要的補充規(guī)約（SupplementarySpecification）非功能性需求詞匯表（Glossary）角色：系統(tǒng)分析員Actor&UsecaseActor定義：與系統(tǒng)進行交互的人或事物種類人外部系統(tǒng)外部設(shè)備或TimerUsecase定義：是actor與系統(tǒng)的一系列交互特點：完成actor的某個目的（不是功能）起始于actor的輸入

其中，系統(tǒng)是一個黑盒用于描述系統(tǒng)行為，但不描述如何實現(xiàn)Usecasediagram表示usecase與actor之間以及usecase之間的關(guān)系Usecasemodeling步驟初始化用例模型在“UseCaseView”中建立一個“UseCaseModel”包在“UsecaseModel”下建立“Actors”和“UseCases”包識別Actor根據(jù)Actor的定義識別Actor把識別的actor放到“Actors”包中識別Usecase根據(jù)Usecase的定義和特點，識別Usecase為每個usecase建立一個包，名字與那個usecase的名字相同，并在每個usecase的包下面加入相應(yīng)的usecase畫用例圖在“UseCaseModel”下面新建一個用例圖，其中表示出actor和usecase以及usecase之間的關(guān)系為每個usecase寫用例規(guī)約（Usecasespecification）更新詞匯表編寫補充規(guī)約用例規(guī)約用例名字（Name）簡要說明（Briefdescription）事件流（FlowsofEvents）系統(tǒng)對于某個用例做了什么的文本描述要被客戶理解描述了用例何時以及如何開始和結(jié)束，用例何時與主角交互以及主角與用例之間的信息交換不描述用戶界面的細節(jié)包括：基本流（Basicflow）：成功的流，又叫happyflow備選流（Alternationflow）特殊需求（Specialrequirements）前置條件（Pre-conditions）后置條件（Post-conditions）擴展點（Extensionpoints）其他場景（Scenarios）場景是用例的一個實例活動圖可以用活動圖描述用例的事件流可以用包（Package）把用例組織起來Usecase之間的關(guān)系有ExtendIncludeGeneralizationUsecasesRelationships--Extend作用表示基本用例（Baseusecase）的有條件的部分，只在某些環(huán)境下執(zhí)行模型化復(fù)雜的或可選的路徑。

擴展用例（Extensionusecase）&基本用例擴展用例只有在基本用例中的某種條件滿足時才能執(zhí)行，如果沒有基本用例，擴展用例不能運行擴展用例可以擴展多個基本用例基本用例的basicflow執(zhí)行時,擴展用例不一定執(zhí)行

擴展點表示UsecasesRelationships--Include反映了多個用例的共同點抽象用例和具體用例抽象用例不能單獨執(zhí)行，必須與包括（也就是執(zhí)行）它的具體用例一起執(zhí)行抽象用例沒有特定的actor，它的actor實際上包括它的具體用例的actor抽象用例可以被幾個其他的用例復(fù)用

具體用例的基本流執(zhí)行時，抽象用例一定執(zhí)行表示Concreteabstract<<include>>檢查點（1）需求：用例模型用例模型可以理解嗎？通過研究用例模型，能形成對系統(tǒng)功能和它們之間的聯(lián)系的清晰理解嗎？滿足了所有的功能需求嗎？用例模型中有多余的行為嗎？模型到包的分解合適嗎？需求：Actor識別了所有的actor嗎？每個actor至少參與了一個用例嗎？每個actor確實是一個角色(role)嗎？是否應(yīng)該合并或分解？是否有兩個actor在一個用例中扮演相同的角色？Actor是否有直觀的、描述性的名字？用戶和客戶是否能理解這些名字？需求：詞匯表每個術(shù)語都有清晰、簡練的定義嗎？每個術(shù)語都包含在用例描述中嗎？屬于在actor和用例的簡單描述中是一致的嗎？檢查點（2）需求：用例每個用例中至少有一個actor嗎？每個用例都獨立于其他用例嗎？如果兩個用例總是以同樣的順序執(zhí)行，也許應(yīng)該合并成一個有具有非常類似的行為或事件流程的用例嗎？為了以后不會混淆，用例具有唯一的、直觀的、說明性的名字嗎？客戶和用戶能理解用例的名字和描述嗎？需求：用例規(guī)約誰要執(zhí)行用例明確嗎？用例的目的明確嗎？簡單的描述刻畫了用例的真實情況嗎？用例的時間流程何時/如何開始/結(jié)束明確嗎？Actor和用例的通信順序符合用戶的期望嗎？Actor的交互和信息交換清晰嗎？是否有過于復(fù)雜的用例？ArchitectureAnalysisArchitectureAnalysisOverview（1）基本構(gòu)架分析時定義系統(tǒng)pieces/parts及其之間關(guān)系的最初的嘗試，這時需要把pieces/parts組織成有明顯依賴的定義良好的layers，關(guān)注的是系統(tǒng)的上層layers。構(gòu)架分析是構(gòu)架設(shè)計師決定如何進行分析的時候，大部分精力用于對分析模式和習慣達成共識，以便分析工作不用在“firstprinciple”上花費太多時間。目的根據(jù)從相似系統(tǒng)或相似問題領(lǐng)域中獲取的經(jīng)驗，定義備選構(gòu)架。定義系統(tǒng)的體系結(jié)構(gòu)模式、關(guān)鍵機制和建模方式定義重用策略為策劃提供輸入在下列情況下，這個工作可以不做：系統(tǒng)體系結(jié)構(gòu)的風險低沒有具有相關(guān)領(lǐng)域的有經(jīng)驗的構(gòu)架設(shè)計師ArchitectureAnalysisOverview（2）輸入用例模型補充規(guī)約詞匯表業(yè)務(wù)模型軟件構(gòu)架文檔設(shè)計模型設(shè)計指南輸出更新的軟件構(gòu)架文檔更新的設(shè)計模型更新的設(shè)計指南用例實現(xiàn)(只是識別出來，但沒有開發(fā))步驟開發(fā)構(gòu)架概述調(diào)查可用資產(chǎn)

定義子系統(tǒng)的高層組織確定分析機制確定核心的抽象概念創(chuàng)建用例實現(xiàn)開發(fā)高層部署模型評審結(jié)果角色：構(gòu)架設(shè)計師Step1:開發(fā)構(gòu)架概述目的：通過研究和評估高層構(gòu)架選項來簡化有關(guān)系統(tǒng)的預(yù)先設(shè)想

將有關(guān)既定系統(tǒng)高層結(jié)構(gòu)的初步理念傳遞給資助人、開發(fā)團隊和其他涉眾在項目的初期、甚至是在項目的提議階段編寫內(nèi)容：反映有關(guān)實現(xiàn)項目前景的初期決策和可行的假設(shè)，以及與系統(tǒng)的物理和邏輯結(jié)構(gòu)、非功能性需求有關(guān)的決策構(gòu)架設(shè)計師將收集有關(guān)當前環(huán)境的信息，并將它們記錄在部署模型中，如電子商務(wù)系統(tǒng)中可能會了解：現(xiàn)有網(wǎng)絡(luò)的邏輯設(shè)計和物理設(shè)計現(xiàn)有數(shù)據(jù)庫和數(shù)據(jù)庫的設(shè)計現(xiàn)有的Web環(huán)境（服務(wù)器、防火墻等等）現(xiàn)有的服務(wù)器環(huán)境（配置、軟件版本和預(yù)計的升級）現(xiàn)有標準（網(wǎng)絡(luò)、命名和協(xié)議等等）構(gòu)架概述的作用：溝通工具Step2：調(diào)查可用資產(chǎn)

目的確定與項目有關(guān)的資產(chǎn)。分析資產(chǎn)和項目需求之間的一致程度與偏差程度。決定是否采用資產(chǎn)作為某些系統(tǒng)領(lǐng)域的基礎(chǔ)。確定并列出項目中可以復(fù)用的潛在資產(chǎn)。進行初步評估，確?？梢垣@取必要的支持Step3:定義子系統(tǒng)的高層組織(1)模式（Pattern）&框架（Framework）模式通用問題在特定情況下的通用解決方法分析/設(shè)計模式小范圍技術(shù)問題的解決方法解決方法的片斷框架定義解決問題的通用方法骨架的解決方法，它的細節(jié)是分析/設(shè)計pattern設(shè)計模式描述了通用設(shè)計問題描述了問題的解決方案討論應(yīng)用模式的結(jié)果和策略構(gòu)架模式（Architecturepattern）構(gòu)架模式代表了軟件系統(tǒng)的基本機構(gòu)的組織模式，提供了一系列預(yù)定義的子系統(tǒng)，闡述了子系統(tǒng)的責任，還包括組織子系統(tǒng)之間關(guān)系的規(guī)則和指南。Step3:定義子系統(tǒng)的高層組織(2)幾種典型的構(gòu)架模式Layers：應(yīng)用被分成不同層次的抽象，從上面的應(yīng)用層到下面的實現(xiàn)/技術(shù)層Model-view-controller(MVC)：應(yīng)用被分成3部分：作為業(yè)務(wù)規(guī)則和底層數(shù)據(jù)的Model、把信息顯示給用戶的View和處理用戶輸入的Controller。Pipesandfilters：數(shù)據(jù)在流中處理，流通過pipe從filter流向filter，filter是處理步驟Blackboard：獨立的特定應(yīng)用通過處理相同的數(shù)據(jù)結(jié)構(gòu)，相互協(xié)作以解決問題ArchitecturalLayers的模型化用stereotypedpackage，如<<layer>>stereotype課程注冊系統(tǒng)決定采用Layers型的構(gòu)架（Demo）包之間的關(guān)系(dependency)對supplier包的修改會影響client包Client包不能獨立地被重用因為它要依賴于supplier包避免依賴關(guān)系形成回路合并包拆分包Step4:識別分析機制—構(gòu)架機制構(gòu)架機制關(guān)于通用標準、方針、管理的策略，是項目中應(yīng)該標準化的問題的實現(xiàn)，每個人都應(yīng)該以相同的方式使用這些概念，復(fù)用同樣的機制來執(zhí)行操作代表了經(jīng)常遇到的問題的通用解決方案，可以是結(jié)構(gòu)模式、行為模型或兩者都是。構(gòu)架機制是系統(tǒng)的需求和如何實現(xiàn)的‘glue’的重要部分，提供了對實現(xiàn)環(huán)境的限制。由構(gòu)架設(shè)計師來管理構(gòu)架機制選擇構(gòu)架機制、通過集成它們來驗證有效性、證實它們確實能工作、把它們用于其他的系統(tǒng)設(shè)計種類Analysismechanism(conceptual)：例如：distributionDesignmechanism(concrete)：例如：RMIImplementmechanism(actual)：例如：Java1.1Step4:識別分析機制—分析機制基本：分析機制關(guān)注的是系統(tǒng)的非功能性需求，建立對非功能性需求的支持通過向設(shè)計師提供復(fù)雜行為的簡單描述來減少分析的復(fù)雜性，增強一致性分析機制被用作復(fù)雜行為在構(gòu)架的中間或更低層的‘placeholder’，通常與具體的問題域無關(guān)，而是計算機科學的概念例子PersistencyCommunication(IPCandRPC)MessageroutingDistributionProcesscontrolandsynchronizationInformationexchange,formatconversionSecurityErrordetection/handling/reportingRedundancyLegacyinterfaceStep4:識別分析機制—分析機制特征Consistency例子粒度（Granularity)：需要保存的對象大小的范圍。容量(Volume)：需要保存的對象的數(shù)量。持續(xù)時間(Duration)：通常對象保留時間。訪問機制：如何唯一地標識并訪問給定對象？訪問頻率：對象是否大致保持恒定不變？它們是否經(jīng)常更新？可靠性（reliability)：對象是否應(yīng)當在進程、處理器或者整個系統(tǒng)崩潰后繼續(xù)存在？進程間通信機制延時（latency）：進程間通信有多快同步（synchronicity)：消息大小協(xié)議、流控制、緩沖等遺留接口機制延時（latency）：有多快持續(xù)時間(Duration)：通常對象保留時間訪問機制：如何唯一地標識并訪問給定對象？訪問頻率：對象是否大致保持恒定不變？它們是否經(jīng)常更新？安全機制數(shù)據(jù)粒度：package-level,class-level,attribute-level

用戶粒度：singleuses,roles/groups

安全規(guī)則：基于數(shù)據(jù)值、基于數(shù)據(jù)的算法、基于用戶和數(shù)據(jù)的算法權(quán)限類型：讀、寫、創(chuàng)建、刪除或其他操作Step4:識別分析機制識別分析機制的過程列出所有的分析機制繪制客戶類到分析機制的映射圖識別分析機制的特征Modelusingcollaborations課程注冊系統(tǒng)的分析機制Persistence分布安全遺留接口Step5:識別關(guān)鍵抽象(Keyabstraction)基礎(chǔ)關(guān)鍵抽象是通常在需求中揭示，系統(tǒng)必須處理的概念關(guān)鍵抽象的來源領(lǐng)域的知識需求GlossaryDomainmodel或businessmodel定義關(guān)鍵抽象定義分析類關(guān)系用類圖模型化分析類及其關(guān)系把分析類向分析機制映射關(guān)鍵抽象的例子（課程注冊系統(tǒng)）ProfessorStudentScheduleCourseCatalogCourseOfferingCourse檢查點GeneralIsthepackagepartitioningandlayeringdoneinalogicallyconsistentway?識別了必要的分析機制嗎？包Haveweprovidedacomprehensivepictureoftheservicesofthepackagesinupper-levellayers?類對關(guān)鍵的實體類及其之間的關(guān)系進行識別和準確的建模了嗎？每個類的名字清晰地反映了它承擔的角色嗎？關(guān)鍵抽象/類及其之間的關(guān)系和商業(yè)模型、領(lǐng)域模型、需求、詞匯表一致嗎？UseCaseAnalysis概要目的找出完成usecase需要的類把usecase的行為分配到類中識別類的責任、屬性和關(guān)聯(lián)標記構(gòu)架機制的使用輸入詞匯表補充規(guī)約用例建模指南用例模型用例實現(xiàn)（只是識別，沒有開發(fā)）軟件構(gòu)架文檔輸出分析類分析模型和/或設(shè)計模型開發(fā)后的用例實現(xiàn)概要用例實現(xiàn)對用例模型中的每個用例，在設(shè)計模型中都有相應(yīng)的實現(xiàn)提供從分析和設(shè)計到需求的可跟蹤性用例實現(xiàn)結(jié)構(gòu)用例實現(xiàn)包是組織用例的類和交互圖的方式每個用例都對應(yīng)一個用例實現(xiàn)包可跟蹤性圖交互圖時序圖（SequenceDiagrams）（動態(tài)）協(xié)作圖（CollaborationDiagrams）（動態(tài)）類圖（ClassDiagrams）（靜態(tài)）用例分析的步驟補充用例描述對每個用例實現(xiàn)從用例行為中找出類把用例行為分配到類對每個分析類描述屬性和關(guān)聯(lián)描述責任限定分析機制（analysismechanism）確定屬性建立分析類之間的關(guān)聯(lián)關(guān)系說明分析類之間的事件依賴關(guān)系整合分析類Step1:補充用例描述用例的描述往往不夠查找分析類用戶通常不關(guān)心系統(tǒng)內(nèi)部的信息，所以開始時的用例描述是黑盒的為了發(fā)現(xiàn)分析類，需要從系統(tǒng)內(nèi)部的視點對用例進行白盒描述例如：課程注冊系統(tǒng)中，學生可能喜歡說“系統(tǒng)顯示課程列表”，但是這不能說明系統(tǒng)內(nèi)部是如何實現(xiàn)的。為了給出系統(tǒng)內(nèi)部是如何工作的，我們要加入:系統(tǒng)從課程目錄遺留數(shù)據(jù)庫中取得課程列表Step2:從用例行為中找出類--分析類邊界類(boundaryclass)是接口與系統(tǒng)外部某些事物的媒介分類用戶接口類系統(tǒng)接口類設(shè)備接口類對象的生命周期與usecase的實例相同控制類(controlclass)用例行為的協(xié)調(diào)者有的用例沒有控制類，復(fù)雜的用例可以有多個控制類控制類會提供以下行為：與周圍環(huán)境無關(guān)定義控制邏輯（event的順序）和usecase事務(wù)如果實體類的內(nèi)部結(jié)構(gòu)或行為變化，控制類很少會變化使用或設(shè)定幾個實體類的內(nèi)容，因此需要協(xié)調(diào)這幾個實體類的行為每次被激活，行為方式不同（flowofevent與多個狀態(tài)有關(guān)）Step2:從用例行為中找出類--分析類實體類(entityclass)系統(tǒng)的關(guān)鍵抽象主要責任是用于保存和管理系統(tǒng)的信息，如一個event，一個人或一些實際存在的對象的信息。通常是持久化的(persistent)通常不特定于某個usecaserealization，有時甚至不特定于系統(tǒng)。分析類的角色Step2:從用例行為中找出類--方法邊界類最初識別時，每對actor/usecase對應(yīng)一個邊界類控制類建議在初始識別時每個用例對應(yīng)一個控制類實體類(entityclass)來源詞匯表（需求階段）Business-domainModel（業(yè)務(wù)建模階段）Usecaseflowofevents（需求階段）Keyabstractions（構(gòu)架分析中識別）Actor的信息可以作為一個實體類用過濾名詞方法尋找實體類在Usecaseflowofevents中畫出名詞去掉重復(fù)的候選去掉含糊的候選去掉actor去掉實現(xiàn)結(jié)構(gòu)去掉屬性去掉操作Step3:把用例行為分配到類指南：把責任分配到類邊界類和actor交互的行為實體類與數(shù)據(jù)抽象封裝有關(guān)的行為控制類特定到一個usecase或一部分非常重要的事件流程的行為動態(tài)建模：用時序圖和協(xié)作圖來描述用例行為注意：對所有基本流和備選流都要進行分析時序圖時序圖表示如何一步步的完成系統(tǒng)的一個功能時序圖是用于決定類責任和接口的主要信息來源時序圖描述了對象間的交互模式通過對象的“生命線”和他們相互發(fā)送的消息來顯示對象時序圖與協(xié)作圖在語義上是相同的，只是時序圖中的消息是按時間順序分布的時序圖表示的是一個場景(scenario)組成主角對象消息生命線Focusofcontrol表示對象直接或通過子過程執(zhí)行動作的一段時間協(xié)作圖協(xié)作圖顯示對象之間的交互協(xié)作圖強調(diào)參與交互的對象的組織適合分析活動，適合表示少數(shù)對象的簡單交互組成主角對象LinksLink是對象通信的途徑消息類之間的關(guān)系A(chǔ)ssociationconnection類的關(guān)聯(lián)表示的是對象之間的關(guān)系A(chǔ)ggregation&CompositionIsapart-ofComposition與aggregation