Rapport de projet

Animation de diagrammes d'état-

CHAMPION Adrien - ETIENNE Thibaut – RIZZI Thibaut1A - INFO - Groupe EF - G36

Juin 2008

2

Table des matières1 – Introduction.........................................................................................................................................5

1.1 - Objectif.........................................................................................................................................51.2 – Choix de conception....................................................................................................................52 – Analyse............................................................................................................................................52.1 – Diagramme de cas d'utilisation...................................................................................................52.2 – Description des différents objets.................................................................................................6

2.2.1 – Les états...............................................................................................................................62.2.2 – Les transitions......................................................................................................................62.2.3 – Les évènements....................................................................................................................62.2.4 – Les actions...........................................................................................................................62.2.5 – Le simulateur.......................................................................................................................7

2.3 – Diagramme de classe...................................................................................................................72.4 – Principe de l'observateur.............................................................................................................8

3 – Algorithme de simulation....................................................................................................................94 – Manuel de l'utilisateur.......................................................................................................................10

4.1 – Construire un simulateur...........................................................................................................104.2 – L'interface console.....................................................................................................................134.3 – L'interface graphique.................................................................................................................13

5 – Test.....................................................................................................................................................165.1 – Diagramme de validation 1 : le chronomètre............................................................................175.2 – Diagrame de validation 2..........................................................................................................185.3 – Diagramme de validation 3 : TestActions.................................................................................185.4 – Diagramme de validation 4: les feux clignotants......................................................................18

6 – Conclusion.........................................................................................................................................19

3

4

1 – Introduction

1.1 - Objectif

L'objectif de ce projet est de simuler des diagrammes d'état, plus précisément d'afficher les évènements qui se produisent au cours de la simulation et les interactions correspondantes. Une interface graphique sera également définie.

1.2 – Choix de conception

Pour ce projet, les ensembles d'éléments sont implantés par le type “Vector”. Ce choix est dû au fait qu'il s'agit d'une collection facilement manipulable et disposant de nombreuse méthodes très utiles. De plus, il n'est pas nécessaire de s'occuper du nombre d'élements contenu dans un vector. Lorsque la capacité maximale est atteinte, un nouveau vector de taille supérieure est automatiquement généré.

De plus notre stratégie d'implémentation du diagramme part du niveau hiérarchique le plus élevé (super état englobant) pour descendre jusqu'aux états normaux; c'est à dire que ces derniers ne sont pas informés des états hierarchiquement supérieurs.

2 – Analyse

2.1 – Diagramme de cas d'utilisation

5

2.2 – Description des différents objets

2.2.1 – Les états

Dans un premier temps, il a été nécessaire de rechercher les caractéristiques communes aux états dits normaux (“EtatNormal”) et aux super états (“SuperEtat”). Ainsi, il est possible de factoriser dans une classe abstraite “Etat” les attributs nom (“String”), actions en entrée, en sortie et actions internes (“Action”).

Un état doit également connaître les transitions dont il est la source, ce qui ajoute un attribut commun.

Ce qui distingue un super état d'un état normal est le fait qu'un super état doit posséder la liste des états initiaux et des états actifs à un instant donné.

Dans un second temps, il a fallu voir quelles étaient les méthodes utiles à ces classes et si possible de les factoriser dans Etat.

Ainsi, il s'est avéré que pour faciliter la construction d'un état, les méthodes ajouterActionsX1 et ajouterTransition étaient nécessaires. Il doit être également possible “d'exécuter” les différentes actions. D'où les méthodes executerActionX.

SuperEtat possède 4 méthodes qui lui sont spécifiques. franchir sera décrite en détail dans la section Algorithme de simulation, initialiser permet de remettre les états actifs à leur valeur initiale, choixUtilisateur est utilisé lorsqu'un indéterminisme est détecté lors de l'execution de franchir, et enfin ajouterEtatInitial ajoute un état initial à l'ensemble correspondant.

Il y a bien sûr les accesseurs aux attributs et les constructeurs qu'il est possible de factoriser dans Etat.

2.2.2 – Les transitions

Une “transition” étant attachée à un état, il n'est pas nécessaire qu'elle connaisse son état source. Elle est donc caractérisée seulement par son état cible, les actions qu'elle peut générer lors de son franchissement et les évènements (“Evenement”) nécessaires à sa validation.

Concernant les méthodes, elles sont principalement constituées d'accesseur aux attributs, et de méthode facilitant la construction d'une transition, AjouterActions, AjouterEvenement. La méthode la plus interressante est estFranchissable qui à partir d'un ensemble d'évènements indique si la transition est franchissable ou non.

2.2.3 – Les évènements

Il s'agit de la classe la plus simple du projet, un évènement est définie entièrement par son nom.

2.2.4 – Les actions

Une action pouvant générer un ou plusieurs évènements, elle possède comme attribut, en plus de son nom, un ensemble d'évènements. La méthode appliquerAction ajoute le contenu de l'attribut des ensembles des évènenements à un autre ensemble passé en argument.

2.2.5 – Le simulateur

“Simulateur” est la classe hiérarchiquement la plus haute. Elle contient l'ensemble des évènements en cours qui seront utilisés durant l'appel à la méthode simuler ainsi que l'ensemble des évènements qui seront disponibles au prochain appel de simuler. C'est ce dernier ensemble que prend en argument appliquerAction vu précédemment.

1 X représente type de l'action: onEntry, onExit, interne.

6

Un simulateur possède également comme attribut un super état correspondant au diagramme.

2.3 – Diagramme de classe

A noter la présence d'une classe “EtatInitial” quasi identique à “EtatNormal”. Celle-ci est en fait un élément de sécurité. Un super état doit forcément posséder un ou plusieurs états initiaux.

7

Illustration 1: Diagramme de classe du package diagramme

2.4 – Principe de l'observateur

L'observateur a pour but d'afficher des informations soit sur une console ou soit via une interface graphique.

Le principe est simple. Un observateur observe un observable auprès duquel il est inscrit. Dans notre cas, un observable est un super état ou un simulateur. Ainsi dès que l'observable effectue une action qui intéresse l'observateur, il l'avertit en lui envoyant les informations nécessaires.

Les 2 méthodes Actualiser permettent d'indiquer qu'une transition a été franchie et qu'un état est actif. L'une renvoie le couple “transition franchie – etat source”, et l'autre un état dont aucune transition n'est franchissable, mais qui est actif.

AvertirDebut et AvertirFin permettent de prévenir les observateurs respectivement qu'un pas de simulation va être lancé et qu'un pas de simulation est terminé.

3 – Algorithme de simulationRemarques préliminaires:

– la méthode franchir dépend du type de l'état l'appelant. Ansi, appelée par un super état, elle va s'appliquer à tous les états actifs; appelée par un état normal, elle executera les actions internes, et enfin appelée par un état initial, elle ne fera rien.

– La méthode initialiser dépend également du type

L'algorithme commence dès le lancement de la méthode simuler qui appelle en fait la méthode franchir du super état associé au simulateur. Le super état va alors prendre un par un les états actifs qui le compose et vérifier s'ils est possible de franchir une des transitions associées à cet état. S'il n'y a pas indéterminisme, l'état actif en cours d'analyse va alors être remplacé par la cible de la transition possible. S'il n'y a aucune transition possible, on applique alors franchir à l'état. S'il y a

8

Illustration 2: Diagramme de classe du package observateur

indéterminisme, le choix de l'utilisateur est alors demandé.

public void franchir(Vector<Evenement> EvenementsCourants,Vector<Evenement> EvenementsSuivants) {

// On parcourt la liste des états actif du super étatfor (Etat e : etatsActifs) {

// On récupère l'ensemble des transitions franchissables.Vector<Transition> franchissables = e.transitionsFranchissables(EvenementsCourants);

// Si le nombre de transitions franchissables est...

// ... égale a 1, on remplace le vecteur actif courant par la // cible de l'unique transition possible.if (franchissables.size() == 1) {

// On récupère l'unique transition possible.Transition choix = franchissables.firstElement();// On remplace l'état actif en cours par la cible e de // cette transition.remplacerEtatActif(e, choix.getEtatCible());// Si e est un super état, on le réinitialise après // l'avoir franchi.choix.getEtatCible().initialiser(EvenementsSuivants);// On execute les actions onEntry de l'état cible, les // actions onExit de e, ainsi que les actions associées// à la transition.executerActions(e, choix, EvenementsSuivants);// On avertit les observateurs du super état qu'il y a // eu une changement.notifierObservateur(new CoupleET(e, choix));

}

// ... supérieur à 1, c'est qu'il y a indeterminisme. Il faut// demander à l'utilisateur de choisir sa transition.else if (franchissables.size() > 1) {

Transition choix = choixUtilisateur(e, franchissables);// On reprend le même déroulement que précédemment.remplacerEtatActif(e, choix.getEtatCible());choix.getEtatCible().initialiser(EvenementsSuivants);executerActions(e, choix, EvenementsSuivants);notifierObservateur(new CoupleET(e, choix));

}

// ... égale a 0, il y a alors deux cas possibles selon le // type de e. Soit e est un super etat et franchir parcourera // ses etats internes,soit e est un etat normal auquel cas // franchir executera simplement les actions internes.

else if (franchissables.isEmpty()) {e.franchir(EvenementsCourants, EvenementsSuivants);notifierObservateur(e);

}}

}

9

4 – Manuel de l'utilisateur

4.1 – Construire un simulateur

Voici l'ensemble des informations nécessaires pour modéliser un diagramme. Les différents éléments de celui-ci sont presentés dans un ordre logique, et il est conseillé de suivre cet ordre lors du codage.

1.Création des états normaux.

Il est tout d'abord nécessaire de déclarer l'ensemble des états composants le système. Attention, il ne s'agit ici que de déclarer les ETATS NORMAUX, ce qui exclut les super états ainsi que les états initiaux, mais pas les états normaux interne à un sous état. Le seul paramètre à fournir au constructeur est le nom de l'état:

Etat arret = new EtatNormal("Arret");

2.Création des états initiaux.

Il est temps à présent de déclarer les états initiaux. La déclaration est la même que pour un état normal, seul le type change bien entendu:

Etat etatInitial1 = new EtatInitial("i1");

3.Création des super états intérieurs et ajout de leurs états initiaux.

Pour implanter les super états, il faut commencer par les déclarer. La procedure est la même que pour les autres types d'états:

SuperEtat marche = new SuperEtat("Marche");

Il faut à présent ajouter les états initiaux:

marche.ajouterEtatInitial(etatInitial2);

Le nombre d'état initiaux ajoutables n'est pas limité, si ce n'est par la mémoire.

4.Création des évènements.

Il faut à présent coder les évènements, c'est à dire les “conditions” potentiellement utilisables pour une transition ou par une action. Le seul paramètre à donner est le nom de l'évènement.

Evenement evTop0 = new Evenement("Top0");

Attention: la reconnaissance d'un évènement se fait par son nom, il sera donc nécessaire de taper le nom exact de l'évènement pour l'activer via l'interface graphique. Ainsi, pour activer l'évènement de l'exemple ci-dessus dans l'interface graphique, il sera nécessaire de taper Top0, et non top0 ou autre chose.

5.Création des transitions et ajout de leurs contraintes.

10

Une transition se construit grâce à son état cible (qui peut être soit un état normal, soit un super état):

Transition tArretMarche = new Transition(marche);

Une fois cela fait, on peut alors y ajouter des conditions sous forme d'évènements, dont le nombre n'est limité que par la memoire :

tArretMarche.ajouterEvenement(top0);

6.Ajout des transitions aux états.

Nos transitions sont maintenant en place, cependant si elles ont leur point d'arrivée, elle n'ont pas encore leur point de depart. Il est donc necessaire d'informer les états de la présence des transitions:

arret.ajouterTransition(tArretMarche);

Les deux états arret et marche sont à présent liés par la transition tArretMarche. Attention à ne pas oublier les transitions partant des états initiaux (ni d'oublier de déclarer les dites transitions lors des declarations)!

7.Création et ajout des actions.

Pour terminer la reproduction du diagramme, il ne nous manque plus que les actions exécutées par les transitions et les états.

Action leverTop0 = new Action("Top0");

Précisons maintenant l'évènement à activer:

leverTop0.ajouterEvenement(evTop0);

Finalement, on attache l'action soit à une transition, soit à un etat. Voyons tout d'abord la transition:

tArretMarche.ajouterAction(leverTop0);

Il existe trois facons d'attacher une action à un etat. Premièrement, l'action on entry: l'action sera executée lors l'activation de l'état:

marche.ajouterActionOnEntry(leverTop0);

Deuxièment, on peut ajouter l'action en tant qu'action interne. L'action sera executée tant que l'état sera actif, et que les conditions stipulées en deuxième paramètre (sous forme de vector d'évènements) sont verifiées (on a choisit ici un vector de conditions vide, ce qui veut dire que l'action sera executée tant que l'état sera actif):

arret.ajouterActionInterne(leverTop0, new Vector<Evenement> ());

Finalement, on peut ajouter l'action on exit, c'est à dire que l'action sera exécutée à la sortie de l'état:

marche.ajouterActionOnExit(leverTop0);

8.Finaliser l'initialisation du graphe.

11

Pour finir, il faut maintenant créer un super état englobant notre diagramme:

SuperEtat diagramme = new SuperEtat ();

Puis on l'initialise avec l'état initial de notre diagramme:

diagramme.ajouterEtatInitial(etatInitial1);

On crée ensuite le simulateur que l'on initialise avec notre Super Etat englobant:

Simulateur sim = new Simulateur(diagramme);

4.2 – L'interface console

Afin de disposer de l'interface console, il est nécessaire d'ajouter un observateur “AfficherConsole“ à tous les super états et au simulateur. L'utilisateur visualise alors les informations de la manère suivante:

>>>> Duree de la simulation : 12Evenement = *Aucun*Transitions franchies : [H4 --()--> H5]

>>>> Duree de la simulation : 13Evenement = *Aucun*Transitions franchies : [H5 --(/^Top0)--> H0]**** Occurence de l'evenement = Top0

>>>> Duree de la simulation : 14Evenement = [Top0]Transitions franchies : [H0 --()--> H1 | Su0 --()--> Su1]

4.3 – L'interface graphique

Afin de disposer de l'interface graphique, il est nécessaire d'ajouter, en premier, à tous les super états et au simulateur un observateur de type “UI2” , d'initialiser le simulateur, et enfin de rendre visisible la vue.

UI vue = new UI(sim);sim.ajouterObservateur(vue);diagramme.ajouterObservateur(vue); // Différents

compteur.ajouterObservateur(vue); // super

chronometre.ajouterObservateur(vue); // états

marche.ajouterObservateur(vue); // !sim.initialiser();vue.setVisible(true);

Attention: il est important d'ajouter une inferface graphique au système afin de pouvoir gérer les indéterminismes.

2 Pour User Inferface.

12

Lorsque la vue apparaît, l'utilisateur voit alors 4 listes et 6 boutons :

– Etats du système: répertorie tous les états présent dans le diagramme, excepté les états initiaux.

– Etats actifs: répertorie tous les états actifs à une durée de simulation précise.

– Transition franchies: historique de toutes les transitions franchies depuis le début de la simulation. L'affichage est semblable à celui effectué par un observateur AfficherConsole. Par confort d'affichage, la dernière ligne est toujours visible.

– Evenements: liste tous les évènements courants à une durée de simulation précise.

– Ajouter evenement: ajoute à la liste des évènements courants l'évènement ayant comme nom le nom saisi dans la zone texte situé juste au dessus.

– Supprimer evenement: permet de supprimer l'évènement sélectionner dans la liste Evenements.

– Simuler pas a pas: permet de faire avancer la simulation d'une durée.

– Simuler: fait avancer la simulation d'une durée de façon continue, toutes les secondes. Il suffit de recliquer pour stopper la simulation.

– R.A.Z: remise à zéro du simulateur.

– Quitter: quitter le programme.

Lors d'un indéterminisme, une pop-up apparaît invitant l'utilisateur à choisir la transition à valider. Par défaut la première transition est choisie.

13

Illustration 3: interface graphique

5 – TestEn plus des tests Junit, il a été nécessaire de tester notre application sur différents digrammes.

5.1 – Diagramme de validation 1 : le chronomètre

14

Illustration 4: Une pop-apparaît lors d'un indéterminisme

Ce test permet de vérifier que l'emboîtement de plusieurs super état fonctionne correctement. Grâce à la simulation continue de la vue graphique, il s'avère que ce diagramme fonctionne sans problème.

5.2 – Diagrame de validation 2

Ce diagramme a pour objectif de vérifier que la priorité des transitions est vérifiée. Aucun problème

15

Illustration 5: Diagramme d'état 1

Illustration 6: Diagramme d'état 2

n'est à signaler. Lorsque l'évènement S apparaît, l'état 1 devient bien actif.

5.3 – Diagramme de validation 3 : TestActions

Ce diagramme a pour but de vérifier que les actions onEntry et onExit sont bien éxécutées au bon moments. Pour le vérifier, nous avons imposé des conditions aux transitions qui ne sont réalisées que lors de la sortie ou de l'entrée d'un état.

5.4 – Diagramme de validation 4: les feux clignotants

Remarque: en raison de la complexité du diagramme d'état des feux clignotants, celui-ci ne figure pas sur ce rapport.

Le fonctionnement de cette interface est le même que celui de la simulation continue de l'interface générale, mais actualisé toutes les 200ms.

Afin de savoir quand changer les images représentant les feux, à chaque pas de simulation, un test sur les états actifs est réalisé. Voici un extrait de code:

if(e.getNom().equals("EteintG") || e.getNom().equals("InactifG")){

jFeuGauche.setIcon(new javax.swing.ImageIcon(getClass().getResource("clignotant2.png")));

}

else if(e.getNom().equals("AllumeG")){

jFeuGauche.setIcon(new

16

Illustration 7: Interface graphique spécifique du clignotant

javax.swing.ImageIcon(getClass().getResource("clignotant.png")));

}

6 – ConclusionCe projet avait d'interressant qu'il nous a permis de voir l'importance de l'analyse d'un sujet

avant de se lancer dans le code proprement dit. En effet, une fois le diagramme de classe réalisé, une grosse partie du projet était faite. Nous avons ensuite rencontrés des difficultés lors du codage. Il nous a fallu voir comment fonctionnait un timer afin de pouvoir réaliser proprement la simulation continue, c'est à dire sans utiliser de boucle while. De plus, nous avons approndis nos connaissances concernant les jFrame, les jDialog et les jList. Notre plus gros problème a été de savoir comment “arrêter” la simulation lors d'un indéterminisme et de la relancer lorsque l'utilisateur a choisi sa transition. C'est ainsi que nous avons réalisé que c'est ce qu'effectuaient les jDialog. Ainsi ce sont beaucoup de petits détails comme celui-ci qui nous ont fait progresser.

De plus, il s'agissait de notre premier projet en groupe. Il a fallu s'organiser méthodiquement afin que chacun puisse apporter sa contribution au projet sans à avoir à attendre le travail d'un partenaire. Travailler à plusieurs est un avantage, il y a toujours un membre du groupe qui a une idée à proposer et à laquelle aucun n'autre n'avait pensé.

17