Afin de généraliser l’approche et de montrer sa versatilité, des expérimentations ont été menées avec d’autres moteurs d’exécution et/ou d’autres outils d’analyse.
10.5.1 EMI-LOGO : un interpréteur de modèles LOGO
L’approche EMI a été mise en œuvre pour réaliser un interpréteur de modèles LOGO [AGR74] appelé EMI-LOGO. LOGO est un langage de programmation éducatif permettant de programmer le déplacement d’une tortue pour réaliser des dessins. Le langage LOGO a été créé en 1967 au laboratoire d’intelligence artificielle du MIT. Il s’agit d’une adaptation du lan-gage LISP visant à faciliter l’apprentissage des concepts de programmation. Ce lanlan-gage a été choisi pour expérimenter notre approche car il s’agit d’un des premiers langages interprétés. De plus, contrairement à UML, LOGO est un langage séquentiel (c.-à-d. avec un seul chemin d’exécution) et procédural avec des concepts algorithmiques relativement simples.
L’interpréteur EMI-LOGO a été implémenté avec le langage C comme langage hôte en utilisant la même méthodologie de conception que l’interpréteur EMI-UML. Parmi les points clés de ce prototype, l’implémentation6 de la sémantique du langage LOGO repose sur une variante du patron de conception Interpréteur [EHV95]. Ce patron de conception est particu-lièrement adapté ici car le modèle forme un arbre syntaxique abstrait où chaque nœud corres-pond à une instruction. Pour l’implémentation d’EMI-LOGO, ce patron a été modifié pour que l’exécution soit pilotable. Plus concrètement, cela se traduit par l’ajout d’une pile d’exécution avec pour chaque instruction un compteur de programme indiquant où en est rendue l’exé-cution. Par exemple, pour l’instructionFOR, le compteur d’itération est utilisé comme compteur de programme afin que chaque itération soit vue comme un pas observable. Une autre ob-servation intéressante est que l’état de l’interface graphique doit également être sauvegardé
6. L’implémentation de la sémantique de LOGO est inspirée de celle créée par Didier Vojtisek en https:// dvojtise.github.io/mde-crashcourse-logo/.
10.5. Expérimentations avec d’autres outils
dans la configuration afin de pouvoir replacer celle-ci dans l’état souhaité. Pour l’interpréteur EMI-LOGO, cela se traduit par la sauvegarde de tous les points et segments visibles ayant été parcourus par la tortue.
Pour les activités d’analyse, ce moteur d’exécution possède un langage d’observation basé sur le langage C et complété avec des opérateurs sous forme de macros C. Le model-checker OBP2 peut être utilisé pour piloter l’exécution de EMI-LOGO et mener diverses activités d’ana-lyse : la simulation interactive, le débogage multivers et le model-checking LTL. Un mécanisme de trace implémenté dans l’interpréteur permet également d’afficher le dessin en cours de réa-lisation sous forme d’une image Scalable Vector Graphics (SVG). La Figure 10.12 présente un exemple de dessin obtenu avec EMI-LOGO à partir du programme LOGO en Listing 10.1.
to drawSquare repeat 4 [ forward 100 right 90 ] end clear pendown repeat 72 [ drawSquare right 5 ] penup
Listing 10.1 – Exemple de programme LOGO.
10.5.2 AnimUML : un outil d’interprétation et d’animation de modèles UML
AnimUML [Jou+20] est un outil d’interprétation et d’animation de modèles UML permettant d’éditer, de simuler et de vérifier des modèles partiels. Cet outil, implémenté en JavaScript, à vocation à être utilisé dans les phases de conception amont pour aider les ingénieurs à concevoir leurs modèles. Des modèles même incomplets peuvent déjà être exécutés et animés avec AnimUML ce qui permet de détecter des erreurs de conception au plus tôt.
AnimUML propose à la fois une interface graphique web et un interpréteur de modèles UML implémenté en JavaScript. L’interface graphique propose diverses fonctionnalités d’édition de
(a) Dessin en cours. (b) Dessin terminé.
FIGURE10.12 – Exemple de dessin pour le programme LOGO ci-dessus.
modèles permettant de créer ou de modifier des modèles UML. Ces modèles peuvent en-suite être exécutés sur un moteur d’exécution et pilotés par des outils d’analyse au travers de l’interface de contrôle d’exécution. La conception de l’interpréteur de modèles UML est forte-ment inspirée de la méthodologie de conception EMI. Il impléforte-mente la sémantique d’UML sous forme opérationnelle en se basant sensiblement sur le même sous-ensemble qu’EMI-UML. Il supporte les concepts pouvant être représentés sur les diagrammes de classes, de structures composites et de machines à états. Ce moteur d’exécution en JavaScript rajoute également des concepts annexes pour supporter l’interprétation de modèles UML partiels comme l’Ether pour le traitement des messages sans destinataire explicite.
Pour l’analyse de modèles, AnimUML permet également de piloter et d’observer l’exécu-tion des modèles UML. AnimUML permet d’animer des modèles par exemple en changeant la couleur de l’état courant d’une machine à états ou en mettant en surbrillance les transi-tions tirables. Il offre également des mécanismes de traces interactifs permettant d’afficher des diagrammes de séquence ou des timing diagrams en utilisant PlantUML. La Figure 10.13 présente un diagramme de séquence réalisé avec AnimUML pour le modèle du contrôleur de passage à niveau. AnimUML utilise l’interface de contrôle d’exécution permettant à la fois de connecter des outils d’analyse externes comme le model-checker OBP2 ou d’autres moteurs d’exécution comme l’interpréteur EMI-UML. Ainsi, AnimUML peut servir d’interface graphique pour EMI-UML afin d’animer les modèles exécutés par cet interpréteur.
AnimUML offre enfin un outil d’exécution comparée (ou de bisimulation forte [Fer90]) per-mettant de comparer les espaces d’état de deux modèles s’exécutant chacun sur un moteur d’exécution. Cette fonctionnalité peut ainsi permettre de comparer les sémantiques opération-nelles de deux moteurs d’exécution ou encore d’étudier l’impact de certains changements sur
10.5. Expérimentations avec d’autres outils
FIGURE10.13 – Capture d’écran de l’interface AnimUML montrant un diagramme de séquence interactif pour le modèle du contrôleur de passage à niveau.
l’exécution d’un même modèle.
Pour effectuer toutes ces activités d’analyse (y compris l’exécution comparée), l’interface de contrôle d’exécution définie dans cette thèse s’est révélée suffisante pour piloter l’exécution des modèles.
10.5.3 Intégration d’EMI-UML dans Gemoc Studio
Pour valider l’interface de contrôle d’exécution, nous avons également intégré l’interpréteur EMI-UML comme moteur d’exécution dans Gemoc Studio. Gemoc Studio peut ainsi piloter l’exécution de modèles UML sur EMI-UML afin de mener de la simulation et du débogage omniscient.
Pour la simulation, Gemoc studio lance l’exécution du modèle comme s’il était déployé sur la plateforme d’exécution réelle. Contrairement à la simulation interactive, ce n’est pas l’utilisateur mais un ordonnanceur qui résout le non-déterminisme général de l’exécution du modèle.
Pour le débogage omniscient, la Figure 10.14 montre une partie de l’interface graphique de Gemoc Studio lors du débogage du modèle de contrôleur de passage à niveau. À gauche, l’addon Concurrent Logical Steps Decider permet à l’utilisateur de choisir le prochain pas d’exé-cution. À droite, l’addon Multidimensional debugger affiche un chronogramme permettant de
FIGURE 10.14 – Capture d’écran d’une partie de l’interface de Gemoc Studio montrant une session de débogage pour le modèle du contrôleur de passage à niveau.
visualiser les valeurs des RTDs à chaque pas d’exécution. Cette addon affiche également la trace d’exécution courante de sorte qu’il est possible de recharger une configuration précé-dente en cliquant sur celle-ci (p. ex. la configuration 6 sur la Figure 10.14). Contrairement à OBP2, Gemoc Studio possède une optimisation telle que l’exécution est rejouée, tant que pos-sible, en s’appuyant sur les données de la trace d’exécution. La configuration courante de l’in-terpréteur n’est rechargée que si une nouvelle trace d’exécution doit être parcourue. Cette op-timisation peut néanmoins rendre plus difficile la détection de problèmes de non-déterminisme d’exécution dans l’interpréteur.
Pour intégrer EMI-UML dans Gemoc Studio, l’interface de contrôle d’exécution s’est mon-trée appropriée pour piloter l’exécution et fournir une projection des RTDs. En ce qui concerne l’observation de l’exécution, un moteur d’exécution dans Gemoc Studio peut être couplé à un “interpréteur d’expressions” notamment pour permettre l’animation de modèles. Il serait tout à fait envisageable d’évaluer des propositions atomiques sur EMI-UML via ce mécanisme afin de répondre aux besoins des activités d’analyse.