Repository navigation
Diagramme de Classes
Le diagramme de classes modélise les objets d'un système et leurs relations. Il fait ressortir :
- Les classes, avec attributs et méthodes
- Les relations entre elles
- Les généralisations (héritage)
Une classe est un rectangle en 3 parties :
- Le nom (
PascalCase) - Les attributs (
camelCase) - Les méthodes (
camelCase)
Les méthodes peuvent être omises si non pertinentes pour le schéma.
Exemple simple : une classe
Voiture(marque, couleur, vitesse — accélérer, freiner) associée à une classeMoteur.
Un attribut a un nom et un type (String, int, Date, etc.). Sa visibilité précise s'il est accessible en dehors de la classe :
| Symbole | Visibilité | Signification |
|---|---|---|
+ |
public | accessible en dehors de la classe |
- |
private | accessible uniquement dans la classe |
# |
protected | accessible aussi dans les classes filles |
Un identifiant unique repère un objet précis parmi les autres (ex : numéro incrémenté) — plus simple que de le décrire en entier.
C'est un attribut qui permet de rendre chaque objet unique.
Exemple concret : dans une classe
Client, plutôt que d'écrire "le client qui s'appelle Jean Dupont, habite à Lyon, né le 12/03/1990" à chaque fois, on lui donne un identifiant simple.
Ici, idClient (ex : 4587) suffit à retrouver ce client précis dans le système, sans confusion possible avec un autre client qui aurait le même nom.
Une ligne entre deux classes représente une relation entre elles : c'est le concept d'Association.
Une flèche triangulaire symbolise une relation de généralisation (héritage) : elle part de la classe fille vers sa classe parente.
Exemple concret : ici,
Personest la classe mère, avec les attributs communsidPerson,firstName,lastName,
ClientetEmployeesont ses classes filles : elles héritent automatiquement de tous les attributs dePerson- Chacune ajoute en plus son propre attribut spécifique :
ClientaenterpriseNameEmployeeasalary
Donc un Client possède en réalité 5 attributs (les 4 hérités + enterpriseName), même si seul enterpriseName est écrit dans son rectangle.
On pourra grâce à la multiplicité, dire combien de classes auront besoin les unes des autres.
La multiplicité indique combien d'objets sont concernés de chaque côté d'une relation.
| Multiplicité | Signification |
|---|---|
1 |
Un et un seul |
0..1 |
Zéro ou un |
0..* |
Zéro à plusieurs (pas de limite) |
1..* |
Au moins un, potentiellement plusieurs |
Exemple concret :
- Un
Payspeut avoir 0 à plusieurs artistes (0..*)- Un
Artisteappartient à 0 ou 1 pays (0..1)
Ça permet de savoir, en lisant le schéma, si une relation est obligatoire ou optionnelle, et si elle concerne un seul ou plusieurs objets.
Parmi les types de relations, il existe l'association simple, l'agrégation et la composition.
| Association | Agrégation (◇) | Composition (◆) | |
|---|---|---|---|
| Symbole | Trait simple | Losange vide | Losange plein |
| Signification | Deux classes sont liées | "A un", "fait partie de" | "A un", lien fort |
| Force du lien | Aucune | Faible | Forte |
| Suppression d'un côté | L'autre survit | L'autre survit | L'autre est supprimé aussi |
Association : le lien le plus simple. Les deux classes se connaissent, mais restent totalement indépendantes.
Agrégation : une classe "contient" l'autre, mais l'objet contenu peut exister sans elle (ex : un étudiant existe même sans université).
Composition : une classe "possède" l'autre de façon forte. Si l'objet conteneur est supprimé, l'objet contenu l'est aussi (ex : une pièce ne peut pas exister sans sa maison).
Exemple concret (à partir de Artiste et Pays) :
| Cas | Explication | Losange |
|---|---|---|
| Agrégation | Un Artiste existe indépendamment de son Pays — il peut ne pas avoir de pays renseigné (0..1), en changer, ou continuer d'exister même si son pays d'origine est supprimé de la base. |
Vide ◇, côté Pays
|
| Composition (cas contrasté, pour comparer) | Si l'on considérait qu'un Artiste ne peut exister que rattaché à un Pays précis, et que sa suppression entraîne celle de tous ses artistes, ce serait alors une composition. |
Plein ◆, côté Pays
|
C'est le même couple de classes, mais le choix entre agrégation et composition dépend du sens métier qu'on veut donner à la relation : est-ce que l'objet contenu peut survivre à la suppression de son conteneur, ou non ?
Pour mettre en pratique tout ce qui précède, voici un exercice basé sur un système de gestion de cinémas, avec ses salles et les films qui y sont projetés.
Trois classes : Cinema, Salle, Film.
- Un
Cinemapossède plusieursSalle - Une
Salleaccueille desFilm - Un
Cinemapropose desFilm
| Classe | Attributs | Rôle |
|---|---|---|
Cinema |
id, nom, nombreSalles, adresse
|
L'établissement |
Salle |
id, numero, capacite
|
Une salle de projection, rattachée à un cinéma |
Film |
id, nom, annee, genre
|
Un film pouvant être projeté |
Sur les deux versions de l'exercice, la relation entre Cinema et Salle est identique :
-
Losange plein ◆ du côté
Cinema→ c'est une composition - Multiplicité
1côtéCinema,1..*côtéSalle
Sens métier : une
Sallen'existe pas indépendamment d'unCinema— elle en fait physiquement partie. Si leCinemaest supprimé (fermeture, démolition), sesSalledisparaissent avec lui. C'est le même principe que l'exemple pièce / maison vu plus haut.
Ici, les relations Cinema↔Film et Salle↔Film sont toutes les deux en 1..* des deux côtés.
Sens métier : un
Cinemaprojette au moins un film, et unFilmest projeté dans au moins un cinéma — il ne peut pas exister de film qui ne soit projeté nulle part. Même logique pourSalle: une salle projette au moins un film, un film est projeté dans au moins une salle.
On retrouve aussi cette logique dans les méthodes : Film possède getCinesByFilm(id): Cinemas[], qui suppose toujours au moins un résultat.
Même structure de classes, mais les relations Cinema↔Film et Salle↔Film passent en 0..* des deux côtés.
Sens métier : un
Cinemapeut projeter zéro ou plusieurs films, et unFilmpeut être projeté dans zéro ou plusieurs cinémas. Un film peut donc exister dans la base (ex : fiche film créée à l'avance) sans être encore programmé dans une salle. C'est plus réaliste pour un système où le catalogue de films est géré indépendamment de la programmation.
