Modélisation dynamique exercices corrigés et conseils méthodologiques

Modélisation dynamique exercices corrigés et conseils méthodologiques

CONCEPTS DE BASE DU DIAGRAMME D’ÉTATS

Commençons par représenter le comportement séquentiel d’une partie, sachant que les Blancs commencent. Représentons ensuite par des états finaux différents les trois issues possibles : gain blanc (1-0), gain noir (0-1) et partie nulle (1/2-1/2). Nous n’avons pas cherché l’exhaustivité, les règles des échecs de compétition étant nettement plus complexes que ce qui est dessiné sur le schéma suivant.

EXERCICE 6-1. Diagramme d’états d’une partie d’échecs

Dessinez le diagramme d’états correspondant au déroulement d’une partie d’échecs. So ul tion Figure 6-1. Début du diagramme d’états de la partie Figure 6-2. Diagramme d’états de la partie 179-210  Si nous souhaitons ajouter la possibilité de commencer une partie à partir d’une position donnée à la place de la position initiale standard, nous sommes amenés à utiliser la nouvelle notation du point d’entrée (« entry point »). Le cercle blanc nommé « Position » sur la figure 6-3 permet de démarrer directement une partie dans l’état « NoirsJouent » si on le désire, alors que le sousétat initial par défaut est « BlancsJouent », comme indiqué par la flèche positionnée au-dessus de ce sous-état. Les événements « pat » et « répétition » sont factorisés, alors que « abandon » et « mat » mènent à des états de sortie différents suivant l’état source. La notation du point de sortie (« exit point ») consiste en une croix à l’intérieur d’un cercle blanc. Elle est également nouvelle et propre à UML 2. Considérons un réveille-matin simplifié : • on peut mettre l’alarme « on » ou « off » ; • quand l’heure courante devient égale à l’heure d’alarme, le réveil sonne sans s’arrêter ; • on peut interrompre la sonnerie. Voyons tout d’abord la première phrase : 1. On peut mettre l’alarme « on » ou « off ».

EXERCICE 6-2. Diagramme d’états simple

Dessinez le diagramme d’états correspondant. Figure 6-3. Diagramme d’états complété de la partie So ul tion 179-210 chap6.fm Page 181 Vendredi, 18. ao t 2006 2:39 14 Point de vue dynamique TROISIÈME PARTIE 182 Le réveil a clairement deux états distincts : Désarmé (alarme « off ») ou Armé (alarme « on »). Une action de l’utilisateur permet de passer d’un état à l’autre. On suppose que le réveil est bien désarmé au départ. Notez le paramètre heureAlarme de l’événement armer. Considérons maintenant les deux autres phrases : 2. Quand l’heure courante devient égale à l’heure d’alarme, le réveil sonne sans s’arrêter ; 3. On peut interrompre la sonnerie. Le fait de sonner constitue un nouvel état pour le réveil. Il s’agit bien d’une période de temps durant laquelle le réveil effectue une certaine activité (sonner) qui dure jusqu’à ce qu’un événement vienne l’interrompre. Le passage de l’état Armé à l’état Sonnerie est déclenché par une transition due à un changement interne, représenté au moyen du mot-clé « when ». En revanche, d’après l’énoncé, le retour de l’état Sonnerie à l’état Armé ne s’effectue que sur un événement utilisateur.

EXERCICE 6-3. Activité finie et transition automatique

Complétez le diagramme d’états précédent pour prendre en compte le fait que la sonnerie du réveil s’arrête d’elle-même au bout d’un certain temps. Figure 6-4. Diagramme d’états de la phrase 1 Figure 6-5. Diagramme d’états préliminaire du réveille-matin 179-210 chap6.fm Page 182 Vendredi, 18. ao t 2006 2:39 14 Modélisation dynamique : exercices corrigés et conseils méthodologiques CHAPITRE 6 183 Il y a donc une deuxième possibilité de sortie de l’état Sonnerie : quand le réveil s’arrête tout seul de sonner au bout d’un certain temps. Dans notre exemple, il suffit donc d’ajouter une activité durable sonner à l’état Sonnerie et une transition automatique en sortie de cet état. Le diagramme d’états complété est représenté sur le schéma suivant. Il convient aussi de se demander si l’utilisateur a le droit de désarmer le réveil pendant qu’il sonne. Dans ce cas, il faudrait ajouter une transition déclenchée par desarmer et allant directement de Sonnerie à Désarmé.

CONCEPTS AVANCÉS DU DIAGRAMME D’ÉTATS

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 Dessinez le diagramme d’états correspondant. EXERCICE 6-6. É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. So ul tion  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. 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 : 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 Figure 6-10. Timing diagram : transformation d’un événement en deux Figure 6-11. Modification erronée du diagramme d’états de la montre à cadran numérique 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.