轉自：http://blog.csdn.net/chenyujing1234/article/details/8173519

UML中包括九種圖：用例圖、類圖、物件圖、狀態圖、時序圖、協作圖、活動圖、元件圖、配置圖。

１）用例圖（Use Case Diagram）

它是UML中最簡單也是最複雜的一種圖。說它簡單是因為它採用了面向物件的思想，又是基於使用者視角的，繪製非常容易，簡單的圖形表示讓人一看就懂。說它複雜是因為用例圖往往不容易控制，要麼過於複雜，要麼過於簡單。

用例圖表示了角色和用例以及它們之間的關係。

※用例圖是從使用者角度描述系統功能，是使用者所能觀察到的系統功能的模型圖，用例是系統中的一個功能單元。 ²用例圖多用於靜態建模階段(主要是業務建模和需求建模)。

用例圖中的事物及解釋

用例圖中的關係及解釋

例子

例項1  參與者之間的泛化關係

參與者：經理，安全主管，保安

用例：管理人事，批准預算，批准安全證書，監視周邊

在參與者之間不存在泛化關係的情況下，各個參與者參與用例的情況分別是：經理參與用例管理人事和批准預算；安全主管參與用例批准安全證書；保安參與用例監視周邊。由於安全主管與經理，安全主管與保安之間泛化關係的存在，意味著安全主管可以擔任經理和保安的角色，就能夠參與經理和保安參與的用例。這樣，安全主管就可以參與全部4個用例。但經理或者保安卻不能擔任安全主管的角色，也就不能參與用例批准安全證書。

例項2  用例之間擴充套件和包含關係

用例的上下文是：短途旅行但汽車的油不足以應付全部路程。那麼為汽車加油的動作在旅行的每個場景(事件流)中都會出現，不加油就不會完成旅行。吃飯則可以由司機決定是否進行，不吃飯不會影響旅行的完成。

例項3.  航空售票的用例圖

²參與者(actor)：clerk，監督員，信用卡服務商，資訊亭 ²用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales ²參與者Clerk參與(或稱發起)Buy tickets和Buy Subscription 兩個用例(關聯關係)。這兩個用例的事件流都包含Make

charges用例(包含關係)。

²系統由：Buy tickets， Buy Subscription， Make charges， Survey sales組成。 ²該系統主要包含：Buy tickets， Buy Subscription， Make charges， Survey sales這幾個功能。 ²該系統主要面向的使用者(參與者)：clerk，監督員，信用卡服務商，資訊亭。

２）類圖（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

繼承、實現、依賴、關聯、聚合、組合的聯絡與區別

分別介紹這幾種關係：

繼承

指的是一個類（稱為子類、子介面）繼承另外的一個類（稱為父類、父介面）的功能，並可以增加它自己的新功能的能力，繼承是類與類或者介面與介面之間最常見的關係；在Java中此類關係通過關鍵字extends明確標識，在設計時一般沒有爭議性； 

 

實現

指的是一個class類實現interface介面（可以是多個）的功能；實現是類與介面之間最常見的關係；在Java中此類關係通過關鍵字implements明確標識，在設計時一般沒有爭議性；

依賴

可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關係是具有偶然性的、、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關係就是依賴；表現在程式碼層面，為類B作為引數被類A在某個method方法中使用；

 

關聯

他體現的是兩個類、或者類與介面之間語義級別的一種強依賴關係，比如我和我的朋友；這種關係比依賴更強、不存在依賴關係的偶然性、關係也不是臨時性的，一般是長期性的，而且雙方的關係一般是平等的、關聯可以是單向、雙向的；表現在程式碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個型別為被關聯類B的全域性變數； 

聚合

聚合是關聯關係的一種特例，他體現的是整體與部分、擁有的關係，即has-a的關係，此時整體與部分之間是可分離的，他們可以具有各自的生命週期，部分可以屬於多個整體物件，也可以為多個整體物件共享；比如計算機與CPU、公司與員工的關係等；表現在程式碼層面，和關聯關係是一致的，只能從語義級別來區分； 

組合

組合也是關聯關係的一種特例，他體現的是一種contains-a的關係，這種關係比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關係，但此時整體與部分是不可分的，整體的生命週期結束也就意味著部分的生命週期結束；比如你和你的大腦；表現在程式碼層面，和關聯關係是一致的，只能從語義級別來區分； 

對於繼承、實現這兩種關係沒多少疑問，他們體現的是一種類與類、或者類與介面間的縱向關係；其他的四者關係則體現的是類與類、或者類與介面間的引用、橫向關係，是比較難區分的，有很多事物間的關係要想準備定位是很難的，前面也提到，這幾種關係都是語義級別的，所以從程式碼層面並不能完全區分各種關係；

但總的來說，後幾種關係所表現的強弱程度依次為：組合>聚合>關聯>依賴；

聚合跟組合其實都屬於關聯 只不過它們是兩種特殊的關聯 因為本是同根生 所以它們之間難免會有相似之處 下面讓我們一起來看一下它們之間有何不同

聚合與組合的概念相信不用我在此贅述大家就已經瞭解了 下面直接上例子

程老師的《大話》裡舉大那個大雁的例子很貼切 在此我就借用一下 大雁喜歡熱鬧害怕孤獨 所以它們一直過著群居的生活 這樣就有了雁群 每一隻大雁都有自己的雁群 每個雁群都有好多大雁 大雁與雁群的這種關係就可以稱之為聚合 另外每隻大雁都有兩隻翅膀 大雁與雁翅的關係就叫做組合 有此可見 聚合的關係明顯沒有組合緊密 大雁不會因為它們的群主將雁群解散而無法生存 而雁翅就無法脫離大雁而單獨生存——組合關係的類具有相同的生命週期

聚合關係圖：

組合關係圖：

從從程式碼上看這兩種關係的區別在於：

建構函式不同

雁群類：

1. publicclass GooseGroup   
2. {   
3. public Goose goose;   
4. public GooseGroup(Goose goose)   
5.         {   
6. this.goose = goose;   
7.         }   
8. }   
9. publicclass GooseGroup   
10.     {   
11. public Goose goose;   
12. public GooseGroup(Goose goose)   
13.         {   
14. this.goose = goose;   
15.         }   
16.     }   
17. 大雁類：  
18. publicclass Goose   
19. {   
20. public Wings wings;   
21. public Goose()   
22.     {   
23.         wings=new Wings();   
24.     }   
25. }   
26. publicclass Goose   
27. {   
28. public Wings wings;   
29. public Goose()   
30.     {   
31.         wings=new Wings();   
32.     }   
33. }   

３）物件圖

物件圖是類圖的例項，幾乎使用與類圖完全相同的標識。它們的不同點在於物件圖顯示類的多個物件例項，而不是例項的類。一個物件圖是類圖的一個例項。由於物件存在生命週期，因此物件圖只能在系統某一時間段存在。

４）狀態圖

描述一個實體基於事件反應的動態行為，顯示了該實體如何根據當前所處的狀態對不同的時間做出反應的。通常建立一個UML狀態圖是為了以下的研究目的：研究類、角色、子系統、或元件的複雜行為。

 

５）時序圖

又稱順序圖，描述了物件之間動態的互動關係，著重體現物件間訊息傳遞的時間順序。

順序圖由一組物件構成，每個物件分別帶有一條豎線，稱作物件的生命線，它代表時間軸，時間沿豎線向下延伸。順序圖描述了這些物件隨著時間的推移相互之間交換訊息的過程。訊息用從一務垂直的物件生命線指向另一個物件的生命線的水平箭頭表示。圖中還可以根據需要增加有關時間的說明和其他註釋。

６）協作圖

協作圖用於顯示元件及其互動關係的空間組織結構，它並不側重於互動的順序。協作圖顯示了互動中各個物件之間的組織互動關係以及物件彼此之間的連結。與序列圖不同，協作圖顯示的是物件之間的關係。

另一方面，協作圖沒有將時間作為一個單獨的維度，因此序列號就決定了訊息及併發執行緒的順序。協作圖是一個介於符號圖和序列圖之間的交叉產物，它用帶有編號的箭頭來描述特定的方案，以顯示在整個方案過程中訊息的移動情況。

協作圖用途：

通過描繪物件之間訊息的移動情況來反映具體的方案。

顯示物件及其互動關係的空間組織結構，而非互動的順序。

※協作圖描述物件間的協作關係，協作圖跟順序圖相似，顯示物件間的動態合作關係。除顯示資訊交換外，協作圖還顯示物件以及它們之間的關係. ※協作圖的一個用途是表示一個類操作的實現

７）活動圖（Activity Diagram）

UML活動圖記錄了單個操作或方法的邏輯，單個使用者案例，或者單個業務流程的邏輯。描述系統中各種活動的執行順序，通常用於描述一個操作中所要進行的各項活動的執行流程。同時，它也常被用來描述一個用例的處理流程，或者某種互動流程。

活動圖由一些活動組成，圖中同時包括了對這些活動的說明。當一個活動執行完畢之後，控制將沿著控制轉移箭頭轉向下一個活動。活動圖中還可以方便地描述控制轉移的條件以及並行執行等要求。

 

８）元件圖（Component Diagram）

元件圖是用來反映程式碼的物理結構。從元件圖中，可以瞭解各軟體元件（如原始碼檔案或動態連結庫）之間的編譯器和執行時依賴關係。使用元件圖可以將系統劃分為內聚元件並顯示程式碼自身的結構。

元件圖的主要目的是顯示系統元件間的結構關係。

９）配置圖

配置圖描述系統中硬體和軟體的物理配置情況和系統體系結構。

在配置圖中，用結點表示實際的物理裝置，如計算機和各種外部裝置等，並根據它們之間的連線關係，將相應的結點連線起來，並說明其連線方式。在結點裡面，說明分配給該結點上執行的可執行構件或物件，從而說明哪些軟體單元被分配在哪些結點上執行