YAKINDU STATECHART TOOLS

Rapport

IFT3150 – PROJET INFORMATIQUE

HANIFA MALLEK

Sous la direction du Dr. Eugène SYRIANI

Avril 30, 2019 Table des matières

Introduction ………………………………………………… 2 1.1 Objectif ………………………………………………… 2 1.2 Motivation ……………………………………………………… 2 1.3 Terminologie ……………………………………………. 3 2 Analyse des besoins ……………………………………… 7 3 Méthodologie et approche adoptée ………………………. 8 4 Conception ………………………………………………... 8 5 Modélisation ……………………………………………... 9 5.1 Justification du choix de modélisation ………………………... 9 5.2 Stabilité et abstraction ………………………………………… 10 6 Design de la machine d’états ……………………………. 11 7 Implémentation …………………………………………. 14 8 Tests et documentation ………………………………… 16 8.1 Tests fonctionnels ……………………………………………. 16 8.2 Tests structurels ……………………………………………… 17 8.3 Documentation ………………………………………………. 19 9 Maintenance ……………………………………………. 19 9.1 Analyse d’impact des modifications sur le code fourni ……... 19 9.2 Maintenance du statechart …………………………………… 20 Conclusion ………………………………………………… 21 Remerciements ……………………………………………. 22 Bibliographie ……………………………………………… 23

Page 1

Introduction

Depuis les dernières décennies, nous remarquons un grand progrès quant à l’utilisation des patrons de conceptions dans le domaine du génie logiciel. Ceci permet de résoudre beaucoup des conflits rencontrés lors du développement, sauf que l’interaction entre les interfaces graphiques et l’application en question restent plutôt conflictuels car la GUI sera directement liée à l’API, ce qui n’est très recommandé. On y trouve beaucoup de couplage, les interfaces deviennent trop lourdes et interagissent beaucoup avec les méthodes internes de l’application. Pour résoudre ce conflit, une solution simple est mise au point. On utilise souvent la modélisation des problèmes par les machines d’état fini, ceux-ci peuvent aussi être utilisées pour interagir entre l’interface graphique et l’application.

1.1 Objectif

Pour permettre une meilleure souplesse de l’interface graphique et une réduction considérable du couplage entre celle-ci et l’application, la machine d’état va interagir avec l’application suivant chaque action faite par l’usager. La couche interface graphique reste superficielle, les méthodes propres à l’application vont être dans une couche de bas niveau de sorte que seul la machine d’état communique entre les deux couches respectives. Nous tentons d’introduire des machines d’état grâce à l’outil YAKINDU Statechart Tools (SCT). Nous avons choisi une application de gestion des voyages par différents moyens de transport afin de concrétiser la performance de l’outils YAKINDU SCT.

1.2 Motivation

Une machine d’état (statechart) est un langage de spécification qui permet de construire un modèle et de le vérifier. Cette implémentation permet d’encapsuler l’état de l’entité dans des classes séparées qui correspondent à l’état voulu. Distingué les évènement, gardes, actions, procédures d’entrées (entries procedures) et de sorties (exit procedure).

Page 2 La solution à cette motivation est modélisée dans le diagramme UML du patron des états suivant :

1.3 Terminologie

YAKINDU Statechart Tools (YAKINDU SCT) est un outil de spécification et de développement de systèmes réactifs, pilotés par les événements, à l’aide de machines à états finis. YAKINDU SCT est un outil utiliser pour l'édition graphique de diagrammes statistiques et fournit des générateurs de validation, de simulation et de code source pour diverses plates-formes cibles et langages de programmation. Toute interaction entre les machines d’états et les méthodes de l’application et vice versa est gérée par un contrôleur.

Page 3 Figure 4.2 The UCM architecture for user interface software

L’IDE est doté d’une perspective qui supporte la modélisation des machines d’états. Il est indispensable d’expliquer les différents termes de l’usage de YAKINDU SCT, certains sont en anglais et perdent leurs sens au recours à la traduction :

Contenu de la perspective de modélisation Modèle de la machine d’état (Statechart model) : est le modèle qui va loger la machine d’états. Le nom du fichier choisit a pour extension .sct, son format externe est un XML Metadata Interchange ou XMI, qui est un langage XML. L’IDE Eclipse est muni d’une perspective qui supporte la modélisation des machines d’états, celle-ci comporte les vues suivantes : • Explorateur de projet (Project Explorer) : Cette vue affiche l’espace de travail et peut également servir pour examiner la structure interne du modèle d'états. • Vue propriété : Dans celle-ci, les propriétés du modèle sont là.

Page 4 • Vue problème : Dans cette vue, on y voit les potentielles erreurs du modèle. • Vue tâche : Toutes les tâches à faire sont là. • Vue simulation : ’est une vue très utile, elle permet de montrer l’exécution de la machine d’état, et de voir la logique de conception. Aussi, on trouve la section de déclaration et la palette pour dessiner le modèle.

Éléments des machines d’états Ce sont des éléments essentiels à la modélisation, et on compte :

État : C’est l’élément central de la machine d’état. Il doit être placé dans une région, doit avoir un nom unique dans celle-ci. Lors de l’exécution, l’état est soit passif ou actif. Un état peut avoir un comportement qui spécifie quelle action est exécutée et sous quelle condition. Ces actions sont exécutées soit en entrant dans l’état ou en sortant suivant des gardes, un évènement temporel ou un évènement venant de l’extérieur (par exemple presser un bouton). La spécification du comportement de l’état est une instruction ou plusieurs (séparées d’un point-virgule) qui consiste en une série de réactions locales. État Idle : C’est l’état repos de la région qui est associé à l’entrée du statechert, une fois l’action effectuée la machine revient à cet état par une transitions définie. État composite : C’est un état qui peut contenir une seule région ou plusieurs pouvant être exécuter simultanément. États orthogonaux : Un état orthogonal est un état composite avec plus d'une région. Ces régions sont exécutées simultanément. Cependant, ce parallélisme n’est pas garanti dans les fonctionnalités actuelles de Yakindu SCT. C’est surtout un moyen de faire travailler deux ou plusieurs actions, mais ils sont exécutés les uns après les autres dans chaque cycle et dans un ordre défini: de haut en bas, de gauche à droite. Ceci est aussi applicable à plusieurs régions dans l'état même. Transition : Une transition permet le transfert d'un état source à un état cible. Elle est représentée sous la forme d'une flèche. Lorsqu'une transition est effectuée, l'état source n’est plus actif, il devient par conséquent passif et l'état cible devient actif.

Page 5 Une transition devrait avoir une réaction. La réaction d’une transition spécifie qu’elles sont les conditions pour que cette transition soit prise, et quelles actions doivent être exécutées lors de cette transition. L'occurrence d'un événement, le fait qu'une condition devienne vraie ou le temps qui passe peut déclencher une transition. La réaction de la transition est associée à la flèche de la transition sous forme de texte. Les points d’entrée : Pour démarrer une machine d’état, il est nécessaire d’avoir un point d’entrée. Si le modèle contient plusieurs régions, chaque région à son propre point d’entrée. Région : Les machines d’états sont organisées en régions, ce qui permet d’avoir plusieurs machines d’états dans différentes régions et de les exécuter simultanément. Les régions contiennent des états et des transitions. Interface : C’est une classe qui agit comme une interface permettant d’avoir la logique d’encapsulation. Elle contient l’état de l’entité actuelle qu’il soit élémentaire ou composite, les évènements, les variables ainsi que les opérations. Variable : Les variables doivent être définies dans une interface interne ou externe. Les variables de l'étendue interne ne sont visibles par aucun code client. Les variables définies dans une interface nommée doivent être référencées à l'aide du nom d'interface. Évènement : Un événement est très important, il se produit à un moment donné dans le contexte d'une machine à états (bouton cliqué, une période de temps écoulée, etc…). Un événement peut être internes (destinés uniquement à être générés et traités par la machine à états), externes (définis dans une étendue d'interface et sont entrants ou sortants et définis référencés à l'aide du nom de l'interface si celle-ci est nommée). Les événements peuvent être traités dans des déclencheurs. Opération : Une opération connecte une machine à états au monde extérieur (lire des données d'un capteur, engager un actionneur, etc.) en rendant le comportement externe accessible à la machine à états. Le logiciel client doit fournir un comportement tel que des fonctions ou des méthodes dans un langage de programmation pour que la machine à états peut interagir avec. Une opération est le

Page 6 moyen utilisé par le langage de l’état statistique pour appeler une telle procédure externe à partir du statechart. Les opérations peuvent avoir aucun, un ou plusieurs paramètres. Un paramètre est déclaré avec un nom et un type. Une opération peut avoir un type de retour unique ou nul similaire aux langages de programmation habituels. Générateur de code (CodeGenerator) : Outil qui transforme la machine d’état en un code source du langage de programmation cible. il est toujours valide, dans le sens où il correspond à la machine d’état modélisée Deep Java intégration : C’est une fonctionnalité qui a été mise en place récemment. Elle permet d’accéder au code Java depuis la machine d’état ce qui facilite l’intégration de celle-ci dans le processus de développement. Cependant, cette fonctionnalité est encore en version bêta.

2 Analyse des besoins

Le besoin initial était d’intégrer les machines d’états dans toute l’application, c’est-à-dire couvrir le côté administrateur et le côté client d’une part, et permettre le parallélisme de sorte que n’importe quel changement du côté administrateur se répercute sur le côté client instantanément d’une autre, mais vu l’ampleur du projet, il a été décidé de faire la partie administrateur, et de s’assurer ensuite que les machines d’états répondent aux tests unitaires.

Afin de permettre une mise en place de cette fonctionnalité, YAKINDU SCT était un choix idéal pour répondre aux différents aspects de cette application. Un dernier besoin à entrainer une maintenance au niveau de l’application fournie afin de réduire le couplage pour permettre une séparation totale entre l’interface graphique et le cœur de l’application. Seul le contrôleur permet l’interaction entre les deux.

Page 7 3 Méthodologie et approche adoptée

Avant de se lancer dans la conception de la machine d’état, nous avons suivi une méthodologie de travail. Pour ce projet nous avons opté pour un processus de développement itératif et incrémental permettant de tester le résultats obtenus à chaque fois qu’une nouvelle fonctionnalité a été ajoutée au niveau du modèle de machine d’états. La flexibilité de ce processus nous permet de s’assurer que la machine d’état répond bien aux besoins afin de faire les corrections le plus tôt. Nous avons eu recours à l’outil de modélisation UML 2.0 (un standard dans la modélisation dans le monde du développement logiciel) afin de comprendre l’application et de pourvoir procéder à l’unification des fonctionnalités voulues.

4 Conception

Plusieurs tentatives de modélisations ont été faite. Ceux-ci menaient à un cycle d’exécution peu souhaité, dans le sens où ces tentatives conduisaient à l’utilisation des switch cases. Ce type d’usage est indésirable et montre qu’il y a un problème dans la conception. Ce problème venait du choix même de l’interface graphique. Vu que le domaine d’intégration profond JAVA est disponible en version bêta, et qui n’est pas encore stable par rapport à celle de C++, ce qui a limité notre choix d’interface graphique. Ce choix est basé sur des boutons, c’est moins visuelle mais répond parfaitement aux besoins actuels.

Pour l’intégration des machines d’états avec YAKINDU SCT. Un contrôleur spécifique a été mis au point pour pouvoir contrôler les flux entrant et sortant de la machine d’état et les méthodes de l’application de voyages. Puisque l’outil YAKINDU modélise les fonctionnalités de l’application, il était important de regrouper celle-ci pour éviter la redondance dans les méthodes de l’application. Notre conception est modélisée dans le diagramme UML suivant :

Page 8

5 Modélisation

La machine d’état YAKINDU, modélise les fonctionnalités de l’API, et n’utilise que les classe et l’API fournie. En premier lieu, on instancie un objet de la machine d’état, qui encapsule chacune des méthodes demandées. Chaque méthode est invoquée par un élément de l’interface graphique. Tout bouton déclenche un évènement de la machine d’état, qui à son tour fait appel à une méthode « raise » de cet évènement, ce qui permet l’exécution. Les méthodes de l’API encapsulées sont celles qui répondent à l’écoute des actions de l’utilisateur.

5.1 Justification du choix de modélisation

Plusieurs choix de modélisation ont été mis en place afin de pouvoir rendre la machine d’état dynamique pour accepter n’importe quelle opération générique, mais ceci rendait la machine d’état trop chargé et la rendait inutilisable. On alors opté pour un modèle plutôt simple ou la sélection des entités se fait par famille, ce qui était plus facile à gérer et à maintenir. Chaque famille d’objets avait des comportement et des actions assez similaires. Donc, il était intéressant de traiter les actions communes ensembles et les actions uniques séparément. Ainsi, l’utilisation des états orthogonaux était très utile car elle permettait

Page 9 d’exécuter n’importe quelle tâche quasi simultanément (le mot quasi est utilisé exprès, on en discutera plus loin dans ce rapport).

5.2 Stabilité et abstraction

En introduisant de la machine d’états dans l’application fournie, il était indispensable de séparer la GUI du reste de l’API. Voici un diagramme de paquet de l’API avant d’introduire la machine d’état.

Cette séparation a permis d’avoir une GUI stable on y ajouter des composantes sans que cela n’affecte le reste. L’API à son tour était légèrement modifiée pour refléter le regroupement des familles d’objets. Le diagramme de paquet ci-dessous reflète les modifications apportées à l’application originale pour l’adapter à l’utilisation de la machine d’état. Ceci était un choix parmi d’autres.

Page 10

6 Design de la machine d’états

Pour le design de la machine d’état, on utilise l’outil YAKINDU SCT ajouté à l’IDE Eclipse. L’idée principale était de pouvoir travailler avec les différentes actions souhaités par l’usager simultanément ou presque. Nous avons créé un objet composite principale pour y loger cinq (5) régions orthogonales. La première région représente l’écran sommaire qui se constitue de trois (3) boutons. Chacun de ses boutons représente un type de voyage soit : - Voyage par avion. - Voyage par paquebot. - Voyage par train.

Pour savoir quel type a été sélectionné, une variable booléenne est associée à chaque famille. Celle-ci est gardée en mémoire dans la machine d’état. C’est cette variable qui va nous permettre de « raiser » la région associée au type de voyage sélectionné sachant que les cinq régions sont dans l’état Idle. Une fois cette variable initialisée, le statechart sait quelle région est concerné par cet évènement. Il est à noter que des règles de modélisation sont nécessaires pour séparer les actions à comportement constant et les actions à comportement variable. L’ajout, la modification, la

Page 11 suppression et l’annulation sont des comportements constants qui dépendent seulement du type de voyage sélectionné. L’assignation des prix, la création de section sont des comportements variables selon le type du voyage et le type du véhicule sélectionné. Mise à part la première région, chaque région est peuplée par deux états, un état Idle, et un état composite regroupement plusieurs régions représentant chacune un comportement. Aussi, chaque état clé comprend une « entry » suivi d’une opération qui sera le lien avec le monde extérieur. Voici une petite démonstration des états Idle.

Page 12 Il est important de savoir que les états composites permettent de loger plusieurs régions afin de concrétiser la notion du parallélisme ou l’orthogonalité. Cependant, pour ce faire, il faut que les région soit dans un ordre croissant faute de quoi, seules les régions consécutives se déclenche, le autres restes passives et ne s’activeront pas. La simulation du modèle est une phase clé dans la conception de la machine d’état. Elle permet voir le comportement souhaité fonctionne tel que décrit dans les spécifications.

Page 13 7 Implémentation

Une fois que le statechart est conçu et simulé, nous sommes passé à l’implémentation du contrôleur. Par la suite chaque bouton de l’interface graphique déclenche un évènement du statechart. On commence par instancié le contrôleur et la machine d’état. On initialise le statechart par la méthode prédéfinie init(), on entre dedans par la méthode enter(). A ce niveau, chaque région orthogonale est positionnée dans l’état « Idle » tel que décrit plus haut. Chaque actionListener() des boutons et associé à un « raise » d’un évènement précis dans la machine d’état, suivi d’un runCycle() pour permettre à la machine de passer d’e l’état actuel au suivant. Les opérations déclarées dans les états clés du statechart sont surchargées pour exécuter les tâches voulues. Par exemple, dans la région GestionPort, dans la sous-région AjoutPort, on y trouve l’opération createPort() Mise à l’intérieur de l’état PopupCreatePort, état responsable de l’ajout d’un nouveau port.

Page 14

Celle-ci est implémentée pour exécuter la création du port au moment où on appui sur le bouton : 1- Cette partie est dans le l’actionListener du bouton.

2- L’opération surcharger du code généré (cette opération est en entry dans l’état « PopupDeleteClicked »)

3- Voici la suite qui permet de retourner vers l’état « Idle » :

Page 15 On trouve dans notre contrôleur, surtout des actionListener(), des « raise » méthodes générées du statechart. Le reste de l’implémentation a été fourni et réadapté pour répondre aux besoin du statechart.

8 Tests et documentation

Pour assurer un comportement idéal des actions voulues et les évaluer, on a effectué quelques tests depuis le début de la conception de la machine d’état au développement. La première nous permettait d’avoir le comportement voulu des actions, des réaction, des évènement et des opération de notre modèle, la deuxième devait respecter le cheminement de l’action de l’état Idle au retour au même état. Les tests encourus se divisent en 2 catégories :

Tests fonctionnels : 1- Assure que la machine d’état se comporte selon les exigences, commencent par les états « Idle » et y retourne tout en passent par toutes les transitions suivant les évènements déclenchants. 2- Ils assurent que le code est conforme au comportement du statechart. Ils permettent aussi de savoir que l’ensemble code et machine d’état concordent et sont cohérent par rapport aux entrées et aux sorties.. Les tests sont faits par rapport aux spécifications. Tests structurels : Ils vérifient l’implémentation des algorithmes conçues et leur interaction par rapport au code YAKINDU SCT généré. Les tests sont faits par rapport au code. Test sur la machine d’état : Yakindu est doté d’une unité de test SCTUnit Test Class et SCT Unit Suite Test, on a essayé de faire ces tests selon une succession logique d’évènement mais sans veine, une erreur est survenue. L’équipe Yakindu a été informée du problème. Ils ont demandé un lien pour vérifier, mais malheureusement, leur réponse n’est pas arrivée à temps.

Page 16 8.1 Tests fonctionnels

Tests non-exhaustifs : Ces tests à la fumée couvrent les différentes actions du système, sans trop détaillé. Voici la liste de les tests manuels : • Vérifier que le programme compile et s’exécute; • Vérifier que l’API interagit avec le comportement de la machine d’état; • Vérifier que l’API reçoit et exécute les actions des statechart de façon coordonnée. • Vérifier qu’après exécution d’une tâche complète que l’état idle est atteint; • Vérifier que la machine d’état communique avec l’API; • Vérifier que les entités manipuler réagissent bien aux changements faits.

Test non-exhaustifs sur la machine d’état : Ces tests ont été réalisés au cours de l’élaboration du contrôleur, avant chaque « RaiseÉvènement », on vérifier si l’état où on est bien actif. Mais, ces tests visés surtout à savoir si on interagissait bien avec le statechart. Ils n’ont pas été formellement documenté.

8.2 Tests structurels

Test unitaires :Nous utilisons l’outil JUnit de Java, fortement recommandé pour les tests unitaires, pour vérifier si les méthodes du code fourni font ce qui est demandé. La dessus les tests n’ont pas étaient très poussés. Ces tests ont été réalisé pour créer des entité de voyage, et y appliquer les différentes opérations de gestion tel que l’ajout, la modification, la suppression,.. . Voici quelques exemples de teste unitaire.

Page 17

Page 18 8.3 Documentation

La documentation a été rédigée à l’aide de JavaDoc. Il vérifie la documentation du code, les conventions de nommage, l’ordre d’apparition (propriétés, constructeurs et méthodes) dans une classe, la lisibilité (espace, longueur des lignes) et la maintenabilité. Cependant, des erreurs et des avertissements ont été détectés dans le code généré de Yakindu, mais cela n’a pas empêché la génération de la documentation, voici une partie des erreurs et avertissements relevée :

On peut accéder à la documentation à partir du fichier TravelTripYakinduModel.html, on peut naviguer dans la documentation du code source et également choisir de lire des extraits du code source.

9 Maintenance

9.1 Analyse d’impact des modifications sur le code fourni

Pour pouvoir intégrer la machine d’état, il fallait séparé tous les frames du reste du code. Une analyse et étude du code a été entamée, afin de préserver les fonctionnalités déjà présente. Les seules corrections qui ont impacté l’affichage sont ceux liés à l’affichage des listes d’entités sélectionnées. Si on procède par simple affichage du contenu des listes, le

Page 19 résultat est tel que souhaité, mais lors du passage de la liste au JPanel, l’affichage est erroné, seul la liste des voyages apparait sur toute les vues, ce qui n’est pas favorable.

La seule chose impactée par ces changement est les interfaces graphiques, le reste du code demeure tel quel, ce qui rend les classes stables. Tout ajout ultérieur, n’impactera que le contrôleur, celui-ci étant très couplé reste modifiable et maintenable puisque il contient juste la gestion des boutons.

9.2 Maintenance du statechart

C’est un module assez maintenable, le fait de choisir des états composites pour y loger les comportements et des actions qu’on veut faire était intentionnel. De la sorte, si on veut ajouter un nouvelle tâche, on insère une nouvelle région dans l’état composite concerné. Si on veut ajouter une autre famille de voyage, il suffit d’ajouter une nouvelle région dans l’état composite principale et y loger un état composite pour d’éventuelles fonctionnalités qu’elles soient constantes ou variables.

Page 20 Conclusion

Ce projet est très intéressant, nous regrettons de n’avoir pu faire que la partie administrateur. Avant, on croyait que les statecharts étaient une notion purement théorique. Au début, c’était légèrement flou, car on pensait que c’était le code qui gérerai les statecharts puisque c’était plutôt restreints à la résolution de problème liés à l’informatique théorique. Voir que ça peut être concrétiser dans un réel projet était très impressionnant. L’idée était proposée par le directeur du projet Dr. Eugène Syriani, PhD.

Ce qui a ralenti le projet, c’est le choix de la conception du modèle du statechart et l’intégration du Deep Java Integration qui causé beaucoup de problèmes allant jusqu’à la rupture du modèle conçu. D’un autre côte, c’était très bénéfique, ceci nous a permis d’acquérir plus d’expérience dans ce genre de modélisation.

Pour le futur, il serait intéressant de pouvoir intégrer le reste de la gestion de voyage. Également, en espérant que le Deep Java Integration soit assez stable pour interagir dynamiquement avec les statecharts.

Page 21 Remerciements

Je tiens à remercier infiniment Dr. Eugène Syriani, PhD d’avoir accepté de diriger ce travail, je le remercie pour son appuis, sa patience et ses directives très fructueuses. Aussi, la charge de travail était lourde. Ma gestion du travail était mauvaise et ma gestion du temps terrible. De plus, il fallait composer avec les autres cours et le travail et les arrêts maladies causé par les pépins de santé de mes enfants. Pour ces derniers, Dr. Syriani a été très compréhensif en ne me tenant pas rigueur des meetings reportés ou annulés.

Je tiens à remercier aussi l’équipe YAKINDU qui m’ont épaulé et soutenu lors des problèmes rencontrés avec la modélisation du statechart, leur feed-back était rapide et donnait une solution aux erreurs que je rencontrer avec leur outil même le dimanche. Mes sincères remerciements à Vasco Sousa et à Louis Édouard Lafontant, ainsi que Dr. Michalis Familis, PhD qui chapeaute ce cours.

Page 22 Bibliographie

- He Nam D., Mousset E.C., et Levy D.C., “Automating the tasting of object behavior: A statechart-driven approach”, International scholarly and scientific research & innovation, 2007, vol 1, numéro 11, p3700-3704. - Harel D., “ Statecharts : A visual foralism for complex systems”, Elsevier Science Publishers (North-Holland), Juillet 1986, p 231 – 274. - Horrocks I., “Constructing the user interface with statecharts”, Addison Wesley Longman Limited, 1999 - Yacoub M. S. et Ammar H.H., “A pattern language of statecharts”, WV26506 - https://stackoverflow.com - https://blogs.itemis.com/en/test-driven-development-with-yakindu-statechart-tools- sctunit - https://en.wikipedia.org/wiki/YAKINDU_Statechart_Tools - https://www.itemis.com/en/yakindu/state-machine/documentation/user- guide/sclang_graphical_elements#sclang_graphical_elements

Page 23