UML總結4---UML九種圖關系說明
轉自：http://blog.csdn.NET/chenyujing1234/article/details/8173519
UML中包括九種圖：用例圖、類圖、對象圖、狀態圖、時序圖、協作圖、活動圖、組件圖、配置圖。
１）用例圖（Use Case Diagram）
它是UML中最簡單也是最復雜的一種圖。說它簡單是因為它采用了面向對象的思想，又是基於用戶視角的，繪制非常容易，簡單的圖形表示讓人一看就懂。說它復雜是因為用例圖往往不容易控制，要麽過於復雜，要麽過於簡單。
用例圖表示了角色和用例以及它們之間的關系。
※用例圖是從用戶角度描述系統功能，是用戶所能觀察到的系統功能的模型圖，用例是系統中的一個功能單元。 2用例圖多用於靜態建模階段(主要是業務建模和需求建模)。用例圖中的事物及解釋
用例圖中的關系及解釋
例子
實例1 參與者之間的泛化關系
參與者：經理，安全主管，保安
用例：管理人事，批準預算，批準安全證書，監視周邊
在參與者之間不存在泛化關系的情況下，各個參與者參與用例的情況分別是：經理參與用例管理人事和批準預算；安全主管參與用例批準安全證書；保安參與用例監視周邊。由於安全主管與經理，安全主管與保安之間泛化關系的存在，意味著安全主管可以擔任經理和保安的角色，就能夠參與經理和保安參與的用例。這樣，安全主管就可以參與全部4個用例。但經理或者保安卻不能擔任安全主管的角色，也就不能參與用例批準安全證書。
實例2 用例之間擴展和包含關系
用例的上下文是：短途旅行但汽車的油不足以應付全部路程。那麽為汽車加油的動作在旅行的每個場景(事件流)中都會出現，不加油就不會完成旅行。吃飯則可以由司機決定是否進行，不吃飯不會影響旅行的完成。
實例3. 航空售票的用例圖
2參與者(actor)：clerk，監督員，信用卡服務商，信息亭 2用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales 2參與者Clerk參與(或稱發起)Buy tickets和Buy Subscription 兩個用例(關聯關系)。這兩個用例的事件流都包含Makecharges用例(包含關系)。
２）類圖（Class Diagram）
是最常用的一種圖，類圖可以幫助我們更直觀的了解一個系統的體系結構。通過關系和類表示的類圖，可以圖形化的方式描述一個系統的設計部分。
※類圖描述系統中類的靜態結構。不僅定義系統中的類，表示類之間的聯系如關聯、依賴、聚合等，也包括類的內部結構(類的屬性和操作) ※類圖是以類為中心來組織的，類圖中的其他元素或屬於某個類或與類相關聯 ※從上到下分為三部分，分別是類名、屬性和操作。類名是必須有的 ※類如果有屬性，則每一個屬性都必須有一個名字，另外還可以有其它的描述信息，如可見性、數據類型、缺省值等 ※類如果有操作，則每一個操作也都有一個名字，其它可選的信息包括可見性、參數的名字、參數類型、參數缺省值和操作的返回值的類型等。（按標準來做，我們常常沒按標準）
3.2.3 抽象類
※不能被實例化的類，一般至少包含一個抽象操作3.2.4 模版類
※一種參數化的類，在編譯時把模版參數綁定到不同的數據類型，從而產生不同的類
3.3 類圖中的關系及解釋
3.3.1 關聯關系
※描述了類的結構之間的關系。具有方向、名字、角色和多重性等信息。一般的關聯關系語義較弱。也有兩種語義較強，分別是聚合與組合
聚合關系
?特殊關聯關系，指明一個聚集（整體）和組成部分之間的關系 
組合關系
?語義更強的聚合，部分和整體具有相同的生命周期
3.3.2 泛化關系
※在面向對象中一般稱為繼承關系，存在於父類與子類、父接口與子接口之間
3.3.3實現關系
※對應於類和接口之間的關系
3.3.4 依賴關系
※描述了一個類的變化對依賴於它的類產生影響的情況。有多種表現形式， 例如綁定(bind)、友元(friend)等
3.4 類圖與代碼的映射
3.4.1 類的映射
3.4.2 關聯關系的映射
3.4.3 泛化關系的映射
3.4.4 實現關系的映射
3.4.5 依賴關系的映射
3.5 類圖例子
3.5.1 圖形編輯器
※圖形編輯器一般都具有一些基本圖形，如直線、矩形等，用戶可以直接使用基本圖形畫圖，也可以把基本圖形組合在一起創建復雜圖形 ※如果區別對待基本圖形和組合圖形，會使代碼變得復雜，而且多數情況下用戶認為二者是一樣的 ※組合模式可以用相同的方式處理兩種圖形
3.5.2 演出售票系統
=================================================================================================================
=====================================================================================================================
轉載自： http://www.cnblogs.com/olvo/archive/2012/05/03/2481014.html
UML類圖關系（泛化 、繼承、實現、依賴、關聯、聚合、組合）
繼承、實現、依賴、關聯、聚合、組合的聯系與區別
分別介紹這幾種關系：
繼承
指的是一個類（稱為子類、子接口）繼承另外的一個類（稱為父類、父接口）的功能，並可以增加它自己的新功能的能力，繼承是類與類或者接口與接口之間最常見的關系；在Java中此類關系通過關鍵字extends明確標識，在設計時一般沒有爭議性；
實現
指的是一個class類實現interface接口（可以是多個）的功能；實現是類與接口之間最常見的關系；在Java中此類關系通過關鍵字implements明確標識，在設計時一般沒有爭議性；
依賴
可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關系是具有偶然性的、、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關系就是依賴；表現在代碼層面，為類B作為參數被類A在某個method方法中使用；
關聯
他體現的是兩個類、或者類與接口之間語義級別的一種強依賴關系，比如我和我的朋友；這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，而且雙方的關系一般是平等的、關聯可以是單向、雙向的；表現在代碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；
聚合
聚合是關聯關系的一種特例，他體現的是整體與部分、擁有的關系，即has-a的關系，此時整體與部分之間是可分離的，他們可以具有各自的生命周期，部分可以屬於多個整體對象，也可以為多個整體對象共享；比如計算機與CPU、公司與員工的關系等；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；
組合
組合也是關聯關系的一種特例，他體現的是一種contains-a的關系，這種關系比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關系，但此時整體與部分是不可分的，整體的生命周期結束也就意味著部分的生命周期結束；比如你和你的大腦；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；
對於繼承、實現這兩種關系沒多少疑問，他們體現的是一種類與類、或者類與接口間的縱向關系；其他的四者關系則體現的是類與類、或者類與接口間的引用、橫向關系，是比較難區分的，有很多事物間的關系要想準備定位是很難的，前面也提到，這幾種關系都是語義級別的，所以從代碼層面並不能完全區分各種關系；
但總的來說，後幾種關系所表現的強弱程度依次為：組合>聚合>關聯>依賴；
聚合跟組合其實都屬於關聯 只不過它們是兩種特殊的關聯 因為本是同根生 所以它們之間難免會有相似之處 下面讓我們一起來看一下它們之間有何不同
聚合與組合的概念相信不用我在此贅述大家就已經了解了 下面直接上例子
程老師的《大話》裏舉大那個大雁的例子很貼切 在此我就借用一下 大雁喜歡熱鬧害怕孤獨 所以它們一直過著群居的生活 這樣就有了雁群 每一只大雁都有自己的雁群 每個雁群都有好多大雁 大雁與雁群的這種關系就可以稱之為聚合 另外每只大雁都有兩只翅膀 大雁與雁翅的關系就叫做組合 有此可見 聚合的關系明顯沒有組合緊密 大雁不會因為它們的群主將雁群解散而無法生存 而雁翅就無法脫離大雁而單獨生存——組合關系的類具有相同的生命周期
聚合關系圖：
組合關系圖：
從從代碼上看這兩種關系的區別在於：
構造函數不同
雁群類：
[cpp] view plaincopy- public class GooseGroup
- {
- public Goose goose;
- public GooseGroup(Goose goose)
- {
- this.goose = goose;
- }
- }
- public class GooseGroup
- {
- public Goose goose;
- public GooseGroup(Goose goose)
- {
- this.goose = goose;
- }
- }
- 大雁類：
- public class Goose
- {
- public Wings wings;
- public Goose()
- {
- wings=new Wings();
- }
- }
- public class Goose
- {
- public Wings wings;
- public Goose()
- {
- wings=new Wings();
- }
- }
３）對象圖
對象圖是類圖的實例，幾乎使用與類圖完全相同的標識。它們的不同點在於對象圖顯示類的多個對象實例，而不是實例的類。一個對象圖是類圖的一個實例。由於對象存在生命周期，因此對象圖只能在系統某一時間段存在。
４）狀態圖
描述一個實體基於事件反應的動態行為，顯示了該實體如何根據當前所處的狀態對不同的時間做出反應的。通常創建一個UML狀態圖是為了以下的研究目的：研究類、角色、子系統、或組件的復雜行為。
５）時序圖
又稱順序圖，描述了對象之間動態的交互關系，著重體現對象間消息傳遞的時間順序。
順序圖由一組對象構成，每個對象分別帶有一條豎線，稱作對象的生命線，它代表時間軸，時間沿豎線向下延伸。順序圖描述了這些對象隨著時間的推移相互之間交換消息的過程。消息用從一務垂直的對象生命線指向另一個對象的生命線的水平箭頭表示。圖中還可以根據需要增加有關時間的說明和其他註釋。
６）協作圖
協作圖用於顯示組件及其交互關系的空間組織結構，它並不側重於交互的順序。協作圖顯示了交互中各個對象之間的組織交互關系以及對象彼此之間的鏈接。與序列圖不同，協作圖顯示的是對象之間的關系。
另一方面，協作圖沒有將時間作為一個單獨的維度，因此序列號就決定了消息及並發線程的順序。協作圖是一個介於符號圖和序列圖之間的交叉產物，它用帶有編號的箭頭來描述特定的方案，以顯示在整個方案過程中消息的移動情況。
協作圖用途：
通過描繪對象之間消息的移動情況來反映具體的方案。
顯示對象及其交互關系的空間組織結構，而非交互的順序。
※協作圖描述對象間的協作關系，協作圖跟順序圖相似，顯示對象間的動態合作關系。除顯示信息交換外，協作圖還顯示對象以及它們之間的關系. ※協作圖的一個用途是表示一個類操作的實現
７）活動圖（Activity Diagram）
UML活動圖記錄了單個操作或方法的邏輯，單個用戶案例，或者單個業務流程的邏輯。描述系統中各種活動的執行順序，通常用於描述一個操作中所要進行的各項活動的執行流程。同時，它也常被用來描述一個用例的處理流程，或者某種交互流程。
活動圖由一些活動組成，圖中同時包括了對這些活動的說明。當一個活動執行完畢之後，控制將沿著控制轉移箭頭轉向下一個活動。活動圖中還可以方便地描述控制轉移的條件以及並行執行等要求。
８）組件圖（Component Diagram）
組件圖是用來反映代碼的物理結構。從組件圖中，可以了解各軟件組件（如源代碼文件或動態鏈接庫）之間的編譯器和運行時依賴關系。使用組件圖可以將系統劃分為內聚組件並顯示代碼自身的結構。
組件圖的主要目的是顯示系統組件間的結構關系。
９）配置圖
配置圖描述系統中硬件和軟件的物理配置情況和系統體系結構。
在配置圖中，用結點表示實際的物理設備，如計算機和各種外部設備等，並根據它們之間的連接關系，將相應的結點連接起來，並說明其連接方式。在結點裏面，說明分配給該結點上運行的可執行構件或對象，從而說明哪些軟件單元被分配在哪些結點上運行
UML總結4---UML九種圖關系說明