Cours UML: États étendus en PDF (Intermédiaire)

UML: États étendus — comportements associés (entry/exit/do) dans la norme UML 2.5. Un état étendu décrit un mode de vie d'un objet avec des comportements associés et des transitions conditionnées par des événements et des [guards]. Ce document de 14 pages présente le diagramme d'états-transitions (nom officiel) et fournit des repères exploitables pour la modélisation comportementale, la modélisation objet et la spécification fonctionnelle.

La Machine à États en UML 2.5

Le diagramme d'états‑transitions représente visuellement la machine à états (state machine) d'une entité : il décrit l'ensemble des états possibles, les transitions entre eux et les triggers qui provoquent ces transitions. Dans le cas des machines à états finis, chaque état correspond à une configuration distincte du système, le diagramme illustrant le cycle de vie d'un objet et facilitant la transformation vers une spécification exécutable ou du pseudo‑code. Cette représentation aide à valider la complétude et la cohérence du comportement attendu.

🎯 Ce que vous allez apprendre

Acquérir les notions nécessaires pour modéliser des comportements réactifs et fiables en UML 2.5, en facilitant la traduction directe vers une spécification fonctionnelle ou du pseudo‑code exécutable.

• Notion d'état et transition — définition formelle d'un état, d'un événement déclencheur et d'une transition avec [guards]. Comprendre ces primitives permet d'identifier triggers et [guards] pertinents pour chaque transition.
• Actions associées : entry/exit/do et effets — distinction entre actions d'entry, effet de transition et activité continue (do), facilitant la traduction vers l'implémentation.
• États composites et sous-états — composition hiérarchique pour factoriser le comportement et réduire la complexité du diagramme.
• Régions orthogonales et concurrence — partition d'un état en régions concurrentes pour représenter des activités parallèles et gérer l'interaction de threads logiques.
• État historique et stratégies d'historique — rôle des pseudostates historiques (shallow vs deep) pour restaurer un sous-état précédent.
• Transitions internes et bonnes pratiques — différencier transitions internes et externes, éviter l'explosion d'états et appliquer des patterns robustes.

📑 Sommaire du document

Vue d'ensemble des sections présentes dans le PDF ; chaque entrée renvoie aux concepts clés et aux exemples pratiques qui illustrent leur usage dans la modélisation comportementale.

• Introduction aux états et transitions
• Syntaxe UML des états étendus
• Actions : entry, exit et do
• États composites et sous-états
• Orthogonalité et régions concurrentes
• État historique et pseudostates
• Transitions internes, [guards] et effets
• Exemples de diagrammes et cas pratiques

👤 À qui s'adresse ce cours ?

• Public cible : concepteurs et développeurs orientés objet, ingénieurs logiciel et architectes comportementaux qui formalisent protocoles d'interaction ou systèmes réactifs.
• Prérequis : niveau intermédiaire en modélisation, connaissance des diagrammes de classes, compréhension des notions d'événement et de transition, et familiarité générale avec la modélisation orientée comportement.

Concepts fondamentaux de la Machine à États

Une machine à états se compose d'états, de transitions, d'événements (triggers) et d'actions. Le cycle de vie d'un objet y est décrit comme une suite d'états successifs, avec des conditions de passage explicites permettant d'anticiper les comportements indésirables. Les états peuvent être atomiques ou composites, et des pseudostates (initial, final, historique) servent à organiser les entrées et sorties. Le document propose des conventions de nommage et des recommandations pour la traçabilité entre diagrammes et spécification exécutable.

Classification des événements (Triggers) en UML 2.5

Les événements (triggers) déterminent l'occurrence des transitions et se répartissent en plusieurs catégories courantes :

• Signaux — messages asynchrones reçus par l'entité, utiles pour la modélisation distribuée et l'interaction entre composants.
• Appels (call) — invocation synchrone d'une opération qui peut déclencher une transition ; pertinent lors de la traduction vers du code procédural.
• Événements de changement (change) — déclenchés par la satisfaction d'une expression booléenne sur l'état du modèle, utiles pour la spécification fonctionnelle de conditions complexes.
• Événements temporels (time) — expirations ou délais, fréquents dans les protocoles et systèmes embarqués pour décrire des timeouts ou des cycles de vie temporels.

Ces catégories aident à relier la modélisation objet à la spécification fonctionnelle et au cycle de vie d'une entité.

Notation et symbolisme

En l'absence d'illustrations, la notation graphique se décrit ainsi : l'état initial est représenté par un cercle plein, l'état final par un cercle entourant un point. Les états sont affichés comme des rectangles à coins arrondis contenant le nom et éventuellement des compartiments pour activités et actions. Les transitions sont des flèches orientées, annotées par trigger [guard] / effect. Les pseudostates (fork/join, choice, shallow/deep history) ont des symboles spécifiques : lignes épaisses pour fork/join, losange pour choice, et un petit "H" pour l'historique. Cette description permet une lecture correcte du diagramme même sans schéma.

Pourquoi utiliser les États Étendus pour les systèmes complexes ?

Les états étendus permettent d'exprimer clairement des comportements persistants (do), des effets d'entrée/sortie (entry/exit) et des spécifications de transition granulaires. Ils facilitent la modularisation via les états composites et la gestion de la concurrence grâce aux régions orthogonales. L'approche réduit les ambiguïtés lors de la revue des exigences et simplifie la génération de tests fonctionnels ciblés, améliorant la maintenabilité des systèmes complexes.

Comparaison : Diagramme d'états vs Diagramme d'activités

Le diagramme d'états se concentre sur les cycles de vie d'un objet, décrivant les états possibles et les transitions qui y conduisent. À l'inverse, le diagramme d'activités modélise des flux de contrôle et des workflows, centrés sur l'ordre des opérations et les activités réalisées. Choisir l'un ou l'autre dépend de l'objectif : privilégier le diagramme d'états pour analyser le comportement d'une entité au fil du temps ; préférer le diagramme d'activités pour représenter des processus métier ou des enchaînements d'actions.

Différences entre transitions internes et externes

Une transition interne s'exécute sans quitter l'état courant et n'active pas les actions exit/entry de l'état parent, ce qui permet de modifier un comportement local sans réinitialiser les activités en cours. Une transition externe provoque la sortie puis la réentrée de l'état parent et déclenche donc les actions d'exit et d'entry, affectant l'ordre d'exécution des effets et la visibilité des [guards]. En pratique, choisir une transition interne évite des interruptions d'activités continues (do) ; choisir une transition externe permet de forcer une réinitialisation d'un sous-état ou une réévaluation complète du contexte. Documenter ce choix améliore la testabilité et la maintenabilité du modèle.

Cas d'usage : Modélisation de systèmes réactifs

Les diagrammes d'états sont particulièrement adaptés aux systèmes réactifs tels que interfaces utilisateur, protocoles de communication, contrôleurs embarqués et automates de gestion d'énergie. Ils permettent de spécifier le comportement attendu face à des événements externes et internes, d'anticiper les scénarios de concurrence via des régions orthogonales et d'utiliser des états historiques pour préserver le contexte après des interruptions. L'usage ciblé de la norme facilite la transition entre la spécification formelle et l'implémentation, notamment pour formaliser des timeouts, des signaux asynchrones et des règles de priorité entre triggers.

Le PDF comprend des exemples pratiques et propose des pistes d'exercices d'application pour s'entraîner sur des cas concrets sans ajouter de matériel externe.

Téléchargez le PDF de 273.53 Ko pour accéder aux diagrammes textuellement décrits et aux exemples immédiatement.

❓ Foire Aux Questions (FAQ)

Quelle est la différence entre une transition interne et une transition externe ? Une transition interne s'exécute sans quitter l'état courant et n'active pas les actions exit/entry, alors qu'une transition externe provoque la sortie et la réentrée de l'état parent, ce qui modifie l'ordre d'exécution des effets et l'application des [guards].

Quand privilégier un état historique plutôt que des transitions explicites ? L'état historique conserve le dernier sous-état actif et restaure automatiquement ce comportement lors d'une réentrée. Il est recommandé lorsque la granularité des sous-états est importante et que l'on souhaite éviter des transitions nombreuses et redondantes, améliorant ainsi la lisibilité et la maintenance du modèle.