L'agrégation est utilisée pour créer une relation de composition entre des éléments du modèle. Il y a plusieurs
exemples de relations de composition : une Bibliothèque contient des Livres, les Services d'une
société sont composés d'Employés, un Ordinateur est composé de plusieurs Périphériques. Pour créer
cela, l'agrégat (Service) a une association d'agrégation avec ses composants (Employés).
Un losange vide est joint à la fin d'un chemin d'association à côté de l'agrégat (le tout) pour indiquer l'agrégation.
Exemple
Dans cet exemple, un Client a une Adresse. Nous utilisons l'agrégation parce que les deux classes font
partie d'un plus grand ensemble. Nous avons aussi choisi de faire de Adresse une classe séparée, car beaucoup
d'autres choses ont aussi des adresses.
Un objet de consolidation peut rassembler plusieurs objets.
Une relation d'agrégation qui a une multiplicité plus grande que celle établie pour l'agrégat est appelée
partagée, et la destruction de l'agrégat n'entraîne pas forcément celle des composants. Cela implique qu'une
agrégation partagée forme un graphique ou un arbre avec de nombreuses racines. Les agrégations partagées sont utilisées
lorsqu'il y a une relation forte entre deux classes, de façon à ce que la même instance puisse participer à deux
agrégations différentes.
Exemple
Prenons l'exemple d'une personne travaillant à son domicile. La Personne et l'Emploi ont tous deux une adresse ; en
fait, il s'agit de la même adresse. L'Adresse fait partie intégrante de la Personne et de l'Emploi. Cependant,
l'Emploi peut disparaître et la Personne conserver la même adresse.
Remarquez qu'il est possible dans ce cas de commencer avec une agrégation partagée puis de revenir à une agrégation non
partagée ultérieurement. L'emploi à domicile peut se développer et prospérer au point de devoir déménager. La Personne
et l'Emploi ne partagent alors plus la même adresse. L'agrégation n'est alors plus partagée.
Exemple d'agrégation partagée.
L'agrégation composite est une sorte d'agrégation avec une forte propriété et une durée de vie du composant
équivalente à celle de l'agrégat. La multiplicité de la fin de l'agrégat (dans cet exemple, la commande) ne peut
être supérieure à un (c'est-à-dire qu'il ne peut être partagé). L'agrégation est aussi inchangeable : une fois établie,
ses liens ne peuvent être changés. En conséquences, une agrégation composite forme un "arbre" de composants, où la
racine est l'agrégat, et les branches les composants.
Il est recommandé d'utiliser l'agrégation composite à la place de l'agrégation "simple" lorsqu'il y a une relation
d'interdépendance forte entre l'agrégat et les composants, et que la définition de l'agrégat est incomplète sans les
composants. Dans l'exemple suivant, il semble logique d'avoir une commande même si rien n'est commandé (par
exemple, Ligne Articles). Dans certains cas, cette interdépendance peut être identifiée dès l'analyse (comme
dans cet exemple), mais le plus souvent ces décisions ne peuvent être prises avec certitude avant l'étape de
conception.
Un losange plein est joint à la fin d'un chemin d'association pour indiquer la composition, comme indiqué ci-dessous:
Exemple d'agrégation composite.
Exemple
Dans cet exemple, l'Interface client est composée de plusieurs autres classes. Ici, les multiplicités des
agrégations ne sont pas encore spécifiées.
Un composant d'Interface client sait quels composants Ecran, Imprimante de relevés, Clavier, et
Haut-parleur lui appartiennent.
La propriété d'une classe est une chose sur laquelle la classe sait quelque chose. Comme dans l'exemple de la classe
Client ci-dessus, on pourrait choisir de créer l'Adresse du client en tant que classe, comme nous l'avons
montré, ou en tant qu'un ensemble d'attributs de la classe. Le fait de choisir d'utiliser une classe et la relation
d'agrégation ou un ensemble d'attributs dépend des éléments suivants :
-
Les "propriétés" ont-elles besoin d'avoir une identité indépendante, de façon à être utilisées par plusieurs objets
? Si oui, utilisez une classe et une agrégation.
-
Plusieurs classes ont-elles besoin d'avoir les mêmes "propriété"? Si oui, utilisez une classe et une agrégation.
-
Les propriétés ont-elles une structure complexe et des propriétés qui leur sont propres ? Si oui, utilisez une
classe (ou des classes) et une agrégation.
-
Dans les autres cas, utilisez les attributs.
Exemple
Dans un guichet automatique, le système doit garder une trace des clients et de leur numéro d'identification,
supposons que l'Interface Client se charge de cela. Ces informations pourraient être considérées comme les
"propriétés" d'une classe. On peut utiliser une classe à part pour faire cela, comme dans l'exemple suivant:
Propriétés d'objet modélisées en utilisant l'agrégation
L'alternative, que l'Interface client garde une trace du client et de son numéro d'identification en utilisant
des attributs, est modélisée de la façon suivante :
Propriétés d'objet modélisées en utilisant les attributs
Le fait d'utiliser des attributs ou une association d'agrégations pour créer une classe séparée dépend du degré de
couplage entre les concepts qui sont représentés : lorsque les concepts que vous êtes en train de créer sont très
étroitement liés, utilisez les attributs. Lorsque les concepts sont susceptibles de changer de manière indépendante,
utilisez une agrégation.
L'agrégation devrait être utilisée seulement dans les cas où il existe une relation de composition entre les classes,
lorsqu'une classe est composée d'autres classes, ou lorsque les "composants" sont incomplets en dehors du contexte de
l'ensemble. Prenons l'exemple d'une commande: ce n'est pas logique d'avoir une commande "vide", constituée de
"rien". Il en va de même pour tous les agrégats: les Services doivent avoir des Employés, les Familles doivent avoir
des Membres de la famille, et ainsi de suite.
Si les classes peuvent avoir des identités indépendantes en dehors du contexte fourni par les autres classes, si elles
ne font pas partie d'un plus grand ensemble, la relation association devrait alors être utilisée. De plus, en cas
d'hésitation, une association est plus appropriée ; les agrégations sont généralement évidentes et les choisir aide
seulement à simplifier le modèle. Ce n'est pas quelque chose d'essentiel pour le succès de la modélisation.
Parfois, une classe peut être agrégée à elle même. Cela ne signifie pas qu'une instance de cette classe est composée
d'elle-même (ce serait idiot), mais qu'une instance de la classe est un agrégat composé d'autres instances de la même
classe. Dans les cas d'auto-agrégation, les noms des rôles sont essentiels pour distinguer le but de l'association.
Exemple
Examinez l'auto-agrégation suivante impliquant la classe Produit:
Dans ce cet exemple, un produit peut être composé d'autres produits ; si tel est le cas, les produits agrégés sont
appelés sous-produits. Cette association peut se faire seulement de l'agrégat vers le sous-produit ; les sous-produits
ne savent pas à quels produits ils appartiennent (car ils peuvent appartenir à plusieurs produits).
|