UML類圖是描述類之間的關系
概念
-
類（Class）：使用三層矩形框表示。
第一層顯示類的名稱，如果是抽象類，則就用斜體顯示。
第二層是字段和屬性。
第三層是類的方法。
注意前面的符號，‘+’表示public，‘-’表示private，‘#’表示protected。 -
接口：使用兩層矩形框表示，與類圖的區別主要是頂端有<
>顯示 。
第一行是接口名稱。
第二行是接口方法。 -
繼承類（extends）：用空心三角形+實線來表示。
-
實現接口（implements）：用空心三角形+虛線來表示
-
關聯（Association）：用實線箭頭來表示，例如：燕子與氣候
-
聚合（Aggregation）：用空心的菱形+實線箭頭來表示
聚合：表示一種弱的‘擁有’關系，體現的是A對象可以包含B對象，但B對象不是A對象的一部分，例如：公司和員工
組合（Composition）：用實心的菱形+實線箭頭來表示
組合：部分和整體的關系，並且生命周期是相同的。例如：人與手
-
依賴（Dependency） ：用虛線箭頭來表示，例如：動物與氧氣
-
基數 ：連線兩端的數字表明這一端的類可以有幾個實例，比如：一個鳥應該有兩只翅膀。如果一個類可能有無數個實例，則就用‘n’來表示。關聯、聚合、組合是有基數的。
重復度：
- 單重復度，只存在一對一的關系。
- 多重復度，用列表、vector或其它的數據結構維護一對多，多對多的關系
這里再說一下重復度，其實看完了上面的描述之后，我們應該清楚了各個關系間的關系以及具體對應到代碼是怎么樣的，所謂的重復度，也只不過是上面的擴展，例如A和B有着“1對多”的重復度，那在A中就有一個列表，保存着B對象的N個引用，就是這樣而已。
形式：依賴/關聯, 組合/聚合,繼承/實現
Dependency /Association,Composition/ Aggregation,Generalization/Realization
關聯-屬性指針-associate
- 雙向關聯-相互關聯，
** 相互把對方作為自己的指針**
C1-C2：指雙方都知道對方的存在，都可以調用對方的公共屬性和方法。
在GOF的設計模式書上是這樣描述的：雖然在分析階段這種關系是適用的，但我們覺得它對於描述設計模式內的類關系來說顯得太抽象了，因為在設計階段關聯關 系必須被映射為對象引用或指針。對象引用本身就是有向的，更適合表達我們所討論的那種關系。所以這種關系在設計的時候比較少用到，關聯一般都是有向的。
使用ROSE 生成的代碼是這樣的：
class C1{
public C2 theC2;
}
class C2 {
public C1 theC1;
}
雙向關聯在代碼的表現為雙方都擁有對方的一個指針，當然也可以是引用或者是值。
- 單向關聯-關聯到它就把它當做自己的屬性指針
C3->C4：表示相識關系，指C3知道C4，C3可以調用C4的公共屬性和方法。
沒有生命期的依賴。一般是表示為一種引用
生成代碼如下：
class C3{
public C4 theC4;
}
class C4{
}
單向關聯的代碼就表現為C3有C4的指針，而C4對C3一無所知。
- 自身關聯（反身關聯）-關聯到自己，就是把自己當做屬性指針
自己引用自己，帶着一個自己的引用
代碼如下：
class C5{
public C5 theC5;
}
就是在自己的內部有着一個自身的引用。
2.依賴-依賴
就把它的指針或引用，作為自己的函數形參-dependency
(1)單向依賴
依賴:
指C5可能要用到C6的一些方法，也可以這樣說，要完成C5里的所有功能，一定要有C6的方法協助才行。C5依賴於C6的定義，一般是在C5類的頭文件中包含了C6的頭文件。ROSE對依賴關系不產生屬性。
注意，要避免雙向依賴。一般來說，不應該存在雙向依賴。
ROSE生成的代碼如下：
class C6
{
public void Func(C7 *pC7Obj);
}
class C7
{
}
(2)雙向依賴
雙向依賴關系圖沒有看到標准的畫法，知道時候補上。
那依賴和聚合\組合、關聯等有什么不同呢？
- 關聯是類之間的一種關系，例如老師教學生，老公和老婆，水壺裝水等就是一種關系。這種關系是非常明顯的，在問題領域中通過分析直接就能得出。
- 依賴是一種弱關聯，只要一個類用到另一個類，但是和另一個類的關系不是太明顯的時候（可以說是“uses”了那個類），就可以把這種關系看成是依賴，依賴 也可說是一種偶然的關系，而不是必然的關系，就是“我在某個方法中偶然用到了它，但在現實中我和它並沒多大關系”。例如我和錘子，我和錘子本來是沒關系 的，但在有一次要釘釘子的時候，我用到了它，這就是一種依賴，依賴錘子完成釘釘子這件事情。
組合是一種整體-部分的關系，在問題域中這種關系很明顯，直接分析就可以得出的。例如輪胎是車的一部分，樹葉是樹的一部分，手腳是身體的一部分這種的關系，非常明顯的整體-部分關系。
上述的幾種關系（關聯、聚合/組合、依賴）在代碼中可能以指針、引用、值等的方式在另一個類中出現，不拘於形式，但在邏輯上他們就有以上的區別。
這里還要說明一下，所謂的這些關系只是在某個問題域才有效，離開了這個問題域，可能這些關系就不成立了，例如可能在某個問題域中，我是一個木匠，需要拿着 錘子去干活，可能整個問題的描述就是我拿着錘子怎么釘桌子，釘椅子，釘櫃子；既然整個問題就是描述這個，我和錘子就不僅是偶然的依賴關系了，我和錘子的關 系變得非常的緊密，可能就上升為組合關系（讓我突然想起武俠小說的劍不離身，劍亡人亡...）。這個例子可能有點荒謬，但也是為了說明一個道理，就是關系 和類一樣，它們都是在一個問題領域中才成立的，離開了這個問題域，他們可能就不復存在了
3.組合/聚合-屬性對象-composite/aggreate
(1)組合-自己是實心的，去組合它，把它當做自己的屬性對象，只是被組合的類不會單獨存在(自己構造函數中使用)
組合（也有人稱為包容）：一般是實心菱形加實線箭頭表示，如上圖所示，表示的是C8被C7包容，而且C8不能離開C7而獨立存在。但這是視問題域而定的， 例如在關心汽車的領域里，輪胎是一定要組合在汽車類中的，因為它離開了汽車就沒有意義了。但是在賣輪胎的店鋪業務里，就算輪胎離開了汽車，它也是有意義 的，這就可以用聚合了。
在《敏捷開發》中還說到，A組合B，則A需要知道B的生存周期，即可能A負責生成或者釋放B，或者A通過某種途徑知道B的生成和釋放。
他們的代碼如下：
class C8
{
public C9 theC9;
}
class C9
{
}
可以看到，代碼和聚合是一樣的。具體如何區別，可能就只能用語義來區分了。
(2)聚合-自己空心的，去聚合它，把它當做自己的屬性對象，被聚合的類可以單獨存在(自己構造函數中不使用)
當類之間有整體-部分關系的時候，我們就可以使用組合或者聚合。
聚合：表示C9聚合C10，但是C10可以離開C9而獨立存在（獨立存在的意思是在某個應用的問題域中這個類的存在有意義。這句話怎么解，請看下面組合里的解釋）。
代碼如下：
class C10
{
public C11 theC11;
}
class C11
{
}
總結聚合和組合：
問題域的語義上：組合中被組合類單獨存在沒有意義; 聚合中被聚合類在可以有單獨存在的意義。
生命期上：組合中必須要負責被組合類的生命期; 聚合中可不負責被聚合類的聲明期，可以由外部程序來創建和消亡（可用賦值）。
4.泛化和實現 derived/implement
(1)繼承（Derived）-子對象指向父對象
泛化關系：如果兩個類存在泛化的關系時就使用，例如父和子，動物和老虎，植物和花等。
ROSE生成的代碼很簡單，如下：
class C12 extends C13
{
}
(2)接口實現（implement）
實現關系指定兩個實體之間的一個合約。換言之，一個實體定義一個 合約 ，而另一個實體保證履行該合約 。
轉自http://blog.csdn.net/blues1021/article/details/45739941