Quelle est la différence entre l'association, l'agrégation et la composition?

Quelle est la différence entre l'association, l'agrégation et la composition? Veuillez expliquer en termes de mise en œuvre.

Pour deux objets, Fooet Barles relations peuvent être définies

Association - J'ai une relation avec un objet. Fooles usagesBar

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

Composition - Je possède un objet et je suis responsable de sa durée de vie. Quand Foomeurt, il en va de mêmeBar

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

Agrégation - J'ai un objet que j'ai emprunté à quelqu'un d'autre. À sa Foomort, Barpeut vivre.

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

Je sais que cette question est étiquetée comme C # mais les concepts sont des questions assez génériques comme cette redirection ici. Je vais donc donner ici mon point de vue (un peu biaisé du point de vue java où je suis plus à l'aise).

Lorsque nous pensons à la nature orientée objet, nous pensons toujours aux objets, à la classe (plans d'objets) et à la relation entre eux. Les objets sont liés et interagissent entre eux via des méthodes. En d'autres termes, l'objet d'une classe peut utiliser des services / méthodes fournis par l'objet d'une autre classe. Ce type de relation est appelé association. .

L'agrégation et la composition sont des sous-ensembles d'association, ce qui signifie qu'il s'agit de cas spécifiques d'association.

• Dans l'agrégation et la composition, l' objet d'une classe "possède" l'objet d'une autre classe .
• Mais il y a une subtile différence. Dans Composition, l'objet de classe qui appartient à l'objet de sa classe propriétaire ne peut pas vivre seul (également appelé "relation de mort"). Il vivra toujours en tant que partie de son objet propriétaire où, comme dans l' agrégation, l'objet dépendant est autonome et peut exister même si l'objet de la classe propriétaire est mort.
• Ainsi, dans la composition, si l'objet propriétaire est récupéré, l'objet appartenant sera également ce qui n'est pas le cas dans l'agrégation.

Confus?

Exemple de composition : Considérez l'exemple d'une voiture et d'un moteur qui est très spécifique à cette voiture (ce qui signifie qu'il ne peut être utilisé dans aucune autre voiture). Ce type de relation entre la classe Car et SpecificEngine est appelé Composition. Un objet de la classe Car ne peut exister sans un objet de la classe SpecificEngine et l'objet de SpecificEngine n'a aucune signification sans la classe Car. Pour mettre des mots simples, la classe Car "possède" uniquement la classe SpecificEngine.

Exemple d'agrégation : Considérons maintenant la classe Car et la classe Wheel . La voiture a besoin d'un objet Wheel pour fonctionner. Cela signifie que l'objet Car possède l'objet Wheel, mais nous ne pouvons pas dire que l'objet Wheel n'a aucune signification sans l'objet Car. Il peut très bien être utilisé dans un objet de vélo, de camion ou de voitures différentes.

En résumé -

Pour résumer l'association est un terme très générique utilisé pour représenter quand une classe utilise les fonctionnalités fournies par une autre classe. Nous disons que c'est la composition si un objet de classe parent possède un autre objet de classe enfant et que cet objet de classe enfant ne peut pas exister de manière significative sans l'objet de classe parent. Si c'est le cas, cela s'appelle Agrégation.

Plus de détails ici. Je suis l'auteur de http://opensourceforgeeks.blogspot.in et j'ai ajouté un lien ci-dessus au message correspondant pour plus de contexte.

L'association est un concept généralisé de relations. Il comprend à la fois la composition et l'agrégation.

La composition ( mélange ) est un moyen d'envelopper des objets ou des types de données simples dans une seule unité . Les compositions sont un élément essentiel de nombreuses structures de données de base

L'agrégation ( collecte ) diffère de la composition ordinaire en ce qu'elle n'implique pas la propriété. Dans la composition, lorsque l'objet propriétaire est détruit, les objets contenus le sont également. En agrégation, ce n'est pas nécessairement vrai.

Les deux dénotent une relation entre un objet et ne diffèrent que par leur force.

Astuce pour se souvenir de la différence: a A - A agrégation et O wn - c O mpositoin

Maintenant, observons l'image suivante

Analogie:

Composition : L'image suivante est la composition d'image, c'est-à-dire l'utilisation d'images individuelles pour créer une image.

Agrégation : collection d'images en un seul endroit

Par exemple, une université possède plusieurs départements, et chaque département a un certain nombre de professeurs. Si l'université ferme, les départements n'existeront plus, mais les professeurs de ces départements continueront d'exister. Par conséquent, une université peut être considérée comme une composition de départements, alors que les départements ont une agrégation de professeurs. De plus, un professeur peut travailler dans plus d'un département, mais un département ne peut pas faire partie de plus d'une université.

Dépendance (références)
Cela signifie qu'il n'y a pas de lien conceptuel entre deux objets. Par exemple, les objets EnrollmentService font référence aux objets Etudiant et Cours (comme paramètres de méthode ou types de retour)

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

Association (has-a)
Cela signifie qu'il y a presque toujours un lien entre les objets (ils sont associés). L'objet de commande a un objet client

public class Order {
    private Customer customer
}

Agrégation (a-une + partie entière)
Type spécial d'association où il existe une relation de partie entière entre deux objets. ils pourraient vivre l'un sans l'autre cependant.

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

Remarque: la partie la plus délicate consiste à distinguer l'agrégation de l'association normale. Honnêtement, je pense que cela est ouvert à différentes interprétations.

Composition (a-une + partie entière + propriété)
Type d'agrégation spécial. An Apartmentest composé de certains Roomart. Un Roomne peut exister sans un Apartment. lorsqu'un appartement est supprimé, toutes les pièces associées sont également supprimées.

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

Extrait d'un article de Robert Martin dans comp.object :

L'association représente la capacité d'une instance à envoyer un message à une autre instance. Ceci est généralement implémenté avec un pointeur ou une variable d'instance de référence, bien qu'il puisse également être implémenté comme argument de méthode, ou la création d'une variable locale.

//[Example:]

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

class A
{
  private:
    B* itsB;
};

L'agrégation [...] est la relation type ensemble / partie. C'est exactement la même chose qu'une association à l'exception que les instances ne peuvent pas avoir de relations d'agrégation cycliques (c'est-à-dire qu'une partie ne peut pas contenir son entier).

//[Example:]

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

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

Le fait qu'il s'agisse d'une agrégation signifie que les instances de Node ne peuvent pas former un cycle. Il s'agit donc d'un arbre de nœuds et non d'un graphique de nœuds.

La composition [...] est exactement comme l'agrégation, sauf que la durée de vie de la «partie» est contrôlée par le «tout». Ce contrôle peut être direct ou transitif. Autrement dit, le «tout» peut assumer la responsabilité directe de la création ou de la destruction de la «partie», ou il peut accepter une partie déjà créée, puis la transmettre à un autre tout qui en assume la responsabilité.

//[Example:]

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

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

Comme d'autres l'ont dit, une association est une relation entre des objets, l'agrégation et la composition sont des types d'association.

Du point de vue de l'implémentation, une agrégation est obtenue en ayant un membre de classe par référence . Par exemple, si la classe A agrège un objet de classe B, vous aurez quelque chose comme ça (en C ++):

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

La sémantique de l'agrégation est que lorsqu'un objet A est détruit, l'objet B qu'il stocke existe toujours. Lorsque vous utilisez la composition, vous avez une relation plus forte, généralement en stockant le membre par valeur :

class A {
    B element;
};

Ici, lorsqu'un objet A est détruit, l'objet B qu'il contient sera également détruit. Le moyen le plus simple d'y parvenir est de stocker le membre par valeur, mais vous pouvez également utiliser un pointeur intelligent ou supprimer le membre dans le destructeur:

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

class A {
    B * element;

    ~A() {
        delete B;
    }
};

Le point important est que dans une composition, l'objet conteneur est propriétaire de l' objet contenu, alors qu'en agrégation, il le référence .

Il est incroyable de voir comment une grande confusion règne sur la distinction entre les trois concepts de relation d' association , l' agrégation et la composition .

Notez que les termes agrégation et composition ont été utilisés dans la communauté C ++, probablement pendant un certain temps avant d'avoir été définis comme des cas particuliers d' association dans les diagrammes de classes UML.

Le problème principal est le malentendu répandu et continu (même parmi les développeurs de logiciels experts) selon lequel le concept de composition implique une dépendance du cycle de vie entre l'ensemble et ses parties de telle sorte que les parties ne peuvent pas exister sans l'ensemble, ignorant le fait qu'il existe également cas d'associations partie-tout avec des parties non partageables où les parties peuvent être détachées de l'ensemble et survivre à leur destruction.

Pour autant que je puisse voir, cette confusion a deux racines:

1. Dans la communauté C ++, le terme "agrégation" était utilisé dans le sens d'une classe définissant un attribut pour référencer des objets d'une autre classe indépendante (voir, par exemple, [1]), qui est le sens d' association dans les diagrammes de classes UML. Le terme "composition" a été utilisé pour les classes qui définissent des objets composants pour leurs objets, de sorte que lors de la destruction de l'objet composite, ces objets composants sont également détruits.

2. Dans les diagrammes de classes UML, "agrégation" et "composition" ont été définies comme des cas particuliers d'associations représentant des relations partielles (qui ont été discutées en philosophie pendant longtemps). Dans leurs définitions, la distinction entre une "agrégation" et une "composition" repose sur le fait qu'elle permet de partager une partie entre deux ou plusieurs ensembles. Ils définissent les "compositions" comme ayant des parties non partageables (exclusives), tandis que les "agrégations" peuvent partager leurs parties. De plus, ils disent quelque chose comme ceci: très souvent, mais pas dans tous les cas, les compositions ont une dépendance du cycle de vie entre le tout et ses parties de telle sorte que les parties ne peuvent exister sans le tout.

Ainsi, si UML a mis les termes "agrégation" et "composition" dans le bon contexte (des relations partielles), ils n'ont pas réussi à les définir de manière claire et sans ambiguïté, capturant les intuitions des développeurs. Cependant, cela n'est pas surprenant car il y a tellement de propriétés différentes (et de nuances d'implémentation) que ces relations peuvent avoir, et les développeurs ne s'entendent pas sur la façon de les implémenter.

Voir également ma réponse étendue à la question SO d'avril 2009 ci-dessous.

Et la propriété qui était supposée définir la "composition" entre les objets OOP dans la communauté C ++ (et cette croyance est encore largement répandue): la dépendance du cycle de vie au moment de l'exécution entre les deux objets liés (le composite et son composant), est pas vraiment caractéristique de la "composition" car on peut avoir de telles dépendances dues à l'intégrité référentielle également dans d'autres types d'associations.

Par exemple, le modèle de code suivant pour "composition" a été proposé dans une réponse SO :

final class Car {    
  private final Engine engine;

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

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

L'intimé a soutenu qu'il serait caractéristique de la «composition» qu'aucune autre classe ne puisse faire référence / connaître l'élément. Cependant, ce n'est certainement pas vrai pour tous les cas possibles de "composition". En particulier, dans le cas du moteur d'une voiture, le constructeur de la voiture, éventuellement mis en œuvre avec l'aide d'une autre classe, peut avoir à référencer le moteur pour pouvoir contacter le propriétaire de la voiture en cas de problème.

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

Annexe - Liste incomplète de questions posées à plusieurs reprises sur la composition par rapport à l'agrégation sur StackOverflow

[ Avr 2009 ]
Agrégation versus Composition [clôturé comme étant principalement basé sur l'opinion]
[ Avr 2009 ]
Quelle est la différence entre la composition et la relation d'association?
[ Mai 2009 ]
Différence entre association, agrégation et composition
[ Mai 2009 ]
Quelle est la différence entre composition et agrégation? [duplicate]
[ Oct 2009 ]
Quelle est la différence entre l'agrégation, la composition et la dépendance? [marqué comme doublon]
[ novembre 2010 ]
Association vs agrégation [marqué comme doublon]
[Août 2012 ]
Différence d'implémentation entre l'agrégation et la composition en Java
[ février 2015 ]
UML - association ou agrégation (extraits de code simples)

Association

L'association représente la relation entre deux classes, elle peut être unidirectionnelle (unidirectionnelle) ou bidirectionnelle (bidirectionnelle)

par exemple:

1. unidirectionnel

Le client passe des commandes

2. bidirectionnel

A est marié à B

B est marié à A

Agrégation

L'agrégation est une sorte d'association.Mais avec des caractéristiques spécifiques.L'agrégation est la relation dans une classe "entière" plus grande contient une ou plusieurs classes "parties" plus petites. .

par exemple:

le club a des membres

Un club ("entier") est composé de plusieurs membres du club ("parties"). Le membre a la vie à l'extérieur du club. Si le club ("entier") devait mourir, les membres ("parties") ne mourraient pas avec lui. Parce que le membre peut appartenir à plusieurs clubs ("ensemble").

Composition

Il s'agit d'une forme d'agrégation plus forte. "Tout" est responsable de la création ou de la destruction de ses "parties"

Par exemple:

Une école a des départements

Dans ce cas, l'école ("entière") devait mourir, le département ("parties") mourrait avec. Parce que chaque partie ne peut appartenir qu'à un seul "tout".

Il est important de comprendre pourquoi nous devrions même nous soucier d'utiliser plus d'une fois la ligne de relation. La raison la plus évidente est de décrire la relation parent-enfant entre les classes (lorsque le parent a supprimé tous ses enfants sont supprimés en conséquence), mais plus impuissant, nous voulons distinguer l'association simple et la composition afin de placer des restrictions implicites sur la visibilité et propagation des changements aux classes apparentées, une question qui joue un rôle important dans la compréhension et la réduction de la complexité du système.

Association

La manière la plus abstraite de décrire la relation statique entre les classes est d'utiliser le lien d'association, qui indique simplement qu'il existe une sorte de lien ou une dépendance entre deux classes ou plus.

Association faible

ClassA peut être lié à ClassB afin de montrer que l'une de ses méthodes inclut un paramètre d'instance ClassB ou renvoie une instance de ClassB.

Association forte

ClassA peut également être lié à ClassB afin de montrer qu'il contient une référence à l'instance ClassB.

Agrégation (Association partagée)

Dans les cas où il existe une partie de la relation entre la classe A (entière) et la classe B (partie), nous pouvons être plus spécifiques et utiliser le lien d'agrégation au lieu du lien d'association, soulignant que la classe B peut également être agrégée par d'autres classes dans l'application ( par conséquent, l'agrégation est également appelée association partagée).

Il est important de noter que le lien d'agrégation n'indique en aucune façon que ClassA possède ClassB ni qu'il existe une relation parent-enfant (lorsque le parent a supprimé tous ses enfants sont supprimés en conséquence) entre les deux. En fait, bien au contraire! Le lien d'agrégation habituellement utilisé pour souligner le fait que ClassA n'est pas le conteneur exclusif de ClassB, car en fait ClassB a un autre conteneur.

Agrégation vs Association Le lien d'association peut remplacer le lien d'agrégation dans chaque situation, tandis que l'agrégation ne peut pas remplacer l'association dans les situations où il n'y a qu'un «lien faible» entre les classes, c'est-à-dire que ClassA a des méthodes qui contiennent le paramètre de ClassB mais ClassA ne le fait pas contenir une référence à l'instance ClassB.

Martin Fowler suggère que le lien d'agrégation ne devrait pas être utilisé du tout parce qu'il n'a pas de valeur ajoutée et qu'il perturbe la cohérence, citant Jim Rumbaugh "Considérez-le comme un placebo de modélisation".

Composition (Association non partagée)

Nous devons être plus précis et utiliser le lien de composition dans les cas où, en plus de la relation partielle entre ClassA et ClassB - il existe une forte dépendance de cycle de vie entre les deux, ce qui signifie que lorsque ClassA est supprimé, ClassB est également supprimé en conséquence

Le lien de composition montre qu'une classe (conteneur, entier) a la propriété exclusive sur les autres classes (parties), ce qui signifie que l'objet conteneur et ses parties constituent une relation parent-enfant / s.

Contrairement à l'association et à l'agrégation, lors de l'utilisation de la relation de composition, la classe composée ne peut pas apparaître comme type de retour ou type de paramètre de la classe composite. Ainsi, les modifications apportées à la classe composée ne peuvent pas se propager au reste du système. Par conséquent, l'utilisation de la composition limite la croissance de la complexité à mesure que le système se développe.

Mesurer la complexité du système

La complexité du système peut être mesurée simplement en consultant un diagramme de classes UML et en évaluant les lignes de relation d'association, d'agrégation et de composition. La façon de mesurer la complexité consiste à déterminer combien de classes peuvent être affectées en changeant une classe particulière. Si la classe A expose la classe B, alors toute classe donnée qui utilise la classe A peut théoriquement être affectée par les modifications apportées à la classe B. La somme du nombre de classes potentiellement affectées pour chaque classe du système est la complexité totale du système.

Vous pouvez en savoir plus sur mon blog: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

Composition (Si vous supprimez "entier", "partie" est également supprimé automatiquement - "Propriété")

• Créez des objets de votre classe existante dans la nouvelle classe. C'est ce qu'on appelle la composition car la nouvelle classe est composée d'objets de classes existantes.

• Utilisez généralement les variables de membre normales.

• Peut utiliser des valeurs de pointeur si la classe de composition gère automatiquement l'allocation / désallocation responsable de la création / destruction des sous-classes.

Composition en 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);
}

Production

--------------- 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 --------------------

Agrégation (Si vous supprimez "entier", "Partie" peut exister - "Aucune propriété")

• Une agrégation est un type spécifique de composition où aucune propriété entre l'objet complexe et les sous-objets n'est impliquée. Lorsqu'un agrégat est détruit, les sous-objets ne sont pas détruits.

• Utilisez généralement des variables de pointeur / variable de référence qui pointent vers un objet qui vit en dehors de la portée de la classe agrégée

• Peut utiliser des valeurs de référence qui pointent vers un objet qui vit en dehors de la portée de la classe agrégée

• Pas responsable de la création / destruction de sous-classes

Code d'agrégation en 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);
}

Production

--------------- 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 --------------------

Le problème avec ces réponses est qu'elles représentent la moitié de l'histoire: elles expliquent que l'agrégation et la composition sont des formes d'association, mais elles ne disent pas s'il est possible pour une association d'être ni l'une ni l'autre.

Je me fonde sur quelques brèves lectures de nombreux articles sur SO et certains documents UML qu'il existe 4 principales formes concrètes d'association de classe:

1. composition: A est composé d'un a B; B n'existe pas sans A, comme une pièce dans une maison
2. agrégation: A has-a B; B peut exister sans A, comme un élève dans une salle de classe
3. dépendance: A utilise-a B; aucune dépendance de cycle de vie entre A et B, comme un paramètre d'appel de méthode, une valeur de retour ou un temporaire créé pendant un appel de méthode
4. généralisation: A is-a B

Lorsqu'une relation entre deux entités ne fait pas partie de celles-ci, elle peut simplement être appelée "une association" au sens générique du terme, et décrit plus en détail d'autres manières (note, stéréotype, etc.).

Je suppose que "l'association générique" est destinée à être utilisée principalement dans deux circonstances:

• lorsque les détails d'une relation sont encore en cours d'élaboration; une telle relation dans un diagramme devrait être convertie dès que possible en ce qu'elle est / sera réellement (l'une des 4 autres).
• lorsqu'une relation ne correspond à aucun des 4 prédéterminés par UML; l'association "générique" vous donne toujours un moyen de représenter une relation qui n'est "pas l'une des autres", afin que vous ne soyez pas bloqué en utilisant une relation incorrecte avec une note "ce n'est pas réellement de l'agrégation, c'est juste que UML n'a pas d'autre symbole que nous pourrions utiliser "

Je pense que ce lien fera vos devoirs: http://ootips.org/uml-hasa.html

Pour comprendre les termes, je me souviens d'un exemple dans mes premiers jours de programmation:

Si vous avez un objet "échiquier" qui contient des objets "boîte" qui sont de la composition car si "l'échiquier" est supprimé, il n'y a plus de raison que les boîtes existent.

Si vous avez un objet "carré" qui a un objet "couleur" et que le carré est supprimé, l'objet "couleur" peut toujours exister, c'est-à-dire l' agrégation

Les deux sont des associations , la principale différence est conceptuelle

Composition : C'est là qu'une fois que vous détruisez un objet (école), un autre objet (salles de classe) qui y est lié serait également détruit. Les deux ne peuvent pas exister indépendamment.

Agrégation : c'est en quelque sorte l'opposé exact de l'association ci-dessus ( Composition) où une fois que vous tuez un objet ( Company), l'autre objet ( Employees) qui lui est lié peut exister par lui-même.

Association .
La composition et l'agrégation sont les deux formes d'association.

    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.

Dans une phrase très simple: l'
agrégation et la composition sont des sous-ensembles d'association.

• A utilise B -> c'est une agrégation

• Un besoin B -> est la composition.

En savoir plus ici .

Je voudrais illustrer comment les trois termes sont implémentés dans Rails. ActiveRecord appelle tout type de relation entre deux modèles an association. On ne retrouve pas très souvent les termes compositionet aggregation, à la lecture de la documentation ou des articles, liés à ActiveRecord. Une association est créée en ajoutant l'une des macros de classe d'association au corps de la classe. Certaines de ces macros sont belongs_to, has_one, has_manyetc ..

Si nous voulons configurer un compositionou aggregation, nous devons ajouter belongs_toau modèle possédé (également appelé enfant) et has_oneou has_manyau modèle propriétaire (également appelé parent). Que nous configurions compositionou aggregationdépend des options que nous transmettons à l' belongs_toappel dans le modèle enfant. Avant Rails 5, la configuration belongs_tosans aucune option créée aggregation, l'enfant pouvait exister sans parent. Si nous voulions un composition, nous devions le déclarer explicitement en ajoutant l'option required: true:

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

Dans Rails 5, cela a été changé. Désormais, déclarer une belongs_toassociation crée un compositionpar défaut, l'enfant ne peut pas exister sans parent. Ainsi, l'exemple ci-dessus peut être réécrit comme suit:

class Room < ApplicationRecord
  belongs_to :house
end

Si nous voulons permettre à l'objet enfant d'exister sans parent, nous devons le déclarer explicitement via l'option optional

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

Extrait du livre de Remo H. Jansen «Beginning React: Learning TypeScript 2.x - Second Edition»:

Nous appelons association les relations dont les objets ont un cycle de vie indépendant où il n'y a pas de propriété des objets. Jetons un coup d'œil à un exemple d'enseignant et d'élève. Plusieurs étudiants peuvent être associés à un seul enseignant et un seul étudiant peut être associé à plusieurs enseignants, mais les deux ont des cycles de vie indépendants (les deux peuvent créer et supprimer indépendamment). Ainsi, lorsqu'un enseignant quitte l'école, nous n'avons pas besoin de supprimer d'élèves, et lorsqu'un élève quitte l'école, nous n'avons pas besoin de supprimer d'enseignants.

Nous appelons agrégation les relations dont les objets ont un cycle de vie indépendant, mais il y a propriété et les objets enfants ne peuvent pas appartenir à un autre objet parent. Prenons un exemple de téléphone portable et de batterie de téléphone portable. Une seule batterie peut appartenir à un téléphone, mais si le téléphone cesse de fonctionner et que nous la supprimons de notre base de données, la batterie du téléphone ne sera pas supprimée car elle peut toujours être fonctionnelle. Donc, en agrégation, alors qu'il y a propriété, les objets ont leur cycle de vie

Nous utilisons le terme composition pour faire référence aux relations dont les objets n'ont pas de cycle de vie indépendant, et si l'objet parent est supprimé, tous les objets enfants seront également supprimés. Prenons un exemple de la relation entre les questions et les réponses. Les questions uniques peuvent avoir plusieurs réponses et les réponses ne peuvent pas appartenir à plusieurs questions. Si nous supprimons des questions, les réponses seront automatiquement supprimées.

L'association est une relation entre deux classes distinctes et l'association peut être de n'importe quel type, disons une à une, une à mai, etc. Elle joint deux entités entièrement distinctes.

L'agrégation est une forme particulière d'association qui est une relation unidirectionnelle à sens unique entre les classes (ou entités), par exemple les classes Wallet et Money. Le portefeuille contient de l'argent, mais l'argent n'a pas nécessairement besoin d'un portefeuille, c'est donc une relation unidirectionnelle. Dans cette relation, les deux entrées peuvent survivre si une autre se termine. Dans notre exemple, si la classe Wallet n'est pas présente, cela ne signifie pas que la classe Money ne peut pas exister.

La composition est une forme restreinte d'agrégation dans laquelle deux entités (ou vous pouvez dire des classes) dépendent fortement l'une de l'autre. Par exemple pour l'homme et le cœur. Un être humain a besoin de cœur pour vivre et un cœur a besoin d'un corps humain pour survivre. En d'autres termes, lorsque les classes (entités) dépendent les unes des autres et que leur durée de vie est la même (si l'un meurt, puis un autre aussi), alors c'est une composition. La classe cardiaque n'a aucun sens si la classe humaine n'est pas présente.

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

Composition: est une relation "partielle".

par exemple «le moteur fait partie de la voiture», «le cœur fait partie du corps».

Association: est une relation de type «a-un»

Par exemple, supposons que nous ayons deux classes, alors ces deux classes sont considérées comme des relations «a-a» si ces deux entités partagent l'objet l'une de l'autre pour un certain travail et en même temps, elles peuvent exister sans dépendance l'une de l'autre ou si les deux ont leur propre vie.

L'exemple ci-dessus montre une relation d'association car les classes Employé et Manager utilisent l'objet l'une de l'autre et leur propre cycle de vie indépendant.

Agrégation: est basée sur une relation "has-a" et c'est \\ une forme particulière d'association

par exemple, «étudiant» et «adresse». Chaque élève doit avoir une adresse afin que la relation entre la classe Élève et la classe Adresse soit une relation de type «Has-A», mais vice versa.