Rapport Projet Long Java Animation de diagramme d’état Contenu Introduction Changement dans la classe Conclusion automate……….. Paquetage simulateu 4 Teste. 6 2 or 5 Sni* to View Le projet long java consiste à simuler des diagrammes d’état et d’afficher les événements qui se produisent au cours de la simulation est les interactions correspondantes. Lors de la première phase on a modélisé le problème dans un diagramme IJML. Cependant et lors de la nous ont assuré le bon fonctionnement de notre programme.
Changement dans la classe automate On a changé plusieurs choses dans le paquetage automate, voici es changements fait par classe • Classe Etat: Dans la classe état on a implanté deux méthodes. La première retourne la liste des transitions franchissable en fonction des événements courant. Cette méthode a été ajoutée pour retourner les transitions qui sont franchissable après avoir vérifié si les événements correspondant sont actifs. La deuxième méthode qu’on a implantée est la méthode qui permet de franchir la transition ‘transitera.
Cette fonction nous retourne l’état cible de la transition à franchir et donc le nouvel état courant. Classe Transition: Une transition n’a pas toujours un évènement qui permet de la franchir et dans ce cas cette transition est toujours franchissable, c’est le cas de Phorloge entre Taco et Tacl on n’a pas d’événement. Ainsi dans la classe transltion on a ajouté un attribut de type ‘Booléen’ qui indique si la transition a un événement ou pas.
On a implanté la méthode ‘isexecutable’ utile pour la fonction ‘isfranchissable’ qui teste si dans les évènements courants on trouve l’evènement associe à notre transition et par conséquent retourne un booléen. L’action associée à une transition peu parfois engendré des événements qui doivent être ajouté aux évènements courant, ainsi on a implanté une fonction ‘appliquer action’ qui permet d’appliquer l’action associé à la fonction.
Classe événement : La classe événement *AGF 9 rif s action’ qui Classe événement : La classe événement n’a pas été changé, mais par contre la structure choisie pour illustrer une liste d’événement est la structure Map car celle-ci permet déviter les doublets. Classe Super état: Chaque Super état est caractérisée par un état initial, un ensemble ‘états courants et un ensemble de Super états. On a implanté une méthode dans cette classe qui permet d’initialiser les états courants pour chaque super état. Elle est très utile lors de l’initialisation première du simulateur utilisé à chaque retour ? zéro de fautomate.
Classe automate : Comme on a vu lors du dernier entretien on a changé le nom de la classe simulateur par ‘automate’ et ceci car le nom de simulateur est plus adapté à ce qui faire les simulations et qui va être l’objet observable pour les interfaces. Un automate n’a plus détat courant car il a des super états et c’est ces super états régions) qui ont des états courant. De plus on a rajouté de nouveaux attributs notamment l’ensemble des événements courants et suivants dont on a besoin pour faire les transitions et appliquer les actions.
On a implanté une méthode dans cette classe qui est utile lors du retour à zéro et qui efface tous les évènements courant et ceux engendré pour redémarrer l’automate. Paquetage simulateur On a implanté un nouveau PAGF3CFS imulateur qui a pour but simuler le fonctionnement d’un automate. Ce paquetage contient tout d’abord La classe détermination qui est une boite de dialogue ont le but est de permettre à l’utilisateur de choisir entre les transitions dans le cas d’indéterminisme.
Ensuite il y a la classe simulateur qui hérite de la classe ‘observable’ et est définie par un automate qui est l’automate a simuler, un ensemble de super état courant à l’automate, un ensemble d’états du système et un dialogue de type détermination. La méthode principale ‘simuler’ consiste à franchir des transitions d’un automate. Finalement viennent les trois interfaces Textuelle, spécifique et générique qui réalisent l’interface observer qui a pour rôle de mettre à jour les interfaces u cas où le simulateur a changé.
L’Interface spécifique permet de visualiser le diagramme complet du feu clignotant. Le code de cette interface a déjà été implémenté dans la première phase. L’interface textuelle permet à chaque pas de la simulation d’afficher les événements ? traiter et les interactions ayant lieu. L’interface générique est une interface générale et n’est pas spécifique à un diagramme en particulier et permet d’afficher ce qui est lister dans la tache6 de sujet du projet. Ces trois interfaces ont été testées dans la classe IHMTest.
Ce este implémente le cas du feu clignotant complet PAGF fonctionnement du programme. Tout d’abord il ya les tests unitaire qui servent à tester les méthodes de chaque classe pour différentes condltions. Ensuite il y a les teste qui assure le bon fonctionnement d’un simulateur et ceux dans plusieurs cas. On s’est inspiré pour les faire du sujet de projet. Voici les figures que représentent les différents tests : Test figure 8 : Ce test assure le bon fonctionnement du simulateur quand deux transitions sont possibles. Et dans ce cas le simulateur doit demander ? l’utilisateur quelle transition hoisir.
Voici le choix que nous donne l’exécution de ce test : Taches : Ce teste est un diagramme d’état d’un processus et assure le bon fonctionnement du simulateur dans le cas général. Test figure 7 : Ce teste assure le bon fonctionnement du simulateur dans le cas des transitions avec priorités. Testsimulateurfeul : Ce teste est un diagramme de feu clignotant sans état inactif TestsimulateurFeu2 : Ce test est la figure 6 du sujet de projet et c’est le diagramme final du feu clignotant. 7 Test simulateurFeu3 : Ce test a été conçu pour s’assurer que le simulateur rentre bien dan
