1.3 Approches pour l’exécution de programmes
1.3.3 Approches basées sur une sémantique opérationnelle
Pour exécuter des modèles, une autre approche consiste à capturer la sémantique opéra-tionnelle du langage de modélisation dans un moteur d’exécution appelé interpréteur. Cet outil encode la sémantique du langage sous forme de règles d’exécution qui sont appliquées par transformations successives sur l’état d’exécution du modèle.
1.3.3.1 Description
Le principe de cette approche est présenté sur la Figure 1.5. Contrairement à l’approche translationnelle, c’est directement le Modèle de conception qui est exécuté. Ce Modèle se conforme au Langage de modélisation et est directement embarqué sur la Plateforme d’exécu-tion. Un Interpréteur doit également être conçu pour implémenter la sémantique de LM. Pour chaque concept exécutable de LM, une règle (c.-à-d. un algorithme) est définie pour modifier l’état d’exécution du modèle (c.-à-d. les données d’exécution dynamiques) en conformité avec
1.3. Approches pour l’exécution de programmes
la sémantique du langage. Cet outil permet ainsi d’exécuter directement le modèle de concep-tion sur la Plateforme d’exécuconcep-tion. Suivant le langage interprété, la plateforme d’exécuconcep-tion peut ici aussi être de différentes natures (p. ex. une autre VM, un OS, un microcontrôleur).
Cette approche n’utilise pas de transformation et permet d’implémenter un moteur d’exé-cution directement dans l’Espace technique de LM. Plusieurs patrons de conception (ou en anglais design patterns) ont été élaborés afin de faciliter l’implémentation d’une sémantique opérationnelle. On trouve notamment les patrons Interpréteur et Visiteur définis par le Gang of Four dans [EHV95]. Plus récemment, d’autres patrons [Led+17 ; LDC18 ; WO16 ; OC12 ; JBF11] ont également été développés afin de faciliter la réutilisation et l’extension de la syn-taxe et de la sémantique des langages.
1.3.3.2 Outils
Différents interpréteurs permettent d’exécuter des modèles avec une sémantique opéra-tionnelle. Cette section présente les caractéristiques de ces outils basés sur des approches spécifiques (applicables à un seul langage) ou des méta-approches (pouvant être mises en œuvre sur différents langages).
Approches spécifiques. Une première méthode pour implémenter une sémantique opéra-tionnelle est de concevoir un interpréteur uniquement pour un langage donné (c.-à-d. de façon spécifique). Par conséquent, cet interpréteur n’est applicable qu’à des modèles de ce langage. L’un des langages sur lequel l’implémentation d’une sémantique opérationnelle a été le plus ap-pliquée est UML. Le travail en [Rie+01] définit notamment une architecture permettant d’implé-menter une machine virtuelle pour UML (UML VM). Les outils ACTi [CD08] et Pópulo [FMS08] permettent d’interpréter les actions et les activités d’UML 2.0 tandis que UVM [SM05a] base son exécution sur les machines à états et les diagrammes de séquence. Le standard founda-tional UML (fUML™) [OMG17c], un sous-ensemble d’UML, peut également être interprété par différents outils dont l’implémentation de référence7, Moka [Rev+18] et Moliz [ML12].
Méta-approches — L’initiative Gemoc. Gemoc Studio8est un Environnement de Dévelop-pement Intégré (EDI) permettant à la fois de définir des langages et de concevoir des modèles conformes à ces langages. La sémantique d’un langage est développée à l’aide d’un méta-langage pouvant lui-même être exécuté à l’aide d’un moteur d’exécution appelé méta-outil. Ce moteur d’exécution permet de concevoir un interpréteur pour le langage conçu et de faire le lien avec les autres outils de développement (p. ex. débogueur, animateur). Chaque métalan-gage et son méta-outil définissent une méta-approche supportée par Gemoc Studio. À partir
7. fUML Ref. Impl. : http://modeldriven.github.io/fUML-Reference-Implementation/. 8. GEMOC Studio : http://gemoc.org/studio.html.
de la définition d’un langage, Gemoc Studio offre un environnement de développement com-plet permettant la modélisation, l’exécution, et l’analyse de modèles conformes à ce langage. L’initiative Gemoc propose ainsi une démarche systématique pour définir la sémantique des langages. Les cinq métalangages supportés dans Gemoc Studio sont Java + Kermeta 3, ALE, xMOF, MoCCML + Kermeta 3 et Henshin.
Nous allons maintenant décrire chacune des cinq méta-approches associées en commen-çant par celles qui permettent de définir des langages séquentiels (c.-à-d. des langages dé-finissant un unique chemin d’exécution correspondant à une séquence d’instructions). (1) La méta-approche Java + Kermeta 3 [Bou+16] permet de définir la sémantique opérationnelle à l’aide de méthodes Java qui sont ensuite tissées dans la syntaxe abstraite du langage avec Ker-meta 3 (K3) [JBF11 ; Dre+09], un tisseur d’aspects. (2) Le langage Action Language for Ecore (ALE)9 est le successeur de K3. Il permet de définir la sémantique opérationnelle d’un lan-gage via le mécanisme d’open class [Cli+00]. (3) Le métalanguage xMOF [May+13 ; MLW12] permet, quant à lui, de définir la sémantique opérationnelle d’un langage sous forme d’activi-tés fUML. Gemoc Studio possède également deux méta-approches permettant de définir des langages concurrents (c.-à-d. des langages définissant différents processus qui rentrent en compétition pour leurs exécutions). (4) Le métalangage MoCCML + Kermeta 3 [Bou+16] est le premier métalangage conçu par l’équipe Gemoc pour définir des langages concurrents. Le langage Model of Concurrency and Communication Modeling Language (MoCCML) [Com+13 ; Dea+15 ; Lat+15] permet de spécifier de façon explicite les différents aspects liés à la concur-rence d’un langage. Le modèle de concurconcur-rence permet de définir des contraintes sur le flot de contrôle du langage et donc de caractériser l’ensemble des chemins d’exécution possibles. Ce modèle de concurrence est ensuite compilé vers Clock Constraint Specification Language (CCSL) [OMG ; And09]. Pour l’exécution, le moteur d’exécution doit coordonner l’interpréteur de la sémantique opérationnelle du langage et TimeSquare [DM12], le solveur de contraintes CCSL utilisé dans Gemoc Studio. (5) La méta-approche basée sur Henshin [Zsc18] permet de définir la sémantique opérationnelle des langages concurrents sous forme de règles déclara-tives écrites avec le langage Henshin. Pour permettre l’exécution, ces règles reposent sur les techniques de transformation de graphes décrites dans le paragraphe suivant.
Méta-approches — La réécriture de graphes ou de termes. Un autre paradigme pour défi-nir une sémantique opérationnelle est d’utiliser des techniques de réécriture. Pour la réécriture de graphes, l’état d’exécution du modèle est vu comme un graphe qu’il est possible de modifier à l’aide de règles de réécriture ou de transformations pour permettre l’exécution. L’outil Hen-shin [Are+10] permet de définir la sémantique opérationnelle d’un langage sous forme de règles déclaratives. Son moteur d’exécution permet ensuite d’exécuter ces règles par transformation
1.3. Approches pour l’exécution de programmes
de modèles. L’interpréteur TGG [KRW04] utilise, quant à lui, des techniques de transformations de graphes basées sur les Triple Graph Grammars (TGGs). Des outils de réécriture de termes, comme K framework [R ¸S10], peuvent aussi être utilisés pour définir la sémantique opération-nelle d’un langage. K framework a notamment été utilisé pour définir la sémantique de plusieurs langages de programmation10dont C [HER15], Java [BR15], Python et Haskell. En théorie, cet outil est aussi applicable pour définir la sémantique des langages de modélisation.
En résumé, on peut constater que très peu d’outils d’interprétation de modèles sont, à notre connaissance, adaptés pour le domaine de l’embarqué c.-à-d. déployables sur une cible em-barquée et conçus pour s’exécuter avec peu de ressources. Les travaux les plus proches s’y rapportant sont ceux qui concernent le développement de VMs pour l’embarqué (p. ex. Squawk [SC05], HaLVM11), pour les réseaux de capteurs (p. ex. Mote Runner [Car+09], Maté [LC02]), ou pour le temps réel (p. ex. Ovm [Bak+06], IBM VM [Aue+07]). Cependant, ces VMs ne per-mettent pas de définir des méta-approches et elles opèrent à un niveau d’abstraction inférieur (c.-à-d. au niveau du bytecode). Nous pouvons aussi remarquer que les approches formelles sont rarement utilisées pour définir des interpréteurs. K framework est la seule approche for-melle parmi toutes celles citées. En ce qui concerne plus spécifiquement UML, la section A.3.3 donne un aperçu des outils implémentant une sémantique opérationnelle pour UML.