Notations de diagramme de classes UML: Différences entre Association, Agrégation et Composition

Certaines notes des diagrammes de classe UML m'embrouillent.

Je suis sûr que je sais ce que signifie Association . Toute relation entre des instances de deux classes, lorsqu'une instance d'une classe a besoin de connaître une instance de la seconde classe pour pouvoir exécuter son travail, est une relation d'association. Une association signifie souvent que la classe A a une référence (champ) à une instance de la classe B.

Cependant, j'ai du mal à comprendre ce que signifient les flèches d' agrégation et de composition . Une partie de ma confusion a été causée par la rencontre de différentes définitions de ces notations.

Deux définitions de la notation d' agrégation :

Définition 1: Une notation d'agrégation entre deux classes est appropriée lorsqu'une instance de la classe A contient une collection d'instances de la classe B (par exemple, une liste, un tableau, peu importe).

Définition 2: Un lien d'agrégation entre deux classes convient si une instance de la classe A contient une référence à une instance de la classe B et que l'instance B dépend du cycle de vie de l'instance A. Signification: Lorsque l'instance de la classe A est supprimée, l'instance de la classe B le sera également. L'instance de la classe B est entièrement contenue par l'instance de la classe A, par opposition à l'instance de la classe A possédant simplement une référence à l'instance de classe B (qui est une association régulière).

En ce qui concerne la signification de la composition et ses différences avec la notation d'agrégation, je n'en suis pas sûre.

Veuillez clarifier les définitions et aidez-moi à comprendre. Des exemples concrets seraient les bienvenus.

Les trois liens Association, Agrégation et Composition forment une sorte d’échelle sur la relation de proximité entre deux classes.

À une extrémité de l'échelle, il y a Association, où les objets des deux classes peuvent se connaître, mais n'affectent pas la vie de chacun. Les objets peuvent exister indépendamment et quel objet de classe A sait quels objets de classe B peuvent varier dans le temps.

À l'autre bout de l'échelle, il y a la composition. La composition représente une relation partie-tout telle que la classe B fait partie intégrante de la classe A. Cette relation est généralement utilisée si des objets de la classe A ne peuvent exister logiquement sans un objet de classe B.

La relation d'agrégation se situe quelque part entre ces deux extrémités, mais personne ne semble s'accorder sur l'endroit où il se trouve, il n'y a donc pas non plus de définition universellement convenue de ce que signifie une agrégation. En ce sens, les deux définitions que vous avez trouvées sont correctes et si vous demandez à 10 personnes, vous risquez d’obtenir 11 définitions différentes.

La composition est quand object Acontient object Bet object Aest également responsable de la création du object B.

Relation de composition

Nous avons une classe A qui sera utilisée par la classe B.

final class A
{
}

Il y a plusieurs options, comme l'apparence de la composition.

Composition d'initialisation directe:

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

Composition d'initialisation du constructeur

final class B
{
    private $a;

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

Composition d'initialisation paresseuse

final class B
{
    private $a = null;

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

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

Vous voyez que cela crée une relation étroite entre les classes Aet B. La classe Bne peut tout simplement pas exister sans A. Ceci est une énorme violation du principe d'injection de dépendance , qui dit:

Une dépendance est un objet utilisable (un service). Une injection est le passage d'une dépendance à un objet dépendant (un client) qui l'utiliserait. Le service fait partie de l'état du client. Transmettre le service au client, plutôt que de permettre à un client de créer ou de trouver le service, est l'exigence fondamentale du modèle.

La composition est parfois utile, comme appeler new DateTimeen php ou new std::vector<int>en C ++. Mais le plus souvent, c'est un avertissement, que la conception de votre code est erronée.

Dans le cas où l'objet class Aserait un objet spécial utilisé pour la mise en cache, il class Bserait toujours mis en cache à l'aide de l'implémentation de class Aet vous n'auriez aucun contrôle pour le modifier de manière dynamique, ce qui est incorrect.

De plus, si vous utilisiez la composition d’initialisation paresseuse , ce qui signifie que vous auriez une méthode de travail object Bappelée la useA()méthode et que la création de celle- object Aci échouerait, votre utilisation deviendra object Bsoudainement inutile.

L'agrégation, en revanche, est une forme de relation qui suit le principe de l' ID . object Bdoit utiliser object A, vous devez alors passer l’instance déjà créée à object Aà object B, et si la création d’ object Aéchec échouait, rien ne serait passé en premier lieu.

En bref, Aggregation est une représentation UML du principe d’injection de dépendance , qu’il s’agisse d’injection de constructeur, d’injection de setter ou d’injection de propriété publique.

Ce sont tous des agrégations

L'injection de constructeur la plus étroite ( object Bne peut exister sans object A).

final class B
{
    private $a;

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

Looser (vous pouvez ou non utiliser l' object Aintérieur object B, mais si vous le faites, vous devriez probablement le définir en premier).

Via setter:

final class B
{
    private $a;

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

Via propriété publique:

final class B
{
    public $a;
}

Il n’existe pas vraiment de bon moyen de justifier l’utilisation de Aggregation sur Composition, si vous n’utilisez que des implémentations concrètes de classes, mais dès que vous commencez à injecter des interfaces ou, dans le cas de classes abstraites C ++, l’agrégation sera le seul moyen de procéder. remplir votre contrat.

En outre, un extrait du standard UML actuel:

11.5.4 Associations - Sémantique - Notation

[...] Une association binaire peut avoir une extrémité avec aggregation = AggregationKind :: shared ou aggregation = AggregationKind :: composite. Lorsqu'une extrémité a agrégation = AggregationKind :: shared, un losange creux est ajouté en guise d'ornement terminal à la fin de la ligne Association, en regard de l'extrémité marquée d'agrégation = AggregationKind :: shared. Le diamant doit être sensiblement plus petit que la notation de diamant pour les associations. Une association avec aggregation = AggregationKind :: composite a également un diamant à l'extrémité correspondante, mais diffère par le remplissage du diamant . […]

9.5.4 Classification - Propriétés - Notation

[…] Parfois, une propriété est utilisée pour modéliser les circonstances dans lesquelles une instance est utilisée pour regrouper un ensemble d'instances; c'est ce qu'on appelle l'agrégation. Pour représenter de telles circonstances, une propriété a une propriété d'agrégation, de type AggregationKind; l'instance représentant l'ensemble du groupe est classée par le propriétaire de la propriété et les instances représentant les individus groupés sont classées par type de propriété. AggregationKind est une énumération avec les valeurs littérales suivantes:

• none : indique que la propriété n'a pas de sémantique d'agrégation.
• Partagé : indique que la propriété a une sémantique d'agrégation partagée. La sémantique précise de l'agrégation partagée varie selon le domaine d'application et le modélisateur.
• Composite : Indique que la propriété est agrégée de manière composite, c'est-à-dire que l'objet composite est responsable de l'existence et du stockage des objets composés (voir la définition des parties en 11.2.3). L'agrégation composite est une forme d'agrégation forte qui nécessite qu'un objet soit inclus dans au plus un objet composite à la fois. Si un objet composite est supprimé, toutes ses occurrences de pièce qui sont des objets sont également supprimées.

[…]

J'ai déjà posté une réponse sur Stackoverflow .

Fondamentalement, une agrégation est plus forte qu'une simple association, mais les objets agrégés peuvent continuer à «vivre» les uns sans les autres, comme avec une simple association.

Une composition est encore plus forte qu'une agrégation car la classe agrégée ne peut pas être agrégée par d'autres classes. Sa "vie" dépend du conteneur.