Rubriques

Agrégation Haut de la page

On utilise l'agrégation pour modéliser une relation compositionnelle entre des éléments de modèle. Il y a de nombreux exemples de relations compositionnelles : une bibliothèque contient des livres, dans une entreprise les départements sont constitués d'employés, un ordinateur est composé d'un certain nombre de périphériques. Pour modéliser cela, l'agrégat (département) possède une association d'agrégation à ses parties constituantes (employé).

Un losange vide est attaché à la fin d'un chemin d'association du côté de l'agrégat (l'ensemble) pour indiquer l'agrégation.

Exemple

Dans cet exemple un client a une adresse. Nous utilisons l'agrégation car les deux classes représentent une partie d'un ensemble plus important. Nous avons également choisi de modéliser l'adresse comme une classe séparée, car de nombreux autres types d'éléments possèdent aussi des adresses.

exemple d'agrégation

Un objet agrégat peut regrouper d'autres objets.

Agrégation partagée Haut de la page

Une relation d'agrégation qui a une multiplicité supérieure à celle définie pour l'agrégat est appelée partagée, et en détruisant l'agrégat on ne détruit pas nécessairement les parties. Implicitement, 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 forte relation entre deux classes, pour que la même instance puisse participer à deux agrégations différentes.

Exemple

Examinez le cas où une personne possède une entreprise à domicile. La personne et l'entreprise ont chacune une adresse ; en fait il s'agit de la même adresse. L'adresse fait partie intégrante de la personne et de l'entreprise. Pourtant l'entreprise peut cesser d'exister, et la personne conservera peut-être la même adresse.

Notez également qu'il est possible dans ce cas de commencer avec une agrégation partagée, puis de passer à une agrégation non-partagée à une date ultérieure. L'entreprise à domicile peut se développer et prospérer, puis déménager dans des locaux séparés. A ce stade, la personne et l'entreprise ne partagent plus la même adresse. Ainsi, l'agrégation n'est plus partagée.

exemple d'agrégation

Un exemple d'agrégation partagée.

Composition Haut de la page

La composition est une forme d'agrégation où la partie et l'agrégat possèdent une appartenance forte et une durée de vie simultanée. La multiplicité de la section agrégat (dans l'exemple, la commande) ne peut pas dépasser un (c'est-à-dire qu'elle ne peut pas être partagée). De même, l'agrégation ne peut être modifiée, une fois établie, ses liens ne peuvent être changés. Implicitement, une agrégation composite forme un "arbre" de parties, la racine étant l'agrégat, et les "branches" les parties.

L'agrégation compositionelle doit être préférée à l'agrégation "simple" lorsqu'il existe une forte relation d'inter-dépendance entre l'agrégat et les parties ; lorsque la définition de l'agrégat est incomplète sans les parties. Dans l'exemple présenté ci-dessous, il semble logique d'avoir une commande même si rien n'est commandé (c'est-à-dire des lignes articles). Dans certain cas, cette inter-dépendance peut être identifiée dès l'analyse (comme c'est le cas avec cet exemple), mais plus généralement on doit attendre la conception pour pouvoir prendre ses décisions en toute confiance.

Un losange plein est attaché à la fin d'un chemin d'association pour indiquer la composition, comme on le voit ci-dessous :

agrégation compositionnelle

Exemple d'agrégation compositionnelle

Exemple

Dans cet exemple, l'interface client est composée de plusieurs autres classes. Dans cet exemple les multiplicités des agrégations ne sont pas encore définies.

Un exemple d'agrégation compositionnelle

Un objet d'interface client sait quels objets Affichage, imprimante de réception, pavé numérique, et haut-parleur lui appartiennent.

Utiliser la composition pour modéliser les propriétés de classe Haut de la page

Une propriété d'une classe est quelque chose que connaît la classe. Comme dans le cas de la classe client montrée ci-dessus, on peut choisir de modéliser l'adresse du client en tant que classe, comme nous l'avons montré, ou en tant qu'ensemble d'attributs d'une classe. La décision d'utiliser une classe et la relation d'agrégation ou bien un ensemble d'attributs dépend des éléments suivants :

  • Les "propriétés" doivent-elles posséder une identité indépendante, de façon à être référencées à partir d'un certain nombre d'objets ? Si c'est le cas, utilisez une classe et une agrégation.
  • Un certain nombre de classes doivent-elles posséder les mêmes "propriétés" ? Si c'est le cas, utilisez une classe et une agrégation.
  • Les "propriétés" possèdent-elles une structure complexe et des propriétés individuelles ? Si c'est le cas, utilisez une classe (ou des classes) et une agrégation.
  • Dans le cas contraire, utilisez des attributs.

Exemple

Dans un distributeur de billets, le système doit suivre les clients actuels et leur PIN : supposons que l'interface client est responsable de cette tâche. Cette information peut être considérée comme les "propriétés" de la classe. On peut effectuer cette tâche en utilisant une classe séparée, comme indiqué ci-dessous :

propriétés modélisées en utilisant une agrégation

Propriétés de l'objet modélisées en utilisant une agrégation

L'alternative, consistant à laisser à l'interface client le soin de suivre les clients actuels et leurs PIN en utilisant des attributs, est modélisée comme ci-dessous :

propriétés modélisées en utilisant des attributs

Propriétés de l'objet modélisées en utilisant des attributs

La décision d'utiliser des attributs ou une association d'agrégation à une classe séparée est prise selon le degré de couplage entre les concepts représentés : lorsque les concepts modélisés sont étroitement connectés, utilisez des attributs. Lorsque les concepts sont susceptibles de changer de façon indépendante, utilisez une agrégation.

Agrégation ou association ? Haut de la page

L'agrégation doit être uniquement utilisée lorsqu'il existe une relation compositionnelle entre les classes, dans laquelle une classe est composée d'autres classes, où les "parties" sont incomplètes en dehors du contexte de l'ensemble. Examinez le cas d'une commande : il est inutile d'avoir une commande "vide" constituée de "rien". Cela vaut pour tous les agrégats : les départements doivent avoir des employés, les familles doivent avoir des membres, etc.

Si les classes peuvent avoir une identité indépendante à l'extérieur du contexte fournit par d'autres classes, si elles ne sont pas des parties d'un ensemble plus important, la relation d'association doit alors être utilisée. De plus, en cas de doute, une association est plus appropriée ; les agrégations sont généralement évidentes, et le choix d'une agrégation a pour seul objectif de permettre un éclaircissement. Ce n'est pas un élément crucial pour le succès de l'effort de modélisation.

Auto-agrégations Haut de la page

Parfois, une classe peut avoir une agrégation avec elle-même. Cela ne signifie pas qu'une instance de cette classe est composée d'elle-même (ce serait absurde), mais qu'une instance de la classe est un agrégat composé d'autres instances de la même classe. Dans le cas des auto-agrégations, les noms de rôles sont essentiels pour distinguer l'objectif de l'association.

Exemple

Examinez les auto-agrégations suivantes concernant la classe produit:

Exemple d'auto-agrégation

Dans ce cas, un produit peut être composé d'autres produits ; si c'est le cas, les produits agrégés sont appelés des sous-produits. L'association n'est navigable que de l'agrégat au sous-produit ; c'est-à-dire que les sous-produits ne savent pas de quels produits ils font partie (car ils peuvent faire partie de plusieurs produits).



RUP (Rational Unified Process)   2003.06.15