Diagramme de classes : attributs, opérations, visibilité et multiplicités

Le diagramme de classes représente la structure d'un logiciel orienté objet : ses classes, avec leurs attributs et leurs opérations, et les relations entre ces classes. C'est le diagramme UML le plus utilisé, celui qui se traduit directement en code et celui que les sujets d'examen fournissent le plus souvent. Ce chapitre présente la notation d'une classe, la visibilité, les associations et la lecture des multiplicités ; le chapitre 5 traite l'héritage, la composition, l'agrégation et les interfaces.

Classe et objet

Une classe décrit un ensemble d'objets qui ont la même structure et le même comportement : la classe FicheFrais décrit toutes les fiches de frais. Un objet (ou instance) est un exemplaire précis : la fiche de novembre 2026 de Lucas Moreau. La classe est le moule, l'objet est le gâteau. Le diagramme de classes montre les moules ; le diagramme d'objets (chapitre 10) montre des gâteaux à un instant donné.

Les notions de classe, d'objet, d'encapsulation et de constructeur sont expliquées en détail, code à l'appui, dans le cours Programmation orientée objet (classe et objet, encapsulation). Ce chapitre se concentre sur la façon de les dessiner.

La notation d'une classe

Une classe se dessine par un rectangle à trois compartiments :

1. le nom, au singulier, en UpperCamelCase (FicheFrais, LigneFraisHorsForfait), centré et en gras ;
2. les attributs, les données que chaque objet porte ;
3. les opérations, ce que chaque objet sait faire.

On n'est pas obligé de tout montrer. Selon le moment du projet, une classe peut se réduire à son nom (diagramme d'esquisse, vue d'ensemble), montrer ses attributs sans types (analyse), ou tout détailler (conception, avant le code). Un compartiment vide n'affirme rien : il dit seulement qu'on ne montre rien ici.

Les attributs

La syntaxe complète d'un attribut est :

visibilité nom : Type [multiplicité] = valeurInitiale {propriétés}

Seul le nom est obligatoire ; en conception, on donne au moins la visibilité, le nom et le type.

Pour les types, UML définit quelques types primitifs (Integer, Real, Boolean, String), mais les diagrammes de conception utilisent presque toujours ceux du langage visé : int, decimal, bool, string, DateOnly en C#. Les sujets d'examen font de même, parfois avec des types génériques (Entier, Chaîne, Date) : reprends les types du sujet.

Les opérations

La syntaxe d'une opération est :

visibilité nom(paramètre : Type, …) : TypeRetour

En général, on ne dessine ni les accesseurs (getMois(), setMois()) ni les propriétés C# triviales : ils alourdissent le diagramme sans rien apprendre. On ne montre que les opérations qui portent une logique métier.

La visibilité

La visibilité dit qui a le droit d'utiliser un attribut ou une opération. C'est la traduction graphique de l'encapsulation : en règle générale, les attributs sont privés et les opérations utiles aux autres classes sont publiques.

Les associations

Une association est une relation durable entre deux classes : leurs objets se connaissent. Elle se dessine par un trait plein entre les deux classes et peut porter :

• un nom, au milieu, souvent un verbe, avec un petit triangle qui donne le sens de lecture : « Visiteur — remplit ▸ — FicheFrais » ;
• un rôle à chaque extrémité, qui dit ce que représente l'objet du bout pour celui d'en face : validateur du côté de Comptable (pour une fiche, ce comptable est son validateur) ;
• une multiplicité à chaque extrémité ;
• une navigabilité, une flèche ouverte au bout du trait.

Les multiplicités

La multiplicité écrite à une extrémité d'une association dit combien d'objets de cette classe sont reliés à un objet de la classe d'en face.

La règle de lecture : pars d'un objet de la classe A, traverse le trait, lis le nombre écrit près de B.

Sur cet exemple :

• un visiteur remplit 0..* fiches : zéro le jour de son embauche, puis une par mois ;
• une fiche est remplie par 1 visiteur, toujours, et par un seul.

Trouver la bonne multiplicité

Pour chaque extrémité, pose deux questions : « Au minimum, combien ? » (0 ou 1, rarement plus) et « Au maximum, combien ? » (1 ou plusieurs). Le minimum dépend des règles de gestion et du moment de la vie de l'objet : une fiche peut-elle exister sans visiteur, même une seconde ? Non : minimum 1. Un visiteur peut-il exister sans fiche ? Oui, le jour de son arrivée : minimum 0.

La navigabilité

Par défaut, une association se parcourt dans les deux sens : la fiche connaît son visiteur, le visiteur connaît ses fiches. Une flèche ouverte au bout du trait restreint le parcours : FicheFrais ──▸ FraisForfait dit qu'une fiche connaît les forfaits qu'elle utilise, mais qu'un forfait ne connaît pas les fiches qui l'utilisent. Une croix au bout du trait dit explicitement « non navigable dans ce sens ».

La navigabilité est une décision de conception, qui se lit directement dans le code : seule la classe d'où part la flèche possède une référence vers l'autre (chapitre 6). En analyse, on la laisse souvent de côté ; en conception, elle évite des références inutiles et des dépendances croisées.

L'association réflexive

Une association réflexive relie une classe à elle-même. Les rôles deviennent alors indispensables pour savoir qui est qui. Chez GSB, chaque visiteur peut avoir un responsable de secteur, lui-même visiteur :

Visiteur  "0..1 responsable"  ────  "0..* equipe"  Visiteur

Se lit : un visiteur a zéro ou un responsable ; un visiteur (en tant que responsable) a zéro ou plusieurs visiteurs dans son équipe.

Trouver les classes dans un texte

Devant un cahier des charges, la méthode classique est l'analyse grammaticale :

1. Souligne les noms : ce sont les classes candidates, ou leurs attributs.
2. Élimine les noms vagues (« système », « information »), les synonymes (« note de frais » et « fiche de frais » sont la même chose), les acteurs qui n'ont pas de données à mémoriser, et les noms qui ne sont qu'une valeur (« montant », « date », « libellé » : ce sont des attributs).
3. Garde comme classe ce qui a une identité, plusieurs propriétés et une vie propre : un visiteur, une fiche, une ligne de frais, un forfait.
4. Repère les verbes qui relient deux classes (« un visiteur remplit une fiche ») : ce sont des associations. Les verbes qui décrivent un traitement (« le comptable valide la fiche ») deviennent des opérations, souvent de la classe qui subit l'action ou qui possède les données (FicheFrais.Valider()).
5. Pose les multiplicités en relisant les règles de gestion, phrase par phrase.

Appliquée au cahier des charges d'AppliFrais, la méthode donne les classes Visiteur, Comptable, Region, FicheFrais, FraisForfait (les quatre forfaits et leur montant), LigneFraisForfait (une quantité d'un forfait sur une fiche) et LigneFraisHorsForfait. Le diagramme complet est au chapitre 5, une fois l'héritage et la composition présentés.

Exercices

Abonnement
- numero : string {readOnly}
- dateDebut : Date
- dureeMois : int = 12
- / dateFin : Date
- nbAbonnements : int        (souligné)
+ Abonnement(numero : string, dateDebut : Date)
+ Renouveler(mois : int)
+ EstActif(jour : Date) : bool
- CalculerFin() : Date

Ticket
+ id : int
+ titre : string
+ idTechnicien : int
+ technicien : Technicien
+ getTitre() : string
+ setTitre(t : string)
+ Cloturer()