六大UML類圖關系連連看
在學習UML類圖的過程中，UML類圖關系是必須要掌握的問題，UML定義的關系主要有六種：依賴、類屬、關聯、實現、聚合和組合。下面對其定義和表示方法逐一說明。
UML類圖關系簡介
依賴（Dependency）：元素A的變化會影響元素B，但反之不成立，那么B和A的關系是依賴關系，B依賴A；類屬關系和實現關系在語義上講也是依賴關系，但由于其有更特殊的用途，所以被單獨描述。UML中用帶箭頭的虛線表示Dependency關系，箭頭指向被依賴元素。
類屬（Generalization）：通常所說的繼承（特殊個體iskindof一般個體）關系，不必多解釋了。UML中用帶空心箭頭的實線線表示Generalization關系，箭頭指向一般個體。
實現（Realize）：元素A定義一個約定，元素B實現這個約定，則B和A的關系是Realize，BrealizeA。這個關系最常用于接口。UML中用空心空心箭頭和虛線表示Realize關系，箭頭指向定義約定的元素。
關聯（Association）：元素間的結構化關系，是一種弱關系，被關聯的元素間通常可以被獨立的考慮。UML中用實線表示Dependency關系，箭頭指向被依賴元素。
聚合（Aggregation）：關聯關系的一種特例，表示部分和整體（整體hasa部分）的關系。UML中用帶空心菱形頭的實線表示Aggregation關系，菱形頭指向整體。
組合（Composition）：組合是聚合關系的變種，表示元素間更強的組合關系。如果是組合關系，如果整體被破壞則個體一定會被破壞，而聚合的個體則可能是被多個整體所共享的，不一定會隨著某個整體的破壞而被破壞。UML中用帶實心心菱形頭的實線表示Composition關系，菱形頭指向整體。
UML類圖關系詳解
后面的例子將針對某個具體目的來獨立地展示各種關系。雖然語法無誤，但這些例子可進一步精煉，在它們的有效范圍內包括更多的語義。
依賴（Dependency）
實體之間一個“使用”關系暗示一個實體的規范發生變化后，可能影響依賴于它的其他實例（圖D）。更具體地說，它可轉換為對不在實例作用域內的一個類或對象的任何類型的引用。其中包括一個局部變量，對通過方法調用而獲得的一個對象的引用（如下例所示），或者對一個類的靜態方法的引用（同時不存在那個類的一個實例）。也可利用“依賴”來表示包和包之間的關系。由于包中含有類，所以你可根據那些包中的各個類之間的關系，表示出包和包的關系。
圖D
關聯（Association）
UML類圖關系中實體之間的一個結構化關系表明對象是相互連接的。箭頭是可選的，它用于指定導航能力。如果沒有箭頭，暗示是一種雙向的導航能力。在Java中，關聯（圖E）轉換為一個實例作用域的變量，就像圖E的“Java”區域所展示的代碼那樣。可為一個關聯附加其他修飾符。多重性（Multiplicity）修飾符暗示著實例之間的關系。在示范代碼中，Employee可以有0個或更多的TimeCard對象。但是，每個TimeCard只從屬于單獨一個Employee。
圖E
聚合（Aggregation）
聚合（圖F）是關聯的一種形式，代表兩個類之間的整體/局部關系。聚合暗示著整體在概念上處于比局部更高的一個級別，而關聯暗示兩個類在概念上位于相同的級別。聚合也轉換成Java中的一個實例作用域變量。#p#
關聯和聚合的區別純粹是概念上的，而且嚴格反映在語義上。聚合還暗示著實例圖中不存在回路。換言之，只能是一種單向關系。
圖F
合成（Composition）
UML類圖關系中合成（圖G）是聚合的一種特殊形式，暗示“局部”在“整體”內部的生存期職責。合成也是非共享的。所以，雖然局部不一定要隨整體的銷毀而被銷毀，但整體要么負責保持局部的存活狀態，要么負責將其銷毀。局部不可與其他整體共享。但是，整體可將所有權轉交給另一個對象，后者隨即將承擔生存期職責。
Employee和TimeCard的關系或許更適合表示成“合成”，而不是表示成“關聯”。
圖G
泛化（Generalization）
UML類圖關系中泛化（圖H）表示一個更泛化的元素和一個更具體的元素之間的關系。泛化是用于對繼承進行建模的UML元素。在Java中，用extends關鍵字來直接表示這種關系。
圖H
實現（Realization）
實例（圖I）關系指定兩個實體之間的一個合同。換言之，一個實體定義一個合同，而另一個實體保證履行該合同。對Java應用程序進行建模時，實現關系可直接用implements關鍵字來表示。
圖I
讀后感：通過java代碼和UML可以很清楚的理解這幾種關系，關聯分3種這比較搞，主要還是要搞清楚依賴，關聯，泛化和實現這4種關系
【編輯推薦】
