Notazioni del diagramma di classe UML: differenze tra associazione, aggregazione e composizione

Sono confuso su alcune delle notazioni dei diagrammi di classe UML.

Abbastanza sicuro di sapere cosa significhi Associazione . Qualsiasi relazione tra istanze di due classi, in cui un'istanza di una classe deve conoscere un'istanza della seconda classe per eseguire il suo lavoro - è una relazione di associazione. Un'associazione spesso indica che la classe A ha un riferimento (campo) a un'istanza di classe B.

Tuttavia, ho difficoltà a capire cosa significano le frecce Aggregazione e Composizione . Parte della mia confusione è stata causata dall'incontro con diverse definizioni di queste notazioni.

Due definizioni della notazione di aggregazione :

Definizione 1: Una notazione di aggregazione tra due classi è adatta ogni volta che un'istanza di classe A contiene una raccolta di istanze di classe B (ad esempio un elenco, una matrice, qualunque cosa).

Definizione 2: un collegamento di aggregazione tra due classi è adatto se un'istanza di classe A contiene un riferimento a un'istanza di classe B e l'istanza B dipende dal ciclo di vita dell'istanza A. Significato: quando viene cancellata l'istanza della classe A, anche l'istanza della classe B. L'istanza della classe B è interamente contenuta dall'istanza della classe A, al contrario dell'istanza della classe A che possiede semplicemente un riferimento all'istanza di classe B (che è normale associazione).

Per quanto riguarda il significato della notazione di composizione e il modo in cui differisce dalla notazione di aggregazione, non sono sicuro.

Per favore chiarisci le definizioni e aiutami a capire. Esempi concreti sarebbero benvenuti.

I tre collegamenti Associazione, Aggregazione e Composizione formano una sorta di scala su quanto due classi sono strettamente correlate tra loro.

All'estremità della scala c'è l'Associazione, in cui gli oggetti delle due classi possono conoscersi a vicenda, ma non si influenzano a vicenda. Gli oggetti possono esistere indipendentemente e quale oggetto di classe A conosce quali oggetti di classe B possono variare nel tempo.

All'altra estremità della scala, c'è Composizione. La composizione rappresenta una relazione parte - intera tale che la classe B è parte integrante della classe A. Questa relazione viene in genere utilizzata se gli oggetti della classe A non possono esistere logicamente senza avere un oggetto di classe B.

La relazione di aggregazione è da qualche parte tra queste due estremità, ma nessuno sembra concordare esattamente dove, quindi non esiste una definizione universalmente concordata di cosa significhi un'aggregazione. In tal senso, entrambe le definizioni che hai trovato sono corrette e se chiedi a 10 persone, rischi di ottenere 11 definizioni diverse.

La composizione è quando un object Acontiene object Bed object Aè anche responsabile della creazione di object B.

Relazione di composizione

Abbiamo una classe A che verrà utilizzata dalla classe B.

final class A
{
}

Esistono più opzioni per l'aspetto della composizione.

Composizione di inizializzazione diretta:

final class B
{
    private $a = new A();
}

Composizione di inizializzazione del costruttore

final class B
{
    private $a;

    public function __construct()
    {
        $this->a = new A();
    }
}

Composizione di inizializzazione lenta

final class B
{
    private $a = null;

    public function useA()
    {
        if ($this->a === null) {
            $this->a = new A();
        }

        /* Use $this->a */
    }
}

Vedete, questo crea una stretta relazione tra le classi Ae B. La classe Bsemplicemente non può esistere senza A. Questa è un'enorme violazione del principio di iniezione di dipendenza , che dice:

Una dipendenza è un oggetto che può essere utilizzato (un servizio). Un'iniezione è il passaggio di una dipendenza a un oggetto dipendente (un client) che lo userebbe. Il servizio fa parte dello stato del client. Passare il servizio al client, piuttosto che consentire a un client di creare o trovare il servizio, è il requisito fondamentale del modello.

La composizione a volte ha un senso, come chiamare new DateTimein php o new std::vector<int>in C ++. Ma il più delle volte, è un avvertimento, che la progettazione del codice è errata.

In un caso in cui class Asarebbe un oggetto speciale utilizzato per la memorizzazione nella cache, class Bverrà sempre memorizzato nella cache utilizzando l'implementazione di class Ae non si avrebbe alcun controllo per modificarlo dinamicamente, il che è male.

Inoltre, se hai usato la composizione di inizializzazione pigra , nel senso che avresti un lavoro object B, chiamato useA()metodo e la creazione di object Afallirebbe, il tuo object Bè improvvisamente inutile.

L'aggregazione, d'altra parte, è un modo di relazione, che segue il principio DI . object Bdeve essere utilizzato object A, quindi dovresti passare l'istanza già creata di object Aa object B, e se la creazione di un object Aerrore non dovesse avvenire, in primo luogo non passerebbe nulla.

In breve, l' aggregazione è la rappresentazione UML per il principio dell'iniezione di dipendenza , sia che si tratti dell'iniezione del costruttore, dell'iniezione del setter o dell'iniezione di proprietà pubblica.

Queste sono tutte aggregazioni

L'iniezione del costruttore più stretta ( object Bnon può esistere senza object A).

final class B
{
    private $a;

    public function __construct(A $a)
    {
        $this->a = $a;
    }
}

Più sciolto (puoi usarlo o meno object Aall'interno object B, ma se lo fai, probabilmente dovresti impostarlo prima).

Tramite setter:

final class B
{
    private $a;

    public function setA(A $a)
    {
        $this->a = $a;
    }
}

Tramite proprietà pubblica:

final class B
{
    public $a;
}

Non c'è davvero un ottimo modo per giustificare l'uso di Aggregazione su Composizione, se tutto ciò che stai usando sono implementazioni concrete di classi, ma una volta che inizi a iniettare interfacce o in caso di classi astratte C ++, improvvisamente Aggregazione sarà l'unico modo per adempiere al tuo contratto.

Inoltre un estratto dell'attuale standard UML:

11.5.4 Associazioni - Semantica - Notazione

[...] Un'associazione binaria può avere un'estremità con aggregation = AggregationKind :: shared o aggregation = AggregationKind :: composite. Quando un'estremità ha aggregazione = AggregationKind :: shared viene aggiunto un diamante vuoto come ornamento terminale alla fine della linea di associazione opposta all'estremità contrassegnata con aggregation = AggregationKind :: shared. Il diamante deve essere notevolmente più piccolo della notazione del diamante per le Associazioni. Anche un'Associazione con aggregazione = AggregationKind :: composite ha un diamante all'estremità corrispondente, ma differisce per il riempimento del diamante . […]

9.5.4 Classificazione - Proprietà - Notazione

[…] A volte una proprietà viene utilizzata per modellare circostanze in cui un'istanza viene utilizzata per raggruppare un insieme di istanze; questo si chiama aggregazione. Per rappresentare tali circostanze, una Proprietà ha una proprietà di aggregazione, di tipo AggregationKind; l'istanza che rappresenta l'intero gruppo è classificata dal proprietario della proprietà e le istanze che rappresentano le persone raggruppate sono classificate in base al tipo di proprietà. AggregationKind è un'enumerazione con i seguenti valori letterali:

• none : indica che la proprietà non ha semantica di aggregazione.
• Condiviso : indica che la proprietà ha una semantica di aggregazione condivisa. La semantica precisa dell'aggregazione condivisa varia in base all'area di applicazione e al modellatore.
• Composito : indica che la Proprietà è aggregata in modo compositivo, ovvero l'oggetto composito ha la responsabilità dell'esistenza e della memorizzazione degli oggetti composti (vedere la definizione delle parti in 11.2.3). L'aggregazione composita è una forte forma di aggregazione che richiede che un oggetto parte sia incluso al massimo in un oggetto composito alla volta. Se un oggetto composito viene eliminato, tutte le sue istanze di parte che sono oggetti vengono eliminate con esso.

[...]

Ho già pubblicato una risposta su Stackoverflow .

Fondamentalmente, un'aggregazione è più forte di una semplice associazione ma gli oggetti aggregati possono continuare a "vivere" l'uno senza l'altro come con una semplice associazione.

Una composizione è persino più forte di un'aggregazione perché la classe aggregata non può essere aggregata da altre classi. La sua "vita" dipende dal contenitore.