UML系統分析與設計SystemAnalysis&Design第一章緒論統一建模語言UMLRational統一過程RUP工具UML系統分析與設計第2版2UML系統分析與設計第2版3UML的背景1989年到1994年，面向對象建模語言從不到10種增加到了50多種。不同的建模語言具有不同的建模符號體系，妨礙了軟件設計人員、開發人員和用戶之間的交流。有必要建立一個標準的、統一的建模語言。統一建模語言UML的誕生結束了符號方面的“方法大戰”。UML統一了Booch方法、OMT方法、OOSE方法的符號體系，采納了其他面向對象方法關于符號方面的許多好的概念。UML系統分析與設計第2版4UML的發展1989年到1994年，面向對象建模語言從不到10種增加到了50多種。不同的建模語言具有不同的建模符號體系，妨礙了軟件設計人員、開發人員和用戶之間的交流。有必要建立一個標準的、統一的建模語言。統一建模語言UML的誕生結束了符號方面的“方法大戰”。UML統一了Booch方法、OMT方法、OOSE方法的符號體系，采納了其他面向對象方法關于符號方面的許多好的概念。UML系統分析與設計第2版5UML的發展UML的建立開始于1994年10月。定義UML1.0時，DEC、HP、I-Logix、IntelliCorp、IBM、ICON計算（ICONComputing）、MCISystemhouse、Microsoft、Oracle、Rational、Texas儀器（TexasInstrumnets）、Unisys等公司都參與了該項工作。UML1.0定義完整、富于表達、功能強大，于1997年1月被提交給OMG（ObjectManagementGroup，對象管理組織），申請成為標準建模語言。2005年，UML2.0被OMG采納，UML2.0對UML1.x進行了很多重大修改。UML系統分析與設計第2版6UML的內容UML定義包括：UML語義描述了基于UML的精確元模型定義。UML表示法定義了UML符號的表示方法，為開發者或開發工具使用這些圖形符號和文本語法為系統建模提供了標準。UML主要特點UML統一了Booch、OMT、OOSE和其他面向對象方法的基本概念和符號。UML系統分析與設計第2版7UML是一種建模語言，而不是一種方法。UML的功能為軟件系統的產物建立可視化模型。UML是一個標準的、被廣泛采用的建模語言，用UML建模有利于交流。UML為系統建立了圖形化的可視模型，使系統的結構變得直觀，易于理解。UML為軟件系統建立模型不但有利于交流，還有利于對軟件的維護。規約軟件系統的產物。規約（Specifying）意味著建立的模型是準確的、無歧義的、完整的。UML定義了在開發軟件系統過程中所做的所有重要的分析、設計和實現決策的規格說明。UML系統分析與設計第2版8UML的功能構造軟件系統的產物。UML不是可視化的編程語言，但它的模型可以直接對應到各種各樣的編程語言。前向工程:從UML模型生成編程語言代碼的過程。逆向工程:從代碼實現生成UML模型的過程。為軟件系統的產物建立文檔。UML可以為系統的體系結構及其所有細節建立文檔。UML還可以為需求、測試、項目規劃活動和軟件發布管理活動建模UML系統分析與設計第2版9UML的組成元素結構元素行為元素分組元素注釋元素UML系統分析與設計第2版10圖結構建模圖類圖、對象圖、組件圖、組合結構圖、包圖和部署圖行為建模圖用例圖、活動圖、狀態機圖、順序圖、通信圖、定時圖和交互概覽圖關系依賴關系關聯關系類屬關系實現關系Rational統一過程RUPRUP的發展UML系統分析與設計第2版11Rational統一過程RUP什么是RUP？RUP是一個軟件工程化過程。它提供了在開發機構中分派任務和責任的方法，它的目標是在可預見的日程和預算前提下確保滿足最終用戶需求的高質量軟件的產生。UML系統分析與設計第2版12Rational統一過程RUPRUP吸收的最佳工程實踐經驗：迭代地開發軟件需求管理使用基于組件的體系結構可視化的軟件建模驗證軟件質量控制軟件的變化UML系統分析與設計第2版13RUPRUP過程可以用二維結構（或兩個軸）來描述UML系統分析與設計第2版14RUP時間軸RUP將軟件生命周期劃分為四個連續的階段：初始階段（Inception）細化階段（Elaboration）構造階段（Construction）交付階段（Transition）UML系統分析與設計第2版15工具市場上大量商業的或開源的UML計算機輔助軟件工程工具：RationalSoftwareModelerVisualParadigmforUMLProsaUMLVisioTogetherVisualUMLObjectDomainUMLMagicDrawUML等，UML系統分析與設計第2版16工具大部分CASE工具都給軟件開發者提供了一整套的可視化建模工具，包括系統建模、模型集成、軟件系統測試、軟件文檔的生成、從模型生成代碼的前向工程、從代碼生成模型的逆向工程、軟件開發的項目管理、團隊開發管理等，為關于客戶＼服務器、分布式、實時系統環境等的真正的商業需求，提供了穩健的、有效的解決方案。UML系統分析與設計第2版17小結UML是定義良好、易于表達、功能強大的語言不僅支持面向對象的分析與設計，而且支持從需求分析開始的軟件開發的全過程。UML系統分析與設計第2版18UML系統分析與設計SystemAnalysis&Design

第二章面向對象分析與設計方法OOA／OOD方法OMT方法Booch方法OOSE方法Fusion方法UML系統分析與設計第2版ZhenyanJi20面向對象分析與設計方法20世紀90年代，一批新的面向對象的方法出現了，其中最引人注目的是Booch方法、OOSE方法和OMT方法等GrandyBooch是面向對象方法最早的倡導者之一，他提出了面向對象軟件工程的概念Rumbaugh等人采用了面向對象的概念，引入各種獨立于語言的表示符，用對象模型、動態模型和功能模型來共同完成對整個系統的建模UML系統分析與設計第2版ZhenyanJi21OOA/OOD方法OOA/OOD（Object-OrientedAnalysis/Object-OrientedDesign，面向對象分析/面向對象設計）方法是由Coad和Yourdon于1991年提出來的。與傳統分析方法相比，OOA／OOD方法的優勢：可以處理更有挑戰性的問題域。改善了分析人員與問題領域專家的交流。通過分析、設計和編程增加內部的一致性。顯式地表示類和對象間的共性。可以建立有彈性的規范。OOA（面向對象分析）、OOD（面向對象開發）和OOP（面向對象編程）的結果可重用。為分析、設計和編程提供一致的基本表示。UML系統分析與設計第2版ZhenyanJi22OOA/OOD方法在分析階段建立的OOA模型由5層組成：主題層（ASubjectLayer） 類和對象層（AClass&ObjectLayer）結構層（AStructureLayer）屬性層（AnAttributeLayer）服務層（AServiceLayer）OOD部分為上述五層添加了4個不同的組件：人機交互組件（HumanInteractionComponent）問題域組件（ProblemDomainComponent）任務管理組件（TaskManagementComponent）數據管理組件（DataManagementComponent）UML系統分析與設計第2版ZhenyanJi23OOA/OOD方法OOD階段擴充了OOA階段創建的5層，將OOA階段產生的結果在OOD階段放入組件中，如圖所示。UML系統分析與設計第2版ZhenyanJi24OOAOOA的過程如下：1．識別問題域中的類和對象在這個步驟中，分析人員通過對問題域深入地分析和理解，識別出組成系統核心的、相關的、穩定的類和對象。識別類和對象的第1步是研究問題域，可以通過審視下列選項來發現可能的類和對象。?結構。 ?其他系統。?設備。 ?被記住的事情或事件。?所扮演的角色。 ?操作的程序。?地點（物理位置）。 ?有組織的單元。UML系統分析與設計第2版ZhenyanJi25OOA2．確定結構結構可以分為兩種，即“一般－特殊”結構（Gen-SpecStructures）和“整體－部分”結構（Whole-PartStructures）。在找出“一般－特殊”結構和“整體－部分”結構后，就可以識別出多重結構，因為多重結構是“一般－特殊”結構和“整體－部分”結構的各種組合。識別出多重結構后，將結構添加到OOA圖中。UML系統分析與設計第2版ZhenyanJi26OOA3．確定主題在這個步驟中，將模型分解為更易管理和理解的主題域，可降低所產生模型的復雜性。4．定義屬性在識別出屬性后，就可以識別出對象間的實例連接（InstanceConnections）。首先對識別出的屬性和實例連接進行檢查，然后規定其屬性，最后將屬性和實例連接添加到OOA圖中。UML系統分析與設計第2版ZhenyanJi27OOA5．定義服務在識別出服務后，可以識別出消息連接（MessageConnections），然后規定服務，并將服務和消息連接添加到OOA圖中。6．準備文檔OOA部分的最后一步是整理OOA文檔。主要文檔包括：完整的OOA圖。類和對象的規格定義。UML系統分析與設計第2版ZhenyanJi28OODOOD的過程如下：1．設計問題域組件設計問題域組件的步驟如下：尋找可以被重用的、以前的設計和類。添加根類，并將特定于問題域的類分組。抽象出公共服務，建立并添加父類。改變問題域模型以改善性能。審查添加到OOA模型中的細節。UML系統分析與設計第2版ZhenyanJi29OOD2．設計人機交互組件設計人機交互組件需要使用原型開發。在完成原型開發后，通過原型來檢查人機交互組件是否滿足下述標準。人機交互作用的一致性。操作步驟的最少化。及時地給予用戶有意義的反饋。提供撤銷功能。不要依賴用戶的記憶力去記住某些東西。掌握軟件所花費的學習時間盡量少。對用戶來說，軟件的樂趣和吸引力也是很重要的。UML系統分析與設計第2版ZhenyanJi30OOD3．設計任務管理組件首先，需要確定系統是否需要任務。如果不需要，就不必設計任務，因為任務會增加系統的復雜性。任務可以分為以下4種：由事件觸發的事件驅動任務（Event-DrivenTasks）。由特定的時間間隔觸發的時鐘驅動任務（Clock-DrivenTasks）。優先級任務（PriorityTasks）。關鍵任務（CriticalTasks）。UML系統分析與設計第2版ZhenyanJi31OOD4．設計數據管理組件首先，要確定數據管理的途徑，即采用平面文件（FlatFile）、關系型數據庫管理系統（RelationalDatabaseManagementSystem）還是面向對象數據庫管理系統（Object-OrientedDatabaseManagementSystem）。其次，根據所選途徑，應用一系列標準進行評價并選擇可能的數據管理工具。最后，根據所選的途徑和工具設計數據管理組件，包括設計數據格式和相應的方法。UML系統分析與設計第2版ZhenyanJi32OMT方法對象模型技術（ObjectModelingTechnique，OMT）是由Rumbaugh等提出的，是一種現今非常流行的面向對象開發技術。其目的是構造一系列模型，并用這些模型不斷地對系統設計進行細化，直到找到最后適合實現的模型。UML系統分析與設計第2版ZhenyanJi33OMT方法使用OMT方法的面向對象開發過程可分為5步，如圖所示。UML系統分析與設計第2版ZhenyanJi34（1）分析。分析問題域并進行建模。（2）系統設計。設計系統的整體體系結構。（3）對象設計。為了有效地實現系統，對對象結構進行細化，并為對象添加細節。（4）編碼。用目標編程語言實現對象和類。（5）測試。驗證系統是否正確。OMT方法—分析分析過程可分為下述5個步驟：1．編寫問題陳述（ProblemStatement）構造分析模型是從為問題域編寫問題陳述開始的。2．建立對象模型（ObjectModel）建立對象模型的步驟如下：（1）識別出類和對象。（2）丟棄不必要和不正確的類。（3）準備數據詞典。（4）識別出類之間的關聯關系。（5）丟棄不必要的和不正確的關聯。UML系統分析與設計第2版ZhenyanJi35OMT方法—分析建立對象模型的步驟如下：（接上頁）（6）抽象出類和對象的屬性。（7）丟棄不必要或不正確的屬性。（8）使用繼承關系來建立類之間的層次關系。（9）遍歷訪問路徑，找出不足。3．建立動態模型（DynamicModel）動態模型主要描述了隨著時間的變化而變化的對象及對象間的關系，動態模型對于具有重要動態行為的系統（例如，交互式系統和實時系統）尤其重要。動態模型描述了系統的可能控制流，而對象模型描述了可能的信息流。UML系統分析與設計第2版ZhenyanJi36OMT方法—分析4．建立功能模型（FunctionalModel）功能模型完全由數據流圖和約束組成，而數據流圖由過程、數據流、參與者和數據存儲組成。其中，一個過程將輸入數據值轉變為輸出數據值。5．細化對象模型、動態模型和功能模型，并建立文檔當分析完成后，要驗證分析模型是否滿足系統最初的需求，這個活動需要該問題領域的專家參與，以檢驗產生的分析模型。UML系統分析與設計第2版ZhenyanJi37OMT方法—系統設計在系統設計階段，主要確定系統的高層次結構。在系統設計階段，需要做出如下決策：1．將系統劃分為子系統對于每個子系統，都必須建立該子系統與其他子系統之間的定義良好的接口，接口的建立使得不同子系統的設計可以獨立進行。如果必要，還可以不斷地將子系統進一步分解為更小的子系統，直到將子系統分解為模塊。UML系統分析與設計第2版ZhenyanJi38OMT方法—系統設計2．識別并發首先要識別出系統固有的并發，可以通過分析狀態圖來完成這個任務。為了定義并發任務，需要檢查系統中不同的、可能的控制線程，并將這幾個控制線程合并為一個。3．將子系統和任務分配給處理器將子系統分配給處理器是從估計所需要的硬件資源開始的，同時設計者還必須決策哪個子系統由硬件實現，哪個子系統由軟件實現。UML系統分析與設計第2版ZhenyanJi39OMT方法—系統設計4．選擇實現數據存儲的策略在設計的這個階段，必須完成關于數據庫的決策，即決定是使用文件還是數據庫管理系統存儲數據。5．識別出全局資源，并確定控制訪問全局資源的機制必須明確定義對全局資源（如物理單元、邏輯名和共享數據等）的使用和訪問。UML系統分析與設計第2版ZhenyanJi40OMT方法—系統設計6．選擇實現軟件控制的方法用軟件實現控制又分為外部控制和內部控制兩種。外部控制（ExternalControl）是系統中對象間的外部可見的事件流。內部控制（InternalControl）是進程內的控制流，可以被看作是程序語言中的過程調用。7．考慮邊界條件描述各種邊界條件也是很重要的，包括如下內容：?系統的初始化。

?系統的結束。?系統的失敗。UML系統分析與設計第2版ZhenyanJi41OMT方法—系統設計8．建立折中的優先級系統的所有目標并不是都可以達到，所以要分析系統的所有目標，然后進行折中，為不同的目標設置不同的優先級。UML系統分析與設計第2版ZhenyanJi42OMT方法—對象設計在對象設計（ObjectDesign）階段，要對類、關聯、屬性和操作進行充分、詳細的規定。對象設計的步驟如下：1．對象模型可以從其他模型獲取操作對于獲得對象模型的操作，必須結合3個模型，為功能模型中的每個過程和動態模型中的每個事件定義操作。UML系統分析與設計第2版ZhenyanJi43OMT方法—對象設計2．設計算法實現操作步驟如下：（1）選擇使實現操作的代價最小的算法。（2）選擇適合該算法的數據結構。（3）如果必要，定義新的內部類和操作。（4）將沒有明確與某個類相關的操作分配給正確的類。3．優化訪問數據的路徑UML系統分析與設計第2版ZhenyanJi44OMT方法—對象設計4．控制的實現使用系統設計階段選擇的策略實現狀態圖。5．調整類結構，并增加繼承6．設計關聯的實現首先要分析怎樣使用關聯，然后確定關聯的實現策略。7．確定對象屬性的準確表達8．用模塊封裝類和關聯UML系統分析與設計第2版ZhenyanJi45OMT方法—實現實現（Implementation）是將設計模型轉變為代碼的過程。由于較困難的決策都已在設計階段完成，所以將設計模型轉變為代碼的實現是直接的、簡單的。UML系統分析與設計第2版ZhenyanJi46OMT方法—測試測試（Testing）用來驗證系統是否被正確實現。在分析和設計階段也部分涉及實現和測試活動，也就是說，分析、設計、實現和測試在增量式的開發中是交錯進行的活動。測試可能會在不同的層次上進行，例如，可以有單元測試、集成測試和系統測試。UML系統分析與設計第2版ZhenyanJi47OMT方法—模型OMT方法通過3個模型——對象模型、動態模型和功能模型來可視化地定義一個系統。1．對象模型（ObjectModel）對象模型描述了系統的靜態結構，還描述了系統中的類以及類間的關系、類的屬性和操作。2．動態模型（DynamicModel）動態模型描述了系統的主要行為，它主要描述了問題域中發生了什么、什么時候發生的以及有什么結果。3．功能模型（FunctionalModel）功能模型描述了如何實現系統功能。UML系統分析與設計第2版ZhenyanJi48Booch方法UML系統分析與設計第2版ZhenyanJi49Booch方法是最早被承認的面向對象設計方法之一。提出了面向對象開發的4個模型描述邏輯結構的邏輯模型（LogicalModel）描述物理結構的物理模型（PhysicalModel）描述靜態語義的靜態模型（StaticModel）描述動態語義的動態模型（DynamicModel）Booch方法Booch方法區分了系統的邏輯結構和物理結構，不但描述了靜態語義，還描述了動態語義。Booch方法的開發過程是一個迭代的、漸進式的系統開發過程。Booch方法的面向對象開發過程可以分為宏過程（MacroProcess）和微過程（MicroProcess）。UML系統分析與設計第2版ZhenyanJi50Booch方法宏過程充當微過程的控制框架，它代表了整個開發隊伍幾個月或幾個星期所進行的活動。宏過程包含如下5個活動：1．概念化（Conceptualization）概念化的目的是試圖建立系統的核心需求。概念化是個非常有創造性的過程，所以沒有嚴格的開發規則。原型是概念化的主要產品。UML系統分析與設計第2版ZhenyanJi51Booch方法2．分析（Analysis）分析的目的是通過識別出構成問題域詞匯表的類和對象來為系統建立模型，它強調系統的行為。3．設計（Design）設計的目的是建立系統的體系結構。設計可以被分為體系結構規劃、戰術設計和版本規劃。體系結構規劃的目的是在生命周期的早期創建一個特定于域的應用程序框架，這個框架可以被不斷地細化，它包括設計整個系統的層次和劃分。UML系統分析與設計第2版ZhenyanJi52Booch方法4．進化（Evolution）進化由微過程的應用和變化管理組成。微過程的應用是從對下一個版本的需求分析開始的，然后設計系統體系結構，實現類和對象。進化的主要產品是一系列的軟件可執行版本，這些版本是對體系結構第一個版本的不斷細化而產生的。5．維護（Maintenance）維護階段的目的是管理軟件的交付使用，這個階段是進化階段的繼續。在這個階段，需要進行系統的本地化以及消除錯誤等工作。UML系統分析與設計第2版ZhenyanJi53Booch方法微過程由4個重要的、無時間順序的活動組成，它故意模糊了傳統的分析與設計方法中的階段，過程是由時機來控制的。1．在給定的抽象層次上識別出類和對象這一步要對問題域和系統需求進行分析以識別出類和對象，這依賴于適當的需求分析。可以通過面向對象分析、行為分析、用例分析等分析方法來識別類和對象。這個步驟產生了候選類和對象的數據詞典，以及描述對象行為的文檔。UML系統分析與設計第2版ZhenyanJi54Booch方法2．識別出這些類和對象的語義這一步的目的是為從前一階段中識別出的每個抽象設立狀態和行為。在這個階段要執行3個動作，即編制故事板（Storyboarding）、孤立類設計（IsolatedClassDesign）和模式抽取（PatternScavenging）。3．識別出類間和對象間的關系識別出類間和對象間關系的目的是確定每個抽象的邊界，并識別出協作的類和對象。UML系統分析與設計第2版ZhenyanJi55Booch方法4．實現類和對象在分析階段，實現類和對象的目的是細化已存在的抽象，并在下一個抽象層次上找出新的類和對象。通過上述步驟，設計者可以得到如下產物。類圖（ClassDiagram）。對象圖（ObjectDiagram）。狀態躍遷圖（StateTransitionDiagram）。交互作用圖（InteractionDiagram）。模塊圖（ModuleDiagram）。進程圖（ProcessDiagram）。UML系統分析與設計第2版ZhenyanJi56OOSE方法OOSE方法是由Jacobson于1994年提出的，它組合了3種已經被使用了很長時間的技術。OOSE方法是所謂的用例驅動的方法（UseCaseDrivenApproach），在這個方法中，用例模型充當可以導出所有其他模型的中心模型。OOSE方法的一個很大貢獻是引入了用例的概念。OOSE過程可以分為3個階段：分析階段構造階段測試階段UML系統分析與設計第2版ZhenyanJi57OOSE方法—分析階段在分析階段產生兩種模型，即需求模型（RequirementsModel）和分析模型（AnalysisModel）。需求模型從用戶的角度描述了系統的所有功能需求，以及系統被最終用戶使用的方式。需求模型為系統確定了邊界，定義了功能。需求模型由下述3個部分組成。1．用例模型2．問題域對象模型（ProblemDomainObjectModel）問題域對象模型描述了系統的邏輯視圖。3．接口描述（InterfaceDescriptions）UML系統分析與設計第2版ZhenyanJi58OOSE方法—構造階段構造階段可以分為兩步，即設計（Design）和實現（Implementation）。1．設計在這個階段，設計模型細化分析模型，使模型適合于實現環境。設計模型由交互作用圖（InteractionDiagram）和狀態躍遷圖（StateTransitionGraphs）組成。2．實現在這一階段，用編程語言實現每個對象。通常，使用者不必等到整個設計模型都完成后再進行系統實現，可以在設計模型部分完成的情況下就開始實現系統。UML系統分析與設計第2版ZhenyanJi59OOSE方法—測試階段測試用來驗證開發完成的軟件系統是否滿足要求。測試有自己的生命周期，一般是從測試計劃開始，以測試報告結束。測試的步驟如下：1．測試計劃制定測試計劃是為了使測試活動的規劃變得容易，并為測試提供參考2．測試規范測試規范確定要進行哪種測試以及測試例子。3．測試報告根據測試規范進行測試，如果測試通過就不用再進行更多的測試；如果測試失敗，則對失敗原因進行分析。在測試階段，先進行單元測試，再進行系統測試。UML系統分析與設計第2版ZhenyanJi60Fusion方法Fusion方法受到了下面的方法或技術影響：OMTFusion方法中的對象模型與OMT方法中的對象模型非常相似。Fusion方法中的操作模型類似于OMT方法中的功能模型。形式方法形式方法中的前置條件和后置條件被用來形式地描述系統的行為。Booch方法Booch方法中對象圖的可視性信息影響了Fusion方法中的可視圖。CRC擴充了通信信息的CRC影響了Fusion方法中的對象交互作用圖。UML系統分析與設計第2版ZhenyanJi61Fusion方法Fusion方法是以構造各種適當的模型為基礎的，并由分析階段、設計階段和實現階段3個階段組成。1．分析階段分析階段會產生描述系統體系結構的模型。分析階段的過程如下。1．建立對象模型（ObjectModel）2．確定系統的接口3．建立接口模型4．檢查分析模型UML系統分析與設計第2版ZhenyanJi62Fusion方法2.設計階段要將在分析階段產生的抽象的定義轉化為軟件結構。設計階段所進行的過程如下。1．建立對象交互作用圖（ObjectInteractionGraphs）2．建立可視圖（VisibilityGraphs）3．建立類的描述（ClassDescriptions）4．建立繼承圖（InheritanceGraphs）5．更新類的描述UML系統分析與設計第2版ZhenyanJi63Fusion方法3.實現階段應根據設計模型進行實現。實現階段的過程如下。1．編碼（Coding）編碼意味著用編程語言來實現設計階段所建立的模型，它與3個因素有關，即系統生命周期、類描述和數據詞典。2．性能在整個開發過程中都需要考慮系統的性能，這一點是很重要的，如要優化經常使用的代碼等。3．檢查檢查軟件中存在的不足，并對軟件進行測試。UML系統分析與設計第2版ZhenyanJi64小結面向對象方法種類繁多，且各有優勢。本章對5種較為重要的面向對象分析與設計方法，包括OOA/OOD方法、OMT方法、Booch方法、OOSE方法和Fusion方法，逐一進行了詳細介紹。UML系統分析與設計第2版ZhenyanJi65UML系統分析與設計SystemAnalysis&Design

第三章UML的關系依賴關系類屬關系關聯關系實現關系UML系統分析與設計第2版ZhenyanJi67依賴關系如果一個模型元素的變化會影響另一個模型元素（這種影響不必是可逆的），那么就說在這兩個模型元素之間存在依賴關系。依賴關系的UML符號表示是帶箭頭的虛線，指向被依賴的模型元素。UML系統分析與設計第2版ZhenyanJi68依賴關系UML系統分析與設計第2版ZhenyanJi69依賴關系UML定義了許多可以應用于依賴關系的衍型用于類圖中類和對象之間依賴關系的衍型：（1）<<bind>>。這個衍型規定了源元素如何用給定的實際參數實例化目標模板。（2）<<derive>>。這個衍型規定了源元素可以從目標元素導出。（3）<<friend>>。這個衍型規定了源元素對于目標元素有特殊的可見性。（4）<<instanceOf>>。這個衍型規定了源對象是目標分類器的實例。（5）<<instantiate>>。這個衍型規定源元素創建了目標元素的實例。UML系統分析與設計第2版ZhenyanJi70依賴關系（6）<<powertype>>。這個衍型規定了目標元素是源元素的強類型。（7）<<refine>>。這個衍型規定了源元素是比目標元素更細化的抽象。例如，在分析階段遇到一個類Bank，那么在設計階段時，將該類細化成更具體的類Bank。（8）<<use>>。這個衍型規定了源元素的語義是依賴目標元素公共部分的語義的。下面2個衍型可以用于包間的依賴關系（1）<<access>>。這個衍型規定了源包有權引用目標包中的元素。（2）<<import>>。這個衍型規定了一種訪問，這種訪問規定目標包的公共元素如何進入源包的命名空間，就好像在源包中聲明了這部分元素一樣。UML系統分析與設計第2版ZhenyanJi71依賴關系下面2個衍型可以用于用例之間的依賴關系（1）<<extend>>。這個衍型規定目標用例擴充了源用例的行為。（2）<<include>>。這個衍型規定源用例包含了另一個用例的行為。下面3個衍型可以用于為對象間的交互作用建模（1）<<become>>。這個衍型規定了目標對象和源對象是同一個對象，但目標對象出現在更晚的時間點，可能有不同的值、狀態和角色。（2）<<call>>。這個衍型規定源操作調用了目標操作。（3）<<copy>>。這個衍型規定了目標對象是源對象的一個準確、獨立的拷貝。UML系統分析與設計第2版ZhenyanJi72依賴關系下面這個衍型可以應用于狀態機的上下文中<<send>>。這個衍型規定了源操作給目標發送一個事件。當模擬操作發送給定事件到目標對象時，可以使用<<send>>。另外還有一個有用的衍型<<trace>>。這個衍型規定目標元素是源元素的祖先。當模擬不同模型中元素間的關系時，可以使用<<trace>>。UML系統分析與設計第2版ZhenyanJi73類屬關系類屬（Generalization）關系描述了一般事物與該事物的特殊種類之間的關系，也即父元素與子元素之間的關系。在UML中，類屬關系用帶空心箭頭的實線表