UML2 :
Diagramme d’états simple
Considérons
une montre à cadran numérique simplifiée :
Montre à
cadran numérique simplifiée
1. Le
mode courant est le mode « Affichage ».
2. Quand
on appuie une fois sur le bouton mode, la montre passe en «
modification heure ». Chaque pression sur le bouton avance incrémente
l’heure d’une unité.
3. Quand
on appuie une nouvelle fois sur le bouton mode, la montre passe en «
modification minute ». Chaque pression sur le bouton avance incrémente
les minutes d’une unité.
4. Quand
on appuie une nouvelle fois sur le bouton mode, la montre repasse en
mode « Affichage ».
Travail à
faire :
Dessinez le diagramme d’états correspondant.
SOLUTION
On obtient sans difficulté particulière ce diagramme
d’états typique, qui est présenté sur le schéma suivant.
Diagramme d’états préliminaire de la montre à cadran numérique
On remarquera les notations en style C++ ou Java pour les actions :
« heure++ » et « minute++ ». UML n’impose pas de « langage d’action » nous pouvons donc en exprimer le détail comme nous le souhaitons : texte libre, pseudo-code, etc.
Nous obtenons des transitions propres sur les états de modification et pas sur l’état d’affichage. Cela veut-il dire que Evénement « appui bouton avance » est impossible dans l’état « Affichage » ? Non, bien sûr. Cela signifie plutôt que, comme cet évènement n’a aucun effet dans cet état, il ne déclenche aucune transition. L’événement est purement et simplement perdu.
CONCEPTS AVANCÉS DU DIAGRAMME D’ÉTATS
Exercice 2
: Événement temporel
Ajoutez le comportement suivant : quand on appuie sur le bouton avance plus de deux secondes, les heures (ou les minutes) s’incrémentent rapidement jusqu’à ce qu’il se produise un relâchement dans la pression du bouton.
Envisagez plusieurs solutions possibles.
SOLUTION
Dans
l’exemple précédent, les événements d’appui sur les boutons correspondaient en
fait au couple indivisible « pression » et « relâchement ». Nous avions
considéré que la durée de pression sur chaque bouton était négligeable par
rapport aux durées des états ou, en tout cas, non significative. Avec le nouvel
énoncé, ce n’est plus le cas, puisque la durée de pression sur le
bouton avance influe sur le comportement de la montre. La bonne approche
consiste à introduire un nouvel évènement : « relâchement bouton
avance », afin de pouvoir gérer le temps de pression.
Le diagramme suivant montre l’utilisation du nouveau timing diagram d’UML 2.
Timing diagram : transformation d’un évènement en deux
Une
première solution, tentante, consiste à introduire une condition sur
la durée de pression, ainsi qu’un nouvel état « Incrémentation rapide »,
comme cela est illustré sur la figure suivante :
Modification erronée du diagramme d’états de la montre à cadran numérique
Modification erronée du diagramme d’états de la montre à cadran numérique
Pourtant, cette solution qui semble évidente n’est pas
acceptable en UML.
En effet, un événement (comme une transition) est par convention instantané, ou en tout cas insécable (atomique). Il est donc tout à fait inapproprié de tester sa durée ! Les seuls concepts dynamiques en UML pour lesquels la notion de durée est significative sont l’état et l’activité durable. Il faut donc s’en servir pour résoudre cet exercice. Deux solutions sont possibles : toutes les deux nécessitent que l’on ajoute un état intermédiaire pour que l’on puisse tester la durée de pression sur le bouton avance, mais elles diffèrent quant à la façon de réaliser ce test :
• La première approche consiste à introduire une activité finie « attendre 2 s » dans l’état intermédiaire et une transition automatique qui représente le fait que le bouton est appuyé plus de deux secondes.
• La seconde approche consiste à utiliser un autre mot-clé proposé par UML :
le pseudo-événement « after », suivi d’une durée en argument représentant l’échéance d’un timer.
Pour illustrer les deux solutions, nous les avons représentées ensemble sur le diagramme suivant mais, dans la réalité, il faudrait bien sûr en choisir une seule et l’appliquer aux deux états de modification. Pour notre part, nous recommandons la seconde solution qui nous semble plus simple et plus facile à lire.
Les deux possibilités pour procéder à une modification correcte du diagramme d’états de la montre à cadran numérique
En effet, un événement (comme une transition) est par convention instantané, ou en tout cas insécable (atomique). Il est donc tout à fait inapproprié de tester sa durée ! Les seuls concepts dynamiques en UML pour lesquels la notion de durée est significative sont l’état et l’activité durable. Il faut donc s’en servir pour résoudre cet exercice. Deux solutions sont possibles : toutes les deux nécessitent que l’on ajoute un état intermédiaire pour que l’on puisse tester la durée de pression sur le bouton avance, mais elles diffèrent quant à la façon de réaliser ce test :
• La première approche consiste à introduire une activité finie « attendre 2 s » dans l’état intermédiaire et une transition automatique qui représente le fait que le bouton est appuyé plus de deux secondes.
• La seconde approche consiste à utiliser un autre mot-clé proposé par UML :
le pseudo-événement « after », suivi d’une durée en argument représentant l’échéance d’un timer.
Pour illustrer les deux solutions, nous les avons représentées ensemble sur le diagramme suivant mais, dans la réalité, il faudrait bien sûr en choisir une seule et l’appliquer aux deux états de modification. Pour notre part, nous recommandons la seconde solution qui nous semble plus simple et plus facile à lire.
Les deux possibilités pour procéder à une modification correcte du diagramme d’états de la montre à cadran numérique
On notera
que le comportement initial est conservé : si le bouton avance est relâché en
moins de deux secondes, les heures (ou les minutes) sont bien incrémentées
d’une unité. En fait, la transition propre qui existait sur chaque état de
modification a pu être coupée en deux suite à la séparation des
deux évènements « appui » et « relâche », et à l’ajout de l’état
intermédiaire.
Aucun commentaire:
Enregistrer un commentaire