UML (Langage de Modélisation Unifié)
Introduction à UML
Le UML (Unified Modeling Language) est un langage de modélisation graphique
standardisé, utilisé pour décrire la conception et l’architecture d’un système logiciel . Il a été
créé dans les années 1994‑1995 pour unifier différentes méthodes orientées objet (Booch,
OMT, OOSE) et est aujourd’hui un standard de fait adopté par l’OMG (Object Management
Group) . UML sert principalement à faciliter l’élaboration de la documentation nécessaire au
développement d’un logiciel orienté objet . Il permet de représenter visuellement les
composants statiques (classes, composants, packages, etc.) et dynamiques (comportement,
interactions) d’un système, tout en favorisant la communication entre experts métier,
analystes et développeurs. Grâce à des outils spécialisés, on peut même générer
automatiquement du code (par exemple en Java) à partir de diagrammes UML .
Sur le plan historique, UML est issu du travail collaboratif de Grady Booch, James
Rumbaugh et Ivar Jacobson chez Rational Software. Leur « méthode unifiée » a donné lieu
à UML 1.0 normalisé en 1997, puis à UML 2.0 adopté en 2005 . La dernière version de la
spécification (UML 2.5.1) date de 2017. UML s’appuie sur les principes de la programmation
orientée objet (héritage, encapsulation, etc.) car il a été conçu comme support de
modélisation pour des systèmes orientés objet .
Le terme de modèle désigne l’ensemble abstrait de l’application (concepts et relations),
tandis qu’un diagramme est une représentation graphique particulière du modèle. Autrement
dit, un modèle UML est constitué d’un ou plusieurs diagrammes UML réunis, chacune de
ces notations (diagramme de classe, diagramme de cas d’utilisation, etc.) étant un aspect du
modèle global . En résumé, UML fournit une notation visuelle unifiée pour modéliser un
système, sous la forme de plusieurs diagrammes complémentaires, ce qui rend la
conception plus claire et compréhensible pour tous les acteurs du projet.
Concepts fondamentaux d’UML
Un élément de modèle UML est une abstraction logique d’un composant d’un système,
pouvant être structurel (classe, acteur, composant, nœud, …) ou comportemental (activité,
état, message, …) . Ces éléments sont représentés dans les diagrammes par des symboles
(rectangles, ellipses, flèches, etc.). Quelques notions clés :
● Classe et objet : une classe est une description abstraite d’un ensemble d’objets
partageant les mêmes caractéristiques (attributs, comportements) . Elle correspond à
un concept métier ou technique (par exemple, CompteBancaire). Un objet est une
instance concrète d’une classe (par exemple, le compte n°12345). UML permet de
modéliser les classes et leurs relations (héritage, associations, compositions)
indépendamment du langage de programmation utilisé . Graphiquement, une classe
est dessinée comme un rectangle divisé en compartiments (nom, attributs,
méthodes) .
● Acteur : dans un diagramme de cas d’utilisation, un acteur représente un rôle externe
interagissant avec le système (utilisateur humain, service externe, capteur, etc.) .
L’acteur n’est pas une classe du système mais un correspondant extérieur. Il est
symbolisé par un petit bonhomme allumette ou par une entité symbolique nommée.
Un acteur peut incarner un humain ou tout autre système qui a des échanges avec
l’application modélisée .
● Cas d’utilisation (use case) : un cas d’utilisation est une fonctionnalité ou un service
rendu par le système à un acteur. Il représente un enchaînement d’interactions
(actions et événements) entre l’acteur et le système pour atteindre un objectif donné
. Par exemple, « Retirer de l’argent d’un distributeur » est un cas d’utilisation où
l’acteur (utilisateur) interagit avec le système bancaire. On note qu’un cas d’utilisation
se dessine comme une ellipse nommée, reliée aux acteurs concernés par des lignes
.
● Activité : une activité est une tâche élémentaire ou un processus dans le système.
Un diagramme d’activité (comportemental) décrit le flux de ces activités pour
accomplir un scénario de bout en bout (cf. infra). Les activités sont représentées par
des nœuds (rouges, ovales ou rectangles) et reliées par des flèches indiquant l’ordre
d’exécution .
● État : un état définit la condition d’un objet ou d’un système à un instant donné. Un
diagramme d’états-transitions modélise le cycle de vie d’un objet en enchaînant
plusieurs états (initial, intermédiaire, final) liés par des transitions déclenchées par
des événements. L’objectif est de décrire le comportement dynamique selon l’état
courant.
● Paquet : un package (paquet) est un conteneur logique qui regroupe des éléments
corrélés du modèle (classes, cas d’utilisation, etc.) . Dans un diagramme de paquets,
on montre les dépendances entre ces packages.
● Composant : un composant est une entité modulaire (par exemple une librairie, un
service ou un module logiciel) mise en œuvre physiquement. Il peut contenir
plusieurs classes. Le diagramme de composants illustre les composants du système
et leurs dépendances .
● Nœud (déploiement) : un nœud est un emplacement d’exécution (machine, serveur,
mobile, etc.). En diagramme de déploiement, on montre comment les composants
logiciels sont déployés sur les nœuds matériels et comment ces nœuds
communiquent .
Tous ces éléments (classes, objets, acteurs, activités, états, composants, etc.) sont reliés
entre eux par des relations UML standard (association, dépendance, généralisation,
réalisation, etc.), chacune ayant une notation graphique précise (flèches, lignes, losanges).
Par exemple, une association est une ligne pleine, une généralisation est une flèche avec
triangle creux, etc. Les stéréotypes (sous-type de modèle marqué « <> ») permettent de
préciser le rôle de certains éléments ([Link]. « <> » sur une classe ).
●
UML (Langage de Modélisation Unifié)
● Introduction à UML
Le UML (Unified Modeling Language) est un langage de modélisation graphique
standardisé, utilisé pour décrire la conception et l’architecture d’un système logiciel . Il a été
créé dans les années 1994‑1995 pour unifier différentes méthodes orientées objet (Booch,
OMT, OOSE) et est aujourd’hui un standard de fait adopté par l’OMG (Object Management
Group) . UML sert principalement à faciliter l’élaboration de la documentation nécessaire au
développement d’un logiciel orienté objet . Il permet de représenter visuellement les
composants statiques (classes, composants, packages, etc.) et dynamiques (comportement,
interactions) d’un système, tout en favorisant la communication entre experts métier,
analystes et développeurs. Grâce à des outils spécialisés, on peut même générer
automatiquement du code (par exemple en Java) à partir de diagrammes UML .
Sur le plan historique, UML est issu du travail collaboratif de Grady Booch, James
Rumbaugh et Ivar Jacobson chez Rational Software. Leur « méthode unifiée » a donné lieu
à UML 1.0 normalisé en 1997, puis à UML 2.0 adopté en 2005 . La dernière version de la
spécification (UML 2.5.1) date de 2017. UML s’appuie sur les principes de la programmation
orientée objet (héritage, encapsulation, etc.) car il a été conçu comme support de
modélisation pour des systèmes orientés objet .
Le terme de modèle désigne l’ensemble abstrait de l’application (concepts et relations),
tandis qu’un diagramme est une représentation graphique particulière du modèle. Autrement
dit, un modèle UML est constitué d’un ou plusieurs diagrammes UML réunis, chacune de
ces notations (diagramme de classe, diagramme de cas d’utilisation, etc.) étant un aspect du
modèle global . En résumé, UML fournit une notation visuelle unifiée pour modéliser un
système, sous la forme de plusieurs diagrammes complémentaires, ce qui rend la
conception plus claire et compréhensible pour tous les acteurs du projet.
● Concepts fondamentaux d’UML
Un élément de modèle UML est une abstraction logique d’un composant d’un système,
pouvant être structurel (classe, acteur, composant, nœud, …) ou comportemental (activité,
état, message, …) . Ces éléments sont représentés dans les diagrammes par des symboles
(rectangles, ellipses, flèches, etc.). Quelques notions clés :
● Classe et objet : une classe est une description abstraite d’un ensemble d’objets
partageant les mêmes caractéristiques (attributs, comportements) . Elle correspond à
un concept métier ou technique (par exemple, CompteBancaire). Un objet est une
instance concrète d’une classe (par exemple, le compte n°12345). UML permet de
modéliser les classes et leurs relations (héritage, associations, compositions)
indépendamment du langage de programmation utilisé . Graphiquement, une classe
est dessinée comme un rectangle divisé en compartiments (nom, attributs,
méthodes) .
● Acteur : dans un diagramme de cas d’utilisation, un acteur représente un rôle externe
interagissant avec le système (utilisateur humain, service externe, capteur, etc.) .
L’acteur n’est pas une classe du système mais un correspondant extérieur. Il est
symbolisé par un petit bonhomme allumette ou par une entité symbolique nommée.
Un acteur peut incarner un humain ou tout autre système qui a des échanges avec
l’application modélisée .
● Cas d’utilisation (use case) : un cas d’utilisation est une fonctionnalité ou un service
rendu par le système à un acteur. Il représente un enchaînement d’interactions
(actions et événements) entre l’acteur et le système pour atteindre un objectif donné
. Par exemple, « Retirer de l’argent d’un distributeur » est un cas d’utilisation où
l’acteur (utilisateur) interagit avec le système bancaire. On note qu’un cas d’utilisation
se dessine comme une ellipse nommée, reliée aux acteurs concernés par des lignes
.
● Activité : une activité est une tâche élémentaire ou un processus dans le système.
Un diagramme d’activité (comportemental) décrit le flux de ces activités pour
accomplir un scénario de bout en bout (cf. infra). Les activités sont représentées par
des nœuds (rouges, ovales ou rectangles) et reliées par des flèches indiquant l’ordre
d’exécution .
● État : un état définit la condition d’un objet ou d’un système à un instant donné. Un
diagramme d’états-transitions modélise le cycle de vie d’un objet en enchaînant
plusieurs états (initial, intermédiaire, final) liés par des transitions déclenchées par
des événements. L’objectif est de décrire le comportement dynamique selon l’état
courant.
● Paquet : un package (paquet) est un conteneur logique qui regroupe des éléments
corrélés du modèle (classes, cas d’utilisation, etc.) . Dans un diagramme de paquets,
on montre les dépendances entre ces packages.
● Composant : un composant est une entité modulaire (par exemple une librairie, un
service ou un module logiciel) mise en œuvre physiquement. Il peut contenir
plusieurs classes. Le diagramme de composants illustre les composants du système
et leurs dépendances .
● Nœud (déploiement) : un nœud est un emplacement d’exécution (machine, serveur,
mobile, etc.). En diagramme de déploiement, on montre comment les composants
logiciels sont déployés sur les nœuds matériels et comment ces nœuds
communiquent .
Tous ces éléments (classes, objets, acteurs, activités, états, composants, etc.) sont reliés
entre eux par des relations UML standard (association, dépendance, généralisation,
réalisation, etc.), chacune ayant une notation graphique précise (flèches, lignes, losanges).
Par exemple, une association est une ligne pleine, une généralisation est une flèche avec
triangle creux, etc. Les stéréotypes (sous-type de modèle marqué « <> ») permettent de
préciser le rôle de certains éléments ([Link]. « <> » sur une classe ).
Les 14 diagrammes UML
UML compte 14 types de diagrammes officiels, répartis en trois familles : diagrammes
structurels, comportementaux et d’interaction . Chacun sert à décrire un aspect particulier du
système :
● Diagrammes structurels (statics) : ils montrent la structure statique du système. C’est
notamment le diagramme de classes, le diagramme d’objets (instances de classes),
le diagramme de composants, le diagramme de déploiement, le diagramme de
paquets, le diagramme de structure composite (interne aux classes, UML 2.x) et le
diagramme de profils. Par exemple, le diagramme de classes est « l’élément central
d’UML » : il représente les classes du système et leurs relations (attributs,
opérations, associations, héritages, etc.) .
● Diagrammes comportementaux (behavioral) : ils modélisent le comportement
fonctionnel du système. Il y a le diagramme des cas d’utilisation (use-case), le
diagramme d’activité et le diagramme états-transitions (state machine) . Le
diagramme de cas d’utilisation décrit les fonctionnalités offertes par le système sous
l’angle des acteurs externes. Le diagramme d’activités décrit les enchaînements de
tâches (workflow) pour réaliser un scénario. Le diagramme d’états-transitions décrit
le comportement d’un objet ou d’un sous-système sous forme de machine à états
finis.
● Diagrammes d’interaction (dynamique) : ce sont des sous-types de diagrammes
comportementaux centrés sur les échanges entre objets. Ils comprennent le
diagramme de séquence, le diagramme de communication (anciennement
diagramme de collaboration), le diagramme global d’interaction (interaction overview)
et le diagramme de temps (timing) . Le diagramme de séquence montre l’ordre
temporel des messages échangés entre acteurs et objets pour un scénario donné.
Le diagramme de communication présente les mêmes messages sous forme de
réseau d’objets connectés. Le diagramme d’interaction globale est une variante de
diagramme d’activités où chaque nœud peut être une séquence, et le diagramme de
temps fait apparaître l’évolution de valeurs au cours du temps.
Exemple de diagramme de classes (domaine bancaire). Chaque classe (Customer, Account,
Card, Transaction) est représentée par un rectangle. On y trouve son nom, ses attributs
publics, et ses opérations. Les lignes entre classes indiquent les associations (ici un client
peut posséder plusieurs comptes et cartes, un compte comporte plusieurs transactions) .*
Diagramme d’objets – Il montre les instances des classes à un instant donné.
Concrètement, c’est un cliché de quelques objets créés à l’exécution et de leurs liens
(relation d’association). On l’utilise souvent pour vérifier qu’un diagramme de classes donné
peut réellement être instancié et pour illustrer des scénarios concrets. Par exemple, on
pourrait représenter les objets réels customer1:Customer, acc123:Account, etc., avec leurs
liens. Ainsi le diagramme d’objets est la projection « vivante » d’un diagramme de classes
pour des instances précises .
Diagramme de composants – Il représente les composants logiciels (modules, librairies,
services) et leurs dépendances. Chaque composant est dessiné comme un rectangle avec
le stéréotype « <> ». Ce diagramme met l’accent sur la structure physique : on y voit
comment les fichiers, modules ou micro-services s’assemblent. Le diagramme de
composants « offre une vue plus simplifiée d’un système complexe en le décomposant en
composants plus petits » .
Diagramme de déploiement – Il décrit l’architecture matérielle et logicielle de l’application.
Les nœuds (machines, serveurs, etc.) sont représentés par des boîtes 3D, et les artefacts
(fichiers exécutables, composants) qui y sont déployés y sont attachés. Ce diagramme
montre où chaque composant logiciel fonctionne physiquement et comment les nœuds
communiquent entre eux . C’est utile pour planifier le déploiement sur les serveurs,
conteneurs ou postes de travail.
Diagramme de paquets – Il montre les dépendances entre les packages (regroupements
logiques) du système . Un paquet UML (rectangle avec l’onglet en haut) contient des
classes ou d’autres éléments. Le diagramme de paquets éclaire l’architecture globale : par
exemple, on peut regrouper les classes par sous-système (métier, persistance, interfaces) et
afficher leurs liens de dépendance.
(En UML 2.x, on trouve aussi le diagramme de structure composite – qui détaille
l’organisation interne d’une classe complexe – et le diagramme de profils – qui sert à créer
des stéréotypes et contraintes spécifiques à un domaine. Ces diagrammes sont plus
spécialisés.)
3.2 Diagrammes comportementaux
Diagramme de cas d’utilisation (use-case) – Il décrit le système du point de vue des besoins
fonctionnels externes. Chaque cas d’utilisation figure par une ellipse nommée (la
fonctionnalité) reliée aux acteurs concernés. Par exemple, « Effectuer un retrait »,
« Consulter le solde » sont des cas d’utilisation pour un système bancaire, liés aux acteurs
Client ou Caissier. Un cas d’utilisation représente l’ensemble d’interactions entre un acteur
et le système pour atteindre un but, sans détailler l’implémentation . Le diagramme de cas
d’utilisation sert à rassembler les exigences fonctionnelles en montrant qui utilise quoi du
système.
Diagramme d’activités – C’est un diagramme de flux de contrôle. Il modélise le déroulement
d’un processus ou d’un scénario métier en listant les activités séquentielles et parallèles. On
y trouve un état initial (triangle rempli), des activités (rectangles ronds), des décisions
(losanges), des fourches/réunions (noeuds de fork/join) et un état final (cercle avec point).
L’idée est de décrire « un processus pas à pas avec un début et une fin clairs », où chaque
activité mène à la suivante . Par exemple, on peut dessiner le processus de traitement d’une
commande (valider panier → autoriser paiement → expédier article), avec des branches
conditionnelles.
Diagramme états-transitions (machine à états) – Il montre la logique interne d’un objet à
travers ses états. Il se dessine sous la forme d’une machine à états finis : cercles et
rectangles pour états, flèches étiquetées pour transitions (et éventuellement gardes et
actions). L’objectif est de représenter le comportement dynamique d’un élément (système,
classe, objet) selon son état courant. Par exemple, un diagramme d’état pour un billet
d’avion peut décrire qu’il passe de l’état Émis à Validé puis Utilisé, avec des événements
enregistrement, embarquement déclenchant les transitions. UML définit précisément ce
diagramme comme « une machine à états finis du comportement du système ou de ses
composants » .
3.3 Diagrammes d’interaction
Diagramme de séquence – Il détaille, pour un scénario donné, l’ordre temporel d’échanges
de messages entre acteurs et objets. Sur un axe vertical (temps), chaque lifeline (acteur ou
objet) est placée en colonne, et des flèches horizontales représentent l’envoi de messages
(opérations appelées) entre eux. C’est utile pour modéliser une transaction ou un service
complexe, car il montre le jeu d’allers-retours. Par exemple, on peut dessiner une séquence
pour « Effectuer un retrait » : Client→GUI, GUI→Contrôleur, Contrôleur→BaseDeDonnées,
etc. Le diagramme ci‑dessous illustre un échange entre un client, un module applicatif et
une base de données pour créer une fiche d’activité (ServiceAttendance) :
Exemple de diagramme de séquence UML (scénario “Créer la présence à un service”).
Chaque colonne verticale est un acteur ou objet (Member, Application, Database…). Les
flèches horizontales représentent les messages échangés dans l’ordre, comme
“ValidateMember()” ou “WriteAttendance()”. Ce diagramme montre le flux temporel des
interactions .
Diagramme de communication (collaboration) – Similaire au diagramme de séquence, il met
l’accent sur les objets et leurs liens plutôt que sur l’axe temporel. Les objets sont dessinés
comme des boîtes reliées entre elles, et les messages sont indiqués numérotés sur ces
liens. C’est une vue alternative de la même information (échanges de messages), utile pour
focaliser sur la topologie des interactions. En UML 2.x, on note souvent « Diagramme de
communication » pour ce genre de vue .
Diagramme global d’interaction (interaction overview) – C’est un diagramme composite
(variant du diagramme d’activités) qui permet d’assembler plusieurs scénarios d’interaction.
Chaque nœud d’activité dans ce diagramme peut contenir un sous-diagramme de séquence
préalablement défini, et des transitions relient ces nœuds. On l’utilise pour modéliser des
flux complexes où l’on veut représenter la navigation entre plusieurs cas d’usage ou
processus interactifs. En pratique, c’est un diagramme d’activités dont certains blocs sont
des diagrammes de séquence .
Diagramme de temps (timing) – Il décrit l’évolution d’une ou plusieurs valeurs (attributs,
signaux) en fonction du temps. On utilise un axe horizontal de temps et des lignes d’état
pour les différentes variables, afin de montrer par exemple la variation d’un signal électrique.
Ce diagramme est moins courant et apparaît surtout dans des domaines temps réel. Il est
défini comme la représentation de la « variation d’une donnée au cours du temps » .
UML dans le cycle de vie logiciel
UML intervient à presque toutes les étapes du développement logiciel. En phase d’analyse,
on établit les diagrammes de cas d’utilisation pour recueillir les besoins et les formaliser. On
crée alors aussi les premiers modèles statiques (diagrammes de classes et d’objets) pour
identifier les entités du domaine. En phase de conception détaillée, on affine ces modèles
statiques et on introduit les diagrammes dynamiques (séquence, activité) pour préciser le
comportement des parties du système. Les diagrammes de composants et de déploiement
sont utilisés pour la conception système et l’architecture technique. Au codage, UML peut
servir à générer automatiquement des squelettes de code (classes, interfaces) ou à guider
l’implémentation. Pendant les tests, les modèles UML (cas d’utilisation et séquences
notamment) aident à définir les scénarios de test et à vérifier que le système correspond aux
spécifications. Enfin, en maintenance, les diagrammes documentent le système existant et
facilitent l’analyse d’impact lors de l’évolution du logiciel. On voit ainsi qu’« UML est destiné
à faciliter la conception des documents nécessaires au développement d’un logiciel orienté
objet, comme standard de modélisation de l’architecture logicielle » .
Avantages et limites d’UML
Parmi ses atouts, UML offre :
● Une notation standardisée et visuelle. En utilisant un langage de symboles commun,
UML permet aux équipes (développeurs, analystes, testeurs, clients) de
communiquer efficacement sur la structure et le comportement du système . Il
favorise la documentation claire (architecture, logique métier, cas d’usage) en
complétant le code par des vues graphiques .
● La couverture de l’ensemble du cycle de vie. UML prend en charge tant l’analyse des
besoins (diagrammes de cas d’utilisation) que la conception détaillée (classes,
séquences), ce qui rend la transition conceptuelle vers le code plus fluide . Il
encourage une démarche itérative où les modèles évoluent avec le projet.
● La compréhension de systèmes complexes. Les diagrammes aident à découper un
système en composants ou processus simples, ce qui améliore la clarté d’ensemble
et le repérage de problèmes de conception.
En revanche, UML présente aussi des inconvénients potentiels :
● Complexité et surcharge. La maîtrise des 14 diagrammes et de toutes leurs notations
peut être ardue pour les débutants . Élaborer et maintenir des diagrammes détaillés
prend du temps, surtout sur de petits projets où l’« overhead » (surcharge de
documentation) n’est pas justifié .
● Ambiguïté d’interprétation. Certains diagrammes (ex. d’états, de séquence
complexes) peuvent prêter à confusion si les conventions ne sont pas strictement
suivies. Deux personnes peuvent interpréter différemment un diagramme mal annoté
.
● Courbe d’apprentissage. Apprendre UML et s’entraîner à modéliser efficacement
demande un investissement initial important. Les équipes doivent être formées pour
en tirer pleinement parti .
● Modélisation excessive ou insuffisante. Il faut trouver le bon équilibre : trop de détails
(sur-modélisation) alourdit les diagrammes, trop peu (sous-modélisation) les rend
peu informatifs . Une vision « minimaliste » peut parfois suffire, selon le contexte et la
méthodologie de développement (agile vs. classique).
En somme, UML est très puissant pour formaliser et partager la conception logicielle, mais
son efficacité dépend de l’usage pertinent des diagrammes et de la discipline dans leur
réalisation.
Synthèse
Pour conclure, UML est un langage de modélisation riche et normalisé qui permet de
représenter graphiquement un système sous différents angles (structure, comportements,
interactions). En combinant diagrammes structurels (classes, composants, déploiement,
etc.) et diagrammes dynamiques (cas d’utilisation, activités, séquences, états, etc.), UML
couvre l’essentiel des besoins de modélisation orientée objet. Chaque diagramme a un
objectif précis et utilise des symboles définis (rectangles pour les classes, ellipses pour les
cas d’utilisation, bonhommes pour les acteurs, nœuds pour les états, etc.). Les exemples
concrets (gestion de banque, bibliothèque, e-commerce, etc.) facilitent la prise en main : on
modélise les acteurs (client, caissier), les entités (Livre, Commande, Produit) et leurs
interactions pour illustrer les concepts. Malgré sa complexité, l’utilisation raisonnée d’UML
offre un cadre cohérent pour analyser, concevoir, communiquer et documenter un logiciel
tout au long de son cycle de vie.
Sources : Présentation basée sur la spécification UML et divers cours et articles spécialisés