Diagramme états-tran­si­tions UML : vi­sua­li­ser des suites d’états d’objets

Lors du dé­ve­lop­pe­ment d'un produit ou de la pro­gram­ma­tion de logiciels, les dia­grammes états-tran­si­tions UML per­met­tent de re­pré­sen­ter le cycle de vie des dif­fé­rents objets de façon imagée et com­pré­hen­sible. Bien qu’un tel diagramme comporte uni­que­ment quelques éléments, une uti­li­sa­tion correcte contribue de façon dé­ter­mi­nante au succès du produit final. Dans les pa­ra­graphes suivants, vous dé­cou­vri­rez pourquoi et dans quels cas utiliser un tel diagramme ainsi que comment créer votre propre diagramme états-tran­si­tions UML.

Un diagramme états-tran­si­tions UML (également appelé sim­ple­ment diagramme d’états-tran­si­tions 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 com­por­te­ment composé d’actions et d’états ou de tran­si­tions 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 in­ter­mé­diaire. Le diagramme états-tran­si­tions permet ainsi de re­pré­sen­ter le cycle de vie complet d’un système ou d’un système partiel ou encore de com­po­santes ou de classes in­di­vi­duelles, qu’il s’agisse des processus d’une machine à café, d’une liseuse ou de com­po­santes tech­niques d’un véhicule.

Le diagramme états-tran­si­tions est l’un des 14 types de dia­grammes 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 scien­ti­fique « Sta­te­charts: A Visual Formalism for Complex Systems ». Parmi les autres types de dia­grammes UML, on trouve par exemple le diagramme des cas d’uti­li­sa­tion et le diagramme de com­po­sants.

Comme nous l’avons déjà évoqué, le but des dia­grammes états-tran­si­tions est de décrire le com­por­te­ment d'un système de façon aussi précise que possible. À la fin, la re­pré­sen­ta­tion graphique des dif­fé­rents processus doit notamment pouvoir répondre aux questions suivantes :

• Que se passe-t-il lorsqu’un objet se trouve dans un état spé­ci­fique ?
• Quel état doit survenir pour que son com­por­te­ment soit modifié ?
• Quels sont les évé­ne­ments dé­clen­cheurs ?
• De quelles pro­prié­tés l’objet doit-il disposer pour pouvoir changer d’état ?

Les dia­grammes états-tran­si­tions UML sont par con­sé­quent utilisés partout où il est utile de vi­sua­li­ser les états et les con­di­tions de tran­si­tion pour un processus de dé­ve­lop­pe­ment optimal. Ils sont par­ti­cu­liè­re­ment appréciés dans la con­cep­tion de systèmes intégrés (Embedded Systems), car ces derniers traitent en arrière-plan dif­fé­rents signaux et processus au­to­ma­ti­sés qui doivent être coor­don­nés les uns avec les autres de manière optimale. Dans ce cas, un diagramme états-tran­si­tions aide les dé­ve­lop­peurs en vi­sua­li­sant toutes les fonctions de commande per­ti­nentes et en les rendant dis­po­nibles d’un coup d’œil.

L’utilité des dia­grammes états-tran­si­tions peut être expliquée fa­ci­le­ment à travers l’exemple de la fonction « Aqua Stop » des machines à laver : cette dernière détermine quand l’ali­men­ta­tion en eau de la machine à laver doit être in­ter­rom­pue. Dans le cadre d’un diagramme états-tran­si­tions UML, elle peut être comprise comme un système à part entière. Dans ce cas, la re­pré­sen­ta­tion graphique permet de mettre en évidence dans quel état et sous quelles con­di­tions le principe « Aqua Stop » s’applique.

Même si les dia­grammes états-tran­si­tions UML sont basés uni­que­ment sur quelques éléments, une com­bi­nai­son as­tu­cieuse de ces éléments permet également de re­pré­sen­ter des suites d’états complexes. Quels sont les éléments les plus im­por­tants d’un diagramme états-tran­si­tions et quelle est la structure sous-jacente ?

Pour passer d’un état à un autre, un événement doit être déclenché. Il re­pré­sente une tran­si­tion. Cette tran­si­tion relie les états entre eux et est re­pré­sen­tée vi­suel­le­ment par une flèche. Certaines con­di­tions peuvent être né­ces­saires pour qu’une telle tran­si­tion soit dé­clen­chée. En principe, les dia­grammes états-tran­si­tions UML opèrent une dis­tinc­tion entre les tran­si­tions internes et externes. Alors que les tran­si­tions externes sont obli­ga­toires dans la création d’un diagramme états-tran­si­tions, les tran­si­tions internes ne doivent pas im­pé­ra­ti­ve­ment faire partie du diagramme.

Dans le diagramme états-tran­si­tions 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 ».

Dans les dia­grammes états-tran­si­tions UML, les éléments de commande sans valeurs affectées impactant le dé­rou­le­ment d’un automate sont appelés des pseu­doé­tats. UML 2, la version actuelle du Unified Modeling Language, dispose de dix pseu­doé­tats dif­fé­rents :

• état initial (angl. Initial) : pas de tran­si­tion entrante et exac­te­ment une tran­si­tion sortante qui révèle l’état initial

• état final (angl. final) : aucune tran­si­tion sortante, fin de la suite de com­por­te­ments

• fourche (angl. fork) : division en plusieurs états pa­ral­lèles
• jointure (angl. join) : fusion de plusieurs états pa­ral­lèles
• jonction (angl. junction) : nœud pour mettre en série plusieurs tran­si­tions
• option (angl. choice) : nœud depuis lequel plusieurs tran­si­tions al­ter­na­tives peuvent être lancées sur la base d’une décision prise au préalable
• point d’entrée (angl. entry point) : re­grou­pe­ment de tran­si­tions si­mi­laires entrant dans un état composite
• point de sortie (angl. exit point) : re­grou­pe­ment de tran­si­tions si­mi­laires sortant d’un état composite
• his­to­rique su­per­fi­ciel (angl. shallow history) : en­re­gis­tre­ment du dernier sous-état actif d’un état composite
• his­to­rique complet (angl. deep history) : en­re­gis­tre­ment du dernier sous-état actif de tous les niveaux hié­rar­chiques d’un état composite

En fonction de la com­plexité, il est possible d’avoir des sous-états donnant une image détaillée de l’état de l’objet et indiquant le com­por­te­ment possible. Ces ex­pli­ca­tions plus complexes des dia­grammes états-tran­si­tions UML sont en par­ti­cu­lier de rigueur dans les contextes tech­niques.

• composite state : permet de définir plus exac­te­ment un état.

Exemple : une porte peut se trouver à l’état « ouverte » ou « fermée ». Des sous-états de l’état « fermée » pour­raient être « dé­ver­rouil­lée » ou « ver­rouil­lée ».

• sub­ma­chine state : un diagramme états-tran­si­tions su­bor­donné est ici ajouté à un état. Les sous-états composés de plusieurs sous-ensembles sont appelés états complexes. Les dif­fé­rents sous-ensembles peuvent se dérouler in­dé­pen­dam­ment les uns des autres, mais peuvent également être liés les uns aux autres.

Exemple : sur un smart­phone, la fonction réveil n’est que l’une des nom­breuses fonc­tion­na­li­tés aux­quelles plusieurs états peuvent être associés. Lorsque plusieurs alarmes sont pro­gram­mées pour dif­fé­rents jours de la semaine et à dif­fé­rentes heures, il s’agit de sous-ensembles se déroulant in­dé­pen­dam­ment les uns des autres.