République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université de Constantine 2

Faculté des Nouvelles Technologies de l’Information et la Communication

Département de l’Informatique Fondamentale et ses Applications

Année :

N° d’ordre :

Série :

THESE

Pour l’obtention du diplôme de Docteur 3ème cycle LMD

Option : Systèmes distribués

Des diagrammes UML 2.0 vers les diagrammes

orientés aspect à l’aide de transformation de

graphes

Mouna AOUAG

Soutenue le 09/10/2014 devant le jury composé de :

Pr. Djamel Eddine Saidouni Professeur Président Université Constantine 2

Pr. Allaoua Chaoui Professeur Rapporteur Université Constantine 2

Pr. Mohamed Tahar Kimour Professeur Examinateur Université d'Annaba

Dr. Abdelhafid Zitouni MCA Examinateur Université Constantine 2

Dr. Hammadi Bennoui MCA Examinateur Université de Biskra

Thèse préparée au laboratoire MISC, Université Constantine 2

Remerciement

Je remercie DIEU le tout puissant qui m'a donné la force, la volonté et lecourage pour accomplir ce modeste travail. Je tiens à formuler ma gratitudeet ma profonde reconnaissance.

Je tiens à remercier très chaleureusement Professeur Chaoui Allaoua, mondirecteur de thèse pour ses conseils, ses encouragements et sa con�ance. Jele remercie aussi pour sa patience, sa bienveillance durant toutes ces annéesde thèse et son soutient.

Je remercie les honorables membres de jury ; Monsieur Djamel EddineSAIDOUNI, Monsieur Abdelha�d ZITOUNI, Monsieur Hammadi BENNOUIet Monsieur Mohamed Taher KIMOUR d'avoir accepté d'être membre demon jury de thèse, d'évaluer mes travaux et pour nous avoir honorés de leurprésence.

J'adresse également mes remerciements à mes amies et mes collègues dulaboratoire MISC qui m'ont soutenu durant toutes ces années en particulierMelle Kenza Bouarroudj, Mme wafa Chama et Mme Raida Elmansouri.

En�n, c'est l'occasion pour moi d'adresser mes remerciements à mes pa-rents pour le soutien inconditionnel qui m'ont apporté au cours des annéesde thèse ainsi que tout au long de mes études supérieures. Leur appui m'a ététrès précieux et je leur en témoigne aujourd'hui ma plus grande reconnais-sance. Je remercie ma soeur Asma et mes chers frères lot� et hicham pourleurs soutien moral.

Résumé

La Modélisation Orientée Aspect (MOA) est un nouveau paradigme demodélisation. Ce dernier est né pour améliorer et résoudre les limites de lamodélisation orientée objet. Dans cette thèse nous proposons une approchequi permet de transformer les diagrammes UML 2.0 (classe, activité, com-munication) vers les diagrammes UML 2.0 orientés aspect on utilisant latransformation de graphes. Pour réaliser ce travail, nous avons d'abord dé-�nit les méta-modèles de chaque diagramme UML 2.0 et les modèles d'as-pect (aspect du diagramme de classe, activité, communication). Ensuite lagrammaire de graphe est appliquée sur les modèles cités précédemment pourobtenir des modèles UML orientés aspect. Nous avons aussi utilisé l'outil deméta-modélisation AToM3 et python pour implémenter notre transforma-tion de modèles. Finalement trois études de cas sont présentés pour illustrernotre approche de transformation.

Mots clé : UML 2.0, MOA, AToM3, diagramme de classe, d'activité etde communication, transformation de graphes.

Abstract

Aspect-Oriented Modeling (AOM) is a paradigm that deals with the limitsof object-oriented modeling. This paradigm solves the problem of interactionand separation (Crosscutting) between base (functional) and aspectual (notfunctional) model. In this thesis we propose an approach that transformssome UML 2.0 diagrams to Aspect-oriented diagrams using graph transfor-mation. To realize this work, we have �rst proposed a meta-model for eachUML diagram, Aspect models (diagram of aspect class, activity and com-munication) and a Graph grammar that performs the transformation pro-cess. We have used the meta-modeling tool AToM3 and python language toimplement our transformations. Finally three case studies are presented toillustrate our transformation approach.

Keywords : UML 2.0, AOM, AToM3, diagram of class, activity andcommunication, Graphs Transformation.

ملخصھي لغة جديدة في التصميم ظھرت من اجل تحسين وحل النقائص ) ( Orientée Aspectتصميم المظھر الموجه

) . ( Orientée Objetتصميم الشيء الموجه الموجودة في )اتصا2تنشاط و ,قسم: UML 2.0 (أي ام ال ةم البيانيوفي ھذه ا2طروحة قمنا باقتراح تقنية الية تعتمد على تحويل الرس

(orientés aspect) رسوم بيانية ذات تصميم مظھر الموجه الى )orienté objet(شيء الموجه و اللتي ھي ذات تصميم .تحويل الرسم البيانيو ذالك عن طريق استعمال

رسوم ال(والنموذج المظھري (les méta-modèles) البيانات الوصفيةنماذج من اجل انجاز ھذا العمل قمنا او2 بتعريف قمنا بتطبيق قواعد الرسم البياني للنماذج المذكورة اعFه من اجل و بعد ذالك ) نشاط واتصا2ت ,لمظھر قسم يةالبيان

نماذج اداة لتعريف كما قمنا كذالك باستعمال ,الموجهاللتي ھي ذات تصميم مظھر UMLالحصول على الرسوم البيانية من اجل تنفيذ نماذج التحويل لدينا و في ا2خير قمنا بتجربة عملنا ھذا على , ATOM3 pythonو ھي البيانات الوصفية

.مجموعة من ا2مثلة اعطت نتائج جيدة

,قسم : UML 2.0(الرسوم البيانية أي ام ال , بيانيال الرسم تحويل , )MOA( تصميم المظھر الموجه : الكلمات المفتاحية, )نشاط واتصا2ت

.AToM 3, قواعد الرسم البياني

Table des matières

1 Introduction Générale 11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Organisation de la thèse . . . . . . . . . . . . . . . . . . . . . 6

I Modélisation des systèmes : État de l'art 7

2 La Modélisation Orientée Objet 82.1 La modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Les types de modélisation . . . . . . . . . . . . . . . . 92.2 La Modélisation Orientée Objet . . . . . . . . . . . . . . . . . 112.3 Introduction à UML 2.0 . . . . . . . . . . . . . . . . . . . . . 112.4 Les avantages et les inconvénient de l'approche orientée objet . 16

2.4.1 Les avantages de l'approche orientée objet : . . . . . . 162.4.2 Les inconvénients de l'approche orientée objet : . . . . 17

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 La Modélisation Orientée Aspect 183.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Pourquoi l'approche Orientée Aspect ? . . . . . . . . . . . . . 193.3 Les techniques et les technologies Orientées Aspect . . . . . . 20

V

3.3.1 Ingénierie des exigences orientée aspect (Aspect orien-ted Requirements Engineering) : . . . . . . . . . . . . . 20

3.3.2 Les approches d'architecture orientée aspect(Aspectoriented Architecture) . . . . . . . . . . . . . . . . . . 21

3.3.3 Les approches de conception orientées aspect (Aspectoriented Design) . . . . . . . . . . . . . . . . . . . . . . 21

3.3.4 La programmation Orientée Aspect (Aspect orientedProgramming) . . . . . . . . . . . . . . . . . . . . . . 22

3.3.5 Les approches de Véri�cation et de test des programmesorientés aspect (Veri�cation of Aspect oriented Pro-grams) . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.6 L'intergiciel orienté aspect (Aspect oriented Middleware) 223.4 Fondements de la Modélisation Orientée aspect . . . . . . . . 23

3.4.1 Dé�nition de la Modélisation Orientée Aspect . . . . . 233.4.2 Concepts et terminologie de la Modélisation Orientée

Aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.3 La modélisation graphique d'un aspect à travers les

diagrammes UML . . . . . . . . . . . . . . . . . . . . . 253.5 Les inconvénients de la MOA . . . . . . . . . . . . . . . . . . 273.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

II Transformation de modèles : état de l'art 29

4 Transformation de modèles à l'aide de la transformation degraphes 304.1 Architecture Dirigée par les Modèles (MDA) . . . . . . . . . . 31

4.1.1 Concepts de bases du MDA . . . . . . . . . . . . . . . 314.1.2 Modèle d'architecture MDA à quatre niveaux . . . . . 34

4.2 Transformation de Modèles . . . . . . . . . . . . . . . . . . . 354.3 Transformation de graphes . . . . . . . . . . . . . . . . . . . . 40

4.3.1 Notion de graphe . . . . . . . . . . . . . . . . . . . . . 414.3.2 Système de transformation de graphes . . . . . . . . . 424.3.3 Grammaire de graphe . . . . . . . . . . . . . . . . . . 434.3.4 Transformations de modèles basées sur la transforma-

tion de graphes . . . . . . . . . . . . . . . . . . . . . . 434.3.5 Langage engendré . . . . . . . . . . . . . . . . . . . . . 444.3.6 Outils de transformation de graphes . . . . . . . . . . . 45

4.4 Les avantages et les inconvénients de l'IDM . . . . . . . . . . . 474.4.1 Les avantages de l'IDM . . . . . . . . . . . . . . . . . . 474.4.2 Les inconvénients de l'IDM . . . . . . . . . . . . . . . . 48

VI

III : Contributions 49

5 Application d'une approche de transformation de graphespour transformer les Diagrammes UML2.0 vers des DigrammesUML Orientés Aspect 505.1 Transformation des diagrammes de classe vers des diagrammes

de classe orientés aspect . . . . . . . . . . . . . . . . . . . . . 515.1.1 Les méta-modèles . . . . . . . . . . . . . . . . . . . . 515.1.2 La grammaire de graphes proposée . . . . . . . . . . . 545.1.3 Exemple explicatif . . . . . . . . . . . . . . . . . . . . 58

5.2 Transformation des diagrammes d'activité vers des diagrammesd'activité orientés aspect . . . . . . . . . . . . . . . . . . . . . 595.2.1 Les méta-modèles . . . . . . . . . . . . . . . . . . . . 605.2.2 La grammaire de graphe proposée pour le diagramme

d'activité . . . . . . . . . . . . . . . . . . . . . . . . . 635.2.3 Exemple explicatif . . . . . . . . . . . . . . . . . . . . 71

5.3 Transformation des diagrammes de communication vers desdiagrammes de communication orientés aspect . . . . . . . . . 735.3.1 Les méta-modelées . . . . . . . . . . . . . . . . . . . . 735.3.2 La grammaire de graphes proposée . . . . . . . . . . . 755.3.3 Exemple explicatif . . . . . . . . . . . . . . . . . . . . 77

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6 Études de cas sur la transformation des Diagrammes UML2.0 vers des Digrammes UML Orientés Aspect 816.1 Étude de cas sur le comportement d'un distributeur automa-

tique d'argent . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.1.1 Le modèle de base et aspect pour les diagrammes de

classe, activité et communication . . . . . . . . . . . . 826.1.2 Le modèle composé pour les diagrammes de classe, ac-

tivité et communication . . . . . . . . . . . . . . . . . 836.2 Étude de cas sur le processus de participation a une conférence 87

6.2.1 Le modèle de base et aspect pour les diagrammes declasse, activité et communication . . . . . . . . . . . . 87

6.2.2 Le modèle composé pour les diagrammes de classe, ac-tivité et communication . . . . . . . . . . . . . . . . . 90

6.3 Étude de cas sur le processus d'établissement d'une com-mande par un client . . . . . . . . . . . . . . . . . . . . . . . 916.3.1 Le modèle de base et aspect pour les diagrammes de

classe,activité et communication . . . . . . . . . . . . 92

VII

6.3.2 Le modèle composé pour les diagrammes de classe, ac-tivité et communication . . . . . . . . . . . . . . . . . 94

6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7 Conclusion et Perspectives 97

Bibliographie 103

VIII

Table des �gures

1.1 le principe de composition d'aspect dans les pro�les . . . . . . 31.2 le principe de composition dans l'outil MATA . . . . . . . . . 41.3 la composition dans HILA . . . . . . . . . . . . . . . . . . . . 41.4 Présentation de la méthode . . . . . . . . . . . . . . . . . . . 5

2.1 Classi�cation et utilisation de langages ou de méthodes [Celso et al., ] 102.2 Évolution de UML . . . . . . . . . . . . . . . . . . . . . . . . 122.3 les diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Le Processus de la Modélisation Orientée Aspect . . . . . . . 243.2 le modèle de base et le modèle d'aspect . . . . . . . . . . . . . 263.3 Le modéle composé base + aspect . . . . . . . . . . . . . . . 27

4.1 Le processus de transformation de modèles dans l'approcheMDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Relations entre système, modèle, méta-modèle et langage . . . 344.3 Les quatre niveaux d'abstraction pour le MDA . . . . . . . . . 354.4 Concepts de base de la transformation de modèles . . . . . . . 364.5 Les types de transformation et leurs principales utilisations . . 374.6 Graphe Orienté . . . . . . . . . . . . . . . . . . . . . . . . . . 414.7 Graphe Non Orienté . . . . . . . . . . . . . . . . . . . . . . . 424.8 Exemple sur les règles de transformation . . . . . . . . . . . . 434.9 Présentation de l'outil AToM3 . . . . . . . . . . . . . . . . . 47

5.1 Méta-modèle du diagramme de classe . . . . . . . . . . . . . . 525.2 Outil de modélisation du diagramme de Classe . . . . . . . . . 52

IX

5.3 Méta-modèle du modèle d'aspect du diagramme de classe . . . 545.4 Outil de modélisation du modèle d'aspect du diagramme de

Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5 Grammaire de graphes pour le diagramme de classe . . . . . . 555.6 Application de la catégorie 1 avec Aspect.PJ== classe et As-

pect.AD==classe . . . . . . . . . . . . . . . . . . . . . . . . . 565.7 Application de la catégorie 1 avec Aspect.PJ== classe et As-

pect.AD== méthode . . . . . . . . . . . . . . . . . . . . . . . 565.8 Application du catégorie 2 . . . . . . . . . . . . . . . . . . . . 565.9 Application de la catégorie 3, avec Aspect.PJ==association

simple et Aspect.AD= association avec attribut. . . . . . . . 575.10 Application de la catégorie 4. . . . . . . . . . . . . . . . . . . 575.11 Application du Catégorie 5. . . . . . . . . . . . . . . . . . . . 585.12 Le modèle de base et aspect du réseau internet. . . . . . . . . 595.13 Le résultat de la composition. . . . . . . . . . . . . . . . . . . 595.14 Méta-modèle du diagramme d'activité . . . . . . . . . . . . . . 615.15 l'outil de modélisation des diagrammes D'activité . . . . . . . 625.16 Méta-modèle pour le modèle d'aspect des diagrammes d'activité 635.17 Outil de modélisation pour le modèle d'aspect du diagramme

d'activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.18 Grammaire de graphes pour le diagramme d'activité . . . . . . 645.19 Application de la Catégorie 1 avec Aspect.PJ= état initial

avec activité, Aspect. AD=activité avec une transition simpleet Aspect. Types= create (créer ) . . . . . . . . . . . . . . . . 65

5.20 Application de la catégorie 2 avec Aspect.PJ= état �nal ,Aspect. AD=activité avec une transition simple et Aspect.Types=create(créer ) . . . . . . . . . . . . . . . . . . . . . . . 66

5.21 Application de la Catégorie 3 avec Aspect.PJ= le vide entre lenom de l'activité 1 et l'activité 2 , Aspect. AD= une transitionsimple et Aspect. Types=create(créer ) . . . . . . . . . . . . . 66

5.22 Application de la Catégorie 4 avec Aspect.PJ= le vide entrele nom de l'activité et le nom de l'activité composite, Aspect.AD= une transition simple et Aspect. Types=context(relier) . 67

5.23 Application de la Catégorie 5 avec Aspect.PJ= le vide entre lenom de l'Activité composite 1 et le nom de l'activité composite2, Aspect. AD= une transition simple et Aspect. Types=context(relier) 68

5.24 Application de la Catégorie 6 avec Aspect.PJ= le nom de l'ac-tivité , Aspect. AD= exception et Aspect. Types=create(créer) 68

5.25 Application de la catégorie 7 avec Aspect.PJ= le nom de com-posite activité, Aspect. AD= composite activité et Aspect.Types=create(créer) . . . . . . . . . . . . . . . . . . . . . . . 69

X

5.26 Application de la catégorie 8 avec Aspect.PJ = une transitionsimple, Aspect. AD= objet d'information . . . . . . . . . . . . 70

5.27 Application de la Catégorie 9 avec Aspect.PJ= une transitionconditionnée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.28 Application de la Catégorie 10 avec Aspect.PJ= une Activité . 715.29 Processus de réalisation d'un mémoire avec le diagramme d'ac-

tivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.30 Le modèle d'aspect pour le processus de réalisation d'un mé-

moire avec le diagramme d'activité . . . . . . . . . . . . . . . 725.31 Processus de réalisation d'un mémoire avec un diagramme

d'activité orienté Aspect . . . . . . . . . . . . . . . . . . . . . 725.32 Méta-modèle du diagramme de communication . . . . . . . . . 745.33 L'outil de modélisation du diagramme de communication . . . 745.34 Méta-modèle du modèle aspect pour le diagramme de commu-

nication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.35 L'outil de modélisation du modèle aspect pour le diagramme

de communication . . . . . . . . . . . . . . . . . . . . . . . . . 755.36 Grammaire de graphes proposée . . . . . . . . . . . . . . . . . 765.37 Application de la règle 1 . . . . . . . . . . . . . . . . . . . . . 765.38 Application de la règle 2 . . . . . . . . . . . . . . . . . . . . . 775.39 Application de la règle 3 . . . . . . . . . . . . . . . . . . . . . 775.40 Application de la règle 4 . . . . . . . . . . . . . . . . . . . . . 775.41 Application de la règle 5 . . . . . . . . . . . . . . . . . . . . . 785.42 Application de la règle 6 . . . . . . . . . . . . . . . . . . . . . 785.43 Modèle de base et aspect du réseau internet . . . . . . . . . . 795.44 Modèle composé pour le réseau internet . . . . . . . . . . . . 79

6.1 Modèle de base et d'aspect de la machine CCP pour le dia-gramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.2 Modèle de base de la machine CCP pour le diagramme d'ac-tivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.3 Modèle d'aspect de la machine CCP pour le diagramme d'ac-tivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.4 Modèle de base et aspect de la machine CCP pour le dia-gramme de communication . . . . . . . . . . . . . . . . . . . 85

6.5 Diagramme de classe orienté aspect . . . . . . . . . . . . . . . 856.6 Diagramme d'activité orientée aspect . . . . . . . . . . . . . . 866.7 Diagramme de communication orientée aspect . . . . . . . . . 866.8 Modèle de base et d'aspect du processus de participation à

une conférence pour le diagramme de classe . . . . . . . . . . 88

XI

6.9 Modèle de base du processus de participation à une conférencepour le diagramme d'activité . . . . . . . . . . . . . . . . . . 88

6.10 Modèle d'aspect du processus de participation à une confé-rence pour le diagramme d'activité . . . . . . . . . . . . . . . 89

6.11 Modèle de base et aspect du processus de participation à uneconférence pour le diagramme de communication . . . . . . . 89

6.12 Diagramme de classe orienté aspect . . . . . . . . . . . . . . . 906.13 Diagramme d'activité orienté aspect . . . . . . . . . . . . . . 916.14 Diagramme de communication orienté aspect . . . . . . . . . 916.15 Modèle de base et d'aspect du processus d'établissement d'une

commande par un client pour le diagramme de classe . . . . . 936.16 Modèle de base du processus d'établissement d'une commande

par un client pour le diagramme d'activité . . . . . . . . . . . 936.17 Modèle d'aspect du processus d'établissement d'une commande

par un client pour le diagramme d'activité . . . . . . . . . . . 946.18 Modèle de base et aspect du processus d'établissement d'une

commande par un client pour le diagramme de communication 946.19 Diagramme de classe orienté aspect . . . . . . . . . . . . . . . 956.20 Diagramme d'activité orientée aspect . . . . . . . . . . . . . . 956.21 Diagramme de communication orienté aspect . . . . . . . . . 96

XII

Chapitre

1

Introduction Générale

Sommaire1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problématique . . . . . . . . . . . . . . . . . . . . . 2

1.3 Travaux connexes . . . . . . . . . . . . . . . . . . . 2

1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Organisation de la thèse . . . . . . . . . . . . . . . 6

1.1 Introduction

Aujourd'hui les systèmes informatique simples ou complexes jouent un rôleimportant dans plusieurs domaines d'applications (par exemple la médecine,l'architecture, les mathématiques, etc ...). La modélisation des systèmes estune phase laborieuse pour la conception et la validation des systèmes. Dansnotre thèse on s'intéresse à la modélisation. Dans ce contexte, plusieurs lan-gages de modélisation existent dans la littérature ; par exemple UML (Uni-�er modeling language), MERISE. Dans notre travail, nous avons appliquéla modélisation en utilisant les diagrammes UML 2.0. Ces diagrammes ontmontré leurs importances et e�cacités depuis leur apparition en 1990. Lesdiagrammes UML 2.0 permettent de modéliser un système en utilisant treizediagrammes divisés en deux catégories statique et dynamique. La catégoriestatique représente l'aspect statique du système et la catégorie dynamiquereprésente l'aspect comportement ou communication d'un système. Cepen-dant, les diagrammes UML 2.0 sont des modèles Orientés Objet(OO). Cesderniers ont des limites, pour cette raison les développeurs et les program-meurs ont dé�nit un nouveau paradigme appelé l'Orientée Aspect(OA) a�nd'améliorer et résoudre les limites de la modélisation orientée object.La Modélisation Orientée Aspect utilise la notion d'aspect pour la séparationentre les modèles fonctionnels (base) et les modèles non fonctionnels (Aspect)pour obtenir des modèles composés. L'intégration des aspects dans le modèle

1

de base est faite selon les points de jointure sélectionnés par les points decoupure. La modélisation orientée aspect est classée parmi les dix meilleurestechnologies émergentes qui ont changé le monde de la modélisation.

1.2 Problématique

Les diagrammes UML 2.0 sont des modèles orientés objet. Cependant, lesmodèles orientés objets ont des limites par exemple la duplication, enchai-nement (éparpillant), la di�culté de réutilisation des modèles et le problèmede Crosscuting (la séparation entre les modèles non fonctionnels) pour le-quel ce paradigme n'a donné aucune solution. Pour résoudre certains de cesproblèmes nous proposons dans cette thèse une approche de transformationautomatique. Cette approche s'appuie sur la Modélisation Orientée Aspecta�n d'améliorer et résoudre les limites citées précédemment. Ce processusest réalisé par la séparation entre les modèles et leurs réutilisation facile enintroduisant le concept nommé Aspect. Pour réaliser ce processus d'une ma-nière automatique, nous appliquons la Transformation de modèles et plusprécisément la transformation de Graphes. La transformation des graphesest e�ectuée par l'application de la grammaire de Graphes (la réecriture desgraphes). Cette grammaire est composée d'un ensemble des règles applicablessur le modèle source et produit automatiquement un modèle cible.

1.3 Travaux connexes

Dans la littérature, ils existent quelques travaux sur la modélisation orientéeAspect (le tissage d'aspect) avec la transformation de modèles. Dans cettethèse, nous nous intéressons à l'utilisation de la transformation de graphes.Dans ce qui suit, nous présentons les travaux liés à notre problème d'intégra-tion d'aspect.

Par exemple, dans [Machta et al., 2010] l'ajout de la notion d'aspects estdi�érent des autres approches ([Whittle et al., , Zhang et Holzl, ]). La dé-�nition d'un aspect se fait par la création d'un pro�l UML contenant unensemble de stéréotypes et de les coller sur le modèle UML. Dans la Figure(1.1), nous présentons le processus de transformation des modèles orientésobjet vers des modèles orientés aspect en utilisant la notion de pro�les. Lemodèle d'aspect est dé�nit par : PJ=le modèle UML (classe, état, activité).PC =Σ PJ. AD =Pro�l = Σ Stéréotype. tel que :PJ : les points de jonction.

2

PC :les points de coupure.AD :conseil(Advice).MB :le modèle de base.AT :attribut,M1 et M2 :sont des méthodes.

Figure 1.1 � le principe de composition d'aspect dans les pro�les

Par contre, les auteurs dans [Whittle et al., ] ont présenté une approche pourobtenir un modèle Orienté Aspect à partir d'un Modèle Orienté Objet en uti-lisant l'outil MATA (Modeling Aspects Using a Transformation Approach).MATA permet la détection de con�it, la dépendance entre les aspects, laRéutilisation des modèles et possède une syntaxe concrète. Dans la �gure(1.2), nous présentons le processus de transformation des modèles orientésobjet vers des modèles orientés aspect en utilisant l'outil MATA. tel que :MB :le modèle de base.MA :le modèle d'aspect.Le modèle d'aspect est dé�nit par : PJ= n'importe quelle placement du mo-dèle UML.PC=Σ PJ.AD= ajout d'un modèle sur n'importe quelle placement du modèle UMLDans [Zhang et Holzl, ] le concept d'aspect est ajouté dans un simple dia-gramme d'état transition. HILA (High-Level Aspects for UML State Ma-chines) est une amélioration des diagrammes état transition. Donc, ils ontamélioré le diagramme état transition par l'ajout de la notion d'aspect dans

3

Figure 1.2 � le principe de composition dans l'outil MATA

un niveau plus élevé. D'autre part, HILA permet de résoudre les limites duparadigme orienté objet par l'introduction de nouveaux aspects (par exemplel'aspect de l'exclusion mutuelle entre les états). La notion History est utiliséepour dé�nir la plus longue séquence (max lenght) pour chaque état, si l'étatpossède deux destinataires. En plus, HILA est lisible, facile à comprendre,�able par rapport au diagramme d'état transition et réutilisable. Dans la �-gure(1.3) 1, nous présentons le Processus d'amélioration des diagrammes étattransition par l'ajout de la notion d'aspect dans un niveau plus élevé. telque :PC :les points de coupure.AD :le Conseil(Advice)

Figure 1.3 � la composition dans HILA

1. Cette �gure est empruntée de [Zhang et Holzl, ]

4

1.4 Contributions

Dans cette thèse, nous utilisons les diagrammes UML 2.0 de classe, d'activitéet de communication pour modéliser l'aspect statique, comportement et com-munication d'un système. Mais ces modèles sont des modèles orientés objetqui ont des limites. L'idée est de transformer les diagrammes UML 2.0 versdes diagrammes UML Orientés Aspect pour résoudre les limites de la modé-lisation Orientée Objet. En plus l'aspect est classé parmi les dix meilleurestechnologies qui changent le monde de la modélisation. Donc, nous propo-sons une approche et un outil de transformation automatique des diagrammesUML 2.0 vers des diagrammes UML Orientés Aspect par l'utilisation de latransformation de graphes et l'outil AToM3, telle que :• Le modèle de base est : les diagrammes UML 2.0 (classe, activité, commu-nication).• Le modèle d'aspect est : les Points de jonction = n'importe quel placementdu modèle UML 2.0.Les points de coupure =Σ des points de jonction.Conseil (Advice)= c'est le modèle à ajouter sur n'importe quel placement dumodèle UML 2.0.Finalement, la transformation ce fait d'une manière automatique par l'ap-plication (exécution) de la grammaire de graphes sur le modèle d'entrée etproduire automatiquement son équivalent qui est le modèle de sortie. Dans la�gure (1.4), nous présentons le processus de transformation des diagrammesUML 2.0 vers des diagrammes UML Orientés Aspect.

Figure 1.4 � Présentation de la méthode

5

1.5 Organisation de la thèse

La thèse est organisée en trois parties en plus d'une introduction générale etd'une conclusion.• La première partie de cette thèse se compose de deux chapitres : Le chapitre2 présente les di�érentes catégories de diagrammes UML 2.0 et les limites dela modélisation Orientée Objet. Le chapitre 3 présente le Paradigme OrientéAspect avec les di�érents concepts de base, leurs technologies, ainsi que lesavantages et les inconvénients des approches orientées Aspect.• La seconde partie est dédiée à la transformation de modèles à l'aide detransformation de graphes. Nous donnerons un rappel sur l'architecture diri-gée par les modèles ou MDA (" Model Driven Architecture"). Ensuite, nousprésentons les concepts les plus intéressants dans le domaine de transforma-tion de modèles, avec une brève présentation de la théorie de transformationde graphes et en�n AToM3 sera présenté comme un outil de transformationde modèles.• La troisième partie présente nos contributions avec des études de cas. Dansle chapitre 05, nous commençons par la dé�nition d'une approche totalementautomatique basée sur la transformation de graphes. L'approche consiste àtransformer des diagrammes UML 2.0 (classe, activité, communication)versdes Diagrammes UML 2.0 qui sont Orientés Aspect. Dans le chapitre 06 nousprésentons quelques études de cas pour illustrer notre approche de transfor-mation de modèles.• Finalement, une conclusion générale résume les contributions de cette thèseainsi que des perspectives de recherche.

6

Première partie

Modélisation des systèmes : Étatde l'art

7

Chapitre

2 La Modélisation Orien-tée Objet

Sommaire2.1 La modélisation . . . . . . . . . . . . . . . . . . . . 9

2.2 La Modélisation Orientée Objet . . . . . . . . . . . 11

2.3 Introduction à UML 2.0 . . . . . . . . . . . . . . . 11

2.4 Les avantages et les inconvénient de l'approche

orientée objet . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 17

La modélisation en informatique est l'étape la plus importante dans le dé-veloppement d'un logiciel. Elle facilite la compréhension du fonctionnementd'un système avant sa réalisation en produisant un modèle. Un modèle estune représentation abstraite et simpli�ée du système réel pour un objec-tif donné. Les données qui existent dans le modèle sont des informationsexactes pour son utilisation future. Ils existent plusieurs méthodes de mo-délisation comme la Modélisation Orientée Aspect(MOA) et la ModélisationOrientée Objet(MOO). La MOO permet de modéliser les concepts d'un sys-tème (information,connaissance)sans se préoccuper de l'implémentation c-à-dindépendamment de l'implémentation. Ils existent plusieurs langages de mo-délisation qui sont orientés objet, parmi lesquelles on trouve UML( Uni�edModeling Language). UML est un langage de modélisation qui permet despéci�er , visualiser , construire et documenter les artefacts des systèmes lo-giciels, ainsi que la modélisation des systèmes non logiciels selon la dé�nitionde OMG. il possède treize diagrammes divisés en deux catégories statiqueet dynamique. Statique pour la représentation statique du système et dyna-mique pour représenter le comportement et la communication du système.Dans ce chapitre nous commençons par des dé�nitions de base de la Mo-délisation avec ces di�érents types. Par la suite, nous présentons UML 2.0comme un langage de modélisation Orienté Objet. Nous donnons les di�é-rentes catégories des diagrammes d'UML 2.0 et nous terminons par introduireles avantages et les inconvénients de l'approche orientée objet.

8

2.1 La modélisation

La modélisation d'un système est le processus de développement des modèles. Selon MarvinL et Minsky [Maria, 1997] un modèle est une représentationabstraite qui contient un ensemble restreint d'informations sur un systèmeréel et un point de vue di�érent ou perspective de ce système. D'autre part, lamodélisation o�re des avantages considérables aux concepteurs des systèmestels que : la facilité de compréhension du fonctionnement des systèmes avantsa réalisation et un bon moyen de maîtriser sa complexité et d'assurer sa co-hérence. En informatique la modélisation est vue comme une séparation entreles di�érent besoins fonctionnels et non fonctionnels (tels que : la sécurité,la �abilité, l'e�cacité, la performance, la �exibilité, ..., etc.)[Kadima, 2005].Par ailleurs La modélisation d'un système est venue à signi�er ce qui repré-sente un système en utilisant une sorte de notation graphique, qui est presquetoujours basée sur des notations dans UML.

2.1.1 Les types de modélisation

la modélisation peut se classer selon le degré du formalisme des langages oudes méthodes employées dans le processus de la modélisation. La modélisa-tion peut être considérée comme étant formelle, semi-formelle ou informelle[Celso et al., ]. La table de la �gure (4.1) ci-dessous présente une dé�nitiondes catégories de langages ainsi que des exemples de langages ou de méthodesqui l'utilisent.

Modélisation Informelle : Le processus de modélisation informelle à based'un langage informel, se justi�e selon [Celso et al., ] pour plusieursraisons :

1. La facilité de compréhension d'un langage permet des consensusentre les personnes qui spéci�ent et celles qui commandent unlogiciel.

2. Elle représente une manière familière de communication entre per-sonnes. Le caractère informel de cette approche rend di�cile toutetentative de standardisation.D'un autre côté, l'utilisation d'un langage informel rend la modé-lisation imprécise et parfois ambigüe [Bahri, 2011].

Modélisation semi-formelle : Le processus de modélisation semi-formelleest basé sur un langage textuel ou graphique pour lequel une syntaxeprécise est dé�nie [Celso et al., ] avec une sémantique. La sémantique

9

Figure 2.1 � Classi�cation et utilisation de langages ou de méthodes[Celso et al., ]

d'un tel langage est souvent assez faible. Néanmoins, ce type de mo-délisation permet d'e�ectuer des contrôles et de réaliser des automati-sations pour certaines tâches. La puissance expressive du modèle gra-phique est utilisée dans la plupart des méthodes de modélisation semi-formelles. Par ailleurs, la modélisation semi-formelle s'appuie sur deslangages graphiques, tels que : UML qui permet la production de mo-dèles assez faciles à interpréter [Bahri, 2011].

Modélisation formelle : La modélisation formelle est un processus de dé-veloppement rigoureux basé sur des notations formelles avec une sé-mantique précise, ainsi que sur des véri�cations formelles. Le principalavantage des spéci�cations formelles est leur capacité à exprimer unesigni�cation précise, en permettant de cette manière des véri�cationsde la cohérence et de la complétude d'un système. Par exemple J. P.Bowen et M. C. Hinchey [Bowen et Hinchey, 1995] montrent qu'avecune traduction appropriée, les méthodes formelles peuvent aider à lacompréhension d'un système par un utilisateur [Bahri, 2011].

10

2.2 La Modélisation Orientée Objet

L'approche orientée objet est classée dans la catégorie des modélisations semi-formelles. Elle constitue une façon de penser les problèmes en appliquant desmodèles organisés autour de concepts du monde réel. l'orienté Objet consi-dère le logiciel comme une collection d'objets dissociés et par conséquentson concept fondamental est l'objet, qui combine à la fois une structure dedonnées et un comportement. La fonctionnalité du logiciel émerge de l'inter-action entre les di�érents objets qui le constituent [Audibert, 2008]. Cettemodélisation permet de comprendre des problèmes, de communiquer avecdes experts du domaine d'applications, de modéliser le métier d'une entre-prise, de réparer la documentation et de concevoir des programmes et desbases de données. Toutefois, l'absence de standards uniformisant l'approcheau début des années 90 a donné lieu à une génération multi-variée de logicielshétérogènes et souvent dupliqués, dispersant ainsi l'e�ort de la communautéinformatique. Au milieu des années 90 des prémices de standardisation ap-paraissent donnant naissance à un langage uni�é sous l'appellation abréviéeUML (Uni�ed Modeling Language) [Bahri, 2011].

2.3 Introduction à UML 2.0

UML est un langage de modélisation qui permet de spéci�er, visualiser,construire, et documenter les artefacts des systèmes logiciels, ainsi que pour lamodélisation d'entreprise et des systèmes non logiciels, selon l'OMG [OMG, 2003].Au niveau de Uni�ed Modeling Language, deux éléments importants sont ànoter. Le terme "uni�ed" et le terme "langage". Le premier terme signi�eque les auteurs ont essayé de regrouper les éléments importants des conceptsobjets, alors que le deuxième montre qu'il s'agit d'un langage de modélisa-tion et non pas d'une méthode. UML est un langage qui permet de modélisernon seulement des applications informatiques ou des structures de données,mais également les activités d'un domaine : mécanique, biologie, processusmétier [Audibert, 2008, Espinasse, 2009, Xavier et al., 2006]. Ce langage demodélisation uni�é repose sur deux concepts essentiels :

1. La modélisation du monde réel au moyen de l'approche orientée objet.

2. L'élaboration d'une série de diagrammes facilitant l'analyse et la concep-tion des systèmes, et permettant de représenter les aspects statiques etdynamiques du domaine à modéliser ou à informatiser.

La naissance d'UML est dûe à la fusion des trois méthodes de référencedans le domaine de la modélisation objet durant les années 1990. En e�et,

11

ces méthodes sont : OMT (Object Modeling Technique) de James Rum-baugh, OOSE (Object Oriented Software Engineering) de Ivar Jacobson, etla méthode de Grady Booch. Le 14 Novembre 1997 UML est adopté parl'OMG(Object Management Group)dans sa version 1.1 comme langage demodélisation des systèmes d'information à objets. A la �n de 2006 la versionUML2.0 devient un langage de modélisation de logiciels standard. La Figure(2.2) montre les di�érentes étapes par lesquelles UML est passé :

Figure 2.2 � Évolution de UML

Les Diagrammes d'UML 2.0

UML 2.0 propose treize types de diagrammes pour représenter les di�é-rents points de vues distinctes pour modéliser des concepts particuliers d'unsystème[Larman, 2005]. Ils se répartissent en deux grands groupes :

1. Diagrammes structurels ou statiques d'un système (Structure Diagram).

2. Diagrammes comportementaux ou dynamiques d'un système (BehaviorDiagram).

Les Diagrammes structurels ou statiques d'un système : • Lesdiagrammes d'objets : Un diagramme d'objets est l'un des dia-grammes UML 2.0 utilisé pour représenter l'aspect statique d'unsystème. On dit aussi diagramme d'instance. Il est utile pour ex-plorer des exemples du monde réel des objets et les relations entre

12

eux. Il montre des instances au lieu de classes. Ils sont utiles pourexpliquer les petits morceaux avec des relations compliquées, enparticulier des relations récursives.• Les diagrammes de composants : Un diagramme de composantsest l'un des diagrammes UML 2.0 utilisé pour représenter l'aspectstatique d'un système. Ils montrent les dépendances entre les com-posants logiciels, y compris les classi�cateurs et les objets précisde mise en oeuvre ; tels que les �chiers de code source, �chiers decode binaires, les �chiers exécutables, des scripts et des tables.• Les diagrammes de déploiements : Un diagramme de déploie-ments représente une vue statique de la con�guration d'exécutionde noeuds de matériel et les composants logiciels qui s'exécutentsur ces noeuds. Les diagrammes de déploiement montrent le ma-tériel de votre système, le logiciel qui est installé sur ce matériel,et le middleware utilisé pour connecter les machines disparates lesuns aux autres.• Les Diagrammes de paquetages : c'est une représentation simpli-�ée des diagrammes de classes complexes, ils peuvent regrouperles classes en paquets. Un paquet est une collection d'élémentsUML logiquement liés. Les paquets sont dé�nis comme des dos-siers de �chiers et peuvent être utilisés sur n'importe lequel desdiagrammes UML 2.0.• Les Diagrammes de structures composites : Les Diagrammesde structures composites sont utilisés pour explorer les instancesd'exécution des instances inter-connectées collaboratrices sur desliaisons de communication. Ils montrent la structure interne (ycompris les pièces et les connecteurs) d'un classi�cateur ou d'unecollaboration structurée.• Les diagrammes de classes : Un diagramme de classe est l'un desdiagrammes UML 2.0 utilisé pour représenter l'aspect statiqued'un système. Il est composé d'un ensemble de classes et d'as-sociations entre elles. La classe est représentée par un rectanglecontenant le nom, les attributs et les opérations. Les associationspeuvent être simples, multiples, avec attributs, composition, agré-gation et héritage.Dans notre travail nous choisissons les diagrammes de classe commeun diagramme structurel pour les transformer vers des diagrammesde classe orientés aspect.

Les Diagrammes comportementaux ou dynamiques d'un système :• Les diagrammes de séquence : Les diagrammes de séquence

13

montrent la collaboration des objets basée sur une séquence detemps. Ils montrent comment les objets interagissent avec les autresdans un scénario particulier d'un cas d'utilisation.• Les diagrammes d'états transitions : Les diagrammes d'étatstransitions peuvent montrer les di�érents états d'une entité aussicomment une entité répond à divers événements par le passaged'un état à un autre. L'histoire d'une entité peut être mieux mo-délisée par un diagramme d'états �nis.• Les Diagrammes de temps : Les diagrammes de temps montrentle comportement des objets dans une période de temps donnée.Le chronogramme est une forme particulière d'un diagramme deséquence. Les di�érences entre un diagramme de temps et un dia-gramme de séquence sont les axes qui sont inversés de sorte quel'augmentation du temps est de gauche à droite et les lignes de viesont présentées dans des compartiments séparés disposés vertica-lement.• Les diagrammes de cas d'utilisation : Les diagrammes de casd'utilisation décrivent le comportement du système cible à par-tir d'un point de vue externe. Les cas d'utilisation décrivent desbesoins réels. Un cas d'utilisation décrit une séquence d'actionsqui o�re quelque chose de valeur mesurable pour un acteur et estdessinée comme une ellipse horizontale. Un acteur est une per-sonne, une organisation ou un système externe qui joue un rôledans un ou plusieurs interactions avec votre système. Les acteurssont dessinés comme des chi�res de bâton. Les associations entreles acteurs et les cas d'utilisation sont indiqués par des lignes so-lides. Une association existe chaque fois qu'un acteur est impliquédans une interaction décrite par un cas d'utilisation.• Les diagrammes vue d'ensemble des interactions : Les diagrammesvue d'ensemble des interactions mettent l'accent sur la vue d'en-semble du �ux de contrôle des interactions. Il s'agit d'une variantedu diagramme d'activités où les noeuds sont les interactions oud'événements d'interaction. Ils décrivent les interactions où lesmessages �lières sont cachés.• Les diagrammes d'activités : Un diagramme d'activités est l'undes diagrammes UML 2.0 utilisés pour représenter l'aspect com-portement (fonctionnelle) d'un système. Il est composé d'un en-semble d'activités avec état initial et un état �nal. ils sont reliéspar des transitions simple, conditionnés, synchrones ou par l'objetd'information. Les activités peuvent être des activités simples ou

14

bien des activités spéciaux (par exemple un événement accepté,signal ou un événement d'attente). On trouve aussi les couloirsd'activités qui sont un sous-diagramme. Chaque diagramme d'ac-tivités est composé de plusieurs couloirs (sous- diagrammes) dontchacun possède un nom. Les diagrammes d'activités sont une va-riante des diagrammes d'états-transitions dans laquelle les étatsreprésentent à la fois la réalisation des actions ou sous activités etles transitions déclenchées par la �nalisation des actions ou sousactivités.• Les diagrammes de communication (collaborations) : Un dia-gramme de communication est l'un des diagrammes UML 2.0utilisés pour représenter l'aspect comportement (communication)d'un système, c'est une représentation simpli�ée de diagrammesde séquences. En plus, on peut construire l'un à partir de l'autre.Un diagramme de communication est une combinaison des dia-grammes classes, séquences, cas de utilisation et objet. Il est com-posé d'un ensemble d'objets qui communiquent entre eux par desmessages. Un lien représente une liaison entre deux objets (émet-teur, récepteur) avec un message transitant entre l'émetteur et lerécepteur. Un message peut être synchrone, asynchrone, réponse,ou perdu. Leur représentation est sous forme d'un graphe danslequel les noeuds représentent des objets et les arcs représententles échanges de messages entre les objets.Dans notre travail nous sommes concernés par les diagrammesd'activités et les diagrammes de communication comme des dia-grammes comportementaux pour les transformer vers des dia-grammes d'activités et communication orientés aspect.

La Figure (2.3) montre les di�érents diagrammes UML :

15

Figure 2.3 � les diagrammes UML

2.4 Les avantages et les inconvénient de l'ap-proche orientée objet

2.4.1 Les avantages de l'approche orientée objet :

L'approche orientée objet possède une capacité d'intégration ou d'uni�cationqui implique les avantages suivants :• La stabilité de la modélisation par rapport aux entités du monde réel.• La construction itérative facilitée par le couplage faible entre composantset la possibilité de réutiliser des éléments d'un développement à un autre.• La simplicité du modèle qui fait appel à cinq concepts fondateurs (lesobjets, les messages, les classes, la généralisation et le polymorphisme).• L'approche orientée objet est largement adoptée, tout simplement parcequ'elle a montré son e�cacité lors de la construction de systèmes dans unediversité de domaines métier et qu'elle englobe les dimensions et les degrésde complexité.

16

2.4.2 Les inconvénients de l'approche orientée objet :

Malgré l'utilisation de toute la puissance des langages Orientés Objet, mêmeen utilisant des design patterns les plus évolués, ils restent dans nos applica-tions des éléments de modèles qui sont impossibles à centraliser, à factoriser.Même l'héritage ne permet pas d'éviter complètement la duplication de mo-dèles ni de garantir la cohérence globale de la gestion d'un problème précis.Tout ça nous permet de citer les inconvénients suivants :• Le modèle de résolution est di�cile à lire et à comprendre, en plus il peutprovoquer des erreurs.• L'objet ne peut pas faire la suppression.• La dispersion (duplication), les fonctionnalités transversales se transversentdans le modèle d'application.• Il n'existe pas un enchainement et un éparpillement du modèle.• La réutilisation des modèles est complexe.Pour cela l'orienté aspect est apparait pour améliorer et résoudre les limitesdu paradigme orienté objet.

2.5 Conclusion

Dans ce chapitre nous avons présenté brièvement la dé�nition de la modéli-sation des systèmes avec ces di�érents types, plus particulièrement la modéli-sation orientée objet. Ensuite nous avons présenté le langage de modélisationuni�é UML 2.0 avec ces diagrammes. Par la suite nous avons cité quelquesavantages et inconvénients de la modélisation orientée objet. Le chapitre sui-vant va introduire la notion de la modélisation orientée aspect qui permetd'améliorer et de donner des solutions au inconvénients (problèmes) de l'ap-proche orientée objet.

17

Chapitre

3 La Modélisation Orien-tée Aspect

Sommaire3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Pourquoi l'approche Orientée Aspect ? . . . . . . 19

3.3 Les techniques et les technologies Orientées Aspect 20

3.4 Fondements de la Modélisation Orientée aspect . 23

3.5 Les inconvénients de la MOA . . . . . . . . . . . . 27

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Introduction

L'orienté objet est un paradigme qui a montré son importance dans la ré-solution des problèmes complexes, depuis son apparition dans les années90. Beaucoup de langages de programmation sont basés sur l'orienté objetexemple (C++, java,..). Mais avec l'évolution de l'informatique les problèmessont devenus plus complexes et l'orienté objet a trouvé des limites pour les-quelles ce paradigme n'a donné aucune solution tels que : (la duplication,l'enchainement du modèle, la di�culté de réutilisation des modèles et le pro-blème d'interaction entre les modèles fonctionnels et non fonctionnels). Pourcela les développeurs et les programmeurs ont pensé à dé�nir un nouveauparadigme appelé "paradigme orienté aspect" permettant de donner des so-lutions aux problèmes de l'orienté objet.Le paradigme orienté aspect a été proposé initialement en 1997 par Kiczaleset son équipe. Pawlak et son équipe ont proposé en 2004 une améliorationde ce paradigme. Il permet la résolution des problèmes très complexes, degrandes tailles, et de donner des solutions meilleures. D'autre part ils existentdes langages de programmation qui sont basés sur l'orienté aspect mais sontlimités, puisque la plupart des langages sont des extensions des langagesorientés objet tels que aspectj qui est basé sur java , JAC, etc ...

18

Le terme programmation orientée aspect est en général lié à la phase d'im-plémentation, et puisque aujourd'hui, la communauté aspect s'intéresse à laséparation des préoccupations transversales (aspects) tout au long du cyclede développement de logiciel, il sera intéressant d'identi�er les aspects auniveau des phases préalables à la phase de programmation. Plusieurs travauxont été proposés pour dé�nir l'aspect (comme entité) dans les phases d'ana-lyse et de conception. Il existe un certain nombre de travaux qui sont menésa�n de dé�nir des techniques de modélisation orientée-aspects qui permettentl'utilisation d'aspects non seulement dans le code mais aussi dans les modèlesquel que soit le contexte.La Modélisation Orientée Aspect (MOA) permet la séparation entre un mo-dèle métier (fonctionnel) et un modèle technique (non fonctionnel), et utiliseun mécanisme d'intégration (Weaver) pour obtenir le modèle intégré (mé-tier+aspect). D'autre part si on constate la manière de l'intégration on trouveque chacun a sa propre composition selon son besoin, son problème et sondomaine d'application ; pour cela il existe plusieurs travaux sur la compo-sition d'aspect [Whittle et al., , Zhang et Holzl, , Machta et al., 2010]. Noussommes intéressés dans cette thèse à la Modélisation Orientée Aspect plutôtqu'à la Programmation Orientée Aspect.Dans ce chapitre nous commençons par l'importance de la MOA, et nousdonnons les techniques et les technologies Orientées Aspect. Par la suitenous présentons quelques concepts de base liés à la MOA avec une dé�nitiondétaillée sur ce paradigme. On termine par les inconvenants de la MOA.

3.2 Pourquoi l'approche Orientée Aspect ?

Les approches orientées aspects sont aujourd'hui disponibles à chaque phasedu développement d'un logiciel : analyse des exigences, conception, ou en-core implémentation. Passer d'une phase à l'autre en conservant les aspectsidenti�és au préalable reste un dé� majeur, pourtant peu étudié. Une ap-proche itérative et dirigée par les préoccupations, permettant de transformerun modèle d'exigences orienté aspect en un modèle de conception lui aussiorienté aspect, et ceci de manière automatique. En utilisant ce principe, nousobtenons de nombreux avantages [POA, 2014] :• La résolution des problèmes dus à l'enchevêtrement et l'éparpillement dumodèle.• Les études montrent que la surcharge introduite par les approches orientéesaspect est relativement faible. En�n, les implantations orientées aspect ontdes niveaux d'adaptabilité et de réutilisation plus élevés que les implantationsuniquement objet.

19

• Maintenance aisée : les modules techniques, sous forme d'aspect, peuventêtre maintenus plus facilement du fait de leur détachement et de leur utili-sation.• Meilleure réutilisation : tout module peut être réutilisé sans se préoccuperde son environnement et indépendamment du métier ou du domaine d'ap-plication. Chaque module implémentant une fonctionnalité technique précisen'a pas besoin de se préoccuper des évolutions futures : de nouvelles fonc-tionnalités pourront être implémentées dans de nouveaux modules qui inter-agiront avec le système au travers des aspects et de créer des systèmes plusévolutifs.• La modélisation orientée aspect est parmi les dix meilleures technologiesqui ont changent le monde de modélisation.• Gain de productivité : le programmeur ne se préoccupe que de l'aspect del'application qui le concerne, ce qui simpli�e son travail, et permet d'aug-menter la parallélisation du développement.• Amélioration de la qualité du modèle : la simpli�cation du modèle qu'en-traîne la modélisation par aspect permet de le rendre plus lisible et donc demeilleure qualité.

3.3 Les techniques et les technologies OrientéesAspect

Le domaine du développement de logiciels orientés aspect intervient d'abordau niveau de la programmation à travers la conception de langages de pro-grammation orientés aspect. En ce sens, ce qui a conduit au fait que la plupartdes idées orientées aspect sont perçus au niveau de la technologie. Récem-ment, des techniques d'analyse et de conception orientées aspect ont émergéet l'attention est donnée aux techniques de véri�cation formelle portant surles interactions et les interférences aspect. Nous allons maintenant donner unaperçu sur la plupart des techniques et des technologies de développementorientées aspect à travers le cycle de vie de développement logiciel.

3.3.1 Ingénierie des exigences orientée aspect (Aspectoriented Requirements Engineering) :

Les techniques d'ingénierie des exigences qui reconnaissent explicitementl'importance d'identi�er clairement et traiter des préoccupations transver-sales d'une manière précoces sont appelées les approches d'ingénierie desexigences orientées aspect. Les préoccupations transverses peuvent être des

20

exigences non fonctionnelles aussi bien que des exigences fonctionnelles. Leursidenti�cations précoces permettent l'analyse précoce de leurs interactions.Ces approches se concentrent sur le principe de la composition de toutesles préoccupations pour avoir le système complet en cours de construction.Ainsi, il est possible de comprendre les interactions et les compromis entreles préoccupations. La composition des besoins permet non seulement d'exa-miner les exigences dans leur ensemble, mais aussi la détection des con�itspotentiels très tôt dans le but de prendre des mesures correctives ou décisionsappropriées à la prochaine étape [Boubendir, 2011].

3.3.2 Les approches d'architecture orientée aspect(Aspectoriented Architecture)

Un aspect architectural est un module architectural qui a une grande in-�uence sur d'autres modules architecturaux. Les approches de conceptiond'architecture orientées aspect décrivent donc les étapes d'identi�cation desaspects architecturaux et leurs composants enchevêtrés. Cette informationest utilisée pour refaire une conception d'architecture donnée tout en met-tant les aspects architecturaux explicites. Ceci est di�érent des approchestraditionnelles où les aspects architecturaux sont une information implicitedans la spéci�cation de l'architecture [Boubendir, 2011].

3.3.3 Les approches de conception orientées aspect (As-pect oriented Design)

La conception orientée aspect porte sur la représentation explicite des pré-occupations transversales à l'aide de langages de conception adéquats. Unlangage de conception orienté aspect consiste en quelque sorte à précisercertains aspects comme un moyen de spéci�er la manière dont les aspectsdoivent être composés et un ensemble de sémantique de composition biendé�nis pour décrire les détails de la façon dont les aspects doivent être inté-grés dans le paradigme orienté objet. Dans les premiers temps, les concep-teurs utilisaient simplement des méthodes et des langages orientés objet(telque UML) pour la conception de leurs aspects. Le langage de conceptionUML est devenu le standard de facto. Plusieurs extensions orientées as-pect de UML ont été conçues pour représenter des concepts orientées as-pect au niveau de la conception. Cela s'est révélé di�cile puisque UMLn'a pas été conçu pour fournir des constructeurs pour décrire les aspects.La principale contribution de la conception orientée aspect était donc defournir aux concepteurs des moyens explicites pour modéliser les systèmes

21

par aspect. Dans notre thèse nous nous sommes basés sur cette approche[Boubendir, 2011],[Brichau et D'Hondt, 2005].

3.3.4 La programmation Orientée Aspect (Aspect orien-ted Programming)

L'orientée aspect se manifeste au niveau de la programmation que les lan-gages de programmation orientés aspect. La plupart de ces langages orientésaspect sont des langages (orientés objet) existants étendus avec des fonction-nalités orientées aspect pour représenter les aspects, exprimer les points decoupure, les point de jonction et des conseils, etc ... Par exemple AspectJbasé sur java [Brichau et D'Hondt, 2005].

3.3.5 Les approches de Véri�cation et de test des pro-grammes orientés aspect (Veri�cation of Aspectoriented Programs)

L'approche orientée aspect a posé de nouveaux dé�s dans les techniques devéri�cation et validation des logiciels a�n de s'assurer que la fonctionnalitédésirée est satisfaite par le système. Des aspects peuvent potentiellementendommager la �abilité d'un système pour lequel ils sont tissés, et peuventrendre invalides des propriétés essentielles du système qui étaient correctesavant le tissage d'aspect. Pour assurer la validité du logiciel par aspects, il ya beaucoup de recherche sur l'utilisation de méthodes formelles et techniquesde tests spécialement adaptées aux aspects [Boubendir, 2011].

3.3.6 L'intergiciel orienté aspect (Aspect oriented Midd-leware)

Bien que l'intergiciel n'est pas une étape dans le cycle de vie, il est un domaineimportant et vaste pour les idées orientées aspect. Beaucoup de développeursde logiciels ont adopté des approches d'intergiciel pour aider à la constructionde systèmes distribués à grande échelle. L'intergiciel facilite le développementde systèmes logiciels distribués en supportant l'hétérogénéité, cachant lesdétails de distribution et fournissant un ensemble de services spéci�ques pourun domaine commun [Brichau et D'Hondt, 2005].

22

3.4 Fondements de la Modélisation Orientée as-pect

Dans cette section nous rappellerons la dé�nition de la modélisation orientéeaspect ainsi que sa représentation graphique ;

3.4.1 Dé�nition de la Modélisation Orientée Aspect

Pour résoudre les problèmes de la modélisation orientée objet, il serait in-téressant de modulariser l'implantation des modèles transverses (technique,non fonctionnel) indépendamment les uns des autres . On parle alors deséparation de ces modèles(fonctionnels, non fonctionnels)et de les combi-ner ultérieurement pour produire le modèle �nal. La Modélisation OrientéeAspect (MOA) est une approche (parmi d'autres) permettant d'atteindrece but. Autrement dit le processus de tissage (la composition)d'aspects sedivise en deux phases. Tout d'abord, une phase de détection permettantd'identi�er des parties particulières d'un modèle de base, puis une phasede composition permettant de construire le modèle prenant en compte l'as-pect [Gil, 2006],[Brichau et D'Hondt, 2005]. En général, le cycle de dévelop-pement de la MOA se fait en trois étapes :

1. La décomposition aspectuelle : Elle consiste à décomposer les besoinsa�n d'identi�er et séparer les modèles transverses encapsulés dans desmodules aspects (techniques, non fonctionnels) et métiers (de base,fonctionnels) qui peuvent être modularisés dans des modules de basetel que classe.

2. Implantation des modèles : Elle consiste à implanter chaque modèleséparément. Les modèles métiers sont implantés par les techniquesconventionnelles de la modélisation orientée objet alors que les mo-dèles transverses sont implantés par les techniques de la modélisationorientée aspect.

3. Recomposition aspectuelle : Elle consiste à construire le système �nalen intégrant ou recoupant les modèles métiers avec les modèles trans-verses. Cette phase est appelée tissage (weaving en anglais). Un tisseur(weaver) utilise des règles spéci�ées par le concepteur de l'applicationa�n de recouper correctement les modèles entre eux. Le tissage d'as-pects est une opération qui accepte en entrée les modules de base etles modules d'aspect. Leur but est l'application et l'attachement desaspects dans les modules de base selon les points de jonction corres-pondant à la spéci�cation des points de coupure d'aspect.

23

Donc un aspect = les points de coupure + Conseil.les points de coupure= Σ les points de Jonction.On peut distinguer deux types de tissage : le tissage statique (avantl'exécution) et le tissage dynamique (durant l'exécution)

Dans la Figure (3.1), nous présentons le processus de la modélisation orientéeaspect tels que : S1,S2 et S3 sont des états, véri�cation et sécurité sont desaspects.

Figure 3.1 � Le Processus de la Modélisation Orientée Aspect

3.4.2 Concepts et terminologie de la Modélisation Orien-tée Aspect

Toute nouvelle approche de modélisation nécessite l'introduction de nou-veaux concepts, de nouveaux langages et de nouveaux outils. De nouveauxconcepts sont introduits avec la MOA a�n de permettre aux développeurs despéci�er et de modéliser les préoccupations transverses. Ces concepts sont :

24

Préoccupations : Selon la dé�nition décrite dans [Brichau et D'Hondt, 2005]et conforme à [Ossher et Tarr, 2000], une préoccupation est dé�nie commeun intérêt relatif au développement d'un système, ayant un rôle critiqueou important à un moment donné du développement. Une préoccupa-tion est alors soit une préoccupation non transversale qui peut être liéeà sa fonctionnalité appelée préoccupation de base, soit une préoccupa-tion transversale, qui peut être liée à des exigences non fonctionnelsappelée préoccupation d'aspect ou simplement aspect.• Préoccupation de Base : Une base est une unité de modularisationqui peut être représentée dans un module de manière isolée en respec-tant une décomposition dominante [Araujo et al., 2002]. Elle représentedonc une préoccupation non transversale (fonctionnelle) qui peut êtrecapturée de manière e�cace avec des approches traditionnelles tel quel'approche orientée Objet.• Préoccupation d'aspect : Un aspect est une unité de modularisationqui est entremêlée avec les autres préoccupations, quelles soient de baseou d'aspect. Elle représente donc une préoccupation transversale (nonfonctionnelle) qui peut être capturée de manière e�cace avec l'approcheorientée Aspect.

Point de jonction (joinpoint en anglais (PJ)) : Endroit dans le modèleoù les conseils (advice)devraient être insérés.

Point de Coupe (pointcut en anglais (PC) ) : Un ensemble de pointsde jonction, souvent une expression régulière et signi�e le choix despoints de jonction pour l'application de conseils.

Conseil (advice en anglais) : Une partie du modèle qui contient la tota-lité ou une partie de l'aspect inséré avant ou après ou autour d'un pointde jonction. Il implante une préoccupation transverse.

Aspect (Aspect en anglais) : Module dé�nissant des Conseils et leurspoints d'activation.

Tisseur (weaver en anglais) : Est un outil spécial permettant d'intégrerou de composer les aspects au modèle de base pour obtenir un modèle�nal (base+aspect).

3.4.3 La modélisation graphique d'un aspect à traversles diagrammes UML

Il existe aujourd'hui plusieurs langages de modélisation graphique adaptésau monde relationnel, au recueil de besoin, à la traçabilité,..., etc. Dans le

25

domaine de la modélisation Orientée Objet, UML fait quasiment l'unani-mité aujourd'hui même si de nouveaux outils introduiront certainement leurpropre notation d'ici quelques mois (Microsoft , WhiteHorse) certains ou-tils MDA dédiés à un domaine particulier. C'est donc ce langage que nousavons choisi pour exprimer nos modèles de Conception Orientée Aspects[Gil, 2006, Zhang et Holzl, , Whittle et al., ].Dans cette thèse, nous nous e�orcerons d'expliquer l'usage de la modélisationorientée aspect en passant par des modèles UML 2.0 enrichis c-à-d la transfor-mation des diagrammes UML 2.0 vers des diagrammes UML orientés aspecten utilisant la transformation de graphes, plutôt que par des exemples sys-tématiques de code. Plus parlants, puisque graphiques, ces modèles o�rirontégalement l'avantage d'être indépendants des tisseurs d'aspects. Le graphiqueo�re un niveau d'abstraction supplémentaire, indispensable à l'élaborationd'une bibliothèque de patterns orientés aspect.Dans les Figures (3.2)et (3.3), nous présentons la modélisation graphiqued'un aspect à travers un exemple qui explique les déférents concepts de basede la MOA et pour résoudre le problème d'équation du premier degré telleque X est une valeur inconnue.

Figure 3.2 � le modèle de base et le modèle d'aspect

26

Figure 3.3 � Le modéle composé base + aspect

3.5 Les inconvénients de la MOA

La modélisation orientée aspect ne peut être élégamment appliquée à toutesles situations de problèmes possibles en plus des limites de MOA [Subotic et al., 2006],ce qui suggère que :• La gestion des transactions, par la coupe transversale, est di�cile à facto-riser dehors dans un aspect distinct.• 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 di�cultésen ce qui concerne les tests et le débogage. Cela est dû à des e�ets secondairesqui se dégagent de la dynamique injection du modèle et qui pourraient, dansle pire des cas, conduire à des ambiguïtés sémantiques dans le �ux de contrôled'un modèle orienté aspect .• Les di�érents aspects peuvent e�ectivement nuire même aux points de jonc-tion 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.

27

3.6 Conclusion

Dans ce chapitre nous avons présenté brièvement la modélisation orientéeaspect. Pour cela, nous avons commencé par les di�érentes approches dedéveloppement de l'orienté aspect, par la suite nous avons vu la dé�nition dela modélisation orientée aspect avec les éléments de base de ce paradigme.En�n nous avons cité quelques limites de la MOA. La transformation desdiagrammes UML2.0 vers des diagrammes UML Orientés Aspect nécessite unmécanisme qui permet la transformation de ces modèles. L'ingénierie Dirigéepar les Modèles (IDM) est l'un des outils de transformation des modèles quisera représentée dans le chapitre suivant(Chapitre 4).

28

Deuxième partie

Transformation de modèles : étatde l'art

29

Chapitre

4

Transformation demodèles à l'aide dela transformation degraphes

Sommaire4.1 Architecture Dirigée par les Modèles (MDA) . . 31

4.2 Transformation de Modèles . . . . . . . . . . . . . 35

4.3 Transformation de graphes . . . . . . . . . . . . . . 40

4.4 Les avantages et les inconvénients de l'IDM . . . 47

L'architecture dirigée par les modèles ou MDA (Model Driven Architecture)est l'une des approches qui existent dans la littérature. Elle permet la réalisa-tion des logiciels et l'amélioration signi�cative dans le processus de dévelop-pement des systèmes complexes. Elle est proposée et soutenue par l'OMG.En plus MDA est une variante de l'ingénierie dirigée par les modèles (IDM ,ou MDE "Model Driven Engineering").la transformation de modèles est une notion importante dans le comporte-ment de l'IDM . Elle utilise le processus de transformation successive sur desmodèles d'entrée et produit automatiquement des modèles en sortie. Danscette thèse, nous nous intéressons aux concepts de transformation de mo-dèles et plus particulièrement à la transformation de graphes en utilisantl'outil AToM3 [atom3, 2011]. Les diagrammes d'UML 2.0 (comme un mo-dèle d'entrée) seront transformés vers des diagrammes UML Orientés Aspect(comme un modèle de sortie).Le but de ce chapitre est de donner quelque notions de base sur la transfor-mation de modèles. En suite nous présentons les di�érents types de transfor-mations. Nous abordons un cadre spéci�que de transformations de modèles,notamment la transformation de graphes, les grammaires de graphes et unaperçu sur l'outil utilisé AToM3.

30

4.1 Architecture Dirigée par les Modèles (MDA)

Une architecture dirigée par les modèles est basée sur les principes suivants :• l'utilisation de modèles dans les di�érentes étapes du cycle de développe-ment d'une application. Plus précisément c'est :� l'élaboration de modèles d'exigences (Computation Independent Model,CIM).

� l'analyse et la conception de ces CIM pour obtenir des modèles totalementindépendants des plates-formes techniques (Platform Independent Model,PIM).

� la transformation de ceux-ci en modèles dépendants de plates-formes pourla génération de code (Platform Speci�c Model, PSM) a�n d'aboutir à uneimplémentation concrète du système.• Le changement important dans la conception des applications. Elle intro-duit une séparation nette dans la logique métier de l'entreprise et la logiqued'implémentation. Elle propose de mettre à disposition des développeurs desoutils d'automatisation de génération de code à partir de la logique métierindépendamment de l'architecture technique.• L'approche objet et l'approche composant n'ont pas tenu leurs promesses.Il devient de plus en plus di�cile de développer des logiciels basés sur cestechnologies. Le recours à des procédés supplémentaires, comme les patronsde conception ou la programmation orientée aspect, et MDA est alors néces-saire.• Le standard MDA doit aussi o�rir la possibilité de stopper l'empilementdes technologies qui nécessite de conserver des compétences particulièrespour faire cohabiter des systèmes divers et variés. Ceci est permis grâce aupassage d'une approche interprétative à une approche transformationnelle.Dans l'approche interprétative, l'individu a un rôle actif dans la construc-tion des systèmes informatiques alors que dans l'approche transformation-nelle, il a un rôle simpli�é et amoindri grâce à la construction automatisée[ANDRE, 2004].Dans ce cadre spéci�que, la transformation de modèles est basée sur lestechniques de modélisation, méta-modélisation et l'ingénierie dirigée par lesmodèles .

4.1.1 Concepts de bases du MDA

Dans cette section nous donnons quelques notions de base sur les Modèles,Méta-modèles, Langages de modélisation, méta-modélisation et transforma-tion de modèles.

31

Un modèle : Un modèle est une abstraction de la réalité, qui permet demieux comprendre le processus de développement d'un système. Il metl'accent sur certains aspects du système et ignore d'autres (c'est unpoint de vue simpli�é du système). Son but est de modéliser et faciliterle traitement du système à utiliser [Kadima, 2005, Blanc, 2005].

le MDA possède plusieurs modèles qui permettent dans un premier temps demodéliser le comportement d'un système, puis la transformation successivepour la génération du code. Conceptuellement, le MDA propose trois pointsde vue, associés à leurs modèles respectifs : le CIM, le PIM et le PSM.

Le modèle CIM : Le CIM (Computational Independent Model) est unmodèle de haut niveau qui représente l'application par la spéci�cationdes besoins (exigences) du client. Ces modèles ont pour objectif de créeret de re�éter la relation entre les fonctionnalités de l'application et lesautres entités avec lesquelles elle interagit. Les CIM, ne contiennent pasd'informations sur la réalisation de l'application ni sur les traitementsou le comportement intérieur d'une l'application [Blanc, 2005].

Le modèle PIM : Le PIM (Platform Independent Model) a pour objectifde structurer l'application en modules et sous-modules. L'analyse et laconception du modèle des exigences avec des méthodes de modélisa-tion comme Merise et Coad/Yourdon ou bien avec des méthodes objetSchlear et Mellor, OMT, OOSE et Booch ont toutes leurs propres mo-dèles. Aujourd'hui, le langage UML s'est imposé comme la référencepour modéliser tous les modèles d'analyse et de conception. Ces mo-dèles font le lien entre le modèle des besoins et le code de l'application.Les modèles d'analyse et de conception doivent être indépendants detoute plate-forme ou technologie de mise en ouvre [Blanc, 2005].

Le modèle PSM : Le PSM (Platform Speci�c Model)est la phase la plusdélicate du MDA. La génération de code peut commencer à partirdes modèles d'analyse et de conception. La di�érence principale entreun modèle de code et un modèle d'analyse et de conception résidedans le fait que le modèle de code est lié à une plate-forme spéci�que[Blanc, 2005].

Il existe des transformations de modèles du système vers d'autre modèles dumême système, on peut citer.• Transformations de modèles CIM vers PSM• Transformations de modèles CIM vers PIM• Transformations de modèles PIM vers PSM• Transformations de diagrammes UML 2.0 vers les réseaux de PétriDans la �gure (4.1), nous présentons le processus de transformation de mo-dèles de l'approche MDA [OMG03b, 2003].

32

Figure 4.1 � Le processus de transformation de modèles dans l'approcheMDA

Un méta-modèle : Un méta-modèle est un modèle qui permet de dé�nirle langage d'expression ou la structure d'un modèle. Autrement dit,la méta-modélisation modélise les entités d'un système, le lien exis-tant entre un modèle et le système qu'il représente avec les contraintesexistantes, c'est-à-dire un méta-modèle est une spéci�cation de la syn-taxe et la sémantique d'un système. Pour illustrer la notion de méta-modèle on peut citer l'exemple suivant : Un programme source Javaest un modèle pour toutes ses exécutions possibles. Le méta-modèled'un programme source Java est la grammaire de Java. La grammairedé�nit un ensemble de programmes syntaxiquement valides. Un pro-gramme source conforme à la grammaire appartient à cet ensemble[Kadima, 2005, Kerkouche, 2011].

le Méta-Méta-modèle : Le méta-méta-modèle est un méta-modèle pourles méta-modèles utilisé tout naturellement pour désigner ce méta-modèle particulier. Le langage utilisé au niveau du méta-méta-modèledoit être su�samment puissant pour spéci�er sa propre syntaxe abs-traite et ce niveau d'abstraction demeure largement su�sant (méta-circulaire). Chaque élément du modèle est une instance d'un élémentdu méta-modèle [Kerkouche, 2011].

33

Une fois le formalisme dé�ni, on peut garantir que tout modèle conformeà ce formalisme pourra être traité correctement. Un modèle est ditconforme à un méta-modèle s'il constitue une représentation d'un sys-tème existant ou imaginaire. La relation entre un méta-méta-modèle etun méta-modèle est analogue à la relation entre un méta-modèle et unmodèle. Cette relation est illustrée dans la �gure(4.2) [Kerkouche, 2011].

Figure 4.2 � Relations entre système, modèle, méta-modèle et langage

4.1.2 Modèle d'architecture MDA à quatre niveaux

Le modèle d'architecture MDA à quatre niveaux d'abstraction, a été dé�nipar l'OMG [OMG, 2004] comme carde général pour l'intégration des méta-modèles, en se basant sur MOF 1 comme le montre la �gure (4.3 [OMG, 2004]).Dans cette architecture, les modèles à deux niveaux adjacents sont liés parune relation d'instanciation [Bahri, 2011] :

Le niveau M0 : Ce niveau contient des informations que l'on souhaite mo-déliser. Ces informations sont des données réelles, donc son des ins-tances du modèle. Il est représenté à la base de la pyramide.

Le niveau M1 : Ce niveau représente toutes les instances d'un méta-modèle.Il décrit certains aspects du système que l'on veut étudier. Il peut conte-nir des modèles d'informations (PIM, PSM), des diagramme de classesUML, un modèle conceptuel de traitement MERISE,..., etc. Le modèle

1. MOF :Méta Object Facility, permet la dé�nition des éléments essentiels, la syntaxeet la structure des méta-modèles

34

Figure 4.3 � Les quatre niveaux d'abstraction pour le MDA

doit être exprimé dans un langage qui est dé�nit ou fourni explicitementdans le niveau M2.

Le niveau M2 : Ce niveau représente toutes les instances d'un méta-méta-modèle. Il est composé de langages de spéci�cations ou de modélisationdes modèles d'information (Le méta-modèle). Le méta-modèle UMLdécrit dans le standard UML dé�nit la structure interne des modèlesUML appartenant au niveau M2.

Le niveau M3 : Ce niveau est composé d'un langage unique pour la dé-�nition des méta-modèles (Méta-méta modèle ou MOF (Meta ObjectFacility)). Il doit être assez générique pour dé�nir les di�érents lan-gages de modélisation existants et assez précis pour exprimer les règlesque chaque langage doit respecter pour pouvoir être traité automati-quement. Le MOF élément ré�exif du niveau M3, dé�nit la structurede tous les méta-modèles du niveau M2. Il est représenté au sommetde la pyramide.

4.2 Transformation de Modèles

Dans la �gure 4.4 [Czarnecki et Helsen, 2006], nous présentons les conceptsde base de la transformation de modèles. La transformation de modèles est unprocessus qui consiste à transformer un ou plusieurs modèles sources confor-mément à leur méta-modèle vers des modèles cibles conformément à leurméta-modèle. En outre, les méta-modèles source et cible peuvent être les

35

mêmes dans certaines situations. En MDA la transformation de modèles estbasée sur les méta-modèles et contient deux étapes [Kadima, 2005] succes-sives, qui sont :• La spéci�cation de règles de transformation permettant la dé�nition decorrespondance entre les concepts du méta-modèle du modèle source et lesconcepts du méta-modèle du modèle cible.• L'application des règles de transformation permettent de passer du modèlesource au modèle cible automatiquement. Un outil de transformation estnécessaire pour l'exécution de ces modèles.

Figure 4.4 � Concepts de base de la transformation de modèles

Dans la littérature on distingue trois types de transformation selon l'archi-tecture MDA [Kadima, 2005] :

Les transformations verticales : Dans ce type de transformation, le mo-dèle source et cible sont situés dans des niveaux d'abstraction di�érents,par exemple (PIM vers PSM, ou bien PSM au PIM). Une transforma-tion qui baisse le niveau d'abstraction est appelée un ra�nement. Unetransformation qui élève le niveau d'abstraction est appelée une abs-traction.

Les transformations horizontales : Une transformation horizontales sefait au même niveau d'abstraction (PIM à PIM, ou bien PSM à PSM).Cette transformation permet de faire des modi�cations au niveau des

36

modèles transformés. Cette modi�cation peut être un ajout, une mo-di�cation, une suppression ou bien une restructuration d'informations.

Les transformations obliques : Une transformation oblique combine unetransformation horizontale et une verticale. Ce type de transformationest notamment utilisé par les compilateurs, qui e�ectuent des optimi-sations du code source avant de générer le code exécutable.

La �gure (4.5) résume les types de transformation et leurs principales utili-sations.

Figure 4.5 � Les types de transformation et leurs principales utilisations

Classi�cation des approches de transformation de modèles

Il existe plusieurs axes pour la classi�cation des approches de transformationde modèles. Selon Czarnecki [Czarnecki et Helsen, 2003] La classi�cation sebase sur les techniques de transformation utilisées dans les approches et lesfacettes qui les caractérisent. Il existe une autre classi�cation multidimen-sionnelle où l'on s'intéresse particulièrement au domaine d'application desmodèles et à leur généricité (capacité de transformer n'importe quel modèlesource à n'importe quel modèle cible). Cette approche prend en considérationl'ingénierie des méthodes pour l'utilisation de transformation de modèles. Ellea été proposée par NPrakash [Prakash et al., 2006] et se base sur trois axes :• la technique de transformation utilisée.• le support du langage de transformation.• le domaine d'application des approches de transformation et leur généricité.

37

Dans ce qui suit, nous allons présenter une classi�cation des approches detransformation basée sur les travaux de Czarnecki [Czarnecki et Helsen, 2003].Il préconise deux types de transformation de modèles : les transformationsde type modèle vers code qui sont aujourd'hui relativement matures et lestransformations de type modèle vers modèles.

Transformations de type modèle vers code : Dans cette catégorie, ondistingue deux approches transformationnelles. La première basée sur leprincipe du visiteur (Visitor-based approach) et la deuxième basée surle principe des patrons (Template-based approach) [ElMansouri, 2009,Bahri, 2011].

1. Approche basée sur le visiteur (Visitor-based) : Cette approcheutilise la génération d'un code écrit dans un langage de program-mation à partir d'un modèle en entrée. Elle consiste à traverser lemodèle en ajoutant des éléments au modèle d'entrée (mécanismede visiteur) et de réduire la di�érence de sémantique entre le mo-dèle et le langage cible. On peut citer comme exemple le projetJamda qui fournit un ensemble de classes pour représenter les mo-dèles UML, une API pour manipuler les modèles, et un mécanismede visiteur pour générer le code java.

2. Approche basée sur les templates (Template-based) : Actuelle-ment, ce sont les approches les plus utilisées et la majorité desoutils MDA disponibles les supportent. La structure d'un tem-plate ressemble au code à générer. On utilise le méta-code du codecible pour accéder aux informations du modèle source. Parmi lesoutils basés sur ce principe, on peut citer : JET, ArcStyler et An-droMDA (un générateur de code qui se repose notamment sur latechnologie ouverte), OptimalJ, XDE (les deux derniers sont aussides transformations de type modèle vers modèle).

Transformations de type modèle vers modèle : Depuis l'apparition duMDA, les transformations de type modèle vers modèle ne cessent dese développer [OMG, 2004]. Elles consistent à transformer un modèlesource vers un modèle cible. Ces modèles peuvent être des instances dedi�érents méta-modèles. Dans les cas où l'on trouve un grand espaced'abstraction entre le PIMs et le PSMs, il est plus facile de générer oud'utiliser des modèles intermédiaires que d'aller directement du PIMvers le PSM cible. Ces modèles intermédiaires sont utiles pour l'opti-misation, le calcul des di�érentes vues du système, leur synchronisationet pour la véri�cation et la validation.

38

� Structure d'une transformation : Une transformation de modèle sedé�nit par un ensemble d'éléments, à savoir : des règles de trans-formation, leurs organisation et ordonnancement, une traçabilité etune orientation [Bahri, 2011]. La combinaison de ses éléments permetde décrire la transformation. Toutefois, ces règles de transformationdoivent être d'abord spéci�ées a�n de pouvoir exprimer les corres-pondances entres les concepts des Méta-modèles source et cible.

Règles de transformation : Une règle de transformation possèdeune logique de forme déclarative ou impérative pour exprimerdes contraintes ou des calculs sur les modèles sources et ciblesde la transformation [Kadima, 2005]. Techniquement, une règlede transformation se compose de deux parties : une partie gaucheappelée LHS (Left Hand Side) qui accède au modèle source, etune partie droite appelée RHS (Right Hand Side) qui accède aumodèle cible. L'exécution d'une règle de transformation orientéede gauche à droite, permet de remplacer les constructions dumodèle source conformes au LHS de la règle par les RHS dela même règle pour la construction du modèle cible. Une règle,peut être bidirectionnelle, comporter des paramètres, ou encorenécessiter la construction de structures intermédiaires. Les règlesde transformation nécessitent :• Une organisation : on peut les organiser de façon modulairepar : la réutilisation par le biais de mécanisme d'héritage entre lesrègles, la composition par le biais d'un ordonnancement explicite,ou en�n, par une structure dépendante du modèle source ou dumodèle cible.• ordonnancement et orientation : il y a deux types d'ordon-nancement des règles ; l'ordonnancement implicite qui est dé�nipar l'outil de transformation lui-même, et l'ordonnancement ex-plicite. Il existe des mécanismes permettant de spéci�er l'ordred'exécution des règles.• Un mécanisme de traçabilité : il permet de renforcer la tech-nique par archivage des corrélations qui existent entre les élé-ments des modèles de transformation.

Spéci�cation des règles de transformation : les règles de trans-formation expriment la correspondance entre les concepts duméta-modèle source et ceux du méta-modèle cible. Le rôle dela spéci�cation est la description de telles relations indépen-damment de toute exécution. Le MDA prévoit l'automatisa-tion complète de cette phase. Certaines approches de transfor-

39

mation fournissent un mécanisme dédié de spéci�cations, telque des pré-conditions et des post-conditions exprimées en OCL(Object Constraint Language). Jusqu'à maintenant, il n'existepas de standard permettant d'exprimer les règles de transfor-mation. Cependant, les travaux actuels de l'OMG sur le stan-dard MOF/QVT (Query Views Transformation) semblent êtreprometteurs. Dans notre travail, nous avons opté pour l'outilAToM3 [atom3, 2011].

Les approches pour la dé�nition des transformations :

Il existe, plusieurs approches permettant de dé�nir la transformation de typemodèle vers modèle. On distingue généralement cinq approches dans la lit-térature :� les approches par manipulation directe ;� les approches relationnelles ;� les approches basées sur la transformation de graphes ;� les approches basées sur la structure ;� les approches hybrides.

4.3 Transformation de graphes

Les graphes et les diagrammes o�rent un support agréable et e�cace pourla modélisation des systèmes complexes. Citons comme exemples, les dia-grammes UML, les réseaux de Pétri ou encore les automates. Les graphespermettent une visualisation des structures complexes des modèles d'unemanière simple. Les techniques de transformation et de réécriture de graphespeuvent être exploitées pour spéci�er l'évolution ou la transformation de cesmodèles.Une transformation de graphes [Karsai et Agrawal, 2004, Andries et al., 1999,Rozenberg, 1999] est le processus de choisir une règle d'un ensemble indiquéet son application à un graphe. La partie du graphe qui correspond à cetterègle sera remplacée par un autre graphe. Ce processus est réitéré jusqu'àce qu'aucune règle ne puisse être appliquée. Les règles de transformation degraphes constituent ce que l'on appelle la grammaire de graphes. Une gram-maire de graphes est une généralisation de la grammaire de Chomsky pour lesgraphes. Une règle est composée de deux parties, une partie gauche (le LeftHand Side (LHS)) et une partie droite ( Right Hand Side (RHS)). Le LHSest la partie du graphe (appelée host graph) sur laquelle on veut appliquerla règle. Le RHS, décrit la modi�cation qui sera e�ectuée sur le host graphe,

40

Figure 4.6 � Graphe Orienté

[Rozenberg, 1999]. Pour bien comprendre le principe de transformations etde grammaires de graphes, nous donnons un rappel sur les concepts de baseliés à la théorie de graphes.

4.3.1 Notion de graphe

Un graphe est constitué de sommets ou noeuds qui sont reliés par des arêtes.Plus formellement, on appelle graphe G = 〈S,A〉.� S : ensemble �ni non vide d'éléments appelés sommets ou noeuds.� A : ensemble �ni non vide de paires de sommets appelés arcs.� A ⊆ X ×X = {(s, t)|s, t ∈ S}Chaque arc de A relie deux sommets de S [Chartrand et Zhang, 2009]. Ilexiste deux types principaux de graphes : les graphes non orientés et lesgraphes orientés.

Graphe orienté et non orienté

Un graphe est dit orienté si les arêtes possèdent une orientation (un sommetde départ et un sommet d'arrivée). Dans le cas contraire, le graphe est ditnon orienté. Plus formellement un graphe orienté est un graphe G = 〈S,A〉où :� S : ensemble �ni d'éléments appelés sommets ou noeuds.� A : ensemble �ni de paires ordonnées de sommets appelés arcs.� A ⊆ X ×X = {(s, t)|s, t ∈ S}La �gure (4.6) présente un exemple d'un graphe orientéUn graphe non orienté G = 〈S,A〉 où :

41

� S : ensemble �ni d'éléments appelés sommets ou n ?uds.� A : ensemble �ni de paires de sommets appelés arêtes.� A ⊆ X ×X = {(s, t)|s, t ∈ S}La �gure (4.7) présente un exemple d'un graphe non orienté

Figure 4.7 � Graphe Non Orienté

Graphe étiqueté : Un graphe étiqueté est un graphe orienté dans lequelles arcs possèdent un ensemble non vide d'étiquettes.

graphe attribué : est un graphe qui peut contenir un ensemble prédé�nid'attributs.

les sommets adjacents : Deux sommets sont adjacents sils sont reliés parune arête .

l'ordre du graphe : ces le nombre de sommets présents dans un graphe.

le degré du graphe : Le degré d'un sommet est le nombre d'arêtes dansce sommet. Si le graphe est orienté le degré de sommet est le nombred'arcs entrants et sortants dans ce sommet.

Le sous-graphe : un sous-graphe d'un graphe G est un graphe G' composéde certains sommets de G, ainsi que toutes les arêtes qui relient cessommets.

4.3.2 Système de transformation de graphes

Un système de transformation de graphes est une structure GTS composéed'un graphe initial S et d'un ensemble de règles de transformation de graphestel que R= r 1 , r 2 , ... , r n [Hamrouche, 2010].

42

4.3.3 Grammaire de graphe

Une grammaire de graphes [Andries et al., 1999] est une structure GG , gé-néralement dé�nie par un triplet : GG = (P, S, T ) où :� P : ensemble de règles.� S : un graphe initial.� T : ensemble de symboles terminaux T.Autrement dit : un graphe non terminal est un résultat intermédiaire de l'ap-plication de ces règles. Les graphes terminaux sont dans le langage engendrépar la grammaire et sur lesquels on ne peut plus appliquer de règles. Doncune grammaire de graphes se distingue des graphes non terminaux.la �gure (4.8)présente un exemple des règles de transformation des dia-grammes d'activités orientés aspect vers les réseaux de Pétri colorés.

Figure 4.8 � Exemple sur les règles de transformation

4.3.4 Transformations de modèles basées sur la trans-formation de graphes

Une séquence de transformation de graphes est composée d'un graphe source(GS ), d'un graphe cible (GT ) et d'une dérivation successive de GS vert GT

en appliquant l'ensemble des règles R (GS ,GS → GT ,GT ). Autrement dit :un système de transformation de graphes est dé�ni comme un système deréécriture de graphes qui applique les règles de la grammaire de graphes surson graphe initial jusqu'à ce qu'aucune règle ne soit applicable pour obtenirun graphe �nal [Rozenberg, 1999].

43

4.3.5 Langage engendré

Soit G0 un graphe initial,Gn est le graphe �nal et une séquence de transfor-mations successives de graphes : G0 → G1 → ... → Gn est une dérivationsuccessive à partir de G0 vers Gn en appliquant les règles de R qui sont éti-quetées par les symboles de T, est dit langage engendré par R, G0 et T et onécrit L(R,G0, T ) [ElMansouri, 2009].

Le principe de règles

Une règle de transformation de graphe r est dé�nie par :r = (L,R,K, glue, emb, cond), elle consiste en :� deux graphes, L graphe du coté gauche sur lequel la règle va s'appliqueret R le graphe du coté droit qui sera produit par la règle.

� Un sous graphe K de L.� glue : une occurrence de K dans R qui relie le sous graphe avec le graphede coté droit.

� emb : une relation d'enfoncement qui relie les sommets du graphe du cotégauche et ceux du graphe du coté droit.

� Un ensemble cond qui spéci�e les conditions d'application de la règle.

L'application des règles

L'application d'une règle r = (L,R,K, Fcond) à un graphe G produit ungraphe résultant H. Le graphe H peut être obtenu depuis le graphe d'origineG en passant par les cinq étapes suivantes :

1. le choix d'une occurrence du graphe du coté gauche L dans G,selon larègle à appliquer.

2. la véri�cation des conditions d'application selon la condition cond.

3. la suppression de l'occurrence de L (jusqu'à K) de G ainsi que les arcspendillés, c'est-à-dire tout les arcs qui ont perdu leurs sources et/ouleurs destinations. Ce qui fournit le graphe de contexte D de L qui alaissé une occurrence de K.

4. Coller le graphe de contexte D et le graphe du coté droit R suivantl'occurrence de K dans D et dans R. C'est la construction de l'unionde disjonction de D et R et, pour chaque point dans K, identi�er lepoint correspondant dans D avec le point correspondant dans R.

5. l'enfoncement du graphe de coté droit dans le graphe de contexte de Lsuivant la relation d'enfoncement emb.

44

L'application de r à un graphe G pour produire un graphe H est appeléeune dérivation directe depuis G vers H à travers r, elle est dénotée parG→ H. L'ordre de déclenchement des règles d'une grammaire est arbitraire.Toutefois, il est possible de donner des priorités à l'ordre d'exécution desrègles [ElMansouri, 2009, Bahri, 2011, Hamrouche, 2010].Cette approche de transformations de modèles a plusieurs avantages par rap-port aux autres proches :� Les grammaires de graphes sont un formalisme naturel, visuel, formel etde haut niveau pour décrire les transformations.

� Les fondements théoriques des systèmes de réécriture de graphes per-mettent d'aider à véri�er certaines propriétés des transformations tellesque la terminaison ou la correction.

4.3.6 Outils de transformation de graphes

Plusieurs outils de transformation de graphes ont été développés pour assurerd'une manière e�cace et facile les transformations de modèles à l'aide destransformations de graphes, parmi lesquels on peut citer :� AGG [AGG, 2010],The Attributed Graph Grammar System.� AToM3 [atom3, 2011],A Tool for Multi-formalism and Meta-Modelling.� VIATRA [VIATRA, 2010],VIsual Automated model TRAnsformations.� FUJABA [Fujaba, 2011] : From UML to Java and back again.� GreAT [Great, 2011] : The Graph Rewrite And Transformation tool suite.� booggie [booggie, 2011] : brings object-oriented graph grammars into en-gineering.

� Et d'autre outils comme : DiaGen, GenGED, PROGRES, GrGen.NET[Blomer et al., 2011], MoTMoT, GROOVE,..., etc.

Dans le cadre de cette thèse, nous avons opté pour AToM3 pour développernotre grammaire de graphes. Ce choix est justi�é par les nombreux avan-tages présentés par cet outil, parmi lesquels on peut citer : sa simplicité, sadisponibilité, il est multi paradigmes (la possibilité de méta-modéliser ), et ils'adapte bien avec les types de transformations utilisés dans le cadre de cettethèse, à savoir les transformations de type modèle vers modèle.

Présentation de l'outil AToM3

AToM3 [atom3, 2011] � A Tool for Multi-formalism and Meta-Modeling � estun outil visuel de modélisation, de méta-modélisation et multi-formalismes[Lara et Vangheluwe, ]. La transformation de modèles est implémentée enPython [Python, 2010] et s'exécute, sans aucun changement, sur toutes lesplateformes sur lesquels il existe un interpréteur de Python (Linux, Windows

45

et MacOS). Il est développé au laboratoire MSDL (Modeling, Simulationand Design Lab) à l'école d'informatique de l'université de McGill. AToM3

est utile pour la modélisation, la méta-modélisation et la transformation demodèles à l'aide des grammaires de graphes. Par ailleurs AToM3, possède unereprésentation graphique associée aux modèles ainsi qu'au formalismes. Enplus il permet de générer des outils de manipulation graphique des modèlesdécrits selon des formalisme spéci�és dans les méta-spéci�cations. Par lasuite, la transformation de modèles s'e�ectue en exécutant les règles de lagrammaire de graphes. Les deux tâches principales d' AToM3 sont la méta-modélisation et la transformation de modèles.

1. La méta-modélisation, AToM3 possède une modélisation visuelle c-à-dpour méta-modéliser de nouveaux formalismes on peut utiliser le mo-dèle ER ou le modèle des diagrammes de classes. Dans le cadre de cettethèse nous avons choisi d'utiliser le modèle des diagrammes de classes.Ces formalisme peuvent être étendus par l'expression de contraintes.Les contraintes fournissent une vue sur la manière dont un construc-teur est lié à un autre pour qu'il ait un sens. En plus ils sont expriméssous une forme textuelle par exemple OCL :(Object Constraint Lan-guage) d′UML ou bien Python

2. La transformation de modèles,AToM3 supporte la réécriture de graphesqui utilise les règles de grammaire de graphes pour la dé�nition destransformations entre les modèles ainsi que la génération du code. L'uti-lisateur doit dé�nir l'ensemble des règles (elles sont composées de : LHSet RHS), les priorités , les conditions qui doivent être satisfaites pourque la règle soit applicable (pré-condition, post-condition) et les actionsà exécuter.AToM3 o�re la possibilité à l'utilisateur pour créer sa propre nou-velle grammaire, de charger une grammaire prédé�nie ( modi�cation,consultation ou exécution). L'exécution de la grammaire s'e�ectue surun modèle en entrée et produit un modèle de sortie d'une manière au-tomatique. La �gure (�gure 4.9) présente l'outil AToM3.

46

Figure 4.9 � Présentation de l'outil AToM3

4.4 Les avantages et les inconvénients de l'IDM

4.4.1 Les avantages de l'IDM

les avantages de l'approche IDM sont :• Elle met davantage l'accent sur l'automatisation du processus de dévelop-pement 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 à ra�ner,maintenir, et éventuellement de transformer les modèles en d'autres modèlesou de générer le code exécutable. Il est important à noter que ces di�érentesactivité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, cequi permet de générer automatiquement son éditeur. La méta modélisationde langages est de plus en plus adoptée pour des domaines spéci�ques a�nde réduire la complexité et d'exprimer e�cacement les concepts du domaine.

47

4.4.2 Les inconvénients de l'IDM

Les inconvénients de l'approche IDM sont :• Malgré que la dé�nition d'une syntaxe abstraite d'un langage par un méta-modèle est bien maîtrisée et supportée par de nombreux environnementsde méta modélisation, la dé�nition de la sémantique de ces langages resteune question ouverte et cruciale. Actuellement, les environnements de méta-modélisation sont en mesure de faire face à la plupart des problèmes dedé�nition syntaxique, mais ils manquent de supports rigoureux permettantde fournir la sémantique des méta-modèles. La sémantique est généralementdonnée en langage naturel, cela implique que les langages dé�nis par méta-modélisation ne sont pas encore aptes à l'analyse formelle de leurs modèles.• L'absence de notations conviviale des di�érentes techniques formelles estun dé� important pour les modèles formels. L'IDM permet, par le biais desnotions de méta-modèles et de transformation de modèles, de concevoir dessupports outillés pour les méthodes formelles. En ce sens, l'IDM n'apporterien de nouveau sur le plan théorique aux concepts d'analyse formelle, maiselle peut permettre une meilleure utilisation a�n de pro�ter pleinement deleurs avantages.

Conclusion

Dans ce chapitre nous avons présenté une vue globale sur la transformationde modèles et plus précisément la transformation de graphes qui consiste àreprésenter un système sous forme d'un graphe. Dans ce contexte, nous avonsprésenté l'architecture MDA avec ces di�érents modèles, la transformationde modèles, les di�érentes approches existantes en se basant sur une classi�-cation proposée dans la littérature. Par la suite nous avons donné un aperçusur la transformation de graphes qui représente une approche de transforma-tion de modèles, la notion de graphe, la grammaire de graphes � les principeset les applications �, quelques outils de transformation de graphes et nousavons également présenté l'outil AToM3, utilisé dans l'implémentation denotre travail.Les concepts présentés dans ce chapitre constituent un background nécessairepour la compréhension de nos contributions dans le cadre de cette thèse quiseront présentées dans le chapitre suivant (Chapitre 5).

48

Troisième partie

: Contributions

49

Chapitre

5

Application d'une ap-proche de transforma-tion de graphes pourtransformer les Dia-grammes UML2.0 versdes Digrammes UMLOrientés Aspect

Sommaire5.1 Transformation des diagrammes de classe vers

des diagrammes de classe orientés aspect . . . . . 51

5.2 Transformation des diagrammes d'activité vers

des diagrammes d'activité orientés aspect . . . . . 59

5.3 Transformation des diagrammes de communica-

tion vers des diagrammes de communication orien-

tés aspect . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . 79

Dans ce chapitre, nous présentons notre contribution qui consiste à transfor-mer des diagrammes UML2.0 vers des diagrammes UML Orientés Aspect ense basant sur l'approche de transformation de graphes. Le chapitre contienttrois contributions :

1. La transformation des diagrammes de classe vers des diagrammes declasse orientés aspect

2. La transformation des diagrammes d'activité vers des diagrammesd'activité orientés aspect.

3. La transformation des diagrammes de communication vers des dia-grammes de communication orientés aspect

Nous commençons chaque transformation de notre approche de transforma-tion par la dé�nition des méta-modèles associés aux modèles source et cible.

50

Ensuite, nous proposons notre grammaire de graphes qui permet la transfor-mation des modèles d'entrée vers les modèles de sortie et nous terminons parun exemple pour illustrer notre approche de transformation. Cette transfor-mation de graphes est réalisée à l'aide de l'outil de modélisation AToM3 etles contraintes sont exprimées en python.

5.1 Transformation des diagrammes de classevers des diagrammes de classe orientés as-pect

Dans cette section ,nous proposons un Diagramme de Classe Orienté As-pect (DCOA). DCOA est une intégration automatique (tissage) du Modèled'aspect(MA) dans le Diagramme de Classe (DC) en se basant sur la trans-formation de graphes. La syntaxe abstraite de chaque formalisme est décriteà l'aide de méta-modèles. Le processus de transformation est réalisé par unegrammaire de graphe qui prend les modèles de source (DC, MA) commeentrée, exécute les règles de la grammaire, et génère en sortie le modèle cible(DCOA).

5.1.1 Les méta-modèles

Le méta-modèle et l'outil généré pour la manipulation des dia-grammes de classes.

Dans la Figure (5.1), nous présentons notre méta-modèle du diagramme declasse composé de huit classes (ClassDiagram, Class-simple, composition, ag-gregation, heritage (inheritance), association-simple, association-attribut etassociation-multiple) et sept associations (ClassDiagramStart, Association-0,Association-1, Association-2, Association-3, Association-4 et Association-5).Dans la Figure (5.2), nous présentons l'outil généré pour la manipulation desdiagrammes de classes.

1. La dé�nition des classes du méta-modèle :• ClassDiagram : Cette classe a un nom et représente un diagrammede classes.• Class-simple : Cette classe représente les classes et possède trois at-tributs : ”class− attribut”,”Nom− classe”, et ”class− op”.• Composition : Cette classe représente une composition et possèdedeux attributs ”com− name” et ”carte”.

51

Figure 5.1 � Méta-modèle du diagramme de classe

Figure 5.2 � Outil de modélisation du diagramme de Classe

• Aggrégation : Cette classe représente une aggrégation. Elle hérite tousles attributs de la composition : multiplicités et associations.• Héritage (inheritance) : Cette classe représente une relation de géné-ralisation.• Association-simple : Cette classe représente une relation simple entredeux classes. Elle a trois attributs : ”ass−name”, ”caleft”, ”caright”

52

pour indiquer la multiplicité des cas.• Association-attribut : Une association peut posséder ses propres pro-priétés. Elle hérite tous les attributs d'une Association-simple : desmultiplicités, des associations plus un attribut ”ass− attribut”.• Association-multiple : Associations d'ordre supérieur qui peuvent êtretirées avec plus de deux extrémités. Elle hérite de Association-simpletoutes ses propriétés avec ses propres attributs ”carbas”.

2. La dé�nition des associations dans le méta-modèle :ClassDiagramStart, Association-0, Association-1, Association-2, Association-3, Association-4 et Association-5 : utilisé pour connecter une seuleclasse avec d'autres classes du modèle. Par example la Class-simpleest reliée avec les di�érentes classes du modèle (simple, attribute etmultiple) avec Association0 et Association1.

Le méta-modèle et l'outil généré pour la manipulation des modèlesd'aspect pour les diagrammes de classe

Dans la Figure (5.3), nous présentons notre méta-modèle du modèle d'aspectpour le diagramme de classe composé de neuf classes : (Aspect-Diagram, As-pect, ClassDiagram, Class-simple, composition, aggregation, heritage (inhe-ritance), association-simple, association-attribut et association-multiple) ethuit associations : (AspectDiagramStart, Aspect-vers, Association-0, Association-1, Association-2, Association-3, Association-4 et Association-5).Dans la Figure (5.4), nous présentons l'outil généré pour la manipulation dumodèle Aspect pour les diagrammes de classe.• Aspect-Diagram : Cette classe a un nom qui représente le modèle d'aspectdu diagramme de classe. En plus, elle comprend les aspects avec leurs pointsd'activation qui peuvent être des classes ou des associations entre elles.•Aspect :cette classe représente les aspects selon une syntaxe donnée. Chaqueaspect a un nom, les points d'activation et les conseils pour l'insérer.• ClassDiagram, Class-simple, composition, aggregation, héritage (inheri-tance), association-simple, association-attribut et association-multiple : lamême dé�nition utilisée dans le méta-modèle du diagramme de classe.•AspectDiagramStart, Aspect-vers, Association-0, Association-1, Association-2, Association-3, Association-4 and Association-5 : utilisées pour relier lesclasses et les aspects avec leurs points de jonction dans le même modèle. Parexemple, l'association Aspect − vers permet de relier le point de jonctionClass− simple avec son aspect Aspect.

53

Figure 5.3 � Méta-modèle du modèle d'aspect du diagramme de classe

Figure 5.4 � Outil de modélisation du modèle d'aspect du diagramme deClasse

5.1.2 La grammaire de graphes proposée

L'idée principale pour la transformation des diagrammes de classe vers desdiagrammes de classe orientés aspect consiste à ajouter des aspects au niveaudes points de jonction sélectionnés par les points de coupure qui se trouventdans le modèle aspect.Dans la Figure (5.5), nous présentons une grammaire de graphes contenant

54

52 règles chacune exprimant un cas particulier.

Figure 5.5 � Grammaire de graphes pour le diagramme de classe

Nous décomposons les 52 règles en 5 catégories comme suit :• Aspect.PJ : point de jonction de l'aspect.• Aspect.AD : les conseils de l'aspect.• Aspect.Types : l'action de l'aspect est une création, suppression ou lien(association) context entre deux classes.

Catégorie 1 (priorité 1)

Ces règles sont appliquées pour localiser un aspect non préalablement traité(Visité == 0) et créer une classe liée à une autre classe. En outre, Elles sontutilisées pour ajouter une méthode ou un attribut dans une classe selon lesconditions suivantes :• Aspect.PJ == le nom de la classe dans laquelle nous ajoutons l'aspect detype Classe.• Aspect.AD == classe à ajouter (aspect de type classe) avec les di�érentesrelations entre elles ou bien l'ajout d'une méthode ou d'un attribut à l'inté-rieur d'une classe.• Aspect.Types == 'créer' pour créer les aspects de type Classe à ajouter.Cette catégorie comprend sept règles.Même chose pour ajouter un attribut dans une classe.

Catégorie 2 (priorité 2 :)

Ces règles sont appliquées pour créer et ajouter un lien entre deux classesqui ne sont pas liées selon les conditions suivantes :

55

Figure 5.6 � Application de la catégorie 1 avec Aspect.PJ== classe etAspect.AD==classe

Figure 5.7 � Application de la catégorie 1 avec Aspect.PJ== classe etAspect.AD== méthode

• Aspect.PJ == le nom de la classe 1 et la classe 2 qui n'ont pas une relationentre elles.• Aspect.AD == les Associations ; composition ; aggrégation ou héritage.• Aspect.Types == 'créer' ou 'contexte' pour marquer l'aspect comme visité.Cette Catégorie comprend sept règles.

Figure 5.8 � Application du catégorie 2

Le même travail est e�ectué pour ajouter l'association (simple, multiple), lacomposition, l'aggrégation et l'héritage.

Catégorie 3 (priorité 3 :)

Ces règles sont appliquées pour faire face à un aspect non visité auparavantet ajouter une autre relation entre deux classes liées selon les conditionssuivantes :

56

• Aspect.PJ == le nom de la classe 1 et la classe 2, qui ont une relationentre elles.• Aspect.AD == les di�érentes relations dans le diagramme de classe.• Aspect.Types == 'créer' pour créer et marquer l'aspect comme visité. CetteCatégorie comprend les trente règles Remarques : Si Aspect.PJ = classe 1,

Figure 5.9 � Application de la catégorie 3, avec Aspect.PJ==associationsimple et Aspect.AD= association avec attribut.

classe 2 et association simple entre elles. Alors, Aspect.AD = association(avec l'attribut ; multiple) ; composition ; agrégation ou d'héritage. Le mêmetravail pour Aspect.PJ =classe 1, classe 2 et l'association (avec l'attribut ;multiple) ; composition ; agrégation ou d'héritage. Cette Catégorie comprendtreize règles.

Catégorie 4,5 (Priorité Resp 4, 5)

Ces règles sont appliquées respectivement pour retirer une classe ou unerelation entre ces classes selon les conditions suivantes :• Aspect.PJ == classe ou le nom de la relation entre deux classes à suppri-mer.• Aspect.Types == 'supprimer' pour supprimer et marquer l'aspect commevisité.Cette Catégorie comprend les huit règles.

Figure 5.10 � Application de la catégorie 4.

57

Figure 5.11 � Application du Catégorie 5.

5.1.3 Exemple explicatif

Pour illustrer notre approche, nous l'avons appliqué au comportement d'unsystème de recherche simple dans le réseau Internet. Par conséquent, nousavons utilisé un diagramme de classe, où les classes représentent les di�érentescatégories dans le système et les liaisons représentent la relation entre cesclasses. Le modèle Aspect contient sept aspects :

• @ IP : Pour ajouter une classe entre deux classes ayant un lien (rela-tion)entre elles.

• Download : Pour ajouter une méthode dans une classe.

• Document : Pour ajouter une classe avec une relation d'héritage d'uneclasse sélectionnée.

• Album : Pour ajouter une classe avec l'association d'attributs dans uneclasse sélectionnée.

• Aggregation : Doit être ajouté entre deux classes qui ne disposent pasde relation.

• La suppression d'une relation entre deux classes.• La suppression d'une classe dans le réseau.Dans la Figure (5.12), nous présentons le modèle de base et le modèle aspectdu réseau internet.Pour une intégration entre les deux modèles (un Diagramme de Classe (DC)et le Modèle aspect), nous faisons un simple clic sur TransDC. Ceci permetl'exécution de la grammaire de graphes proposée dans la section précédente ;et nous obtenons la Gigure (5.13).

58

Figure 5.12 � Le modèle de base et aspect du réseau internet.

Figure 5.13 � Le résultat de la composition.

5.2 Transformation des diagrammes d'activitévers des diagrammes d'activité orientés as-pect

Dans cette section nous donnons l'approche de transformation des Diagrammesd'activité vers des Diagrammes d'activité Orientés Aspect. Dans notre tra-vail, nous nous intéressons aux points suivants.

59

5.2.1 Les méta-modèles

Le méta-modèle et l'outil de modélisation généré pour la manipu-lation des diagrammes d'activités

Dans la Figure (5.14), nous présentons notre méta-modèle des diagrammesd'activité composé de quinze classes : (ActivityDiagram, ColoireAD, AD-Initial, AD-Final, AD-Activity, AD-Compositeactivity, Transitionsimple, transition-cond, synchronisation, inteription, exception, objet, AccepteEvent, signal,wiatingtime et neuf associations (StartcoloireAD, Start-AD, possed-initailconection,possed-fainalconection, TSactivityverstransition, TSversactivity, has-inside,AOconect et OAconnect).Dans la �gure (5.15, nous présentons l'outil généré pour manipuler les dia-grammes d'activité.

• ActivityDiagram : Cette classe a un attribut qui est le nom et représenteles activités dans le diagramme.

• ColoireAD : Cette classe posséde un nom et représente le couloir desactivités dans le diagramme.

• AD-Initial : Cette classe représente l'activité initial des d'activités ou desactivités composite.

• AD-Final Cette classe représente l'activité �nal du diagramme d'acti-vité.

• AD-Activity : Cette classe représente les activités simples et posséde unattribut qui est le nom.

• AD-Compositeactivity : Cette classe représente les activités compositeset hérite tous les attributs de la AD − Activity, multiplicités et lesassociations.

• Transitionsimple : Cette association représente une transition simpleentre les deux activités source et cible. elle contient un attribut : garde.

• Transition-cond : Cette association représente une transition condition-née d'une activité source vers deux destinations. Elle contient troisattributs : garde, repoui (si la réponse est oui) et repnon (si la réponseest non).

• Synchronisation : Cette classe représente la synchronisation entre lesactivités.

• Interruption, Exception : Représente les signaux qui bloquent ou stoppentcertaines activités.

• Objet : Permet de relier deux activités et posséd un attribut qui est lenom.

60

• AccepteEvent, signal et wiatingtime : Représente un signal ou un évé-nement qui permet l'acceptation ou non de cet événement.

• StartcoloireAD, Start-AD, possed-initailconection, possed-fainalconection,TSactivityverstransition, TSversactivity, has-inside, AOconect et OAconnect :Utilisé pour relier une simple activité avec d'autres activités du modèle. Parexemple la classe AD−Activity est relier a la classe Transitionsimple avecdeux association qui sont TSactivityverstransition et TSversactivity.

Figure 5.14 � Méta-modèle du diagramme d'activité

Le méta-modèle du modèle d'aspect pour les Diagrammes D'acti-vités

Dans la Figure (5.16,nous vous présentons notre méta-modèle du modèle d'as-pect pour les diagrammes d'activités composé de seize classes : Aspectmodel,ColoireAD, Aspect, AD-Initial, AD-Final, AD-Activity, AD-Compositeactivity,Transitionsimple, transition-cond,synchronisation, inteription, exception, ob-jet, AccepteEvent, signal et wiatingtime.Nous avons dix associations : StartcoloireAD, Start-aspect, Start-AspectModel,

61

Figure 5.15 � l'outil de modélisation des diagrammes D'activité

possed-initailconection, possed-fainalconection TSactivityverstransition, TS-versactivity, has-inside, AOconect et OAconnect.Dans la �gure (5.17, nous présentons l'outil généré pour manipuler le modèled'aspect pour les diagrammes d'activités.

• Aspectmodel : Cette classe a un nom, représente le modèle d'aspect dudiagramme et comprend des aspects avec leurs points d'activation quipeuvent être des activités ou des liens entre deux activités ou plus.

• Aspect : Cette classe représente les aspects selon une syntaxe donnée.Chaque aspect a un nom, les points d'activation et les conseils pourl'insérer.

• ColoireAD, AD-Initial, AD-Final, AD-Activity, AD-Compositeactivity, Tran-sitionsimple, transition-cond, synchronisation, inteription, exception, objet,AccepteEvent, signal et wiatingtime : la même dé�nition utilisée dans leméta-modèle des diagrammes d'activités.• StartcoloireAD, Start-aspect, Start-AspectModel, possed-initailconection,possed-fainalconection, TSactivityverstransition, TSversactivity, has-inside,AOconect et OAconnect : utilisé pour relier les activités et sélectionner l'as-pect avec leur point de jonction dans le même modèle. Par exemple, l'associa-tion Start−AspectModel sélect les points de jonction qui sont : AD−Initial,AD − Final, AD − Activity, AD − Compositeactivity, Transitionsimple,transition−cond, synchronisation, inteription, exception, objet,AccepteEvent,signal et wiatingtime.

62

Figure 5.16 � Méta-modèle pour le modèle d'aspect des diagrammes d'ac-tivité

5.2.2 La grammaire de graphe proposée pour le dia-gramme d'activité

Dans la Figure (5.18), nous présentons une grammaire de graphes contenantquatre-vingt huit (88) règles chacune exprime un cas particulier.Nous décomposons les 88 règles en 10 Catégories.Remarques :• Aspect.PJ : point de jonction de l'aspect.• Aspect.AD : les conseils de l'aspect.• Aspect.Types : l'action de l'aspect est une création ou suppression ou unlien (association) context entre deux activités.

Catégorie 1(Priorité 1) : Ces règles sont appliquées pour localiser un as-

63

Figure 5.17 � Outil de modélisation pour le modèle d'aspect du diagrammed'activité

Figure 5.18 � Grammaire de graphes pour le diagramme d'activité

pect non préalablement traité (Visité == 0) et créer une nouvelle ac-tivité liée à l'état initial selon les conditions suivantes :• Aspect.PJ = état initial d'une activité ou d'une activité compositedans lequel nous ajoutons les aspects de type activité.• Aspect.AD== activité ajoutée (Aspect de type activité ou activitécomposite) avec les di�érentes relations entre elles.• Aspect. Types == "create" pour créer les aspects de type activité àajouter.

64

Cette Catégorie comprend les quatre règles comme indiqué dans la�gure (5.19).

Figure 5.19 � Application de la Catégorie 1 avec Aspect.PJ= état initialavec activité, Aspect. AD=activité avec une transition simple et Aspect.Types= create (créer )

.

Le même travail pour : Aspect.PJ= état initial avec activité, Aspect.AD=composite activité avec une transition simple et Aspect. Types=create(créer)ou Aspect.PJ= état initial avec composite activité, Aspect. AD=activitéou composite activité avec une transition simple et Aspect. Type=create(créer).

Catégorie 2(Priorité 1) : Ces règles sont appliquées pour localiser un As-pect non préalablement traité (visite == 0) et de créer une nouvelleactivité liée à l'état �nal selon les conditions suivantes :• Aspect.PJ == état �nal dans lequel on ajoute un aspect de typeactivité.• Aspect.AD== activité ajoutée (Aspect de type activité ou compositeactivité) avec les di�érentes relations entre elles.• Aspect.Types == create pour créer les aspects de type activité àajouter.Cette Catégorie comprend deux règles comme indiqué dans la �gure(5.20).Le même travail pour : Aspect.PJ= etat �nal , Aspect. AD=compositeactivité avec une transition simple et Aspect. Types=create(créer).

Catégorie 3(Priorité 2) : Ces règles sont appliquées pour créer et ajouterun lien entre deux activités ne possèdant pas une relation entre ellesselon les conditions suivantes :• Aspect.AD = = transition simple ; transition conditionnel ; synchro-nisation des activités ; objet ; exception ; interruption ou bien ajoutéactivité ou activité composite avec une transition simple ; condition-née ; synchronisation ; objet ; exception ou interruption.

65

Figure 5.20 � Application de la catégorie 2 avec Aspect.PJ= état �nal , As-pect. AD=activité avec une transition simple et Aspect. Types=create(créer)

.

• Aspect.Type = = create(créer) ou context(relier) et pour marquerl'aspect comme visité.• Aspect.PJ== le nom de l'activité 1 et l'activité 2 n'ayant pas derelation entre elles.Cette Catégorie comprend dix-sept règles tel que le montre la �gure(5.21).

Figure 5.21 � Application de la Catégorie 3 avec Aspect.PJ= le vide entrele nom de l'activité 1 et l'activité 2 , Aspect. AD= une transition simple etAspect. Types=create(créer )

.

Le même travail pour : Aspect.PJ= le vide entre le nom de l'activité 1et l'activité 2, Aspect. AD= transition conditionnée ; synchronisation ;objet ; exception or interruption ou bien ajouté une activité ou compo-site activité avec une transition simple ; conditionné ; synchronisation ;objet ; exception ou interruption et Aspect. Types == create(crée) orcontext(relier)et pour marquer l'aspect comme visité.

Catégorie 4(Priorité 2) : Ces règles sont appliquées pour créer et ajouterun lien entre l'activité et l'activité composite qui n'ont pas de relationentre elles selon les conditions suivantes :

66

• Aspect.PJ== le nom de l'activité et l'activité composite qui n'ontpas de relation entre elles.• Aspect.AD == transition simple ; conditionné ; synchronisation ; ob-jet d'information ; exception ; interruption ou bien ajouté activité oucomposite activité avec une transition simple ; conditionné ; synchroni-sation ; objet ; exception ou interruption.• Aspect.Types = = create(crée) ou context(relier)et pour marquerl'aspect comme visité.Cette Catégorie comprend dix-sept règles tel que le montre la �gure(5.22).

Figure 5.22 � Application de la Catégorie 4 avec Aspect.PJ= le vide entrele nom de l'activité et le nom de l'activité composite, Aspect. AD= unetransition simple et Aspect. Types=context(relier)

.

Le même travail pour : Aspect.PJ= le vide entre le nom de l'activité 1et le nom de composite activité, Aspect. AD= transition conditionné ;synchronisation ; objet ; exception ou interruption ou bien ajouté ac-tivité ou composite activité avec une transition simple ; conditionnée ;synchronisation ;objet ; exception ou interruption et Aspect. Type = =create(crée) ou context(relier)et pour marquer l'aspect comme visité

Catégorie 5(Priorité 2) : Ces règles sont appliquées pour créer et ajouterun lien entre deux activités composites qui n'ont pas de relation entreelles en respectant les conditions suivantes :• Aspect.PJ== le nom de la composite Activité 1 et la compositeactivité 2 qui n'ont pas de relation entre elles.• Aspect.AD == transition simple ; objet.• Aspect.Types== create(crée) ou context(relier)et pour marquer l'as-pect comme visité.Cette Catégorie comprend deux règles tel que le montre la �gure (5.23).

Catégorie 6(Priorité 1) : Ces règles sont appliquées pour localiser un As-pect non préalablement traité (visité == 0) et relier une activité avec

67

Figure 5.23 � Application de la Catégorie 5 avec Aspect.PJ= le vide entrele nom de l'Activité composite 1 et le nom de l'activité composite 2, Aspect.AD= une transition simple et Aspect. Types=context(relier)

.

une autre activité ou une activité composite en respectant les conditionssuivantes :•Aspect.PJ == le nom de l'activité à laquelle nous ajoutons les aspectsde type activité.• Aspect.AD== Activité ou activité composite à ajoutés (aspect detype activité ou composite activité ) avec les di�érentes relations entreelles.• Aspect.Types == create pour créer un aspect de type activité ouactivité composite à ajouter.Cette Catégorie comprend dix règles.

Figure 5.24 � Application de la Catégorie 6 avec Aspect.PJ= le nom del'activité , Aspect. AD= exception et Aspect. Types=create(créer)

.

Le même travail pour Aspect.PJ=le nom de l'activité, Aspect. AD=activitéou composite activité avec une transition simple ; conditionné ; synchro-nisation ; objet ou interruption et Aspect. Types=create (crée).

Catégorie 7(Priorité 1) : Ces règles sont appliquées pour localiser un As-pect non préalablement traité (Visité == 0) et relier une composite

68

activité avec une autre activité ou une composite activité. Selon lesconditions suivantes :• Aspect.PJ == le nom de composite activité dans laquelle on ajouteun aspect de type activité.• Aspect.AD== Activité ou composite activité à ajouter (aspect detype activité ou composite activité ) avec les di�érentes relations entreelles.• Aspect.Types == create pour créer les aspects de type activité oucomposite activité à être ajoutés.Cette catégorie comprend dix règles.

Figure 5.25 � Application de la catégorie 7 avec Aspect.PJ= lenom de composite activité, Aspect. AD= composite activité et Aspect.Types=create(créer)

.

Le même travail pour Aspect.PJ=le nom de la composite activité, As-pect. AD=activité ou composite activité avec une transition condi-tionné ; synchronisation ; objet ou interruption ; exception et Aspect.Types=create (crée).

Catégorie 8(Priorité 3) : Ces règles sont appliquées pour répondre à unaspect non visité auparavant, et ajouter une autre relation entre deuxactivités qui ont un lien entre elles en respectant les conditions sui-vantes :• Aspect.AD == les di�érentes relations dans le diagramme d'activité.• Aspect.Types == create pour créer et marquer l'aspect comme visité.• Aspect.PJ== le nom de l'activité 1 et l'activité 2 qui ont une relationentre elles.Cette catégorie comprend quinze règles.Remarque :• Si Aspect.PJ = le nom de l'activité 1, le nom de l'activité 2 et unetransition simple entre elles.

69

Figure 5.26 � Application de la catégorie 8 avec Aspect.PJ = une transitionsimple, Aspect. AD= objet d'information

.

• Alors Aspect.AD= transition conditionne ; synchronisation ou inter-ruption ; exception.La même chose pour Aspect.PJ= le nom de l'activité 1, le nom de l'acti-vité 2 et transition conditionné ; synchronisation ; objet d'information ;interruption ou exception.

Catégorie 9 10(Priorité 4,5) : Ces règles sont appliquées respectivementpour supprimer une activité ou une relation entre activités, selon lesconditions suivantes :• Aspect.Type = = delete (supprimer).• Aspect.PJ== activité ou le nom de la relation entre ces activités quidoivent être supprimées.Cette Catégorie comprend dix règles.

Figure 5.27 � Application de la Catégorie 9 avec Aspect.PJ= une transitionconditionnée

.

La même chose pour Aspect.PJ= composite activité ; une transitionsimple ; synchronisation ; objet d'information ; interruption ;AcceptEvent(événement Accepté), signal et waitingtime (le temps d'attente).

70

Figure 5.28 � Application de la Catégorie 10 avec Aspect.PJ= une Activité.

5.2.3 Exemple explicatif

A�n de mettre en évidence notre approche nous avons opté pour l'étudede cas d'un exemple pour montrer les étapes de transformation (les règles)en utilisant l'outil AToM3. Nous avons appliqué notre approche sur � leprocessus de réalisation d'un mémoire de �n d'étude �. Dans la Figure (5.29),nous présentons la modélisation du comportement de ce processus avec lediagramme d'activité qui est notre modèle de base.

Figure 5.29 � Processus de réalisation d'un mémoire avec le diagrammed'activité

Notre modèle d'aspect contient deux aspects : évaluation et véri�cation commeindiqué dans la Figure (5.30). La Figure (5.31) présente le résultat obtenuaprès l'application de notre grammaire de graphes.

71

Figure 5.30 � Le modèle d'aspect pour le processus de réalisation d'unmémoire avec le diagramme d'activité

Figure 5.31 � Processus de réalisation d'un mémoire avec un diagrammed'activité orienté Aspect

72

5.3 Transformation des diagrammes de com-munication vers des diagrammes de com-munication orientés aspect

A�n de transformer un Diagramme de Communication (DC) vers un Dia-gramme de Communication Orienté Aspect (DCOA), nous proposons deuxméta-modèles ; le premier pour le diagramme de communication et le deuxièmepour le modèle aspect. Ces méta-modèles sont représentés par le formalismede diagramme de Classe UML et les contraintes sont exprimées en Python.Nous proposons aussi un ensemble de règles qui représentent notre grammairede graphes.

5.3.1 Les méta-modelées

Le méta-modèle et l'outil de modélisation des diagrammes de Com-munication

Dans la Figure (5.32), nous présentons notre méta-modèle composé de troisclasses (diagcomm, objet et objetaspect) et deux associations (contient, lien).

• Diagcomm : Cette classe sert à représenter le diagramme de communi-cation.

• Objet : Cette classe représente les objets ; chaque objet possède un nomet peut communiquer à travers des connecteurs.

• Objetaspect : Cette classe représente les objets ajoutés (les aspects) auDC et hérite tous ses attributs : multiplicités, associations à partir dela classe objet.

• Contient : C'est une association de composition, qui permet de relier leDiagcomm avec ses objets.

• Lien : C'est une association simple, permettant la communication entredeux objets. Autrement dit, elle représente les messages envoyés oureçus par un objet.

Dans la Figure (5.33), nous présentons notre outil de modélisation des dia-grammes de communication.Dans la Figure (5.34), nous présentons notre méta-modèle du modèle aspectcomposé de trois classes (modelAspect, Aspect et objet) et trois associations(possède, Vers et lien).

• modelAspect : Cette classe englobe les aspects avec leurs points d'acti-vation qui peuvent être des objets ou des liens entre deux objets.

73

Figure 5.32 � Méta-modèle du diagramme de communication

Figure 5.33 � L'outil de modélisation du diagramme de communication

• Aspect : Cette classe représente les aspects selon une syntaxe donnée ;chaque aspect possède un nom, un point d'activation et un advice àajouter.

• Objet : Cette classe représente les objets ; chaque objet possède un nom.

• Posséde : C'est une association de composition qui relie le modèle aspectavec ses aspects.

• Vers : C'est une association simple qui relie les aspects avec les objets surlesquels un aspect devra être inséré.

• Lien : C'est une association simple qui relie les objets entre eux ; ce lienreprésente les messages envoyés ou reçus par les objets.

74

Figure 5.34 � Méta-modèle du modèle aspect pour le diagramme de com-munication

Dans la Figure (5.35), nous présentons l'outil de modélisation du modèleAspect pour les diagrammes de communication.

Figure 5.35 � L'outil de modélisation du modèle aspect pour le diagrammede communication

5.3.2 La grammaire de graphes proposée

Nous proposons une grammaire de graphes contenant six règles chacune ex-primant un cas particulier. Ces règles seront appliquées dans l'ordre croissant(chaque règle a une priorité). La Figure (5.36) représente notre grammaire.

75

Figure 5.36 � Grammaire de graphes proposée

Remarque : OB1, OB2 : sont des objets ; OBA : sont des objets aspects àajouter ;aspect.add = = sont les conseils d'un aspect et aspect.type = = sontles types d'un aspect (ajout,suppression,lien).

Règle 1, 2 (Priorité resp 1, 2) : Ces règles sont appliquées pour localiserun aspect non traité précédemment (Visité = = 0), et créer un objetlié à un autre objet ou entre deux objets ayant déjà communiqués danscet ordre comme indiqué dans les Figures (5.37) et (5.38).

Figure 5.37 � Application de la règle 1

Règle 3 (Priorité 3) : Cette règle est appliquée pour créer et ajouter unlien reliant deux objets qui ne communiquent pas, selon la condition(aspect.add = = "lien" et aspect.type = = create) ; et pour marquerl'aspect comme visité comme indiqué dans la Figure (5.39).

76

Figure 5.38 � Application de la règle 2

Figure 5.39 � Application de la règle 3

Règle 4 (Priorité 4) : Cette règle est appliquée pour traiter un aspect nonvisité précédemment, et ajouter un objet communiquant entre deuxautres (cet objet est parfaitement adéquat aux objets non liés) commeindiqué dans la Figure (5.40).

Figure 5.40 � Application de la règle 4

Règle 5, 6 (Priorité respectivement 5, 6) : Ces règles sont appliquéespour supprimer respectivement un objet existant ou un lien selon lacondition (aspect.type == delete) comme indiqué dans les Figures(5.41)et (5.42).

5.3.3 Exemple explicatif

Pour valider notre approche, nous l'avons appliqué sur le comportement d'unréseau internet. Pour ce faire nous avons adopté un diagramme de communi-cation, dont les objets représentent les di�érentes machines (Mi) et les liens

77

Figure 5.41 � Application de la règle 5

Figure 5.42 � Application de la règle 6

représentent la communication entre ces machines (objets). Le Modèle As-pect représente cinq aspects (la sécurité sur une machine, la véri�cation desdeux machines communiquantes, l'ajout d'un objet de communication entredeux machines qui ne communiquent pas, l'ajout d'un lien de communicationentre deux machines, la suppression d'un objet dans le réseau). Voir la Figure(5.43) qui englobe les deux modèles.Pour obtenir une intégration entre les deux modèles (Diagramme de Com-munication (DC) et le modèle d'aspect ), nous faisons un simple cliquesur TransDC. Ce qui permet l'exécution de notre grammaire de graphes(ensemble des règles) proposée dans la section précédente. La Figure (5.44)donne le résultat de la composition.

78

Figure 5.43 � Modèle de base et aspect du réseau internet

Figure 5.44 � Modèle composé pour le réseau internet

5.4 Conclusion

Dans ce chapitre, nous avons proposé une approche automatique basée surla transformation de graphes pour générer des diagrammes UML orientésAspect à partir des diagrammes UML2.0. Cette approche est basée sur la

79

méta-modélisation (les méta-modèles).L'approche est divisée en trois sous approches :

1. La transformation des diagrammes de classe vers des diagrammes declasse orientés aspect

2. La transformation des diagrammes d'activité vers des diagrammesd'activité orientés aspect.

3. La transformation des diagrammes de communication vers des dia-grammes de communication orientés aspect

Donc, nous avons proposé dans chaque approche la dé�nition du méta-modèlepour le modèle d'entrée ainsi que le méta-modèle du modèle de sortie. En-suite nous avons présenté une grammaire de graphes � ensemble de règles� permettant la réalisation de la transformation. Cette transformation a étée�ectuée à l'aide de l'outil de modélisation et de méta-modélisation AToM3

et les contraintes ont été exprimées en python. dans le chapitre suivant, nousallons illustrer un exemple de transformation bien discuté dans la littérature.

80

Chapitre

6

Études de cas sur latransformation desDiagrammes UML 2.0vers des DigrammesUML Orientés Aspect

Nous avons appliqué notre approche de transformation sur trois études decas. Le premier sur le comportement d'un distributeur automatique d'argent,le deuxième sur le processus de participation à une conférence et le derniersur le processus d'établissement d'une commande d'un client. Nous notonsque nous avons obtenu de bons résultats.

6.1 Étude de cas sur le comportement d'un dis-tributeur automatique d'argent

Pour valider notre approche, nous l'avons appliqué sur le comportement d'undistributeur automatique d'argent (CCP). Par conséquent, nous avons uti-lisé trois diagrammes : classe, activités et communication pour modéliser lemodèle de base. Nous avons également trois modèles d'aspects :Le premier modèle d'aspect est pour la classe représentant un aspect quiest la véri�cation du code CCP. Cet aspect permet de véri�er le code del'utilisateur s'il est valide ou non après la saisie du code.Le deuxième est le modèle d'aspect pour l'activité représente cinq aspects(la langue, la véri�cation du code non valide, la véri�cation du temps, lacontinuation dans des activités données).

• La langue : Cet aspect ajoute la notion de langue que l'utilisateur peututiliser la machine dans une langue donnée.

• Véri�cation du code non valable : Cet aspect permet de véri�er si lecode est invalide ; après 3 fois de saisie du code l'utilisateur est bloqué.

• Véri�cation du temps : Cet aspect permet de véri�er le temps d'inac-tivité de l'utilisateur sur une machine.

81

• La continuation d'une activité donnée : Cet aspect permet à l'utili-sateur de continuer à utiliser les opérations d'une machine après unretrait ou une consultation de son compte.

Le troisième modèle aspect est pour la communication. Il représente l'aspectde la véri�cation du code CCP. Cet aspect permet de véri�er le code del'utilisateur s'il est valide ou non après la saisie du code.

6.1.1 Le modèle de base et aspect pour les diagrammesde classe, activité et communication

Le modèle de base et aspect pour le diagramme de classe

Dans la Figure (6.1), nous présentons le modèle de base et aspect pour lediagramme de classe.

Figure 6.1 � Modèle de base et d'aspect de la machine CCP pour le dia-gramme de classe

Le modèle de base et aspect pour le diagramme d'activité

Dans les Figures (6.2) et (6.3), nous présentons le modèle de base et aspectpour le diagramme d'activité.

82

Figure 6.2 � Modèle de base de la machine CCP pour le diagramme d'ac-tivité

Le modèle de base et aspect pour le diagramme de communication

Dans la Figure (6.4), nous présentons le modèle de base et aspect pour lediagramme de communication.

6.1.2 Le modèle composé pour les diagrammes de classe,activité et communication

Le modèle composé : un diagramme de classes orienté aspect

Dans la Figure (6.5), nous présentons le modèle composé qui est un dia-gramme de classes orienté aspect.

Le modèle composé : un diagramme d'activité orienté aspect

Dans la Figure (6.6), nous présentons le modèle composé qui est un dia-gramme d'activité orientée aspect.

83

Figure 6.3 � Modèle d'aspect de la machine CCP pour le diagramme d'ac-tivité

Le modèle composé : un diagramme de communication orienté as-pect

Dans la Figure (6.7),nous présentons le modèle composé qui est un dia-gramme de communication orientée aspect.

84

Figure 6.4 � Modèle de base et aspect de la machine CCP pour le diagrammede communication

Figure 6.5 � Diagramme de classe orienté aspect

85

Figure 6.6 � Diagramme d'activité orientée aspect

Figure 6.7 � Diagramme de communication orientée aspect

86

6.2 Étude de cas sur le processus de partici-pation a une conférence

Pour illustrer notre approche, nous l'avons appliqué aussi sur le processusde participation à une conférence. Par conséquent, nous avons utilisé troisdiagrammes : classe, activités et communication pour modéliser le modèle debase. Nous avons également trois modèles d'aspects :Le premier modèle d'aspect est pour la classe. Il représente un aspect quipermet la véri�cation des informations et les articles. Cet aspect permet devéri�er les informations d'un chercheur et de véri�er si le format de l'articleest conforme ou non au format de la conférence aprés la soumission.Le deuxième est le modèle d'aspect pour l'activité. Il représente quatre as-pects (Véri�cation de l'article, évaluation de la décision, OK de la version�nale, Accusé de réception).

• Véri�cation de l'article : Cet aspect permet de véri�er la structure del'article selon le format de la conférence.

• Evaluation de la décision : Cet aspect permet d'évaluer la décision desévaluateurs (reviewers) s'il y à un con�it.

• OK de la version �nale : Cet aspect permet de contrôler la version �-nale si elle est corrigée ou non avant de publier l'article.

• Accusé de réception : Cet aspect permet de donner un accusé de récep-tion si l'argent de l'enregistrement de l'article est disponible au niveaudu compte de la conférence.

Le troisième modèle aspect est pour la communication. Il représente un as-pect qui est la véri�cation d'information et de l'article. cet aspect permet devéri�er les informations d'un chercheur et de véri�er si le format de l'articleest conforme ou non au format de la conférence aprés la soumission.

6.2.1 Le modèle de base et aspect pour les diagrammesde classe, activité et communication

Le modèle de base et aspect pour le diagramme de classe

Dans la Figure (6.8), nous présentons le modèle de base et aspect pour lediagramme de classe.

Le modèle de base et aspect pour le diagramme d'activité

Dans les Figures (6.9)et (6.5), nous présentons le modèle de base et aspectpour le diagramme d'activité.

87

Figure 6.8 � Modèle de base et d'aspect du processus de participation à uneconférence pour le diagramme de classe

Figure 6.9 � Modèle de base du processus de participation à une conférencepour le diagramme d'activité

Le modèle de base et aspect pour le diagramme de communication

Dans la Figure (6.11), nous présentons le modèle de base et aspect pour lediagramme de communication.

88

Figure 6.10 � Modèle d'aspect du processus de participation à une confé-rence pour le diagramme d'activité

Figure 6.11 � Modèle de base et aspect du processus de participation à uneconférence pour le diagramme de communication

89

6.2.2 Le modèle composé pour les diagrammes de classe,activité et communication

Le modèle composé : Un diagramme de classes orienté aspect

Dans la Figure (6.12), nous présentons le modèle composé qui est un dia-gramme de classe orienté aspect.

Figure 6.12 � Diagramme de classe orienté aspect

Le modèle composé : Un diagramme d'activité orienté aspect

Dans la Figure (6.13), nous présentons le modèle composé qui est un dia-gramme d'activité orienté aspect.

Le modèle composé : Un diagramme de communication orientéaspect

Dans la Figure (6.14), nous présentons le modèle composé qui est un dia-gramme de communication orienté aspect.

90

Figure 6.13 � Diagramme d'activité orienté aspect

Figure 6.14 � Diagramme de communication orienté aspect

6.3 Étude de cas sur le processus d'établisse-ment d'une commande par un client

La troisième étude de cas est le processus d'établissement d'une commandepar un client. Nous avons utilisé donc les trois diagrammes : classe, activité

91

et communication pour modéliser le modèle de base. Nous avons égalementtrois modèles d'aspects :Le premier modèle d'aspect est pour la classe. Il représente deux aspect lepremier est la disponibilité d'une commande ; cet aspect permet de véri�er sila commande est disponible ou non et le deuxième c'est possède. Cet aspectpermet de donner une association de composition entre un fournisseur et lescomptables.Le deuxième est le modèle d'aspect pour l'activité. Il représente deux aspects(Véri�cation du prix, contrôle de payement).Véri�cation du prix : Cet aspect permet de véri�er le prix d'une commandeavant d'envoyer la facture au client.Contrôle de payement : Cet aspect permet de contrôler si le client a payé lacommande ou non. si oui la facture est enregistré si non il passe vers un état�nal.Le troisième modèle aspect est pour la communication. Il représente troisaspects qui sont : le contrôleur de prix, le prix contrôlé et l' aspect de sup-pression d'un lien.

• Le contrôleur de prix : Cet aspect permet de contrôler les prix établispar le comptable.

• Le prix contrôlé : Cet aspect permet d'ajouter un lien ou bien des mes-sages entre les contrôleurs et le fournisseur.

• Suppression d'un lien : Cet aspect permet de supprimer un lien entrele fournisseur et les comptables.

6.3.1 Le modèle de base et aspect pour les diagrammesde classe,activité et communication

Le modèle de base et aspect pour le diagramme de classe

Dans la Figure (6.15), nous présentons le modèle de base et aspect pour lediagramme de classe.

Le modèle de base et aspect pour le diagramme d'activité

Dans les Figures (6.16)et (6.17), nous présentons le modèle de base et aspectpour le diagramme d'activité.

Le modèle de base et aspect pour le diagramme de communication

Dans la Figure (6.18),nous présentons le modèle de base et aspect pour lediagramme de communication.

92

Figure 6.15 � Modèle de base et d'aspect du processus d'établissement d'unecommande par un client pour le diagramme de classe

Figure 6.16 � Modèle de base du processus d'établissement d'une commandepar un client pour le diagramme d'activité

93

Figure 6.17 � Modèle d'aspect du processus d'établissement d'une com-mande par un client pour le diagramme d'activité

Figure 6.18 � Modèle de base et aspect du processus d'établissement d'unecommande par un client pour le diagramme de communication

6.3.2 Le modèle composé pour les diagrammes de classe,activité et communication

Le modèle composé : Un diagramme de classes orienté aspect

Dans la Figure (6.19), nous présentons le modèle composé qui est un dia-gramme de classes orienté aspect. 94

Figure 6.19 � Diagramme de classe orienté aspect

Le modèle composé : Un diagramme d'activité orienté aspect

Dans la Figure (6.20), nous présentons le modèle composé qui est un dia-gramme d'activité orienté aspect.

Figure 6.20 � Diagramme d'activité orientée aspect

95

Le modèle composé : Un diagramme de communication orientéaspect

Dans la Figure (6.21),nous présentons le modèle composé qui est un dia-gramme de communication orienté aspect.

Figure 6.21 � Diagramme de communication orienté aspect

6.4 Conclusion

Dans ce chapitre nous avons présenté trois études de cas a�n d'illustrer notreapproche de transformation des diagrammes UML 2.0 vers des diagrammesUML orientés aspect. Le premier sur le comportement d'un distributeur au-tomatique d'argent. Nous avons dé�nis des modèles de base et aspect pour lesdiagrammes de classe, activité et communication. L'application de la gram-maire de graphes nous a permis d'obtenir automatiquement un diagrammeUML orienté aspect. Le deuxiéme sur le processus de participation à uneconférence et le dernier c'est le processus d'établissement d'une commandepar un client. Nous avons aussi suivi les mémes étapes cité précédemmentpour arriver a des diagrammes UML orientés aspect. Finalement nous avonsmontré l'e�cacité de notre approche a travers les résultats obtenus.

96

Chapitre

7 Conclusion et Perspec-tives

Conclusion

Les systèmes qui engendrent un comportement complexe nécessitent un for-malisme très e�cace pour modéliser leurs fonctionnements. Pour ce type desystèmes plusieurs formalismes existent tels que les diagrammes d'UML 2.0.Le problème de ces formalismes est la duplication des fonctionnalités trans-versales, di�culté de réutilisation des modèles et le problème d'interaction(crosscutting concern) entre les préoccupations. A�n de remédier à ces pro-blèmes, plusieurs solutions ont été développées parmi lesquelles on trouve lamodélisation orientée aspect. La modélisation orientée aspect est un nouveaulangage de modélisation développé par Kiczales et son équipe en 1996. Elletraite les limites de la modélisation orientée objet par l'introduction de lanotion d'aspect, mais elle reste basée sur le paradigme orientée objet.Dans ce travail, nous utilisons les techniques de transformation de graphespour transformer des modèles orientés objet vers des modèles orientés aspect.L'exécution d'une grammaire de graphes permet l'intégration du modèle d'as-pect dans le modèle de base pour obtenir un modèle orienté aspect ainsi que,le tissage (composition ou intégration) qui est une application des règles dela grammaire de graphes. De ce fait, l'outil AToM3 basé sur la méta- mo-délisation est choisi. Dans notre thèse, nous avons proposé une approcheet un nouvel outil de transformation qui permet de transformer certainsDiagrammes UML 2.0 vers des Diagrammes UML orientés aspect en uti-lisant la grammaire de graphes. À cet e�et, nous avons utilisé le formalismedes diagrammes de classe UML comme formalisme de méta-modélisation.Nous avons d'abord proposé six méta-modèles : Un méta-modèle pour le dia-gramme de classe et un pour le modèle d'aspect de classe, un méta-modèlepour le diagramme d'activité et un pour le modèle d'aspect d'activité et unméta-modèle pour le diagramme de communication et un autre pour le mo-dèle d'aspect communication. Ensuite, nous avons proposé une grammaire degraphes qui e�ectue le processus de transformation. Finalement, Nous avonsappliqué notre approche sur des études de cas.

97

Perspectives

Comme perspectives de cette thèse, nous envisageons :En premier lieu de faire la même transformation en utilisant des outils stan-dards comme TGG, EMF et GMF . Ensuite, nous proposons l'utilisationdes approches a�n d'assurer la qualité des modèles aspects composés. Nousplani�ons également d'inclure la phase d'analyse et de véri�cation pour ladétection des con�its et la dépendance entre les règles. Nous proposons aussila résolution des problèmes tels que : la séquence des points de jonction dansune point de coupure donné d'un aspect au moment de la composition etl'interaction entre les préoccupations transversale(crosscutting concern). Enplus, nous allons transformer d'autres diagrammes UML 2.0 vers des dia-grammes UML orientés aspect. D'autre part nous proposons de transformerles modèles obtenus (les diagrammes UML orienté aspect) vers des modèlesformels pour faire la véri�cation, le test et la validation des systèmes.

98

Bibliographie

[AGG, 2010] AGG (2010). http ://tfs.cs.tu-berlin.de/agg/.

[ANDRE, 2004] ANDRE, S. (novembre 2004). Mda (model dri-ven architecture) principes et états de l'art. http ://syl-vain.andre.free.fr/MDA/MDAv1.8.pdf.

[Andries et al., 1999] Andries, M., Engels, G., Habel, A., Hoffmann,B., Kreowski, H. J., Kuske, S., Pump, D., Schürr, A. et Taent-zer, G. (1999). Graph transformation for speci�cation and programming.Science of Computer programming, 34(1):1�54.

[Araujo et al., 2002] Araujo, J., Moreira, A., Brito, I. et Rachid, A.(October 2002). Aspect oriented requirements with uml. Workshop :Aspect-Oriented Modelling with UML ,UML 2002,Dresden,Germany.

[atom3, 2011] atom3 (2011). http ://-moncs.cs.mcgill.ca/msdl/research/projects/atom3.html.

[Audibert, 2008] Audibert, L. (novembre 2007-2008.). Uml 2.0, institutuniversitaire de technologie de villetaneuse, département informatique,adresse du document : http ://laurentaudibert.developpez.com/cours-uml/html/cours-uml.html.

[Bahri, 2011] Bahri, M. R. (2011). Une approche intégrée Mobile-UML/Réseaux de Petri pour l'Analyse des systèmes distribués à based'agents mobiles. Thèse de doctorat, Université de Mentouri, Constan-tine.

[Blanc, 2005] Blanc, X. (2005). Mda en action : Ingénierie logicielle guidéepar les modèles. Eyrolles.

99

[Blomer et al., 2011] Blomer, J., Gei, R. et Jakumeit, E. (2011). Thegrgen.net user manual www.grgen.net.

[booggie, 2011] booggie (2011). http ://www.booggie.org/.

[Boubendir, 2011] Boubendir, A. (17 /11 /2011). Un cadre génirique pourla détection et la résoulution des intéraction entre les aspects. Thèse dedoctorat, Université de Mentouri, Constantine.

[Bowen et Hinchey, 1995] Bowen, J. P. et Hinchey, M. G. (july 1995). Se-ven more myths of formal methods ieee software,. pages 34�41.

[Brichau et D'Hondt, 2005] Brichau, J. et D'Hondt, T. (30 August 2005).Introduction to aspect-oriented software development, aosd-europe,.

[Celso et al., ] Celso, J., Freire, J. et Giraudin, J. Agnès front ateliermodsi : Un outil de méta- modélisation et de multi-modélisation. labora-toire de logiciels et systèmes réseaux, imag b.p. 72 - 38402 - saint martind h`eres cedex france.

[Chartrand et Zhang, 2009] Chartrand, G. et Zhang, P. (2009). Chro-matic Graph Theory, page 27.

[Czarnecki et Helsen, 2003] Czarnecki, K. et Helsen, S. (2003). Classi-�cation of model transformation approaches. OOPSLA'03 Workshop onGenerative Techniques in the Context of Model- Driven Architecture.

[Czarnecki et Helsen, 2006] Czarnecki, K. et Helsen, S. (2006). Feature-based survey of model transformation approaches. IBM SYSTEMS JOUR-NAL, 45(03).

[ElMansouri, 2009] ElMansouri, R. (2009). Modélisation et Véri�cationdes processus métiers dans les entreprises virtuelles : Une approche ba-sée sur la transformation de graphes. Thèse de doctorat, Université deMentouri, Constantine.

[Espinasse, 2009] Espinasse, B. (2009). Introduction àuml (uni�ed modeling language), adresse du docu-ment :http ://www.lsis.org/espinasseb/supports/mr-tc/introulmsept09-4p.pdf (accessed 2013).

[Fujaba, 2011] Fujaba (2011). http ://www.fujaba.de/.

[Gil, 2006] Gil, T. (21 janvier 2006). La conception orientée aspect. ValtechTraining.

[Great, 2011] Great (2011). http ://-repo.isis.vanderbilt.edu/tools/get.toolgreat.

[Hamrouche, 2010] Hamrouche, H. (2010). Une approche de transforma-tion des diagrammes d'activité d'uml vers csp basée sur la transformationde graphes. Mémoire de D.E.A., Ecole Doctorale en Informatique de l'Est.

100

[Kadima, 2005] Kadima, H. (2005). Mda, une conception orientée objetguide par les modèles. DUNOD.

[Karsai et Agrawal, 2004] Karsai, G. etAgrawal, A. (2004). Graph trans-formations in omg's model-driven architecture. Lecture Notes in ComputerScience, Springer Berlin, Heidelberg, 3062:243�259.

[Kerkouche, 2011] Kerkouche, E. (2011). Modélisation Multi-Paradigme :Une Approche Basée sur la Transformation de Graphes. Thèse de doctorat,Université de Mentouri, Constantine.

[Lara et Vangheluwe, ] Lara, J. D. et Vangheluwe, H. Using meta-modelling and graph grammars to process gpss models. In 16th EuropeanSimulation Multi-conference (ESM).

[Larman, 2005] Larman, C. (2005). UML 2 et les design patterns.Analyseet conception orientées objet et développment itératif, page 655.

[Machta et al., 2010] Machta, N., Bennani, M. T. etAhmed, S. B. (2010).Modélisation orientée aspects des systèmes temps réel. 8th InternationalConference of Modelisation and Simulation.MOSIM 10.

[Maria, 1997] Maria, A. (1997). Introduction to modelling and simulation,.pages 7�13.

[OMG, 2004] OMG, O. M. G. (2004). Model driven architecture (mda).URL http ://www.omg.org/mda.

[OMG, 2003] OMG, O. M. G. (copyright 2003). Mda guide version 1.0.1.

[OMG03b, 2003] OMG03b, O. M. G. (2003). Mda guide version 1.0.1 ?

[Ossher et Tarr, 2000] Ossher, H. et Tarr, P. (2000). Multi-dimensionalseparation of concerns and the hyperspace approach. In Proceedings of theSymposium on Software Architectures and Component Technology : TheState of the Art in Software Development. Kluwer,.

[POA, 2014] POA (2014). http ://fr.wikipedia.org/wiki/programmation-orientee-aspect.impl.c3.a9mentation.

[Prakash et al., 2006] Prakash, N., Srivastava, S. et Sabharwal, S.(2006). The classi�cation framework for model transformation. ComputerScience 2 (2), 2(2):166�170.

[Python, 2010] Python (2010). Python home page.htpp ://www.python.org.

[Rozenberg, 1999] Rozenberg, G. (1999). Handbook of graph grammarsand computing by graph transformation. World Scienti�c, 1.

[Subotic et al., 2006] Subotic, S., Bishop, J. et Gruner, S. (2006).Aspect-oriented programming for a distributed framework.

101

[VIATRA, 2010] VIATRA (2010). Visual automated transfor-mations for formal veri�cation and validation of uml mo-dels. URL :http ://dev.eclipse.org/viewcvs/indextech.cgi/gmt-home/subprojects/VIATRA2/index.html.

[Whittle et al., ] Whittle, J., Jayaraman, P., Elkhodary, A., Mo-reira, A. et Araújo, J. Mata : a uni�ed approach for composing umlaspect models based on graph transformation.

[Xavier et al., 2006] Xavier, B., Isabelle, M. et b Cédric (28 Septem-ber,2006). Uml 2 pour les développeurs. cours avec exercices corrigés.Eyrolles, Paris.

[Zhang et Holzl, ] Zhang, G. et Holzl, M. Hila : high-level aspects for umlstate machines.

102

103