Expériences pour décrire la sémantique en
ingénierie des modèles
Benoît Combemale** Sylvain Rougemaille*Xavier Crégut**
Frédéric Migeon*Marc Pantel** Christine Maurel*
*FéRIA - IRIT-LYRE, Université Paul Sabatier
118, route de Narbonne
F-31062 Toulouse Cedex 9
{sylvain.rougemaille, frederic.migeon, christine.maurel}@irit.fr
** FéRIA - IRIT-LYRE, INPT-ENSEEIHT
2, rue Charles Camichel, BP 7122
F-31071 Toulouse Cedex 7
{benoit.combemale, xavier.cregut, marc.pantel}@enseeiht.fr
RÉSUMÉ. L’Ingénierie Dirigée par les Modèles a permis plusieurs améliorations significatives
dans le développement de systèmes complexes en se concentrant sur une préoccupation plus
abstraite que la programmation classique. Cependant, il est encore nécessaire d’associer aux
éléments de modélisation une sémantique forte pour atteindre un niveau élevé de certifica-
tion tel que l’exigent actuellement les systèmes critiques. Dans ce cadre, cet article décrit
les moyens d’exprimer une sémantique, plus particulièrement opérationnelle, selon deux ap-
proches : l’utilisation d’un langage de méta-programmation, Kermeta, et l’utilisation d’un lan-
gage de transformation, ATL. Pour ces expérimentations, nous nous appuyons sur un méta-
modèle simplifié d’un Langage de Description de Procédé.
ABSTRACT. MDE has provided several significant improvements in the development of complex
systems by focusing on more abstract preoccupation than programming. However, more steps
are needed on the semantic side in order to reach high-level certification such as the one cur-
rently required for critical embedded systems. In this scope, we present mainly the description
of an operational semantics at the meta-model level, following two approaches, using a meta-
programming language such as Kermeta and a model transformation Language, ATL. We will
base our experimentations on a simple Process description Language metamodel.
MOTS-CLÉS : Ingénierie des Modèles, sémantique, OCL, ATL, Kermeta
KEYWORDS: Model Driven Engineering, semantics, OCL, ATL, Kermeta
18 IDM’06, Lille – Secondes Journées sur l’ingénierie des modèles
1. Introduction
L’Ingénierie Des Modèles (IDM) a permis d’établir une nouvelle approche, plus
abstraite, pour le développement de systèmes complexes. Un système peut être dé-
crit par différents modèles liés les uns aux autres. L’idée phare est d’utiliser autant
de modèles différents (ou Langages Dédiés – Domain Specific Languages) que les
aspects chronologiques ou technologiques du développement du système le néces-
sitent. La principale différence avec un programme est qu’un modèle se concentre sur
la syntaxe abstraite alors qu’un programme se concentre sur la syntaxe concrète. La
syntaxe abstraite se focalise sur les concepts fondamentaux du domaine et exprime
ainsi une sémantique à travers le vocabulaire choisi pour nommer les concepts. Pour
les systèmes orientés données, le niveau d’abstraction ainsi obtenu a conduit à des
améliorations significatives et semble correspondre à un niveau sémantique adéquat.
Pour les systèmes plus orientés calculs, les aspects dynamiques des modèles méritent
d’être encore approfondis.
Cette contribution porte sur des approches de définition de la sémantique des méta-
modèles en regard des travaux de la communauté des langages de programmation. Les
expériences présentées se sont déroulées dans le cadre du projet TOPCASED1(Farail
et al., 2006) dont le but est de fournir un atelier basé sur l’IDM pour le développe-
ment de systèmes logiciels et matériels embarqués. Les autorités de certification pour
les domaines d’application de TOPCASED (aéronautique, espace, automobile...) im-
posent des contraintes de qualification fortes pour lesquelles des approches formelles
(analyse statique, vérification du modèle, preuve) sont envisagées.
L’outillage de TOPCASED a pour but de simplifier la définition de nouveaux DSL
ou langages de modélisation en fournissant des technologies du méta-niveau telles
que des générateurs d’éditeurs syntaxiques (textuels et graphiques), des outils de va-
lidation statique et d’exécution des modèles. Cet article présente plusieurs approches
pour intégrer les considérations sémantiques des langages de programmation dans
une démarche IDM. Nous nous concentrons ici sur deux technologies pour créer des
modèles exécutables. Il s’agira dans un premier temps d’expérimenter le langage de
méta-programmation Kermeta (Muller et al., 2005) puis, dans un second temps, d’éta-
blir une sémantique opérationnelle à partir du langage de transformations de modèles
ATL (Atlas Transformation Language) (Bézivin et al., 2005). Nous terminerons par
un bilan de ces différentes expérimentations.
Pour illustrer notre approche, nous prendrons l’exemple d’un langage simplifié de
description de processus, SimplePDL (fig. 1), inspiré du standard SPEM (Obj 2005)
proposé par l’OMG. Ce langage définit le concept de processus (Process) composé
d’un ensemble d’activités (Activity) représentant les différentes tâches à réaliser durant
le développement. Une activité peut dépendre d’une autre (Precedes). Une contrainte
sur le démarrage ou la fin de la seconde activité est précisée : start-to-start,finish-to-
start et finish-to-finish (PrecedenceKind).
1. Officiel : www.topcased.org et développement : gforge.enseeiht.fr/projects/topcased-mm
Sémantique et IDM : expériences 19
Figure 1. Le méta-modèle Ecore de SimplePDL
2. Syntaxe des méta-modèles
2.1. Définition de la Syntaxe Abstraite
La syntaxe abstraite d’un langage de modélisation exprime, de manière structu-
relle, l’ensemble de ses concepts et leurs relations. Les langages de méta-modélisation
tels que le standard de l’OMG MOF (Obj 2003a), offrent les concepts et relations élé-
mentaires en termes desquels il est possible de décrire un méta-modèle représentant
cette syntaxe abstraite. Nous disposons, à ce jour pour définir cette syntaxe, de nom-
breux environnement et langages de méta-modélisation : Eclipse-EMF/Ecore (Bu-
dinsky et al., 2003), GME/MetaGME(Ledeczi et al., 2001), AMMA/KM3 (ATLAS,
2005) ou XMF-Mosaic/Xcore (Clark et al., 2004).
Pour définir la syntaxe abstraite de SimplePDL, nous avons utilisé l’éditeur gra-
phique Ecore du projet TOPCASED permettant la description de méta-modèles à
l’aide du langage de méta-modélisation Ecore d’EMF. Nous avons défini le méta-
modèle de SimplePDL comme le montre la figure 1. Ce méta-modèle représente le
point de départ de nos expérimentations. Il sera utilisé comme support pour les di-
verses expériences que nous présentons ici. En premier lieu, nous désirons donner une
syntaxe concrète à SimplePDL, afin de pouvoir en créer des modèles conformes.
Cette forme est semblable à la sémantique de construction des arbres abstraits à
partir des arbres de syntaxe concrète pour les langages de programmation.
2.2. Définition de la Syntaxe Concrète
La syntaxe concrète d’un langage fournit un formalisme, graphique ou textuel,
pour manipuler les concepts de la syntaxe abstraite et ainsi en créer des « instances ».
Le modèle ainsi obtenu sera conforme au méta-modèle de la syntaxe abstraite. La
définition d’une syntaxe concrète ad’hoc est à ce jour bien maîtrisée et outillée. Il
20 IDM’06, Lille – Secondes Journées sur l’ingénierie des modèles
<<Diagram>>
Process
<<Node>>
Activity
<<Node>>
Guidance
<<Edge>>
GuidanceLink
<<Edge>>
Precedes target
source
Figure 2. Modèle de configuration
existe en effet de nombreux projets qui s’y consacrent, principalement basés sur EMF
(Eclipse Modeling Framework) : GMF2, Merlin Generator3, GEMS4, TIGER (Ehrig et
al., 2005), etc. Cependant, le défi actuel réside dans l’automatisation de cette concré-
tisation de la syntaxe. L’idée est de générer automatiquement une syntaxe concrète à
partir d’une syntaxe abstraite donnée (Ledeczi et al., 2001, Clark et al., 2004). Cette
approche générative, en plus de ses qualités de généricité, permettrait de normaliser la
construction des syntaxes concrètes.
TOPCASED propose un outil appelé le « générateur d’éditeur graphique » qui
permet, pour un modèle Ecore donné, de définir une syntaxe concrète graphique et
l’éditeur associé. Cette génération d’éditeur, s’appuie sur le résultat de la génération
de syntaxe textuelle (XML) fournie par EMF (Budinsky et al., 2003) et consiste à défi-
nir une correspondance entre les éléments du formalisme graphique (syntaxe concrète)
et le modèle Ecore (syntaxe abstraite). Tout ceci est décrit dans le modèle de confi-
guration (configurator) qui offre une grande liberté de personnalisation des éléments
graphiques de la syntaxe concrète souhaitée. Dans TOPCASED, il a été utilisé pour
engendrer les éditeurs pour Ecore, UML2, AADL5et SAM (formalisme à base d’au-
tomates hiérarchiques utilisé par Airbus).
Pour SimplePDL, nous avons défini en premier lieu le modèle de notre syntaxe
concrète (la figure 2 en présente une version simplifiée). Activity et Guidance sont
définies comme Node (boîtes). Precedes est définie comme Edge, une relation entre
deux boîtes. Process est représentée comme Diagram qui correspond à un paquetage
qui contiendra les autres éléments. Définir la syntaxe concrète d’un langage peut né-
cessiter l’emploi d’éléments additionnels ne correspondant à aucun concept abstrait.
Par exemple, ici il est indispensable d’ajouter GuidanceLink comme Edge pour relier
une Guidance à une Activity.GuidanceLink ne correspond pourtant à aucun concept
de SimplePDL. Sa présence est cependant obligatoire pour lier un élément graphique
Guidance à la boîte représentant l’activité qu’il décrit. Il se traduit par l’EReference
appelée guidance de Activity (fig. 1). Il faut noter que les concepts de la syntaxe abs-
traite (fig. 1) et ceux de la syntaxe concrète (fig. 2) sont des concepts différents qui
2. Generic Modeling Framework, http://www.eclipse.org/gmf/tutorial/
3.http://sourceforge.net/projects/merlingenerator/
4. Generic Eclipse Modeling System, http://sourceforge.net/projects/gems/
5. Architecture Analysis and Design Language, http://www.aadl.info/
Sémantique et IDM : expériences 21
Figure 3. Extension du méta-modèle pour la description de la syntaxe concrète
Figure 4. Éditeur généré, syntaxe concrète graphique de SimplePDL
doivent être mis en correspondance. Nous avons employé les mêmes noms quand la
correspondance était évidente.
Pour pouvoir utiliser le générateur d’éditeur TOPCASED, nous avons dû ajouter
deux références (composition), entre Process et Guidance et entre Process et Precedes
(fig. 3), à notre syntaxe abstraite initiale (fig. 1). Elles sont nécessaires pour pouvoir
placer graphiquement une Activity et une Guidance dans un Processus.
La figure 4 présente l’éditeur engendré. Tous les concepts du modèle de configu-
ration sont présents dans la palette. Sélectionner un élément de la palette et le déposer
sur le diagramme crée un élément graphique (node ou edge) et instancie, selon le
modèle de configuration, la méta-classe correspondante du méta-modèle SimplePDL.
Dans le cas d’un « trait », le modèle de configuration permet de préciser sa représenta-
1 / 18 100%
La catégorie de ce document est-elle correcte?
Merci pour votre participation!

Faire une suggestion

Avez-vous trouvé des erreurs dans linterface ou les textes ? Ou savez-vous comment améliorer linterface utilisateur de StudyLib ? Nhésitez pas à envoyer vos suggestions. Cest très important pour nous !