Diagramme de classes

1. Identifier les bonnes classes

Le diagramme de classes représente la structure du domaine ou d’une solution. On commence par les concepts dont le système doit conserver l’identité et les informations : Client, Demande, Devis et LigneDevis. Les verbes du besoin aident ensuite à attribuer les responsabilités : un devis calcule son total et contrôle son acceptation.

Relever les noms dans un texte constitue un point de départ, pas une procédure automatique. « Bouton », « écran » et « rapidité » ne deviennent pas nécessairement des classes métier. Un statut peut être une valeur d’énumération plutôt qu’une classe autonome. Le choix dépend de ce que le système doit représenter.

On sépare le modèle du domaine, qui explique les notions métier, du modèle de conception, qui peut comporter contrôleurs, services et dépôts. Le premier est relu avec les utilisateurs ; le second organise la réalisation logicielle.

2. Lire les compartiments et les signatures

Une classe se dessine avec un rectangle généralement divisé en trois zones : son nom, ses attributs et ses opérations. Une visibilité peut précéder un membre : + public, - privé, # protégé, ~ accessible dans le paquetage.

Devis
-----------------------------
- reference : String
- dateExpiration : Date
- statut : StatutDevis
/ total : Decimal
-----------------------------
+ calculerTotal() : Decimal
+ accepter(date : Date) : void

La barre oblique indique une propriété dérivée. Ici, total découle des lignes du devis. Une opération décrit un service offert par la classe ; sa méthode est la réalisation concrète de ce service. La signature nomme les paramètres et le type de retour.

Les montants utilisent dans cette étude une représentation décimale et une devise explicite. Le modèle ne fixe pas encore une bibliothèque numérique. Un devis ne doit pas accepter un total incohérent simplement parce qu’un écran l’a envoyé.

3. Associations et multiplicités : lire dans les deux sens

Une association exprime un lien structurel entre instances. La multiplicité inscrite près d’une extrémité indique combien d’objets de cette extrémité peuvent être liés à un objet de l’autre extrémité. Pour Client 1 : 0..* Demande, chaque demande appartient à un client et un client possède zéro, une ou plusieurs demandes.

Un nom de rôle précise le sens d’un lien : propriétaire, versions, responsable. Une flèche de navigabilité indique un accès dans une direction ; l’absence de flèche ne signifie pas toujours « accès dans les deux sens », car un diagramme peut laisser cette information non spécifiée.

R2 contient une contrainte que la multiplicité 0..* ne suffit pas à exprimer : plusieurs devis peuvent être associés à la demande, mais au plus un est accepté. On ajoute cette règle entre accolades ou dans une note liée au modèle.

4. Composition, agrégation et dépendance

La composition se note par un losange plein du côté du tout. Une LigneDevis appartient à un seul Devis à un instant donné. Dans notre modèle, elle n’a pas d’existence métier autonome après suppression définitive de ce devis. Les règles d’archivage peuvent conserver le tout et ses parties sans contredire cette appartenance.

L’agrégation partagée, représentée par un losange creux, indique une relation tout-parties plus faible dont les détails dépendent du domaine. Elle ne précise pas à elle seule un cycle de vie. Une association ordinaire est souvent plus claire si aucune règle supplémentaire n’est définie.

La dépendance se représente par une flèche en pointillés vers l’élément utilisé. ServiceDevis dépend d’un contrat de notification pour envoyer un message ; cela ne signifie pas qu’une notification fait partie du devis. Association et dépendance répondent donc à des besoins différents.

5. Généralisation et interfaces

La généralisation est un trait plein terminé par un triangle creux orienté vers la classe générale. Une classe spécialisée doit pouvoir être utilisée là où la classe générale est attendue, en respectant son contrat. Une opération abstraite annonce un comportement que les classes concrètes doivent fournir.

Une interface décrit un contrat sans imposer l’état interne d’une implémentation. La réalisation d’une interface se dessine avec un trait en pointillés et un triangle creux pointant vers l’interface. CanalNotification peut déclarer envoyer(message), puis Courriel et SMS réaliser ce contrat.

Un rôle professionnel ne justifie pas automatiquement une sous-classe. Une personne pouvant changer de fonction ou cumuler plusieurs fonctions peut être mieux représentée par Utilisateur, Role et Affectation. Ce choix évite de transformer un changement d’affectation en changement artificiel de type d’objet.

6. Contraintes, classes d’association et validation

Une classe d’association porte les informations d’un lien. Si un collaborateur intervient sur plusieurs demandes avec une date d’affectation et un volume prévu, ces valeurs décrivent l’affectation, pas le collaborateur seul ni la demande seule. La classe Affectation peut alors représenter cette relation.

Les contraintes complètent le dessin : {quantite > 0}, {prixUnitaire >= 0}, {au plus un devis accepté par demande}. On peut employer du texte précis ; une expression formelle exige de connaître les noms et types du modèle. Des contraintes trop vagues restent impossibles à tester.

Pour valider, choisir une demande sans devis, une demande avec deux versions et un devis à deux lignes. Lire chaque multiplicité dans les deux sens. Rechercher ensuite les situations interdites : ligne sans devis, demande sans client, deux devis acceptés pour une même demande. La page suivante construit ces exemples sous forme de diagrammes d’objets.

Scénarios illustrés : comparer les situations

Varier le canal sans changer le métier

Le service utilise envoyer(message) par l’intermédiaire d’un contrat. Les réalisations Courriel et SMS proposent le même service avec des moyens différents. Le triangle creux pointe vers l’interface ; le trait de réalisation est discontinu.

Porter les informations d’une participation

Une date d’affectation et un volume prévu décrivent la relation entre une personne et un dossier. La ligne discontinue rattache la classe d’association à l’association. Cet exemple suppose une affectation par paire ; pour plusieurs épisodes distincts entre la même personne et la même demande, on peut modéliser Affectation comme une classe autonome avec son propre identifiant.

Exercices corrigés