UNIVERSITE D’ANGERS

Habilitation à diriger des recherches

Spécialité Informatique

Contribution à l’étude et à l’application de l’ingénierie dirigée par

les modèles

présentée et soutenue publiquement par

Slimane HAMMOUDI

Soutenue le lundi 29 novembre 2010 devant le jury composé de :

Président du Jury
Jean-Louis Ferrier Professeur, Université d’Angers - ISTIA

Rapporteurs
Thérèse Libourel Professeur, Université de Montpellier 2 - LIRMM
Michel Léonard Professeur, Université de Genève, FSES - Suisse
Taleb-Bendiab Professeur, Université de Liverpool, JMU - UK

Examinateurs
Stéphane Loiseau Professeur, Université d’Angers - LERIA
Joaquim Filipe Professeur, Polytechnique de Setubal, EST - Portugal
Table des matières

1 Introduction 7
1.1 Contexte et domaines applicatifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1 L’ingénierie dirigée par les modèles . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 Les services Web et applications internet . . . . . . . . . . . . . . . . . . . 8
1.1.3 L’informatique pervasive et les applications sensibles au contexte . . . . . 9
1.2 Démarche de recherche et contributions . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Techniques de modélisation et méta modélisation . . . . . . . . . . . . . . . . 10
1.2.2 Techniques de transformations . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.3 Méthodologies de développement . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 L’IDM, l’approche MDA et positionnement. 14

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Concepts de bases de l’IDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1 Modèle et système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Métamodèle : langage de modélisation . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Métamétamodèle : langage de métamodélisation . . . . . . . . . . . . . . . 16
2.2.4 IDM et transformation de modèles . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5 IDM, et ses principales approches. . . . . . . . . . . . . . . . . . . . . . . 18
2.3 L’approche MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Processus de développement dans MDA . . . . . . . . . . . . . . . . . . . 20
2.3.2 Modélisation et métamodélisation dans MDA . . . . . . . . . . . . . . . . 23
2.3.3 OCL, Action Semantics et XMI . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.4 Le pont vers les ontologies :ODM. . . . . . . . . . . . . . . . . . . . . . . 30
2.4 La transformation de modèles dans MDA . . . . . . . . . . . . . . . . . . . . . . 31
2.4.1 Les différentes approches de transformations de modèles . . . . . . . . . . 31
2.4.2 L’approche de transformation par modélisation . . . . . . . . . . . . . . . 32
2.4.3 Langages et standard pour la transformation de modèles . . . . . . . . . . 33
2.5 Positionnement : de la correspondance à la transformation . . . . . . . . . . . . . 35
2.5.1 Mapping Versus Transformation : définitions . . . . . . . . . . . . . . . . 36
2.5.2 Une nouvelle architecture pour le processus de transformation. . . . . . . 37
2.5.3 Un formalisme graphique pour la spécification des correspondances . . . . 38
2.5.4 Un métamodèle de correspondances. . . . . . . . . . . . . . . . . . . . . . 39
2.5.5 Un outil pour la génération des règles de transformations . . . . . . . . . 41
2.6 Discussion et synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3 MDA et Plateforme Services Web 45

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Domaine applicatif et processus MDA . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.1 Les services Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2.2 Processus de développement MDA . . . . . . . . . . . . . . . . . . . . . . 47
3.2.3 Exemple illustratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Modélisation, métamodélisation et transformation . . . . . . . . . . . . . . . . . . 50

2
TABLE DES MATIÈRES 3

3.3.1 La modélisation : le modèle PIM de l’agence de voyage . . . . . . . . . . . 51

3.3.2 La métamodélisation : les métamodèles PIM et PSM . . . . . . . . . . . . 53
3.3.3 Spécification des correspondances et transformation M2M. . . . . . . . . . 56
3.3.4 Transformation M2C : Mise en œuvre du modèle métier . . . . . . . . . . 61
3.4 Conclusion, travaux connexes et synthèse . . . . . . . . . . . . . . . . . . . . . . 64
3.4.1 Positionnement par rapport à l’état de l’art . . . . . . . . . . . . . . . . . 64
3.4.2 Points forts et limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.4.3 Liste des publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4 MDA et les applications sensibles au contexte. 68

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.2 Domaine applicatif et approche COMODE . . . . . . . . . . . . . . . . . . . . . . 69
4.2.1 Contexte et sensibilité au contexte . . . . . . . . . . . . . . . . . . . . . . 69
4.2.2 COMODE : principe et architecture . . . . . . . . . . . . . . . . . . . . . 71
4.3 Processus de développement COMODE . . . . . . . . . . . . . . . . . . . . . . . 72
4.4 Un métamodèle de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.5 Le processus de transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.5.1 Transformation paramétrée pour le tissage du contexte. . . . . . . . . . . 75
4.5.2 Transformation par composition de modèles . . . . . . . . . . . . . . . . . 77
4.5.3 Exemple illustratif de la transformation paramétrée . . . . . . . . . . . . . 80
4.6 Conclusion, travaux connexes et synthèse . . . . . . . . . . . . . . . . . . . . . . 82
4.6.1 Positionnement par rapport à l’état de l’art . . . . . . . . . . . . . . . . . 82
4.6.2 Points forts et limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.6.3 Liste des publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5 MDA et le processus de transformation 86

5.1 Introduction et motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2 Une architecture pour le processus de transformation . . . . . . . . . . . . . . . . 87
5.3 Une méthodologie pour le processus de transformation . . . . . . . . . . . . . . . 89
5.3.1 Les utilisateurs MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.2 Processus de transformation : activités de préparation et d’exécution . . . 89
5.3.3 Processus de transformation et principaux utilisateurs . . . . . . . . . . . 91
5.4 Appariement et mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4.1 Algorithme pour l’appariement des métamodèles . . . . . . . . . . . . . . 94
5.4.2 Un outil SAMT4MDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.5 Conclusion, travaux connexes et synthèse . . . . . . . . . . . . . . . . . . . . . . 97
5.5.1 Positionnement par rapport à l’état de l’art . . . . . . . . . . . . . . . . . 98
5.5.2 Synthèse, points forts et travaux futurs . . . . . . . . . . . . . . . . . . . . 99
5.5.3 Liste des publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6 Synthèse, direction de recherche et perspectives 102

6.1 Services adaptables : modèles à l’exécution . . . . . . . . . . . . . . . . . . . . . 103
6.2 Composition et tissage de modèles . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.3 L’appariement des métamodèles et la transformation . . . . . . . . . . . . . . . . 105

Bibliographie 106
Avant propos

Parcours scientifique
Mes premier pas dans la recherche ont été réalisés, le second semestre de l’année 1988 à l’uni-
versité de Montpellier II, lors de mon travail de stage de DEA. Le CRIM (Centre de Recherche
en Informatique de Montpellier) fut alors mon premier centre de recherche. Celui-ci a donné nais-
sance après fusion avec le LAM (Laboratoire d’automatique de montpellier) à une unité mixte le
LIRMM (Le Laboratoire d’informatique, de Robotique et de Microélectronique de Montpellier).
J’ai débuté mon stage de DEA sous la responsabilité des professeurs Claude Boksenbaum et Jean
Ferrier ou je devais étudier les techniques de contrôles de concurrences classiques et leur mise en
oeuvre dans les bases de données orientées objets. Ce stage entré dans le cadre d’une coopération
avec L’INRIA autour du grand projet O2 sous la conduite de Francois Bancilhon, visant à la
conception d’un système de gestion de bases de données orientée objets. Le point de départ de
mes recherches a été l’article de référence publié en 1981 : Concurrency Control in Distributed
Database Systems. ACM Comput. Survev par Philippe Bernstein ainsi que le livre publié en 1987
par le même auteur chez Addison-Wesley sur le même sujet. Au delà du mécanisme de “Contrôle
de Concurrence” étudié lors de mon stage de DEA, l’approche Orientée Objets à travers le projet
O2 initialement, a constituée sans aucun doute la base pour mes travaux de recherche futurs. Le
projet O2 initié en 1988 a engendré une intense activité de recherche autour de l’approche orientée
objet au niveau national et a donné lieu à un livre Building an Object-Oriented Database System,
The Story of O2, regroupant les principaux articles produit au cours de ce projet. La plupart
de ces articles ont constitués mes références bibliographiques initiales autour de l’approche objet.

Poursuivant et me confortant dans la voie que j’avais empruntée, j’ai décidé juste après mon
DEA, de déposer une demande de bourse d’étude afin d’entamer une thèse en informatique.
En septembre 1989 la demande de bourse m’a été accordée dans le cadre des accords franco-
algériens et j’ai ainsi continué en thèse dans l’équipe de M.Claude Boksenbaum dans le domaine
des systèmes d’information et les bases de données. Mon travail concernait la conception d’un
système d’aide à l’organisation et la réalisation de tâches dans un environnement bureautique.
Les systèmes de Workflow et de Groupware pour lesquels une intense activité de recherche a vu
le jour au début des années 1990, n’ont fait que conforter mes travaux de recherche durant ma
thèse. Le concept clé sur lequel a reposé ma thèse est celui de tâche qui permet de modéliser
l’activité d’un employé dans une organisation. Autour de ce concept, notre travail s’est décliné
en trois étapes :

– la conceptualisation (définition des concepts et des fonctionnalités du système)

– la spécification (formalisation des concept et des fonctionnalités)
– la représentation (langage adéquat pour la mise en oeuvre )

L’un des principaux constat de mon travail de thèse fut que les deux principaux courants de
l’approche objet issus des langages de programmation et des bases de données, n’étaient pas
adaptés à la représentation du concept de tâche dédié à la modélisation de l’activité d’un em-
ployé. Cette dernière nécessitait une richesse sémantique et une flexibilité dans la représentation,
que n’avaient pas les deux principaux courants de l’approche objet.

4
TABLE DES MATIÈRES 5

Les langages de représentation de connaissances issus du courant de l’intelligence artificielle

et inspirés du concept de frame de Marvin Minsky sont alors apparus comme les plus adaptés à
notre problématique.

Dès la fin de ma thèse j’ai été sollicité par un collègue brésilien pour participer dans un
nouveau programme de postgraduation au Brésil à l’Université Fédérale du Maranhão (UFMA).
Mon parcours international à démarré en Janvier 1994 avec une première expérience au Brésil
comme professeur visitant jusqu’à Août 1997. Suivi d’une expérience au Portugal de septembre
1997 jusqu’à Août 1999 comme professeur invité au département des systèmes d’information de
l’université de Minho. Les connaissances acquise durant ma thèse de doctorat sur l’approche
orientée objets et les systèmes de gestion de tâches, ont été renforcées durant les six années de
mon parcours international par le développement de deux principaux projets de recherche. Ces
projets avaient pour premier objectif l’encadrement d’étudiants en master, et ont été menés en
coopération avec d’autre collègues du Brésil, Portugal et Australie. Voici une description succinte
des deux projets :
- Le projet GOOSM 1 (1996-1998, Brésil) le principal objectif de ce projet fut la proposition
d’un modèle conceptuel dédié à la conception des bases de données avancées (orientées objets
en particulier). Ce modèle intègre d’une part la richesse structurelle des modèles sémantiques,
et d’autre part les aspects comportementaux des modèles a objets. Ce projet a donné lieu à un
travail de Master présenté à l’UFMA au Brésil .

- Le projet WEICOT 2 (1996-2000, Brésil puis Portugal) fait suite à mes travaux de thèse
sur la conception d’un système d’aide à la réalisation de tâches. Ce projet a été mené en co-
opération avec le Professeur Labidi, qui, après avoir terminé sa thèse a Nice en 1995, a rejoint
le programme de Postgraduation au Brésil. Notre constat en ce temps fut que les systèmes de
Workflow proposés n’étaient pas adaptés aux activités complexes faiblement structurées et de
longues durées. Nous avons alors étudié une extension aux systèmes de workflow existants en
proposant deux mécanismes fondamentaux pour la gestion des activités complexes : la coopéra-
tion (plusieurs acteurs sont généralement impliqué dans la réalisation d’une activité complexe)
et l’organisation temporelle (la planification des activités de longues durées). Ce projet a donné
lieu à deux travaux de Master présenté à l’UFMA au Brésil

En Septembre 1999 je suis recruté à L’ESEO (École Supérieure de l’ouest) sur Angers. En no-
vembre 2000 l’OMG (Object Management Group) a proposé une approche nommée Model Driven
Architecture (MDA™) pour le développement et la maintenance des systèmes à prépondérance
logicielle. Cette approche s’insère dans une tendance plus générale appelée Ingénierie Dirigée
par les Modèles (IDM) qui considère les modèles comme les outils de base dans la production,
le fonctionnement et l’évolution des systèmes logiciels. Suite à l’approche objet des années 80
et de son principe du « tout est objet », l’ingénierie du logiciel s’est orientée vers l’ingénierie
dirigée par les modèles et le principe du « tout est modèle ». Cette nouvelle tendance s’inscrit
en continuité avec nos précédents travaux, où l’approche par objets a toujours représentée notre
cadre conceptuel pour le modélisation et la représentation des connaissances dans les différents
domaines d’applications. En février 2002, avec l’arrivée de Denivaldo Lopes du Brésil pour réali-
ser une thèse de doctorat en France, j’ai commencé mon premier encadrement autour de l’IDM
avec l’aide d’une bourse du conseil général de Maine et Loire.

1. (Generic Object Oriented Semantic Model for Advanced Database Design)

2. (Workflow Environment Integrating Cooperation and Temporal Organisation)
TABLE DES MATIÈRES 6

Le présent document
Traditionnellement, la phase de rédaction de rapport d’habilitation à diriger des recherches
est l’occasion de prendre du recul par rapport au travail en cours pour faire une synthèse et une
analyse sur tout ce que nous avons réalisé dans le domaine de la recherche. Il me paraît évident
que si je reproduisais la synthèse de tous mes travaux issus de mon parcours international dans ce
document, ceci apparaîtrait incohérent et son contenu éclaté. Ainsi, il ne me semble pas pertinent
de faire cohabiter, dans un même document, mes travaux sur la conception des bases de données
avancées d’une part, les systèmes de workflow d’autre part avec ceux sur l’ingénierie des modèles.
En conséquence le présent document vous présente une synthèse de mes travaux depuis 2002,
année de lancement de mon premier projet de recherche autour de l’IDM et l’inscription de
mon premier thésard sur cette nouvelle thématique. Cependant, je présenterai en annexe de
ce document un résumé des différents projets de recherche mené en coopération avec d’autre
collègues lors de mon parcours international. Ainsi, les travaux présentés ici portent sur l’étude
et l’application de l’approche IDM à deux domaines important de la dernière décennie :
– Les services Web comme plateforme de développement et d’intégration des applications
internet ;
– l’Informatique ubiquitaire et les applications sensibles au contexte.

Au delà de l’application des concepts et des techniques de l’IDM à deux domaines phares et des
contributions qui en découlent, la spécificité de ce travail et une de ses originalités est d’avoir
renforcé et mis en oeuvre un des principes essentiel du génie logiciel et fondateur de l’IDM : le
principe de la séparation des préoccupations.
Cette habilitation est en partie le fruit du co-encadrement de trois thèses de doctorat. Deux
thèses déja soutenues respectivement à l’université de Nantes et d’Angers en collaboration avec
les professeurs J. Bézivin (LINA, Nantes) et S. Loiseau (LERIA, Angers). La dernière thèse est en
phase finale et sera soutenue courant 2011 à l’université de Tunis dans le cadre d’une coopération
avec Prof. M. Gammoudi (Fac Sciences, Tunis). Cette dernière thèse est co-encadré avec Prof.
M. Huchard du laboratoire LIRMM de Montpellier.
Chapitre 1

Introduction

Nos travaux ont pour contexte l’ingénierie dirigée par les modèles (IDM), que l’on peut définir
au sens large comme une nouvelle approche qui étudie l’usage des modèles dans les processus
d’ingénierie. Comme dans tout processus d’ingénierie, le processus est indissociable du produit.
Le produit est le résultat à atteindre, tandis que le processus est le chemin qu’il faut parcourir
pour atteindre le résultat. L’ingénierie dirigée par les modèles s’inscrit dans cette perspective
qui considère les modèles comme les outils de base dans la production, le fonctionnement et
l’évolution des systèmes. Les systèmes d’information sont notre champ d’application avec deux
domaines cibles :
- les plateformes services Web ;
- l’informatique pervasive et les applications sensibles au contexte.

Ces deux domaines phares de l’ère Internet et de la mobilité sont liés. Les applications sen-
sibles au contexte ont suscité un grand intérêt en particulier depuis l’émergence des technologies
sans fil d’une part et des terminaux mobiles d’autre part. Ces applications sont, dans le cadre
d’internet, majoritairement distribuées et mobiles. D’un autre coté, les services Web ont réussi à
être les plateformes consensuelles d’interopérabilité entre applications réparties sur le Web. Au-
jourd’hui, les plateformes services Web, regroupent les technologies les plus prometteuses pour
la mise en œuvre des applications distribuées et mobiles sur internet et, en particulier, des ap-
plications sensibles au contexte. Le concept de "services sensibles au contexte" est de nos jours
un domaine à part entière.

L’objectif principal de nos travaux est l’étude et l’application de l’ingénierie dirigée par les
modèles en se focalisant sur trois de ses principaux axes :
- les techniques de modélisation et métamodélisation ;
- les techniques de transformation ;
- les méthodologies de développement.

Nos contributions s’inscrivent dans ces trois principaux axes de l’ingénierie dirigée par les modèles
et dans leurs applications à nos deux domaines cibles : les services Web et les applications sensibles
au contexte. Une des originalités de nos travaux est d’avoir suivi une approche qui respecte,
renforce et met en œuvre le principe de la séparation des préoccupations, un des principes
essentiels du génie logiciel et fondateur de l’ingénierie dirigée par les modèles. Nous allons dans
un premier temps présenter brièvement l’IDM suivi de nos deux domaines d’application afin de
préciser le contexte général de nos travaux. Nous discuterons ensuite nos principales contributions
dans la section 1.2

7
CHAPITRE 1. INTRODUCTION 8

1.1 Contexte et domaines applicatifs

1.1.1 L’ingénierie dirigée par les modèles
En novembre 2000, l’OMG (Object Management Group), initie l’approche MDA (Model
Driven Architecture) [Soley, 2000] pour le développement et la maintenance des systèmes à pré-
pondérance logicielle. Cette approche s’inscrit dans une tendance plus générale appelée Ingénierie
Dirigée par les Modèles (IDM) qui met le modèle au centre du développement des logiciels et des
systèmes d’information. L’IDM a pour but d’apporter une nouvelle vision unifiée de concevoir des
applications en séparant la logique métier de l’entreprise, de toute plateforme technique. En effet,
la logique métier est stable et subit peu de modifications au cours du temps, contrairement à l’ar-
chitecture technique. Il paraît donc bénéfique de séparer les deux pour faire face à la complexité
des systèmes d’information et aux coûts excessifs de migration technologique. Cette séparation
autorise alors la capitalisation du savoir logiciel et du savoir-faire de l’entreprise. A ce niveau,
les technologies basées sur l’approche objet et l’approche composant n’ont pas pu tenir leurs
promesses. Face à la complexité croissante des systèmes d’information des entreprises, aux nou-
veaux types d’applications telles que les applications distribuées sur le Web, Il devenait de plus
en plus difficile de développer des logiciels basés sur ces technologies. Le recours à des procédés
supplémentaires, comme les patrons de conception [Gamma et al., 1993] ou la programmation
orientée aspect [Kiczales et al., 1997], était alors nécessaire. De manière encore plus radicale que
pouvaient l’être les approches des patrons et des aspects, l’IDM vise à fournir différents types de
modèles pour exprimer séparément chacune des préoccupations des utilisateurs, des concepteurs,
des architectes, etc. C’est par ce principe de base fondamentalement différent que l’IDM peut
être considérée en rupture par rapport aux approches objets et post-objets. Elle offre la pos-
sibilité d’arrêter l’empilement des technologies qui nécessite une conservation des compétences
particulières pour faire cohabiter des systèmes divers et variés. Ceci est permis grâce au passage
d’une approche interprétative à une approche transformationnelle, où les concepteurs ont un rôle
simplifié et amoindri grâce à la construction automatisée et aux techniques de transformations
entre modèles. L’initiative MDA proposée par l’OMG peut se définir comme la réalisation des
principes de l’ingénierie des modèles autour d’un ensemble de standards comme le MOF, XMI,
OCL, UML, CWM, SPEM, QVT, ODM etc. Nos travaux seront basés sur l’approche MDA et
ses technologies standards.

1.1.2 Les services Web et applications internet

Depuis son apparition, l’informatique s’est développée massivement et surtout très rapide-
ment. Si les années 80 ont vu la banalisation de l’ordinateur personnel, les années 90 ont permis
d’étendre l’utilisation de l’informatique à tous les domaines. L’explosion de l’usage des réseaux
et des systèmes distribués a profondément changé nos méthodes de travail. Les logiciels informa-
tiques sont alors devenus omniprésents dans les entreprises (par exemple : système de contrôle
et de supervision, comptabilité et gestion des ressources humaines), dans les hôpitaux, dans les
écoles, et sont de plus en plus utilisés par le grand public. Ainsi, la période de la fin des années
1980 et début des années 1990 a vu une multiplication des plateformes et des logiciels hétérogènes.
C’est ainsi que la problématique de recherche désignée par le terme interopérabilité a vu le jour
durant cette période. Son objectif est de permettre à des systèmes hétérogènes de communiquer
et d’échanger des informations de manière transparente.
Les intergiciels (middleware) tels que CORBA (Common Object Request Broker Architec-
ture), Java RMI (Java Remote Methode Invocation) et DCOM (Distributed Component Object
Model) ont été proposés pour simplifier le développement des logiciels et surtout permettre l’inter-
opérabilité entre les systèmes distribués et hétérogènes. Ils ont répondu de manière satisfaisante
à cette interopérabilité dans le contexte des systèmes distribués, mais l’apparition d’internet a
toutefois introduit de nouvelles exigences pour lesquelles ils n’avaient pas été conçus. Les ser-
vices Web ont été proposés afin de remplacer ou compléter les anciens intergiciels incapables
de répondre efficacement à l’exigence d’interopérabilité sur internet. Les services Web sont un
CHAPITRE 1. INTRODUCTION 9

ensemble de technologies standards, prometteuses pour le développement, le déploiement et l’in-

tégration d’applications Web représentées par des services.

En plus de leur standardisation par le W3C, la vraie force des services Web est dû à leur large ac-
ceptation par l’ensemble des acteurs des systèmes d’information et des logiciels sur internet. Une
plateforme service Web permet de créer, de personnaliser et d’héberger des services en utilisant
les technologies standards. Dans nos travaux nous étudions et expérimentons l’approche MDA
pour la plateforme service web. Notre démarche sera illustrée par un exemple typique d’applica-
tion internet qui est à la fois B2C (Business-to-Consumer ) et B2B (Business-to-Business). Elle
illustre donc bien la problématique des applications métiers qui mettent en œuvre des interactions
aussi bien avec les clients finaux qu’avec d’autres applications de partenaires.

1.1.3 L’informatique pervasive et les applications sensibles au contexte

Ces dernières années ont vu apparaître toute une gamme d’outils informatiques non tradi-
tionnels capables d’accompagner les activités quotidiennes de l’être humain. Par exemple, des
téléphones portables utilisables comme cartes de crédit ou qui passent automatiquement en mode
silencieux lors de l’entrée en réunion, des réfrigérateurs capables de commander par internet les
produits en fonction du besoin, des maisons qui adaptent la coloration de l’éclairage en fonction
de l’humeur des habitants, des dispositifs GPS qui guident le conducteur en tenant compte non
seulement du trajet mais également du trafic routier et de la dépense en carburant. Les applica-
tions ont également évolué pour s’adapter à ces nouveaux outils, qualifiés de pervasifs. L’informa-
tique pervasive, également appelée ubiquitaire, s’occupe du développement des applications qui
automatisent ce type d’activités non traditionnelles. Le terme «informatique ubiquitaire» a été
proposé pour la première fois en 1991, par Weiser [Weiser, 1991]. Il a idéalisé un environnement
intelligent doté de capteurs ayant pour objectif de réaliser certaines activités sans interférence
humaine. La caractéristique essentielle des applications pervasives est d’anticiper le comporte-
ment de l’utilisateur en réagissant sans son intervention et de manière transparente. L’objectif
premier d’un système pervasif est de permettre de répondre au besoin de l’utilisateur où qu’il
se trouve et à n’importe quel moment. L’importance croissante de ces applications fait que des
nombreux travaux récents s’y intéressent. Dans [Abowd et Mynatt, 2000] quatre principaux axes
de recherche de l’informatique pervasive sont distingués : (i) les interfaces naturelles, permettant
de communiquer avec l’environnement informatique selon des modes de communication usuels
dans l’environnement physique, comme la parole, l’écriture ou la manipulation d’objets phy-
siques, (ii) les interfaces qui doublent la mémoire de l’utilisateur en restituant des scènes réelles
enregistrées automatiquement, (iii) l’informatique du quotidien (everyday computing), dont l’en-
jeu est d’assurer une présence continue auprès de l’utilisateur et (iv) l’informatique sensible au
contexte. En plus des services Web, ce deuxième axe représente notre second domaine d’appli-
cation de l’approche IDM à partir de MDA. La sensibilité au contexte concerne la perception
de l’environnement pour interagir plus naturellement avec l’utilisateur. Cette perception passe
par l’utilisation de capteurs de l’environnement physique, de matériels auto-descriptifs, de des-
cription des personnes, etc. Le contexte fournit un grand éventail d’informations qui permet au
système pervasif d’agir de façon adaptée. Cette sensibilité au contexte a donc pour premier objec-
tif l’adaptation du système pervasif en cours d’exécution. Nous montrerons comment l’approche
MDA, à partir du principe de séparation des préoccupations et des techniques de transformations
adaptées, permet de mettre en œuvre les applications sensibles au contexte.

1.2 Démarche de recherche et contributions

La séparation des préoccupations est un concept présent depuis de nombreuses années dans
différentes disciplines comme l’ingénierie des logiciels [Parnas, 1972] [Dijkstra, 1974], les bases
de données [Bachman, 1974], les interfaces homme machine à travers MVC [Reenskaug, 1979] et
les réseaux et l’internet à travers les niveaux du modèle TCP/IP [Stevens, 1994]. Les différentes
préoccupations des concepteurs apparaissent comme les points clés pour organiser et décomposer
CHAPITRE 1. INTRODUCTION 10

une application en un ensemble d’éléments compréhensibles et facilement manipulables. Dans le

contexte du logiciel et du système d’information, la séparation en préoccupations apparaît d’une
part dans les différentes étapes de son cycle de vie mais aussi d’autre part dans les différentes
natures des préoccupations. Il peut s’agir de préoccupations d’ordre fonctionnel (séparations des
fonctions de l’application), technique (séparation des propriétés du logiciel système), ou encore
liées aux rôles des acteurs du processus logiciel (séparation des actions de manipulation du
logiciel). Par ces séparations, le logiciel n’est plus abordé dans sa globalité, mais par parties.
Cette approche réduit la complexité de conception, de réalisation, mais aussi de maintenance
d’un logiciel et en améliore le compréhension, la réutilisation et l’évolution. Cette séparation
est la motivation d’approches telles que la programmation par aspects [Kiczales et al., 1997], les
filtres de composition [Aksit, 1996], la programmation adaptative [Lieberherr et al., 2001] et la
programmation générative [Czarnecki et Eisenecker, 1999].
Dans le cadre de l’ingénierie dirigée par les modèles, la séparation des préoccupations est
un principe de base. Elle fournit un support méthodologique de modélisation. Elle permet de
décomposer la modélisation d’un système en plusieurs modèles dédiés a des préoccupations dif-
férentes. Associé a ce découpage, un processus d’intégration des différents modèles est requis.
L’association du découpage et du processus d’intégration facilite la collaboration des différents
acteurs d’un processus logiciel. L’approche MDA propose une organisation des modèles en sui-
vant la séparation des préoccupations. La principale séparation est en termes de préoccupations
fonctionnelles et de préoccupations techniques. Pour cela MDA organise les modèles en deux
grandes catégories : les modèles indépendants des plates-formes (PIM) et les modèles spécifiques
aux plates-formes (PSM). Au sein de ces deux catégories, les modèles sont structurés par niveaux
d’abstraction : du plus général au plus précis. La transition d’un niveau à l’autre est réalisée par
raffinements successifs.

Notre démarche pour l’étude et l’application de l’approche MDA est guidée par ce principe
de la séparation des préoccupations. Le point clé de notre démarche de recherche est la mise en
œuvre de ce principe dans l’ensemble des trois problématiques nous concernant : la modélisation
et la métamodélisation, la transformation et la méthodologie de développement.
Ainsi, les principales contributions de nos travaux reposent et découlent de ce principe de
la séparation des préoccupations, et s’inscrivent dans les trois principaux thèmes de l’IDM et
MDA :
- les techniques de modélisation et métamodélisation ;
- les techniques de transformation ;
- les méthodologies de développement.

Nous avons appliqué et renforcé le principe de la séparation des préoccupations lors de l’étude
et la mise en oeuvre de l’IDM à travers MDA à nos deux domaines cibles : les services Web et
les applications sensibles au contexte. Deux types de contributions résultent de nos travaux :
Celles liées aux techniques de MDA intrinsèquement (processus de transformation) et celles qui
découlent de l’application de MDA. Toutes ces contributions sont résumées dans les trois sections
ci-dessous dédiées aux trois principaux axes de MDA.

1.2.1 Techniques de modélisation et méta modélisation

Lorsque nous avons étudié l’approche MDA et son application à la plateforme services web
pour le développement des applications internet, nous nous sommes intéressés à deux langages
standard de L’OMG : UML et EDOC. Nous avons étudié ces langages pour la représentation
d’une part des modèles métiers (PIM) et d’autre par pour la représentation de la plateforme
cible service web (PSM). Nous avons alors appliqué le principe classique de séparation des pré-
occupations de MDA (PIM-PSM), et nos contributions ont été les suivantes :

– la définition des métamodèles pour les plateformes J2EE et dotNet à partir des langages
UML et EDOC ;
CHAPITRE 1. INTRODUCTION 11

– la définition d’un modèle d’application internet et sa mise en œuvre sur les plateformes
J2EE et dotNet ;
– Une étude de l’impact du type du langage de modélisation dans une démarche MDA :
UML (type généraliste) versus EDOC (type DSL - Domain Specific Language).

L’étude des applications sensibles au contexte à partir de l’approche MDA nous a mené à nous
intéresser aux ontologies et la spécification ODM de l’OMG. En effet, les langages issus de la
mouvance des ontologies semblaient plus adaptés à la représentation des données contextuelles.
Notre principale préoccupation a été de regarder d’une part comment définir les information
contextuelles, et d’autre part comment les intégrer dans la logique métier d’une application. Nos
contributions dans cette partie sont les suivantes :
– la proposition d’un métamodèle de contexte centré utilisateur dans un environnement mo-
bile. Notre métamodèle prend en compte les entités contextuelles les plus référencées dans
l’état de l’art. Ceci nous permet de dériver des modèles de contexte au plus près des situa-
tions réelles du développement d’applications sensibles aux contexte ;
– l’application du principe de séparation des préoccupations au niveau modèles entre la
logique métier et les données contextuelles. Les modèles de contexte (CM) et les modèles
métiers (PIM) sont définis séparément puis intégrés par une technique de transformation
adaptée, qui sera discutée dans la section suivante. Nous avons proposé deux nouveaux
types de modèles désignés par CPIM (Contextual Platform Independant Model) et CPSM
(Contexual Platform Specific Model).

1.2.2 Techniques de transformations

Dès nos premiers pas dans l’IDM, nous nous sommes intéressés au processus de transfor-
mation proposé par l’OMG [OMG, 2005]. Dans ce processus, la définition des règles de trans-
formations est faite au niveau des métamodèles et l’exécution de ces règles se fait au niveau
des modèles. En s’inspirant du domaine des bases de données et en particulier des travaux de
Bernstein [Bernstein, 2003] d’une part, et celui des ontologies d’autre part [Do et al., 2003] nous
avons appliqué le principe de séparation des préoccupations au processus de transformation, et
nos contributions ont été les suivantes :

– une architecture originale du processus de transformation séparant explicitement les parties

mappings et transformations. Les mappings sont alors spécifiés par un expert alors que les
règles de transformations peuvent être générées automatiquement. Nous avons proposé un
métamodèle pour la définition des mappings entre deux métamodèles. Cette proposition a
été implémentée et expérimentée dans nos travaux sur la plateforme services web.
– une seconde architecture du processus de transformation intégrant le matching entre mé-
tamodèles comme une nouvelle composante en plus des mapping et transformation. Cette
architecture est dédiée à un processus semi-automatique de la transformation. Nous avons
proposé un algorithme de matching entre métamodèles et réalisé nos premières expérimen-
tations pour un processus semi-automatique de la transformation.

– L’application de MDA à la plateforme services Web nous a amené à nous interesser au

langage standard BPEL pour spécifier des modèles d’orchestrations de services. Nous avons
proposé une solution concrète basée sur les profils UML (valeurs marquées) pour réduire la
distance sémantique entre les métamodèles d’UML (diagramme d’activité ) et de BPEL,
et, ainsi, permettre la transformation du langage UML vers le langage BPEL.
– Une autre contribution importante découlant de notre application de MDA pour le dé-
veloppement des applications sensibles aux contexte, fut de regarder comment intégrer le
contexte et la logique métier au niveau des modèles. Nous avons alors proposé la technique
de transformation paramétrée, permettant de compléter les modèles métiers par les don-
nées contextuelles.
CHAPITRE 1. INTRODUCTION 12

1.2.3 Méthodologies de développement

A partir du processus classique de développement de logiciel selon l’approche MDA

[Kleppe et al., 2003], nous nous sommes intéressés à étendre ce processus et l’adapter pour nos
domaines d’applications en intégrant les résultats de nos travaux issus des techniques de modé-
lisation et métamodélisations, et ceux des techniques de transformations. Nos contributions ont
été les suivantes :

– une méthodologie de mise en œuvre de l’approche MDA pour le développement des appli-
cations internet sur la plateforme service web. Dans cette méthodologie nous mettons en
avant le principe de la séparation des préoccupations mapping versus transformation.

– une méthodologie nommée COMODE (Context-aware Model driven Development) qui a

pour objectif de fournir aux concepteurs d’applications sensibles aux contexte une méthode
de développement basée sur l’ingénierie dirigée par les modèles. Dans cette méthodologie
nous mettons en avant le principe de la séparation des préoccupations modèle métier versus
modèle de contexte.

– une méthodologie mettant en œuvre le processus semi-automatique de la transformation

dans l’approche MDA. Cette méthodologie détaille les principales activités du processus
semi-automatique de transformation en fonction de deux critères : comment réaliser cha-
cune des activités et qui en est responsable ? Dans cette méthodologie nous mettons en
avant le principe de la séparation des préoccupations matching versus mapping versus
transformation.

Le tableau 1.1 résume les principales contributions de notre étude de l’approche IDM à travers
MDA, et de son application à nos deux domaines cibles : les services Web et les applications
sensibles au contexte. La première colonne "IDM(MDA)", présente nos contributions aux trois
principales problématiques de l’IDM à partir de MDA, indépendamment du domaine d’appli-
cation. Les deux colonnes suivantes, présentent nos contributions suite à l’application de l’IDM
à partir de MDA à nos deux domaines cibles. Les contributions qui relèvent du principe de la
séparation des préoccupations sont illustrées en italique.

IDM (MDA) Services Web Sensibilité au contexte

Métamodèles pour les
UML (genéraliste) versus plateformes J2EE et modèle métier versus modèle de
Modélisation & dotNET contexte
EDOC (DSL : langage Métamodèle de contexte
Métamodélisation Métamodèles UML versus
spécifique au domaine) CPIM et CPSM
EDOC

mapping versus application du principe

mapping versus
transformation transformation Transformation paramétrée
Transformation
matching versus mapping Transformation UML vers Composition de modèles
Processus semi-automatique BPEL
Approche MDA avec le MDA pour la plateforme
Méthodologie COMODE
Méthodologie de principe (mapping versus services Web
transformation) (MDA pour applications sensibles
développement (mapping versus
Processus semi-automatique au contexte)
transformation)

Table 1.1 – Les principales contributions de notre étude

CHAPITRE 1. INTRODUCTION 13

1.3 Organisation du mémoire

La suite de ce document est composée de cinq chapitres.

le chapitre 2 présente l’ingénierie dirigée par les modèles dans le but d’une part de définir les
notions abordées dans ce mémoire, et d’autre part de situer notre contribution liée au processus
de transformation dans MDA.

le chapitre 3 présente l’application de l’approche MDA à la plateforme services Web. Ce cha-

pitre est centré sur la thèse de Denivaldo Lopes soutenue en juillet 2005 et co-encadré avec le
Pr. Jean Bézivin de l’université de Nantes.

le chapitre 4 présente l’application de l’approche MDA pour le développement des applications

sensibles aux contexte. Ce chapitre est basé sur les travaux de thèse de Samyr Vale soutenue en
décembre 2009 et co-encadré avec le Pr.Stéphane loiseau de l’université d’Angers.

le chapitre 5 présente notre approche pour la mise en œuvre d’un processus semi-automatique
de la transformation dans MDA. Ce chapitre est une synthèse des travaux en cours dans le cadre
d’une thèse co-encadré avec les professeurs Marianne Huchard (Lirmm, Montpellier) et Mohamed
Gammoudi (Fac des sciences de Tunis). La thèse sera soutenue par Wajih Alouini à la Fac des
Sciences de Tunis courant 2011.

Dans chacun des chapitres 3, 4 et 5 nous dresserons un panorama des travaux connexes et nous
situerons notre approche par rapport à l’état de l’art. Nous insisterons aussi sur les points forts
et les travaux qu’il reste à mener.

Le chapitre 6 présente la conclusion résumant les principaux apports de nos travaux et dis-
cutant des perspectives de recherche que nous entrevoyons pour les prochaines années.

Deux annexes sont également fournies. L’annexe A est dédiée à mon curriculum vitae. L’an-
nexe B contient une sélection d’articles qui balaie les projets de recherche menés.
Chapitre 2

L’IDM, l’approche MDA et

positionnement.

MDA is probably not the silver bullet for software engineering, but :
there is no reasonable alternative to MDA [Bézivin, 2003].

2.1 Introduction
Avec le développement des réseaux et de l’avènement de l’internet et principalement du
Web, les systèmes d’information n’ont jamais été autant au centre de la stratégie des entreprises
que durant la dernière décennie. Les fonctionnalités qu’ils offrent, leur facilité d’utilisation, leur
fiabilité, leur performance et leur robustesse sont des qualités indéniables qui permettent aux
entreprises d’innover et d’être compétitives. De nouvelles technologies et plate-formes d’exécu-
tions et de nouvelles versions de logiciels sont proposées continuellement afin de faciliter la mise
en œuvre de ces systèmes d’information tout en accroissant leurs qualités. La dernière en date
de ces technologies et plate-forme d’exécutions est certainement la plate-forme orientée service
et l’architeture logicielle associée désignée par l’architecture orientée service (notée SOA pour
Services Oriented Architecture).
Le vrai problème de ces nouvelles technologies et plate-formes d’exécutions, est qu’elles sont
toujours plus complexes et allourdissent considérablement les contraintes imposées aux équipes de
développement. Cela met les entreprises devant un vrai dilemme, car elles hésitent entre adopter
une nouvelle plate-forme et subir le coût de la migration ou ne pas l’adopter et prendre le risque
de voir les concurrents devenir plus compétitifs en ayant adoptée la nouvelle plate-forme.
Ce dilemme est un inconvénient majeur pour l’évolution des systèmes d’information des en-
treprises. La compléxité des plates-formes d’exécutions est la cause réelle de cet inconvénient,
pourtant ces plates-formes sont conçues pour améliorer la productivité et faciliter la maintenance
des systèmes informatiques. Pour répondre à ce frein au développement des systèmes d’informa-
tion, il était nécessaire de définir une approche permettant de faire face à la compléxité. Cette
approche se devait d’être fléxible et générique afin de pouvoir s’adapter à tout type de plate-
forme.
En novembre 2000, l’Object Management Group (OMG) a proposé l’approche nommée Model
Driven Architecture (MDA™) pour le développement et la maintenance des systèmes à prépon-
dérance logicielle [Soley, 2000]. MDA applique la séparation des préoccupations entre la logique
métier des systèmes informatiques et les plates-formes utilisées et se fonde sur l’utilisation mas-
sive des modèles. Ainsi, la pérennité est l’objectif principal de MDA. Il s’agit de faire en sorte
que la logique métier des applications ne soit plus mêlée aux considérations techniques de mise
en production. Il devient dès lors possible de capitaliser les savoir-faire et d’être beaucoup plus
réactif aux chagements technologiques. Pour atteindre cet objectif, MDA vise à représenter sous
forme de modèles toute l’information utile et nécessaire à la construction et à l’évolution des
systèmes d’information. Les modèles sont au centre du cycle de vie des logiciels et des systèmes
d’information.

14
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 15

Figure 2.1 – Relations entre système, modèle, métamodèle et langage.

Au-delà de la proposition spécifique MDA de l’OMG, l’Ingénierie Dirigée par les Modèles
(IDM), ou Model Driven Engineering (MDE) en anglais, permet d’appréhender le développement
de systèmes complexes en se concentrant sur une préoccupation plus abstraite que la program-
mation classique. Il s’agit d’une forme d’ingénièrie générative dans laquelle tout ou partie d’une
application est engendrée à partir de modèles. L’objectif de l’IDM est de définir une approche
pouvant intégrer différents espaces technologiques [Kurtev et al., 2002]. Ainsi, l’approche MDA
devient une variante particulière de l’Ingénierie Dirigée par les Modèles. L’IDM peut être vue
comme une famille d’approches qui se développent à la fois dans les laboratoires de recherche et
chez les industriels impliqués dans les grands projets de développement logiciels.
Dans ce chapitre, nous proposons dans un premier temps une présentation des concepts clés de
l’IDM et des principales approches afférentes (section 2.2) puis nous focaliserons notre discussion
sur l’approche MDA et les travaux de normalisation de l’OMG (section 2.3). Nous détaillons
les deux premiers axes principaux de l’IDM selon l’approche MDA et surlesquels portent nos
travaux de recherche : le processus de développement et la modélisation (métamodélisation).
La section 2.4 présente la transformation de modèles qui est le troisième axe clé de MDA. La
section 2.5 présente une première contribution de nos travaux de recherche liée au processus de
transformation de modèles dans MDA. Le principe de la séparation des préoccupations est alors
mis en œuvre entre d’une part la spécification des correspondances entre métamodèles, et d’autre
part la génération des règles de transformations. Nous concluons enfin par la section 2.6 avec
une discussion sur les limites actuelles de l’IDM et les travaux de recherche en cours.

2.2 Concepts de bases de l’IDM

Cette section définit les concepts de base de l’ingénierie dirigée par les modèles et les relations
qui lient ces concepts. Les definitions présentées dans cette section sont inspirées des travaux de
l’action spécifique MDA du CNRS [Bézivin et al., 2005]. Nous allons nous inspirer de la figure 2.1
pour présenter les différentes définitions autour des quatre concepts de base : système, modèle,
métamodèle et langage.

2.2.1 Modèle et système

Le concept central de l’IDM est la notion de modèle. Il n’existe pas à ce jour de définition
universelle de ce qu’est un modèle (tout comme il n’existe pas de définition universelle de ce qu’est
un objet, un aspect ou un service web). Néanmoins, à partir de différentes définitions proposées
dans la littérature [Bézivin et al., 2005] [Seidewitz, 2003], un consensus se dégage, et la définition
suivante proposée dans [Bézivin et Gerbé, 2001] est très représentative de ce consensus :
"A model is a simplification of a system build with an intended goal in mind.
The model should be able to answer questions in place of the actual system”
Cette définition stipule qu’un modèle est une abstraction d’un système construit dans un but
précis. De ce fait, le modèle contient un ensemble restreint d’informations sur un système et
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 16

cet ensemble d’informations est choisi pour être pertinent vis a vis de l’utilisation qui sera faite
du modèle. On dit alors que le modèle représente le système. On déduit de cette définition la
première relation fondamentale de l’IDM, entre le modèle et le système qu’il représente, nommée
represents dans [Atkinson et Kühne, 2003][Bézivin, 2004a]. Par analogie avec les langages de
programmation, un programme exécutable représente le système alors que le code source de ce
programme représente le modèle.

2.2.2 Métamodèle : langage de modélisation

Pour qu’un modèle soit productif, et c’est l’objectif premier de l’IDM, il faut qu’il puisse
être manipulé par une machine et donc que le langage dans lequel ce modèle est exprimé soit
clairement défini. On utilise pour cela la notion de métamodèle qui est au coeur de l’IDM. La
définition suivante assez consensuelle dans la litérature est présentée dans [OMG, 2002b] :
"A meta-model is a model that defines the language for expressing a model "
Ainsi, un métamodèle représente les concepts du langage de métamodelisation utilisé et la sé-
mantique qui leur est associée. En d’autres termes, le métamodèle décrit le lien existant entre
un modèle et le système qu’il représente. Cette notion de métamodèle conduit à l’identifica-
tion d’une seconde relation, liant le modèle et le langage utilisé pour le construire, désignée par
conformsTo dans [Bézivin, 2004a][Favre, 2004] et stipule en fait qu’un modèle est conforme à son
métamodèle. En poursuivant l’analogie avec le monde de la programmation, un programme est
écrit ou est exprimé dans un langage de programmation, un modèle est écrit ou est exprimé dans
un langage de modélisation. Chacun des langages (programmation ou modélisation) définit les
concepts et les règles à suivre (syntaxe) pour écrire un programme source conforme au langage
de programmation, ou spécifier un modèle conforme au langage de modélisation (métamodèle).
Cette notion de conformité est essentielle à l’ingénièrie dirigée par les modèles mais n’est pas
nouvelle : un texte est conforme à une orthographe et une grammaire et un document XML est
conforme à sa DTD.
Un autre point lié à la notion de métamodèle est la distinction entre langage et métamodèle
qui sont souvent confondus dans la litérature. Bien que ces deux concepts soient proches (voir
la définition ci-dessus), ils sont néanmoins différents [Bézivin et al., 2005]. Un langage est un
système abstrait alors qu’un métamodèle est une définition explicite de ce langage. En reprenant
la figure 2.1 et le monde de la programmation, plusieurs programmes écrits en langage C sont
conformes à la même grammaire du langage C. La grammaire est alors considérée comme un
modèle représentant cet ensemble de programmes et auquel chacun doit se conformer. Ces deux
relations permettent ainsi de bien distinguer le langage, qui joue le rôle de système, du (ou des)
métamodèle(s) qui joue(nt) le rôle de modèle(s) de ce langage. Pour résumer à partir de la figure
2.1, nous pouvons dire :
– Un programme source Java est un modèle pour toutes ses exécutions possibles.
– Le métamodèle d’un programme source Java est la grammaire de Java.
– La grammaire définit un ensemble de programmes syntaxiquement valides.
– Un programme source conforme à la grammaire appartient à cet ensemble.

2.2.3 Métamétamodèle : langage de métamodélisation

Les concepts de système, modèle et métamodèle ainsi que les relations qui les lient, repré-
sentent les principes de base sur lesquels s’appuie l’IDM. A partir de ces principes de bases,
d’autres non moins importants peuvent être déduits afin d’assurer une complétude et une cohé-
rence du cadre conceptuel de l’IDM. Ainsi, de la même manière qu’il est nécessaire d’avoir un
métamodèle pour interpréter un modèle, pour pouvoir interpréter un métamodèle il faut disposer
d’une description du langage dans lequel il est écrit : un métamodèle pour les métamodèles. Le
terme métamétamodèle est utilisé tout naturellement pour désigner ce métamodèle particulier.
Un métamétamodèle définit les notions de base permettant l’expression des métamodèles et des
modèles. Il permet d’exprimer les règles de conformités qui lient les entités du niveau modèle à
celle du niveau métamodèle. Afin de limiter le nombre de niveaux d’abstraction (et ainsi eviter
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 17

Figure 2.2 – Pyramide de modélisation à 4 niveaux

d’avoir à définir un métamétamétamodèle), un métamétamodèle est concu avec la propriété de

métacircularité, câd la capacité de se décrire lui-même. Dans le cas des grammaires, on spécifie
ainsi EBNF par une grammaire et dans le cas d’XML, c’est une DTD XML pour les DTD qui
joue le rôle de métamétamodèle. Ainsi, l’IDM est fondée sur une architecture à quatre niveaux
(cf. figure 2.2), initialement proposée dans le cadre du MDA [Soley, 2000], et qui fait mainte-
nant l’objet d’un large consensus en IDM [Seidewitz, 2003] [Bézivin et al., 2005]. Cette approche
consistant à considérer une hiérarchie de métamodèles n’est pas propre à l’OMG, ni même à
l’IDM, puisqu’elle est utilisée depuis longtemps dans différents domaines de l’informatique. Le
domaine des langages de programmation par le biais des grammaires [Aho et al., 1986], est peut
être, celui qui est le plus cité dans la litérature pour illustrer cette architecture à 4 niveaux.
Plusieurs hiérarchies peuvent être considérées et chaque hiérarchie définit un espace technique
[Kurtev et al., 2002, Bézivin et al., 2005]. Nous distinguons par exemple le modelware (espace
technique des modèles), le grammarware (espace technique des grammaires définies par les lan-
gages tels que BNF ou EBNF), le BDware (espace technique des bases de données), etc. Nos
travaux portent sur l’espace technique des modèles à travers l’approche MDA de l’OMG qui sera
décrite en détail dans la section 2.3.
C’est sur les principes présentés dans cette section que se base l’organisation de la modéli-
sation en IDM généralement décrite sous forme pyramidale (cf. figure 2.2). Le monde réel est
représenté à la base de la pyramide (niveau M0). Les modèles représentant cette réalité consti-
tuent le niveau M1. Les métamodèles permettant la définition de ces modèles (p. ex. UML)
constituent le niveau M2. Enfin, le métamétamodèle, unique et métacirculaire, est représenté au
sommet de la pyramide (niveau M3).

2.2.4 IDM et transformation de modèles

Les deux principaux artefacts de l’ingénièrie dirigée par les modèles sont les modèles et
les transformations de modèles. Rendre les modèles productifs consiste à leur appliquer des
transformations pour obtenir des résultats utiles au développement, généralement sous la forme
de modèles plus détaillés et proches de la solution technique finale ou du code. Pour ces raisons,
les transformations de modèles sont omniprésentes dans l’IDM. D’un point de vue général, on
appelle transformation de modèles tout programme dont les entrées et les sorties sont des modèles.
Cette section propose un tour d’horizon rapide des techniques et approches permettant la mise en
œuvre des transformations de modèles dans l’IDM. La section 2.4 sera dédiée à une présentation
plus détaillée de la transformation de modèles dans le cadre de MDA.
Une transformation de modèles s’apparente toujours à une fonction qui prend en entrée un
ensemble de modèles dits sources, et qui fournit en sortie un ensemble de modèles dits cibles. Les
modèles d’entrées et de sortie sont tous structurés par leur métamodèle. Ainsi, si une transfor-
mation de modèles s’exécute au niveau des modèles, elle se spécifie au niveau des métamodèles.
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 18

Figure 2.3 – Métamodèles et transformations de modèles

En effet, une transformation exprime des correspondances structurelles entre les modèles source
et cible. Ces correspondances structurelles s’appuient sur les métamodèles des modèles source
et cible [Blanc, 2005]. Par exemple, une transformation de modèles visant à transformer des
modèles UML vers des programmes JAVA spécifierait la règle suivante : à toute classe UML
correspond une classe JAVA. Cette même règle, exprimée selon les métamodèles, deviendrait :
à tout élément du modèle source instance de la métaclasse Class du métamodèle UML doit
correspondre un élément du modèle cible instance de la métaclasse Class du métamodèle JAVA.
Cette règle exprime bien une correspondance structurelle entre les métamodèles UML et JAVA
et plus précisément une correspondance entre les métaclasses Class (UML) et Class (JAVA).
La figure 2.3 illustre les relations entre les transformations de modèles et les métamodèles. Si la
transformation est ici binaire, avec une unique source et une unique cible, il est important de
souligner que les transformations de modèles peuvent être N-aires, c’est à dire qu’elles peuvent
avoir en entrée et en sortie plusieurs modèles.

2.2.5 IDM, et ses principales approches.

Dans le courant des langages spécifiques aux domaines et de la programmation générative,
un certain nombre d’approches basées sur les modèles se développent depuis une décennie. La
figure 2.4 ci-dessous présentée dans [Bézivin, 2009] illustre trois principales approches parmi cette
tendance : le Model-Integrated Computing (MIC), le Model-Driven Architecture (MDA) et les
Software Factories. Les deux sous-sections qui suivent présentent les grandes lignes des deux
approches MIC et software factories. Nos travaux étant centré principalement sur l’approche
MDA, celle-ci est présentée plus en détail dans la section 2.3.

2.2.5.1 Model-Integrated Computing (MIC)

Les travaux autour du Model-Integated Computing (MIC) [Sztipanovits et al., 2005] pro-
posent, dès le milieu des années 90, une vision du génie logiciel dans laquelle les artefacts de
base sont des modèles spécifiques au domaine d’application considéré. Initialement, le MIC a
été conçu pour le développement de systèmes embarqués complexes, alors qu’aujourd’hui il est
utilisé dans différents domaines orientés logiciels. Le MIC place les modèles au centre du cycle
de vie des systèmes incluant la spécification, la conception, le développement, la vérification,
l’intégration, et la maintenance.
Le MIC repose principalement sur une architecture à trois niveaux :
– Le niveau Meta qui fournit des langages de métamodélisation, des métamodèles, des envi-
ronnements de métamodélisation et des méta-générateurs pour créer des outils spécifiques à
un domaine qui seront utilisés dans le niveau MIPS (Model- Integrated Program Synthesis).
– Le niveau Modèle (MIPS) qui est constitué de langages de modélisation spécifiques à un
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 19

Figure 2.4 – Les approches et outils IDM.

domaine, et de chaînes d’outils pour la construction, l’analyse de modèles et la synthèse

d’applications.
– Le niveau Application qui représente les applications logicielles adaptables. Dans ce ni-
veau les programmes exécutables sont spécifiés en terme de composition de plates-formes
(CORBA, etc.).
En pratique, les idées du MIC sont implantées dans la suite d’outils GME [Davis, 2003]. (The
Generic Modeling Environment)

2.2.5.2 Les usines logicielles (Software Factories)

Les usines logicielles (Software Factories) [Greenfield et Short, 2003] sont la vision de Mi-
crosoft de l’ingénierie dirigée par les modèles. Le terme d’usine logicielle fait référence à une
industrialisation du développement logiciel et s’explique par l’analogie entre le processus de dé-
veloppement proposé et une chaîne de montage industrielle classique. Quatre points ont été
identifiés caractérisant une chaine de montage [Muller, 2006]. L’idée des usines logicielles est
d’adapter ces caractéristiques au développement logiciel, qui ont fait leur preuve pour la pro-
duction de masse de familles de produits matériels. Les deux premiers points correspondent à
la spécialisation des fournisseurs de logiciels et des développeurs à l’intérieur des équipes de dé-
veloppement. Le troisième point correspond à l’utilisation d’outils de génie logiciel spécifiques
au domaine d’application, c’est-à-dire de langages, d’assistants et transformations spécifiques.
Le dernier point correspond à la réutilisation de composants logiciels sur étagères. L’environne-
ment de développement Visual Studio .NET 2005 de Microsoft à été conçu autour de ces idées
et propose un environnement générique extensible pouvant initialement être configuré pour un
ensemble de domaines d’applications prédéfinis. Visual studio permet de manipuler des modèles
exprimés dans un langage proche des experts métiers, et d’en déduire le code source.

2.3 L’approche MDA

L’OMG a défini MDA en 2000 [Soley, 2000] avec comme objectif de promulguer de bonnes
pratiques de modélisation afin de déterminer comment, quand, quoi et pourquoi modéliser et
d’exploiter pleinement les avantages des modèles. Une dernière version de la spécification MDA a
été adoptée en 2003 [Miller et Mukerji, 2003] donnant une définition détaillée de l’architecture. La
figure 2.5 illustre la philisophie, les technologies standards ainsi que l’architecture de modélisation
de MDA. La figure de gauche illustre le LOGO de l’OMG concernant l’approche MDA. Celle-ci
repose sur un ensemble de standards à partir desquels les plateformes, les applications et les
services transversaux sont concues. La figure de droite illustre trois principaux standards de
MDA dans l’architecture à 4 niveaux.
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 20

Figure 2.5 – Principes, technologies et architecture MDA

MDA définit plusieurs fomalismes standards de modélisation, notament UML, MOF et XMI,
afin de promouvoir les qualités intrinsèques des modèles, telles que pérennité, productivité et prise
en compte des plateformes d’exécution. La section 2.3.2 présentera les principaux standards de
MDA et leur place dans le processus de modélisation et métamodélisation. Le principe clé de MDA
consiste en l’utilisation de modèles aux différentes phases de développement d’une application en
s’appuyant sur le standard UML. Plus précisément, MDA préconise l’élaboration des modèles :
– d’exigences (Computation Independant Model - CIM), dans lesquels aucune considération
informatique n’apparait,
– d’analyse et de conception (Platform Independant Model - PIM)
– de code (Platform Specific Model - PSM).
Dans la section 2.3.1 nous discuterons ces trois types de modèles et leur place dans le processus
de développement MDA. L’objectif majeur de MDA [Blanc, 2005], est l’élaboration de modèles
pérennes (PIM), indépendants des détails techniques des plateformes d’exécution (J2EE, .Net,
PHP, Oracle, ect.), afin de permettre la génération automatique de la totalité des modèles de
code (PSM) et d’obtenir un gain significatif de productivité. Cette génération automatique est
possible grâce à l’exécution des transformations de modèles. On comprend pourquoi le succés
de MDA et de l’IDM en général, repose en grande partie sur la résolution de problème de
transformation de modèle. Cette problématique a donnée lieu ces dernières années à de nombreux
travaux académiques [Jézéquel, 2004, Jouault, 2006], industriels [TOPCASED-WP5, 2008] et de
normalisation [OMG, 2002c]. Ainsi, afin de donner un cadre normatif pour l’implémentation
des différents langages dédiés à la transformation de modèles, l’OMG a défini le standard QVT
(Query/View/Transformation) [OMG, 2008]. La section 2.4 sera dédiée à la partie transformation
de modèles dans MDA.

2.3.1 Processus de développement dans MDA

Nous avons insisté sur la place centrale qu’occupe les modèles dans l’IDM et à fortiori dans
l’approche MDA. C’est cela qui la différencie principalement des approches classiques du génie
logiciel telles que OMT (Object Management Technique), OOSE (Object Oriented Software
Engineering) et UP (Unified Process), qui placent les objets ou les composants au premier plan.
Nous avons vu aussi que MDA préconisait l’élaboration de différents modèles, modèle d’exigences
CIM, modèle d’analyse et de conception abstraite PIM et modèle de code et de conception
concrète PSM. Ces modèles de base seront présentés plus en détail dans les sous sections suivantes.
Au dela de ces modèles de base, MDA préconise de modéliser n’importe quel artefact nécessaire au
cycle de développement des applications. Nous pouvons donc trouver des modèles d’éxigence, de
test, de sécurité, etc. Cependant, toute ces notions de modèles et de formalisme de modélisation
ne sont pas suffisantes pour mettre en œuvre MDA. Un processus de développement (appelé
aussi méthode de développement) est plus que nécessaire pour MDA. Une méthode définit une
démarche reproductible qui fournit des résultats fiables. Tous les domaines de la connaissance
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 21

Figure 2.6 – Processus de développement selon l’approche MDA

utilisent des méthodes plus ou moins sophistiquées et plus ou moins formalisées. Les cuisiniers
parlent de recettes de cuisine, les pilotes déroulent des check-lists avant le décollage, les architectes
dessinent des plans et les musiciens suivent des règles de composition. Une méthode d’élaboration
de logiciels selon l’approche MDA doit décrire comment construire des systèmes logiciels de
manière fiable et reproductible en utilisant les différents types de modèles. La figure 2.6 illustre
le processus de développement selon l’approche MDA. Cette figure en trois couloirs est une
extension d’une première ébauche présentée dans [Kleppe et al., 2003]. Le couloir de gauche
présente les activités du processus classique de développement de logiciel. Le couloir central
présente les différents modèles impliqués dans chaque activité et les liens entre les différents
modèles. Enfin, le couloir de droite présente les principaux formalismes préconisés à chaque
étape et pour chaque type de modèle. Comme il a été remarqué dans [Kleppe et al., 2003], les
phases de développement dans MDA sont simillaires au processus classique de développement
de logiciels. La principale différence réside dans la nature des artefacts qui sont crées durant
le processus de développement. Les artefacts dans le cadre de MDA sont des modèles formels
interprétables et manipulables par une machine.

2.3.1.1 Le modèle d’exigences CIM

Un modèle d’exigence doit représenter l’application dans son environnement afin de définir
quels sont les services offerts par l’application et quelles sont les autres entités avec lesquelles
il interagit. Le modèle d’exigence traduit les besoins du client et représente ainsi le point de
départ dans le cycle de développement. Les modèles d’exigences peuvent être considérés comme
des éléments contractuels, destinés à servir de référence lorsqu’on voudra s’assurer qu’une appli-
cation est conforme aux demandes du client. Il est important de noter qu’un modèle d’exigences
ne contient pas d’information sur la réalisation de l’application ni sur les traitements. C’est
pourquoi, dans le vocabulaire MDA, les modèles d’exigences sont appelés les CIM (Computa-
tion Independant Model), "modèle indépendant de la programmation". Avec UML, un modèle
d’exigence peut se résumer à un diagramme de cas d’utilisation. Ce dernier contient en effet les
fonctionnalités fournies par l’application (cas d’utilisation) ainsi que les différentes entités qui
interagissent avec elles (acteurs) sans apporter d’information sur le fonctionnement de l’applica-
tion. Un autre formalisme plus récent i* [Gordijn et al., 2006] a été proposé pour modéliser les
exigences pour les applications orientées services. En conclusion, le rôle des modèles d’exigences
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 22

dans une approche MDA est d’être les premiers modèles pérennes. Une fois les exigences modéli-
sées, elles sont censées fournir une base contractuelle avec le client. Grâce aux liens de tracabilité
avec les autres modèles qui suivront dans le cycle de développement, un lien peut être créé depuis
les exigences jusqu’au code final.

2.3.1.2 Le modèle PIM

Une fois le modèle d’exigences réalisé et validé par le client, le travail d’analyse et de concep-
tion peut démarrer. Dans l’approche MDA, cette phase utilise les modèles appelés PIM (Platform
Independant Model), désignés aussi par modèle d’analyse et de conception abstraite. En effet,
ces modèles spécifiants généralement la logique métier de l’entreprise, sont indépendants de toute
plate-forme technique et ne doivent pas contenir d’informations sur les technologies qui seront
utilisées pour déployer l’application. En intégrant les détails d’implémentations que très tard
dans le cycle de développement, il est possible de maximiser la séparation des préoccupations
entre la logique métier des applications et les techniques d’implémentation. Aujourdhui, UML s’es
imposé comme la référence pour réaliser les modèles d’analyse et de conception. Il est important
de noter que MDA ne fait que préconiser l’utilisation d’UML et qu’il n’exclut pas que d’autres
langages puissent être utilisés. En effet, l’IDM, au contraire, favorise la définition de langages de
modélisation dédiés à un domaine particulier [Jouault et Bézivin, 2006] (Domain Specific Lan-
guages – DSL) offrant ainsi aux utilisateurs des concepts propres à leur métier et dont ils ont la
maîtrise. Ces langages sont généralement de petite taille et doivent être facilement manipulables,
transformables, combinables, etc. Dans ce contexte, l’OMG a proposé des langages standards
dédiés à des domaines d’applications, tel que EDOC (Enterprise Distributed Object Computing)
pour les systèmes distribués à base de composants, CWM pour les bases données, etc. Quels que
soient les langages utilisés, le rôle des modèles d’analyse et de conception est de pérenniser la
logique métier de l’entreprise et de faire le lien entre les modèles d’exigences et le code final de
l’application. Les modèles PIM doivent être productifs, c’est à dire qu’ils doivent être suffisam-
ment précis et contenir suffisamment d’information pour qu’une génération automatique de code
soit envisageable ultérieurement.

2.3.1.3 Le modèle PSM

Cette phase, la plus délicate dans MDA, concerne la génération de code. Le modèle PSM
(Platform Specific Model), appelé aussi le modèle de code ou de conception concrète, est alors
mis en jeux. MDA considère que le code final d’application peut être facilement obtenu à partir
du PSM. En effet, le code d’une application se résume à une suite de lignes textuelles, comme
un fichier SQL, alors qu’un modèle de code est plutôt une représentation structurée incluant,
par exemple, les concepts de table, clé primaire, clé étrangère, etc. L’écriture de code à partir du
modèle de code est donc une opération assez triviale. La principale différence entre un modèle
de code PSM est un modèle d’analyse et de conception PIM réside dans le fait que le modèle de
code est lié à une plate-forme d’exécution. Ainsi, une caractéristique importante des modèles de
code est qu’ils intègrent les concepts des plate-formes d’exécution. Pour élaborer des modèles de
code, MDA propose, entre autres, l’utilisation des profils UML (voir section 2.3.2.2). Un profil
UML est une adaptation du langage UML à un domaine particulier.

2.3.1.4 Du modèle CIM au modèle PSM

La mise en production de MDA passe par la mise en relation des trois principaux modèles
CIM, PIM et PSM. Cette mise en relation se fait par les techniques de transformations qui
sont omniprésentes et occupent une place centrale dans MDA. Ces techniques permettent de
transformer un modèle CIM en un modèle PIM et d’obtenir un modèle PSM à partir d’un
modèle PIM. La section 2.4 présentera les techniques de transformations dans l’espace MDA. A
partir de la figure 2.6 illustrant le processus de développement dans MDA, nous pouvons lister
les principales transformations de modèles suivantes conformément à MDA :
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 23

– Transformation de modèles CIM vers PIM. Permettent d’élaborer des PIM partiels
à partir des informations contenues dans les CIM. L’objectif est de s’assurer que les besoins
exprimés dans les CIM sont bien représentés dans les PIM. Ces transformations sont es-
sentielles à la pérennité des modèles. Ce sont elles qui guarantissent les liens de traçabilité
entre les modèles et les besoins exprimés par le client.
– Transformations de modèles PIM vers PIM. Permettent de raffiner les PIM afin
d’améliorer la précision des informations qu’ils contiennent. En UML, de telles transforma-
tions, peuvent être, par exemple, l’enrichissement de classes UML à partir des diagrammes
de séquences et des diagrammes d’états transitions. Ces transformations sont omniprésentes
dans les outils d’élaboration de modèles PIM. Elles permettent d’accélerer la production
des PIM et donc de raccourcir le cycle de développement.
– Transformations de modèles PIM vers PSM. Permettent d’élaborer une bonne partie
des modèles PSM à partir des modèles PIM. Ces transformations sont les plus importantes
de MDA car elles guarantissent la pérennité des modèles aussi bien que leur productivité
et leur lien avec les plates-formes d’exécution. Nous illustrons ces transformations dans la
section 5 dédiée à notre approche de la transformation, séparant explicitement la partie
spécification des correspondances de la partie génération des règles de transformations.
– Transformations de modèles PSM vers code. Permettent de générer la totalité du
code. Ces transformations consistent en une traduction entre un formalisme structuré tel
que un diagramme UML et un formalisme textuel représentant le code final.

2.3.2 Modélisation et métamodélisation dans MDA

Pour mettre en œuvre son objectif principal qui est la pérennité par les modèles, MDA définit
une architecture à 4 niveaux (cf. section 2.2), qui établit les concepts de base de l’ingénièrie par
les modèles et positionne chacun des standards qui font MDA, tel que MOF, UML, OCL, XMI.
Cette section présente ces langages standards qui forment le socle de base pour la modélisation
et la métamodélisation dans MDA. Nous préciserons la place de certain de ces langages dans nos
travaux de recherche. Nous commencons par une brève présentation de chacun de ces standards
et leur place dans MDA.
Le succès industriel du langage UML est unanimement reconnu, puisque c’est désormais le
langage de spécification d’applications orientées objet le plus utilisé au monde. Le consensus sur
ce langage fut décisif dans cette transition vers l’IDM et les techniques de production basées sur
les modèles. Après l’acceptation du concept clé de métamodèle comme langage de description de
modèle, de nombreux métamodèles ont émergés afin d’apporter, chacun, leurs spécificités dans
un domaine particulier (développement logiciel, entrepôt de données, procédé de développement,
etc.). Devant le danger de voir reproduire l’époque des intergiciels [Bézivin, 2004b] et ainsi voir
émerger indépendamment et de manière incompatible une grande variété de métamodèles, il y
avait un besoin urgent de donner un cadre général pour leur description. La réponse logique fut
donc d’offrir un langage de définition de métamodèles qui prit lui-même la forme d’un modèle : ce
fut le métamétamodèle MOF (Meta-Object Facility) [OMG, 2006a]. Une des lacunes du langage
UML est son incapacité à exprimer une sémantique opérationnelle. Il n’est pas évident pour UML
d’exprimer par exemple précisément ce que fait une opération. Dans le métamodèle UML, une
opération n’est définie que par son nom, ses paramètres et les exceptions qu’elle émet. Le corps
de l’opération ne peut donc être défini. Le langage OCL (Object Constraint Language) a été
précisément défini par l’OMG pour combler cette lacune et permettre la modélisation du corps
des opérations UML. OCL permet d’exprimer des contraintes sur tous les éléments des modèles
UML. Le standard XMI permet de représenter les modèles sous forme de documents XML et
favorise ainsi leur échange et donc leur pérennité. Le principe de fonctionnement de XMI consiste
à générer automatiquement une spécification de structuration de balises XML (DTD ou XML
schema) à partir d’un métamodèle. Il est ainsi possible de bénéficier du mécanisme de validation
des documents XML. Pour permettre l’adaptation d’UML à d’autres domaines et pour préciser la
signification de cette adaptation, l’OMG a standardisée le concept de profil UML. Un profil est un
ensemble de techniques et de mécanismes permettant d’adapter UML à un domaine particulier.
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 24

Cette adaptation peut se faire sur n’importe quel modèle UML et elle ne modifie en rien le
métamodèle UML. Enfin, l’OMG ne pouvait ignorer le franc succés de l’ingénièrie des ontologies
dans les domaines tel que le Web et le semantic Web. Ainsi, l’OMG a proposé le métamodèle
ODM (Ontology Definition Metamodel) qui a pour objectif de permettre la modélisation d’une
ontologie conformément au formalisme MOF. La modélisation d’ontologies en MOF permet un
héritage de tout l’outillage de ce dernier. En effet une fois qu’un langage de modélisation du Web
Sémantique comme OWL est modélisé en MOF, ses utilisateurs peuvent utiliser les capacités de
MOF pour la création, la gestion de modèles, la génération de code et l’interopérabilité avec des
modèles MOF.
Les sous sections suivantes seront dédiées à une présentation de ces différents standards de
l’OMG et de l’approche MDA. Nous évoquerons la place de chacun de ces standards dans nos
travaux de recherche.

2.3.2.1 Les langages de métamodélisation

Nous avons vu que l’architecture à 4 niveaux de MDA permettait de faire la différence entre
les entités à modéliser (niveau M0), les modèles (niveau M1), les métamodèles (niveau M2) et les
métamétamodèles (niveau M3). Les langages de métamodélisation se situent au niveau M3, et
permettent de spécifier des métamodèles au niveau M2. Dans l’approche MDA, le langage MOF
incarne le socle architectural. Dans l’environnement Eclipse, le langage Ecore joue le même rôle
que MOF, il permet la spécification de métamodèles.

- Le langage MOF Tous les métamodèles public de l’OMG sont réalisés avec la version 1.4
de MOF, qui est assez simple d’utilisation, contrairement à la version 1.3, qui nécessitte une
connaissance de CORBA, ou de la version actuelle 2.0, très complexe. Nos travaux de recherche
ont aussi utilisé cette version 1.4, c’est la raison pour laquelle nous la présentons ci-après. Nous
évoquerons l’état actuel de la version 2.0 en fin de cette section, car c’est elle qui permettra
d’élaborer les futurs métamodèles. Les métamodèles MOF1.4 sont définis sous forme de classes.
Les modèles conformes aux métamodèles sont considérés comme des instances de ces classes.
La figure 2.7 présente une partie de ce que pourrait être un diagramme de classe représentant
MOF1.4.

Figure 2.7 – Représentation de MOF1.4 sous forme de diagramme de classes.

CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 25

Les principaux concepts de MOF1.4 illustrés par la figure 2.7 sont les suivants :
– Class. Une classe (désignée par métaclasse dans MOF) permet de définir la structure de
ses instances (désignées par méta-objets). Un ensemble de méta-objets constitue un modèle.
Une métaclasse a un nom et contient des attributs et des opérations, aussi appelés méta-
attributs et méta-opérations. Les désignations en "méta" permettent de discerner les entités
du niveau M2 de celles du niveau M1.
– DataType. Un type de donnée permet de spécifier le type non-objet d’un méta-attribut
ou d’un paramètre d’une méta-opération.
– Association. Pour exprimer des relations entre métaclasses, MOF1.4 propose le concept
de méta-association qui est une association binaire entre deux métaclasses. Une méta-
association porte un nom, et chacune de ses extrémités peut porter un nom de rôle et une
multiplicité.
– Package. Pour grouper entre eux les différents éléments d’un métamodèle, MOF1.4 propose
le concept de Package. Un Package, aussi appelé métapackage, est un espace de nommage
servant à identifier par des noms les différents éléments qui le constituent.
La version MOF 2.0 est la version courante de MOF. Conceptuellement, l’architecture MOF2.0 ne
diffère que très peu de celle de MOF1.4. MOF2.0 est toujours l’unique métamétamodèle, et UML
2.0 est le métamodèle dédié à la modélisation d’applications orientées objets. Techniquement,
en revanche, cette version est assez déroutante [Blanc, 2005]. L’un des objectifs de MOF2.0 est
de capitaliser les points communs existants entre UML et MOF au niveau des diagrammes de
classes et d’en expliciter les différences. Pour realiser cet objectif, les moyens mis en œuvre ne
facilitent pas la compréhension de cette version.

- Le langage Ecore Le langage de métamodélisation Ecore a été présenté par la fondation

Eclipse dans le cadre du projet EMF (Eclipse Modeling Framework). EMF propose un framework
pour le développement des applications basées sur l’ingénierie dirigée par les modèles. Ce frame-
work permet de générer automatiquement des interfaces Java à partir de métamodèles Ecore. La
figure 2.8 présente une partie du métamétamodèle Ecore.
La particularité des métamodèles Ecore est qu’ils ne contiennent pas de méta-associations
entre leurs méta-classes. Pour exprimer une relation entre deux métaclasses, il faut utiliser des
méta-attributs et les typer par des métaclasses. EMF impose cette contrainte pour faciliter la
génération des interfaces Java. Le concept d’association n’existant pas en Java, il faudrait en effet
une transcription particulière. Ainsi, les métamodèles conformes à Ecore sont composés d’EClass
contenant des EAttribute et des EReference.

Figure 2.8 – Un fragment du métamodèle Ecore

CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 26

Figure 2.9 – Un fragment du métamodèle du langage UML

2.3.2.2 Les langages de modélisation

Les langages de modélisation ou métamodèles sont situés au niveau M2 de l’architecture MDA
et permettent de spécifier des modèles. L’environnement MDA est partitionné par un ensemble
de métamodèles. Chacun de ces métamodèles est dédié soit à une étape particulière de MDA
(exigences, analyse et conception), soit à un domaine d’application particulier (bases de données,
composants logiciels, systèmes embarqués). MDA n’impose aucune contrainte quant à l’utilisation
de tel ou tel métamodèle, mais préconise de facon générale l’utilisation du métamodèle UML pour
l’étape d’analyse et de conception abstraite et suggère de recourir au profils UML pour élaborer
des modèles de code et de conception concrète à partir de modèles UML. En plus d’UML et ses
profils, nous présentons succintement le langage de modélisation EDOC (Enterprise Distributed
Object Computing). EDOC est un standard de l’OMG pour la spécification des applications
distribuées à base de composants. Dans le chapitre 3 dédié à l’approche MDA pour la plateforme
services Web, nous utiliserons EDOC pour la modélisation métier (PIM) des applications Web.

- Le métamodèle UML et les profils UML

La première version de UML a été publiée en 1997 par l’OMG. Depuis, UML est devenu la
référence pour la création de modèles et le métamodèle d’UML est le plus connu de l’approche
MDA. Nos n’allons pas détailler ici le métamodèle d’UML, il existe aujourdhui une multitude
de documents pour cela. Une decription générale du métamodèle d’UML est présentée dans les
travaux de thèses que nous avons co-encadrées [Lopes, 2005, Vale, 2009]. Une description plus
détaillée est présentée dans [Blanc, 2005, OMG, 2007]. Nous nous contenterons ainsi de préciser le
rôle du métamodèle d’UML dans MDA et sa place dans nos travaux de recherche. Le métamodèle
UML définit la structure que doit avoir tout modèle UML. Il précise, par exemple, qu’une classe
UML peut avoir des attributs et des opérations. La figure 2.9 montre un fragment du métamodèle
UML et précise au niveau métamodèle par exemple qu’une association UML est composée de
deux extrémités, chacune representant une classe.
D’un point de vue plus conceptuel, le métamodèle UML permet de concevoir des modèles
décrivant des applications objet selon différentes vues. Par exemple, les diagrammes de classes
permettent de décrire la partie statique des applications alors que les diagrammes de séquences
ou d’états transitions permettent d’en définir la partie dynamique. Comme évoqué précédem-
ment, les modèles UML sont indépendants des plates-formes d’exécutions. Ils sont utilisés pour
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 27

Figure 2.10 – Exemple de profil UML pour modéliser un sémaphore.

décrire aussi bien les applications Java, Bases de données ou C#. Plusieurs outils proposent des
générateurs de code vers différents langages de programmation. Ainsi, il est évident que le mé-
tamodèle UML représente le métamodèle idéal pour la conception des modèles PIM (Platform
Independant Model). Nous avons utilisé UML pour la spécification des applications internet et
leur mise en œuvre sur les plateformes Services Web (chapitre 3). Nous discuterons dans ce cha-
pitre les limites du langage UML pour la spécification d’applications et leur mise en œuvre sur
des plateformes nécessitant une sémantique particulière.
Ainsi, UML est un langage général, et a donc été conçu pour prendre en charge une grande va-
riété d’applications et de contexte de mise en œuvre. Cependant, même avec cette intention d’être
général, UML ne peut pas couvrir tous les contextes et offre ainsi un mécanisme d’extensibilité
basé sur les profils, qui est une caractéristique fondamentale. Un profil permet la personnalisa-
tion d’UML pour prendre en charge des domaines spécifiques qui ne peuvent pas être représentés
avec UML dans son état original. Le profil est constitué de trois concepts : les stéréotypes, les
contraintes et les valeurs marquées. Un stéréotype c’est le concept central des profils, qui définit
une sous-classe d’un ou plusieurs éléments du métamodèle UML. Cette sousclasse a la même
structure que ses éléments de base, mais le stéréotype peut spécifier des contraintes et des pro-
priétés supplémentaires. Concretement, un stéreotype est une sorte d’étiquette nommée que l’on
peut coller sur n’importe quel élément d’un modèle UML. Lorsque un stéréotype est collé sur
un élément d’un modèle, le nom du stéréotype définit la nouvelle signification de l’élément. La
figure 2.10 inspirée de [Blay-Fornarino, 2008] illustre un profil UML pour rajouter le concept de
semaphore dans UML.
Les profils UML dédiés à des plateformes d’exécutions permettent, par définition, d’adapter
UML à ces plateformes. Le point intéressant à souligner dans un contexte MDA est que les mo-
dèles réalisés selon ces profils ne sont plus des modèles indépendants des plateformes d’exécutions
mais, au contraire, des modèles dépendants de ces plateformes. Ces modèles ne sont donc plus des
PIM mais des PSM (Platform Specific Model). Il est tout naturel que MDA préconise l’utilisation
des profils UML pour l’élaboration de PSM car cela à le mérite de faciliter les transformations
PIM vers PSM puisque PIM et PSM sont tous deux des modèles UML. Il est enfin important de
noter que l’OMG a standartisé certains profils tel que : CORBA, EJB et EDOC.

- Le métamodèle EDOC
EDOC (Enterprise Distributed Object Computing) est une spécification pour le développe-
ment des applications distribuées d’entreprise basées sur les composants [OMG, 2004]. La version
1.4 d’UML que nous avons utilisé lors de nos expérimentations de MDA sur la plateforme service
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 28

Figure 2.11 – Un fragment du métamodèle d’ EDOC_CCA

web, n’intègre pas la notion de composant. Aujourdhui, le paradigme composant est pleinement
intégré dans la spécification UML2.0. Ainsi, nous avons eu recours à EDOC afin d’utiliser et
comparer deux standards (UML et EDOC) pour la mise en œuvre des applications Web sur les
plateformes sevice Web. EDOC, se situant dans la mouvance des DSL (Domain Specific Lan-
guage), s’est averé plus proche de la plateforme service web que le langage UML. Le chapitre 3
reviendra plus en détail sur cette partie. La spécification EDOC est indépendante d’une plate-
forme technologique, ce qui permet de réaliser son implémentation sur différents intergiciels,
comme par exemple les services Web, CORBA, EJB ou DCOM/COM. EDOC est composée de
sept spécifications [OMG, 2004]. Parmi ces specifications, l’architecture ECA (Enterprise Colla-
boration Architecture) occupe la place centrale. Celle-ci fournit quatre métamodèles et profils :
– CCA (Component Collaboration Architecture) : utilise des classes ainsi que des graphes
d’activité et de collaboration pour modéliser la structure et le comportement des compo-
sants.
– Entities model : utilise un ensemble d’extensions UML pour modéliser les entités d’un
système.
– Events Model : est un ensemble d’extensions UML pour modéliser les événements d’un
système.
– Business Process Model : compléments de CCA et du modèle de comportement du système.
Il permet de définir des processus métiers à différents niveaux de détails, en utilisant un
diagramme de tâche.
Nous nous intéressons particulièrement à la partie CCA de la spécification EDOC et de L’ECA.
En effet, cette partie de la spécification présente un métamodèle de composition générale qui
résume l’état de l’art sur les composants, la récursivité dans la composition, la spécification de
ports de communication entre composants et la notion de protocole pour représenter les dialogues
simples ou complexes entre composants. La figure 2.11 présente un fragment du métamodèle de
EDOC_CCA.
Parmi les éléments de ce fragment du métamodèle EDOC-CCA, nous distinguons :
– ProcessComponent : représente le contrat pour un composant qui réalise des actions. Un
ProcessComponent peut définir un ensemble de Ports pour l’interaction avec d’autres Pro-
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 29

cessComponent. Le ProcessComponent définit le contrat externe du composant en termes

de ports et de chorégraphie d’activités de ports (qui envoient ou reçoivent des messages ou
initialisent des sous-protocoles).
– PortOwner : contient l’ensemble des Ports qui réalisent le contrat du ProcessComponent.
– Port : définit un point d’interaction entre les ProcessComponents. La forme la plus simple
d’un port est le FlowPort, qui peut produire ou consommer un type de données simples.
Les interactions plus complexes entre les composants utilisent un ProtocolPort, lequel fait
référence à un Protocol, i.e. à une conversation complète entre composants.
– PropertyDefinition : définit un paramètre de configuration de composants qui peut être un
ensemble.
D’autres éléments tel que InitiatingRole, RespondingRole et Interface, permettent d’enrichir la
sémantique des protocoles et des ports de communications.

2.3.3 OCL, Action Semantics et XMI

Comme nous l’avons évoqué précédemment, dans UML, il n’était pas possible d’exprimer
précisément ce que fait une opération, c’est-à-dire son corps. Le langage OCL [Warmer, 2002],
Object Constraint Language, a été défini par l’OMG pour combler cette lacune et permettre la
modélisation du corps des opérations dans un modèle UML. OCL peut exprimer des contraintes
sur tous les éléments d’un modèle UML. Il est utilisé pour exprimer des pré et post-conditions
sur les opérations. Par exemple, il est possible de dire, en utilisant OCL, que l’opération accep-
terUneLocationDeVoiture a comme pré-condition verifierClientMajeur, ce qui veut dire qu’avant
de faire appel à l’opération qui accepte la location d’une voiture il faut d’abord vérifier que
le client est majeur. Les expressions OCL ne génèrent aucun effet de bord. L’évaluation d’une
expression OCL n’entraîne aucun changement d’état dans le modèle auquel elle est rattachée.
Une contrainte OCL est une expression dont l’évaluation doit retourner vrai ou faux. L’évalua-
tion d’une contrainte OCL permet de la sorte de savoir si la contrainte est respectée ou non.
OCL dispose d’un formalisme textuel, on parle d’expression OCL. Une expression OCL porte
sur un élément du modèle UML. Pour être évaluée, une expression OCL doit être rattachée à un
contexte, qui doit être directement relié à un modèle UML. L’exemple suivant permet de spéci-
fier, pour un compte bancaire, que la valeur du solde doit être positive avant toute invocation de
l’opération debit :
context CompteBancaire : :debit() :Integer
pre : solde > 0
Le métamodèle OCL permet de représenter n’importe quelle expression OCL sous forme de
modèle. Cette représentation permet de rendre les expressions OCL pérennes et productives. De
plus, le lien fort qui unit les modèles UML et les expressions OCL représentées sous forme de
modèles, permet d’exploiter pleinement les modèles UML au niveau PIM dans MDA. Pour des
raisons évidentes de simplicité d’utilisation, OCL reste avant tout un langage textuel.
Jusqu’à sa version 1.4, UML était très critiqué parce qu’il ne permettait pas de spécifier des
créations, des suppressions ou des modications d’éléments de modèles. Ces actions ne pouvant
pas non plus être spécifiées à l’aide du langage OCL, puisque celui-ci est sans effet de bord, il
était nécessaire de standardiser un nouveau langage. C’est ce qui a donné naissance au langage
AS (Action Semantics) [Blanc, 2005]. L’objectif de Action Semantics est de permettre de définir
des actions. Une action au sens AS est une opération sur un modèle qui fait changer l’état
du modèle. Grâce à ces actions, il est possible de modifier les valeurs des attributs, de créer
ou de supprimer des objets, de créer de nouveaux liens entre les objets, etc. Ainsi le concept
d’Action Semantics permet de spécifier pleinement le corps des opérations UML. Au départ AS
était un langage développé à part entière hors de UML puis inclus dans la version 1.5. Dans
UML 2.0, il est enfin totalement intégré au métamodèle. AS n’est standardisé que sous forme de
métamodèle, et aucune syntaxe concrète n’est définie, contrairement à OCL. Ainsi, le manque
de format concret (textuel), rend l’utilisation de AS complexe. C’est la raison pour laquelle AS
n’est pas encore pleinement exploité, contrairement à OCL. Dans nos travaux de recherche sur
les techniques de transformations dans MDA (voir section 2.4), OCL est utilisé pour l’expression
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 30

des correspondances entre éléments de deux métamodèles.

Les modèles étant des entités abstraites, ils ne disposent pas intrinsèquement de représen-
tation informatique. L’OMG à donc décidé de standardiser XMI (XML Metadata Interchange),
qui permet l’échange de modèles sérialisés en XML. XMI se focalise sur les échanges de méta-
données conformes au MOF. L’objectif de XMI est de permettre de sérialiser et d’échanger des
métamodèles MOF et des modèles basés sur ces métamodèles sous forme de fichiers en utilisant
des dialectes XML. Il permet aussi de sérialiser des métamodèles qui sont créés avec Ecore. Ceci
est possible car XMI ne définit pas un dialecte XML unique, mais un ensemble de règles qui per-
mettent de créer une DTD ou schéma XML pour différents métamodèles. Ainsi, les métamodèles
conformes à MOF ou à Ecore et leurs modèles respectifs peuvent être portables en utilisant XMI.
Toutes nos experimentations autour de la plateforme Eclipse ont utilisées ce format d’échange
pour le traitement des métamodèles.

2.3.4 Le pont vers les ontologies :ODM.

L’OMG ne pouvait pas ignorer le franc succés des ontologies dans différents domaines tel que
le Web sémantique, l’intéropérabilité des systèmes d’informations et le traitement des langages
naturelles. Une ontologie définit les termes et concepts (sens) utilisés pour décrire et représen-
ter une connaissance. Une ontologie peut aller de la taxonomie (connaissance avec un minimum
d’hiérarchie ou structure Parent/Enfant) au thésaurus ou lexique (mots et synonymes) ou mo-
dèles conceptuels (avec une connaissance plus complexe), à la théorie de la logique (avec une
connaissance très riche, complexe, consistante et sensée). Une ontologie doit être exprimée dans
une syntaxe bien définie permettant une automatisation du traitement par les machines. L’onto-
logy Definition Metamodel (ODM) [OMG, 2006b] a pour objectif de permettre la modélisation
d’ontologies en utilisant le formalisme MOF. ODM est une spécification de l’OMG dont la ver-
sion 1.0 datée de mai 2009. L’ingénierie d’ontologies a atteint un certain degré de maturité dans
certains domaines tel que le Web et le Web sémantique. Cependant, les ontologies sont souvent
capturées dans des langages de représentation de la connaissance (KR : Knowledge Representa-
tion) qui proviennent des théories de l’intelligence artificielle. Ces langages sont pour la plupart
structurés suivant des formalismes de logique tels que la logique de prédicats. Cette structure a
rendu la syntaxe de ces langages inhabituelle et peu commode à ceux qui ont l’habitude d’utili-
ser d’autres langages de modélisation, souvent graphiques ; ceci explique le manque d’utilisation
large de ces langages et donc le développement d’ontologies, retardant ainsi l’adoption des tech-
nologies du Web Sémantique. La familiarité des utilisateurs avec UML, la disponibilité des outils
UML, l’existence de plusieurs modèles de domaines et la similarité de ces modèles aux ontologies,
suggèrent qu’UML puisse être utilisé pour faire des développements d’ontologies. Ceci permettra
aussi de créer un lien entre la communauté UML et celle du Web Sémantique. De plus, UML
dispose de beaucoup d’outils permettant la gestion de modèles. Le MDA et son architecture à
quatre couches fournit une base solide pour définir le métamodèle de n’importe quel langage de
modélisation. Il offre donc une fondation pour rapprocher l’ingénierie de logiciels et des métho-
dologies comme UML aux technologies du Web Semantique basées sur RDF et OWL. Ainsi, une
fois qu’un langage de modélisation du Web Sémantique comme OWL est modélisé en MOF, ses
utilisateurs peuvent adopter les capacités de MOF pour la création, la gestion de modèles, la
génération de code et l’interopérabilité avec des modèles MOF. ODM définit cinq métamodèles
(RDFS, OWL, Topic Maps, Common Logic et Description Logic), deux profiles UML (le profile
RDFS/OWL, le profile Topic Maps) et un ensemble de correspondances QVT, de UML à OWL,
Topic Maps à OWL et RDFS/OWL à Common Logic. La figure 2.12 illustre le métamodèle
ODM est les liens entre le monde UML et celui des ontologies.
Dans le cadre de l’informatique ubiquitaire, et particulierement les applications sensibles aux
contextes, les formalismes issues des ontologies sont largement reconnues comme étant les plus
adaptés à la représentation des informations du contexte [Euzenat et al., 2008]. Dans le chapitre
4 dédié à l’application de l’approche MDA pour les applications sensibles au contexte, nous
discuterons de ce point.
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 31

Figure 2.12 – Principe de ODM

2.4 La transformation de modèles dans MDA

La transformation de modèles est la troisième problématique clé de MDA et de l’IDM en gé-
néral. Elle permet de rendre les modèles productifs et d’obtenir une tracabilité entre des modèles
très abstraits, proches des besoins exprimés par les utilisateurs, et des modèles très concrets,
proches des plate-formes d’exécutions. Nous avons vu en section 2.3.1 lors de la présentation du
processus de développement dans MDA les différents types de transformations. Quel que soit son
type (PIM vers PSM, PIM vers PIM, etc.), une transformation de modèles s’apparente toujours
à une fonction qui prend en entrée un ensemble de modèles et qui fournit en sortie un ensemble
de modèles. Nous avons vu en section 2.2.4 que si une transformation de modèles s’exécute au
niveau des modèles, elle se spécifie au niveau métamodèles. Les métamodèles permettent dans le
processus de transformation MDA de définir les structurations possibles des modèles source et
cible et de servir de base pour la définition des règles de transformation.

2.4.1 Les différentes approches de transformations de modèles

Trois principales approches ont été développées pour la mise en œuvre des transformations
de modèles. La différence entre ces trois approches est liée à la manière dont les règles de trans-
formations sont spécifiées [Blanc, 2005].
– Approche par programmation. Comme son son l’indique, un langage de programma-
tion est mis en œuvre pour programmer une transformation de modèle de la même manière
que l’on développe n’importe quelle application. Le langage de programmation est de type
orienté objet afin de préserver l’uniformité conceptuelle avec les modèles UML et les ou-
tils MDA. Les transformations selon cette approche sont donc des applications qui ont la
spécificité de manipuler des modèles. Ces applications utilisent des interfaces de gestion de
modèles offrant les opérations nécessaires pour la manipulation des modèles. Les standards
et framework MOF, JMI et EMF disposent de ces interfaces. Cette approche est très utili-
sée car elle bénéficie de la richesse des langages de programmation et des environnements
de développement fortement outillés.
– Approche par template. L’approche par template consiste à définir des canevas pour
les modèles cibles souhaités. Ces canevas sont des modèles cibles paramétrés ou modèles
templates. L’exécution d’une transformation consiste à prendre un modèle template et à
remplacer ses paramètres par les valeurs d’un modèle source. Cette approche par template
est implémentée par exemple dans Softeam MDA Modeler.
– L’approche par modélisation. Cette approche consiste, quant-à-elle, à appliquer les
concepts de l’ingénierie des modèles aux transformations des modèles elles-mêmes. L’ob-
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 32

jectif est de modéliser les transformations de modèles et de rendre les modèles de transfor-
mation pérennes et productifs, en exprimant leur indépendance vis-à-vis des platesformes
d’exécution. Le standard MOF 2.0 QVT de l’OMG a été élaboré dans ce cadre et a pour
but de définir un métamodèle permettant l’élaboration des modèles de transformation de
modèles. Le langage de transformation de modèles ATL[Jouault, 2006] que nous avons uti-
lisé dans nos travaux de recherche est aussi dans cette mouvance. QVT ainsi que ATL
seront présentés dans la section 2.4.3.
L’approche par modélisation, même si elle est la plus complexe à mettre en œuvre, reste la plus
prometteuse, car elle offre une solution favorisant la pérennité des transformations et facilite donc
leur réutilisation. C’est dans cette approche que, se situent les techniques de transformations
développées dans nos recherches, ainsi que nos premières contributions (Voir section 2.5) liées au
processus de transformation dans MDA. La section qui suit présente plus en détail cette approche
de la transformation par modélisation.

2.4.2 L’approche de transformation par modélisation

Plusieurs définitions ont été proposées pour préciser la transformations de modèles. La défi-
nition suivante, largement consensuelle, est proposée dans [Kleppe et al., 2003] :
“A Transformation is the automatic generation of a target model from a source model, accor-
ding to a transformation definition. A transformation definition is a set of transformation rules
that together describe how a model in the source language can be transformed into a model in
the target language. A transformation rule is a description of how one or more constructs in the
source language can be transformed into one or more constructs in the target language”.
Cette définition exibe les principaux concepts impliqués dans la transformation de modèles,
et supportés par les langages de transformations, à savoir :
– modèle (ou métamodèle) source et modèle (ou métamodèle) cible
– la définition (formelle) d’une transformation composée d’un ensemble de règles.
– règles de transformations.
La figure 2.13 que nous désignons par "Architecture du processus de transformation dans MDA"
présente le scénario le plus courant pour la transformation de modèles et qui est compatible avec
la norme MOF2.0/QVT (OMG, 2005). Ce scénario s’insère complètement dans l’architecture à
4 niveaux de MDA et chaque élément présenté dans la figure 2.14 joue un rôle important dans
la processus de transformation. Dans cette approche de transformation par modélisation, MOF
est le seul métamétamodèle utilisé pour créer des métamodèles. Les règles de transformations
spécifient comment générer un modèle cible PSM à partir d’un modèle source PIM. Ces règles
de transformations sont définies au niveau M2 de l’architecture MDA entre métamodèles, et
exécutées au niveau M1 entre modèles.

Figure 2.13 – L’architecture du processus de transformation de modèle dans MDA

CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 33

Les règles de transformations sont basées sur les langages de transformations, tels que le
standard QVT. Le moteur de transformation prend en entrée le modèle source, exécute les
règles de transformation, et produit en sortie le modèle cible. Formellement, soit ma(s)/Ma et
mb(s)/Mb, où ma est un modèle d’un système s créé à l’aide du métamodèle Ma, et mb est
un modèle du même système s créé à l’aide du métamodèle Mb, une transformation peut par
conséquent être définie comme suit : ma(s)/Ma →mb(s)/Mb. Lorsque Ma et Mb sont conformes
au même métamétamodèle (MOF), la transformation peut être exprimée dans un langage de
transformation conforme à MOF tel que ATL ou QVT.

2.4.3 Langages et standard pour la transformation de modèles

De nombreux langages sont à ce jour disponibles pour écrire des transformations de modèle
selon l’approche par modélisation. Cette approche (conformément à la figure 2.13) repose alors
sur la définition d’un métamodèle dédié à la transformation de modèle et des outils permettant
la spécification et l’exécution des modèles de transformation. Tous les langages développés selon
cette approche proposent un métamodèle de transformation conforme à MOF (ou largement com-
patible à MOF, type Ecore de l’environnement EMF d’Eclipse) et utilise OCL pour la navigation
dans les modèles. La première thèse que nous avons co-encadré s’est faite dans l’équipe ATLAS
de Nantes qui à lancée dés le début des années 2000 la conception du langage de transformation
ATL. Toutes nos mises en œuvre concernant la partie transformation de modèles ont été réalisées
avec le langage ATL.
Afin de donner un cadre normatif pour l’implantation des différents langages dédiés à la
transformation de modèle, l’OMG a défini le standard QVT (Query/View/Transformation)
[OMG, 2005]. ATL et QVT représentent certainement les deux langages qui, durant cette der-
nière décénnie, ont bien marqué l’état de la recherche et du développement autour des langages
de transformations issus de cette mouvance de la transformation de modèles par modélisation.

2.4.3.1 Le langage ATL

ATL est l’acronyme d’ATLAS Transformation Language ; c’est un langage hybride (déclaratif
et impératif) et permet de faire des transformations de modèles aussi bien endogènes (même
espace technologique) qu’exogènes (espace technologique différent). ATL est défini par un modèle
MOF pour sa syntaxe abstraite et possède une syntaxe concrète textuelle. Pour accéder aux
éléments d’un modèle, ATL utilise des requêtes sous forme d’expressions OCL. Une requête
permet de naviguer entre les éléments d’un modèle et d’appeler des opérations sur ceux-ci.
Une règle déclarative d’ATL, appelée Matched Rule, est spécifiée par un nom, un ensemble de
patrons sources (InPattern) mappés avec les éléments sources, et un ensemble de patrons cibles
(OutPattern) représentant les éléments créés dans le modèle cible. Depuis la version proposée en
2006 d’ATL, de nouvelles fonctionnalités ont été ajoutées telles que l’héritage entre les règles et le
multiple pattern matching (plusieurs modèles en entrée). Le style impératif d’ATL est supporté
par deux constructions différentes. En effet, on peut utiliser soit des règles impératives appelées
Called Rule, soit un bloc d’instructions impératives (ActionBlock ) utilisé avec les deux types
de règles. Une Called Rule est appelée explicitement en utilisant son nom et en initialisant ses
paramètres. La figure 2.14 ci-dessous présente la syntaxe abstraite d’une règle de transformation
ATL.
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 34

Figure 2.14 – Syntaxe abstraite d’une règle de transformation ATL

Les outils de transformation liés à ATL sont intégrés sous forme de plug-in ADT (ATL De-
velopment Tool) pour l’environnement de développement Eclipse. Un modèle de transformation
ATL se base sur des définitions de métamodèles au format XMI. L’environnement ADT dispose
du langage KM3 (Kernel MetaMetaModel) qui est une forme textuelle simplifiée d’EMOF per-
mettant de décrire des métamodèles et des modèles. En effet, ADT supporte les modèles décrits
dans différents dialectes d’XMI, qui peuvent par exemple être décrits au format KM3 et trans-
formés au format XMI voulu. Une fois les métamodèles décrits en KM3, ils sont mappés dans le
métamodéle Ecore pour un traitement ultérieur.

2.4.3.2 Le standard QVT

Les transformations de modèles étant au coeur de MDA, l’OMG a défini le standard dé-
nommé QVT (Query, Views, Transformation) [OMG, 2008] pour modéliser ces transformations.
Ce standard définit le métamodèle permettant l’élaboration des modèles de transformation. Le
métamodèle de QVT est conforme à MOF et OCL est utilisé pour la navigation dans les mo-
dèles. Le métamodèle fait apparaître trois sous-langages pour la transformation de modèles (cf.
figure 2.15), caractérisés par le paradigme mis en œuvre pour la définition des transformations
(déclaratif, impératif et hybride). Les langages Relations et Core sont tous deux déclaratifs mais
placés à différents niveaux d’abstraction. L’un des buts de Core est de fournir une base pour la
spécification de la sémantique de Relations. La sémantique de Relations est donnée comme une
transformation de Relations vers Core. Il est parfois difficile de définir une solution complètement
déclarative à un problème de transformation donné. Pour répondre à ce besoin, QVT propose
deux mécanismes pour étendre Relations et Core : un troisième langage appelé Operational Map-
pings et un mécanisme d’invocation de fonctionnalités de transformation implémentées dans un
langage arbitraire (boîte noire ou black box ). Operational Mappings étend Relations avec des
constructions impératives et des constructions OCL avec effets de bord. Les langages de style
impératif sont mieux adaptés pour des transformations complexes qui comprennent une compo-
sante algorithmique importante. Par rapport au style déclaratif, ils ont l’avantage de gérer les
cas optionnels dans une transformation.
Dans la littérature, des outils implémentant le standard QVT commencent à voir le jour.
Parmi eux, nous pouvons citer : SmartQVT [Alizon F., 2008], MediniQVT[Medini, 2008], etc.
Pour terminer cette partie sur la transformation de modèles, il est important de mention-
ner la catégorie des outils de transformation de modèles dans lesquels la transformation de
modèles revient à l’exécution d’un méta-programme. Parmi ces outils nous pouvons citer Ker-
meta [Triskel, 2005, Jézéquel J., 2005, Muller, 2006] de l’IRISA-INRIA Rennes. Une description
en Kermeta est assimilable à un programme issu de la fusion d’un ensemble de métadonnées
(EMOF) et du métamodèle d’action AS (Action Semantics) qui est maintenant intégré dans
UML 2.0 Superstructure. Le langage Kermeta est donc une sorte de dénominateur commun
des langages qui coexistent actuellement dans le paysage de l’IDM. Ces langages sont les lan-
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 35

Figure 2.15 – Architecture du standard QVT [OMG, 2008]

gages de métadonnées (EMOF, ECORE,. . .), de transformation de modèles (QVT, ATL,. . .), de
contraintes et de requêtes (OCL), et d’actions AS (Action Semantics).

2.5 Positionnement : de la correspondance à la transformation

Cette section présente nos contributions liées aux processus de transformation dans MDA.
La figure 2.13 présentée dans la section 2.4.2 illustre ce que nous avons appelé "l’architecture du
processus de transformation dans MDA". Tous les langages de transformations proposés dans
le cadre de MDA et, en particulier ATL, reposent sur cette architecture. Nos premiers travaux
autour de MDA se sont interessés à cette architeture du processus de transformation et pour
laquelle nous avons relevé deux principaux problèmes :
1. Le premier problème concerne la création manuelle des règles de transformation entre
les métamodèles. Cette étape est souvent fastidieuse et enclin aux erreurs ce qui a, par
conséquent, un coût en terme d’efficacité [Fabro et Valduriez, 2007]. De plus, l’écriture des
règles de transformation nécessite une bonne maitrise à la fois du langage de transformation
que des métamodèles source et cible, afin de bien exprimer les correspondances tant d’un
point de vue structurel que sémantique.
2. Le deuxième problème qui nous intéresse le plus dans cette section concerne la spécification
de ces règles de transformations, qui implique ensemble les techniques de correspondances
(mapping) aussi bien que celles de transformations sans distinction explicite entre elles.
Ainsi, la spécification des correspondances entre les éléments de deux métamodèles et la
transformation entre eux sont regroupées dans le même composant (définition des règles
de transformations) et au même niveau (Niveau métamodèles M2).
La réponse au premier problème est traitée en détail dans le chapitre 5 de ce manuscript, nous
proposons alors une approche complète pour la semi-automatisation du processus de tansforma-
tion dans MDA. Le deuxième problème représente de notre point de vue un vrai problème de
"mélange des préoccupations" entre deux notions importantes du processus de transformation :
– La spécification des correpondances
– la définition des règles de transformations
La séparation entre ces deux notions relève à nos yeux du même niveau que la séparation entre
les modèles PIM et PSM. La spécification des correspondances doit être indépendante de tout
langage de transformation, alors que la définition des règles de transformations se fait dans un
langage précis. La spécification des correspondances consiste à relier des concepts de modélisa-
tion sémantiquement équivalents entre deux métamodèles. Cette spécification doit se faire par des
langages de haut niveau (idéalement graphique), puis complétée éventuellement par un langage
textuel neutre (type OCL) pour exprimer les contraintes de correspondances. Celles-ci serviront
à la génération automatique des règles de transformations. La définition des règles de transfor-
mations consiste en un ensemble de règles qui indiquent comment les éléments du métamodèle
source sont transformés en éléments du métamodèle cible. Ces règles sont exprimées dans un
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 36

langage de transformation type ATL. Notre approche présentée dans cette section suggère une
génération automatique de ces règles de transformations à partir de la spécification des cor-
respondances. Cette séparation des préoccupations "Correspondances versus Transformations"
permet à l’expert de se concentrer sur la partie spécification des correspondances en reliant les
éléments équivalents de deux métamodèles et en utilisant des outils bien adaptés.
La distinction et la séparation entre les techniques de mapping et de transformation ont été
mises en avant dans au moins deux domaines connexes à MDA :
– Dans les bases données [Bernstein, 2003, Fagin et al., 2008] :
"A good way to think about mapping design is as a three-step process that produces map-
pings in three successively more refined representations : correspondences, mapping
constraints, and transformations. . . ." [Bernstein, 2003], Model Management
Project.
". . . A schema mapping is a high-level specification that describes the relationship between
two database schemas. .... schema mappings constitute the essential building blocks of
data exchange...."
[Fagin et al., 2008], PODS’2008
– Dans les ontologies [Dou et al., 2003] :
"It’s important to distinguish ontology translation from ontology mapping, which is the
process of finding correspondences (mappings) between the concepts of two ontologies".
OntoMerge Project.
Dans le cadre de MDA, l’intérêt de la distinction et la séparation entre les techniques de mapping
et de transformation pour l’ensemble du processus de transformation a été discuté dans nos
différent travaux [Hammoudi et Lopes, 2005, Hammoudi et al., 2005, Lopes, 2005]. En outre, la
séparation entre les parties spécification des correspondances et la définition des transformations
constitue un premier pas vers une semi-automatisation du processus de transformation, puisque
les correspondances peuvent être découvertes (en parties) par un processus de matching entre
métamodèles. Le chapitre 5 sera dédié entierement à la problématique de la semi-automatisation
des transformations dans l’approche MDA.

2.5.1 Mapping Versus Transformation : définitions

Afin de clarifier les termes et concepts liés aux techniques de mapping (correspondance) et
de transformation, nous proposons ci-dessous les définitions suivantes :
Définition (spécification des correspondances). Le spécification des correspondances est l’ac-
tivité d’un expert qui, à partir de deux métamodèles (source et cible), définit les corres-
pondances entre les éléments du métamodèle source et ceux du métamodèle cible. Cette
activité donne lieu à un modèle de correspondances. La spécification des correspondances
est réalisée par des outils de haut niveau (graphique et textuel) permettant à l’expert de
se concentrer sur la tâche de définition des correspondances.
Définition (modèle de correspondance). Un modèle de correpondance est le résultat de l’activité
spécification des correspondances entre deux métamodèles. Il permet de préciser l’ensemble
des correspondances entre deux métamodèles. Dans notre démarche, un modèle de corres-
pondance permet de générer automatiquement un modèle de transformation comme un
ensemble de règles de transformation conformément à un langage de transformation (ATL,
QVT). Un modèle de correspondance est conforme à un métamodèle de correspondance.
Définition (métamodèle de correspondance). Un métamodèle de correspondances permet de
définir le concept central de correpondance. Cette définition permet à un expert de spécifier
des correspondances entre deux métamodèles afin de générer un modèle de correspondances.
La section 2.5.4 présente notre proposition d’un métamodèle de correspondances.
Définition (génération de règles de transformation). La génération de règles de transformation
est le processus qui permet de dériver automatiquement un modèle de transformation
conforme à un langage à partir d’un modèle de correspondance entre deux métamodèles.
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 37

Définition (modéle de transformation). Un modèle de transformation est un ensemble de règles

de transformation écrit dans un langage de transformation et qui permet de transformer
un modèle source en un modèle cible. La définition des règles de transformation entre
deux métamodèles produit un modèle de transformation. Un modèle de transformation est
conforme à un métamodèle de transformation.
Définition (métamodéle de transformation). Un métamodèle de transformation est un langage
définit sous forme d’une syntaxe abstraite pour la transformation des modèles dans MDA.
Il permet d’écrire des programmes de transformation (modèle) sous la forme d’un ensemble
de règles de transformation entre deux métamodèles.
Définition (transformation de modèle). Une transformation de modèle est une opération qui
permet d’exécuter le modèle de transformation sur un modèle source pour produire un
modèle cible. La transformation de modèle est l’objectif final dans le processus de trans-
formation dans MDA.

2.5.2 Une nouvelle architecture pour le processus de transformation.

La figure 2.16 illustre notre proposition pour le processus de transformation dans MDA.
Cette proposition étend l’architecture initiale de l’OMG (illustrée par la figure 2.13) en sépa-
rant explicitement la partie spécification des correspondances de la partie définition des règles
de transformations. Nous avons présenté pour la première fois cette nouvelle architecture du
processus de transformation dans la conférence CAISE en 2005 [Lopes et al., 2005].
Notre approche considère les correspondances comme des entités de première classe représen-
tées par un métamodèle (Mapping MM), qui permet de spécifier des modèles de correpondances
(Mapping M) entre deux métamodèles source et cible. Les différentes entités de cette architecture
sont :

Metametamodel
Level M3
conformsTo conformsTo conformsTo conformsTo

TransformationMetamodel MappingMetamodel SourceMetamodel TargetMetamodel

Level M2
conformsTo +left +right
conformsTo conformsTo conformsTo

MappingModel SourceModel TargetModel

TransformationModel
Level M1
+source +target
generatedFrom
generatedFrom

TransformationDefinition

generatedFrom Level M0
TransformationProgram

+execute TransformationEngine

Figure 2.16 – Une proposition d’architecture type pour la transformation de modèles

– Au niveau 3 de l’architecture, aucun changement par rapport à l’architecture de base

de l’OMG. Metametamodèle représente le formalisme de base permettant de créer des
métamodèles. Les deux langages MOF et Ecore sont les plus utilisés à ce niveau.
– Au niveau 2 de l’architecture, nous avons les métamodèles suivants :
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 38

– SourceMetamodel et TargetMetamodel (un métamodèle source et un métamodèle cible) :

par exemple, le métamodèle de UML et un métamodèle du langage JAVA.
– MappingMetamodel (un métamodèle de correspondances) : le langage pour spécifier les
correspondances entre les éléments d’un métamodèle source et les éléments d’un méta-
modèle cible. Les deux sections suivantes seront dédiées à la spécification des correspon-
dances et au métamodèle de correspondances.
– TransformationMetamodel (un métamodèle de transformation) : le formalisme (syntaxe
abstraite) permettant de définir un modèle de transformation comme un ensemble de
règles. Ce modèle appellé aussi "définition de la transformation" permet de transformer
un modèle source en un modèle cible.
– Au niveau 1 de l’architecture, nous avons les modèles suivants :
– MappingModel (un modèle de correspondance) : le modèle contenant les correspondances
entre deux métamodèles.
– SourceModel et TargetModel (un modèle source et un modèle cible) : par exemple, un
modèle d’une agence de voyages en UML qui doit être transformé en un modèle équivalent
en Java.
– TransformationModel (un modèle de transformation) : décrit la transformation d’un mé-
tamodèle dans un autre. Le modèle de transformation est généré dans notre approche à
partir du modèle de correspondances. Ce dernier est indépendant d’un langage de trans-
formation (hormis OCL pour l’expression de la sémantique des correspondances), alors
que le modèle de transformation est totalement dépendant d’un langage de transforma-
tion (ATL, QVT).
– Au niveau 0, nous avons les éntités suivantes :
– TransformationProgram (un programme de transformation) : un programme exécutable
pour réaliser la transformation.
– TransformationEngine (un moteur de transformation) : exécute un programme de trans-
formation à partir d’un modèle source pour produire un modèle cible équivalent.

2.5.3 Un formalisme graphique pour la spécification des correspondances

Dans le cadre de MDA, l’utilisation d’une notation graphique pour spécifier des correspon-
dances doit être intuitive, simple, et permettre la réutilisation de l’existant. Nous avons donc
adopté la notation présentée par la figure 2.17. Cette notation graphique réutilise la syntaxe
graphique d’UML comme dans d’autres propositions présentées dans [Hausmann et Kent, 2003,
Willink, 2003]
Le métamodèle source est localisé dans la partie gauche, le métamodèle cible dans la par-
tie droite, et la correspondance (mapping) se situe entre les deux. Une ligne en pointillés et
fléchée à gauche illustre une référence à un élément du métamodèle source. Une ligne en poin-
tillés doublement fléchée à droite illustre une référence à un élément du métamodèle cible. Le
cercle dénote un élément de correspondance identifié par un nom. Les lignes commencées par
une extrémité en forme de losange représentent la notion de composition d’UML : un élément
de correspondance peut être composé d’autres éléments de correspondance. Par conséquent,
une correspondance est aussi un modèle qui est utilisé pour spécifier les inter-relations entre
deux métamodèles. Cette notation graphique met en évidence les inter-relations entre deux mé-
tamodèles, mais elle est insuffisante pour permettre d’exécuter des requêtes sur les métamo-
dèles. Les requêtes sont importantes puisqu’elles permettent, par une navigation dans les mé-
tamodèles, de trouver quels sont les éléments équivalents ou similaires entre deux métamodèles
[Bernstein, 2003, Pottinger et Bernstein, 2003]. Actuellement, OCL est une solution largement
répandue pour spécifier des requêtes [Bordbar et Staikopoulos, 2004, Hausmann et Kent, 2003,
Kleppe et al., 2003], ce qui justifie son utilisation dans nos travaux pour permettre la création
de requêtes et de vues. Ainsi, chaque élément de correspondance (Mapping Element) contient
une requête en OCL pour naviguer dans le métamodèle source et retourner l’élément source
correspondant à l’élément du métamodèle cible. De plus OCL peut être utilisé pour spécifier des
contraintes entre les correspondances, par exemple faire le filtrage des éléments source avec une
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 39

Figure 2.17 – Formalisme graphique pour la spécification des correspondances

caractéristique particulière.
Les correspondances entre métamodèles ne sont pas toujours du type 1 : 1 (un-vers-un),
mais elles peuvent être 1 : n, n : 1 et m : n. Nous avons proposé [Lopes, 2005] une extension
au formalisme présenté sur la figure 2.17 afin de prendre en compte les différentes catégories de
correspondances.Une correspondance un-vers-un est caractérisée par un élément du métamodèle
cible présentant une structure et une sémantique similaire à un élément du métamodèle source.
Une correspondance un-vers-plusieurs est caractérisée par un ensemble non-unitaire et non-vide
d’éléments d’un métamodèle source contenant une structure et une sémantique similaire à un
élément du métamodèle cible. Une correspondance plusieurs-vers-un est caractérisée par un élé-
ment du métamodèle cible présentant une sémantique et une structure similaire à un ensemble
non-unitaire et non-vide des éléments du métamodèle source. Ce dernier type de correspondance
n’est pas directement réalisé avec des langages de transformation comme ATL, mais il peut être
simulé en utilisant une règle de transformation qui prend un seul élément du métamodèle source
et détermine les autres éléments en utilisant les relations entre eux. Une correspondance de type
plusieurs-vers-plusieurs n’est pas présentée, puisqu’elle peut être simulée par les autres types.
Ce formalisme graphique sera utilisé dans le chapitre 3 pour illustrer notre approche MDA
appliquée à la plateforme services Web.

2.5.4 Un métamodèle de correspondances.

Nous présentons ici notre proposition d’un métamodèle pour la spécification des correspon-
dances entre les éléments de deux métamodèles dans le cadre du processus de transformation de
MDA. Ce métamodèle permet de :
– identifier puis relier les éléments équivalents de deux métamodèles (source et cible). Ceci
représente la définition des correspondances ;
– gérer l’historique des différentes alternatives de correspondances ;
– spécifier des correspondances bidirectionnelles (Bi-directional mapping). Elles sont souhai-
tables, mais souvent complexes à réaliser [Mens et Van Gorp, 2006] ;
– naviguer entre les éléments des deux métamodèles en correspondances.
– Outre ces caractéristiques, nous souhaitons rester le plus indépendant possible du langage
de transformation. En fait, la spécification de correspondance peut être vue comme un PIM
et une définition de transformation dans un langage comme ATL peut être vue comme un
PSM.
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 40

Figure 2.18 – Un métamodèle pour la spécification des correspondances

La figure 2.18 présente notre proposition d’un métamodèle pour la spécification des correspon-
dances. Cette proposition a été discutée initialement dans un article de la revue ISI (Ingénièrie
des Systèmes d’Information) [Hammoudi et al., 2005]
Dans ce métamodèle, on considère que la correspondance pourrait être unidirectionnelle ou
bidirectionnelle. Dans la correspondance unidirectionnelle, un métamodèle source est mis en
correspondance avec un métamodèle cible. Dans la correspondance bidirectionnelle, la corres-
pondance est spécifiée dans les deux sens. Ainsi, de manière générale, les deux métamodèles sont
désignés par métamodèle source et métamodèle cible. Par la suite nous utiliserons les termes
métamodèle source (ou métamodèle gauche) et métamodèle cible (ou métamodèle droit)
Ce métamodèle de correspondances présente les éléments suivants :
– Element est une généralisation des autres éléments.
– Historic permet de préciser les différents choix pris lors de la spécification de correspon-
dances. Il comprend la date de la dernière mise à jour, une note, le numéro de la dernière
version et un ensemble de définitions représentant les différentes alternatives de correspon-
dances.
– Definition est l’élément principal qui contient toutes les définitions de correspondances
entre deux métamodèles gauche et droite (i.e. chaque correspondance possède un élément
gauche et un ou plusieurs éléments droits).
– Correspondence permet de spécifier la correspondance proprement dite entre deux ou
plusieurs éléments des métamodèles gauche et droit. La correspondance a un filtre défini
par une expression OCL. La propriété bidirectionnelle est précisée par un booléen. Deux
convertisseurs de types désignés respectivement par typeconverterRL et typeconverterLR.
L’élément typeconverterRL permet la conversion d’un élément du métamodèle droit vers
un élément du métamodèle gauche. L’élément typeconverterLR permet la conversion d’un
élément du métamodèle gauche vers un élément du métamodèle droit. En général, il est
nécessaire de préciser uniquement typeconverterLR.
– Left identifie dans une correspondance l’élément du métamodèle gauche.
– Right identifie dans une correspondance l’élément du métamodèle droit.
– MetaModelHandler permet de naviguer dans un métamodèle. Il possède les informations
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 41

nécessaires pour accéder et explorer un métamodèle participant dans une spécification de

correspondances.
– ElementHandler permet l’accès aux éléments en correspondances sans les modifier.
– TypeConverter permet une conversion de type entre un élément de gauche et un élément
de droite. Si un élément du métamodèle gauche et un élément du métamodèle droit sont
égaux alors la correspondance est simple et directe. En revanche, si les deux éléments
sont équivalents alors il est nécessaire de spécifier la conversion entre les deux éléments
en utilisant TypeConverter. Dans ce cas, une expression OCL permettra de spécifier cette
conversion et sera utilisée par la suite pour transformer l’élément de gauche en éléments
de droite.

2.5.5 Un outil pour la génération des règles de transformations

Nous avons développé un Plug-in sous Eclipse mettant en œuvre le métamodèle de corres-
pondances présenté dans la section ci-dessus. Deux principales fonctionnalités sont disponibles :
– La spécification des correspondances entre deux métamodèles (par l’expert)
– La génération automatique des règles de transformation en ATL (Modèle de transforma-
tion).
La première version de cet outil nommée MMT4MDE (Mapping Modeling Tool) est présentée
dans [Lopes, 2005]. La figure 2.19 montre la principale fenêtre de notre outil composée du pre-
mier métamodèle à gauche, le modèle de correspondance au centre et le second métamodèle à
droite.Dans cette figure, les fragments des métamodèles d’UML et de C# sont mis en correspon-
dance. L’éditeur de propriétés du modèle de correspondance est présenté au bas de la figure. Un
développeur peut utiliser cet éditeur pour ajuster les propriétés d’un modèle de correspondance.
Ce plug-in est basé sur EMF (Eclipse Modeling Framework), un framework de modélisation
qui facilite la génération de code permettant de créer des outils et des applications dirigées
par les modèles [Steinberg et al., 2009]. En fait EMF et MDA sont des approches similaires
pour le développement de systèmes logiciels, mais chacune utilise des technologies différentes.
MDA a été initialement développée par l’OMG en utilisant MOF et UML, alors qu’EMF est
basée sur le métamodèle Ecore et encourage la création des métamodèles spécifiques (DSL -
Domain Specific Language) [Cook, 2006]. Dans le contexte d’« Eclipse », EMF est un plug-in
supplémentaire pouvant être utilisé tel qu’il est ou étendu par d’autres plug-ins. Plug-in est un
mécanisme permettant d’étendre l’architecture de base d’« Eclipse » avec des extensions qui
partagent le même environnement [Gamma et al., 1993]. Avant de spécifier les correspondances
avec notre outil, nous avons besoin de créer des métamodèles conformes à Ecore. Quelques outils
permettent l’édition de métamodèles conformes à Ecore tel que : Omondo [OMONDO., 2004]
ou bien l’éditeur Ecore fourni par EMF [Steinberg et al., 2009]. Les étapes suivantes permettent
d’illustrer l’utilisation de notre outil (Dans [Lopes, 2005], une présentation détaillée est faite de
l’outil MMT4MDE) :
1. Nous créons un projet sous « Eclipse » et nous importons les métamodèles (UML et C#)
dans ce projet. Nous utilisons un guide (wizard) pour créer le modèle de correspondances
et on précise le nom du modèle de correspondances, le codage du fichier de correspondances
(par exemple, Unicode et UTF- 8) et les fichiers des métamodèles au format XMI.
2. Les métamodèles à gauche (UML) et à droite (C#) sont chargés à partir de fichiers XMI,
et le modèle de correspondances est créé. Il contient les éléments suivants : Historic,
Definition, left, right et MetamodelHandlers. Pour chaque élément MetamodelHandler,
des éléments ElementHandlers représentant des références aux éléments des métamodèles
en correspondance sont créés.
3. Nous éditons le modèle de correspondance. Nous commençons d’abord par créer les corres-
pondances entre les éléments des deux métamodèles. Ensuite, pour chaque correspondance,
des correspondances imbriquées sont créées. Enfin, pour chaque correspondance imbriquée,
on désigne un élément de gauche et un ou plusieurs éléments de droite. De plus, chaque
élément de gauche ou droite a un ElementHandler. Si nécessaire, l’élément TypeConverter
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 42

est utilisé pour expliciter une conversion entre les éléments en correspondance par le biais
d’une expression OCL.
4. Le modèle de correspondances peut être validé conformément à son métamodèle et peut
être utilisé pour générer une définition de transformations, en utilisant ATL par exemple.

Figure 2.19 – La spécification de correspondances avec MMT4MDE (Mapping Modeling Tool)

La figure 2.20 illustre la génération des règles de transformations en ATL d’UML vers C#, ob-
tenue à partir du modèle de correspondance défini précédemment. Ce fragment de code ATL pré-
sente la définition d’un module UML2CSHARP, la règle Class2Class et la règle Interface2Interface.
Dans le corps de la règle Class2Class l’élément source Class d’UML et l’élément cible Class de
C# apparaissent, ainsi que les différents bindings comme par exemple name<-class.name. Dans
le corps de la règle Interface2Interface l’élément source Interface d’UML et l’élément cible
Interface de C# apparaissent, ainsi que les différents bindings entre les différents attributs,
name <- interface.name, nameSpace <- interface.namespace.
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 43

Figure 2.20 – La génération des règles de transformations en ATL : de UML vers C#

2.6 Discussion et synthèse

Le développement des systèmes d’information dirigés par les modèles a pour principal objectif
de concevoir des applications en séparant les préoccupations et en placant les notions de modèles,
métamodèles et transformations de modèles au centre du processus de développement. Nous avons
introduit dans ce chapitre ces notions qui sont à la base des principes généraux de l’IDM, c’est-à-
dire la métamodélisation d’une part et la transformation de modèles d’autre part. Ces deux axes
constituent les deux problématiques clé de l’IDM sur lesquelles la plupart des travaux de recherche
se concentrent actuellement. Aujourdhui, l’IDM reste fortement marquée par l’approche MDA
et les standard de l’OMG, c’est pourquoi nous avons focalisé notre présentation et nos travaux
de recherche sur cette approche. Nous nous sommes particulièrement intéressés à trois axes
principaux de l’approche MDA et sur lesquels portent nos travaux de recherche :
– Les techniques et langages de modélisation et métamodélisation dans MDA
– Les techniques et langages de transformation de modèles dans MDA
– Le processus de développement dans MDA
Nous nous sommes focalisé sur la transformation de modèles qui est au centre de l’approche
MDA. En effet, l’intérêt de transformer un modèle Ma en un modèle Mb, que les métamodèles
respectifs MMa et MMb soient identiques (transformation endogène) ou différents (transforma-
tion exogène), est primordial (génération de code, refactoring, migration technologique, etc.).
De plus, l’approche MDA repose sur le principe de la création d’un modèle indépendant de
toute plateforme (PIM) pouvant être raffiné en un ou plusieurs modèle(s) spécifique(s) à une
plateforme (PSM). Les méthodes de transformation sont là aussi indispensables pour changer de
niveau d’abstraction (transformation verticale), dans le cas du passage de PIM à PSM et inver-
sement, ou pour rester au même niveau d’abstraction (transformation horizontale) dans le cas
de transformation PIM à PIM ou PSM à PSM. Toutefois, aujourdhui, ces transformations sont
réalisées manuellement, ce qui rend la tâche fastidieuse et source d’erreurs, rendant ainsi le pro-
CHAPITRE 2. L’IDM, L’APPROCHE MDA ET POSITIONNEMENT. 44

cessus de transformation coûteux. Nous avons proposé de renforcer le principe de la séparation

des préoccupations au niveau de la transformation de modèles, en distinguant explicitement la
partie spécification des correspondances (mappings) de la partie génération des règles de trans-
formations. Ainsi, les règles de transformations sont générées automatiquement à partir d’un
modèle de correspondances spécifié par un expert entre deux métamodèles . La spécification des
correspondances devrait se faire par des outils de haut niveau (graphique), aidant un expert dans
sa tâche de définition de correspondances entre les éléments de deux métamodèles. Nous avons
implémenté et validé cette approche dans un outil appelé MMT4MDE (Mapping Modeling Tool).
Dans le chapitre 3 dédié à l’application de MDA à la plateforme services Web, nous utiliserons cet
outil pour expérimenter et valider notre approche de transformation. En outre, cette séparation
entre les parties spécification des correspondances et la définition des transformations est la clé
et constitue un premier pas vers un processus semi-automatique de la transformation, puisque
les correspondances peuvent être découvertes (en parties) par un processus de matching entre
métamodèles. Le chapitre 5 sera dédié à la semi-automatisation du processus de transformation
qui est un réel défi dans MDA.
Chapitre 3

MDA et Plateforme Services Web

Technologies such as Web Services and component models have been advocated as
silver bullets for the service-oriented development of e-applications. However, if we
are to draw any lessons from the past, then the most important would be : there are
no (lasting) one-fits-all technology solutions, and therefore technologies will always
differ and evolve. [Pires et al., 2004].

3.1 Introduction
Ce chapitre présente notre approche MDA pour le développement des applications Internet
sur la plateforme services Web. Les services Web ont émergé durant cette dernière décennie
comme des technologies incontournables pour, d’une part, le développement et le déploiement
d’applications Internet et d’autre part, l’intégration et la communication entre des applications
hétérogènes. Les services Web ont réussi à être la plateforme consensuelle d’interopérabilité
entre applications réparties sur Internet, là où CORBA, DCOM et Java RMI ont échoué. Le
consensus industriel sur le langage XML et les technologies qui en découlent a été décisif. Ainsi,
les services Web reposent principalement sur des technologies basées sur XML pour la structure
et le contenu de messages échangés entre services (SOAP), pour la description fonctionnelle et
non fonctionnelle des services (WSDL), pour la découverte et le courtage des services (UDDI,
WS-Discovery) et pour leurs orchestrations (BPEL). L’ensemble de ces technologies appelé WS-*,
s’articule de manière cohérente [Nezhad et al., 2006]. L’adoption très répandue de ces standards
basés sur XML a stimulé une intense activité de recherche durant cette décennie dans les milieux
universitaires et industriels, autour des problèmes liés aux services Web. Ce chapitre porte sur
le travail de recherche que nous avons initié en 2003 avec la thèse de Denivaldo Lopes. Ce travail
fut alors motivé par deux constats :
– La plupart des problématiques de recherche autour des services Web portent sur les stan-
dards technologiques basés sur XML et sur les plateformes supportant ces standards (par
exemple, J2EE et dotNET). Cependant, une solution globale séparant clairement les par-
ties métiers des parties technologiques fait défaut. Par exemple, le problème de la compo-
sition de services est traité sous un angle technique dans la plupart des approches exis-
tantes. Ainsi, la composition des services Web est réalisée selon un processus adhoc, long
et sujet aux erreurs, impliquant souvent des techniques de programmation de bas niveau
[Medjahed et al., 2003].
– Les services Web ont réussi à assurer l’intéropérabilité des applications sur Internet. Ce-
pendant, l’expérience a montré que la création d’un nouveau intergiciel (même avec des
standards 1 ) n’est pas une solution viable à long terme pour supporter le développement et
l’intégration d’applications. Par conséquent, dans un futur plus ou moins proche, de nou-
velles exigences qui dépassent les capacités des services Web devraient apparaître. Ainsi,
tout laisse à penser que d’autres intergiciels vont apparaître [Pires et al., 2004].

1. l’intergiciel CORBA en est un exemple illustratif

45
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 46

Partant de ces constats, un axe de recherche prometteur pour le développement d’applica-

tions Internet fondées sur les services Web consiste en la séparation de leurs aspects liés à la
plate-forme de ceux indépendants de la plate-forme, en les décrivant par des modèles sépa-
rés. Cette tendance est mise en avant par l’approche de l’architecture guidée par les modèles
MDA que nous avons présentée dans le chapitre précèdent. Ainsi, dans cette approche, la
notion de modèle est au coeur du développement des systèmes, permettant de séparer
les caractéristiques indépendantes de la plate-forme (ou PIM– Platform-Independent Mo-
del) exprimées par des modèles neutres, de ceux dépendants de la plate-forme (ou PSM
– Platform-Specific Model), intégrant des caractéristiques spécifiques à des plates-formes
d’implémentation. L’approche MDA vise à fournir une architecture dans laquelle les appli-
cations Internet complexes (tel que les applications B2B) peuvent évoluer pour s’adapter
à de nouvelles exigences ou technologies. La logique métier est préservée des changements
technologiques, et les systèmes traditionnels (legacy systems) peuvent être intégrés et har-
monisés avec les nouvelles technologies.

Plan de ce chapitre
Dans un premier temps (section 3.2), nous présentons une vue d’ensemble des services Web
ainsi qu’un exemple typique d’application Internet afin d’illustrer notre approche. Le processus
de développement selon l’approche MDA sera aussi présenté dans cette section. La section 3.3
sera dédiée à la métamodélisation et la transformation. Pour la partie métamodélisation, nous
mettons face-à-face deux standards de l’OMG, UML et EDOC. Pour la partie transformation
nous présentons, d’une part, les différents scénarios de transformations expérimentés et, d’autre
part, la mise en œuvre de notre approche de transformation : spécification des correspondances
versus définition des règles de transformation. Nous présentons ensuite la mise en œuvre de notre
approche en utilisant l’outil MMT4MDE. La dernière section de ce chapitre (section 3.4) fournit
un positionnement par rapport à l’état de l’art, situe nos contributions et présente des objectifs
qui permettront de poursuivre les travaux. Nous présentons finalement une vue synthétique
de nos travaux sur MDA et la plateforme services Web en y positionnant les participants, les
coopérations et les publications.

3.2 Domaine applicatif et processus MDA

3.2.1 Les services Web
Le consortium W3C définit un service Web comme étant une application ou un composant
logiciel qui vérifie les propriétés suivantes :
Il est identifié par un URI, ses interfaces et ses liens peuvent être décrits en XML, sa définition
peut être découverte par d’autres services Web, il peut interagir directement avec d’autres services
Web à travers le langage XML et ce en utilisant des protocoles Internet.
Plusieurs définitions ont été proposées dans l’état de l’art, chacune mettant en avant certaines
caractéristiques des services Web (découverte, invocation, etc.). Actuellement, le modèle de ré-
férence des services Web repose sur différents standards basés sur XML, parmi lesquels WSDL,
UDDI et SOAP, fournissant une infrastructure pour supporter la description, la découverte
et l’interaction des services. La figure 3.1 présente un modèle de référence des services Web
[Medjahed et al., 2003]. Elle illustre les principaux acteurs (client, fournisseur et annuaire des
services), les principales technologies (WSDL, SOA et UDDI) et les principales opérations (re-
cherche, publication et invocation par message SOAP).
Les interfaces et les données exhibées par le service sont exprimées en termes métiers. Les
aspects technologiques ne sont plus essentiels car les services sont autonomes, c’est-à- dire qu’ils
sont indépendants du contexte d’utilisation ainsi que de l’état des autres services, et interopèrent
via des protocoles standardisés. Un service définit une entité logicielle (e.g., une ressource, une
application, un module, un composant logiciel, etc.) qui communique via un échange de messages
et qui expose un contrat d’utilisation. Durant cette dernière décennie, différents problèmes liés
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 47

Figure 3.1 – Modèle de référence des services Web, d’après [Medjahed et al., 2003].

aux services Web ont fait l’objet d’intenses recherches tel que la composition, la sémantique et la
sécurité. La composition des services Web peut être statique ou dynamique. Dans la composition
statique, les services sont sélectionnés et composés durant l’étape de conception, tandis que dans
la composition dynamique, ils le sont à l’étape de l’exécution. Créer des compositions de services
signifie ordonner les invocations d’opérations, router les messages, modifier les paramètres et
gérer les exceptions. Plusieurs langages de composition de services sont définis tel que WSBPEL
[Jordan et al., 2007] et SCUFL [Oinn et al ., 2004]. Les compositions de services sont au coeur
de l’architecture orientée service (SOA) [MacKenzie et al., 2006]. Celles-ci facilitent l’exposition,
l’interconnexion, la gestion et l’évolution d’applications à base de services. Dans le cadre des
services Web, nous nous intéressons plus particulièrement aux langages WSDL et BPEL. En
effet, notre objectif est de modéliser les logiques métiers en utilisant des langages de haut niveau
de type PIM (UML et EDOC), puis de transformer cette modélisation en description de services
(WSDL), ou en orchestration de services (BPEL). Pour la génération de code sur des plates-
formes concrètes, nos expérimentations se sont portées sur les plates-formes J2EE et dotNET.

3.2.2 Processus de développement MDA

La figure 3.2 illustre les principales activités d’une méthode permettant le développement
d’applications sur des plates-formes service Web selon l’approche MDA. Ces activités sont re-
présentées par deux diagrammes d’activités UML ; le premier (a) montre les étapes suivies par
l’utilisateur-expert et représente la phase dite de préparation. Il démarre par la spécification des
deux métamodèles source (1) et cible (2) et suit le processus jusqu’à la génération des règles
de transformation (4) et d’un programme de transformation exécutable. Le second diagramme
(b) illustre les étapes de la phase dite d’exécution réalisée par l’utilisateur-concepteur. Celui-
ci commence par spécifier un modèle métier d’une application basée sur un métamodèle PIM
(1), puis, en exécutant le programme de transformation (2), il génère automatiquement l’implé-
mentation de ce modèle métier sur une plateforme spécifique donnée (4). La distinction entre
les activités de préparation et les activités d’exécution est fondamentale dans les projets MDA
[Gavras et al., 2004]. Dans notre contexte de « Développement d’applications sur la plate-forme
service Web », les activités de l’utilisateur-expert sont les activités de préparation (diagramme
a), alors que ceux de l’utilisateur-concepteur représentent les activités d’exécution qui mènent
à un modèle final implémenté sur une plateforme spécifique. Dans [Gavras et al., 2004], les au-
teurs présentent les différents types d’utilisateurs dans MDA. Le chapitre 5 dédié à la semi-
automatisation du processus de transformation discutera les types d’utilisateurs dans MDA.

3.2.2.1 La phase de préparation : génération des règles de transformations

La phase de préparation comprend 4 activités présentées dans la figure 3.2 (a), elle est à
la charge de l’utilisateur-expert. Cette phase permet d’une part, de choisir (ou spécifier) les
métamodèles source et cible et, d’autre part, de préparer les régles de transformation (code
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 48

Figure 3.2 – Processus MDA de développement d’applications sur la plate-forme service Web.

source) pour les futures mises en œuvres d’applications. Voici une présentation de ces 4 activités :
– Spécification du métamodèle PIM (1) : cette activité a pour but de définir le métamodèle
PIM approprié pour un domaine d’application. Deux approches peuvent être distinguées
pour cette activité : l’approche DSL (Domain Specific Language) [Jouault, 2006], où le
métamodèle PIM est un langage spécialisé adapté à un domaine d’application ; l’approche
MDA qui préconise l’utilisation des langages standard de l’OMG pour la définition des
métamodèles. L’étude de l’approche MDA est l’un de nos objectifs et nous avons donc opté
pour les deux langages standard UML et EDOC pour la métamodélisation. De plus, le
langage EDOC, tout en étant un standard de MDA, est bien dans la mouvance des DSL
puisque il est préconisé spécifiquement pour les systèmes distribués à base de composants.
En outre, nous avons utilisé les profils UML pour prendre en considération les sémantiques
particulières. Comme retour d’expérience, nous avons déduit (cf. section 3.5) que l’approche
DSL puisqu’elle met en avant des langages spécifiques est plus adaptée que l’utilisation du
langage UML beaucoup plus général.
– Spécification du métamodèle PSM (2) : cette activité a pour objectif de définir le métamodèle
PSM de la plateforme cible. Les PSM sont spécifiés dans le même formalisme que les PIM
(UML ou EDOC), mais sont de plus bas niveau car ils doivent se conformer à des contraintes
imposées par la plateforme cible, c’est-à-dire la plateforme dans laquelle l’application sera
implémentée.
– Spécification des correspondances PIM-PSM (3) : Cette activité est dédiée à la spécification
des correspondances. Elle consiste à spécifier quels éléments du PIM (par exemple d’UML)
sont équivalents ou similaires aux éléments du PSM (par exemple quels éléments d’UML
sont équivalents ou similaires aux éléments de WSDL). Conformément à notre approche
de transformation présentée dans le chapitre 2, la spécification des correspondances donne
lieu à un modèle de correspondances. Ce modèle doit être complet et cohérent afin de
permettre une génération automatique des règles de transformations.
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 49

– Génération des règles de transformation (4) : cette activité a pour but de générer automati-
quement les règles de transformation à partir des correspondances. Ces règles constituent
un programme de transformation qui traduit un modèle PIM en un modèle PSM équi-
valent. Le modèle de mapping obtenu à la phase précédente, suite à une éventuelle mise à
jour par l’utilisateur expert, doit être complètement défini pour permettre une génération
automatique des règles de transformation. Ce modèle de transformation, qui est décrit par
un ensemble de règles de transformation, est structuré conformément au langage ATL que
nous avons utilisé dans toutes nos expérimentations.

3.2.2.2 La phase d’exécution : génération du code source (plate-forme cible)

Cette phase est réalisée par l’utilisateur-concepteur qui, après avoir défini le modèle mé-
tier, souhaite l’implémenter sur une plateforme spécifique. Dans cette phase nous avons quatre
activités décrites dans la figure 3.2 (b).
– Spécification du modèle PIM (1) : à partir du métamodèle PIM, un utilisateur-concepteur
définit son modèle métier en se concentrant uniquement sur la logique métier, sans tenir
compte des considérations d’implémentation. Dans cette étape, le concepteur peut utiliser,
par exemple, les différents diagrammes UML qui mèneront à un diagramme de classes final
prêt à l’implémentation sur une plateforme spécifique. Notre démarche sera illustrée par
l’exemple de l’agence de voyage présenté dans la section suivante
– Exécution du Programme de Transformation (2) : le programme de transformation obtenu
dans la première partie est maintenant utilisé. Il prend en entrée le modèle PIM défini
lors de l’étape précédente et produit en sortie le modèle PSM équivalent. Le moteur de
transformation, qui exécute le programme de transformation, lit le modèle source, applique
les règles de transformation et produit le modèle cible correspondant.
– Vérification du modèle PSM obtenu (3) :le modèle PSM produit lors de la phase précédente
représente une première version et peut être complété par des informations très spécifiques à
la plateforme cible pour produire un modèle final exécutable. L’intervention de l’utilisateur-
concepteur est donc nécessaire afin de vérifier si le PSM obtenu est complet. Dans le cas
où il est complet, le modèle PSM est transformé en code source pour la plateforme cible ;
dans le cas contraire, l’utilisateur-concepteur compléte manuellement le modèle PSM afin
de pouvoir générer un code source exécutable sur la plateforme cible.
– Génération du code source, fichiers de déploiements (4) : Cette activité consiste à générer le
code source, les scripts et le fichier de déploiement à partir du PSM final créé précédemment.
Dans ce cas, une transformation de type modèle vers code est nécessaire.

3.2.3 Exemple illustratif

Pour étudier et illustrer l’approche MDA pour le développement d’applications sur la plate-
forme service Web, nous avons choisi l’exemple classique de l’agence de voyages. Une agence de
voyages vend des billets d’avion, réserve des chambres d’hôtel et gère la location de voitures. Afin
de fournir ses services aux clients, une agence de voyages doit établir des liaisons avec d’autres
partenaires, i.e. une compagnie aérienne, une entreprise de location de voitures et un hôtel. Dans
ce contexte, une institution financière, i.e. une agence bancaire, est requise pour accomplir les
transactions financières entre un client et une entreprise (C2B) ou entre deux entreprises (B2B).
La figure 3.3 présente un diagramme de cas d’utilisation simplifié impliquant l’agence de voyages
et ses partenaires.
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 50

Travel Agency AirLines

AirLinesService

Customer
CarHire
TravelService
RentingCarService

Hotel

HotelService

BankService

Bank

Figure 3.3 – Diagramme des cas d’utilisations de l’agence de voyage

A ce stade, nous pouvons considérer ce diagramme des cas d’utilisation comme notre modèle
CIM de départ à partir duquel un concepteur spécifie un modèle PIM. Dans les prochaines
sections, cet exemple illustratif de notre domaine d’application sera modélisé, transformé et
déployé sur une plate-forme service Web, avec une approche de l’ingénierie dirigée par les modèles
conforme à MDA.

3.3 Modélisation, métamodélisation et transformation

La figure 3.4 présente nos différentes applications de l’approche MDA sur la plateforme Service
Web 2 . Cette figure illustre quatre points clés discutés brièvement précédemment :
1. Les deux principaux formalismes de modélisation et métamodélisation (UML et EDOC).
2. Les différents types de modèles (PIM, PSM et code).
3. les différentes plateformes (Services Web, J2EE et dotNET, BPEL)
4. Les deux principales techniques de transformations (modèle-modèle et modèle-code).

Figure 3.4 – Métamodèles, modèles et transformations

2. Dans [Lopes, 2005], nous avons aussi étudié la plateforme dotNet qui ne sera pas discuté ici
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 51

IL est important de noter que la plateforme service Web (WS) représentée par le langage
WSDL, est une plateforme abstraîte car indépendante de tout langage de programmation et
d’un environnement de développement. Au contraire, J2EE avec JWSDP est une plateforme ser-
vice Web concrète ; elle permet la mise en œuvre complète des services avec le langage Java sous
l’environnement J2EE. Les sections suivantes clarifient notre approche. La section 3.3.1 définit le
modèle PIM de l’agence de voyage en utilisant le langage UML. La section 3.3.2 présente ensuite
les métamodèles permettant de spécifier les logiques métiers et les plateformes cibles. La section
3.3.3 présente la première étape du processus de transformation permettant de générer les règles
de transformations entre métamodèles. Cette section sera illustrée par notre outil MMT permet-
tant la génération des règles de transformation à partir de spécifications de correspondances. La
section 3.3.4 sera dédiée à la seconde étape de la transformation, permettant d’implanter notre
modèle métier présenté dans la section 3.3.1 sur une plateforme cible services Web.

3.3.1 La modélisation : le modèle PIM de l’agence de voyage

Les figures 3.5 et 3.6 présentent le modèle UML (PIM) de notre exemple illustratif "Agence
de voyage". Dans la figure 3.5, six classes implémentent les principales caractéristiques du
système : Customer (le client), ServiceTravelAg (l’agence de voyage), ServiceAirLines (la
compagnie aérienne), ServiceCarHire (la location de voiture), ServiceHotel(la chaine hô-
tels) et ServiceBank (la banque). Le client accède à l’agence de voyages via son navigateur
Web. L’agence de voyages fournit les services pour chercher, réserver, payer et annuler un billet
d’avion, la location d’une voiture et la réservation d’une chambre. Les classes ServiceAirLines,
ServiceCarHire et ServiceHotel permettent de chercher, réserver, payer et annuler les services
qu’elles proposent. La classe ServiceBank permet de réaliser les transactions financières entre
les différents partenaires.

customer airlines

Customer AirLines
+find_travel(travel_req:Travel_req) : Travel_list +find_flight(inf_req:Fly_req) : Fly_list
+reserve_travel(travel_inf:Travel_Inf) : Reserv +airlines_serv +reserve_flight(fly_sel:Fly_Inf) : Reserv
+pay_travel(pay_inf:Pay_Inf) : Ack_pay +pay_flight(pay_inf:Pay_Inf) : Ack_pay
+cancel_travel(reserv_inf:Reserv) : Ack_cancel +cancel_flight(reserv_inf:Reserv) : Ack_cancel

travelagency carhire
+travel_serv

TravelAg CarHire
+find_travel(travel_req:Travel_req) : Travel_list +find_car(car_req:Car_req) : Car_list
+carhire_serv
+reserve_travel(travel_sel:Travel_Inf) : Reserv +reserve_car(car_sel:Car_Inf) : Reserv
+pay_travel(pay_inf:Pay_Inf) : Ack_pay +pay_car(pay_inf:Pay_Inf) : Ack_pay
+cancel_travel(reserv_inf:Reserv) : Ack_cancel +cancel_car(reserv_inf:Reserv) : Ack_cancel

hotel
bank
+bank_serv Hotel
Bank +find_room(room_req:Room_req) : Room_list
+hotel_serv
+make_payment(pay_inf:Pay_Inft) : Ack_pay +reserve_room(room_sel:Room_Inf) : Reserv
+pay_room(pay_inf:Pay_Inf) : Ack_pay
+bank_serv +bank_serv +bank_serv
+cancel_room(reserv_inf:Reserv) : Ack_cancel

Figure 3.5 – Le modèle PIM de l’étude de cas "agence de voyages"

CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 52

La figure 3.6 illustre un diagramme d’activité pour l’agence de voyages. Dans ce diagramme,
l’activité principale qui est la recherche d’un voyage implique l’invocation de trois services : le
service de recherche d’une chambre d’hôtel, celui d’une location de voiture et enfin celui d’un
billet d’avion. Pour réaliser cette activité principale, l’agence de voyages fait une composition de
trois services impliquant les trois classes ServiceAirLines, ServiceCarHire et ServiceHotel.
Concrètement, l’agence de voyages reçoit une requête d’un client illustrée par l’activité principale
ReceiveFindTravel. Ensuite, l’activité principale démarre trois activités secondaires en parallèle.
Dans chaque activité démarrée, une action d’affectation (AssignInputFlight ; AssignInputCar
ou AssignInputRoom) fait la copie des données reçues par ReceiveFindTravel dans l’entrée d’un
service (CallFlight ; CallCar ou CallRoom). Après l’éxécution des trois services l’action d’af-
fectation AssignReturn copie le résultat de chaque service pour être envoyé au client. L’action
ReplyFindTravel retourne le résultat de la recherche au client. De manière similaire, chaque mé-
thode de la classe ServiceTravelAg peut être décrite par un diagramme d’activité illustrant les
sous-activités réalisées par les autres classes. Afin de modéliser l’activité recherche d’un voyage
comme une composition de services et permettre sa transformation vers le langage standard
WSBPEL, nous utilisons des valeurs marquées d’UML pour lier le diagramme d’activité au dia-
gramme de classe. À chaque action, des valeurs marquées sont utilisées pour faire référence à une
classe ou à une opération du diagramme de classes.

Figure 3.6 – Diagramme d’activités pour l’agence de voyages (fragment)

Le tableau 3.1 présente des exemples de valeurs marquées avec dans la première colonne
les actions, au milieu les marques, et à droite les valeurs. Une présentation complète de ces
valeurs est faîte dans [Lopes, 2005]. L’utilisation de valeurs marquées est nécessaire car il y a une
différence syntaxique et sémantique entre le métamodèle d’UML (version 1.4) et celui de BPEL
(BPEL4WS version 1.1).

Dans le métamodèle de BPEL, chaque action est réalisée par une opération d’un service, et
chaque service est associé à un (partnerLink). Celui-ci contient les informations sur le rôle et
l’interface (PortType) du service qui réalise cette opération. Dans le métamodèle d’UML (ver-
sion 1.4), les actions (ActionState) d’un diagramme d’activité ne sont pas liées à une opération
(Operation) d’une classe. Dans ce cas, nous utilisons les valeurs marquées pour établir cette
association (action - opération - classe). De plus, les actions peuvent correspondre à une appel
(invoque en BPEL), réception (receive en BPEL) ou affectation (assign en BPEL). D’autres
travaux comme [Skogan et al., 2004], ont aussi relevé cette distance sémantique entre le dia-
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 53

Table 3.1 – Exemple de valeurs marquées associées au diagramme d’activité.

gramme d’activité d’UML et le langage BPEL, et ont proposé les profils UML pour réduire cette
distance et permettre une transformation.
La section 3.3.3.3 dédiée à la spécification des correspondances entre UML et BPEL discu-
tera plus en détail de ce problème. Il est important de noter qu’aujourd’hui, UML2.0 permet de
pallier à ce problème en proposant différents éléments (AcceptCallAction, ReplyAction, CallO-
perationAction, ReadVariableAction, WriteVariableAction) qui permettent de préciser le concept
d’action du diagramme d’activité. Dans notre approche (Table 3.1), nous avons utilisé des
marques tel que « activity » (acceptant les valeurs « receive » , « assign », « invoque » et «
reply » ), « class » (acceptant le nom d’une classe) et « operation » (acceptant le nom d’une
opération).

3.3.2 La métamodélisation : les métamodèles PIM et PSM

Les métamodèles de type PIM sont UML et EDOC, deux langages standards de l’OMG.
Ces deux métamodèles ont été présentés en chapitre 2. Nous allons présenter ici les principaux
métamodèles pour la partie PSM dédiée au services Web et à la composition de ces services.
Sur la page suivante nous avons les différents métamodèles spécifiés à partir du formalisme
UML/MOF. Les figures 3.7 et 3.8 décrivent deux métamodèles des deux plateformes abstraites
pour d’une d’une, part la, description des services (WSDL) et, d’autre part, l’orchestration des
services (BPEL). Les figurent 3.9 et 3.10 décrivent deux métamodèles de la plateforme J2EE
pour le développement des services Web : le métamodèle du langage JAVA, et le métamodèle de
l’API Java pour les services Web (JWSDP, JAX-WS).

La figure 3.7 représente un métamodèle pour WSDL. Ce métamodèle permet de dériver des
modèles de services (documents XML) composés des éléments suivants :
– Les opérations proposées par le service Web ;
– Les données et messages échangés lors de l’appel d’une opération ;
– Le protocole de communication ;
– Les ports d’accès au service.

Dans WSDL, il existe une séparation entre deux niveaux indépendants, l’un abstrait, l’autre
concret. Le niveau abstrait regroupe les informations pouvant être réutilisées (i.e. non spécifique
à un service), tandis que le niveau concret est constitué de la description des protocoles d’accès
au service Web (i.e. spécifique à un service). Le niveau abstrait est utilisé principalement lors
du processus de sélection des services, tandis que le niveau concret est seulement utilisé lors de
l’invocation des méthodes du service Web.

La figure 3.8 présente un métamodèle pour BPEL. Ce métamodèle permet de spécifier des
modèles d’orchestration de services. Un modèle d’orchestration de services met en œuvre une
composition de services qui est un moyen efficace pour créer, exécuter et maintenir des ser-
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 54

vices qui dépendent d’autres services. L’élément central du métamodèle BPEL est le processus
qui forme une couche au dessus de WSDL. Les processus de BPEL exportent et importent des
fonctionnalités en utilisant les interfaces de services Web uniquement (BPEL contient les ca-
ractéristiques d’un langage structuré en blocs inspiré du langage XLANG de Microsoft). BPEL
permet de modéliser deux types de processus :

– Le processus abstrait spécifie les échanges de messages entre les différentes activités, sans
spécifier le comportement interne de chaque activité.
– Le processus exécutable : spécifie l’ordre d’exécution des activités constituant le processus,
des partenaires impliqués dans le processus, des messages échangés entre ces partenaires,
et le traitement de fautes et d’exceptions.

Conformément à la figure 3.8, les principaux éléments du processus BPEL sont les suivants :

– Les liens de partenaires : Un lien de partenaire (partnerLink ) correspond au service avec

lequel le processus échange des informations. Le lien de partenaire représente la relation
de conversation entre deux processus partenaires.
– Les activités : Le processus dans BPEL est constitué d’activités liées par un flot de
contrôle. Ces activités peuvent être basiques ou structurées
– Les données : Le processus dans BPEL a un état qui est maintenu par des variables
contenant des données. Ces données sont combinées afin de contrôler le comportement du
processus. Elles sont utilisées dans les expressions et les opérations d’affectation.

Une présentation détaillée des métamodèles de WSDL et BPEL des figures 3.7 et 3.8 se trouve
dans [Lopes, 2005]. Afin de mettre en œuvre notre approche MDA pour les services Web, nous
avons expérimenté deux plateformes concrètes dans nos travaux[Lopes, 2005] : la plateforme
J2EE et la plateforme dotNet. Nous ne présentons ici que la mise en œuvre sur la plateforme
J2EE. Celle-ci est constituée de différentes technologies, notamment le langage Java, JDBC (Java
DataBase Connectivity), JWSDP (Java Web Services Developer Pack ), EJB (Enterprise Java-
Beans) et JSP (Java Server Pages). Parmi ces technologies, nous nous intéressons particuliè-
rement au langage Java et JWSDP. Ce dernier est le framework du monde Java permettant
la programmation et le déploiement de services Web. Ainsi, nous présentons un métamodèle
de Java et un autre de JWSDP. La figure 3.9 présente un métamodèle de Java. La figure 3.10
présente d’une part (partie en haut) un template (modèle) et d’autre part (partie en bas) un
métamodèle pour JWSDP. Le template décrit la réalisation d’un service Web en JWSDP. En
réalité, le template spécifie l’utilisation de l’API de JWSDP qui se situe au niveau modèle dans
l’architecture de quatre niveaux de MDA . Un service Web est créé en JWSDP à travers une
WSClass (conforme à JClass) qui implémente une WSInterface (conforme à JInterface). Une
description détaillée des métamodèles liés à la plateforme J2EE (Java et JWSDP) est présentée
dans [Lopes, 2005].

Nous allons aborder maintenant les techniques de transformations permettant d’une part, la
génération des règles de transformations utilisées pour une transformation modèle-vers-modèle
(notée M2M) et, d’autre part, la mise en œuvre d’un modèle métier PIM sur une plateforme cible
par une transformation modèle-vers-code ( notée M2C). La première étape consiste à spécifier
les correspondances entre deux métamodèles et la génération automatique des règles de trans-
formation. Ces règles de correspondances permettront ensuite d’obtenir un premier modèle PSM
à partir d’un modèle PIM. La seconde étape consiste à transformer le modèle PSM vers le code
final propre à la plateforme. La génération de code à partir d’un modèle PSM n’est d’ailleurs pas
réellement considérée dans MDA. Celle-ci s’apparente plutôt à une traduction des PSM dans un
formalisme textuel.
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 55

+ complexType
1..* + wsdlType BPELExtensibleElements PartnerLink
ComplexType * +name: 1..*
WSDLType +partnerLinkType:
+ wsdlType + partnerLinks + partnerLink +myRole:
+ partnerLink
PartnerLinks
SimpleType +partnerRole:
* 1..*
+ partner Partner
+ partners Partners
WSDLElement 1..* +name: 0..1
+ import * + partnerLinkType
Import Variable
* + variable PartnerLinkType
Extensible Element + variables Variables
+name:
+ types Types +name:
1..* +messageType:
0..1 *
+type:
Documentation Part
Process +element:
+ documents + part * + correlationSets CorrelationSets 1..2 + role
+ message +name: CorrelationSet
0..1 Message + correlationSet
+targetNamespace: *
* +name: Role
+ portType +abstractProcess: 1..*
+ doc Definition +properties:
PortType +name:
+ faultHandlers FaultHandlers + catch -portType:String
+name: * + type Catch
+ binding
+targetNameSpace: *
* +faultName:
* Binding
+faultVariable:
+ binding + catchAll
+ compensationHandler CompensationHandler
AcivityOrCompensateContainer
Port 0..1
+ output *
+ port *
StartWithExtension + eventHandlers EventHandlers
0..1 + service Correlations
+ input 0..1 Service * + onMessage + correlations
OnMessage
* * 0..1
Fault + fault + activity *
BindingOperation +partnerLink:
+ operation * +portType:
+name: 1..* Activity
* * + operataion Flow +operation:
0..1 + activity +name:
Operation +variable:
OneWayOperation +joinCondition:
Empty
+ oneway +suppressionJoinFailure:
OnAlarm
+ input + input + requestresponse 0..1 Invoke + activity + onAlarm
1..* +for:
ParamType RequestResponseOperation Receive Switch * +until:
+ output
+name: + solicitresponse + target
+ input Reply While
+message: SolicitResponseOperation Target
0..1 Assign Sequence
+ output + notification * +linkName:
NotificationOperation
+ fault 0..1 Wait Pick
FaultType
+ source Source
+name: * Throw Scope
+ fault +linkName:
+message: Terminate * +transitionCondition:
*
Created with Poseidon for UML Community Edition. Not for Commercial Use.
Created with Poseidon for UML Community Edition. Not for Commercial Use.

Figure 3.7 – Un métamodèle de WSDL Figure 3.8 – Un métamodèle de BPEL

JElement
+ has * Annotation << enumeration >>
+name:String TypeName
+ jelement +expression:String
+visibility:Visibility
+byte:int
+modifier:Modifier
+short:int
* + jelements +int:int
+ throws
+ jpackage JClass +long:int
+isActive:Boolean * +float:int
JPackage
+double:int
+ enclosing 0..1 + super 0..1 + implementedby +char:int
* *
* JClassifier * + implements +boolean:int
+ nested + sub
JInterface +String:int

+ type + type
+ owner JPrimitiveType
<< enumeration >>
+ jmembers +type:TypeName Modifier
{ordered} *
config.xml
JMember +jabstract:int config-interface.xml Service WSDL
+name : String Configuration +wsdl
+final:int Configuration
+location : URI
+targetNamespace : URI +xmlns : URI
+isStatic:Boolean +regular:int
+packageName : String
+xmlns : URI +service +typeNamespace : URI
+packageName : String

+interface web.xml 0..1 Display-name

<< enumeration >> +display : String
Interface +display-name
+ jfields JField JMethod Visibility +name : String 0..1
* Web-app Description
* +isTransient:Boolean +isNative:Boolean +public:int jaxrpc-ri.xml
+endpoint +description +description : String
+isVolatile:Boolean +isSynchronized:Boolean + throwMethods +protected:int
EndPoint
0..1
+name : String Session-config
+isFinal:Boolean +body:String +private:int +displayName : String +session-config
-session-config : String
WebServices +description : String
+ owner + owner +xmlns : URI +session-timeout
+interface : String 0..1
0..1 0..1
+version : String +implementation : String Session-timeout
{ordered} + jvalue
{ordered} * + jparameters +targetNamespaceBase : URI +model : String +session-timeout : String
JValue +typeNamespaceBase : URI
JParameter +urlPatternBase : URI EndPointMapping
+value:String *
+result:Boolean +endpointName : String

+ jparameters +endpointMapping
+urlPattern : URI

Created with Poseidon for UML Community Edition. Not for Commercial Use.

Figure 3.9 – Un métamodèle de Java Figure 3.10 – Un métamodèle de JWSDP

CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 56

3.3.3 Spécification des correspondances et transformation M2M.

La spécification des correspondances entre métamodèles puis la génération des règles de trans-
formation sont la spécificité de notre approche de la transformation présentée dans le chapitre 2.
Notre objectif est d’offrir à l’expert des outils lui permettant de se concentrer sur la spécification
des correspondances, puis de générer automatiquement les règles de transformations. Ces règles
permettront de réaliser automatiquement une première transformation modèle vers modèle. Pour
la partie PIM, nous allons considérer ici le métamodèle EDOC-CCA présenté au chapitre 2. Dans
[Lopes, 2005], en plus de celui de EDOC-CCA, les métamodèles d’UML et des profils UML sont
pris en compte pour la partie PIM.

3.3.3.1 La plateforme abstraite WSDL

La figure 3.11 montre une spécification de correspondances entre les métamodèles EDOC-
CCA et WSDL en utilisant notre formalisme graphique présenté au chapitre 2. L’élément de cor-
respondance P2D met en relation l’élément Package de EDOC-CCA avec l’élément Definition
de WSDL. L’élément de correspondance Pc2S met en relation l’élément ProcessComponent
avec l’élément Service de WSDL. L’élément de correspondance P2PB met en relation l’élé-
ment ProtocolPort avec les éléments PortType, Binding et Port de WSDL. L’élément de
correspondance O2O met en relation l’élément OperationPort avec les éléments Operation et
BindingOperation de WSDL. L’élément de correspondance F2M met en relation l’élément FlowPort
avec l’élément Message de WSDL. Par mesure de simplification, toutes les correspondances ne
sont pas présentées sur la figure 3.11. Nous rappelons que les correspondances entre éléments de
deux métamodèles sont précisées et complétées par le langage OCL. Une fois les correspondances
totalement définies par un expert, la génération des règles de transformations en langage ATL
se fait de manière automatique.

Figure 3.11 – La spécification des correspondances (EDOC-CCA, WSDL)

CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 57

Ainsi, chaque élément de correspondance sur la figure 3.11 se voit associé une règle de trans-
formation en ATL. L’élément PC2S permet de générer la règle ATL PC2S suivante :

1 -- File : EDOC2WSDL . atl 2

2 module EDOC2WSDL ;
3 create OUT : WSDL from IN : EDOC ;
4 rule Pc2S {
5 from pc : EDOC ! P ro c e s s C o m p o n e n t
6 to sv : WSDL ! Service
7 ( name <- pc . name ,
8 owner <- pc . namespace ,
9 port <- pc . ports - > select ( e | e . oclIsKindOf ( EDOC ! ProtocolPort ) ) ) }

Les figures 3.12 et 3.13 illustrent, en utilisant notre outil MMT4MDE présenté au chapitre
2, la mise en œuvre, d’une part, de la spécification des correspondances entre les métamodèles
EDOC-CCA et WSDL (figure 3.12) et, d’autre part, de la génération des règles de transformations
(figure 3.13). Une partie du code en ATL de la transformation entre les métamodèles d’EDOC-
CCA et WSDL est présentée dans figure la 3.13.

3.3.3.2 La plateforme concrète J2EE

L’activité de spécification des correspondances est plus simple lorsque seuls des métamodèles
entrent en jeu comme par exemple UML d’une part et WSDL de l’autre. Cependant, cette activité
devient plus complexe dès que des bibliothèques doivent êtres utilisées. Nous avons vu (cf. 3.3.2)
que la plateforme services Web J2EE est représentée par le framework JWSDP. Celui-ci est
constitué d’une bibliothèque et des fichiers de configuration et de déploiement. Dans la section
précédente, nous avons proposé un template et un métamodèle pour JWSDP. Le template est un
modèle permettant de décrire la réalisation d’un service Web en JWSDP. Ce modèle doit être
respecté lors de la spécification des correspondances et, par conséquent, dans la définition des
transformations. La création d’une spécification de correspondances entre UML et J2EE peut
être effectuée en une seule étape ou en étapes progressives. Dans le premier cas, le template de
JWSDP peut être utilisé dès la transformation d’UML en Java. Dans le second cas, nous pouvons
tout d’abord spécifier les correspondances entre UML et Java, puis entre Java et le template de
JWSDP. Dans les deux cas, la spécification de correspondances entre le métamodèle d’UML
et celui de JWSDP doit être faite, puis les fichiers de configuration et de déploiement peuvent
alors être générés. La plate-forme JWSDP étant composée de deux parties, un template et un
métamodèle, le template est conforme au métamodèle de Java, et le métamodèle de JWSDP
contient la description des fichiers de déploiement.
Dans [Lopes, 2005], nous avons proposé l’utilisation des étapes progressives pour la trans-
formation d’UML en J2EE, et d’une seule étape dans le cadre de la transformation d’UML en
dotNET.
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 58

Figure 3.12 – L’interface MMT4MDE pour la spécification des correspondances

Figure 3.13 – L’interface MMT4MDE pour la génération des règles de transformations

CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 59

3.3.3.3 La plateforme d’orchestration BPEL

Nous avons discuté dans la section 3.3.1 du problème de distance sémantique entre le
métamodèle d’UML (version 1.4) et le langage BPEL. Cette section présente notre approche
pour réduire cette distance sémantique et permettre la spécification des correspondances et la
génération des règles de transformations entre les deux métamodèles.
Un diagramme d’activité est un cas particulier de diagramme d’état dans lequel les états
sont des actions ou des sous-actions, et les transitions sont déclenchées par l’accomplissement
d’actions. Un diagramme d’activité est attaché à un classificateur tel qu’un cas d’utilisation, un
paquetage (package) ou une classe.
BPEL est basé sur un modèle de composant à granularité fine constitué d’activités qui peuvent
être de deux types : basique ou structurée. Les activités basiques représentent l’invocation d’une
opération réalisée par un service Web, par exemple invoke, receive, reply et assign. Les
activités structurées sont basées sur l’approche des hiérarchies d’activités dans laquelle un proces-
sus est spécifié par le raffinement progressif d’une activité dans un arbre d’activités. Les noeuds
représentent les actions à exécuter et les noeuds intermédiaires définissent une contrainte entre
les activités secondaires.
Une spécification de correspondances entre le diagramme d’activité d’UML et BPEL n’est
pas une tâche simple. Ils sont tous les deux utilisés pour représenter des processus, mais ils
utilisent des approches différentes : celle du diagramme d’activité est fondée sur les automates
d’états-finis (dans la forme d’état-transition) alors que celle de BPEL est basée sur une hiérarchie
d’activités. La spécification de correspondances et la définition de transformations entre UML et
BPEL doivent considérer leurs caractéristiques respectives. D’une part, un diagramme d’activité
n’est pas forcément structuré alors que BPEL est bien structuré. La figure 3.14 illustre la diffé-
rence entre un diagramme d’activité structuré et un diagramme d’activité non structuré. Ainsi,
nous devons considérer qu’un diagramme d’activités peut être mis en correspondance avec un
processus BPEL seulement si ce diagramme est réalisé de manière structurée, ceci afin de rendre
la transformation entre le diagramme d’activité et BPEL moins complexe. Dans ces conditions,
pour chaque Fork 3 il doit y avoir un Join 4
De plus, chaque processus secondaire créé par un même Fork doit se synchroniser par le biais
d’un même Join avant de rendre la main au processus principal.

Figure 3.14 – (a) un diagramme d’activité non-structuré, (b) un diagramme d’activité structuré.
3. Fork permet la création de plusieurs processus enfants qui sont exécutés en parallèle.
4. Join permet la synchronisation entre plusieurs processus enfants avant de continuer l’exécution du processus.
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 60

Nom Valeur
activity invoque, receive, reply, assign
class une classe liée à une action ou qui contient une
opération participant à une affectation
operation une opération liée à une action
fromOperation une opération d’entrée qui participe à une affec-
tation
toClass une classe qui contient une opération participant
à une affectation
toOperation une opération qui participe à une affectation

Table 3.3 – Les valeurs marquées permettant d’étendre un diagramme d’activité.

Nous utilisons des valeurs marquées pour étendre UML afin de diminuer la distance struc-
turelle et sémantique entre UML et BPEL et de permettre la spécification de correspondances
entre une action d’un diagramme d’activité d’UML et une activité Invoke, Assign, Receive ou
Reply de BPEL, tel qu’introduit dans la section 3.3.1. Nous utilisons aussi des valeurs marquées
pour lier une action à une opération et à une classe. Le tableau 3.2 présente un sous-ensemble
des valeurs marquées utilisées. Dans [Lopes, 2005], nous présentons toutes les valeurs marquées
utilisées .
Les figures 3.15 et 3.16 illustrent respectivement la spécification des correspondances entre
UML (digramme d’activité) et BPEL puis la génération des règles de transformation.
La figure 3.15 illustre (en grisé) l’élément de correspondance Ag2P qui met en relation l’élément
Activity-Graph d’UML avec l’élément Process de BPEL. La figure 3.16 illustre une partie des
règles de transformations générées. La règle Ag2P est associée à l’élément de correspondance de
même nom.

Figure 3.15 – Une spécification de correspondances entre UML et BPEL.

CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 61

Figure 3.16 – La génération des règles de transformations entre UML et BPEL

Une des conséquences de la différence structurelle et sémantique entre le diagramme d’ac-

tivité d’UML et BPEL est le besoin d’utiliser massivement les requêtes en OCL. Ces requêtes
permettent la navigation dans le métamodèle d’UML afin d’obtenir l’information nécessaire cor-
respondant au métamodèle de BPEL. Par exemple, dans la correspondance A2R, l’expression
OCL suivante est nécessaire pour récupérer le partnerLink associé à l’activité receive à partir
d’un ActionState :

Exemple 1 – L’expression OCL associée à la correspondance « A2R »

1 if @ . taggedValue - > size () > 1 then

2 if ( @ . taggedValue - > select ( e | e . type . name = ’ class ’) - > size () > 0 )
3 then
4 @ . taggedValue - > select ( e | e . type . name = ’ class ’) - > first (). getDataValue ()
5 else ’ null ’
6 endif
7 else
8 ’ null ’
9 endif

3.3.4 Transformation M2C : Mise en œuvre du modèle métier

La mise en œuvre finale du modèle métier de l’agence de voyage présenté en section 3.3.1
repose sur une transformation modèle-vers-code. Il s’agit de transformer un modèle décrit selon
le formalisme UML/MOF vers une description textuelle conforme au code source. Comme nous
l’avons évoqué précédemment, l’approche MDA ne considère pas cette partie comme une trans-
formation classique modèle-vers-modèle ; elle la considère plutôt comme une traduction vers un
code final spécifique à une plateforme. Ainsi, le résultat de transformation modèle-vers-code (cf.
figure 3.17) consiste en l’obtention du code source des services Web (les documents WSDL et
BPEL), de J2EE (le code source Java conforme à un modèle Java et au template de JWSDP, et
les fichiers de configuration et déploiement). Nous avons aussi étudié dans nos expérimentations
le langage EDOC pour la partie PIM et la plateforme dotNET pour la partie PSM. Nous présen-
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 62

tons dans ce qui suit des fragments de code pour les services Web et la plateforme J2EE à partir
de la modélisation en UML illustrée par les figures 3.5 et 3.6 de la section 3.3.1. Dans la partie
synthèse en section 3.4, nous reviendrons sur nos différentes expérimentations, en mettant face-
à-face UML et EDOC d’une part, J2EE et dotNET d’autre part. Il est important de noter que
pour toute nos expérimentations nous avons utilisé plusieurs spécifications et différentes versions
de la même spécification. Le tableau 3.3 présente la version de chaque spécification utilisée dans
nos expérimentations et les principales plateformes de mise en œuvre. La figure 3.17 illustre le
principe de la transformation modèle-vers-code.

Techniquement, la transformation modèle-vers-code est obtenue par une requête ATL per-
mettant de déclencher le processus de transformation et de naviguer dans les éléments du modèle,
et par une bibliothèque de fonctions appelées helpers en ATL [Jouault, 2006], permettant la tra-
duction en code source final de tous les éléments du modèle. Dans [Lopes, 2005], nous présentons
en détail la transformation modèle-vers-code.
Les exemples 2 et 3 présentent respectivement des fragments de codes de WSDL et BPEL
générés à partir du modèle UML de l’agence de voyage (diagramme de classe et diagramme
d’activité).

Figure 3.17 – La transformation modèle vers code.

Spécification et plateforme Version Référence

UML 1.4 [OMG, 2001]
EDOC - ECA 1.0 [OMG, 2004]
MOF 1.4 [OMG, 2002a]
XMI 1.2 [OMG, 2002d]
WSDL 1.1 [W3C, 2001]
BPEL 1.1 [Andrews et al., 2003]
J2EE (J2SDK & JWSDP) 1.4.2 & 1.3 [SUN, 2004]
dotNET (IIS) 1.0.3 [MICROSOFT, 2003]

Table 3.5 – Les différentes spécifications et plateformes utilisées dans nos expérimentations.
 CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 63

Exemple 2 – Un fragment de WSDL de l’agence de voyages

1 <? xml version ="1.0" encoding =" UTF -8"? >
2 < definitions name =" S e r v i c e _ t r a v e l a g e n c y " *** >
3 < types > *** </ types >
4 < message name =" findTravel " >
5 ***
6 </ message >
7 < portType name =" Se r vi c eT ra v el Ag " >
8 < operation name =" > findTravel " param eterOr der ="" >
9 < input message = " findTravel " / >
10 < output message =" f i n d T r a v e l R e s p o n s e " / >
11 </ operation >
12 ***
13 </ portType >
14 < binding name =" S e r v i c e T r a v e l A g B i n d i n g " type =" Se rv i ce Tr a ve l Ag " >
15 < operation name =" findTravel " >*** </ operation >
16 ***
17 </ binding >
18 < service name =" S er vi c eT ra v el A g " >
19 < port name =" S e r v i c e T r a v e l A g P o r t " binding =" S e r v i c e T r a v e l A g B i n d i n g " >
20 < soap : address location =" R E P L A C E _ W I T H _ A C T U A L _ U R L " / >
21 </ port >
22 </ service >
23 </ definitions >

Exemple 3 – Un fragment de BPEL généré à partir du diagramme d’activités

1 < process name =" S er vi c eT ra v el Ag " *** >
2 < partnerLinks >
3 < partnerLink name =" S er vi c eT ra v el Ag "
4 p ar tn e rL in k Ty pe =" I T F _ S e r v i c e T r a v e l A g L i n k "
5 myRole =" I T F _ S e r v i c e T r a v e l A g P r o v i d e r " / >
6 ***
7 </ partnerLinks >
8 < variables >
9 < variable name =" i n p u t S e r v i c e T r a v e l A g f i n d T r a v e l "
10 messageType =" I T F _ S e r v i c e T r a v e l A g _ f i n d T r a v e l "/ >
11 ***
12 </ variables >
13 < sequence >
14 < receive name =" R e c e i v e F i n d T r a v e l "
15 partnerLink =" S er v ic eT r av el A g "
16 portType =" I T F _ S e r v i c e T r a v e l A g "
17 operation =" findTr a v e l "
18 variable =" i n p u t S e r v i c e T r a v e l A g f i n d T r a v e l " ***/ >
19 < flow name =" ForkA " >
20 < sequence >
21 < assign name =" A s s i g n I n p u t F l i g h t " >*** </ assign >
22 < invoke name =" CallFlight " partnerLink =" S e rv ic e Ai r Li ne s "
23 portType =" I T F _ S e r v i c e A i r L i n e s "
24 operation =" FindFlight "***/ >
25 </ sequence >
26 < sequence >
27 < assign name =" As singIn putCar " >*** </ assign >
28 < invoke name =" CallCar " partnerLink =" Servi ceCarH ire "
29 portType =" I T F _ S e r v i c e C a r H i r e " operation =" findCar " ***/ >
30 </ sequence >
31 < sequence >
32 < assign name =" A s si ng I np ut R oo m " > *** </ assign >
33 < invoke name =" CallRoom " partnerLink =" ServiceHotel " ***/ >
34 </ sequence >
35 </ flow >
36 < assign name =" AssignReturn " >*** </ assign >
37 </ sequence >
38 </ process >
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 64

3.4 Conclusion, travaux connexes et synthèse

Ce travail a fait l’objet de la thèse de doctorat de Denivaldo Lopes [Lopes, 2005] et d’un
stage de master recherche [Janvier, 2005]. Il a donné lieu à dix (10) publications : 1 publication
de revue [Hammoudi et al., 2005], huit publications dans des conférences et workshops internatio-
naux dont IEEE-EDOC, CAISE et IEEE-ICWS, et une publication dans la conférence nationale
Inforsid.

3.4.1 Positionnement par rapport à l’état de l’art

A ce jour, on peut trouver dans la littérature de nombreux travaux sur l’application de
l’approche MDA à la plate-forme services Web. David Frankel [Frankel, 2002] est sans doute le
premier à avoir proposé une approche MDA pour développer des applications ayant les services
WEB comme plate-forme cible. Un environnement de développement selon l’approche MDA est
alors proposé avec trois composantes :
1. Une architecture 4-tiers
2. La création de modèles métiers à partir du langage UML
3. La spécification des correspondances entre un modèle métier et WSDL.

Frankel a insisté sur la précision et la complètude des modèles métiers PIM pour assurer leurs
transformations sur les plateformes cibles. Par rapport à notre approche, la spécification des
correspondances entre UML et WSDL est proposée par Frankel sur un cas particulier et non de
manière générique entre deux métamodèles. De plus Frankel se limite à UML comme seul langage
pour la définition de la partie métier. Dans [Grønmo et al., 2004] les auteurs s’intéressent à la
composition des services Web, et proposent une méthodologie pour la mise en œuvre de cette
composition. Cette méthodologie repose sur deux types de transformation : la transformation
entre un diagramme de classe UML et un document WSDL (pour des services simples) et la
transformation entre un diagramme d’activité UML et document BPEL (pour des services com-
posites). Ce travail fut un des premiers à proposer la mise en correspondance entre un diagramme
d’activité UML et le langage BPEL. Des valeurs marquées sont alors proposées pour réduire la
distance sémantique entre le diagramme d’activité UML version 1.4 et la langage BPEL. Cepen-
dant, comme pour Frankel, l’approche préconisée par Gronmo utilise exclusivement le langage
UML pour la partie PIM et ne fournit pas des règles de transformations explicites selon un lan-
gage de transformation. Dans [Kath et al., 2004], une infrastructure pour la mise en œuvre de
l’approche MDA pour la plateforme service Web est proposée. Cette infrastructure est constituée
de différents outils qui sont assemblés pour supporter l’approche MDA. Ces outils permettent
de spécifier un métamodèle pour les services Web (WSDL), une correspondance entre EDOC et
WSDL, un métamodèle pour BPEL et une correspondance entre EDOC et BPEL. Cependant,
comme dans l’approche de Gronmo [Grønmo et al., 2004], les règles de transformations visant
à générer automatiquement des documents WSDL ou BPEL à partir de diagramme UML ne
sont pas proposées dans [Kath et al., 2004]. Dans [Baïna et al., 2004], les auteurs proposent une
méthodologie orientée modèle pour le développement de services Web simples et composites,
mais en dehors de l’approche MDA. Ils proposent un framework qui permet la génération auto-
matique de modèles de composition BPEL à partir de spécifications de protocoles fondées sur la
description de service et sur le modèle de composition de Self-Serv [Benatallah et al., 2003], une
variation des statecharts. La méthodologie proposée s’articule autour de trois phases de transfor-
mation : chaque transition est d’abord transformée dans un squelette de processus ; chaque état
est ensuite transformé dans un squelette d’états en ajoutant la transition sous-jacente à l’état ;
finalement, une fois que les squelettes individuels des transitions et des états ont été réalisés, les
squelettes des états sont liés ensemble dans un squelette de processus général selon la topologie de
statechart. Dans [Skogan et al., 2004], les auteurs proposent une méthode pour générer un docu-
ment BPEL à partir du diagramme d’activité UML 1.4. La méthode proposée suit l’approche de
Gronmo en associant des valeurs marquées au diagramme d’activité, afin de réduire la distance
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 65

sémantique avec le langage BPEL. Cependant, comme pour Gronmo, l’approche proposée par
Skogan utilise exclusivement le langage UML pour la partie PIM et ne fournit pas des règles de
transformations explicites conformément à un langage de transformation. Des approches plus ci-
blées vers des domaines d’applications ou à des langages de spécification ont aussi été proposées.
Anzbök et Dustdar [Anzböck et Dustdar, 2005] proposent une approche dirigée par les modèles
permettant de générer semi-automatiquement une spécification BPEL à partir d’un modèle de
workflow dédié au domaine médical. Dans [Mendling et Hafner, 2006], les auteurs mettent en
avant le langage de définition de chorégraphie WS-CDL, et proposent des transformations entre
un modèle général WS-CDL et des composants BPEL impliqués dans une chorégraphie. Cepen-
dant, cette approche ignore la partie orchestration dédiée à l’exécution d’un processus métier à
travers BPEL. Plus récemment, dans [Yu et al., 2007] les auteurs proposent un environnement
de développement complet permettant de générer des document WSDL et BPEL à partir de spé-
cifications métiers en langage EDOC. L’architecture de collaboration des composants (CCA) est
la partie centrale du langage EDOC. De manière similaire à notre approche, les auteurs utilisent
la composante structurelle de CCA pour modéliser les aspects structurels des modèles métiers
PIM, alors que les aspects dynamiques sont modélisés à travers la composante CCA chorégra-
phie. Le standard QVT est utilisé pour la définition des règles de transformations lesquelles sont
écrites manuellement par un expert. Les auteurs de [Yu et al., 2007] rejoignent nos conclusions
[Lopes, 2005] quand ils considèrent que UML est un langage de modélisation général, alors que
EDOC dans la mouvance des DSLs est plus adapté pour la modélisation d’applications Internet
mises en œuvre sur la plateforme services Web. Pour terminer et compléter ce tour d’horizon
des travaux connexes, il nous semble important de présenter succinctement les deux tendances
suivantes :

1. La tendance industrielle des outils CASE dédiés à BPEL

2. L’approche MDA pour SOA et la notation standard BPMN [OMG, 2009].

Les outils CASE tel que IBM Websphere (IBM), Oracle BPEL Process Manager (Oracle), offrent
une interface visuelle conviviale pour la spécification de processus métier avec un langage d’or-
chestration graphique, puis la génération du code en BPEL. Le problème majeur est celui de la
multitude des langages d’orchestrations tel que BPML [Arkin, 2002] et WSCI [Arkin et al., 2002].
Chaque outil supporte un langage d’orchestration propre et de ce fait les concepteurs font face aux
problèmes classiques de migration et d’intéropérabilité entre langages et outils. Notre approche
suivant la démarche MDA permet de palier à ce problème, car le même modèle d’orchestration
définit de manière générique peut être transformé vers différents langages d’orchestration en
appliquant différentes règles de transformation.
La seconde tendance des travaux connexes est celle de l’approche MDA pour le développe-
ment des architectures SOA. Il existe aujourd’hui un large consensus industriel et académique sur
les architectures orientées services comme les architectures logicielles incontournables des futurs
systèmes d’information[Benatallah et al., 2003]. Parmi les axes de recherches autour de SOA, les
méthodologies de développements occupent une place importante [Ramollari et al., 2007] et l’ap-
proche MDA est largement préconisée [Emig et al., 2006]. Dans ce contexte, la notation standard
BPMN de l’OMG est alors souvent utilisée pour la définition des processus métiers et des règles
de transformations vers BPEL sont proposées [Dumas, 2009]. Le problème est que la définition
des règles de transformations est plutôt complexe du fait de la différence entre les deux langages :
les modèles de processus en BPMN sont orientés graphique, alors que dans le langage BPEL la
définition des processus suit une structure de blocs. Ainsi, la définition des règles de transfor-
mations BPMN-BPEL est directe pour certaines classes de BPMN, mais moins évidentes pour
d’autres classes.
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 66

3.4.2 Points forts et limites

Dans ce travail, nous avons proposé l’application de l’approche MDA pour le développement
d’applications Internet sur des plates-formes services Web. Notre démarche a été illustrée par
un exemple d’application e-commerce « agence de voyages ». Nous avons utilisé les formalismes
standard de l’OMG UML et EDOC pour exprimer les modèles neutres indépendants de la plate-
forme(PIM) de l’application « agence de voyages », et nous avons généré notre application sur
trois platesformes cibles (PSM) : services Web (plateforme abstraite), J2EE (Java et JWSDP) et
BPEL (orchestration de services). Nos contributions se situent dans les trois axes de recherche
sur lesquels portent nos travaux : la métamodélisation, les techniques de transformation et le
processus de développement.
Pour la métamodélisation, nous avons mis face-à-face UML et EDOC pour la modélisa-
tion métier (partie PIM) des applications. EDOC dans la mouvance des langages spécifiques au
domaine (DSL) était alors plus adapté et plus proche des services Web que le langage UML
(formalisme plus généraliste). Dès 2005, nous avons constaté que l’IDM à langage unique (UML)
devait perdre sa position centrale au profit de l’IDM à langage multiple (approche DSL). Au-
jourd’hui, il est d’une évidence que le développement à base de modèles ne peut pas se cantonner
exclusivement à une vision orientée UML.
Pour les techniques de transformations, nous avons expérimenté notre approche de génération
des règles de transformations à partir de la spécification de correspondances mise en œuvre
par notre outil MMT4MDE. Une telle expérimentation a été réalisée sur des métamodèles de
grande taille et divers (EDOC, WSDL, BPEL,..) ; elle a montré l’intérêt indéniable d’opérer la
transformation en deux temps et avec des outils adaptés. En effet, l’expert se concentre sur
la tâche de spécification des correspondances entre deux métamodèles en utilisant des outils
adaptés, laissant la partie génération des règles de transformations se faire automatiquement par
l’outil.
Pour le processus de développement, nous avons proposé une méthode permettant le dé-
veloppement d’applications internet sur des plates-formes service Web selon l’approche MDA.
Cette méthode distingue deux phases. La première phase, dite de préparation consiste à générer
des règles de transformation entre un métamodèle dédié au développement métier (PIM) des
applications et un métamodèle décrivant la plateforme cible service Web. La deuxième phase,
dite d’exécution, commence par la spécification d’un modèle métier d’une application basé sur
le métamodèle PIM , puis, en exécutant les règles de transformations, elle génère automatique-
ment l’implémentation de ce modèle métier sur une plateforme spécifique Services Web. Notre
approche de transformation en deux temps est au centre du processus de développement.

Les résultats de nos travaux sur l’approche MDA pour le développement d’applications In-
ternet sur des plates-formes services Web peuvent être résumés comme suit :
– Un outil simple dédié à la spécification des correspondances et à la génération des règles
de transformations.
– Un processus de développement intégrant notre approche de transformation en deux temps.
– Un cas d’étude exhaustif mettant en œuvre des services simples et composites dans le
contexte du Web (orchestration de services) .
– Une solution concrète fondée sur les profils UML (valeurs marquées) pour réduire la dis-
tance sémantique entre métamodèles (BPEL et diagramme d’activité UML).

Nous pouvons cependant regretter quelques points, et nous pourrons donc poursuivre nos inves-
tigations sur plusieurs axes :
– Dans nos expérimentations, nous avons choisi de modéliser la logique métier de notre
exemple illustratif avec une forte granularité. De plus, les spécifications de correspondances
ne prennent pas en compte les corps des méthodes. Ainsi, la plate-forme finale n’a pas pu
être complètement générée à partir de modèles.
– Le métamodèle de correspondance a été validé en utilisant UML, EDOC, les Services
Web, J2EE et dotNET. Cependant, nous ne pouvons pas encore assurer qu’il est suffi-
CHAPITRE 3. MDA ET PLATEFORME SERVICES WEB 67

sant pour être appliqué comme tel avec d’autres formalismes de modélisation et d’autres
plates-formes. Ainsi, une extension de notre métamodèle de correspondance pourrait être
nécessaire.
– La spécification de correspondance entre UML (diagramme d’activité) et BPEL a mon-
tré l’impact de la distance sémantique entre métamodèles dans l’approche dirigée par les
modèles. Nous avons utilisé des profils pour diminuer cette distance, mais cette solution a
introduit d’autres problèmes tels que la complexité des règles de transformation. La version
UML 2.0 plus riche et plus proche de BPEL (le diagramme d’activités) permet de palier à
ce problème.

3.4.3 Liste des publications

Ci-dessous la liste des articles que nous avons publiés sur l’approche MDA et la plate-forme
services Web.

Journal :

Slimane Hammoudi, Denivaldo Lopes et Jean Bézivin

Approche MDA pour le développement des e-applications sur la plate-forme des services Web, Revue d’Ingénierie des
Systèmes d’Information, Special issue on : Web services, theory and applications, Hermes science publications, 2005.

Conférence & Workshop :

Denivaldo Lopes, Slimane Hammoudi, Jean Bézivin and Frédéric Jouault

Generating Transformation Definition from Mapping Specification : Application to Web Service Platform, The 17th
Conference on Advanced Information Systems Engineering (CAiSE’05), LNCS 3520, 309-325, Porto, Portugal, June
13-17, 2005.
Denivaldo Lopes, Slimane Hammoudi, Jean Bézivin and Frédéric Jouault
Mapping Specification in MDA : From Theory to Practice, First International Conference INTEROP-ESA 2005 Inter-
operability of Enterprise Software and Applications, Geneva, Switzerland, February 21 - 25, 2005.

Jean Bézivin, Slimane Hammoudi, Denivaldo Lopes and Frédéric Jouault

B2B Applications, BPEL4WS, Web Services and dotNET in the context of MDA, International Conference on Enter-
prise Integration and Modelling Technology (ICEIMT2004), Canada, Toronto, October 9-11, 2004.

Jean Bézivin, Slimane Hammoudi, Denivaldo Lopes and Frédéric Jouault

Applying MDA Approach for Web Service Platform, The 8th International IEEE Enterprise Distributed Object Compu-
ting Conference (EDOC2004), Monterey, USA, September 20-24, 2004.

Denivaldo Lopes and Slimane Hammoudi

Web Services in the Context of MDA, The 2003 IEEE-International Conference on Web Services (ICWS2003), Las
Vegas, USA, June 23-26, 2003.

Jean Bézivin, Slimane Hammoudi, Denivaldo Lopes and Frédéric Jouault

Applying MDA Approach to B2B Applications : A Road Map, Workshop on Model Driven Development (WMDD2004)
- at ECOOP 2004, Oslo, Norway, June 15, 2004.

Slimane Hammoudi, Denivaldo Lopes.

Etude et application de l’approche MDA à la Plateforme Service Web.
Workshop OCM-SI, Inforsid, Juin 2007, Perros-Guirec, France.

Slimane Hammoudi, Denivaldo Lopes.

Model Driven Architecture for Web Services Platforms : Conceptualization and Prototyping
In 2nd International Workshop on Web Services and Interoperability (WSI’2006), in conjunction with INTEROP’2006
Conference, 20th March 2006, Bordeaux, France.
Chapitre 4

MDA et les applications sensibles au

contexte.

A more thorough science-based approach to informatics and ubiquitous computing is both

necessary and possible. We often think in terms of models, whether formal or not. These
models, each involving a subset of the immense range of concepts needed for ubiquitous
computer systems, should form the structure of our science [Milner, 2006].

4.1 Introduction
Comme annoncé par Weiser en 1991 [Weiser, 1991], les systèmes pervasifs (aussi désignés
comme ubiquitaire) permettant de doter tout objet de la vie quotidienne de capacité de calcul et
de communication, et rendant son intelligence transparente à l’utilisateur, est une réalité de nos
jours. Dans le cadre de l’informatique et en particulier des systèmes d’information, les avancées
dans le domaine des réseaux mobiles sans fil d’une part et des terminaux mobiles d’autre part
ont ouvert une perspective nouvelle pour les systèmes pervasifs. Ainsi, les systèmes d’information
pervasifs [Satyanarayanan, 2001, Saha et Mukherjee, 2003] sont nés de l’ambition de fournir un
accès au système d’information en tout lieu, à tout moment, et sous une forme et avec un contenu
correspondant à la situation de l’utilisateur.
Contrairement au poste de travail traditionnel, l’informatique ubiquitaire se caractérise par
des changements constants de l’environnement. Le plus souvent, ces changements sont dus à
la mobilité de l’utilisateur. Dans le domaine de l’informatique ubiquitaire, une classe d’appli-
cations dites sensibles au contexte a suscité un grand intérêt en particulier depuis l’émergence
des technologies sans fils. Une application sensible au contexte peut capturer dynamiquement
un ensemble d’informations de son environnement ; ces informations représentent un contexte ;
l’application adapte son exécution à ce contexte. Aujourd’hui, les plateformes services Web et
SOA, sont parmi les technologies les plus prometteuses pour la mise en œuvre des applications
distribuées et mobiles sur internet. Les travaux autour des services sensibles au contexte sont
ainsi devenus nombreux ces dernières années [Sheng et Benatallah, 2005, de Farias et al., 2007].
Notre travail s’intéresse à la mise en œuvre de services sensibles au contexte à partir d’une ap-
proche MDA. Ces services utilisent le contexte pour réaliser des activités adaptées et fournir des
informations pertinentes à l’utilisateur sans intervention explicite de sa part. La plupart des ap-
proches existantes discutées dans [Kapitsaki et al., 2009, Truong et Dustdar, 2009] pour la mise
en œuvre des services sensibles au contexte, présentent certaines limitations :
– Les approches proposées dans [Hirschfeld et al., 2008, Vallejos et al., 2007] modélisent et
implémentent ensemble les activités métiers et contextuelles. Ceci limite les possibilités de
réutilisation et de gestion du contexte.
– Les approches proposées dans [Broll et al., 2007, Gu et al., 2005] sont dédiées à des appli-
cations ad-hoc bien ciblées : recherche de restaurant dans une ville, maison intelligente. Le
métamodèle de contexte proposé couvre alors un domaine d’applications restreint et bien
délimité.

68
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 69

– L’approche proposée dans[Sheng et Benatallah, 2005] propose un métamodèle de contexte

qui définit les liens entre les types de contexte, l’application et le mécanisme de sensibilité au
contexte. Le métamodèle proposé est d’un niveau d’abstraction tel qu’il n’est pas possible
de connaître les entités contextuelles de base, afin de dériver des modèles de contexte
conformes au métamodèle.
En partant de ce constat, nous proposons une nouvelle approche, dirigée par les modèles, pour la
mise en œuvre des services sensibles au contexte. Par une séparation explicite entre les activités
métiers et les activités contextuelles nous favorisons la réutilisabilité, l’adaptabilité et la gestion
des informations contextuelles. Ainsi, un modèle de contexte peut être défini indépendamment
de la logique métier d’une application, à différents niveaux d’abstraction, puis tissé par des tech-
niques de transformation adaptées. Notre approche appelée COMODE (COntext aware MOdel
driven DEvelopment) repose sur trois principales techniques :
– La séparation des préoccupations par des modèles (contexte et logique métier).
– Les techniques de transformations pour le tissage du contexte.
– La plateforme service pour la mise en œuvre.
Quatre parties composent notre approche COMODE : (1) l’architecture logiciel COMODE, (2)
le processus de développement COMODE, (3) le métamodèle de contexte et (4) le processus de
transformation permettant de tisser le contexte à la logique métier.

Plan de ce chapitre
Dans un premier temps (section 4.2), nous présentons une vue d’ensemble de la notion de
contexte et des applications sensibles au contexte. Notre approche COMODE à travers sa com-
posante architecture logicielle pour le développement des applications sensibles au contexte sera
aussi présentée dans cette section. La section 4.3 sera dédiée au processus de développement selon
notre approche COMODE. Les principales activités du processus sont présentées, et les différents
modèles produits par ces activités sont discutés. Quatre types d’acteurs impliqués dans le proces-
sus de développement sont identifiés. La section 4.4 présente un métamodèle de contexte pour des
applications mobiles centrées utilisateur. La section 4.5 présente les techniques de transforma-
tions permettant de tisser la logique métier d’une application et le contexte au niveau modèles.
La dernière section de ce chapitre (section 4.6) positionne nos travaux par rapport à l’état de
l’art, situe nos contributions et présente des objectifs qui permettront de poursuivre les travaux.
Nous présentons finalement la liste des publications autour de ce travail.

4.2 Domaine applicatif et approche COMODE

4.2.1 Contexte et sensibilité au contexte
L’informatique sensible au contexte fait référence à des applications qui utilisent des infor-
mations dites contextuelles pour fournir des services adaptés ou des informations pertinentes
à l’utilisateur (ou à d’autres applications) afin d’effectuer une tâche spécifique. Deux notions
importantes et liées caractérisent l’informatique sensible au contexte : qu’est ce que le contexte ?
qu’est ce que la sensibilité au contexte ? Le contexte dans le domaine de l’informatique ubi-
quitaire, a été mentionné pour la première fois, à notre connaissance, par Schilit et Theimer
[Schilit et Theimer, 1994] dans leur projet AMS (Active Map Service). Le contexte est alors
défini de manière spécifique comme portant sur des variables comme la localisation, l’iden-
tité et le profil des utilisateurs, des objets capteurs d’informations ainsi que les changements
dans ces objets. Depuis, plusieurs définitions ont été proposées dans la littérature de l’informa-
tique ubiquitaire [Strang et Linnhoff-Popien, 2004]. La définition la plus citée est celle de Dey
[Dey et Abowd, 1999] :
“Context is any information that can be used to characterize the situation of an entity. An
entity is a person, place, or object that is considered relevant to the interaction between a user
and an application, including the user and applications themselves”.
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 70

Cette définition permet de prendre en compte toutes les entités (abstraites ou concrètes)
considérées comme pertinentes lors d’une interaction entre un utilisateur et une application. Elle
permet de couvrir une large gamme d’applications sensibles au contexte, au delà des applications
mobiles. Cette définition a été réduite dans [Dey et al., 2001] afin de se focaliser sur une classe
d’applications. Les auteurs identifient alors quatre catégories de contextes considérés comme les
plus utilisés d’un point de vue pratique : la localisation, le profil de l’utilisateur, l’activité et enfin
le temps. La notion de sensibilité au contexte est indissociable du contexte. Un système est dit
sensible au contexte s’il peut récupérer, interpréter et utiliser des informations caractérisant le
contexte et adapter sa réponse en fonction de ces informations et de l’activité exécutée. On dis-
tingue clairement aujourd’hui entre les applications qui utilisent le contexte de manière statique,
comme par exemple un service de météo qui aura besoin d’informations de localisation et de
données temporelles pour produire un bulletin, d’autres applications qui adaptent dynamique-
ment leur comportement en fonction du contexte. L’utilisation statique du contexte n’implique
pas une modification du comportement du système.
Dey et Abowd [Dey et Abowd, 1999] introduisent une autre définition de la sensibilité au
contexte dans laquelle ils insistent sur l’utilisation du contexte et du comportement du système.
Les auteurs estiment qu’un système est sensible au contexte s’il utilise le contexte pour fournir
des informations pertinentes et/ou des services à l’utilisateur, où la pertinence dépend de la tâche
de l’utilisateur :
“a system is context-aware if it uses context to provide relevant information and/or services
to the user, where relevance depends on the user’s task”.

Dey et Abowd, expliquent comment utiliser le contexte et proposent une classification des ca-
ractéristiques des applications sensibles au contexte en s’appuyant sur les travaux de
[Schilit et Theimer, 1994, Pascoe, 1998]. Ils définissent trois catégories de fonctionnalités :
– les informations et les services qui peuvent être présentés à l’utilisateur dans le contexte
courant. Ceci inclut la sélection d’informations de proximité ("où est la banque la plus
proche ?") et de services (interface modifiable) ;
– l’exécution automatique d’un service dans un certain contexte. Ceci inclut les actions ini-
tiées par des déclencheurs de contexte ("context triggered actions"), par exemple un télé-
phone qui change son volume d’écoute en fonction du bruit ambiant ;
– l’étiquetage du contexte à l’information pour une restitution ultérieure.

Comme il a été observé et discuté dans plusieurs travaux [Chaari et al., 2007, Keidl et Kemper, 2004,
Henricksen et al., 2005], un système sensible au contexte à plusieurs composants, tel que un cap-
teur de contexte, stockage du contexte, raisonneur du contexte et consommateur du contexte,
pour ne citer qu’une partie. Ces composants sont logiquement séparés des applications qu’ils
supportent. Ainsi, dans [Truong et Dustdar, 2009], les auteurs proposent une séparation expli-
cite entre :
– Les services sensibles au contexte et les applications : ils utilisent les informations du
contexte et les outils supportés, afin de réagir "intelligemment" (être sensible au contexte).
– Les composants de la sensibilité au contexte : ils aident les applications et les services en
captant et fournissant les informations du contexte. Des exemples de ces composants sont
les capteurs, les enregistreurs de contexte et les moteurs de raisonnement sur le contexte.

Ainsi, la séparation entre la détection et l’utilisation du contexte est nécessaire afin d’améliorer
l’extensibilité et la réutilisabilité dans le système. Dans cette perspective, la figure 4.1 propo-
sée dans [Baldauf et al., 2007] illustre une architecture en couches pour les systèmes sensibles
au contexte, permettant de séparer les parties détection et utilisation, en y ajoutant la partie
interprétation et raisonnement. Une description détaillée de ces différentes couches est présentée
dans [Baldauf et al., 2007].
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 71

Figure 4.1 – Architecture conceptuelle pour les systèmes sensibles au contexte

4.2.2 COMODE : principe et architecture

L’approche COMODE de mise en œuvre de services sensibles au contexte repose sur le prin-
cipe de la séparation des préoccupations, qui est appliqué dès la phase de modélisation concep-
tuelle (PIM). Les deux principales préoccupations à savoir la logique applicative (ou métier) et
le contexte sont représentées par des modèles indépendants. La figure 4.2 illustre à gauche les
principes et les principaux composants de notre approche, et à droite l’architecture COMODE
composée de 5 vues.

Figure 4.2 – Développement de sevices sensibles au contexte dans COMODE

L’architecture COMODE est composée de cinq vues dédiées au développement d’applications

sensibles au contexte selon une approche MDA. Cette décomposition en vues suit l’approche du
langage standard EDOC-ECA [OMG, 2004] et du modèle de référence des systèmes distribués
ouvert RM-ODP. Ainsi, nous avons proposé conformément à la figure 4.2 ces vues pour traiter
les différentes exigences liées au développement des applications sensibles au contexte de manière
indépendante, à savoir : la définition du contexte, sa représentation, le tissage du contexte avec
la logique métier et son adaptation.
Dans la figure 4.2, les vues métiers, contexte et composition, sont exprimées par des mo-
dèles PIM, c’est-à-dire des modèles sans aucune considération technologique. La vue métier se
focalise sur la logique métier d’une application, ses fonctionnalités indépendemment des aspects
technologiques et des informations contextuelles. La vue contexte est responsable de la définition
des informations contextuelles, de leurs captures, de leurs représentations et interprétations. La
vue « composition » permet de lier la logique métier et la logique du contexte. Ainsi, la logique
sera enrichie par les informations contextuelles, qui permettront de réaliser l’adaptation en phase
d’exécution. Les vues « adaptation » et « service » sont de niveau PSM, c’est-à-dire dépendantes
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 72

de la plateforme technologique finale. Elles reposent sur la vue ingénierie de EDOC-ECA, et

ainsi, elles permettent de spécifier les détails de la plateforme finale. Cependant, il est important
de noter qu’au niveau PSM, nous distinguons la plateforme abstraite (par exemple la plateforme
service) d’une plateforme concrète qui est spécifique à une technologie (J2EE ou dotNET).
Dans ce travail, nous nous intéressons à la «vue contexte» et à la vue «composition». De plus,
nous proposons une méthodologie qui guide un concepteur lors du développement d’applications
sensibles au contexte. Cette méthodologie illustre la mise en œuvre des différentes vues par les
modèles et les techniques de transformations. Ainsi, dans les sections qui suivent nous allons
présenter :
– Une méthodologie illustrant les activités et les utilisateurs impliqués dans le développement
d’une application sensible au contexte.
– La définition d’un métamodèle permettant de préciser notre domaine de contexte pour des
applications mobiles centrées utilisateur.
– Une technique de transformation permettant d’intégrer le contexte à la logique applicative
à partir des modèles.

4.3 Processus de développement COMODE

Comme noté dans [Picek, 2009], aujourd’hui, une étude détaillée des méthodologies de déve-
loppement de logiciels, mènerait inévitablement aux questions suivantes : comment l’approche
MDA s’insère dans les méthodologies existantes ? Est-ce que ces méthodologies peuvent êtres
utilisées pour un développement de type MDA, ou, a-t-on besoin de développer de nouvelles mé-
thodologies adaptées à l’approche MDA ? A cette question, nous avons répondu dans le chapitre
2 par la proposition de [Kleppe et al., 2003] illustrant comment le processus de développement
classique de logiciel est adapté à MDA. Cependant, dans notre travail les spécificités des applica-
tions sensibles au contexte doivent êtres prises en considération durant les différentes phases de
développement. Ces spécificités semblent (a priori) en contradiction avec l’approche MDA. Dans
un cas, l’adaptabilité du système durant l’exécution est le premier objectif, alors que l’approche
MDA relève le niveau d’abstraction, mettant l’accent sur les phases initiales de développement,
spécifiquement à partir de métamodèles et modèles. Nous montrons dans cette section comment
la méthodologie traditionnelle pour le développement de logiciel peut être adaptée pour le déve-
loppement des applications sensibles au contexte selon une approche MDA. La figure 4.3 illustre
les activités de la méthodologie COMODE et les différents utilisateurs ainsi que leurs places
dans cette méthodologie. Cette figure situe COMODE d’une part par rapport au processus de
développement de logiciel traditionnel (Picek, 2009), et d’autre part par rapport au processus
de développement MDA (Kleppe, 2003). Le processus de développement MDA présenté dans
[Kleppe et al., 2003] est illustré au centre de la figure 4.3 ; il n’est pas différent du processus
classique de développement de logiciel. Les mêmes activités sont identifiées et considérées dans
le cycle de développement. Une des principales différences réside dans les artefacts créés durant
le processus. Ce sont des modèles formels dans le cas du processus MDA. Comme nous en avons
discuté précédemment, PIM, PSM et le code final sont les trois principaux modèles dans MDA
et, en conséquence, dans une approche MDD.
Afin de renforcer le principe de la séparation des préoccupations, nous distinguons quatre
catégories d’utilisateurs dans le développement de services sensibles au contexte. Chaque acteur
est associé à une ou plusieurs activités dans le processus de développement. Voici une présentation
de ces différents acteurs et leurs activités :
– concepteur de logique métier : personne qui se concentre sur la logique métier et la définition
d’un modèle PIM. À partir du métamodèle choisi pour la logique métier (UML, EDOC,...),
cet utilisateur définit son modèle d’application en se focalisant uniquement sur la logique
métier, sans considération technologique. Dans cette partie, l’utilisateur peut, par exemple,
spécifier différents diagrammes UML, qui mèneront à un diagramme de classe final prêt à
une traduction pour une plateforme finale ;
– concepteur du contexte : personne qui se focalise sur la définition du modèle de contexte à
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 73

Figure 4.3 – Processus de développement et principaux utilisateurs dans COMODE

partir du métamodèle de contexte. Le principal objectif ici est celui de définir les données
qui permettent de mettre en œuvre la sensibilité au contexte durant l’exécution ;
– concepteur de la sensibilité au contexte : deux principales activités sont de la responsa-
bilité de cet utilisateur. La première activité consiste en la préparation du modèle CPIM
(Contextual Platform Independent Model) obtenu à partir des techniques de transforma-
tions entre les deux modèles précédents. À ce stade le modèle PIM est complété par les
données contextuelles, mais sans leur partie sensibilité au contexte qui, elle intervient du-
rant l’exécution. Ainsi, la seconde activité de cet utilisateur est de préparer le modèle
CPSM (Contextual Platform Specific Model), qui intègre, d’une part, les caractéristiques
de la plateforme cible (plateforme service) et d’autre part, le mécanisme de sensibilité au
contexte qui assure l’adaptabilité à l’exécution ;
– l’utilisateur final : personne qui utilise un dispositif mobile «n’importe où et n’importe
quand» pour invoquer des services. Le système, de manière transparente, fournit des infor-
mations pertinentes et/ou accomplit des services en utilisant le contexte.

4.4 Un métamodèle de contexte

Dans l’approche dirigée par les modèles, l’utilisation des métamodèles permet d’assurer, non
seulement, une syntaxe précise à une représentation commune à différents modèles, mais aussi
une sémantique propre à un domaine d’application. Nous nous sommes intéressés dans nos tra-
vaux aux applications mobiles centrées utilisateurs. Dans la littérature sur la modélisation du
contexte à partir d’une approche MDA, différents métamodèles de contexte ont été proposés.
Certains sont d’un niveau d’abstraction ne permettant pas de connaitre les entités contextuelles
de base [Sheng et Benatallah, 2005, de Farias et al., 2007]. D’autres sont spécifiques à un type
d’application particulier tel que l’environnement d’une maison inttelligente [Gu et al., 2005] ou à
un domaine d’application particulier tel que celui du tourisme [Cappiello et al., 2006], ou encore
plus spécifiquement à la recherche intelligente d’un restaurant [Broll et al., 2007].
Nous proposons une définition large tout en restant reliés à notre domaine d’étude de sorte
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 74

Figure 4.4 – Un métamodèle de contexte pour des applications mobiles

que cette définition soit utile pour d’autres gammes d’applications mobiles.
Nous considérons que le contexte est un ensemble d’informations structurées en trois dimen-
sions : (i) l’acteur qui est la personne entité centrale dans le système, (ii) l’environnement dans
lequel l’acteur évolue et (iii) le dispositif informatique utilisé par l’acteur pour faire appel ou
bien invoquer des services capturant les différents états de l’environnement.
La figure 4.4 illustre notre métamodèle de contexte en utilisant le langage UML. Une définition
plus complète de ce métamodèle à partir des ontologies est présentée dans [Vale et Hammoudi, 2009b].
Nous avons alors utilisé la spécification ODM de l’OMG[OMG, 2006b]. La figure 4.4 identifie et
regroupe les principales entités contextuelles génériques qui seront prises en compte dans la mo-
délisation d’une application mobile sensible au contexte. Le métamodèle proposé est composé de
six entités contextuelles génériques (grisées sur la figure 4.4), et quatre entités spécifiques à cer-
taines des applications mobiles. La classe ContextView regroupe toutes les entités contextuelles
impliquées dans une application. Elle est identifiée par un nom et elle possède deux types de
relations : l’agrégation et une association simple. La première relation précise qu’une instance
de ContextView est composée de plusieurs entités contextuelles impliquées dans une application
sensible au contexte. La seconde relation belongsTo exprime l’historique des entités contextuelles.
Cette information peut être intéressante pour la définition des vues de contextes futurs. La se-
conde entité générique du métamodèle est ContextEntity. Celle-ci est spécialisée en trois entités
génériques : Actor, ComputationalEntity et Environment.
– Actor : l’acteur peut être une personne ou bien un objet qui possède un état et un profile. Il
évolue dans un environnement et il utilise un dispositif informatique mobile pour solliciter
des services. L’état d’un acteur peut être en mouvement ou bien fixe.
– ComputationalEntity : c’est le dispositif informatique mobile utilisé par l’acteur pour ac-
céder aux services et capturer les informations contextuelles à partir de l’environnement.
Le dispositif mobile dispose des informations concernant son type qui peut être (PDA,
ordinateur portable, téléphone mobile, etc), l’application, le réseau, etc.
– Environment : l’environnement regroupe toutes les informations qui entourent l’acteur et
son dispositif mobile et qui peuvent être importantes pour l’application. Ces informations
classées sous différentes catégories : (i) spatiales (la localisation, la ville, l’immeuble, le
bureau . . .), (ii) temporelles (l’heure, la date, la saison . . .), (iii) climatique (température,
type du climat . . .).
L’entité Profile correspond au profil de l’utilisateur, il est important de la mentionner dans ce
métamodèle en raison de son rôle capital dans toute application mobile centrée utilisateur. En
outre le profile est très attaché à l’entité acteur. Il contient les informations qui le décrivent. Un
acteur peut avoir un profil dynamique et/ou statique. En effet, le profil statique regroupe les
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 75

Figure 4.5 – Les modèles et les techniques de transformations dans COMODE

informations pertinentes pour toute application mobile sensible au contexte comme la date de
naissance, le nom ou le sexe de l’utilisateur. A l’opposé, le profil dynamique inclut des informa-
tions personnalisées qui dépendent de l’acteur. Le profil dynamique d’un utilisateur peut être
ses objectifs, ses préférences, ses intentions ou bien ses contraintes. Par exemple l’objectif d’un
touriste lors de la recherche d’un restaurant, c’est de diner. Le profil dans ce cas peut donner des
informations concernant ses habitudes culinaires.

4.5 Le processus de transformation

La séparation des préoccupations (métier et contexte) est mise en avant au niveau modèle dans
notre approche, où les modèles de contexte sont définis de manière indépendante de la logique
applicative, à différents niveaux d’abstraction, puis tissés par des techniques de transformations
adaptées. Deux types de transformation sont considérées. Le premier type de transformation
désigné par transformation paramétrée permet de tisser le contexte à la logique applicative au
niveau modèle. Nous avons étudié cette transformation dite paramétrée [Vale, 2009], qui n’est
pas suffisamment explorée dans l’application de l’IDM et pour laquelle il n’y a pas, à ce jour, de
langage de transformation dédié. Ainsi, le tissage du contexte avec le modèle métier PIM permet
d’obtenir un modèle CPIM (Contextual Platform Independent Model). Le modèle CPIM est le
résultat du modèle métier enrichi par des données de contexte, permettant d’assurer l’adaptabilité
à l’exécution. Le second type de transformation est celui de la composition de modèles. La
composition de modèle est un processus qui prend deux ou plusieurs modèles en entrée, les
intègre au travers d’une opération de composition et produit un modèle composite en sortie.
La figure 4.5 illustre les différents modèles et techniques de transformations pour l’obtention
d’un modèle CPIM et sa transformation sur une plateforme cible en modèle CPSM (Contextual
Platform Specific Model). Il est à noter que cette dernière transformation CPIM - CPSM relève
de la technique classique de la transformation conformément à notre approche de transformation
discutée au chapitre 2.
Nous allons dans la suite présenter les deux techniques de transformations permettant de tisser
le contexte à la logique métier au niveau des modèles. Nous illustrerons ensuite la transformation
paramétrée sur un exemple concret.
.

4.5.1 Transformation paramétrée pour le tissage du contexte.

La transformation paramétrée a été initialement proposée par David Frankel [Frankel, 2002]
où la notion de paramètre est utilisée pour proposer différentes options dans le processus de
transformation. Par exemple il est possible de définir, au travers de paramètres, si l’attribut
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 76

d’une classe sera transformé vers un attribut XML ou vers un élément XML. Ainsi, la technique
de transformation paramétrée repose sur l’utilisation des paramètres qui serviront de balises
dans le processus de transformation. Nous l’avons adaptée à notre problématique en considérant
les paramètres comme les entités (attributs, opérations, classes,...etc) du modèle métier (PIM)
représentant le contexte. Ces entités seront complétées (et/ou enrichies) par le modèle de contexte
lors du processus de transformation. Un mécanisme de tissage est alors mis en œuvre entre le
modèle métier PIM et le modèle de contexte. La figure 4.6 illustre le principe de la transformation
paramétrée adaptée à notre problématique. Le modèle PIM est développé indépendamment du
contexte, puis durant la transformation il est enrichi par les informations contextuelles utilisées
comme des paramètres : profiles, dispositif mobile, localisation.

Figure 4.6 – Principe de la transformation paramétrée

Afin de mettre en œuvre le principe de la transformation paramétrée, nous avons introduit

deux mécanismes permettant, d’une part, d’identifier les éléments du modèle métier PIM repré-
sentant le contexte et, d’autre part, de faciliter le processus de substitution de ces éléments par
les éléments correspondants issus du modèle de contexte. Ces deux mécanismes sont :
– le marquage des éléments de type contexte
– les templates
Le marquage permet d’identifier les éléments représentant le contexte (les paramètres). Ce faisant,
nous simplifions la tâche de la définition des règles de transformations et celle du moteur de
transformation. Sans les marques, il serait nécessaire de parcourir tous les éléments des deux
modèles, PIM et modèle de contexte, afin d’identifier les éléments en commun. Nous avons choisi
<#> comme marque d’élément paramétrable. Tous les éléments représentant le contexte seront
préfixés par ce symbole.
Le template est un mécanisme général de généricité permettant de paramétrer un élément
UML. Paramétrer un élément consiste à identifier l’ensemble des ses paramètres formels (Tem-
plateParameter ) qui représentent la signature du template (TemplateSignature). Dans UML 2.0
[OMG, 2006a], on ne peut définir comme paramètre que les éléments dits paramétrables c’est-
à-dire qui héritent de la métaclasse abstraite ParameterableElement. Comme exemple de ces
éléments on trouve les opérations, les attributs et les classifieurs. Les templates permettent de
définir de manière générique les éléments représentant le contexte dans le modèle PIM, puis
lors du processus de transformation (tissage), ces éléments seront substitués par leurs définitions
spécifiques.
La figure 4.7 présente l’exemple d’une classe template et le marquage des éléments ;
Les paramètres du template sont représentés dans un rectangle en pointillé superposé à l’élé-
ment templateable. Ce rectangle contient la liste formelle des paramètres du template. Une présen-
tation complète des mécanismes de marquage et de template pour la transformation paramétrée
est faite dans [Vale, 2009]. Ainsi, dans notre approche COMODE, l’objectif de la transforma-
tion paramétrée est de tisser le contexte à la logique métier de l’application. Cela veut dire
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 77

que certains éléments du contexte seront tissés au modèle PIM pour créer le modèle CPIM.
Comme pour le modèle métier PIM, les éléments du modèle de contexte peuvent être marqués et
sont templateables. La figure 4.8 schématise le processus de marquage lors de la transformation
paramétrée.

Figure 4.7 – Marquage et templates pour la transformation paramétrée

Figure 4.8 – Processus de marquage et tissage dans la transformation paramétrée

Concrètement, une fois que les modèles PIM et contexte sont marqués, la transformation
paramétrée est réalisée en deux processus : un processus de matching et un processus de sub-
stitution. Le processus de matching permet d’aligner les éléments du modèle PIM avec ceux du
contexte. Le processus de substitution permet d’enrichir les éléments du modèle PIM représen-
tant le contexte par leur définition issue du modèle de contexte. De manière très simplifiée, la
technique de transformation paramétrée peut être intuitivement définie par la formule suivante :

Transformation paramétrée = Matching +Substitution

4.5.2 Transformation par composition de modèles

La composition est un concept fondamental du génie logiciel. Il concerne la construction des
systèmes à partir d’unités logicielles séparées. Ce concept n’est pas nouveau. Il est utilisé dans
plusieurs approches du génie logiciel [Nierstrasz et Meijler, 1995]. Dans le cadre de l’IDM, la
composition de modèle est un thème de recherche nouveau. Cependant, différentes approches
de composition de modèles commencent à émerger et des prototypes commencent à voir le jour
[Nguyen, 2008]. Notre objectif ici n’est pas d’étudier les différentes approches de composition.
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 78

Figure 4.9 – Vue simplifiée d’un processus de composition de modèles

Nous allons plutôt présenter une approche qui est adaptée à notre problématique de composition
d’un modèle métier PIM et un modèle de contexte. Nous allons commencer dans la section
suivante (4.5.2.1) par une présentation succincte de la composition de modèles, ensuite dans la
section (4.5.2.2), nous présenterons l’approche de composition adaptée pour notre problématique.
La section (4.5.2.3) positionne cette approche de composition de modèles par rapport à notre
proposition de transformation paramétrée.

4.5.2.1 Composition de modèles

Plusieurs définitions informelles ont été proposées pour la composition de modèles, et les deux
suivantes sont assez représentatives :
"Model composition is an operation that combines two or more models into a single one"
[Fabro et al., 2005]

"Model composition in its simplest form refers to the mechanism of combining two models
into a new one" [Akehurst et al., 2007]

Ces deux définitions peuvent être traduites schématiquement par la figure 4.9. Ainsi, la com-
position de modèles peut être définie comme un processus qui prend deux ou plusieurs modèles
en entrée, les intègre au travers d’une opération de composition et produit un modèle composite
en sortie.
Le schéma de la figure 4.9 est bien sur incomplet. En effet, aucune hypothèse n’est exprimée
sur les modèles en entrée, en sortie, ni sur l’opération de composition. En réalité, chaque approche
précise les hypothèses pour le processus de composition adopté. Ainsi, une classification des
différentes approches de composition est présentée dans [Nguyen, 2008] selon les quatre volets
suivants :
– classification selon les caractéristiques des modèles en entrée ;
– classification selon les caractéristiques des modèles en sortie ;
– classification selon les caractéristiques de l’opération de composition ;
– autres caractéristiques de composition.
Six environnements dédiés à la composition de modèles ont été proposés dans l’état de l’art.
Nous les listons ci-dessous par ordre chronologique :
- Eclipse Modeling Framework [Steinberg et al., 2009].
- Kompose [Fleurey et al., 2007].
- Generic Modeling Environment [Molnar et al., 2007].
- Epsilon Merging Language [Kolovos et al., 2006].
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 79

Modélisation Orientée Aspect Gestion de Modèle Métamodélisation

Kompose Atlas Model Weaver, Epsilon Eclipse modeling Framework,
Merging Language Generic Modeling
Environment, Xactium,
XMF/XMF-Mosaic.

Table 4.2 – Les approches de composition de modèles et domaines d’applications

- Atlas Model Weaver [Bézivin et al., 2006].

- Xactium XMF/XMF-Mosaic[Clark et al., 2004]
Le tableau 4.2 présente une classification succincte de ces approches selon leur domaine d’appli-
cation privilégie.
Parmi ces différentes approches de compositions, l’approche basée sur la signature mise en
œuvre par l’outil Kompose [Fleurey et al., 2007] est la plus proche de notre problématique de
tissage du modèle de contexte et du modèle métier. Cette approche a été initialement proposée
dans le cadre de la modélisation orientée aspect, pour le tissage des aspects au niveau des modèles.
Dans la section suivante, nous allons discuter des points clés de cette approche puis nous la
situerons par rapport à la transformation paramétrée présentée dans la section précédente.

4.5.2.2 Composition de modèles basée sur les signatures

L’approche de composition de modèles basée sur les signatures [Fleurey et al., 2007] repose
sur une stratégie de fusion des modèles et est réalisée en deux phases : une phase de comparaison
et une phase de fusion.
- Phase de comparaison :
Cette phase est basée sur la comparaison des signatures des éléments à fusionner. Une si-
gnature est un ensemble de valeurs extraites de certaines propriétés de l’élément du modèle.
L’ensemble des propriétés du type de l’élément définit le type de la signature. Par exemple, le
type de la signature d’une classe UML consiste en des propriétés « nom » et « EstAbstraite » ;
la signature d’une classe concrète, par exemple Etudiant, sera nom = Etudiant, EstAbstraite =
faux.
- Phase de fusion :
Les éléments du modèle, qui ont la même valeur de signature, vont être fusionnés. Dans le
cas contraire, ils seront simplement ajoutés au modèle composé résultant de la composition.
Pendant la phase de fusion, il est probable que des conflits surgissent. En effet, si deux
éléments correspondent en signatures (deux classes de même nom) mais diffèrent par certaines
autres propriétés (par exemple l’une est abstraite, l’autre non), alors cette approche basée sur les
signatures utilise des directives de composition pour forcer ou empêcher la fusion des modèles.
Le concept central du langage de spécifications de composition est le composeur (composer ).
Un composeur représente une opération de composition effectuée sur deux modèles. Il rassemble
toutes les directives de composition. La structure d’un composeur comprend : deux modèles en
entrée (un modèle de base et un modèle aspect), le nom du modèle composé en sortie et les
directives de composition. Il existe deux types de directives de composition : directives préfusion
et directives postfusion. Les directives préfusion sont appliquées sur les modèles avant de les
composer. Les directives de postfusion sont appliquées sur le modèle résultat. Les directives pré-
fusion telles que le renommage, la suppression ou l’ajout d’éléments sont utilisées sur les modèles
en entrée afin de forcer ou d’empêcher la fusion. Par exemple, dans le cas des classes abstraites
et non abstraites, les directives peuvent forcer la classe fusionnée finale à prendre la valeur "Es-
tAbstraite = faux ". Les directives postfusion telles que l’ajout (Add), la suppression (Remove), la
création (Create), la mise à jour (Set) permettent d’assurer la fiabilité et la cohérence du modèle
final fusionné.
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 80

4.5.2.3 Transformation paramétrée versus composition de modèles

La technique de composition de modèles basée sur les signatures est purement syntaxique,
les éléments possédant le même nom et la même signature sont considérés comme identiques.
Cette approche à été proposée dans le cadre de la modélisation orientée aspects [Fleurey, 2006] et
c’est tout naturellement qu’elle se trouve adaptée à notre problématique de tissage du modèle de
contexte au modèle métier. En effet, comme nous en avons discuté dans [Monfort et Hammoudi, 2010],
les modèles d’aspects permettent de représenter les différents contextes d’exécutions d’un modèle
métier. Un modèle de contexte précise les informations contextuelles. A partir de ces informa-
tions, un modèle d’aspects permet de mettre en œuvre l’adaptabilité à l’exécution du modèle
métier. Malgré la simplicité de cette technique de composition de modèles basée sur les signa-
tures, elle n’est adaptable qu’à des modèles simples de petite taille et ayant des éléments de même
sémantique représentés par des signatures similaires. Notre proposition de la transformation pa-
ramétrée permet de diriger la transformation à travers l’usage des paramètres et des templates.
En plus des templates, nous avons proposé dans [Vale, 2009] l’utilisation des ontologies pour
renforcer les similitudes sémantiques des éléments des deux modèles PIM et contexte. La trans-
formation paramétrée permet d’enrichir le modèle métier par les informations contextuelles issues
du modèle de contexte. Un métamodèle de la transformation paramétrée ainsi que l’algorithme
générique exprimé en OCL de cette transformation sont présentés dans [Vale, 2009]. La section
suivante illustre la transformation paramétrée sur un exemple.

4.5.3 Exemple illustratif de la transformation paramétrée

Afin d’illustrer la technique de la tranformation paramétrée permettant le tissage du contexte
au modèle métier, nous allons prendre un exemple d’un fournisseur de services nommé FunFin-
der. Cellui-ci permet à un utilisateur mobile de trouver des attractions dans une ville selon deux
principes :

– l’utilisateur ne spécifie que le service souhaité (exemple : un Restaurant)

– le système utilise de manière transparente toutes les informations pertinentes (contexte)
afin de donner à l’utilisateur les réponses les plus adaptées.

La figure 4.10 présente un exemple mettant en œuvre la technique de transformation paramé-

trée. Trois modèles sont présentés : le modèle métier (PIM) du fournisseur de service FunFinder,
le modèle de contexte au centre et enfin le modèle fusion CPIM. Dans cet exemple, nous nous
interessons particulierement à la recherche d’un restaurant pour un utilisateur mobile. Initia-
lement, dans le modèle métier, un service de salutation greeting qui salue l’utilisateur avec un
message de bienvenue dans sa langue native, est invoqué. Ensuite, l’utilisateur invoque le service
RestaurantsFinder pour la recherche d’un restaurant. La méthode findByContext ( ), dont les
paramètres sont précisés dans le modèle CPIM, permet de rechercher un restaurant selon deux
paramètres contextuels : les préférences culinaires de l’utilisateur et sa localisation géographique
à l’instant de la demande de recherche d’un restaurant. Le modèle de contexte regroupe les entités
contextuelles pertinentes pour le service recherche d’un restaurant. Nous avons donc un acteur
représentant l’utilisateur mobile avec d’une part, son profile limité à ses préférences culinaires, et
d’autre part son numéro de téléphone mobile permettant de donner à tout moment la localisation
géographique de l’acteur.
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 81

Figure 4.10 – Exemple de la transformation paramétrée

CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 82

Pour préparer le processus de transformation paramétrée afin de tisser le modèle de contexte

à la logique métier, le concepteur de la logique métier et celui du contexte doivent mettre à jour
respectivement le modèle métier PIM et le modèle de contexte conformément à la figure 4.10
comme suit :
– dans le modèle métier, les éléments représentant le contexte doivent être marqués et si
nécessaire, un template permet de préciser leurs types génériques. Dans notre exemple le
concepteur marque la classe person comme la principale entité contextuelle et précise à
travers le template que cette classe a pour type générique user.
– dans le modèle de contexte, toutes les entités contextuelles pertinentes pour le service
recherche d’un restaurant sont marquées. Ainsi, l’acteur sollicitant la recherche d’un res-
taurant, son profile culinaire et sa localisation géographique sont tous marqués. Le template
associé à la classe Actor permet de préciser le type générique de cette classe. La classe Mo-
bilePhone n’a pas été marquée car sa présence dans le modèle fusion n’a pas d’intérêt direct
dans le processus de recherche d’un restaurant. C’est la classe location qui intervient dans
la recherche d’un restaurant.
Le processus de transformation paramétrée prend en entrée les deux modèles PIM et contexte
et exécute une opération de matching entre ces deux modèles. La classe person (marquée) du
modèle PIM se trouve directement alignée avec la classe Actor du modèle de contexte car elles ont
le même type générique user. A partir de cet alignement, le modèle fusion CPIM est obtenu avec
l’ensemble des classes intervenant dans le service recherche d’un restaurant. Les paramètres de la
méthode findByContexte (kind :FoodPreference et area :Location) de la classe RestaurantsFinder,
se trouvent liés aux deux classes FoodPreference et Location, afin de trouver les restaurants en
fonction des données de ces deux classes.

4.6 Conclusion, travaux connexes et synthèse

Ce travail a fait l’objet de la thèse de doctorat de Samyr Vale [Vale, 2009] et de deux stages
de master recherche [Lajili, 2009] et [Khelifa, 2010]. Il a donné lieu à douze (12) publications
scientifiques : 2 publications dans deux revues internationales , six publications dans des confé-
rences internationales et nationales et quatre publications dans des workshops. La section 4.6.1
positionne notre travail par rapport à l’état de l’art, la section 4.6.2 situe les points forts de notre
travail et décline ses limites et les travaux futurs, la section 4.6.3 présente la liste des publications
autour de ce travail.

4.6.1 Positionnement par rapport à l’état de l’art

Durant les dernières années les techniques de développements dirigées par les modèles ont
été appliquées avec succès dans différents projets. Ceci a motivé l’utilisation de ces techniques
pour le développement des applications sensibles au contexte et plus particulièrement les ser-
vices sensibles au contexte. Le langage de modélisation utilisé majoritairement est le langage
UML. Les techniques de profile et métamodélisation permettent l’extensibilité pour la prise en
compte de la sémantique des domaines d’applications et des plateformes de mise en œuvres. Au
delà d’UML d’autres formalismes ont été proposés pour la modélisation du contexte. Une étude
détaillée des différents formalismes dédiés à la représentation du contexte est présentée dans
[Strang et Linnhoff-Popien, 2004]. Sheng et Benatallah [Sheng et Benatallah, 2005] ont proposé
l’une des premières approches ContextUML pour la prise en compte du contexte à partir d’une
approche dirigée par les modèles et la mise en œuvre sur une plateforme services. Les auteurs
proposent un métamodèle pour des applications mobiles mises en œuvre sur des plateformes
services web. Le métamodèle se focalise sur les liens entre les types de contexte, les services et
le mécanisme de sensibilité au contexte. ContextUML peut être utilisé pour définir (i) l’affecta-
tion des paramètres associés à des opérations contextuelles et (ii) la gestion de la sensibilité au
contexte pour les services. L’approche ContextUML a été étendue dans [Prezerakos et al., 2007]
dans un but de mieux séparer dès la conception la partie modélisation du contexte de la par-
tie service métier. En plus du diagramme de classe, le diagramme d’activité UML est utilisé
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 83

pour modéliser le flux des services. Les techniques de transformations de l’approche MDD et la
programmation orientée aspects sont utilisés pour la mise en œuvre finale sur une plateforme
services. Les apports de l’intégration entre l’approche MDD et la programmation par aspects
sont discutés dans [Carton et al., 2009], et représentent un des axes de nos travaux en cours et
futurs. Le chapitre 6 dédié aux perspectives de nos travaux de recherche reviendra sur cette
partie. Dans un autre travail similaire à l’approche ContextUML, les auteurs proposent un profil
UML pour le développement des applications sensibles au contexte selon une approche MDD
[Grassi et Sindico, 2007]. Le profile proposé permet de classifier le contexte en (i) le contexte
d’état (statique), qui permet de caractériser l’état courant d’une entité, et (ii) le contexte dy-
namique (orienté évènement) qui représente les changements d’états d’une entité en fonction
d’évènements. Les contraintes sont utilisées sur chacun des types de contexte afin de mettre en
œuvre la sensibilité au contexte : les contraintes d’états font référence à des points spécifiques
dans le temps, tandis que les contraintes évènementielles exploitent les données historiques des
évènements liés aux contextes. Dans [Ou et al., 2006], une approche MDA est proposée à partir
des ontologies pour la représentation des informations liées au contexte. Les concepts du modèle
de contexte sont définis à partir des métamodèles de RDFS/OWL. Une architecture dite d’in-
tégration (MDIA) est proposée pour le développement des services sensibles au contexte selon
une approche MDA. Cependant, les auteurs n’abordent pas les techniques de transformation et
la gestion du contexte est liée à la logique métier des services. Dans [de Farias et al., 2007], les
auteurs présentent différents modèles de contexte proposés dans la littérature, et proposent un
métamodèle selon le formalisme MOF intégrant les principaux concepts liés au contexte pour
des applications mobiles à base de services. Ce travail ne discute pas des techniques de trans-
formations, ni comment le contexte est associé à la logique métier des applications. L’approche
dirigée par les modèles a aussi été utilisée pour le développement des environnements intelligents
(SmartHome), où la notion de contexte trouve tout son rôle. Dans [Gu et al., 2005], les auteurs
proposent un métamodèle de contexte pour décrire l’environnement d’une maison intelligente.
Ils ont défini une ontologie de contexte hiérarchique composé de deux couches : (1) Common
upper ontologie : cette couche décrit les concepts de base comme la personne, la localisation,
les entités informatiques, l’activité de la personne, etc. (2) The domain specific ontology : Cette
deuxième couche décrit les propriétés et les détails de tous les concepts de base, par exemple
la personne possède un nom, un rôle, un état qui décrit son activité. Plus récemment dans
[Serral et al., 2010], les auteurs proposent une méthode selon l’approche MDD pour la modélisa-
tion et la mise en œuvre de services ubiquitaires associés à une maison intelligente. Les auteurs
définissent un langage de modélisation PervML qui repose sur les ontologies, à travers le langage
OWL, pour décrire les services métiers et le contexte dans des modèles indépendants. Ensuite
les auteurs proposent une stratégie de génération automatique de code java pour les services
demandés.
Au delà de l’IDM, de nombreuses recherches en gestion du contexte qui ont été menées
récemment se sont principalement concentrées sur l’acquisition, le traitement, la modélisation
et la transmission du contexte à l’application. Le travail le plus connu dans le domaine est
celui de Dey et son équipe [Salber et al., 1999]. Dey a défini une architecture pour l’acquisition,
l’interprétation et l’assemblage de données contextuelles provenant de sources diverses à base de
context widgets.

4.6.2 Points forts et limites

Notre travail se positionne dans le domaine des applications pervasives sensibles au contexte.
Plus spécifiquement, on s’intéresse aux services mobiles centrés utilisateur et on utilise l’approche
MDA pour le développement de ces services. Nous proposons une approche appelée COMODE
avec deux principales facettes :
– La séparation entre la logique métier des applications et le contexte par des modèles.
– Une technique de transformation pour le tissage du contexte à la logique métier au niveau
des modèles.
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 84

A notre connaissance, notre approche est la seule proposition qui s’intéresse aux deux facettes
de façons unifiée, les autres travaux se concentrant habituellement sur la définition d’un modèle
unique intégrant logique métier et contexte. Des techniques de transformations classiques sont
alors mises en œuvre pour aboutir à une plateforme cible. Notre approche COMODE permet
d’associer à une même logique métier différent modèles de contexte et inversement un même
modèle de contexte peut être associé à différent modèles métier. La technique de transformation
paramétrée permet au concepteur de marquer les entités du modèle métier jugées pertinentes
pour le processus d’adaptation. Ces entités représentent le contexte et seront complétées par
le modèle de contexte durant le processus de transformation. Les résultats de nos travaux sur
l’approche MDA pour les applications sensibles au contexte peuvent être résumés comme suit :
– une architecture logiciel COMODE composée de cinq vues dédiées au développement d’ap-
plications sensibles au contexte selon une approche MDA ;
– un processus de développement COMODE illustrant les principaux modèles, les principaux
utilisateurs et les principales activités, impliqués dans le développement d’applications
sensibles au contexte selon une approche MDA.
– un métamodèle de contexte intégrant les principales entités utilisées dans l’état de l’art des
applications mobiles centrées utilisateur et sensibles au contexte.
– une technique de transformation dite paramétrée permettant de tisser le contexte à la
logique métier au niveau des modèles. La logique métier se retrouve enrichie par les données
contextuelles permettant la mise en œuvre de services adaptés à l’utilisateur final.
On peut cependant regretter quelques points, et nous pourrons donc poursuivre nos investigations
sur plusieurs axes. Dans le cas de l’architecture logiciel COMODE nous ne nous sommes interessé
qu’à trois vues : métier, contexte et composition. Les vues adaptation et services, même si nous
avons présenté quelques idées dans [Vale, 2009], doivent être développées de manière détaillée
afin d’aboutir à une réalisation de l’approche COMODE. Le métamodèle de contexte est décrit
sous le formalisme UML/MOF, il manque cependant une définition plus complète des principales
entités contextuelles. Les propriétés caractérisant chacune des principales entités (Acteur, Profile,
Environnement,...ect) doivent être déclinées et leur rôle dans la sensibilité au contexte doivent
être précisé. Dans [Vale et Hammoudi, 2009a] nous avons initié une définition du métamodèle
de contexte à partir des ontologies OWL/RDF afin de bénéficier de la richesse sémantique, de
l’extensibilité et de l’interopérabilité de ces formalismes [Euzenat et al., 2008]. Ce travail sera
poursuivi dans l’objectif de définir un métamodèle de contexte complet à base d’ontologies qui
doit être (a) suffisamment général pour être utilisé par différentes applications mobiles centrées
utilisateur, (b) suffisamment spécifique pour couvrir les principales entités contextuelles proposées
dans l’état de l’art des applications mobiles sensibles au contexte (c) suffisamment flexible pour
permettre une extensibilité et la prise en compte de nouvelles entités propres à un domaine
d’application. Enfin , faute de temps et de moyens humains, nous n’avons pas implanté nos
premiers résultats concernant les techniques de transformations et le processus de développement.
La chapitre 6 réservé à nos perspectives de recherche et développement reviendra en détail sur
nos travaux futurs.

4.6.3 Liste des publications

Ci-dessous la liste des articles publiés dans ce thème de recherche.

Journal :

When Parameterized Model Driven Development Supports Aspect Based SOA.

Valérie Monfort, Slimane Hammoudi
International Journal of E-Business Research (IJEBR). Accepted in 2010. pp 1-23.
ARCAMODE : An Architecture for the Development of Context-Aware Services Using Model Driven Architecture
and Ontologies
CHAPITRE 4. MDA ET LES APPLICATIONS SENSIBLES AU CONTEXTE. 85

Samyr Vale and Slimane Hammoudi

Communications of SIWN, Vol. 7, May 2009, pp. 135-141. SIWN Journal-2009

Conférence :

Vers des architectures orientées services et adaptables

Valérie Monfort and Slimane Hammoudi,
15ème colloque de l’Association Information et Management (AIM 2010).19, 20 et 21 mai 2010
à La Rochelle (France).
COMODE : A Framework for the Development of Context-Aware Applications in the Context of MDE
Samyr Vale and Slimane Hammoudi
The Fourth International Conference on Internet and Web Applications and Services ICIW 2009
May 24-28, 2009 - Venice/Mestre, Italy. pp. 261-266.
An Architecture for the Development of Context-aware Services based on MDA and Ontologies
Samyr Vale and Slimane Hammoudi.
Proceedings of the International MultiConference of Engineers and Computer Scientists 2009 Vol
I IMECS 2009, March 18 - 20, 2009, Hong Kong. pp 1-7.
On the challenge of adaptable SOA
Valérie Monfort, Slimane Hammoudi Second International Conference on Web and Information
Technologies"ICWIT’09" 12-14 June 2009, Kerkennah Islands, SFAX, Tunisia. pp 1-15.
Model Driven Development of Context-Aware Mobile Applications : an Architecture and a Metamodel
Saber Lajili, Slimane Hammoudi, Olivier Camp, Mohamed Gammoudi
ICSOFT’2009, the 4th International Conference on Software and Data Technologies, July 26-29,
2009, Sofia, Bulgaria. pp. 43-52.
Towards Adaptable SOA : Model-Driven Development, Context and Aspect
Valérie Monfort, Slimane Hammoudi
International Conference On Service Oriented Computing 2009, Joint ICSOC-ServiceWave 2009,
23rd – 27th November 2009. Stockholm, Sweden, pp. 175-189.

Workshop

Développement Dirigé par les Modèles de Services Sensibles au Contexte.

Slimane Hammoudi, Samyr Vale, Stéphane Loiseau
3ème Atelier sur la Gestion de Données dans les Systèmes d’Information Pervasifs. Conjoint à
Inforsid 2010
25 mai 2010 – Marseille.
ODM-based Architecture for the Development of Mobile Context-aware Applications
Samyr Vale and Slimane Hammoudi
The 2nd International (ACM) Conference on PErvasive Technologies Related to Assistive
Environments PETRA 2009 Greece, June 9-13, 2009.
Model Driven Development of Context-aware Service Oriented Architecture
Samyr Vale, Slimane Hammoudi.
In PerGrid’08, July 16-18, 2008 - São Paulo – Brazil, In conjunction with 2008 IEEE 11th
International Conference on Computational Science and Engineering
Context-aware Model Driven Development by Parameterized Transformation.
Samyr Vale, Slimane Hammoudi.
In MDISIS’08, Model Driven Interoperability for Sustainable Information Systems held in
conjunction with CAiSE’08, 16th of June 2008, Montpellier, FRANCE
Chapitre 5

MDA et le processus de transformation

By using frameworks that explicitly model assumptions about the application do-
main and the implementation environment, automated tools can analyze models for
flaws and transform them into implementations, avoiding the need to write large
amounts of code and eliminating the errors caused by programming [Booch et al., 2004].

5.1 Introduction et motivation

Ce chapitre est dédié à nos travaux sur la semi-automatisation du processus de transfor-
mation dans MDA. La semi-automatisation du processus de transformation est un réel défi
dont les avantages sont importants : elle réduit considérablement le temps de développement
de la transformation et diminue les éventuelles erreurs pouvant se produire lors d’une spécifica-
tion manuelle des transformations. Au chapitre 2 (section 2.5) nous avons initié une première
tentative vers la semi-automatisation en introduisant une approche séparant explicitement la
spécification des correspondances de la définition des transformations. Nous avons proposé une
extension de l’architecture du processus de transformation dans MDA, en séparant explicite-
ment le métamodèle des correspondances de celui des transformations. Nous avons également
implémenté cette approche dans un outil appelé MMT (Mapping Modeling Tool). Dans cette
première approche, une spécification des correspondances est réalisée manuellement pour dé-
finir les relations entre métamodèles (c’est-à-dire les éléments équivalents des métamodèles),
tandis que la définition des règles de transformations est générée automatiquement à partir des
correspondances. Dans ce travail, nous proposons une seconde extension de l’architecture du pro-
cessus de transformation dans le contexte de MDA. Cette seconde extension, introduit les tech-
niques d’appariements (matching) entre métamodèles [Lopes et al., 2006b, Lopes et al., 2006a,
Kappel et al., 2007, Lamine Lafi, 2010] en vue d’obtenir des correspondances entre deux méta-
modèles de manière semi-automatique. Les correspondances produites pourraient être adaptées
et validées par un expert dans le but de générer automatiquement un modèle de transforma-
tion consistant en un ensemble de règles de transformation. La figure 5.1 illustre les princi-
paux concepts et techniques impliqués dans un processus semi-automatique de transformation.
Les techniques d’appariements mettent en œuvre un processus qui produit les correspondances
potentielles entre deux métamodèles. En général, cette tâche implique la recherche d’éléments
équivalents ou similaires entre deux métamodèles. L’expert humain intervient dans cette étape
pour corriger les résultats obtenus (étape (1) sur la figure 5.1). C’est l’une des étapes dans le
processus de transformation dans laquelle l’expert intervient pour adapter, compléter et/ou va-
lider ces résultats. Nous reviendrons par la suite sur ces opérations. Finalement, un modèle de
transformation est dérivé automatiquement (étape (2) sur la figure 5.1) à partir du modèle de
correspondances. Le modèle de transformation (ensemble de règles) prend un modèle source et
produit un modèle équivalent sur une plateforme cible.
Trois principales contributions caractérisent nos travaux sur la semi-automatisation du pro-
cessus de transformation . Nous proposons une nouvelle architecture pour le processus de trans-
formation qui introduit la correspondance et l’appariement comme des entités de première classe,

86
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 87

Figure 5.1 – Principes d’un processus semi-automatic pour la transformation

représentées par des modèles et métamodèles. Ceci fait l’objet de la section 5.2. Notre seconde
contribution propose une méthodologie qui illustre les différentes étapes d’un processus semi-
automatique de transformation. Ceci fait l’objet de la section 5.3. Enfin, une mise en œuvre
complète est réalisée à travers un outil désigné par SAMT4MDE (Semi-Automatic Matching
Tool for MDE). Cet outil supporte les différentes étapes de notre approche : de l’appariement
entre métamodèles jusqu’a la génération des règles de transformations. Une évaluation de notre
algorithme d’appariement entre métamodèles est réalisée par des mesures de qualités proposées
dans le domaine des bases de données. Ceci fait l’objet de la section 5.4. Nous concluons ensuite
ce chapitre par un positionnement par rapport à l’état de l’art, une synthèse des apports et des
idées pour des travaux futurs. En tout dernier lieu, nous présentons une vue synthétique des
actions que nous avons menées sur cette thématique, incluant notamment les participants et les
publications.

5.2 Une architecture pour le processus de transformation

La figure 5.2 illustre notre proposition d’une architecture étendue pour le processus de trans-
formation dans MDA, permettant d’une part une génération semi-automatique de règles de
transformation, et d’autre part une génération d’un modèle cible à partir d’un modèle source.
Les deux principales opérations de notre approche sont : le Matching et la Transformation. Tous
les composants liés à ces opérations, et les relations entre eux sont présentés dans la figure 5.2
basée sur l’architecture standard de métamodélisation à niveaux de MDA. Le MOF au niveau
M3 est auto-défini et permet la définition des métamodèles du niveau M2.
Au niveau M2, nous avons les différents métamodèles nécessaires pour le processus de trans-
formation semi-automatique : les métamodèles source et cible concernés par le processus de
transformation (Source MM et Target MM), le métamodèle d’appariement (Matching MM), le
métamodèle de correspondance (Mapping MM) et le métamodèle de transformation (transfor-
mation MM). Au niveau M1, nous trouvons les différents modèles impliqués dans le processus
de transformation semi-automatique : les modèles source et cible (Source M et Target M), le
modèle d’appariement (Matching M), le modèle de correspondance (Mapping M) et le modèle de
transformation (Transformation M). Le niveau M0 concerne la partie exécution, où un moteur
de transformation prend un modèle source comme entrée d’un programme de transformation et
produit en sortie un modèle cible. Nous présentons ci-après les différents composants des divers
niveaux ainsi que les liens entre eux.
L’appariement est le processus qui produit les correspondances entre deux métamodèles.
En général, cette tâche implique la recherche d’éléments équivalents ou similaires entre deux
métamodèles. Dans le domaine des bases de données, cette activité s’appelle schema matching
[Rahm et Bernstein, 2001]. Dans notre contexte, un modèle d’appariement (Matching M) prend
deux métamodèles désignés respectivement par source et cible ‘target’ (représentant respective-
ment un métamodèle PIM et un métamodèle PSM), et produit un modèle de Correspondance
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 88

Figure 5.2 – Architecture pour la semi-automatisation du processus de transformation

(Mapping M). Le modèle d’appariement est conforme à un métamodèle d’appariement (Mat-

ching MM) qui à son tour met en œuvre des techniques permettant la recherche des concepts de
modélisation sémantiquement équivalents entre deux métamodèles. Dans nos précédents travaux
[Lopes et al., 2006b, Lopes et al., 2006a], nous avons proposé un premier algorithme d’apparie-
ment entre métamodèles fondé sur la théorie des ensembles. Cet algorithme est une première
mise en œuvre du métamodèle d’appariement. Les correspondances entre les éléments de deux
métamodèles (source et cible) sont enregistrées dans un modèle de correspondance (Mapping M)
conforme à un métamodèle de correspondance (Mapping MM). Ce métamodèle définit les diffé-
rents types de liens (correspondances) qui pourraient être générés par le modèle d’appariement.
Chaque type de lien correspond à un pattern de transformation spécifié dans le modèle de trans-
formation décrit ci-après. Puisqu’il n’existe pas de solution générique d’appariement pour les
différents métamodèles et domaines d’application, il est recommandé, voir nécessaire, de donner
à l’expert humain la possibilité de vérifier les correspondances obtenues, et, si nécessaire, de les
mettre à jour ou de les adapter. C’est l’une des étapes dans le processus dans laquelle l’expert
intervient pour adapter, compléter et / ou valider les résultats obtenus. Nous reviendrons par la
suite sur ces opérations. Enfin, un modèle de transformation (Transformation M), conforme à son
métamodèle de transformation (Transformation MM), est dérivé automatiquement à partir d’un
modèle de correspondance. Un modèle de transformation est représenté essentiellement par un
ensemble de règles qui indiquent comment les éléments du métamodèle source sont transformés
en éléments du métamodèle cible. Ces règles sont exprimées dans un langage de transformation
basé sur les standards MDA (OCL, MOF). Ce langage, tel que le standard QVT, est décrit par
un métamodèle en tant que formalisme général sous la forme d’une syntaxe abstraite pour la
transformation des modèles dans MDA. Généralement, le modèle de transformation est complété
par des informations telles que celles concernant l’environnement d’exécution, et produit fina-
lement un programme de transformation prêt à l’exécution. Cette dernière partie est souvent
réalisée par un concepteur qui implémente un modèle métier dans une plateforme spécifique.
Enfin, un moteur de transformation prend en entrée un modèle source, et génère un modèle cible
en exécutant le programme de transformation
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 89

5.3 Une méthodologie pour le processus de transformation

Nous visons, à travers notre méthodologie, à appuyer la nouvelle architecture du processus
de transformation présentée et à discuter les caractéristiques de ses différentes étapes ainsi que
des utilisateurs y intervenant. Avant de présenter les différentes activités du processus de trans-
formation, nous commençons par la classification des utilisateurs de la technologie MDA et nous
montrons par la suite comment ils interviennent dans ce processus.

5.3.1 Les utilisateurs MDA

Selon [Gavras et al., 2004], les utilisateurs de la technologie MDA peuvent être classés en
trois catégories et chaque utilisateur fait appel à d’autres. Dans le but de faciliter la pré-
sentation de notre méthodologie dans les sections suivantes, parmi les utilisateurs cités dans
[Gavras et al., 2004] nous nous limiterons aux deux catégories d’utilisateurs les plus importantes
et qui sont les plus concernées par le processus de transformation :
– utilisateur-expert : spécialisé particulièrement dans la manipulation des métamodèles et
des plateformes, et responsable de la génération d’un modèle de transformation, souvent
exprimé sous forme de règles soumises aux utilisateurs de connaissances.
– utilisateur-concepteur : spécialisé entre autres dans la gestion des modèles métiers et de leur
traduction dans des plateformes cibles en utilisant un modèle de transformation implémenté
par l’utilisateur-expert.

5.3.2 Processus de transformation : activités de préparation et d’exécution

La figure 5.3 illustre les principales phases d’une méthodologie permettant la
semi-automatisation du processus de transformation. Ces phases sont représentées par deux dia-
grammes d’activités ; le premier diagramme (a) montre les étapes suivies par l’utilisateur-expert.
Il démarre par la spécification des deux métamodèles source [1] et cible [2] et suit le proces-
sus jusqu’à la génération des règles de transformation [5] et d’un programme de transformation
exécutable. Le second diagramme (b), illustre les étapes suivies par l’utilisateur-concepteur qui
spécifie un modèle métier d’une application basée sur un métamodèle PIM [1]. Puis, à l’aide d’un
programme de transformation [2], il génère automatiquement l’implémentation de ce modèle mé-
tier sur une plateforme spécifique donnée [3]. La distinction entre les activités de préparation et
les activités d’exécution est fondamentale dans les projets MDA [Gavras et al., 2004]. Dans notre
contexte de « processus semi-automatique de transformation », les activités de l’utilisateur-expert
sont les activités de préparation (diagramme a), alors que ceux de l’utilisateur-concepteur repré-
sentent les activités d’exécution qui mènent à un modèle final implémenté pour une plateforme
spécifique.

5.3.2.1 Phase de préparation : génération des règles de transformation

La phase de préparation comprend 5 activités décrites dans la figure 5.3 (a), et est en partie
à la charge de l’utilisateur-expert.
– Spécification du métamodèle PIM : cette activité a pour but de définir le métamodèle PIM
approprié pour un domaine d’application. Les métamodèles PIM sont spécifiés essentiel-
lement à partir de sous ensembles des métamodèles standards de MDA tels que UML ou
EDOC, qui sont tous deux définis à partir du même métamétamodèle MOF. De plus, les
profils UML peuvent être utilisés pour prendre en considération les sémantiques particu-
lières d’un domaine d’application donné.
– Spécification du métamodèle PSM : cette activité a pour objectif de définir le métamodèle
PSM de la plateforme cible. Les PSM sont spécifiés dans le même formalisme que les PIM,
mais sont de plus bas niveau car ils doivent se conformer à des contraintes imposées par la
plateforme cible, c’est-à-dire la plateforme dans laquelle l’application sera implémentée.
– Techniques d’appariement : cette activité cruciale vise à sélectionner les algorithmes d’ap-
pariement appropriés afin de générer des correspondances. Le processus d’appariement peut
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 90

(a) phases de préparation (b) phases d’exécution

Figure 5.3 – Méthodologie pour un processus semi-automatic de la transformation

être représenté par une opération de gestion de modèles appelée match [Bernstein, 2003].
Cette opération prend deux métamodèles M1 et M2 en entrée et produit en sortie une
première version d’un modèle de correspondance Mm. M1 et M2 sont, respectivement,
conformes aux métamodèles correspondants MM1 et MM2. Mm est conforme au métamo-
dèle de correspondance MMm. L’opérateur → représente la relation conformsTo.

Mm → MMm = match (M1 → MM1, M2 → MM2).

Nous discutons les principes fondamentaux de l’appariement de métamodèles et nous présen-

tons notre approche algorithmique dans la section 5.5.

– Valider et/ou adapter les correspondances : cette activité est à la charge de l’expert humain.
Cependant, étant donné que les techniques d’appariement existantes ne donnent pas de
solution idéale pour tous les cas possibles, il serait rationnel de doter les utilisateurs-
expert d’outils interactifs pour réaliser les corrections nécessaires. Ces outils, permettent à
l’expert, de valider, supprimer ou modifier les correspondances obtenues, ou plus encore,
de spécifier des correspondances que les techniques d’appariement n’ont pas pu déterminer.
Nous appellerons cette partie fondamentale du processus de transformation, la technique
d’« Adaptation ».
– Génération des règles de transformation : cette phase a pour but de générer automatique-
ment les règles de transformation à partir des correspondances et de les formater en un
modèle de transformation de telle manière qu’elles puissent être utilisées par le programme
(de transformation) qui transforme le modèle PIM en un modèle PSM. Le modèle de cor-
respondance obtenu à la phase précédente, suite à son adaptation par l’utilisateur expert,
doit être complètement défini pour permettre une génération automatique du modèle de
transformation. Ce modèle, qui consiste en un ensemble de règles de transformation, est
un modèle structuré conformément au standard MOF2.0-QVT de l’OMG ou au langage
ATL utilisé dans nos expérimentations.
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 91

5.3.2.2 Phase d’exécution : mise en œuvre d’un modèle métier

Cette phase est réalisée par l’utilisateur-concepteur qui, après avoir défini le modèle métier,
voudrait l’implémenter sur une plateforme spécifique. Dans cette phase nous avons 5 activités
décrites dans la figure 5.3 (b), que nous pouvons réduire à 3. En effet, les trois dernières activités
sont regroupées car elles concernent le même modèle PSM.
– Spécification du modèle PIM : à partir du métamodèle PIM, un utilisateur-concepteur
définit son modèle métier en se concentrant uniquement sur la logique métier sans tenir
compte des considérations d’implémentation. Dans cette étape, le concepteur peut utiliser,
par exemple, les différents diagrammes UML qui mèneront à un diagramme de classe final
prêt à l’implémentation sur une plateforme spécifique.
– Exécution du Programme de Transformation : le programme de transformation obtenu
dans la première partie est maintenant utilisé. Il prend en entrée le modèle PIM défini
lors de l’étape précédente et produit en sortie le modèle PSM équivalent. Le moteur de
transformation, qui exécute le programme de transformation, lit le modèle source, applique
les règles de transformations et produit le modèle cible correspondant.
– De l’édition du PSM au modèle exécutable : nous regroupons ici les trois dernières étapes de
la deuxième phase, puisqu’elles concernent le même modèle PSM sous différentes versions.
Le modèle PSM produit lors de la phase précédente représente une première version et peut
être complété par des informations très spécifiques à la plateforme cible pour produire un
modèle final exécutable. Il est donc possible de vérifier si le PSM obtenu est complet.
Dans le cas où il est complet, la tâche de transformation est accomplie avec succès, si-
non, l’utilisateur-concepteur doit le compléter manuellement afin d’aboutir à un modèle
exécutable sur la plateforme cible.

5.3.3 Processus de transformation et principaux utilisateurs

Cette section a pour but de résumer les principaux concepts, techniques et lignes directrices
de notre méthodologie pour que le processus de transformation soit semi-automatique. Le tableau
5.1 montre les activités dans le processus de transformation en se focalisant sur deux aspects
importants : la manière dont ils sont réalisés (manuellement ou automatiquement), et qui est
responsable de leur réalisation (utilisateur expert, utilisateur concepteur). Du point de vue logi-
ciel, le processus de transformation fait appel à trois programmes essentiels qui sont au cœur du
processus semi-automatique de transformation :
– Programme d’appariement : met en œuvre les techniques d’appariement associées au mé-
tamodèle d’appariement et produit une première version d’un modèle de correspondance
entre deux métamodèles source et cible, PIM et PSM.
– Programme de génération : prend un modèle de correspondance adapté et validé par un
expert, et applique le processus de dérivation. Ce dernier génère automatiquement un
programme de transformation sous forme d’un ensemble de règles.
– Programme de transformation : prend un modèle source défini par l’utilisateur concepteur
et produit un modèle cible équivalent sur une plateforme spécifique.

5.4 Appariement et mise en œuvre

Dans MDA, les techniques d’appariement appliquées aux métamodèles forment le noyau du
processus semi-automatique de transformation et leur clé de voute même si les approches d’ap-
pariement de métamodèles dans le contexte de l’ingénierie des modèles sont encore à leur début
[Lopes et al., 2006b, Lopes et al., 2006a, Lamine Lafi, 2010, Kappel et al., 2007, Falleri et al., 2008].
D’un point de vue structurel, les schémas dans le domaine des bases de données et les métamodèles
dans notre contexte de MDA sont en étroite relation. Dans le contexte de l’appariement des sché-
mas [Rahm et Bernstein, 2001, Do et al., 2003, Do et Rahm, 2007] plusieurs notions permettant
d’évaluer les techniques d’appariements ont été définies.
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 92

Processus ? Acteur ? commentaires

A partir d’outils graphiques compatibles MOF,
manuel l’utilisateur expert spécifie les métamodèles
Métamodèles
(éditeur utilisateur-expert PIM et PSM pour, respectivement, un do-
PIM & PSM
graphique) maine d’application et une plateforme cible en
vue de l’implémentation finale.
Un programme d’appariement met en œuvre
programme les techniques d’appariement. Ce programme
Techniques d’appariement
automatique prend les deux métamodèles PIM et PSM et
d’appariement (utilisateur-expert) produit une première version d’un modèle de
correspondance
L’utilisateur expert met à jour et valide les cor-
Validation/Mise respondances obtenues précédemment. Le mé-
manuel
à jour des tamodèle PIM devrait correspondre complète-
(éditeur utilisateur-expert
correspondances ment et correctement au PSM. La technique
graphique)
d’adaptation est utilisée par l’utilisateur ex-
pert.
Le modèle de correspondance, mis à jour et
adapté à l’étape précédente, permet de géné-
Génération de programme de
rer automatiquement un programme de trans-
règles de automatique génération
Transformation (utilisateur-expert) formation sous forme d’un ensemble de règles.
La technique de dérivation est utilisée par le
programme de génération.
L’utilisateur concepteur, en utilisant un outil
manuel
graphique UML tels que Poseidon ou Rational
Modèle PIM (éditeur utilisateur-concepteur
Rose, spécifie un modèle métier conforme au
graphique)
métamodèle PIM défini par l’utilisateur expert

programme de A partir du modèle métier PIM défini par le

Exécution des transformation concepteur, le programme de transformation
règles de automatique
(utilisateur- est exécuté pour produire une première version
Transformation concepteur) d’un modèle PSM équivalent.
La première version d’un modèle PSM pour-
manuel rait être complétée par l’utilisateur concepteur
PSM final (éditeur utilisateur-concepteur pour produire une nouvelle version de PSM
graphique) prête à l’exécution.

Table 5.1 – Activités et acteurs dans un processus semi-automatique de transformation

Figure 5.4 – Comparaison entre vrais appariements et ceux dérivés automatiquement

CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 93

Ainsi, la notion de distance sémantique a été définie dans [Goranson, 2005] :

“the notion of semantic distance is developed to cover the notion of how close is close enough”

Une notion duale à la distance sémantique est celle de similarité entre deux schémas (schema
similarity) définie comme le "rapport entre le nombre d’éléments appariés et le nombre de tous
les éléments des deux schémas d’entrée" (SS = Nm / NT), où SS est la similarité entre schémas,
Nm est le nombre d’éléments appariés et Nt est le nombre total d’éléments des deux schémas en
entrée du processus d’appariement.
En partant de ces notions de base, plusieurs approches d’appariement de schémas ont été pro-
posées dans la littérature [Do et Rahm, 2007, Rahm et Bernstein, 2001, Shvaiko et Euzenat, 2005],
chacune ayant ses propres caractéristiques, regroupées selon une taxonomie [Rahm et Bernstein, 2001].
Dans [Hammoudi et al., 2010], nous présentons une synthèse de ces différentes approches d’ap-
pariements de schémas. Des mesures de qualités pour évaluer les différentes approches d’apparie-
ments de schémas ont été aussi proposées dans [Do et al., 2003]. Nous avons adopté ces mesures
pour évaluer notre approche d’appariement des métamodèles présentée en section 5.4.2, et nous
allons ci-dessous les introduire de manière succincte.
Ainsi, les correspondances entre les schémas peuvent être regroupées en des ensembles créés
soit manuellement soit automatiquement. Un ensemble créé manuellement par un expert peut
contenir tous les appariements valides (c.-à-d éléments appariés), alors qu’un ensemble créé auto-
matiquement peut contenir à la fois des appariements valides et d’autres non valides. Le premier
ensemble est dénommé par Real Matches (vrais appariements), et le second par Derived Matches
(appariements dérivés) (cf. Fig. 5.4).
Par ailleurs, d’autres sous-ensembles sont définis comme suit :
– A (faux négatifs) sont des appariements valides mais non identifiés automatiquement.
– B (vrais positifs) sont des appariements valides et qui ont été correctement déterminés par
l’opération automatique d’appariement.
– C (faux positifs) sont des appariements proposés d’une manière erronée par l’opération
automatique d’appariement.
– D (vrais négatif) sont de faux appariements qui ont été correctement écartés par l’opéra-
tion automatique d’appariement.

Basée sur les cardinalités de ces ensembles, les mesures de qualité d’appariement sont fournies
comme paramètres pour les benchmarks comme suit [Do et al., 2003] :
|B| |B|
P recision = |B| +|C| Recall = |A| +|B|

precision∗recall |1|
F − M easure = 2 ∗ precision+recall Overall = recall ∗ (1- precision )

La précision reflète la part des appariements pertinents parmi les appariements automati-
quement obtenus. Une plus grande précision signifie que les appariements trouvés ont plus de
chance d’être pertinents. Si le nombre de faux positifs est égal à zéro, tous les appariements
sont considérés être pertinents. Le Recall reflète la fraction des appariements pertinents par
rapport à l’ensemble des appariements concernés. Un Recall élevé exprime le fait que presque
tous les appariements pertinents ont été trouvés. Toutes ces mesures ont été développées spé-
cifiquement dans le contexte de l’appariement des schémas [Do et al., 2003, Do et Rahm, 2007,
Rahm et Bernstein, 2001]. On peut remarquer que F-mesure représente la moyenne harmonique
de la précision et du Recall. L’idée principale à travers Overall est de quantifier l’effort après
l’appariement nécessaire pour l’ajout des appariements manquant et la suppression des résultats
erronés.
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 94

5.4.1 Algorithme pour l’appariement des métamodèles

Cette section décrit le schéma général d’un algorithme d’appariement associé à l’opérateur
match présenté dans la section 5.3.2 comme :

Mc → MMc = match (Ma → MMa, Mb → MMb).

Il prend deux métamodèles Ma et Mb comme entrées et produit un modèle de correspon-

dance Mc. Ce modèle de correspondance est conforme à un métamodèle de correspondance
MMc présenté au chapitre 2. En général, Ma, Mb et Mc sont conformes au même métaméta-
modèle, ce qui simplifie le processus de transformation. Ainsi, notre proposition pour l’apparie-
ment de deux métamodèles est basée sur un précédent algorithme pour apparier deux ensembles
[Lopes et al., 2006b, Lopes et al., 2006a]. En effet, nous avons considéré les modèles et les méta-
modèles comme des ensembles d’entités, tout en sachant que ce sont des ensembles complexes et
hétérogènes. Avant de présenter le schéma général de notre algorithme d’appariement, nous pro-
posons les définitions suivantes pour les trois ensembles Ma, Mb et Mc, où Ma est l’ensemble des
éléments qui constituent le métamodèle source, Mb est l’ensemble des éléments qui constituent
le métamodèle cible et Mc est l’ensemble des éléments qui représentent les correspondances entre
les éléments de Ma et Mb :

– Un métamodèle M ( Ma ou Mb) est un ensemble de classes, de types de données et d’énu-

mérations. Chaque classe dans un métamodèle est composée d’un ensemble d’attributs et
de relations. Chaque énumération dans un métamodèle est un ensemble de littéraux.
– Un modèle de correspondance Mc entre deux métamodèles Ma et Mb est un ensemble de
classes appariées, des types de données appariés et d’énumérations appariées. Chaque élé-
ment dans un ensemble de classes appariées entre deux métamodèles Ma et Mb est composé
du triplet suivant :
– une classe de Ma
– une classe de Mb
– un ensemble d’attributs appariés et de relations appariés.

Pour tester l’appariement des classes, des types et des énumérations, nous avons défini trois
fonctions ϕ, ϕ0 et ϕ00 [Hammoudi et al., 2010]. Chacune de ces trois fonctions est définie comme
suit :
1 si a = b (a et b sont équivalent)
ϕ (a, b) = 0 si a u b (a et b sont similaire)
−1 si a 6= b (a et b sont dif f érent)
Les notions d’équivalences et de similarités ont été définies respectivement dans
[Bernstein, 2003, Pottinger et Bernstein, 2003]. Nous les avons adoptées dans notre algorithme
d’appariement en utilisant les trois critères d’appariement suivant pour l’évaluation des fonc-
tions :
– la similarité des noms (name similarity),
– la similarité des types (type similarity),
– l’appariement de graphes (graph matching).

Ainsi, par rapport aux différentes approches d’appariements [Rahm et Bernstein, 2001], nous
avons adopté une approche hybride mixant différent critères d’appariements. Des présentations
détaillées de notre approche d’appariement ainsi que de notre algorithme se trouvent dans les
articles suivants [Lopes et al., 2006b, Lopes et al., 2006a, Hammoudi et al., 2010]. Ci-dessous la
description générale de notre algorithme en pseudo-code Java.
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 95

Algorithme 1 – Schéma général d’un algorithme d’appariement de métamodèles

1 class M e t a m o d e l M a t c h i n g {
2 public C match ( Metamodel Ma , Metamodel Mb ) {
3 C c = new C () ; // create the set C .
4
5 BasicEList classLeafMa = new BasicEList () ;// create lists
6 BasicEList classLeafMb = new BasicEList () ;
7 BasicEList enumMa = new BasicEList () ;
8 BasicEList enumMb = new BasicEList () ;
9 BasicEList dTMa = new BasicEList () ;
10 BasicEList dTMb = new BasicEList () ;
11
12 /* Find leaf classes : select a1i from Ma that are leaves , and select b1x from Mb that are
leaves . */
13 classLeafMa = getLeafClass ( Ma ) ;
14 classLeafMb = getLeafClass ( Mb ) ;
15 /* get Enumerations from Ma and Mb */
16 enumMa = getEnum ( Ma ) ;
17 enumMb = getEnum ( Mb ) ;
18 /* get DataTypes from Ma and Mb */
19 dTMa = getDataType ( Ma ) ;
20 dTMb = getDataType ( Mb ) ;
21 /* Select equal or similar classes : For each pair of leaf classs a1i from Ma and b1x from
Mb , the function ( i . e . matchClasses ) classifies the elements of this pair in equal ,
similar or different . */
22 matchClasses ( classLeafMa , classLeafMb , c ) ;
23 /* Select equal or similar data types : For each pair of data types a2j from Ma and b2y
from Mb , the function ( i . e . mat chData Types ) classifies the Elements of this pair in
equal , similar or different . */
24 matc hDataT ypes ( dTMa , dTMb , c ) ;
25 /* Select equal or similar enumerations : For each pair of enumerations a3k from Ma and
b3Z from Mb the function ( i . e . matchEnums ) classifies the elements of this pair in
equal , similar or different . */
26 matchEnums ( enumMa , enumMb , c ) ;
27 return c ;
28 }
29 ***
30 }

5.4.2 Un outil SAMT4MDE

Nos expérimentations en vue de rendre le processus de transformation semi-automatique ont
été réalisées grâce à un plug-in d’appariement de métamodèles appelé Semi-Automatic Matching
Tool for MDE (SAMT4MDE). Ce plug-in implémente l’algorithme présenté dans la section pré-
cédente sous l’environnement EMF [Steinberg et al., 2009]. SAMT4MDE étend notre premier
prototype Mapping Tool for MDE (MT4MDE) présenté dans le chapitre 2 par l’appariement
semi-automatique de métamodèles. Il met en œuvre le processus semi-automatique de la trans-
formation, à partir de l’appariement entre deux métamodèles jusqu’à la génération des règles de
transformations en ATL. Dans [Hammoudi et al., 2010], nous présentons l’architecture ainsi que
les principaux modules de notre outil SAMT4MDE. Les quatre principales étapes supportées par
notre outil sont les suivantes :
1. Le modèle de correspondance obtenu suite au processus d’appariement.
2. La validation et l’adaptation des correspondances obtenues par un utilisateur expert.
3. Le modèle de correspondance obtenu après l’étape de la validation / adaptation.
4. Le modèle de transformation (ensemble de règles) obtenu automatiquement à partir du
modèle de correspondances.
Les figures 5.5 et 5.6 illustrent les étapes 2 et 4 sur les métamodèles (fragment) de UML d’une
part et de C# d’autre part. Après l’obtention d’un modèle de correspondances suite au processus
d’appariement, la figure 5.5 montre une fenêtre permettant à l’expert de valider et adapter les
éléments appariés. La figure 5.6 montre des règles de transformation en ATL générées automa-
tiquement par notre outil après une mise à jour et une validation par l’expert du modèle de
correspondances.
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 96

Figure 5.5 – Le processus de validation pour les éléments appariés

Figure 5.6 – Les règles de transformations générées à partir des correspondances

CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 97

Le tableau 5.2 donne un aperçu sur les résultats obtenus dans nos différentes expérimentations
discutées dans [Hammoudi et al., 2010]. Nous avons utilisé les mesures de qualités développées
pour l’appariement des schémas en bases de données [Do et al., 2003] et présentées brièvement
en début de cette section 4.

UML-C# UML-Java UML-

WSDL
Similarité de schémas 0.74 0.84 0.84
Precision 0.71 0.86 1.0
Recall 0.68 0.68 0.62
F-Mesure 0.69 0.76 0.76
Overall 0.40 0.57 0.62

Table 5.2 – Les mesures de qualités d’appariements de métamodèles

Dans ce qui suit, nous discutons brièvement des principales leçons tirées de nos trois ex-
périmentations : UML-C #, UML-Java et UML-WSDL. Les plus grandes valeurs de similarité
de schémas et de la précision ont été obtenues pour UML-WSDL. Les meilleures valeurs des
caractéristiques de Recall et de F-mesure ont été réalisées pour l’appariement UML-Java. Ces
résultats nous permettent de tirer les conclusions suivantes :
– La distance sémantique entre les métamodèles d’UML et WSDL (ou Java) est relativement
faible, et donc de nombreuses propriétés sont appariées (schema similarity = 0.84).
– Il n’ y a aucune ambiguïté sémantique entre les propriétés des métamodèles UML et WSDL,
puisque la précision de l’appariement est totale.
– Outre que ces valeurs sont très intéressantes en termes de découverte d’appariements, nous
pensons que les transformations de qualités égales dont le code a été écrit manuellement
prendraient plus de temps pour être produites. Maintenant, nous devons donc mener des
expérimentations pour prouver ce point, et montrer que dans l’ensemble, un processus de
transformation dans une approche semi-automatique est plus efficace et prend moins de
temps qu’une transformation entièrement manuelle.

Toutefois, notre outil a montré quelque limites. Par exemple, dans l’appariement entre les méta-
modèles de UML et de C#, notre outil SAMT4MDE propose que l’élément Attribute de UML
peut correspondre à l’élément Attribute de C #. En UML, un Attribute est une caractéristique
dans un classifier qui décrit une série de valeurs dont le type est classifier, tandis que, en C #, At-
tribute est utilisé pour inclure des informations supplémentaires à un type classifier. Cette erreur
peut être justifiée, car, après l’application des relations croisées [Pottinger et Bernstein, 2003],
l’élément Attribute en UML a une relation avec un classifier UML, et l’élément Attribute C #
a une relation avec un classifier C #. En plus, les noms de ces deux éléments sont les mêmes,
mais les significations sont différentes. En d’autres termes, les deux éléments ont des structures
similaires, et une analyse préliminaire linguistique détermine qu’ils sont égaux. En fait, ces élé-
ments ont été appariés à tort et cette correspondance est un faux positif. Dans des recherches
futures, nous tâcherons d’éviter ce genre d’erreurs par l’amélioration de notre outil par une
analyse sémantique et l’utilisation des techniques d’apprentissage.

5.5 Conclusion, travaux connexes et synthèse

Ce travail a fait l’objet de deux stages de master recherche [Alouini, 2008] et [Lafi, 2010], et
d’une thèse de doctorat de Wajih Alouini [Alouini, 2011] dont la soutenance est prévue en Juin
2011 en coopération avec la Faculté des Sciences de Tunis et le LIRMM de Montpellier. Il a
donné lieu à dix (10) publications scientifiques : 2 publications dans deux revues internationales,
cinq publications dans des conférences internationales et nationales et trois publications dans
des workshops. La section 5.5.1 positionne notre travail par rapport à l’état de l’art, la section
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 98

5.5.2 situe les points forts de notre travail et décline ses limites et discute les travaux futurs, la
section 5.5.3 présente la liste des publications autour de ce travail.

5.5.1 Positionnement par rapport à l’état de l’art

Les techniques d’appariement, qui sont à la base d’un processus semi-automatique de trans-
formation, ont été étudiées intensivement dans différents domaines. L’appariement de schémas
(schema matching) en base de données [Rahm et Bernstein, 2001] a été un des précurseurs alors
qu’aujourd’hui avec le Web et le semantic web, la recherche sur les techniques d’appariement
d’ontologies est très active [Shvaiko et Euzenat, 2005]. Une riche bibliographie sur le sujet de
l’appariement et la recherche autour de ce thème est maintenue sur le site Ontology Matching
(www.ontologymatching.org). L’appariement d’ontologie [Shvaiko et Euzenat, 2005] est un axe
qui se développe rapidement afin de trouver la solution au problème de l’hétérogénéité séman-
tique qui est un des nombreux problèmes dans le processus d’appariement de deux métamo-
dèles. En fait, pour trouver la similarité entre des entités utilisées dans les systèmes d’apparie-
ment d’ontologie courants, de nombreuses stratégies sont utilisées (par exemple, la similarité des
chaînes de caractères, les synonymes, la similarité entre structures et sur la base des instances)
[Lin et Sandkuhl, 2008].

Parmi les approches d’appariement de métamodèles, les auteurs de [Falleri et al., 2008] pro-
posent une approche qui en trois phases qui détecte automatiquement les correspondances entre
deux métamodèles, et les utilise pour générer un alignement entre ces métamodèles. L’ap-
proche commence par la génération de graphes orientés étiquetés représentant les métamodèles
à apparier, puis, l’approche continue avec l’application de l’algorithme de Similarity Flooding
[Melnik et al., 2002] sur les graphes produits. Ces graphes sont ensuite utilisés dans un proces-
sus de calcul du point fixe dont le résultat indique les nœuds dans le premier graphe et leurs
semblables dans le second. La dernière étape consiste en la génération d’un alignement entre
les deux métamodèles. L’article évalue différentes configurations de l’algorithme similarity floo-
ding et sur plusieurs métamodèles. En comparaison avec notre approche, celle présentée dans
[Falleri et al., 2008] utilise un algorithme de matching orienté graphe avec différentes configu-
rations. Cependant, les auteurs ne proposent ni une architecture ni une méthodologie pour le
processus de transformation, et de ce fait le travail décrit pourrait être vu comme une variante
pour l’appariement des métamodèles. D’autre part, il n’est pas démontré que la transforma-
tion en graphes ne ralentit pas le processus. Dans le même ordre d’idées visant à faciliter la
génération semi-automatique de correspondances entre métamodèles et en vue d’améliorer le
modèle d’appariement pour le développement du modèle de transformation, [Voigt et al., 2010]
propose d’intégrer les approches d’appariement existantes dans un même module et de réutiliser
les résultats des appariements en appliquant différents apparieurs spécifiques de métamodèles.
Notamment, un apparieur d’instances, un apparieur de graphe, un apparieur d’annotation, un
apparieur de type de données, un apparieur de fréquence, un apparieur de patron, et une confi-
guration d’appariement basée sur la classification de types de transformation de modèles. Cette
nouvelle approche est implémentée dans un prototype combinant l’apparieur d’instance et l’ap-
parieur de type de données dans un environnement existant. Ce travail représente également
une variante du processus d’appariement dans notre architecture. Une autre tendance récente
(transformation de modèles basée sur des exemples-MTBE ) pour aider au développement de
transformations est inspirée par les approches de la programmation par l’exemple ou par la
démonstration [Lieberman, 1993]. Dans ces propositions, les règles de transformations sont géné-
rées à partir des exemples de transformations (traces composées d’exemples de correspondances).
Ainsi, des règles d’ATL sont dérivées des exemples de transformation écrits dans une syntaxe
concrète dans [Wimmer et al., 2007]. Dans [Kessentini et al., 2008], ils utilisent un algorithme
basé sur l’optimisation par essaims particulaires (particle swarm optimization) pour générer une
transformation consistante d’un modèle. La transformation d’un élément du modèle source est
codée comme une particule qui doit être située dans l’espace des transformations possibles. Les
correspondances existantes et connues des exemples de transformation indiquent ce que l’algo-
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 99

rithme essaie de respecter. Une autre approche MTBE est donnée dans [Varró et Balogh, 2007]où
les règles de transformation de graphes sont dérivées d’une manière semi-automatique à par-
tir des correspondances entre des modèles donnés par un utilisateur. L’analyse est alors basée
sur la logique inductive des éléments voisins du modèle, et l’interaction avec un expert. Dans
[Dolques, 2009], des informations sur les métamodèles source et cible, ainsi que sur les corres-
pondances sont codées dans des tables traitées par l’approche d’analyse formelle des concepts
(Formal Concept Analysis). Les règles de transformation sont ensuite déduites par inférence sur
la base des points communs dans la description des exemples de correspondance. L’approche
MTBE est une approche complémentaire qui exige une extension de l’architecture du processus
de transformation, car les traces et les exemples doivent être ajoutés dans le processus global.
Quand l’approche MTBE arrive à maturité, une perspective serait de la combiner avec les ap-
proches basées sur l’appariement de métamodèles pour obtenir une architecture hybride.

Cependant, très peu de travaux se sont intéressés à la semi-automatisation du processus de

transformation dans le cadre de MDA, ou plus généralement dans le cadre de MDE.
[Fabro et al., 2005] et [Kappel et al., 2007] sont à notre connaissance les seuls travaux ayant
abordé cette problématique à ce jour. Le premier propose différentes heuristiques pour la réali-
sation de l’appariement entre deux métamodèles. Ces heuristiques sont mises en œuvre par un
métamodèle d’appariement permettant de générer un modèle de tissage (Weaving model) à partir
de propriétés des métamodèles source et cible pris en entrée. Dans [Kappel et al., 2007], ils pro-
posent une approche dite de lifting, permettant de transformer les métamodèles source et cible en
ontologies équivalentes. Des techniques d’appariement largement développées dans les domaines
des ontologies [Shvaiko et Euzenat, 2005] et des schémas en bases de données [Do et Rahm, 2007]
sont ensuite appliquées. Leur approche a été mise en œuvre à travers un prototype disponible
sur le site du projet ModelCVS . Dans cette deuxième approche, l’aspect génération automa-
tique de règles de transformations à partir de correspondances n’est pas abordé. Dans ce travail,
nous avons centré notre approche sur les aspects architecturaux et méthodologiques que nous
considérons primordiaux pour aborder ce défi de la semi-automatisation dans MDA.

5.5.2 Synthèse, points forts et travaux futurs

Dans ce chapitre, nous avons présenté notre approche pour un processus semi-automatique de
transformation dans MDA à l’aide d’une architecture et une méthodologie. Il est clair qu’un pro-
cessus semi-automatique de transformation est un défi important dans l’approche MDA puisqu’il
n’existe pas encore de solution complète qui automatise le développement de la transformation
de modèles.
Ce processus est semi-automatique car l’algorithme d’appariement entre métamodèles trouve
les éléments en correspondance qui sont ensuite validés, refusés ou corrigés par un utilisateur
expert. Ensuite, l’utilisateur peut ajouter de nouvelles correspondances ainsi que des expressions
OCL dans la spécification de correspondance (modèle de correspondance). Une fois la spécifi-
cation de correspondance est terminée, l’utilisateur peut utiliser les générateurs pour transfor-
mer cette spécification de correspondance en une définition de transformation d’un langage de
transformation spécifique. Ainsi, notre approche est indépendante du langage de transformation,
puisqu’une spécification de correspondance est indépendante d’un langage donné (hormis le lan-
gage neutre OCL). Dans notre approche, l’accent n’est plus mis sur la création manuelle de la
transformation mais sur la spécification semi-automatique de correspondances. Une spécifica-
tion de correspondances contient la logique nécessaire pour correspondre un métamodèle à un
autre métamodèle et elle peut être partiellement générée grâce aux algorithmes d’appariement de
métamodèles. Le principe clé de notre approche est de considérer les métamodèles de correspon-
dances et d’appariements comme étant des entités de première classe dans MDA. Un processus
semi-automatique apportera de nombreux avantages dans MDA :

– il diminue le temps de développement pour la création des définitions de transformations :

une fois les spécifications de correspondances validées et complétées, elles sont utilisées pour
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 100

générer les définitions de transformation dans un langage spécifique de transformation.

Une attention particulière est accordée à l’algorithme d’appariement de métamodèles dans
le cadre de la spécification de correspondances. En plus, lorsque l’utilisateur change de
plateforme de transformation, il n’a besoin que de la spécification de correspondances
définie préalablement et applique un nouveau générateur de transformations pour générer
automatiquement les définitions de transformation pour la nouvelle plateforme.
– il réduit les éventuelles erreurs pouvant se produire dans le codage manuel des définitions
de transformation : puisque la définition de transformation est générée à partir des spé-
cifications de correspondances, l’accent est mis sur la spécification de correspondance qui
a un niveau d’abstraction élevé et qui est définie par un langage indépendant de la pla-
teforme. Les spécifications de correspondance peuvent être exprimées en partie à l’aide
de formalisme graphique, et sont par conséquent lisibles et non vulnérables à des facteurs
causant des erreurs. En outre, comme les spécifications de correspondances peuvent être
générées par un algorithme d’appariement de métamodèles, la qualité du processus est
améliorée. Toutefois, dans l’état actuel de la recherche, il n’est pas possible de trouver tous
les éléments de correspondance par la seule application des algorithmes d’appariement de
métamodèles et une intervention humaine reste nécessaire pour compléter les spécifications
de correspondance.
– Il améliore la qualité du code final de la transformation : les algorithmes d’appariement de
métamodèles utilisent des algorithmes de reconnaissance des formes, des dictionnaires, des
analyseurs de structure, des analyseurs sémantiques, les relations croisées et déduites qui
constituent les connaissances utilisées par l’homme afin de trouver des correspondances.
Cependant, les tâches répétitives sont adaptées aux ordinateurs, mais pas pour l’homme.
Ainsi, un outil d’appariement semi-automatique de métamodèles et des générateurs auto-
matiques de définition de transformation sont essentiels pour améliorer l’approche MDA,
et assurer la qualité des spécifications de correspondances et des définitions de transforma-
tions.

Les perspectives de ce travail dédié à la semi-automatisation du processus de transformation

seront discutés dans le chapitre suivant.
CHAPITRE 5. MDA ET LE PROCESSUS DE TRANSFORMATION 101

5.5.3 Liste des publications

Ci-dessous la liste des articles publiés autour de ce thème de la semi-automatisation du
processus de transformation dans MDA.

Journal :

Towards A Semi-Automatic Transformation Process in MDA : Architecture, Methodology and First Experiments.
Slimane Hammoudi, Wajih Alouini, Denivaldo Lopes, Marianne Huchard
International Journal of Information System Modeling and Design (IJISMD). issue No 4, 2010.
pp 1-33.
Semi-Automatic Generation of Transformation Rules in Model Driven Engineering : The Challenge and First Steps
Slimane Hammoudi, Wajih Alouini, Denivaldo Lopes, Mohamed Gammoudi
International Journal of Software Engineering and Its Applications (IJSEIA). To be published
in 2010.

Conférence :

A Semi-Automatic Transformation Process in MDA : Architecture and Methodology.

Slimane Hammoudi, Wajih Alouini, Denivaldo Lopes
In 10th International Conference on Enterprise Information Systems, 12 - 16, June 2008,
Barcelona, Spain, pp. 416-425.
Vers une Semi-automatisation du Processus de Transformation dans l’Approche MDA.
Hammoudi, S. Vale, S., Lopes, D
Congrès IDM’08, 5-6, Juin 2008, Mulhouse, France
Generation of Transformation Rules in Model Driven Engineering : The Challenge and First Steps.
Slimane Hammoudi, Samyr Vale. In 1st International Computer Science and Technology
Conference, San Diego, California, USA March 31 through April 3, 2008. pp
Schema Matching in the context of Model Driven Engineering : From Theory to Practice.
Denivaldo Lopes, Slimane Hammoudi, Zair Abdelouahab
Advances and Innovations in Computing and Software Engineering, Springer, 2006, Editores
Tarek Sobh and Khaled Elleithy,
Metamodel matching : Experiments and comparison.
Denivaldo Lopes, Slimane Hammoudi, J De Souza.
In ICSEA’06, International Conference on Software Engineering Advances. October 29 -
November 3, 2006 - Tahiti, French Polynesia.

Workshop

Metamodels Matching : Issue, techniques and comparison

Lamine Lafi, Wajih Alouini, Slimane Hammoudi, Mohamed Gammoudi
2nd Intenational Workshop FTMMD, Joint to International Conference ICEIS. June 2010,
Portugal.
From Mapping Specification to Model Transformation in MDA : Conceptualization and Prototyping
Slimane Hammoudi, Denivaldo Lopes.
1st International Workshop on MDEIS, ICEIS International Conference May 2005, MIAMI,
USA,
Mapping Versus Transformation in MDA : Generating Transformation Definition from Mapping Specification.
Slimane Hammoudi, Jerome Janvier, Denivaldo Lopes.
In VORTE 2005, 9th IEEE International Conference on EDOC Twente, Netherland.
Chapitre 6

Synthèse, direction de recherche et

perspectives

Ce document propose une vision unifiée des différents travaux que j’ai menés autour de
l’ingénierie des modèles et ses applications à deux domaines phare de l’ère internet : les services
Web et l’informatique pervasive sous l’angle des applications sensibles au contexte. L’application
de l’IDM aux deux domaines m’a conduit à m’intéresser et intensifier mes recherches sur les trois
axes clés de l’IDM selon l’approche MDA :
– Les techniques de modélisation et métamodélisation.
– Les techniques de transformations de modèles.
– Les méthodologies de développement.
La transformation de modèles a pris une place importante dans mes travaux de recherche et mes
contributions sur cet axe s’inscrivent sur deux problématiques :
– la semi-automatisation du processus de la transformation.
– l’application des deux techniques de transformations : la transformation paramétrée et la
composition de modèles.

Une des originalités de nos travaux est d’avoir suivi une approche qui renforce et met en œuvre
le principe de la séparation des préoccupations, un des principes essentiels du génie logiciel et
fondateur de l’ingénierie dirigée par les modèles. Nos travaux ont permis de proposer et de mettre
en œuvre une séparation entre les modèles suivants :
– modèle de correspondance versus modèle de transformation (pour le processus de transfor-
mation dans MDA)
– modèle métier versus modèle de contexte (pour le développement des services pervasifs
sensibles aux contexte).
La première séparation permet dans un premier lieu de s’afranchir des langages de transforma-
tions, et de se concentrer sur une problématique de plus haut niveau d’abstraction, la spécification
des correspondances. Dans un second lieu, la séparation entre modèle de correspondances et mo-
dèle de transformation nous à conduit à proposer une approche pour la semi-automatisation du
processus de transformation.
La seconde séparation entre modèle métier et modèle de contexte permet la réutilisabilité et la
gestion des informations contextuelles indépendemment de la partie métiers. Ainsi, un modèle
de contexte peut être défini indépendamment de la logique métier d’une application, à différents
niveaux d’abstraction, puis tissé au modèle métier par des techniques de transformation adap-
tées. Nous avons proposé deux techniques de transformations : la transformation paramétrée et
la composition de modèles.

Mes contributions en termes de publications sont illustrées à la fin de chaque chapitre et

représentées dans l’annexe B par 4 articles de revues, dont 1 revue nationale et 3 revues inter-
nationales qui résument les principaux résultats de mes recherches.

102
CHAPITRE 6. SYNTHÈSE, DIRECTION DE RECHERCHE ET PERSPECTIVES 103

Mon projet scientifique pour les prochaines années s’inscrit dans la lignée de mes travaux
présenté dans ce document sur l’étude et l’application de l’ingénierie dirigée par les modèles. Le
vaste champ de recherche autour de l’IDM dépasse de loin ce qu’une personne, ou une équipe
peut entreprendre. l’IDM est toujours dans une phase de défrichage, encore largement empirique.
Comme il a été remarqué dans [Muller, 2006], nous manipulons des notions sans les avoir définies
formellement, ni sans avoir défini des opérateurs qui s’appliquent sur ces notions. Pour avancer
significativement, l’IDM doit se doter d’une théorie des modèles et des opérations les manipulants
afin de pouvoir d’une part raisonner sur les modèles et d’autre part afin de pouvoir construire
des outils fiables et efficaces.
Nous précisons dans chacune des sections qui suivent les recherches qui nous semblent prio-
ritaires et sur lesquelles nous comptons travailler à court terme.

6.1 Services adaptables : modèles à l’exécution

La société d’aujourd’hui dépend de plus en plus de logiciels devant être disponibles qua-
siment sans interruption et devant s’adapter en permanence aux différentes conditions envi-
ronnementales ainsi qu’aux changements d’exigences [Jézéquel, 2010].

Research on providing support for creating and using runtime models is in its infancy.
Providing support for changing behavior during runtime is particularly challenging. If models
are to be used to effect changes to running software, research needs to focus on how the
changes can be effected in a controlled manner [France et Rumpe, 2007].
L’architecture orientée services (SOA – Service Oriented Architecture) représente le socle des
futurs systèmes d’information des entreprises, où les services sont perçus comme des entités auto-
nomes qui peuvent être décrites, publiées, catégorisées, découvertes et composées dynamiquement
pour le développement de systèmes interopérables et évolutifs. Aujourd’hui, il est largement ad-
mis que les services Web étudiés dans le chapitre 3 de ce mémoire constituent la solution adéquate
pour implémenter les architectures orientées service. Cependant les services Web ont un code mo-
nolithique et encapsulent différentes préoccupations telles que la sécurité, l’authentification, et
de ce fait, présentent des limitations par rapport à leur adaptabilité dynamique aux changements
de la logique métier. Ces limitations affectent les fournisseurs et les consommateurs de services.
D’un coté, les fournisseurs de services n’ont pas le moyen de changer dynamiquement une im-
plémentation ou une composition de services existante. Ils sont obligés de stopper le service, de
le re-codifier puis de le redéployer. Pendant ce temps, le service est rendu indisponible pour ses
utilisateurs. D’un autre coté, comme le service est partagé par plusieurs applications clientes, si
un changement affecte la description du service WSDL ou le protocole d’interaction BPEL, les
consommateurs ne pourront plus interagir avec celui ci et aboutissent à des erreurs d’exécution.
Nous désignons par adaptation évolutive des services la possibilité de changer dynamiquement la
logique métier d’un service sans avoir à le stopper. Une autre approche d’adaptation des services
a été présentée dans le chapitre 4 sous le vocable de services sensibles aux contexte. Un service
sensible au contexte peut capturer dynamiquement un ensemble d’informations de son environne-
ment ; ces informations représentent un contexte ; le service s’adapte en cours d’exécution grâce à
ce contexte. Nous désignons par adaptation contextuelle des services la possibilité d’adapter dy-
namiquement la logique métier d’un service en fonction d’informations contextuelles. Nous avons
proposé au chapitre 4 une approche appelée COMODE pour le développement de ces services
sensibles aux contexte à partir de l’approche MDA. Cependant, la problématique de la sensibilité
au contexte, permettant à des services de s’adapter dynamiquement en fonction des données du
contexte, n’a pas été abordée.
Notre première perspective est de proposer une approche IDM permettant de prendre en
compte les deux types d’adaptation des services de la conception (design-time) et jusqu’a l’exé-
cution (runtime).
– l’adaptation évolutive des services permet de faire évoluer dynamiquement la logique métier
d’un service ou des préoccupations transversales liées aux service, tout en assurant une
disponibilité totale du service.
CHAPITRE 6. SYNTHÈSE, DIRECTION DE RECHERCHE ET PERSPECTIVES 104

– l’adaptation contextuelle des services permet de capturer dynamiquemment des informa-

tions sur l’environnement du service et d’adapter le service en fonction de ces informations.
Nos premières idées concernant cette perspective de services adaptables à partir d’une approche
IDM ont été présentées en novembre 2009 à la conférence de référence sur les services ICSOC
[Monfort et Hammoudi, 2009]. Voici les principales techniques que nous avons proposées et qui
feront partie de notre champ d’investigation pour cette perspective :

– la modélisation orientée aspect [Jézéquel, 2006, Rashid et al., 2003] : permet de modéliser
dès la conception à travers les aspects, soit les évolutions possibles de la logique métier d’un
service, soit les situations contextuelles permettant d’assurer l’adaptabilité du service.
– modèle à l’exécution (Model@runtime) [Bencomo et al., 2006, Morin et al., 2009] : permet
de mettre en œuvre l’évolution d’une logique métier d’un service ou son adaptabilité à l’exé-
cution. Dans le workshop Runtime Models [Bencomo et al., 2006], Gordon Blair a identifié
certaines des problématiques de recherche autour des modèles à l’exécution.
– la composition et le tissage de modèles [Clarke, 2002, France et al., 2007] : permet dès la
conception et de manière automatique de composer des modèles pour gérer des variations
d’évolutions. Elle peut aussi être utilisée pour composer des modèles à l’exécution afin de
mettre en œuvre l’adaptabilité dynamique [Jézéquel, 2010].

Cette dernière technique permettant la composition de modèles tant au niveau de la conception

qu’a l’exécution, représente de notre point de vue la clé de voute pour la mise en œuvre des ser-
vices adaptables selon une approche IDM. Cette perspective sera privilégiée dans nos recherches
futures à court terme et c’est pour cela que nous la présentons ci-dessous.

6.2 Composition et tissage de modèles

Bien sûr, la séparation des préoccupations est d’un intérêt limité si on ne peut pas recom-
poser ces préoccupations automatiquement. La composition automatique de modèles permet
en effet de gérer des variations de préoccupations de conception [Jézéquel, 2010].
Cette deuxième perspective vise a proposer des techniques dans le cadre de l’IDM et MDA,
permettant d’automatiser la composition de modèles tant durant la phase de conception d’un
système que durant son exécution. Au dela de l’IDM et MDA, aujourd’hui, la conception de
logiciels devient de plus en plus complexe, et dans ce contexte la multi-modélisation devient une
activité majeure du processus de développement, notamment dans la phase de conception où plu-
sieurs modèles sont généralement produits et doivent cohabiter et/ou être composés pour obtenir
un modèle global cohérent du système. Plusieurs approches s’intéressent à la multi-modélisation,
que ce soient les approches traditionnelles comme la modélisation par points de vue ou la mo-
délisation par sujets, le développement par aspects, ou l’ingénierie des modèles. Même si ces
travaux sont reconnus ou prometteurs, l’automatisation de la composition de modèles (appelée
aussi fréquemment fusion) constitue encore un défi majeur du Génie Logiciel, et de l’ingénièrie
des modèles en particulier. Les questions essentielles, que nous nous posons, sont :

– Comment composer automatiquemment des modèles durant la conception en prenant

compte non seulement des critères syntaxiques comme dans [Fleurey et al., 2007], mais
aussi des critères sémantiques de ces modèles ?
– Comment composer automatiquement des modèles dynamiques (diagrammes de séquences,
diagrammes d’activités,...ect) dans un modèle de conception détaillé qui pourra donner lieu
à de la génération de code [Jézéquel, 2008] ou de la génération de tests [Pickin et al., 2007] ?
– Comment composer automatiquement des modèles à l’exécution afin de spécifier et gérer
l’adaptabilité dynamiques des systèmes et des services ?
CHAPITRE 6. SYNTHÈSE, DIRECTION DE RECHERCHE ET PERSPECTIVES 105

6.3 L’appariement des métamodèles et la transformation

La troixième perspective est de continuer à améliorer le processus semi-automatique pour
la transformation presenté largement dans le chapitre 5. La transformation étant au coeur de
l’IDM et de l’approche MDA, sa semi-automatisation représente un vrai défi auquel nous voulons
continuer à contribuer. Nous avons vu au chapitre 5 que les techniques d’appariement de méta-
modèles sont à la base d’un processus semi-automatique de la transformation. Nous souhaitons
donc poursuivre nos recherches sur deux axes complémentaires permettant l’amélioration des
techniques d’appariement et par conséquent le processus semi-automatique de transformation :
– Spécifier et concevoir une infrastructure permettant de pouvoir évaluer grâce à des mé-
triques les performances des différentes approches d’appariement de métamodèles. Etablir
un benchmark composé de plusieurs métamodèles déjà alignés qui pourra servir à comparer
les différentes approches d’appariements.
– Proposer une approche hybride d’appariement des métamodèles permettant de combiner
les résultats de différentes approches afin d’améliorer le processus de découverte des cor-
respondances entre métamodèles.

Participer, modestement, à l’avancée de ces trois perspectives constitue une aventure que je
souhaite mener à bien au niveau national et international avec la communauté avec laquelle j’ai
le plaisir et la chance de travailler.
Bibliographie

[Abowd et Mynatt, 2000] Abowd, G. D. et Mynatt, E. D. (2000). Charting past, present, and
future research in ubiquitous computing. ACM Trans. Comput.-Hum. Interact., 7(1):29–58.
[Aho et al., 1986] Aho, A. V., Sethi, R. et Ullman, J. D. (1986). Compilers : Princiles,
Techniques, and Tools. Addison-Wesley.
[Akehurst et al., 2007] Akehurst, D. H., Vogel, R. et Paige, R. F. (2007). Lecture notes in
computer science. Springer,, vol. 4530,.
[Aksit, 1996] Aksit, M. (1996). Separation and composition of concerns in the object-oriented
model. ACM Comput. Surv., 28(4es):148.
[Alizon F., 2008] Alizon F., B. M. (2008). Les modèles dans l action à france télécom avec
smartqvt. In Génie Logiciel, source : Journées Neptune n° 5, 08/04/2008.
[Alouini, 2008] Alouini, W. (2008). La semi-automatisation du processus de transformation
dans l approche mda : Architecture et méthodologie. Mémoire de D.E.A., Mastère de l ISIG
(Kairouan) tunisie.
[Alouini, 2011] Alouini, W. (2011). Vers une semi-automatisation du processus de transforma-
tion dans l approche MDA. Thèse de doctorat, Fac des Sciences de Tunis - TUNISIE.
[Andrews et al., 2003] Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J.,
Leymann, F., Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I. et Weerawa-
rana, S. (2003). Business process execution language for web services. Rapport technique,
IBM.
[Anzböck et Dustdar, 2005] Anzböck, R. et Dustdar, S. (2005). Semi-automatic generation of
web services and bpel processes - a model-driven approach. In Business Process Management,
pages 64–79.
[Arkin, 2002] Arkin (2002). A. business process modeling language. Rapport technique, San
Mateo, CA : BPMI.org.
[Arkin et al., 2002] Arkin, A. et al. (2002). Web services choreography interface (wsci) 1.0.
Rapport technique, W3C.
[Atkinson et Kühne, 2003] Atkinson, C. et Kühne, T. (2003). Model-driven development : A
metamodeling foundation. IEEE Software, 20(5):36–41.
[Bachman, 1974] Bachman, C. W. (1974). Summary of current work - ansi/x3/sparc/study
group - database systems. FDT - Bulletin of ACM SIGMOD, 6(3):16–39.
[Baïna et al., 2004] Baïna, K., Benatallah, B., Casati, F. et Toumani, F. (2004). Model-
driven web service development. In CAiSE, pages 290–306.
[Baldauf et al., 2007] Baldauf, M., Dustdar, S. et Rosenberg, F. (2007). A survey on
context-aware systems. IJAHUC, 2(4):263–277.
[Benatallah et al., 2003] Benatallah, B., Sheng, Q. Z. et Dumas, M. (2003). The self-serv
environment for web services composition. IEEE Internet Computing, 7(1):40–48.
[Bencomo et al., 2006] Bencomo, N., Blair, G. S. et France, R. B. (2006). Summary of the
workshop [email protected] at models 2006. In MoDELS Workshops, pages 227–231.
[Bernstein, 2003] Bernstein, P. A. (2003). Applying model management to classical meta data
problems. In CIDR.

106
BIBLIOGRAPHIE 107

[Bézivin, 2004a] Bézivin, J. (2004a). Model engineering for software modernization. In WCRE,
page 4.
[Bézivin, 2004b] Bézivin, J. (2004b). Sur les principes de base de l ingénierie des modèles.
L’OBJET, 10(4):145–157.
[Bézivin, 2009] Bézivin, J. (2009). The three ages of mde. In 2èmesJournées surl Interopérabilité
des Applications d’Entreprise.
[Bézivin et al., 2006] Bézivin, J., Bouzitouna, S., Fabro, M. D. D., Gervais, M.-P.,
Jouault, F., Kolovos, D. S., Kurtev, I. et Paige, R. F. (2006). A canonical scheme
for model composition. In ECMDA-FA, pages 346–360.
[Bézivin et Gerbé, 2001] Bézivin, J. et Gerbé, O. (2001). Towards a precise definition of the
omg/mda framework. In ASE, pages 273–280.
[Blanc, 2005] Blanc, X. (2005). MDA en action. Eyrolles.
[Blay-Fornarino, 2008] Blay-Fornarino, M. (2008). Cours idm, master. Rapport technique,
EPU département SI, Université de Nice.
[Booch et al., 2004] Booch, G., Brown, A. W., Iyengar, S., Rumbaugh, J. et Selic, B.
(2004). An mda manifesto. url http ://www.bptrends.com/publicationfiles/. Rapport tech-
nique, IBM.
[Bordbar et Staikopoulos, 2004] Bordbar, B. et Staikopoulos, A. (2004). On behavioural
model transformation in web services. In ER (Workshops), pages 667–678.
[Broll et al., 2007] Broll, G., Hußmann, H., Prezerakos, G. N., Kapitsaki, G. et Sal-
sano, S. (2007). Modeling context information for realizing simple mobile services. Rapport
technique, Media Informatics Group, LMU, Munich, Germany.
[Bézivin, 2003] Bézivin, J. (2003). Mda : From hype to hope, and reality. keynote lecture. In
UML’2003.
[Bézivin et al., 2005] Bézivin, J., Blay, M., Bouzhegoub, M., Estublier, J., Favre, J.-M.,
Gérard, S. et Jézéquel., J. M. (2005). Rapport de synthèse de las cnrs sur le mda (model
driven architecture). Rapport technique, CNRS.
[Cappiello et al., 2006] Cappiello, C., Comuzzi, M., Mussi, E. et Pernici, B. (2006). Context
management for adaptive information systems. Electr. Notes Theor. Comput. Sci., 146(1):69–
84.
[Carton et al., 2009] Carton, A., Driver, C., Jackson, A. et Clarke, S. (2009). Model-
driven theme/uml. T. Aspect-Oriented Software Development VI, 6:238–266.
[Chaari et al., 2007] Chaari, T., Ejigu, D., Laforest, F. et Scuturici, V.-M. (2007). A
comprehensive approach to model and use context for adapting applications in pervasive en-
vironments. Journal of Systems and Software, 80(12):1973–1992.
[Clark et al., 2004] Clark, T., Evans, A., Sammut, P. et Willan., J. (2004). Applied me-
tamodelling : A foundation for language driven development. Rapport technique, Middlesex
University.
[Clarke, 2002] Clarke, S. (2002). Extending standard uml with model composition semantics.
Sci. Comput. Program., 44(1):71–100.
[Cook, 2006] Cook, S. (2006). Separating concerns with domain specific languages. In JMLC,
pages 1–3.
[Czarnecki et Eisenecker, 1999] Czarnecki, K. et Eisenecker, U. W. (1999). Components
and generative programming. In ESEC / SIGSOFT FSE, pages 2–19.
[Davis, 2003] Davis, J. (2003). Gme : the generic modeling environment. In OOPSLA Compa-
nion, pages 82–83.
[de Farias et al., 2007] de Farias, C. R. G., Leite, M. M., Calvi, C. Z., Pessoa, R. M. et
Filho, J. G. P. (2007). A mof metamodel for the development of context-aware mobile
applications. In SAC, pages 947–952.
BIBLIOGRAPHIE 108

[Dey et Abowd, 1999] Dey, A. K. et Abowd, G. D. (1999). Towards a better understanding

of context and context-awareness. Rapport technique git-gvu-99-22„ Institute of Technology,
Georgia.
[Dey et al., 2001] Dey, A. K., Abowd, G. D. et Salber, D. (2001). A conceptual framework
and a toolkit for supporting the rapid prototyping of context-aware applications. Human-
Computer Interaction Journal, 16(2):97–166.
[Dijkstra, 1974] Dijkstra, E. W. (1974). On the role of scientific thought. Rapport technique,
Burroughs.
[Do et al., 2003] Do, H. H., Kirsten, T. et Rahm, E. (2003). Comparative evaluation of
microarray-based gene expression databases. In BTW, pages 482–501.
[Do et Rahm, 2007] Do, H. H. et Rahm, E. (2007). Matching large schemas : Approaches and
evaluation. Inf. Syst., 32(6):857–885.
[Dolques, 2009] Dolques, X., H. M. . N. C. (2009). From transformation traces to transfor-
mation rules : Assisting model driven engineering approach with formal concept analysis. In
In Supplementary Proceedings of 17TH International Conference On Conceptual Structures
(ICCS’09).
[Dou et al., 2003] Dou, D., McDermott, D. V. et Qi, P. (2003). Ontology translation on the
semantic web. In CoopIS/DOA/ODBASE, pages 952–969.
[Dumas, 2009] Dumas, M. (2009). Case study : Bpmn to bpel model transformation. In
GRABATS-2009.
[Emig et al., 2006] Emig, C., Weisser, J. et Abeck, S. (2006). Development of soa-based
software systems - and evolutionary programming approach. In Proceedings of the Advanced
International Conference on Telecommunications and International Conference on Internet
and Web Applications and Services,, page 182, Guadeloupe. IEEE Computer Society.
[Euzenat et al., 2008] Euzenat, J., Pierson, J. et Ramparany, F. (2008). Dynamic context
management for pervasive applications. Knowledge Eng. Review, 23(1):21–49.
[Fabro et al., 2005] Fabro, M. D. D., Bézivin, J., Jouault, F. et Valduriez, P. (2005). Ap-
plying generic model management to data mapping. In BDA.
[Fabro et Valduriez, 2007] Fabro, M. D. D. et Valduriez, P. (2007). Semi-automatic model
integration using matching transformations and weaving models. In SAC, pages 963–970.
[Fagin et al., 2008] Fagin, R., Kolaitis, P. G., Nash, A. et Popa, L. (2008). Towards a theory
of schema-mapping optimization. In PODS, pages 33–42.
[Falleri et al., 2008] Falleri, J.-R., Huchard, M., Lafourcade, M. et Nebut, C. (2008).
Metamodel matching for automatic model transformation generation. In MoDELS, pages
326–340.
[Favre, 2004] Favre, J.-M. (2004). Foundations of meta-pyramids : Languages vs. metamodels -
episode ii : Story of thotus the baboon1. In Language Engineering for Model-Driven Software
Development.
[Fleurey, 2006] Fleurey, F. (2006). Langage et méthode pour une ingénierie des modèles fiable.
Thèse de doctorat, Équipe d accueil : Triskell - IRISA, l Université de Rennes 1.
[Fleurey et al., 2007] Fleurey, F., Baudry, B., France, R. B. et Ghosh, S. (2007). A generic
approach for automatic model composition. In MoDELS Workshops, pages 7–15.
[France et al., 2007] France, R. B., Fleurey, F., Reddy, R., Baudry, B. et Ghosh, S.
(2007). Providing support for model composition in metamodels. In EDOC, pages 253–266.
[France et Rumpe, 2007] France, R. B. et Rumpe, B. (2007). Model-driven development of
complex software : A research roadmap. In FOSE, pages 37–54.
[Frankel, 2002] Frankel, D. (2002). Model Driven Architecture : Applying MDA to Enterprise
Computing. John Wiley & Sons, Inc., New York, NY, USA.
BIBLIOGRAPHIE 109

[Gamma et al., 1993] Gamma, E., Helm, R., Johnson, R. E. et Vlissides, J. M. (1993). Design
patterns : Abstraction and reuse of object-oriented design. In ECOOP, pages 406–431.
[Gavras et al., 2004] Gavras, A., Belaunde, M., Pires, L. F. et Almeida, J. P. A. (2004).
Towards an mda-based development methodology. In EWSA, pages 230–240.
[Goranson, 2005] Goranson, H. T. (2005). Semantic Distance and Enterprise Integration, cha-
pitre Volume 183/2005, pages 39–52. Springer.
[Gordijn et al., 2006] Gordijn, J., Yu, E. et van der Raadt, B. (2006). E-service design using
i* and e3 value modeling. IEEE Software, 23(3):26–33.
[Grassi et Sindico, 2007] Grassi, V. et Sindico, A. (2007). Towards model driven design of
service-based context-aware applications. In ESSPE, pages 69–74.
[Greenfield et Short, 2003] Greenfield, J. et Short, K. (2003). Software factories : assembling
applications with patterns, models, frameworks and tools. In OOPSLA Companion, pages 16–
27.
[Grønmo et al., 2004] Grønmo, R., Skogan, D., Solheim, I. et Oldevik, J. (2004). Model-
driven web services development. pages 42–45.
[Gu et al., 2005] Gu, T., Pung, H. K. et Zhang, D. (2005). A service-oriented middleware for
building context-aware services. J. Network and Computer Applications, 28(1):1–18.
[Hammoudi et al., 2010] Hammoudi, S., Alouini, W., Lopes, D. et Huchard, M. (2010).
Towards a semi-automatic transformation process in mda : Architecture, methodology and first
experiments. International Journal of Information System Modeling and Design (IJISMD),
issue No 4:1–31.
[Hammoudi et Lopes, 2005] Hammoudi, S. et Lopes, D. (2005). From mapping specification
to model transformation in mda : Conceptualization and prototyping. In WSMDEIS, pages
110–121.
[Hammoudi et al., 2005] Hammoudi, S., Lopes, D. et Bézivin, J. (2005). Approche mda pour
le développement d’applications internet sur des plates-formes services web. modélisation,
transformation et prototypage. Ingénierie des Systèmes d’Information, 10(3):67–90.
[Hausmann et Kent, 2003] Hausmann, J. H. et Kent, S. (2003). Visualizing model mappings
in uml. In SOFTVIS, pages 169–178.
[Henricksen et al., 2005] Henricksen, K., Indulska, J., McFadden, T. et Balasubrama-
niam, S. (2005). Middleware for distributed context-aware systems. In OTM Conferences (1),
pages 846–863.
[Hirschfeld et al., 2008] Hirschfeld, R., Costanza, P. et Nierstrasz, O. (2008). Context-
oriented programming. volume 7, pages 125–151.
[Janvier, 2005] Janvier, J. (2005). Les techniques de transformations dans l approche mda et
application aux services web. Mémoire de D.E.A., Université d’Angers, LERIA.
[Jézéquel, 2004] Jézéquel, J.-M. (2004). A mda approach to model & implement transforma-
tions. In Language Engineering for Model-Driven Software Development.
[Jézéquel, 2006] Jézéquel, J.-M. (2006). Modeling and aspect weaving. In MMOSS.
[Jézéquel, 2008] Jézéquel, J.-M. (2008). Model driven design and aspect weaving. Software
and System Modeling, 7(2):209–218.
[Jézéquel, 2010] Jézéquel, J.-M. (2010). Ingénierie dirigé par les modèles : du design-time au
runtime. Génie Logiciel - Ingéniérie dirigée par les modèles, (93).
[Jordan et al., 2007] Jordan, D. et al. (2007). Web services business process execution language
version 2.0. Rapport technique, OASIS.
[Jouault, 2006] Jouault, F. (2006). Contribution à l étude des langages de transformation de
modèles. Thèse de doctorat, Université de Nantes.
[Jouault et Bézivin, 2006] Jouault, F. et Bézivin, J. (2006). Km3 : A dsl for metamodel
specification. In FMOODS, pages 171–185.
BIBLIOGRAPHIE 110

[Jézéquel J., 2005] Jézéquel J., Fleurey F., D. Z. M. P. P. M. M. C. (2005). Kermeta : Un

langage de méta-modélisation exécutable compatible avec emof/ecore, et son environnement
de développement sous eclipse. In Actes des Premières Journées sur l Ingénierie Dirigée par
les Modèles IDM 05, session Démos&Posters,.
[Kapitsaki et al., 2009] Kapitsaki, G. M., Prezerakos, G. N., Tselikas, N. D. et Venieris,
I. S. (2009). Context-aware service engineering : A survey. Journal of Systems and Software,
82(8):1285–1297.
[Kappel et al., 2007] Kappel, G., Kargl, H., Kramler, G., Schauerhuber, A., Seidl, M.,
Strommer, M. et Wimmer, M. (2007). Matching metamodels with semantic systems - an
experience report. In BTW Workshops, pages 38–52.
[Kath et al., 2004] Kath, O., Blazarenas, A., Born, M., Eckert, K.-P., Funabashi, M. et
Hirai, C. (2004). Towards executable models : Transforming edoc behavior models to corba
and bpel. In EDOC, pages 267–274.
[Keidl et Kemper, 2004] Keidl, M. et Kemper, A. (2004). Towards context-aware adaptable
web services. In Feldman, S. I., Uretsky, M., Najork, M. et Wills, C. E., éditeurs :
Proceedings of the 13th international conference on World Wide Web - Alternate Track Papers
& Posters, WWW 2004, New York, NY, USA. ACM.
[Kessentini et al., 2008] Kessentini, M., Sahraoui, H. A. et Boukadoum, M. (2008). Model
transformation as an optimization problem. In MoDELS, pages 159–173.
[Khelifa, 2010] Khelifa, A. H. (2010). Adaptabilité des architectures orientées services par la
composition des modèles. Mémoire de D.E.A., Mastère de l ISIG-Kairouan, tunisie.
[Kiczales et al., 1997] Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C. V.,
Loingtier, J.-M. et Irwin, J. (1997). Aspect-oriented programming. In ECOOP, pages 220–
242.
[Kleppe et al., 2003] Kleppe, A. G., Warmer, J. et Bast, W. (2003). MDA Explained : The
Model Driven Architecture : Practice and Promise. ADDISON-WESLEY.
[Kolovos et al., 2006] Kolovos, D. S., Paige, R. F. et Polack, F. (2006). The epsilon object
language (eol). In ECMDA-FA, pages 128–142.
[Kurtev et al., 2002] Kurtev, I., Bézivin, J. et Ak ?it, M. (2002). Technological spaces :
An initial appraisal. In In : International Conference on Cooperative Information Systems
(CoopIS), DOA’2002 Federated Conferences, Industrial Track,.
[Lafi, 2010] Lafi, L. (2010). Le matching des métamodèles dans le cadre de l approche mda.
Mémoire de D.E.A., Mastère de l ISIG tunisie.
[Lajili, 2009] Lajili, S. (2009). Proposition d une architecture et d un métamodèle pour un
développement idm des applications sensibles au contexte. Mémoire de D.E.A., Mastère de l
ISIG tunisie (Kairouan), boursier du gouvernement tunisien.
[Lamine Lafi, 2010] Lamine Lafi, Wajih Alouini, S. H. M. M. G. (2010). Metamodels matching :
Issue, techniques and comparison. In Proceedings of FTMDD workshop, ICEIS Conference.
[Lieberherr et al., 2001] Lieberherr, K. J., Orleans, D. et Ovlinger, J. (2001). Aspect-
oriented programming with adaptive methods. Commun. ACM, 44(10):39–41.
[Lieberman, 1993] Lieberman (1993). Watch what I do : programming by demonstration. MIT
Press, Cambridge, MA, USA.
[Lin et Sandkuhl, 2008] Lin, F. et Sandkuhl, K. (2008). A survey of exploiting wordnet in
ontology matching. In IFIP AI, pages 341–350.
[Lopes, 2005] Lopes, D. (2005). Étude et applications de l approche MDA pour des plates-formes
de Service Web. Thèse de doctorat, Université de Nantes.
[Lopes et al., 2006a] Lopes, D., Hammoudi, S. et Abdelouahab, Z. (2006a). Schema Mat-
ching in the context of Model Driven Engineering : From Theory to Practice, chapitre Advances
and Innovations in Systems, Computing Sciences and Software Engineering. Springer.
BIBLIOGRAPHIE 111

[Lopes et al., 2005] Lopes, D., Hammoudi, S., Bézivin, J. et Jouault, F. (2005). Generating
transformation definition from mapping specification : Application to web service platform.
In CAiSE, pages 309–325.
[Lopes et al., 2006b] Lopes, D., Hammoudi, S., de Souza, J. et Bontempo, A. (2006b). Me-
tamodel matching : Experiments and comparison. In ICSEA, page 2.
[MacKenzie et al., 2006] MacKenzie, m., Laskey, K., McCabe, F., Brown, P. et Metz, R.
(2006). Reference model for service oriented architecture 1.0. Rapport technique, OASIS.
[Medini, 2008] Medini (2008). Mediniqvt available at : http ://projects.ikv.de/qvt/. Rapport
technique, Medini.
[Medjahed et al., 2003] Medjahed, B., Bouguettaya, A. et Elmagarmid, A. K. (2003).
Composing web services on the semantic web. VLDB J., 12(4):333–351.
[Melnik et al., 2002] Melnik, S., Garcia-Molina, H. et Rahm, E. (2002). Similarity flooding :
A versatile graph matching algorithm and its application to schema matching. In ICDE, pages
117–128.
[Mendling et Hafner, 2006] Mendling, J. et Hafner, M. (2006). From ws-cdl choreography to
bpel process orchestration. Rapport technique, Vienna University of Economics and Business
Administration.
[Mens et Van Gorp, 2006] Mens, T. et Van Gorp, P. (2006). A taxonomy of model transfor-
mation. Electron. Notes Theor. Comput. Sci., 152:125–142.
[MICROSOFT, 2003] MICROSOFT (2003). dotnet framework, version 1.0.3 microsoft, 2003.
Rapport technique, MICROSOFT.
[Miller et Mukerji, 2003] Miller, J. et Mukerji, J. (2003). Model driven architecture (mda)
1.0.1 guide. Rapport technique, OMG.
[Milner, 2006] Milner, R. (2006). Ubiquitous computing : Shall we understand it ? Comput.
J., 49(4):383–389.
[Molnar et al., 2007] Molnar, Z., Balasubramanian, D. et Lédeczi, A. (2007). An intro-
duction to the generic modeling environment. In In Proceedings of the TOOLS Europe 2007
Workshop on Model-Driven Development Tool Implementers Forum (Zurich, Switzerland).
[Monfort et Hammoudi, 2009] Monfort, V. et Hammoudi, S. (2009). Towards adaptable soa :
Model driven development, context and aspect. In ICSOC/ServiceWave, pages 175–189.
[Monfort et Hammoudi, 2010] Monfort, V. et Hammoudi, S. (2010). When parameterized
model driven development supports aspect based soa. International Journal of E-Business
Research (IJEBR), 6:22.
[Morin et al., 2009] Morin, B., Barais, O., Jézéquel, J.-M., Fleurey, F. et Solberg, A.
(2009). Models@ run.time to support dynamic adaptation. IEEE Computer, 42(10):44–51.
[Muller, 2006] Muller, A. (2006). De la modélisation objet des logiciels à la metamodélisation
des langages informatiques. Thèse de doctorat, L Université de Rennes 1.
[Nezhad et al., 2006] Nezhad, H. R. M., Benatallah, B., Casati, F. et Toumani, F. (2006).
Web services interoperability specifications. IEEE Computer, 39(5):24–32.
[Nguyen, 2008] Nguyen, T. (2008). Codèle : Une approche de composition de modèles pour
la Construction de Systèmes à Grande Échelle. Thèse de doctorat, UNIVERSITÉ JOSEPH
FOURIER - GRENOBLE I.
[Nierstrasz et Meijler, 1995] Nierstrasz, O. et Meijler, T. D. (1995). Research directions in
software composition. ACM Comput. Surv., 27(2):262–264.
[Oinn et al ., 2004] Oinn, T. et al . (2004). A tool for the composition and enactment of bioin-
formatics workflows. Bioinformatics journal, 17(20):3045–3054.
[OMG, 2001] OMG (2001). Omg unified modeling language specification, version 1.4. Rapport
technique, OMG.
BIBLIOGRAPHIE 112

[OMG, 2002a] OMG (2002a). Meta object facility (mof) specification - version 1.4, formal/01-
11-02. Rapport technique, OMG.
[OMG, 2002b] OMG (2002b). "meta object facility (mof) specification" version 1.4. Rapport
technique, OMG.
[OMG, 2002c] OMG (2002c). Request for proposal : Mof 2.0 query/views/transformations rfp,
october 2002. disponible sur http ://www.omg.org/docs/ad/02-04-10.pdf,. Rapport technique,
OMG.
[OMG, 2002d] OMG (2002d). Xml metadata interchange (xmi) specification, version 1.2,. Rap-
port technique, OMG.
[OMG, 2004] OMG (2004). Enterprise collaboration architecture (eca) specification, omg
formal/04-02-01. Rapport technique, OMG.
[OMG, 2005] OMG (2005). Qvt final adopted spec., http ://www.omg.org/docs/ptc/05-11-01.
Rapport technique, OMG.
[OMG, 2006a] OMG (2006a). Mof2.0, http ://www.omg.org/cgi-bin/doc ?formal/06-01-01.
Rapport technique, OMG.
[OMG, 2006b] OMG (2006b). Ontology defnition metamodel. omg specification,. Rapport tech-
nique, The Object Management Group OMG, IBM, and Sandpiper Software.
[OMG, 2007] OMG (2007). Unified modeling language (uml) 2.1.2 superstructure, november
2007. final adopted specification. Rapport technique, OMG.
[OMG, 2008] OMG (2008). Qvt 2.0 transformation spec,
http ://www.omg.org/spec/qvt/1.0/pdf/. Rapport technique, OMG.
[OMG, 2009] OMG (2009). Bpmn 1.2, available at http ://www.omg.org/spec/bpmn/1.2/. Rap-
port technique, OMG.
[OMONDO., 2004] OMONDO. (2004). Omondo eclipse uml, october 2004. disponible sur
http ://www.omondo.com,. Rapport technique, Omondo.
[Ou et al., 2006] Ou, S., Georgalas, N., Azmoodeh, M., Yang, K. et Sun, X. (2006). A
model driven integration architecture for ontology-based context modelling and context-aware
application development. In ECMDA-FA, pages 188–197.
[Parnas, 1972] Parnas, D. L. (1972). On the criteria to be used in decomposing systems into
modules. Commun. ACM, 15(12):1053–1058.
[Pascoe, 1998] Pascoe, J. (1998). Adding generic contextual capabilities to wearable computers.
In Press, I. C., éditeur : 2nd International Symposium on Wearable Computers, pages 92–99,
Los Alamitos, California.
[Picek, 2009] Picek, R. (2009). Suitability of modern software development methodologies for
model driven development. JIOS, NO. 2, 33:285–295.
[Pickin et al., 2007] Pickin, S., Jard, C., Jéron, T., Jézéquel, J.-M. et Traon, Y. L. (2007).
Test synthesis from uml models of distributed software. IEEE Trans. Software Eng., 33(4):252–
269.
[Pires et al., 2004] Pires, L. F., van Sinderen, M. J., de Farias, C. R. G. et Almeida, J.
P. A. (2004). Use of models and modelling techniques for service development. In Mendes,
M. J., Suomi, R. et Passos, C., éditeurs : Third IFIP Conference on e-Commerce, e-Business
and e-Government (I3E 2003), Guarujá, São Paulo, Brazil, pages 441–456. Kluwer Academic
Publishers.
[Pottinger et Bernstein, 2003] Pottinger, R. et Bernstein, P. A. (2003). Merging models
based on given correspondences. In VLDB, pages 826–873.
[Prezerakos et al., 2007] Prezerakos, G. N., Tselikas, N. D. et Cortese, G. (2007). Model-
driven composition of context-aware web services using contextuml and aspects. In Proceedings
of 2007 IEEE International Conference on Web Services (ICWS 2007), pages 320–329, Salt
Lake City, Utah, USA. IEEE Computer Society.
BIBLIOGRAPHIE 113

[Rahm et Bernstein, 2001] Rahm, E. et Bernstein, P. A. (2001). A survey of approaches to

automatic schema matching. VLDB J., 10(4):334–350.
[Ramollari et al., 2007] Ramollari, E., Dranidis, D. et Simons, A. J. H. (2007). A survey
of service oriented development methodologies. Rapport technique, South East European
Research Centre (SEERC).
[Rashid et al., 2003] Rashid, A., Moreira, A. M. D. et Araújo, J. (2003). Modularisation
and composition of aspectual requirements. In AOSD, pages 11–20.
[Reenskaug, 1979] Reenskaug, T. (1979). Mvc- models-views-controllers. Rapport technique,
XEROX PARC 1978-79.
[Saha et Mukherjee, 2003] Saha, D. et Mukherjee, A. (2003). Pervasive computing : A para-
digm for the 21st century. IEEE Computer, 36(3):25–31.
[Salber et al., 1999] Salber, D., Dey, A. K. et Abowd, G. D. (1999). The context toolkit :
Aiding the development of context-enabled applications. In CHI, pages 434–441.
[Satyanarayanan, 2001] Satyanarayanan, M. (2001). Interview : Mahadev satyanarayanan on
mobile and pervasive computing. IEEE Distributed Systems Online, 2(6).
[Schilit et Theimer, 1994] Schilit, B. et Theimer, M. (1994). Disseminating active map infor-
mation to mobile hosts. IEEE Network, 8:22–32.
[Seidewitz, 2003] Seidewitz, E. (2003). What models mean. IEEE Software, 20(5):26–32.
[Serral et al., 2010] Serral, E., Valderas, P. et Pelechano, V. (2010). Towards the model
driven development of context-aware pervasive systems. Pervasive and Mobile Computing,
6(2):254–280.
[Sheng et Benatallah, 2005] Sheng, Q. Z. et Benatallah, B. (2005). Contextuml : A uml-based
modeling language for model-driven development of context-aware web services. In Proceedings
of 2005 International Conference on Mobile Business (ICMB 2005), pages 206–212, Sydney,
Australia.
[Shvaiko et Euzenat, 2005] Shvaiko, P. et Euzenat, J. (2005). A survey of schema-based mat-
ching approaches. pages 146–171.
[Skogan et al., 2004] Skogan, D., Grønmo, R. et Solheim, I. (2004). Web service composition
in uml. In EDOC, pages 47–57.
[Soley, 2000] Soley, R. (November 2000). Model driven architecture (mda), draft 3.2. Rapport
technique, Object Management Group, Inc.,.
[Steinberg et al., 2009] Steinberg, D., Budinsky, F., Paternostro, M. et Merks, E. (2009).
EMF : Eclipse Modeling Framework 2.0. Addison-Wesley Professional.
[Stevens, 1994] Stevens, W. R. (1994). TCP/IP Illustrated. Addison-Wesley.
[Strang et Linnhoff-Popien, 2004] Strang, T. et Linnhoff-Popien, C. (2004). A context mo-
deling survey.
[SUN, 2004] SUN (2004). Javaweb services developer pack, march 2004. disponible sur http ://-
java.sun.com/webservices,. Rapport technique, SUN.
[Sztipanovits et al., 2005] Sztipanovits, J., Glossner, C. J., Mudge, T. N., Rowen, C.,
Sangiovanni-Vincentelli, A. L., Wolf, W. et Zhao, F. (2005). Grand challenges in
embedded systems. In CODES+ISSS, page 333.
[TOPCASED-WP5, 2008] TOPCASED-WP5 (2008). Guide méthodologique pour les trans-
formations de modèles. Rapport technique, IRIT/MACAO.
[Triskel, 2005] Triskel (2005). Kermeta, irisa, rennes, http ://www.irisa.fr/triskell,
http ://www.kermeta.org,. Rapport technique, IRISA.
[Truong et Dustdar, 2009] Truong, H. L. et Dustdar, S. (2009). A survey on context-aware
web service systems. International Journal of Web Information Systems, 5(1):5–31.
[Vale, 2009] Vale, S. (2009). Approche Dirigée par les Modèles pour le Développement des Ap-
plications Sensibles au Contexte. Thèse de doctorat, Université d’Angers.
BIBLIOGRAPHIE 114

[Vale et Hammoudi, 2009a] Vale, S. et Hammoudi, S. (2009a). Comode : A framework for the
development of context-aware applications in the context of mde. In ICIW, pages 261–266.
[Vale et Hammoudi, 2009b] Vale, S. et Hammoudi, S. (2009b). Odm-based architecture for
the development of mobile context-aware applications. In PETRA.
[Vallejos et al., 2007] Vallejos, J., Ebraert, P., Desmet, B., Cutsem, T. V., Mostinckx,
S. et Costanza, P. (2007). The context-dependent role model. In DAIS, pages 1–16.
[Varró et Balogh, 2007] Varró, D. et Balogh, A. (2007). The model transformation language
of the viatra2 framework. Sci. Comput. Program., 68(3):214–234.
[Voigt et al., 2010] Voigt, K., Ivanov, P. et Rummler, A. (2010). Matchbox : combined meta-
model matching for semi-automatic mapping generation. In SAC, pages 2281–2288.
[W3C, 2001] W3C (2001). Web services description language (wsdl) 1.1. Rapport technique,
W3C.
[Warmer, 2002] Warmer, J. (2002). The role of ocl in the model driven architecture. In FIDJI,
page 202.
[Weiser, 1991] Weiser, M. (1991). The computer for the 21st century. Human-computer inter-
action : toward the year 2000, 0:933–940.
[Willink, 2003] Willink, E. (2003). Umlx - a graphical transformation language for mda. In
Workshop on Model Driven Architecture Foundations and Applications, , pages 13-24, June
2003.
[Wimmer et al., 2007] Wimmer, M., Strommer, M., Kargl, H. et Kramler, G. (2007). To-
wards model transformation generation by-example. In HICSS, page 285.
[Yu et al., 2007] Yu, X., Zhang, Y., Zhang, T., Wang, L., Hu, J., Zhao, J. et Li, X. (2007).
A model-driven development framework for enterprise web services. Information Systems
Frontiers, 9(4):391–409.