UML : Les diagrammes de classes

Contents

Une classe est un concept qui reprend l'ensemble des propriétés (et non des valeurs de ces propriétés) communes à un ensemble d'éléments du domaine d'application ou de la machine.

Une classe est généralement une sorte de mode d'emploi, n'ayant pas d'existence propre. Le plus souvent, ce qui existe, ce sont les objets. Un objet est une entité réelle, qui correspond au mode d'emploi : nous retrouvons dans l'objet les attributs spécifiés dans la classe, et nous pouvons appeler sur l'objet les opérations (les méthodes) définies pour la classe.

Une classe est définie par son nom, ses attributs, et ses opérations. Nous représenterons donc la classe par un rectangle séparé en trois bandes horizontales.

Classe
[visibilité] attribut_1 [:type][=valeur initiale][{contrainte}]
[visibilité] attribut_2 [:type][=valeur initiale][{contrainte}]
...
[visibilité] attribut_n [:type][=valeur initiale][{contrainte}]
[visibilité] opération_1([[param:]type], ..., [[param:]type]) [:type]
[visibilité] opération_2([[param:]type], ..., [[param:]type]) [:type]
...
[visibilité] opération_n([[param:]type], ...,[[param:]type]) [:type]

Nous pouvons dire que le diagramme de classe est un diagramme « statique » car il ne permet pas de représenter les aspects dynamiques et temporels de ses éléments.

Contents Haut

Attributs

Chaque attribut comporte au minimum un nom. Si ce nom est souligné, cela signifie que la valeur de cet attribut est partagée par tous les objets de cette classe. Les autres renseignements sur l'attribut sont facultatifs.

La syntaxe complète des attributs est la suivante : [visibilité] nom [:type][=valeur initiale][{contrainte}], les éléments entre crochets étant facultatifs.

Visibilité

Le nom de l'attribut peut éventuellement être précédé par un type de visibilité (ou opérateur de visibilité), par exemple lors de la modélisation de classes d'un langage de programmation orienté-objet.

Exemples de type de visibilité en Java

Visibilité | Publique | Protégée | Paquet | Privée |
La classe elle même | OUI | OUI | OUI | OUI |
Une sous-classe du même package | OUI | OUI | OUI | NON |
Pas une sous-classe, mais du même package | OUI | OUI | OUI | NON |
Une sous-classe dans un autre package | OUI | OUI | NON | NON |
Pas une sous-classe, et dans un autre package | OUI | NON | NON | NON |
Symbole préfixe en UML | + | # | (rien) | - |
Nom usuel | public | protected | package | private |
Visibilité | Publique | Protégée | Paquet | Privée |

Contents Haut

Type

Nous pouvons faire suivre le nom de l'attribut par un double point et le type de l'attribut. Par exemple, nous pouvons avoir lastName : String, qui définit que les valeurs de l'attribut lastName sont de type String.

Contents Haut

Multiplicité

Nous pouvons ensuite aussi spécifier une multiplicité entre crochets. Nous définissons alors soit une valeur unique, qui correspond au nombre exact de fois que cet attribut est présent, soit (aussi entre crochets) une valeur minimum et une valeur maximum.

Par défaut (quand nous ne renseignons pas de multiplicité) cela correspond à un attribut monovalué3 obligatoire.

Exemples de multiplicités

  • [3] exactement 3 valeurs
  • [0..1] de 0 à 1 valeur (quand nous avons un minimum égal à 0, l'attribut est facultatif)
    • [0..*] de 0 à un nombre indéterminé
  • [3..5] au moins trois valeurs et maximum 5

Contents Haut

Valeur initiale

Nous pouvons spécifier la valeur que prendra cet attribut à la création d'un objet de cette classe.

Contents Haut

Contrainte

Nous pouvons ajouter certaines contraintes entre accolades.
Par défaut les valeurs d'un attribut sont modifiables à la création d'un objet de cette classe. Si nous désirons pécifier que ces valeurs ne sont pas modifiables par la suite, nous pouvons ajouter la contrainte {frozen} après l'attribut dans le diagramme de classe.

Contents Haut

Opérations

Chaque opération comporte au minimum un nom, suivi par des parenthèses. Les autres renseignements sur l'opération sont facultatifs.

Représentation

Par défaut, toute opération est concrète (c.a.d. qu'une implémentation existe au niveau de cette classe). Si nous désirons représenter une opération abstraite, nous devons écrire son nom en italique (et dans ce cas, la classe doit elle aussi être abstraite4).

Par défaut, toute opération est une opération d'instance (c.a.d. que nous devons avoir un objet de cette classe auquel nous pouvons demander d'exécuter l'opération). Si nous désirons représenter une opération de classe, nous devons souligner le nom. Cela signifie alors que nous pouvons demander à la classe elle-même d'effectuer l'opération, sans nécessairement devoir créer d'objet de cette classe.

Parties facultatives

La syntaxe complète des opérations est la suivante : [visibilité] nom ([[param:]type][,[param: ]*)[:type], les éléments entre crochets étant facultatifs.
Les valeurs que peut prendre la visibilité sont identiques aux valeurs de la visibilité des attributs.

Entre les parenthèses, nous pouvons retrouver des paramètres. Si ces derniers sont mentionnés, ce qui nous intéresse particulièrement est le type du paramètre, mais nous pouvons aussi spécifier le nom du paramètre avant son type.

Enfin, nous pouvons aussi spécifier, après la parenthèse fermante, le type de retour, qui est le type de la valeur renvoyée après un appel à cette opération.

Le diagramme de classe ne spécifie pas explicitement ce que fait l'opération; nous avons besoin pour cela d'un diagramme d'activité.

Contents Haut

Interfaces

Nous avons aussi un type particulièr : l'interface, pour lequelle toutes les opérations (et les attributs5) ont une visibilité de type public. C'est tout à fait logique si nous considérons nos interfaces comme des « contrats » (tout dans le contrat doit être visible de tous) que les classes qui l'implémentent6 s'engagent à respecter. En UML, Une interface est un ensemble d'attributs et de méthodes publiques que des classes peuvent s'engager à fournir (“provide” ) ou exiger (“require” ) d'autres classes.

Nous représentons le fait que notre classe est une interface par le mot clé entre doubles chevrons ouvrants et fermants au dessus du nom. Nous pouvons aussi plus simplement représenter notre interface par un petit cercle ou un demi-cercle vide, mais nous ne devons pas oublier de mentionner son nom en dessous du cercle.

« interface »
Nom


[+] opération_1([[param:]type], ..., [[param:]type]) [:type]
[+] opération_2([[param:]type], ..., [[param:]type]) [:type]
...
[+] opération_n([[param:]type], ...,[[param:]type]) [:type]
  • Si la classe fournit (implémente) l'interface, nous le représentons par un cercle.
  • Si la classe exige une interface, nous le représentons par un arc de cercle (un demi cercle vide) dans lequel peut se placer le cercle de l'interface de la classe qui fournit le service.

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 30/10/2006, last modified the 07/03/2020
Source of the printed document:https://www.gaudry.be/en/en/uml-class-diagram.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.

Notes
  1. ↑a,b Unified Modeling Language : corresponds to « langage de modélisation unifié » en français

  2. ↑a,b UML : “Unified Modeling Language” (en français, « langage de modélisation unifié ») Plus d'informations sur UML.

  3. ↑ monovalué : une seule valeur

  4. ↑ Opération abstraite : Si la classe possède au moins une opération abstraite, nous sommes dans l'impossibilité de créer une unstance de cette classe (comment exécuter une méthode qui n'est pas implémentée ?). La classe doit donc dans ce cas être abstraite elle aussi.

  5. ↑ Interface et attribut : Une interface peut spécifier des attributs, mais comme toutes les parties de l'interface doivent avoir une vivibilité de type public et que nous avons l'habitude de restreindre la visibilité de nos attributs à private ou protected, nous ne les spécifierons normalement jamais dans nos interfaces.

  6. ↑ Implémentation versus héritage : Une sous-classe hérite d'une super-classe (elle reçoit quelque chose de la classe parent), mais elle implémente une interface (elle ne reçoit rien, et doit fournir une implémentation de ce qui est spécifié dans le contrat).

Contents Haut

References

  1. book Language of the document:fr IHDCB335 - AMSI : Patrick HEYMANS, Analyse et modélisation des systèmes d'information (2009)
  2. View the html document Language of the document:uk UML 2 Tutorial : Sparx Systems Pty Ltd., Class Diagram
  3. View the pdf document Language of the document:uk UML Version 2.3 : Object Management Group, Inc., Infrastructure specification (03/05/10)
  4. View the pdf document Language of the document:uk 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.

Contents Haut