UML 2

Les diagrammes d'états-transitions d'UML décrivent le comportement interne d'un objet à l'aide d'un automate à états finis. Ils présentent les séquences possibles d'états et d'actions qu'une instance de classe peut traiter au cours de son cycle de vie en réaction à des événements discrets (de type signaux, invocations de méthode).

Ils spécifient habituellement le comportement d'une instance de classeur (classe ou composant), mais parfois aussi le comportement interne d'autres éléments tels que les cas d'utilisation, les sous-systèmes, les méthodes.

Le diagramme d'états-transitions est le seul diagramme, de la norme UML, à offrir une vision complète et non ambiguë de l'ensemble des comportements de l'élément auquel il est attaché. En effet, un diagramme d'interaction n'offre qu'une vue partielle correspondant à un scénario sans spécifier comment les différents scénarii interagissent entre eux.

La vision globale du système n'apparaît pas sur ce type de diagrammes puisqu'ils ne s'intéressent qu'à un seul élément du système indépendamment de son environnement.

Concrètement, un diagramme d'états-transitions est un graphe qui représente un automate à états finis, c'est-à-dire une machine dont le comportement des sorties ne dépend pas seulement de l'état de ses entrées, mais aussi d'un historique des sollicitations passées.

Comme nous venons de le dire, un automate à états finis est un automate dont le comportement des sorties ne dépend pas seulement de l'état de ses entrées, mais aussi d'un historique des sollicitations passées. Cet historique est caractérisé par un état global.

Un état global est un jeu de valeurs d'objet, pour une classe donnée, produisant la même réponse face aux événements. Toutes les instances d'une même classe ayant le même état global réagissent de la même manière à un événement. Il ne faut pas confondre les notions d'état global et d'état. La section 5.2.1Les deux acceptions du terme état donne plus d'information sur ces deux acceptions du terme état.

Un automate à états finis est graphiquement représenté par un graphe comportant des états, matérialisés par des rectangles aux coins arrondis, et des transitions, matérialisées par des arcs orientés liant les états entre eux.

La figure 5.1 montre un exemple simple d'automate à états finis. Cet automate possède deux états (Allumé et Éteint) et deux transitions correspondant au même événement : la pression sur un bouton d'éclairage domestique. Cet automate à états finis illustre en fait le fonctionnement d'un télérupteur dans une maison. Lorsque l'on appuie sur un bouton d'éclairage, la réaction de l'éclairage associé dépendra de son état courant (de son historique) : si la lumière est allumée, elle s'éteindra, si elle est éteinte, elle s'allumera.

Un diagramme d'états-transitions rassemble et organise les états et les transitions d'un classeur donné. Bien entendu, le modèle dynamique du système comprend plusieurs diagrammes d'états-transitions. Il est souhaitable de construire un diagramme d'états-transitions pour chaque classeur (qui, le plus souvent, est une classe) possédant un comportement dynamique important. Un diagramme d'états-transitions ne peut être associé qu'à un seul classeur. Tous les automates à états finis des diagrammes d'états-transitions d'un système s'exécutent concurremment et peuvent donc changer d'état de façon indépendante.

5-2-1-a. État dans un diagrammes d'états-transitions▲

Comme nous l'avons déjà dit, un état, que l'on peut qualifier informellement d'élémentaire, se représente graphiquement dans un diagramme d'états-transitions par un rectangle aux coins arrondis (figure 5.2).

Certains états, dits composites (cf. section 5.6États composites), peuvent contenir (i.e. envelopper) des sous-états.

Le nom de l'état peut être spécifié dans le rectangle et doit être unique dans le diagramme d'états-transitions, ou dans l'état enveloppant. On peut l'omettre, ce qui produit un état anonyme. Il peut y avoir un nombre quelconque d'états anonymes distincts. Un état imbriqué peut être identifié par son nom qualifié (cf. section 2.4.2Espace de noms) si tous les états enveloppants ont des noms.

Un état peut être partitionné en plusieurs compartiments séparés par une ligne horizontale. Le premier compartiment contient le nom de l'état et les autres peuvent recevoir des transitions internes (cf. section 5.4.6Transition interne), ou des sous-états (cf. section 5.6États composites), quand il s'agit d'un état composite. Dans le cas d'un état simple (i.e. sans transition interne ou sous-état), on peut omettre toute barre de séparation (figure 5.2).

5-2-1-b. État d'un objet, ou du diagramme d'états-transitions (i.e. état global)▲

5-2-2-a. État initial▲

L'état initial est un pseudoétat qui indique l'état de départ, par défaut, lorsque le diagramme d'états-transitions, ou l'état enveloppant, est invoqué. Lorsqu'un objet est créé, il entre dans l'état initial.

5-2-2-b. État final▲

L'état final est un pseudoétat qui indique que le diagramme d'états-transitions, ou l'état enveloppant, est terminé.

Un événement est quelque chose qui se produit pendant l'exécution d'un système et qui mérite d'être modélisé. Les diagrammes d'états-transitions permettent justement de spécifier les réactions d'une partie du système à des événements discrets. Un événement se produit à un instant précis et est dépourvu de durée. Quand un événement est reçu, une transition peut être déclenchée et faire basculer l'objet dans un nouvel état. On peut diviser les événements en plusieurs types explicites et implicites : signal, appel, changement et temporel.

Un signal est un type de classeur destiné explicitement à véhiculer une communication asynchrone à sens unique entre deux objets. L'objet expéditeur crée et initialise explicitement une instance de signal et l'envoi à un objet explicite ou à tout un groupe d'objets. Il n'attend pas que le destinataire traite le signal pour poursuivre son déroulement. La réception d'un signal est un événement pour l'objet destinataire. Un même objet peut être à la fois expéditeur et destinataire.

Les signaux sont déclarés par la définition d'un classeur portant le stéréotype « signal » ne fournissant pas d'opération et dont les attributs sont interprétés comme des arguments (cf. figure 5.5). La syntaxe d'un signal est la suivante :

<nom_événement> ( [ <paramètre> : <type> [; <paramètre> : <type> ... ] ] )

Les signaux supportent la relation de généralisation (cf. figure 5.5). Les signaux héritent des attributs de leurs parents (héritage) et ils déclenchent des transitions contenant le type du signal parent (polymorphisme).

Un événement d'appel représente la réception de l'appel d'une opération par un objet. Les paramètres de l'opération sont ceux de l'événement d'appel. La syntaxe d'un événement d'appel est la même que celle d'un signal. Par contre, les événements d'appel sont des méthodes déclarées au niveau du diagramme de classes.

Un événement de changement est généré par la satisfaction (i.e. passage de faux à vrai) d'une expression booléenne sur des valeurs d'attributs. Il s'agit d'une manière déclarative d'attendre qu'une condition soit satisfaite. La syntaxe d'un événement de changement est la suivante :

when ( <condition_booléenne> )

Notez la différence entre une condition de garde (cf. section 5.4.2Condition de garde) et un événement de changement. La première est évaluée une fois que l'événement déclencheur de la transition a lieu et que le destinataire le traite. Si elle est fausse, la transition ne se déclenche pas et la condition n'est pas réévaluée. Un événement de changement est évalué continuellement jusqu'à ce qu'il devienne vrai, et c'est à ce moment-là que la transition se déclenche.

Les événements temporels sont générés par le passage du temps. Ils sont spécifiés soit de manière absolue (date précise), soit de manière relative (temps écoulé). Par défaut, le temps commence à s'écouler dès l'entrée dans l'état courant.

La syntaxe d'un événement temporel spécifié de manière relative est la suivante :

after ( <durée> )

Un événement temporel spécifié de manière absolue est défini en utilisant un événement de changement :

when ( date = <date> )

Une transition définit la réponse d'un objet à l'occurrence d'un événement. Elle lie, généralement, deux états E1 et E2 et indique qu'un objet dans un état E1 peut entrer dans l'état E2 et exécuter certaines activités, si un événement déclencheur se produit et que la condition de garde est vérifiée.

La syntaxe d'une transition est la suivante :

[ <événement> ][ '[' <garde> ']' ] [ '/' <activité> ]

La syntaxe de <événement> a été définie dans la section 5.3Événement.

Le même événement peut être le déclencheur de plusieurs transitions quittant un même état. Chaque transition avec le même événement doit avoir une condition de garde différente. En effet, une seule transition peut se déclencher dans un même flot d'exécution. Si deux transitions sont activées en même temps par un même événement, une seule se déclenche et le choix n'est pas prévisible (i.e. pas déterministe).

Une transition peut avoir une condition de garde (spécifiée par '[' <garde> ']' dans la syntaxe). Il s'agit d'une expression logique sur les attributs de l'objet, associé au diagramme d'états-transitions, ainsi que sur les paramètres de l'événement déclencheur. La condition de garde est évaluée uniquement lorsque l'événement déclencheur se produit. Si l'expression est fausse à ce moment-là, la transition ne se déclenche pas, si elle est vraie, la transition se déclenche et ses effets se produisent.

Lorsqu'une transition se déclenche (on parle également de tir d'une transition), son effet (spécifié par '/' <activité> dans la syntaxe) s'exécute. Il s'agit généralement d'une activité qui peut être

• une opération primitive comme une instruction d'assignation ;
• l'envoi d'un signal ;
• l'appel d'une opération ;
• une liste d'activités, etc.

La façon de spécifier l'activité à réaliser est laissée libre (langage naturel ou pseudocode).

Lorsque l'exécution de l'effet est terminée, l'état cible de la transition devient actif.

Une transition externe est une transition qui modifie l'état actif. Il s'agit du type de transition le plus répandu. Elle est représentée par une flèche allant de l'état source vers l'état cible.

La figure 5.6 illustre la représentation graphique d'une transition externe entre deux états.

Une transition dépourvue d'événement déclencheur explicite se déclenche à la fin de l'activité contenue dans l'état source (y compris les états imbriqués). Elle peut contenir une condition de garde qui est évaluée au moment où l'activité contenue dans l'état s'achève, et non pas ensuite.

Les transitions de garde sont, par exemple, utilisées pour connecter les états initiaux et les états historiques (cf. section 5.6.3État historique) avec leur état successeur puisque ces pseudoétats ne peuvent rester actifs.

Les règles de déclenchement d'une transition interne sont les mêmes que pour une transition externe excepté qu'une transition interne ne possède pas d'état cible et que l'état actif reste le même à la suite de son déclenchement. La syntaxe d'une transition interne reste la même que celle d'une transition classique (cf. section 5.4.1Définition et syntaxe). Par contre, les transitions internes ne sont pas représentées par des arcs, mais sont spécifiées dans un compartiment de leur état associé (cf. figure 5.7).

Les transitions internes possèdent des noms d'événement prédéfinis correspondant à des déclencheurs particuliers : entry, exit, do et include. Ces mots-clefs réservés viennent prendre la place du nom de l'événement dans la syntaxe d'une transition interne.

entry

• entry permet de spécifier une activité qui s'accomplit quand on entre dans l'état.

exit

• exit permet de spécifier une activité qui s'accomplit quand on sort de l'état.

do

• une activité do commence dès que l'activité entry est terminée. Lorsque cette activité est terminée, une transition d'achèvement peut être déclenchée, après l'exécution de l'activité exit bien entendu. Si une transition se déclenche pendant que l'activité do est en cours, cette dernière est interrompue et l'activité exit de l'état s'exécute.

include

• permet d'invoquer un sous-diagramme d'états-transitions.

Les activités entry servent souvent à effectuer la configuration nécessaire dans un état. Comme il n'est pas possible de l'éluder, toute action interne à l'état peut supposer que la configuration est effectuée indépendamment de la manière dont on entre dans l'état. De manière analogue, une activité exit est une occasion de procéder à un nettoyage. Cela peut s'avérer particulièrement utile lorsqu'il existe des transitions de haut niveau qui représentent des conditions d'erreur qui abandonnent les états imbriqués.

Le déclenchement d'une transition interne ne modifie pas l'état actif et n'entraîne donc pas l'activation des activités entry et exit.

Les points de jonction sont un artefact graphique (un pseudoétat en l'occurrence) qui permet de partager des segments de transition, l'objectif étant d'aboutir à une notation plus compacte ou plus lisible des chemins alternatifs.

Un point de jonction peut avoir plusieurs segments de transition entrante et plusieurs segments de transition sortante. Par contre, il ne peut avoir d'activité interne ni des transitions sortantes dotées de déclencheurs d'événements.

Il ne s'agit pas d'un état qui peut être actif au cours d'un laps de temps fini. Lorsqu'un chemin passant par un point de jonction est emprunté (donc lorsque la transition associée est déclenchée) toutes les gardes le long de ce chemin doivent s'évaluer à vrai dès le franchissement du premier segment.

La figure 5.8 illustre bien l'utilité des points de jonction.

La figure 5.9 illustre l'utilisation de points de jonction pour représenter le branchement d'une clause conditionnelle.

Un point de décision possède une entrée et au moins deux sorties. Contrairement à un point de jonction, les gardes situées après le point de décision sont évaluées au moment où il est atteint. Cela permet de baser le choix sur des résultats obtenus en franchissant le segment avant le point de choix (cf. figure 5.10). Si, quand le point de décision est atteint, aucun segment en aval n'est franchissable, c'est que le modèle est mal formé.

Il est possible d'utiliser une garde particulière, notée [else], sur un des segments en aval d'un point de choix. Ce segment n'est franchissable que si les gardes des autres segments sont toutes fausses. L'utilisation d'une clause [else] est recommandée après un point de décision, car elle garantit un modèle bien formé.

Un état simple ne possède pas de sous-structure, mais uniquement, le cas échéant, un jeu de transitions internes. Un état composite est un état décomposé en régions contenant chacune un ou plusieurs sous-états.

Quand un état composite comporte plus d'une région, il est qualifié d'état orthogonal. Lorsqu'un état orthogonal est actif, un sous-état direct de chaque région est simultanément actif, il y a donc concurrence (cf. section 5.6.5Concurrence). Un état composite ne comportant qu'une région est qualifié d'état non orthogonal.

Implicitement, tout diagramme d'états-transitions est contenu dans un état externe qui n'est usuellement pas représenté. Cela apporte une plus grande homogénéité dans la description : tout diagramme d'états-transitions est implicitement un état composite.

L'utilisation d'états composites permet de développer une spécification par raffinements. Il n'est pas nécessaire de représenter les sous-états à chaque utilisation de l'état englobant. Une notation abrégée (figure 5.12) permet d'indiquer qu'un état est composite et que sa définition est donnée sur un autre diagramme.

La figure 5.11 montre un exemple d'état composite et la figure 5.12 montre sa notation abrégée.

Les transitions peuvent avoir pour cible la frontière d'un état composite et sont équivalentes à une transition ayant pour cible l'état initial de l'état composite.

Une transition ayant pour source la frontière d'un état composite est équivalente à une transition qui s'applique à tout sous-état de l'état composite source. Cette relation est transitive : la transition est franchissable depuis tout état imbriqué, quelle que soit sa profondeur.

Par contre, si la transition ayant pour source la frontière d'un état composite ne porte pas de déclencheur explicite (i.e. s'il s'agit d'une transition d'achèvement), elle est franchissable quand l'état final de l'état composite est atteint.

Les transitions peuvent également toucher des états de différents niveaux d'imbrication en traversant les frontières des états composites.

La figure 5.13 illustre une configuration complexe de transition produisant une cascade d'activités.

Un état historique, également qualifié d'état historique plat, est un pseudoétat qui mémorise le dernier sous-état actif d'un état composite. Graphiquement, il est représenté par un cercle contenant un H.

Une transition ayant pour cible l'état historique est équivalente à une transition qui a pour cible le dernier état visité de l'état englobant. Un état historique peut avoir une transition sortante non étiquetée indiquant l'état à exécuter si la région n'a pas encore été visitée.

Il est également possible de définir un état historique profond représenté graphiquement par un cercle contenant un H*. Cet état historique profond permet d'atteindre le dernier état visité dans la région, quel que soit son niveau d'imbrication, alors que le l'état historique plat limite l'accès aux états de son niveau d'imbrication.

La figure 5.14 montre un diagramme d'états-transitions modélisant le lavage automatique d'une voiture. Les états de lavage, séchage et lustrage sont des états composites définis sur trois autres diagrammes d'états-transitions non représentés ici. En phase de lavage ou de séchage, le client peut appuyer sur le bouton d'arrêt d'urgence. S'il appuie sur ce bouton, la machine se met en attente. Il a alors deux minutes pour reprendre le lavage ou le lustrage, exactement où le programme a été interrompu, c'est-à-dire au niveau du dernier sous-état actif des états de lavage ou de lustrage (état historique profond). Si l'état avait été un état historique plat, c'est toute la séquence de lavage ou de lustrage qui aurait recommencé. En phase de lustrage, le client peut aussi interrompre la machine. Mais dans ce cas, la machine s'arrêtera définitivement.

Comme nous l'avons déjà dit, il est possible de masquer les sous-états d'un état composite et de les définir dans un autre diagramme. Cette pratique nécessite parfois l'utilisation de pseudoétats appelés points de connexion.

Lorsque l'on utilise le comportement par défaut de l'état composite, c'est-à-dire entrer par l'état initial par défaut et considérer les traitements finis quand l'état final est atteint, aucun problème ne se pose, car on utilise des transitions ayant pour cible, ou pour source, la frontière de l'état composite. Dans ce cas, les points de connexion sont inutiles.

Le problème se pose lorsqu'il est possible d'entrer ou de sortir d'un état composite de plusieurs façons. C'est, par exemple, le cas lorsqu'il existe des transitions traversant la frontière de l'état composite et visant directement, ou ayant pour source, un sous-état de l'état composite. Dans ce cas, la solution est d'utiliser des points de connexion sur la frontière de l'état composite.

Les points de connexion sont des points d'entrée et de sortie portant un nom, et situés sur la frontière d'un état composite. Ils sont respectivement représentés par un cercle vide et un cercle barré d'une croix (cf. figure 5.15). Il ne s'agit que de références à un état défini dans l'état composite. Une unique transition d'achèvement, dépourvue de garde, relie le pseudoétat source (i.e. le point de connexion) à l'état référencé. Cette transition d'achèvement n'est que le prolongement de la transition qui vise le point de connexion (il peut d'ailleurs y en avoir plusieurs). Les points de connexions offrent ainsi une façon de représenter l'interface (au sens objet) d'un état composite en masquant l'implémentation de son comportement.

On peut considérer que les pseudoétats initiaux et finals sont des points de connexion sans nom.

Les diagrammes d'états-transitions permettent de décrire efficacement les mécanismes concurrents grâce à l'utilisation d'états orthogonaux. Un état orthogonal est un état composite comportant plus d'une région, chaque région représentant un flot d'exécution. Graphiquement, dans un état orthogonal, les différentes régions sont séparées par un trait horizontal en pointillé allant du bord gauche au bord droit de l'état composite.

Chaque région peut posséder un état initial et final. Une transition qui atteint la bordure d'un état composite orthogonal est équivalente à une transition qui atteint les états initiaux de toutes ses régions concurrentes.

Toutes les régions concurrentes d'un état composite orthogonal doivent atteindre leur état final pour que l'état composite soit considéré comme terminé.

La figure 5.16 illustre l'utilisation d'un état composite orthogonal pour modéliser le fait que la préparation de la boisson d'un distributeur de boissons se fait en parallèle au rendu de la monnaie.

Il est également possible de représenter ce type de comportement au moyen de transitions concurrentes. De telles transitions sont qualifiées de complexes. Les transitions complexes sont représentées par une barre épaisse et peuvent, éventuellement, être nommées. La figure 5.17 montre la mise en œuvre de ce type de transition. Sur ce diagramme, l'état orthogonal préparer boisson et rendre monnaie peut éventuellement ne pas apparaître (tout en gardant la représentation de ses sous-états) pour alléger la représentation, car la notion de concurrence est clairement apparente de par l'utilisation des transitions complexes.