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 |)
|