Relations entre les éléments des diagrammes de classes

Remonter à Diagrammes de classes UML 1.5

Une relation est une connexion entre des éléments. Dans la Modélisation, les trois relations majeures sont les dépendances, les généralisations et les associations. Une relation est représentée graphiquement par différents types de lignes utilisées pour distinguer les types de relations.

Types de relations entre les éléments des diagrammes de classes

Vous pouvez utiliser les types suivants de relations entre les éléments des diagrammes de classes :

• Généralisation et implémentation
• Dépendance
• Association (association simple, association n-aire, agrégation et composition)
• Interfaces fournies et interfaces requises (UML 2.0)

Généralisation et implémentation

• Généralisation -- Une généralisation est une relation entre un élément général (superclasse ou parent) et un type plus spécifique de cet élément (sous-classe ou enfant). Une généralisation est aussi utilisée pour pointer la relation d'héritage entre deux interfaces (un enfant et un parent).

La généralisation signifie qu'un enfant hérite des propriétés (attributs, opérations et autres) de ses parents et que les objets de l'élément enfant sont utilisables partout où peuvent apparaître les objets de l'élément parent.

Une généralisation est représentée graphiquement sous la forme d'une ligne dirigée continue avec une grande tête de flèche fermée, pointant sur le parent :

• Implémentation -- Une relation d'implémentation est le type spécial de la relation de généralisation. Une implémentation est un lien d'héritage indiquant qu'une classe enfant implémente une interface parent.

Une implémentation est représentée graphiquement sous la forme d'une ligne dirigée de pointillés avec une grande tête de flèche fermée, pointant sur l'interface parent :

Dépendance

Une dépendance est une relation entre deux éléments dans laquelle une modification à un élément (l'élément indépendant - fournisseur) provoque des modifications sur l'autre élément (l'élément dépendant - client).

Une dépendance est représentée graphiquement sous la forme d'une ligne dirigée de pointillés, dirigée vers l'élément indépendant (fournisseur):

Association

Une relation entre les instances de deux classes. Il y a association entre deux classes si une instance d'une classe (client) doit connaître l'autre (fournisseur).

Dans un diagramme, une association est représentée sous la forme d'une ligne continue connectant deux classes.

La navigation, les rôles et les multiplicités sont des éléments facultatifs placés sur les associations dans un souci de clarté :

• Navigation d'association. Les associations peuvent être dirigées ou non-dirigées. Un lien dirigé pointe sur la classe fournisseur (la cible). Une flèche de navigation sur une association montre la direction dans laquelle l'association peut être traversée ou interrogée. Une classe peut être interrogée à propos de son "élément", mais pas le contraire. La flèche vous informe aussi sur le "propriétaire" de l'implémentation de l'association. Les associations sans flèche de navigation sont bidirectionnelles. Par exemple, une association bidirectionnelle entre les classes Library et Book indique que vous pouvez effectuer une traversée des objets du type Library vers les objets du type Book, et aussi dans l'autre sens.

• Rôles. Une association a deux extrémités. Chaque extrémité peut comporter un nom de rôle pour clarifier la nature de l'association.

• Multiplicité. Une extrémité d'association peut comporter une multiplicité. La multiplicité d'une extrémité d'association est le nombre d'instances possibles de la classe associée à une instance unique de l'autre extrémité. Les multiplicités sont des nombres ou des intervalles de nombres.

Ce tableau répertorie les multiplicités les plus courantes :

Multiplicité	Signification
0..1	Zéro ou une instance. La notation n..m indique n à m instances.
1 ou n	Exactement une instance ou exactement n instances.
0..* ou *	Pas de limite sur le nombre d'instances (y compris aucune).
1..*	Au moins une instance.

Types d'associations

Voici les types d'une relation d'association :

1. Association (Association simple) -- Une association ("association simple") entre deux classes homologues. Elle représente une relation pure structurelle entre deux homologues. Les deux classes sont conceptuellement au même niveau, n'étant pas plus importantes l'une que l'autre.

Une association est représentée graphiquement sous la forme d'une ligne continue connectant deux classes :

Cette figure montre le lien "association simple", ayant le rôle owner, les multiplicités 1 et 0..*, et spécifie la navigation d'association de la classe Client vers la classe Password.

2. Association (Association n-aire) -- Une association n-aire peut connecter autant de classes d'extrémités d'associations (participants) que nécessaire. Pour créer des associations n-aire, utilisez une classe d'association.

Les classes d'association apparaissent dans les diagrammes sous la forme de trois éléments associés :

* La classe d'association elle-même (), représentée par une icône de classe.

* Un lien de classe d'association n-aire (), représenté par un losange.

* Un connecteur d'association (), représenté par un lien entre une icône de classe d'association et un losange d'association.

L'inspecteur d'objets d'une classe d'association, d'un lien d'association et d'un connecteur contient un onglet Association supplémentaire. Cet onglet contient seulement la propriété label, sa valeur étant synchronisée avec le nom de la classe d'association. Pour les classes d'association et les liens d'extrémité d'association, l'élément Custom de l'inspecteur d'objets affiche des propriétés supplémentaires qui correspondent au rôle de cette partie de l'association n-aire (respectivement associationClass et associationEnd).

Vous pouvez supprimer les liens d'extrémité d'association ou les classes participantes sans détruire l'association n-aire entière. Néanmoins, la suppression de la classe d'association aboutit à la suppression de tous les composants de l'association n-aire.

Voir aussi : Création d'une classe d'association.

3. Agrégation -- Une agrégation est le type spécial d'association représentant une relation "partie-tout", dans laquelle une classe représente un plus grand élément ("tout") contenant de plus petits éléments ("parties"). Un lien d'agrégation distinct est utilisé entre chaque classe représentant une partie et une classe représentant le tout.

Une agrégation est représentée graphiquement sous la forme d'une ligne continue entre deux classes, avec un losange creux à l'extrémité "tout" :

Cette figure montre le lien d'agrégation. La classe Order représente le "tout" et la classe Person représente les "parties". Les multiplicités 0..* sur les deux extrémités et les rôles union et member spécifient que chaque union (du type Group) peut contenir n'importe quel nombre de members (du type Person) et, au contraire, que chaque objet de type Person peut être un member de n'importe quel nombre de unions (du type Group). La navigation d'agrégation bidirectionnelle spécifie qu'un objet de type Group peut demander ses membres de type Person et qu'un objet de type Person peut demander les unions (du type Group type) dont il est un membre.

4. Composition -- Une composition est une forme "forte" spéciale d'agrégation dans laquelle "l'extrémité composite" a la responsabilité totale de la gestion de ses "extrémités de parties" (comme la création et la destruction de ses parties).

Une composition est représentée graphiquement sous la forme d'une ligne continue entre deux classes, avec un losange plein à l'extrémité de la composition :

Cette figure montre les liens de composition. La classe Order représente la "composition" et les classes Customer et LifeItem représentent les "parties".

Interfaces fournies et interfaces requises

Les diagrammes de classes UML 2.0 introduisent les interfaces fournies et les interfaces requises.

Pour marquer les interfaces fournies et les interfaces requises, les diagrammes de classes UML 2.0 utilisent les liens d'interface fournie (notation "lollipop") et d'interface requise (notation "soket") (voir Eléments des diagrammes de classes UML 2.0).

Voir aussi

• Diagrammes de classes UML 2.0
• Procédures des diagrammes de classes