我不確定我是否正確使用association and aggregation or composition diamond。UML類圖Association vs（Aggregation | Composition）-Diamonds
我會使用關聯的接口，因爲我不能實例化它們。像他們那樣做here例如。或者對於靜態類，原因相同。
而我只用於可以實例化的對象的鑽石。像普通班一樣。
但我不確定這是否是區分它們的正確方法，因爲如果您再次使用check，則會看到它們沒有如此具體。在UML 2.3 specification我無法出去更多，所以你如何使用它？
還有第三種方式，用虛線表示的箭頭<>箭頭，但是我沒有使用膠水的時候使用這個。所以也許你也可以幫助我呢？
我會使用關聯的接口，因爲我不能實例化它們。就像他們在這裏舉例說明的一樣。或者對於靜態類，原因相同。
而我只用於可以實例化的對象的鑽石。像普通班一樣。
這不是他們真正的工作方式。這三種形式（關聯，聚合和組合）定義了關於關係的不同屬性。雖然可以與接口相關，但所有這三者通常在類之間使用。關聯和組合是最簡單的兩個：
聚合（空心菱形）坐在中間的某個位置。這有點像構圖 - 除非它不強制上述屬性。我不親自使用它。語義太不清楚了，因爲它是值得的。
而且還有第三種方式，用虛線表示的箭頭<>箭頭，但是我沒有使用這種粘合劑。
我認爲你的意思是依賴關係。這是一種較弱的聯合形式。作爲一個例子，取下面的類定義
class Foo {
def bar(Baz: aParam) {
...
}
}
在這種情況下Foo類型具有從其在酒吧（）方法的簽名使用上型巴茲的依賴性。然而，它們之間沒有關聯（不能明智地討論例如Foo的實例和Baz的實例之間的關係的基數）。
從實用的角度來看，我會說：
hth。
讓我們來設置條款。聚合是UML標準中的一個元語言，並且意味着BOTH構成和共享聚合，簡稱爲共享。通常它被錯誤地命名爲「聚合」。它是壞的，因爲構圖也是一個聚合。據我所知，你的意思是「共享」。
此外從UML標準：
複合 - 指示該屬性被聚集複合地， 即，複合物具有用於存在和 存儲所構成的對象（零件）的責任。
所以，大學cathedras關聯是一種組合物，因爲cathedra的不存在出來大學（IMHO）的
共享聚合的精確語義因應用領域和 建模而變化。
也就是說，如果您只遵循您的或其他人的某些原則，則所有其他關聯都可以繪製爲共享聚合。也看here。
不客氣。 – sfinnie