Qual è la differenza tra associazione, aggregazione e composizione?

Qual è la differenza tra associazione, aggregazione e composizione? Spiegare in termini di implementazione.

Per due oggetti Fooe Barle relazioni possono essere definite

Associazione - Ho una relazione con un oggetto. FoousiBar

public class Foo { 
    void Baz(Bar bar) {
    } 
};

Composizione - Possiedo un oggetto e sono responsabile della sua vita. Quando Foomuore, così faBar

public class Foo {
    private Bar bar = new Bar(); 
}

Aggregazione - Ho un oggetto che ho preso in prestito da qualcun altro. Quando Foomuore, Barpuò vivere.

public class Foo { 
    private Bar bar; 
    Foo(Bar bar) { 
       this.bar = bar; 
    }
}

So che questa domanda è etichettata come C # ma i concetti sono domande piuttosto generiche come questo reindirizzamento qui. Quindi fornirò il mio punto di vista qui (un po 'di parte dal punto di vista di Java dove mi trovo più a mio agio).

Quando pensiamo alla natura orientata agli oggetti, pensiamo sempre agli oggetti, alla classe (progetti di oggetti) e alla relazione tra loro. Gli oggetti sono correlati e interagiscono tra loro tramite metodi. In altre parole, l'oggetto di una classe può utilizzare servizi / metodi forniti dall'oggetto di un'altra classe. Questo tipo di relazione è definita associazione. .

Aggregazione e composizione sono sottoinsiemi di associazioni nel senso che sono casi specifici di associazione.

• Sia nell'aggregazione che nella composizione, l' oggetto di una classe "possiede" l'oggetto di un'altra classe .
• Ma c'è una sottile differenza. In Composizione l'oggetto della classe che appartiene all'oggetto della sua classe proprietaria non può vivere da solo (chiamato anche "relazione di morte"). Vivrà sempre come parte del suo oggetto proprietario dove come in Aggregazione l'oggetto dipendente è autonomo e può esistere anche se l'oggetto della classe proprietaria è morto.
• Quindi, nella composizione, se il possesso di un oggetto è un garbage collection, anche l'oggetto posseduto non sarà il caso in aggregazione.

Confuso?

Esempio di composizione : considera l'esempio di un'auto e di un motore che è molto specifico per quell'auto (nel senso che non può essere utilizzata in nessun'altra auto). Questo tipo di relazione tra Car e la classe SpecificEngine si chiama Composizione. Un oggetto della classe Car non può esistere senza un oggetto della classe SpecificEngine e l'oggetto di SpecificEngine non ha significato senza la classe Car. In parole povere, la classe Car "possiede" solo la classe SpecificEngine.

Esempio di aggregazione : ora considera la classe Car e la classe Wheel . L'auto ha bisogno di un oggetto ruota per funzionare. Ciò significa che l'oggetto Car possiede l'oggetto Wheel ma non possiamo dire che l'oggetto Wheel non abbia alcun significato senza l'oggetto Car. Può benissimo essere utilizzato in una bici, camion o diversi oggetti auto.

Riassumendo -

Per riassumere l'associazione è un termine molto generico usato per rappresentare quando una classe usa le funzionalità fornite da un'altra classe. Diciamo che è composizione se un oggetto classe genitore possiede un altro oggetto classe figlio e quell'oggetto classe figlio non può esistere in modo significativo senza l'oggetto classe genitore. Se può, allora si chiama Aggregazione.

Maggiori dettagli qui. Sono l'autore di http://opensourceforgeeks.blogspot.in e ho aggiunto un link sopra al post pertinente per ulteriori contesti.

L'associazione è un concetto generalizzato di relazioni. Include sia la composizione che l'aggregazione.

La composizione ( miscela ) è un modo per avvolgere oggetti semplici o tipi di dati in una singola unità . Le composizioni sono un componente fondamentale di molte strutture di dati di base

L'aggregazione ( raccolta ) differisce dalla composizione ordinaria in quanto non implica la proprietà. Nella composizione, quando l'oggetto proprietario viene distrutto, lo sono anche gli oggetti contenuti. Nel complesso, questo non è necessariamente vero.

Entrambi indicano una relazione tra oggetto e differiscono solo per la loro forza.

Trucco per ricordare la differenza: ha A - A ggregation e O wn - c O mpositoin

Ora osserviamo la seguente immagine

Analogia:

Composizione : la seguente immagine è la composizione delle immagini, ovvero l'uso di singole immagini per creare un'immagine.

Aggregazione : raccolta di immagini in un'unica posizione

Ad esempio, un'università possiede vari dipartimenti e ogni dipartimento ha un numero di professori. Se l'università chiuderà, i dipartimenti non esisteranno più, ma i professori in quei dipartimenti continueranno ad esistere. Pertanto, un'università può essere vista come una composizione di dipartimenti, mentre i dipartimenti hanno un'aggregazione di professori. Inoltre, un professore potrebbe lavorare in più di un dipartimento, ma un dipartimento non potrebbe far parte di più di un'università.

Dipendenza (riferimenti)
Significa che non esiste un collegamento concettuale tra due oggetti. ad es. riferimenti agli oggetti EnrollmentService Oggetti per studenti e corsi (come parametri del metodo o tipi di ritorno)

public class EnrollmentService {
    public void enroll(Student s, Course c){}
}

Associazione (has-a)
Significa che esiste quasi sempre un collegamento tra gli oggetti (sono associati). L'oggetto ordine ha un oggetto cliente

public class Order {
    private Customer customer
}

Aggregazione (has-a + parte intera) Tipo
speciale di associazione in cui esiste una relazione parte intera tra due oggetti. potrebbero vivere l'uno senza l'altro però.

public class PlayList{
    private List<Song> songs;
}

Nota: la parte più difficile è quella di distinguere l'aggregazione dalla normale associazione. Onestamente, penso che questo sia aperto a diverse interpretazioni.

Composizione (ha-a + parte intera + proprietà) Tipo
speciale di aggregazione. An Apartmentè composto da alcuni Rooms. A Roomnon può esistere senza un Apartment. quando viene eliminato un appartamento, vengono eliminate anche tutte le stanze associate.

public class Apartment{
    private Room bedroom;
    public Apartment() {
       bedroom = new Room();
    }
}

Da un post di Robert Martin in comp.object :

L'associazione rappresenta la capacità di un'istanza di inviare un messaggio a un'altra istanza. Questo è in genere implementato con un puntatore o una variabile di istanza di riferimento, sebbene potrebbe anche essere implementato come argomento del metodo o la creazione di una variabile locale.

//[Example:]

//|A|----------->|B|

class A
{
  private:
    B* itsB;
};

L'aggregazione [...] è la tipica relazione intera / parte. Questo è esattamente lo stesso di un'associazione con l'eccezione che le istanze non possono avere relazioni di aggregazione cicliche (cioè una parte non può contenere il suo intero).

//[Example:]

//|Node|<>-------->|Node|

class Node
{
  private:
    vector<Node*> itsNodes;
};

Il fatto che si tratti di aggregazione significa che le istanze di Node non possono formare un ciclo. Quindi, questo è un albero di nodi, non un grafico di nodi.

La composizione [...] è esattamente come l'aggregazione, tranne per il fatto che la durata della "parte" è controllata dall'intero. Questo controllo può essere diretto o transitivo. Cioè, il "tutto" può assumersi la responsabilità diretta della creazione o della distruzione della "parte", oppure può accettare una parte già creata e successivamente passarla a qualche altro tutto che si assume la responsabilità di essa.

//[Example:]

//|Car|<#>-------->|Carburetor|

class Car
{
  public:
    virtual ~Car() {delete itsCarb;}
  private:
    Carburetor* itsCarb
};

Come altri hanno detto, un'associazione è una relazione tra oggetti, aggregazione e composizione sono tipi di associazione.

Dal punto di vista dell'implementazione, si ottiene un'aggregazione avendo un membro della classe per riferimento . Ad esempio, se la classe A aggrega un oggetto di classe B, avrai qualcosa del genere (in C ++):

class A {
    B & element;
  // or B * element;
};

La semantica dell'aggregazione è che quando un oggetto A viene distrutto, l'oggetto B che sta memorizzando esiste ancora. Quando usi la composizione, hai una relazione più forte, di solito memorizzando il membro per valore :

class A {
    B element;
};

Qui, quando un oggetto A viene distrutto, anche l'oggetto B che contiene verrà distrutto. Il modo più semplice per raggiungere questo obiettivo è archiviare il membro in base al valore, ma è anche possibile utilizzare un puntatore intelligente o eliminare il membro nel distruttore:

class A {
    std::auto_ptr<B> element;
};

class A {
    B * element;

    ~A() {
        delete B;
    }
};

Il punto importante è che in una composizione l'oggetto contenitore possiede quello contenuto, mentre in aggregazione lo fa riferimento .

È sorprendente quanta confusione esiste sulla distinzione tra i tre concetti di relazione associazione , aggregazione e composizione .

Si noti che i termini aggregazione e composizione sono stati utilizzati nella comunità C ++, probabilmente per qualche tempo prima che siano stati definiti casi speciali di associazione nei diagrammi di classe UML.

Il problema principale è il malinteso diffuso e continuo (anche tra gli sviluppatori di software esperti) che il concetto di composizione implica una dipendenza del ciclo di vita tra il tutto e le sue parti in modo tale che le parti non possano esistere senza il tutto, ignorando il fatto che ci sono anche casi di associazioni di parti intere con parti non condivisibili in cui le parti possono essere staccate e sopravvivere alla distruzione del tutto.

Per quanto posso vedere, questa confusione ha due radici:

1. Nella comunità C ++, il termine "aggregazione" è stato usato nel senso di una classe che definisce un attributo per fare riferimento a oggetti di un'altra classe indipendente (vedi, ad esempio, [1]), che è il senso di associazione nei diagrammi di classe UML. Il termine "composizione" è stato usato per le classi che definiscono oggetti componenti per i loro oggetti, in modo tale che alla distruzione dell'oggetto composito, anche questi oggetti componenti vengano distrutti.

2. Nei diagrammi di classe UML, sia "aggregazione" che "composizione" sono stati definiti casi speciali di associazioni che rappresentano relazioni parte-intere (che sono state discusse in filosofia per molto tempo). Nelle loro definizioni, la distinzione tra una "aggregazione" e una "composizione" si basa sul fatto se consente di condividere una parte tra due o più interi. Definiscono "composizioni" come parti non condivisibili (esclusive), mentre "aggregazioni" possono condividere le loro parti. Inoltre dicono qualcosa del tipo: molto spesso, ma non in tutti i casi, le composizioni hanno una dipendenza del ciclo di vita tra il tutto e le sue parti in modo tale che le parti non possano esistere senza il tutto.

Pertanto, mentre UML ha inserito i termini "aggregazione" e "composizione" nel giusto contesto (di relazioni parti intere), non sono riusciti a definirli in modo chiaro e inequivocabile, catturando le intuizioni degli sviluppatori. Tuttavia, questo non è sorprendente perché ci sono così tante proprietà diverse (e sfumature di implementazione) che queste relazioni possono avere e gli sviluppatori non sono d'accordo su come implementarle.

Vedi anche la mia risposta estesa alla domanda SO di aprile 2009 elencata di seguito.

E la proprietà che si presumeva definisse la "composizione" tra oggetti OOP nella comunità C ++ (e questa convinzione è ancora ampiamente diffusa): la dipendenza del ciclo di vita di runtime tra i due oggetti correlati (il composito e il suo componente) è non proprio caratteristico per la "composizione" perché possiamo avere tali dipendenze a causa dell'integrità referenziale anche in altri tipi di associazioni.

Ad esempio, il seguente modello di codice per "composizione" è stato proposto in una risposta SO :

final class Car {    
  private final Engine engine;

  Car(EngineSpecs specs) {
    engine = new Engine(specs);
  }

  void move() {
    engine.work();
  }
}

Il convenuto ha affermato che sarebbe caratteristico per la "composizione" che nessun'altra classe potrebbe fare riferimento / conoscere il componente. Tuttavia, questo non è certamente vero per tutti i possibili casi di "composizione". In particolare, nel caso di un motore di un'auto, il produttore dell'auto, eventualmente implementato con l'aiuto di un'altra classe, potrebbe dover fare riferimento al motore per poter contattare il proprietario dell'auto ogni volta che c'è un problema con esso.

[1] http://www.learncpp.com/cpp-tutorial/103-aggregation/

Appendice - Elenco incompleto di domande ripetute sulla composizione rispetto all'aggregazione su StackOverflow

[ Apr 2009 ]
Aggregazione contro composizione [chiusa principalmente come opinione di]
[ aprile 2009 ]
Qual è la differenza tra la composizione e la relazione di associazione?
[ Maggio 2009 ]
Differenza tra associazione, aggregazione e composizione
[ Maggio 2009 ]
Qual è la differenza tra composizione e aggregazione? [duplicato]
[ ott 2009 ]
Qual è la differenza tra aggregazione, composizione e dipendenza? [contrassegnato come duplicato]
[ nov 2010 ]
Association vs. Aggregation [contrassegnato come duplicato]
[Ago 2012 ]
Differenza di implementazione tra aggregazione e composizione in Java
[ feb 2015 ]
UML - associazione o aggregazione (semplici frammenti di codice)

Associazione

L'associazione rappresenta la relazione tra due classi. Può essere unidirezionale (unidirezionale) o bidirezionale (bidirezionale)

per esempio:

1. unidirezionale

Il cliente effettua gli ordini

2. bidirezionale

A è sposato con B

B è sposato con A

Aggregazione

L'aggregazione è un tipo di associazione, ma con caratteristiche specifiche. L'aggregazione è la relazione in una classe "intera" più grande contiene una o più classi "parti" più piccole. .

per esempio:

il club ha membri

Un club ("intero") è composto da più membri del club ("parti"). I membri hanno vita all'esterno del club. Se il club ("intero") dovesse morire, i membri ("parti") non morirebbero con esso. Perché i membri possono appartenere a più club ("interi").

Composizione

Questa è una forma più forte di aggregazione. "Intero" è responsabile della creazione o distruzione delle sue "parti"

Per esempio:

Una scuola ha dipartimenti

In questo caso la scuola ("intera") sarebbe morta, il dipartimento ("parti") sarebbe morto con essa. Perché ogni parte può appartenere a un solo "intero".

È importante capire perché dovremmo anche preoccuparci di usare più di una linea di relazione. Il motivo più ovvio è descrivere la relazione genitore-figlio tra le classi (quando il genitore ha eliminato tutti i suoi figli vengono eliminati di conseguenza), ma più impotentemente, vogliamo distinguere tra associazione semplice e composizione al fine di porre restrizioni implicite sulla visibilità e propagazione delle modifiche alle classi correlate, una questione che svolge un ruolo importante nella comprensione e nella riduzione della complessità del sistema.

Associazione

Il modo più astratto per descrivere la relazione statica tra le classi è utilizzare il collegamento Associazione, che afferma semplicemente che esiste un qualche tipo di collegamento o una dipendenza tra due o più classi.

Associazione debole

ClassA può essere collegata a ClassB per mostrare che uno dei suoi metodi include un parametro dell'istanza ClassB o restituisce un'istanza di ClassB.

Associazione forte

ClassA può anche essere collegata a ClassB per dimostrare che contiene un riferimento all'istanza di ClassB.

Aggregazione (associazione condivisa)

Nei casi in cui esiste una parte della relazione tra ClassA (intera) e ClassB (parte), possiamo essere più specifici e utilizzare il collegamento di aggregazione anziché il collegamento di associazione, evidenziando che ClassB può anche essere aggregata da altre classi nell'applicazione ( pertanto l'aggregazione è anche nota come associazione condivisa).

È importante notare che il collegamento di aggregazione non indica in alcun modo che ClassA possiede ClassB né che esiste una relazione genitore-figlio (quando il genitore ha eliminato tutti i suoi figli vengono eliminati di conseguenza) tra i due. In realtà, al contrario! Il collegamento di aggregazione solitamente utilizzato per sottolineare il fatto che ClassA non è il contenitore esclusivo di ClassB, poiché in realtà ClassB ha un altro contenitore.

Aggregazione vs associazione Il collegamento di associazione può sostituire il collegamento di aggregazione in ogni situazione, mentre l'aggregazione non può sostituire l'associazione in situazioni in cui esiste solo un "collegamento debole" tra le classi, cioè ClassA ha metodi che contengono parametri di ClassB ma ClassA no contenere riferimento all'istanza di ClassB.

Martin Fowler suggerisce che il collegamento di aggregazione non dovrebbe essere usato affatto perché non ha alcun valore aggiunto e disturba la coerenza, citando Jim Rumbaugh "Pensalo come un modello di placebo".

Composizione (associazione non condivisa)

Dovremmo essere più specifici e utilizzare il collegamento di composizione nei casi in cui oltre alla relazione parziale tra ClassA e ClassB - esiste una forte dipendenza del ciclo di vita tra i due, il che significa che quando ClassA viene eliminata, anche ClassB viene eliminata di conseguenza

Il collegamento di composizione mostra che una classe (contenitore, intero) ha la proprietà esclusiva su altre classi (parti), il che significa che l'oggetto contenitore e le sue parti costituiscono una relazione padre-figlio.

A differenza dell'associazione e dell'aggregazione, quando si utilizza la relazione di composizione, la classe composta non può apparire come tipo restituito o tipo di parametro della classe composita. Pertanto, le modifiche alla classe composta non possono propagarsi al resto del sistema. Di conseguenza, l'uso della composizione limita la crescita della complessità man mano che il sistema cresce.

Misurare la complessità del sistema

La complessità del sistema può essere misurata semplicemente osservando un diagramma di classe UML e valutando le linee di relazione di associazione, aggregazione e composizione. Il modo per misurare la complessità è determinare quante classi possono essere influenzate cambiando una determinata classe. Se la classe A espone la classe B, qualsiasi data classe che utilizza la classe A può teoricamente essere influenzata dalle modifiche alla classe B. La somma del numero di classi potenzialmente interessate per ogni classe nel sistema è la complessità totale del sistema.

Puoi leggere di più sul mio blog: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

Composizione (Se rimuovi "intero", anche la "parte" viene rimossa automaticamente - "Proprietà")

• Crea oggetti della tua classe esistente all'interno della nuova classe. Questa si chiama composizione perché la nuova classe è composta da oggetti di classi esistenti.

• In genere usa variabili membro normali.

• Può utilizzare i valori del puntatore se la classe di composizione gestisce automaticamente l'allocazione / deallocazione responsabile della creazione / distruzione delle sottoclassi.

Composizione in C ++

#include <iostream>
using namespace std;
/********************** Engine Class ******************/
class Engine
{
    int nEngineNumber;
    public:
    Engine(int nEngineNo);
    ~Engine(void);
};
Engine::Engine(int nEngineNo)
{
    cout<<" Engine :: Constructor " <<endl;
}
Engine::~Engine(void)
{
    cout<<" Engine :: Destructor " <<endl;
}
/********************** Car Class ******************/
class Car
{
    int nCarColorNumber;
    int nCarModelNumber;
    Engine objEngine;
    public:
    Car (int, int,int);
    ~Car(void);
};
Car::Car(int nModelNo,int nColorNo, int nEngineNo):
nCarModelNumber(nModelNo),nCarColorNumber(nColorNo),objEngine(nEngineNo)
{
    cout<<" Car :: Constructor " <<endl;
}
Car::~Car(void)
{
    cout<<" Car :: Destructor " <<endl;
    Car
    Engine
    Figure 1 : Composition
}
/********************** Bus Class ******************/
class Bus
{
    int nBusColorNumber;
    int nBusModelNumber;
    Engine* ptrEngine;
    public:
    Bus(int,int,int);
    ~Bus(void);
};
Bus::Bus(int nModelNo,int nColorNo, int nEngineNo):
nBusModelNumber(nModelNo),nBusColorNumber(nColorNo)
{
    ptrEngine = new Engine(nEngineNo);
    cout<<" Bus :: Constructor " <<endl;
}
Bus::~Bus(void)
{
    cout<<" Bus :: Destructor " <<endl;
    delete ptrEngine;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    // Composition using simple Engine in a car object
    {
        cout<<"------------- Inside Car Block ------------------"<<endl;
        Car objCar (1, 2,3);
    }
    cout<<"------------- Out of Car Block ------------------"<<endl;
    // Composition using pointer of Engine in a Bus object
    {
        cout<<"------------- Inside Bus Block ------------------"<<endl;
        Bus objBus(11, 22,33);
    }
    cout<<"------------- Out of Bus Block ------------------"<<endl;
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Produzione

--------------- Start Of Program --------------------
------------- Inside Car Block ------------------
Engine :: Constructor
Car :: Constructor
Car :: Destructor
Engine :: Destructor
------------- Out of Car Block ------------------
------------- Inside Bus Block ------------------
Engine :: Constructor
Bus :: Constructor
Bus :: Destructor
Engine :: Destructor
------------- Out of Bus Block ------------------
--------------- End Of Program --------------------

Aggregazione (se si rimuove "intero", può esistere "Parte" - "Nessuna proprietà")

• Un'aggregazione è un tipo specifico di composizione in cui non è implicita la proprietà tra l'oggetto complesso e gli oggetti secondari. Quando un aggregato viene distrutto, gli oggetti secondari non vengono distrutti.

• Utilizzare in genere variabili puntatore / variabile di riferimento che puntano a un oggetto che non rientra nell'ambito della classe aggregata

• Può usare valori di riferimento che puntano a un oggetto che non rientra nell'ambito della classe aggregata

• Non è responsabile della creazione / distruzione di sottoclassi

Codice di aggregazione in C ++

#include <iostream>
#include <string>
using namespace std;
/********************** Teacher Class ******************/
class Teacher
{
    private:
    string m_strName;
    public:
    Teacher(string strName);
    ~Teacher(void);
    string GetName();
};
Teacher::Teacher(string strName) : m_strName(strName)
{
    cout<<" Teacher :: Constructor --- Teacher Name :: "<<m_strName<<endl;
}
Teacher::~Teacher(void)
{
    cout<<" Teacher :: Destructor --- Teacher Name :: "<<m_strName<<endl;
}
string Teacher::GetName()
{
    return m_strName;
}
/********************** Department Class ******************/
class Department
{
    private:
    Teacher *m_pcTeacher;
    Teacher& m_refTeacher;
    public:
    Department(Teacher *pcTeacher, Teacher& objTeacher);
    ~Department(void);
};
Department::Department(Teacher *pcTeacher, Teacher& objTeacher)
: m_pcTeacher(pcTeacher), m_refTeacher(objTeacher)
{
    cout<<" Department :: Constructor " <<endl;
}
Department::~Department(void)
{
    cout<<" Department :: Destructor " <<endl;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    {
        // Create a teacher outside the scope of the Department
        Teacher objTeacher("Reference Teacher");
        Teacher *pTeacher = new Teacher("Pointer Teacher"); // create a teacher
        {
            cout<<"------------- Inside Block ------------------"<<endl;
            // Create a department and use the constructor parameter to pass the teacher to it.
            Department cDept(pTeacher,objTeacher);
            Department
            Teacher
            Figure 2: Aggregation
        } // cDept goes out of scope here and is destroyed
        cout<<"------------- Out of Block ------------------"<<endl;
        // pTeacher still exists here because cDept did not destroy it
        delete pTeacher;
    }
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Produzione

--------------- Start Of Program --------------------
Teacher :: Constructor --- Teacher Name :: Reference Teacher
Teacher :: Constructor --- Teacher Name :: Pointer Teacher
------------- Inside Block ------------------
Department :: Constructor
Department :: Destructor
------------- Out of Block ------------------
Teacher :: Destructor --- Teacher Name :: Pointer Teacher
Teacher :: Destructor --- Teacher Name :: Reference Teacher
--------------- End Of Program --------------------

Il problema con queste risposte è che sono metà della storia: spiegano che aggregazione e composizione sono forme di associazione, ma non dicono se è possibile che un'associazione non sia nessuna di queste.

Raccolgo sulla base di alcune brevi letture di molti post su SO e alcuni documenti UML che ci sono 4 principali forme concrete di associazione di classe:

1. composizione: A è composta da una B; B non esiste senza A, come una stanza in una casa
2. aggregazione: A has-a B; B può esistere senza A, come uno studente in una classe
3. dipendenza: A usa-a B; nessuna dipendenza del ciclo di vita tra A e B, come un parametro di chiamata del metodo, il valore restituito o un temporaneo creato durante una chiamata del metodo
4. generalizzazione: A is-a B

Quando una relazione tra due entità non è una di queste, può semplicemente essere definita "un'associazione" nel senso generico del termine, e ulteriormente descritta in altri modi (nota, stereotipo, ecc.).

La mia ipotesi è che "l'associazione generica" ​​debba essere utilizzata principalmente in due circostanze:

• quando i dettagli di una relazione sono ancora in fase di elaborazione; tale relazione in un diagramma dovrebbe essere convertita il più presto possibile in ciò che è / sarà effettivamente (una delle altre 4).
• quando una relazione non corrisponde a nessuna di quelle predeterminate da UML; l'associazione "generica" ​​ti dà ancora un modo di rappresentare una relazione che "non è una delle altre", quindi non sei bloccato usando una relazione errata con una nota "questa non è in realtà aggregazione, è solo UML non ha altri simboli che potremmo usare "

Penso che questo link farà i tuoi compiti: http://ootips.org/uml-hasa.html

Per capire i termini, ricordo un esempio nei miei primi giorni di programmazione:

Se si dispone di un oggetto "scacchiera" che contiene oggetti "box" che sono composizione perché se la "scacchiera" viene eliminata non vi è più motivo di esistere.

Se hai un oggetto 'quadrato' che ha un oggetto 'colore' e il quadrato viene eliminato, l'oggetto 'colore' potrebbe ancora esistere, cioè aggregazione

Entrambi sono associazioni , la differenza principale è concettuale

Composizione : Questo è dove una volta che distruggi un oggetto (Scuola), anche un altro oggetto (Classrooms) a cui è legato verrebbe distrutto. Entrambi non possono esistere indipendentemente.

Aggregazione : è esattamente l'opposto dell'associazione above ( Composition) dove una volta che si uccide un oggetto ( Company), l'altro oggetto ( Employees) a cui è legato può esistere da solo.

Associazione .
Composizione e aggregazione sono le due forme di associazione.

    Simple rules:
    A "owns" B = Composition : B has no meaning or purpose in the system 
    without A
    A "uses" B = Aggregation : B exists independently (conceptually) from A
    A "belongs/Have" B= Association; And B exists just have a relation
    Example 1:

    A Company is an aggregation of Employees.
    A Company is a composition of Accounts. When a Company ceases to do 
    business its Accounts cease to exist but its People continue to exist. 
    Employees have association relationship with each other.

    Example 2: (very simplified)
    A Text Editor owns a Buffer (composition). A Text Editor uses a File 
    (aggregation). When the Text Editor is closed,
    the Buffer is destroyed but the File itself is not destroyed.

In una frase molto semplice:
aggregazione e composizione sono sottoinsiemi di associazione.

• A usa B -> questa è un'aggregazione

• A ha bisogno di B -> è composizione.

Leggi di più qui .

Vorrei illustrare come i tre termini sono implementati in Rails. ActiveRecord chiama qualsiasi tipo di relazione tra due modelli un association. Non si trovano molto spesso i termini compositione aggregation, durante la lettura di documentazione o articoli, relativi ad ActiveRecord. Un'associazione viene creata aggiungendo una delle macro della classe di associazione al corpo della classe. Alcune di queste macro sono belongs_to, has_one,has_many ecc ..

Se vogliamo impostare una compositiono aggregation, dobbiamo aggiungere belongs_toal modello di proprietà (chiamato anche bambino) e has_oneo has_manyal modello possedere (chiamato anche genitore). Sia che configuriamo compositiono aggregationdipende dalle opzioni che passiamo alla belongs_tochiamata nel modello figlio. Prima di Rails 5, configurando belongs_tosenza alcuna opzione creata un aggregation, il figlio poteva esistere senza un genitore. Se volessimo un composition, dovevamo dichiararlo esplicitamente aggiungendo l'opzione required: true:

class Room < ActiveRecord::Base
  belongs_to :house, required: true
end

In Rails 5 questo è stato modificato. Ora, dichiarando belongs_toun'associazione crea un compositiondi default, il figlio non può esistere senza un genitore. Quindi l'esempio sopra può essere riscritto come:

class Room < ApplicationRecord
  belongs_to :house
end

Se vogliamo consentire all'oggetto figlio di esistere senza un genitore, dobbiamo dichiararlo esplicitamente tramite l'opzione optional

class Product < ApplicationRecord
  belongs_to :category, optional: true
end

Da: libro di Remo H. Jansen “Beginning React: Learning TypeScript 2.x - Second Edition”:

Chiamiamo associazione quei rapporti i cui oggetti hanno un ciclo di vita indipendente dove non c'è proprietà degli oggetti. Diamo un'occhiata a un esempio di insegnante e studente. Più studenti possono essere associati a un singolo insegnante e un singolo studente può essere associato a più insegnanti, ma entrambi hanno cicli di vita indipendenti (entrambi possono creare ed eliminare in modo indipendente). Pertanto, quando un insegnante lascia la scuola, non è necessario eliminare alcuno studente e quando uno studente lascia la scuola non è necessario eliminare alcun insegnante.

Chiamiamo aggregazione quelle relazioni i cui oggetti hanno un ciclo di vita indipendente, ma esiste la proprietà e gli oggetti figlio non possono appartenere a un altro oggetto genitore. Facciamo un esempio di un telefono cellulare e una batteria del telefono cellulare. Una singola batteria può appartenere a un telefono, ma se il telefono smette di funzionare e lo eliminiamo dal nostro database, la batteria del telefono non verrà eliminata perché potrebbe essere ancora funzionante. Quindi, in aggregazione, mentre c'è proprietà, gli oggetti hanno il loro ciclo di vita

Usiamo il termine composizione per fare riferimento a relazioni i cui oggetti non hanno un ciclo di vita indipendente e se l'oggetto genitore viene eliminato, anche tutti gli oggetti figlio verranno eliminati. Facciamo un esempio della relazione tra domande e risposte. Le singole domande possono avere più risposte e le risposte non possono appartenere a più domande. Se eliminiamo le domande, le risposte verranno automaticamente eliminate.

L'associazione è una relazione tra due classi separate e l'associazione può essere di qualsiasi tipo, ad esempio uno a uno, uno a maggio, ecc. Unisce due entità completamente separate.

L'aggregazione è una forma speciale di associazione che è una relazione unidirezionale unidirezionale tra classi (o entità), ad esempio le classi Wallet e Money. Wallet ha denaro, ma il denaro non deve necessariamente avere Wallet, quindi è una relazione unidirezionale. In questa relazione entrambe le voci possono sopravvivere se ne termina un'altra. Nel nostro esempio se la classe Wallet non è presente, ciò non significa che la classe Money non possa esistere.

Composizione è una forma ristretta di aggregazione in cui due entità (o si possono dire classi) sono fortemente dipendenti l'una dall'altra. Per es. Umani e cuore. Un essere umano ha bisogno del cuore per vivere e un cuore ha bisogno del corpo umano per sopravvivere. In altre parole, quando le classi (entità) dipendono l'una dall'altra e la loro durata di vita è la stessa (se una muore poi anche un'altra), allora è una composizione. La classe cardiaca non ha senso se la classe umana non è presente.

https://www.linkedin.com/pulse/types-relationships-object-oriented-programming-oop-sarah-el-dawody/

Composizione: è una relazione "parte di".

per esempio "il motore fa parte della macchina", "il cuore fa parte della carrozzeria".

Associazione: è una relazione di tipo "has-a"

Ad esempio, supponiamo di avere due classi, quindi si dice che queste due relazioni siano relazioni "ha-a" se entrambe queste entità condividono l'oggetto reciproco per qualche lavoro e allo stesso tempo possono esistere senza la reciproca dipendenza o entrambe hanno il loro propria vita.

L'esempio sopra mostra una relazione di associazione a causa della classe Employee e Manager che utilizza l'oggetto l'uno dell'altro ed entrambi il proprio ciclo di vita indipendente.

Aggregazione: si basa sulla relazione "has-a" ed è \\ una forma speciale di associazione

ad esempio, "Studente" e "indirizzo". Ogni studente deve avere un indirizzo, quindi la relazione tra la classe Student e la classe Address sarà una relazione di tipo “Has-A” ma viceversa non è vera.