Métamodèle retenu dans TOPCASED pour la simulation de

chine à états UML2.0

Domain Definition MetaModel

Pour la première version de l’animateur, nous avons ciblé un sous-ensemble des machines à états d’UML2.0 dont le métamodèle est donné sur la figure9.4. Ce métamodèle décrit les propriétés structurelles des machines à états. Afin de clari- fier leur présentation, nous allons l’illustrer à travers un exemple qui introduit les concepts pris en compte pour la simulation. Cet exemple est donné sur la figure9.5

et décrit une unique machine à états car l’animateur n’est actuellement capable que de simuler une seule machine à la fois. Le prochain paragraphe détaille cet exemple et souligne les concepts pris en compte dans la simulation et donc présents dans le métamodèle (entre parenthèse et en italique).

La machine à états (StateMachine) de la figure9.5modélise les feux clignotants d’une voiture. C’est une machine à états concurrente composée de quatre régions (Region) : une pour le feux gauche, une pour le feux droit, une pour la poignée et une pour l’horloge interne. Les feux droit et gauche partagent la même ma- chine à états et pourraient être considérés comme deux instances du même concept Feu. Les travaux sur la gestion d’instances dans le simulateur sont actuellement en cours, et nous avons donc dû dans un premier temps dupliquer la machine à états et renommer les signaux (Signal) qui déclenchent (Trigger) les transitions (Tran-

9.3. TOPCASED MODEL SIMULATION 151

Handle Right Flashing Light Left Flashing Light

Clock TIC after(3) / ^TOP pushUp/^RStart _{pushUp/^LStop} pushDown/^RStop pushDown/^LStart MIDDLE DOWN UP OFF LStart ON OFF RStart ON RStop LStop TOP TOP TOP TOP switchedOn switchedOff switchedOff switchedOn

FIGURE9.5: Machine à états pour des feux clignotants

sition). Aussi, le signal Lstart démarre le feux gauche et le met dans l’état appelé ON. Cet état est composé d’une région avec les deux sous-états switchedOff et switchedOnqui indiquent si la lumière est allumée ou non. Le feux passe d’un état à l’autre en fonction du signal TOP généré par l’horloge. Enfin, la poignée réagit en fonction des signaux envoyés par l’utilisateur pushUp et pushDown et de sa position – down, middle ou up – pour allumer ou éteindre le feux gauche ou droit.

Nous avons considéré dans un premier temps uniquement les transitions lo- cales, c.-à-d. les transitions dont l’état source et l’état cible appartiennent à la même région. Une transition est déclenchée par des événements (Event) et peut exécuter une activité quand elle est franchie. Les activités (Activity) sont décomposées en actions (Action). La première action que nous avons prise en compte (BroadCast- SignalAction) permet d’envoyer le signal de manière globale à tout le modèle. Un événement correspond soit à un signal (SignalEvent) soit à une date (TimeEvent). La transition dans la région correspondant à l’horloge définit un événement tempo- rel indiquant qu’elle sera franchie au bout de 3 unités de temps à partir de l’entrée dans l’état TIC. Les transitions dans la région Handle correspondant à la manette sont déclenchées soit par le signal pushDown, soit pas le signal pushUp. Quand elles sont franchies, elles exécutent une action qui émet en diffusion un signal fai- sant évoluer les régions qui correspondent aux feux.

Notons que tous les éléments qui ne sont pas pris en compte par la simula- tion peuvent être présents dans le modèle construit à partir de l’éditeur graphique (MDDMM) mais seront ignorés dans le modèle dynamique (MSDMM). Une analyse

en utilisant des contraintes OCL devra être réalisée pour avertir l’utilisateur des éléments non supportés (et du risque d’échecs de la simulation).

States Definition MetaModel

Conformément à l’approche définie dans cette thèse, nous avons complété le métamodèle défini par l’OMG de manière à prendre en compte les informations dynamiques caractérisant l’état du système (MSDMM). Par exemple, nous avons

besoin de connaître l’état courant de chaque région active, la liste des signaux en attente, de pouvoir dire si une transition peut être franchie ou pas, etc.

Cette partie de la syntaxe abstraite vient compléter celle du DDMM. L’opéra- teur merge utilisé dans l’approche présentée dans cette thèse pour structurer les dif- férentes préoccupations n’est actuellement pas disponible dans EMF. C’est pour- quoi nous avons préféré définir des métamodèles différents avec des liens entre eux (le SDMM a des liens vers le DDMM). Une transformation de modèle en ATL permet de construire un MSDMMà partir d’un MDDMM.

Events Definition MetaModel

Pour l’exécution des machines à états UML2.0, le EDMM contient dans un premier temps un seul événement « injecter un signal ». Il rajoute un signal à ceux qui doivent être traités par la machine à états. Cet événement peut être à la fois exogène et endogène. Dans notre exemple, cet événement est exogène pour les si- gnaux pushDown et pushUp de la manette. Il est endogène pour les signaux comme RStartqui sont émis lors du franchissement d’une transition de la région Handle.

Des travaux en cours intègrent les notions de classe et d’instance. Cela conduit à distinguer deux événements différents pour injecter un signal. Le premier diffuse le signal à toutes les machines du système (broadcast signal) et le second cible la machine à états d’une instance particulière (send signal).

Grâce à ces événements et en s’appuyant sur le TM3, on peut définir des scé- narios et des traces d’exécution comme des séquences d’instances des événements décrits ci-dessus. La figure9.6 présente un exemple de scénario (figure9.6a) qui consiste à lever puis baisser la manette. Elle donne aussi une trace possible expri- mée sous forme textuelle (figure9.6c) et de diagramme de séquence UML (figure

9.6b).