Diagramme de classes UML

Introduction au diagramme de classes UML

Le diagramme de classes est l’un des diagrammes structurels les plus utilisés dans la modélisation UML (Unified Modeling Language). Il décrit les classes, leurs attributs, leurs opérations ainsi que les relations entre elles (associations, héritage, dépendances, etc.). Ce cours reprend les notions essentielles testées dans le quiz et les développe de façon pédagogique, tout en étant optimisé pour le référencement naturel (SEO).

Visibilité des membres dans UML

Dans UML, chaque attribut ou opération possède une visibilité qui indique qui peut y accéder. Les symboles les plus courants sont :

• + : public – accessible depuis n’importe quelle classe.
• # : protected – accessible dans la classe où il est déclaré et dans ses sous‑classes.
• - : private – accessible uniquement dans la classe qui le possède.
• ~ : package – accessible aux classes du même paquet (ou même namespace).

Le symbole # correspond donc à la visibilité protected. Cette visibilité permet aux classes dérivées d’utiliser ou de modifier le membre tout en le protégeant des accès extérieurs non contrôlés.

Associations et réflexivité

Une association représente une relation structurée entre deux classes. Lorsqu’une classe possède une relation avec elle‑même, on parle d’association réflexive. Visuellement, cela se traduit par les deux extrémités de la ligne qui pointent vers la même classe.

Exemple :

• Classe Employee avec une association « supervise » vers elle‑même, indiquant qu’un employé peut superviser d’autres employés.

Cette représentation montre clairement la nature auto‑référentielle de la relation.

Contraintes de multiplicité : le rôle de {XOR}

Les contraintes de multiplicité précisent le nombre d’instances participant à une association. La contrainte {XOR} indique que deux (ou plusieurs) associations sont mutuellement exclusives : une instance ne peut appartenir qu’à l’une d’elles à la fois.

Utilisation typique :

• Une classe Payment peut être liée soit à CreditCard, soit à BankTransfer, mais jamais aux deux simultanément.

Cette contrainte aide à modéliser des choix alternatifs dans le modèle métier.

Méthodes de classe vs méthodes abstraites

Dans la modélisation UML, il est crucial de distinguer deux types de méthodes :

• Méthode de classe (ou static) : possède un corps complet et agit généralement sur des attributs de classe (partagés par toutes les instances). Elle est invoquée via le nom de la classe.
• Méthode abstraite : ne possède pas d’implémentation dans la classe où elle est déclarée. Elle ne définit que son entête (signature) et doit être implémentée dans les sous‑classes concrètes.

La différence fondamentale réside donc dans la présence d’un corps : la méthode de classe possède un corps, alors que la méthode abstraite ne possède que son entête.

Représentation des associations n‑aires

Une association n‑aire implique plus de deux classes simultanément. UML la représente à l’aide d’un losange (ou diamond) relié à chaque classe participante.

Exemple typique :

• Association Enrollment entre les classes Student, Course et Semester. Le losange Enrollment est relié aux trois classes, indiquant que chaque inscription implique un étudiant, un cours et un semestre.

Cette notation clarifie les relations complexes où plusieurs entités interagissent simultanément.

Attributs dérivés

Un attribut « dérivé » est calculé à partir d’autres attributs ou de règles métier, plutôt que d’être stocké directement. En UML, on le signale généralement avec une barre oblique / devant le nom de l’attribut.

Exemple :

• Classe Rectangle avec les attributs width et height. L’attribut dérivé /area est calculé comme width * height.

Les attributs dérivés permettent de représenter des valeurs qui restent toujours cohérentes avec les données sources.

Contraintes OCL : garantir la monotonie d’une collection

OCL (Object Constraint Language) complète UML en offrant un langage formel pour exprimer des contraintes. Pour assurer qu’une collection orders ne diminue jamais (c’est‑à‑dire qu’on ne peut qu’ajouter des éléments), on utilise la contrainte {addonly}.

Syntaxe typique :

context Customer inv: self.orders->isOrderedBy(self) and self.orders->size() >= self.orders@pre->size()

Cette contrainte garantit que le nombre d’ordres ne peut que croître ou rester stable, jamais diminuer.

Compartiments d’une classe UML

Un diagramme de classe représente chaque classe sous forme d’un rectangle découpé en trois compartiments :

• Compartiment du haut : nom de la classe.
• Compartiment du milieu : attributs (propriétés).
• Compartiment du bas : opérations (méthodes).

Les opérations sont donc placées dans le compartiment du bas, ce qui permet de distinguer clairement les comportements de la classe des données qu’elle possède.

Résumé des concepts clés

• Visibilité # = protected.
• Association réflexive : les deux extrémités pointent vers la même classe.
• Contrainte {XOR} : exclusivité mutuelle entre associations.
• Méthode de classe possède un corps ; méthode abstraite ne possède que l’entête.
• Association n‑aire représentée par un losange relié à chaque classe.
• Attribut dérivé : calculé à partir d’autres attributs, noté /.
• Contrainte OCL {addonly} : collection qui ne diminue jamais.
• Compartment du bas du rectangle UML contient les opérations.

Maîtriser ces notions vous permettra de créer des diagrammes de classes clairs, précis et conformes aux standards UML, facilitant ainsi la communication entre développeurs, analystes et parties prenantes.