Mealy/fr

Introduction
Un automate est composé d'états et de transitions. Son comportement est dirigé par des événements fournis en entrée (cette notion d'événements sera reliée directement à la notion d'événement en DEVS) : l'automate passe d'état en état, suivant les transitions, en fonction des événements d'entrée. Un automate fini forme donc un graphe orienté étiqueté, dont les états sont les sommets et les transitions les arêtes étiquetées.

Dans le cas des automates de type Mealy, lors d'un événement d'entrée, une action est peut être réalisée et est donc dépendante de l'événement ayant déclenché la transition.

Une machine de Mealy est définie par le n-tuple, (S, S0, &#931;, &#923;, T, G) où :
 * S est un ensemble fini d'états
 * S0 est l'état initial et appartient à S
 * &#931; est l'ensemble fini d'événements d'entrée
 * &#923; est l'ensemble fini d'événements de sortie
 * T : S × &#931; &#8594; S est la fonction de transition qui met en correspondance un état et un événement d'entrée avec l'état suivant
 * G : S × &#931; &#8594; &#923; est la fonction de sortie qui associe chaque état et événement d'entrée à un événement de sortie

La structure
L'extension FSA::Mealy n'impose rien sur la structure du modèle. Dans la définition du modèle, il faut juste relier les transitions et les sorties aux noms de ports définis.

Les initialisations
L'extension FSA::Mealy ne nécessite aucun paramètre hormis les paramètres spécifiques au modèle utilisés lors des actions ou des sorties (voir Modèle avec des conditions).

Comment écrire un modèle à base de FSA::Mealy ?
L'écriture d'un modèle passe par la construction d'une sous-classe de vle::extension::fsa::Mealy et la définition de l'automate de type Mealy est réalisée à l'intérieur du constructeur.

Voici un exemple de déclaration avec une énumération :

Dans cet exemple, l'automate se compose de 3 états définis par les symbole a, b et c.

Voici maintenant un exemple d'initialisation des paramètres, il ne faut pas oublier la récupération des paramètres dans le constructeur sinon les paramètres du modèle ne seront pas définis.

La deuxième étape consiste à définir compléter le constructeur avec la définition de l'automate (les états, les transitions, les actions et les sorties). La définition passe par l'utilisation des opérateurs < >.

La méthode state(this) << permet de déclarer la liste des états de l'automate.

Après avoir défini les états, on peut déclarer les transitions et la relation entre transition et événement externe. On considère dans cette extension, les événements externes au travers les ports.

Dans l'exemple, on définit 6 transitions entre les 3 états a, b et c. A chaque transition, on indique le port sur lequel l'événement doit arriver. Par exemple, si l'automate est en état a et qu'un événement arrive sur le port in1 alors l'automate passe en état c. L'automate reste en état c tant qu'aucun événement n'arrive sur les ports in1 ou in2.

Lors d'une transition, on peut définir des actions.

Dans l'exemple, on définit une action mise en oeuvre par la méthode action1 lorsque l'on réalise la transition de a vers c sur l'événement in1. La méthode action1 appartient à la classe M et a pour signature :

La méthode admet en paramètre la date (le paramètre time) à laquelle l'action est réalisée et l'événement qui a déclenché la transition. L'événement peut transporter des données et qui peuvent être traité par la méthode.

La définition des sorties est possible sous deux formes :
 * la sortie ne produit qu'un événement sans donnée ;
 * la sortie produit un événement avec des données qui sont liées à l'état du modèle (ici, l'état désigne les données supplémentaires définies dans le modèle).

Dans le premier cas, il suffit de faire le lien entre la transition et le port de sortie. Les sorties sont construites après les actions.

Dans l'exemple, un événement est déposé sur le port out1 lorsque l'on passe de l'état a à l'état c sur l'événement in1.

Pour le deuxième cas, on fait appel à une méthode qui doit avoir la forme suivante :

Lors d'une sortie de ce type, le modélisateur doit construire lui-même le ou les événements en fonction de l'état du modèle.

Il reste une dernière chose à définir : l'état initial.

Les conflits entre les événements
Etant donné que nous sommes en P-Devs, il est possible qu'au même instant plusieurs événements arrivent sur les ports d'entrée d'un automate. Dans ce cas là, il est possible de surcharger la méthode select qui donne l'ordre de traitement des événements. Par défaut, l'ordre n'est pas touché et cet ordre est aléatoire.

La méthode select doit construire une nouvelle liste ordonnée des événements.

Un exemple complet
L'exemple proposé définit un petit compteur d'événements. A chaque événement d'entrée, un compteur est incrémenté et sa valeur est mise en sortie du modèle. Le modèle possède un seul port d'entrée in et un seul port de sortie.

A l'initialisation (dans le constructeur ce qui n'est pas très bien), le compteur (l'attribut value) est mis à zéro. Lors d'un événement d'entrée, l'automate passe dans l'état RUN et lance l'action start qui met le compteur à 1. Ensuite la méthode out est invoquée et construit un événement avec la valeur du compteur. Dans l'état RUN, lorsqu'un événement arrive, l'action run incrémente le compteur et la méthode out est invoquée.

La méthode observation de la classe vle::devs::Dynamics est surchargeable et permet ici d'ajouter l'observation de la variable supplémentaire d'état value. Par défaut, on ne peut qu'observer l'état discret de l'automate sur le port "state".