Méta-modèles DEVS basés sur XML

Une première méthode consiste à créer des modèles DEVS sous formes de variantes de XML, langage balisé permettant le stockage de modèles. Tout modèle XML peut être :

− bien formé : il respecte la syntaxe préconisée par le W3C ;

− valide : il est bien formé, et de plus il est conforme à son méta-modèle, exprimé sous forme de DTD, ou bien de XML Schema. C’est ce méta-modèle qui est en fait celui du formalisme DEVS.

La caractéristique principale des méta-modèles de DEVS basés sur XML est qu’ils ne permettent pas d’offrir la possibilité de représenter des modèles DEVS autrement que textuellement.

Dans de nombreuses approches, telles que [Filippi, 2003], XML est utilisé pour représenter des modèles couplés DEVS (la nature de ce langage balisé fait qu’il est souvent utilisé pour spécifier des hiérarchies), mais les modèles atomiques restent spécifiés en langage objet. XML est donc utilisé dans ce cas-là pour une représentation partielle des modèles DEVS, et surtout pour permettre leur stockage.

D’autres approches, en revanche, prennent en charge les modèles atomiques et couplés, même si les fonctions propres aux modèles atomiques sont encapsulées dans un langage orienté-objet : ce sont ces dernières que nous détaillons ici.

a) DEVSML

La méthode qui vise à représenter tous les modèles DEVS en XML a été initiée dans [Janousek et al. 2006] : elle introduit l’approche DEVS Modeling Language ou DEVSML. Elle permet de décrire des modèles atomiques et couplés DEVS, et est fortement influencée par JavaML (langage basé sur XML décrivant des modèles de code JAVA) [Badros, 2000]. La description sous forme textuelle d’un modèle étant efficace mais peu pratique, les auteurs proposent un petit outil graphique permettant de créer le squelette des modèles. Ces travaux posent la question de la modélisation des fonctions : langage simple, pseudo code…etc.

89 Les auteurs proposent provisoirement d’utiliser un petit langage fonctionnel proche de LISP. Les transformations vers le code de la plateforme de destination se font ensuite via des spécifications de type XSL (XSLT, XPath). Parallèlement à ces travaux, [Risco-Martín et al. 2007a] ont publié un schéma XML appelé DEVSXML exposant des concepts très proches de ceux de DEVSML, et ajoutant un petit simulateur à l’architecture de base : xDEVS.

Ces deux approches similaires ont par la suite fusionné et [Mittal et al. 2007a] constitue l’aboutissement de cette fusion. Le langage balisé DEVSML permet de définir le comportement de modèles atomiques en offrant la possibilité de définir des fonctions et aussi de décrire la structure du système via les modèles couplés. A également été prévue une fonctionnalité permettant à DEVSML de spécifier des modèles atomiques avec des fonctions proches de C++, mais à notre connaissance elle n’a pas été implémentée.

DEVSML est employé pour modéliser des modèles DEVS, au sein d’une architecture SOA. De ce fait, ces travaux peuvent être considérés comme des travaux hybrides : ils s’intéressent à l’interopérabilité via les simulateurs ainsi que via les modèles. Mais le plus intéressant ici est l’aspect modélisation/méta-modélisation, car l’export vers différentes plateformes est assez limité.

La DTD d’un modèle atomique a été définie comme le montre la Figure III-1). Les éléments simples sont indiqués sous formes d’attributs, ils suivent plus ou moins la définition de base d’un modèle DEVS atomique. On peut noter l’ajout des éléments suivants :

− un champ de métadonnées simulator : tout modèle en DEVSML porte donc en lui une indication concernant la plateforme sur laquelle il est destiné être simulé ;

− des éléments service : chaque service est en fait un container, il est implémenté dans le langage cible en tant que méthode. Cette fonctionnalité n’est pas encore implémentée ;

− un élément spécifique à Java concernant les imports, les constructeurs et les méthodes ;

− de même, comme DEVSML repose sur JavaML, les fonctions deltint, deltext…etc. sont proches de JavaML et seront ainsi transformées en code JAVA au moment de la simulation.

Les limitations de cette approche sont donc claires : malgré le fait que les modèles DEVSML puissent être multiplateformes, ils ne sont pour l’instant pas compatibles avec des simulateurs autres que ceux basés sur JAVA (ici, DEVSJAVA et xDEVS).

90 Figure III-1 : DTD d’un modèle atomique DEVSML [Mittal et al. 2007a]

Une nouvelle version du « framework DEVSML » a été définie dans [Mittal et al. 2012]. Elle propose une approche offrant la possibilité à des experts d’un domaine de définir des DSLs (Domain Specific Language) et de leur associer des transformations vers le langage DEVSML et vers du code exécutable DEVSJAVA. Cette dernière version s’inscrit par conséquent dans une optique plus clairement IDM et utilise les outils de l’environnement EMF. Le langage DEVSML est décrit sous la forme d’une grammaire EBNF en utilisant le framework XText¹. Des DSLs tels que NLDEVS Natural Language DEVS sont également définis en suivant la même démarche (définition d’une grammaire EBNF). Des transformations de type M2M, vers DEVSM et DEVS sont ensuite spécifiées en utilisant le langage Xtend².

La Figure III-2 montre l’exemple d’un modèle atomique de générateur dans le langage DEVSML version 2 (vision arborescente du modèle générée par Eclipse-EMF).

La notion d’état est représentée sous la forme d’une énumération (passive, active, finishing) intégrée dans la description de la fonction timeAdvance elle-même ainsi définie également en extension (une valeur est associée à chaque valeur de l’état). Les fonctions de transitions sont représentées par une machine d’état (DEVS state Machine) définissant en énumération les différents changements d’état associés à chacune d’elle (internal_Transitions et external_Transitions). Il en est de même pour la fonction output qui est décrite en affectant un évènement de sortie à chaque valeur d’état concernée. On note également la possibilité de définir des variables globales typées au niveau d’un modèle atomique (ici arrTime et count).

1 http://www.eclipse.org/Xtext 2 http://www.eclipse.org/xtend

91 Le code DEVSJAVA est généré par l’exécution automatique d’une transformation spécifiée à l’aide du langage Xtend.

Figure III-2 : Exemple de modèle atomique DEVSML V2 [Mittal et al. 2012] b) SimStudio et DML

Une approche similaire à DEVSML a été menée par une équipe de l’ISIMA [Touraille et al. 2010] [Touraille et al. 2011]. Les auteurs proposent un méta-modèle unificateur pour DEVS baptisé DEVS Markup Language ou DML [Touraille et al. 2009b], exprimé en XML, et se conformant au XML Schema.

Ils décrivent également un environnement de modélisation et simulation DEVS : SimStudio. Cet environnement possède son propre noyau de simulation (programmé en C++) : DEVS Meta-Simulator (DEVS-MS). Sur celui-ci doivent venir se greffer différents composants logiciels, notamment pour la modélisation, la visualisation des modèles et leur stockage. A ce jour, seul un composant de modélisation basique semble avoir été implémenté, pourtant cette approche semble prometteuse de par sa philosophie originale. A terme, les auteurs annoncent l’intégration de plusieurs sortes de modèles dans l’environnement, notamment :

− Modèles DML modifiables, (ré)utilisables tels quels ou intégrables dans une hiérarchie de modèles couplés

− Modèles de simulateurs avec transformations (depuis DML) associées

L’intérêt de l’emploi d’un autre méta-formalisme est toutefois souligné et présenté comme une évolution possible de l’approche. Le méta-formalisme candidat est MOF, à cause notamment de son association avec le standard XMI.

DML propose une gestion originale des algorithmes, qui offrent un pouvoir d’expression relativement puissant. Pour décrire des fonctions DEVS il faut utiliser un

92 mélange de code générique, possédant une correspondance directe dans les langages impératifs existants, et de fragments de code abstraits, qui doivent être implémentés pour chaque langage cible. Nous donnons ci-dessous (Figure III-3) un exemple de code hybride ou semi-générique : dans ce fragment, deux implémentations sont possibles pour l’opération de mise d’un élément dans une file : pour C++ et pour Java.

Figure III-3 : Fragment de code hybride C++/Java avec DML [Touraille et al. 2009a] Seuls les types et les fragments de code abstraits nécessitent d'être concrétisés en une implémentation spécifique. Les auteurs, en vue d’une simplification de cette étape, proposent la construction de « catalogues » de types et de fragments accompagnés de leurs implémentations dans les langages les plus populaires. Ils offrent par ailleurs aux fournisseurs de frameworks DEVS de publier le modèle de leur plate-forme pour permettre l’intégration de celle-ci à SimStudio.

Trois niveaux d’indépendance sont identifiés : par rapport à la plateforme, par rapport au langage cible, par rapport aux bibliothèques.

Le problème délicat de la gestion des fonctions DEVS va de pair avec la spécification des algorithmes : code générique, code tiré d’un langage fonctionnel, ou fragments de code orientés-objet. Le fait d’utiliser un méta-modèle balisé complexifie notablement la définition d’une fonction, fut-elle très simple. La figure suivante tirée de [Touraille et al. 2010] est la description en DML d’une fonction testant la variable sigma : si cette dernière est nulle, un élément est ajouté dans un tampon. D’un fonctionnement pourtant très simple d’un point de vue algorithmique, cette fonction n’en est pas moins fastidieuse à implémenter manuellement (Figure III-4).

Des fragments de code objet spécifique, non pas au langage cible, mais à la plateforme de destination, sont là-aussi ajoutés.

L’intégration de DML dans le cadre d’une architecture orientée services a été évoquée dans [Touraille et al. 2009a]. Chaque modèle DML est interprété puis, grâce à WSDL, implémenté en Web Service. Cela permet de regrouper des modèles en ligne de manière à ce que les modèles locaux ou distants soient indifféremment utilisés dans la simulation, de manière totalement transparente. Les messages transitant sur le réseau ne sont plus cette fois-ci des messages entre simulateurs comme vu en 3.2) mais des invocations d’opérations propres au modèle (la fonction ta, δint, δext…). L’avantage d’une telle approche aurait été de

93 pousser au maximum l’interopérabilité des modèles en considérant indifféremment les modèles situés en local et les modèles distants. Toutefois, ce projet n’a visiblement pas été implémenté et n’est plus évoqué dans les articles présentant SimStudio [Touraille et al. 2010] [Touraille et al. 2011].

Figure III-4 : Fonction DML implémentée en code semi-générique [Touraille et al. 2010] Pour conclure cette sous-section traitant des méta-modèles DEVS basés sur XML, il faut souligner que malgré le fait que ce formalisme soit particulièrement bien adapté au stockage et donc au partage des données, il reste, lorsqu’il n’est pas associé à une représentation graphique, très lourd à modifier, dès que la hiérarchie des modèles ou la structure des fonctions se complexifient un tant soit peu.

c) Transformations associées

[Risco-Martín et al. 2007b] proposent une transformation du formalisme Statecharts vers DEVS. Ce travail s’inscrit dans la continuité de

− [Mittal 2006] qui montre comment la plupart des diagrammes UML peuvent être transformés en composants DEVS orientés XML : DEVSML ;

− [Risco-Martín et al. 2007a] qui proposent une manière de créer des PIM DEVS (le terme PIM est employé ici en référence à MDA, même si les auteurs ne se placent pas dans le même espace technologique) avec DEVSXML (qui deviendra par la suite DEVSML).

Les auteurs se placent donc dans l’espace technologique XML et proposent une transformation en trois étapes, les deux premières étapes sont M2M et la dernière étape est M2T. La première étape consiste à définir des modèles exprimés en UML State Machine

Diagrams. Ces modèles sont ensuite transformés en modèles SCXML1. Les fichiers SCXML représentant le modèle Statecharts sont ensuite transformés en FD-DEVS SM², un formalisme balisé représentant des machines DEVS finies et déterministes (restriction FD-DEVS vue dans le premier chapitre de ce travail) [Mittal 2007].

1 http://www.w3.org/TR/scxml

94 Enfin, la dernière étape consiste à transformer les modèles FD-DEVS en des modèles de simulation interprétables par des simulateurs DEVS.

Ce travail se limite à la transformation de modèles comportementaux, l’auteur partant du principe que le comportement reste l’aspect d’un modèle DEVS le plus difficile à spécifier, contrairement à la structure (modèles couplés) dont les concepts peuvent plus facilement être compris par des chercheurs provenant d’horizons scientifiques différents.

En ce qui concerne SimStudio, les transformations associées se font via XSLT. Dans un premier temps, chaque modèle DML est transformé vers un modèle DML-Lang. La différence entre le méta-modèle de DML-Lang et celui de DML est minime : elle concerne le code générique. Les portions de code « génériques » en DML sont remplacées en DML-Lang par leurs équivalents dans le langage de destination, mais les fragments de code dépendants des bibliothèques et des simulateurs n’ont toujours pas été générés. Ensuite, chaque modèle DML-Lang est transformé en modèle DML-Sim, au moyen d’un méta-modèle appelé « fragments de code » établissant des correspondances entre la syntaxe abstraite exprimée avec DML et la syntaxe concrète propre aux plateformes et/ou au langage cible.