MODEL DRIVEN OPERATIONAL SEMANTICS

Institut de la Francophonie pour
l’Informatique

Institut de Recherche en Informatique et
Système Aléatoire

MODEL DRIVEN OPERATIONAL
SEMANTICS
Rapport de Stage

PHAM Quang-Hieu

Sous la direction de

Jean-Marc JEZEQUEL
Directeur de Recherche
Projet TRISKELL

Mars – Août 2008


Remerciements
Je tiens à remercier tout particulièrement Jean-Marc JEZEQUEL, responsable de
l’équipe TRISKELL à l’IRISA, de m’avoir accueilli dans ce équipe et de m’avoir
aidé durant ce stage.
Je remercie Cyril FAUCHER, Gilles PERROUIN, Didier VOJTISEK et Vincent
MAHE pour les conseils précieux qu’ils m’ont fournis pendant les 5 mois de
stage.
Je tiens également à remercier tous les enseignants-chercheurs, doctorants et
stagiaires de l’équipe TRISKELL, avec qui j’ai eu le plaisir de travailler, pour les
discussions scientifiques fructueuses que j’ai pu avoir avec eux.

2


Table des matières
INTRODUCTION ............................................................................................................................... 5
PRESENTATION DE L’IRISA......................................................................................................... 8
2.1 L’IRISA ......................................................................................................................................... 8
2.2 L’EQUIPE TRISKELL ..................................................................................................................... 9
CONTEXTE DU STAGE.................................................................................................................. 11
3.1 MODEL-DRIVEN ENGINEERING ...................................................................................................... 11
3.1.1 Développement logiciel ......................................................................................................... 12
3.1.2 Activité de modélisation ........................................................................................................ 13
3.1.3 Transformation de modèles ................................................................................................... 15
3.2 DOMAIN-SPECIFIC LANGUAGES ..................................................................................................... 17
3.2.1 Introduction.......................................................................................................................... 17
3.2.2 Domain-Specific Modelling Languages ................................................................................. 18
3.3 CONCLUSION ................................................................................................................................ 20
L’ETAT DE L’ART ............................................................................................................................ 21
4.1 STRUCTURES MODULAIRES DE SEMANTIQUE OPERATIONNELLE (MODULAR SOS)........................... 21
4.1.1 Structural Operational Semantics (SOS)............................................................................... 22
4.1.2 Problème de modularité dans la SOS.................................................................................... 23
4.1.3 Modular SOS – a variant of SOS .......................................................................................... 25
4.2 LANGAGE DE META-MODELISATION KERMETA ............................................................................ 27
4.2.1 Contexte ............................................................................................................................... 27
4.2.2 Processus de construction de Kermeta................................................................................... 27
4.2.3 Architecture de Kermeta ....................................................................................................... 28
4.2.4 Utilisation du langage Kermeta............................................................................................. 29
4.3 LE TYPAGE DES MODELES (MODEL TYPING).................................................................................. 30
4.3.1 Contexte ............................................................................................................................... 30

4.3.2 Système de types ................................................................................................................... 31
4.3.3 Type de modèles.................................................................................................................... 32
4.3.4 Typage de modèles................................................................................................................ 32
4.4 CONCLUSION ................................................................................................................................ 36
ETUDE DE CAS : MODULAR SOS DE WREN ......................................................................... 37
5.1 INTRODUCTION LE LANGAGE WREN ............................................................................................... 37
5.2 SPECIFICATION DE SOS ................................................................................................................. 39
5.2.1 Syntaxe Abstraite de Wren..................................................................................................... 39
5.2.2 SOS règles pour l’évaluation des expressions ........................................................................ 39
5.2.3 SOS règles pour des commandes ........................................................................................... 41
5.3 SPECIFICATION DE MSOS.............................................................................................................. 42
5.3.1 Définition la structure de Label............................................................................................. 42
5.3.2 MSOS règles pour l’évaluation des expressions..................................................................... 43
5.3.3 MSOS règles pour les commandes......................................................................................... 44
IMPLEMENTATION DE WREN SOUS KERMETA ................................................................ 45
6.1 ABSTRACT SYNTAXIQUE MODEL ................................................................................................... 45
6.2 SEMANTIQUES DYNAMIQUES ......................................................................................................... 46

3


6.3 IMPLEMENTATION DE L’INTERPRETEUR .......................................................................................... 47
6.3.1 Charger des modèles............................................................................................................. 48
6.3.2 Exécuter les modèles............................................................................................................. 49
6.3.3 Résultat ................................................................................................................................ 49
6.4 EVOLUTION DU LANGAGE WREN .................................................................................................. 50
6.4.1 Ligne de produit Wren .......................................................................................................... 50
6.4.2 Extensions de données........................................................................................................... 51
6.4.3 Extensions d’opération.......................................................................................................... 52
6.4.4 Combinaison les extensions................................................................................................... 55

6.5 CONCLUSION ................................................................................................................................ 56
CONCLUSION ET PERSPECTIVE .............................................................................................. 58
7.1 CONCLUSION ................................................................................................................................ 58
7.2 PERSPECTIVE ................................................................................................................................ 59
RÉFÉRENCES................................................................................................................................... 62

4


Chapitre 1
Introduction

Aujourd’hui, la taille et la complexité des logicielles développés
augmentent de plus en plus rapidement alors que les contraintes de temps de
développement, de qualité, de maintenance et d’évolution sont toujours plus
fortes, les systèmes d’information deviennent être distribués plus en plus
largement. Dans ce contexte, les techniques de génie logiciel sont contraintes à
évoluer sans cesse pour permettre de gérer la complexité et d’assurer la qualité du
logiciel produit.
Pour faire face à cette évolution rapide et croissante des applications
logicielles, l’Ingénierie Dirigée par des Modèles (IDM) ou Model-Driven
Engineering (MDE) ouvre de nouvelles voies d’investigation. Les grandes
tendances actuelles de l’IDM sont l’utilisation de langages dédiés (DomainSpecific Languages), les approches orientées aspects et les approches à base de
composants. Un des points communs à ces approches est l’utilisation de modèles
pour permettre une montée en abstraction par rapport aux langages de
programmation.
Dans ce cadre, un modèle n’est plus une simple image ou un élément de
conception ou de documentation, mais bien un élément productif qui doit pouvoir
être traité automatiquement. L’idée de l’IDM est de les traiter comme des entités
centrales dans le développement logiciel. Ce nouveau processus de développement

procède par des transformations de modèles pour compéter, enrichir, préciser un
modèle métier initial avec les nombreux aspects plus directement liés à
l’environnement, la plateforme, les performances,… Ainsi les modèles simplifient
5


la vision d’un système en permettant de représenter, de manière abstraite, un
aspect du logiciel, et une transformation permet ensuite d’intégrer cet aspect dans
le modèle global du logiciel en développement. La combinaison de ces deux
entités permet le développement simplifié de systèmes fiables, mêmes complexes.
D’ailleurs, la définition des langages dédiés entraîne l’application des
technologies de meta-modélisation à générer et intégrer sémantiquement des
langages riches et outils destinés des exigences de modélisation spécifique. Le but
est de fournir aux développeurs les abstractions raisonnables de modélisation pour
que ils puissent isoler le problème de domaine spécifique à partir les détails
d’implémentation.
Actuellement, le développement des langages variétés nécessite la
réutilisation et l’augmentation de la modularité dans la conception et la
spécification des langages. Tandis que les méta-modèles sont utilisés bien à définir
la syntaxe abstraite et sémantiques statiques des langages dédiés, la pratique
courant de la spécification de sémantique opérationnelle n’augmente pas encore
bien la modularité. Pour cette étude, nous nous intéressons à la technique de
définition de la spécification de sémantiques opérationnelle pour augmenter la
modularité.
Le but du stage que j’effectue dans l’équipe Triskell (IRISA/INRIA) est
d’étudier la modularité dans la définition des sémantiques des langages dédiés,
l’emprunt des idées de structures modulaires de sémantique opérationnelle
(Modular Structural Operational Semantics) et puis de s’appuyer sur les progrès
récents de Typage des Modèles (Model Typing).
La démarche devrait permettre de définir des constructions individuelles de

la sémantique opérationnelle comme les petits blocs qui pourraient facilement être
étendu et combinés pour construire non triviales familles de langues dans le
domaine des logiciels embarqués.
La suite de ce rapport est organisée de la façon suivante. Tout d’abord, le
chapitre 2 présente brièvement l’IRISA et l’équipe Triskell où je travaille durant
mon stage. Le chapitre 3 rappelle le contexte dans lequel se place mon stage.
L’objectif de ce chapitre est d’introduire les langages dédiés, l’ingénierie des
modèles et d’exprimer le rôle des modèles dans le développement des langages
dédies. En suite, dans le chapitre 4, je présente un travail bibliographique sur les
structures modulaires de sémantique opérationnelle, les langages de métamodélisation en présentant le langage KERMETA et l’idée principale du typage
des modèles. Le chapitre 5 présente le langage simple WREN comme mon étude
de cas et illustre comment spécifier des structures modulaires de sémantique
opérationnelle pour le WREN. Et puis, dans le chapitre 6, je présente
l’implémentation d’un interpréteur du WREN sous KERMETA. Ce chapitre
exprime comment construire des composants individuels de la sémantique
opérationnelle de WREN en utilisant KERMETA pour qu’on puisse faciliter les
6


étendre et les réutiliser pour construire une famille des langages associés au
WREN. En fin, le chapitre 7 conclut ce travail et propose quelques perspectives.
Les documents que je les consulte durant le stage sont énumérés dans la section de
référence à la fin de ce rapport.

7


Chapitre 2
Présentation de l’IRISA

2.1 L’IRISA

L’Institut de Recherche en Informatique et Système Aléatoire (IRISA) est
situé sur le campus Universitaire de Beaulieu à Rennes. Cet institut de recherche
est un pôle de recherche public regroupant environ 530 personnes dont 205
chercheurs ou enseignants chercheurs, 175 chercheurs en thèse, 90 ingénieurs,
techniciens, administratifs et de nombreux collaborateurs contractuels ou invités
internationaux pour des séjours de plus courte durée. L’INRIA, le CNRS,
l’Université de Rennes 1 et l’INSA de Rennes sont les partenaires de cette unité
mixte de recherche.
Les travaux de recherche dans cet institut se développent au sein d’une
trentaine d’équipes de recherche et autour de grands thèmes scientifiques tels que :
- Systèmes communicants
- Systèmes cognitifs
- Systèmes symboliques
- Systèmes numériques
- Systèmes biologiques.
Ces thèmes génériques se déclinent dans de nombreux domaines
d’application, sources de collaborations avec d’autres acteurs tant du monde
8


académique qu’industriel. Citons les télécommunications, le multimédia et les
technologies avancées pour la santé.
Les missions essentielles de cet institut sont d’une parte de conduire des
recherches dont l’excellence scientifique est attestée par des publications et des
échanges internationaux, et d’autre part d’assurer la diffusion des connaissances et
du savoir-faire, en particulier auprès de ses partenaires industriels, des PME-PMI
régionales, regroupées dans le club Irisatech, aux structures de recherche et
développement de grands groupes industriels mondiaux. La dimension

européenne, par la participation des équipes de recherche aux programmes
européens (actuellement FP6-IST) est fortement présente. En complément, ce
laboratoire s’investit dans la démarche d’incubation d’entreprises lancée tant par
INRIA-Transfert sur le plan national que par l’incubateur Emergys en Bretagne.
L’Irisa, en relation étroite avec l’Institut de formation supérieure en
informatique et communication (Ifsic), l’école doctorale Matisse de l’Université
de Rennes 1 et l’INSA de Rennes, l’antenne de Bretagne de l’ENS-Cachan,
participe activement à la formation par et pour la recherche.
J’ai effectué mon stage au sein du projet TRISKELL que je vais maintenant
présenter.

2.2 L’Equipe TRISKELL
Le projet Triskell est une équipe de recherche au sein
de l'IRISA . Ce projet Triskell est dirigé par M. Jean-Marc
JEZEQUEL. Une vingtaine de personnes (EnseignantsChercheurs, Post-Doctorants, Doctorants, Ingénieurs,…)
travaillent pour ce projet.
Le thème de l'équipe est la construction fiable et efficace d'applications par
assemblage de composants logiciels. Les domaines abordés par l'équipe sont :
Ingénierie des modèles
Manipulation formelle de modèles UML
Conception par contrat avec composants et aspects
Vérification et Validation intra et intercomposants
Le projet a pour objectif général la construction fiable et économiquement
efficace de lignes de produits par assemblage de composants logiciels, en
particulier dans le domaine des systèmes répartis et réactifs ayant des temps de
réponse statistiquement contraints ("temps réel mou").

9

Se focalisant sur l'ingénierie des modèles, Triskell a pour ambition de
construire des méta-modèles, des outils et des bibliothèques de composants
spécifiques pour donner à un concepteur de logiciel un certain niveau de confiance
dans la fiabilité d'assemblages de composants pouvant provenir de sources tierces.
Il s'agit notamment d'étudier des modèles permettant la spécification de propriétés
à la fois fonctionnelles et non-fonctionnelles de composants devant être déployés
sur des systèmes répartis, et de bâtir un continuum d'outils tirant partie de ces
éléments de spécification, allant de vérificateurs hors-ligne à des moniteurs
supervisant en ligne le comportement des composants d'une application répartie.
Le projet a également pour ambition de connecter de manière explicite les
résultats de ses recherches aux problématiques industrielles au travers d'actions de
transfert technologique, ce qui implique en particulier de prendre en compte dès le
départ les standards industriels du domaine que sont UML, Corba, COM+ et
Enterprise JavaBeans. Triskell veut se placer à la frontière de deux domaines du
logiciel : d'une part le domaine de la spécification et de la preuve formelle de
logiciel, et d'autre part le domaine de la conception informelle mais structurée par
composants banalisés. Nous pensons que l'emploi des techniques présentées plus
loin permettra d'améliorer et de fiabiliser le passage entre formel et informel, et
contribuera à la fluidité des processus de conception, mise en oeuvre et test de
logiciels.
Au sein de cette équipe, j’ai travaillé dans le domaine d’Ingénierie des
Modèles, notamment sur la définition des structures modulaires de sémantique
opérationnelle en utilisant Kermeta. Ce domaine est un axe de recherche principal
au sein de l’équipe, il y a plusieurs travaux en cours de réaliser autours de
Kermeta.

10


Chapitre 3

Contexte du Stage

L’Ingénierie Dirigée par les 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écessitent. 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.
L’objectif de ce chapitre est d’introduire le contexte du sujet de stage,
d’abord d’un survol de l’IDM, avec les notions de modélisation et de
transformation des modèles, puis de présenter les langages dédiés du point de vue
de l’IDM.

3.1 Model-Driven Engineering
L’Object Management Group (OMG) a défini des approches du génie
logiciel dans la volonté de faire ressortir la séparation des préoccupations ainsi que
l’interopérabilité. L’une d’elles est le Model-Driven Architecture qui est une
architecture proposant des directives pour structurer des spécifications définies
comme des modèles. Pour cela cette approche décompose l’activité de
développement logiciel en trois étapes : modèle indépendant des plates-formes (et
11


technologies) (PIM), modèle spécifique à une technologie (PSM) et enfin le code
en tant que tel [Ken02]. En ce sens, l’OMG a adopté la maxime tout est modèle
plutôt que tout est objet.

3.1.1 Développement logiciel

Figure 3.1.1 : Exemple de transformation de l’abstraction au code

Pour améliorer le développement d’un système d’information, l’OMG a
défini une approche nécessitant des modèles de deux types : les modèles abstraits
indépendants de toutes technologies et les modèles spécifiques à une plate-forme.
Ces deux types de modèles sont définis comme suit [Ken02] :
• PIM spécification formelle de la structure et de la fonctionnalité d’un
système dont il faut omettre tous les détails techniques ;

12


• PSM réalisation spécifique à une plate-forme des fonctionnalités du
PIM dont il est issu via des transformations.
Il est à noter que le but de ces modèles est de permettre de générer du code
à partir d’un PSM issu d’un PIM après transformation (cf figure 3.1.1).
Dans la plupart des cas il faut quand même compléter le code généré car tout n’est
pas modélisable même à l’échelle des PSM, de plus dans certains cas il sera
préférable de ne pas faire de génération afin de permettre à l’équipe de
développement de rendre le code plus maintenable. Même si le modèle PIM peut
servir de documentation dans une certaine mesure.

3.1.2 Activité de modélisation
Afin de bien structurer l’activité de modélisation des systèmes
d’informations, l’OMG a défini des standards de modélisation afin de permettre le
support des modèles dans les différents environnements de modélisation tel que le
Unified Modeling Language (UML) et le Meta Object Facility (MOF).

Afin d’unifier les méthodes de développement, L’OMG a défini dans le
MOF quatre couches de modélisation afin de permettre l’interopérabilité entre les
modèles (cf Figure 3.1.2) :

Figure 3.1.2 : Pile à quatre couches du MOF

Il s’agit d’une vision de la modélisation, méta-modélisation donnée par
l’OMG qui peut-être vue comme une formalisation d’approches déjà existantes
[BBB+04]. On peut par exemple mettre au niveau M3 EBNF (Extended BackusNaur Form) qui est utilisé pour écrire la grammaire d’un langage comme C
(niveau M2) : au niveau M1 on aurait alors des programmes écrits en C, et au
niveau M0 les exécutions spécifiques de ces programmes [Béz01].
Cela n’est pas restreint au domaine de l’informatique : une carte par
exemple est le modèle d’une région géographique particulière, sa légende est le
métamodèle de la carte. [BBB+04]

13


Les modèles, métamodèles et méta-métamodèles sont des concepts de base
de l’ingénierie des modèles. La partie suivante présente leurs définitions et les
relations qui existent entre ces concepts.
Les modèles : Un modèle est avant tout une représentation d’un système à étudier,
mais un modèle ne sert ` a rien s’il n’a pas de but, donc un modèle doit être défini
pour un usage particulier.
Il doit aussi être le moyen de communication des idées dans une
communauté de développement, car il est toujours plus facile de comprendre une
représentation d’un système que le système en lui même. Il doit donc être clair
mais peut être incomplet car il ne sert pas à représenter le système dans son entier
[MCF03].
Un modèle permet d’abstraire les entités qui vont exister en évitant de

décrire ce qui n’est pas utile au système étudié [FR03].
Le MOF doit permettre de manipuler les modèles selon les besoins des
utilisateurs, et donc il doit pouvoir autoriser la transformation d’un modèle en
d’autres plus spécifiques via des transformations qui doivent avoir la propriété
d’être avant tout réutilisable pour éviter de devoir les redéfinir à chaque
changement dans le modèle. Les transformations sont de toutes sortes et peuvent
permettre de transformer les modèles abstraits en modèles concrets (PIM =>
PSM), ainsi que de passer d’un type de modèle à un autre.
La couche modèle se trouve très bas dans l’architecture du MOF (juste au
dessus de la couche des données, cf Figure 3.1.2), elle est donc très dépendante
des niveaux supérieurs car un modèle ne peut avoir de portée plus grande que ne le
permet son métamodèle. Ainsi la portée d’un modèle est affectée par le
métamodèle dans lequel il est décrit.
Les métamodèles : Un modèle est défini à l’aide d’un langage de modélisation
structuré. Un métamodèle est un modèle d’un langage de modélisation, de fait il
est défini pour agencer une classe de modèles plus qu’un modèle en particulier
[Fav04b]. Néanmoins plus qu’un modèle, il être capable de décrire les
fonctionnalités importantes du langage modélisé [CESW08].
Les méta-métamodèles : Selon [Mul06], de la même manière qu'il est nécessaire
d'avoir un metamodèle pour interpréter un modèle, pour pouvoir interpréter un
metamodèle il faut disposer d'une description du langage dans lequel il est écrit:
un metamodèle pour les metamodèles. C'est naturellement que l'on désigne ce
metamodèle particulier par le terme de meta-metamodèle. En pratique, un metametamodèle détermine le paradigme utilisé dans les modèles qui sont construit à
partir de lui.
De ce fait, le choix d'un meta-metamodèle est un choix important et
l'utilisation de différents meta-metamodèles conduit à des approches très
différentes du point de vue théorique et du point de vue technique.
14

Pour approfondir la description d’un métamodèle, caractérisons d’abord ce
qu’est un langage de modélisation. Nous prenons la définition du second chapitre
du livre Applied Metamodeling [CESW08] qui indique qu’un langage est composé
généralement des fonctionnalités suivantes : une syntaxe, des relations.
Syntaxe : la syntaxe en tant que tel comporte deux parties qu’il convient de
séparer : la syntaxe concrète et la syntaxe abstraite.
• Syntaxe concrète : fournit une notation qui facilite la présentation et la
construction des modèles. Celle-ci doit permettre de saisir les
fonctionnalités les plus utiles sans pour autant rendre le modèle trop
complexe.
• Syntaxe abstraite : la syntaxe abstraite d’un langage décrit le vocabulaire
des concepts fournis par le langage et comment les combiner entre eux.
Relations : les correspondances entre les langages permettent de situer les
langages les uns par rapport aux autres. De plus il est nécessaire de définir des
relations entre les éléments de langages différents afin de permettre les
transformations entre les langages. Enfin il entre faut aussi définir des
correspondances entre la syntaxe concrète et la syntaxe abstraite d’un même
langage afin que celui-ci soit fonctionnel.
Enfin les langages de modélisation ne sont pas des entités figées et doivent
être extensibles afin de pouvoir se plier à de nouveaux domaines d’application.

3.1.3 Transformation de modèles
Les transformations de modèles forment une base de l’approche MDE,
puisqu’il s’agit d’automatiser la transformation d’un modèle source en un modèle
cible. La Figure 3.1.3 schématise ce processus.
Disposant d’un modèle d’entrée décrit par un métamodèle, la
transformation produit un modèle de sortie décrit par son métamodèle. Les
métamodèles d’entrée et de sortie peuvent être identiques : il est possible de faire
des transformations d’un modèle UML en un autre modèle UML par exemple
(surtout qu’UML peut décrire aussi bien un PIM qu’un PSM). Une spécification

de la transformation est disponible et nous faisons l’hypothèse réaliste suivante: la
spécification est définie de manière formelle ou pseudo formelle.
L’intérêt des transformations de modèles est important dans le processus de
développement. Il s’agit d’établir un premier modèle à partir de la spécification
qui sera indépendant de la plate-forme (PIM). Ce modèle peut par exemple être
affiné (à l’aide de transformations ou pas). Ensuite intervient la transformation
vers un autre modèle qui sera dépendant d’une architecture cible (PSM). Ce

15


modèle pourra être amélioré en déterminant par exemple les lacunes dans la
spécification. Par une suite de transformations, on peut finalement obtenir le code
source implantable. On sera ainsi passé de la spécification à l’implantation de
façon automatique, qui est l’objectif principal des transformations de modèles tel
qu’il est défini dans le MDA.

Figure 3.1.3 : Transformation de modèles

Cependant les applications des transformations de modèles ne sont pas
uniquement du type PIM vers PSM mais peuvent par exemple être de PSM vers
PIM. Il s’agit alors de « reverse engineering » (ou retro ingénierie). Nous pouvons
enfin avoir des transformations de PIM vers PIM ou de PSM vers PSM (la
génération de code appartient à cette catégorie).
Les transformations de modèles offrent d’autres intérêts:
Pour appliquer un design pattern (patron de conception) par
exemple qui est connu sous un métamodèle particulier mais pas
avec celui de notre modèle.

16

-

-

Pour simplifier un changement de plate-forme : on prend le
programme existant, par le reverse engineering on obtient un
modèle PIM et avec la spécification de la nouvelle plate-forme on
peut créer une transformation pour obtenir le programme final
voulu. L’opération peut être répétée automatiquement pour tous les
programmes à adapter.
Pour effectuer du réusinage (refactoring) : tout en restant à un
même niveau (PIM…) on peut appliquer des transformations à un
modèle, par exemple pour le rendre plus facilement testable ou
réutilisable.

3.2 Domain-Specific Languages
3.2.1 Introduction
Langages de programmation en général peuvent être classifiés ou regroupés
par différents critères. Critères possibles sont l'objet (par exemple Fortran pour la
programmation scientifique par opposition à C pour la programmation système), le
paradigme (LISP comme un langage fonctionnel ou Smalltalk comme un langage
orienté objet), que ce soit est impératif ou déclaratives et de domaine spécifique ou
à usage général [Kar07].
Langues d'usage général (General Purpose Languages ou GPLs) sont moins
spécialisés et sont adaptées à un large domaine des applications de traitement des
opérations jusqu'à l'informatique scientifique. Java est un éminent représentant. En
comparaison, un langage dédié (Domain-Specific Languages ou DSLs) est créé
pour résoudre certains problèmes spécifiques dans un domaine particulier, et n'a en

principe pas vocation à résoudre des problèmes en dehors de ce contexte. À ce
titre, un DSL peut être utilisé pour générer les membres d'une famille de systèmes
dans un domaine d'application. Le langage dédié bien-formé est conçu sur la base
d'une compréhension approfondie sous-jacent du domaine d'application, ce qui
donne exactement le pouvoir expressif de produire les membres de la famille
facilement [DK01].
Dans [Jon96], Jones présente le concept niveau de langage (langage level)
comme un critère de la technique d’estimation. Plus d’augmentation du niveau des
langages, moins des instructions nécessitées pour coder un point de fonction
(Function Point). Par exemple, COBOL est un niveau 3 et nécessite environ 105
instructions par des points de fonction. Le niveau de langues diverses fournir aussi
un raccourci pratique pour convertir la taille d'une langue à l'autre. La table
suivante présente la classification des quelques langages dédiés plus connus selon
leurs niveaux.

17


Table 3.2.1 : Niveaux des langages dédiés plus connus

DSL

domaine

niveau

Java
VHDL
HTML
SQL

Excel

GPL
Hardware design
Web pages markup
Database queries
spreadsheets

5
17
22
25
57

Domaine : au fil des années, de nombreux DSL ont été introduites dans les
différents domaines d'application (télécommunications, multimédia, les bases de
données, architectures logicielles, la gestion Web, etc), chacune proposant des
constructions et des concepts familiers aux experts et professionnels travaillant
dans ces domaines. Cependant, le développement d'un DSL est souvent complexe
et lourde tâche. Une profonde compréhension du domaine est donc nécessitée pour
exécuter l'analyse nécessaire et pour obtenir les exigences du langage.
Avantage : comme indiqué plus haute, les langages dédiés offrent quelques
avantages :
Les langages dédiés permettent d'exprimer des solutions avec les
tournures idiomatiques au niveau d'abstraction du domaine traité. En
conséquence, les experts du domaine eux-mêmes peuvent comprendre,
valider, modifier, et souvent même développer des programmes en
langage dédié.
Les langages dédiés facilitent la documentation du code.
Les langages dédiés améliorent la qualité, la productivité, la fiabilité,

la maintenabilité, la portabilité et les possibilités de réutilisation.
Les langages dédiés permettent la validation au niveau du domaine.
Aussi longtemps que les éléments du langage sont sûrs, toute phrase
écrite avec ces éléments peut être considérée comme sûre.

3.2.2 Domain-Specific Modelling Languages
Comme tout autre langage informatique (y compris GPLs), un DSL se
compose de la syntaxe concrète et de la définition de syntaxe abstraite et peut-être
une définition sémantique, qui peut être formulée à divers degrés de précision et
de formalité.
Dans le cadre de l’IDM, un DSL est construit comme une collection de
modèles coordonnés les uns les autres. De cette façon, la puissance de l’unification
des modèles est bien augmentée. Chacun des modèles qui composent un DSL
spécifie une des aspects de langage suivants : métamodèle de définition de
domaine, syntaxes concrètes,
sémantiques dynamiques et opérations
additionnelles.
18


Métamodèle de définition de domaine (Domain Definition MetaModel ou
DDMM) :
C’est un métamodèle introduit les abstractions basiques de ce domaine et
leurs relation des uns aux autres. Il devient le métamodèle des modèles qui sont
exprimés dans ce langage dédié. Donc, ce métamodèle joue un rôle central dans la
définition des langages dédiés. De cette manière, nous voyons que le Métamodèle
de définition de domaine est semblable au Métamodèle de définition de la Syntaxe
Abstraite (ou ASM) présenté dans [CRC+06].
La syntaxe abstraite d’un langage de modélisation exprime, de manière
structurelle, l’ensemble de ses concepts et leurs relations. Les langages de métamodélisation tels que le standard de l’OMG MOF, offrent les concepts et relations

élémentaires en termes desquels il est possible de décrire un métamodèle
représentant cette syntaxe abstraite. Et ce métamodèle est le métamodèle de
définition de la syntaxe abstraite de langage dédié.
Syntaxes concrètes :
Un langage informatique peut avoir différentes syntaxes concrètes qui sont
définis par la transformation des modèles qui fait des relations entre le DDMM et
l’affichage des modèles du langage dédié.
D’autre façon, 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étamodèle
de la syntaxe abstraite.
Sémantiques dynamiques :
Généralement, des langages dédiés ont différents types de sémantiques. Il y
a au moins trois moyens qui nous permettent de décrire la sémantique d'un langue.
Il s'agit de:
dénotationnelle, qui est défini par la construction d'objets
mathématiques appelé dénotations, qui représentent le sens du
programme / modèle.
opérationnel, qui est en décrivant comment une mogram valable est
interprété comme des séquences des étapes de calcul. La séquence des
étapes de calcul est souvent donnée sous la forme d'un système de
transition des états (state transition system), qui montre comment le
régime d'exécution d'un état à l'autre.
translationnelle, qui est de traduire la mogram dans une autre langue
qui est bien compris.
Une meilleur façon pour décrire des sémantiques est les sémantiques
opérationnelles ou appelées aussi sémantiques dynamiques se basant sur les
notions d’un système de transition des états. Les sémantiques dynamiques d’un
langage dédié peuvent être obtenues de différentes manières, par exemple par
19

mapping à un autre DSL qui a lui-même les sémantiques opérationnelles bien
formées ou encore être définis en utilisant un GPL.
Opérations additionnelles sur des DSLs :
Ce sont des opérations qui manipulent des programmes décrits dans le
language dédié donné. Chacune des opérations peut être défini par un mapping
représenté par une transformation des modèles. L’étude de ces opérations sur des
DSL présente un nombre des défis et actuellement est un sujet ouvert de
recherche.
Dans un autre papier [Kle07], Kleppe conclut qu’une description de
langage précise seules syntaxes abstraites ne suffit pas. Une description fiable de
langage doit se baser sur trois composants : syntaxe abstraite, syntaxe concrète et
sémantiques. En conséquence, un langage doit être construite par itération à partir
de la partie de syntaxe abstraite, puis l’ajout de syntaxe concrète et des
sémantiques. Le résultat de chaque itération sera une bonne description dans
lequel chaque élément prend sa place.

3.3 Conclusion
Dans ce chapitre, je viens de présenter le contexte de mon stage en
mentionnant l’IDM, les langages dédiés et la relation entre l’IDM et les langages
dédiés. Avec le développement de l’Ingénierie des Modèles, il porte quelques
approches pour spécifier les langages dédiés et augmente le niveau d’abstraction
de la spécification des langages.
La question posée en course est de comment augmenter la modularité
quand on développe une famille des langages associés. Actuellement, il reste
encore des difficultés pour la résoudre. Ça est l’objectif de mon stage et dans le
chapitre suivant je vais présenter mes travaux bibliographiques sur le Modular
SOS [Mos99a], le langage de méta-méta-modélisation Kermeta [MFJ05] et l’idée
de Typage des Modèles [SJ06].

20


Chapitre 4
L’Etat de l’Art

Dans ce chapitre, j’étudie les quelques travaux qui concernent la définition des
structures modulaires de sémantique opérationnelle, les langages de métamodélisation et le typage des modèles.

4.1 Structures Modulaires de Sémantique Opérationnelle
(Modular SOS)
Sémantique Opérationnelle Structurelle est un framework connu qui est
utilisé pour spécifier les sémantiques des langages de programmation. Cependant,
la modularité dans SOS est assez pauvre : quand on veut étendre la spécification
d’un langage ou ajouter une nouveau composant, il faut que les règles de SOS de
tous les composants fonctionnels soient complètement reformulées.
Modular SOS est un variant de SOS, les règles de chaque composant
fonctionnel individuel des langages sont définies définitivement, on ne doit pas
reformuler des règles quand étendre le langage. De cette manière, MSOS fournit
un haut degré de modularité pour des descriptions de langage de programmation.
Cette session présente des notions principales de SOS et puis souligne la
différence de MSOS par rapport à SOS qui est le facteur de l’augmentation de
modularité dans des descriptions des langages spécifiés.

21


4.1.1 Structural Operational Semantics (SOS)
Système de transition

Selon [AFV01], SOS est une approche de sémantique opérationnelle, elle
fournit un framework qui permet de définir des sémantiques opérationnelles des
langages de la programmation.
Selon [Plo81a, Plo81b, Mou05, Mos99a], la sémantique opérationnelle
structurelle est représentée par un système de transition étiquetée (Labeled
Transition System - LTS) qui est définit par un quadruple Γ, Α, →, Τ consistant :
- un ensemble Γ des configurations γ ,
- un ensemble Α des étiquettes α ,
- une relation ternaire → ⊆ Γ× Α×Γ de transition avec l’étiquette α
α
→ γ ' ), et
entre deux configurations γ et γ ' (écrit γ 
- un ensemble Τ ⊆ Γ des configurations terminales. Si on a une
transition γ → γ ' , alors γ ∉Τ .
Dans LTS, une computation à partir de γ o est une série finie ou infinie des
α

α

α

α
1
2
3
transitions successives γ i 
→ γ i +1 qu’on écrit γ 0 →
γ 1 →
γ 2 →
... Et

lorsque cette série est terminée avec γ n , alors on a γ n ∈Τ .
Remarque, des étiquettes dans SOS sont optionnelles, donc parfois le système de
transition de SOS est simplement une structure Γ, →, Τ .
SOS définit aussi autres descriptions de sémantique, tel que la syntaxe
abstraite, des valeurs calculées, des configurations, des étiquettes, et des règles de
transition.

Valeurs calculées : Valeurs calculées dans SOS sont déterminées comme des
truth-values, numéros, la valeur nil et un environnement représentant des bindings
pour des déclarations.
Table 4.1.1 : ensemble des valeurs calculés

Expression values:

»∪Τ

Command values:

{nil}

Declaration values :

Env

Entités auxiliaires : Entités auxiliaires diverses sont aussi utiles dans SOS, elles
sont utilisées comme des valeurs calculées, ou comme des éléments de
configuration.
Des environnements ρ ∈ Env et des stores σ ∈ Stores sont des fonctions
finies, de X vers Y et écries Χ → fin ϒ . La variété d’environnement et de stores est
présentée successivement par DVal et SVal. La table suivante présente des entités

auxiliaires.

22


Table 4.1.2 : ensemble des entités auxiliaires

Environments:
Denotable values:
Stores:
Locations:
Storable values:

ρ ∈ Env = Id →

DVal
fin
DVal = » ∪ Τ ∪ Loc
σ ∈ Stores = Loc →
SVal
fin
l ∈ Loc
(arbitrary)
SVal = » ∪ Τ

Configurations : Configurations sont des états du système de transition. Dans les
descriptions des langages de programmation de SOS, configurations impliquent
non seulement la syntaxe abstraite, mais aussi des entités auxiliaires par exemple
des environnements ou des stores.
Table 4.1.3 : Configurations de SOS

Γ = { ρ , e,σ

} ∪ { ρ , c, σ } ∪ { ρ , d , σ }
Τ = { ρ , con,σ } ∪ { ρ , nil , σ } ∪ { ρ , ρ ',σ }
Règles de transition : Dans SOS, les relations de transition sont spécifiées de
manière inductive par des règles. Une règle de SOS est formée à partir des
t'
assertions de transition t 
→ t '' , où des termes t, t’, t’’ peuvent contenir des
meta-variables.
Il y a deux types de règles, règle simple et règle conditionnelle. Une règle
t'
simple contient une assertion t 
→ t '' , cependant une règle conditionnelle est
c , c ,..., cn
écrite sous forme 1 2
. Les conditions c1 , c2 ,..., cn et la conclusion c sont
c
des assertions de transition. De cette manière, une règle simple peut être
considérée comme une règle conditionnelle avec une liste vide des conditions.
t'
Dans des assertions t 
→ t '' , des parties syntactiques des termes de
configuration t jouent un rôle significatif dans les spécifications de SOS, elles sont
traitées comme des controls de transitions. Dans ce contexte, une règle est
structurelle si tous les composants du control de conclusion sont bien spécifiés par
des controls des conditions.

4.1.2 Problème de modularité dans la SOS

Comme mentionné avant, la modularité de SOS est assez limitée, voire
pauvre. Les extensions des langages spécifiés peuvent demander de reformuler des
règles précédentes.
Dans la suite, pour illustrer le problème de modularité dans la SOS, nous
allons considérer des règles de SOS d’un simple langage pour l’évaluation des
23


expressions arithmétiques. Les syntaxes abstraites de ce langage sont simplement
présentées comme suivant.
Table 4.1.4 : Syntaxes Abstraites du langage exemple

Numbers:

n ∈ » = {0,1, 2,...}

Identifiers:

x ∈ Id = { x0 , x1 , x2 ,...}

BinaryOperations:

bop ∈ Bop = {+, −,*,...}

Constants:

con ∈ Con

Expressions:

e ∈ Exp
e ::= con | x | e0 bop e1

Commands:

c ∈ Com
c ::= nil | x := e | c0 ; c1

Declarations:

d ∈ Dec
d ::= const x = e | var x := e | d 0 ; d1

Cette table suivante présente un exemple des règles de SOS utilisées pour
évaluation des expressions arithmétiques. Dans cet exemple, la relation de
transition comporte des syntaxes et un environnement.
Les règles (1) et (2) imposent l’évaluation séquentielle des expressions e0 et
e1 . Par exemple dans la règle (1), dans l’environnement σ , si on a une transition

e0 → e0' , alors l’expression e0 bop e1 va être évaluée à la e'0 bop e1 dans le
système de transition.
Table 4.1.5 : Règles de SOS

(1)
(2)
(3)
(4)

ρ | e0 → e0'
ρ | e0 bop e1 → e0' bop e1

ρ | e1 → e1'
ρ | con0 bop e1 → con0 bop e1'
bop = +, n = n0 + n1
ρ | n0 bop n1 → n

ρ ( x) = con
ρ | x → con

La règle (3) présente l’évaluation de l’opération binaire ‘+’. Et la règle (4)
présente l’évaluation d’une variable dans l’environnement σ . Rappeler que
l’environnement σ contient les bindings Id → Val , donc si la variable x se
trouve dans une expression quelconque, elle va être évaluée par sa valeur con
dans l’étape suivante.

24


Dans la table 4.1.5, on présente des règles de SOS, elles illustrent
l’évaluation des expressions arithmétiques. Maintenant, on suppose qu’une
extension d’ajouter la notion de stores. Alors, la configuration comporte
maintenant les syntaxes, un environnement, et un store. Donc, les règles doivent
être reformulée.
Table 4.1.6 : Règles réformulées de SOS

(5)
(6)

ρ | e0 ,σ → e0' ,σ
ρ | e0 bop e1 ,σ 1 → e0' bop e1 ,σ
ρ | e1 ,σ → e1' ,σ

ρ | con0 bop e1 ,σ → con0 bop e1' ,σ

(7)

bop = +, n = n0 + n1
ρ | n0 bop n1 , σ → n,σ

(8a )

ρ ( x ) = con
ρ | x,σ → con,σ

(8b)

ρ ( x ) = l , σ (l ) = con
ρ | x,σ → con,σ

Les règles (5, 6, 7) présentent les évaluations séquentielles des expressions
comme ses règles correspondantes (1, 2, 3) dans l’exemple précédent. Une
différence est la méthode d’évaluer une variable. Dans le nouvel contexte, pour
évaluer une variable, il faut d’abord chercher la location de cette variable dans
l’Environnement, puis chercher la valeur de cette location trouvée dans le Store
comme présenté dans la règle (8b).
Pour résoudre le problème de modularité des spécifications de SOS, un
variant de SOS, Modular SOS [Mos99a] présenté dans la session suivante, élimine
les causes d’insatisfactions des SOS en exploitant le système de transition étiqueté.

4.1.3 Modular SOS – a variant of SOS
Afin d’augmenter la modularité des spécifications de SOS, et
particulièrement d’éviter des reformulations des règles comme illustrées ci-dessus,

Modular SOS exploite l’utilisation des étiquettes dans le système de transition
[Mos04], pour encapsuler des structures sémantiques. Toutes les structures
sémantiques sont des éléments de la structure d’étiquette, elles sont changées et
accédées indépendamment des un des autres, via les deux fonctions get() et set().
Autrement dit, les configurations de MSOS sont simplement l’arbre de syntaxes

25