Diagramme états-transitions UML : visualiser des suites d’états d’objets
L'équipe éditoriale IONOS
Lors du développement d'un produit ou de la programmation de logiciels, les diagrammes états-transitions UML permettent de représenter le cycle de vie des différents objets de façon imagée et compréhensible. Bien qu’un tel diagramme comporte uniquement quelques éléments, une utilisation correcte contribue de façon déterminante au succès du produit final. Dans les paragraphes suivants, vous découvrirez pourquoi et dans quels cas utiliser un tel diagramme ainsi que comment créer votre propre diagramme états-transitions UML.
Qu’est-ce qu’un diagramme états-transitions ?
Un diagramme états-transitions UML (également appelé simplement diagramme d’états-transitions ou en anglais state diagram voire state machine diagram) visualise les états d’un automate à états finis, c’est-à-dire d’un modèle de comportement composé d’actions et d’états ou de transitions d’états. Dans ce cadre, le diagramme prévoit pour chaque objet du modèle aussi bien un état initial qu’un état final et au moins un état intermédiaire. Le diagramme états-transitions permet ainsi de représenter le cycle de vie complet d’un système ou d’un système partiel ou encore de composantes ou de classes individuelles, qu’il s’agisse des processus d’une machine à café, d’une liseuse ou de composantes techniques d’un véhicule.
Le diagramme états-transitions est l’un des 14 types de diagrammes du Unified Modeling Language (UML) et du Systems Model Language (SysML). Il repose sur un concept de David Harel qui l’a publié en 1987 dans son article scientifique « Statecharts: A Visual Formalism for Complex Systems ». Parmi les autres types de diagrammes UML, on trouve par exemple le diagramme des cas d’utilisation et le diagramme de composants.
À quoi servent les diagrammes états-transitions UML ?
Comme nous l’avons déjà évoqué, le but des diagrammes états-transitions est de décrire le comportement d'un système de façon aussi précise que possible. À la fin, la représentation graphique des différents processus doit notamment pouvoir répondre aux questions suivantes :
- Que se passe-t-il lorsqu’un objet se trouve dans un état spécifique ?
- Quel état doit survenir pour que son comportement soit modifié ?
- Quels sont les événements déclencheurs ?
- De quelles propriétés l’objet doit-il disposer pour pouvoir changer d’état ?
Les diagrammes états-transitions UML sont par conséquent utilisés partout où il est utile de visualiser les états et les conditions de transition pour un processus de développement optimal. Ils sont particulièrement appréciés dans la conception de systèmes intégrés (Embedded Systems), car ces derniers traitent en arrière-plan différents signaux et processus automatisés qui doivent être coordonnés les uns avec les autres de manière optimale. Dans ce cas, un diagramme états-transitions aide les développeurs en visualisant toutes les fonctions de commande pertinentes et en les rendant disponibles d’un coup d’œil.
L’utilité des diagrammes états-transitions peut être expliquée facilement à travers l’exemple de la fonction « Aqua Stop » des machines à laver : cette dernière détermine quand l’alimentation en eau de la machine à laver doit être interrompue. Dans le cadre d’un diagramme états-transitions UML, elle peut être comprise comme un système à part entière. Dans ce cas, la représentation graphique permet de mettre en évidence dans quel état et sous quelles conditions le principe « Aqua Stop » s’applique.
Dans de nombreux secteurs industriels tels que la technologie médicale ou les transports, les diagrammes états-transitions sont utilisés pour expliquer des situations complexes. Les diagrammes états-transitions sont également utilisés dans la gestion de produits et de projets ainsi que dans l’ingénierie des exigences.
Diagramme états-transitions : aperçu de la structure et des composantes
Même si les diagrammes états-transitions UML sont basés uniquement sur quelques éléments, une combinaison astucieuse de ces éléments permet également de représenter des suites d’états complexes. Quels sont les éléments les plus importants d’un diagramme états-transitions et quelle est la structure sous-jacente ?
États
Les états sont les composantes essentielles d’un diagramme états-transitions. Les huit états sont toujours représentés par un rectangle aux angles arrondis. Une porte peut par exemple prendre deux valeurs d’état :
Si l’on garde l’exemple de diagramme états-transitions représentant les états d’une porte, la condition suivante doit toujours être remplie :
- l’objet se trouve toujours dans l’un des deux états : la porte est soit ouverte soit fermée, mais n’est jamais à la fois ouverte et fermée.
Dans les diagrammes états-transitions plus complexes, le rectangle peut être divisé en un maximum de trois zones représentant des spécifications du comportement (voir transition).
Transition : comment un état change-t-il ?
Pour passer d’un état à un autre, un événement doit être déclenché. Il représente une transition. Cette transition relie les états entre eux et est représentée visuellement par une flèche. Certaines conditions peuvent être nécessaires pour qu’une telle transition soit déclenchée. En principe, les diagrammes états-transitions UML opèrent une distinction entre les transitions internes et externes. Alors que les transitions externes sont obligatoires dans la création d’un diagramme états-transitions, les transitions internes ne doivent pas impérativement faire partie du diagramme.
Dans le diagramme états-transitions d’un système d’ascenseur, une condition pour l’action « Fermer la porte de l’ascenseur » peut par exemple être que celle-ci soit tout d’abord ouverte pendant un minimum de cinq secondes avant de passer de l’état « ouverte » à « fermée ».
Transition externe : changement d’état
Les transitions comme celles figurant dans l’exemple suivant de diagramme états-transitions UML sont des transitions externes. Dans ce cadre, la transition a pour effet que l’objet passe à un autre état (entry/exit).
Exemple : si l’alarme d’un radio-réveil est déclenchée, l’état passe de « Alarme activée (activated) » à « Alarme désactivée (deactivated) ». L’état est modifié.
Transition interne : l’état reste inchangé
Dans le cas d’une transition interne, ce n’est pas un changement d’état qui est déclenché, mais une activité.
Exemple : dans un système de comptabilité, une facture impayée peut donner lieu à l’envoi automatique d’une facture (transition externe). Si un rappel est envoyé comme réaction à l’absence de paiement, dans ce cas, il s’agit d’une transition interne. En effet, une activité se produit, à savoir « Envoi du rappel », mais la facture reste ouverte et, jusqu’à nouvel ordre, demeure à l’« état impayé ».
Événements : pourquoi les états changent-ils ?
Les événements (actions) peuvent décrire davantage les conditions dans lesquelles un état est abandonné, afin de passer à l’état suivant. Lors de la transition de l’état de départ au premier état véritable, il n’est pas nécessaire de fournir de plus amples informations sur l’événement, elles sont facultatives. Si aucun événement n’est indiqué, cela signifie qu’il survient automatiquement dès que toutes les activités des états précédents sont achevées.
Un NON-événement (Trigger/ANY-Trigger) indique que l’événement est en principe toujours disponible. Les événements peuvent être nommés comme des spécifications du comportement de l’état ou dans le cadre de la transition de l’état (voir transition).
Un événement déclencheur doit remplir les trois conditions suivantes :
- entry : l’événement est déclenché automatiquement lors de l’entrée dans un état, c’est-à-dire dans toutes les transitions entrantes.
- exit : l’événement est déclenché à la sortie d’un état, c’est-à-dire dans toutes les transitions sortantes.
- do : l’événement est toujours déclenché lorsque l’état n’est pas modifié.
Ces spécifications de comportement peuvent être notées dans l’état afin de présenter de façon simplifiée quels comportements modifient l’état. De tels déclencheurs peuvent être représentés graphiquement de deux façons : ils peuvent d’une part être présentés dans l’état correspondant comme le montre l’exemple de diagramme états-transitions suivant :
Les événements peuvent également être indiqués à l’aide de la flèche de transition :
Pseudoétats
Dans les diagrammes états-transitions UML, les éléments de commande sans valeurs affectées impactant le déroulement d’un automate sont appelés des pseudoétats. UML 2, la version actuelle du Unified Modeling Language, dispose de dix pseudoétats différents :
- état initial (angl. Initial) : pas de transition entrante et exactement une transition sortante qui révèle l’état initial
- état final (angl. final) : aucune transition sortante, fin de la suite de comportements
- fourche (angl. fork) : division en plusieurs états parallèles
- jointure (angl. join) : fusion de plusieurs états parallèles
- jonction (angl. junction) : nœud pour mettre en série plusieurs transitions
- option (angl. choice) : nœud depuis lequel plusieurs transitions alternatives peuvent être lancées sur la base d’une décision prise au préalable
- point d’entrée (angl. entry point) : regroupement de transitions similaires entrant dans un état composite
- point de sortie (angl. exit point) : regroupement de transitions similaires sortant d’un état composite
- historique superficiel (angl. shallow history) : enregistrement du dernier sous-état actif d’un état composite
- historique complet (angl. deep history) : enregistrement du dernier sous-état actif de tous les niveaux hiérarchiques d’un état composite
Spécial : diagramme subordonné
En fonction de la complexité, il est possible d’avoir des sous-états donnant une image détaillée de l’état de l’objet et indiquant le comportement possible. Ces explications plus complexes des diagrammes états-transitions UML sont en particulier de rigueur dans les contextes techniques.
- composite state : permet de définir plus exactement un état.
Exemple : une porte peut se trouver à l’état « ouverte » ou « fermée ». Des sous-états de l’état « fermée » pourraient être « déverrouillée » ou « verrouillée ».
- submachine state : un diagramme états-transitions subordonné est ici ajouté à un état. Les sous-états composés de plusieurs sous-ensembles sont appelés états complexes. Les différents sous-ensembles peuvent se dérouler indépendamment les uns des autres, mais peuvent également être liés les uns aux autres.
Exemple : sur un smartphone, la fonction réveil n’est que l’une des nombreuses fonctionnalités auxquelles plusieurs états peuvent être associés. Lorsque plusieurs alarmes sont programmées pour différents jours de la semaine et à différentes heures, il s’agit de sous-ensembles se déroulant indépendamment les uns des autres.
Créer un diagramme états-transitions : exemple de diagramme états-transitions simple
Un diagramme états-transitions peut être appliqué aux objets les plus divers. Dans l’exemple suivant, les différents éléments doivent être présentés à l’aide de la représentation graphique des états d’une facture. Les principaux éléments d’un diagramme états-transitions UML sont représentés de la façon suivante :
Une fois structuré et transposé dans notre exemple, le diagramme simple ressemble à ce qui suit :
Après le point de départ comme pseudoétat, la facture se trouve à l’état « émise » (written). Dans le meilleur des cas, cet état est suivi par la transition vers l’état « payée » (paid). Cette transition peut être décrite davantage en la dotant du nom d’événement « envoyée ».
Si la facture est acquittée, elle se trouve à l’état « payée ». Avant d’atteindre cet état, il peut être nécessaire d’envoyer un « rappel » (reminder). Comme ce rappel ne change pas l’état de la facture, il s’agit d’une activité et donc d’une transition interne. Si la facture n’est pas acquittée, jusqu’à trois rappels peuvent être envoyés.
