在UML類圖中，常見的有以下幾種關系:?泛化（Generalization）,??實現（Realization），關聯（Association)，聚合（Aggregation），組合(Composition)，依賴(Dependency)

?　　1.?泛化（Generalization）

　　【泛化關系】：是一種繼承關系，表示一般與特殊的關系，它指定了子類如何特化父類的所有特征和行為。例如：老虎是動物的一種，即有老虎的特性也有動物的共性。

　　【箭頭指向】：帶三角箭頭的實線，箭頭指向父類

?

　　2.?實現（Realization）

　　【實現關系】：是一種類與接口的關系，表示類是接口所有特征和行為的實現.

　　【箭頭指向】：帶三角箭頭的虛線，箭頭指向接口

?

　　3.?關聯（Association)

　　【關聯關系】：是一種擁有的關系，它使一個類知道另一個類的屬性和方法；如：老師與學生，丈夫與妻子關聯可以是雙向的，也可以是單向的。雙向的關聯可以有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭。

　　【代碼體現】：成員變量

　　【箭頭及指向】：帶普通箭頭的實心線，指向被擁有者

?

　　上圖中，老師與學生是雙向關聯，老師有多名學生，學生也可能有多名老師。但學生與某課程間的關系為單向關聯，一名學生可能要上多門課程，課程是個抽象的東西他不擁有學生。?

　　下圖為自身關聯：?

　　4.?聚合（Aggregation）

　　【聚合關系】：是整體與部分的關系，且部分可以離開整體而單獨存在。如車和輪胎是整體和部分的關系，輪胎離開車仍然可以存在。

　　聚合關系是關聯關系的一種，是強的關聯關系；關聯和聚合在語法上無法區分，必須考察具體的邏輯關系。

　　【代碼體現】：成員變量

　　【箭頭及指向】：帶空心菱形的實心線，菱形指向整體

?

　　5.?組合(Composition)

　　【組合關系】：是整體與部分的關系，但部分不能離開整體而單獨存在。如公司和部門是整體和部分的關系，沒有公司就不存在部門。

???????組合關系是關聯關系的一種，是比聚合關系還要強的關系，它要求普通的聚合關系中代表整體的對象負責代表部分的對象的生命周期。

【代碼體現】：成員變量

【箭頭及指向】：帶實心菱形的實線，菱形指向整體

　　6.?依賴(Dependency)

　　【依賴關系】：是一種使用的關系，即一個類的實現需要另一個類的協助，所以要盡量不使用雙向的互相依賴.

　　【代碼表現】：局部變量、方法的參數或者對靜態方法的調用

　　【箭頭及指向】：帶箭頭的虛線，指向被使用者

?

　　各種關系的強弱順序：

　　泛化?=?實現?>?組合?>?聚合?>?關聯?>?依賴?

　　下面這張UML圖，比較形象地展示了各種類圖關系：

一、?UML類圖及ROSE代碼

1、?關聯關系

1） 雙向關聯：

C1-C2：指雙方都知道對方的存在，都可以調用對方的公共屬性和方法。

在GOF的設計模式書上是這樣描述的：雖然在分析階段這種關系是適用的，但我們覺得它對于描述設計模式內的類關系來說顯得太抽象了，因為在設計階段關聯關系必須被映射為對象引用或指針。對象引用本身就是有向的，更適合表達我們所討論的那種關系。所以這種關系在設計的時候比較少用到，關聯一般都是有向的。

使用ROSE 生成的代碼是這樣的：

雙向關聯在代碼的表現為雙方都擁有對方的一個指針，當然也可以是引用或者是值。

2）單向關聯：

C3->C4：表示相識關系，指C3知道C4，C3可以調用C4的公共屬性和方法。沒有生命期的依賴。一般是表示為一種引用。

生成代碼如下：

單向關聯的代碼就表現為C3有C4的指針，而C4對C3一無所知。

3）自身關聯（反身關聯）：

自己引用自己，帶著一個自己的引用。

代碼如下：

就是在自己的內部有著一個自身的引用。

2、?聚合/組合關系

當類之間有整體-部分關系的時候，我們就可以使用組合或者聚合。

1） 聚合

表示C9聚合C10，但是C10可以離開C9而獨立存在（獨立存在的意思是在某個應用的問題域中這個類的存在有意義。這句話怎么解，請看下面組合里的解釋）。

代碼如下：

2） 組合

也有人稱為包容，一般是實心菱形加實線箭頭表示，如上圖所示，表示的是C8被C7包容，而且C8不能離開C7而獨立存在。但這是視問題域而定的，例如在關心汽車的領域里，輪胎是一定要組合在汽車類中的，因為它離開了汽車就沒有意義了。但是在賣輪胎的店鋪業務里，就算輪胎離開了汽車，它也是有意義的，這就可以用聚合了。在《敏捷開發》中還說到，A組合B，則A需要知道B的生存周期，即可能A負責生成或者釋放B，或者A通過某種途徑知道B的生成和釋放。

代碼如下：

3、?依賴關系

指C5可能要用到C6的一些方法，也可以這樣說，要完成C5里的所有功能，一定要有C6的方法協助才行。C5依賴于C6的定義，一般是在C5類的頭文件中包含了C6的頭文件。ROSE對依賴關系不產生屬性。

注意，要避免雙向依賴。一般來說，不應該存在雙向依賴。

ROSE生成的代碼如下：

雖然ROSE不生成屬性，但在形式上一般是A中的某個方法把B的對象作為參數使用(假設A依賴于B)。如下：

依賴和聚合\組合、關聯等區別和聯系：

關聯是類之間的一種關系，例如老師教學生，老公和老婆，水壺裝水等就是一種關系。這種關系是非常明顯的，在問題領域中通過分析直接就能得出。

依賴是一種弱關聯，只要一個類用到另一個類，但是和另一個類的關系不是太明顯的時候（可以說是“uses”了那個類），就可以把這種關系看成是依賴，依賴也可說是一種偶然的關系，而不是必然的關系，就是“我在某個方法中偶然用到了它，但在現實中我和它并沒多大關系”。例如我和錘子，我和錘子本來是沒關系的，但在有一次要釘釘子的時候，我用到了它，這就是一種依賴，依賴錘子完成釘釘子這件事情。

組合是一種整體-部分的關系，在問題域中這種關系很明顯，直接分析就可以得出的。例如輪胎是車的一部分，樹葉是樹的一部分，手腳是身體的一部分這種的關系，非常明顯的整體-部分關系。

上述的幾種關系（關聯、聚合/組合、依賴）在代碼中可能以指針、引用、值等的方式在另一個類中出現，不拘于形式，但在邏輯上他們就有以上的區別。

這里還要說明一下，所謂的這些關系只是在某個問題域才有效，離開了這個問題域，可能這些關系就不成立了，例如可能在某個問題域中，我是一個木匠，需要拿著錘子去干活，可能整個問題的描述就是我拿著錘子怎么釘桌子，釘椅子，釘柜子；既然整個問題就是描述這個，我和錘子就不僅是偶然的依賴關系了，我和錘子的關系變得非常的緊密，可能就上升為組合關系（讓我突然想起武俠小說的劍不離身，劍亡人亡...）。這個例子可能有點荒謬，但也是為了說明一個道理，就是關系和類一樣，它們都是在一個問題領域中才成立的，離開了這個問題域，他們可能就不復存在了。

4、?泛化（繼承）關系

泛化關系：如果兩個類存在泛化的關系時就使用，例如父和子，動物和老虎，植物和花等。ROSE生成的代碼很簡單，如下：

5、?模板

上面的圖對應的代碼如下：

這里再說一下重復度，其實看完了上面的描述之后，我們應該清楚了各個關系間的關系以及具體對應到代碼是怎么樣的，所謂的重復度，也只不過是上面的擴展，例如A和B有著“1對多”的重復度，那在A中就有一個列表，保存著B對象的N個引用，就是這樣而已。

二、?UML基本元素符號及其JAVA實現

1、類（Classes）

類包含3個組成部分。第一個是Java中定義的類名。第二個是屬性（attributes）。第三個是該類提供的方法。

屬性和操作之前可附加一個可見性修飾符。加號（+）表示具有公共可見性。減號（-）表示私有可見性。#號表示受保護的可見性。省略這些修飾符表示具有package（包）級別的可見性。如果屬性或操作具有下劃線，表明它是靜態的。在操作中，可同時列出它接受的參數，以及返回類型，如下圖所示：

2、包（Package）

包是一種常規用途的組合機制。UML中的一個包直接對應于Java中的一個包。在Java中，一個包可能含有其他包、類或者同時含有這兩者。進行建模時，你通常擁有邏輯性的包，它主要用于對你的模型進行組織。你還會擁有物理性的包，它直接轉換成系統中的Java包。每個包的名稱對這個包進行了惟一性的標識。

3、接口（Interface）

接口是一系列操作的集合，它指定了一個類所提供的服務。它直接對應于Java中的一個接口類型。接口既可用下面的那個圖標來表示（上面一個圓圈符號，圓圈符號下面是接口名，中間是直線，直線下面是方法名），也可由附加了<<interface>>的一個標準類來表示。通常，根據接口在類圖上的樣子，就能知道與其他類的關系。

三、?UML關系及其JAVA實現

1、?依賴（Dependency）

實體之間一個“使用”關系暗示一個實體的規范發生變化后，可能影響依賴于它的其他實例。更具體地說，它可轉換為對不在實例作用域內的一個類或對象的任何類型的引用。其中包括一個局部變量，對通過方法調用而獲得的一個對象的引用（如下例所示），或者對一個類的靜態方法的引用（同時不存在那個類的一個實例）。也可利用“依賴”來表示包和包之間的關系。由于包中含有類，所以你可根據那些包中的各個類之間的關系，表示出包和包的關系。

2、?關聯（Association）

實體之間的一個結構化關系表明對象是相互連接的。箭頭是可選的，它用于指定導航能力。如果沒有箭頭，暗示是一種雙向的導航能力。在Java中，關聯轉換為一個實例作用域的變量。可為一個關聯附加其他修飾符。多重性（Multiplicity）修飾符暗示著實例之間的關系。在示范代碼中，Employee可以有0個或更多的TimeCard對象。但是，每個TimeCard只從屬于單獨一個Employee。

3、?聚合（Aggregation）

聚合是關聯的一種形式，代表兩個類之間的整體/局部關系。聚合暗示著整體在概念上處于比局部更高的一個級別，而關聯暗示兩個類在概念上位于相同的級別。聚合也轉換成Java中的一個實例作用域變量。

關聯和聚合的區別純粹是概念上的，而且嚴格反映在語義上。聚合還暗示著實例圖中不存在回路。換言之，只能是一種單向關系。

4、?合成（Composition）

合成是聚合的一種特殊形式，暗示“局部”在“整體”內部的生存期職責。合成也是非共享的。所以，雖然局部不一定要隨整體的銷毀而被銷毀，但整體要么負責保持局部的存活狀態，要么負責將其銷毀。

局部不可與其他整體共享。但是，整體可將所有權轉交給另一個對象，后者隨即將承擔生存期職責。Employee和TimeCard的關系或許更適合表示成“合成”，而不是表示成“關聯”。

5、?泛化（Generalization）

泛化表示一個更泛化的元素和一個更具體的元素之間的關系。泛化是用于對繼承進行建模的UML元素。在Java中，用extends關鍵字來直接表示這種關系。

6、?實現（Realization）

實例關系指定兩個實體之間的一個合同。換言之，一個實體定義一個合同，而另一個實體保證履行該合同。對Java應用程序進行建模時，實現關系可直接用implements關鍵字來表示。

原文地址：http://www.cnblogs.com/riky/archive/2007/04/07/704298.html

http://www.jfox.info/uml-lei-tu-guan-xi-fan-hua-ji-cheng-shi-xian-yi-lai-guan-lian-ju-he-zu-he

http://www.cnblogs.com/chaosimple/archive/2013/06/11/3131933.html

總結

以上是生活随笔為你收集整理的UML类图关系（泛化 、继承、实现、依赖、关联、聚合、组合）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。