Approche outillée pour la définition d’une sémantique

Nous avons montré dans ce chapitre qu’il était possible d’appliquer la taxono- mie des techniques pour exprimer une sémantique d’un langage de programmation à l’IDM et donc aux langages de modélisation. Chaque technique répond à des be- soins différents sur les modèles. D’autre part, les expérimentations montrent que le domaine de l’IDM et les outils actuellement disponibles sont assez mûrs pour être utilisés dans la description de la sémantique des DSML, sans recourir à un langage de programmation. C’est une étape indispensable qui prouve la pertinence des outils et des concepts introduits par l’IDM.

Malgré tout, la définition de la sémantique d’un langage (de programmation comme de modélisation) reste une tâche compliquée qui, dans un contexte où l’on préconise la définition de petits langages dédiés, est amenée à être répétée de mul- tiple fois. Afin d’aider le concepteur du langage, nous pensons qu’il est donc indis- pensable d’intégrer l’expression de la sémantique d’un DSML dans une démarche plus globale et outillée. Pour cela, nous introduisons dans la suite de cette thèse une démarche dans laquelle l’expression de la sémantique est fortement couplée à une structuration précise et générique de la syntaxe abstraite.

Par ailleurs, la multiplication des DSML nécessite un effort considérable pour fournir les moyens de valider et vérifier les modèles construits à partir de ces diffé- rents DSML. Pour cela, il semble pertinent de profiter de l’abstraction offerte par un DSML, en se concentrant uniquement sur le domaine considéré, afin d’offrir des outils génériques qui s’appuient sur la structure d’un DSML exécutable introduite dans cette thèse.

Enfin, au même titre que pour les langages de programmation, il est impor- tant de pouvoir vérifier la cohérence de plusieurs sémantiques d’un même DSML définies pour des besoins différents (simulation, vérification, etc.).

Deuxième partie

Contributions pour la simulation

& la vérification de modèle

Chapitre 5

Démarche outillée pour la

définition d’un DSML exécutable

La métamodélisation vise à définir les langages de modélisation à partir de modèles, appelés métamodèles. Comme nous l’avons vu dans le chapitre2, la dé- finition des différentes constructions du langage (sous la forme de concepts et de relations entre eux) est une tâche très proche de celle de la modélisation elle-même, en considérant le langage lui-même comme le système à modéliser.

Dans l’objectif d’exécuter les modèles construits, il est nécessaire d’explici- ter la sémantique d’exécution. Les expérimentations présentées au chapitre4pour exprimer la sémantique d’exécution d’un DSML ont montré que de nouvelles in- formations doivent être prises en compte. L’exécution d’un modèle correspond à le faire évoluer d’un état observable du système à un autre, conformément à la sémantique d’exécution définie. Lorsque l’on souhaite exécuter un modèle, il faut capturer les informations qui permettent d’appréhender son évolution. Cela corres- pond à pouvoir distinguer dans le modèle chacun des états possibles du système et ainsi pouvoir les présenter à l’utilisateur. En plus des informations structurelles du modèle, il est donc nécessaire de compléter la syntaxe abstraite par des informa- tions qui vont évoluer au cours de l’exécution. Par abus de langage, nous parlerons des informations dynamiques du modèle. Ces informations doivent être définies au niveau d’abstraction adéquat. En d’autres termes, elles doivent être nécessaires et suffisantes pour répondre aux questions que le concepteur se pose sur le sys- tème au cours de son exécution. Nous présentons pour cela, dans la section5.2, une approche outillée et basée sur le principe de substituabilité des modèles1dans laquelle les propriétés comportementales du système sont prises en compte pour déterminer le bon niveau d’abstraction des informations dynamiques.

Par ailleurs, nous nous concentrons dans cette thèse sur une des utilisations possibles de la sémantique d’exécution, qui consiste à pouvoir valider les modèles par simulation ou les vérifier à l’aide des techniques de model-checking. En plus de la définition des informations dynamiques et de la formalisation des propriétés

1. Le principe de substituabilité est présenté dans la section2.1de cette thèse.

temporelles que l’on souhaite vérifier, d’autres préoccupations sont à prendre en compte au niveau de la syntaxe abstraite. Il s’agit en particulier des différents types d’interaction possibles avec l’utilisateur (gérés par l’interface graphique dans nos expérimentations avec Kermeta) et la séquence particulière qui correspond à une certaine exécution du système. Ces préoccupations nécessitent d’être explicitées et structurées dans la syntaxe abstraite de manière à être capitalisées pour la mise en place d’outils génériques, support à l’exécution des modèles. Nous proposons dans la section5.3d’étendre la syntaxe abstraite pour prendre en compte ces nouvelles préoccupations.

Nous décrivons également une architecture générique pour construire de ma- nière structurée une syntaxe abstraite permettant de capturer l’exécution d’un mo- dèle et les informations dédiées à la validation dynamique des modèles.

La démarche est illustrée tout au long de ce chapitre par une des applications principales de nos travaux, la définition d’une extension exécutable de SPEM2.0, appeléeXSPEM.XSPEM permet de modéliser un procédé puis de l’exécuter de manière à le vérifier formellement ou l’animer graphiquement. Pour cela, nous avons dans un premier temps sélectionné les informations actuellement définies dans SPEM2.0 qui étaient pertinentes pour l’exécution d’un procédé (section5.1). Nous présentons ensuite, dans la section5.2, les moyens de définir au sein de la syntaxe abstraite l’ensemble des états possibles d’un procédé. La section5.3 dé- taille les autres préoccupations à prendre en compte pour la validation des modèles. Nous proposons dans la section5.4d’organiser l’ensemble de ces préoccupations selon une architecture générique. Enfin, nous discutons les apports de la démarche et de l’architecture générique dans la section5.5.

La définition d’un SPEM2.0 exécutable a fait l’objet d’une publica- tion dans la conférence internationale APSEC 2007 [BCCG07]. La démarche pour la définition d’un DSML exécutable a pour sa part été publiée dans la conférence internationale ICEIS 2007 [CGCT07] et a été retenue pour être éditée dans l’ouvrage Enterprise Information System, vol. IX[CCG+08a]. La structuration des différentes préoccu- pations a été publiée à ERTS 2008 [CCG+08b].

5.1

X

SPEM, une extension eXécutable de SPEM2.0

Dans l’ensemble du chapitre, nous illustrons la démarche proposée de manière à étendre la spécification de SPEM2.0 et ainsi prendre en compte l’exécution des procédés qui n’est actuellement pas adressée par le standard de l’OMG. Nous ap- pelons notre propositionXSPEM, pour eXecutable SPEM. Dans un premier temps, nous présentons dans cette partie les éléments de SPEM2.0 qui jouent un rôle dans l’exécution d’un procédé et que nous réutilisons donc dansXSPEM (section5.1.1). Nous introduisons également une première extension du standard permettant d’ap- pliquer un modèle de procédé à un projet particulier (section5.1.2). Enfin, nous illustrons par un exemple de modèle de procédé, les concepts structurels de l’in-

5.1. XSPEM, UNE EXTENSION EXÉCUTABLE DE SPEM2.0 81 génierie des procédés repris dansXSPEM (section5.1.3). A l’instar de Kurtev et al. [KBJV06], nous appelons DDMM (Domain Definition MetaModel) cette par- tie de la syntaxe abstraite du DSML.

Dans le document Approche de métamodélisation pour la simulation et la vérification de modèle. Application à l'ingénierie des procédés (Page 75-81)