République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Université de Larbi Tébessi–Tébessa-
Faculté des Sciences Exactes et des Sciences de la Nature et de la Vie
Département : Mathématiques et Informatique
MEMOIRE DE MASTER
Domaine :Informatique
Filière : Informatique
Option :Systèmes d‟Information
Thème :
Présentépar :
Imane DJEFFEL
Maroua SOUALHIA
Devant le jury :
Mohamed AOUINE MAA Université de Larbi Tébessi Président
Mohamed AMROUNE MCB Université de Larbi Tébessi Rapporteur
Salwa DIFFALLAH MAA Université de Larbi Tébessi Examinateur
Date de soutenance : 29-05-2016
Note :…. Mention :………………………..
Tissage de modèles dynamiques pour la
réutilisationd’applications
Résumé
ملخص
نقد ىرا األخس انشأ نتحسن حال. ى طسقت نمذجت جددة نهنمذج (MOA) انمجو ةيجانب اننمذج
ىرا (MDE)ىرا انعمم ضع ف إطاز انيندست انمجيت من طسف اننماذج . انمفسضت عهى اننمذجت انمجيت انيادفت
.من اجم نمذجت األنظمت انمسكبت
قد اقتسحنا . ننماذج اندنامكت عهى أساس جانب اننمذجت انمجيت لانيدف من ىره انمركسة ى تشكم اننسج
. مجمعت من انجانب نهحصل عهى نمذج جددFSMاطسحت تسمح بنسج نمذج قاعدي ى
قد استعمهنا . FSMـ ثم ضعنا تحهن نتقهص تضح الFSMنـ نماذج انفقت إلنجاش ىرا انعمم قمنا بتحدد
ف األخس تم عسض دزاست حانت. إلقساز نسجنا Kermeta اننمذجت انفقت Eclipeplugin de tissage كرنك
.نتضح اطسحتنا نهنسج
FSM ،Kermetaانمجيت، اننمذجت ، جانبIDMاننسج، انجانب، : يةالكلمات المفتاح
Résumé
Abstract
Aspect Oriented Modeling (MOA) is a new modeling paradigm. The latter was born to
improve and solve the limitations of object-oriented modeling.
This research is part of the Model Driven Engineering (MDE). This is to model complex
systems.
The objective of this paper is to formalize weaving dynamic models in an aspect-
oriented modeling. We proposed an approach that helps build a base model, which was an
FSM with an aspect together to get a new model. To make this work, we first define the meta-
models of the WSF. Then we made two changes to minimize and determine the WSF.
Wealsoused the Eclipse plugin with weaving and meta-modeling Kermeta implement our
weaving.
Finally a case study is presented to illustrate our approach weaving.
Keyword: weaving, aspect, IDM, aspect-oriented modeling, FSM, Kermeta
Résumé
Résumé
La Modélisation Orientée Aspect (MOA) est un nouveau paradigme de modélisation.
Ce dernier est né pour améliorer et résoudre les limites de la modélisation orientée objet.
Ce travail de recherche se situe dans le cadre de l‟Ingénierie Dirigée par les Modèles (IDM).
Il s'agit de modéliser des systèmes complexes.
L‟objectif de ce mémoire est de formaliser un tissage de modèles dynamiques selon
une modélisation orientée aspect. Nous avons proposé une approche qui permet de tisser un
modèle de base qui été un FSM avec un ensemble d‟aspect pour obtenir un nouveau modèle.
Pour réaliser ce travail, nous avons d'abord définit les méta-modèles du FSM. Ensuite on a
fait deux transformations pour minimiser et déterminer le FSM. Nous avons aussi utilisé
Eclipse avec le plugin de tissage et de méta-modélisation Kermeta implémenter notre tissage.
Finalement une étude de cas est présentée pour illustrer notre approche de tissage.
Mot clé : tissage, aspect, IDM, modélisation orientée aspect, FSM, kermeta
Dédicace
Il m’a été très difficile d’écrire cette page par souci d'oublier les nombreuses personnes qu'il me faut citer pour leur aide, leur accueil,
leur soutien... ! Qu'elles soient toutes assurées de ma plus profonde reconnaissance même si leur nom n’y figure pas !
Les mots me manqueront pour traduire ma gratitude, ma reconnaissance et mon affection à mes très chers parents qui ont tant
sacrifié pour me voir progresser. En Hommage à leur confiance, je tien à leurs offrir cette mémoire pour leurs sacrifices et leur soutien
illimité. Je dédie ce modeste travail en témoignage de mon grand amour
et ma gratitude infinie à mes chers frères Nazih, ibrahim, Ramzi et leurs femmes, à ma très chère sœur Soumaya, pour leurs soutiens et pour les efforts qu’ils ont consentis pour l’accomplissement de mes
études. Sans oublié mes nièces : Nada, Melissa, Nadine, et mes neveux :
Nader, Youssef El Mahdi, Amir, Anass. A toute ma famille.
A mes chères amies :Marwa, Souhaila, Asma, Meriem, Khaoula, Sawsen, Amel, Imane, Hassiba, Ikram, en souvenir de notre sincère et
profonde amitié et des moments agréables que nous avons passés ensemble.
A tous mes collègues surtout les étudiants du master II système d’information promotion 2016.
Enfin, je dédié ce travail à tous ceux qui me connaisse de près ou de loin.
Imane DJEFFEL
Dédicace A l'âme de mon très cher père"Allah yarhmou",
Qui a tant espéré voir ce jour, qui s’est sacrifié pour ma réussite, m’a
aidé, (m’a appris la patience et la persévérance), et qu’il soit fier de
moi comme il l’a toujours été, merci papa de m’avoir fait autant de
confiance.
À ma très chère mère
Aucune dédicace ne saurait exprimer mon respect, mon amour éternel
et ma considération pour les sacrifices que vous avez consenti pour
mon instruction et mon bien être.
A mes chers et adorable frères et sœurs
En témoignage de mon affection fraternelle, de ma profonde tendresse
et reconnaissance, je vous souhaite une vie pleine de bonheur et de
succès et que Dieu, le tout puissant, vous protège et vous garde.
À Mes professeurs
Qui doivent voir dans ce travail la fierté d'un savoir bien acquis.
À tous mes amis
(Imane, Souhaila, Meriem, Chaima, Khawla, Sawssen, Asma.Z,
Ikram, Asma.B)
En souvenir de notre sincère et profonde amitié et des moments
agréables que nous avons passés ensemble.
SOUALHIA Maroua
Remerciement
Nous tenons avant tout à remercier Dieu tout puissant de
nous avoir donné la force et la volonté pour achever ce
modeste travail.
Nos vifs remerciements, accompagnés de toute notre
gratitude, vont tout d’abord à notre encadreur Mr
AMROUNE Mohamed, pour encadrement, son assistance,
son soutien, sa disponibilité et ses précieux conseils.
Nos remerciements s’adressent également aux membres
de jury qui nous avons fait l’honneur de juger notre travail.
Nos profonds remerciements vont également à tous nos
enseignants, ainsi que tous les membres du département de
MATH ET INFORMATIQUE pour tout le savoir qu’ils ont
su nous transmettre durant nos années d’études.
Et enfin nous remercions tous ceux qui ont contribué de près
ou de loin à la réalisation de ce travail.
Table des matières
Table des matières
LISTE DES TABLEAUX
LISTE DES FIGURES
ABREVIATIONS
INTRODUCTION GENERALE……………………...……..…………………………... 1
INTRODUCTION……………..…………………………………………………………. 4
1.NIVEAUX D’ABSTRACTION……...………………..………...………...………… 4
1.1.Modèle………………………………………………………………….………… 4
1.2.Meta modèle……………………………………………………………………… 5
1.3.Meta méta modèle……………...………………………………………………… 6
2.LANGAGE DEDIE…………………………………………………………………... 7
2.1.Langage dédie à la programmation………………...…………………………….. 7
2.2.Langage dédie à la modélisation………………………………………...……….. 8
3.L’APPROCHE MDA……………..………………………………………………….. 8
3.1.NOTION DE PLATEFORME…………………………………………………… 8
3.2.CIM (COMPUTATION INDEPENDENT MODEL)……………………………. 8
3.3.PIM (PLATFORM INDEPENDENT MODEL)…………………………………. 9
3.4.PDM (PLATFORM DESCRIPTION MODEL)…………………………………. 10
3.5.PSM (PLATFORM SPECIFIC MODEL)………………………………………... 11
Chapitre I : Ingénierie Dirigée par Modèle
Table des matières
4.L'INGENIERIE DIRIGEE PAR LES MODELES………………………………... 11
4.1.DEFINITION…………………………………………………………………….. 11
4.2.LES POINTS FORTS DE L'IDM………………………………………………... 12
4.3.LES POINTS FAIBLES DE L‟IDM……………………………………………... 13
4.4.LES BASES DE L‟IDM………………………………………………………….. 13
4.4.1. TRANSFORMATION DE MODELES……………………………..……. 14
a. Principales approches de transformation de modèles…………………..……. 14
b. Langage de transformation…………………………………………………… 15
4.4.2. TRANSFORMATIONS…………………………………………………… 16
a. CIM vers PIM………………………………………………………………… 17
b. PIM vers PIM………………………………………………………………… 17
c. PIM vers PSM…………………………………………………………...…… 17
d. PSM vers PSM……………………………………………………...………... 17
e. Transformation PSM vers Code……………………………………………… 18
f. Transformations inverses PIM vers CIM, PSM vers PIM et code PSM….….. 18
5.LES STANDARDS DE L'OMG……………………………………………………... 19
5.1.MOF (Meta Object Facility)……………………………………………………… 19
5.2.XMI (XML MetadataInterchange)……………………………………………….. 19
5.3.OCL (Object ConstraintLanguage)………………………………………………. 20
6.COMPOSITION DE MODELES……………………………………………………. 20
CONCLUSION…………………………………………………………………………… 21
Chapitre II :Composition de modèles
Table des matières
INTRODUCTION………………………………………………………………………... 22
1.COMPOSITION DE MODELES……………………………………………………. 22
1.1.Définition…………………………………………………………………………… 22
1.2.Classification des approches………………………………………………………... 23
1.2.1. Classification selon les caractéristiques des modèles en entrée…………….. 23
1.2.2. Classification selon les caractéristiques des modèles en sortie……………... 24
1.2.3. Classification selon les caractéristiques de l'opération de composition…….. 24
1.2.4. Autres caractéristiques de classification…………………………………….. 27
2.LES APPROCHES DE COMPOSITION…………………………………………… 29
2.1.Kompose……………………………………………………………………………. 29
2.2.Virtual EMF……………………………………..………………………………….. 30
2.3.Generic Modeling Environment……………………………………………………. 33
2.4.La PlateformeAMMA..…………………………………………………………….. 33
2.5.Atlas Model Weaver………………………………………………………………... 35
CONCLUSION.................................................................................................................... 37
INTRODUCTION………………………………………………………………………. 38
1.APPROCHE ORIENTEE OBJET…………………………………………………. 38
1.1.Les préoccupations transversales………………………………………………….. 39
1.2.Les problèmes du crosscutting…………………………………………………….. 40
Chapitre III :L’ingénierie De Modèles Orientée Aspects
Table des matières
1.2.1. Dispersion du code……………………………………………………...…. 41
1.2.2. Enchevêtrement du code…………………………………………………… 42
1.3.Conséquences……………………………………………………………………… 42
2.MODELISATION ORIENTEE ASPECT…………………………………………. 43
2.1.Concepts et terminologie………………………………………………………….. 45
2.1.1. Préoccupations……………………………………………………………... 45
2.1.2. Point de jonction…………………………………………………………… 46
2.1.3. Point de coupe……………………………………………………………... 46
2.1.4. Conseil……………………………………………………………………... 46
2.1.5. Aspect……………………………………………………………………… 46
2.1.6. Tisseur (Weaver en anglais)……………………………………………….. 46
2.1.7. Mécanisme d‟introduction…………………………………………………. 46
2.2.La modélisation graphique d'un aspect à travers les diagrammes UML………….. 46
2.3.Points faibles de la MOA………………………………………………………….. 47
3.L’INGENIERIE DES EXIGENCES ORIENTEE ASPECTS (AORE)………….. 48
3.1.Définition de l‟exigence…………………………………………………………… 48
3.2.Définition de l‟AORE……………………………………………………………... 48
3.3.Objectifs de L‟AORE……………………………………………………………... 49
4.LES APPROCHES DE MODELISATION ORIENTEE ASPECT……………… 49
4.1.Composition de modèles dans l‟approche Theme et al………..………………….. 49
4.2.Composition de modèles dans l‟approche de France et al………………………… 53
4.3.Composition de modèles dans l‟approche MATA………………………………... 55
Table des matières
5.SYNTHESE DES DIFFERENTES APPROCHES DE COMPOSITION.............. 58
5.1.Critères de comparaison…………………………………………………………… 59
5.2.Tableau comparatif des approches………………………………………………… 60
CONCLUSION………………………………………………………………………….. 60
INTRODUCTION………………………………………………………………………. 61
1. PROCESSUS DE NOTRE APPROCHE.................................................................. 61
2. ETUDE DE CAS: MACHINE A ETATS FINIS..................................................... 63
2.1. Présentation.............................................................................................................. 63
2.2. Métamodèle et Modèles d'une machine à états finis............................................... 64
2.2.1. Création de méta modèle............................................................................... 64
2.2.2. Création de modèle........................................................................................ 66
3. GENERATION DE L'EDITEUR............................................................................. 67
4. UTILISATION DE L'EDITEUR.............................................................................. 68
5. AJOUT DE COMPORTEMENT KERMETA........................................................ 69
5.1. Pseudo-Codes.......................................................................................................... 70
5.1.1. Pseudo Code de la fonction run().................................................................. 70
5.1.2. Pseudo Code de la fonction step()................................................................. 70
5.1.3. Code de la fonction fire().............................................................................. 70
5.1.4. Implémentation en Kermeta.......................................................................... 71
5.1.5. Exécutez la simulation................................................................................... 71
Chapitre IV : Contribution
Table des matières
6. TRANSFORMATION DE MODELE...................................................................... 72
6.1. 1ère transformation détermination............................................................................
72
6.1.1. Algorithme..................................................................................................... 73
6.1.2. Implémentation.............................................................................................. 73
6.1.3. Exécution…………………………………………………………………... 75
6.2. 2ème transformation Minimisation / Optimisation....................................................
75
6.2.1. Algorithme……………………………………............................................. 76
6.2.2. Implémentation.............................................................................................. 77
6.2.3. Exécution…………………………………………………………………... 77
7. OUTILS....................................................................................................................... 78
7.1. L‟environnement de modélisation eclipse............................................................... 78
7.2. Langage kermeta...................................................................................................... 79
7.2.1. Presentation.................................................................................................... 79
7.2.2. Fabrication de kermeta.................................................................................. 80
7.2.3. Installation de kermeta.................................................................................. 81
CONCLUSION………………………………………………………………………….. 85
CONCLUSION GENERALE…………..…...……………..……….…………...……… 86
BIBLIOGRAPHIE
Liste de figures
N° Titre Page
I.1 Relations entre système, modèle, méta modèle et langage 6
I.2 Pyramide de modélisation de l‟OMG 7
I.3 Exemple de CIM 9
I.4 Exemple de PIM 10
I.5 Exemple de PDM 10
I.6 Exemple de PSM 11
I.7 Schéma de base d‟une transformation 15
I.8 Transformations des modèles 18
II.1 Processus de composition de modèles : vue simple 23
II.2 Une vue synthétisée de la classification des approches de
composition de modèles
28
II.3 Processus de composition de Kompose 29
II.4 Processus de composition de VEMF 31
II.5 Les APIs de VEMF 32
II.6 Architecture de la plateforme AMMA 34
II.7 Méta-modèle AMW 35
III.1 Modularité : l‟Idéal vs. Réalité 42
III.2 le modèle de base et le modèle d'aspect 47
III.3 Le modèle composé base + aspect 47
III.4 Le modèle d‟aspect d‟un patron sujet-observateur en utilisant Thème 51
III.5 Le modèle tissé en utilisant la notation de Thème 52
III.6 Le modèle d‟aspect d‟un patron sujet-observateur en utilisant la
notation de France et al.
53
III.7 Un modèle d‟aspect spécifique à un contexte donné en utilisation
l‟approche de France et al.
54
III.8 Exemple de composition de scénarii avec MATA 57
IV.1 l‟approche proposée 62
IV.2 Automate fini reconnaissant les écritures binaires des multiples de 3 63
IV.3 Méta modèle pour machine à états finis 64
IV.4 Etape 1 de création d'un projet EMF 65
IV.5 Etape 2 de création d'un projet EMF 65
IV.6 Etape 3 de création d'un projet EMF 65
IV.7 Etape1 pour création d'une instance du métamodèle proposé 66
IV.8 Etape 2 pour création d'une instance du métamodèle proposé 66
IV.9 Etape 1 pour générer l‟éditeur 67
IV.10 Etape 2 pour générer l‟éditeur 68
IV.11 Etape 3 pour générer l‟éditeur 68
IV.12 Utilisation de l‟éditeur 69
IV.13 Utilisation de l‟éditeur 69
IV.14 Exemple d'exécution du fichier DETExecut.kmt 72
IV.15 Exécution de l‟implémentation de la détermination 75
IV.16 Exemple d'automate finis Dans cet automate, tous les états sont
accessibles, les états c, d et e sont indistinguables, ainsi que les
états a et b
76
IV.17 Automate minimal équivalent. Les états indistinguables sont
regroupés en états
76
IV.18 Exécution de l‟implémentation de la minimisation 77
IV.19 Architecture générale de la plate-forme Eclipse 79
IV.20 différents types d'expressions Kermeta 80
IV.21 Sélection de Kermeta pour Eclipse de l‟Eclipse Marketplace 82
IV.22 Sélection des composants pour l'installation 83
IV.23 Confirmation des composants sélectionnés pour l'installation 83
IV.24 Accepter de Software License Pendant l‟Installation de Kermeta 84
IV.25 L‟installation de Kermeta 84
Liste de tableaux
N° Titre Page
III.1 Comparaison des approches étudiées. 60
IV.1 Table de transition de l'automate de la figure IV.2 63
Abréviations
IDM : Ingénierie Dirigée par Modèles
MDA : Model Driven Architecture
UML : UnifiedModelingLanguage
μ : représentationDe
c : conformeA
OMG : Object Management Group
BNF : Backus-Naur form
EBNF : Extended BNF
BDware : Base Data ware
MOF : Meta Object Facility
CIM : Computation Independent Model
PIM : Platform Independent Model
PDM : Platform Description Model
PSM : Platform Specific Model
XML : eXtensibleMarkupLanguage
QVT : Query/View/Transformation
ATL : ATLAS Transformation Language
ADT : ATL DevelopementTool
XMI : XML MetadataInterchange
EMF : Eclipse Modeling Framework
DTD : Document Type Definition
OCL : Object ConstraintLanguage
EML : EPSILON MERGING LANGUAGE
EPSILON : Extensible Plateform for Specification of Integrated Languages for
mOdelmaNagement
AMW : Atlas Model Weaver
AM : Aspect Model
PM : Primary Model
EMOF : Essential MOF
EOL : Epsilon Object Language
EVL : Epsilon Validation Language
ECL : EpsilonComparisonLanguage
API : Application Programming Interface
GME : GenericModelingEnviroment
DSML : Domain-SpecificModelingLanguage
FCO : First Class Objects
AMMA : ATLAS Model Management Architecture
IDE : IntegratedDevelopmentEnvironment
KM3 : Kernel Meta Meta Model
AM3 : AtlanModMegaModel Management
TCS : TextualConcreteSyntaxSpecification
HOT : HigherOrder Transformation
XSLT : eXtensibleStylesheetLanguage Transformations
MOA : Modélisation Orientée Aspect
AORE : L‟ingénierie des Exigences Orientée Aspects
AO : Aspect Oriented
RE : Requirements Engineering
AOSD : Aspect Oriented Software Development
IE : Ingénierie des Exigences
MATA : Modeling Aspects using a Transformation Approach
RSM : Rational Software Modeler
Introduction
générale
Introduction générale
-1-
Introduction générale
Contexte
L'Ingénierie dirigée par les modèles (IDM) est une pratique d'Ingénierie des
systèmes qui utilise les capacités des technologies informatiques pour décrire à la fois le
problème posé et sa solution en utilisant des modèles, des concepts, et des langages. Les
transformations de ces modèles spécifient des raffinements d‟un niveau d‟abstraction vers un
autre.
L‟augmentation du niveau d‟abstraction dans un développement logiciel est assurée par
l‟IDM. Ce qui permettra une réalisation adéquate à travers une séparation verticale du
domaine logique et une mise en œuvre des technologies dans différents modèles, qui
partitionnent les décisions qui doivent être considérées à différentes phases du cycle de
développement logiciel.
La modélisation Orientée aspects (MOA) est un nouveau domaine inspirés de l‟IDM qui
prend en charge la décomposition des préoccupations dans des modèles séparés à un même
niveau d‟abstraction. Les préoccupations sont des “éléments” d‟intérêt qui nécessitent d‟être
traités au cours du développement d‟un système logiciel.
La séparation des préoccupations transverses permet au concepteur de logiciel d‟avoir
un meilleur contrôle sur les variations (dans le contexte des lignes de produits par exemple) et
les évolutions du logiciel. Cette idée est vulgarisée dans le niveau de programmation par le
langage AspectJ[81]. Dans nos jours la communauté aspects intéresse aussi à opérer cette
séparation au niveau de modélisation plus tôt dans le cycle de développement à travers les
phases d‟expression des besoins et d‟analyse/conception [119], [120], [121]. En outre, le fait de
séparer les préoccupations transverses dans le cycle de développement, a besoin de
mécanismes automatiques de tissage d‟aspects. La modélisation orientée aspect permettra de
cibler des plateformes non orientées-aspect ou bien faciliter la mise en place de techniques de
validation comme la simulation ou la génération de tests.
Cette séparation horizontale étend la séparation verticale de l‟IDM en répartissant
davantage les décisions qui doivent être prises à chaque niveau d‟abstraction. La
Introduction générale
-2-
maintenabilité des modèles est l‟une des avantages attendus de la définition des
préoccupations dans différents modules.
Pour produire le modèle complet d‟un système logiciel, il est nécessaire de décomposer
les préoccupations à un niveau de modélisation assurée par l‟existence de tisseur de
préoccupations. Le tissage est fondé sur des spécifications décrivant comment les
préoccupations modélisées doivent être composées. Une mauvaise spécification d‟un tissage
peut introduire des erreurs dans les modèles composés.
Pour détecter ces erreurs, le test est une approche faisable pour valider les différents
modèles des préoccupations et les modèles composés.
Pour rendre utilisable la séparation des préoccupations au cours des phases de
modélisation, les notions d‟aspect, de point de coupure et de tissage doivent être précisément
et relativement définies au formalisme de modélisation utilisée.
Problématique
Le paradigme orienté objets est supposé avoir l‟avantage de la réutilisabilité par rapport
au paradigme procédural. Il permettrait aux utilisateurs de suivre le code d‟une manière plus
facile et avoir une maintenance plus rapide.
Or, ce paradigme pose de nombreux problèmes au niveau des fonctionnalités présentes
dans plusieurs objets par exemple la duplication, enchainement (éparpillant), la difficulté de
réutilisation des modèles et le problème de Cross cuting (la séparation entre les modèles non
fonctionnels) pour lequel ce paradigme n'a donné aucune solution. Pour résoudre certains de
ces problèmes les développeurs et les programmeurs ont défini un nouveau paradigme appelé
l'Orientée Aspect(OA) afin d'améliorer et résoudre les limites de la modélisation orientée
objet.
La Modélisation Orientée Aspect utilise la notion d'aspect pour la séparation entre les
modèles fonctionnels (base) et les modèles non fonctionnels (Aspect) pour obtenir des
modèles composés. Cette dernière est classée parmi les dix meilleures technologies
émergentes qui ont changé le monde de la modélisation.
Introduction générale
-3-
Objectifs
Ne pas tout développer à partir de zéro
Réutiliser des composants d‟application pour développer une nouvelle à partir de
d‟autres composants existants
Organisation du mémoire
Notre mémoire s‟articulera autour de quatre chapitres, en plus d‟une introduction et
d‟une conclusion générale.
Le premier chapitre présente l‟ingénierie dirigée par modèles (IDM) comme le cadre
générale de notre étude. Nous définissons les principaux concepts de l‟IDM aussi les
transformations de modèles.
Le deuxième chapitre décrit, en premier lieu, la définition de composition classification
des approches de composition En dernier lieu, nous citons les différents outils de
composition.
Dans le troisième chapitre, nous présentons, la modélisation orientée aspects avec leur
concepts de base et aussi l‟ingénierie de besoin orientée aspect. L‟objectif de ce chapitre est
analyser les approches existantes d‟ingénierie des exigences orientées Aspects pour fournir
une base pour notre approche en analysant ces approches.
Le dernier chapitre est un cas d‟études qui met en évidence les différents concepts
étudiés ainsi que les résultats obtenues
Enfin, on termine notre mémoire par une conclusion générale où seront résumés les
principaux concepts que nous avons obtenus durant ce travail de recherche.
Chapitre I :
Ingénierie Dirigée par
Modèle
Chapitre I :
INTRODUCTION
1. NIVAU D’ABSTRACTION
1.1.Modèle
1.2.Meta modèle
1.3.Meta méta modèle
2. LANGAGE DEDIE
2.1.Langage dédie à la programmation
2.2.Langage dédie à la modélisation
3. L’APPROCHE MDA
3.1.NOTION DE PLATEFORME
3.2.CIM (COMPUTATION INDEPENDENT MODEL)
3.3.PIM (PLATFORM INDEPENDENT MODEL)
3.4.PDM (PLATFORM DESCRIPTION MODEL)
3.5.PSM (PLATFORM SPECIFIC MODEL)
4. L'INGENIERIE DIRIGEE PAR LES MODELES
4.1.DEFINITION
4.2.LES POINTS FORTS DE L'IDM
4.3.LES POINTS FAIBLES DE L‟IDM
4.4.LES BASES DE L‟IDM
5. LES STANDARDS DE L'OMG
5.1.MOF (Meta Object Facility)
5.2.XMI (XML MetadataInterchange)
5.3.OCL (Object ConstraintLanguage)
6.COMPOSITION DE MODELES
CONCLUSION
Chapitre I Ingénierie Dirigée par Modèle
-4-
INTRODUCTION
Aujourd‟hui les outils IDM ont atteint un bon niveau de maturité et sont de plus en plus
adoptés dans le cadre d‟applications complexes et critiques. Il préconise l‟utilisation intensive
des modèles et des transformations au cœur du processus de développement.
Le terme IDM a été proposé pour la première fois par [1]. Elle a apporté des
améliorations significatives dans le développement des systèmes complexes en fournissant les
moyens permettant de passer d‟un niveau d‟abstraction à un autre ou d‟un espace de
modélisation à un autre.
Dans la suite de ce chapitre, nous proposons de ramener l‟IDM dans un monde plus
rigoureux en essayant d'aborder ses principes clés ainsi que ses différents niveaux
d‟abstraction suivi d'une présentation de L‟approche MDA qui préconise la séparation des
spécifications métiers propre à un domaine de celles d‟implémentation.
1. NIVEAUX D’ABSTRACTION
Ces niveaux d‟abstraction basés sur trois concepts fondamentaux sont à la base de
l'Ingénierie Dirigée par les Modèles : les modèles, les métas modèles, le méta méta modèle.
La figure I.1 schématise les relations entre ces concepts dans une architecture à trois niveaux
d‟abstraction.
1.1. MODELE
Il n'existe pas de définition universelle pour le concept de modèle, cependant on peut
trouver un consensus relatif autour du fait qu'un modèle est une représentation simplifiée (ou
abstraction) d'un système réel modélisé sous la forme d‟un ensemble de faits construits dans
une intention particulière.
Un modèle doit pouvoir être utilisé pour répondre à des questions sur le système
modélisé. Il est décrit au moyen d'un langage d'expression de modèles, par exemple UML
(Unified Modeling Language) [2].
On déduit de cette définition la première relation majeure de l‟IDM, entre le modèle et
le système qu‟il représente, appelée représentation De dans [3],[4],[5], et nommée μ sur la
figure I.1.Notons que même si la relation précédente a fait l‟objet de nombreuses réflexions, il
Chapitre I Ingénierie Dirigée par Modèle
-5-
reste toutefois difficile de répondre à la question « QU’EST CE QU’UN BON MODELE ?
» et donc de formaliser précisément la relation μ. Néanmoins un modèle doit, par définition,
être une abstraction pertinente du système qu‟il modélise, c.-à-d. qu‟il doit être suffisant et
nécessaire pour permettre de répondre à certaines questions en lieu et place du système qu‟il
représente, exactement de la même façon que le système aurait répondu lui-même. Ce
principe, dit de substituabilité, assure que le modèle peut se substituer au système pour
permettre d‟analyser de manière plus abstraite certaines de ses propriétés [6].
La notion de modèle dans l‟IDM fait explicitement référence à la notion de langage bien
défini. En effet, pour qu‟un modèle soit productif, il doit pouvoir être manipulé par une
machine. Le langage dans lequel ce modèle est exprimé doit donc être clairement défini. De
manière naturelle, la définition d‟un langage de modélisation a pris la forme d‟un modèle,
appelé méta modèle [7].
1.2. META MODELE
Le méta modèle est un langage qui permet d‟exprimer des modèles. Dans un méta
modèle, on définit les concepts ainsi que les relations entre les concepts permettant d'exprimer
des modèles [8]. Un modèle est une construction possible, ou instance, d'un méta modèle.
La notion de méta modèle conduit à l‟identification d‟une seconde relation, liant le
modèle et le langage utilisé pour le construire, appelée conformeAet nommée c sur la figure
I.1.
En cartographie (cf. Figure I.1), il est effectivement indispensable d‟associer à chaque
carte la description du « langage» utilisé pour réaliser cette carte. Ceci se fait notamment sous
la forme d‟une légende explicite. La carte doit, pour être utilisable, être conforme à cette
légende. Plusieurs cartes peuvent être conformes à une même légende. La légende est alors
considérée comme un modèle représentant cet ensemble de cartes (μ) et à laquelle chacune
d‟entre elles doit se conformer(c) [7].
A partir de ces deux relations on peut bien distinguer le langage qui joue le rôle de
système, du (ou des) méta modèle(s) qui jouent le rôle de modèle(s) de ce langage.
Chapitre I Ingénierie Dirigée par Modèle
-6-
Figure I.1 : Relations entre système, modèle, méta modèle et langage [9].
1.3. META META MODELE
Un méta méta modèle est un modèle qui décrit un langage de méta modélisation, c.-à-d.
les éléments de modélisation nécessaires à la définition des langages de modélisation. Il a de
plus la capacité de se décrire lui-même [7].
Sur ces trois niveaux d‟abstraction se base l‟organisation de la modélisation de
l‟OMG1qui est généralement décrite sous une forme pyramidale (Figure I.2). Le monde réel
est représenté à la base de la pyramide (niveau M0). Les modèles représentant cette réalité
constituent le niveau M1. Les méta modèles permettant la définition de ces modèles (p. ex.
UML) constituent le niveau M2. Enfin, le méta méta modèle, unique et méta circulaire, est
représenté au sommet de la pyramide (niveauM3) [7].
L‟approche consistant à considérer une hiérarchie de méta modèles n‟est pas propre à
l‟OMG, ni même à l‟IDM, puisqu‟elle est utilisée depuis longtemps dans de nombreux
domaines de l‟informatique. Chaque hiérarchie définit un espace technique [10], [11],
[12].Nous distinguent par exemple le modelware2 (espace technique des modèles),
1OMG : L'OMG (Object Management Group) a été formé en 1989 par un groupe de fournisseurs dans le but de
créer une architecture standard pour les objets distribués. L‟OMG est notamment à la base des
standards UML, MOF, CORBA. L‟OMG est aussi à l‟origine de la recommandation MDA et IDM avec en
particulier le langage standardisé de transformation de modèles QVT. 2Modelware : est un espace technique pour concevoir, maintenir et réutiliser des modèles de développement de
logiciels.
Chapitre I Ingénierie Dirigée par Modèle
-7-
Le grammarware (espace technique des grammaires définies par les langages tels que
BNF3 ou EBNF
4), le BDware
5 (espace technique des bases de données), etc.
Figure I.2 : Pyramide de modélisation de l’OMG [4]
2. LANGAGE DEDIE
[13]Propose la définition suivante de la notion de langage dédié : « Un langage dédié est
un langage de programmation ou un langage de spécification exécutable qui offre, grâce à des
notations et abstractions appropriées, un pouvoir d‟expression concentré sur, et généralement
limité a, un domaine d‟applications particulier.»
Il existe deux types des langages dédiés :
2.1. LANGAGES DEDIES A LA PROGRAMMATION
Sont des langages qui peuvent être utilisés pour décrire des applications afin de
répondre aux différents besoins. Les langages de programmation utilisés au quotidien sont
souvent d'ordre généraliste, comme : C [14], C++[15], Java [16], etc. Ils peuvent servir à
résoudre de vastes types de problèmes de nature différente [17].
3BNF (Backus-Naur form) : est une notation permettant de décrire les règles syntaxiques des langages de
programmations. Elle est utilisée pour décrire le langage étudié. 4EBNF (Extended BNF) : est une extension du métalangage BNF, créée par NiklausWirth. Cette forme permet
de condenser la notation BNF et de la rendre plus lisible. 5BDware : espace technique de base de données.
Le MOF
UML, etc.
Modèle UML, etc.
Code, etc.
M1
M0
M2
M3
Chapitre I Ingénierie Dirigée par Modèle
-8-
2.2. LANGAGES DEDIES A LA MODELISATION
Langages dédiés à la modélisation peut être graphique ou textuel :
Un langage de modélisation graphique utilise des techniques de diagramme avec
notamment des symboles représentant des concepts et des lignes qui connectent les
symboles et qui représentent les relations entre ceux-ci.
Un langage de modélisation textuel quant à lui va utiliser des mots clés normalisés
accompagnés de paramètres qui constitueront des expressions interprétables notamment
par un outil informatique dédié à ce langage. L‟ensemble des instructions et de leurs
règles d‟écriture sont regroupées au sein d‟une grammaire. Un moyen d‟expression d‟une
grammaire est par exemple le formalisme BNF (Backus-Naur Form).
3. L’APPROCHE MDA
L‟architecture dirigée par les modèles (Model-Driven Architecture, MDA) [18], [19],
[8]est une initiative de l‟organisme OMG (Object Management Group) [20]qui vise à
standardiser les pratiques de l‟IDM. Le standard MDA préconise la séparation entre modèles
indépendants des plateformes (Platform Independant Model) et modèles spécifiques aux
plateformes (Platform Specific Model). L'idée de base derrière cette distinction est de
capitaliser un savoir-faire indépendamment des plateformes dans des modèles abstraits. Ces
modèles abstraits sont ensuite transformés en PSM via des transformations explicites.
3.1. NOTION DE PLATE-FORME
Une plateforme est un système offrant des services nécessaires à la construction, la
réalisation ou l‟exécution d‟autres systèmes [9].On distingue deux types de plateformes dans
la pratique : les plateformes logicielles et les plateformes matérielles.
Dans le paradigme IDM, les plateformes doivent être définies dans des modèles pour
permettre leur prise en compte dans le processus de construction du système.
3.2. CIM (COMPUTATION INDEPENDENT MODEL)
Appelé aussi modèle de domaine ou modèle métier. Il modélise les exigences du
système. Il montre le système dans l‟environnement organisationnel dans lequel il va être
Chapitre I Ingénierie Dirigée par Modèle
-9-
exécuté. Son but est d‟aider à la compréhension du problème. Les exigences exprimées dans
le CIM doivent être traçables dans le PIM et le PSM.
Flux
Organisation
Figure I.3 : Exemple de CIM
3.3. PIM (PLATFORM INDEPENDENT MODEL)
Décrit le système sans montrer les détails de son utilisation sur une plate-forme
particulière. Un PIM peut être construit en se basant sur les points de vue entreprise. Les
PIMs représentent par exemple les différentes entités fonctionnelles d‟un système avec leurs
interactions. Ils représentent l‟intérêt de l‟application : le logique métier. Un PIM doit être
raffiné par les détails d‟une ou plusieurs architecture(s) particulière(s) pour obtenir un PSM.
Chapitre I Ingénierie Dirigée par Modèle
-10-
Figure I.4 : Exemple de PIM
3.4. PDM (PLATFORM DESCRIPTION MODEL)
Après la définition du PIM, l‟architecte doit choisir une plateforme technique qui
permet d‟implanter le système avec la qualité architecturale décrite dans le PIM. Cette
plateforme doit être décrite dans un modèle afin de permettre son intégration dans la
construction du logiciel. Ce modèle est appelé PDM.
Figure I.5 : Exemple de PDM
Chapitre I Ingénierie Dirigée par Modèle
-11-
3.5. PSM (PLATFORM SPECIFIC MODEL)
C'est un modèle dépendant d‟une plateforme technologique. C‟est le modèle produit par
la transformation du PIM. Il spécifie comment le système va utiliser la plate-forme choisie.
Les PSM servent essentiellement de base à la génération de code exécutable vers ces mêmes
plateformes techniques.
Figure I.6 : Exemple de PSM
4. L'INGENIERIE DIRIGEE PAR LES MODELES
4.1. DEFINITION
L'Ingénierie Dirigée par les Modèles est une approche plus globale et générale que le
MDA. Elle cherche à en appliquer les principes et à les généraliser pour tout espace
technologique tels l'orienté-objet, les ontologies, les documents XML ou les grammaires de
langages. Le MDA peut ainsi être perçu comme un processus spécifique de type IDM [21].
Chapitre I Ingénierie Dirigée par Modèle
-12-
Selon [21]l‟IDM repose sur les principes suivants :
Capitalisation : les modèles doivent être réutilisables,
Abstraction : les modèles doivent être indépendant des technologies de mise en
œuvre afin d'adapter le logique métier à différents contextes et de permettre de faire plus
facilement évoluer les applications vers de nouvelles technologies,
Modélisation : abordée selon une vision productive (pour générer le code final du
logiciel pour une technologie de mise en œuvre donnée) par opposition à la traditionnelle
vision contemplative (but de documentation, spécification, communication),
Séparation des préoccupations : l'IDM s'illustre généralement selon les deux
principales préoccupations du métier et de la plateforme de mise en œuvre mais d'autres
préoccupations sont possibles.
Pour passer à une vision productive des modèles, il est nécessaire qu'ils soient bien
définis ; ce qui amène l‟importante notion de méta-modèle. Ainsi, les modèles productifs
pourront être manipulés et interprétés via des outils [22]répondant aux besoins de l'approche
IDM : définition de méta-modèles, définition de langages, définition de transformations et
leur exécution, génération de code, composition de modèles, génération d'environnement
graphique de modélisation, vérification de conformité de modèles, spécification de
contraintes, etc.[21].
4.2. LES POINTS FORTS DE L'IDM
Les points forts de l‟IDM selon [23]sont :
Elle met davantage l'accent sur l'automatisation du processus de développement
des systèmes.
Cette approche est basée principalement sur des représentations du système à un
haut niveau d'abstraction qui sont les modèles.
Le processus de développement, dans cette approche, revient à raffiner, maintenir,
et éventuellement de transformer les modèles en d'autres modèles ou de générer le code
exécutable. Il est important à noter que ces différentes activités se font d'une manière
automatique.
La méta-modélisation, qui est aussi un concept clé de l'approche IDM, permet de
donner à un langage de modélisation, une notation abstraite, ce qui permet de générer
automatiquement son éditeur. Le méta modélisation de langages est de plus en plus adoptée
Chapitre I Ingénierie Dirigée par Modèle
-13-
pour des domaines spécifiques afin de réduire la complexité et d'exprimer efficacement les
concepts du domaine.
4.3. LES POINTS FAIBLES DE L'IDM
Les points faibles de l‟IDMselon [23] sont :
Malgré que la définition d'une syntaxe abstraite d'un langage par un méta modèle
est bien maîtrisée et supportée par de nombreux environnements de méta modélisation, la
définition de la sémantique de ces langages reste une question ouverte et cruciale.
Actuellement, les environnements de méta modélisation sont en mesure de faire face à la
plupart des problèmes de définition syntaxique, mais ils manquent de supports rigoureux
permettant de fournir la sémantique des méta-modèles. La sémantique est généralement
donnée en langage naturel, cela implique que les langages définis par méta modélisation ne
sont pas encore aptes à l'analyse formelle de leurs modèles.
L'absence de notations conviviale des différentes techniques formelles est un défi
important pour les modèles formels. L'IDM permet, par le biais des notions de méta-modèles
et de transformation de modèles, de concevoir des supports outillés pour les méthodes
formelles. En ce sens, l'IDM n'apporte rien de nouveau sur le plan théorique aux concepts
d'analyse formelle, mais elle peut permettre une meilleure utilisation afin de profiter
pleinement de leurs avantages.
4.4. LES BASES DE L’IDM
L‟IDM a pour principal objectif de relever un certain nombre de défis du génie logiciel
(pérennité, prise en compte des plates-formes d‟exécution, qualité, productivité, sûreté,
séparation des préoccupations, coût, etc.) en suivant une approche à base de modèles dite
générative. En focalisant le raisonnement sur les modèles, l‟IDM permet de travailler à un
niveau d‟abstraction supérieur et de vérifier sur une maquette numérique (ensemble de
modèles qui traitent divers aspects d‟un système) un ensemble de propriétés que l‟on devait
vérifier auparavant sur le système final.
Chapitre I Ingénierie Dirigée par Modèle
-14-
4.4.1. TRANSFORMATION DE MODELES
La définition de transformations a pour objectif de rendre les modèles opérationnels
dans une approche IDM, ce qui augmente considérablement la productivité des applications.
La transformation de modèles est une opération très importante dans toute approche orientée
modèle. En effet, les transformations assurent les opérations de passage d‟un ou plusieurs
modèles d‟un niveau d‟abstraction donné vers un ou plusieurs autres modèles du même
niveau (transformation horizontale) ou d‟un niveau différent (transformation verticale). On
peut citer comme exemple de transformation verticale, la transformation PIM vers PSM dans
l‟approche MDA. Le modèle transformé est appelé modèle source et le modèle résultant de la
transformation est appelé modèle cible. [19]
c. Principales approches de transformation de modèles
Dans [19]trois approches de transformations de modèles sont identifiées : l‟approche
par programmation, l‟approche par Template et l‟approche par modélisation.
L’approche par programmation : Elle consiste à utiliser les langages de
programmation en général, et plus particulièrement les langages orientés objet. Dans cette
approche, la transformation est décrite sous forme d‟un programme à l‟image de n‟importe
quelle application informatique. Cette approche reste très utilisée car elle réutilise
l‟expérience accumulée et l‟outillage des langages existants.
L’approche par Template : Elle 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 SofteamMDA Modeler.
L’approche par modélisation : Elle consiste, quant-à-elle, à appliquer les
concepts de l‟ingénierie des modèles aux transformations des modèles elles-mêmes.
L‟objectif est de modéliser les transformations de modèles et de rendre les modèles de
transformation pérennes et productifs, en exprimant leur indépendance vis-à-vis des plates-
formes 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éta modèle permettant l‟élaboration des modèles de transformation de
modèles. A titre d‟exemple, cette approche a été choisie par le groupe ATLAS pour le langage
de transformation de modèles ATL. Dans l‟approche par modélisation, la transformation se
Chapitre I Ingénierie Dirigée par Modèle
-15-
fait par l‟intermédiaire de règles de transformations qui décrivent la correspondance entre les
entités du modèle source et celles du modèle cible. En réalité, la transformation se situe au
niveau des méta modèles source et cible qui décrivent la structure des modèles cible et source.
Figure I.7ci-dessous détaille le schéma de base d‟une transformation dans une approche
IDM. Le moteur de transformation de modèles prend en entrée un ou plusieurs modèles
sources et crée en sortie un ou plusieurs modèles cibles. Une transformation des entités du
modèle source met en jeu deux étapes.
Figure I.7 : Schéma de base d’une transformation [24]
d. Langage de transformation
On retrouve des langages conçus spécifiquement pour faire de la transformation de
modèles et qui peuvent être intégrés dans les environnements de développement standard (par
ex. Eclipse).
Dans le monde académique nous retrouvons le standard QVT [25], le langage ATL du
groupe ATLAS de l‟INRIA-LINA [26]
QVT (Queries, Views, Transformations) :
Le QVT est un langage de transformation de modèles standardisé par l‟OMG (Object
Management Group, 2011). Il permet la transformation de modèle à modèle et du modèle vers
du texte en utilisant particulièrement le méta modèle d‟UML. Donc, il est possible de générer
du code source ou même de la documentation grâce à ce langage.
Chapitre I Ingénierie Dirigée par Modèle
-16-
L‟objectif de QVT est d‟établir une manière standardisée pour interroger les modèles
MOF, créer des vues et définir les transformations. Le standard QVT vise à atteindre les
objectifs suivants :
Normaliser un moyen d‟exprimer des correspondances (transformations) entre
langages définis avec MOF ;
Exprimer des requêtes (Query) pour filtrer et sélectionner des éléments d‟un modèle
(notamment sélectionner les éléments source d‟une transformation) ;
Proposer un mécanisme pour créer des vues (Views) qui sont des modèles déduits
d‟un autre pour en révéler des aspects spécifiques ;
Formaliser une manière de décrire des transformations (Transformation).
ATL (Atlas Transformation Language) :
ATL est un langage de transformation hybride inspiré du langage QVT.
ATL [26]est l‟acronyme d‟ATLAS Transformation Language ; c‟est un langage à
vocation déclarative, mais qui est en réalité un langage hybride permettant de faire des
transformations de modèles aussi bien endogènes qu‟exogènes. Les outils de transformation
liés à ATL sont intégrés sous forme de plug-in ADT6 (ATL Development Tool) dans
l‟environnement de développement Eclipse. Un modèle de transformation ATL se base sur
des définitions de méta modèles au format XMI. Sachant qu‟il existe des dialectes d‟XMI,
ADT est adapté pour interpréter des méta modèles décrits à l‟aide d‟EMF (Eclipse).
Les transformations dans ATL sont unidirectionnelles mais il est possible de faire des
transformations bidirectionnelles à l‟aide d‟un ensemble de règles implémentées à la fois dans
les deux directions : le modèle source et le modèle cible.
4.4.2. TRANSFORMATIONS
Le principe de l‟approche MDA consiste à passer des PIMs aux PSMs pour préparer et
faciliter la génération de code vers une plate-forme technique choisie. Ce passage des PIMs
aux PSMs est une transformation de modèles. Le MDA identifie plusieurs types de
transformations (voir figure I.8) [27].
6 ADT (ATL DevelopementTool) : est l‟atelier de développement ATL crée par l‟équipe ATLAS à l‟université
de Nantes. Il s‟agit d‟un IDE basé sur la plateforme Eclipse. Le but d‟ADT est de fournir un environnement
complet de développement de transformations de modèles en ATL
Chapitre I Ingénierie Dirigée par Modèle
-17-
a. CIM vers PIM :
Permettent d‟élaborer des PIMs partiels à partir des informations contenues dans les
CIMs. L‟objectif est de s‟assurer que les besoins exprimés dans les CIMs sont bien
représentés dans les PIMs. Ces transformations sont essentielles à la pérennité des modèles.
Ce sont elles qui garantissent les liens de traçabilité entre les modèles et les besoins exprimés
par le client [27].
b. PIM vers PIM :
Ce type de transformations s‟effectue pour ajouter ou soustraire des informations aux
modèles. Le fait de masquer par exemple quelques éléments afin de s‟abstraire de détails
fonctionnels est typiquement une transformation PIM vers PIM. Dans l‟autre sens, le passage
du problème à la solution est la plus naturelle des transformations PIM vers PIM. Il est
important de noter que ces transformations ne sont pas toujours automatisables [27].
c. PIM vers PSM :
Une telle transformation s‟effectue lorsque les PIMs sont suffisamment complets pour
pouvoir être "immergés" dans une plate-forme technique. L‟opération qui consiste à ajouter
des informations propres à une plate-forme technique pour permettre la génération de code est
une transformation PIM vers PSM. A l‟heure actuelle, les plates-formes techniques visées
sont DotNet, J2EE, XML et CORBA. Il apparaît clairement que ce sont les règles qui
permettent ces transformations qui sont importantes et qui doivent être généralisées et
capitalisées. Ces transformations ont donc pour but d‟être fortement automatisées [27].
d. PSM vers PSM :
Une telle transformation s'effectue ors des phases de déploiement, d'optimisation ou de
reconfiguration. Notons de plus qu‟une unique transformation PIM vers PSM n'est pas
toujours suffisante pour permettre la génération de code, il faudra alors parfois transformer les
PSM en PSM en utilisant des formalismes intermédiaires (exemple de passage d'UML à SDL
puis de SDL à C++).
Chapitre I Ingénierie Dirigée par Modèle
-18-
e. Transformation PSM vers Code :
La transformation de PSM vers l‟implémentation (le code) est une transformation de
type modèle à texte [28]. Le code est parfois assimilé à un PSM exécutable. Dans la pratique,
il n‟est généralement pas possible d‟obtenir la totalité du code à partir du modèle et il est alors
nécessaire de le compléter manuellement.
f. Transformations inverses PIM vers CIM, PSM vers PIM et code PSM :
Ces transformations sont des opérations de rétro-ingénierie (reverse engineering). Ce
type de transformations pose de nombreuses difficultés mais il est essentiel pour la
réutilisation de l‟existant dans le cadre de l‟approche MDA [29]
Figure I.8 : Transformations des modèles [27].
La Figure I.8 synthétise les différentes transformations possibles des modèles. LeCIM
représente le niveau de modèle le plus abstrait. Par passages successifs, les modèles
deviennent de plus en plus concrets jusqu‟à l‟obtention du code. Le code peut être assimilé
par certains à un PSM exécutable, de même que la génération de code n‟est pas toujours
considérée comme une transformation de modèle. La figure montre aussi qu‟il est possible à
partir du code de recréer un PSM puis un PIM puis un CIM. Toutefois, le passage du code au
Chapitre I Ingénierie Dirigée par Modèle
-19-
PSM ne peut s‟effectuer que si la démarche MDA a été respectée, sinon les techniques
traditionnelles de rétro-ingénierie doivent être appliquées [30].
5. LES STANDARDS DE L'OMG
L‟OMG a déjà défini plusieurs standards pour le MDA : nous en dressons ici une liste
des plus importants.
5.1. MOF (META OBJECT FACILITY)
Le MOF est le standard de l’OMG qui permet l‟élaboration de méta-modèles [31] et de
représenter les méta-modèles grâce à des diagrammes ressemblants à des diagrammes de
classes UML. Dans ces diagrammes, les classes (que l‟on appelle des méta classes)
représentent les concepts à définir et les associations (que l‟on appelle des méta-associations)
représentent les relations entre ces concepts. Les méta-classes et les méta-associations sont
contenues dans des packages.
5.2. XMI (XML METADATAINTERCHANGE)
XMI est le langage d‟échange entre le monde des modèles et le monde XML
(eXtensible Markup Language). C‟est le format d‟échange standard entre les outils
compatibles MDA. XMI décrit comment utiliser les balises XML pour représenter un modèle
UML en XML. Cette représentation facilite les échanges de données (ou méta-données) entre
les différents outils ou plates-formes de modélisation.[34], [35], [36]
En effet, XMI définit des règles permettant de construire des DTD7 (Document Type
Definition) et des schémas XML à partir de méta-modèle, et inversement. Ainsi, il est
possible d‟encoder un méta-modèle dans un document XML, mais aussi, à partir de document
XML il est possible de reconstruire des méta modèles.[35]
Les méta-modèles MOF et UML sont décrits par des DTD et les modèles traduits dans
des documents XML conformes à leur DTD correspondante. XMI a l‟avantage de regrouper
les métadonnées et les instances dans un même document ce qui permet à une application de
comprendre les instances grâce à leurs méta-données. Ceci facilite les échanges entre
7DTD (document type definition) : est un document permettant de décrire un modèle de document XML. Le
modèle est décrit comme une grammaire de classe de documents.
Chapitre I Ingénierie Dirigée par Modèle
-20-
applications et certains outils pourront automatiser ces échanges en utilisant un moteur de
transformation du type XSLT[32], [33],[34],[35],[36],[37].
5.3. OCL (OBJECT CONSTRAINT LANGUAGE)
En utilisant uniquement UML, il n‟est pas possible d‟exprimer toutes les contraintes
souhaitées. Fort de ce constat, l’OMG a défini formellement le langage textuel de contraintes
OCL, qui permet de définir n‟importe quelle contrainte sur des modèles UML [19] : le
langageOCL (Object ConstraintLanguage) qui est un langage d‟expression permettant de
décrire des contraintes sur des modèles. Une contrainte est une restriction sur une ou plusieurs
valeurs d‟un modèle non représentable en UML.[38], [39], [40], [41].
Une contrainte OCL est une expression dont l‟évaluation doit retourner vrai ou faux.
L‟évaluation d‟une contrainte permet de savoir si la contrainte est respectée ou non. OCL
donne des descriptions précises et non ambigües du comportement du logiciel en complétant
les diagrammes. Il définit des pré-conditions, des post-conditions et des invariants pour une
opération. Il permet aussi la définition des expressions de navigation et des expressions
booléennes. C‟est un langage de haut niveau d‟abstraction, parfaitement intégré àUML, qui
permet de trouver des erreurs beaucoup plus tôt dans le cycle de vie de l‟application. Cette
vérification d‟erreurs est rendue possible grâceà la simulation du comportement du modèle
[38], [39], [40], [41].
6. COMPOSITION DE MODELES
Dans[42], la composition de modèles est définie comme suit : « selecting what to
compose, where to place the composed concepts and finally determining how to integrate the
concepts at the selected location in the composed model ».
Pour synthétiser, on peut définir la composition comme une opération de gestion de
modèles, qui consiste à générer un seul modèle (appelé modèle composé) par combinaison du
contenu d'au minimum deux modèles. Plusieurs sujets de réflexion peuvent être identifies
concernant : l'opération de composition, le type de modèles sources, la syntaxe et la
sémantique du modèle composé,….
Chapitre I Ingénierie Dirigée par Modèle
-21-
La composition a un impact à trois niveaux selon[43]:
Niveau syntaxique : Expression du modèle composé issu des modèles d'entrée,
Niveau sémantique : Affectation d‟une sémantique au modèle composé, en fonction
de la sémantique des modèles sources associés,
Niveau méthodique : Utilisation du modèle composé, issu du processus de
composition, dans un processus de développement logiciel (Intégration au processus de
génération de code par exemple).
De ce fait, le processus de composition ne peut pas être considéré comme une opération
atomique. Avant de déclencher le processus de composition à proprement parler, il est
nécessaire d‟identifier les liens entre les éléments à composer ; suivie par une opération de
composition qui a pour objectif la création du modèle « global » en combinant les éléments
des modèles d'entrée à l'aide des relations définies dans le modèle de correspondance.
CONCLUSION
Dans ce chapitre nous avons essayé de définir les principaux concepts du domaine de
l‟ingénierie des modèles. En premier lieu, Nous avons mis en évidence le principal rôle des
modèles dans le processus de conception des systèmes. Nous avons présenté, par la suite, les
différentes techniques de traitement des modèles parmi lesquelles nous avons détaillé la méta-
modélisation ainsi que les techniques de transformation qui sont aujourd‟hui des pivots
majeurs pour l‟innovation dans les domaines de recherche liés à la conception des systèmes
complexes.
Chapitre II :
Composition de modèles
Chapitre II :
INTRODUCTION
1.COMPOSITION DE MODELES
1.1.DEFINITION
1.2.CLASSIFICATION DES APPROCHES
2.LES APPROCHES DE COMPOSITION
2.1.KOMPOSE
2.2.EPSILON MERGING LANGUAGE
2.3.VIRTUAL EMF
2.4.GENERICMODELINGENVIROMENT
2.5.LA PLATEFORME AMMA
2.6.ATLAS MODEL WEAVER
CONCLUSION
Chapitre II Composition de modèles
-22-
INTRODUCTION
Dans le processus de développement dirigé par les modèles, la composition de modèles
est un thème de recherche nouveau et très actif qui vise à automatiser et aussi à réutiliser le
même modèle PIM en cas de changement de plate-forme. Il s‟agit globalement d‟une
opération qui consiste à combiner un certain nombre de modèles pour en créer un ou
plusieurs.
Notre objectif dans ce chapitre est d‟étudier les approches de composition, analyser les
éléments utilisés en entrée puis présenter la méthodologie à suivre pour réaliser un tel
processus. Notre objectif principal sera donc de répondre aux questions suivantes :
- Qu'est-ce qu'on a en entrée ?
- Avec quel outil, on va faire la composition ?
- Comment on va faire la composition ?
- Qu'est-ce qu'on aura en sortie ?
1. COMPOSITION DE MODELES
Dans un processus de développement à base de modèles, la composition consiste à
combiner un certain nombre de modèles pour en créer un ou plusieurs. La composition
apparaît sous divers termes selon le contexte d'application.
1.1. DÉFINITION
"Model composition is an operation that combines two or more models into a single
one."[44].
"Model composition in its simplest form refers to the mechanism of combining two
models into a new one." [45].
Ces deux définitions peuvent être traduites diagrammatiquement comme la figure II.1.
Conformément à celui-ci, on peut dire que la composition de modèles 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
Chapitre II Composition de modèles
-23-
Figure II.1 : Processus de composition de modèles : vue simple
Néanmoins, ce schéma est très abstrait. Aucune hypothèse sur les modèles en entrée, sur
en sortie, ni sur l'opération de composition est exprimée. Dans la pratique, une approche de
composition de modèles doit préciser ces hypothèses pour son contexte de travail. Celles-ci
consistent également les différences permettant de classifier les approches.
1.2. CLASSIFICATION DES APPROCHES
1.2.1. CLASSIFICATION SELON LES CARACTERISTIQUES DES MODELES
EN ENTREE
a. La quantité des modèles en entrée : deux ou plusieurs.
Un processus de composition peut recevoir deux ou plusieurs modèles en entrée. Dans
la plupart des cas, chaque composition prend deux modèles, mais il existe des cas comme les
éditeurs EMF [46] où on peut composer plusieurs modèles à la fois (par l'importation des
modèles sous forme de ressources au même éditeur).
b. Le rôle des modèles composés : symétrique ou asymétrique.
Il existe des approches utilisant un modèle de base et des modèles des aspects au
moment de la composition. Ces approches, dites de composition asymétrique [47]utilisent le
même style de composition que les langages orientés aspect comme AspectJ. D‟autres
approches ne font pas de différence entre les modèles à composer ; ce sont des approches
symétriques [48].
c. Le type des modèles composés : structurel ou comportemental.
Certaines approches se focalisent sur la composition de modèles structuraux (schémas
de base de données [48], diagrammes de classes UML [49] etc.), certaines autres s'intéressent
aux modèles comportementaux (modèles de Pétri Net, diagrammes d'état UML [50]etc.).
Notons que, dans la première catégorie, certaines approches ne précisent pas les types
des modèles composés (ceux-ci peuvent être un ensemble des objets, les schémas de base de
donnée, les modèles UML etc. [48], [44].) alors que d'autres se restreintes aux modèles UML
[49].
Chapitre II Composition de modèles
-24-
d. L'hétérogénéité des modèles source :
Composition de même méta modèle ou différent méta modèles. Le premier cas est dit la
composition endogène, alors que le deuxième est dit la composition exogène.
1.2.2. CLASSIFICATION SELON LES CARACTERISTIQUES DES MODELES
EN SORTIE
a. La quantité des modèles en sortie : un ou plusieurs.
Le résultat final de l'opération de composition peut être soit un modèle composite [49],
[47]soit un ensemble comprenant les modèles d'entrée plus une troisième partie qui les intègre
[51].
1.2.3. CLASSIFICATION SELON LES CARACTERISTIQUES DE L'OPERATION
DE COMPOSITION :
a. Le type de composition : par opérateurs ou par relations.
Nous avons identifié deux types de composition : par opérateurs tels que la fusion, le
remplacement, l'union, le tissage etc. et par l'établissement des relations telles que
l'association, l'agrégation, l'héritage.
Dans le premier type, la composition est réalisée en exécutant les opérateurs de
composition sur les modèles sources ; alors que dans le second type, les modèles source sont
composées en utilisant les relations pour les connecter.
La différence est que les opérateurs ne sont pas une partie du modèle final ; tandis que
les relations font vraiment partie de ce modèle.
b. Les éléments de composition :
Ce sont les éléments supplémentaires participant aux compositions. Il y a deux axes de
classification : le type et le formalisme de ces éléments.
Le type d'éléments de composition :
Nous distinguons deux types d'élément de composition possibles : les spécifications de
composition et les relations.
Les relations expriment les liens de connexion entre les modèles. Elles sont à la fois les
éléments de composition et les éléments du modèle final. Les spécifications de composition
sont les éléments de composition mais par contre elles ne sont pas des éléments du modèle
Chapitre II Composition de modèles
-25-
final. Leur rôle est de modéliser les connaissances nécessaires au processus de composition.
En général, un processus de composition a besoin de connaître :
Quoi : spécifie quels éléments de modèle seront composés (ex. une classe, un
attribut, une méthode etc.) et leurs correspondances.
Comment : spécifie des opérateurs de composition (ex. correspondance (match),
remplacement (replace), redéfinition (over ride) etc.) qui vont être utilisés pour
composer des éléments indiqués.
Notons que, ces informations (i.e. quoi et comment) peuvent être modélisées par une ou
plusieurs spécifications de composition à la fois. Ceci dépend de chaque approche.
Par exemple, dans EML [52], ces informations sont décrites dans les spécifications des
règles de composition (règles de correspondance, règles de fusion et règles de
transformation), tandis que dans AMW [44](cf. section 2.6) elles sont réparties dans les
modèles de tissage et les transformations [53].
Le langage de composition :
Les éléments de composition ont besoin de formalismes pour les exprimer. Ces
formalismes sont très variés car chaque approche a ses propres éléments de composition. Ils
peuvent être un langage de tissage [44], un méta modèle des règles de composition [52], un
profil UML pour la composition de modèles [49]etc.
Malgré leur diversité, on peut généralement évaluer un formalisme de composition sur
deux points : les abstractions de composition qu'il fournit et son extensibilité. Le premier
point concerne ses primitives alors que le second point concerne sa capacité à permettre à
l'utilisateur de définir ses propres abstractions de composition.
La classification sur les formalismes se base donc sur deux points : les abstractions de
composition prédéfinies et l'extensibilité du langage.
c. Abstractions de composition prédéfinies :
De manière détaillée, il y a plusieurs variations autour ce point qui fait les différences
entre les approches. Par exemple, nous pouvons faire la classification selon les trois axes
suivants :
La variété de types des abstractions : {correspondance, tissage, la fusion,
remplacement, surcharge, ...}
Dans le cas de la composition par relations, ces abstractions sont les types de relation
tels que l'association, l'héritage, l'agréation. Dans le cas de la composition par opérateurs, ces
abstractions sont les opérateurs de composition primitifs tels que la correspondance
Chapitre II Composition de modèles
-26-
(matching), le tissage (weaving), la fusion (merging), le remplacement (replace), le surcharge
(override) etc.
La variété de quantité des abstractions :
Le nombre des abstractions est différent selon les approches. Par exemple, AMW
[53].propose un opérateur prédéfini : la correspondance (match) alors que EML [52] propose
trois opérateurs : la correspondance (match), la fusion (merge), et la transformation
(transform).
La variété d'implémentation des abstractions
Plusieurs approches peuvent proposer un même type d'abstraction de composition mais
l'implémenter différemment. A titre d'exemple, prenons la fusion de modèles (structurels,
orientés objet), cette abstraction est implémentée dans plusieurs approches mais chacune a sa
version.
Généralement, le processus de fusion de modèles peut être divisé en trois stades : avant,
pendant et après la fusion. La description d'une telle fusion est comme suit :
Avant la Fusion : il est probablement nécessaire de transformer (ou adapter) les
modèles pour que la fusion puisse être réalisée sans conflit.
Pendant la Fusion : il y a deux phases :
Phase de correspondances : Etablit les correspondances entre les éléments de
modèles. La découverte des correspondances peut être automatique, manuelle ou
semi-automatique.
Phase de fusion : Intègre les éléments en correspondance. Il est probable
d'avoir les conflits (ex., les éléments correspondants n'ont pas le même type). La
résolution de conflit est soit automatique (basée sur certaines stratégies de
résolution prédéfinies) soit manuelle (ex., faire apparaître un panel pour que
l'utilisateur résoudre le problème).
Après la Fusion : il est nécessaire de restaurer la cohérence du modèle final.
Cependant, dans la réalité, l'implémentation des approches ne respectent pas toujours
ce processus. Certaines approches proposent explicitement l'adaptation [54] mais
certaines autres non [52]. La manière de découvrir des correspondances est faite
automatiquement dans [52], [54] ; mais manuellement dans [53] ; et semi
automatiquement dans [50]. De la même manière, la résolution de conflit peut varier
entre manuel et automatique, même les stratégies de résolution sont différentes.
Chapitre II Composition de modèles
-27-
d. Extensibilité du formalisme : extensible ou non extensible.
Les abstractions prédéfinies avec les sémantiques prédéfinies permettent la réalisation
d'un grand nombre de scénarios de composition. Cependant, dans le cas général, ceci ne veut
pas dire que la composition se limite à ces actions. L'utilisateur a probablement besoin de
définir ses propres sémantiques de composition. Ceci entraîne la nécessité d‟extension du
formalisme de composition par la définition de nouvelles abstractions ou la redéfinition de la
sémantique d'une abstraction prédéfinie. Nous distinguons ainsi les formalismes extensibles et
non extensibles. Le premier type est plus flexible que le deuxième. Il permet de réaliser les
compositions de manière particulière.
Dans le cas extensible, nous distinguons aussi deux manières d'extension du langage : la
définition de nouvelles abstractions ou la redéfinition de la sémantique d'une abstraction
prédéfinie. La première est fournie dans AMW [44] ; alors que la deuxième est fournie dans
EML [52].
1.2.4. AUTRES CARACTERISTIQUES DE CLASSIFICATION
a. L'effet de composition : structure de modèle transformée ou préservée. Les
compositions peuvent transformer la structure des modèles source ou la préserver.
Composition poids lourd : La composition transforme la structure des modèles
composés (ex... la fusion des modèles).
Composition poids léger : La composition ne transforme pas la structure des
modèles composés (ex... établir des relations entre les modèles).
b. L'orientation de composition : Composition orientée transformation ou
composition pure.
Ceci est assez lié à la caractéristique de l'effet de composition mentionné ci-dessus.
Dans le cas de tissage, ou de fusion où il y a une transformation effectuée sur les éléments
sources pour produire les éléments cibles, la composition est dite orienté transformation, alors
que dans le cas d'établissement des relations, la composition est dite pure composition.
La figure II.2 donne une vue synthétisée de la classification des approches de
composition de Modèles.
Chapitre II Composition de modèles
-28-
Figure II.2 : Une vue synthétisée de la classification des approches de composition de modèles.[55]
Chapitre II Composition de modèles
-29-
2. LES APPROCHES DE COMPOSITION
2.1. KOMPOSE
Kompose est un outil open source, implémenté en Kermeta8[56], qui supporte la
composition de modèles. Il définit une approche conçue pour la modélisation orientée aspects.
Les préoccupations transverses9 sont définies dans un modèle d'aspect AM (Aspect Model)
alors que les fonctionnalités de base sont dans un modèle primaire PM (Primary Model). Le
processus de correspondance est implicite, il est assuré à travers une correspondance
automatique à base de noms et de signatures. Une signature est un ensemble de propriétés
syntaxiques associées à un type d‟élément [57]. La signature d'un élément de modèle
comprend les valeurs liées à ses propriétés. Le processus de correspondance est automatique,
mais après la spécialisation de certaines opérations de comparaison (par exemple : Equal) au
niveau méta-modèle.
2.1.1. PRINCIPE
Kompose est un Framework qui implémente une approche de modélisation orientée
aspect pour la composition de modèle à travers un ensemble de directives. Le schéma de la
Figure II.3 résume le processus de composition, qui est structuré en deux parties : la mise en
correspondance, qui identifie les éléments de modèles décrivant le même concept, et la
composition qui permet de créer de nouveaux éléments.
Figure II.3 : Processus de composition de Kompose
8Kermeta : est un langage de méta modélisation exécutable disponible en Open-source. Il dispose d‟un
environnement de développement de méta modèles basé sur EMOF dans un environnement Eclipse. Il permet
non seulement de décrire la structure des méta modèles, mais aussi leur comportement.
9Les préoccupations transverses : (en anglais crosscutting concerns) sont les fonctionnalités dites non métiers
Chapitre II Composition de modèles
-30-
2.1.2. PROCESSUS DE COMPOSITION
a. Phase de mise en correspondance
La phase de mise en correspondance se base sur l‟implémentation d‟un ensemble
d‟opérations qui sont spécialisées en fonction du domaine.
b. Phase de composition
Cette phase se base sur une méthode classique : elle est implémentée d'une manière
générique en utilisant l'introspection [58]. Les éléments ayant la même signature sont
composés et leurs contenus (propriétés et méthodes) sont comparés à leur tour puis composés.
Les éléments n'ayant pas de correspondant sont simplement copiés dans le modèle composé.
Cette technique pose certains problèmes, dans le sens où elle ne permet pas de composer des
éléments qui représentent le même concept lorsqu'ils possèdent des signatures différentes.
C'est par exemple le cas de deux classes possédant le même nom, mais ayant des propriétés
différentes (l'une abstraite et l'autre concrète). Le mécanisme proposé pour résoudre ces
conflits réside dans l'utilisation de directives de composition afin d'adapter les modèles
sources. Les directives de composition permettent de forcer des correspondances et d'en
rejeter d'autres ou bien de contourner les règles de fusion par défaut en les redéfinissant [59]. Il
existe donc deux types de directives :
pré-merge : Directives permettant d'adapter les modèles sources afin d'y introduire des
modifications avant d'entamer la composition,
post-merge : Directives appliquées dans le but de corriger le modèle composé. C'est
ainsi qu'on pourra par exemple éliminer des éléments de modèles qui ne doivent pas
apparaitre pour une raison ou une autre dans le modèle composé.
2.2. VIRTUALEMF
2.2.1. PRINCIPE
La majorité des approches de composition étudiées dans les sections précédentes
génèrent le modèle composé en y copiant (physiquement) les éléments de modèles à partir des
modèles sources. Une fois le modèle composé créé, les modèles qui ont servi à sa création
n'ont plus d‟importance, étant donné que l'utilisateur va agir directement sur le modèle
composé et que la manipulation des éléments du modèle est faite directement dans ce dernier.
Ces approches présentent des inconvénients au niveau :
du temps de création du modèle composé et de la consommation de mémoire dans le
cas de composition de modèles de grandes tailles,
de l'absence de synchronisation. Ce qui amène à exécuter le processus de
composition à chaque fois qu'il y a une modification dans les modèles sources.
Chapitre II Composition de modèles
-31-
L'approche VirtualEMF[62] permet de contourner ces limitations en proposant la notion
de modèle virtuel. VirtualEMF est un plug-in Eclipse construit au-dessus d’EMF
[63].Contrairement à un modèle concret, un modèle virtuel est un modèle qui ne contient pas
de donnée physique : il est défini comme un modèle qui redirige toutes ses demandes d'accès
et de manipulation directement à l'ensemble des modèles de base à partir desquels il a été
généré [64]. Cette méthode de virtualisation, présente les avantages suivants :
une meilleure synchronisation ; Les modèles sources et composés partagent les
mêmes instances d'éléments de modèles,
une création rapide du modèle composé et une utilisation réduite de la mémoire,
puisqu'il ne contient pas de données concrètes.
2.2.2. PROCESSUS DE COMPOSITION
Le schéma de Figure II.4 présente le processus de composition de VirtualEMF.
Figure II.4: Processus de composition de VEMF.
Ce processus de composition est quasi similaire à celui proposé dans [65]. La différence
réside dans l'ajout de la notion de modèle virtuel. Les différents accès au modèle virtuel sont
traduits par des opérations sur les modèles sources (principe de délégation). Deux APIs ont
été réalisées afin d'accéder aux modèles de façon transparente (Figure II.4) : une API de
virtualisation (VirtulizationAPI) et une API de gestion de liens (LinkingAPI). L'exploitation
de ces APIs est illustrée ci-dessous.
Chapitre II Composition de modèles
-32-
Figure II.5 : Les APIs de VEMF [64].
a. Phase de mise en correspondance
Dans cette phase, des relations entre les modèles sources sont établies (en utilisant
l'interface graphique d‟AMW) afin de produire le modèle de liens (WeavingModel). La
sémantique de ces relations est définie en étendant le méta-modèle de liens.
b. Phase de composition
La deuxième phase consiste à créer le modèle virtuel en invoquant une fonction (load)
de chargement des ressources. Cette fonction reçoit en entrée un fichier (virtualmodel) de
persistance qui stocke les emplacements physiques de toutes les ressources incluses dans ce
processus, à savoir : le Weaving Model, les modèles sources et leurs méta-modèles (Figure
II.5).
Le chargement sera suivi par l'établissement des liens implicites entre les modèles
sources et le modèle composé par VEMF. Ces liens permettent de manipuler de façon
transparente les éléments du modèle composé.
L'accès à un élément (virtuel) du modèle composé est pris en charge par l'API de
virtualisation. Si cette API détecte que cet élément est référencé dans le modèle de liens (i.e.
par des règle d‟association, d‟héritage, de composition, …) alors elle délègue la gestion de cet
élément à l'API de liens, dont le rôle est de gérer les différents types de liens puis de retourner
le résultat à l'API de virtualisation. Si ce n‟est pas le cas, l'API de virtualisation accède
directement à l'élément approprié dans le modèle source.
Chapitre II Composition de modèles
-33-
2.3. GENERICMODELINGENVIROMENT
Generic Modeling Enviroment (GME) [66], [67], [68], [69], [70] est un environnement de
modélisation générique pouvant être rendu spécifique en utilisant les paradigmes de
modélisation (les langages de modélisation dédié aux domaines - DSMLs) qui sont construits
aussi par l'environnement GME générique lui-même. Un paradigme de modélisation
formalise un méta modèle définissant la syntaxe, la sémantique et la présentation concrète du
DSML.
Les environnements de modélisation spécifiques configurés permettent ensuite de créer
les modèles. Ces modèles sont sauvegardés dans la base de données et puis sont utilisés pour
générer ou synthétiser automatiquement les applications. , [67], [68].
Tous les modèles définis par GME, quel que soit le paradigme, partagent un même
ensemble de concepts de modélisation générique, indépendant des paradigmes et partagés par
tous les environnements GME configurés. Ces concepts sont appelés FCOs (First Class
Objects) (formalisme).[67], [68]
Ils définissent des modèles d'un point de vue générique de sorte qu'un modèle est un
ensemble de parties composées sans préciser la nature de la partie. Cette nature va être
précisée par les concepts métiers du paradigme. Les concepts de FCOs ont capable de
composer/décomposer des parts permettant de créer et de gérer des modèles complexes.[69],
[70]
2.4. LA PLATEFORME AMMA
La plateforme AMMA [71]est un Framework qui offre de nombreuses opérations de
manipulation et de gestion de modèles telles que la transformation, le tissage et l'édition de
modèles et de méta-modèles. La Figure II.6 présente l'architecture d'AMMA basée sur EMF.
La fonction de transformation dans AMMA est assurée par le langage ATL. Un IDE
(Integrated Development Environment) et un moteur d'exécution ont été également
développés pour ce langage sous forme de plateforme Eclipse. Cet environnement facilite le
processus d'écriture de transformations grâce à un éditeur de code, un débogueur et un schéma
présentant une vue de la syntaxe abstraite de la transformation du programme en cours
d'édition.[71]
Chapitre II Composition de modèles
-34-
Figure II.6 : Architecture de la plateforme AMMA
Nous présentons ci-dessous les caractéristiques principales des composants d'AMMA :
ATL est un langage dédié de transformation de modèles. Il utilise des méta-modèles
source et cible pour définir une transformation de modèle. En dehors des transformations, il
peut être utilisé également pour la vérification de modèles [26].
KM3 est un langage de définition de méta-modèles basé sur les concepts du MOF2.0
[72] et EMF/Ecore [46]. La syntaxe concrète de KM3 est actuellement basée sur une notation
textuelle proche du langage Java.
L'outil AMW permet de définir des liens de tissage entre les éléments de deux ou
plusieurs modèles ; ces liens sont définis dans un modèle de tissage qui a pour objectif
principal la représentation des différents types de liens entre les éléments des modèles.
L'outil de gestion de méga-modèles AM3 fournit un support de modélisation et de
coordination globale entre les ressources dans un développement orienté IDM.
Le langage TCS [73]est un langage de transformation de programmes en modèles et
de modèles en programmes. Il sert à représenter syntaxiquement les concepts classiques d'un
langage (mots clé, symboles, structures de contrôle et d'ordonnancement, etc. En utilisant ce
langage, les modèles peuvent être sérialisés en texte et les fichiers textes peuvent être analysés
afin de générer les modèles correspondants.
L'outil ATP définit une série d'injecteurs/extracteurs permettant d'assurer les
opérations d'importation et/ou d'exportation de modèles venant d'espaces technologiques
différents (classes Java, modèles relationnels, etc.).
Chapitre II Composition de modèles
-35-
2.5. ATLAS MODEL WEAVER
Atlas Model Weaver (AMW) est un module d’AMMA (ATLAS Model Management
Architecture) [74] - une plateforme de gestion de modèles génériques. Ce module est destiné
particulièrement à la création de relations (i.e. des liens) entre les éléments de modèles (ou
méta modèles).
2.5.1. MODELES
Les modèles composés sont structuraux, orientés objet. A présent, AMW utilise EMF
comme le Handler de ses modèles. Le type de composition est par opérateur.
2.5.2. COREWEAVINGMETAMODEL
L’AMW est développé sur la base d'un méta modèle noyau de tissage. Ce méta modèle
noyau soutient la gestion de la liaison de base, à savoir n : n relations entre les éléments du
modèle. Les identifiants des éléments visés peuvent être enregistrées en utilisant différentes
méthodes d‟identification. Le méta modèle noyau de tissage est illustré dans la figure II.7 qui
fournit une description du méta-modèle AMW [74].
Figure II.7 : Méta-modèle AMW [74]
Chapitre II Composition de modèles
-36-
WElement est l'élément de base à partir de laquelle tous les autres éléments héritent. Il
a un nom et une description.
WModel représente l'élément racine qui contient tous les éléments du modèle. c'est
composé par les éléments de tissage et les références à des modèles tissés.
WLink remplit les première et seconde conditions. WLink exprimer un lien entre les
éléments du modèle, à savoir, il a une sémantique simples de liaison. Pour être en mesure
d'exprimer types de liens différents et la sémantique, cet élément est étendu avec différents
méta modèles (nous expliquent comment ajouter différents types de liens dans la section
suivante).
WLinkEnd gère la troisième condition (appelé lien critère). Chaque lien point final
représente un élément de modèle lié. De cette façon, il est possible de créer N-ary des liens.
WElementRef satisfait à la quatrième condition. Nous associons l'WElementRef
élément avec une fonction d'identification sur les éléments liés. La fonction prend en
paramètre l'élément de modèle à être lié et retourne un identifiant unique pour cet élément.
Pour des raisons pratiques, nous définissons un arbitre de champ de chaîne qui sauve la valeur
de la fonction de retour. Il y a aussi la fonction inverse qui prend la valeur de l'attribut ref, et
renvoie l'élément à partir du modèle correspondant.
WModelRef est similaire à l'élément WElementRef, mais il fait référence à un modèle
entier.
2.5.3. MECANISME DE COMPOSITION : TISSAGE ET TRANSFORMATION
Les modèles de tissage eux même ne sont pas le modèle composite résultat. Ce sont les
abstractions de l'opération de composition mais pas le modèle composite final. Cependant, ces
abstractions ne sont pas exécutables. Pour obtenir le modèle composite, il faut transformer ces
abstractions sous forme d'un programme exécutable (vers un langage de programmation par
exemple), puis l'exécution de ce programme va produire le modèle composite résultat
(manière de créer le modèle composite). Dans le cas de AMW, AMW propose de transformer
les modèles de tissage en programmes ATL (ATL est un langage de transformation de la
plateforme AMMA). Le processus de transformation d'un modèle de tissage vers le
programme ATL est réalisé par une autre transformation écrite aussi en ATL. Ce qu'on
appelle une transformation d'ordre supérieur (HOT - higher-order transformation) (élément de
composition). Un HOT est une transformation qui soit prend une transformation en entrée,
soit produit une transformation en sortie, soit les deux.
Chapitre II Composition de modèles
-37-
Pour chaque méta modèle de tissage étendu (pour la composition), il y a un HOT
différent. Ce HOT est unique et ne se change pas. Par contre, les modèles de tissage peuvent
être changés. Chaque fois que les modèles de tissage sont changés, la translation de nouveaux
modèles de tissage vers les nouveaux programmes ATL va s'effectuer par l'application de
même HOT. L'exécution des nouveaux programmes ATL va produire les nouveaux modèles
composites. La transformation de modèle de tissage vers le code ATL n'est qu'une possibilité
pour obtenir le modèle de composition exécutable. Ceci a pour but de profiter des facilités
fournies par la plateforme AMMA (dans ce cas, c'est le langage ATL). Cependant, il est
possible, au lieu d'utiliser ATL, d'utiliser les autres langages de transformation comme XSLT
pour traduire les modèles de tissage. De plus, le programme résultat n'est pas forcément en
ATL. Il peut être dans un langage d'exécution quelconque par exemple Java ou C.
CONCLUSION
Dans ce chapitre, nous avons essayé de mettre l'accent sur les principales approches de
composition de modèles représentatives. Abordée dans de nombreux travaux de recherche, Il
n‟y a pas encore de standard relatif à un tel processus. Néanmoins, nous avons survolé, les
principales méthodes à savoir : transformation, tissage…
Chapitre III :
L’ingénierie De Modèles
Orientée Aspects
Chapitre III :
INTRODUCTION
1.APPROCHE ORIENTEE OBJET
1.1.Les préoccupations transversales
1.2.Les problèmes du crosscutting
1.3.Conséquences
2.MODELISATION ORIENTEE ASPECT
2.1.Concepts et terminologie
2.2.La modélisation graphique d'un aspect à travers les diagrammes UML
2.3.Points faibles de la MOA
3.L’INGENIERIE DES EXIGENCES ORIENTEE ASPECTS (AORE)
3.1.Définition de l‟exigence
3.2.Définition de l‟AORE
3.3.Objectifs de L‟AORE
4.LES APPROCHES DE COMPOSITION ORIENTEE ASPECT
4.1.Composition de modèles dans l‟approche Theme et al
4.2.Composition de modèles dans l‟approche de France et al
4.3.Composition de modèles dans l‟approche MATA
5.SYNTHESE DES DIFFERENTES APPROCHES DE COMPOSITION
5.1.Critères de comparaison
5.2.Tableau comparatif des approches
CONCLUSION
Chapitre III L’ingénierie De Modèles Orientée Aspects
-38-
INTRODUCTION
Depuis son apparition dans les années 90, l'orienté objet est un paradigme qui a montré
son importance dans la résolution des problèmes complexes. Mais avec l'évolution de
l'informatique, les problèmes sont devenus plus complexes à gérer et l'orienté objet a trouvé
des limites pour lesquelles ce paradigme n'a donné aucune solution. Il a été incapable de faire
face aux problèmes de la duplication, l'enchainement du modèle, la difficulté de réutilisation
des modèles et l'interaction entre les modèles fonctionnels et non fonctionnels. Pour cela, une
nouvelle ère de modélisation a vu le jour. Il s'agit d'un nouveau paradigme appelé
"paradigme orienté aspect".
Ce chapitre est décomposé en plusieurs sections. La première section présente une brève
introduction au paradigme orientée objet qui se focalise sur ses capacités et de ses incapacités
de modularisation suivi d'une étude de la solution proposée qui est l‟approche orientée aspect.
Les sections suivantes vont permettre d'exposer les différents concepts et terminologie utilisés
dans l‟approche orientée aspect et dresser un bilan de ses différentes approches de
composition.
1. APPROCHE ORIENTEE OBJET
Dès le début des années 80, une nouvelle approche a été créée afin d‟améliorer une
solution aux problèmes posés par l‟approche procédurale (modulaire) (la réutilisation,
dissocier les données des fonctions, absence de technique permettant de favoriser la
spécialisation). Cette nouvelle approche est dite approche orientée objet qui vise à découvrir
une nouvelle entité appelée objet :
Créée afin de regrouper les fonctions et les données.
Caractérisé par : un état (les valeurs des attributs), un comportement (les opérations
possible sur un objet (les méthodes)), une identité (le nom de l‟objet).
C‟est grâce aux nombreux concepts du paradigme orienté objet [75] (l‟encapsulation
[76], le mécanisme d‟héritage et le polymorphisme, etc.) que l‟approche orientée objet
améliore la réutilisabilité d‟un système complexe.
L’encapsulation est une technique de mise en œuvre du principe de décomposition
modulaire, produisant ainsi des modules à faible couplage qui, de plus, doivent présenter
Chapitre III L’ingénierie De Modèles Orientée Aspects
-39-
chacun une et une seule entité logique à forte cohésion. Elle permet aussi de cacher les détails
d‟implantation au-dessous des interfaces.
Le polymorphisme caractérise la possibilité de définir plusieurs fonctions de même
nom mais possédant des paramètres différents. Grâce à de tels concepts, l‟approche orientée
objet possède un potentiel pour faire accroître la productivité, la flexibilité et la
compréhensibilité d‟un système informatique, assurant ainsi l‟évolution et la réutilisation des
logiciels.
Cependant, cette réutilisation n‟est pas toujours aisée. C‟est notamment le cas pour les
applications dont la construction ne se limite pas à la simple définition d‟un ensemble de
services attendus, mais nécessite également la prise en compte de différentes propriétés non
fonctionnelles. En effet, du fait des contraintes d‟exécution, il est constamment nécessaire d‟y
intégrer différentes propriétés non fonctionnelles comme, par exemple, la gestion de la
mémoire, la persistance ou dans un cadre réparti, la répartition des données, la
synchronisation, etc. Or, il s‟avère que les unités de décompositions fonctionnelles et les
propriétés non fonctionnelles sont souvent orthogonales et leur intégration dans un
programme unique est compromettante dans le sens où elle conduit à des programmes peu
lisibles, difficiles à faire évoluer, à maintenir et à réutiliser.
La décomposition fonctionnelle adoptée par l‟approche orientée objet nous donne
toujours comme résultat des préoccupations transversales (crosscutting concerns) affectant
ainsi le développement de l‟application de différentes façons.
Dans ce qui suit, nous présentons deux problèmes récurrents de l‟approche orientée
objet ainsi que leurs implications.
1.1. LES PREOCCUPATIONS TRANSVERSALES
Une préoccupation est l‟abstraction d‟un but particulier ou une unité modulaire
d‟intérêt. Un système typique admet principalement deux types de préoccupations : des
préoccupations fonctionnelles et des préoccupations techniques (non fonctionnelles) [77].
Dans [78] , nous trouvons comme exemple un cas de contrainte d‟intégrité référentielle :
un objet client ne peut être supprimé s‟il n‟a pas honoré toutes ses commandes. Comme la
classe client n‟est pas censée connaitre les contraintes imposées par les autres classes et que la
classe commande n‟a aucune raison de permettre la suppression d‟un client, nous nous
retrouvons face à un problème quant à la séparation indépendante des tâches. C‟est ce que
Chapitre III L’ingénierie De Modèles Orientée Aspects
-40-
l‟on appelle une fonctionnalité transversale (crosscuttingconcern). Alors que le découpage
des données en classes a pour but de rendre les classes indépendantes entre elles. Les
fonctionnalités transversales telles que les contraintes d‟intégrités référentielles viennent se
superposer à ce découpage et brisent l‟indépendance des classes. L‟approche orientée objet ne
fournit aucune solution, pour ce genre de problème.
Il existe différents types de préoccupations transversales, dont les principales familles
sont les suivantes [79] :
Préoccupations orientées données
Persistance des données
Contrôle d‟accès aux données (gestion de droits, d‟utilisateurs autorisés, de groupes)
Préoccupations orientées fonctionnalités
logging/tracing.
Préoccupations orientées règles de gestion
De gestion d‟exceptions, de debugging et de tests, etc.
Préoccupations architecturales
Interopérabilité entre applications hétérogènes
Schémas de connexion entre composants répartis
Préoccupation de débogage
Génération de la trace
1.2. LES PROBLEMES DU CROSSCUTTING
Une utilisation classique de l‟approche orientée objet pour traiter ce phénomène de
crosscutting, impose de mêler le code des préoccupations transversales au code des classes
définissant l‟application. De tels enchevêtrements introduisent des problèmes récurrents, qui
compromettent la réutilisation des implantations de l‟ensemble des unités fonctionnelles ainsi
que celles des propriétés transversales de l‟application, indépendamment les unes des autres
Chapitre III L’ingénierie De Modèles Orientée Aspects
-41-
[80], [79]. Nous distinguons principalement deux problèmes induits par l‟approche orientée
objet :
L’enchevêtrement du code (Code Tangling) :L‟approche orientée objet conduit à
l‟enchevêtrement du code source correspondant aux services de base de l‟application, traités
par les différentes classes, avec celui correspondant aux différentes propriétés
transversales.[81]
La dispersion du code (Code Scattering) : L‟approche orientée objet conduit à la
dispersion du code correspondant à chacune des propriétés transversales dans la description
des différentes classes concernées par ces propriétés.[81]
Combinés ensemble, ces deux problèmes récurrents contrarient le principe de séparation des
préoccupations et affectent ainsi, la conception et l‟implantation de l‟application de plusieurs
façons. Dans ce qui suit, nous illustrons tout d‟abord ces deux problèmes et nous détaillons
ensuite leurs implications.[81]
1.2.1. DISPERSION DU CODE
La dispersion du code signifie que la spécification d‟une propriété du système n‟est pas
encapsulée dans un seul module. Par exemple, dans un système de gestion de base de
données, il est possible que l‟optimisation des performances, la journalisation (logging) et la
synchronisation puissent concerner toutes les classes accédant à la base de données. On voit
donc que ces aspects doivent être implémentés dans plusieurs modules sans être bien
circonscrits. Il s‟agit très souvent de portions de code similaires à ajouter un peu partout dans
les modules concernés par ces propriétés. Dans la figure III.1.a, les colonnes illustrent les
différents modules et les parties apparaissant en couleur foncée représentent les
préoccupations. Ces dernières sont dispersées sur presque tous les modules.[81]
a) Code dispersé (mauvaise modularité)
Chapitre III L’ingénierie De Modèles Orientée Aspects
-42-
A l‟opposé, la figure III.1.b donne un exemple d‟une préoccupation circonscrite dans un
seul module.
b) Code regroupé (bonne modularité)
Figure III.1 : Modularité : l’Idéal vs. Réalité (extrait de [81])
1.2.2. ENCHEVETREMENT DU CODE
Chaque module du système contient la description de plusieurs propriétés ou de
fonctionnalités différentes. Un problème qui découle directement du constat précédent est que
certaines préoccupations non-fonctionnelles viennent recouper l‟implantation des
préoccupations fonctionnelles. Il en résulte la présence d‟éléments de plusieurs
préoccupations dans l‟implantation d‟un seul et même module
1.3. CONSEQUENCES
Plus faible réutilisation : Une unité de décomposition fonctionnelle implémente des
propriétés transversales multiples. Les autres systèmes qui nécessitent des services similaires
(offerts par cette unité de décomposition fonctionnelle) ne sont pas forcément capables
d‟utiliser directement cette unité de décomposition modulaire. En effet, les unités de
décompositions fonctionnelles regroupent non seulement leurs comportements propres mais
en plus, elles y mêlent des propriétés transversales, diminuant ainsi la compréhension et
éventuellement la réutilisation de ces unités. Aussi, la réutilisation d‟une propriété
transversale dans d‟autres systèmes est compromise, du fait de la dispersion du code
implantant cette propriété à travers l‟ensemble des unités concernées par cette dernière.
Pauvre qualité du code : l‟enchevêtrement du code final de l‟application produit
souvent un code mêlant plusieurs préoccupations dissimulées. De plus, en ciblant trop de
propriétés transversales en même temps, certaines d‟entre elles risquent de ne pas recevoir
l‟attention nécessaire.
Chapitre III L’ingénierie De Modèles Orientée Aspects
-43-
Evolution difficile : une vue limitée et des ressources limitées produisent généralement
un modèle de conception qui ne répond qu‟aux problèmes actuels. Répondre aux problèmes
futurs nécessite souvent de retravailler toute l‟implantation. Comme celle-ci n‟est pas
modularisée, cela veut dire que de nombreux modules de décomposition devront être
modifiés. Modifier chaque sous-système pour propager les modifications peut conduire à des
incohérences.
Les deux problèmes précédents entraînent des conséquences négatives sur le
développement du logiciel telles que :
Mauvaise traçabilité : l‟implantation simultanée de plusieurs propriétés transversales
dans l‟ensemble des unités de modularisation fonctionnelle avec lesquelles elles interagissent,
rend obscure la correspondance entre une préoccupation et son implémentation. Cette
mauvaise traçabilité nuit à la compréhension et par conséquent à l‟évolution et à la
réutilisation du code source relatif à cette préoccupation.
Faible productivité : l‟implantation simultanée de plusieurs propriétés transversales
éloigne l‟attention du développeur du but final, vers les besoins annexes, limitant d‟autant la
productivité de l‟application. De même, reconsidérer les préoccupations de manière répétitive
(i.e. dans chaque module) réduit la productivité.
2. MODELISATION ORIENTEE ASPECT
Pour résoudre les problèmes de la modélisation orientée objet, il serait intéressant de
modulariser l'implantation des modèles transverses (technique, non fonctionnel)
indépendamment les uns des autres. On parle alors de séparation de ces modèles
(fonctionnels, non fonctionnels) et de les combiner ultérieurement pour produire le modèle
final. La Modélisation Orientée Aspect (MOA) est ce but.
La Modélisation Orientée Aspect (MOA) permet d‟identifier chaque préoccupation
indépendamment des autres, puis elles sont assemblées selon des règles bien définies. La
séparation entre un modèle métier (fonctionnel) et un modèle technique (non fonctionnel)
consiste à séparer les préoccupations transverses des préoccupations de base et sont
encapsulées dans des nouvelles unités modulaires appelées «aspect» [82], [83], [84].
Aussi l‟approche fournit de nouvelles techniques de composition pour combiner les
aspects et les unités modulaires de base [83]qui utilise un mécanisme d'intégration pour
obtenir le modèle intégré (métier + aspect). D'autre part si on constate la manière de
l'intégration on trouve que chacun a sa propre composition selon son besoin, son problème et
Chapitre III L’ingénierie De Modèles Orientée Aspects
-44-
son domaine d'application ; pour cela il existe plusieurs travaux sur la composition
d'aspect[85], [86],[87].En conséquence, la modularité du système est améliorée et le système
devient facile à maintenir [83].
Le paradigme orienté aspect a été proposé initialement en 1997 par Kiczales et son
équipe [79].Pawlak et son équipe ont proposé en 2004[78]une amélioration de ce paradigme. Il
permet la résolution des problèmes très complexes, de grandes tailles, et de donner des
solutions meilleures.
Bouanaka[88] a présenté une approche pour l‟intégration du paradigme orienté aspect
dans le modèle de cas d‟utilisation. Il a ajouté de nouvelles notations pour le package cas
d‟utilisation pour capturer essentiellement les exigences dites non fonctionnelle du serveur
d‟application.
Breu et al. [89]ont tenté d‟identifier les préoccupations transverses dans le projet Eclipse
en utilisant des techniques d‟analyse formelles. Une étude sur l'application de trois techniques
d'extraction d'aspect pour identifier des préoccupations présentes dans JHotDraw10
a été
réalisée pour étudier les forces d'identification d'aspect et les faiblesses de chaque technique.
Un outil d'extraction peut ne pas suffire pour identifier les aspects car chacun emploie une
méthode différente. Par conséquent, un mélange de différentes techniques est conseillé.
Durr et al. [90]ont essayé de transformer les préoccupations transverses, tels que la
gestion des erreurs, en aspect et ont essayé de montrer l‟importance de la factorisation en
aspect. Ils ont utilisé AspectBrowser11
pour identifier les aspects qui sont supposés connus à
l‟avance. Il est important de préciser que la majorité des études de cas étudiées, pour identifier
les préoccupations transverses, sont relatives au programme JHotDraw, et ne concernent pas
des études de cas réelles.
En général, le cycle de développement de la MOA se fait en trois étapes :
La décomposition aspectuelle : Elle consiste à décomposer les besoins afin d'identifier
et séparer les modèles transverses encapsulés dans des modules aspects (techniques, non
fonctionnels) et métiers (de base, fonctionnels) qui peuvent être modularisés dans des
modules de base tel que classe.
10
JHotDraw :JHotDraw est un framework Java GUI pour Graphiques techniques et structurés. Il a été développé
comme un «exercice de conception», mais est déjà très puissant. Sa conception repose fortement sur certains
modèles de conception bien connus. 11
Aspect Browser : c‟est un outil pour aider les changements évolutifs en rendant le code associé à un
changement global (une sorte d‟aspect)
Chapitre III L’ingénierie De Modèles Orientée Aspects
-45-
Implantation des modèles : Elle consiste à implanter chaque modèle séparément. Les
modèles métiers sont implantés par les techniques conventionnelles de la modélisation
orientée objet alors que les modèles transverses sont implantés par les techniques de la
modélisation orientée aspect.
Recomposition aspectuelle : Elle consiste à construire le système final en intégrant ou
recoupant les modèles métiers avec les modèles transverses. Cette phase est appelée tissage
(weaving en anglais). Un tisseur (weaver) utilise des règles spécifiées par le concepteur de
l'application afin de recouper correctement les modèles entre eux. Le tissage d'aspects est une
opération qui accepte en entrée les modules de base et les modules d'aspect. Leur but est
l'application et l'attachement des aspects dans les modules de base selon les points de jonction
correspondant à la spécification des points de coupure d'aspect.
2.1. CONCEPTS ET TERMINOLOGIE
Toute nouvelle approche de modélisation nécessite l'introduction de nouveaux concepts,
de nouveaux langages et de nouveaux outils. De nouveaux concepts sont introduits avec la
MOA afin de permettre aux développeurs de spécifier et de modéliser les préoccupations
transverses. Ces concepts sont :
2.1.1. PREOCCUPATIONS :
Selon la définition décrite dans [91] et conforme à [92], une préoccupation est définie
comme un intérêt relatif au développement d'un système, ayant un rôle critique ou important à
un moment donné du développement. Une préoccupation est alors soit une préoccupation non
transversale qui peut être liée à sa fonctionnalité appelée préoccupation de base, soit une
préoccupation transversale, qui peut être liée à des exigences non fonctionnelles appelées
préoccupation d'aspect ou simplement aspect.
Préoccupation de Base : Une base est une unité de modularisation qui peut être
représentée dans un module de manière isolée en respectant une décomposition dominante
[93]. Elle représente donc une préoccupation non transversale (fonctionnelle) qui peut être
capturée de manière efficace avec des approches traditionnelles telles que l‟approche orientée
Objet.[91]
Préoccupation d'aspect : Un aspect est une unité de modularisation qui est entremêlée
avec les autres préoccupations, quelles soient de base ou d'aspect. Elle représente donc une
préoccupation transversale (non fonctionnelle) qui peut être capturée de manière efficace avec
l'approche orientée Aspect.[91]
Chapitre III L’ingénierie De Modèles Orientée Aspects
-46-
2.1.2. POINT DE JONCTION :
Endroit dans le modèle où les conseils (advice) devraient être insérés.
2.1.3. POINT DE COUPE :
Un ensemble de points de jonction, souvent une expression régulière et signifie le choix
des points de jonction pour l'application de conseils.
2.1.4. CONSEIL :
Une partie du modèle qui contient la totalité ou une partie de l'aspect inséré avant ou
après ou autour d'un point de jonction. Il implante une préoccupation transverse.
2.1.5. ASPECT :
Module définissant des Conseils et leurs points d'activation.
2.1.6. TISSEUR (WEAVER EN ANGLAIS) :
Est un outil spécial permettant d'intégrer ou de composer les aspects au modèle de base
pour obtenir un modèle final (base + aspect).
2.1.7. MECANISME D’INTRODUCTION
Permet de modifier la structure du code de base (ajout d'attribut, ajout de méthodes,
ajout d'un lien d'héritage, ...)
2.2. LA MODELISATION GRAPHIQUE D'UN ASPECT A TRAVERS
LES DIAGRAMMES UML
Il existe aujourd'hui plusieurs langages de modélisation graphique adaptés au monde
relationnel, au recueil de besoin, à la traçabilité,..., etc. Dans le domaine de la modélisation
Orientée Objet, UML fait quasiment l'unanimité aujourd'hui même si de nouveaux outils
introduiront certainement leur propre notation d'ici quelques mois (Microsoft, WhiteHorse)
certains outils MDA dédiés à un domaine particulier. C'est donc ce langage que nous avons
choisi pour exprimer nos modèles de Conception Orientée Aspects [94], [86], [85].
Dans les Figures (III.2) et (III.3), nous présentons la modélisation graphique d'un aspect
à travers un exemple qui explique les déférents concepts de base de la MOA et pour résoudre
le problème d'équation du premier degré telle que X est une valeur inconnue.
Chapitre III L’ingénierie De Modèles Orientée Aspects
-47-
Figure III.2 : le modèle de base et le modèle d'aspect[23]
Figure III.3 : Le modèle composé base + aspect[23]
2.3. POINTS FAIBLES DE LA MOA
Selon [23]la modélisation orientée aspect ne peut être élégamment appliquée à toutes les
situations de problèmes possibles en plus des limites de MOA [95], ce qui suggère que :
La gestion des transactions, par la coupe transversale, est difficile à factoriser dehors
dans un aspect distinct.
Chapitre III L’ingénierie De Modèles Orientée Aspects
-48-
La MOA est surtout adaptée pour les projets de développement de logiciels à grande
échelle.
Dans les systèmes distribués la MOA apporte avec elle certaines difficultés en ce qui
concerne les tests et le débogage. Cela est dû à des effets secondaires qui se dégagent
de la dynamique injection du modèle et qui pourraient, dans le pire des cas, conduire à
des ambiguïtés sémantiques dans le flux de contrôle d'un modèle orienté aspect.
Les différents aspects peuvent effectivement nuire même aux points de jonction dans le
tissage. Ainsi, la MOA peut violer le principe d'encapsulation, bien que d'une manière
assez systématique et bien contrôlée.
3. L’INGENIERIE DES EXIGENCES ORIENTEE ASPECTS
(AORE)
3.1. DEFINITION DE L’EXIGENCE
Ross définit une Exigence comme :
Une évaluation précise du besoin auquel le système devra répondre. Les exigences
doivent exprimer pourquoi le système est requis et préciseront quelles sont les
fonctionnalités du système qui serviront et satisferont ce contexte. Elles doivent
également préciser comment le système est construit [96].
3.2. DEFINITION DE L’AORE
Les approches d‟analyse des exigences orientées aspects sont des approches qui
explicitement reconnaissent l'importance d‟identifier, traiter, raisonner sur des préoccupations
transversales/besoins durant la phase d'analyse des exigences [91], [97].
Les techniques d'ingénierie des exigences qui reconnaissent explicitement l'importance
d'identifier clairement et traiter des préoccupations transversales d'une manière précoces sont
appelées les approches d'ingénierie des exigences orientées aspect. Les préoccupations
transverses peuvent être des exigences non fonctionnelles aussi bien que des exigences
fonctionnelles. Leurs identifications précocés permettent l'analyse précoce de leurs
interactions.
Ces approches se concentrent sur le principe de la composition de toutes les
préoccupations pour avoir le système complet en cours de construction.
Chapitre III L’ingénierie De Modèles Orientée Aspects
-49-
Ainsi, il est possible de comprendre les interactions et les compromis entre les
préoccupations. La composition des besoins permet non seulement d'examiner les exigences
dans leur ensemble, mais aussi la détection des conflits potentiels très tôt dans le but de
prendre des mesures correctives ou décisions appropriées à la prochaine étape [98].
3.3. OBJECTIFS DE L’AORE
Malgré la grande importance qui représente l‟ingénierie des exigences orientée
aspect(AORE), la plupart des praticiens dans le domaine des logiciels d'aujourd'hui ne sont
pas conscients de cette nouvelle méthodologie et de ses avantages. L’AORE vise à traiter les
propriétés transverses, de manière systématique afin de faciliter un raisonnement réel sur leur
impact dans le domaine du problème, ainsi la modularisation de telles propriétés transversales
dans la spécification des exigences permet qu‟elles puissent être effectivement projeté et donc
tracer, dans le domaine de la solution [97].
4. LES APPROCHES DE COMPOSITION ORIENTEE ASPECT
Il existe un grand nombre d‟approches de modélisation orientées-aspect, comme nous le
montre l‟étude proposée par le réseau européen d‟excellence AOSD12
-Europe [99].
4.1. COMPOSITION DE MODELES DANS L’APPROCHE THEME ET
AL
L‟approche Theme de Clarke et al. [100], [101], [102], [103]est une approche
d‟analyse/conception orientée aspect, définie comme une extension du langage UML pour
supporter la modularisation des préoccupations d‟un système, notamment les préoccupations
transverses (transactions, distribution, etc.). Le modèle de développement proposé par cette
approche se situe à deux niveaux : le niveau d‟identification (analyse) des exigences
(Theme\Doc) et le niveau de conception (Theme\UML).[104]
Theme\Doc propose un modèle à base d‟un graphe d‟analyse et un support pour la
visualisation et la spécification des exigences d‟un système. Ce niveau sert à documenter et à
identifier les relations entre les fonctionnalités à concevoir, et à révéler les fonctionnalités du
système considérées comme transverses.[105]
Theme\UML permet de modéliser les fonctionnalités et les aspects du système, et de
spécifier comment ces thèmes doivent être composés.[105]
12
AOSD : le développement de logiciels orientée aspect est une technologie de développement de logiciels qui
cherche de nouveaux modularisations de systèmes logiciels afin d'isoler des fonctions secondaires ou de soutien
à partir du programme principal de la logique métier . AOSD permet à de multiples préoccupations soient
exprimées séparément et unifiés automatiquement dans les systèmes de travail.
Chapitre III L’ingénierie De Modèles Orientée Aspects
-50-
Nous allons nous focaliser sur Theme/UML qui est nous explicitons comment les
modèles de conception (Themes) sont composés dans cette approche.[105]
4.1.1. Aperçu de l’approche THEME\UML
Theme\UML a pour but de résoudre le problème de la dispersion des exigences dans les
modèles de conception. Un Theme correspond à un élément de conception permettant
l‟encapsulation d‟une fonctionnalité ou d‟une préoccupation transverse. Il est représenté par
un paquetage stéréotypé par « theme ». Il peut être combiné avec d‟autres Themes à l‟aide
d‟une relation de substitution appelée „bind‟ qui exprime la composition entre deux
Themes.[105]
Un Theme est représenté par un paquetage paramétré. Chaque paramètre correspond à
une classe et à l‟ensemble des méthodes sur lesquelles la fonctionnalité doit être tissée. La
partie structurelle du système est souvent représentée dans Theme\UML par des diagrammes
de classes, tandis que les diagrammes de séquence sont utilisés pour décrire le comportement.
[105]
4.1.2. La composition
Theme/UML est une approche dite symétrique, c‟est-à-dire que Theme n‟établit pas de
distinction forte entre un modèle de base et un modèle d‟aspect. [105]
Chaque préoccupation est encapsulée dans un theme, qui est un paquetage UML portant
le stéréotype «theme». La figure III.4 décrit deux themes (Observer et Library). Les themes
d‟aspect présentent tout de même une distinction par rapport aux themes de base. En effet, un
theme d‟aspect comporte un mécanisme de template (similaire à celui de France et al.) qui
permet l‟instanciation de paramètres template. Trois types de compositions sont possibles : la
fusion, le remplacement (pour la composition de deux themes de bases), et l‟association (pour
la composition d‟un theme de base avec un theme d‟aspect). Le tissage des deux themes de la
figure III.4 est représenté dans la figure III.5.Comme le theme Observer est un theme
d‟aspect, la composition utilise une association. Sur la figure III.4, nous pouvons voir la
description de l‟association (Bind [. . .]) qui est liée au template du theme Observer. La classe
BookCopy joue le rôle de Subject, les méthodes borrowCopy () et returnCoppy () jouent le
rôle de _aStateChange (..), etc. [105]
Chapitre III L’ingénierie De Modèles Orientée Aspects
-51-
Figure III.4 : Le modèle d’aspect d’un patron sujet-observateur en utilisant Theme
Chapitre III L’ingénierie De Modèles Orientée Aspects
-52-
Figure III.5 : Le modèle tissé en utilisant la notation de Theme
4.1.3. Discussion
Theme est une approche dont l‟intérêt majeur porte sur la méthodologie qu‟elle propose. A
l‟opposé, bien que Theme utilise des themes qui comportent une partie structurelle et une
partie comportementale, les inconvénients de themes sont, premièrement qu‟il n‟existe pas
d‟outils et de formalisations des mécanismes de composition. Deuxièmement, Theme ne
propose pas de mécanisme de détection de points jonction.[105]
Chapitre III L’ingénierie De Modèles Orientée Aspects
-53-
4.2. COMPOSITION DE MODELES DANS L’APPROCHE DE
FRANCE ET AL
4.2.1. Aperçu :
L‟approche de France et al. [106], [107]est basée sur UML2.0, et récemment, elle a été
améliorée dans [108], [109], en proposant des mécanismes de composition plus aboutis, mais
concernant essentiellement les diagrammes de classe. Les modèles d‟aspects (les
préoccupations d‟aspects modélisées) sont représentés en utilisant des “diagrammes
templates”.[105]
Plus précisément, ce sont des templates de diagrammes de classe et de diagrammes de
communications qui décrivent respectivement les parties structurelles et comportementales
des aspects. Pour améliorer la lisibilité de leurs aspects, les auteurs préfèrent fournir une
notation des templates différentes de celle proposée par UML2.0. France et al. proposent
également une brève description d‟un processus de conception de modélisation orientée-
aspect.[105]
Figure III.6 : Le modèle d’aspect d’un patron sujet-observateur en utilisant la notation de
France et al.
Chapitre III L’ingénierie De Modèles Orientée Aspects
-54-
4.2.2. La composition :
Selon [105], France et al. établissent une distinction entre les modèles d‟aspect et les
modèles de base. Les modèles d‟aspect sont modélisés en utilisant des diagrammes templates,
qui sont décrits par des paquetages paramétrés (Figure III.6). A partir des diagrammes
template, une association textuelle (et donc explicite) à une application donnée, permet
l‟instanciation d‟un modèle d‟aspect spécifique à un contexte donné (Figure III.7).
L‟association suivante instancie le modèle d‟aspect de la Figure III.6 et permet l‟obtention du
modèle d‟aspect spécifique à un contexte, représenté sur la Figure III.7 :
Figure III.7 : Un modèle d’aspect spécifique à un contexte donné en utilisation l’approche de
France et al.
Le modèle d‟aspect spécifique à un contexte est ensuite composé avec un modèle de
base. Dans [108], les auteurs introduisent un mécanisme de composition, appelé signature-
based composition supporté par des directives de composition. Malheureusement, le
mécanisme de composition n‟est pour l‟instant appliqué qu‟aux diagrammes structurels. Par
contre, il est défini en termes de composition de méta modèle et il est implanté dans
l‟environnement Kermeta. Les directives de composition servent à la résolution de conflits
entre éléments (par exemple, lorsque deux classes ont le même nom).[105]
Chapitre III L’ingénierie De Modèles Orientée Aspects
-55-
Les directives de composition permettent également, entre autres, d‟ajouter, de
supprimer, de remplacer des éléments d‟un modèle. Finalement, ils contiennent des directives
telles que “precedes” et “follows” dérivées de la méta classe Dependency d‟UML, permettant
de spécifier un ordre de composition des modèles d‟aspect avec le modèle de base.[105]
4.2.3. Discussion :
L‟approche de modélisation orientée-aspect de France et al. est une des approches
existantes les plus avancées. Ils proposent des mécanismes de composition évolués qui sont
réellement implantés et donc utilisables. Nous pouvons tout de même faire deux critiques
majeures à leur approche. Premièrement, ils ne proposent pas de mécanisme de détection de
points de jonction. Deuxièmement, les mécanismes de composition sont restreints aux
modèles statiques.[105]
4.3. COMPOSITION DE MODELES DANS L’APPROCHE MATA
4.3.1. Aperçu :
L‟approche MATA (Modeling Aspects using a Transformation Approach) [110][111] est
une approche de composition de modèles d‟aspect qui utilise les techniques de transformation
de modèle. Plus précisément, elle utilise un langage de transformation à base de règles de
réécriture de graphes. La procédure de composition est asymétrique, car elle fait la distinction
entre un modèle de base et un modèle aspect. MATA définit un modèle d‟aspect comme une
combinaison de deux parties dépendantes : un patron et une spécification de composition. Le
patron est utilisé pour détecter un emplacement dans le modèle de base où les spécifications
de composition seront appliquées. Même si les modèles d‟aspect et le modèle de base utilisent
la même syntaxe concrète, ils sont syntaxiquement différents à cause de la présence des
variables de patron, et des annotations utilisées par la spécification de composition.[104]
MATA définit trois types d‟annotations représentés par les stéréotypes suivants : create,
deleteetcontext. Le stéréotype createest utilisé pour annoter les éléments qui vont être ajoutés
dans le modèle de base, alors que les éléments marqués par le stéréotype delete vont être
supprimés du modèle de base. Le stéréotype contextest utilisé pour éviter d‟appliquer un
stéréotype à plusieurs éléments dans le cas où un élément est annoté par un de ces stéréotypes
et contient d‟autres éléments.[104]
Chapitre III L’ingénierie De Modèles Orientée Aspects
-56-
4.3.2. La composition :
Le processus de composition avec MATA se fait en deux temps : d‟abord un motif
décrit par le patron de l‟aspect est recherché dans le modèle de base, puis on procède à la
modification de ce motif selon la spécification de composition.[104]
L‟approche MATA a été développée initialement dans le contexte de la modélisation
orientée aspect. La technique de composition peut être généralisée à la composition de
plusieurs modèles, en considérant une chaîne de transformation par application successive de
modèles d‟aspect. Bien que l‟approche supporte la composition des diagrammes de classes,
des diagrammes de séquence et d‟états d‟UML, elle peut être adaptée à d‟autres modèles
UML ou d‟autres langages de modélisation décrits par un métamodèle.[104]
L'outil support de MATA est développé sous l‟environnement RSM (Rational Software
Modeler) d'IBM. Un prototype a été mis en application et un certain nombre de cas d'études
ont été modélisés avec ce prototype. Les utilisateurs peuvent choisir un ensemble d‟aspects et
l'outil produit un modèle composé de ces aspects avec le modèle de base. L'utilisateur peut
également définir un ordre de composition des aspects dans le cas où un aspect doit se
composer avant les autres. Si un ordre n'est pas défini, l'outil choisit un ordre par défaut.[104]
MATA considère la composition d‟aspects comme un cas particulier de transformation
de graphes. Cette transformation est définie par des règles de réécriture de graphe. Une règle
prend en entrée un modèle de base Mb et un modèle d‟aspect Ma et produit par fusion le
modèle composé Mab. [104]
4.3.3. Exemple de composition de scénarii avec MATA
Cet exemple illustre comment l‟approche MATA peut être utilisée pour spécifier et
composer les modèles d‟aspect à travers une application de téléphonie mobile [111]. Dans cet
exemple, on se limite à la modélisation de trois cas d‟utilisation : réceptionner un appel,
prendre un appel en messagerie et notifier un appel en attente. On considère le cas
d‟utilisation réception d’un appel comme cas de base, car tous les téléphones mobiles
disposent de cette fonctionnalité. Par contre, les deux autres cas d‟utilisation seront considérés
comme des aspects pour une meilleure séparation des préoccupations. Dans le processus de
modélisation avec MATA, le cas d‟utilisation de base est modélisé en UML, alors que les cas
d‟utilisation considérés comme des aspects sont modélisés selon le profil MATA. Pour
illustrer un exemple de composition de scénarios avec MATA, nous limitons notre étude aux
Chapitre III L’ingénierie De Modèles Orientée Aspects
-57-
modèles de séquence décrivant le comportement de la réception d‟un appel, et la prise d‟un
appel dans la boîte de messagerie.
(a) scénario de réception d‟un appel (b) scénario de prise d‟un message vocal
(c) le modèle composé
Figure III.8 :Exemple de composition de scénarii avec MATA[104]
La Figure III.8a décrit le modèle de base du scénario „réceptionner un appel‟. Lors de la
réception d‟un appel, le téléphone informe l‟utilisateur en affichant les informations de
l‟appelant (numéro, nom, etc.), et par l‟envoi d‟un signal sonore. L‟utilisateur peut ensuite
soit accepter l‟appel (et raccrocher par la suite) soit le refuser.[104]
La Figure III.8b décrit le scénario „prendre un message vocal‟ modélisé par un modèle
d‟aspect selon l‟approche MATA. Quand le téléphone sonne pendant une période de temps
Chapitre III L’ingénierie De Modèles Orientée Aspects
-58-
bien définie, l‟appel est redirigé vers le système de messagerie vocale. Ce comportement est
spécifié dans MATA par la création d‟un nouveau fragment altpuisque le renvoi d‟un appel
est un scénario alternatif du cas où l‟appelé reçoit l‟appel. On remarque aussi sur cette figure
qu‟un fragment anyest utilisé pour capturer tous les messages venant du modèle de base après
la sonnerie. Ceci est nécessaire, car quand un message est pris, l‟utilisateur ne doit pas
pouvoir prendre d‟appel. Par conséquent, le fragment altdoit être « enroulé » autour de tous
les messages de la base. Le stéréotype contextest utilisé dans ce fragment pour spécifier qu‟il
doit être appliqué sur le modèle de base. La Figure III.8c présente le modèle composé
résultant de la composition du modèle de base et du modèle d‟aspect.[104]
4.3.4. Discussion
L‟approche MATA présente une technique de composition de modèles d‟aspect basée
sur le langage UML et le profil MATA. Dans cette approche, la composition est vue comme
un cas particulier de transformation de modèle, ce qui permet d‟asseoir la composition
d‟aspects sur une base formelle en réutilisant la théorie des graphes. La technique supporte les
modèles structurels d‟UML (diagrammes de classes), et les modèles de comportement
(diagrammes de séquences et machines à états). A la différence de certaines approches de
modélisation orientées aspect [112], le mécanisme de composition dans MATA ne se base pas
sur l‟identification des points de jonctions, car ceci est réalisé par le modèle d‟aspect lui-
même.[104]
MATA se base sur la syntaxe concrète du langage de modélisation, ce qui facilite la
tâche du modélisateur, mais ne favorise pas la réutilisation des transformations qui sont
spécifiées explicitement dans les modèles d‟aspect.[104]
5. SYNTHESE DES DIFFERENTES APPROCHES DE
COMPOSITION
Les approches présentées ci-dessus proposent toutes des solutions permettant de définir
et de formaliser l‟opération de composition de modèles orientées aspect. Le but de cette
synthèse est de définir en premier lieu un ensemble d‟exigences de base (Sept critères
d‟évaluation) pour toute approche de composition de modèles orientée aspect, et d‟évaluer la
pertinence de chaque solution par rapport à ces exigences.
Chapitre III L’ingénierie De Modèles Orientée Aspects
-59-
Nous présentons dans la section suivante nos critères d‟évaluation en positionnant les
approches étudiées par rapport à ces critères, puis nous donnons un tableau récapitulatif des
approches étudiées sur la base de ces critères
5.1. Critères de comparaison
Pour faire une évaluation comparative des approches présentées ci-dessus, nous avons
retenu les critères suivants qui permettent une caractérisation discriminante :
Niveau de représentation de modèles
Outil de composition
Détection de points de jonction
Représentation des préoccupations
Mécanisme de composition
Type de diagrammes utilisés
Langage de modélisation
Nous explicitons ci-dessous la manière dont ces critères sont pris en compte dans les
approches étudiées.
Niveau de représentation de modèles : ce critère présente quelle niveau est pris en
charge par l‟approche dans le processus de développement.
Outil de composition : ce critère présent est ce qu‟il y a des outils qui supporte
l‟approche ou non.
Représentation des préoccupations : la manière de représenter les préoccupations dans
chaque approche.
Détection de points de jonction :
Mécanisme de composition : ce critère caractérise l‟existence d‟une définition formelle
de mécanisme de composition et des règles explicites pour composer les aspects avec
le modèle de base
Type de diagrammes utilisés : ce critère présente quelle type de diagrammes est
supporté par l‟approche, structuraux ou comportementaux.
Langage de modélisation : ce critère caractérise l‟existence d‟un langage de
modélisation ou non.
Chapitre III L’ingénierie De Modèles Orientée Aspects
-60-
5.2. Tableau comparatif des approches
Cette section résume l‟évaluation des différentes approches de composition étudiées
selon les critères identifiés dans la section précédente. Le Tableau 2 montre le résultat de cette
comparaison. Les colonnes représentent les critères d‟évaluation, tandis que les lignes
représentent les approches étudiées. Nous pouvons constater qu‟aucune approche ne satisfait
pleinement les exigences représentées par ces critères.
Tableau III.1 : Comparaison des approches étudiées.
Critères
Approches
Niveau de
représentation
Outil de
composition
Détection de
points de jonction
Représentation
des
préoccupations
Mécanisme
de
composition
Type de
diagrammes
utilisés
Langage de
modélisation
Thème/UML Analyse +
Conception Non Non
Thème
(paquage UML) non
Structurel +
Comportementa
le
UML
France Conception Oui Non Diagramme de
template oui
Structurel +
Comportementa
le
UML
Mata Non Oui Non
Un patron +
une
spécification
non Structurel +
Comportementa
le
UML +
profil
MATA
CONCLUSION
Durant les dernières années, l‟ingénierie des besoins a permis la naissance de plusieurs
approches de développement traitent les préoccupations sous forme d‟un ensemble de
propriétés fonctionnelles et non-fonctionnelles. C'est avec l'apparition de la programmation
orienté aspect, initiée par Kiczales et al. Vers la fin de 1997, que plusieurs équipes de
recherche travaillant dans le domaine de l‟ingénierie des besoins, se sont intéressées soit pour
adapter les méthodes existantes ou pour développer de nouvelles approches pour la prise en
charge du concept aspect dès les premières phases du cycle de vie de développement logiciel.
Tout au long de ce chapitre, nous nous sommes focalisées sur l‟approche orientée objet, le
concept de la séparation des préoccupations, ainsi que le concept des préoccupations
transversales. Par la suite on a discuté l'importance de la MOA et ses concepts de base, en
survolant les approches de composition orientées Aspect avec une synthèse qui nous permet
de faciliter et de proposer notre approche qui est bien détaillé dans le chapitre suivant.
Chapitre IV :
Contribution
Chapitre IV :
INTRODUCTION
1.PROCESSUS DE NOTRE APPROCHE
2.ETUDE DE CAS: MACHINE A ETATS FINIS
2.1.Présentation
2.2.Métamodèle et Modèles d'une machine à états finis
3.GENERATION DE L'EDITEUR
4.UTILISATION DE L'EDITEUR
5.AJOUT DE COMPORTEMENT KERMETA
5.1.Pseudo-Codes.
6.TRANSFORMATION DE MODELE
6.1.1ère
transformation détermination
6.2.2ème
transformation Minimisation / Optimisation
7.OUTILS
7.1.L‟environnement de modélisation eclipse
7.2.Langage kermeta
CONCLUSION
Chapitre IV Contribution
-61-
INTRODUCTION
Dans ce chapitre, nous présentons notre contribution proposée sous forme d‟une
méthodologie qui consiste à composer des modèles dans l‟approche orientés aspect en se
basant sur le célèbre cas d‟automate à états finis. Comme il a été présenté dans le chapitre
précédent, il y a plusieurs approches qui sert à composer les modèles dans l‟approche orientée
aspect, ces derniers permet la composition dans le coté comportementale, c‟est notre objectif
de ce chapitre.
1. PROCESSUS DE NOTRE APPROCHE
Nous avons essayé de proposer une approche générique pour le tissage de modèles
dynamiques orientées aspect qui regroupe les différents concepts vus au cours de ce mémoire.
Cette approche permet le tissage entre le célèbre cas connu le FSM (la machine à états finis)
avec un ensemble d‟aspect.
Ce FSM est utilisé dans plusieurs domaine, parmi lesquels on cite :
La modélisation des processus.
Le contrôle
Les protocoles de communication.
La vérification des programmes.
La compilation.
La recherche des motifs dans un texte.
Cette approche se base sur les points principaux suivants:
Elle permet la construction et la réutilisation des applications
On a proposé un méta modèle d‟une machine à états finis.
Notre modèle c‟est l‟instanciation du méta modèle par des fichiers XMI.
On a proposé aussi deux transformations, la première c‟est une minimisation d'un
FSM (Elimination des états dupliqués, Elimination des états redondants). Et la
deuxième c‟est une détermination d'un FSM (Traduction d'un modèle non déterministe
à modèle déterministe). On fait ces deux transformations pour obtenir un modèle
minimale qui est utilisé après dans le tissage pour être réutilisé ou pour la construction
d‟un nouveau système.
Chapitre IV Contribution
-62-
On a comme entrée un modèle sous forme de fichier XMI conforme au méta modèle
proposé, plus un ensemble des aspects qui représente l'implémentation du déroulement
du changement du comportement de chaque objet présentant dans le modèle, on
compose le modèle de base avec l‟ensemble des aspects (chaque aspects représente une
fonctionnalité particulière) pour nous obtenir un nouveau modèle (fichier XMI)
conforme au méta modèle proposé.
Figure IV.1 : l’approche proposée
Chapitre IV Contribution
-63-
2. ETUDE DE CAS: MACHINE A ETATS FINIS
2.1. PRESENTATION
Un automate fini (on dit parfois, par une traduction littérale de l'anglais, machine à
états finis, au lieu de machine avec un nombre fini d'états ou machine à états
finie ou machine finie à états), finite-state automaton ou finite-state machine (FSA, FSM), est
une machine abstraite qui est un outil fondamental en mathématiques discrètes et
en informatique.
Figure IV.2 : Automate fini reconnaissant les écritures binaires des multiples de 3.
Un automate est constitué d'états et de transitions. Son comportement est dirigé par
un mot fourni en entrée : l'automate passe d'état en état, suivant les transitions, à la lecture de
chaque lettre de l'entrée.
L'automate est dit « fini » car il possède un nombre fini d'états : il ne dispose donc que
d'une mémoire bornée. On peut très bien considérer des automates sans limitation sur le
nombre d'états : la théorie qui en résulte est très analogue à la théorie habituelle.
Une autre façon commode de représenter un automate fini est sa table de transition. Elle
donne, pour chaque état et chaque lettre, l'état d'arrivée de la transition. Voici à droite la table
de transition de l'automate de la figure IV.2:
Tableau IV.1 : Table de transition de l'automate de la figure IV.2
0 1
S0 S0 S1
S1 S2 S0
S2 S1 S2
Chapitre IV Contribution
-64-
Un automate fini (AFN) est défini par un quintuplet (A, Q, I, F, μ) tel que :
A est l'alphabet (vocabulaire), ensemble fini, non vide de symboles ;
Q est l'ensemble des états possibles pour la machine (fini et non vide) ;
I ⊆ Q est l'ensemble des états initiaux ou états de départ ;
F ⊆ Q correspond aux états finaux ou états d'acceptation ;
μ la fonction de transition telle que μ : A ∪ {ε} × Q → Q. Pour la
configuration courante d'état et de symbole, μ(aj,qi)=qk signifie qu'on
passe dans l'état qk et que le ruban est déplacé d'une case vers la gauche.
2.2. METAMODELE ET MODELES D'UNE MACHINE A ETATS
FINIS
2.2.1. Création de méta modèle
Pour la raison qu'un bon schéma est plus efficace qu'une longue description, nous vous
présentons le méta modèle d'une machine à états finis
Figure IV.3: Méta modèle pour machine à états finis [113]
Chapitre IV Contribution
-65-
La création d'un tel méta modèle peut se faire en suivant les étapes citées ci-dessous :
1- Créer un nouveau projet avec File -> New -> Project and in "Eclipse Modeling
Framework" puis sélectionner "Empty EMF Project".
2- A l'aide de l'assistant vous pouvez continuer jusqu'à l'obtention d'un méta modèle
se présentant sous la forme d'un fichier ECORE.
Figure IV.4: Etape 1 de création d'un projet EMF
Figure IV.5 : Etape 2 de création d'un projet EMF
Figure IV.6 : Etape 3 de création d'un projet EMF
Chapitre IV Contribution
-66-
2.2.2. Création de modèle
La création d'une instance du méta modèle proposé peut être effectuée de la manière
suivante:
1- Ouvrez le fichier DET.ECORE avec Ecore Sample Model Editor (file ->
Open with ->SampleReflective Ecore Model Editor).
2- Cliquez sur la métaclasse DET puis clic droite sur CreateDynamic Instance
and ouis sélectionner un dossier comme destination. Cette instance sera nommée
instance DET.XMI.
Figure IV.7: Etape1 pour création d'une instance du métamodèle proposé
Figure IV.8 : Etape 2 pour création d'une instance du métamodèle proposé
Chapitre IV Contribution
-67-
3. GENERATION DE L'EDITEUR
Arrivant à cette étape, nous allons maintenant créer un fichier .genmodel. Il s'agit d'un
générateur de code basé sur un fichier .ecore, pouvant générer un éditeur simple capable de
créer des instances d'un méta modèle.
Ceci peut être effectué par :
Un Clic droit sur le projet
Une sélection de New ->Other, et "EMF Genrator Model» dans «Eclipse Modeling
Framework".
Figure IV.9 : Etape 1 pour générer l’éditeur
Chapitre IV Contribution
-68-
Figure IV.10 : Etape 2 pour générer l’éditeur
Figure IV.11 : Etape 3 pour générer l’éditeur
4. UTILISATION DE L'EDITEUR
Clic droit sur "model.editor".
Puis Clic sur Run As -> Eclipse Application.
Créer un nouveau projet vide dans votre nouvelle instance d'Eclipse (où votre éditeur
fonctionne comme un plug-in).
Ensuite, allez dans File -> New ->Other ->Example EMF Model CreationWizard et
sélectionnez Fsm Model.
Chapitre IV Contribution
-69-
Figure IV.12 : Utilisation de l’éditeur
Figure IV.13 : Utilisation de l’éditeur
5. AJOUT DE COMPORTEMENT KERMETA
Pour commencer, il faut ouvrir la perspective Kermeta par Window->Open
Perspective ->Other ->Kermeta puis créer un nouveau projet KERMETA par File -> New -
> New Kermeta Project.
Ajout d'un comportement au méta-modèle DET consiste à effectuer une simulation
d'exécution des opérations et un contexte d'exécution représenté par l'état actuel de la machine
d'état. Voilà pourquoi on a besoin d'ajouter une référence de l'État actuel de la machine et
effectuer l'implémentation de trois opérations / méthodes suivantes:
Chapitre IV Contribution
-70-
run() pour la classe DET.
step(String) : String pour la classe Etat.
fire(): String pour la classe Transition.
5.1. PSEUDO-CODES
5.1.1. Pseudo Code de la fonction run()
Initialiser l'état Actuel
Répéter
1- Imprimer l'état Actuel
2- Lire Une Chaîne de caractères
3- Traiter / Analyser une étape (Un état)
4- Traiter les exceptions s'il y en a et quitter le programme en affichant un message
d'erreur
Jusqu'à ce que l'utilisateur décide de sortir.
5.1.2. Pseudo Code de la fonction step()
A partir de l'état actuel
1- Sélectionnez les transitions possibles
2- S'il n'y a aucune
Soulever une exception PasTransition
3- S'il y a plus d'un
Soulever une exception Indéterminé
4- S'il n'y a qu'une seule transition
5- Appelez son opération Deplacer et retourner le résultat atteint
5.1.3. Code de la fonction fire()
1- Changer l'état actuel de la machine d'état
2- Retourner la chaîne produite
Chapitre IV Contribution
-71-
5.1.4. Implémentation en Kermeta
Il a été mentionné (cfsection 7),Kermeta offre un moyen simple d'implémenter le
comportement d'un objet: il s'agit des aspects. Ce concept va nous permettre:
D'ajouter de nouveaux éléments et de nouvelles opérations à un méta-modèle.
De combiner plusieurs aspects.
Un exemple d'une classe aspect peut être illustré comme suit (Cas de la classe fsm)
packagefsm;
requirekermeta
require "http://www.kermeta.org/fsm"
usingkermeta::standard
aspectclass FSM
{
referencecurrentState : State
operation run() : Void raisesFSMExceptionisdo
// [...]
end
operation initialize(p_state : State, isInitComb : Boolean) isdo
// [...]
end
}
5.1.5. Exécutez la simulation
Avant de lancer notre application, une étape de pré-configuration doit être effectuée. Un
Clic droit sur le fichier .kmt correspondant à notre simulation nous ramène à "Run As".
Sélectionner "Run Configurations...". Créer une nouvelle "Kermeta Application". Des
champs seront automatiquement remplis mais on doit mentionner le champ "Operation
arguments" avec la valeur du modèle à vérifier (Instance du métamodèle). Ceci va nous
conduire à un résultat comme :
Chapitre IV Contribution
-72-
Figure IV.14: Exemple d'exécution du fichier DETExecut.kmt
6. TRANSFORMATION DE MODELE
Pour cette étape, nous avons proposé deux transformations de modèles. Chacune d'elle
possède un modèle en entrée qui conduit vers un modèle de sortie. Généralement, ceci peut
être effectué de la manière suivante:
1- Charger le modèle à transformer et initialiser le modèle de sortie.
2- Traitement de la transformation.
3- Enregistrer le modèle de sortie.
6.1. 1ere TRANSFORMATION DETERMINATION
Dans une machine à états finis, on peut avoir des états où deux (ou plusieurs) transitions
sortantes ont le même état en entrée. Cette situation implique que la machine doit déterminer
dans quelle direction va y aller. Ceci nous a motivé de proposer un algorithme permettant
l'annulation des différents choix. En d'autres termes, transformer notre modèle en intégrant
des aspects pour obtenir un autre modèle déterministe.
Chapitre IV Contribution
-73-
6.1.1. Algorithme
L'algorithme de construction d'un AFD T' = {A, Q', I', F', μ'} à partir d'un AFN
quelconque T = {A, Q, I, F, μ} est le suivant : [114]
I' = ε-fermeture(T,I) ; Ajouter I' dans Q' ;
Pour chaque "état" E (ensemble d'états de T) non-marqué dans Q' :
o Le marquer
o Déterminer pour chaque symbole a de A
E' = Μ(a,E)
E'' = ε-fermeture(T,E')
Si E'' n'existe pas dans Q' alors :
L'ajouter dans Q'
S'il contient un état final de T alors l'ajouter dans F'
Créer une transition μ'(a,E)
6.1.2. Implémentation
Créer un nouveau projet Kermeta
Créer un fichier Kermeta (.kmt) nommé transformationDeter.kmt.
Chapitre IV Contribution
-74-
Le code général de ce fichier peut être vu comme suit
@mainClass "fsm::Determination"
@mainOperation "main"
packagefsm;
requirekermeta
require "platform:/resource/DET.Aspects/metamodels/DET_Aide.kmt"
usingfsm
usingkermeta::standard
usingkermeta::persistence
class Determination
{
referenceprocessed_states : Set<State>
reference repository : EMFRepository
reference helper : AutomatonHelper
operation main(input_automaton : String) : Voidisdo
// [...]
end
operation determine(input : FSM, output : FSM, output_state : State) isdo
// [...]
end
operation jointure( str_seq : Collection<String>) : String isdo
// [...]
end
}
Chapitre IV Contribution
-75-
6.1.3. Exécution
Figure IV.15 : Exécution de l’implémentation de la détermination
6.2. 2èmeTRANSFORMATION MINIMISATION / OPTIMISATION
En informatique théorique, et plus particulièrement en théorie des automates,
la minimisation d'un automate fini déterministe est l'opération qui consiste à transformer
un automate fini déterministe donné en un automate fini déterministe ayant le nombre
minimal d'états et qui reconnaît le même langage rationnel. La minimisation a une importance
pratique évidente par le gain d'espace qu'elle permet. Il existe plusieurs algorithmes pour
effectuer cette opération de minimisation ;
Dans certains cas, une machine à états finis contient des états redondants. Donc, nous
avons essayé de proposer une transformation utilisant des aspects le langage KERMETA
permettant supprimer les états doublons et réduire en conséquence la taille du graphe
représentant la machine.
Chapitre IV Contribution
-76-
Figure IV.16: Exemple d'automate finis Dans cet automate, tous les états sont accessibles, les
états c, d et e sont indistinguables, ainsi que les états a et b.
Figure IV.17: Automate minimal équivalent. Les états indistinguables sont regroupés en
états.
6.2.1. Algorithme
On considère un automate fini déterministe complet n TiQA ,, sur un alphabet A .
Ici Q est l'ensemble des états, i est l'état initial,T est l'ensemble des états terminaux.
La fonction de transition est notée par un simple point. Un état q est accessible s'il existe
un mot tel que .iq , il est inaccessible sinon. Les états inaccessibles peuvent être
supprimés sans modifier le langage reconnu par l'automate, et l'automate minimal ne possède
que des états accessibles. Un automate est accessible si tous ses états sont accessibles.[115]
Les états accessibles d'un automate peuvent être calculés au moyen d'un parcours du graphe
qui représente l'automate. Ce sont les états qui sont atteints par un chemin depuis l'état initial.
Il suffit donc d'adapter l'algorithme usuel de parcours d'un graphe à ce cas.
Chapitre IV Contribution
-77-
P:={F,Q\F};"Partition initiale"
W:=l'ensemblevide;"Candidats en attente"
foreachainAdo
ajouter(min(F,Q\F),a)àW;"Initialisation de l'ensemble W"
while(W≠l'ensemblevide)do
choisirensemble(Z,a)dansWetl'enleverdeW
foreachXdePcoupépar(Z,a)enX'etX''do"Calcul de la coupe"
remplacerXinPparlesdeuxensemblesX'etX''"Raffinement de la partition"
foreachbinAdo"Mise-à-jour de l'ensemble"
if(X,b)estinW"des candidats en attente"
remplacer(X,b)inWpar(X',b)et(X'',b)
else
ajouterlepluspetitde(X',b)et(X'',b)àW;
end;
end;
end;
6.2.2. Implémentation
Créer un nouveau projet Kermeta
Créer un fichier Kermeta (.kmt) nommé MinimMachine.kmt.
6.2.3. Exécution
Figure IV.18: Exécution de l’implémentation de la minimisation
Chapitre IV Contribution
-78-
7. OUTILS
7.1. L’ENVIRONNEMENT DE MODELISATION ECLIPSE
C‟est une plateforme de développement écrite en Java, fruit du travail d'un consortium
de grandes entreprises (IBM, Borland, Rational Rose, HP...). Il en résulte un IDE performant
et open Source qui a su trouver sa place comme l'un des environnements de développement
Java les plus populaires. Elle intègre pour cela la prise en charge des outils comme Ant, SVN,
JUnit... [116]
Pour ce qui est de l‟ergonomie, Eclipse n'a rien à envier à ses concurrents. Cette
plateforme contient en effet toutes les fonctionnalités indispensables (création de projet, de
template, refactoring, debuggage). Elle est également très aisée à prendre en main. Mais la
grande force de cet IDE réside dans l'ouverture de son noyau qui permet l'ajout de très
nombreux plugins. Il est par exemple possible d'intégrer des éditeurs XML, HTML, JSP, etc.
ou encore de déployer ses applications vers la quasi totalité des serveurs du marché. [116]
Eclipse est distribué sous la forme de bundles, qui contiennent un certain nombre de
plugins pré-configurés pour une tache donnée comme par exemple eclipse-jee pour le
développement Java EE ou encore eclipse-sdk pour le développement de plugins. [116]
Enfin, Eclipse n'est pas limité au développement Java mais supporte aussi d'autres
langages comme PHP (via PDT) et C/C++ (via CDT), etc. [116]
A noter l'apparition de version "bundle" d'Eclipse contenant un certain nombre de
plugins préconfigurés depuis la version 3.2 (et le projet Callisto) visant à synchroniser la
sortie de plusieurs projets pour en assurer la compatibilité. Renouvelé chaque année, la
nouvelle version d'Eclipse propose toujours davantage de projets en standard. [116]
Chapitre IV Contribution
-79-
Figure IV.19: Architecture générale de la plate-forme Eclipse[117]
La Figure IV.19illustre l‟architecture générale d‟Eclipse. La plate-forme définit un
ensemble de frameworks et de services communs pour assurer une interopérabilité des outils
ajoutés. C‟est l‟équivalent d‟un noyau pour un système d‟exploitation. Le workbench
comprend un système de gestion concurrente de ressources distribuées (Versioning and
Configuration Management), une gestion de projets, une gestion des versions, une
infrastructure de débogage indépendante des langages de développement, un framework
d‟extension des fonctionnalités, une bibliothèque graphique portable (Standard Widget
Toolkit, SWT). Le workspace comprend un espace de stockage des ressources manipulées
(.java,.class,.xml,etc.),un framework pour une interface graphique portable (JFace),un
système générique d‟aide, de recherche, de comparaison et de mise à jour des plates-formes,
des parseurs, le support de scripts, etc. [116]
7.2. LANGAGE KERMETA
7.2.1. Présentation
L‟OMG au travers du MOF propose un langage standardisé afin de permettre la
définition de nouveaux méta-modèles. Kermeta est le résultat d‟un travail collectif, le fruit
d‟une communauté open-source (www.kermeta.org) qui s‟est structurée initialement autour de
l‟équipe Triskell de l‟Irisa à Rennes, et qui regroupe aujourd‟hui des contributeurs de divers
horizons. [118]
Le langage Kermeta est ainsi un langage de méta-modélisation exécutable, qui intègre
méta-données et besoins d'exécutabilité partagés par les langages de transformation, d'action
Chapitre IV Contribution
-80-
et de contraintes. Conformément aux enseignements tirés de l'initiative TopModL, nous nous
sommes attachés à rendre ce langage le plus largement compatible avec les approches
actuelles de metamodélisation (comme EMOF, Ecore...) et leurs outils associés. [118]
D‟un point de vue technique, le langage Kermetaest construit par composition d'aspect
en tissant l'exécutabilité dans le méta-modèle d’EMOF. Cette approche générative nous
permet principalement de bénéficier de tout l'outillage qui s'applique à EMOF (notamment
dans l'environnement Eclipse). [118]
7.2.2. FABRICATION DE KERMETA
Kermeta réutilise les constructions d'OCL pour la navigation et les expressions et ajoute
des constructions permettant la modification de modèles. La Figure IV.20 présente la
hiérarchie d'héritage entre les différents types d'expressions Kermeta. [118]
Figure IV.20 : différents types d'expressions Kermeta[118]
Selon [118] Les principales constructions de ce langage sont:
Des structures de contrôle classiques comme les boucles (Loop), les
conditionnelles (Conditional) et les blocs (Block). Nous avons exclu du langage toutes
constructions telles que break ou gotocar elles brisent le flot de contrôle ce qui tend à rendre
les programmes difficiles à comprendre et à maintenir.
Chapitre IV Contribution
-81-
La déclaration de variables locales (VariableDecl). Étant donné que nous
souhaitons réaliser un langage statiquement typé, les variables locales doivent être déclarées
avec leur type.
Des expressions permettant de lire les variables locales et les propriétés ainsi que
d'appeler des opérations (CallExpression et ses sous-classes).
Des affectations permettant d'affecter les variables locales et les propriétés des
objets (Assignement).
Des expressions littérales pour les types primitifs et les types (Literalet ses sous
classes).
Un mécanisme d'exceptions permettant le traitement des erreurs. L'expression
Raisepermet de lever une exception.
Une forme limitée de lambda-expressions permettant l'implantation d'itérateurs
analogues à ceux d'OCL tel que select, rejectou collect.
La partie action de Kermeta est constituée d‟un langage d‟actions impératif qui inclut
entre autre :
Des concepts propres au domaine de la manipulation de modèles comme par
exemple les associations,
Des concepts orientés-objets classiques tels que l‟héritage multiple ou la redéfi-
nition avec une politique de liaison dynamique,
Des expressions et fermetures analogues à celles d‟OCL (Object-Constraint
Language).
L‟utilisation de Kermeta pour l‟implantation des techniques proposées dans cet article a
deux intérêts majeurs. Premièrement, cela permet d‟encapsuler les algorithmes de détection et
de composition directement dans le méta modèle de scénario utilisé (par exemple UML2.0).
Deuxièmement, du fait de sa compatibilité avec les outils Eclipse, tout modèle manipulé en
Kermeta peut facilement être édité, stocké ou visualisé avec un outil Eclipse. [118]
7.2.3. Installation de KERMETA
1- Pour installer le composant de base de Kermeta pour Eclipse, ouvrez le
Marketplace Eclipse, sélectionnez l'onglet de recherche, et la recherche de " Kermeta "
comme le montre la figure IV.21, «Sélection Kermeta pour Eclipse de l‟Eclipse
Marketplace" . Cliquez sur le bouton Installer à droite de la deuxième élément de la liste
à la figure IV. 19, «Sélection Kermeta pour Eclipse de l‟Eclipse Marketplace" .
Chapitre IV Contribution
-82-
Figure IV.21 : Sélection de Kermeta pour Eclipse de l’Eclipse Marketplace.
2- Une fois que vous cliquez sur Installer , Eclipse va télécharger une liste des
composants disponibles sur le site de mise à jour à distance et vous présenter une liste
des fonctionnalités disponibles dans Kermeta comme le montre les figures IV.22 et
IV.23 , "Sélection des composants de Kermeta pour l'installation " . Sélectionnez les
composants nécessaires pour l‟intégration, puis cliquez sur le bouton Confirmer.
Chapitre IV Contribution
-83-
Figure IV.22 : Sélection des composants pour l'installation
Figure IV.23 : Confirmation des composants sélectionner pour l'installation
Chapitre IV Contribution
-84-
3- Eclipse va demander alors d'accepter les licences pour Kermeta dans Eclipse dans
l'examen des licences représentée à la figure IV.24, " Accepter de Software License
Pendant l‟Installation de Kermeta". Kermeta pour Eclipse est distribué sous la version
de licence Eclipse Public 1.0. Si vous êtes d'accord avec les conditions de cette licence,
sélectionnez " J'accepte les termes du contrat de licence" et cliquez sur le bouton
Terminer.
Figure IV.24: Accepter de Software License Pendant l’Installation de Kermeta .
Figure IV.25: L’installation de Kermeta
Chapitre IV Contribution
-85-
CONCLUSION
Dans ce chapitre, nous avons introduit et décrit l‟approche proposée pour le tissage de
modèle dynamique dans l‟approche orientée aspect. Cette représentation nous permet d‟écrire
le méta-modèle de FSM, avec les deux transformations. Dans le cadre de ce chapitre nous
avons aussi présenté les outils de modélisation de notre approche qui sont l‟environnement
Eclipse et le plugin kermeta.
Conclusion
générale
Conclusion générale
-86-
Conclusion générale
Le contexte associé aux travaux de ce mémoire est celui de la modélisation orientée
aspect (MOA). La MOA est un domaine de recherche récent, et à travers l‟état de l‟art
présenté dans ce document, nous avons constaté que très peu de travaux traitaient du
problème du tissage d‟aspects.
Les travaux présentés dans ce mémoire traitent de l‟exécution et de la simulation pour le
domaine des systèmes temps réel sous forme d'automates à états finis. Ce travail s‟inscrit dans
le contexte de l‟ingénierie dirigée par les modèles. L‟objectif de ces travaux était de mettre en
œuvre un moteur d‟exécution de modèles exploitant les hypothèses sur la sémantique
d‟exécution des modèles à un niveau d‟abstraction élevé afin de pouvoir simuler ces modèles
le plus tôt possible dans le flot de conception d‟une application.
Le choix du paradigme aspect dans un processus de développement d‟un système
d'informations trouve ses motivations dans l‟apport principal apporté par ce paradigme dans le
domaine de l‟ingénierie des modèles. Ce paradigme permet au niveau implémentation de
régler le problème de la dispersion et de l‟enchevêtrement du code et au niveau conceptuel il
permet une meilleure prise en charge des problèmes de préoccupations transversales.
En nous appuyant sur les concepts du paradigme aspect, qui permettent une meilleure
réutilisation des artefacts des systèmes existants en tissant des aspects capables d‟apporter les
modifications adéquates aux éléments existants afin de les réutiliser, nous avons proposé une
approche de développement d‟un SI, selon laquelle il est possible de construire un système à
partir de systèmes existants produits à l‟occasion de développements antérieurs.
Conclusion générale
-87-
Perspectives
Les perspectives des travaux présentés dans ce mémoire suivent différents axes de
réflexion et se situent dans des contextes de recherche différents.
A court terme nous devons essentiellement définir une méthodologie générique qui
donne des règles méthodologiques de paramétrage du modèle d‟exécution en fonction de
la sémantique d‟un profil.
Pour la partie implémentation, nous devons améliorer l‟aspect graphique des
simulations. Nous devons ajouter l‟aspect animation de modèles afin de pouvoir
visualiser l‟évaluation des modèles dans le temps. Un autre aspect d‟implémentation que
nous devons améliorer est celui de la visualisation de traces d‟exécution.
Bibliographie
Bibliographie
Bibliographie
[1] S.Kent, "Model driven engineering," in Proceedings of the Third International
Conference on Integrated Formal Methods, IFM ’02, London, UK, UK, 2002, pp. 286–
298. [Online]. http://dl.acm.org/citation.cfm?id=647983. 743552
[2] G Booch, J Rumbaugh, and I Jacobson, The unified modeling language user guide.,
1999.
[3] Atkinson Colin and Thomas Kuhne, Model-Driven Development : A Metamodeling
Foundation.: IEEE Software, 20(5), 2003.
[4] Jean Bézivin, La transformation de modèles. Ecole d‟Eté d‟Informatique CEA EDF
INRIA: INRIA-ATLAS & Université de Nantes, 2003.
[5] Ed Seidewitz, What models mean.: IEEE software, 2003.
[6] Marvin Minsky, mind, and models.: Semantic Information Processing, 1968.
[7] Benoît Combemale, Ingénierie Dirigée par les Modèles (IDM) État de. Toulouse:
Institut de Recherche en Informatique de Toulouse (UMR CNRS 5505), 2008.
[8] Jean Bézivin and Olivier Gerbé, Towards a Precise Definition of the OMG/MDA
Framework, IEEE Computer Society Press ed. San Diego, USA: In Proceedings of the
16th IEEE international conference on Automated Software, 2001.
[9] Jean-Marie Favre, Towards a Basic Theory to Model Model Driven Engineering.
Lisboa: In Workshop on Software Model Engineering (WISME), joint event with UML
?2004, 2004.
[10] Jouault Frédéric, Jean Bézivin, and Ivan Kurtev, TCS : a DSL for the specification of
textual, D. Schmidt, and T. Veldhuizen, S. Jarzabek, Ed. Portland, Oregon, USA:
Proceedings of the 5th International Conference on Generative Programming and,
Bibliographie
October 2006.
[11] J Bézivin, F Jouault, P Rosenthal, and P Valduriez, Modeling in the Large and Modeling
in the Small, U Aßmann, M Aksit, and A Rensink, Eds. Twente, The Netherlands:
Model Driven Architecture, European MDA Workshops : Foundations and
Applications, MDAFA 2003 and MDAFA 2004, , June 26-27, 2003 and Linköping,
Sweden, June 10-11, 2004, Revised Selected Papers, 2005, vol. volume 3599 of Lecture
Notes in Computer Science.
[12] Jean Bezivin and Ivan Kurtev, Model-based Technology Integration with the Technical.
Esbjerg, Denmark: In Metainformatics Symposium, 2005.
[13] Arie van Deursen, Paul Klint, and Joost Visser, Domain-specific languages : An
annotated bibliography.: ACM SIGPLAN Notices, June 2000.
[14] Brian Kernighan and Dennis Ritchie, The C Programming Language (1st ed.),
Englewood Cliffs, NJ:.: Prentice Hall, 1978.
[15] Stroustrup Bjarne, The C++ Programming Language (Special Edition ed.).: Addison-
Wesley.
[16] Jon Byous, Java technology: The early years.: Sun Developer Network, 1998.
[17] A Abou Dib, Une approche formelle de l'interopérabilité pour une famille de langages
dédiés, Thèse de Doctorat. Toulouse: Université de Toulouse, 18 décembre 2009.
[18] MDA Guide Version 1.0.1. [Online]. http://www.omg.org/mda
[19] X. Blanc, MDA en action Ingénierie logicielle guidée par les modèles. Paris: Eyrolles,
2005.
[20] Object Management Group. [Online]. http://www.omg.org
[21] P Laforcade, V Barré, and B Zendagui, Scénarisation Pédagogique et Ingénierie Dirigé
par les Modèles. Lausanne: Environnements Informatiques pour l‟Apprentissage
Humain, 2007.
[22] J Bézivin and E Breton, Applying the Basic Principles of Model Engineering to the
Bibliographie
Field of Process Engineering.: European Journal for the Informatics Professional, 2004,
vol. 5.
[23] M AOUAG, Des diagrammes UML 2.0 vers les diagrammes orientés aspect à l’aide de
transformation de graphes. Constantine: laboratoire MISC, Université Constantine 2,
2014.
[24] S Diaw, R Lbath, and B Coulette, Etat de l’art sur le développement logiciel dirigé par
les modèles., 2008.
[25] (2008) OMG-QVT. [Online]. http://www.omg.org/spec/QVT/1.0/PDF/
[26] J Bézivin and F Jouault, Using ATL for Checking Models. Tallinn, Estonia: Proceedings
of the International Workshop on Graph and Model Transformation (GraMoT)., 2005.
[27] J Bézivin and X Blanc, MDA : vers un important changement de paradigme en génie
logiciel.: Développeur Référence, Juillet 2002. [Online]. http://www.devreference.net/
[28] Krzysztof Czarnecki and Simon Helsen, Feature-based survey of model transformation
approaches.: IBM Syst. J., 2006.
[29] E Kerkouche, Modélisation Multi-Paradigme: Une Approche Basée sur la
Transformation de Graphes. Constantine: université de mentouri, 2011.
[30] J BEZIVIN, Les nouveaux défis des systèmes complexes et la réponse MDA de l'OMG.,
2002d. [Online]. Disponible sur : http://www.lifl.fr/jfiadsma2002/talks/jfiadsma2002-
Bezivin.pdf
[31] M Belaunde, Model Repository Tool.: Univers@lis. [Online].
http://universalis.elibel.tm.fr/
[32] X BLANC, Ingénierie des modèles. juillet 2004. [Online]. http://www-
src.lip6.fr/homepages/Xavier.Blanc/courses/XB-Model-Engineering.ppt
[33] J BEZIVIN and X BLANC, MDA vers un nouveau paradigme(1).: Développeur
Référence, 15 juillet 2002a. [Online]. Disponible sur :
http://www.weblmi.com/devreference
Bibliographie
[34] J BEZIVIN and X BLANC, Standards et travaux (3).: Développeur Référence, 2
octobre 2002c. [Online]. Disponible sur : http://www.weblmi.com/devreference
[35] R LEMESLE, Techniques de modélisation et de Méta-Modélisation.: Université de
Nantes, 26 octobre 2000. [Online]. Disponible sur : http://www.sciences.univ-
nantes.fr/info/lrsg/Recherche/mda/richard.pdf
[36] P-M OUM OUM SACK, Interopérabilité des Outils d’assistance à l’évolution des
systèmes.: Mémoire de DEA, Laboratoire d‟Informatique du Littoral, 26 juin 2003.
[Online]. isponible sur : http://lil.univ-littoral.fr/~oumoumsack/publi/MemDocFinal.pdf
[37] P SRIPLAKICH, Techniques des transformations de modèles basées sur la
métamodélisation.: Mémoire de DEA Systèmes Informatiques Répartis, Université
Pierre et Marie, septembre 2003. [Online]. Disponible sur :
http://modfact.lip6.fr/ModFactWeb/qvt/SimpleTRL.pdf
[38] OMG, UML 2.0 OCL specification.: OMG document, Octobre 2003. [Online]. http
://www.omg.org
[39] T Baar, OCL and graph-transformations - a symbiotic alliance to alleviate the frame
problem., Springer, Ed.: In MoDELS Satellite Events, 2005., vol. volume 3844 of
Lecture Notes in Computer Science.
[40] OMG1, The unified modelling language 2.0 - object constraint language 2.0 proposal.:
OMG document, 2003. [Online]. http ://www.omg.org,
[41] D Akehurst and O Patrascoiu, "OCL 2.0 - implementing the standard for multiple
metamodels ,UML 2003 preliminary version," University of Kent, Canterbury, UK,
technical report Janvier 2003.
[42] C Jeanneret, R France, and B Baudry, A reference process for model composition.: In
Proceedings of the 2008 AOSD workshop on Aspect-oriented modeling. ACM, 2008.
[43] C Herrmann, H Krahn, B Rumpe, M Schindler, and S Völkel, An algebraic view on the
semantics of model composition, Springer ed.: In Model Driven Architecture-
Foundations and Applications, 2007.
Bibliographie
[44] M Didonet Del Fabro, J Bézivin, and P Valduriez, Weaving Models with theEclipse
AMW plugin. Esslingen, Germany: In : Eclipse Modeling Symposium, Eclipse Summit
Europe2006, 2006.
[45] D.H Akehurst, R Vogel, and R.F Paige, ECMDA-FA 2007, LNCS 4530., 2007.
[46] F Budinsky, D Steingerg, E Merks, and R Ellersick, Eclipse ModelingFramework : A
Developer's Guide.: Addison Wesley, 2003.
[47] Y Raghu Reddy et al., Directives for Composing Aspect-Oriented Design Class Models,
Transactions on Aspect-Oriented Software DevelopmentI.: LNCS 3880 (Springer-
Verlag), 2006.
[48] P.A Bernstein, Applying Model Management to Classical Meta Data Problems.:
InProceedings of the Conference on Innovative Database Research (CIDR), Janvier
2003.
[49] S Clarke, Extending Standard UML with Model Composition Semantics.: Scienceof
Computer Programming, 2002.
[50] Shiva Nejati, Mehrdad Sabetzadeh, Marsha Chechik, Steve Easterbrook, and Pamela
Zave, Matching and Merging of StatechartsSpecifications, IEEE Computer Society ed.
Washington,DC, USA: ICSE '07 : Proceedingsof the 29th international conference on
Software Engineering, 2007.
[51] S Bouzitouna and M. P Gervais, Composition rules for PIM Reuse. Canterbury, UK:
Proceedingsof the 2nd European Workshop on MDA with Emphasis on Methodologies
andTransformations (EWMDA-MT'04), September 2004.
[52] D Kolovos , R Paige, and F Polack, Merging models with the epsilon merging language
(eml).: Model Driven Engineering Languages and Systems, 2006a.
[53] J Bézivin et al., A canonical scheme for model composition. Bilbao, Spain: European
Conference in Model Driven Architecture (EC-MDA) 2006, Juillet 2006.
[54] Franck Fleurey, Benoit Baudry, Robert France, and Sudipto Ghosh, A GenericApproach
For Automatic Model Composition.: Aspect Oriented Modeling (AOM)Workshop,
Bibliographie
Octobre 2007.
[55] Thi Thanh Tam Nguyen, Codèle : Une Approche de Composition de Modèles.:
Université Joseph-Fourier Grenoble I -Laboratoire Informatique de Grenoble (LIG),
2008.
[56] Z Drey, C Faucher, F Fleurey, V Mahé, and D Vojtisek, Kermeta language. Reference
Manual., 2009.
[57] M Acher, P Collet, P Lahire, and R France, Comparing approaches to implement
feature model composition.: Modelling Foundations and Applications, 2010.
[58] B Morin, J Klein, O Barais, and J.M. Jézéquel, A generic weaver for supporting product
lines.: In Proceedings of the 13th international workshop on Early Aspects,ACM, 2008.
[59] F Fleurey, B Baudry, R France, and S Ghosh, A generic approach for automatic model
composition.: Models in Software Engineering, 2008.
[60] D Kolovos, L Rose, R Paige, and FAC Polack, The epsilon book. Structure., 2010.
[61] D.S Kolovos, R.F Paige, and F.A.C Polack, Model comparison: a foundation for model
composition and model transformation testing.: In Proceedings of the 2006 international
workshop on Global integrated model management, ACM, 2006b.
[62] C Clasen, F Jouault, and J Cabot, Virtualemf: a model virtualization tool.: Advances in
Conceptual Modeling,Recent Developments and New Directions, 2011a.
[63] EMF Eclipse. (2006) Eclipse modeling framework. [Online].
http://www.sysml.org/docs/specs/OMGSysML-v1.1-08-11-01.pdf
[64] C Clasen, F Jouault, J Cabot, and et al, Virtual Composition of EMF Models.: In 7èmes
Journées sur l‟Ingénierie Dirigée par les Modèles, 2011b.
[65] M Didonet Del Fabro and P Valduriez, Towards the efficient development of model
transformations using model weaving and matching transformations.: Software and
Systems Modeling, 2009.
[66] GME. GME 5 User± Manual, document en ligne. [Online].
Bibliographie
http://www.isis.vanderbilt.edu/projects/gme/GMEUMan.pdf
[67] J Davis, GME : The Generic Modeling Environment. (Anaheim, CA, USA: Proceedings
of Conference on Object Oriented Programming Systems Languages and Applications
(OOPSLA '03), 2003.
[68] Gabor Karsai, Miklos Maroti, Akos Ledeczi, Jeff Gray, and Janos Sztipanovits,
Composition and Cloning in Modeling and Meta-Modeling.: IEEE Transactions
onControl Systems Technology,12 Mars 2004, 2004.
[69] A Ledeczi, M Maroti, and P Volgyesi, The Generic Modeling Environment.:
Proceedings of the IEEE Workshop on Intelligent Signal Processing (WISP.01), 2001.
[70] Z Molnár, D Balasubramanian, and A Lédeczi, An Introduction to the Generic Modeling
Environment. Zurich, Switzerland: In Proceedings of the TOOLS Europe 2007
Workshop on Model-Driven Development Tool Implementers Forum, June 2007.
[71] J Bézivin, F Jouault, and D Touzet, "An introduction to the ATLAS Model
ManagementArchitecture," Rapport de recherche N° 05 Février 2005.
[72] OMG-MOF, OMG/MOF Meta Object Facility (MOF) 1.4. Final Adopted
SpecificationDocument., 2002.
[73] F Jouault and I Kurtev, On the Architectural Alignment of ATL, QVT. Dijon, France: In:
Proceedings of the2006 ACM Symposium on Applied Computing (SAC 06). ACM
Press, 2006c.
[74] M Didonet Del Fabro and F Jouault, Model Transformation and Weaving in theAMMA
Platform. Braga, Portugal: Workshop on Generative and Transformational Techniques
inSoftware Engineering (GTTSE), 2005.
[75] P Wegner, Concepts and Paradigms of Object-Oriented Programming.: ACM OOPS
Messenger, aug 1990, vol. volume 1.
[76] A Snyder, Encapsulation and Inheritance in Object-Oriented Programming
Languages”.: Proc. of the 1st Conference on Object-Oriented Programming Systems,
Languages and Applications (OOPSLA‟86), nov 1986.
Bibliographie
[77] Ouafa Hachani, Patrons de conception a base d’aspects pour l’ingénierie des systèmes
d’information par réutilisation., 2006.
[78] R Pawlak, J.P Retaillé, and L Seinturier, Programmation orienté aspect pour
Java/J2EE., 2004.
[79] G Kiczales et al., Aspect-Oriented Programming, M. A. a. S. Matsuoka, ed.: in 11th
European Conf. Object-Oriented Programming, 1997, vol. vol. 1241, LNCS.
[80] W Hursh and C Lopes, Separation of concerns.: College of Computer Sciences,
Northeastern University, rapport n° NU-CCS-95-03, Février 1995.
[81] G Kiczales et al., An Overview of AspectJ.: European Conference on Object-Oriented
Programming (ECOOP'01), 2001.
[82] E Beniassad et al., Discovring early aspects.: IEEE Software, e3, 2006.
[83] AOSD. AOSD homepage. [Online]. HTTP://WWW.AOSD.net
[84] H.L Ossher and P. L Tarr, Operation-Level Composition: A Case in (Join) Point.:
ECOOP ‟98 Workshop Reader, Springer Verlag. LNCS, 1998.
[85] J Whittle, P Jayaraman, A Elkhodary, A Moreira, and J Araújo, Mata : a unified
approach for composing uml aspect models based on graph transformation., 2009.
[86] G Zhang and Matthias Hölzl, high-level aspects for uml state machines In 14th Wsh.
Denver: Aspect-Oriented Modeling (AOM@MoDELS‟09), 2009.
[87] N Machta, M.T Bennani , and S.B Ahmed, Modélisation orientée aspects des systèmes
temps réel.: 8th International Conference of Modelisation and Simulation.MOSIM 10,
2010.
[88] Mohamed Ali BOUANAKA, Une méthode de développement de serveurs
d’applications basée sur l’approche orientée aspect.: laboratoire LIRE, Université
Mentouri de Constantine, 2009.
[89] S Breu, T Zimmermann, and C Lindig, Mining eclipse for cross-cutting concerns.
Shanghai, China: In Proceedings of the 2006 international Workshop on Mining
Bibliographie
Software Repositories MSR '06, ACM Press, New York, NY, 2006.
[90] P Durr, G Gulesir, L Bergmans, M Aksit, and R.V Engelen, Applying AOP in an
Industrial Context.: Workshop on Best Practices in Applying Aspect-Oriented Software
Development, March 2006.
[91] J Brichau and T D‟Hondt, Introduction to Aspect-Oriented Software Development.:
AOSD-Europe, 30August 2005.
[92] H Ossher and P Tarr, Multi-dimensional separation of concerns and the hyperspace
approach.: In Proceedings of the Symposium on Software Architectures and Component
Technology : The State of the Art in Software Development,Kluwer, 2000.
[93] J Araujo, A Moreira, I Brito, and A Rachid, Aspect oriented requirements with uml.
Dresden,Germany: Workshop : Aspect-Oriented Modelling with UML, October 2002.
[94] T Gil, La conception orientée aspect.: Valtech Training, 21 janvier 2006.
[95] S Subotic, J Bishop, and S Gruner, Aspect-oriented programming for a distributed
framework., 2006.
[96] Douglas T Ross and Kenneth Schoman, Structured analysis for requirements definition.:
IEEE Trans. Software Eng, 1977.
[97] J Araujo et al., "Earlyaspect: the current landscape," Technical Report February, 2005.
[98] A Boubendir, Un cadre générique pour la détection et la résolution de l’interaction
entre les aspects. Constantine: Université de Mentouri, 2011.
[99] A Rashid et al., Survey of Analysis and Design Approaches, R Chitchyan and A Rashid,
Eds.: AOSD-Europe, 2005.
[100] Siobhán Clarke and Elisa Baniassad, Aspect-Oriented Analysis and Design :The Theme
Approach.: Addison Wesley, 2005.
[101] Siobhan Clarke and Robert J Walker, Generic aspect-oriented design with theme/uml.:
Aspect-Oriented Software Development,Addison-Wesley, 2004.
[102] Siobhan Clarke and Robert J Walker, Towards a standard design languagefor aosd.
Bibliographie
Enschede, The Netherlands: In First International Conference on Aspect-Oriented
Software Development(AOSD), April 2002.
[103] E Baniassad and S Clarke, Theme : An approach for aspectoriented analysis and
design.: In ICSE ‟04 : Proceedings of the 26th International Conference on Software
Engineering. IEEE Computer Society, 2004.
[104] Anwar ADIL, Formalisation par une approche IDM de la composition de modèles dans
le profil VUML.: université de Toulouse, 2009.
[105] Jacques Klein, Aspects Comportementaux et Tissage.: Université de Rennes 1, 4
décembre 2006.
[106] Robert France, Indrakshi Ray, Geri Georg, and Sudipto Ghosh, Aspect oriented
approach to early design modelling.: IEE Proceedings Software, August 2004.
[107] Indrakshi Ray, Robert France, Ni Li, and Geri Georg, An aspect-based approach to
modeling access control concerns.: Journal of Information and Software Technology,
July 2004.
[108] Raghu Reddy et al., Directives for composing aspect-oriented design class models.:
Transactions on Aspect-Oriented Software Development (TAOSD), 2006.
[109] Raghu Reddy, Robert France, Sudipto Ghosh, Franck Fleurey, and Benoit Baudry,
Model composition – a signature-based approach. Montego Bay: In AOM Workshop,
October 2005.
[110] Jon Whittle et al., An expressive aspect composition language for uml state diagrams,
Bill Opdyke, Douglas C. Schmidt, and Frank Weil, editors In Gregor Engels, Ed. Berlin,
Heidelberg: Proceeding MODELS'07 Proceedings of the 10th international conference
on Model Driven Engineering Languages and Systems, 2007a.
[111] Jon Whittle and Praveen K Jayaraman, MATA: A Tool for Aspect-Oriented Modeling
Based on Graph Transformation.: Workshop Aspect-Oriented Modeling, 2007b.
[112] T Cottenier, A van den Berg, and T Elrad, Motorola WEAVR: Model Weaving in a
Large Industrial Context. Vancouver, Canada: Aspect-Oriented Software Development
Bibliographie
(AOSD), 2007.
[113] François Tanguy, Didier Vojtisek, Zoé Drey, and Marie Gouyette, Building a DSL using
Kermeta., 2006.
[114] Patrice Séébold, Théorie de automates : méthodes et exercices corrigés, série Passeport
pour l'informatique. Paris, 1999.
[115] B. W. Watson, "A taxonomy of finite automata minimization algorithms". The
Netherlands,: Computing Science Note 93/44, Eindhoven University of Technology,
1993.
[116] ECLIPSE, http://www.eclipse.org.
[117] Catherine GRIFFIN, Transformations in eclipse.: Dans Workshop on Model-Driven
Development WMDD / IBM / ATHENA Consortium , 2004.
[118] KERMETA. KERMETA. [Online]. http://www.kermeta.org
[119] Araujo J., Whittle J., and Kim, « Modeling and composing scenario-based requirements
with aspects ». Kyoto, Japan: Proc. of RE2004, 2004.
[120] Whittle J. and Araújo J., « Scenario modelling with aspects. ».: IEE Proceedings -
Software, 2004, vol. vol.151, nÆ 4.
[121] Rashid A., Moreira A. M. D., and Araújo J., « Modularisation and composition of
aspectual requirements. ».: AOSD, 2003.
Top Related