UML : Les diagrammes de classes

Sommaire du document

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.

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.

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

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.

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

Valeur initiale

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

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.

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 abstraite^[4]).

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é.

Interfaces

Nous avons aussi un type particulièr : l'interface, pour lequelle toutes les opérations (et les attributs^[5]) 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émentent^[6] 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.

• 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.

Notes

1. ↑^a,b Unified Modeling Language : correspond à « 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).
   
   

Références

1. IHDCB335 - AMSI : Patrick HEYMANS, Analyse et modélisation des systèmes d'information (2009)
2. UML 2 Tutorial : Sparx Systems Pty Ltd., Class Diagram
3. UML Version 2.3 : Object Management Group, Inc., Infrastructure specification (02/05/10)
4. UML Version 2.3 : Object Management Group, Inc., Superstructure specification (04/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.

Structure du document