TECHNOLOGIE OBJET RAPPORT DU PROJET LONG LANGAGE : JAVA ANIMATION DE DIAGRAMMES D ETAT.

École Nationale Supérieure d Électrotechnique, d Électronique, d Informatique, d Hydraulique et des Télécommunications. TECHNOLOGIE OBJET RAPPORT DU PROJET LONG LANGAGE : JAVA ANIMATION DE DIAGRAMMES D ETAT. Fait par : EL MAHI Moncef. SLIMANI Rajae BENSAID Mouad. Encadré par : Mr PANTEL Marc. Mr Navarro Emmanuel. Mr Gasparini Simone. 14 juin 2014

Sommaire 1 Introduction...................................... 3 1.1 Présentation des diagrammes d états transitions.................... 3 1.1.1 Description des diagrammes d états :...................... 3 1.2 Objectifs du projet.................................... 4 1.3 Cahier des charges.................................... 4 1.4 Organisation du travail.................................. 5 2 Modélisation du simulateur de diagrammes d états-transitions........ 6 2.1 Démarche de la construction de notre modèle..................... 6 2.1.1 Action....................................... 6 2.1.2 Evènement.................................... 6 2.1.3 Transition..................................... 6 2.1.4 Etat........................................ 6 2.1.5 EtatSimple.................................... 6 2.1.6 EtatAbstrait................................... 7 2.1.7 EtatExcecutable................................. 7 2.1.8 EtatConcurrent.................................. 7 2.1.9 EtatOU...................................... 7 2.1.10 Simulateur.................................... 7 2.1.11 SimulateurAbstrait................................ 8 2.2 Diagramme de classe................................... 8 3 Programmation du simulateur de diagrammes d état.............. 9 3.1 Choix de conception et raffinages............................ 9 3.1.1 nextstep de la classe EtatAbstrait....................... 9 3.1.2 nextstep de la classe EtatAbstrait....................... 10 4 Interface textuelle................................... 11 5 Interface graphique générique............................ 12 5.1 Cas d utilisation..................................... 12 5.2 Ergonomie......................................... 12 6 Test : Interface graphique spécifique simulant le comportement d un feu clignotant............................................ 14 6.1 Description........................................ 14 6.2 Démarche......................................... 14 6.2.1 Remarques.................................... 14 6.3 Diagramme........................................ 15 6.4 Construction du diagramme............................... 15 6.5 Simulation à travers l interface textuelle........................ 15 6.6 Simulation à travers l interface graphique SWING.................. 17 7 Tests de l interface graphique générique sur l exemple de la figure 6..... 18 1

SOMMAIRE 2 8 Diagrammes de validation.............................. 20 8.1 Diagramme de validation 1............................... 20 8.2 Diagramme de validation 2............................... 20 9 Répartition des tâches................................ 21 10 Manuel utilisateur................................... 22 11 Conclusion....................................... 23

1 Introduction 1.1 Présentation des diagrammes d états transitions 1.1.1 Description des diagrammes d états : Définition Un diagramme d états (appelé aussi diagramme d état-transitions) décrit le comportement des objets d une classe au moyen d un automate d états associés à la classe. Le comportement est modélisé par un graphe, ce graphe est constitué de Noeuds, ces derniers représentent les états possibles des objets. Et aussi, de transitions d état. Une transition est une action ou une réaction de l objet sous l effet d une occurrence d événement. Un diagramme d états peut être aussi defini comme une description du cycle de vie d un objet d une classe. En effet : Les états qui peuvent être pris par les objets d une classe. Les événements qui provoquent la transition d un état à un autre. Les actions subies ou provoqués qui accompagnent un changement d état. Les activités qui surviennent tant que l objet est dans un état donné. Maintenant, on passe à la définition de chaque composantes du diagramme : On commence par la notion d état. Un état est une étape dans le cycle de vie d un objet. Chaque objet possède à un instant donné un état particulier. Chaque état est identifié par un nom.de plus, il est stable et durable. Chaque diagramme d états transitions comprend un état. Remarques : Il est possible de n avoir aucun état final (exemple d un système qui ne s arrête jamais). Pour la notion de transitions : Les états sont reliés par des connexions unidirectionnelles appelées transition. Concernant la notion d événement, en fait : Un événement correspond à l occurrence d une situation donnée dans le domaine étudié. Un évènement est une information instantanée qui doit être traitée à l instant où il se produit. 3

1. INTRODUCTION 4 On peut décrire un événement par : Son nom. Sa liste de paramètres. Son objet expéditeur. Son objet destinataire. Sa description textuelle. Remarque : La communication entre objets par évènements est de type asynchrone, atomique et unidirectionnelle. En résumé Etat d un objet : Situation d un objet que l on désire connaître et gérer. Transition : Passage d un objet d un état à un autre. Elle est déclenché par un évènement. Evènement : Stimulus qui provoque une (ou plusieurs) transition(s). A chaque stimulus peut correspondre une action responsable des modifications de l objet. Pour la notion de Garde : Une garde est une condition booléenne qui permet ou non le déclenchement d une transition lors de l occurrence d un évènement. 1.2 Objectifs du projet 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.3 Cahier des charges Le projet doit respecter un cahier des charges qui définit les contraintes de réalisation suivantes : Le projet est à effectuer en groupe de trois personnes Il faut une organisation professionnelle afin de pouvoir avancer vite et rendre un travail de qualité. La démarche de notre organisation vous sera présent dans une section suivante. Le projet doit fonctionner sans aucune modification sur les machines LINUX des salles de TP du 2eme étage du batîment C de l ENSEEIHT. Les principes énoncés en cours et étudiés en TD et TP doivent être respectés lors de la réalisation de ce projet.

1. INTRODUCTION 5 Les divers outils vus en TOB devront être utilisés s ils peuvent être utiles pour la réalisation du projet. Nous devons disposer d un algorithme qui permet d effectuer toutes les fonctions escomptées tout en prenant en compte la complexité temporelle et spatiale. Ces fonctions doivent être compréhensible par l utilisateur et doivent prendre des paramètres que cet utilisateur peut entrer facilement (soit sur un terminal : ce qu on faisait jusqu à présent) ou via une interface graphique (Ce qu on va développer au cours de ce projet). 1.4 Organisation du travail Dès la publication du projet et la constitution des groupes, on a décidé de nous réunir afin de nous organiser et de répartir les tâches à faire pendant les vacances. à la fin de cette réunion, un chef du projet a été désigné dont la mission est de surveiller la progression du projet, le respect des Deadlines, la communication entre les membres du groupe et l information du professeur encadrant de la progression du travail ainsi que les prévisions des tâches à effectuer pour la semaine suivante. Pour la communication entre les membres du groupe, on a décidé de créer un groupe privé sur Internet nous permettant un échange instantané dans le cas de difficultés rencontrées par un membre. On a fixé des crénaux de travail individuel et collectif : Les créneaux de travail individuel nous permettent de réaliser les tâches individuelles. Les créneaux de travail collectif nous permettent de nous réunir afin de discuter de la progression du projet et de réunir les tâches faites tout en veillant à ce que le travail rassemblé soit cohérent avec la vision globale souhaitée et avec les contraintes fixées par le cahier des charges fonctionnel. Ceci est réalisé avec un calendrier gnatt chart :

2 Modélisation du simulateur de diagrammes d états-transitions 2.1 Démarche de la construction de notre modèle On va vous décrire dans les sous paragraphes qui suivent les choix réalisés dans la conception et l implémentation de ce projet. 2.1.1 Action l interface Action hérite de l interface Runnable. une action est déclenchée généralement par un événement. Une interface qui hérite d une autre, pourquoi??? En effet, si on utilise directement Runnable, on n aura plus besoin de créer une classe ( ici Interface ) Action. Du coup, on peux simplement justifier ce choix par le fait qu on veut avoir Action à la place de Runnable. Pour finir, Cette classe va être realisée lors de la création du test. 2.1.2 Evènement C est une classe qui a comme attribut un nom, ce dernier caractérise chaque évènement. 2.1.3 Transition La classe transition possède : Un état source. Un état cible. Unn évènement. Et enfin une action. La méthode la plus importante est celle qui nous permet de franchir une transition : franchir. 2.1.4 Etat L Etat est une interface, qui sert principalement à factoriser trois méthodes, qui sont : activer. désactiver. nextstep(list Evenement ). 2.1.5 EtatSimple La classe EtatSimple hérite de la classe abstraite EtatAbstrait. 6

2. MODÉLISATION DU SIMULATEUR DE DIAGRAMMES D ÉTATS-TRANSITIONS 7 2.1.6 EtatAbstrait C est une classe qui implémente( réalise ) deux interfaces, la première Etat et la deuxième qui est Comparable EtatAbstrait. Pour les attributs, on a choisit une liste pour chaque type d action, En effet : On une liste d action en entrée de l état : onentryaction On une liste d action en sortie de l état : onexitaction On une liste d action interne a l état : inaction 2.1.7 EtatExcecutable Cette classe hérite de la classe abstraite EtatAbstrait. Elle a deux méthodes de plus que la classe mère. Qui sont : ignorerfils. et reinitialiser. 2.1.8 EtatConcurrent La classe EtatConcurrent hérite de la classe abstraite EtatExecutable. Elle a comme attributs, une liste d états exécutables, qu on a appelé : régions. Elle a redéfinit toutes les méthodes qui se trouvent dans les classes mères. Plus, une méthode qui permet d ajouter une région à la liste de régions qu on avait. 2.1.9 EtatOU C est une classe qui hérite elle aussi de la classe abstraite EtatExecutable. Elle a comme attributs, une liste d états executables, qu on a appelé : fils. Elle a redéfinit toutes les methodes qui se trouvent dans les classes mères. Plus, une méthode qui permet d ajouter un fils dans la liste de fils qu on avait. 2.1.10 Simulateur Un simulateur est représenté par une interface qui permet de factoriser les méthodes, et de les spécifier. Les méthodes dont on a besoin ici sont : activer (EtatAbstrait) désactiver(etatabstrait) franchir(transition) ignorer( EtatAbstrait) indeterminisme(list Transition ) demarrer nextstep ajouterevenment(evenment) retirerevenment(evenment)

2. MODÉLISATION DU SIMULATEUR DE DIAGRAMMES D ÉTATS-TRANSITIONS 8 2.1.11 SimulateurAbstrait Le SimulateurAbstrait est une réalisation de l interface Simulateur. Et, qui est elle même censé être hérite par d autres classes afin de réaliser les simulations. Elle a comme attributs : une liste d états actifs. une liste de transitions franchises. un ensemble d evenments (pour eviter la redondonce). un ensemble d etats ignorés (sert a ignorer des états sans les desactiver). un état executable qui representra l entrée. Et dernièrement le pas de simulation. Maintenant, En ce qui concerne les méthodes. On réalise toutes les méthodes spécifiées dans l interdace Simulateur, Tout en ajoutant une méthode clearall qui permet de vider toutes les listes présentes dans la classe SimulateurAbstrait. 2.2 Diagramme de classe

3 Programmation du simulateur de diagrammes d état 3.1 Choix de conception et raffinages Par souci d efficacité, on ne décomposera que les méthodes dont l alorithme est un peu complexe, on évitera ainsi de raffiner les méthodes dont l algorithme est licite. 3.1.1 nextstep de la classe EtatAbstrait a Méthode : nextstep() Sémantique : cette méthode passe à l état suivant en éxécutant les événements liés à l état en cours. Paramètres : environnement : List Evenement Préconditons : aucunes Postconditions : L état est passé à l état suivant R0 : Passer à l état après avoir exécuté les événements liés à l état en cours R1 : (*Passer à l état après avoir exécuté les événements liés à l état en cours*) Définir une liste de transitions franchissables ; Franchir les transitions franchissables ; R2 : (*Définir une liste de transitions franchissables *) Structure de contrôle : Pour... faire, Si... alors.. sinon Pour tout chaque événement de l environnement a Si la transition associée à cet événement appartient à l état alors a L état est rajouté à la liste des états franchissables ; a Sinon rien ; Fin pour ; (*Franchir les transitions franchissables*) Structure de contrôle : Si... alors.. sinon S il existe des transitions franchissables alors a Désactiver l état a S il existe plusieurs transitions franchissables alors a Traiter le cas d indéterminisme a Sinon a Franchir la transition ; Rajouter la transitions à la liste des transitions franchies dans l environnement du Simulateur ; a Fin si ; Fin si ; 9

3. PROGRAMMATION DU SIMULATEUR DE DIAGRAMMES D ÉTAT 10 3.1.2 nextstep de la classe EtatAbstrait a Méthode : nextstep() Sémantique : cette méthode permet de passer un l étape suivante lors de la simulation Paramètres : Préconditons : aucunes Postconditions : Le simulateur est passé à l état suivant R0 : Passer à l étape suivante lors de la simulation. R1 : (*Passer à l étape suivante lors de la simulation*) Incrémenter le pas de la simulation et réinitialiser la liste des événements, des transitions franchies et des états actifs ; R2 : (*Incrémenter le pas de la simulation et réinitialiser la liste des événements, des transitions franchies et des états actifs *) pas pas+1 ; copieevenements evenements ; copieetatsactifs etatsactifs ; Passer à l état suivant ; R3 : (*Passer à l état suivant*) Structure de contrôle : Pour... faire, Si... alors.. sinon Pour tout les états actifs faire a Si l état en cours n est pas ignoré alors a On passe à l état suivant en exécutant les événements liés à cet état ; a Sinon rien ; Fin pour ;

4 Interface textuelle La classe SimulateurTextuel hérite de la classe abstraite SimulateurAbstrait, qui elle même implémente(ou réalise) l interface Simulateur. Dans cette classe on commence par la redéfinition de la méthode démarrer qui a comme but principal d afficher les états actifs, la durée de simulation, la liste des événements et les transitions franchises. Tout en appellant la méthode démarrer de la classe mère. On a aussi redéfinie la méthode nextstep de la même manière que la méthode démarrer. l indéterminisme hérite quant à lui directement de la classe Simulateur. Elle propose à l utilisateur la liste des transitions possibles. Et permet de franchir la transition choisie par l utilisateur. Pour résumer, la classe SimulateurTextuel est créée uniquement pour effectuer l affichage souhaité à chaque simulation et qui correspond à l affichage donné dans l énoncé. En tenant compte de l indeterminisme s il y en a. 11

5 Interface graphique générique 5.1 Cas d utilisation avec détails sur les bouttons simuler et pas à pas. 5.2 Ergonomie Les deux figures suivantes présentent l interface graphique générique de l application qui permet la simulation des diagrammes d état : Pour organiser au mieux cette interface, notre choix s est porté sur une barre de menu contenant les principales fonctionnalités (Fichier Quitter l application,? A propos et le manuel utilisateur ), ensuite on a mis deux onglets : Diagramme et Evenement : Le premier donne à l utilisateur la possibilité de visionner le diagramme sous forme d un arbre JTree (Jpanel n1), le (Jpanel n2) permet d afficher la liste des transitions franchies JList et le (JPanel n3) permet d afficher l occurence d un évènement. Le second onglet contient la liste d évènements à engendrer. On sélectionne les évènements qu on souhaite déclencher et on les ajoute à la liste des évènements à déclencher au TOP SUIVANT, de même on peut retirer un évènement de la liste des évènements prévus au TOP SUIVANT. On a bien veillé à ne pas permettre l ajout du même évènement plus d une fois à la liste des évènements à déclencher. En ce qui concerne la partie en bas, on un Jlabel qui affiche le numéro du pas de simulation, un bouton démarrer qui devient simuler quand la simulation est lancée et qui permet d effectuer la simulation pas à pas, un 2 ème bouton démarrer qui à son tour devient simuler quand la simulation commence et qui permet la simulation en continu du diagramme d état, un bouton pause qui permet de suspendre la simulation, un bouton réinitialiser qui permet de remettre à zéro la simulation et finalement un bouton quitter qui permet de quitter l application. 12

5. INTERFACE GRAPHIQUE GÉNÉRIQUE 13 Dans le cas d indéterminisme, une fenêtre s ouvre et invite l utilisateur à choisir entre une transition parmi la liste des transitions franchissables. On n a pas encore réussi à le faire, c est pourquoi, on tâchera à vous présenter ce cas le jour des tests.

6 Test : Interface graphique spécifique simulant le comportement d un feu clignotant 6.1 Description 6.2 Démarche Il s agit tout simplement de changer la vue par rapport à l interface générique, j ai par conséquent programmer les boutons de telle sorte qu ils engendrent des évènements puis j effectue une simulation en continu. L interface graphique contient la photo arrière d une voiture et un ensemble de boutons : Le bouton permet de déclencher le feu gauche. Le bouton permet de déclencher le feu droit. Le bouton détresse permet de déclencher les feux de détresse. Le bouton AF qui permet d arrêter les feux. Et le bouton quitter qui permet de fermer l application. 6.2.1 Remarques Par manque de temps, on a utilisé le diagramme de la figure 6 pour simuler le fonctionnement des feux clignotant. Par conséquent, il faut obligatoirement passer par le bouton AF si on veut passer du feu droit au feu gauche ou vice versa. On peut interprété ça par le fait que le conducteur passe par l état intermédiaire. (le bras dans son état normal) pour basculer d un état à un autre. Par contre pour les feux de détresse, ils ont un fonctionnement normal, pour les activer, on appuie sur le bouton détresse, et pour les désactiver, on réappuie sur le même bouton. 14

6. TEST : INTERFACE GRAPHIQUE SPÉCIFIQUE SIMULANT LE COMPORTEMENT D UN FEU CLIGNOTANT 15 6.3 Diagramme 6.4 Construction du diagramme La construction du diagramme commence par lister l ensembles des états simples, des états concurrents et des super états, on passe par la suite à la définition des évènements, des transitions entre les états et l affectation des actions associées à chaque transition.et enfin on n oublie pas de déclarer tous les fils auprès de leur père (superétat). 6.5 Simulation à travers l interface textuelle A chaque pas, le simulateur textuel propose à l utilisateur s il veut ajouter un événement à l environnement. Si c est le cas, l événement est rajouté à l environnement et déclenché lors du prochain pas de la simulation.

6. TEST : INTERFACE GRAPHIQUE SPÉCIFIQUE SIMULANT LE COMPORTEMENT D UN FEU CLIGNOTANT 16

6. TEST : INTERFACE GRAPHIQUE SPÉCIFIQUE SIMULANT LE COMPORTEMENT D UN FEU CLIGNOTANT 17 6.6 Simulation à travers l interface graphique SWING La photo qui suit montre la vue choisie pour tester le fonctionnement des feux clignotants. On a rencontré quelques difficultés pour définir un intervalle au bout duquel les actions se répètent, par conséquent, on a contacté d autres groupes qui nous ont proposé l utilisation d un timer, malheureusement, on n a pas réussi à l inclure dans notre interface. on a été dans l obligation de nous adresser envers des élèves de deuxième année qui nous initier à la notion des threads. On n a pas utiliser la notion pour faire plusieurs taches au même moment, mais on a contourner la notion pour obtenir du chronométrage.

7 Tests de l interface graphique générique sur l exemple de la figure 6 18

7. TESTS DE L INTERFACE GRAPHIQUE GÉNÉRIQUE SUR L EXEMPLE DE LA FIGURE 6 19

8 Diagrammes de validation 8.1 Diagramme de validation 1 Pour le premier diagramme de validation, on a trouvé un petit problème qu on a résolu par la suite. Quand on ajoute l événement A à l environnement le fils reste actif et par conséquent on ne passe pas à l état 1, on avait déjà pensé à ce problème lors de la conception, mais dans le cas où les événements sont différents. 8.2 Diagramme de validation 2 Pas de problèmes majeurs. 20

9 Répartition des tâches Après la séance du premier retour avec le professeur encadrant, le groupe s est réuni afin d apporter des modifications sur le diagramme UML comme a été suggéré. En effet, lors du premier rapport le diagramme était incomplet, on a donc mené une analyse plus approfondie et une réflexion sur l architecture du code qui a fait qu on a apporté les modifications nécessaires. Après s être mis d accord sur le diagramme UML final, ainsi que le patron de conception général, les tâches on été réparties comme suit : Conception du modèle et son implantation : Rajae SLIMANI et Mouad BENSAID Conception de la vue (Interfaces graphiques) et intégration avec le simulateur : Moncef EL- MAHI Exemples de test : tout le groupe, on a essayé de faire plusieurs exemples du plus basique au plus compliqué afin de tester tout les critères demandés. Rapport final : tout le groupe, chacun a expliqué la partie qu il a effectué après concertation avec le groupe. Au fur et à mesure de l avancement du projet, lorsque un membre du groupe rencontrait une difficulté (des problèmes de débuggages par exemples..), tout le groupe intervenait pour résoudre le problème afin de veiller à ce que le projet évolue parallèlement et ne pas retarder l exécution des tests. Nous sommes convenu à ce qu on s accorde des deadlines pour la réalisation de chaque partie (elles varient selon la complexité de la partie ainsi que la priorité de celle-ci, cf GanttChart) que chacun s est engagé à respecté afin de gérer au mieux le temps attribué pour la réalisation du projet. 21

10 Manuel utilisateur Afin de simuler un diagramme d état prédéfini, veuillez suivre les étapes suivantes : 1. Le diagramme à simuler doit être implémenté en JAVA. 2. Définir l arborescence du diagramme : Rentrer les Super-Etats et les sous états correspondant en respectant la hiérarchie et l indentation. L arborescence vous permettra de mieux visualiser la simulation en conclure le bon déroulement de celle-ci. 3. Rentrer la liste des évènements contenue dans le diagramme. 4. Pour une simulation pas à pas : Cliquer sur le bouton simuler pas à pas. Sur l onglet Evènements, ajouter l événement que vous souhaitez exécuter (lister dans le champs Evènement à déclencher, l événement sera ainsi ajouté à l environnement d exécution. Vous le verrez apparaître dans le champ TOP suivant qui indique qu il sera exécuté au TOP suivant de l horloge. Revenir sur l onglet Diagramme, la transition franchie sera affichée dans le champs Transitions franchies. Faire de même pour le pas suivant. Le nombre de pas simuler est affiché en bas à droite de la fenêtre. 5. Pour une simulation en continue : Sur l onglet Evènements, ajouter l événement que vous souhaitez exécuter (lister dans le champs Evènement à déclencher, l événement sera ainsi ajouté à l environnement d exécution. Vous le verrez apparaître dans le champ TOP suivant qui indique qu il sera exécuté au TOP suivant de l horloge. Revenir sur l onglet Diagramme, cliquer sur le bouton Démarrer dans le champs En continu, les transitions franchies seront alors affichées au fur et à mesure. Si l on souhaite rajouter un événement, cliquer sur le bouton pause et suivez les même étapes d ajout que précédemment ensuite cliquez sur simuler. La simulation en continue alors va continuer en tenant compte de l événement ajouté. 22

11 Conclusion Le projet long était avant tout une bonne épreuve de travail de groupe qui nous a permis de mener une réflexion à la fois globale et partagée. A l issue, nous avons pu développer le sens d initiative, de critique et de prendre du recul sur les choix de conception. Partir de rien nous a aussi permis de mener une profonde réflexion, d établir une architecture propre et non imposée et donc de mieux cerner le problème afin de répondre au mieux aux critères imposés et choisir les solutions adéquates. La gestion du timing et la répartition des tâches étaient un grand apport personnel en terme d outil et de stratégie d organisation. En ce qui concerne l apport pédagogique, le projet a balayé à peu près toutes les notions vues en cours, ce qui était un bon exercice où l on a retravaillé les notions pour développer la maîtrise du langage de technologie objet. *** Fin *** 23