Typage des expressions

Cette section détaille les règles de typage applicables aux principales constructions

du langage d’action de Kermeta.

Structures de contrôles

La première structure de contrôle à laquelle nous nous intéressons est le bloc. Un

bloc est une séquence d’expressions. Un bloc est correctement typé si l’ensemble des

instructions qu’il contient sont correctement typées. Lors de la vérification de type d’un

bloc, un nouveau contexte est empilé dans la table des symboles de l’environnement de

typage. Ce nouveau contexte contient les éventuelles variables locales définies dans le

bloc. Il est dépilé a la fin de l’analyse du bloc. Lors de son exécution, un bloc retourne la

valeur retournée par la dernière expression qu’il contient. Comme le montre la règle de

déduction 3.1, le type d’un bloc est donc le type de la dernière expression qu’il contient.

E `exp<sub>1</sub> :τ<sub>1</sub>, . . .,E `exp_n:τ_n

do exp₁, . . .,exp_n end :τ_n ^(3.1)

Les règles 3.2 et 3.3 détaille le typage des conditionnelles. Il est nécessaire que le

type de la condition soit Boolean. Dans le cas où il n’y a qu’une seule branche, le

type de la conditionnelle correspond au type de l’expression de cette branche. Dans le

cas où il y a deux branches, le type de la valeur retournée par la conditionnelle peut

correspondre soit au type de l’expression de la branchethensoit au type de l’expression

de le branche else. Nous avons choisi une solution simple à ce problème : le type de

Système de types de Kermeta 95

retour de la conditionnelle correspond au type le plus général des deux. C’est le rôle de

la fonctionancestor(E, τ₁, τ₂) utilisée dans la règle 3.3. Cette fonction vaut :

– τ₁ si τ₂¹τ₁,

– τ₂ si τ₁¹τ₂,

– Objectdans les autre cas.

Dans les versions futures de Kermeta, il serait intéressant d’introduire lestypes unions

afin de typer au mieux les expressions conditionelles.

E`cond:Boolean,E `exp:τ₁

ifcond thenexp end :τ₁ ^(3.2)

E `cond:Boolean,E `exp₁:τ₁,E`exp₂ :τ₂

ifcondthen exp₁ elseexp₂ end :ancestor(E, τ₁, τ₂) ^(3.3)

Pour le typage des boucles, comme le montre la règle 3.4 nous avons choisi une

solution très simple. Il est simplement nécessaire que la condition soit une expression

booléenne et le type de retour est toujoursVoid.

E`init:τ<sub>i</sub>,E`cond:Boolean,E `exp:τ

from inituntil condloop exp end :V oid ^(3.4)

Variables

Les règles 3.5 et 3.6 correspondent à la déclaration de variables locales avec et

sans expression d’initialisation. Le type de la déclaration de variable est le type de

l’expression d’initialisation. Si aucune expression d’initialisation n’est donnée alors le

type estVoid. Lorsqu’une déclaration de variable est vérifiée, un symbole correspondant

à la variable est ajouté en haut de la table des symboles de l’environnement de typage.

Le type associé à ce symbole est le typeτ_v déclaré pour la variable.

E`τ_v

E `var v :τ_v :V oid ^(3.5)

E `τ<sub>v</sub>,E`exp:τ_e,τ_e¹τ_v

E `var v :τ_v initexp :τ_e ^(3.6)

Lors de l’appel à une variable, le symbole correspondant est recherché dans

l’envi-ronnement de typage et, comme le montre la règle 3.7, le type rendu est le type associé

au symbole trouvé. La fonction symbol utilisé dans la règle correspond à la recherche

du haut en bas de la pile de symbole dans l’environnement de typage.

E `symbol(v, E) =τ

Affectation et cast

La règle 3.8 détaille le typage des affectations Kermeta. La valeur retournée par une

affectation est la valeur qui a été affectée. Le type de l’affectation correspond donc au

type de la partie droite de l’affectation. Pour que l’affectation soit correcte, il faut que

le type de la partie droite soit un sous-type de la partie gauche.

E`lhs:τ,E`rhs:τ0,τ0¹τ

E` lhs:= rhs:τ^{0 (3.8)}

Dans le cas du cast dynamique c’est aussi la valeur affectée qui est retournée. La

valeur rendue par l’expression en partie droite est affectée si son type dynamique est

un sous-type du type statique de la partie gauche. Sinon, la valeur void est affectée.

Comme le montre la règle 3.9 le type d’un cast dynamique correspond au type statique

de la partie gauche.

E`lhs:τ,E`rhs:τ0,τ ¹τ0

E ` lhs?=rhs:τ ^(3.9)

Appel de propriétés et d’opérations

La règle 3.10 correspond au typage des appels de propriété et d’opérations. La

fonc-tion f eature(f, τ, E) utilisée dans cette règle correspond à la recherche du type d’une

propriété ou d’une opération nommée f disponible sur le typeτ (ou un de ses

super-types) dans l’environnementE. Pour une propriété ou une opération sans paramètres le

type obtenu correspond directement au résultat du typage. En revanche pour une

opé-ration qui a des paramètres le type obtenu est un type fonction. Il faut alors vérifier que

le nombre adéquat de paramètres a été fourni à l’appel, et que le type des paramètres

effectifs sont des sous-types des types spécifiés pour les paramètres formels. Dans ces

conditions, le résultat du typage correspond à la partie droite du type fonction.

E`exp:τ,τ :Class

f eature(f, τ, E) ={τ₁× · · · ×τ_n→τ_f}

E `exp₁ :τ0

1, . . .,E `exp_n:τ0

n

τ₁⁰ ¹τ₁, . . .,τ_n⁰ ¹τ_n

exp.f(exp₁, . . . , exp_n) :τ_f

(3.10)

Fonctions

Les dernières constructions de Kermeta dont nous détaillons le typage ici sont la

définition et l’utilisation de fonctions ou clôtures lexicales. La règle 3.11 correspond à la

définition d’une fonction. Les fonctions doivent avoir au moins un paramètre. Le type

d’une fonction est un type fonction pour lequel la partie gauche est le type produit

contenant les types déclarés pour les paramètres, et la partie droite est le type de

l’expression correspondant au corps de la fonction.

Conclusion 97

E `τ<sub>1</sub>, . . .,E `τ_n,E`exp:τ

function{v₁ :τ₁, . . . , v_n:τ_n|exp}:{τ₁× · · · ×τ_n→τ} ^(3.11)

La règle 3.12 détaille le typage de l’application d’une fonction. Cette règle est très

similaire à l’appel d’opérations avec paramètres. Afin de ne pas compliquer le langage,

nous avons dans un premier temps interdit les mécanismes fonctionnels plus évolués

comme la currification par exemple. Cependant dans une version future du langage, il

serait intéressant d’enrichir les capacités fonctionnelles de Kermeta.

exp:{τ₁× · · · ×τ_n→τ_f},E `τ<sub>1</sub>, . . .,E`τ_n,E `τ_f

E`exp₁ :τ0

1, . . .,E `exp_n:τ0

n

τ0

1 ¹τ₁, . . .,τ0

n¹τ_n

exp(exp₁, . . . , exp_n) :τ_f

(3.12)

3.5 Conclusion

Au sein d’un projet de modélisation, il est avantageux d’utiliser un ensemble de

lan-gages dédiés pour la définition de méta-modèles, de modèles, de contraintes de

transfor-mations, etc. Cependant, dans la plupart des environnements existants, les différents

langages utilisés sont indépendants les uns des autres et donc difficilement

interopé-rables. L’avantage lié à l’utilisation de langages dédiés est alors nuancé par le fait que

les différents artefacts d’un même projet restent déconnectés les uns des autres du

fait de leur hétérogénéité. Dans ces conditions, il difficile d’assurer et de maintenir la

cohérence globale d’un projet.

La réponse que nous proposons à ce problème est une plateforme de modélisation

dont le coeur est le méta-langage Kermeta. L’expressivité de Kermeta est suffisante pour

exprimer sans difficultés l’ensemble des artefacts d’un projet de modélisation. L’objectif

de ce langage n’est pas de remplacer les langages dédiés existants mais de fournir une

base sémantique commune à ces langages. L’utilisation de Kermeta comme

dénomina-teur commun permet l’intégration des différents artefacts d’un projet de modélisation

dans une représentation qui permet l’interopérabilité.

En plus de la contrainte liée à l’expressivité de Kermeta, nous avons défini un

langage le plus simple possible, en terme de nombre de concepts, tout en restant à

un niveau d’abstraction satisfaisant pour l’utilisateur. Nous avons porté une attention

toute particulière au système de types de Kermeta afin de fournir un maximum de

vérifications statiques. Ces vérifications statiques permettent d’assurer un minimum de

cohérence entre les différents artefacts d’un projet et constitue un premier pas

indispen-sable pour la construction de processus de validation spécifiques à l’ingénierie dirigée

par les modèles.

La première version comportait un parseur, un vérificateur de types (type-checker),

un interpréteur et un éditeur intègré à Eclipse avec coloration et complétion. Le projet

open-source Kermeta compte, en juin 2006, plus de douze développeurs actifs2 et un

2

Parmis lesquels Zoé Drey, Jean-Marie Mottu et Didier Vojtisek qui ont joué un rôle de premier

nombre d’utilisateurs croissant. En plus des éléments implantés dans la première version

de l’environnement Kermeta, les principales nouveautés sont l’interopérabilité avec Java

et EMF, un metteur au point (debugger), un éditeur graphique et des frameworks

associés à des méta-modèles standards tel que UML2 par exemple.

Dans ce chapitre nous avons détaillé la construction du langage Kermeta. C’est un

langage dédié à l’ingénierie des modèles. C’est un langage généraliste par rapport aux

langages MOF, OCL ou QVT qui sont plus spécialisés, mais c’est un langage dédié par

rapport à des langages comme Java ou Eiffel. Les cinq principales forces du langages

Kermeta sont :

– Sonexpressivitéqui permet de spécifier dans un formalisme unique les quatres

principaux types d’artefacts de l’ingénierie des modèles : les méta-modèles, les

contraintes, la sémantique et les transformations.

– Ses mécanismes orienté-objets qui permettent de réutiliser des bonnes

pra-tiques issues de la programmation orienté-objets : utilisation de design patterns,

traitement d’exceptions, utilisation d’assertions (ou contrats), etc.

– Ses mécanismes orienté-modèles (comme les associations et compositions)

qui permettent de garantir des propriétés de conformité entre les modèles et leurs

méta-modèles.

– Son système de types statique qui permet de garantir un premier niveau de

cohérence entre les différents artefacts d’un projet.

– Sonmechanisme d’introspectionqui permet d’implanter facilement des

trans-formations de programmes et des techniques de validation basées sur l’analyse

statique.

– Sa conformité au standard EMOF qui permet une bonne intégration avec

d’autres outils d’ingénierie des modèles (comme Eclipse/EMF par exemple).

Une faiblesse potentielle du langage Kermeta est d’être un langage généraliste. En effet,

là où des langages comme MOF, OCL ou QVT proposent des constructions spécifiques

à chacune des activités de l’ingénierie des modèles, Kermeta offre un ensemble restreint

de constructions plus générales. Afin de valider le langage Kermeta, il est nécessaire

de montrer que son niveau abstraction de ces constructions reste suffisant pour

conce-voir, implanter, valider et maintenir les différents artefacts d’un projet d’ingénierie des

modèles. Cette étude fait l’objet du chapitre suivant.

Chapitre 4

Utilisation de Kermeta : études

de cas

Le chapitre précédent détaille la conception et la réalisation du langage Kermeta

comme coeur d’une plateforme de modélisation. Ce chapitre propose un ensemble

d’études de cas pour la validation de Kermeta. Au début du chapitre précédent

(sec-tion 3.2), nous avons défini trois exigences pour le langage Kermeta : une expressivité

suffisante, une taille minimale et une bonne utilisabilité. Une partie de ces exigences a

été satisfaite lors de la construction de Kermeta mais il reste nécessaire de valider par

la pratique que le langage Kermeta répond de façon satisfaisante aux besoins de

l’ingé-nierie des modèles, malgré les contraintes imposées par les préocupations d’expressivité

et de fiabilité.

En ce qui concerne l’expressivité, Kermeta est un langage Turing-complet. D’un

point de vue théorique cette première exigence est donc satisfaite. La taille minimale

est une exigence qui a guidé les choix de conception de Kermeta : choix de EMOF

comme langage de méta-données, conception d’un langage d’action compact, etc.

Ce-pendant l’utilisabilité n’est pas une exigence qui peut être assurée complètement par

construction. L’utilisabilité est une exigence générale qui regroupe un ensemble de

pro-priétés dont la satisfaction est parfois difficile à assurer formellement. Pour pouvoir

qualifier un langage d’utilisable, nous avons retenu les six critères suivants :

1. Être au bon niveau d’abstraction. Si les constructions offertes sont trop

"bas-niveau" l’utilisation du langage est inutilement coûteuse, ce qui constitue une

source d’erreur potentiellement importante. A l’inverse, des primitives trop

spé-cifiques ou trop nombreuses nuisent à l’expressivité du langage. Un compromis

doit donc être trouvé en fonction du domaine d’application du langage considéré.

2. Permettre de gérer la complexité des applications. Le langage doit offrir des

constructions pour assurer son passage à l’échelle vis-à-vis de la complexité du

domaine considéré.

3. Permettre de la réutilisation de code. Les applications d’un domaine ont

généra-lement des points communs qu’il est intéressant de factoriser. Afin d’éviter toute

duplication de code, le langage doit offrir la possibilité de réutiliser, spécialiser ou

étendre du code existant.

4. Faciliter la validation des programmes. La validation des programmes est toujours

une phase très coûteuse du développement. Il est donc important que le langage

utilisé mette en oeuvre toutes les techniques existantes pour assurer la qualité et

la robustesse des programmes.

5. Faciliter la maintenance et l’évolution des applications. Les applications de ce

domaine doivent pouvoir s’adapter aux évolutions des besoins de ce domaine.

Pour que les évolutions soient le moins coûteuse possible, il est nécessaire que le

langage offre des mécanismes permettant de faire évoluer les programmes.

6. Être supporté par des outils et interopérer avec les outils du domaine considéré.

Ce dernier point est primordial pour permettre l’utilisation du langage. Les outils

doivent assister l’écriture des programmes, permettre leur mise-au-point et leur

exécution. Les outils et le langage doivent également interopérer avec les autres

outils du domaine considéré pour être utilisables en pratique.

Pour assurer que Kermeta vérifie l’ensemble de ces critères dans le contexte de

l’in-génierie des modèles, la démarche que nous avons adopté comporte deux étapes. La

première est une étape amont qui consiste à intégrer dès la conception de Kermeta des

concepts et des constructions qui ont fait leurs preuves dans le domaine de la

progra-mation : concepts orienté-objets, langage d’action impératif, traitement d’exceptions,

typage statique, contrats, etc. La seconde est une étape avale qui consiste à vérifier,

par des études de cas, que le langage Kermeta permet de concevoir et d’implanter les

un ensemble de cas d’applications caractéristiques de l’ingénierie des modèles : la

défi-nition de langages de modélisation, l’implantation de transformations de modèles et de

composition de modèles. Cette dernière étape est le seul moyen de valider les qualités

pratiques de Kermeta. Dans cette optique, ce chapitre détaille quatre études de cas qui

couvrent les principaux cas d’utilisations d’une plateforme d’ingénierie des modèles.

La première étude, présentée section 4.1, traite l’exemple du langage d’automate

utilisé au début du chapitre précédent. L’objectif de cette étude est d’illustrer sur un

exemple simple et complet les possibilités et les avantages de Kermeta pour la

spécifica-tion des différents artéfacts relatifs à un méta-modèle : sa structure, sa sémantique, des

contraintes et des transformations. Cette étude est également l’occasion de présenter

brièvement les outils que nous avons développé autour du langage Kermeta.

La seconde étude, présentée section 4.2, discute de l’implantation de

transforma-tions de modèles. Les transformatransforma-tions de modèles sont une des applicatransforma-tions

caractéris-tiques de l’ingénierie des modèles. L’objectif de l’étude est de valider les capacités de

Kermeta pour leur implantation. L’étude que nous avons menée repose sur un

bench-mark de transformations de modèles défini par les organisateurs du workshop MTIP’05

[BRST05] pour évaluer différentes techniques de transformation de modèles. Cette étude

montre, par exemple, comment tirer avantage des possibilités offertes par Kermeta pour

l’écriture de code de transformation de modèles réutilisable.

La troisième étude, présentée section 4.3, détaille la mise en oeuvre en Kermeta

de travaux académiques sur la modélisation orientée aspects. Pour cette étude,

Ker-Exemple des automates 101

meta à été utilisé pour l’implantation de deux techniques de tissage de modèles. La

première permet de composer des diagrammes de classes et la seconde de composer

des diagrammes de séquences. Le principal intérêt de Kermeta pour cette application

est de permettre d’intégrer la sémantique (et les variations sémantiques) du tissage

directement dans le méta-modèle considéré.

La quatrième étude, présentée section 4.4, revient sur des travaux utilisant

l’ingé-nierie des exigences menée en lien avec l’industrie. Ces travaux proposent une chaîne

de traitement des exigences basée sur l’ingénierie des modèles. Cette chaîne comporte,

entre autres, deux langages de modélidation dédiés et un certain nombre de

transfor-mations de modèles. L’objectif de cette étude est de montrer que Kermeta fournit un

bon moyen pour la mise en oeuvre de processus complets d’ingénierie des modèles.

4.1 Exemple des automates

Dans la section 3.1 nous avons pris l’exemple d’un méta-modèle d’automate afin

de montrer les limites des environnements de modélisation existants. Pour spécifier

le langage d’automates, nous avions utilisé EMOF pour définir la structure du

méta-modèle, OCL pour spécifier des contraintes, le langage naturel pour définir la

séman-tique du méta-modèle et un langage dédié pour implanter des transformations de

mo-dèles. Les limitations de cette approche sont la conséquence de l’hétérogénéité et de la

non-intéroperabilité des langages utilisés. Par exemple, cela rend difficile toute

vérifica-tion automatique relative à la cohérence entre les différents artéfacts considérés. Cette

section montre comment l’utilisation de Kermeta permet une bonne intégration entre

la structure, des contraintes, la sémantique et des transformations de modèles.

La figure 4.1 rappelle le méta-modèle d’automate que nous utilisons. En pratique ce

méta-modèle a été défini graphiquement en utilisant Eclipse/EMF et Omondo afin

d’ob-tenir un diagramme. Les outils Eclipse/EMF étant conformes au standard EMOF, ce

méta-modèle est directement utilisable dans l’environnement Kermeta. Cela est rendu

possible par le fait que Kermeta à été construit par extension du standard EMOF.

Dans l’environnement Kermeta, des transformations permettent d’importer et

d’expor-ter des méta-modèles depuis Eclipse/EMF. La figure 4.2 présente le listing Kermeta

correspondant exactement au méta-modèle d’automate de la figure 4.1. On retrouve sur

ce listing les classes, les propriétés et les opérations du méta-modèle. Pour la propriété

dérivéealphabet un corps vide et un commentaire ont été ajoutés.

Dans le document Langage et méthode pour une ingénierie des modèles fiable (Page 97-104)