在這裏，我與另一個關於聚合和關聯的問題。我想學習一些UML的基礎知識，所以我開始閱讀Martin Fowler的「UML蒸餾」。我讀了關於課程的兩章，還有一件事情我不能完全理解，我認爲這是聚合與關聯。在這本書中有這樣的引用：UML聚合與協會
在UML之前的日子裏，人們通常對聚合和什麼是關聯是什麼都很模糊。無論模糊與否，他們總是與其他人不一致。因此，許多建模者認爲聚合很重要，儘管原因不同。所以UML 包括聚合（圖5.3），但幾乎沒有任何語義。正如Jim Rumbaugh所說：「想象一下 是一種模擬安慰劑」[Rumbaugh，UML Reference]。
當我從這個報價和我的堆棧溢出閱讀主題的理解並不重要的這兩個關係我使用的一個，他們的意思是bassicly相同，或有任何情況下的使用聚合而不是關聯會是合理的和/或我不能改變一個到另一個而不改變類圖的「含義」？
我在問這個問題，因爲這本書是從2003年開始的，有些東西可能會在這幾年中發生變化。
魯博的語句是最有說服力的和Uncle Bob的好建議。正如我所說的elsewhere，Aggregation在語義上很弱以至於沒有提供任何實際的益處。它只有一個有效的角落案例（遞歸關係的非循環），但很少有人知道並理解這一點。所以你最終不得不在評論中指出。
我只是不使用它。並從未感到任何損失。堅持簡單的二元關聯，關注真正重要的事情 - 獲得基數和命名權。與嘗試確定不可判定的關聯與聚合相比，你會得到更多的結果。
hth。
也許這可以幫助你，但我不認爲你會找到最完美的解釋：
不同的是蘊涵之一。聚合表示全部/部分關係，而關聯則不表示關係。然而， 可能在實施兩種關係 的方式上有很大差異。也就是說，查看代碼 並確定特定關係是否應該是聚合或關聯是非常困難的。由於這個原因， 完全忽略聚合關係是非常安全的。
[Robert C. Martin | UML]
和每個情況的例子：
一）協會是一個關係，其中所有的對象都有自己的生命週期 並沒有主人。讓我們舉一個老師和 學生的例子。多個學生可以與單個教師關聯，並且單個學生可以與多個教師關聯，但對象之間不存在所有權並且都具有其自己的生命週期。 都可以獨立創建和刪除。
b）聚合是一種特殊的關聯形式，其中所有對象都有自己的生命週期，但存在所有權和子對象不能屬於另一個父對象。我們以部門和教師的 爲例。單個教師不能屬於 多個部門，但是如果我們刪除部門，教師對象 不會被銷燬。我們可以考慮「有一個」的關係。
[Maesh | GeeksWithBlogs]
有趣，但關於第二個例子，我認爲如果我們將聚合與關聯交換，仍然不會有任何區別，這一切歸結爲個人喜好和圖表的可讀性？ – Andna 2012-03-09 21:25:47
你怎麼能告訴*關係是否是整體/部分？ – reinierpost 2012-03-13 09:07:05
可能有用http://www.uml-diagrams.org/association.html#aggregation – Jekis 2015-07-31 09:01:36
在UML聚合中定義不明確，因爲它們沒有任何明確定義的語義。 聚合的一個有效用例是幾個類的封裝，如Eric Evans的「Domain Driven Design」中所述。
E.g.一輛車有四個輪子。 對於每輛車，您可能需要計算每個車輪驅動的總米數。 這個計算是由汽車實體完成的，因爲它知道它有哪個車輪，而且你不關心哪個車輪屬於哪輛車。
汽車是所有零件的聚合根部，例如車輪，並且您無法從聚合體外部訪問汽車零部件，只是根部。
所以基本上一個聚合封裝了一組屬於彼此的類。
UML組成在語義上更接近DDD的聚合。 DDD聚合具有一些非常明確的語義（甚至比UML組合更強）。當然比UML聚合更強大。不幸的是，這些術語不匹配:-( – sfinnie 2012-03-12 20:47:42
我傾向於使用Aggregation來顯示與具有一大區別的組合相同的關係：包含的類不負責所包含對象的生命週期。通常，將一個（非空）指針或對要包含的對象的引用傳遞給包含類的構造函數。包含對象在其生命週期期間取決於所包含的對象。如果沒有包含的對象，包含對象就無法完成它的工作。這是我對Aggregation暗示的「部分/整體」關係的解釋。
「包含對象無法完全地在沒有包含對象的情況下完成它的工作」。對於關聯和某些窗體依賴關係，這是否也適用？ – Jupiter 2013-09-10 16:15:55
他們不是這個意思！我可以這樣說：
關聯關係：一個類引用另一個類。其實它表明一個班級與另一個班級有關，但他們 不一定具有顯示這種關係的屬性......例如 '教師'和'學生'班級，雖然'教師'班級沒有 屬性，指的是學生，但我們確實知道，實際上 老師確實有學生......並且「學校」班也有'老師'和' ''學生'屬性，現在讓這兩個類別與其他每個 相關。
聚合關係：一個類包含另一個類。但是如果容器（ClassRoom）被銷燬，則包含的（Chair）不是。 其實ClassRoom擁有主席。聚合關係比關係關係更強烈。
這裏也是關於它和整個UML2的教程。0，這說明了一切方便，簡單，你可能會發現它有用：https://github.com/imalitavakoli/learn-uml2
提示：也讓我提，因爲關聯關係類大部分的時間之間存在，我們有時不把它畫到避免不必要的複雜
實施明智沒有太大的區別，但概念上有很大的不同：聚合用於表示層次結構。當您使用組件的層次那裏工作，你需要有根接口某些類型的操作：在層次
與協會打交道時，大多數這些操作是不需要的。
這個詞經常會感到困惑。
聚合和組合是一些類型的關聯。有 幾乎期間 實現聚合和協會之間的差異，很多人會完全跳過聚集關係， 他們與關聯關係圖。
你可以從這個比喻的想法。
類：A（人）和等級：B（汽車）具有關聯關係，如果 類：阿具有等級：B聲明，並且還類別： B（汽車）對象不是必需創建等級：A（人）對象。
類：A（汽車）和等級：B（輪胎）具有聚合關係，如果 類：阿具有等級：B聲明，並且還等級：B（輪胎）目的是必不可少創建類：A（汽車）對象。
乾杯！
要添加，我只想建議從OMG網站下載UML規範：最好的參考，並請參閱第110
沒有表明Property沒有聚集語義。
shared指示該屬性具有共享聚合語義。精確的共享聚合語義因應用領域和建模者而異。
composite指示該屬性是複合聚合的，即複合對象對組合對象的存在和存儲負責（參見11.2.3中的部分定義）。
對組成鏈接有什麼想法？ – Dennis 2013-06-01 08:19:20
@ Dennis：與Aggregation不同，Composition具有明確定義的語義，可以將其與直接二元關聯區分開來。更多在這裏：http://stackoverflow.com/questions/7834052/uml-class-diagram-association-vs-aggregation-composition-diamonds/7836357#7836357 – sfinnie 2013-06-03 07:44:32