TUTORIELS 
UML: vues dynamiques (2)
Examen des diagrammes d'états-transitions, des événements qui déclenchent les changements d'états et des spécifications annexes possibles.  (13 juillet 2001)
 

Après avoir détaillé (premier volet de ce tutoriel) les diagrammes de collaboration et de séquences, nous terminons ce survol d'UML et de ses vues dynamiques par les diagrammes d'activités et d'états-transitions. Ces derniers, tout d'abord, décrivent comme leur nom l'indique des changements d'état, d'un objet ou d'un composant. Un état est défini par les valeurs (intantanées) des attributs de l'objet ou des objets considérés. Une transition peut être déclenchée par un événement, ou au contraire être automatique. Dans le premier cas, la transition est désignée par l'événement qui la déclenche. Une transition peut également être conditionnelle. Par exemple, examinons le diagramme suivant:

On considère un scénario, qui a donc un début et une fin, et différents états des objets du modèle lors du déroulement de ce scénario. Celui-ci peut lui-même être déclenché par un événement, lequel est donc externe au scénario: la transition (symbolique) vers le premier état est donc modélisée comme une transition automatique. Dans notre exemple, le deuxième état est atteint à partir du premier suite à un événement. Ces deux états sont liés ici au sein d'un super-état. Un troisième état, auquel on accède suite à un autre événement à partir du deuxième état, est soumis à une transition conditionnelle: un événement particulier, et un seul, provoque la fin du scénario: tout autre ramène à l'état de départ.

Plus concrètement, si notre scénario décrit un moteur de recherche par exemple: le premier état pourrait être l'affichage de la boîte de recherche, le second la recherche proprement dite (l'événement déclanchant étant la saisie d'un mot-clé). La fin de la recherche conduit à un troisième état qui est l'affichage des résultats. A partir de là, l'utilisateur peut cliquer sur l'un des résultats proposés, ce qui met fin au scénario, ou cliquer sur quelque chose comme "Effectuer une nouvelle recherche", ce qui le ramène à la boîte de recherche. Ajoutons que l'imbrication au sein d'un super-état des états "affichage de la boîte de recherche" et "recherche" n'est pas exploitée ici.
Evidemment, toute cette représentation est extrêmement simplifiée.

On peut associer des actions aux événements (avec la syntaxe suivante: événement / action), et en particulier spécifier des actions propres à un état. Par exemple, à "l'entrée" de l'état "affichage de la boîte de recherche", on pourra préciser l'action "placer le curseur dans le champ texte", et à la "sortie" de l'état, l'action "supprimer les mots-clés trop courants". UML utilise pour cela des noms d'événements spécifiques: entry et exit. Il en existe d'autres comme do qui désigne une action récurrente au sein d'un état. Ces événements sont associés à un état et non à une transition.

Par ailleurs des groupes d'états-transitions simultanés peuvent être représentés sur un même diagramme, en utilisant des automates à agrégation d'états (qui englobent au sein d'un super-état les séries d'états-transitions simultanées séparées par des lignes en pointillés). On utilise parfois des barres de synchronisation* à partir desquelles toutes les transitions automatiques sont simultanées, et qui sont franchies uniquement lorsque toutes les transitions qui y parviennent ont été réalisées.

Enfin, on peut paramétrer et contraindre les événements, par exemple:

saisie(mot-clé) [valide]

(
sur le modèle événement(paramètre) [contrainte]) afin de clarifier la modélisation.

Survol rapide des états-transitions, cet article sera prochainement complété par l'examen des diagrammes d'activités.

(*symbole |)

 
[ Jérôme Morlon, JDNet
 
Accueil | Haut de page