當A類與B類具有聚合和組合關系時，如何繪制UML圖？

Question

我有兩個問題要問。 所以我們假設有一個類A和B這樣定義。

1。

class A {
    private B b;
    private B otherB;
    public A(B otherB)
    {
        this.otherB = otherB; 
    }
}
class B {
}

因此，A類與變量b具有組合關系，與變量otherB具有聚合關系。 我如何在UML圖中繪制它。

2.以下案件是否仍然是一種構成關系？

class A
{
    private B b;
    public B getMethod(){
        B newB = new B();
        newB.bValue = b.bValue;
        return newB;
    }  
}
class B
{
    private int bValue;
}

Answer 1

1. 正如其他評論/回復所指出的那樣，不存在在同一類之間具有不同關聯（組成與否）的問題。

2. 從實現的角度來看（這也適用於上一個問題），您需要了解組合關聯的含義 。

基本上，如果我們有實例規范a1和a2 （作為類A的實例），那么只有其中一個可以通過復合關聯的角色（關聯結束）“composesB”組成實例b1 （作為類B的實例） 。

同樣，假設a1通過復合關聯的“composesB”角色組成b1 ，每次a1被“銷毀”時， b1也應該被“銷毀”。 相反，如果a1對象通過聚合關聯的“aggregatesB”角色聚合b1 ，則不會發生這種情況。

您可以想象，從實現的角度來看，您需要的不僅僅是字段和類中的簡單方法，以支持兩個類之間的復合關聯。

更新：包含一個示例。

例如，EMF是EMOF規范（它不是UML）的實現，其中包含引用的概念（類似於復合關聯的概念）可以描述如下。 在我們的特定情況下：

遠離技術細節，當您將A實例設置為A實例對象的一部分（包含，組合）時，您可能會意識到這一點。 您首先必須通過相同的包含引用檢查前者是否可能包含在不同的A實例中，如果是這樣，則需要從舊的A實例中刪除此類實例。

Answer 2

1. 事實上， 在類之間創建多個關聯是合法的。 建議在您執行此操作時為每個關系分配一個角色。

2. 我要說是的，這仍然是一種構成關系（盡管其他人可能不同意）。 為了說明我的情況，我們看一下簡單的IBM 定義，顯示由Schedule組成的Student（可能是其他的東西）。 很容易想象，還會有一個由附表組成的教師，教師可能想要獲得學生的時間表，反之亦然。 另一個類獲得一個附表是否會使作文關系無效？ 我想不是; 或者至少，IBM的定義似乎並不那么狹隘以至於排除了這種可能性。