UML類圖快速入門篇
1、關聯
雙向關聯：
C1-C2：指雙方都知道對方的存在，都可以呼叫對方的公共屬性和方法。
在GOF的設計模式書上是這樣描述的：雖然在分析階段這種關係是適用的，但我們覺得它對於描述設計模式內的類關係來說顯得太抽象了，因為在設計階段關聯關係必須被對映為物件引用或指標。物件引用本身就是有向的，更適合表達我們所討論的那種關係。所以這種關係在設計的時候比較少用到，關聯一般都是有向的。
使用ROSE 生成的程式碼是這樣的：
class C1 
...{
public: C2* theC2;
};class C2 ...{public: C1* theC1;};
雙向關聯在程式碼的表現為雙方都擁有對方的一個指標，當然也可以是引用或者是值。
class C3 ...{public: C4* theC4;};class C4 ...{};
單向關聯的程式碼就表現為C3有C4的指標，而C4對C3一無所知。
自身關聯（反身關聯）：
自己引用自己，帶著一個自己的引用。
程式碼如下：
class C14 ...{public: C14* theC14;};
就是在自己的內部有著一個自身的引用。
2、聚合/組合
當類之間有整體-部分關係的時候，我們就可以使用組合或者聚合。
class C9 ...{public: C10 theC10;};class C10 ...{};
組合（也有人稱為包容）：一般是實心菱形加實線箭頭表示，如上圖所示，表示的是C8被C7包容，而且C8不能離開C7而獨立存在。但這是視問題域而定的，例如在關心汽車的領域裡，輪胎是一定要組合在汽車類中的，因為它離開了汽車就沒有意義了。但是在賣輪胎的店鋪業務裡，就算輪胎離開了汽車，它也是有意義的，這就可以用聚合了。在《敏捷開發》中還說到，A組合B，則A需要知道B的生存週期，即可能A負責生成或者釋放B，或者A通過某種途徑知道B的生成和釋放。
他們的程式碼如下：
class C7 ...{public: C8 theC8;};class C8 ...{};
可以看到，程式碼和聚合是一樣的。具體如何區別，可能就只能用語義來區分了。
3、依賴
依賴:
指C5可能要用到C6的一些方法，也可以這樣說，要完成C5裡的所有功能，一定要有C6的方法協助才行。C5依賴於C6的定義，一般是在C5類的標頭檔案中包含了C6的標頭檔案。ROSE對依賴關係不產生屬性。
注意，要避免雙向依賴。一般來說，不應該存在雙向依賴。
ROSE生成的程式碼如下：
// C5.h#include "C6.h"class C5 ...{};// C6.h#include "C5.h"class C6...{};
雖然ROSE不生成屬性，但在形式上一般是A中的某個方法把B的物件作為引數使用(假設A依賴於B)。如下：
#include "B.h"class A...{ void Func(B &b);}
那依賴和聚合\組合、關聯等有什麼不同呢？ 關聯是類之間的一種關係，例如老師教學生，老公和老婆，水壺裝水等就是一種關係。這種關係是非常明顯的，在問題領域中通過分析直接就能得出。 依賴是一種弱關聯，只要一個類用到另一個類，但是和另一個類的關係不是太明顯的時候（可以說是“uses”了那個類），就可以把這種關係看成是依賴，依賴也可說是一種偶然的關係，而不是必然的關係，就是“我在某個方法中偶然用到了它，但在現實中我和它並沒多大關係”。例如我和錘子，我和錘子本來是沒關係的，但在有一次要釘釘子的時候，我用到了它，這就是一種依賴，依賴錘子完成釘釘子這件事情。
組合是一種整體-部分的關係，在問題域中這種關係很明顯，直接分析就可以得出的。例如輪胎是車的一部分，樹葉是樹的一部分，手腳是身體的一部分這種的關係，非常明顯的整體-部分關係。
上述的幾種關係（關聯、聚合/組合、依賴）在程式碼中可能以指標、引用、值等的方式在另一個類中出現，不拘於形式，但在邏輯上他們就有以上的區別。
這裡還要說明一下，所謂的這些關係只是在某個問題域才有效，離開了這個問題域，可能這些關係就不成立了，例如可能在某個問題域中，我是一個木匠，需要拿著錘子去幹活，可能整個問題的描述就是我拿著錘子怎麼釘桌子，釘椅子，釘櫃子；既然整個問題就是描述這個，我和錘子就不僅是偶然的依賴關係了，我和錘子的關係變得非常的緊密，可能就上升為組合關係（讓我突然想起武俠小說的劍不離身，劍亡人亡...）。這個例子可能有點荒謬，但也是為了說明一個道理，就是關係和類一樣，它們都是在一個問題領域中才成立的，離開了這個問題域，他們可能就不復存在了。
4、泛化（繼承）
泛化關係：如果兩個類存在泛化的關係時就使用，例如父和子，動物和老虎，植物和花等。
ROSE生成的程式碼很簡單，如下：
#include "C11.h"class C12 : public C11...{};
5、這裡順便提一下模板
上面的圖對應的程式碼如下：
template<int>class C13 ...{};
這裡再說一下重複度，其實看完了上面的描述之後，我們應該清楚了各個關係間的關係以及具體對應到程式碼是怎麼樣的，所謂的重複度，也只不過是上面的擴充套件，例如A和B有著“1對多”的重複度，那在A中就有一個列表，儲存著B物件的N個引用，就是這樣而已。 好了，到這裡，已經把上面的類圖關係說完了，希望你能有所收穫了，我也費了不少工夫啊（畫圖、生成程式碼、截圖、寫到BLOG上，唉，一頭大汗）。不過如果能讓你徹底理解UML類圖的這些關係，也值得了。:) +++++++++++++++++++++++++++++++++++++++++++++++++++++
在UML建模中，對類圖上出現元素的理解是至關重要的。開發者必須理解如何將類圖上出現的元素轉換到Java中。以java為代表結合網上的一些例項，下面是個人一些基本收集與總結：
基本元素符號：
1. 類（Classes）
類包含3個組成部分。第一個是Java中定義的類名。第二個是屬性（attributes）。第三個是該類提供的方法。
屬性和操作之前可附加一個可見性修飾符。加號（+）表示具有公共可見性。減號（-）表示私有可見性。#號表示受保護的可見性。省略這些修飾符表示具有package（包）級別的可見性。如果屬性或操作具有下劃線，表明它是靜態的。在操作中，可同時列出它接受的引數，以及返回型別，如下圖所示：
2. 包（Package）
包是一種常規用途的組合機制。UML中的一個包直接對應於Java中的一個包。在Java中，一個包可能含有其他包、類或者同時含有這兩者。進行建模時，你通常擁有邏輯性的包，它主要用於對你的模型進行組織。你還會擁有物理性的包，它直接轉換成系統中的Java包。每個包的名稱對這個包進行了惟一性的標識。
3. 介面（Interface）
介面是一系列操作的集合，它指定了一個類所提供的服務。它直接對應於Java中的一個介面型別。介面既可用下面的那個圖示來表示（上面一個圓圈符號，圓圈符號下面是介面名，中間是直線，直線下面是方法名），也可由附加了<<interface>>的一個標準類來表示。通常，根據介面在類圖上的樣子，就能知道與其他類的關係。
關 系：
1. 依賴（Dependency）
實體之間一個“使用”關係暗示一個實體的規範發生變化後，可能影響依賴於它的其他例項。更具體地說，它可轉換為對不在例項作用域內的一個類或物件的任何型別的引用。其中包括一個區域性變數，對通過方法呼叫而獲得的一個物件的引用（如下例所示），或者對一個類的靜態方法的引用（同時不存在那個類的一個例項）。也可利用“依賴”來表示包和包之間的關係。由於包中含有類，所以你可根據那些包中的各個類之間的關係，表示出包和包的關係。
2. 關聯（Association）
實體之間的一個結構化關係表明物件是相互連線的。箭頭是可選的，它用於指定導航能力。如果沒有箭頭，暗示是一種雙向的導航能力。在Java中，關聯轉換為一個例項作用域的變數，就像圖E的“Java”區域所展示的程式碼那樣。可為一個關聯附加其他修飾符。多重性（Multiplicity）修飾符暗示著例項之間的關係。在示範程式碼中，Employee可以有0個或更多的TimeCard物件。但是，每個TimeCard只從屬於單獨一個Employee。
3. 聚合（Aggregation）
聚合是關聯的一種形式，代表兩個類之間的整體/區域性關係。聚合暗示著整體在概念上處於比區域性更高的一個級別，而關聯暗示兩個類在概念上位於相同的級別。聚合也轉換成Java中的一個例項作用域變數。
關聯和聚合的區別純粹是概念上的，而且嚴格反映在語義上。聚合還暗示著例項圖中不存在迴路。換言之，只能是一種單向關係。
4. 合成（Composition）
合成是聚合的一種特殊形式，暗示“區域性”在“整體”內部的生存期職責。合成也是非共享的。所以，雖然區域性不一定要隨整體的銷燬而被銷燬，但整體要麼負責保持區域性的存活狀態，要麼負責將其銷燬。
區域性不可與其他整體共享。但是，整體可將所有權轉交給另一個物件，後者隨即將承擔生存期職責。Employee和TimeCard的關係或許更適合表示成“合成”，而不是表示成“關聯”。
5. 泛化（Generalization）
泛化表示一個更泛化的元素和一個更具體的元素之間的關係。泛化是用於對繼承進行建模的UML元素。在Java中，用extends關鍵字來直接表示這種關係。
6. 實現（Realization）
例項關係指定兩個實體之間的一個合同。換言之，一個實體定義一個合同，而另一個實體保證履行該合同。對Java應用程式進行建模時，實現關係可直接用implements關鍵字來表示。
像聚合還分為：非共享聚合、共享聚合、複合聚合等。以及其它內容，下次再補充。