Institut Francophone International
MÉMOIRE DE FIN D’ÉTUDES
MASTER D’INFORMATIQUE
Option : Réseaux et Systèmes Communicants
Année académique : 2013 - 2014
Sujet : Études de l’approche d’ingénierie dirigée
par les modèles pour le développement des
applications mobiles
Auteur :
Encadrant :
SIRISANG Jariya
Étudiant de l’Institut
Francophone International
HO Tuong Vinh, Ph.D.
L’Institut Francophone
(IFI)
21 janvier 2015
International (IFI)
REMERCIEMENTS
Je voudrais tout d’abord remercier Monsieur Victor Moraru qui m’a conseillé ce
stage pour la fin de mes études.
Je tiens à remercier Monsieur HO Tuong Vinh qui m’a proposé ce sujet intéressant
et encadré pendant six mois de mon stage. Je le remercie de son contact chaleureux, ses
conseils, ses soutiens et ses encouragements.
Merci également toutes les réponses de mes amis qui m’aident beaucoup de finir
ce travail. Merci enfin à mes parents pour leur soutien et leur encouragement à tout
l’instant.
i
RESUME
Ce sujet du stage situe dans le domaine du génie logiciel. Il vise à étudier l’approche
d’ingénierie dirigée par les modèles pour le développement des applications mobiles.
Puisque la consommation des appareils mobiles augmente rapidement, les sociétés
des applications mobiles ont envie de profiter cette situation. Mais il n’est pas facile de
développer une application qui peut fonctionner sur les plateformes différentes telque
iOS, Android, WindowsPhone, BlackBerry etc. Il est nécessaire de développer l’application séparément pour chaque plateforme. En général, pour développer une application,
on suit l’étape d’interroger des exigences, de faire l’analyse, ensuite on conçoit la conception et commence à coder. Ce processus prend beaucoup de temps et de coûts. Et il aurait
un grand problème lorsque le produit ne correspond pas aux exigences.
Dans le cadre de ce stage, on propose une solution qui applique le principe de
l’approche d’ingénierie dirigée par les modèles pour le développement des applications
mobiles. Celle-ci aiderait au développeur de réduire le temps et le coût de développement
grâce aux avantages des modèles. L’idée de l’approche d’ingénierie dirigée par les modèles
est que le développement de l’application est guidé par les modèles. Elle est très bien
adaptée avec l’approche
Cross-platform
afin de réaliser les applications mobiles
pour des différences systèmes d’exploitation. Cela réduit le temps et des ressources pour
le développement. Le code est automatiquement généré à partir des modèles qui sont
définis par le développeur.
Mot-clé : Ingénierie dirigée par les modèles, Application mobile, Multi-plateforme,
DSL, Modélisation.
ii
ABSTRACT
This subject of the internship is in the field of software engineering. It aims to
study the mobile application development approach particularly in the engineering model
driven approach.
Since the consumption of mobile devices augumente quickly, the manufacturer of
mobiles applications would like to take benefit of this situation. But it is not easy to
develop an application that could execute on different platforms such as IOS, Android,
WindowsPhone, Blackberry etc. It is necessary to develop separately for each platform.
In general, to develop an application, we follow the step of getting the requirements, analyze the requirements and then designing and coding. This process takes many
time and costs. And it would be a big problem when the product does not correspond
to user requirements.
We propose a solution that applies Model driven engineering approach for the
development of mobiles applications, which will help to reduce the development’s time
and costs through the advantages of models.
The idea for the approach of model driven engineering that is the application
development is guided by the models. It is very well suited to the ”Cross-platform”
approach to realize the mobile application for the differences in operating systems. It
reduces development’s time and resources. The source code is automatically generated
from the models that are defined by the developer. The generated application is truly
native and causes less of the problems of non-response requiments.
Keyword : Model Driven Engineering, Mobile Application, Cross- platform, DSL, Modelling.
iii
Table des matières
REMERCIEMENTS
i
RESUME
ii
ABSTRACT
iii
Contents
iv
List of Figures
v
List of Tables
vi
1 Introduction
1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Motivation et objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Plan du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
3
2 Recherche bibliographique
4
2.1 Quelques Frameworks pour le développement des applications mobiles . . 4
2.1.1 Adobe AIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 jQuery Mobile Framwork . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 MD2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 IDM :Ingénierie Dirigée par les Modèles pour le développement des logiciels 7
2.2.1 La définition de l’IDM . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 L’idée et l’objectif de l’IDM . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Les approches de l’IDM . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3.1 Modèle-Integrated Computing (MIC) . . . . . . . . . . . 9
2.2.3.2 Les usines logicielles (Software Factories) . . . . . . . . . 9
2.2.3.3 L’approche MDA : Model-Driven Architecture . . . . . . 10
2.2.4 La transformation de modèle . . . . . . . . . . . . . . . . . . . . . 11
2.2.5 Les outils de l’IDM . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.5.1 Kermeta . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.5.2 MetaEdit+ . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.5.3 EMF (Eclipse-EMF-website) . . . . . . . . . . . . . . . . 12
2.3 Intérêt de l’approche d’ingénierie dirigée par les modèles pour le développement
des applications mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
iv
Contents
v
3 Solution proposée
3.1 Méthodologie et technique de l’approche MDA . . . .
3.1.1 Méthodologie de l’approche MDA . . . . . . .
3.1.2 Techniques disponibles de l’approche MDA . .
3.2 Solution proposée . . . . . . . . . . . . . . . . . . . . .
3.2.1 Méta-modélisation . . . . . . . . . . . . . . . .
3.2.1.1 Conception de la méta-modélisation .
3.2.2 Générateur de code . . . . . . . . . . . . . . . .
3.2.2.1 Conception pour le développement du
3.2.2.2 Plateforme cible (Android) . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
générateur de
. . . . . . . .
4 Implémentation et Expérimentation
4.1 Implémentation de la solution . . . . . . . . . . . . . . .
4.1.1 Implémentation de langage dédié : DSL . . . . .
4.1.1.1 Application . . . . . . . . . . . . . . . .
4.1.1.2 Model . . . . . . . . . . . . . . . . . . .
4.1.1.3 View . . . . . . . . . . . . . . . . . . .
4.1.1.4 Control . . . . . . . . . . . . . . . . . .
4.1.2 Implémentation de générateur de code . . . . . .
4.1.2.1 Le module generateManifest . . . . .
4.1.2.2 Le module generateView . . . . . .
4.1.2.3 Le module generateResource . . . .
4.1.2.4 Le module generateActivity . . . .
4.2 Application de la méthode proposée . . . . . . . . . . .
4.2.1 Processus de développement . . . . . . . . . . . .
4.2.2 Application 1 : Une application simple . . . . . .
4.2.2.1 Description de l’application . . . . . . .
4.2.2.2 Résultat . . . . . . . . . . . . . . . . .
4.2.2.3 Conclusion . . . . . . . . . . . . . . . .
4.2.3 Application 2 : Une application de jeu Sudoku
4.2.3.1 Description de l’application . . . . . . .
4.2.3.2 Résultat . . . . . . . . . . . . . . . . .
4.2.3.3 Conclusion . . . . . . . . . . . . . . . .
4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
. . .
. . .
code
. . .
15
15
15
16
19
20
20
21
21
22
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
25
26
27
29
31
33
33
33
33
34
34
34
35
36
37
37
37
38
40
40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Conclusion et perspective
42
5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A Modèle PIM de l’application simple avec DSL
44
B Modèle PIM de l’application de jeu
45
Bibliographie
Sudoku avec DSL
47
Table des figures
2.1
2.2
2.3
2.4
L’Adobe AIR . . . . . . . .
Le jQuery Mobile Framwork
Le PhoneGap . . . . . . . .
L’architecture de MDA . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 5
. 6
. 7
. 10
3.1
3.2
3.3
3.4
3.5
3.6
3.7
Le principe de processus de MDA . . . . . . . . . . . . . . .
L’hiérarchie de modèles de MDA . . . . . . . . . . . . . . . .
Le plan du flux de MDA . . . . . . . . . . . . . . . . . . . . .
La vue l’ensemble de solution . . . . . . . . . . . . . . . . . .
L’étape de réalisation de PIM . . . . . . . . . . . . . . . . . .
L’étape de réalisation de générateur . . . . . . . . . . . . . .
Les répertoires et fichiers nécessaires de l’application Android
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
17
18
19
20
21
22
4.1
4.2
4.3
4.4
4.5
Le concept de DSL . . . . . . . . . . . . . . . . . .
L’architecture de l’Acceleo . . . . . . . . . . . . . .
Le concept de la transformation pour la plateforme
La configuration de l’exécution d’Acceleo . . . . .
La location du code généré . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
32
32
35
35
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
Android
. . . . .
. . . . .
.
.
.
.
.
Liste des tableaux
4.1
4.2
4.3
4.4
4.5
4.6
La
La
La
La
La
La
comparaison
comparaison
comparaison
comparaison
comparaison
comparaison
d’interface
d’interface
d’interface
d’interface
d’interface
d’interface
de
de
de
de
de
de
Main .
Second
Main .
Help . .
level . .
Game .
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
38
38
39
39
Chapitre 1
Introduction
Le premier chapitre concerne la présentation de la problématique du sujet Étude
de l’approche d’ingénierie dirigée par les modèles pour le développement des applications
mobiles . On présente la motivation et l’objectif du travail.
1.1
Problématique
Actuellement, la tendance de l’utilisation des appareils mobiles (par exemple.
Smartphone, Tablet, Phablet etc.) augmente rapidement. Grâce à cela, le marché des
applications mobiles est de plus en plus élargi. Chaque jour, les sociétés lancent des
nouvelles applications pour répondre à l’augmentation de consommation des appareils
mobiles et aux besoins des utilisateurs.
Cependant, des applications mobiles sont souvent fournis pour plusieurs systèmes
d’exploitation (Android, iOS, WindowsPhone). Il est essentiel de développer séparément
pour chaque plateforme en raison de détails différents dans la programmation des interfaces, des bibliothèques, et des langages de programmation.
Dans l’industrie de développement du logiciel, on trouve un grand besoin du
développement. C’est un effort de réaliser un logiciel complexe avec la courte durée
et moins de budget. Cette situation existe aussi dans le développement des applications pour les appareils mobiles. Puisque l’utilisation des appareils mobiles est de plus
en plus populaire, la compétition entre des sociétés d’application mobile est plus forte.
Sûrement, la société qui peut recevoir le plus de bénéfits est celle qui peut produire plus
rapidement et dépenser moins de ressource du développement des applications pour la
sortie des nouveaux appareils mobiles et pour les différences plateformes.
1
Chapter 1. Introduction
2
Les applications sont séparément fournis pour les différents plateformes, néanmoins
les fonctionnalités pour chaque plates-formes sont de mêmes. Donc il existe la répétition
de code. Si l’on peut éviter la répétition dans le développement, on peut aussi diminuer
le temps et le budget.
Les chercheurs tentaient d’étudier des approches qui peuvent résoudre des problématiques sur :
– L’évitement de répétition de code avec une structure généralisée pour la réduction du temps de développement.
– La probabilité de baisser d’erreur ou faciliter de la correction.
– Le changement dans le code. Il est moins compliqué de modifier si des fonctionnalités sont changées.
– La capacité de rédiger des fonctionnalités pour les différents langages, en les
appelants une fois et de réduire le temps de développement. Par exemple, la
définition d’une entité en Java, Objectif c ,c# peut être faite par écrivant une
seule fois dans la langue spécifique à un domaine et de générer les différentes
versions.
– Généralement, la méthode de développement d’un logiciel commence par l’étape
de réunir des requêtes et puis on analyse ces requêtes afin d’avoir la conception du produit. En suite, la conception est prise à l’implémentation du logiciel. Pareillement pour celle de l’application mobile, à l’étape d’implémentation,
les développeurs devraient réaliser l’implémentation qui supporte les différences
plates-formes pour la raison mentionné ci-dessus. En plus, cette méthode pourrait aussi agrandir l’intervalle entre des requêtes et l’implémentation si la conception n’est pas bien conçue. Cela provoque un grand problème d’économique.
1.2
Motivation et objectif
L’approche d’ingénierie dirigée par les modèles est une nouvelle approche intéres-
sante pour le développement des applications mobiles. Revoir sur la méthode de développement originale, on mettra à la place de la conception par les modèles de l’application. Cela peut simplifier le développement et réduire l’intervalle entre des requêtes et
l’implémentation. Le modèle représente clairement l’idée de l’application grâce à l’aide
des outils pour modéliser un modèle comme UML (Unified Modeling Language) et s’il
y a des erreurs, il est facile et rapide de corriger en revoyant et modifiant des modèles.
L’idée de l’approche d’ingénierie dirigée par les modèles est que le développement
de l’application est guidé par les modèles. Elle est très bien adaptée avec l’approche
Chapter 1. Introduction
Cross-platform
3
afin de réaliser l’application mobile pour des différentes systèmes
d’exploitation, cela réduit le temps et des ressources de développement. Le code est
automatiquement généré à partir des modèles qui sont définis par le développeur. Le
code de l’application générée est de même avec le code réalisé manuellement et amène
moins de problème d’insatisfaction des requêtes.
Ce stage a l’objectif d’étudier l’approche d’ingénierie dirigée et découvrir ses avantages pour le développement des applications mobiles. Pour ce stage, je dois avoir la
compréhension sur cet approche en étudiant des travaux qui ont été fait et faire la
comparaison, donner des point fort et des points faibles de l’approche.
1.3
Plan du document
Ce rapport se compose 5 chapitres qui sont le produit de l’étude de l’approche
d’ingénierie dirigée par les modèles pour le développement des applications mobiles.
Dans le premier chapitre, on a présenté la problématique, la motivation et l’objectif de
ce sujet du stage. On va présenter dans le deuxième chapitre sur la recherche de bibliographies qui concernent notre travail, et les travaux qui ont déjà existants. D’ailleurs
on représente aussi les descriptions de l’approche d’ingénierie dirigée par les modèles.
Dans le troisième chapitre, on propose une solution pour l’implémentation de l’approche
d’ingénierie dirigée par les modèles pour le développement des applications mobiles. Le
chapitre suivant est l’implémentation de la solution proposé et l’expérimentation. En fin,
le cinquième chapitre, on donne l’analyse sur le travail, la conclusion et les perspectives.
Chapitre 2
Recherche bibliographique
Ce chapitre est une présentation de la recherche de bibliographie sur les travaux existants pour faciliter le développement des applications mobiles et sur l’approche d’ingénierie dirigée par les Modèles(IDM) pour le développement des logiciels.
Commençant par la discussion sur les techniques qui nous permettent de développer
plus rapide et facilement une application mobile. En suite, on va présenter l’approche
d’ingénierie dirigée par les Modèles(IDM) qui est un autre choix pour le développement
des logiciels et à la fin, on vous parle des outils de cette approche.
2.1
Quelques Frameworks pour le développement des applications mobiles
Comme on a parlé dans le chapitre précédant de problématique dans le dévelop-
pement des applications mobiles, les chercheurs font des efforts afin de trouver la solution pour faciliter le développement des applications mobiles. Et l’approche de multiple
plateforme (Cross-platform) [21, 22] est considérée comme l’approche qui est la plus
populaire pour l’instant. On présente des exemples de quelques travaux qui aident aux
développeurs de développer des applications mobiles.
2.1.1
Adobe AIR
À partir de 2011, il était clair qu’Adobe AIR[11] a été choisi comme la plateforme
au deuxième rang dans le développement des applications pour les appareils mobile
d’Android de Google et la première plateforme pour obtenir un soutien officiel afin de
développer des applications pour le Blackberry Playbook.
4
Chapter 2. Recherche bibliographique
5
Au début Adobe AIR est inventé pour l’objectif de faire Runtime sur l’environnement de Microsoft Windows et d’Apple OS X, car cela permet aux développeurs de créer
des applications avec la technologie Adobe qui peut être mis au travail sur les systèmes
d’exploitation précités sans modifier l’application.
Le moment où Adobe AIR est populaire dans la section du développement de
l’application de web, les produits chez Apple comme iPhone et iPad lance la nouvelle
technologie du contrôle des appareils indépendant de la sourire et le clavier. C’est la
raison pour laquelle chez Adobe trouve la popularité de cette nouvelle technologie et
améliore l’Adobe AIR afin de soutenir la nouvelle technologie d’écran tactile pour les
appareils mobiles. Adobe AIR devient le premier choix qui est développé pour fonctionner sur cette nouvelle technologie et consiste à travailler en étroite collaboration des
appareils mobiles et les tablettes de Google Android et RIM.
Adobe AIR sur des appareils mobiles est adapté à consommer moins de ressources
par rapport à celui sur un PC. Ceci permet aux développeurs d’ignorer le problème du
manque de ressource.
Grâce au concept de ne pas dépendre trop de langage de programmation, Adobe
AIR peut développer dans deux façons. C’est la façon de l’utilisation d’Actionscript 3 et
Adobe Flex framework, une autre façon est de l’utilisation HTML, CSS et Javascript.
Toutefois tous les façons sont implémentés par des outils d’Adobe par exemple Adobe
Flash Professionnel CS 5, Adobe Flash Builder 4.5 et Adobe Dreamweaver CS 5. Pour
développeurs, il faut avoir connaissance sur le langage de programmation orienté objet
(OOP).
Cependant Adobe AIR est développé pour la technologie de web, il a besoin de
l’Internet afin d’accéder à l’application comme le site web général.
Figure 2.1: L’Adobe AIR
Chapter 2. Recherche bibliographique
2.1.2
6
jQuery Mobile Framwork
jQuery Mobile [15] nous permet de créer un site web mobile plus facilement. Avec
laquelle nous ne devons pas perdre le temps à la conception de l’interface de l’utilisateur
(UI). Cela nous permet aussi de construire une application mobile qui peut être adapté
avec PhoneGap pour pouvoir soumis à l’App Store d’Apple ou Android ainsi.
Les avantages de jQuery Mobile :
– Une fois de la réalisation, il est possible de fonctionner sur tous les plateforme
des appareils tels que iOS, Android, BlackBerry, Windows Phone etc.
– La collaboration avec le Framework PhoneGap, nous permet de réaliser facilement une application. Il n’a pas besoin d’apprendre le langage du système tels
que la plateforme iOS d’apprendre Objective-C langue et d’apprendre Java pour
la plateforme Android.
– Il peut être utilisé avec le langage de programmation PHP et la base de données
MySQL, il n’y a pas de différence de la programmation sur PHP et MySQL en
général.
– Il y a beaucoup de beaux thèmes à choisir. Nous ne devons pas perdre de temps
à écrire CSS ou Javascript pour les interfaces, il permet aux développeurs de
travailler plus rapidement.
Les points faibles de jQuery Mobile : Le développement des sites web et des applications sur des appareils mobiles en utilisant jQuery Mobile, il faut admettre que
certaines capacités puisse commencer à utiliser un langage spécifique (langue maternelle) sont développés. Comme l’interface matérielle de smartphones, mais certains App
Mobile qui n’a pas besoin de trucs, rien de plus. Il fonctionne comme un site Web et
d’afficher une excellente sur les smartphones, il est interdit d’utiliser le jQuery Mobile
est un excellent choix pour l’application des applications de développeur.
Figure 2.2: Le jQuery Mobile Framwork
2.1.3
PhoneGap
PhoneGap [10] est un Framework basé sur le principe de Cross-Platform. L’idée
de PhoneGap est d’envelopper le code qui est créé par HTML, CSS, JavaScript dans une
Chapter 2. Recherche bibliographique
application par le
Wrapper
7
afin d’obtenir des applications pour chaque plateforme.
Cependant PhoneGap n’est pas approprié avec l’application de grandes fonctionnalités
car il ne supporte pas certaines fonctions. L’application générée par PhoneGap n’est pas
l’application du langage original de plateforme cible.
Figure 2.3: Le PhoneGap
2.1.4
MD2
Le Framework MD2 [4] implémente l’idée de la transformation automatique pour
générer le code source à partir du développement des modèles. Ce fait permet aux
plusieurs transformation de générer le code pour les différents cibles plateforme. L’intérêt
de cette approche n’est que le Cross-Platform mais c’est aussi le cycle du développement
rapide grâce à la propriété de réutilisable et de traçabilité.
Le développement des applications par MD2 est divisé en 3 phrases : Tout d’abord,
le développeur décrit l’application par un modèle de textuelle. Deuxièmement, un générateur de code pour chacune des plateformes supportées transforme le modèle vers le code
source de la plateforme respective avec des éléments structurels nécessaires tels que les
fichiers de projet. Pour le moment, les générateurs de code pour Android et iOS sont
disponibles. A la troisième phase, le développeur doit compiler le code source généré.
Le langage de MD2 est décrit sous le cadre de modèle Model-View-Controller
(MVC)[16]. Le modèle d’une application est séparé en partie de modèle, de vue, et
de contrôleur. Dans les applications générées, le contrôleur est basé sur un système
d’événements, qui gère toutes les actions de l’utilisateur ainsi que des événements internes ou périphériques. Les développeurs spécifient les actions dans le modèle, avant
d’être prises si un événement se produit.
2.2
IDM :Ingénierie Dirigée par les Modèles pour le développement des
logiciels
Dans le processus général pour développement de logiciel, il est difficile lorsqu’on
a besoin d’ajouter des fonctions ou de corriger des erreurs. Cela peut aussi provoquer le
Chapter 2. Recherche bibliographique
8
problème de budget. Les chercheurs donc étudient des approches pour diminuer l’écart
entre les exigences et le produit final. Et l’Ingénierie Dirigée par les Modèles est une
approche qui peut résoudre ce problème. On va représenter les détails de cette approche
à la suit.
2.2.1
La définition de l’IDM
L’Ingénierie Dirigée par les Modèles(IDM) [1, 12] utilisée sous le terme anglais de
MDE (Model Driven Engineering) est une discipline du génie logiciel par laquelle tout ou
partie d’une application informatique est engendrée à partit de modèles. Il est nécessaire
de fournir des outils flexibles et fiables pour la gestion automatique des modèles ainsi
que des langages dédiés pour leurs transformations, pour vocation l’automatisation du
développement de logiciel en fournissant des outils et des langages de la transformation.
2.2.2
L’idée et l’objectif de l’IDM
Un modèle est défini comme une abstraction d’un système. Il est essentiel qu’un
modèle peut être utilisé pour répondre à des questions sur le système modélisé.
On peut dire qu’un modèle est une forme simple pour représenter l’idée d’un
système. Il permet aux intervenants de comprendre facilement et correctement le concept
de système. Cela aide aux développeurs de réaliser le système satisfait aux besoins exacts
de l’utilisateur.
L’ingénierie Dirigée par les Modèles (IDM) relève ces avantages de modèle pour
le développement de logiciel. L’IDM fournit des modèles afin d’exprimer séparément
des préoccupations des utilisateurs, des concepteurs, etc. L’idée est d’interpréter des
exigences d’utilisateur en forme des modèles, et puis considérer ces modèles comme la
première source du processus de développement. En suite, les modèles seraient transformés par la machine, c’est l’idée de
transformations de modèles
. L’objectif finale
est de rendre opérationnels les modèles pour génération de code exécutable.
Pour formaliser et transformer des modèles, l’IDM fournit des outils et des langages
pour réaliser la transformation et formaliser des modèles. On les appelle les langages de
modélisation et les langages de transformation dont on parlera plus tard.
Chapter 2. Recherche bibliographique
2.2.3
9
Les approches de l’IDM
Nous avons présenté dans la partie précédant le concept et l’idée de l’IDM. Pour
mieux comprendre son principe, on représentera les principales approches de développement logiciel basées sur l’IDM.
2.2.3.1
Modèle-Integrated Computing (MIC)
Cette approche est proposée au milieu des années 90. Au début le MIC est conçu
pour le développement des systèmes embarqués complexes. L’idée de l’approche MIC
est comme le principe de l’IDM, c’est que considérer des modèles comme le centre
de processus de développement d’application. Le MIC fournit une technologie pour la
spécification et l’utilisation de DSMLs, des outils de méta-programmation, des techniques de vérification et de transformation de modèles.
L’architecture de MIC est conçue en 3 niveaux suivants :
– Le niveau Meta fournit des langages de méta-modélisation, des méta-modèles,
des environnements de méta-modé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 (MIPS) est constitué de langages de modélisation spécifiques à un
domaine, et de chaı̂nes d’outils pour la construction et l’analyse de modèles, la
synthèse d’applications.
– Le niveau Application représente les applications logicielles adaptables. Dans ce
niveau, les programmes exécutables sont spécifiés en termes de composition de
plateformes (CORBA, etc.)
2.2.3.2
Les usines logicielles (Software Factories)
L’idée des usines logicielles est d’adapter ces caractéristiques au développement de
logiciels. Les deux premiers points correspondent à la spécialisation des éditeurs 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 de transformateurs spécifiques. Le dernier point
correspond à la réutilisation de composants logiciels sur étagères. L’environnement de
développement Visual Studio .Net 2005 a é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.
Chapter 2. Recherche bibliographique
2.2.3.3
10
L’approche MDA : Model-Driven Architecture
L’approche MDA : Model-Driven Architecture est proposée par l’OMG : Object
Management Group en 2000. L’idée de base du MDA est la séparation des spécifications
fonctionnelles d’un système des détails de son implémentation sur une plateforme donnée.
Cela veut dire que des modèles sont spécifiés indépendant de plateforme, on appelle
Platform Independent Model( PIM) . Les modèles de PIM sont utilisés pour exprimer
les fonctionnalités du système avant de définir la plateforme utilisée. Et un autre type
de modèle est
Platform Specific Model (PSM) . Ce type de modèle est différent par
rapport au PIM. Le PSM est les modèles spécifiés la plateforme utilisée. L’approche
MDA permet de déployer un même modèle de type PIM sur plusieurs plateformes grâce
au principe de la transformation vers PSM.
L’architecture de MDA est standardisée en 4 niveaux :
– M0 – Le monde réel ou CIM est un niveau des fonctionnalités du système ou
des exigences des utilisateurs.
– M1 – Le modèle est des exigences qui sont formalisés et modélisés, dans ce cas
c’est le modèle PIM et PSM qui représentent le système.
– M2 – Le méta-modèle est un modèle de modèles. C’est un langage utilisé pour
décrire des modèles. Par exemple UML, XML.
– M3 – Le méta-métamodèle permet de décrire un modèle de méta-modèles. Selon
l’OMG, le MOF est un exemple de description de méta-modèles.
Figure 2.4: L’architecture de MDA
Ref.[1]
Les transformations entre le CIM, le PIM et les PSM sont souvent automatisés à
l’aide d’outils. Ces transformations sont réalisées avec des outils plus ou moins compatibles avec le standard de l’OMG nommé QVT.
Chapter 2. Recherche bibliographique
2.2.4
11
La transformation de modèle
La communauté IDM (Bézivin, 2004)[3] consiste à dire qu’une transformation
de modèles est la génération d’un ou de plusieurs modèles cibles à partir d’un ou de
plusieurs modèles sources. L’un des objectifs d l’IDM est que l’IDM consiste à pouvoir
rendre opérationnels les modèles à l’aide de transformations. Donc la transformation est
le cœur de l’IDM. Cette notion est bien représentée dans l’approche de MDA.
L’approche MDA demande de créer d’abord un modèle indépendant de toute plateforme (PIM), en suite PIM est raffiné en un ou plusieurs modèles spécifique à une
plateforme (PSM). La transformation joue le rôle de l’intermédiaire, définit des règles
de transformation entre PIM et PSM.
Une transformation des entités du modèle source met en jeu deux étapes. La
première étape permet d’identifier les correspondances entre les concepts des modèles
source et cible au niveau de leurs méta-modèles, ce qui induit l’existence d’une fonction
de transformation applicable à toutes les instances du méta-modèle source. La seconde
étape consiste à appliquer la transformation du modèle source afin de générer automatiquement le modèle cible par un programme appelé moteur de transformation ou
d’exécution.
2.2.5
Les outils de l’IDM
Dans cette partie est la présentation des outils qui permet de méta-modélisation
dans lesquels la transformation de modèles revient à l’exécution d’un méta-programme.
Il existe maintenant de nombreux des outils de méta-modélisation. Ces qui sont présentés
suivants, sont quelques exemples souvent utilisés.
2.2.5.1
Kermeta
Kermeta [3] est un atelier de méta-modélisation développé par l’équipe Triskell
de l’IRISA. Kermeta est utilisable sous forme d’un plugin Eclipse. Une description en
KERMETA est assimilable à un programme issu de la fusion d’un ensemble de métadonnées (EMOF) et du méta-modè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. Kermeta peut être vu comme étant composé d’un méta-méta-modèle (une extension d’EMOF) auquel est associé un langage permettant de définir des actions sur
les méta-modèles. Ces actions peuvent servir par exemple à vérifier la cohérence d’un
Chapter 2. Recherche bibliographique
12
modèle (avec des validations de contraintes à l’OCL) ou bien encore à réaliser des transformations de modèles. La définition d’un méta-modèle en Kermeta peut se faire de 3
manières :
– Via un éditeur graphique de modèle à l’UML
– Via un éditeur sous forme d’arbre en associant des instances du méta-élément
de Kermeta (représentation XMI)
– En écrivant un
programme Kermeta correspondant à la définition du méta-
modèle
2.2.5.2
MetaEdit+
MetaEdit+ [3, 6] permet de définir explicitement un métamodèle et au même
niveau de programmer tous les outils nécessaires, allant des éditeurs graphiques aux
générateurs de code, en passant par des transformations de modèles.
2.2.5.3
EMF (Eclipse-EMF-website)
EMF (Eclipse Modeling Framework) a été développé pour simplifier le chargement,
la manipulation et le stockage des modèles dans l’environnement Eclipse. EMF repose
dans la famille d’Eclipse Modeling Framework. Elle est une plateforme de modélisation
et de génération de code qui facilite la construction d’outils et d’autres applications
basées sur des modèles structurés. EMF n’est pas spécifique à un méta-modèle, donc il
peut gérer tous les types de modèles. Il est basé sur une norme de description de métamodèle nommé ”Ecore”. Cette norme est un sous-ensemble de la norme MOF (MOF
Essentiel), qui à son tour est un sous-ensemble de MOF2.EMF est composé des plug-ins
qui sont :
– Le méta-modèle Ecore qui est un canevas de classes pour décrire les modèles
EMF et manipuler les référentiels de modèles.
– EMF.Edit qui est un canevas de classes pour le développement d’éditeurs de
modèles EMF.
– Le modèle de génération GenModel qui permet de personnaliser la génération
Java.
– JavaEmitterTemplate qui est un moteur de template générique.
– JavaMerge qui est un outil de fusion de code Java.
- Xem thêm -
.PDF 
56 
160 
74 
