Moore/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 Moore, à l'entrée dans un état, une action est peut être réalisée et est donc indépendante de l'événement ayant déclenché la transition.

Une machine de Moore est définie comme un 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 un ensemble fini d'événements d'entrée
 * &#923; est un ensemble fini d'événements de sortie
 * T : S &times; &#931; &#8594; S est une fonction de transition qui met en correspondance un état et un événement d'entrée avec l'état suivant
 * G : S &#8594; &#923; est la fonction de sortie qui associe chaque état à un événement de sortie (on s'autorise à ne pas générer d'événement pour tous les états).

La structure
L'extension FSA::Moore 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::Moore 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::Moore ?
L'écriture d'un modèle passe par la construction d'une sous-classe de vle::extension::fsa::Moore et la définition de l'automate de type Moore 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 et 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 et donc lors de l'entrée dans un nouvel état, 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 entre dans l'état a. 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.

Grâce à l'opérateur >>, on peut aussi dire que cette même méthode est utilisée pour plusieurs états.

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 l'état 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 out lorsque l'on entre dans les états a et c.

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 modifié 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énement. 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, le compteur (l'attribut value) est mis à zéro (l'action start de l'état START). Lors d'un événement d'entrée, l'automate passe dans l'état RUN et lance l'action run qui incrémente le compteur. Ensuite la méthode out est invoquée et construit un événement avec la valeur du compteur.

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".