構成和聚合關係的問題UML

我在UML中遇到了一些Composition和Aggregation關係的問題，我確實理解整體/部分關係，所以如果一個類不能存在而沒有整體，那麼它會使它成爲一個強大的合成關係，如果它仍然可以存在而沒有整體，那麼它就會成爲一個弱聚集關係。構成和聚合關係的問題UML

然而，當處理真正的軟件需求時，有時候它會變得更棘手。我有下面包括它們都正確UML標準顯示的所有必要的，屬性，操作和屬性但是我不確定我的關係的類圖：

1接口和6類

可能有人確認，如果我的關係是否正確？

非常感謝

來源

2014-01-19 Ryman Holmes

有幾個問題。組成的最好例子是迷宮到位。您的連接器在錯誤的一端有鑽石。由其他班級組成的班級有鑽石，所以迷宮由地點組成。迷宮應該有鑽石。物種 - 蛇的關係是可疑的，因爲除蛇之外還有許多物種，物種不包括蛇。我也不認爲探險家是由石頭組成的。探索石之間的關係是直截了當的（如果我理解你的應用）1對多關係。我還會在圖表中添加多重性以澄清1：1，1：很多等。請更正您的圖表並重新發布。

來源

2014-01-19 14:17:23 Bruce

我可以問一下，當找到兩個類之間的關係時，如果一個類聲明'Snake'有一個'Species'類型的字段，那麼它會產生什麼效果呢？是我們應該看的實際代碼或類的目的和名稱？ –

如果物種是一類，蛇有一個田間類型的物種，那麼它可能是一條蛇n --- 1種物種的關係。不聚集或組成。只是多對一的關係。這是假設可能有一個動物園應用程序，可能有許多相同物種的蛇。 – Bruce

Snake在概念上是物種，所以這種關係應該是具體的繼承，具體來說Snake擴展了物種。 – Ronald

反之亦然。黑色的菱形應該在側面，可以保持或僅僅是來自連接另一側的一組物體。

另外一個居住者可以存在沒有位置（冒險之前的探險家），所以它相當聚合依賴，而不是組成。至於迷宮，迷宮是地點的組成部分，好的。資源管理器對石頭的依賴又是聚合 - 石頭可以輕鬆地沒有資源管理器。

此外，我不確定石頭應該直接從乘客身上下降。我會定義CaveObject類（因爲Object已經很忙），並且從中得到Stone和Occupant，以及從最後一個派生出Snake和Explorer。我會添加一個界面TemporaryOccupant，並讓Explorer來實現它。在那個界面中，我將把函數從一個位置移動到另一個位置。

至於物種/蛇，恐怕我迷路了 - 屬於什麼？相反，物種應該是另一個界面，蛇和探索者也應該實現它。

順便說一句，我在這裏看到另一個錯誤：你連接Snake和物種 - 它是其他類的屬性已經與另一個類的類型。不要將其聲明爲類矩形中的多個參數。

您的資源管理器只有名稱的getter，但沒有Setter。你的drop（）沒有參數來設置將被刪除的內容。

來源

2014-01-20 09:11:32 Gangnus

構成和聚合關係的問題UML

回答

相關問題