– La deuxième étape a pour objectif de permettre de vérifier formellement les modèles. Elle consiste à définir une sémantique par traduction vers un domaine formel tel que les réseaux de Petri. Cette étape correspond à la définition d’un compilateur de modèle. Les propriétés définies dans l’étape précédente peuvent être traduites automatiquement de manière à être véri- fiées sur le modèle obtenu par traduction. Toutefois, afin de s’assurer que les conclusions obtenues sont cohérentes, nous détaillons la preuve de bisimula- tion qu’il est nécessaire d’établir entre le modèle initial et le modèle obtenu par traduction.
– La troisième étape a pour objectif de permettre d’animer des modèles. Elle consiste à définir la sémantique d’exécution comme l’ensemble des réac- tions à chaque événement défini dans le EDMM. Ceci équivaut à décrire la sémantique comportementale par un système de transition. Pour simuler le modèle, cette sémantique est prise en compte par un ensemble de com- posants réutilisables que nous avons conçus (moteur de simulation à évé- nements discrets et panneau de contrôle) s’appuyant sur les concepts géné- riques du TM3. Les outils graphiques comme l’animateur et le constructeur de scénario sont engendrés à partir des décorations graphiques définies sur les éléments du SDMM et du EDMM et viennent compléter l’éditeur gra- phique obtenu à partir du DDMM comme c’est actuellement le cas dans
TOPCASED.
– La quatrième étape consiste à traduire automatiquement les DSML et les modèles vers une représentation abstraite formelle que nous avons dé- finie à travers la bibliothèque COQ4MDE. L’environnement COQ permet alors de vérifier formellement la conformité d’un modèle par rapport à son langage. COQ4MDE a été défini de manière à pouvoir être étendu facile- ment pour exprimer la sémantique d’exécution d’un DSML et utiliser alors l’environnement COQ pour vérifier le comportement d’un modèle.
10.3
Élargissement des résultats
Les travaux présentés dans cette thèse s’inscrivent dans un champ encore peu exploré de la recherche. Ils contribuent à l’étude de l’ingénierie de la sémantique pour les langages de modélisation. Un consensus est encore loin d’être trouvé, et nécessite pour cela de poursuivre les études sur ce domaine.
Nous pensons que l’approche présentée dans cette thèse permet de donner un cadre rigoureux pour définir les outils de vérification et de simulation pour un DSML. Ces travaux ouvrent maintenant de nombreuses perspectives, à court terme comme à long terme, afin d’aider le métaconcepteur à définir l’ensemble des as- pects d’un DSML.
10.3. ÉLARGISSEMENT DES RÉSULTATS 161
10.3.1 Environnement d’expression des propriétés temporelles
Il nous semble intéressant d’étendre notre étude sur TOCL afin de pouvoir ex- primer des propriétés aussi bien sur la syntaxe abstraite du langage que sur les mo- dèles construits. Ces propriétés peuvent ensuite être prises en compte de la même manière dans la traduction automatique vers un langage tel que LTL. L’ensemble de ces propriétés peut également être pris en compte dans la simulation afin de mieux appréhender les erreurs, en complément de l’animation graphique du mo- dèle sur des exécutions particulières. Pour cela, il faut fournir les outils d’analyse qui permettront d’évaluer les propriétés sur chacun des états de l’exécution. Ces outils peuvent être génériques et intégrés à l’architecture d’un simulateur de mo- dèle proposé dans le chapitre7.
10.3.2 Analyse des résultats de vérification
Notre approche consiste à compiler le modèle dans un domaine exécutable au sein duquel on profite des outils disponibles pour exécuter, vérifier ou simuler le modèle. Ainsi, au même titre que le debugger d’un langage de programmation permet de visualiser, au cours de l’exécution, les informations du programme, il est souhaitable de pouvoir afficher les résultats des outils sur le modèle initial. Cependant, nous n’avons pas abordé dans cette thèse la problématique de l’analyse des résultats fournis par les outils réutilisés grâce à une sémantique par traduction. Cette problématique fait actuellement l’objet de nombreux travaux, qui abordent aussi bien la bidirection que la traçabilité des transformations de modèle. L’ap- proche qui nous semble la plus pertinente consiste à définir la sémantique par tra- duction non pas comme une transformation de modèle mais comme un modèle de lien [FBJ+05] entre la syntaxe abstraite du DSML source et celle du domaine cible. Un tel modèle pourrait être construit à partir d’un outil comme AMW (Atlas Model Weaver) [AMW07]. Un interpréteur dédié à la sémantique par traduction, mais gé- nérique à tous les DSML grâce à l’architecture introduite dans cette thèse, pourrait générer à partir d’un modèle de lien l’ensemble des transformations, dépendantes les unes des autres grâce à un modèle de trace (construit par certaines et utilisé par d’autres).
Cette approche permettrait de rendre transparente l’utilisation d’un formalisme différent pour la vérification formelle d’un modèle. Elle permettrait également de coupler la vérification (par compilation) et la simulation (par interprétation). En effet, le contre-exemple fourni par le model-checker pourrait être interprété comme une trace sur le modèle initial et ainsi être simulé, par exemple en mode pas à pas.
10.3.3 Extension du cadre de simulation
Les travaux que nous avons menés dans TOPCASED ont permis d’établir le prototype pour le premier périmètre de la simulation de machine à états UML2. Ces travaux sont actuellement poursuivis pour étendre le métamodèle d’UML2 pris en compte. Nous travaillons plus particulièrement sur le lien entre les machines à
états et le diagramme de classe afin de pouvoir instancier la même machine à états pour chaque objet d’une même classe.
La structuration de la syntaxe abstraite introduite dans cette thèse nous permet de bien distinguer les informations spécifiques à chaque instance de machine à états (celles du SDMM), des informations qui peuvent être partagées entre chaque ins- tance (celles du DDMM). Les premiers résultats obtenus sont présentés dans [Bez07].
10.3.4 Sémantique d’exécution avec création dynamique
Une des limites de nos travaux réside dans les sémantiques d’exécution pour lesquelles il y a, à l’exécution, modification de la structure du modèle. Nous nous sommes restreints aux sémantiques d’exécution où seule la valeur des informations dynamiques évolue. Par exemple, dansXSPEM, nous ne permettons pas de créer à l’exécution de nouvelles activités.
Nous avons choisi de nous restreindre à de telles sémantiques en raison des limitations imposées par les méthodes de model-checking et des difficultés ergo- nomiques pour l’animation graphique de modèles. Malgré tout, dans le cas d’une simulation en mode batch, il est intéressant de pouvoir étendre l’expressivité de l’approche afin de définir des sémantiques permettant la création dynamique. Par exemple, pour les machines à états UML2, il est souvent indispensable de créer dynamiquement de nouveaux objets, instanciant alors au cours de l’exécution de nouvelles machines à états à simuler.
10.3.5 Environnement de métamodélisation formelle
La cadre formel que nous avons défini permet d’exprimer la syntaxe abstraite et la sémantique statique des DSML. L’objectif majeur de ce travail est de fournir un environnement de métamodélisation formelle, qui peut facilement être étendu pour exprimer la sémantique d’exécution des DSML. C’est pour cela que nous avons fait le choix d’implanter ce cadre sous la forme d’une bibliothèque COQ et d’un langage de requête dont la syntaxe est proche d’OCL. Nous travaillons actuellement à l’extension de ce langage afin de pouvoir l’utiliser pour exprimer formellement la sémantique d’exécution.
Nous avons choisi d’étendre ce langage de requête à un langage de transforma- tion dédié pour l’expression de transformations endogènes sur la syntaxe abstraite des DSML. Nous pensons ainsi permettre l’expression formelle de la sémantique d’exécution sous la forme d’un système de transition couplé aux événements décris dans le EDMM. Cette sémantique pourrait être considérée comme la référence afin de valider la cohérence entre les différentes sémantiques (opérationnelle et par tra- duction) d’un même DSML. Il est également envisageable de l’utiliser pour géné- rer automatiquement différentes sémantiques opérationnelles, visant chacune une plateforme d’exécution et des besoins différents (p. ex. Kermeta, Java, etc.). Cette approche est illustrée sur la figure10.2.
10.3. ÉLARGISSEMENT DES RÉSULTATS 163
Operational Semantics Definition n Abstract Syntax Definition for Models Execution & Validation
Static Semantics Formalization (automatic) Abstract Syntax Formalization (automatic)
Operational Reference Semantics Definition & Formalization
Operational Semantics Definition FinishToStart FinishToStart FinishToStart Operational Semantics Definition 2 Operational Semantics Definition 1 Automatic Generation