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.
English translation
You have asked to visit this site in English. For now, only the interface is translated, but not all the content yet.If you want to help me in translations, your contribution is welcome. All you need to do is register on the site, and send me a message asking me to add you to the group of translators, which will give you the opportunity to translate the pages you want. A link at the bottom of each translated page indicates that you are the translator, and has a link to your profile.
Thank you in advance.
Document created the 11/06/2010, last modified the 07/03/2020
Source of the printed document:https://www.gaudry.be/en/uml-class-diagram-relation.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
References
- 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)
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.