有一個例子來解釋UML中的關聯。聚合或組合或簡單的關聯？
一個人在一家公司工作;一家公司有多個辦事處。
但我無法理解Person，Company和Office類之間的關係。我的理解是：
但我不確定第二點。如果我錯了，請糾正我。
謝謝。
爲什麼在這種情況下使用組合或聚合？ UML規範給建模者留下了聚合的含義。你希望它對觀衆意味着什麼？對於這種情況，構圖的意義可能太強大了。那麼，爲什麼在這裏使用它？我建議你使用一個簡單的關聯。
如果我是你，我會更真實地解決問題領域。在我所知的世界裏，當公司停業時，辦事處不會停止存在。相反，公司佔用某些數量的辦公室一段有限的時間。如果一家公司倒閉，這些辦事處被出售或出租給其他公司。辦事處不會燒燬在地上。
如果您在應用程序中的問題域不正確，那麼當客戶「更改該應用程序的需求」時，所採用的快捷方式將變爲無效。問題域實際上並沒有太大的改變，只是你允許採取的捷徑。如果您採用快捷方式以與問題域錯開的方式滿足要求，則調整應用程序的開銷很大。你的客戶變得不開心，你會加班加點。爲自己和每個人保存麻煩！
雖然Jim的回答是正確的，但我想添加一些額外的信息。還有用於聚集
在第一種情況下，兩個主要用途它給出了一個暗示多久對象應居住。這與內存使用情況直接相關。如果目標語言（如大多數現代語言）使用垃圾收集器，則可以簡單地忽略此模型信息。
在第二種情況下，這只是部分記憶問題。數據庫中的合成聚合指示聚合元素需要與聚合元素一起刪除。這不是一個記憶，但在大多數情況下是一個安全問題。所以在這裏你必須考慮三次。
然而，共享聚合在所有情況下都具有非常深奧的含義。
您是對問題域還是解決方案域進行建模？這很重要。 –
這有什麼關係？我正在執行給定陳述的解決方案。 – RashiR
問題域模型代表真實世界。在現實世界中，當一家公司倒閉時，各局不會停止存在。由於您正在對解決方案域進行建模，因此您可以自由地爲特定應用程序採取某些快捷方式。但是，您可能會因爲要求「改變」而後悔。 （問題領域並沒有真正改變，只有應用程序允許的快捷方式！對於你留下的問題領域更真實，以後每個人都會更開心。） –