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 structures statiques d’un système : classes, attributs, opérations, relations et contraintes. Cette leçon couvre les concepts clés rencontrés dans les questions d’un quiz typique, afin de vous aider à maîtriser la lecture et la création de diagrammes de classes.

Visibilité des membres de classe

En UML, chaque attribut ou opération possède une visibilité qui indique son niveau d’accès. Les symboles les plus courants sont :

• + : public – accessible depuis n’importe quel autre élément du modèle.
• - : privé – accessible uniquement à l’intérieur de la classe.
• # : protégé – accessible aux sous‑classes.
• ~ : package – accessible aux classes du même paquetage.

Dans le quiz, la bonne réponse était Public, représenté par le symbole « + ».

Multiplicité des associations

La multiplicité indique le nombre d’instances qui peuvent participer à une association. Elle se place à chaque extrémité du lien.

Exemple : "1..*"

Le texte "1..*" signifie au moins une instance de la classe cible, sans limite supérieure. Ainsi, l’association peut contenir une, deux, voire plusieurs instances, mais jamais zéro.

Cette notion est cruciale pour exprimer des contraintes comme « chaque client possède au moins une commande ».

Contraintes UML : le stéréotype {frozen}

UML permet d’ajouter des contraintes sous forme de stéréotypes entre accolades. Le stéréotype {frozen} s’applique généralement aux collections et indique que le nombre d’objets ne peut pas varier après leur création.

Par exemple, une collection Set<Employee> {frozen} signifie que le nombre d’employés dans cet ensemble est fixe : aucune addition ni suppression n’est autorisée.

Représentation des classes abstraites et des méthodes abstraites

Une classe abstraite ne peut pas être instanciée directement. En UML, on la représente en italique :

• Le nom de la classe est écrit en italique.
• Les méthodes abstraites sont également en italique.

Cette convention visuelle permet de distinguer rapidement les éléments qui nécessitent une implémentation dans les sous‑classes.

Méthodes de classe vs méthodes d’instance

Les deux types de méthodes diffèrent principalement par le type d’attributs qu’elles manipulent :

• Méthode d’instance : agit sur les attributs d’une instance particulière (les variables d’objet). Elle nécessite un objet pour être invoquée.
• Méthode de classe (ou méthode statique) : agit uniquement sur les attributs de classe (variables partagées entre toutes les instances). Elle peut être appelée sans créer d’objet.

Dans le quiz, la réponse correcte était que la méthode de classe ne manipule que les attributs de la classe elle‑même.

Associations asymétriques et rôles

Une association asymétrique indique une direction de navigation privilégiée. Pour clarifier le sens de la relation, il est recommandé d’ajouter les rôles des extrémités. Le rôle décrit la fonction ou la signification de chaque extrémité dans le contexte du modèle.

Par exemple, dans une association entre Client et Commande, on peut préciser les rôles « client » et « commande » afin de rendre le diagramme plus lisible.

Contraintes OCL : {subset}

OCL (Object Constraint Language) complète UML en permettant d’exprimer des contraintes précises. Le stéréotype {subset} garantit qu’une collection A est toujours un sous‑ensemble d’une autre collection B. En OCL, cela s’écrit généralement :

context MyClass
inv: self.A->includesAll(self.B)

Cette contrainte assure l’intégrité des relations entre collections, par exemple « les employés d’un projet sont toujours un sous‑ensemble des employés de l’entreprise ».

Associations n‑aires

Contrairement aux associations binaires (entre deux classes), une association n‑aire relie trois classes ou plus. Elles sont utiles pour modéliser des relations complexes où plusieurs entités interviennent simultanément.

Exemple classique : une association Participation qui relie Étudiant, Cours et Enseignant. Chaque instance de Participation représente la participation d’un étudiant à un cours donné, animé par un enseignant.

Bonnes pratiques pour la création d’un diagramme de classes UML

• Utilisez des noms clairs et cohérents pour les classes, attributs et opérations.
• Respectez les conventions de visibilité (+, -, #, ~) afin de faciliter la lecture.
• Indiquez toujours la multiplicité aux deux extrémités d’une association.
• Ajoutez les rôles dans les associations asymétriques pour préciser le sens.
• Employez l’italique pour les classes et méthodes abstraites.
• Spécifiez les contraintes (ex. {frozen}, {subset}) entre accolades pour rendre les règles d’affaires explicites.
• Préférez les associations binaires lorsqu’une relation peut être décomposée ; n’utilisez les n‑aires que si la sémantique ne se prête pas à une modélisation plus simple.

Résumé des concepts clés du quiz

• Visibilité « + » = public.
• Multiplicité "1..*" = au moins une instance.
• {frozen} = nombre d’objets fixe.
• Classe abstraite et méthode abstraite = nom en italique.
• Méthode de classe = manipule uniquement les attributs de classe.
• Association asymétrique = ajouter les rôles des extrémités.
• {subset} = contrainte OCL de sous‑ensemble.
• Association n‑aire = relie plus de deux classes.

Exercices pratiques

Pour consolider vos connaissances, essayez les activités suivantes :

1. Créez un diagramme de classes simple pour un système de bibliothèque. Incluez les visibilités, les multiplicités, et une classe abstraite Document avec une méthode abstraite getTitle().
2. Ajoutez une association asymétrique entre Bibliothécaire et Prêt en précisant les rôles « gère » et « effectue ».
3. Définissez une contrainte {frozen} sur la collection ISBNList d’une classe Catalogue.
4. Modélisez une association n‑aire impliquant Étudiant, Cours et Semestre.

Ces exercices vous permettront de mettre en pratique les notions abordées et d’améliorer votre aisance avec les diagrammes de classes UML.