sé-mantique pour un DSML et les moyens de la définir au sein d’un métamodèle. Nous proposons pour cela une discussion au regard des travaux de la communauté des langages de programmation et des techniques utilisées. Nous mettons plus par-ticulièrement l’accent sur les sémantiques permettant d’exécuter un modèle en vue de l’animer, le simuler ou le vérifier dynamiquement. Nous illustrons ensuite ces différentes techniques à travers des expérimentations pour définir la sémantique d’exécution d’un langage simple de modélisation de processus : SIMPLEPDL. Ces expérimentations permettent d’évaluer les différences entre les approches et d’in-troduire les outils qui peuvent être utilisés pour les mettre en œuvre. Un bilan de ces expérimentations et une discussion sur leurs mises en œuvre concluent ce chapitre et permettent de préciser la problématique de cette thèse.
La taxonomie des sémantiques ainsi que les différentes mises en œuvres et discussions ont fait l’objet d’une publication au sein de la confé-rence francophone IDM 2006 [CRC+06a] et dans le workshop inter-national MDEIS 2006 [CRC+06b].
4.1 Taxonomie des sémantiques dans l’IDM
La sémantique des langages de programmation est formalisée depuis de nom-breuses années et il semble pertinent de profiter de l’expérience acquise pour ex-plorer les moyens d’exprimer la sémantique des langages de modélisation. La sé-mantique d’un langage définit de manière précise et non ambiguë la signification des constructions de ce langage. Elle permet ainsi de donner un sens précis aux programmes construits à partir de celui-ci. On dit qu’une sémantique est formelle lorsqu’elle est exprimée dans un formalisme mathématique et permet de vérifier la cohérence et la complétude de cette définition. On distingue la sémantique sta-tiquequi correspond à des propriétés indépendantes de l’exécution ou valables pour toutes les exécutions. Celle-ci est en général vérifiée statiquement lors de la compi-lation des programmes (et exprime des règles, comme le typage, qui ne peuvent pas être exprimées par la syntaxe) et la sémantique dynamique (ou comportementale) qui permet de décrire le comportement des programmes à l’exécution. Pour aller de la plus concrète à la plus abstraite, une sémantique comportementale peut être opérationnelle, dénotationnelle ou axiomatique [Win93]. Une sémantique opéra-tionnelledonne une vision impérative en décrivant un programme par un ensemble de transitions (ou transformations) entre les états du contexte d’exécution (p. ex. de la mémoire). Une sémantique dénotationnelle décrit, sous forme de fonctions, l’effet d’un programme et non la manière dont celui-ci est exécuté. Une sémantique axiomatiquepropose une vision déclarative en décrivant l’évolution des caractéris-tiques d’un élément lors du déroulement d’un programme.
Par analogie avec l’approche suivie pour les langages de programmation, le défi actuel dans l’IDM consiste à donner les moyens d’exprimer une sémantique précise pour les concepts de la syntaxe abstraite des langages de modélisation (de
int x; void decr () { if ( x>0 ) x = x − 1; } (a) Programme decr() x : Int System (b) Modèle
FIGURE4.1: Fonction decr
manière à pouvoir en exécuter les modèles). Tel que nous avons défini un DSML (cf. section2.2), l’expression d’une sémantique correspond à définir un mapping de chaque état du modèle, capturé par la syntaxe abstraite, vers un domaine séman-tique qui définit l’ensemble des états possibles du système. Dans le contexte de l’IDM, cette fonction prend naturellement la forme d’un modèle (cf. Mas, figure
2.4) et il est donc indispensable d’étudier le langage de modélisation adéquat pour le définir. Notons que ce langage (La2s) doit permettre de manipuler à la fois la syntaxe abstraite du DSML considéré et celle du domaine sémantique choisi. Cette propriété peut être formalisée de la manière suivante : LAS, LSD⊆ La2s[HR04].
On peut classer les différentes sémantiques selon les catégories définies pour les langages de programmation (sémantique axiomatique, dénotationnelle et opé-rationnelle), et appliquer celles-ci selon les besoins (vérification de modèle, anima-tion de modèle, etc.) et les outils disponibles. Nous les présentons dans la suite de cette partie en les illustrant à travers l’exemple simple de la fonction decr dont le programme et un de ses modèles sont fournis sur la figure4.1. Ce programme décrit une fonction qui décrémente de un la valeur de x à condition qu’elle soit stricte-ment positive. Nous exprimons par la suite la sémantique selon les trois niveaux d’abstraction cités.
La sémantique axiomatique ainsi que la sémantique statique (également appe-lée context condition par l’OMG et correspondant à une sémantique axiomatique très simple pouvant être vérifiée statiquement11) peuvent être exprimées sur la syntaxe abstraite, soit à l’aide du langage de métamodélisation lui-même (p. ex. les multiplicités) soit en la complétant de contraintes exprimées à l’aide d’un lan-gage comme OCL (invariant, pré- ou post-condition). Les pré- et post-conditions supposent d’avoir identifiées des opérations sur le modèle. Une spécification axio-matique de la sémantique de la fonction decr peut, par exemple, être définie par la propriété OCL donnée sur le listing4.1.
Listing 4.1: Sémantique axiomatique de la fonction decr context System::decr ()
post : self .x = if ( self .x@pre > 0 ) then
11. Notons qu’en UML il est possible d’exprimer des propriétés OCL portant sur des séquences d’envois de messages. Cependant, ces propriétés ne sont pas vérifiées par les vérificateurs OCL car elles nécessitent la formalisation de la sémantique d’exécution du langage, par exemple UML, et la mémorisation de la trace d’exécution
4.1. TAXONOMIE DES SÉMANTIQUES DANS L’IDM 59 self .x@pre − 1
else
self .x@pre endif
Les sémantiques opérationnelle et dénotationelle peuvent également être expri-mées pour un DSML et correspondent toutes les deux à la définition d’un mapping vers un domaine sémantique. Dans le cadre de nos travaux, nous différencions dans l’IDM ces deux types de sémantique d’exécution de la manière suivante.
La sémantique opérationnelle s’exprime sur une représentation abstraite iden-tique à celle de la syntaxe abstraite du langage considéré. Elle est dans ce cas exprimée sur des concepts instanciés à partir des paradigmes utilisés pour la défi-nition de la syntaxe abstraite (dans notre cas, les concepts de métamodélisation). Ces concepts sont dénués de sémantique mais un langage d’action permet de l’ex-primer et ainsi de définir les outils support à l’exécution. Un tel langage permet de décrire l’évolution du modèle et de produire, à partir d’un état donné, un ou plusieurs autres états (dit successeurs). Dans le contexte des langages naturels, une sémantique opérationnelle revient à manipuler une phrase (le plus souvent menta-lement), dans la même langue que celle utilisée pour l’écrire initialement. On lui donne dans ce cas un sens selon l’expérience acquise (propre à chacun). De ma-nière plus formelle, notons qu’une sémantique opérationnelle est, par définition, fortement bisimilaire12au système de transition de référence du système. En effet, la représentation abstraite sur laquelle elle est exprimée étant identique à la syn-taxe abstraite du langage, chaque état exprimé par la sémantique opérationnelle est observable par le système de transition de référence.
Pour l’exemple de la fonction decr, la sémantique opérationnelle peut être spé-cifiée de la manière suivante : Z 7→ Z tel que x 7→ if(x > 0)?x − 1 : x. Le domaine sémantique choisi dans ce cas correspond à Z.
La sémantique dénotationnelle s’exprime sur une représentation abstraite dif-férente de celle définie dans la syntaxe abstraite du langage considéré. Les pa-radigmes utilisés sont fixes et sémantiquement bien définis. Ils sont adaptés à la construction d’outils efficaces pour le support de l’exécution (p. ex. des outils de model-checking). Dans le contexte des langages naturels, cela revient à interpréter une phrase dans une langue différente que celle dans laquelle elle a été initialement écrite. L’expression de la sémantique correspond à trouver alors une traduction dans la nouvelle langue pour que la phrase garde le même sens. De manière plus formelle et par expérience, le domaine choisi est alors faiblement bisimilaire au système de transition de référence du système. Il est alors nécessaire de retrouver les états que l’on souhaite observer dans le formalisme initial. Ce type de séman-tique correspond dans l’IDM à une sémanséman-tique par traduction qui définit un lan-gage par sa transformation vers un autre lanlan-gage formellement défini [CESW04]. Nous utilisons dans la suite de ce mémoire cette terminologie.
Une sémantique par traduction de la fonction decr peut correspondre à la fonc-12. Selon la définition de la bisimulation donnée dans [Mil95].
tion qui traduit ce programme dans un domaine formel tel que les réseaux de Pe-tri [Rei85]. Une telle fonction pourrait alors fournir le réseau suivant pour la fonc-tion decr, où la valeur de x est représentée par le marquage de la place de même nom :
decr x
Les réseaux de Petri ayant une sémantique formelle, le programme prend alors le sens du réseau de Petri généré.
Nous nous concentrons dans la suite de cette thèse sur la notion de sémantique d’exécutionqui permet de donner un caractère opératoire à un DSML. Le méta-modèle est alors dit exécutable et permet de faire évoluer les méta-modèles qui lui sont conformes au cours d’une exécution conformément à la sémantique du langage. Nous nous restreignons pour cela à l’étude des sémantiques opérationnelles et par traduction vers un domaine sémantique opérationnel.
Nous présentons dans les sections suivantes les technologies actuellement dis-ponibles dans la communauté de l’IDM pour définir les différents types de sé-mantique décrits précédemment. Pour les illustrer, nous nous appuyons sur SIM-PLEPDL, un langage simplifié de modélisation de processus dont les syntaxes (abs-traite et concrète) ont été définies dans le chapitre2. Dans cet exemple, l’exécution d’un processus consiste à réaliser toutes les activités qui le composent. Le proces-sus est dit terminé quand toutes ses activités sont terminées. Une activité ne peut être commencée que si les activités dont elle dépend sont commencées (précé-dence start-to-start) ou terminées (précé(précé-dence finish-to-start). Au fur et à mesure du développement, le taux de réalisation d’une activité augmente jusqu’à ce qu’elle soit terminée. Elle ne peut être terminée que si les activités précédentes de type finish-to-finish sont terminées et les activités précédentes de type start-to-finish sont commencées. Ce sont les équipes de développement qui décident de quelle activité commencer, continuer (i.e. augmenter le taux d’avancement) ou terminer.