UML : relations entre classes
Le plus souvent, nous ne nous contentons pas de représenter une seule classe, mais bien un ensemble de classes qui ont certains liens entre-elles. Nous pouvons diviser les relations qui unissent les classes en différentes catégories :
- association
- agrégation et composition
- généralisation ( et vice versa : spécialisation)
- dépendances
Association
Nous représenterons les associations en UML par un trait entre deux classes, le plus souvent avec un nom qui caractérise l'association. Nous pouvons aussi mentionner le sens de lecture de l'association par une flèche près du nom de l'association.
Chaque extémité d'une association est un rôle. Un rôle peut comporter un nom, une multiplicité, et plus rarement une visibilité.
Multiplicité des rôles
Attention que la position de la multiplicité en UML est inversée à celle utilisée en analyse entité relationnelle.Associations un à un
Dans le cas d'une relation “one-to-one”, la multiplicité du rôle d'origine est de 1, tandis que celle du rôle de destination est de 0..1 (dans le cas d'un attribut facultatif, sinon 1). Une classe d'origine ne peut être liée à plus d'une classe de destination.
Associations un à plusieurs
Dans le cas d'une relation “one-to-many”, la multiplicité du rôle d'origine est de 0..1, tandis que celle du rôle de destination est de 0..*. Nous ne pouvons pas avoir plus d'une classe d'origine pour une même classe de destination.
Associations plusieurs à plusieurs
Dans le cas d'une relation “many-to-many”, la multiplicité de chaque rôle est de 0..*. Une classe d'origine peut être liée à plusieurs classes de destination, et plusieurs classes d'origine peuvent être liées à la même classe de destination.
Associations n-aires
Jusqu'à présent, nous avons envisagé des relations entre deux classes (relations binaires), mais nous pouvons avoir certains types de relations qui impliquent plus de deux classes (les relations n-aires avec n>2). Ces relations n-aires ne sont pas toujours évidentes à gérer, et certains auteurs suggèrent de ne pas les utiliser. Nous tenterons de les utiliser le moins souvent possible, et de ne pas dépasser le nombre de trois classes impliquées dans la relation.
Nous représenterons une association n-aire par un losange, des angles duquel partent nos traits qui le relient à nos classes.
Classes d'associations
Nous avons parfois besoin de manipulerr certaines informations qui dépendent de la relation elle-même. Nous représenterons nos classes d'associations comme nos autres classes, mais nous retrouverons rarement la partie opérations.
Nous relierons ensuite en traits pointillés cette classe d'association à l'association qu'elle caractérise (soit le trait de l'association dans le cas d'une relation binaire, ou alors le losange dans le cas d'une relation n-aires). Nous ne représenterons pas la multiplicité de la classe d'association, car nous avons une relation one-to-one implicite.
Associations qualifiées
Nous pouvons retrouver certains attributs de la relation sous forme d'un « qualifieur », sous la forme d'un rectangle du côté de la classe de départ, mais ce type de représentation est à éviter.
Agrégation
Une agrégation est une association non symétrique qui introduit une notion de subordination. Nous avons donc une classe qui représente un ensemble, et une classe qui représente un élément de cet ensemble (l'élément est subordonné à l'ensemble). Nous donnerons le nom d'agrégat à la classe qui représente l'ensemble.
La relation entre l'élément et l'agrégat est cependant assez faible : l'élément peut être lié en même temps à plusieurs agrégats différents, et l'agrégat peut exister sans la présence d'éléments (de même, l'élément peut exister sans l'agrégat).
Nous représenterons la relation d'agrégation comme une autre association, mais avec un losange vide du côté de l'agrégat.
Composition
Une composition est une association très forte dont l'existence du composant (un des éléments de l'ensemble) dépend de celle du composé (l'ensemble). Nous retrouvons parfois l'expression « agrégation par valeur » pour désigner une composition.
La relation est très forte : le composant ne peut être lié en même temps qu'à un seul composé; et si le composé est détruit, le composant est détruit aussi.
Nous représenterons la relation de composition comme une agrégation, mais avec un losange plein du côté du composé.
Relation d'héritage
Pour représenter le fait qu'une sous-classe hérite d'une super-classe, nous relierons les deux classes par un trait terminé par un triangle vide dont la pointe touche le bas de la super-classe. Deux groupes, constitués de contraintes opposées nous permettent de préciser la relation :
- Pouvons-nous avoir des instances qui ne soient d'aucune sous-classe ?
- “complete”
- “incomplete”
- Une instance peut-elle appartenir à plusieurs sous-classes ?
- “overlapping”
- “disjoint”
Par défaut (c.a.d. si nous ne spécifions pas de restriction), toute sous-classe est reliée à sa classe parente par une association avec la contrainte {overlapping, incomplete}.
Contrainte “complete”
Nous pouvons qualifier de “complete” la relation de spécialisation quand nous souhaitons ajouter la contrainte qu'il ne peut exister d'instance de la super-classe qui ne soit une instance de la sous-clase. En pratique, nous qualifierions la super-classe de classe abstraite pour supprimer toute possibilité ce création d'un objet de cette super-classe.
Nous représentons la contrainte par {complete} à côté de la flèche de la relation de spécialisation.
Contrainte “incomplete”
Nous pouvons qualifier de “incomplete” la relation de spécialisation quand il peut exister des instance de la super-classe qui ne sont pas des instances d'une des sous-clases. En pratique, nous qualifierions la super-classe de classe abstraite pour supprimer toute possibilité ce création d'un objet de cette super-classe.
Nous représentons la contrainte par {incomplete} à côté de la flèche de la relation de spécialisation.
Contrainte “overlapping”
Nous pouvons qualifier de “overlapping” la relation de spécialisation quand une instance de la super-classe peut appartenir simultanément à plusieurs sous-classes. Ce type de représentation ne peut être appliqué tel quel dans certains langages, comme par exemple en Java (Nous devrions alors recourir à des interfaces pour contourner le problème).
Nous représentons la contrainte par {overlapping} (ou {overlapping, incomplete} à côté de la flèche de la relation de spécialisation.
Contrainte “disjoint”
Nous pouvons qualifier de “disjoint” la relation de spécialisation quand une instance de la super-classe ne peut appartenir simultanément qu'au maximum à une seule sous-classe.
Nous représentons la contrainte par {disjoint} à côté de la flèche de la relation de spécialisation.
Contrainte “partition”
Nous pouvons qualifier de “partition” la relation de spécialisation quand les caractéristiques de disjoint et complete sont réunies. Donc une association avec la contrainte {disjoint, complete} ne peut comporter que des instances qui n'appartiennent qu'à une seule sous-classe, et aucune instance du super-type.
Nous représentons la contrainte par {disjoint, complete} à côté de la flèche de la relation de spécialisation.
Dépendances
Nous noterons toutes les autres relations entre les classes comme des relations de dépendances, par un trait pointillé terminé par une flèche ouverte vers la classe de destination. Nous noterons le type de la relation de dépendance entre doubles chevrons ouvrants et fermants.
Exemples de types de relations de dépendances entre classes : « instanciate », « refine », « trace », « implements », « use », etc.
Document créé le 11/06/2010, dernière modification le 07/03/2020
Source du document imprimé : https://www.gaudry.be/uml-class-diagram-relation.html
L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.
Notes
Références
IHDCB335 - AMSI : Patrick HEYMANS, Analyse et modélisation des systèmes d'information
(2009)
UML 2 Tutorial : Sparx Systems Pty Ltd., Class Diagram
UML Version 2.3 : Object Management Group, Inc., Infrastructure specification
(03/05/10)- UML Version 2.3 : Object Management Group, Inc.,
Superstructure specification
(05/05/10)
Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.
