L’analyse Des Agents Mobiles - univ- · PDF fileProfesseur Seridi Hamid et le Professeur Kazar Okba, davoir accepté de juger mon travail. Je ne remercierais jamais assez, mon mari

République Algérienne Démocratique et Populaire

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

Université Mentouri Constantine

Faculté Des Sciences de l’Ingénieur

Département d’Informatique

N°: .............................

Série: ..........................

Thèse de Doctorat en Sciences en Informatique

Thème :

Un Cadre Formel pour La Modélisation et

L’analyse Des Agents Mobiles

Présentée par : Mme DEHIMI NARDJESS TISSILIA

Composition du Jury

Pr. MohamedKhirddine Kholladi Université El wed Président

Pr. Chaoui Allaoua Université Constantine2 Rapporteur

Pr. Mohamed Benmohammed

Pr. Hamid Seridi

Pr. Okba Kazar

Université Constantine2

Université de Guelma

Université de Biskra

Examinateur

Examinateur

Examinateur

Dédicaces

À tous ceux que j’aime

et à ceux qui m’aiment.

Remerciements

J‟adresse toute ma gratitude et mes remerciements au Pr Allaoua Chaoui

professeur à l‟université Mentouri Constantine qui a dirigé ce travail avec

compétence et professionnalisme. Je le remercie pour sa patience, sa tolérance

et ses qualités humaines durant ces années de thèse.

Je tiens à remercier chaleureusement, le Pr Kholladi Mohamed

Khireddine de m‟avoir fait l‟honneur d‟accepter de présider mon jury de

thèse.

Je remercie vivement, le Professeur Benmohammed Mohamed, le

Professeur Seridi Hamid et le Professeur Kazar Okba, d‟avoir accepté de juger

mon travail.

Je ne remercierais jamais assez, mon mari Abdelhakim, pour son

abnégation et sa patience, pour son aide et son soutien sur tous les plans.

Un grand merci à toute ma famille grands et petits (mes chères parents

mes beaux-parents, mes adorables quatre enfants, mes frères et sœurs et tous

les autres), pour leurs amour et encouragements.

Sans oublier de remercier tous mes collègues et amis (ies), qui n‟ont pas

manqué de me soutenir durant toutes ses années de thèse, et en particulier ma

chère Fatima Boussela, pour sa présence et son dévouement.

Résumé

L‟émergence des réseaux informatiques à grande échelle a donné naissance à de

nombreuses applications réparties. Ces applications exigent une forte interaction entre

différentes entités distribuées sur le réseau et qui partagent les mêmes ressources et les

mêmes buts. Plusieurs modèles d‟exécution distribués pour ces applications ont été

proposés dans la littérature. Parmi lesquels, le modèle d‟agent mobile trouve bien sa

place en proposant une solution facilitant le développement des applications réparties.

En effet, Un agent mobile est une entité autonome, capable d‟interagir avec son

environnement ainsi que sur soi-même, en se déplaçant d'un site du réseau à un autre

pour atteindre ses objectifs.

Il s‟avère donc que la technologie de la mobilité du code est l'un des domaines de

recherche les plus attrayants. Cependant, le manque de langages de modélisation de la

mobilité du code et les insuffisances formelles des approches existantes, incite à

suggérer de nouveaux formalismes. Dans ce contexte, nous présentons les Réseaux

Reconfigurables étiquetés (Labeled Reconfigurables Nets, LRN). Nous proposons une

approche et un outil de transformation automatique de modèles LRN à leurs

spécifications équivalentes en R-Maude. Cette transformation vise à rendre possible la

vérification des propriétés des systèmes modélisés en utilisant les LRN puisque ce

nouveau formalisme n'a pas d'outils pour l'analyse et la vérification. Notre approche est

basée sur l'utilisation combinée de la méta-modélisation et des grammaires de

graphe. Dans notre travail, le formalisme de diagramme de classe UML de l‟outil

ATOM3 est utilisé pour définir un métamodèle pour les LRN. ATOM3 est aussi utilisé

pour générer un outil de modélisation visuelle pour l‟élaboration de modèles selon le

métamodèle des LRN proposé. Nous avons aussi proposé une grammaire de graphe

pour générer automatiquement, la description R-Maude des modèles LRN

graphiquement spécifiés. Ensuite, la logique de réécriture R-Maude est utilisée pour

effectuer la simulation de la spécification générée.

Mots clés : Agent Mobile, Labeled Reconfigurable Nets, MDA, Grammaires de

Graphe, R-Maude, outil ATOM3.

Abstract

The emergence of large-scale computer networks has given rise to many

distributed applications. These applications require a close interaction between different

entities distributed over the network and share the same resources and the same goals.

Several models for distributed execution of these applications have been proposed in the

literature. Among them, the model of mobile agent offers a solution that facilitates the

development of distributed applications. Indeed, a mobile agent is an autonomous entity

able to react on its environment and on it self, by moving from one network site to

another to reach its objectives.

It appears clearly, that the technology of code mobility is one of the most

attractive areas of research. However, the poorness of modeling languages to deal with

code mobility at requirement phase has incited the researchers to suggest new

formalisms. Among these, we find Labeled Reconfigurable Net (LRN). We propose an

approach and a tool for automatic transformation of LRN models to their equivalent

R-Maude specifications. This transformation aims to make it possible to verify

properties of systems modeled using the LRN, as this new formalism has no tools for

analysis and verification. Our approach is based on the combined use of meta-modeling

and graph grammars. In our work, the formalism of UML class diagram tool ATOM3 is

used to define a meta-model for the LRN. ATOM3 is also used to generate a visual

modeling tool for developing models according to the proposed metamodel of LRN. We

have also proposed a graph grammar to automatically generate the R-Maude description

for the LRN models, graphically specified. Then, the rewriting logic R-Maude is used to

perform the simulation of the generated specification.

Keywords: Mobile Agent, Labeled Reconfigurable Nets, MDA, Graph

Grammars, R-Maude, ATOM3 tool.

ملخص

نظرا لظهور شبكات الحاسوب على نطاق واسع ظهرت العديد من التطبيقات الموزعة.

التطبيقات تتطلب تفاعل وثيق بين مختلف الكيانات الموزعة على الشبكة و التي تتقاسم نفس هذه

. من ماذج لتوزيع تنفيذ هذه التطبيقاتالموارد و تشترك في نفس األهداف. وقد اقترحت عدة ن

المحمول من خالل تقديمه للحلول التي تسهل تطوير التطبيقات الموزعة. العميلبينها، نموذج

المحمول هو كيان مستقل قادر على التفاعل مع بيئته وكذلك مع نفسه، وذلك باالنتقال من العميل

شبكة ألخرى لتحقيق أهدافه.

المحمول تصادفها مشاكل أمنية و توافقية في مختلف قواعد العميللكن تقدم تطبيقات

أدى بالباحثين إلى استكشاف نماذج أخرى لغات النماذج لوصف خاصية التنقل،اإلستقبال ، قلة

أداة للتحول و LRNتطبيقات. نقترح في هذه األطروحة شكلية جديدة هذه الألجل دعم تحقيق

. هذا التحول يهدف الى جعل من الممكن Maude -Rإلى مواصفاتها المعادلة LRNالتلقائي للنماذج

ية جديدة ال يوجد لها األدوات الالزمة ألن هذه الشكل LRNالتحقق من خصائص النظم باستخدام

ستند على االستخدام المشترك للنماذج الفوقية ولقواعد الرسم البياني. في نللتحليل والتحقق. و

. كما يستخدم metamodel -LRNلتحديد ATOM3من أداة UMLعملنا، يتم استخدام مخطط

ATOM3 لتوليد أداة العرض المرئي لوضع نماذج وفقا لmetamodel المقترح لLRN .

LRNالمعادلة للنماذج Maude -Rاقترحنا أيضا قاعدة الرسم البياني للتوليد التلقائي لمواصفات

ألداء المحاكاة للمواصفات المنجزة. Maude -Rالمقترحة. ثم، يتم استخدام منطق إعادة كتابة

، أداة Maude –R، قواعد الرسم البياني، LRN ، MDA: وكيل محمول، الكلمات المفتاحية

ATOM3.

1

Table des matières

Introduction générale ............................................................................................................... 7

Chapitre 1: Agents mobiles et applications réparties…..……………………………….... 11

1.1 Systèmes répartis et Agents mobiles .................................................................................. 11

1.1.1 Structures organisationnelles non mobiles pour les systèmes répartis ..................................... 11

1.1.1.1. Client/serveur ................................................................................................................... 11

1.1.1.2 Événement asynchrone ...................................................................................................... 12

1.1.1.3 Mémoire virtuelle partagée (MVP) ................................................................................... 12

1.1.2. Structures organisationnelles avec mobilité pour les systèmes répartis .................................. 13

1.1.2.1. La mobilité ....................................................................................................................... 13

1.1.2.2. Structures organisationnelles ............................................................................................ 14

1.2. Agents mobiles .................................................................................................................. 15

1.2.1 Définitions ................................................................................................................................ 15

1.2.2 Environnement d'exécution et système d'agents mobiles ......................................................... 16

1.2.3 Services requis pour l'exécution d'agents mobiles.................................................................... 18

1.2.3.1 Structure d'un agent mobile ............................................................................................... 18

1.2.3.2 Création d'agents mobiles .................................................................................................. 18

1.2.3.3 Migration d'un agent .......................................................................................................... 19

1.2.3.4 Service de nommage.......................................................................................................... 20

1.2.3.5 Service de localisation ....................................................................................................... 20

1.2.3.6 Communications entre les agents ...................................................................................... 20

1.2.3.7 Exécution d'un agent ......................................................................................................... 21

1.2.3.8 Sécurité .............................................................................................................................. 22

1.2.3.9 Cycle de vie et contrôle de l'agent ..................................................................................... 23

1.2.4. Domaine d‟application des agents mobiles ............................................................................. 24

1.2.5 Exemples de plateformes existantes ......................................................................................... 25

1.2.6. Avantages et inconvénients du paradigme agents mobiles ..................................................... 26

1.3. Conclusion ......................................................................................................................... 27

2

Chapitre 2: Approche MDA et Transformation de Modèles.…………………………..... 28

2.1 Principe ............................................................................................................................... 28

2.2 Définition des concepts fondamentaux .............................................................................. 29

2.2.1 Modèle ...................................................................................................................................... 29

2.2.2 Métamodèle .............................................................................................................................. 29

2.2.3 Métamétamodèle ...................................................................................................................... 29

2.3 L‟approche MDA ............................................................................................................... 30

2.3.1 Les modèles dans l‟Architecture MDA .................................................................................... 31

2.3.2 Principe de transformation ....................................................................................................... 32

2.3.3 Passage entre modèles .............................................................................................................. 33

2.3.4 Types de transformations de modèles ...................................................................................... 34

2.3.5. Classification des approches de transformation de modèles ................................................... 34

2. 3.5.1 Transformations de type Modèle vers code ...................................................................... 35

2.3.5.2. Transformations de type modèle vers modèle .................................................................. 35

2.4. Transformation de graphes ................................................................................................ 38

2.4.1. Concept de graphe ................................................................................................................... 38

2.4.2. Transformation de graphes ...................................................................................................... 40

2.4.2.1 Grammaires de graphes ..................................................................................................... 41

2.4.2.2. Le principe de règles ........................................................................................................ 41

2.4.2.3. Application des règles ...................................................................................................... 42

2.4.2.4 Système de transformation de graphe ................................................................................ 42

2.4.2.5 Langage engendré ............................................................................................................. 43

2.5. AToM3: Un outil de Modélisation Multi-paradigme ....................................................... 43

2.5.1. Présentation de l‟outil AToM3 ................................................................................................. 43

2.5.2. La Méta-modélisation avec AToM3 ........................................................................................ 44

2.5.3 La Transformation de Modèles. ............................................................................................... 46

2.6. Conclusion ......................................................................................................................... 48

Chapitre 3: Modélisation Formelle et Mobilité…………………………………...………. 49

3.1. But de la modélisation ....................................................................................................... 50

3.2. Différentes Formes de Modélisation ................................................................................ 51

3.3. Techniques d‟analyse ........................................................................................................ 52

3.4. Méthodes Formelles .......................................................................................................... 53

3.4.1. Les langages formels ............................................................................................................... 53

3

3.4.2. Les mythes autour des méthodes formelles ............................................................................. 54

3.4.3. Classification des Méthodes Formelles ................................................................................... 54

3.4.4. Techniques de vérification formelle ........................................................................................ 56

3.4.4.1. Vérification de modèles (Model-Checking) ..................................................................... 56

3.4.4.2. Preuve de théorèmes (Theorem proving) ......................................................................... 56

3.5 Combinaison d‟IDM avec les Méthodes Formelles .......................................................... 56

3.6. Réseaux de Petri ................................................................................................................ 58

3.6.1. Introduction ............................................................................................................................. 58

3.6.2 Concepts de base & définition .................................................................................................. 60

3.6.2.1 Définitions informelles ...................................................................................................... 60

3.6.2.2 Définitions formelles ......................................................................................................... 61

3.6.3 Modélisation des systèmes complexes ..................................................................................... 65

3.6.3.1 Parallélisme ....................................................................................................................... 65

3.6.3.2 Synchronisation ................................................................................................................. 66

3.6.3.3. Partage de ressources ....................................................................................................... 67

3.6.4 Méthodes d'analyse pour les réseaux de Petri .......................................................................... 67

3.6.4.1Analyse par graphes des marquages ................................................................................... 67

3.6.4.2 L‟équation de matrice ........................................................................................................ 68

3.6.4.3 La réduction des RdPs ....................................................................................................... 68

3.6.5 Extensions des réseaux de Petri ................................................................................................ 69

3.6.5.1. Les réseaux de Petri colorés ............................................................................................. 69

3.6.5.2 Les réseaux de Petri synchronisés (RdPS) ....................................................................... 69

3.6.5.3. Les réseaux de Petri temporisés ....................................................................................... 70

3.6.6. Modélisation des systèmes mobiles par les RdPs ................................................................... 70

3.6.6.1. Le paradigme (nets-within-nets) ...................................................................................... 70

3.6.6.2. Le paradigme (Nested Nets) ............................................................................................. 72

3.7. Conclusion ........................................................................................................................ 72

Chapitre 4:Une Plateforme Formelle pour la Modélisation et la Simulation desLRN.. 73

4.1 Réseaux reconfigurables étiquetés (Labeled Reconfigurable Nets LRN) ......................... 74

4.1.1 Définition.................................................................................................................................. 74

4.1.2 Exemples de modélisation des paradigmes de la mobilité avec les LRN ................................ 75

4.1.2.1 L'évaluation à distance ...................................................................................................... 75

4.1.2.2 Code à la demande............................................................................................................. 76

4

4.1.2.3. Mobile Agent ................................................................................................................... 77

4.2 Le système Maude .............................................................................................................. 78

4.2.1 Modules Maude ........................................................................................................................ 79

4.2.2 Syntaxe de Maude .................................................................................................................... 80

4.3 Reconfigurable Maude ...................................................................................................... 82

4.4 Meta-modélisation des LRN (réseaux reconfigurables étiquetés) .................................... 83

4.5 La grammaire de graphe qui génère la spécification R-Maude des modèles LRN…….. 84

4.6 Exemples ........................................................................................................................... 91

4.7 Prototypage R-Maude ....................................................................................................... 95

4.8 Conclusion ......................................................................................................................... 97

Conclusion générale et perspectives ..................................................................................... 98

Références Bibliographiques ............................................................................................... 100

5

Liste des figures

Figure 1.1. Organisation Client/serveur .................................................................................. 12

Figure 1.2. Evaluation à distance ............................................................................................. 14

Figure 1.3. Code à la demande ................................................................................................. 14

Figure 1.4. Agent mobile .......................................................................................................... 15

Figure 1.5. Place et Région ...................................................................................................... 17

Figure 1.6. Migration d‟un agent mobile ................................................................................. 19

Figure 2.1. Pyramide de la modélisation OMG ....................................................................... 30

Figure 2.2. Principe de la construction d‟un système à base de modèles dans le MDA .......... 31

Figure 2.3. Processus de transformation de modèles pilotée par les métamodèles .................. 32

Figure 2.4. Transformations de modèles MDA ........................................................................ 33

Figure 2.5. Exemple typique d‟une transformation de modèle vers modèle ........................... 36

Figure 2.6. Graphe non orienté ................................................................................................. 39

Figure 2.7. Graphe orienté simple ............................................................................................ 39

Figure 2.8. Graphe orienté étiqueté .......................................................................................... 39

Figure 2.9. G‟ est un sous graphe de G .................................................................................... 40

Figure 2.10. Une grammaire déterministe de graphes.............................................................. 41

Figure 2.11. Système de réécriture de graphes ......................................................................... 42

Figure 2.12. Récriture pour la grammaire de la figure 2.10 ..................................................... 43

Figure 2.13. Présentation AToM3 ............................................................................................ 44

Figure 2.14. Méta-Modèle des automates à états finis ............................................................. 45

Figure 2.15. Editeur graphique généré pour les automates à états finis ................................... 46

Figure 2.16. Grammaire de Graphe: élimination de l‟indéterminisme .................................... 47

Figure 2.17. Application de la Grammaire ............................................................................... 48

Figure 3.1. Classification et Utilisation de Langages ou de Méthodes [José] ......................... 51

Figure 3.2. La classification des méthodes formelles .............................................................. 55

Figure 3.3. Les MFs & IDM .................................................................................................... 57

Figure 3.4. Méthode générale de modélisation et d‟analyse basée sur les réseaux de Petri. ... 59

Figure 3.5. Un réseau de Petri comportant 7 places, ................................................................ 60

Figure 3.6. Un réseau de Petri marqué avec un vecteurde marquage ...................................... 61

Figure 3.7. Evolution d‟états d'un réseau de Petri [Claud01] ................................................... 63

Figure 3.8. Un réseau de Petri marqué ..................................................................................... 64

Figure 3.9. Matrice d‟incidence et vecteur de marquage du RdP de la figure 3.8. .................. 65

Figure 3.10. Structure du parallélisme ..................................................................................... 65

6

Figure 3.11. Synchronisation mutuelle .................................................................................... 66

Figure 3.12. Synchronisation par sémaphore ........................................................................... 66

Figure 3.13. Synchronisation par Partage de ressources .......................................................... 67

Figure 3.14. (a) Réseau de Petri (b) Graphe des marquages fini.............................................. 68

Figure 3.15. (a) Réseau de Petri (b) Graphe des marquages infini .......................................... 68

Figure 3.16. RdP (gauche) et RdP coloré (droite) [Scor06] ..................................................... 69

Figure 3.17. Un exemple d'un RdP Nets-within-Nets [Kohler07] .......................................... 71

Figure 3.18. Un exemple d'un RdP Nets-within-Nets après franchissement. .......................... 71

Tableau 3.1. Les types de mobilité. .......................................................................................... 72

Figure 3.19. Nested Nets [Kees06] .......................................................................................... 72

Figure 4.1. Modèle -REV- avant et après le franchissement de rt. .......................................... 76

Figure 4.2. Modèle -COD- avant et après le franchissement de rt. .......................................... 77

Figure 4.3. Modèle -MA- avant et après le franchissement de rt. ............................................ 78

Figure 4.4. Le module fonctionnel PEANO-NAT ................................................................... 80

Figure 4.5. Petri-machine ......................................................................................................... 81

Figure 4.6 Le module système Petri-machine ......................................................................... 81

Figure 4.7 Déclaration d‟une classe sous la forme d‟un module système .............................. 82

Figure 4.8 Méta-Modèle des LRN .......................................................................................... 83

Figure 4.9 barre d‟outils pour l‟environnement de modélisation des LRN ........................... 84

Figure 4.10 Les règles de la grammaire de graphes ................................................................ 85

Figure 4.11 Le modèle LRN de l‟exemple 1 ............................................................................ 91

Figure 4.12 Spécification Maude Générée pour exemple1, .................................................... 92


Figure 4.14 Spécification Maude Générée pour exemple2, .................................................... 94


Figure 4.16 Spécification Maude Générée pour l‟exemple 3 .................................................. 95

7

Introduction générale

L'évolution des réseaux à grande échelle a permis la naissance d'un grand nombre de

nouvelles applications qui se développent autour de ce type de réseau [Arcangeli02] :

commerce électronique, recherche d'information sur le web, plate-forme pour calcul reparti...

Ces applications sont formées d‟entités reparties, la communication et les échanges entre ces

entités est à la base de la bonne fonctionnalité du système en entier.

Le modèle client/serveur est l‟un des modèles les plus utilisé dans de tels systèmes.

Dans ce modèle, seul le client représente une application au sens propre du terme et le rôle du

serveur est de répondre aux demandes des clients. Le serveur construit ses réponses

indépendamment du client, ainsi une partie des données envoyées est inutile, augmentant

ainsi le trafic sur le réseau. De plus ce modèle exige une connexion permanente entre le client

et le serveur, ce qui n'est pas le cas des terminaux mobiles qui sont exposés à la perte de la

connexion. Le concept d'agent mobile apparait dans ce contexte comme une solution

facilitant la mise en œuvre d'applications dynamiquement adaptables, et il offre un cadre

générique pour le développement des applications reparties sur des réseaux de grande taille.

L'envoi du code sur le serveur permet d'adapter les services distants aux exigences du client et

de ne lui envoyer que les informations utiles, ce qui n‟est évidemment pas le cas pour Le

modèle client/serveur.

Un agent mobile [Arcangeli02] est une entité logicielle qui se déplace d'un site à un

autre en cours de l‟exécution pour accéder à des données ou à des ressources distantes. Le

déplacement de l‟agent, se fait avec son code son état d'exécution et ses propres données. En

outre, l'agent lui-même, peut décider d‟une manière autonome de migrer. De ce fait, la

mobilité est contrôlée par l'application et non par le système d'exécution. Le but du

déplacement est généralement d'accéder localement a des données ou à des ressources

initialement distantes, d'effectuer le traitement en local et de ne déplacer que les données

utiles.

Deux grandes normes de standardisation (FIPA [FIPA] et MASIF [MASIF]) et un

nombre important de plates-formes [MASIF], ont apparu pour les agents mobiles, malgré leur

récente introduction. Cependant, le développement des applications des agents mobiles,

rencontre des problèmes liés à l‟interopérabilité et à la sécurité dans les différentes

plateformes d‟accueil. Face aux insuffisances des efforts pour la standardisation de ces

8

plateformes, les chercheurs étaient contraints d‟explorer d‟autres paradigmes, pour une

meilleure prise en charge et mise en œuvre des applications à base d‟agents mobiles.

D'autre part, peu de travaux de recherches portent sur les méthodes et les outils pour l‟analyse

et la conception des systèmes d‟agents mobiles. Les prédominantes approches orientées agent

qui existent jusqu'à maintenant, sont celles qui cherchent à adapter les méthodologies

d'analyse et de conception orientées objets pour le développement des applications d‟agents

mobiles [Bahri09].

Concevoir une approche qui inspire ses notations de l'analyse et de la conception

orientée objet (en particulier du langage UML) et qui pourra être utilisée tout au long du

processus de développement des systèmes d‟agents mobiles, serait très intéressant. UML

possède plusieurs avantages, il est à la fois un support de communication, une norme, un

langage de modélisation objet. Il offre aussi une bonne commodité pour la modélisation et la

compréhension des modèles. Néanmoins, la sémantique semi-formelle d‟UML présente un

inconvénient majeur, vue l‟insuffisance de l‟outil pour la vérification de tels modèles. L‟idée

serait de pouvoir transformer de tels modèles semi-formels, vers des modèles exprimés dans

un langage formel ( tel que les réseaux de Petri) ou carrément vers un code équivalent où la

vérification est possible. Ce point de vue, coïncide avec la philosophie de l‟approche IDM

(Ingénierie dirigée par les Modèles).

L‟ingénierie dirigée par les modèles (IDM ou MDE : Model Driven Engineering) est le

domaine qui met à disposition des outils, concepts et langages pour créer et transformer des

modèles afin de mécaniser le processus que les ingénieurs suivent habituellement à la main.

L‟IDM se concentre sur une préoccupation plus abstraite que la programmation classique (on

y adopte un degré d‟abstraction plus élevé), ce qui permet d‟obtenir plusieurs améliorations

dans le développement de systèmes complexes. Grâce à l‟utilisation importante des modèles

(qui peuvent être exprimés dans des formalismes différents) et des transformations

automatiques entre les modèles, L‟IDM permet un développement souple et itératif, grâce aux

raffinements et enrichissements par transformations successives et automatiques entre les

modèles.

Dans notre étude, nous nous sommes intéressés à l‟utilisation des réseaux de Petri pour

modéliser et vérifier des agents mobiles. Une extension de ces réseaux, où la structure du

réseau peut changer au cours de son exécution a été proposée. Ainsi, dans ce nouveau

formalisme, le Labeled Reconfigurable Nets (LRN) [Kahloul07], les réseaux de Petri ont été

étendus via l‟utilisation des transitions reconfigurables étiquetées. Quand une transition


9

reconfigurable est tirée, la structure du réseau change. Le changement qui se produit dépend

de certaines informations (destination de la migration, le type de migration, les ressources

requises et leur type pour les processus ou des agents ... etc.). Cette information est présentée

dans une étiquette associée à la transition reconfigurable. Cette idée a été utilisée, pour

montrer comment certains concepts de base définis dans la mobilité peuvent être modélisés, à

savoir: les agents mobiles, l'évaluation à distance, et le code à la demande. Une technique de

modélisation et de simulation d'agents mobiles en utilisant les LRN ainsi qu‟une extension de

Maude ont été également proposées [Kahloul2-08]. Cette extension est appelée reconfigurable

Maude (R-Maude). Dans R-Maude, des règles spécifiques, appelées règles reconfigurables

(RR) sont introduites. Un prototype de R-Maude a été réalisé. L'idée était d'abord modéliser

des systèmes mobiles utilisant les LRN, puis de les traduire dans la spécification R-Maude, et

enfin simuler l'exécution de ces spécifications en utilisant le prototype réalisé.

Dans ce contexte, nous avons en outre proposé une approche totalement automatisée

basée sur la méta-modélisation et les grammaires de graphes pour générer de manière

totalement automatique la spécification R-Maude des modèles réseaux de Petri

reconfigurables proposés en utilisant l‟outil AToM3. En effet, dans notre travail, le

formalisme de diagramme de classe UML de l‟outil ATOM3 est utilisé pour définir un

métamodèle pour les LRN. ATOM3 est aussi utilisé pour générer un outil de modélisation

visuelle pour l‟élaboration de modèles selon le métamodèle des LRN proposé. Nous avons

aussi proposé une grammaire de graphe pour générer automatiquement, la description

R-Maude des modèles LRN graphiquement spécifiés.

Organisation du mémoire

Le reste de ce mémoire est organisé comme suit :

Dans Le premier chapitre de cette thèse, nous avons présenté les différentes

technologies utilisées pour la répartition et la communication entre les différentes entités

d'une application repartie. Nous avons situé la technologie d'agents mobiles par rapport aux

différentes techniques présentées. Nous avons enchainé ensuite avec quelques exemples de

plateformes d'implémentation des applications d'agents mobiles. Avec la multitude de plates-

formes d'exécution, des efforts dans le domaine de la standardisation ont été déployés. Ce

chapitre a été conclu avec des critiques du paradigme.

Dans le deuxième chapitre nous avons commencé par présenter sommairement

l‟Ingénierie Dirigée par les Modèles (IDM), suivie par la présentation de sa variante : Model-


10

Driven Architecture (MDA). Nous avons insisté plus particulièrement sur la transformation de

modèles, l‟une des techniques prometteuses dans l'approche MDA. Cette approche permet

l'automatisation des processus de modélisation, depuis les phases de développement jusqu‟à

celles de tests, en passant par la génération de code. Nous avons présenté par la suite une

énumération de quelques types de transformation de modèles, suivie d‟une classification de

certaines approches de transformation. Sur un autre plan, nous avons mis l‟accent sur les

transformations de graphes qui représentent une des approches de transformation de modèles

et ce après avoir fait un bref aperçu sur la notion de graphe. Enfin, nous avons présenté

AToM3, l‟outil de transformation utilisé dans notre travail, d‟une façon assez exhaustive, car

nous jugeons importants les éléments présentés dans ce cadre pour la compréhension de notre

contribution.

Le chapitre 3, a été consacré à la présentation des concepts fondamentaux des

techniques formelles, de vérification et validation des systèmes. Nous avons insisté sur les

réseaux de Petri, qui sont un formalisme de modélisation. Ils représentent un cadre formel de

spécification des systèmes grâce à leur sémantique. Un grand avantage de l‟utilisation des

réseaux de Petri est leur force d‟expressivité due à leur aspect graphique. Nous avons abordé

dans un cadre général la modélisation par les réseaux de Petri. Par la suite, nous avons étudié

quelques types de RdPs avec leurs variantes. Nous avons également introduit une brève

présentation des extensions de RdPs pour la mobilité.

Dans le quatrième chapitre, nous avons présenté un nouveau formalisme, basé sur les

réseaux de petri, « les Labeled Reconfigurables Nets (LRN) ». Ce formalisme permet une

modélisation explicite des environnements informatiques et d‟exprimer la mobilité entre eux.

Nous avons décrit par la suite, notre support outillé de manipulation et de simulation des LRN

basé sur la méta-modélisation et les grammaires de graphes. Nous avons enchainé par la

présentation d‟une extension pour Maude: reconfigurable Maude (R-Maude). R-Maude est un

système distribué qui peut être utilisé pour la spécification et la simulation des systèmes à

code mobile. Un prototype de ce système a été réalisé et utilisé pour simuler les spécifications

des modèles LRN. Un exemple des étapes de simulation a été également présenté.

Enfin, une conclusion générale résume notre contribution et présente des perspectives

de notre travail.

11

Chapitre1

Agents mobiles et applications réparties

L‟émergence des réseaux informatiques à grande échelle a donné naissance à de

nombreuses applications réparties. Ces applications exigent une forte interaction entre

différentes entités distribuées dans le réseau, celles-ci partagent les mêmes ressources et

visent à atteindre les mêmes buts. Ces applications réparties adoptent une multitude de

modèles d‟exécution distribués, proposés dans la littérature.

Nous commençons, dans ce chapitre, par présenter brièvement les caractéristiques de

quelques modèles d‟exécution distribuée utilisés pour la mise en œuvre d‟une application

répartie. Nous insisterons sur la description du modèle d‟agent mobile, qui propose une

solution facilitant le développement des applications réparties sur des réseaux à grande

échelle. Cette description permet d‟appréhender la complexité de ce domaine qui est exprimée

par la variété des aspects à considérer dans un tel système.

1.1 Systèmes répartis et Agents mobiles

Dans le développement des applications distribuées, La programmation par agents

mobiles a bien trouvé sa place comme nouveau paradigme. Cependant, pour la construction et

la gestion des systèmes répartis, il existe d‟autres structures organisationnelles, qui peuvent

être classées en deux catégories. L‟une concerne les structures d‟organisation sans mobilité, et

l‟autre comporte les structures d‟organisation avec mobilité.

1.1.1 Structures organisationnelles non mobiles pour les systèmes répartis

Dans la conception d‟une application répartie classique, qui ne nécessite pas la

mobilité, interviennent plusieurs structures organisationnelles dont les plus répandues sont les

suivantes:

1.1.1.1. Client/serveur

Dans le modèle client/serveur, un serveur représente un objet géré sur un site et offrant

des services aux clients. Les fonctionnalités d'une application sont alors encapsulées dans des

services qui sont proposées/exécutées au sein de serveurs. Les serveurs sont ainsi vus comme

des fournisseurs de services. On trouve soit : (i) des serveurs de données, dans lesquels des

clients accèdent à des données localisés sur chaque serveur (SGBD, LDAP, etc...), (ii) soit des

serveurs de calculs, dans lesquels des clients utilisent les ressources de chaque serveur afin

d'exécuter une tache précise.


12

Dans le modèle client/serveur, seul le code initialement installé sur le serveur pourra

être exécuté sur ce dernier, et le rôle de celui-ci est de répondre aux demandes émises par les

processus clients. L‟interaction avec un serveur est établie par le client demandeur d'un

service. Nous pouvons envisager que l'exécution d'une tâche sur un serveur nécessite

l'interaction avec d'autres serveurs (telle que la consultation d'une base de données). Dans ce

cas un même processus peut être à la fois client et serveur. Dans le modèle client/serveur seul

le client représente une application au sens propre du terme. Le serveur a pour fonction de

répondre aux demandes des clients. Les réponses dépendent des requêtes formulées et non pas

des applications clientes qui l'interrogent.

Le client envoie une requête au serveur. Cette requête décrit l'opération à exécuter (le

service demandé) ainsi que ses paramètres. On dit alors que le client invoque une opération

sur le serveur. Le serveur exécute le service demandé par le client et renvoie la réponse. Il

s'agit d'une invocation synchrone, en effet dans ce type de communication le client qui émet

une requête vers le serveur se bloque, en attendant sa réponse (voir figure 1.1).

Figure 1.1. Organisation Client/serveur

1.1.1.2 Événement asynchrone

Ce modèle permet la communication entre plusieurs processus et ceci d'une façon

indirecte. Les différents composants de l'application coopèrent par l'envoi et la réception de

notification. Les processus communiquent entre eux par l'intermédiaire d'une base

représentant un gestionnaire d'abonnement et de distribution d'évènements.

Cette base se charge d‟orienter un évènement vers ses abonnés. Dans ce modèle, il y a

deux types de processus : les émetteurs qui envoient ou publient des évènements dans la base,

et les consommateurs qui s'abonnent à certaines catégories d'évènements. Quand la base reçoit

une notification d'évènement, elle se charge de la distribuer a tous les composants qui ont

déclaré leur intérêt pour recevoir ce message. Ainsi, cet intermédiaire fait un découplage entre

les sources et les consommateurs d'évènements. L'émetteur d'une communication n'est pas

obligé de spécifier la destination de ses messages, de même le destinataire ne connait pas

nécessairement l'origine du message. Ce type d'infrastructure [Leclercq04] qui permet de

communiquer à l'aide de messages est désigné par MOM (Message Oriented Middleware).

1.1.1.3 Mémoire virtuelle partagée (MVP)

Les échanges se font par l'intermédiaire d'une mémoire partagée de grande taille qui

sert d'espace de communication entre des processus sur des ordinateurs qui ne partagent pas

Client Serveur


13

physiquement leur mémoire. Son intérêt est de permettre l'utilisation d'un modèle de

programmation qui a des avantages par rapport aux modèles basés sur l'échange de message.

Les processus accèdent à la mémoire partagée par des lectures et des mises à jour sur ce qui

leur semble être de la mémoire ordinaire à l'intérieur de leur espace d'adressage. Le système,

tournant en tâche de fond, assure de manière transparente que les processus s'exécutant sur

différents ordinateurs observent les mises à jour effectuées par d'autres processus.

Le grand avantage de la MVP [Bennett90] est d'épargner au programmeur la gestion

de l'échange de messages quand il écrit une application qui en aurait besoin dans la MVP. On

ne peut toutefois pas éviter complètement l'échange de message dans un système distribue, il

faut bien sûr que le système sous-jacent de la MVP envoie les mises à jours aux différents

processeurs, chacun ayant une copie locale des données partagées [Guyennet97]. Ces données

doivent être mises à jour de façon régulière pour une question de performance mais aussi de

validité des données utilisées.

1.1.2. Structures organisationnelles avec mobilité pour les systèmes répartis

Les applications utilisant les réseaux comme infrastructures, particulièrement Internet,

ont connu une croissance remarquable rapidement. Les structures organisationnelles non

mobiles, tel que l‟approche client/serveur, se heurtent à de grands défis. Vue le caractère

centralisé de ces approches, l‟émergence des nouvelles tendances pour le partage du savoir et

des ressources disponibles sur le réseau planétaire, est énormément ralentit. De ce fait, le

concept de la mobilité est une bonne alternative des approches non mobile.

Dans ce qui suit, nous présentons quelques définitions et concepts de bases de la

mobilité, nous enchainerons avec quelques structures d‟organisation se basant sur la mobilité

pour les systèmes répartis.

1.1.2.1. La mobilité

La mobilité en général est le déplacement physique ou logiciel dans les réseaux de

télécommunication. De ce fait, trois concepts de base sont répandus, on cite: la mobilité

physique (Mobile computing), le code mobile et les agents mobiles.

La mobilité physique se définie comme étant un paradigme dans lequel les utilisateurs du

réseau partagé se connectent via des machines déplaçables [Gardarin93]. La diffusion des

réseaux sans fils, et les réseaux de télécommunication cellulaires, expliquent La motivation

de ce paradigme. Ces réseaux nécessitent de grandes capacités de calcul et de traitement de

l‟information.

La capacité dynamique d‟échange entre les fragments du code à exécuter et les locations

sur lesquels s‟exécutera ce code, définit le code mobile. Un équilibrage de charge entre les

processeurs connectés sur le réseau est assuré par la migration du code (processus, objet,

ou une procédure). Celle-ci permet également d‟améliorer les performances dans la

communication (rassembler les objets qui se communiquent intensivement sur les mêmes

nœuds).

Les agents mobiles sont des entités logicielles qui peuvent se déplacer d'un site du réseau

à un autre pour atteindre leurs objectifs et ce d‟une manière autonome.


14

1.1.2.2. Structures organisationnelles

Parmi les structures organisationnelles de la mobilité, nous présentons l‟évaluation à

distance, le code à la demande et le modèle à base d‟Agent Mobile.

1.1.2.2.1 Évaluation distante

Dans une interaction par évaluation distante (voir Figure 1.2), un client envoie un code

à un site distant. Le site récepteur utilise ses ressources pour exécuter le programme envoyé.

Eventuellement, une interaction additionnelle délivre ensuite les résultats au client. Dans ce

schéma, seul le code est transmis au serveur et l'exécution du code se déroule uniquement sur

ce dernier. Le code d'une requête SQL émis vers un serveur de base de données représente un

exemple d'évaluation distante.

Figure 1.2. Evaluation à distance

1.1.2.2.2 Code à la demande

Dans ce schéma, le processus client interagit avec un site distant afin de récupérer un

savoir-faire qui sera exécuté sur la machine cliente. Ainsi, le client télécharge le code

nécessaire à la réalisation d'un service. Le rôle du site distant est de fournir le code du service

qui sera exécuté sur le site client (voir Figure 1.3). Les Applets Java reposent sur cette

technologie de code mobile, il s'agit d'un programme chargé à partir d'une page Web pour être

exécuté sur la machine du client.

Figure 1. 3. Code à la demande


15

1.1.2.2.3 Agents mobiles

Par comparaison avec les deux schémas précédents, l'exécution du processus débute

sur le site client. Dans la mesure où le client a besoin d'interagir avec le serveur, ce même

processus (code, état d'exécution et données) se déplace à travers le réseau pour continuer son

exécution et pour interagir localement avec les ressources du serveur (voir Figure 1.4). Après

exécution, l'agent mobile retourne éventuellement vers son client afin de lui fournir les

résultats de son exécution. Dans ce schéma, le savoir-faire appartient au client, l'exécution du

code est initiée côté client et continue sur les différentes machines visitées.

Figure 1.4. Agent mobile

1.2. Agents mobiles

1.2.1 Définitions

Le terme agent est très répandu en informatique. La notion d'agent a donné lieu à de

très nombreuses définitions, notamment dans le domaine de l'intelligence artificielle.

Un agent [Beale94] est une entité logicielle (informatique ou électronique) plongée

dans un environnement dans lequel elle est capable d'agir. Il possède un comportement

autonome relié à ses observations, à sa connaissance et aux interactions qu'il entretient

avec l'environnement et avec les autres agents.

D‟après [Ferber95], un agent est une entité physique ou virtuelle qui est capable d‟agir

dans un environnement et qui peut communiquer directement avec d‟autres agents. Cette

entité est mue par un ensemble de tendances (sous la forme d‟objectifs individuels ou

d‟une fonction de satisfaction, voire de survie, qu‟elle cherche à optimiser). Afin

d‟atteindre ses objectifs, l‟agent tient compte des ressources et des compétences dont il

dispose, ainsi que de sa perception et des représentations qu‟il dispose de son

environnement.

Nous définissons un agent mobile comme étant un agent répondant à cette définition et

capable de se déplacer d'un site a un autre dans un réseau pour accomplir la tâche du client.

De cette définition découlent les points essentiels suivants liés à l‟agent:

Comportement : Un agent est pourvu d'un programme qui lui dicte la tâche à accomplir.

On dit qu'il agit par délégation pour le client. Un agent peut ainsi venir avec une

compétence particulière sur une machine hôte.


16

La Mobilité: Un agent mobile est capable de migrer d‟une machine vers une autre pour

atteindre ses objectifs.

La Communication: Les agents peuvent communiquer entre eux ainsi qu‟avec autrui.

Par échanges de messages ou selon un mode de communication établit par l‟architecture

dans laquelle évoluent les agents tels que les SMA (Systèmes Multi Agents).

L’Apprentissage: Un agent est capable d‟augmenter ses capacités par apprentissage en

utilisant ses connaissances.

la Réactivité et La Pro-Activité: un agent réactif est caractérisé par sa réaction aux

événements externes pour l‟exécution de nouvelles tâches. Par contre, un agent Pro-Actif

se caractérise par la capacité d‟anticiper des changements plutôt que de réagir à ces

changements.

Autonomie : Un agent agit indépendamment du client. Il décide lui-même là où il va se

déplacer et ce qu'il doit y faire, en fonction du comportement qui lui a été donné. Ceci

implique que l'on ne peut pas toujours prévoir l'itinéraire des agents.

Environnement : L'environnement dans laquelle l'agent évolue est constitué :

‒ par les machines qui vont accueillir l'agent lors de son exécution; ainsi l'agent utilise

les ressources (unité de calcul, mémoire, etc...) disponibles sur la machine afin

d'accomplir la tâche demandée par le client,

‒ Par les liens réseau que l'agent utilise pour se déplacer entre les différents sites.

‒ Par les autres agents fixes et mobiles avec qui l'agent interagit afin de réaliser son but.

1.2.2 Environnement d'exécution et système d'agents mobiles

Un environnement d'exécution d'agents mobiles fournit une interface de

programmation et un milieu d'exécution offrant des primitives pour créer, lancer et exécuter

un agent mobile. Cet environnement est constitué par un ensemble de programmes statiques,

appelés places, s'exécutant sur les sites du système susceptibles d'accueillir des agents.

Les environnements d'exécution d'agents mobiles offrent plusieurs services de base

permettant l'exécution d'un agent mobile sur un site. Ces services sont: création et migration

d'un agent mobile, communication et échange de messages entre les agents mobiles, accès aux

ressources locales par les agents mobiles et traçage des agents mobiles en cours de

l‟exécution. Viennent s‟ajouter à ces services, fournis par l'environnement d'exécution

d'agents mobiles, des mécanismes mettant en œuvre des notions de qualité de service requise

par les applications, à titre d‟exemple, la sécurité ou la tolérance aux pannes.

Un système d‟agent (appelé aussi serveur d‟agent) est l‟espace de vie des agents. Il est

associé à une autorité qui identifie l‟organisation ou la partie pour laquelle les agents agissent.

La diversité des systèmes ainsi développés, rend les passerelles entre de tels systèmes souvent

impossibles. Afin de permettre l‟interopérabilité entre les systèmes à agents mobiles, l‟OMG

(Object Management Groupe) a montré son intérêt pour cette classe d‟application par la

définition des spécifications de MASIF (Mobile Agent System Interoperability) [MASIF].


17

Par ailleurs, la FIPA (Foundation For Intelligent Physical Agents) [FIPA] a lancé un autre

effort pour la spécification de l‟architecture des systèmes d‟agents mobiles.

Cinq concepts jouent un rôle important dans le système d‟agent :

1. La place : Un agent mobile se déplace d‟un environnement d‟exécution à un autre. Cet

environnement est appelé " place ". Une place est un contexte au sein d‟un système

d‟agent, dans lequel un agent s‟exécute. Ce contexte peut fournir un ensemble de services

uniformes sur lesquels l‟agent peut compter indépendamment de sa localisation spécifique.

La place de départ et la place de destination peuvent être situées au sein d‟un même

système d‟agent ou sur des systèmes d‟agents différents. Un système d‟agent peut contenir

une ou plusieurs places (voir figure 1.3).

2. Région : Une région est un ensemble de systèmes d‟agent qui appartiennent à la même

autorité mais qui ne sont pas nécessairement de même type. Le concept de région permet

à une autorité d‟être représentée par plusieurs systèmes d‟agent (voir figure 1.3).

3. Les ressources : Le système d‟agent et la place fournissent un accès contrôlé aux

ressources locales et aux services (base de données, processeurs, mémoire, disques).

4. Le type d’un système d’agent : Le type d‟un système d‟agent permet de définir le

profil d‟un agent. Par exemple, si le type d‟un système d‟agent est " AGLET ", alors le

système d‟agent est implémenté par IBM et supporte Java comme langage de

programmation.

5. Localisation : La localisation est un concept important pour les agents mobiles. On

définit la localisation d‟un agent comme étant la combinaison de la place dans laquelle il

s‟exécute et l‟adresse réseau du système d‟agent où réside la place. Concrètement, elle est

définie par l‟adresse IP et le port d‟écoute du système d‟agent avec le nom de la place

comme attribut.

Figure 1.5. Place et Région


18

1.2.3 Services requis pour l'exécution d'agents mobiles

Dans cette section, nous allons décrire les fonctions nécessaires pour construire des

applications reparties à base d‟agents mobiles. Apres une présentation de la structure d'un

agent mobile, nous allons présenter les services suivants :

création d'un agent,

transfert d'un agent,

désignation d'un agent, c'est-à-dire offrir un nom globalement unique a un agent,

localisation d'un agent,

communication entre agents,

exécution d'un agent,

protection d'un agent.

Ces différents services sont détailles dans les paragraphes suivants.

1.2.3.1 Structure d'un agent mobile

Un agent mobile est un programme pouvant se comporter d'une façon autonome au

profit de son client. Chaque agent a son flot d'exécution pour pouvoir prendre l'initiative

d'exécuter des taches. Un agent doit avoir la capacité de migrer d'une machine à une autre sur

le réseau. Pour parler de la migration d'un agent, il est important de connaitre les éléments à

transférer avec l'agent. Une instance d'agent mobile comporte trois parties [Tanenbaum92] :

‒ Un code exécutable qui représente la suite d'instructions définissant le comportement

statique de l'agent mobile,

‒ Un contexte d'exécution qui reflète l'état d'exécution courant de l'agent mobile (valeurs

des registres, pile d'exécution),

‒ Les données ou les ressources utilisées par l'agent mobile ; ces ressources sont divisées

en deux parties [Fuggetta98] :

‒ Les ressources transférables qui sont les valeurs des attributs de l'agent et qui lui

donnent un état global,

‒ Les ressources non transférables qui constituent l'environnement d'exécution fourni

par le système (par exemple les fichiers ouverts, les connexions sockets, les registres,

etc.) et les matériels physiques utilises par l'agent (imprimante, écran, etc.).

Dans le paragraphe §2.3.3, nous allons montrer comment l'agent migre avec son code,

son contexte d'exécution et ses données.

1.2.3.2 Création d'agents mobiles

Dans la mesure où ces agents peuvent se déplacer, on peut se poser la question, lors de

leur création, de l'endroit où l'on souhaite qu'ils démarrent leurs activités. Une fois crée,

l'agent peut être actif, c'est-à-dire que l'exécution de son code est déclenchée. La

création/lancement d'un agent peut prendre plusieurs formes :

‒ Création locale,

‒ Création et exécution à la demande (code on demand),

‒ Création et exécution à distance (remote exécution).


19

La création de l'agent n'est pas directement liée à la mobilité, mais a des mécanismes

sur lesquels s'appuie la mobilité. A sa création, un nom globalement unique (cf. §2 .3.4) doit

être attribue à l'agent ce qui va permettre de localiser l'agent et de communiquer avec lui.

1.2.3.3 Migration d'un agent

La migration permet le transfert d'un agent en cours d'exécution d'un site à un autre à

travers le réseau. Nous allons prendre le cas d'un agent qui désire migrer entre deux machines

avec la possibilité de recevoir des messages pendant son déplacement (voir Figure 1.6). Cette

migration comporte les étapes suivantes [Ismail99] :

1. la sérialisation du contexte de l'agent et la production d'un message incluant le contexte

sérialise de l'agent et son code;

2. le processus de l'agent étant suspendu sur sa machine d'origine, toutes les

communications avec d'autres agents sont donc suspendues et l'agent est détruit;

3. l'envoi du contexte et du code de l'agent vers la machine de destination;

4. l'état de l'agent migrant est restaure sur la machine de destination, un nouveau processus

léger est créé pour la poursuite de son exécution;

5. les communications en cours sont redirigées vers la machine de destination, l'agent

n'étant pas encore active, ces messages seront traites après sa réactivation;

6. réactivation de l'agent sur la machine de destination, dès que la partie de son contexte

nécessaire à son exécution est reçue ; la machine de destination s'occupe des liens

dynamiques entre l'agent et son code. A partir de ce moment, la migration prend fin. Le

processus sur la machine d'origine peut être définitivement efface.

Figure 1.6. Migration d‟un agent mobile

Les différentes stratégies de migration d'agents dépendent de la manière dont sont

traitées ces diverses étapes et des données transférées avec l'agent lors de sa migration.

Deux types de migrations ont été proposés dans les plates-formes existantes :


20

1. La migration forte permet à un agent de se déplacer quel que soit l'état d'exécution

dans lequel il se trouve. Dans ce type de migration l'agent se déplace avec son code,

son contexte d'exécution et ses données. Dans ce cas, l'agent reprend son exécution

après la migration exactement là où elle était avant son déplacement. La migration forte

nécessite un mécanisme de capture instantanée de l'état d'exécution de l'agent. Elle peut

être proactive ou réactive. Dans la migration proactive, la destination de l'agent est

déterminée par l'agent lui-même. Dans la migration réactive, la migration de l'agent est

dictée par une partie ayant une relation avec l'agent mobile.

2. La migration faible ne fait que transférer avec l'agent son code et ses données. Sur le

site de destination, l'agent redémarre son exécution depuis le début en appelant la

méthode qui représente le point d'entrée de l'exécution de l'agent, et le contexte

d'exécution de l'agent est réinitialisé. Pour que l'agent se branche sur une instruction

particulière de son code après sa migration, le programmeur doit inclure dans l'état de

l'agent des moments privilégies (explicites) dans le code de l'agent (point d'arrêt) pour

pouvoir le relancer. La migration forte, bien que beaucoup plus exigeante à implanter

[Dillenseger02] que la migration faible [Grasshopper98], n'en est pas moins

indispensable pour toutes les applications pour lesquelles les notions de fiabilité et de

tolérance aux pannes sont primordiales.

1.2.3.4 Service de nommage

Dans un système à agents mobiles, les agents ont besoin de communiquer entre eux, ce

qui nécessite de les nommer. Le nom donne à l'agent doit être globalement unique. Dans la

plupart des systèmes à agents mobiles ce nom est construit à partir du nom de la machine (ou

adresse IP) ou l'agent s'exécute, d'un numéro de port et d'un identificateur localement unique.

1.2.3.5 Service de localisation

Afin de communiquer avec un agent mobile, il est nécessaire de le retrouver. La

mobilité de l'agent introduit des contraintes sur les communications qui n'étaient pas présentes

avec les systèmes classiques ou les objets ne pouvaient pas changer de lieu d'exécution. En

particulier, il faut que des entités mobiles puissent communiquer indépendamment de leur

localisation et de leur mobilité [Alouf02]. Le point le plus important concerne la fiabilité, il

faut pouvoir assurer les communications à tout moment avec les objets mobiles. Pour ces

raisons, un système à agents mobiles doit offrir un service de localisation des agents à travers

un serveur de noms. Ce serveur de noms contient la localisation courante de l'agent ou bien

suffisamment d'informations pour le localiser.

1.2.3.6 Communications entre les agents

La communication entre deux entités peut se faire de deux façons, la plus intuitive

consiste à avoir un mécanisme permettant une communication directe entre les objets, ce qui

correspond à la communication synchrone ou asynchrone entre les deux entités.


21

Une deuxième manière de la faire est d'avoir des mécanismes de communication indirecte.

Dans ce cas un objet voulant communiquer envoie son message à un objet tiers qui se charge

à son tour de l‟envoyer au destinataire.

Dans un système à agents mobiles, il faut différencier deux types de communication,

selon que la communication intervient entre deux agents ou entre un agent et un groupe

d'agents. Les moyens de communication entre les agents sont multiples, nous pouvons citer la

communication par message, session, tableau blanc, rendez-vous, par évènement distribué ou

local.

1.2.3.7 Exécution d'un agent

Un système à agents mobiles doit offrir la possibilité d'exécuter un agent sur les

machines qui vont accueillir ce dernier, ainsi l'agent utilise les ressources disponibles sur la

machine afin d'accomplir la tache demandée par le client. Sur la machine d'accueil, les agents

mobiles peuvent être amenés à effectuer des entrées/sorties, accéder à l'interface utilisateur, au

système de gestion de fichiers, aux applications externes et à l'interface réseau. Les machines

qui forment notre système d'exécution n'auront pas toutes le même type de système

d'exploitation. Par conséquent, maintenir l'indépendance vis-à-vis du système d'exploitation

d'un environnement d'agents mobiles tout en autorisant en même temps l'accès aux ressources

est un problème important à surmonter dans les environnements d'exécution d'agents mobiles.

C'est pour cette raison que la plupart des environnements d'agents mobiles utilisent le langage

Java comme langage d'implémentation du code mobile [Gomoluch01].

Java est un langage oriente objet développe par Sun et présente officiellement en 1995.

Les applications écrites en Java [Java] sont compilées en bytecode et exécutées sur une

machine virtuelle, la Java Virtuel Machine (JVM). Le succès du langage Java se traduit, entre

autre, par le fait qu'on peut raisonnablement considérer que la machine virtuelle Java constitue

aujourd'hui un environnement d'exécution "universel", car disponible sur toutes les machines

d'un système reparti. Cette propriété en fait une plateforme de développement de choix pour

les applications mobiles ou distribuées car le programmeur n'a pas à gérer différents langages

ou différentes versions d'un programme suivant les systèmes sur lequel il va s'exécuter. En

plus de cette propriété liée a la portabilité, Java propose toute une série de services qui

permettent de construire des applications distribuées mobiles. On trouve notamment :

- la sérialisation/de sérialisation d'un objet afin de le transmettre à travers le réseau.

- la communication entre deux objets situés sur des machines distantes (RMI, socket,

etc...)

- le chargement dynamique de code à partir d'un site distant.

L'utilisation de Java permet de résoudre le problème lie à l'exécution de l'agent sur les

différentes machines du système repartie. Mais avec la diversité des plates-formes

disponibles, nous pouvons nous interroger sur la migration entre les différentes plates-formes.

Chaque plate-forme possède sa propre façon pour définir le comportement des agents, ce

qui pose un problème de compatibilité lors de la migration d'un agent entre les différentes


22

plates-formes. Pour surmonter ce problème, des travaux comme dans [Groot04] proposent un

langage générique, pour la description du comportement de l'agent, base sur le langage XML.

Une projection de cette description permet à une plate-forme d'agents mobiles de reconstruire

l'agent avec son propre langage.

L'exécution d'un agent mobile sur une machine hôte pose le problème du piratage des

sites visites. Ce problème, non spécifique aux agents mobiles, est symétrique pour ces

derniers. En effet, un agent mobile est expose au problème du piratage par les logiciels qui

fonctionnent sur les sites qu'il visite. Dans la section suivante, nous allons détailler les

problèmes liés à la sécurité dans un environnement d'agents mobiles.

1.2.3.8 Sécurité

Garantir la sécurité dans les environnements d'agents mobiles est important du fait de

la nature même du modèle d'exécution des agents et du fait des interactions des agents

mobiles avec plusieurs systèmes et ressources. Un système à agents mobiles doit offrir des

mécanismes permettant une exécution sécurisée des agents au sein du système. Trois types de

problèmes de sécurité ont été identifiés pour les environnements d'exécution d'agents mobiles:

‒ La sécurité du site d'accueil contre un agent. Au cours de son exécution, un agent

mobile peut avoir accès aux ressources du site sur lequel il est situé. Un agent malveillant

peut donc profiter des accès aux ressources locales pour propager des virus [Chess97], des

worms ou des chevaux de Troie. Il peut masquer sa véritable identité et lancer une tâche

lourde ce qui va entrainer l‟indisponibilité du service [Bellavista01]. La machine qui va

accueillir l'agent mobile doit être amenée à détecter le mauvais déroulement de l'exécution

de l'agent. Dans [Galtier01], les auteurs présentent une méthode qui permet à l'agent de

définir ses besoins d'une façon indépendante de la machine sur lequel il s'exécute. Le site

d'accueil peut détecter les abus commis par l'agent permettant ainsi de le contrôler. Une

approche classique pour protéger les sites des agents malveillants est de limiter les accès

des agents aux ressources locales du site [Hantz06]. Dans cette approche, le comportement

de l'agent est écrit sous la forme d'un langage interprété. L'agent est exécuté dans un

environnement qui a son tour s'exécute au-dessus du site. Le contrôle de l'agent est ainsi

fait dans l'environnement d'exécution [Carvalho04]. Une seconde approche consiste à ne

laisser s'exécuter que les agents authentifies [Ametller04], une signature est attribuée à

l'agent permettant au site d'accueil de l'authentifier avant son exécution.

‒ La sécurité d'un agent contre le site d'accueil. La protection des agents mobiles contre

des sites hostiles est spécifique au domaine. Les agents sont à protéger à deux niveaux : la

protection du code de l'agent (changement du comportement) et la modification de l'état de

l'agent. Plusieurs approches ont été proposées: l'approche organisationnelle permet,

seulement aux sites dignes de confiance, de gérer des systèmes d'agents mobiles;

l'approche de détection de manipulation offre des mécanismes fondés sur le traçage

permettant de détecter les manipulations de données effectuées sur un agent [Diaz01];

enfin l'approche de protection par boite noire. La cryptographie mobile est une étape vers

l'approche de protection par boite noire. La spécification de l'agent est convertie en code


23

exécutable et en un ensemble de données encryptées [Claessens03]. Le cryptage de

données empêche un éventuel attaquant de lire ou de modifier les données. Dans

[Benachenhou05], les auteurs présentent une nouvelle approche qui consiste à exécuter un

agent clone sur un site sur afin de surveiller l'exécution du vrai agent. Cette solution

engendre une augmentation dans le trafic réseau (échange entre l'agent et son clone).

‒ La sécurité d'un agent contre un autre agent. L'agent doit être protégé contre une

éventuelle attaque par un autre agent [Hohlfeld02] situé sur le site hôte ou sur un autre site.

Un agent doit avoir sa propre politique de sécurité qui peut être soit assurée par l'agent lui-

même, soit par le site d'accueil.

1.2.3.9 Cycle de vie et contrôle de l'agent

Un environnement d'exécution pour agents mobiles doit offrir à l'utilisateur la

possibilité de contrôler les activités de l'agent. Depuis sa création jusqu'à sa terminaison, un

agent peut passer par plusieurs étapes (cycle de vie d'un agent). Un langage de programmation

d'agents mobiles doit offrir au programmeur des points d'entrée qui vont lui permettre de

contrôler l'activité de son agent. Un agent passe par une partie ou la totalité des étapes

suivantes :

Création et initialisation. Lors de sa création, l'agent peut être initialise avec des

informations nécessaires à son exécution telles qu'un itinéraire, des préférences de son

utilisateur, etc. Par ailleurs, un agent est initialise par le système avec des informations

nécessaires à son interaction avec son environnement, comme par exemple l'identité de

son utilisateur.

Migration. L'agent se déplace entre les machines du système. Le but de cette migration

est souvent motive par une coopération en local avec des agents fixes ou d'autres agents

mobiles s'exécutant sur le même site. Avant de reprendre ses activités, l'agent aura

besoin des informations sur le nouveau site.

Activation et désactivation. Dans une application basée sur les agents mobiles, un

agent se désactive en suspendant son exécution afin d'être sauvegarde sur un support

non volatile. L'agent mobile est donc gelé. L'activation est l'opération inverse par

laquelle l'agent est restaure afin de continuer son exécution.

Terminaison. Une fois que sa tâche est réalisée, l'agent se termine et son processus

d'exécution est tué. Avant sa terminaison l'agent a besoin de livrer un bilan a son

utilisateur.

Souvent, un environnement d'agent mobile offre aux développeurs des méthodes

relatives au cycle de vie d'un agent. Ces méthodes sont appelées des ≪ call-back ≫. Un agent

doit être informe chaque fois qu'un évènement du cycle de vie commence, réussi ou échoue

(voir Table 1.1). Cela a pour but non seulement de réagir aux évènements en question mais

aussi d'être capable de refuser une création, une migration ou une réinitialisation après un

déplacement.


24

1.2.4. Domaine d’application des agents mobiles

Beaucoup de domaines d‟application impliquant les agents mobiles comme nouvelle

technologie ont vu le jour, malgré que les agents mobiles soient introduits récemment. Parmi

ceux-ci nous citons :

Recherche et filtrage d’information : C‟est le plus grand champ d‟application et

d‟expérimentation des agents. Les premiers systèmes commerciaux utilisant des agents

étaient des agents “moniteurs”. C‟étaient des programmes qui alertaient l‟utilisateur quand

une information intéressante apparaît. Alexa est une barre d‟outils d‟aide gratuite à la

navigation. Elle procure des informations statistiques et des liens sur chaque site visité.

Elle aide également au magasinage en ligne en vérifiant l‟identité d‟un site de commerce à

partir des contacts donnés sur la page. Les agents, et spécialement les agents mobiles, sont

adaptés pour agir comme des “bots”, des logiciels qui naviguent continuellement sur la

toile pour trouver de nouvelles informations.

Le Commerce électronique : Les agents sont naturellement adaptés au commerce

électronique, vu que Les principes d‟autonomie et de délégation sont largement employés

dans ce type d‟application. L‟agent agit pour le compte d‟une personne et applique

différentes stratégies pour remplir les services demandés. Pour dialoguer et négocier avec

les services présents sur différents sites et afin de réaliser la meilleure transaction possible,

l‟agent utilise sa mobilité qui lui permet de se déplacer de site en site.

La Compression des documents : Le transfert de documents est très utilisée sur Web. Si

un client veut obtenir une copie d'un document, il doit formuler une demande auprès d‟un

serveur qui lui envoie un flux de données correspondant au contenu du document. Le client

pourra utiliser un outil de compression de données, afin d‟optimiser le transfert de

données. Pour cela, le serveur doit être étendu pour pouvoir assurer cette fonction de

compression. des extensions particulières sont aussi envisagées au niveau des clients pour

que différents client puisse utiliser différents outils de compression.

Services de télécommunication : Dans le domaine des télécommunications, La

fonctionnalité de mobilité trouve toute son utilité. Il est très intéressant de noter Les agents

mobiles peuvent être utilisés pour couvrir les couches de protocoles de communication, de

la maintenance des réseaux jusqu‟aux applications mobiles suivant ainsi l‟usager dans ses


25

déplacements. Un “Personal Communicator Agent” (PCA) est un agent mobile chargé de

délivrer un message au destinataire, quel que soit son appareil (téléphone, ordinateur,

portable ou téléphone sans fil). Le PCA d‟un utilisateur doit pouvoir recevoir les messages

et les conduire à l‟utilisateur dans les meilleures conditions. Par exemple, si le seul moyen

de délivrer un message urgent à un utilisateur est via un téléphone sans fil, l‟agent

personnel doit convertir le message textuel en message vocal. Le suivi de l‟utilisateur

même quand il change de machine est assuré par la mobilité de ces agents

Robotique : Le rendement des robots physiques peut être amélioré par les agents. À

l‟aide de capteurs, les robots se basent dans leur comportements sur des agents qui

traduisent l‟information obtenue pour définir les actions à entreprendre (tourner, avancer,

etc.). Exemple : En utilisant une opinion basée sur un comportement réactionnaire, Astérix

est un exemple de robot, qui permet un dépistage de haut niveau.

1.2.5 Exemples de plateformes existantes

Cette partie tente de donner une idée sur les plateformes existantes permettant le

développement et la manipulation des agents mobile. Cette tâche est assez difficile pour

plusieurs raisons:

- Cette technologie est en plein essor bien que la notion d’agent soit relativement

ancienne

- l’évolution très rapide du domaine ne permet pas d’avoir toujours une information

actuelle.

- Il y a plusieurs modèles pour décrire le comportement des agents. Chacun fait l’objet de

recherches et de documents qui ne permettent pas d’avoir une vue globale et homogène.

- La maîtrise technologique des agents est un enjeu économique et stratégique très

important, ce qui explique la difficulté de trouver une normalisation acceptable.

Il existe à l’heure actuelle beaucoup d’implémentations différentes incompatibles entre

elles. Certaines écrites en Java pur, bénéficiant de fait du portage multiplateformes. Citons :

Odyssey [ODYSSEY] (de General Magic), Une des premières plateformes d’agents. Il

est indépendant du protocole de transport utilisé et peut donc s’adapter à RMI (de Sun),

CORBA (de OMG) ou DCOM (de Microsoft).

Aglets [AGLETS] d’IBM, utilisent la notion de référence distante (AgletProxy), le

passage de messages (multicast, broadcast) et le protocole ATP développé par IBM. Il

offre en outre une certaine notion de sécurité en limitant les ressources allouées aux

aglets.

Dima [DIMA] du laboratoire LIP6, est une plateforme pour les systèmes multi agents

permettant le développement de différents types d’agents (réactif, cognitif et hybride).

Cette plateforme ne supporte pas la mobilité. Cette dernière doit être programmée.


26

Jade [JADE] du CSELT de l’université de Parma, est un logiciel qui simplifie la mise

en place des systèmes multi-agents par grâce à une interface personnalisée qui répond

aux spécifications de la Fondation pour les Agents Intelligent Physique -FIPA- et grâce

à un ensemble d'outils qui supportent la résolution des bugs. Jade propose en plus des

services de sécurité.

Grasshopper : La plateforme Grasshopper développée par IKV++ (Innovation Know-

how Vision++) en 1997 est un environnement d‟implémentation et d‟exécution pour

agents mobiles. Ce produit développé en Java a été testé sur SUN Solaris 2.5 et 2.6, et

sur Windows (NT et 9x). Pour son fonctionnement, Grasshopper requiert au minimum

la version Java 1.1.4Visibroker 3.1. Grasshopper a la particularité d‟être la première

plate-forme compatible avec le protocole standard MASIF (Mobile Agent System

Interoperability Facility) de l‟OMG (Object Managment Group) et les standards de

FIPA (Foundation For Intelligent Physical Agents).

1.2.6. Avantages et inconvénients du paradigme agents mobiles

Un agent mobile [Arcangeli02] est une entité logicielle qui se déplace d'un site à un

autre en cours d'exécution pour accéder à des données ou à des ressources distantes. Il se

déplace avec son code son état d'exécution et ses données propres. La décision de migration

peut se faire à l'initiative de l'agent lui-même de manière autonome, la mobilité est ainsi

contrôlée par l'application et non par le système d'exécution. Le but du déplacement est

généralement d'accéder localement a des données ou à des ressources initialement distantes,

d'effectuer le traitement en local et de ne déplacer que les données utiles. Malgré leur jeune

apparition, les agents mobiles se sont rapidement imposés en particulier dans le domaine de la

recherche portant sur les applications réparties. Ce paradigme a été aussitôt évalué afin de

vérifier ce qu‟il pouvait apporter comme avantages par rapport aux méthodes de

programmation classiques. Dans la suite de cette section, nous présentons quelques aspects

pour l‟évaluation des agents mobiles:

- La Réduction de la charge Réseau: Il est généralement plus avantageux en terme de

performances, de faire voyager du code plutôt que des données.

- Le Déplacement du Code vers les données: Les serveurs contenant des données

procurent un ensemble fixe d'opérations. Un agent peut étendre cet ensemble pour les

besoins particuliers d'un traitement.

- La Fiabilité: La vie d'un programme classique est liée à la machine où il s'exécute.

Un agent mobile peut se déplacer pour éviter une erreur matérielle ou logicielle ou

tout simplement un arrêt de la machine.

- L'adaptation dynamique du système aux problèmes: Les agents peuvent se répartir

eux-mêmes sur des machines du réseau, afin de mieux tenir compte de l'état du

système au moment où ils doivent exécuter leurs tâches.

- La gestion de la robustesse et de la tolérance aux pannes: Si une machine s'arrête,

l'agent qui s'y trouve peut changer de machine pour terminer sa tâche en cours. En se

déplaçant avec leur code et données propres, les agents mobiles peuvent s‟adapter

facilement aux erreurs systèmes. Ces erreurs peuvent être d‟ordre purement physique


27

tel que la disparition d‟un nœud, ou d‟ordre fonctionnel comme l‟arrêt d‟un service. Si

dans un site par exemple un service tombe en panne, l‟agent utilisateur de ce service

pourra alors choisir de se déplacer vers un autre site contenant la fonctionnalité

désirée. Ceci permet une meilleure tolérance aux fautes.

- Indépendance des calculs: Certains services, nécessitant de longues phases de

traitement, ne supportent pas toujours les ruptures de connexion avec les clients. Par

ailleurs, le maintien des liens des communications dans les réseaux à large échelle ou

sans fil, est très difficile. Ceci rend, le modèle d‟évaluation à distance où le client et le

serveur doivent rester connectés tant que le service est en cours d‟exécution, très peu

adéquat. Les agents mobiles offrent aux clients la possibilité de déléguer les

interactions avec le service sans maintenir une connexion de bout en bout.

- La difficulté de développement et l’insuffisance de la standardisation: c‟est

l‟inconvénient majeur des agents mobiles étant donné que ce domaine est encore

relativement jeune. Il se heurte donc, à de fortes contraintes lors des phases de

développement. Comme par exemple le fait qu‟il existe à l‟heure actuelle un trop

grand nombre d‟intergiciels pour agents mobiles dont chacun possède ses propres

défauts et qualités [Cubat05]. La standardisation est donc loin, avec cette diversité

d‟offre.

Les agents ont besoin d‟exprimer les caractéristiques des services qu‟ils recherchent et

surtout d‟obtenir des réponses précises sur leur localisation ainsi que sur la manière de les

utiliser; et comme il n‟existe pas, jusqu‟à présent, de langage standard partagé par toutes les

plateformes de développements des applications d‟agents mobiles pour exprimer ces besoins,

un handicap sérieux se pose pour ce nouveau paradigme. De plus, avec tous les langages

existants, les développeurs sont, encore une fois, face à un large éventail de possibilités.

Heureusement, le domaine des systèmes multi-agents qui cherche à mettre en place des

langages précis en s‟appuyant sur un ensemble d‟ontologies et de protocoles caractérisant les

interactions inter-agents, pourrait apporter une solution à ce problème.

1.3. Conclusion

Dans ce chapitre, nous avons présenté les différentes technologies utilisées pour la

répartition et la communication entre les différentes entités d'une application repartie. Ainsi,

nous avons situé la technologie d'agents mobiles par rapport aux différentes techniques

présentées.

Un agent mobile est une entité autonome qui se déplace d'une machine à l'autre sur le

réseau, sans perdre son code ni son état. C'est l'environnement d'exécution qui se charge

d'assurer cette fonctionnalité. Il permet la création et la migration d'un agent, la

communication et l'échange de messages entre les agents mobiles et il assure la sécurité de

l'agent et de son site d'accueil.

Nous avons enchainé ensuite avec quelques exemples de plateformes

d'implémentation des applications d'agents mobiles. Avec la multitude de plates-formes

d'exécution, des efforts dans le domaine de la standardisation ont été déployés. Ce chapitre a

été conclu avec des critiques de ce paradigme.

28

Chapitre 2

Approche MDA et Transformation de Modèles

L‟ingénierie dirigée par les modèles (IDM ou MDE : Model Driven Engineering) est

le domaine qui met à la disposition de ses utilisateurs, des outils, concepts et langages pour

créer et transformer des modèles afin de mécaniser le processus que les ingénieurs suivent

habituellement à la main. L‟IDM se concentre sur une préoccupation plus abstraite que la

programmation classique ce qui permet d‟obtenir plusieurs améliorations dans le

développement de systèmes complexes. Grâce à l‟utilisation importante des modèles (qui

peuvent être exprimés dans des formalismes différents) et des transformations automatiques

entre les modèles, L‟IDM permet un développement souple et itératif, grâce aux raffinements

et enrichissements par transformations successives et automatiques entre les modèles. Ce que

propose donc, l‟approche de l‟ingénierie des modèles est la mécanisation du processus que les

ingénieurs expérimentés suivent à la main [Kadima05].

Dans cette thèse, notre proposition repose sur la démarche de l‟Ingénierie Dirigée par

les Modèles (IDM). Dans ce chapitre, nous présentons sommairement le principe et les

concepts fondamentaux de cette démarche et nous illustrons sa mise en œuvre à travers

l‟exemple de la variante que l‟Object Management Group (OMG) a définie autour de ses

standards: le Model-Driven Architecture (MDA). Nous donnerons entre autres, une idée sur la

transformation de modèles, sur les grammaires de graphes et un aperçu sur l‟outil utilisé à

savoir: ATOM3.

2.1 Principe

Une définition cohérente d‟un processus de construction d‟un produit nécessite à la

fois une bonne connaissance et une bonne maîtrise du produit à concevoir et de l‟intention du

processus de construction. La bonne connaissance et la bonne maîtrise du produit et de

l‟intention du processus de construction se traduisent par la possibilité d‟obtenir une

description précise et concise du produit, de l‟ensemble des solutions que l‟on souhaite

construire à partir de sa description initiale et de l‟ensemble des préoccupations qui mènent à

l‟ensemble des solutions visées. Dans la démarche de l‟IDM, cette description est exprimée à

travers un ensemble fini de modèles qui peuvent être interprétés ou transformés par une

machine. Pour qu‟une machine puisse interpréter ou transformer un modèle, il faut que le

modèle soit défini dans un langage que la machine comprend. Ce langage est appelé

métamodèle dans la littérature relative à la démarche de l‟IDM. Les métamodèles de

définition des modèles d‟un produit peuvent être différents. Pour gérer cette diversité, l‟IDM

repose sur l‟utilisation d‟un langage commun appelé métamétamodèle pour décrire tous les

métamodèles impliqués dans la description des modèles du produit afin de permettre leur

intégration dans les outils de mise en œuvre du processus de construction.


29

Le principe de l‟IDM consiste donc à utiliser des modèles de manière systématique et

intempestive durant le processus de construction d‟un produit. Dans le domaine de

l‟ingénierie des logiciels, le fait d‟utiliser des modèles pour décrire les différents aspects d‟un

produit n‟est pas une idée spécifique à l‟IDM. Il existe d‟autres approches et méthodes de

modélisation telles que Merise ou SSADT, la programmation générative ou encore les usines

logiciels (Software factories) dans lesquelles les modèles sont vus comme étant la base de

toute activité humaine d‟ingénierie [Mokrane04]. La spécificité de l‟IDM repose sur sa

capacité à donner une dimension productive (ou opérationnelle) aux modèles. Dans le monde

de l‟IDM, un modèle est dit productif s‟il est exécutable ou s‟il peut être utilisé pour

construire des artefacts exécutables. Pour pouvoir construire des artefacts exécutables à partir

d‟un modèle, il faut être capable de définir des opérations sur le modèle afin de construire ces

artefacts exécutables. Ces opérations sont appelées des transformations de modèles dans la

démarche de l‟IDM. Tout modèle ou artefact exécutable est défini dans le contexte d‟une

plate-forme [Mireille06].

La démarche de l‟IDM repose donc sur cinq concepts fondamentaux : les modèles, les

métamodèles, les métamétamodèles, les transformations de modèles et les plateformes. Il

n‟existe pas de définitions standards de ces concepts dans le monde l‟IDM. La section

suivante présente les définitions rencontrées et qui semblent être acceptées par la plupart des

utilisateurs de l‟IDM dans la littérature.

2.2 Définition des concepts fondamentaux

2.2.1 Modèle

Un modèle est une abstraction simplifiée d‟un système étudié, construite dans une

intention particulière. Il doit pouvoir être utilisé pour répondre à des questions sur le système

[Jean01]. Un système est une construction théorique que forme l‟esprit sur un sujet (par

exemple, une idée qui est mise en œuvre afin d‟expliquer un phénomène physique qui peut

être représenté par un modèle mathématiques) [Wikipédia08].

2.2.2 Métamodèle

Un métamodèle est un langage qui permet d‟exprimer des modèles. Il définit les

concepts ainsi que les relations entre concepts nécessaires à l‟expression de modèles [Jean01].

Un modèle est une construction possible du métamodèle dans lequel il est défini. Dans la

littérature, un modèle est dit conforme au métamodèle dans lequel il est défini.

2.2.3 Métamétamodèle

Un métamétamodèle est un langage qui permet d‟exprimer des métamodèles. Pour

pouvoir interpréter un méta-modèle il faut disposer d‟une description du langage dans lequel

il est écrit : un méta-modèle pour les méta-modèles. C‟est naturellement que l‟on désigne ce

méta-modèle particulier par le terme de méta-méta-modèle [Marcus04]. Pour limiter le

nombre de niveaux d‟abstraction, le méta-méta-modèle doit avoir la capacité de se décrire lui-

même. Dans le monde de l‟IDM, il existe de nombreux langages tels que Keret [IRISA08],

MOF (pour Meta Object Facility) [OMG06], [OMG03], EMOF (The Essential MOF Model)

[OMG06], Ecore [Merks06] etc. disponibles pour l‟´écriture de métamodèles.

C‟est sur ces principes que se base l‟organisation de la modélisation de l‟OMG

généralement décrite sous une forme pyramidale (figure 2.1). Le monde réel est représenté à

la base de la pyramide (niveau M0). Les modèles représentant cette réalité constituent le


30

niveau M1. Les méta-modèles constituent le (niveau M2). Enfin, Le niveau M3 est le niveau

le plus abstrait parmi les quatre niveaux dans cette architecture. Il définit la structure de tous

les méta-modèles du niveau M2 ainsi que lui-même.

Figure 2.1. Pyramide de la modélisation OMG

Dans l‟architecture à quatre niveaux, la validation d‟un modèle se fait via le modèle du

niveau suivant. Ce concept de méta-modèle semble être fondamental. Outre le fait qu‟il aide à

réduire les ambiguïtés et les incohérences de la notation, il constitue aussi un précieux atout

pour les concepteurs, dans le sens où il permet d‟automatiser le processus de développement

logiciel. L‟inconvénient majeur des langages de méta-modélisation dont MOF, c‟est qu‟ils

n‟offrent pas des techniques de validation et des règles de passage d‟un niveau à un autre.

MOF : Meta Object Facility MOF pour (Meta-Object Facility) [OMG00] est un ensemble d‟interfaces permettant

de définir la syntaxe et la sémantique d‟un langage de modélisation. Il a été créé par l‟OMG

afin de définir des méta-modèles et leurs modèles correspondants [Sylvain04]. Il fait partie

des standards définis par l‟OMG. Le MOF spécifie la structure et la syntaxe de tous les méta-

modèles. Ils ont le même formalisme. Il spécifie aussi des mécanismes d‟interopérabilité entre

ces méta-modèles. Il est donc possible de les comparer et de les relier. Grâce à ces

mécanismes d‟échanges, le MOF peut faire cohabiter plusieurs méta-modèles différents

[Sylvain04].

2.3 L’approche MDA

L'approche dirigée par les modèles (Model Driven Approach– MDA) est une variante

de l‟IDM qui a été initiée par l‟OMG en novembre 2000. C‟est un cadre de développement et

de maintenance de produits logiciels basé sur l‟utilisation et la transformation de modèles.

Les outils utilisés dans l'architecture MDA ont pour but de manipuler des modèles

logiciels, de vérifier leur cohérence, de les raffiner, pour terminer avec leurs transformation

automatique en squelettes de code.

MDA peut résoudre les problèmes d'évolutivité, d'interopérabilité, de portabilité, et de

documentation en vue d'augmenter la productivité dans le processus de développement

logiciel.


31

2.3.1 Les modèles dans l’Architecture MDA

Dans l‟approche MDA, on perçoit trois points de vue, auquels on associe les modèles

respectifs : CIM, PIM et PSM.

Le modèle CIM : le CIM (Computational Independent Model) Appelé aussi modèle de

domaine ou modèle métier. Il permet de recenser les différents besoins du client

indépendamment de toute implémentation.

Le modèle PIM : le PIM (Platform Independent Model) représente un modèle de

spécification de la partie fonctionnelle du système. Cette spécification doit être conforme

à une analyse informatique cherchant à répondre aux besoins métiers indépendamment de

des détails techniques.

Le PSM : le PSM (Platform Specific Model) correspond au modèle de conception et

d‟implémentation d'une application par rapport à une plateforme spécifique.

Le point de départ de la construction d‟un produit est l‟identification des besoins des

utilisateurs. Dans le MDA, ces besoins sont traduits dans un modèle indépendant de tout

système informatique (CIM pour Computational Independent Model). Le principe du MDA

consiste à séparer ensuite la spécification fonctionnelle (PIM pour Platform Independent

Model) du produit de sa spécification d‟implantation sur une plate-forme technique

particulière (PSM pour Platform Specific Model). Dans l‟idée initiale du MDA, le PSM est

construit à l‟aide d‟un ensemble de transformations automatiques ou semi automatiques de

modèles qui fusionnent les informations spécifiques à la plate-forme choisie (PDM pour

Platform Description Model) et les informations du PIM. Ce PSM peut être raffiné jusqu‟à

l‟obtention du code d‟implantation effective du produit comme l‟indique la figure 2.2.

Figure. 2.2 Principe de la construction d‟un système à base de modèles dans le MDA


32

2.3.2 Principe de transformation

La transformation de modèles doit mettre en œuvre des opérations permettant la

création d‟un modèle cible à partir des informations fournies par un modèle source. Elle se

base essentiellement sur les relations entre les modèles. Le passage du modèle source vers le

modèle cible, nécessite la connaissance parfaite des relations existantes entre les deux

modèles.

En MDA la transformation de modèles repose sur l‟utilisation des métamodèles et

comprend deux étapes [Kadima05] successives, qui sont :

La détermination des règles de transformation qui expriment la relation entre les

concepts du métamodèle décrivant le modèle source et ceux du métamodèle décrivant

le modèle cible.

L‟application de ces règles de transformation au modèle source pour générer le modèle

cible.

La figure 2.3 résume les concepts de base et le principe d‟une transformation de

modèles. En somme, une transformation est définie sur la base des métamodèles de sa source

et de sa cible. Les métamodèles et les modèles (source, cible, y compris le modèle de la

transformation) sont enregistrés dans un ensemble de référentiels (repositories). La

transformation est exécutée à l‟aide d‟un moteur de transformation qui est un outil capable de

lire un modèle dans un référentiel donné, d‟appliquer la transformation pour générer une

solution qu‟il décrit dans un référentiel approprié, et ce conformément à la définition de la

transformation.

Figure 2.3. Processus de transformation de modèles pilotée par les métamodèles


33

2.3.3 Passage entre modèles

Passer progressivement des PIM aux PSM pour préparer et faciliter la génération de

code vers la plate-forme technique choisie, constitue l‟idée du MDA. Ce passage des PIM aux

PSM est une transformation de modèles [Jean02]. Dans le cycle de vie et de développement

d‟un produit, le MDA identifie différentes catégories de transformations de modèles.

PIM vers PIM (raffinement): Cette transformation constitue un enrichissement et une

spécialisation du modèle, en y apportant des informations indépendantes des spécificités

d'une technologie. La description d'un modèle de répartition, de persistance des données

ou de composants peut être vue comme un raffinement.

PIM vers PSM (projection): C‟est la traduction du modèle générique, vers une

plateforme d'exécution.

PSM vers PSM (réalisation): C'est la mise en œuvre concrète d'un modèle générique

sur une plate-forme d'exécution. Elle consiste en l'ensemble des phases qui mènent à un

logiciel exécutable, telles que la génération de code source, la compilation, le

déploiement, l'instanciation et l'initialisation des composants logiciels.

PSM vers PIM (reverse-engineering): Cette transformation permet l'élaboration du

modèle générique à partir de l'implémentation existante d'un logiciel. En théorie, cette

transformation est censée fournir un modèle générique décrivant l'application à partir

d'une base de code accessible. En pratique, il est très complexe d'automatiser

entièrement ce processus pour tout modèle PSM.

Génération de code: dans la pratique, certains travaux font la distinction entre les PSM

exécutables (ou code) et les PSM non exécutables, mais la génération de code n‟est pas

toujours considérée comme une transformation de modèles. La figure 2.4 montre quand même

qu‟il est possible de passer d‟un PSM non exécutable à du code et inversement. Il est

important de souligner que le passage du code au PSM est une opération de rétro-ingénierie

qui est assez complexe à réaliser. Si le code n‟a pas ´été conçu dans la démarche du MDA, il

faut faire appel aux techniques traditionnelles de rétro-ingénierie pour effectuer de telles

opérations. En somme, il est possible de classer les transformations de modèles possibles dans

le MDA dans quatre catégories comme l‟indique la figure 2.4.

Figure. 2.4 Transformations de modèles MDA


34

– les transformations (2) : décrivent le processus de conversion d‟un PIM en un PSM;

– les raffinements (1), (3) et (6) : introduisent ou suppriment des informations dans un modèle ;

– les retro-ingénieries (4) et (7) : convertissent un modèle vers un niveau d‟abstraction plus élevé ;

– la génération de code (5) : transforme un PSM non exécutable en un code exécutable. Nous avons déjà

mentionné que la génération de code n‟est pas toujours considérée comme une transformation de modèles

dans la pratique.

2.3.4 Types de transformations de modèles

D‟un point de vue utilisateur, une transformation prend un ou plusieurs modèles en

entrée et génère un ou plusieurs modèles en sortie [Eric07]. Dans une transformation

interviennent deux composantes: la première est la définition de la transformation, la seconde

est l‟outil de transformation.

Les transformations sont des processus permettant d'une part les manipulations de

modèles, et d'autre part le passage d'un niveau de modèle à un autre [David06]. Pour réaliser

des transformations de modèles, les modèles doivent être exprimés dans un langage de

modélisation défini à l‟aide d‟un méta-modèle. On compte deux types de transformations:

endogènes et exogènes et ce, partant des méta-modèles sources et cibles de la transformation.

Si les modèles utilisés sont issus du même métamodèle, la transformation est dite endogène.

Par contre, si les modèles sources et cibles sont de différents méta-modèles, la transformation

est dite exogène ou translation. Ces deux catégories de transformations peuvent être

subdivisées comme suit :

Transformations endogènes

Optimisation : améliorer les performances tout en maintenant la sémantique,

Restructuration (refactoring) : transformation de la structure pour améliorer certains

aspects de la qualité du logiciel,

Simplification : transformation afin de réduire la complexité syntaxique.

Transformations exogènes

Synthèse : transformation d‟un certain niveau d‟abstraction vers un niveau

d‟abstraction moins élevé.

Rétro ingénierie : inverse de la synthèse.

Migration : transformation d‟un programme écrit dans un langage vers un autre

langage du même niveau d‟abstraction.

Le niveau d‟abstraction constitue un autre facteur important à prendre en considération

dans les transformations. On distingue les transformations horizontales et les transformations

verticales.

Une transformation horizontale est une transformation où les modèles sources et cibles

sont du même niveau d‟abstraction. Alors que, dans une transformation verticale, les modèles

impliqués sont de différents niveaux d‟abstraction.

2.3.5. Classification des approches de transformation de modèles

Selon NPrakash [Prakash06], la classification des approches de transformation de

modèles se base sur plusieurs points de vue, Chacun d‟entre eux permet un type de

classification. D‟après CZarnecki [Czar03] la classification des approches de transformation

de modèles repose sur les techniques de transformation adoptées par ses approches et leurs


35

caractéristiques, telles que : la technique des langages de programmation et celle des patrons.

D‟autre part, et s‟intéressant particulièrement au domaine d‟application des modèles et à leur

généricité (capacité de transformer n‟importe quel modèle d‟entrée à n‟importe quel modèle

de sortie), NPrakash [Prakash06] propose une classification selon un point de vue

multidimensionnel.

Selon CZarneki [Czar03], il existe deux types de transformation de modèles :

les transformations de type modèle vers code qui sont aujourd‟hui relativement matures

et les transformations de type modèle vers modèles.

2. 3.5.1 Transformations de type Modèle vers code

La transformation de « modèle vers du code » est utilisée pour générer du code dans

un langage de programmation (Java, C++, XML, HTML, etc.) particulier à partir d‟un modèle

source. On distingue deux approches de transformations de type modèle vers code : les

approches basées sur le principe du visiteur (Visitor-based approach) ou celles basées sur le

principe des patrons (Template-based approach).

Les approches basées sur le principe du visiteur transforment le modèle en entrée

vers un code écrit dans un langage de programmation en sortie. La différence de

sémantique entre le modèle et le langage cible est réduite par l‟ajout de visiteurs au

modèle d‟entrée. Le modèle enrichi par les visiteurs est parcouru pour obtenir Le code

cible et créer ainsi un flux de texte en sortie.

Approches basées sur l‟utilisation de templates. Dans ces approches, un template est

un fragment de texte (du code) cible contenant des bouts de métacodes qui permettent:

(a) d‟accéder aux informations du modèle source

(b) de sélectionner du texte (code)

(c) de réaliser des expansions de manière itérative

2.3.5.2. Transformations de type modèle vers modèle

Les transformations de type modèle vers modèle sont aujourd‟hui plus maîtrisées, en

effet, elles ont beaucoup évolué au cours de ces dernières années, et plus particulièrement

depuis l‟apparition du MDA [OMG04]. Dans la démarche de l‟IDM, la transformation de

« modèle à modèle » est utilisée pour réaliser une activité de génération de modèles qui peut

être automatisée. La conversion d‟une classe UML en une table relationnelle (UML to

RDBMS, figure 2. 5) est un exemple typique de transformation de modèle à modèle souvent

cité dans la littérature à titre illustratif.


36

Figure 2.5 Exemple typique d‟une transformation de modèle vers modèle

a- Modélisation de la transformation

Les différences, de la sémantique et de la syntaxe entre les deux modèles, source et cible

tels que : les PMIs et les PSMs, imposent une démarche rigoureuse pour une transformation

de type modèle à modèle qui ne cesse de se développer grâce à la diversité des techniques

MDA. La modélisation de transformation de modèles apparaît alors comme solution à ce

problème. Modéliser une transformation relève de la métamodélisation, qui est désormais, une

technique pilier, dans le cadre de la transformation de modèles.

b- Structure de la transformation

Une transformation de modèle se définit par un ensemble d‟éléments à savoir : des

règles de transformation ainsi que leurs organisations et leurs ordonnancement, une traçabilité

et une orientation doivent être aussi mises sn œuvre. La combinaison de ses éléments permet

de décrire la transformation qui est un modèle en soit même. Cependant, ces règles de

transformation doivent être d‟abord spécifiées afin de pouvoir exprimer les correspondances

entres les concepts des Métamodèles source et cible.

Règles de transformation : une règle de transformation se définit comme une

description de la manière dont une ou plusieurs constructions dans le langage du

modèle source peuvent être transformées en une ou plusieurs constructions dans le

langage du modèle cible [Kadima05]. Des contraintes ou des calculs sur les modèles

sources et cibles de la transformation sont exprimés par une logique de forme

déclarative ou impérative, que doit possède toute règle de transformation.

Spécification des règles de transformation : La correspondance entre les concepts du

métamodèle source et les concepts du métamodèle cible, est exprimée par les règles de


37

transformation. La spécification décrit de telles relations indépendamment de toute

exécution. l‟automatisation complète de cette phase est prévue par les techniques MDA.

Certaines approches de transformation fournissent un mécanisme dédié de

spécifications, tel que des pré-conditions et des post-conditions exprimées en OCL. Des

spécifications particulières de transformation peuvent représenter une fonction entre les

modèles source et cible et peuvent être exécutables. Mais généralement, les

spécifications décrivent des relations et elles ne sont pas exécutables.

Pour exprimer les règles de transformation, il n‟existe pas actuellement de standard.

Cependant, Les travaux actuels de l‟OMG sur le standard MOF/QVT (Query Views

Transformation) sont prometteurs. Dans notre these, nous avons utilisé l‟outil ATOM3

[ATOM3].

c- Approches pour la définition de la transformation:

Les différentes caractéristiques présentées dans cette section constituent des points de

variation qui distinguent les différentes approches pour la définition de transformation de type

modèle vers modèle. On peut globalement distinguer cinq types d‟approches :

Manipulations directes

Ces approches se basent sur la représentation interne des modèles source et cible et sur

une collection d‟APIs pour les manipuler. L‟implémentation des règles de

transformation et leur ordonnancement restent à la charge du développeur en langage de

programmation standard comme Java par exemple.

Approches relationnelles

Ces approches utilisent une logique déclarative reposant sur des relations d‟ordre

mathématique pour spécifier les relations entre les éléments des modèles source et cible

par le biais de contraintes. L‟utilisation de la programmation logique est

particulièrement adaptée à ce type d‟approche.

Approches guidées par la structure

Dans ces approches, la transformation se fait en deux étapes. La première consiste à

créer la structure hiérarchique du modèle cible, alors que la deuxième consiste à ajuster

les attributs et les références dans le modèle cible.

Transformations de graphes

Les transformations de graphes, qui sont basées sur les grammaires de graphes

[Gerber02], sont des techniques et des formalismes directement applicables à la

transformation de modèles. Elles sont similaires aux approches relationnelles dans le

sens où elles permettent l‟expression des transformations sous une forme déclarative.

Dans cette approche les modèles source et cible sont représentés sous forme de graphes.

Cette notation visuelle permet aussi d‟exprimer les règles de transformation sous forme

graphique. Cette approche trouve son utilité dans le cas où les formalismes manipulés

possèdent des syntaxes concrètes visuelles. Elle est formelle et bien fondée sur des

bases mathématiques (comme la théorie des graphes et des grammaires formelles) ce

qui permet de vérifier certaines propriétés de la transformation. Cette approche vise à

considérer l‟opération de transformation comme un autre modèle conforme à son propre

méta-modèle (lui-même défini à l‟aide d‟un langage de méta-modélisation).


38

Une grammaire de graphe permet ainsi en tant que formalisme de modéliser une

transformation [Vangheluwe02]. Une grande partie des outils récents adoptent cette

approche avec certaines différences tels que : VIATRA, AToM3, AGG et GReAT

[Taentzer05].

Approches hybrides

Les approches hybrides sont une combinaison des différentes techniques. On peut

notamment retrouver des approches utilisant à la fois des règles déclarative et

impérative. ATL (ATLAS Transformation Langage) [Jouault06] est un exemple de cette

approche.

2.4. Transformation de graphes

Dans la modélisation des systèmes, on rencontre le problème de la description de leurs

structures complexes. Les modèles et métamodèles, possèdent le plus souvent une

représentation sous forme de graphe. En effet, la théorie des graphes ouvre un grand champ de

modélisation conduisant à des solutions efficaces pour de nombreux problème. En outre, Les

graphes offrent un support agréable et efficace qui permet la modélisation de systèmes. Par

conséquent, les techniques de transformation et de réécriture des graphes peuvent être

appliquées à la transformation de modèles et exploitées pour spécifier comment évoluent ces

derniers.

Nous allons passer en revue quelques concepts de bases relatifs à la théorie de graphes,

avant d‟aborder les techniques de transformation de graphes et les outils rendant de telles

techniques applicables.

2.4.1. Concept de graphe

On appelle graphe G le couple (S,A) constitué d‟un ensemble S de sommets et d‟un

ensemble A d‟arcs. Chaque arc de A relie deux sommets de S. Un graphe peut être orienté ou

non selon le sens que l‟on donne aux arcs, les deux sommets qu‟ils relient pouvant être

considères comme ordonné ou non. [Yann03].

Principalement, on distingue trois catégories de graphes : les graphes orientés, les

graphes non orientés et les graphes étiquetés (cf. les figures 2.6 et 2.7 et 2.8). Dans la suite de

cette section nous allons présenter quelques définitions relatives aux propriétés et

caractéristiques des graphes :

Graphes non orientés

Un graphe non orienté n‟est qu‟un graphe orienté symétrique: si un arc relie le sommet a au

sommet b, un autre arc relie le sommet b au sommet a; on ne trace alors qu‟un trait entre a et

b que l‟on appelle une « arête ».


39

Figure 2.6. Graphe non orienté

Le nombre de sommets présents dans un graphe est appelé ordre du graphe. Le graphe

de la figure 2.6 est d‟ordre 3.

Le degré d'un sommet est le nombre d'arêtes dont ce sommet est une extrémité. Le degré

du sommet B de la figure 2.6 est 3.

Graphes orientés

Un graphe orienté est un graphe dont les arêtes sont orientées: on parle alors de l'origine et de

l'extrémité d'une arête. Dans un graphe orienté une arête est dénommée « arc ».

Figure 2.7. Graphe orienté simple

Graphe étiqueté : Un graphe étiqueté est un graphe orienté, dont les arcs possèdent des

étiquettes. La nécessité de l‟étiquetage découle du fait qu‟un graphe utilisé pour la

représentation d‟un modèle doit être capable de prendre en charge les différentes relations

entre les éléments du modèle représenté. Les graphes orientés ne suffisent pas pour exprimer

les relations entre les éléments du modèle. Un étiquetage des arcs dans les graphes permet de

spécialiser les relations entre les différents sommets dans un graphe.

Figure 2.8. Graphe orienté étiqueté

A

B

C

F

F

S

K


40

Le Chemin dans un graphe: le chemin dans un graphe est la succession des arcs parcourus

dans un sens définit dans le graphe, les propriétés et les caractéristiques d‟un chemin sont:

- sa longueur qui est égale au nombre d‟arcs parcourus ;

- le chenin décrit une chaîne si l‟on ne tient pas compte de la direction des arcs ;

- le chemin décrit un circuit s‟il revient à son point de départ ;

- la distance entre deux sommets dans un graphe est la longueur du plus court chemin entre

ces deux sommets, si cette longueur est de 1 les sommets sont dits adjacents.

- le diamètre d‟un graphe est la plus grande distance séparant deux sommets dans ce graphe.

Le sous-graphe : un sous graphe G’(S’,A’) d‟un graphe G(S,A) est un graphe composé

d‟un sous ensemble de sommet S’ S et d‟un sous ensemble d‟arêtes A’A’ tel que A’

représente les arêtes reliant les sommets S’ dans le graphe G (cf. la figure 4.7).

Graphe – G Graphe – G’

Figure 2.9. G’ est un sous graphe de G

2.4.2. Transformation de graphes

Les graphes et les diagrammes sont un moyen très pratique pour la description des

structures complexes et des systèmes ainsi que pour la modélisation des idées de manière

directe et intuitive. Les graphes servent à visualiser les structures complexes des modèles

d‟une façon simple et intuitive, alors que les transformations de graphes, peuvent être

exploitées pour spécifier comment ces modèles peuvent évoluer.

La transformation de graphes est un système de transformation de modèles

[Kadima05], elle se réalise grâce aux règles de transformation [Guerra06]. Les règles

s‟appliquent à un graphe source, en se basant sur le principe du pattern matching, pour

produire un graphe cible. Le principe de base est d‟appliquer les règles de transformation qui

remplacent des sous graphes dans le graphe source par des sous graphes dans le graphe cible

et ce, en utilisant la production préalablement définie dans les règles de transformation.

Les transformations de graphes [Rozenberg99] ont évolué dans la répercussion à

l‟imperfection dans l‟expressivité des approches de réécriture classique comme les

grammaires de Chomsky et la réécriture de termes pour s‟y prendre avec les structures non

linéaires. Une transformation de graphe [Karsai04, Andries99, Rozenberg99] consiste en

l‟application d‟une règle à un graphe et itérer ce processus. Chaque application de règle

A

B

C A

B


41

transforme un graphe par le remplacement d‟une de ses parties par un autre graphe. La

transformation de graphe est donc le processus de choisir une règle parmi un ensemble de

règles indiqué, appliquer cette règle à un graphe et réitérer ce processus, jusqu'à

l‟impossibilité d‟application de toute règle.

2.4.2.1 Grammaires de graphes

La transformation de graphe est spécifiée sous forme d‟un modèle de grammaires de

graphes, ces dernières sont une généralisation, pour les graphes, des grammaires de Chomsky.

Elles sont composées de règles dont chacune est composée d‟un graphe de côté gauche (LHS)

et d‟un graphe de côté droit (RHS).

Une grammaire de graphe GG = (P,S,T), est un ensemble P de règles muni d‟un

graphe initial S et d‟un ensemble T de symboles terminaux [Andries99].

Une grammaire de graphes distingue les graphes non terminaux, qui sont les résultats

intermédiaires sur lesquels les règles sont appliquées, des graphes terminaux dont on ne peut

plus appliquer de règles, on dit que ces derniers sont dans le langage engendré par la

grammaire. Pour vérifier si un graphe G est dans les langages engendrés par une grammaire

de graphe, il doit être analysé. Le processus d‟analyse va déterminer une séquence de règles

dérivant G.

Exemple : Une grammaire de graphe à 2 règles.

Figure 2.10. Une grammaire déterministe de graphes

2.4.2.2. Le principe de règles

Une règle de transformation de graphe est définie par : r = (L, R, K, glue, emb, cond)

Elle consiste en:

Deux graphes, L graphe de côté gauche et R graphe de côté droit.

Un sous graphe K de L.

Une occurrence glue de K dans R qui relie le sous graphe avec le graphe de

côté droit.

Une relation d‟enfoncement qui relie les sommets du graphe de côté gauche et

ceux du graphe du côté droit.

Un ensemble cond qui spécifie les conditions d‟application de la règle.


42

2.4.2.3. Application des règles

L‟application d‟une règle r= (L, R, K, glue, emb, cond) à un graphe G produit un

graphe résultant H. Le graphe H fourni, peut être obtenu depuis le graphe d‟origine G en

passant par les cinq étapes suivantes :

1. Choisir une occurrence du graphe de côté gauche L dans G.

2. Vérifier les conditions d‟application d‟après cond.

3. Retirer l‟occurrence de L (jusqu‟à K) de G ainsi que les arcs pendillé, c-à-d

tous les arcs qui ont perdu leurs sources et/ou leurs destinations. Ce qui

fournit le graphe de contexte D de L qui a laissé une occurrence de K.

4. Coller le graphe de contexte D et le graphe de côté droit R suivant

l‟occurrence de K dans D et dans R. c‟est la construction de l‟union de

disjonction de D et R et, pour chaque point dans K, identifier le point

correspondant dans D avec le point correspondant dans R.

5. Enfoncer le graphe du côté droit dans le graphe de contexte de L suivant la

relation d‟enfoncement emb :

La dérivation directe depuis G vers H à travers r dénotée par G ⇒ H, est l‟application

de la règle r sur un graphe G pour fournir un graphe H.

2.4.2.4 Système de transformation de graphe

Un système de transformation de graphe se défini comme un système de réécriture de

graphes qui applique les règles de la Grammaire de Graphes sur son graphe initial jusqu'à ce

que plus aucune règle ne soit applicable [Rozenberg99].

Figure 2.11. Système de réécriture de graphes


43

Exemple :

Figure 2.12. Récriture pour la grammaire de la figure 2.10

Cette approche de transformations de modèles a plusieurs avantages par rapport aux

autres approches [Rozenberg99]:

Les grammaires de graphes sont un formalisme naturel, visuel, formel et de haut

niveau pour décrire les transformations

Les fondements théoriques des systèmes de la réécriture de graphes permettent

d‟aider à vérifier certaines propriétés des transformations telles que la terminaison ou

la correction.

2.4.2.5 Langage engendré

Soit un ensemble donné P de règles et un graphe G0. Une séquence de transformations

de graphe successive G0 ⇒ G1 ⇒ … ⇒ Gn, est une dérivation à partir de G0 vers Gn par les

règles de P (toutes les règles utilisées appartiennent à P). G0 est le graphe initial et Gn est le

graphe dérivé de la séquence de transformation citée. L‟ensemble des graphes dérivés à partir

d‟un graphe initial S en appliquant les règles de P qui sont étiquetées par les symboles de T

est dit langage engendré par P, S et T, et noté L(P,S,T).

2.5. AToM3: Un outil de Modélisation Multi-paradigme

Actuellement, il existe plusieurs outils de transformation de graphes, entre autres : AGG

[AGG], AToM3 [ATOM3], VIATRA [Viatra], etc. Etant simple et disponinle, ATOM

3 a été

utilisé dans le cadre de cette thèse.

2.5.1. Présentation de l’outil AToM3

AToM3

[ATOM3] « A Tool for Multi-formalism and Meta-Modeling » [De Lara02] est

un outil de modélisation multi-paradigme développé par le laboratoire MSDL

(Modelling,Simulation and Design Lab) à l'université de McGill Montréal, Canada. Comme il


44

a été implémenté en Python [Python], il peut être exécuté, sans aucun changement, sur toutes

les plateformes où un interpréteur de Python est disponible (Linux, Windows et MacOS).

AToM3 est un outil visuel qui possède une couche de Méta-modélisation lui permettant

une modélisation graphique des différents formalismes. Il utilise et implémente un ensemble

de concepts tel que : métamodélisation, la modélisation selon plusieurs formalisme et les

grammaires de graphes qu‟il utilise pour la transformation de modèles. Par ailleurs, A partir

de la méta-spécification, AToM3 génère un outil pour la manipulation des différents modèles

décrits dans un formalisme spécifié, ces modèles ont une représentation interne de syntaxe

abstraite, et ils ont une autre représentation externe visuelle sous forme de graphes de syntaxe

concrète. Les règles des grammaires de graphes sont spécifiées par la syntaxe concrète des

modèles.

Dans AToM3, les modèles ainsi que les formalismes ont une description graphique. Les

modèles sont décrits selon des formalismes spécifiés par des méta-modèles, et ce, en utilisant

l‟outil de modélisation généré par AToM3. La transformation de modèles pourra donc

s‟effectuer en utilisant les grammaires de graphes (cf. la figure 2.13).

Figure 2.13. Présentation AToM3

2.5.2. La Méta-modélisation avec AToM3

L‟outil AToM3, utilise le formalisme Entité-Relation (ER) ou le formalisme des

diagrammes de classes d'UML pour définir les formalismes utilisateurs en les décrivant

visuellement par des graphes. Ceci signifie que pour méta-modéliser de nouveaux


45

formalismes on peut utiliser le formalisme ER ou les diagrammes de classes d‟UML. Le

modèle des diagrammes de classes a été adopté dans le cadre de cette thèse.

Pour pouvoir réaliser une spécification complète des formalismes de modélisation, les

méta-modèles utilisateurs peuvent être étendus par l'expression de contraintes qui ne peuvent

pas être exprimées visuellement. Les contraintes sont exprimées sous une forme textuelle.

Pour ce faire, certains systèmes (dont AToM3) utilisent le langage OCL. Comme AToM3 est

implémenté en Python, on peut également utiliser du code Python pour exprimer les

contraintes. Au niveau méta-modèle, les entités qui doivent apparaître dans les modèles sont

spécifiées ainsi que leurs attributs, relations, cardinalités, contraintes sans oublier leurs

apparences graphiques.

Nous expliquons à travers le formalisme des automates à états finis (FSA) comment

utiliser AToM3 pour générer un éditeur de modèles FSM, et comment éliminer

l‟indéterminisme de ces modèles par le biais d‟une grammaire de graphes. La Figure 2.14

montre le méta-modèle des automates à états finis, alors que la Figure 3.15 présente l‟éditeur

graphique généré automatique avec AToM3 pour le formalisme des automates à états finis

(FSA) [De Lara02].

Figure 2.14. Méta-Modèle des automates à états finis


46

Figure 2.15. Editeur graphique généré pour les automates à états finis

2.5.3 La Transformation de Modèles.

Dans AToM3 un système de réécriture de graphes qui applique itérativement les règles

d‟une grammaire de graphes pour guider la procédure de transformation, est utilisé pour la

transformation de modèles. Pour diriger le choix de la règle à appliquer l'utilisateur spécifie et

classe ses règles selon des priorités bien étudiées. Selon l‟ordre ascendant de leurs priorités

toutes les règles sont testées, à chaque itération.

Lors de l‟application des règles, les attributs des éléments de la partie LHS doivent

avoir des valeurs qui seront comparées avec les attributs des éléments du modèle pendant le

processus de correspondance (matching). Un attribut peut prendre une valeur spécifique ou

n‟importe quelle valeur (<ANY>). En outre, les liens de traçabilité entre les éléments source

et cibles sont représentés par des étiquettes sous forme de numéros. Si une étiquette d‟un

élément apparaît dans la partie LHS mais pas dans la partie RHS, cet élément sera supprimé

lors de l‟application de la règle. Si au contraire, une étiquette d‟un élément n‟apparaît que

dans la partie RHS, cet élément sera créé suite à l‟application de cette règle. Le nœud sera

maintenu, si son étiquette apparaît à la fois dans la partie LHS et dans la partie RHS de la

règle à appliquer,

Suite à l‟application d‟une règle, les valeurs des attributs des éléments maintenus ou

nouvellement crées par la règle seront définis. On distingue, dans l‟outil AToM3 plusieurs

possibilités de le faire. Si l‟élément est déjà présent dans la partie LHS, les valeurs de ses

attributs peuvent copiées (<COPIED>). On a également la possibilité de leurs donner des

valeurs spécifiques ou de définir un programme Python pour calculer ces valeurs


47

(<SPECIFIED>), éventuellement, en utilisant les valeurs des attributs source. A chaque règle

peuvent être attaché, des actions à effectuer et des conditions supplémentaires, liées à son

application.

Outre les règles de transformations, dans la grammaire de graphe, on peut utiliser aussi

une action initiale et une autre finale. L‟action initiale (ou finale) spécifie les actions à

exécuter avant (ou après) l‟application des règles. AToM3 offre à l‟utilisateur la possibilité de

créer, charger, modifier et exécuter une grammaire. Un modèle en sortie est le résultat de

l‟exécution de la grammaire sur le modèle en entrée.

La Figure 3.16 représente la grammaire de graphes qui permet d‟éliminer

l‟indéterminisme dans un modèle des automates à états finis. L‟application de cette

grammaire de graphe sur le modèle de la Figure 3.15 est illustrée par la Figure 3.17.

Figure 2.16. Grammaire de Graphe: élimination de l‟indéterminisme


48

Figure 2.17. Application de la Grammaire

2.6. Conclusion

Dans ce chapitre, nous avons commencé dans un premier temps par présenter

sommairement l‟Ingénierie Dirigée par les Modèles (IDM), par la suite nous avons illustré sa

mise en œuvre à travers l‟exemple de la variante que l‟Object Management Group (OMG) a

définie autour de ses standards : le Model-Driven Architecture (MDA). Nous avons focalisé

plus particulièrement sur la transformation de modèles, l‟une des techniques prometteuses

dans l'approche MDA. Cette approche permet l'automatisation des processus de modélisation,

depuis les phases de développement jusqu‟à celles de tests, en passant par la génération de

code, dans ce contexte, nous avons présenté quelques autres approches de modélisation issues

de la littérature. Nous avons présenté par la suite une énumération de quelques types de

transformation de modèles, suivie d‟une classification de certaines approches de

transformation. Sur un autre plan, nous avons mis l‟accent sur les transformations de graphes

qui représentent une des approches de transformation de modèles et ce après avoir fait un bref

aperçu sur la notion de graphe.

Enfin, nous avons présenté AToM3, l‟outil de transformation utilisé dans notre travail,

d‟une façon assez exhaustive, car nous jugeons importants les éléments présentés dans ce

cadre pour la compréhension de notre contribution.

49

Chapitre 3

Modélisation Formelle et Mobilité

Définir le processus de construction d‟un produit d‟une façon cohérente, se base sur la

bonne connaissance et la grande maîtrise du produit sans oublier de cerner avec exactitude

l‟intention du processus de construction. La possibilité d‟obtenir une description précise et

concise du produit, ainsi que de l‟ensemble des solutions que l‟on souhaite construire à partir

de la description initiale de celui-ci, traduit justement, la bonne connaissance et la bonne

maîtrise du produit et de l‟intention du processus de construction. Un ensemble fini de

modèles peut exprimer cette description.

Vu la complexité croissante des systèmes complexes et les contraintes de sûreté et de

bon fonctionnement qui leurs sont associées, le développement de ces systèmes sollicite de

plus en plus les activités de modélisation, de vérification et de validation. Définir les

différentes préoccupations qui interviennent dans le cycle de développement, et ce, en

procurant aux développeurs des approches de modélisation pour exprimer exactement les

informations nécessaires à chacune d‟entre elles, relève du rôle de la modélisation. Pour

assurer la fiabilité et la sûreté de fonctionnement du système, en particulier dans les premières

étapes de sa conception, il est nécessaire d‟associer à la modélisation des techniques

d‟analyses pour vérifier les modèles par rapport aux propriétés attendues et valider ceux-ci par

rapport aux exigences du client.

Un agent mobile est une entité logicielle pouvant se déplacer d'un site du réseau à un

autre pour atteindre ses objectifs, et ce d‟une manière autonome. Deux grandes normes de

standardisation (FIPA et MASIF [MASIF]) et un grand nombre de plateformes [MASIF] pour

les agents mobiles sont apparus, malgré leur récente introduction. Cependant, et surtout lors

de la phase de développement, le domaine des agents mobiles se heurte à des contraintes liées

à la modélisation. Les approches orientées-agents existantes dans leur majorité, cherchent à

adapter les méthodologies de modélisation, relatives à l‟analyse et à la conception orientées

objets pour le développement des applications d‟agents mobiles [Bahri09]. Il serait beaucoup

plus intéressant, d'obtenir une approche qui pourra être utilisée tout au long des phases de

développement des systèmes à agents mobiles (propre à eux), et qui inspire ses notations de

l'analyse et de la conception orientée objet (en particulier du langage UML). Néanmoins, un

sérieux problème concernant la relation entre les agents et les objets, se pose.


50

Il serait avantageux d‟intégrer les méthodes formelles dans les activités de

développement des systèmes, en particulier ceux à base d‟agents mobiles, mais ceci présente

une difficulté réelle liée à la manipulation des concepts théoriques et des méthodes d‟analyse

associées, ainsi que la capacité des développeurs d‟exprimer les propriétés du système de

façon aisée.

Dans ce chapitre, nous présentons une panoplie de méthodes formelles et leur

classification. Ensuite nous abordons l‟utilisation et l‟intégration de ces méthodes formelles à

la méthodologie IDM afin d‟augmenter la fiabilité et de garantir l‟absence d‟erreurs de

conception. Dans ce contexte, les réseaux de Petri représentent une technique formelle

largement utilisée. Un intérêt particulier sera porté sur eux. Nous clôturerons ce chapitre, par

la présentation de quelques extensions de RdPs pour la mobilité.

3.1. But de la modélisation

Modéliser un système avant sa réalisation permet de mieux comprendre le

fonctionnement du système. C‟est également un bon moyen de maîtriser sa complexité et

d‟assurer sa cohérence. La modélisation en informatique peut être vue comme la séparation

des différents besoins fonctionnels et préoccupations extra-fonctionnelle (telles que: la

sécurité, la fiabilité, l‟efficacité, la performance, la ponctualité, la flexibilité, etc.)

[Kadima05]. Un modèle est un langage commun, précis, qui est connu par tous les membres

de l‟équipe et il est donc, à ce titre, un moyen privilégié pour communiquer. Cette

communication est essentielle pour aboutir à une compréhension commune pour les

différentes parties prenantes (notamment entre la maîtrise d‟ouvrage et la maîtrise d‟œuvre

informatique) et précise d‟un problème donné [Aud07].

Dans le domaine de l‟ingénierie du logiciel, le modèle permet de mieux répartir les

tâches et d‟automatiser certaines d‟entre elles. C‟est également un facteur de réduction des

coûts et des délais. Par exemple, les plateformes de modélisation savent maintenant exploiter

les modèles pour faire de la génération de code (au moins au niveau du squelette) voir des

allers retours entre le code et le modèle sans perte d‟information.

La réalisation d‟un système fait intervenir en général, toute une équipe de travail. La

communication entre les différents membres de l‟équipe détermine la réussite du projet à

concevoir. Dans ce contexte, Le modèle se définit comme étant un langage commun aux

membres de l‟équipe, qui facilite la communication et la compréhension entre les différentes

parties concernées par le projet. En effet, dans l‟ingénierie du logiciel le modèle permet une

meilleure répartition des tâches entre les différents intervenants. Ceci a un impact direct sur

la réduction des coûts et des délais de réalisation des projets.

Selon les modèles employés, on distingue plusieurs formes de modélisation.


51

3.2. Différentes Formes de Modélisation

La modélisation peut être classée selon le degré du formalisme des langages ou des

méthodes utilisés. Ainsi, la modélisation peut être considérée comme étant formelle, semi-

formelle ou informelle [José]. La table de la figure 3.1 ci-dessous présente une définition des

catégories de langages ainsi que des exemples de langages ou de méthodes utilisés dans la

modélisation.

Catégories de Langages

Langage Informel Langage Semi-Formel Langage Formel

Simple Standardisé

Langage qui

n‟a pas un

ensemble

complet de

règles pour

restreindre une

construction

Langage avec une

structure, un

format et des

règles pour la

composition

d‟une

construction.

Langage qui a une

syntaxe définie pour

spécifier les conditions

sur lesquelles les

constructions sont

permises.

Langage qui possède une

syntaxe et une sémantique

définies rigoureusement.

Il

existe un modèle

théorique

qui peut être utilisé pour

valider une construction.

Exemples de Langages ou Méthodes

Langage

Naturel.

Texte Structuré en

Langage Naturel.

Diagramme Entité-

Relation, Diagramme

à Objets.

Réseaux de Petri,

Machines à états finis,

VDM, Z.

Figure 3.1. Classification et Utilisation de Langages ou de Méthodes [José]

Modélisation Informelle

Selon [José], plusieurs raisons justifient le processus de modélisation informelle à

base de langages informels:

- La facilité de compréhension du langage informel, qui permet des consensus entre les

personnes qui spécifient et celles qui commandent un logiciel.

-Le langage informel représente une manière familière de communication entre les personnes.

Par contre, l‟utilisation d‟un langage informel rend la modélisation imprécise et

parfois ambigüe. Toute tentative de standardisation est difficile, vue le caractère informel de

cette approche. Néanmoins, Il est possible d‟utiliser une Modélisations Informelle plus ou

moins „standardisée‟ pour restreindre ce problème, c‟est-à-dire une modélisation qui utilise

un langage naturel tout en introduisant des règles d‟utilisation de ce langage dans la


52

construction de la modélisation. Un tel type de modélisation garde les avantages de la

modélisation informelle en la rendant moins imprécise et moins ambigüe.

Modélisation Semi-Formelle

Le processus de modélisation semi-formelle est basé sur un langage textuel ou

graphique pour lequel une syntaxe précise est définie [José]. Ce type de modélisation permet

d‟effectuer des contrôles et de réaliser des automatisations pour certaines tâches, bien que La

sémantique des langages Semi-Formels soit souvent assez faible.

Les méthodes de modélisation semi-formelles dans leur majorité, s‟appuient fortement

sur des langages graphiques. Cela, se justifie par l‟expressivité que peut avoir un modèle

graphique bien développé. Le langage textuel est utilisé normalement comme complément

aux modèles graphiques.

Par ailleurs, la modélisation semi-formelle (tels que : UML) utilise fortement les

langages graphiques, ceci permet la production de modèles assez faciles à interpréter.

Néanmoins, les aspects sémantiques impliqués dans cette approche de modélisation souffrent

d‟une remarquable déficience. Afin de pallier aux insuffisances de cette approche,

l‟utilisation de contraintes a été introduite, dans ce contexte, on retrouve à titre d‟exemple les

travaux de S. Cook et J. Daniels [Cook94].

Modélisation Formelle

Les méthodes formelles adoptent un processus de développement rigoureux basé sur

des notations formelles avec une sémantique définie. Les aspects formels se caractérisent par

leurs capacités à exprimer une signification précise, permettant ainsi des vérifications de la

cohérence et de la complétude d‟un système, ceci constitue leur principal avantage. En effet,

et à titre d‟exemple, J. P. Bowen et M. C. Hinchey [Hin95] montrent qu‟avec une traduction

appropriée, les méthodes formelles peuvent aider à la compréhension d‟un système par un

utilisateur. Selon A.Hall [Hall90] les méthodes formelles aident à trouver des erreurs et à

diminuer leur incidence sur la réalisation du projet, à travers une spécification complète qui

peut être appliquée à n‟importe quel type de système, logiciel ou matériel. Elles ne remplacent

cependant pas des méthodes existantes et doivent être utilisées d‟une manière conjointe avec

celles-ci, en effet, si une connaissance mathématique solide est nécessaire pour réaliser des

preuves, elle ne l‟est pas impérativement pour spécifier. L‟utilisation de méthodes formelles

peut provoquer une diminution des coûts et de la durée de réalisation des projets.

Les études pour la création d‟autres outils formels qui couvrent toute la spécification,

outre les outils de preuves déjà existants, montrent l‟intérêt qu‟on porte à ces méthodes. Bien

qu‟elles ne soient pas utilisées dans tous les types de modélisation, L‟application des

méthodes formelles, plus que souhaitable, commence à être imposée par des sociétés dans

certains cas, qui nécessitent plus de rigueur.

3.3. Techniques d’analyse

Les systèmes deviennent de plus en plus complexes, il est donc impératif d‟assurer

certaines performances, et de limiter l‟impact des risques de dysfonctionnement à défaut de

garantir catégoriquement leurs absence. Pour cela, de nombreuses méthodes et techniques ont

été développées pour analyser les systèmes complexes.


53

Vérification

La vérification répond à la question "Construisons-nous correctement le modèle ?" ("is the

system being built right?"). La vérification est l‟ensemble des inspections, tests, simulations,

preuves automatiques, ou autres techniques appropriées permettant d‟établir et de documenter

la conformité des résultats du développement vis-à-vis des critères préalablement établis, a-t-

on atteint ce qu‟on voulait atteindre ? La vérification est définie comme étant "la confirmation

par examen et apport de preuves tangibles (informations dont la véracité peut être démontrée,

fondée sur des faits obtenus par observation, mesures, essais ou autres moyens) que les

exigences spécifiées ont été satisfaites" [ISO 8402].

Validation

La validation cherche à répondre à la question "Construisons nous le bon modèle?" ("is

the right system being built?"). La validation consiste à évaluer si le système développé est

adéquat quant aux besoins exprimés par ses futurs utilisateurs et ce par rapport à des usages

bien spécifiques. Par définition la validation est la "confirmation, par examen et apport de

preuves tangibles, que les exigences particulières pour un usage spécifique prévu sont

satisfaites. Plusieurs validations peuvent être effectuées s‟il y a différents usages prévus" [ISO

8402].

Qualification

Qualifier un modèle c‟est assurer qu‟il peut servir à la communication claire, sans

ambiguïtés ni interprétation secondaire possible entre les activités du projet et/ou entre les

acteurs d‟un groupe de travail.

Certification

Le modèle est certifié, s‟il respecte une norme et peut donc servir de base à

l‟établissement d‟un référentiel réutilisable et générique à un domaine. L‟implication et la

responsabilité d‟un organisme tiers qui reconnaît la pertinence, la rigueur, l‟intérêt du modèle

et garantit ces qualités lors de sa diffusion, est bien évidement sous-entendue.

3.4. Méthodes Formelles

Les méthodes formelles (MFs) sont des techniques basées sur les mathématiques pour

décrire des propriétés de systèmes. Elles fournissent un cadre très rigoureux pour spécifier,

développer et vérifier les systèmes d'une façon systématique, plutôt que d'une façon ad hoc,

afin de démontrer leur validité par rapport à une certaine spécification [Wing90].

L‟absence des incohérences, des contradictions et des failles dans la conception ainsi

que la détermination de la correction l‟implantation d‟un système, sont tous des éléments très

fortement assurés par ces méthodes. Ces méthodes sont désormais, l‟objet de nombreuses

recherches afin d‟élargir leurs champs d‟application.

3.4.1. Les langages formels

L‟utilisation de langages formels, est à la base des méthodes formelles, et ce pour

donner une spécification du système que l‟on souhaite développer à un niveau de détail désiré.

Un langage formel est en effet un langage doté d‟une sémantique mathématique adéquate

basée sur des règles d‟interprétation et des règles de déduction [Petit99, Benzaken91].

Contrairement aux descriptions en langages informels semi-formels, qui peuvent donner

lieu à différentes interprétations, Les règles d‟interprétation dans les langages formels,


54

garantissent l‟absence d‟ambiguïté dans les descriptions produites. Alors que les règles de

déduction quant à elles, permettent de raisonner sur les spécifications pour prouver des

propriétés attendues ou éviter les incomplétudes et les inconsistances.

3.4.2. Les mythes autour des méthodes formelles

Bien qu‟il y ait eu une utilisation significative des méthodes formelles dans les

industries critiques [Hinchey95], elles n‟ont pas été très bien accueillies en général par la

communauté de développement de logiciels [Bloomfield99]. Il y a eu beaucoup d‟idées

fausses à propos des méthodes formelles, dans [Hall90], l‟auteur cite sept mythes à leur sujet:

L‟utilisation des méthodes formelles produit un logiciel parfait : faux, une spécification

formelle est un modèle du monde réel et peut donc inclure des erreurs, des malentendus et

des omissions.

Utiliser les méthodes formelles signifie faire de la preuve de programme : La spécification

formelle d‟un système est valable sans vérification formelle des programmes, car une

analyse détaillée est rigoureusement suivie dans le cycle de développement.

Les méthodes formelles ne sont justifiables que pour les systèmes critiques: L‟expérience

industrielle montre que les coûts de développement peuvent être réduits pour tous les

types de systèmes.

Les méthodes formelles sont pour les mathématiciens: faux, les mathématiques employées

par ces méthodes sont élémentaires.

Les méthodes formelles augmentent les coûts de développement : Non prouvé, il y a un

déplacement des coûts vers les premières étapes.

Les clients ne peuvent comprendre les spécifications formelles: un support d‟explication

en langage naturel, ou le prototypage, peuvent être utilisés.

Les méthodes formelles ne sont utilisées que pour les systèmes triviaux : de nombreux

projets industriels relatifs aux systèmes non-triviaux ont été maintenant, mis en œuvre.

3.4.3. Classification des Méthodes Formelles

Dans la littérature, il existe plusieurs classifications des méthodes formelles. Selon J.M. Wing

[Wing90], on peut distinguer les méthodes:

Orientées opérations pour décrire le fonctionnement du système et son comportement par

des axiomes.

Orientées données pour décrire les états du système

Hybrides en combinant les deux orientations.


55

Figure 3.2. La classification des méthodes formelles

Des trois approches de base, découlent les approches secondaires suivantes :

Basées modèle

Basées logique

Algébriques

Algèbre de processus

Orientées réseaux (graphiques)

a- Approches basées modèle : Dans cette approche. Il n'y a pas de représentation explicite de

la concurrence. Le système est modélisé par la définition explicite des états et des opérations

qui le transforment d'un état vers un autre. Des besoins Non fonctionnels (telles que l'exigence

temporelle) peuvent être exprimée dans certains cas. Exemples de méthodes : Z, VDM, et B.

b- Approches basées logique : Les propriétés du système, y compris les comportements

temporels et probalistiques, peuvent être décrite en utilisant la logique. Le système d‟axiomes

associé à la logique permet de valider ces propriétés. Dans certains cas, un sous-ensemble de

la logique peut être exécuté (par exemple, le système de tempura).La spécification exécutable

est ensuite utilisée pour une simulation et un prototypage rapide. La logique de Hoare,

Dijkstra, logique temporelle… sont quelques exemples de la dite approche.

c- Approches algébriques : On définit ici implicitement des opérations, en reliant leurs

comportement sans définir la signification des états actuels. Similaire à l'approche fondée sur

les modèles, dans le sens ou il n'y a pas de représentation explicite de la concurrence.

Exemples: OBJ, Larch.

d- Algèbre de processus : C‟est dans cette approche, qu‟une représentation explicite des

processus concurrents est autorisée. En effet, les contraintes sur toutes les communications

autorisées et observables entre processus, permettent la représentation du comportement du

système. Exemples: Communicating Sequential Processes (CSP), Lotos, Timed CSP.


56

e- Approches basées graphes Etant faciles à comprendre et, par conséquent, plus accessibles

aux non-spécialistes, les notations graphiques sont très répandues pour la spécification des

systèmes. Cette approche combine des langages graphiques avec la sémantique formelle, ce

qui permet de puiser des avantages de ces deux axes dans le développement de systèmes.

Exemples: Petri Nets, State Charts.

3.4.4. Techniques de vérification formelle

Habituellement, on distingue deux grandes familles de techniques pour vérifier

formellement la correction d‟un système. La premiere technique est appelée vérification de

modèles, ou model-checking, et consiste à construire un modèle à partir d‟une description

formelle d‟un système. En second lieu, les techniques de preuve (theorem proving) qui sont

des démonstrations mathématiques au sens propre du terme vue que la vérification des

propriétés est effectuée par déduction à partir d‟un ensemble d‟axiomes et de règles

d‟inférences.

3.4.4.1. Vérification de modèles (Model-Checking)

Construire un modèle fini d‟un système et vérifier qu‟une propriété cherchée est vraie

dans ce modèle est à la base de la technique de vérification de modèles. Dans le model-

checking, on peut procéder de deux manières pour la vérification: vérifier qu‟une propriété

exprimée dans une logique temporelle est vraie dans le système, ou comparer (en utilisant une

relation d‟équivalence ou de préordre) le système avec une spécification pour vérifier si le

système correspond à la spécification ou non. Le model-checking est complètement

automatique et rapide, et ce contrairement au theorem proving. Il peut être utilisé pour aider le

débogage en produisant des contre-exemples qui représentent des erreurs subtiles dans la

conception.

3.4.4.2. Preuve de théorèmes (Theorem proving)

Dans cette technique, le système et les propriétés recherchées sont exprimés comme

des formules dans une logique mathématique, qui est décrite par un système formel qui définit

un ensemble d‟axiomes et de règles de déduction. Partant des axiomes du système, la preuve

de théorèmes, constitue le processus de recherche de la preuve d‟une propriété. Des appels

aux axiomes et aux règles, ainsi qu‟aux définitions et lemmes qui ont été possiblement

dérivés, sont fait durant Les étapes de recherche de la preuve. Contrairement au model-

checking, le theorem proving peut s‟utiliser avec des espaces d‟états infinis à l‟aide de

techniques comme l‟induction structurelle. Le processus de vérification, dans cette technique,

peut être lent, sujet à l‟erreur, demande beaucoup de travail et des utilisateurs spécialisés avec

beaucoup d‟expertise, ceci constitue son principal inconvénient.

3.5 Combinaison d’IDM avec les Méthodes Formelles

L'utilisation des méthodes formelles (MFs) s‟avère désormais, essentielle pour le

développement de systèmes complexes, notamment pour les systèmes critiques où les

questions liées à la sûreté/fiabilité sont cruciales. D‟un autre côté, l‟IDM a atteint niveau de

maturité assez important. En effet, elle est devenue une nouvelle démarche en génie logiciel

capable de concevoir, l‟intégralité du cycle de développement en se basant sur la méta-

modélisation et transformation de modèles. On note néanmoins que chacune des deux

approches a des points forts et d‟autres faibles.

Il serait donc intéressant de voir comment ces deux approches peuvent être combinées.

La suite de cette section, montre comment les inconvénients des méthodes formelles peuvent


57

être surmontés grâce aux apports de l‟IDM et réciproquement. La Figure 3.3, représente

brièvement les avantages et les inconvénients de l‟IDM et des MFs [Gargantini09].

Figure 3.3. Les MFs & IDM

Avantages des MFs. Un modèle abstrait du système peut servir de support pour s‟assurer

que le système en cours de développement répond aux exigences des clients, par

simulation ou tests, et garantir certaines propriétés liées à son comportement par l'analyse

formelle (validation et vérification). Pour cela, l'utilisation des méthodes formelles dans

l'ingénierie des systèmes devient indispensable, surtout dans les phases amont du

développement.

Inconvénients des MFs. Malgré que les applications des méthodes formelles ont envahi

le monde industriel et avec de bons résultats, les développeurs hésitent encore à les

adopter. Outre leur difficulté d‟utilisation et d‟apprentissage, cette réserve est

principalement dû à:

1) Les techniques formelles utilisent des notations complexes par rapport à d'autres

notations intuitives et graphiques utilisées par les langages semi-formels comme le

langage UML.

2) Le manque de l‟assistance aux développeurs dans leurs démarches de

développement de manière transparente à cause de l‟absence de support outillé.

3) Les différentes méthodes formelles ne sont pas intégrées à leurs outils d‟analyses

adjacents.

Avantages de l’IDM. L'automatisation du processus de développement des systèmes est

de plus en plus assurée par l‟approche IDM. Des représentations du système dans cette

approche, se font à un haut niveau d‟abstraction associé aux modèles. Par la suite, le

processus de développement, revient à raffiner, maintenir, et éventuellement transformer

vers d‟autres modèles ou à générer le code exécutable. Il est impératif de noter que ces

différentes activités se font d‟une manière automatique. En outre, et étant le concept clé de

l‟approche IDM, la méta-modélisation, permet de donner à un langage de modélisation

une notation abstraite, ce qui permet de générer automatiquement l‟éditeur qui lui est

associé. Afin de réduire la complexité et d'exprimer efficacement les concepts du

domaine, la métamodélisation de langages, est de plus en plus adoptée pour des domaines

spécifiques.


58

Inconvénients de l’IDM. La définition de la sémantique d‟un langage par un méta-

modèle reste une question ouverte, cruciale et non maitrisée. alors que la définition d'une

syntaxe abstraite de ces langages est bien maîtrisée et supportée par de nombreux

environnements de métamodélisation. Actuellement, ces environnements, sont en mesure

de faire face à la plupart des problèmes de définition syntaxique, mais ils ne peuvent pas

fournir la sémantique des méta-modèles par manque de supports rigoureux permettant de

le faire. De ce fait, les langages définis par la métamodélisation ne permettent pas

l'analyse formelle des modèles qu‟ils produisent, car leur sémantique est généralement

donnée dans un langage naturel.

Des défis importants se présentent donc aux MFs, on en cite: L'absence de notations

conviviale, le manque d'intégration des différentes techniques formelles et de

l‟interopérabilité de leurs outils. Ceci peut être en partie réglé par l'IDM qui permet, par le

biais des notions de méta-modèle et de transformation de modèles, de concevoir des supports

outillés pour les méthodes formelles et d‟assurer leur interopérabilité. Ceci dit, l‟IDM

n‟apporte pas un plus sur le plan théorique, aux concepts d‟analyse formelle, mais elle peut

permettre de profiter pleinement de leurs avantages en leur assurant une meilleure intégration.

3.6. Réseaux de Petri

3.6.1. Introduction

Les systèmes dynamiques ne peuvent pas être décrits en ne prenant en compte que

leurs états initiaux et finaux. En effet, on doit tenir compte de leur comportement permanent

qui est une séquence d'états, pour qu‟on puisse parler d‟une description bien fondée. Parmi le

grand nombre des techniques formelles qui ont déjà été proposées pour spécifier, analyser et

vérifier ce genre de systèmes, Les réseaux de Petri sont l‟une des plus utilisés.

Carl Adam Petri a introduit le formalisme des réseaux de Petri [Tran05], dans sa thèse

"Communication avec des Automates" à l‟université Darmstadt en Allemagne, en 1962. Un

peu plus tard et au début des années 70s, ce travail a été développé par Anatol W. Holt, F.

Commoner, M. Hack et leurs collègues dans le groupe de recherche de Massachussetts

Institute Of Technology (MIT). En 1975 MIT organise la première conférence sur les réseaux

de Petri et les méthodes relationnels. Par la suite, J. Peterson a publié en 1981, le premier

ouvrage sur les réseaux de Petri .

Le formalisme des réseaux de Petri (RdP) a été proposé comme un outil mathématique

permettant la modélisation des systèmes dynamiques à événements discrets. Les réseaux de

Petri offrent un outil formel avec une bonne représentation graphique permettant de modéliser

et d‟analyser les systèmes discrets, notamment les systèmes concurrents et parallèles.

Grace à leur facette graphique, les réseaux de Petri, aident à comprendre facilement le

système modélisé. En outre, les activités dynamiques et concurrentes des systèmes sont

aisément simulées, par les RDP, vue leur puissance d‟expression mathématique. L‟intérêt

primordial de ces réseaux réside dans leur possibilité d'analyser les systèmes modélisés. En


59

effet, Ce formalisme bénéficie d‟une multitude de techniques d‟analyse et d‟outils. Des

caractéristiques importantes du système concernant sa structure et son comportement

dynamique sont révélées suite à l‟analyse du réseau de Petri qui le modélise. Les résultats de

cette analyse sont utilisés pour évaluer le système, une évaluation qui permettra ainsi, sa

modification ou son amélioration. La figure 3.4 montre la méthode générale basée sur le

formalisme des réseaux de Petri pour la modélisation et l‟analyse des systèmes.

Figure 3.4. Méthode générale de modélisation et d‟analyse basée sur les réseaux de Petri.

Les réseaux de Petri sont des outils de modélisation utilisés généralement en phase

préliminaire de conception de système afin de réaliser leur spécification fonctionnelle,

modélisation et suivre leur évaluation. Grâce à leur expressivité et à leur souplesse, ils sont

utilisés dans une large variété de domaines Ils permettent notamment :

¤ La modélisation des systèmes informatiques,

¤ L‟évaluation des performances des systèmes discrets, des interfaces homme-machine,

¤ La commande des ateliers de fabrication,

¤ La conception de systèmes temps réel

¤ La modélisation des protocoles de communication,

¤ La modélisation des chaines de production (de fabrication),

¤ ...

En fait, tout système dans lequel circule objets et information peut être modélisé par les RdP,

dont les atouts sont :


60

¤ Ils permettent de décrire de manière précise mais non formelle la structure d‟un

système,

¤ Ils offrent un support graphique de conception,

¤ Ils permettent de décrire un système étape par étape, en décomposant en éléments plus

simples les éléments constitutifs initiaux du système,

¤ Ils permettent de décrire à l‟aide d‟un même support de base, à la fois la structure et la

dynamique d‟un système,

¤ Ils permettent de passer d‟une description graphique d‟un système à une description

formelle permettant l‟analyse mathématique du système.

3.6.2 Concepts de base & définition

3.6.2.1 Définitions informelles

Intuitivement, un réseau de Petri est un graphe orienté biparti (ayant deux types de

noeuds) : des places représentées par des cercles et des transitions représentées par des

rectangles. Les arcs du graphe ne peuvent relier que des places vers des transitions, ou des

transitions vers des places (pas d‟arcs reliant les places ni d‟arcs entre transitions). Un

exemple de réseau de Petri est illustré par la figure 3.5.

Un réseau de Petri décrit un système dynamique à événements discrets. Les états

possibles du système (qui sont discrets), sont décrits par les places. Les transitions quant à

elles, permettent la description des événements ou des actions qui causent le passage du

système d‟un état vers un autre.

Figure 3.5. Un réseau de Petri comportant

7 places, 8 transitions et 17 arcs orientés

Condition L‟état du système peut être vu comme un ensemble de conditions qui sont de ce fait,

des prédicats ou des descriptions logiques d‟un état du système. Une condition est soit vraie

soit fausse.


61

Evénement

Les actions se déroulant dans le système définissent Les événements. L‟état du

système conditionne le déclenchement d‟un événement.

Déclenchement, pré-condition, post-condition

Les pré-conditions de l‟événement sont les conditions nécessaires au déclenchement

de celui-ci. Quand un événement se produit, certaines de ses pré-conditions peuvent cesser

d‟être vraies alors que d‟autres conditions (post-conditions de l‟événement), deviennent

vraies.

Le Marquage d’un réseau de Petri

Un réseau de Petri permet de décrire la dynamique du système représenté, étant donné

que c‟est un graphe muni d‟une sémantique opérationnelle, c‟est-à-dire qu‟un comportement

est associé au graphe. Pour cela, on associe un troisième élément: les jetons, aux places. À un

instant donné, une répartition des jetons dans les places est appelée marquage du réseau de

Petri. Grace au marquage d‟un réseau de Petri, l'état du système modélisé par ce réseau est

défini. Le marquage consiste à placer initialement un nombre mi entier (positif ou nul) de

jetons dans chaque place Pi du réseau. Le marquage du réseau sera défini par un vecteur M =

{mi} (cf. la figure 3.6).

Pour un marquage donné, une transition peut être sensibilisée ou non. Si chacune des

places en entrée d‟une transition contient au moins un jeton, elle est sensibilisée. Pour un

marquage donné, L‟ensemble des transitions sensibilisées défini l‟ensemble des changements

d‟états possibles du système depuis l‟état correspondant à ce marquage. C‟est un moyen de

définir l‟ensemble des événements auxquels ce système est réceptif dans cet état.

Figure 3.6. Un réseau de Petri marqué avec un vecteur

de marquage M : M = (1,0,1,0,0,2,0).

3.6.2.2 Définitions formelles

Formellement, un réseau de Petri (R) est un triplé R= (P, T, W) où P est l'ensemble des

places (les places représentent les conditions) et T l'ensemble des transitions (les transitions


62

représentent les événements ou les actions) tel que P ∩ T =φ et W est la fonction définissant le

poids porté par les arcs où W : ((P ×T) ∪ (T × P)) → N= {0, 1, 2,…}.

Le réseau R est fini si l'ensemble des places et des transitions est fini, c-à-d |P ∪T|∈N.

Un réseau R = (P, T, W) est ordinaire si pour tout (x, y) ∈ ((P ×T) ∪(T × P)):

W(x, y) ≤ 1.

Pour chaque x∈ P ∪T :

*x représente l'ensemble des entrées de x : *x= {y∈P∪T/W (y, x) ≠ 0}

x* représente l'ensemble des sorties de x : x* = {y ∈ P ∪T/W(x, y) ≠ 0}

Remarque

Si *x=φ, x est dite source, si x*=φ, x est dite puits.

Pour exprimer l'état d'un réseau de Petri, les places peuvent contenir des jetons qui ne

sont que de simples marques (points noirs). La structure et l‟état d'un réseau de Petri,

déterminent son comportement.

Notion d’état dans un réseau de Petri

Dans la théorie des réseaux de Petri, l'état d'un réseau est souvent appelé marquage

du réseau. Il est défini par l‟association des jetons aux places. Le marquage d'un réseau de

Petri R= (P, T, W) est défini par la fonction de marquage M : P→ N.

Un réseau de Petri marqué est donné par Σ = (P, T, W, M0) où M0 est le marquage

initial. La règle de franchissement définit le comportement d'un réseau de Petri marqué.

Notion de changement d’état et de règle de franchissement

Le mouvement de jetons des places d‟entrée vers les places de sortie d‟une transition,

traduit le changement d’état du système. Ce mouvement est causé par le franchissement d‟une

transition. Le franchissement représente une occurrence d‟un événement ou d‟une action. La

présence de jetons dans les places d‟entrée de la transition, conditionne son franchissement.

Quand toutes les places en entrée d‟une transition sont suffisamment marquées, la

transition peut être tirée, suite à ce tir ou franchissement, les jetons sont retirés des places en

entrée (ancien état) et ajoutés aux places en sortie (Nouvel état) de la transition franchie.

La relation de transition qui définit le changement d'état dans un réseau marqué lors de

l'exécution d'une action, est appelée règle de franchissement. La formalisation de la possibilité

d‟exécution d‟une action définit la règle de franchissement: on dit qu'une transition t ∈T peut

être franchie à partir d'un marquage M (qui représente l'état du system à un instant donné) si

et seulement si chaque place d'entrée p ∈*t de la transition t contient au moins un nombre de

jetons qui est supérieur ou égale au poids de l'arc reliant cette place d'entrée p à la transition t,

tel que: M (p) ≥W(p, t) ∀ p ∈ P.

Une règle de franchissement est définie par M‟(p) = M (p) - W(p, t) + W (t, p) pour

tout p ∈P, ceci traduit le fait que, lorsque la transition t est franchie à partir d'un marquage


63

M, il faut retirer W(p, t) jetons à partir de chaque place en entrée à la transition t et ajouter

W(t, p) jetons dans chaque place en sortie de la transition t ce qui permet de produire un

nouveau marquage M'. Le franchissement d'une transition t, dénoté par M [t > M’, est appelé

occurrence de t.

Exécution d'un réseau de Petri : Notion de marquage

L'exécution d'un réseau de Petri est définie par un ensemble de séquences

d'occurrence. Une séquence d'occurrence est une séquence de transitions franchissables

dénotée par σ =M0 t1 M1 t2…tel que Mi -1 [ti > Mi. Une séquence t1 t2… est une séquence

de transitions (commencée par le marquage M) si et seulement si il existe une séquence

d'occurrence M0 t1 M1... avec M=M0. Si la séquence finie t1 t2 …tn conduit à un nouveau

marquage M‟, à partir du marquage M, on écrit M [t1 t2…tn > M‟ ou simplement

M[t1t2…tn> si on ne veut pas spécifier le marquage résultat.

L'ensemble de marquages accessibles d'un réseau marqué (P, T, W, M0) est défini par

[M0 > = {M ∃t1 t2…tn: M0 [t1t2…tn > M}.

Exemple:

Dans le cas des réseaux dits à arcs simples ou de poids égal à 1 (cf. la figure 3.7), Le

franchissement d'une transition consiste à retirer un jeton dans chacune des places d‟entrée de

la transition et à en ajouter un dans chacune de sorties de places de celle-ci.

Figure 3.7. Evolution d‟états d'un réseau de Petri [Claud01]

L'évolution des états d‟un réseau de Petri marqués simple obéit aux règles suivantes :

Quand chacune des places en entrées d‟une transition, possède au moins le nombre de

jetons correspondant au poids de l‟arc la reliant à cette transition, on dit que la

transition est franchissable (sensibilisée ou tirable).

lorsque plusieurs transitons sont validées, le réseau ne peut évoluer que par

franchissement d'une seule transition sélectionnée à la fois.

Le franchissement d'une transition est indivisible et de durée nulle.

On voit donc, que dans l'évolution des réseaux de Petri, ceux-ci peuvent passer par

différents états dont l'apparition est conditionnée par le choix des transitions tirées. D‟où


64

l‟indéterminisme introduit par ces règles. Ceci cadre bien avec les situations réelles où il n'y a

pas de priorité dans la succession des événements [Claud01].

Représentation matricielle

Les tâches d'analyse et de vérification effectuées sur un modèle RdP peuvent être

simplifiées, grâce à la représentation matricielle d'un RdP. En ffet, manipule une

représentation graphique d'un modèle RdP est une tâche délicate comparée à une

représentation matricielle. Il est également possible, de représenter la fonction W (fonction de

poids) par des matrices.

Définition

Soit Un réseau de Petri R= (P, T, W) avec P= {p1, p2, …, pm} et T= {t1, t2, …, tn}.

On appelle matrice des pré-conditions pré, la matrice m × n à coefficients dans N telle que

pré (i,j)= W(pi, tj) indique le nombre de marques que doit contenir la place pi pour que la

transition tj devienne franchissable. De la même manière on définit la matrice des post-

conditions post, la matrice m × n telle que post (i,j)= W(pi, tj) contient le nombre de marques

déposées dans pi lors du franchissement de la transition tj. La matrice C= post – pré est

appelée matrice d'incidence du réseau (m représente le nombre de places d'un réseau de Petri

et n le nombre de transitions).

Le marquage d'un réseau de Petri est représenté par un vecteur de dimension m à coefficients

dans N. La règle de franchissement d'un réseau de Petri est définie par :

M’ (p) =M (p) + C (p, t).

Exemple

Figure 3.8. Un réseau de Petri marqué avec un vecteur

de marquage M : M = (1,0,0,0).

Pour le réseau ci-dessus (cf. la figure 3.8) , P= {p1, p2, p3, p4} T= {t1, t2, t3}, la

représentation matricielle est donnée ci-dessous (cf. la figure 3.9).


65

Figure 3.9. Matrice d‟incidence et vecteur de marquage du RdP de la figure 3.8.

Sémantique du parallélisme et problème de conflits

Quand plusieurs transitions peuvent être franchissables à un moment donné dans un

réseau de Petri, on parle de parallélisme de tir des transitions. Cet aspect pose un problème de

choix pour l‟état futur du réseau qui dépend de la transition sélectionnée parmi toutes celles

offertes. En général, ce conflit est résolu par le choix d‟une sémantique dite du parallélisme

qui définit une stratégie de tir, exemple : tirer une seule transition à la fois.

3.6.3 Modélisation des systèmes complexes

Les RdPs permettent de modéliser un certain nombre de comportements importants

dans les systèmes complexes tels que le parallélisme, la synchronisation, le partage de

ressources, la mémorisation et la lecture d‟information, la limitation d‟une capacité de

stockage, etc.

3.6.3.1 Parallélisme

Le parallélisme représente la possibilité que plusieurs processus évoluent simultanément

au sein du même système. Une transition ayant plusieurs places en sortie, peut provoquer le

départ simultané de l‟évolution plusieurs processus. Le franchissement de la transition T1 met

un jeton dans la place P2 (ce qui marque le déclenchement du processus 1) et un jeton dans la

place P3 (ce qui marque le déclenchement du processus 2).

Figure 3.10. Structure du parallélisme


66

3.6.3.2 Synchronisation

La synchronisation est modélisée sous deux formes :

Synchronisation mutuelle (Par rendez-vous) : La synchronisation mutuelle ou par

rendez-vous permet de synchroniser les opérations de plusieurs processus qui se

retrouvent au niveau d‟une transition donnée. La Figure 3.11 montre un exemple

de deux processus. Le franchissement de la transition T7 ne peut se faire que si la

place P12 du processus1 et la place P6 du processus 2 contiennent chacune au

moins un jeton. Si ce n‟est pas le cas, par exemple la place P12 ne contient pas de

jetons, le processus 2 est bloqué sur la place P6; il attend que l‟évolution du

processus 1 soit telle qu‟au moins un jeton apparaisse dans la place P12.

Figure 3.11. Synchronisation mutuelle

Synchronisation par signal (sémaphore): Dans ce type de synchronisation,

l‟évolution d‟un processus est conditionnée par celle d‟un autre. Dans l‟exemple

de la figure 3.12, les opérations du processus 2 ne peuvent se poursuivre que si le

processus 1 a atteint un certain niveau dans la suite de ses opérations. Par contre,

L‟avancement des opérations du processus 1 ne dépend pas de l‟avancement des

opérations du processus 2. Si la place "Signal" est marquée et la place "Attente" ne

l‟est pas, cela signifie que le processus 1 a envoyé le signal mais le processus 2 ne

l‟a pas encore reçu. Si, par contre, la place "Signal" n‟est pas marquée et que la

place "Attente" est marquée, cela signifie que le processus 2 est en attente du

signal.

Figure 3.12. Synchronisation par sémaphore


67

3.6.3.3. Partage de ressources

C‟est un type de modélisation lié à un système au sein duquel plusieurs processus

partagent une même ressource en utilisant le principe de l‟exclusion mutuelle. Dans la Figure

3.13, Le jeton dans la place P0 présente une ressource mise en commun entre le processus 1 et

le processus 2. Le franchissement de la transition T17 lors de l‟évolution du processus 1

entraîne la consommation du jeton présenté dans la place P0. La ressource que constitue ce

jeton n‟est alors plus disponible pour l´évolution du processus 2. Lorsque la transition T18 est

franchie, un jeton est alors est placé dans la place P0 : la ressource devient alors disponible

pour l‟évolution des deux processus.

Figure 3.13. Synchronisation par Partage de ressources

3.6.4 Méthodes d'analyse pour les réseaux de Petri

L‟utilité majeure de la modélisation des systèmes est la possibilité d‟analyser leurs

propriétés. Les réseaux de Petri offrent des techniques d'analyse puissantes pour valider des

modèles de comportement de systèmes à événements discrets. Parmi lesquelles, nous citons le

graphe de marquages, l‟équation de matrice et la réduction des réseaux de Petri.

3.6.4.1Analyse par graphes des marquages

Une idée intuitive pour étudier les propriétés d‟un RdP est de construire le graphe de

tous ses marquages accessibles. Le graphe des marquages accessibles est un graphe dont

chaque sommet correspond à un marquage accessible et dont chaque arc correspond au

franchissement d‟une transition permettant le passage d‟un marquage à l‟autre. On dénote

deux situations :

1. Le graphe est fini. C‟est le cas de figure le plus favorable car dans ce cas toutes les

propriétés peuvent être déduites simplement par inspection de ce graphe.

2. Le graphe est infini. Dans ce cas, et pour déduire certaines propriétés, on est

amenés à construire un autre graphe appelé "graphe de couverture".


68

Exemple 1

Figure 3.14. (a) Réseau de Petri (b) Graphe des marquages fini

Exemple 2

Figure 3.15. (a) Réseau de Petri (b) Graphe des marquages infini

3.6.4.2 L’équation de matrice

Cette méthode consiste à trouver une représentation matricielle du réseau, les

techniques de l'algèbre linéaire permettent alors d‟obtenir les propriétés structurelles du

réseau.

3.6.4.3 La réduction des RdPs

Pour l‟analyse des propriétés d‟un RdP de taille significative, l‟utilisation du graphe de

marquage ou de l‟équation de matrice s‟avère insuffisante. L‟objectif de la technique par

réduction est de présenter des règles permettant d‟obtenir à partir d‟un RdP marqué, un RdP

marqué équivalent mais plus simple, avec un nombre réduit de places et de transitions. Les méthodes d‟analyse des réseaux de Petri prennent pleine puissance avec leurs

mise en œuvre par le biais d‟un ensemble d‟outils d‟analyse tels que : INA (Integrated

NetAnalyzer) [INA], PEP (Programming Environment based on Petrinets) [Pep], TINA

[Tina],etc …


69

3.6.5 Extensions des réseaux de Petri

Les systèmes réel impose beaucoup de contraintes, Leur modélisation peut donc

engendrer des réseaux de Petri de taille importante dont la manipulation et l‟analyse est très

difficile. En plus, les RdPs usuels ne permettent pas d‟exprimer certaines propriétés, telle que

la mobilité, rendant ainsi leur analyse assez difficile. Dans ce contexte, plusieurs extensions

de réseaux de Petri ont vu le jour, entre autres on a: les réseaux de Petri colorés [Jensen 97,

Jensen98], Les ECATNets [Bettaz92, Bettaz93], etc. Dans la section suivante, nous

présentons un aperçu de quelques extensions des Rdps.

3.6.5.1. Les réseaux de Petri colorés

Les jetons placés dans les états du réseau seront colorés, ce qui permettra de les

distinguer et augmentera ainsi, l‟expressivité d‟un RdP. Ce procédé de marquage permet de

distinguer les jetons d‟un même état. Cette information permet de distinguer des jetons entre

eux et peut être de type quelconque [Kurt 97]. Ainsi, les arcs ne sont pas seulement étiquetés

par le nombre de jetons mais par leurs couleurs. Le franchissement d‟une transition est alors

conditionné par la présence dans les places en entrée du nombre de jetons nécessaires, qui en

plus satisfont les couleurs qui étiquettent les arcs. Après le franchissement d‟une transition,

les jetons qui étiquettent les arcs d‟entrée sont retirés des places en entrée tandis que ceux qui

étiquettent les arcs de sortie sont ajoutés aux places en sortie de cette transition. Les réseaux

colorés n‟apportent pas de puissance de description supplémentaire par rapport aux réseaux de

Petri, ils permettent juste une condensation de l‟information.

L‟exemple ci-dessous représente un système de production constitué d‟une première

machine avec son stock en sortie limité à 3 produisant la pièce a et d‟une seconde machine

avec son stock en sortie limité à 3 produisant la pièce b. Le passage du RdP (Figure 3.16

gauche) au RdP coloré (Figure 3.16 droite) est appelé pliage et le passage du RdP coloré au

RdP dépliage.

Figure 3.16. RdP (gauche) et RdP coloré (droite) [Scor06]

3.6.5.2 Les réseaux de Petri synchronisés (RdPS)

Dans les modélisations RdPS que nous avons vues précédemment, le fait qu‟une

transition soit franchissable indique que toutes les conditions sont réunies pour qu‟elle soit

effectivement franchie. Le moment où se produira le franchissement n‟est pas connu.


70

Un RdP synchronisé est un RdP où à chaque transition est associée un événement. La

transition sera alors franchie si elle est validée et en plus, quand l‟événement associé se

produit.

Dans un RdP synchronisé, une transition validée n‟est pas forcement franchissable. La

transition est validée quand la condition sur les marquages est satisfaite. Elle deviendra

franchissable quand l‟événement externe associé à la transition se produit : elle est alors

immédiatement franchie. Si en fonction du marquage de ses places d‟entrée, plusieurs

franchissements sont possibles, un seul se produira effectivement, celui dont l‟événement

associé se produit en premier [Scor06].

3.6.5.3. Les réseaux de Petri temporisés

Dans les réseaux de Petri temporisés introduits par Ramchandani [RAM 74], la durée

d‟une activité est explicitement intégrée. La temporisation peut concerner les places (réseaux

de Petri P-temporisés) aussi bien que les transitions (réseaux de Petri T-temporisés) et ce en

fonction des événements modélisés. Pour les réseaux de Petri P-temporisés. La temporisation

représente alors la durée minimale de tir ou le temps de séjour minimum d‟un jeton dans une

place.

Dans ce qui suit, nous porterons une attention particulière aux réseaux de Petri

étendus pour modéliser la mobilité, vu que dans cette thèse, nous nous intéressons aux

systèmes à base d‟agents mobiles.

3.6.6. Modélisation des systèmes mobiles par les RdPs

La mobilité, a soulevé depuis longtemps de nombreuses questions difficiles

[Kohler02], même La modélisation des systèmes mobiles par les RdPs ordinaires ou étendus

tel que les RdPs colorés est désormais insuffisante, à cause des particularités des applications

mobiles (migration clonage, etc.). Ainsi, l‟introduction de nouvelles extensions aux RdPs,

s‟avère plus que nécessaires pour modéliser les applications mobiles. En effet, tout

récemment, un modèle qui capture la mobilité d'une manière élégante et intuitive, a été

proposé. Un modèle qui est capable d'exprimer les différents types de mobilité des agents et

qui est fondé sur un formalisme dont la sémantique est formelle, autorisant par conséquent, la

vérification de l'exécution de ces systèmes mobiles. un tel modèle, est fondé sur le paradigme

des réseaux dans les réseaux (nets within nets en anglais) qui généralise la notion de jeton

classique à des jetons schématisant des réseaux de Petri.

3.6.6.1. Le paradigme (nets-within-nets)

Le paradigme nets-within-nets [Kohler07] est un formalisme qui fournit une nouvelle

technique de modélisation, en effet l‟idée astucieuse qui donne aux jetons mêmes du réseau

la structure d'un réseau de Petri (Figure 3.17), est innovante. La passivité des jetons dans les

autres types de réseaux de Petri, est levée par les jetons dans les nets-within-nets, qui sont eux

actifs. La notion de jeton dans ce paradigme permet de modéliser les systèmes récursifs et

hiérarchiques de façon simple. En outre, la modélisation des systèmes adaptatifs et mobiles

est tolérée par ce paradigme.

Dans l‟exemple de la Figure 3.17 du réseau de Petri nets-within-nets, nous considérons

la situation où nous avons une hiérarchie à deux niveaux. Un niveau inférieur qui s'appelle

System Nets (le RdP à ce niveau est formé de places contenant des jetons qui sont aussi des


71

RdPs) et un niveau supérieur qui s'appelle object nets (les places dans le RdP à ce niveau

contiennent des jetons simples). La place P1 de System Nets de la figure 3.17 contient un

Object Nets (Le RdP dont les places sont b1 et b2).

Figure 3.17. Un exemple d'un RdP Nets-within-Nets [Kohler07]

Le franchissement d'une transition dans le niveau inférieur peut être synchronisé par le

franchissement d'une transition dans le niveau supérieur. Dans l‟exemple de la figure 3.4, la

transition t n'est franchissable que lorsque la transition e est franchissable. Cette

synchronisation se fait par des fonctions qui s'appellent down-link et up-link :

Le down-link est la fonction qui mène la transition du niveau inférieur (System

Nets).

Le up-link est la fonction qui mène la transition du niveau supérieur (Object Nets).

Le franchissement de la transition t donne lieu à la situation de la Figure 3.18.

Figure 3.18. Un exemple d'un RdP Nets-within-Nets après franchissement.

L‟interaction entre les Object Nets et les Système Nets induit quatre possibilités pour

contrôler le type de déplacement et par conséquent la mobilité des Object Nets, on distingue

donc, pour un agent donné, quatre possibilités de se déplacer ou de se faire déplacer, tableau

3.1.

L‟Object Net déclenche son propre mouvement dans le Système Nets. dans cette situation

le Système Nets n‟aura aucune influence sur la mobilité des Object Nets (mobilité

subjective).

Le Système Nets force l‟Object Net à se déplacer, dans cette situation l‟Object Net subit

une transportation forcée.

L‟Object Net et le Système Net parviennent à un accord pour la mobilité de l‟Object Net.

L‟Object Net se déplace à l‟intérieur du System Net. Dans cette situation le mouvement de

l‟Object net est non contrôlé (mobilité spontanée).

b1

P1 P2 t

ON : ch()

ON ON

b2

e

: ch(x)

x

P1 P2 t

ON : ch(5)

ON ON

b2

e

: ch(x=5)

5

b1


72

Tableau 3.1. Les types de mobilité.

3.6.6.2. Le paradigme (Nested Nets)

Ce paradigme est basé sur l‟idée introduite par le paradigme nets-within-nets en se

basant sur l'étude d‟une sémantique autre que la sémantique de référence. En effet, dans ce

paradigme aussi (Nested Nets), chaque jeton peut être un réseau de Petri. Pour modéliser les

systèmes adaptatifs et mobiles [Kees06], les nested nets trouvent bien leur place.

Ce paradigme est une extension des RdPs colorés dont les jetons peuvent changer de

couleur sans le franchissement de transitions [Kees06], (cf. la figure 3.19).

Figure 3.19. Nested Nets [Kees06]

3.7. Conclusion

La modélisation, vérification et validation des systèmes informatiques constituent

aujourd'hui un enjeu crucial. C'est en particulier le cas pour les systèmes critiques dont les

pannes peuvent avoir des conséquences irréversibles et néfastes sur leur environnement

(système mobile par exemple). Dans ce cadre, nous avons présenté dans ce chapitre, les

concepts fondamentaux des techniques formelles de modélisation, vérification et validation

des systèmes. Nous avons insisté sur les réseaux de Petri, qui sont un formalisme de

modélisation. Ils représentent un cadre formel de spécification des systèmes grâce à leur

sémantique. Un grand avantage de l‟utilisation des réseaux de Petri est leur force

d‟expressivité due à leur aspect graphique. Nous avons abordé dans un cadre général la

modélisation par les réseaux de Petri. Par la suite, nous avons étudié quelques types de RdPs

avec leurs variantes. Nous avons également introduit une brève présentation des extensions de

RdPs pour la mobilité.

73

Chapitre 4

Une Plateforme Formelle pour la Modélisation

et la Simulation des LRN

Les outils formels qui ont été utilisées pour modéliser et analyser des systèmes

classiques, ne peuvent supporter les propriétés des systèmes à code mobile [Fuggetta98].

Beaucoup de travaux sur les outils formels tentent d‟étendre les outils classiques afin qu‟ils

puissent traiter la mobilité du code. L‟algèbre de processus basée modèles (π-calcul

[Milner92], join-calcul [Fournet02], HOπ-calcul [Sangiorgi01] par exemple), les PrN

(Predicate/Transition nets) [Xu00] et les modèles de transition basés État (Petri nets par

exemple), sont parmi eux. Afin d‟éviter le développement ad-hoc des systèmes a code

mobile, plusieurs travaux ont proposé des méthodologies et approches ([Duran00],

[Berger05], [Athie03]…) qui visent à résoudre ce problème.

Pour modéliser la mobilité, certains réaux de Petri de haut niveau ont été proposés.

Les plus connus sont les Réseaux Mobiles (variante de réseaux de Petri colorés) [Asperti96].

Beaucoup d'extensions ont été proposées pour adapter les mobiles Petri nets a des systèmes

mobiles spécifiques, tels que : Elementary Object Nets [Valk98], labeled reconfigurable nets

[Kahloul07], Nested Petri Nets [Kees06] [Lomazova02], Hyper Petri Nets [Bednarczyk04]…

Dans [Bahri2-09], les auteurs ont proposé une approche pour transformer diagrammes

mobiles UML Statechart vers des modèles Nested nets et ce dans le but de l'analyse, Elle

produit des modèles graphiques très structurés, et rigoureusement analysables qui facilite la

détection précoce des erreurs comme le blocage, incohérences, etc … Leur approche est basée

sur la transformation de graphe puisque l'entrée et la sortie du processus de transformation

sont des graphes. Ils ont utilisé l‟outil de méta-modélisation ATOM3.

Dans [El Mansouri08], les auteurs ont fourni un environnement graphique pour l'outil

Petri net INA [INA]. Tout d'abord, ils ont proposé un méta-modèle pour les modèles de

réseaux de Petri et l'ont utilisé dans l‟outil de méta-modélisation ATOM3 pour générer

automatiquement un environnement de modélisation visuelle pour définir les modèles à être

analyser par l‟outil INA. Puis, ils ont défini une grammaire de graphes pour traduire les

modèles créés en une description textuelle en langage INA, ensuite, INA est utilisé pour

effectuer l'analyse des spécifications générées.

Dans [Kerkouche08], les auteurs ont présenté un cadre formel et un outil basé sur

l'utilisation combinée de la méta-modélisation et grammaires de graphes pour la spécification

et l'analyse de systèmes logiciels complexes en utilisant le G-Nets formalisme.

Une Plateforme Formelle pour la Modélisation et la Simulation des LRN

74

Leur outil permet au développeur de dessiner un modèle G-Nets et le transformer en son

modèle équivalent PrT-nets automatiquement, afin de l‟analyser en utilisant l‟analyseur

PROD. Dans [Kerkouche09], les auteurs ont proposé une approche pour la transformation des

statechart et des diagrammes de collaboration UML vers des modèles réseaux de Petri

colorés.

Dans ce chapitre, nous proposons une approche et un outil de transformation

automatique de modèles LRN à leurs spécifications équivalentes en Maude pour des fins

d'analyse [Dehimi4-12]. Cette transformation vise à rendre possible la vérification des

propriétés des systèmes modélisés en utilisant les LRN puisque ce nouveau formalisme n'a

pas d'outils pour l'analyse et la vérification. Notre approche est basée sur l'utilisation

combinée de la méta-modélisation et des grammaires de graphe. ATOM3 est l‟outil qu‟on

utilise, il est fondé sur la méta-modélisation et la transformation de modèles.

Dans notre travail, le formalisme de diagramme de classe UML de l‟outil ATOM3 est

utilisé pour définir un méta-modèle pour les LRN. ATOM3 est aussi utilisé pour générer un

outil de modélisation visuelle pour l‟élaboration de modèles selon le méta-modèle des LRN

proposé. Nous avons aussi proposé une grammaire de graphe pour générer automatiquement,

la description R-Maude des modèles LRN graphiquement spécifiés [Dehimi5-12]. Ensuite, la

logique de réécriture R-Maude est utilisée pour effectuer la simulation de la spécification

générée. Notre approche est illustrée par des exemples.

4.1 Réseaux reconfigurables étiquetés (Labeled Reconfigurable Nets LRN)

4.1.1 Définition

Le formalisme «Labeled Reconfigurable Nets (LRN)» [Kahloul07] est conçu pour

modéliser les systèmes à code mobile. Les auteurs dans [Kahloul07], ont tenté de modéliser la

mobilité de façon intuitive et explicite. La mobilité du code (un processus ou un agent) va être

modélisée directement à travers la reconfiguration du réseau. Le formalisme permet l'ajout et

la suppression de places, arcs et transitions au moment de l'exécution.

Officieusement, les réseaux reconfigurables étiquetés (LRN) sont une extension des

réseaux de Petri. Un LRN est un ensemble d'environnements (blocs d'unités). Les connexions

entre ces milieux et leur contenu peuvent être modifié pendant l'exécution. Une unité est un

réseau de Petri spécifique. Une unité peut contenir trois types de transitions (une transition de

départ unique , un ensemble de transitions ordinaires et un ensemble de

reconfigurables transitions ).

Les pré-Conditions et les post-conditions pour franchir une transition, sont les mêmes

que dans les réseaux de Petri. Les Reconfigurables transitions sont étiquetées avec des

étiquettes qui influencent leurs franchissement .Quand une reconfigurable transition est

franchie, un réseau N sera déplacé d‟un environnement E vers un autre environnement E '.

Le réseau N, l'environnement E et E 'sont définies dans l'étiquette associée à la transition.


75

Après avoir franchi la reconfigurable transition, la structure du LRN sera mise à jour

(certaines places, arcs ou transitions seront supprimés ou ajoutés).

4.1.2 Exemples de modélisation des paradigmes de la mobilité avec les LRN

Un système à code mobile est composée d'unités d'exécution (EUs, exécution units),

de ressources et d‟environnements de calcul (CEs, computational environments). EUs seront

modélisés comme unités et les environnements de calcul comme environnements. La

modélisation des ressources nécessite l‟utilisation d‟un ensemble de places.

Les transitions reconfigurables modélisent la mobilité. La clé de la modélisation de la

mobilité consiste à identifier l'étiquette (label) associée à la transition reconfigurable. L'unité à

être déplacé y doit être identifiée, de même que l'environnement cible de calcul et les types de

liaison aux ressources et leur emplacement. Ce label dépend de la nature de la mobilité.

En général, une transition reconfigurable rt est toujours étiqueté <EU, CE, CE‟, , >,

tels que:

EU: l'unité d'exécution qui doit être déplacée.

CE, CE‟: respectivement, les environnements de calcul source cible.

: sera utilisé pour modéliser les ressources transférables et clonées, ψ=ψr∪ψc.(ψr removed

places et ψc cloned places). Donc est vide si le système n'a pas ces ressources.

: modélise les liens après le déplacement.

L'unité d'exécution qui contient la transition reconfigurable rt et l'UE qui représente le

premier argument de l'étiquette associée à rt, seront définies en fonction des trois paradigmes

de conception: l'évaluation distance (REV, remote evaluation), le code à la demande (COD,

code on demand), et l'agent mobile (MA, mobile agent) [Kahloul07].

4.1.2.1 L'évaluation à distance

Dans le paradigme d'évaluation à distance, une unité d'exécution EU1 envoie une autre

unité d'exécution EU2 à partir d'un environnement de calcul CE1 à un autre CE2. La transition

reconfigurable rt est contenue dans l‟unité modélisant EU1 et EU2 sera le premier argument

dans label (étiquette) associé à rt.

Considérons deux environnements de calcul E1 et E2. Tout d'abord, E1 contient deux

unités d'exécution EU1 et EU2, E2 contient une unité d'exécution EU3. Les trois unités

d'exécution d'exécutent des boucles infinies. EU1 exécute des actions {a11, a12}, EU2 exécute

des actions {a21, a22, a23} et EU3 exécute des actions {a31, a32}. a21 nécessite une ressource

transférable TR1 et une ressource non transférable liée par type PNR1 qui est partagé avec a11.

a22 et a12 partagent une ressource transférable liée par valeur VTR1, et a23 nécessite une

ressource non transférable NR1. Dans E2, EU1 nécessite une ressource non transférable lié par

type PNR2 pour exécuter a31. PNR2 ayant le même type de PNR1.


76

Le système sera modélisé par un réseau reconfigurable étiqueté LRN (labeled

reconfigurable net). Ce LRN contient deux environnements E1, E2 qui modélisent les deux

environnements de calcul (CE1 et CE2).les unités EU1 et EU2 vont modéliser les unités

d'exécution UE1 et UE2, respectivement. Dans ce cas, l‟unité UE1 contiendra une transition

reconfigurable rt <EU2,E1,E2,, >, tels que:

1. E1 = (RP1, GP1, U1, A1); RP1 = {TR1, PNR1, VTR1, NR1}. U1 = {EU1, EU2};

2. E2 = (RP2, GP2, U2, A2); RP2 = {PNR2}. GP2 = {PEU1}.

3. r = {TR1}, c = {VTR1};

4. = {(PEU1, str2), (PNR2, a21), (NR1, a23)}.

La figure 4.1 montre le modèle de ce système avant la migration et après la migration.

Figure 4.1. Modèle -REV- avant et après le franchissement de rt.

4.1.2.2 Code à la demande

Dans le paradigme, code à la demande, une unité d'exécution EU1 cherche une autre

unité d'exécution UE2. La transition reconfigurable rt est contenue dans l‟unité qui modélise

EU1 et EU2 sera le premier argument du label de rt. Si l'on reprend l'exemple ci-dessus, l‟unité

EU1 contiendra une transition reconfigurable rt <EU2, E2, E1, , >.

La transition rt <EU2, E2, E1, , > signifie que EU1 demandera à déplacer EU2 de E2 à E1.

Dans ce cas, = {TR1, VTR1}, = {(PEU2, str2), (PNR2, a21), (NR1, a23)}.


77

La figure 4.2 montre le modèle proposé pour modéliser ce système.

Figure 4.2. Modèle -COD- avant et après le franchissement de rt.

4.1.2.3. Mobile Agent

Dans le paradigme des agents mobiles, les unités d'exécution sont des agents

autonomes. L'agent lui-même déclenche la mobilité. Dans ce cas, rt(la transition

reconfigurable) est contenue dans l‟unité qui modélise l'agent et EU (le premier argument) est

également cet agent.

Soit E1 et E2 deux environnements de calcul. E1 contient deux agents, un agent mobile

MA et un agent statique SA1, E2 contient un agent unique statique SA2. Les trois agents

exécutent des boucles infinies. MA exécute des actions {a11, a12, a13}, SA1 exécute des actions

{a21, a22, a23} et SA2 exécute des actions {a31, a32}. Pour être exécutée, a11 a besoin d'une

ressource transférable TR1 et d‟une ressource non transférable liée par type de PNR1 qui est

partagée avec a21. a12 et a22 partagent une ressource transférable liée par valeur, et a13 et a23

partagent une ressource non transférable NR1. Dans E1, SA2 nécessite une ressource non

transférable liée par type PNR2 pour exécuter a32. PNR2 ayant le même type de PNR1.

Le système sera modélisé par un réseau reconfigurable étiqueté LRN (labeled

reconfigurable net). Ce LRN contient deux environnements E1, E2 qui modélisent les deux

environnements de calcul. Dans ce cas, l'unité A qui modélise l'agent mobile A contiendra une

transition reconfigurer rt <A, E1, E2, , >; tels que:

1. E1 = (RP1, GP1, U1, A1); RP1 contenant au moins quatre places qui modélisent les quatre

ressources. Soient TR1, NR1, PNR1 et VTR1 ces places.


78

2. E2 = (RP2, GP2, U2, A2); RP2 = {PNR2}, GP2 = {PA2}.

3. r = {TR1}, c = {VTR1};

4. = {(PA2, str1), (PNR2, a11), (NR1, a13)}.

La figure 4.3 montre le modèle proposé pour modéliser ce système.

Figure 4. 3. Modèle -MA- avant et après le franchissement de rt.

4.2 Le système Maude

Maude est un environnement de programmation destiné à la modélisation de diverses

notions relevant de plusieurs domaines [Eker02, Meseguer03, Clarke03, McCombs03]. Ce

langage, basé sur la logique de réécriture, a été développé en fonction de trois grands

objectifs: la simplicité, l‟expressivité et la performance.

Simplicité : Un programme devrait être le plus simple possible et le plus aisé à

comprendre que possible, et devrait posséder en outre une sémantique très claire.

Expressivité : Il devrait être possible d‟exprimer naturellement une vaste gamme

d‟applications, aussi bien pour un programme déterministe que pour un programme

hautement concurrentiel.


79

Performance : on devrait pouvoir utiliser un langage comme spécification

exécutable d‟un modèle, mais également comme un véritable langage de

programmation compétitif.

La plupart du temps, la simplicité et la performance sont présentes dans n‟importe quel

Langage, ils vont de pair. Par contre, maximiser l‟expressivité du langage est sans aucun

doute l‟un des avantages les plus marquants du langage Maude. Certains diront certainement

qu‟un langage développé spécifiquement pour un domaine donné a l‟avantage de simplifier

les notations pour les initiés. Dans ce contexte, Maude devrait alors être vu comme un

métalangage avec lequel il est très aisé de développer un langage spécifique.

Il est également important de noter que Maude permet de programmer à deux niveaux

différents : Core Maude et Full Maude. On peut différencier les deux niveaux par ce qui suit :

Core Maude: Core Maude est le niveau de base de Maude, programmé directement en

C++. Il implémente toutes les fonctionnalités de base du logiciel, les modules

fonctionnels et les modules systèmes ;

Full Maude: Full Maude est le niveau supérieur. Programmé en Core Maude, Full

Maude est en réalité une extension du premier niveau, avec lequel il est possible de

combiner des modules pour perfectionner le développement. Full Maude offre de

nombreux avantages. Il est notamment utilisé avec le paradigme de programmation

orienté-objet et les modules orientés-objet Maude.

4.2.1 Modules Maude

Le développement Maude se fait par l‟écriture de divers modules décrivant le système

que l‟on écrit. Ainsi, l‟unité de base pour le développement Maude est le module. Il en existe

trois types : les modules fonctionnels, les modules système et les modules orientés-objet.

Module fonctionnel : Les modules fonctionnels sont principalement utilisés pour la

définition de types de données et d‟opérateurs via la théorie des équations.

Module système : Les modules systèmes, quant à eux, sont utilisés pour définir des

théories de réécriture. D‟une certaine façon, tout comme la logique de réécriture est

plus générale que la logique des équations, un module système englobe un module

fonctionnel.

Module orienté-objet : Ce dernier type de module est développé spécifiquement

pour le paradigme de développement orienté-objet qui est aujourd‟hui la norme sur

le marché. Ce type de module est utilisé au niveau de Full Maude.

En plus, Maude a son propre model-checker qui est utilisé pour vérifier les propriétés du

système[Meseguer92].


80

4.2.2 Syntaxe de Maude

Dans ce qui suit, quelques brefs exemples de code Maude seront donnés afin

d‟illustrer le fonctionnement du langage.

Rappel : Logique de réécriture.

La logique de réécriture, dotée d‟une sémantique saine et complète, a été introduite par

Meseguer [Meseguer91]. Elle permet de décrire les systèmes concurrents [Eker02,

Meseguer03, Clavel05]. Cette logique unifie tous les modèles formels qui expriment la

concurrence [Meseguer91]. Dans la logique de réécriture, les formules logiques sont appelées

règles de réécriture. Elles sont de la forme suivante :

La règle R indique que le terme t devient (se transforme en) t‟ si une certaine condition

C est vérifiée. Le terme t représente un état partiel d‟un état global S du système décrit. La

modification de l‟état global S du système vers un autre état S‟ est réalisée par la réécriture

d‟un ou plusieurs termes qui expriment les états partiels.

Modules fonctionnels

Tel que discuté précédemment, il existe trois types de modules en Maude : les

modules fonctionnels, systèmes et orientés-objet. Dans ce qui suit, un très court programme

Maude sera défini à l‟aide d‟un module fonctionnel. La figure 4.4 montre ce court

programme.

Figure 4.4. Le module fonctionnel PEANO-NAT

Ce court programme montre en réalité une façon alternative pour définir les nombres

naturels. On le fait ici à l‟aide de la fonction Successeur. Ainsi, un seul nombre de base existe,

0, et les autres sont définis à l‟aide de la fonction successeur (l‟opérateur s). Deux équations

sont également définies : un nombre naturel additionné à 0 donne ce nombre naturel, et un

nombre naturel additionné au successeur d‟un autre nombre naturel donne le successeur de

l‟addition des deux nombres naturels.


81

Modules systèmes

Le second type de module intéressant est le module système. Par rapport au module

fonctionnel, ce dernier incorporera des règles de réécriture.

Figure 4.5. Petri-machine

La figure 4.6 montre un court programme Maude défini à l‟aide d‟un module système.

Il consiste en la représentation Maude du système décrit à la figure 4.5 à l‟aide d‟un réseau de

Petri, un des modèles de concurrence les plus simples. Le programme consiste en un automate

représentant une machine distributrice très simple. Les entrées sont les suivantes :

– $ représente l‟entrée d‟une pièce de 1$ dans la machine ;

– c représente un bonbon ;

– a représente une pomme ;

– q représente une pièce de 25 cents.

Le système permet donc l‟achat d‟un bonbon à 1 $ et l‟achat d‟une pomme pour 0,75 $. La

machine fait aussi la monnaie : pour quatre pièces de 0,.25 $, elle retourne une pièce de 1 $.

Figure 4.6 Le module système Petri-machine


82

Modules orientés-objet

Les modules orientés-objet sont développés à l‟aide du niveau Full Maude. Ils ont

alors leur propre notation spécifiquement développée pour le paradigme objet. Une classe est

déclarée à l‟aide d‟un module Maude orienté-objet, comme suit :

class ClassName | att1 : attType.

Le principe de réduction d‟un module orienté-objet Maude sous une forme de module système

peut être utilisé. Pour se faire, la notation de la figure 4.7 est utilisée.

Figure 4.7 Déclaration d‟une classe sous la forme d‟un module système

On remarque alors la façon utilisée pour déclarer une classe et ses attributs, à l‟aide

des mots clés Cid, l‟identifiant général de toutes les classes de Maude et Attribute le type de

Maude représentant un attribut d‟une classe.

4.3 Reconfigurable Maude

Maude [Clavel99] est considéré comme un langage de haut niveau et un système de

haute performance supportant des spécifications exécutables et permettant la programmation

déclarative dans la logique de réécriture [Meseguer2-92].

De nombreuses extensions de Maude ont été proposées pour faire face à certains

aspects non pris en compte dans l'ancienne version. Par exemple, Maude [Ölveczky00] est un

système permettant la spécification et l'analyse en temps réel. Maude mobile [Duran00] étend

Maude pour la spécification des systèmes mobiles.

Un codage des Labeled Reconfigurable Net (LRN), dans un langage basé sur Maude a

été proposé, le langage inspiré est appelé «Reconfigurable Maude (R-Maude) » [Kahloul08].

Il bénéficie de la puissance de Maude (comme un méta-langage). Maude a été étendu pour

supporter la traduction des LRN et leur simulation. R-Maude enrichit Maude avec nouveau

type de règles de réécriture. Ces règles sont appelées règles reconfigurables (R-Rules). la

sémantique de ces règles est similaire à celle de la transition reconfigurable des LRN. Quand

une telle règle est exécutée, la spécification R-Maude sera mise à jour de différentes manières

en liaison avec le label (étiquette) associé à cette règle.


83

4.4 Meta-modélisation des LRN (réseaux reconfigurables étiquetés)

Pour construire des modèles du formalisme LRN dans ATOM3, nous devons définir

un méta-modèle pour les LRN. Le méta-formalisme utilisé dans notre travail est les

diagrammes de classes UML et les contraintes sont exprimées en code Python [Dehimi6-12].

Comme le LRN consiste en des places, des transitions et des arcs des places vers les

transitions et des transitions vers les places, nous avons proposé pour la méta-modélisation

des LRN, deux Classes pour décrire les places et les Transitions et deux associations, une

pour les arcs entrants arc-in et l‟autre pour les arcs sortants arc-out, comme illustré par la

Figure 4.8. Nous avons également spécifié la représentation visuelle de chaque classe ou

association. La reconfigurable transition est représentée dans le meta-modèle par une classe

(rectrans), qui hérite de la classe mère (trans) avec l‟attribut label en plus, qui décrit les

informations relatives à la mobilité [Dehimi1-12].

Figure 4.8 Méta-Modèle des LRN

Compte tenu de notre méta-modèle, nous avons utilisé l‟outil ATOM3 pour générer un

environnement de modélisation visuel pour les modèles LRN. La figure 4.9 montre l'outil

LRN généré et une boîte de dialogue pour éditer une transition reconfigurable [Dehimi2-12].


84

Figure 4.9 barre d‟outils pour l‟environnement de modélisation des LRN

4.5 La grammaire de graphe qui génère la spécification R-Maude des

modèles LRN. [Dehimi3-12]

Afin de simuler les modèles LRN, nous les traduisons ici vers leurs représentations

équivalentes dans la syntaxe de R-Maude. Dans cette section, nous montrons comment utiliser

l'environnement de modélisation généré dans la section précédente pour générer la

spécification R-Maude. Nous le faisons en définissant une grammaire de graphes pour

parcourir le modèle LRN et générer le code correspondant R-Maude.

La grammaire de graphe possède une Action initiale qui est utilisé pour créer le fichier

où le code en R-Maude sera généré. Cette action attribue également à tous les éléments

Transition et Place dans le modèle des attributs temporaire utilisées dans les conditions

spécifiées dans les règles. Pour les éléments « Transition », nous utilisons deux attributs :

actuel (current) et visité (visited). L'attribut actuel est utilisé pour identifier la transition dans

le modèle dont le code est à générer, tandis que l'attribut visité est utilisée pour indiquer si le

code pour la transition en cours a été générée ou non. Pour les éléments « Place », deux

attributs sont utilisés : fromVisited et toVisited. L'attribut fromVisited est utilisé pour indiquer

si cette place est traitée comme place d'entrée alors que l'attribut toVisited est utilisé pour

indiquer si cette place est traitée comme place de sortie. Ces attributs sont initialisés à 0.

Dans notre grammaire de graphes, nous avons proposé sept règles (voir figure 4.10)

qui seront appliqués dans l'ordre croissant de leurs priorité, par le système de réécriture

jusqu'à ce qu'aucune règle ne soit applicable. Nous sommes concernés ici par la génération de

code, donc les règles de grammaire ne changeront pas les modèles LRN, d‟où la même


85

apparence graphique des parties gauches et droites des règles proposées. Ces règles sont

décrites comme suit :

Figure 4. 10 Les règles de la grammaire de graphes


86

Règle1 : cotegauche (priorité 1): est appliquée pour localiser une place (qui n'a pas

été traitée, fromvisited = = 0), liée à la transition actuelle avec un arc d'entrée et génère la

spécification R-Maude correspondante. Cette règle de grammaire se charge de la construction

de la partie gauche de la règle de réécriture liée à la transition en cours de traitement

(current= = 1). Une fois exécutée, on marque la place comme traitée (fromvisited = = 1)

Condition liée à la règle1

transition=self.getMatched(graphID, self.LHS.nodeWithLabel(2))

place=self.getMatched(graphID, self.LHS.nodeWithLabel(1))

return place.fromVisited == 0 and transition.visited == 0 and transition.current

== 1

Dans l’Action liée à la règle 1 (la mise à jour de l‟attribut fromVisited )


place.fromVisited = 1

Règle2: séparer (priorité 2): est appliqué pour générer le code R-Maude qui sépare

LHS(cote gauche) et RHS(cote droit) de la règle de réécriture (RR) équivalente. Ceci ne sera

fait que si toutes les places en entrée de la transition en cours, ont été introduites dans la partie

gauche de la RR liée à cette même transition et dont le code R-Maude est en cours de

génération.


87


node=self.getMatched(graphID,self.LHS.nodeWithLabel(1))

return node.visited == 0 and node.current == 1

Dans l’Action liée à la règle2 (la mise à jour de l‟attribut current )


node.current = 2

Règle3 : cotedroit (priorité 3): est appliqué pour localiser une place (qui n'a pas été

traitée tovisited = = 0) qui est liée à la transition actuelle avec un arc de sortie et de générer

la spécification R-Maude correspondante. Une fois introduite dans la partie droite du code de

la règle à générer, cette place est marquée comme visitée par la mise à un de l‟attribut to

visited qui lui est associé et ce au niveau de l‟action liée à cette règle. Cette règle de

grammaire se charge de la construction de la partie droite de la règle de réécriture liée à la

transition en cours (dont le symbole séparateur => a été déjà introduit par la règle 2 ( current

= = 2) ).


88


transition=self.getMatched(graphID, self.LHS.nodeWithLabel(2))


return place.toVisited== 0 and transition.visited== 0 and transition.current== 2

Dans l’Action liée à la règle3 (la mise à jour de l‟attribut toVisited )


place.toVisited = 1

Règle4: condition (priorité 4): est appliquée pour terminer la génération du code

R-Maude de la RR (génération du point à la fin de la règle), liée à la transition en cours, à

condition bien sûr d‟avoir introduits toutes les places en sortie dans son côté droit; chose faite

grâce au degré de priorité de cette règle par rapport à la précédente. En fin la transition sera

marquée comme visitée (visited = = 1).


node=self.getMatched(graphID, self.LHS.nodeWithLabel(1))


Dans l’Action liée à la règle4 (la mise à jour des attributs Visited et current)


node.visited=1

node.current=0


89

Règle5: InitPlace (priorité 5): s'applique pour localiser et réinitialiser à 0, les attributs

temporaires (fromvisited et tovisited) dans les places, pour le traitement de la prochaine

transition. En effet des places qui ont intervenue dans des transitions déjà traitées, peuvent

intervenir dans d‟autres transitions non encore traitées.


place=self.getMatched(graphID,self.LHS.nodeWithLabel(1))

return place.fromVisited!=0 or place.toVisited!=0

Action liée à la règle5

place=self.getMatched(graphID,self.LHS.nodeWithLabel(1))

place.fromVisited=0

place.toVisited=0

Règle6: transition (priorité 6): est appliqué pour sélectionner une transition LRN qui

n'a pas été traitée ( visited = = 0 et current = = 0) et la marque pour commencer son traitement

(current = = 1). Le début de la règle de réécriture R-Maude qui lui est associée est aussi

générée par cette règle (rl [nom] : (pour les transition simples) ou rl [nom] [label] : (pour les

transitons reconfigurables).


90




Dans l’Action liée à la règle6 (la mise à jour de l‟attribut current)


node.current=1

Règle7: terminer (priorité 7):est appliqué pour terminer l'écriture du fichier généré

R-Maude et le ferme, et met à 1 la valeur de l‟attribut « final », initialement mise à 0 (dans

action initiale).


return self.graphRewritingSystem.final==0

Dans l’Action liée à la règle7 (la mise à jour de l‟attribut final)

self.graphRewritingSystem.final=1

La grammaire de graphe a également une action finale qui efface les attributs temporaires des

entités.


91

4.6 Exemples

Pour pouvoir concrétiser l‟utilité de la grammaire définie, on a essayé de l‟appliquer

sur divers exemples dont les suivants :

Exemple 1: LRN avec un Agent statique

Le premier exemple concerne un environnement de calcul E1. E1 contient un agent

unique et statique SA1 qui exécute une boucle infinie. SA1 nécessite une ressource non

transférable liée par type PNR2 pour exécuter a32. Le système va être modélisé par un LRN.

La figure 4.11 présente le modèle graphique de cet exemple créé dans notre outil.

Figure 4.11 le modèle LRN de l‟exemple 1

Traduction du modèle LRN vers la Description R-Maude

Cette étape à la représentation graphique d'un modèle LRN comme entrée. Elle consiste

en la traduction de cette représentation graphique vers sa description R-Maude équivalente à

l'aide de la grammaire de graphes définie dans la section précédente. Pour réaliser cette

traduction, l'utilisateur doit exécuter la grammaire de graphe précédemment définie. Le

résultat de la traduction de l‟exemple 1, est donné par la Figure 4.12, c‟est le fichier env2-

system.maude qui contient la description du modèle LRN de la Figure 4.11.


92

Figure 4.12 spécification R-Maude Générée pour exemple1,

env2-system.maude.

Exemple 2: LRN évaluation à distance

Le deuxième exemple concerne l‟environnement de calcul E1 du modèle LRN-REV

(remote evaluation) présenté par la figure 4.1 au début de ce chapitre. E1 contient deux unités

d'exécution EU1 et EU2. Les deux unités d'exécution d'exécutent des boucles infinies. EU1

exécute des actions {a11, a12}, EU2 exécute des actions {a21, a22, a23}. a21 nécessite une

ressource transférable TR1 et une ressource non transférable liée par type PNR1 qui est

partagé avec a11. a22 et a12 partagent une ressource transférable liée par la valeur VTR1, et a23

nécessite une ressource non transférable NR1. La figure 4.13 présente le modèle graphique de

cet environnement créé dans notre outil.


93

Figure 4.13 Le modèle LRN de l‟exemple 2


Le résultat de la traduction de l‟exemple 2, est donné par la Figure 4.14, c‟est le fichier

envir1-system.maude qui contient la description du modèle LRN de la Figure 4.13.


94

Figure 4.14 spécification R-Maude Générée pour exemple2,

envir1-system.maude.

Exemple 2: LRN avec un Agent Mobile

Le résultat d'une autre spécification R-Maude de l‟exemple 3, est le fichier env1-

system.maude, qui contient la description d'un modèle LRN représenté par la figure 4.15

Nous remarquons que l'environnement LRN dans cet exemple, contient deux agents, un

A1(PA1) mobile qui comprend une transition reconfigurable (RT) et un agent A2(PA2)

statique.

Figure 4.15 le modèle LRN de l‟exemple 3


95


Le résultat de la traduction de l‟exemple 3, est donné par la Figure 4.16, c‟est le fichier

env1-system.maude qui contient la description du modèle LRN de la Figure 4.15.

Figure 4.16 spécification R-Maude Générée pour l‟exemple 3

4.7 Prototypage R-Maude

Les auteurs dans [Kahloul08], ont prototypé R-Maude. Le prototype est un système

composé d'un éditeur de texte et d‟un interpréteur. L'éditeur est utilisé pour entrer les

spécification et commandes. L‟interpréteur exécute les commandes. Le système a été

expérimenté sur un LAN (Local Area Network), composé d'un petit nombre de machines. Le

système est installé sur toutes les machines hôtes. Les spécifications sont donc édités partout

et au niveau chaque hôte, les commandes peuvent être exécutées. L'exécution des commandes

créera la dynamique du système. Cette dynamique peut être vue comme la migration des

spécifications (ou de leurs parties) à travers le LAN. Les spécifications sont transférées en tant

que messages entre les machines.

L'interpréteur réalisé pour R-Maude peut être utilisé pour interpréter les spécifications

Maude. La différence majeure, c'est que dans ce nouvel interpréteur, l'interprétation des R-

Rules a été ajoutée. Le label de la R-règle précède la règle, et il a la forme [MT |L | IP @ | S].

La sémantique de ces paramètres est la suivante: MT: Type de mobilité (MA, COD, REV),

L: un ensemble d'opérations et de règles à être déplacer, clonés ou retirés de l'hôte local,

@ IP: adresse IP de l'hôte distant, S: ressources à déplacer ou à supprimer de l'hôte local.

Lorsque les spécifications (ou partie d'entre elles) sont déplacés, certaines ressources (R)

nécessaire de tirer quelques règles deviennent distantes (sur un autre hôte). L'adresse IP de

l'hôte distant apparaît avec la ressource concernée sous la forme: R [@ IP].

Pour coder les LRN, la reconfigurable-transition (R-transition) sera traduite en


96

reconfigurable-Règle (R-rule). Ci-après, nous présentons le codage de l‟exemple de l‟agent

mobile représenté par la Figure 4.3, dans R-Maude prototype. Nous considérons que les deux

environnements E1, E2 sont représentés par les deux spécifications sur les deux hôtes (Host1

et Host2). Host1 a l'adresse IP: 192.168.0.1, et Host2 a l'adresse IP: 192.168.0.2.

Sur l'hôte 1, nous avons spécification suivante:

mod E1

sort Place Marking .

subsort Place << Marking .

op _,_ : Marking Marking ->Marking .

ops PA1,P11,P12,P13,P14,PA2,P21,P22,P23,TR1,VTR1,PNR1,NR1:->Place

rl [str1] : PA1=>P11 .

rl [rt][MA|192.186.0.2|{{P11-P14},{str1-a13}}|{TR1,VTR1}] :P11=>P12.

rl [a11] : P12, TR1, PNR1=>P13 .

rl [a12] : P13, VTR1=>P14 .

rl [a13] : P14, NR1=>PA1 .

rl [str2]: PA2=>P21 .

rl [a21] : P21, PNR1=>P22 .

rl [a22] : P22, VTR1=>P23 .

rl [a23] : P23, NR1=>PA2 .

endmod

Sur l'hôte 2, nous avons spécification suivante:

mod E2




ops PA1,PA2,P31,P32,PNR2 : -> Place.

rl [str3] : PA2=>P31 .

rl [a31] : P31=>P32 .

rl [a32] : P32, PNR2=>PA2 .

endmod

Comme exemple de commande, nous avons "rw PA1 " sur l'hôte 1. L'exécution de

cette commande va produire respectivement sur l'hôte 1 et Host2 les deux spécifications:

mod E1




ops PA1,PA2,P21,P22,P23,VTR1,PNR1,NR1:->Place

rl [str2]: PA2=>P21 .

rl [a21] : P21, PNR1=>P22 .

rl [a22] : P22, VTR1=>P23 .

rl [a23] : P23, NR1=>PA2 .

endmod


97

et au niveau de l‟hôte 2. mod E2




ops PA1,PA2,P31,P32,PNR2 : -> Place.

ops VTR1, TR1:-> Place.

ops P11,P12,P13,P14:->Place.

rl [str3] : PA2=>P31 .

rl [a31] : P31=>P32 .

rl [a32] : P32, PNR2=>PA2 .

rl [str1] : PA1=>P11 .

rl [rt][MA|192.186.0.2|{{P11-P14},{str1-a13}}|{TR1,VTR1}] :P11=>P12.

rl [a11] : P12, TR1, PNR2=>P13 .

rl [a12] : P13, VTR1=>P14 .

rl [a13]:P14,NR1[192.168.0.1]=>PA1.

endmod

Enfin, l'état du marquage sera: "P12" sur l'hôte 2. À ce stade, les deux spécifications

poursuivent leur exécution sur les deux hôtes où elles résident.

4.8 Conclusion

Dans ce chapitre, nous avons présenté un nouveau formalisme, basé sur les réseaux de

petri, « les Labeled Reconfigurables Nets (LRN) ». Ce formalisme permet de faire une

modélisation explicite des environnements informatiques et d‟exprimer la mobilité entre eux.

Nous avons présenté la façon dont ce formalisme permet, grâce à une approche simple et

intuitive, la modélisation des paradigmes de la mobilité du code. L'accent a été mis, sur les

liaisons vers les ressources et la façon dont elles seront mises à jour après la mobilité.

Nous avons décrit par la suite, notre support outillé de manipulation et de simulation

des LRN basé sur la méta-modélisation et les grammaires de graphes. Nous avons commencé

par la proposition d'un métamodèle pour les LRN et avons généré par la suite

automatiquement, L‟éditeur approprié qui permet à l‟utilisateur de dessiner un LRN

graphiquement. Nous avons proposé également, une grammaire de graphe pour transformer le

modèle source en un code cible. Notre proposition a été illustrée par des exemples expressifs.

Nous avons enchainé avec la présentation d‟une extension pour Maude: reconfigurable

Maude (R-Maude). R-Maude est un système distribué qui peut être utilisé pour la

spécification et la simulation des systèmes à code mobile. Un prototype de ce système a été

réalisé et utilisé pour simuler les spécifications des modèles LRN. Un exemple des étapes de

simulation a été également présenté.

Notre objectif à travers l‟outil que nous avons développé, est de faciliter l‟utilisation

conjointe des modèles graphiques des LRN et les représentations textuelles dans le langage

R-Maude. Les LRN disposent d‟un côté graphique facilitant le développement d‟un système à

code mobile au cours de sa spécification. D‟autre part la version textuelle en langage

R-Maude permet le développement des outils pour la simulation et l‟analyse des LRN.

98

Conclusion générale et perspectives

Dans cette thèse, nous nous sommes intéressés au paradigme des agents mobiles. Nous

avons essayé de développer cadre formel pour leurs modélisation et analyse. On a commencé

par introduire dans le premier chapitre la notion d‟agent en général, suivie par le paradigme

des agents mobiles. Le constat fait à ce niveau a montré que le développement des

applications des agents mobiles se heurte à des problèmes inhérents à la sécurité et à

l‟interopérabilité dans les différentes plateformes d‟accueil hétérogènes. Les insuffisances des

efforts pour la standardisation de ces plateformes, ont poussé les chercheurs à explorer

d‟autres horizons pour une meilleure prise en charge et mise en œuvre des applications à base

d‟agents mobiles.

D'autre part, très peu de travaux de recherches portent sur les méthodes et les outils pour

l‟analyse et la conception des systèmes d‟agents mobiles. Dans cette optique, une extension

des réseaux de petri vers les Reconfigurables Petri Nets (LRN) a été présentée. En effet, nous

avons proposé une approche totalement automatisée basée sur la méta-modélisation et les

grammaires de graphes pour générer des modèles réseaux de Petri reconfigurables (LRN),

pour la modélisation de la mobilité, en utilisant ATOM3. Nous avons donc décrit, notre

support outillé de manipulation et de simulation des LRN, à commencer par la proposition

d'un méta-modèle pour les LRN pour générer par la suite automatiquement, L‟éditeur

approprié qui permet à l‟utilisateur de dessiner un LRN graphiquement. Nous avons proposé

également, une grammaire de graphe pour transformer le modèle source en un code cible en

R-Maude. R-Maude est un système distribué qui peut être utilisé pour la spécification et la

simulation des systèmes à code mobile. Un prototype de ce système a été réalisé et utilisé

pour simuler les spécifications des modèles LRN. Un exemple des étapes de simulation a été

également présenté.

Nous avons donc, proposé une approche et un outil traitant de la transformation des

modèles LRN vers leur spécification R-Maude équivalente. Cette transformation vise à

permettre de procéder à la vérification des propriétés des systèmes modélisés à l'aide des

LRN, étant donné que ces derniers n'ont pas d'outils pour l'analyse et la vérification. Le coût

de construction d'un outil de modélisation visuelle (LRN par exemple) à partir de zéro est

prohibitif. Nous avons montré dans ce travail que la méta-Approche de modélisation est utile

pour faire face à ce problème car elle permet la modélisation des formalismes eux-mêmes. Par

le biais de la grammaire de graphes, les manipulations de modèles sont exprimées sur une

Conclusion générale et perspectives

99

base formelle et d'une manière graphique très expressive. Notre approche est basée sur

l'utilisation combinée de la méta-modélisation et de la grammaire de graphes. L‟outil ATOM3

est utilisé comme outil de transformation de graphes.

Dans les travaux futurs, nous prévoyons de cacher les étapes de la simulation, L‟objectif

est de décharger l'utilisateur d'avoir à invoquer manuellement R-Maude et de manipuler la

version textuelle du résultat de la simulation. A cet effet, le résultat de la simulation sera

retourné de manière graphique avec la structure du modèle LRN. Nous prévoyons aussi de

mettre l'accent sur la modélisation et l'analyse des aspects. Dans la modélisation aspects, nous

sommes intéressés par le traitement de problèmes tels que la modélisation de la mobilité

multi-sauts, des états des processus durant la migration, ... en ce qui concerne le côté analyse,

nous travaillons sur une sémantique dénotationnelle pour les LRN. Pour R-Maude, le présent

R-Maude ne peut être utilisé que pour simuler les modèles. Les travaux futurs se chargeront

de l'analyse de la spécification, à cet effet, nous prévoyons d‟adapter Maude model-checker à

R-Maude afin d‟effectuer certaines vérification des propriétés des systèmes mobiles. Nous

visons également à faire face aux aspects de sécurité [Armoogum10] [Sarkar11].

Références Bibliographiques

100


[AGG] AGG Home page: http://tfs.cs.tu-berlin.de/agg/

[AGLETS] AGLETS (IBM Corporation). <URL:http://www.trl.ibm.co.jp/aglets/>.

[Alouf02] Sara Alouf and Fabrice Huet and Philippe Nain, Forwarders vs. Centralized Server:

An Evaluation of Two Approaches for Locating Mobile Agents. Proceedings of the 2002

International Conference on Measurement and Modeling of Computer Systems

(SIGMETRICS-02) pp.278--279, 2002.

[Ametller04] Joan Ametller and Sergi Robles and Jose A.Ortega-Ruiz, Self-Protected Mobile

Agents. AAMAS pp.362-367, 2004.

[Andries99] M. Andries, G. Engels, A. Habel, B. Hoffmann, h.-J. Kreowski, s. Kuske, D.

Pump, A. Schürr et G. Taentzer. Graph transformation for specification and programming.

Science of Computer programming, vol 34, NO°1, pages 1-54, Avril 1999.

[Arcangeli02] Jean-Paul Arcangeli, Abdelkader Hameurlain, Guy Bernard, Jean- Francois

Monin, eds., Agents et code mobiles. Numero thematique de la Revue des sciences et

technologies de l'information, serie Technique et science informatiques (RSTI-TSI), Hermes

Science Publications - Lavoisier, Paris, Vol 21 N°6, 2002.

[Armoogum10] Armoogum, S., Caully, A. Obfuscation Techniques for Mobile Agent code

confidentiality. Journal of E-Technology 1(2), 83–94 (2010)

[Asperti96] Andrea Asperti and Nadia Busi. Mobile Petri Nets. Technical Report UBLCS-

96-10, Department of Computer Science University of Bologna, May 1996.

[Athie03] Athie L. Self and Scott A. DeLoach. Designing and Specifying Mobility within the

Multiagent Systems Engineering methodology. Special Track on Agents, Interactions,

Mobility, and Systems (AIMS) at the 18th ACM Symposium on Applied Computing (SAC

2003). Melbourne, Florida, USA, 2003.

[ATOM3]http://moncs.cs.mcgill.ca/MSDL/research/projects/ATOM3.html.

[Aud07] Laurent Audibert : UML 2.0, Institut Universitaire de Technologie de Villetaneuse,

Département Informatique, Adresse du document:http://www-lipn.univ-paris13.fr/

audibert/pages/enseignement/cours.htm, novembre 2007.

[Bahri09] M.R. Bahri, R. Mokhtari, et A. Chaoui, Modelling of mobile agent-based systems

by UML2.0, Conference international ACIT, Elhamamat, Tunisia 2009.

[Bahri2-09] Mohamed Redha Bahri, Abdelkamel Hettab, Allaoua Chaoui, Elhillali

Kerkouche. Transforming Mobile UML Statecharts Models to Nested Nets Models using

Graph Grammars: An Approach for Modeling and Analysis of Mobile Agent-Based Software

Systems, In Proccedings of IEEE SEEFM2009, the 2009 Fourth

http://moncs.cs.mcgill.ca/MSDL/research/projects/ATOM3.html

http://www-lipn.univ-paris13.fr/


101

[Bednarczyk04] M.A. Bednarczyk, L. Bernardinello, W. Pawlowski, and L. Pomello.

Modelling Mobility with Petri Hypernets. 17th Int. Conf. on Recent Trends in Algebraic

Development Techniques, WADT‟04. LNCS vol. 3423, Springer-Verlag, 2004.

[Benzaken91] Claude Benzaken. Systèmes Formels: Introduction à la logique et à la théorie

des langages. Editions Masson, 1991.

[Bennett90] John K. Bennett and John B. Carter and Willy Zwaenepoel, Munin: Distributed

Shared Memory Based on Type-Specific Memory Coherence. PPOPP, pp.168--176, 1990.

[Beale94] Russell Beale and Andrew Wood, Agent-Based Interaction. BCS HCI pp.239-245,

1994.

[Bellavista01] Paolo Bellavista and Antonio Corradi and Cesare Stefanelli, How to Monitor

and Control Resource Usage in Mobile Agent Systems , 2001.

[Benachenhou05] Lotfi Benachenhou and Samuel Pierre, A New Protocol for Protecting a

Mobile Agent Using a Reference Clone. MATA, pp.364-373, 2005.

[Berger05] Reinhartz-Berger, I., Dori, D. and Katz, S. (2005). Modelling code mobility and

migration: an OPM/Web approach, Int. J. Web Engineering and Technology, Vol. 2, No. 1,

pp.6–28.

[Bettaz92] M. Bettaz, and M. Maouche. How to specify Non Determinism and True

Concurrency with Algebraic Term Nets. Lecture Notes in Computer Science, N 655, Spring

Verlag, Berlin, p. 11-30, 1992.

[Bettaz93] M. Bettaz, M. Maouche, M. Soualmi, and M. Boukebeche. Protocol Specification

Using ECATNets. Networking and Distributed Computing, pp 7-35. 1993.

[Bloomfield99] R.E. Bloomfield and D. Craigen. Formal methods diffusion: Past lessons and

future prospects. Technical Report D/167/6101/1, Bundesamt fur Sicherheit in der

Informationstechnik, Bonn, Germany, December 1999.

[Carvalho04] Marco M. Carvalho and Thomas B. Cowin and Niranjan Suri and Maggie R.

Breedy and Kenneth Ford, Using mobile agents as roaming security guards to test and

improve security of hosts and networks. SAC pp.87-93, 2004.

[Claessens03] Claessens and Preneel and Vandewalle, (How) Can Mobile Agents Do Secure

Electronic Transactions on Untrusted Hosts? A Survey of the Security Issues and the Current

Solutions. ACMTIT: ACM Transactions on Internet Technology, 2003.

[Clarke03] Clarke, E. M. Model Checking Overview. Presentation Slides, 2003.

[Claud01] C.Kaiser, ANNEXE 2 LES RÉSEAUX DE PETRI, Reproduit avec la permission de

Francis Cottet, ENSMA décembre 2001.

[Clavel05] Clavel, M., Durán, F., Eker, S., Lincoln, P., Martí-Oliet, N., Mesenguer, J. and

Talcott. C. Maude Manual (Version 2.1.1). April 2005.


102

[Clavel99]. Clavel, M., Durán, F., Eker, S., Lincoln, P., Marti-Oliet, N., Meseguer, J.,

Quesada, J. Maude:specification and programming in rewriting logic. SRI International

(January 1999), http://maude.csl.sri.com

[Chess97] D. Chess and C. Harrison and A. Kershenbaum, Mobile Agents: Are They a Good

Idea?. j-LECT-NOTES-COMP-SCI, pp.25--48, 1997.

[Cook94] Cook (S.) et Daniels (J.). – Designing Object Systems - Object-Oriented Modelling

with Syntropy. – Prentice-Hall, 1994.

[Czar03] K. Czarnecki, S. Helsen, Classification of Model Transformation Approaches,

University of Waterloo, Canada.2003, [email protected], [email protected].

[Cubat05]C. Cubat thèse de doctorat « Agents Mobiles Coopérants pour les Environnements

Dynamiques», Institut National Polytechnique de Toulouse 2005.

[Dehimi4-12] Nardjes Dehimi, Raida Elmansouri, and Allaoua Chaoui. A Formal Framework

and a Tool to Process and Simulate Labeled Reconfigurable Nets Models Based on Graph

Transformation. NDT 2012, Part II, CCIS 294, pp. 404–415. Springer-Verlag 2012.

[Dehimi5-12] Nardjes Dehimi and Allaoua Chaoui. Using Meta-modeling Graph Grammars

and R-Maude to Process and Simulate LRN Models. International Journal of Software

Engineering (IJSE), Volume (3) : Issue (2) : 2012.

[Dehimi3-12] Nardjes Dehimi and Allaoua Chaoui. “Using graph grammars and meta-

modeling to process code mobility in LRN models”. IEEE International Conference on

Information Technology and e-Services 2012. pp.657-662.

[Dehimi6-12] Nardjes Dehimi and Allaoua Chaoui. Processing and Simulating LRN Models

Using Meta-modeling Graph-Grammars and R-Maude. SMTDA 2012Stochastic Modeling

Techniques and Data Analysis International Conference June 2012 Chania, Crete, Greece.

[Dehimi1-12]Nardjes Dehimi and Allaoua Chaoui. A Meta-modelling and Graph Grammar

Based Approach to Process LRN Models. 2nd International Conference on Information

Systems and Technologies 2012.

[Dehimi2-12] Nardjes Dehimi and Allaoua Chaoui. Des Réseaux Reconfigurables Etiquetés à

Maude en Utilisant La Meta-Modélisation et les Grammaires de Graphe. Conférence

internationale sur le traitement de l‟information multimédia Avril 2012, Mascara, Algérie.

[David06] David Durand, Gestion de la Qualité de Service dans les Applications Réparties

sur Bus Middleware Orientés Objet Approche Dirigée par les Modèles, Thèse de Doctorat,

université de Picardie Jules Verne, le 8 novembre 2006.

[DeLara02] J. De Lara and H. Vangheluwe. AToM3: "A Tool for Multi-Formalism

Modelling and Meta-Modelling". Lecture Notes in Computer Science, No 2306, pp. 174-188,

2002.

mailto:[email protected]

mailto:[email protected]


103

[Dillenseger02] Bruno Dillenseger and Anne-Marie Tagant and Laurent Hazard,

Programming and Executing Telecommunication Service Logic with Moorea Reactive

Mobile Agents. Mobile Agents for Telecommunication Applications, 4th International

Workshop, MATA 2002 pp.48--57, 2002.

[Diaz01] Jesus Arturo Perez Diaz and Dario Alvarez Gutierrez and Igor Sobrado, A fast data

protection technique for mobile agents against malicious hosts. Electr. Notes Theor. Comput.

Sci, 2001.

[DIMA] DIMA, OASIS, Laboratoire d‟Informatique de Paris 6 (LIP6) <URL :http://wwww-

poleia.lip6.fr/~guessoum/DIMA.html>.

[Duran00] Francisco Duran, Steven Eker, Patrick Lincoln and José Meseguer. Principles of

Mobile Maude. In: Kotz, D., Mattern, F. (eds.) ASA/MA 2000. LNCS, vol. 1882, pp. 73–85.

Springer, Heidelberg(2000).

[Eker02] Eker, S., Meseguer, J. and Sridharanarayanan, A. The Maude LTL Model Checker.

F.Gaducci and U. Montanari, editors, Proc. of the 4th International Workshop on Rewriting

Logic and its Applications (WRLA 2002), 2002.

[El Mansouri08]. El Mansouri, R., Kerkouche, E., Chaoui, A.: A Graphical Environment for

Petri Nets INA Tool Based on Meta-Modelling and Graph Grammars. Proceedings of Word

Academy of Science, Engineering and Technology 34 (October 2008) ISSN 2070-3740

[Eric07] Eric Piel, Ordonnancement de systèmes parallèles temps-réel, de la modélisation à la

mise en oeuvre par l‟ingénierie dirigée par les modèles, Thèse. Lille, le 14 décembre 2007.

[Ferber95] J. Ferber, Les systèmes multi-agents Vers une intelligence collective, Masson,

1995.

[FIPA] Foundation for Intelligent Physical Agents,1998, URL,(www.fipa.org).

[Fournet02] Cédric Fournet Georges Gonthier. The Join Calculus: a Language for

Distributed Mobile Programming. In Applied Semantics. International Summer School,

APPSEM 2000, Caminha, Portugal, September 2000, LNCS 2395, pages 268-- 332, Springer-

Verlag. August 2002.

[Fuggetta98] Alfonso Fuggetta and Gian Pietro Picco and Giovanni Vigna, Understanding

Code Mobility. IEEE Transactions on Software Engineering, pp.342-361, 1998.

[Galtier01] Virginie Galtier and Kevin L. Mills and Yannick Carlinet and Stephen F.Bush

and Amit Kulkarni, Predicting and Controlling Resource Usage in a Heterogeneous Active

Network. Active Middleware Services, pp.35-44, 2001.

[Gardarin93] G. Gardarin O.Gardarin, Le Client-Serveur. Eyrolles, mars 1993.

[Gargantini09] Angelo Gargantini, Elvinia Riccobene and Patrizia Scandurra. Integrating

Formal Methods with Model-driven Engineering . In Proceedings of the Fourth International

Conference on Software Engineering Advances, Porto, Portugal , ISBN: 978-0-7695-3777-1,

2009.

http://www.fipa.org/


104

[Gerber02] Anna Gerber, Michael Lawley , Kerry Raymond , Jim Steel and Andrew Wood,

Transformation: The Missing Link of MDA, In : Graph Transformation. Volume 2505 of

Lecture Notes in Computer Science, Springer- Verlag (2002) 90-105 Proc. 1st International

Conference. Graph Transformation, Barcelona, Spain 2002.

[Gomoluch01] J. Gomoluch and M. Schroeder, Information agents on the move: A survey on

loadbalancing with mobile agents, 2001

[Grasshopper98] Grasshopper – A, M. Breugst and I. Busse and S. Covaci and T.Magedanz,

Mobile Agent Platform for IN Based Service Environments. Proceedings of IEEE IN

Workshop, pp.279--290, 1998.

[Groot04] David R. A. De Groot and Frances M. T. Brazier and Benno J. Overeinder, Cross-

Platform Generative Agent Migration, 2004.

[Guerra03] E. Guerra, J. de Lara, A Framework for the Verification of UML Models.

Examples using Petri Nets. Ecole Politechnique Superieur, Ingenieríe de l‟ Informátique,

Université Autónoma de Madrid.Spain 2003

[Guyennet97] H. Guyennet and J-C. Lapayre and M. Trehel, CAliF: une plate-forme de

d'eveloppement de collecticiels utilisant la memoire partagee distribuee. Calculateurs

paralleles, pp.251-271, 1997

[Hall90] A. Hall. Seven myths of formal methods. IEEE Softw., 7(5):11–19, 1990.

[Hantz06] F. Hantz and H. Guyennet, A P2P Platform using sandboxing. HPCS'06,

Workshop on security and high Performance computing systems, In conjunction with ECMS

2006, 20th European Conf. on Modelling and Simulation, Bonn, Germany, pp.736-739, 2006.

[Hin95] Hinchey (M. G.) et Bowen (J. P.). – Seven more myths of formal methods. IEEE

Software, july 1995, pp. 34–41.

[Hinchey95] M. G. Hinchey and J. Bowen, editors. “Applications of Formal Methods”,

Prentice Hall International, 1995. isbn 0-13-366949-1.

[Hohlfeld02] Matthew Hohlfeld and Aditya Ojha and Bennet Yee, Security in the Sanctuary

System, http://historical.ncstrl.org/tr/ps/ucsd_cs/CS2002-0731.ps, 2002.

[INA] INA home page : www2.informatik.hu-berlin.de/~starke/ina.html

[IRISA08] IRISA. Kermeta-breathe life into your metamodels. http ://www.kermeta.org/,

2008.

[Ismail99] L. Ismail and D. Hagimont and J. Mossiere, Evaluation of the Mobile Agents

Technology: Comparison with the Client/Server Paradigm, 1999.

[ISO 8402] ISO 8402 Qualité: Concepts et Terminologie. Partie 1: Termes génériques et

Définitions.


105

[JADE] JADE: Java Agent Development Framework. <URL: http://www.jade.cselt.it/>.

[Java] Java Sun, http://java.sun.com.

[Jean01] Jean Bézivin and O. Gerbé. Towards a precise definition on the omg/mda

framework. In ASE‟01, november 2001.

[Jean02] Jean Bézivin, Xavier Blanc. MDA : Vers un important changement de paradigme en génie

logiciel. http ://www.sciences.univnantes. fr/info/perso/permanents/vailly/ Enseignement/

Documents/MDA.Partie1. -JBXB.Last.prn.pdf, Juillet 2002.

[Jensen97] Kurt Jensen. A Brief Introduction to Coloured Petri Nets. Lecture Notes in

Computer Science, No 1217, Springer-Verlag, 1997, pp 203-208.

[Jensen98] Kurt Jensen. An Introduction to the Practical Use of Coloured Petri Nets.

Lecture Notes in Computer Science, No 1492, Springer-Verlag, pp 237-292, 1998.

[José] José-Celso Freire Junior_ - Jean-Pierre Giraudin – Agnès Front Atelier MODSI: Un

Outil de Méta-Modélisation et de Multi-Modélisation. Laboratoire Logiciels Systèmes

Réseaux – IMAG B.P. 72 - 38402 – Saint Martin d‟Hères Cedex – France.

[Jouault06] Frédéric Jouault, Freddy Allilaire, Jean Bézivin, Ivan Kurtev and Patrick

Valduriez. ATL: a QVT like transformation language. In Companion to the 21th Annual

ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and

Applications, OOPSLA 2006, October 22-26, 2006, Portland, Oregon, USA, pages 719– 720,

2006.

[Kadima05] H. Kadima, MDA une conception orientée objet guide par les modèles.

DUNOD 2005.

[Kahloul07] Laid Kahloul and Allaoua Chaoui, Labeled reconfigurable nets For modeling

code mobility, In proceedings of ACIT 2007. Lattakia, Syria.

[Kahloul08] Kahloul, L., Chaoui, A. LRN/R-Maude Based Approach For Modeling And

Simulation Of Mobile Code Systems. In: Proceedings of ACIT 2008, Tunisia (2008).

[Kahloul2-08]. Kahloul, L. and Chaoui, A. LRN/R-maude based approach for modeling and

simulation of mobile code systems. In Ubiquitous Computing and Communication Journal

(UbiCC journal), Volume 3 Number 6, Volume 3 No. 6, 12/20/2008. http://www.ubicc.org/

search_advanced.aspx.

[Kerkouche08] Kerkouche, E., Chaoui, A.: A Formal Framework and a Tool for the

Specification and Analysis of G-Nets Models Based on Graph Transformation. In: Garg, V.,

Wattenhofer, R., Kothapalli, K. (eds.) ICDCN 2009. LNCS, vol. 5408, pp. 206–211. Springer,

Heidelberg (2008).

[Kerkouche09] Kerkouche, E., Chaoui, A., Khalfaoui, K.: Transforming UML models to

colored Petri nets models using graph grammars. In: Proceedings of IEEE ISCC 2009,

Tunisia, July 5-7, pp.230–236 (2009).

http://www.jade.cselt.it/

http://java.sun.com/

http://www.ubicc.org/


106

[Karsai04] G. Karsai, A. Agrawal. Graph Transformations in OMG’s Model-Driven

Architecture. Lecture Notes in Computer Science, Vol 3062, 243-259, Springer Berlin /

Heidelberg, juillet 2004.

[Kees06] Kees M. van Hee, Irina A. Lomazova, Olivia Oanea, Alexander Serebrenik, Natalia

Sidorova, Marc Voorhoeve. Nested Nets for Adaptive Systems. 14 EE. ICATPN 2006: 241-

260.

[Kohler02] Köhler M and Rölke H, Mobile object net systems. Concurrency and mobility. in

Proceedings of the International Workshop on Concurrency, Specification, and Programming

(CS&P 2002), Berlin, 2002.

[Kohler07] M. Köhler, R. Langer, R. Lüde, D. Moldt, H. Rölke, R. Valk, Socionic Multi-

Agent Systems Based on Reflexive Petri Nets and Theories of Social Self-Organisation,

Journal of Artificial Societies and Social Simulation vol. 10, no.1, 2007.

http://jasss.soc.surrey.ac.uk/10/1/3.html 31-Jan-2007

[Kurt1 97] Jensen Kurt. Coloured petri nets: Basic concepts, analysis methods and pratical

use, volume 1. Springer, 1997.

[Lomazova02] I.A. Lomazova. Nested Petri Nets. Multilevel and Recursive Systems.

Fundamenta Informaticae vol.47, pp.283-293. IOS Press, 2002.

[Leclercq04] Matthieu Leclercq and Vivien Quema and Jean-Bernard Stefani,DREAM: a

component framework for the construction of resource-aware, reconfigurable MOMs.

Adaptive and Reflective Middleware, pp.250--255, 2004.

[Marcus04] Marcus Alanen and Iven Porres. Coral : A metamodel kernel for transformation

engines. In Second European Workshop on Model Driven Architecture (MDA), Canterbury,

United Kingdom, 2004 september.

[MASIF] MASIF, The OMG Mobile Agent System Interoperability Facility,1997, URL

www.masif.org

[McCombs03] McCombs, T. Maude 2.0 Primer (Version 1.0). August 2003.

[Merks06] Ed Merks Raymond Ellersick Frank Budinsky, David Steinberg and Timothy J.

Grose. Eclipse Modeling Framework. Hermès - Lavoisier, 2006.

[Meseguer03] Meseguer, J. Software Specification and Verification in Rewriting Logic.

2003.

[Meseguer91] Meseguer, J. Rewriting as a Unified Model of Concurrency. In SIGPLAN

OOPS Mess , 2(2) :86–88, 1991.

[Meseguer92] Meseguer J. A Logical Theory of Concurrent Objects and its Realization in

the Maude Language. Agha G., Wegner P. and Yonezawa A., Editors, Research Directions in

Object-Based Concurrency. MIT Press, 1992, pp. 314-390.

http://jasss.soc.surrey.ac.uk/10/1/3.html%2031-Jan-2007

http://www.masif.org/


107

[Meseguer2-92] . Meseguer, J.: Conditional rewriting logic as a unified model of

concurrency. Theoretical Computer Science 96(1), 73–155 (1992)

[Milner92] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes.

Information and Computation, 100:1–77, 1992.

[Mireille06] Mireille Blay-Fornarino Jean-Marie Favre, Jacky Estublier. L‟ingénierie dirigée

par les modèles - Au-delà du MDA. Hermès - Lavoisier, 2006.

[Mokrane04] Mokrane Bouzhegoub Jacky Estublier Jean-Marie Favre Sébastien Gérard

Jean-Marc Jézéquel Jean Bézivin, Mireille Blay. Rapport de synthèse de l‟as cnrs sur le mda

(model driven architecture). http ://www.irisa.fr/triskell/publis/2004/Jezequel04e.pdf.

[ODYSSEY] ODYSSEY (General Magic). <URL:http://www.genmagic.com/technology/

mobile_agent.html>.

[Ölveczky00] Ölveczky, P.C., Meseguer, J.: Real-Time Maude: A tool for simulating and

analyzing realtime and hybrid systems. In: Futatsugi, K. (ed.) Third International Workshop

on Rewriting Logic and its Applications. ENTCS, vol. 36. Elsevier (2000),

http://www.elsevier.nl/ locate.entcs/volume36.html

[OMG00] OMG. Meta object facility (MOF) specification (version 1.3). OMGdocument,

Object Management Group, ftp ://ftp.omg.org/pub/docs/formal/00-04-03.pdf, March 2000.

[OMG03] OMG. Omg‟s metaobject facility. http ://www.omg.org/mof, 2003.

[OMG04] Object Management Group (OMG), Model Driven Architecture (MDA),

http://www.omg.org/mda,2004.

[OMG06] OMG. Meta object facility (MOF) core specification. http ://www.omg.org/docs/

formal/06-01-01.pdf, 2006.

[Pep] PEP home page: http://peptool.sourceforge.net/

[Petit99] Michaël Petit. Formal requirements engineering of manufacturing systems: a

multiformalism and component-based approach . Thèse de doctorat de l'Université de

Namur, Belgique, Octobre 1999.

[Prakash6] N. Prakash, S. Srivastava, S. Sabharwal. The Classification Framework for

Model Transformation, Journal of Computer Science 2 (2): 166-170, 2006.

[Python] Python home page: htpp://www.python.org.

[RAM 74] RAMCHANDANI C., Analysis of asynchronous concurrent systems by timed

Petri nets, PhD thesis, Massachusetts Institute of Technology, Cambridge, MA, 1974, Project

MAC Report MAC-TR-120.

[Rozenberg99] G. Rozenberg. Handbook of Graph Grammars and Computing by Graph

Transformation. Vol.1. World Scientific, 1999.

http://www.omg.org/mda,2004

http://peptool.sourceforge.net/


108

[Sangiorgi01] D. Sangiorgi and D. Walker. The π-Calculus: A Theory of Mobile Processes.

Cambridge University Press, 2001.

[Sarkar11] Sarkar, A., Debnath, N.: CASE Tool Design for Graph Semantic Based Aspect

Oriented Model. Journal of Intelligent Computing 2(4), 169–182 (2011)

[Scor06] G. Scorletti et G. Binet Réseaux de Petri Maîtres de conférences à l‟Université de

Caen, France 20 juin 2006. Page web: http: //www.greyc.ensicaen. fr/EquipeAuto/Gerard

S/mait_Petri.html.

[Sylvain04] Sylvain Andre. MDA (model driven architecture) principes et ´états de l‟art.

Technical report, CNAM, 05 Novembre 2004.

[Taentzer05] Gabriele Taentzer, Karsten Ehrig, Esther Guerra, Juan de Lara, Laszlo Lengyel,

Tihamer Levendovszky, Ulrike Prange, Gabriele Taentzer, Daniel Varro and Szilvia Varro-

Gyapay. Model Transformation by Graph Transformation : A Comparative Study. Model

Transformations in Practice Workshop at MoDELS, Montego, 2005.

[Tanenbaum92] A. S. Tanenbaum, Modern Operating Systems, Prentice-Hall .1992.

[Tina] Tina Home page : http://www.laas.fr/tina/

[Tran05] V. Tran, V. Moraru, Réseau de Petri, Institut de la Francophonie pourl'Informatique

Promotion 10 15 juillet 2005.

[Valk98] R. Valk. Petri Nets as Token Objects: An Introduction to Elementary Object Nets.

Applications and Theory of Petri Nets 1998, LNCS vol.1420, pp.1-25, Springer-Verlag, 1998.

[Vangheluwe02] Hans Vangheluwe and Juan De Lara. Meta-models are models too. In

Proceedings of the 2002 Winter Simulation Conference, (pp. 597-605), Eds : E. Yücesan, C.-

H. Chen, J. L. Snowdon, and J. M. Charnes, 2002.

[VIATRA] VIATRA, Visual Automated Transformations for Formal Verification and

Validation of UML Models, URL:http://dev.eclipse.org/viewcvs/indextech.cgi/gmt-home/

subprojects/VIATRA2/index.html

[Wikipédia08] Wikipédia. Système. http ://fr.wikipedia.org/wiki/Acceuil/Système, 2008.

[Wing90] Jeannette M. Wing. A Specifier's Introduction to Formal Methods. Computer, vol.

23(9):8-23, 1990.

[Xu00] Dianxiang Xu and Yi Deng, Modeling Mobile Agent Systems with High Level Petri

Nets. 0-7803- 6583-6/00/ © 2000 IEEE.

[Yann03] Yann Dantal et Christophe Haug Théorie des graphes Principes et programmation

Soluscience 2003.

http://dev.eclipse.org/viewcvs/indextech.cgi/gmt-home/subprojects/VIATRA2/index.html

http://dev.eclipse.org/viewcvs/indextech.cgi/gmt-home/subprojects/VIATRA2/index.html