Rapport De Projet 3150 Hanifa Mallek
Total Page:16
File Type:pdf, Size:1020Kb
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 Eclipse 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 : C’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.