Tissage de modèles dynamiques pour la réutilisationd ...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é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.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.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-


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

https://fr.wikipedia.org/wiki/Ing%C3%A9nierie_des_syst%C3%A8mes



https://fr.wikipedia.org/wiki/Informatiques

https://fr.wikipedia.org/wiki/Mod%C3%A8les


-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.


-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


-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.


-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.


-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


-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


-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.


-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


-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].


-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


-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.


-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


-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.


-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


-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++).


-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


-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.


-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é,….


-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


-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].


-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


-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


-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.


-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.


-28-

Figure II.2 : Une vue synthétisée de la classification des approches de composition de modèles.[55]


-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

https://fr.wikipedia.org/wiki/Eclipse


-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.


-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.


-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.


-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]


-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.).


-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]


-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.


-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


-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


-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


-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é)


-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.


-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


-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)


-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]


-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.


-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.


-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.


-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.

https://en.wikipedia.org/wiki/Software_development_methodology

https://en.wikipedia.org/wiki/Software_system

https://en.wikipedia.org/wiki/Business_logic

https://en.wikipedia.org/wiki/Concern_(computer_science)


-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]


-51-

Figure III.4 : Le modèle d’aspect d’un patron sujet-observateur en utilisant Theme


-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]


-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.


-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]


-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]


-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


-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


-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.


-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.


-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.


-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


-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

https://fr.wikipedia.org/wiki/Math%C3%A9matiques_discr%C3%A8tes

https://fr.wikipedia.org/wiki/Informatique

https://fr.wikipedia.org/wiki/Mot


-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]


-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


-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é


-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


-68-



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.


-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:


-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


-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 :


-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.


-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.


-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

}


-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.

https://fr.wikipedia.org/wiki/Informatique_th%C3%A9orique

https://fr.wikipedia.org/wiki/Th%C3%A9orie_des_automates

https://fr.wikipedia.org/wiki/Automate_fini

https://fr.wikipedia.org/wiki/Langage_rationnel


-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.


-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


-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]


-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


-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.


-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" .


-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.


-83-

Figure IV.22 : Sélection des composants pour l'installation

Figure IV.23 : Confirmation des composants sélectionner pour l'installation


-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


-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-


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.


-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,

http://dl.acm.org/citation.cfm?id=647983.%20743552

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

http://www.omg.org/mda

http://www.omg.org/

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

http://www.omg.org/spec/QVT/1.0/PDF/

http://www.devreference.net/

Disponible%20sur%20:%20http:/www.lifl.fr/jfiadsma2002/talks/jfiadsma2002-Bezivin.pdf

Disponible%20sur%20:%20http:/www.lifl.fr/jfiadsma2002/talks/jfiadsma2002-Bezivin.pdf

http://universalis.elibel.tm.fr/

http://www-src.lip6.fr/homepages/Xavier.Blanc/courses/XB-Model-Engineering.ppt

http://www-src.lip6.fr/homepages/Xavier.Blanc/courses/XB-Model-Engineering.ppt

Disponible%20sur%20:%20http:/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.


Disponible%20sur%20:%20http:/www.sciences.univ-nantes.fr/info/lrsg/Recherche/mda/richard.pdf

Disponible%20sur%20:%20http:/www.sciences.univ-nantes.fr/info/lrsg/Recherche/mda/richard.pdf

isponible%20sur%20:%20http:/lil.univ-littoral.fr/~oumoumsack/publi/MemDocFinal.pdf

Disponible%20sur%20:%20http:/modfact.lip6.fr/ModFactWeb/qvt/SimpleTRL.pdf



http%20:/www.omg.org

http%20:/www.omg.org

http%20:/www.omg.org,

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].

http://www.sysml.org/docs/specs/OMGSysML-v1.1-08-11-01.pdf

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.

http://www.isis.vanderbilt.edu/projects/gme/GMEUMan.pdf

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

http://www.aosd.net/

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.

http://www.kermeta.org/

Documents

Tissage de modèles dynamiques pour la réutilisationd ...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