Aissam Belghiat

Université AbdelHamid Mehri - Constantine2
Faculté Des nouvelles Technologies de l’Information et de la

Communication
Département Sciences de l’ordinateur et ses applications
THESE
Présentée pour l’obtention du diplôme de doctorat en sciences
Spécialité : Informatique
Par :
Aissam Belghiat
Intitulée :
Une approche de spécification et de vérification
des systèmes logiciels à base d’agents mobiles en
utilisant UML mobile et π-calcul
Soutenu publiquement le : 07/02/2017 devant le jury composé de:

Mr. Saidouni DjamelEddine Prof. Université AbdelHamid Mehri-Constantine2 Président
Mr. Chaoui Allaoua Prof. Université AbdelHamid Mehri-Constantine2 Rapporteur
Mr. Maouche Mourad MCA Université Philadelphia (Jordanie) Co-rapporteur
Mr. Bennoui Hammadi MCA Université de Biskra Examinateur
Mr. Kahloul Laid MCA Université de Biskra Examinateur
Mr. Benmerzoug Djamel MCA Université AbdelHamid Mehri-Constantine2 Examinateur
Mr. Echahed Rachid Prof. CNRS et Université de Grenoble (France) Invité
Remerciements
Remerciements
D’abord, je remercie Dieu le tout puissant qui m’a donné la volonté, la force, la
patience et le courage pour accomplir ce modeste travail.
J’adresse toute ma reconnaissance au Pr. Allaoua Chaoui mon directeur de thèse, qui
m'a toujours accueilli avec bienveillance et qui n’a ménagé ni son temps ni ses efforts pour
m’aider.
Je voudrais également exprimer toute ma gratitude au Pr. Rachid Echahed (CNRS et

Université de Grenoble-Alpes, France) chef d’équipe CAPP (Calculs Algorithmes Programmes
et Preuves) au laboratoire LIG (Laboratoire d’Informatique de Grenoble). Celui-ci a grandement
facilité ma tâche de recherche par ses conseils, ses remarques précises et ses critiques
constructives au cours de tous mes séjours d’études au sein de son laboratoire.
Je tiens à remercier aussi Dr. Mourad Maouche (Université de Philadelphia,

Jordanie), Pr. Mokhtar Beljhem (Université d’Otawa, Canada), Dr. Elhillali Kerkouche
(Université de Jijel) et Pr. Mohamed Redjimi (Université de Skikda) pour leurs soutiens et
aide.
Je tiens à remercier ma famille ainsi que tous mes collègues et mes amis pour leur
soutien moral.
Je tiens à remercier Pr. DjamelEddine Saidouni de m’avoir fait l’honneur d’accepter

de présider l’ensemble des membres de mon jury.
Je remercie également Dr. Hammadi Bennoui, Dr. Laid Kahloul ainsi que Dr. Djamel
Benmerzoug d’avoir accepté de juger ce travail.
En fin, je tiens à remercier tous ceux qui ont contribué d’une façon ou d’une autre à
la réalisation de ce mémoire.
Abstract
Abstract
Mobile agent-based software systems are a special type of applications which benefit
from the advantages of mobile agents. This leads to a new paradigm that can solve multiple
complex problems in several fields and areas, e.g. network management, electronic
commerce, and e-learning.
Modeling and analysis of mobile agent-based software systems would present
enormous difficulties; this is due to the use of mobile agents which often generates new
situations increasingly complicated. Mobile UML (M-UML) has been proposed as an
extension of UML to model these systems. π-calculus is a rigorous formal method introduced
to specify the behavior of concurrent systems with mobile communication.
In this thesis, we propose MSDs (Mobile Statechart Diagrams); an extension of M-
UML statechart diagrams that provide more modeling elements. Then an integrated approach
MSDs/π-calcul is developed for modeling and verification of mobile agent-based software
systems by translating the former to the later. The derived π-calculus specifications are then
used to analyze and check these systems using π-calculus analytical tools (such as MWB
tool). The approach is illustrated by a case study. We provide also an implementation of the
approach in order to automate its different steps. AToM3 is used as a transformation tool.
Keywords: Mobile UML; π-calculus; modeling; verification.

Résumé
Résumé
Les systèmes logiciels à base d'agents mobiles sont un type particulier d'applications
qui bénéficient des avantages des agents mobiles. Cela conduit à un nouveau paradigme qui
peut résoudre multiples problèmes complexes dans plusieurs domaines et secteurs, par
exemple la gestion du réseau, le commerce électronique et le e-learning.
La modélisation et analyse des systèmes logiciels à base d'agents mobiles présentent
d'énormes difficultés; cela est dû à l'utilisation des agents mobiles qui génère souvent de
nouvelles situations de plus en plus compliquées. Mobile UML (M-UML) a été proposé
comme une extension de l’UML pour modéliser ces systèmes. π-calcul est une méthode
formelle rigoureuse introduite pour spécifier le comportement des systèmes concurrents avec
communications mobiles.
Dans cette thèse, nous proposons les MSDs (Mobile Statechart Diagrams); Une
extension des diagrammes d'états-transition M-UML qui fournissent plus d'éléments de
modélisation. Ensuite, une approche intégrée MSDs / π-calcul est développée pour la
modélisation et la vérification des systèmes logiciels à base d'agents mobiles en transformant
le premier vers le dernier. Les spécifications π-calcul dérivées sont ensuite utilisées pour
analyser et vérifier ces systèmes à l'aide des outils d'analyse du π-calcul (tel que l’outil
MWB). L'approche est illustrée par une étude de cas. Nous fournissons également une
implémentation de l'approche afin d'automatiser ses différentes étapes. AToM3 est utilisé
comme outil de transformation.
Mots clés: Mobile UML; π-calcul; modélisation; vérification.

‫ملخص‬
‫ملخص‬
‫أنظمة البرمجيات القائمة على وكيل متنقل هي نوع خاص من‬
‫التطبيقات التي تستفيد من ايجابيات الوكالء المتنقلون ‪.‬وهذا يؤدي إلى نموذج‬
‫جديد يمكن أن تحل بواسطته المشاكل المعقدة المتعددة في العديد من‬
‫الميادين والمجاالت‪ ،‬على سبيل المثال‪ ،‬إدارة الشبكات‪ ،‬والتجارة اإللكترونية‪،‬‬
‫والتعليم اإللكتروني‪.‬‬
‫نمذجة وتحليل النظم والبرمجيات المستندة على الوكالء المتنقلون‬
‫يولد صعوبات هائلة؛ ويرجع ذلك إلى استخدام الوكالء المتنقلون والتي غالبا‬
‫ما ينتج حاالت جديدة معقدة على نحو متزايد ‪.‬وقد اقترح المحمول ‪M-UML‬‬
‫كامتداد لـ ‪ UML‬لنمذجة هذه األنظمة ‪ π-calculus .‬هو أسلوب رسمي‬
‫صارم قدم لتحديد سلوك النظم المتزامنة مع االتصاالت المتنقلة‪.‬‬
‫‪MSDs (Mobile Statechart‬‬ ‫في هذه األطروحة‪ ،‬نقترح‬
‫)‪Diagrams‬؛ الذي هو امتداد لمخططات ‪M-UML Statechart Diagrams‬‬
‫التي توفر المزيد من عناصر النمذجة‪ .‬بعد ذلك نطور طريقة مركبة ‪MSDs /‬‬
‫‪ π-calculus‬لوضع النماذج والتحقق من أنظمة البرمجيات القائمة على‬
‫الوكالء المتنقلون بترجمة األول إلى الثاني‪ .‬ثم يتم استخدام مواصفات ‪π-‬‬
‫‪ calculus‬لتحليل ومراجعة هذه النظم باستخدام األدوات التحليلية لـ ‪π-‬‬
‫‪) calculus‬مثل أداة ‪ .(MWB‬نوفر دراسة حالة اليضاح الطريقة والتمكن من‬
‫تطبيقها ‪.‬و نقدم أيضا تطوير الطريقة من أجل اتمتت الخطوات المختلفة‬
‫باستعمال اداة ‪.AToM3‬‬
‫كلمات مفتاحية ‪ ;π-calculus ;Mobile UML :‬نمذجة; تحليل‪.‬‬

Table des matières
Table des matières

Introduction générale…………………………………………………………………........01
1. Le paradigme de l’agent mobile…..……………..………………………………….......04
1.1. Introduction………………………………………………………………..…….....…..
05
1.2. Evolution de la mobilité…….……………………………………………….....……. 05
1.2.1. Client-Serveur……….………………………………….....……………………. 05
1.2.2. Evaluation à distance….……………………………….....……………………. 05
1.2.3. Code à la Demande.…….……………………………….....……………………. 06
1.2.4. Agent Mobile…….…….……………………………….....……………………. 07
1.3. Systèmes logiciels à base d'agents mobiles……….....……………………………... 07
1.3.1. Concepts de base et architecture..…………………………….....…………………
07
1.4. Les propriétés des agents.………………………….....………….………………….. 08
1.5. Les plateformes d'agents mobiles……….……......……………………………………09
1.3.1. Présentation…..……………..…………………………….....………………… 09
1.3.1. Standards…………………....…………………………….....………………… 10
1.3.1. Domaines d’application des agents mobiles……………….....………………… 11
1.6. Avantages des agents mobiles……….……......…………………………………… 12
1.7. Désavantage des agents mobiles……….……......……………………….……………13
1.8. La communication entre les agents……….…......……………………………………15
1.9. Conclusion………….………...……………………………….......……….……….. 16
2. UML et le π-calcul.…………………………..……………………………….……....... 17
2.1. Introduction…………………………………..…………………………………….......
18
2.2. La modélisation avec UML……………………………….……………....………... 18
2.2.4. Les diagrammes UML…………………..………………..........……………….... 18
2.2.5. La méta-modélisation avec UML..……..………………..........……………….... 21
2.2.6. Mécanismes d’extension d’UML..……..………………..........……………….... 21
2.3. La spécification avec le π-calcul………………………………......……………...........
22
2.3.1. La mobilité dans le π-calcul…………………….....………………….…………. 23
2.3.2. La syntaxe du π-calcul…..…………………….....………………….…………. 23
2.3.3. Les noms libres et liés.…..…………………….....………………….…………. 25
Table des matières
2.3.4. Notions importantes….…..…………………….....………………….…………. 25

2.3.5. La sémantique du π-calcul..…………………….....………………….…………. 26
2.3.6. Les graphes de flots (Flowgraphs)……………….....………………….………….28
2.3.7. Qualités du π-calcul..………….……………….....………………….…………. 29
2.3.8. Variantes du π-calcul…………….……………….....………………….………….31
2.3.9. Un exemple complet………….……………….....………………….…………. 31
2.4. Conclusion………………………………………………………….....……………. 33
3. Etude comparative des approches existantes….…….…….…….……………….…... 35
3.1. Introduction………………………………………………………...………………... 36
3.2. Travaux connexes…………….…………………………………………...……...... 36
3.3.1. Défis de modélisation et lacunes.………………………….....……………….……
37
3.3. La classification des approches de modélisation de systèmes logiciels à base
d'agents mobiles………..………………………….....………………………..……. 38
3.3.1. Les approches basées sur UML…..…………………….....…………………… 39
3.3.2. Approches formelles………..…………….....…………………………………. 42
3.3.3. Approches hybrides ………..…………….....…………………………………. 43
3.4. Le cadre de comparaison……..…………….....………………………………… 44
3.4.1. Critères de comparaison……….…..…………………….....…………………… 44
3.4.2. Résultats de comparaison..……….…..…………………….....……………………
45
3.4.3. Discussion sur la comparaison.….…..…………………….....……………………46
3.5. Conclusion………………………………………………………….....……………... 49
4. Approche proposée…..………………………………………………………………… 52
4.1. Introduction………………………………………………………………......….……53
4.2. Les diagrammes états-transitions mobiles……………………......………..……….....53
4.3. L'approche proposée………..………………………………......………..………..... 56
4.3.1. Définition formelle des MSDs…………………………......………..………..... 56
4.3.2. Formalisation des MSDs…….…………………………......………..………..... 58
4.3.2.1. Pseudo-états Initial et Final……………………...………..……………………
60
4.3.2.2. Places………………………………………...………..…………………… 60
4.3.2.3. Les états..………...………....………....……..………....………....……….. 62
4.3.2.4. Transition..………...………....………....……..………....………....……….. 63
4.3.2.5. Traitements des évènements..………....……..……...………....……..………..64
4.3.2.6. Traitement des conditions………....…………....…………....…………....… 67
Table des matières
4.3.2.7. Traitement des actions…....……………....……………....……………....……68

4.3.2.8. Traitement transitions marquées…………....……………....……………....…
73
4.3.2.9. Les états composites et les transitions complexes……....…………....…… 74
4.3.2.10. Le système complet…....……....………....………....………....………....…76
4.4. Travaux connexes.………………………......……………………………………… 77
4.5. Discussion et leçons apprises.………………………......…………………………… 79
4.8. Conclusion……………………………………………………………......………........80
5. Etude de cas : modélisation et vérification………………………………………….......81
5.1. Introduction……………………………………………….………………......……….82
5.2. Etude de cas.……………..……….………………………………......……………. 82
5.2.1. Modélisation en MSDs…..…………………………......………..………..... 82
5.2.2. Dérivation du code π-calcul……………………………………………………84
5.3. Analyse et vérification……………………………………………………………… 90
5.3.1. La logique modale………………………………………………………….… 91
5.3.2. L’outil MWB……………………..………………………………………… 92
5.4. Conclusion……………………………………………………………......………........96
6. L'environnement intégré développé………………….…………………………….......97
6.1. Introduction……………………………………………….………………......……….98
6.2. Travaux connexes.……………..…………………………………......……………. 98
6.3. Transformation de graphes…..…………………..………….………..……………… 99
6.3.1. Principe de transformation de graphes.……………………......………..……….....
99
6.3.2. Outils de transformation de graphes.……………………......………..……….....100
6.3.3. Présentation de l’outil AToM3…………………………......………..………..... 100
6.4. L'environnement intégré proposé…..……………………. ...………..………………102
6.4.1. L’architecture de l’outil.......………………………......………..………..... 102
6.5. Méta-modélisation des diagrammes MSDs …..………………..…..……………… 103
6.5.1. Méta-modèle………......………..……….....………......………..………........... 103
6.5.2. La grammaire de graphe proposée………………………......………..……….....107
6.6. Exemple…….....………….....………….....………….....………….....………….....…
112
6.7. Conclusion………………………......………………………………………………..113
Conclusion générale……………………………………………….....………………….....114
Bibliographie et Webographie…………………………………….....……………….….....
115
Communications et Publications…………………………………….....………………….121
Figures
Liste des figures

FIG. 1.1 Le paradigme client-serveur……….…..……………………………….…… 05
FIG. 1.2 Le paradigme évaluation à distance………………………………………… 06
FIG. 1.3 Le paradigme code à la demande…………..………………………..……. 06
FIG. 1.4 Le paradigme agent mobile.………..……………………………........…… 07
FIG. 1.5 Architecture d’un système logiciel à base d'agents mobiles…………………..
08
FIG. 2.1 Classification des types de diagrammes UML...…………………………… 19
FIG. 2.2 Règles de la réduction…………….………………………………………… 26
FIG. 2.3 Règles de la congruence structurelle………………..…..……….………… 27
FIG. 2.4 Règles de transition………..………………………………….…………… 28
FIG. 2.5 Les éléments structurels de graphes de flot………………..…………………29
FIG. 2.6 Passage d’un lien………………………………………………….………… 29
FIG. 2.7 L’intrusion dans la portée d’un lien…………………….……...……...…… 30
FIG. 2.8 L’extrusion de portée d’un lien………..…………………………..…….……30
FIG. 2.9 L’exemple du mouvement d’un véhicule………………….………………. 32
FIG. 3.1 Cycle de vie de développement des systèmes logiciels à base d'agents
mobiles……………….……………...…………………………………….. 37
FIG. 3.2 Classification des approches existantes de modélisation..…….………………
38
FIG. 4.1 Un aperçu du système à un moment donné; une vue de processus π-calcul.…56
FIG. 5.1 Le diagramme d'états transitions mobile du VA………………………….. 80
FIG. 5.2 Le diagramme d'états-transitions mobile du VM………………………….. 80
FIG. 5.3 Le diagramme d'états transitions mobile du VC.…………………………… 81
FIG. 5.4 Application de la simulation…………………………………………………90
FIG. 5.5 Application de la vérification de modèles……………………………………92
FIG. 5.6 Application de la vérification d’équivalence……………………………… 92
FIG. 6.1 Principe de transformation de graphes………….………………….……… 97
FIG. 6.2 Présentation de l’outil AToM3...………………………………………………
98
FIG. 6.3 Le canevas de l’outil AToM3……………………..……….……………… 99
FIG. 6.4 Architecture du framework proposé………………………………..……… 100
FIG. 6.5 Le méta-modèle proposé de diagramme de statechart mobile……….….……
101
FIG. 6.6 L’outil intégré AToM3 pour les diagrammes de statechart mobile………… 104
FIG. 6.7 L’outil intégré développé…………………….….…..……….…………… 110
Tableaux
Liste des tableaux

TAB. 1.1 Plateformes des agents mobiles…………………………………………… 10
TAB. 2.1 Les différents diagrammes UML.……………….………………………… 20
TAB. 2.2 Les noms libres et les noms liés d'un processus…………………………… 25
TAB. 3.1 Légende de comparaison………………….…………..……….…………… 44
TAB. 3.2 Comparaison entre les différentes extensions UML pour la mobilité..…… 45
TAB. 4.1 Les éléments structurels des MSDs..……………………..……………….… 52
TAB. 6.1 La grammaire de graphe proposée………………………………………..…108
TAB. 6.2 Transformation d'un état simple avec une transition mobile vers π-calcul…… 109
Introduction générale
La dissémination de l’informatique dans les différents domaines ces dernières
décennies a engendré beaucoup de défis et de nouvelles situations de plus en plus
compliquées. Cela a poussé les chercheurs à tenter de trouver d’autres paradigmes autres que
ceux déjà existants (spécialement le paradigme orienté objet) pour faire face à ces nouvelles
difficultés rencontrées, notamment dans les systèmes distribués. Le paradigme de l’agent
mobile était considéré au début de la décennie précédente comme étant le successeur de
l’orienté objet, qui va permettre une évolution majeure dans le développement de plusieurs
systèmes critiques dans des domaines différents. Cela est dû aux différentes propriétés qui
caractérisent les agents mobiles, telles que : la mobilité, l’autonomie, l’adaptabilité … etc, qui
fournissent de la flexibilité par rapport à d’autres technologie.
Les systèmes logiciels à base d'agents mobiles sont un type particulier de systèmes
logiciels qui profitent des avantages des agents mobiles. Ils se composent de plusieurs agents
communiquants qui s’éxecutent sur plusieurs places distribuées et qui peuvent se déplacer
entre elles afin de réaliser leurs buts. Cela conduit à un nouveau paradigme qui peut résoudre
plusieurs problèmes complexes dans plusieurs domaines tels que la gestion du réseau, le
commerce électronique, e-learning ... etc.
La modélisation et l’analyse de ces systèmes dans les premières phases de conception
peuvent améliorer largement leur développement. Fournir une approche qui permet de
spécifier et de vérifier tels systèmes n’est pas une tache triviale. En effet, plusieurs aspects
doivent être pris en charge, à savoir la mobilité, et la communication.
Plusieurs tentatives de fournir un langage expressif complet pour ces systèmes sont
proposées dans la littérature. M-UML (mobile UML) [15] est l'une de ces tentatives; c’est une
extension d’UML (Unified Modeling Language) [57] pour modéliser les systèmes logiciels à
base d'agents mobiles en couvrant les aspects de la mobilité qui représente le nouveau concept
inhérent de tels systèmes. M-UML fournit une version de base des diagrammes d'états-
transitions mobiles pour décrire le comportement d'un agent en terme de changement d'état.
M-UML a une sémantique semi-formelle qui empêche toute tâche d'analyse automatique de
ses diagrammes. La transformation des diagrammes vers une méthode formelle adéquate peut
1
résoudre le problème. Le π-calcul [22] peut jouer ce rôle d’une manière satisfaisante. C’est
une algèbre de processus pour décrire le comportement des systèmes concurrents avec
communications mobiles. Nous l’avons délibérément choisi parce qu'il offre les mécanismes
appropriés pour décrire le comportement et le mouvement des agents dans ces diagrammes.
En plus, il fournit plusieurs outils pour automatiser la tâche de vérification.
La première contribution de cette thèse consiste à fournir une étude comparative
complète des différentes propositions qui existent dans la littérature ainsi qu'une classification
des approches de modélisation des systèmes logiciels à base d'agents mobiles. En se basant
sur les résultats de cette étude, nous avons adopté M-UML et l’étendre à cause des avantages
qu’il offre par rapport aux autres.
La deuxième et majeure contribution de ce travail consiste en la proposition des
diagrammes d’états-transitions mobiles MSDs (Mobile Statechart Diagrams) comme
extension des diagrammes d’états-transitions M-UML, suivie d'une approche intégrée
MSDs/π-calcul pour la modélisation et la vérification des systèmes logiciels à base d'agents
mobiles. Dans notre approche, le comportement d'un système logiciel à base d'agents mobiles
est modélisé par un ensemble de diagrammes d'états-transitions mobiles communicants
MSD1... MSDk. L'idée de base proposée consiste à donner à cet ensemble de diagrammes un
système π-calcul correspondant qui consiste en un réseau de processus en interaction, une
reconfiguration de ce système est faite à chaque fois qu’un agent passe d’un état à un autre ou
d’une place à une autre. Pour cela, nous avons proposé vingt-sept (27) règles de
correnspondance entre les diagrammes MSDs et le π-calcul. Les spécifications π-calcul
générées sont ensuite utilisées pour analyser et vérifier ces systèmes à l'aide des outils
d'analyse du π-calcul tel que le MWB (Mobility WorkBench) [66]. L'approche proposée est
illustrée par une étude de cas de la litérature.
La troisième contribution est le développement d’un outil intégré qui permet
l’automatisation de l’approche en utilisant la méta-modélisation et la transformation de
graphes en AToM3 [53].
Le manuscrit est organisé en six chapitres en plus d'une introduction et une
conclusion.
Dans l’introduction générale, la problématique et les contributions du travail de
recherche sont abordées.
Le premier chapitre est dédié au paradigme de l’agent mobile. Le but est de faire un
tour sur les atouts de cette technologie.
2
Le deuxième chapitre est consacré aux deux langages autour desquels nous avons
construit notre approche, à savoir le langage UML et langage π-calcul. Le premier est un
langage semi-formel considéré comme le standard de la modélisation des systèmes orienté
objet, le dernier est un langage formel très connus par sa richesse sémantique pour la
spécification des systèmes concurrents avec communications mobiles.
Dans le troisième chapitre, une étude comparative de différentes approches proposée
dans la littérature est présentée. L’étude consiste en la proposition d’un cadre de comparaison,
une classification et une évaluation de plusieurs propositions.
Dans le quatrième chapitre, nous avons proposé en premier lieu les diagrammes
d’états-transitions mobiles MSDs (Mobile Statechart Diagrams) comme extension des
diagrammes d’états-transitions M-UML. Nous avons introduit de nouveaux éléments dans
MSDs pour prendre en charge la mobilité de manière plus aisée. Puis, nous avons présenté
notre approche qui consiste en la formalisation diagrammes semi-formel MSDs que nous
avons proposé à l'aide du langage formel π-calcul.
Dans le cinquième chapitre, nous avons illustré notre approche par une étude de cas
qui consiste en la modélisation et la vérification d’un système de vote électronique.
Dans le sixième chapitre, nous avons présenté l’automatisation de notre approche en
utilisant une combinaison de la méta-modélisation et des grammaires de graphes. Nous avons
proposé un métamodèle pour les MSDs ainsi qu'une grammaire de graphes pour les
transformer en π-calcul.
Nous avons terminé notre manuscrit par une conclusion générale et des perspectives
de travail de recherche.
3
Chapitre 1
Le paradigme de l’agent mobile
Au sommaire de ce chapitre
1.1 Introduction
1.2 Evolution de la mobilité
1.3 Systèmes logiciels à base d'agents mobiles
1.4 Les propriétés des agents
1.5 Les plateformes d'agents mobiles
1.6 Avantages des agents mobiles
1.7 Désavantage des agents mobiles
1.8 La communication entre les agents
1.9 Conclusion
Le paradigme de l’agent mobile Chapitre 1
1.1. Introduction
Le paradigme de l'agent mobile est une extension des paradigmes client/serveur et

évaluation à distance qui offre un nouveau moyen de développement de systèmes distribués.
Il est considéré comme l'étape la plus récente de l'évolution de la programmation orientée
objet, et les agents ont plusieurs avantages par rapport aux objets. La mobilité est le nouveau
concept qui caractérise ce paradigme ; c’est la capacité de migration d'un agent vers d'autres
hôtes différentes de lui-même où il reprend son exécution, afin de réaliser une tâche.
Dans ce chapitre nous allons évoquer la technologie des agents mobiles, Nous allons
commencer par présenter l'évolution de la notion de mobilité. Puis, nous rappelerons les
concepts fondamentaux des systèmes logiciels à base d'agents mobiles. Nous allons enchainer
avec les proprités, les plateformes, les avantages et les inconvénients des agents mobiles.
Enfin, nous détaillerons la communication entre agents.
1.2. Evolution de la mobilité
Nous allons exposer dans cette section l’évolution de la mobilité de la technologie de

client/serveur jusqu’à l’agent mobile [6].
1.2.1. Client-Serveur
Le paradigme client-serveur est bien connu et largement utilisé. Dans ce paradigme
(voir FIG. 1.1), un serveur (B) situé dans un site (SB) a le savoir-faire et les ressources
nécessaires pour offrir un ensemble de services. Un client (A) situé dans un site (SA)
demande l’exécution de l’un des services en interagissant avec ce serveur. Ce dernier en
réponse, exécute la demande du client et lui envoie les résultats.
Savoir-faire
Savoir-faire
Demande Ressource
s
Réponse
FIG. 1.1 – Le paradigme client-serveur [6].
1.2.2. Evaluation a distance

Dans ce paradigme (voir FIG. 1.2), un composant (A) situé dans un site (SA) a le
savoir-faire essentiel pour effectuer le service, mais il n'a pas les ressources nécessaires, qui se
trouvent sur un site distant (SB). Par conséquent, (A) envoie le savoir-faire du service à un
5
composant de calcul (B) situé sur le site distant. (B) à son tour, exécute le code en utilisant les
ressources qui y sont disponibles et retourne un résultat au composant (A).
Savoir-faire
Demande Ressource
s
Réponse
FIG. 1.2 - Le paradigme évaluation a distance [6].
1.2.3. Code à la Demande

Dans ce paradigme (voir FIG. 1.3), le composant (A) est déjà capable d'accéder aux
ressources dont il a besoin, qui sont co-localisés avec lui sur le site (SA). Cependant, aucune
information sur la façon de manipuler ces ressources n’est disponible à (SA). Donc, (A)
interagit avec un composant (B) situé sur (SB) en demandant le savoir-faire du service, qui est
aussi situé sur (SB). Le (B) envoie par la suite le savoir-faire à (A), qui peut donc commencer
l'exécuter.
Ressource Demande
s
Réponse
Savoir-faire
FIG. 1.3 – Le paradigme code à la demande [6].
1.2.4. Agent Mobile (Mobile Agent)

Dans ce paradigme (voir FIG. 1.4), le savoir-faire du service est possédé par (A), qui
est initialement hébergé par (SA), mais quelques-unes des ressources nécessaires sont situées
sur (SB). Par conséquent, (A) migre à (SB) portant le savoir-faire et peut-être des résultats
intermédiaires. Après qu’il déménage à (SB), (A) complète le service en utilisant les
ressources qui y sont disponibles. (A) peut revenir à (SA) comme il peut ne revenir pas.
Le paradigme de l'agent mobile est différent des autres paradigmes de code mobile,
car les interactions associées impliquent la mobilité d'un composant de calcul existant. En
d'autres termes, alors que dans les paradigmes d’évaluation à distance et code à la demande,
l'accent est mis sur le transfert de code entre les composants, dans le paradigme des agents
mobiles tout un composant de calcul est déplacé vers un site distant, ainsi que son état, le code
dont il a besoin, et quelques ressources nécessaires pour exécuter la tâche.
6
Migration Ressource
s
Savoir-faire
FIG. 1.4 – Le paradigme agent mobile [6].
1.3. Systèmes logiciels à base d'agents mobiles
Les applications basées agents mobiles sont un type spécial de systèmes logiciels qui
profitent des avantages des agents mobiles afin de fournir un nouveau paradigme bénéfique
qui permet de résoudre plusieurs problèmes complexes dans divers domaines et secteurs
notamment les systèmes distribués.
1.3.1. Concepts de base et architecture

Un système logiciel à base d'agents mobiles implique multiples agents (stationnaires
ou mobiles) qui interagissent et communiquent entre eux dans un environnement de
fonctionnement adéquat (plates-formes ou serveurs agents mobiles) où l'exécution des agents
peut avoir lieu et où les différents services et les ressources sont fournis. Nous présentons ici
les éléments essentiels de cette architecture [5]. La figure 1.5 montre l'architecture des
systèmes logiciels à base d'agents mobiles.
Agent: c’est une entité logicielle qui exécute des tâches pour le compte de quelqu'un
(une personne) ou quelque chose (une organisation ou un autre agent) avec une
certaine autonomie, c’est à dire ses actions pourraient être non seulement déterminées
par des événements ou des interactions externes, mais aussi par sa propre motivation
(ou but).
Agent stationnaire: c’est un agent qui exécute à la place ou il a été créé, c’est à dire
qu'il ne bouge pas.
Agent Mobile: c’est un agent qui peut passer d'un nœud à un autre pour accomplir sa
tâche. il peut (ou ne peut pas) retourner à son "nœud-maison".
Plate-forme d'agent: c’est un composant logiciel où les agents peuvent s’exécuter, et
où les différents services et ressources sont fournis pour eux afin d’accomplir leurs
tâches.
Nœud: c’est l'infrastructure de l'environnement d'exécution, sur lequel les agents et les
plates-formes d'agents sont effectivement opérés, il existe au minimum un.
Région: c’est un réseau logique de places qui ont la même autorité.
7
Place: représente un emplacement logique, fourni par les plates-formes d’agents, où

les agents exécutent, et manipulent des ressources locales.
Ressources: représentent des entités non-autonomes, tels que les fichiers, les bases de
données et autres, qui peuvent être utilisés et partagés par plusieurs agents.
Nœud 1 Nœud 2
Plateforme d’Agents A Plateforme d’Agents B
Place1 Place1 Place2
Plateforme d’Agents C
Agent mobile
Agent stationnaire
Place1 Place2
Communiquer
Utiliser
Migrer
Ressource
Région Place3
FIG. 1.5 - Architecture d’un système logiciel à base d'agents mobiles
1.4. Les propriétés des agents
Les agents ont plusieurs propriétés qui confirment leurs qualités par rapport aux
objets. On cite les suivantes [10] [7]:
 Autonomie: la capacité de l'agent de faire ses propres choix et de prendre ses propres
décisions pendant son exécution sans l'intervention d'aucune autre entité externe (par
exemple l'utilisateur).
 Les compétences de communication: la capacité d’établir des relations de

communication avec l’environnement entourant.
 Réactivité: la capacité d’adapter son activité pour répondre aux différents stimuli
externes du fait que l’environnement entourant est toujours sujet de changements
continus.
8
 Notions mentales: la capacité d'acquérir ses propres connaissances comme résultat

des expériences obtenues en cours de son cycle de vie.
 Persistance: Avoir un état interne qui reste cohérent tant qu’il y a des interactions
futures pour réaliser certaines taches.
 Vitalité: la capacité de résoudre les situations les plus défavorables durant son cycle
de vie. En effet, l'agent doit faire face à des situations anormales qui créent un état
d'instabilité qui pourrait menacer ou endommager sa persistance.
 Mobilité: la capacité de migrer d’un hôte à un autre pour achever ses taches.
 La capacité sociale: la capacité de communiquer et de coopérer avec d'autres agents

pour réaliser des objectifs par l'échange d’information et de connaissances.
 Pro-activité: la capacité de générer des événements dans l'environnement entourant,

de commencer des nouvelles interactions avec les autres agents, et de coordonner des
activités avec eux dans l’objectif de réaliser ses taches.
 Véracité: le système des agents prend en compte l’échange des informations qui ne
sont pas sous le contrôle direct des entités d'inspection d’ordre-supérieur, Alors ils
sont tenus de respecter la véracité.
 Bienveillance: un agent mobile doté de caractéristiques mentionnées ci-dessus ne doit

pas accomplir des actes contraires à la volonté de l'utilisateur.
1.5. Les plateformes d'agents mobiles
1.5.1. Présentation
Une plateforme d'agents mobiles (ou système d’agents mobiles) est un système
logiciel distribué responsable du soutien et de la gestion des agents mobiles. Plusieurs plates-
formes ont été mises en œuvre pour le développement des agents mobiles, et il est impossible
de les décrire toutes ici. La plupart des plates-formes d'agents mobiles considèrent Java1
comme langage de programmation des agents en raison de sa portabilité.
Tableau 1.1 évoque quelques exemples de plates-formes. Nous avons sélectionné ces
outils qui, à notre avis, ont été ou sont encore très important pour la communauté de la
recherche et des projets industriels [10].
1
https://www.java.com/fr/
9
Outil Organisation URL

ADK Tryllian www.tryllian.com
Aglets Open Source aglets.sourceforge.net
Ajanta University of Michigan www.cs.umn.edu/Ajanta/
Concordia Mitsubishi www.merl.com/projects/concordia/
D’Agents Dartmouth College agent.cs.dartmouth.edu
Grasshopper IKV www.grasshopper.de
Mole University of Stuttgart mole.informatik.uni-stuttgart.de
Semoa Fraunhofer Society www.semoa.org
Tacoma Uni Tromso www.cs.uit.no/forskning/DOS/Tacoma/
Tracy University of Jena www.mobile-agents.org
Voyager ObjectSpace/Recursion www.recursionsw.com
JADE Telecom Italia www.jade.tilab.com
TAB. 1.1 - Plateformes des agents mobiles
1.5.2. Standards
L’apparition et l’évolution du paradigme de l'agent mobile résultent en un grand
nombre de plates-formes d’exécution. Cela avait commencé de poser plusieurs problèmes tels
que les incompatibilités entre les différentes plates-formes d'exécution des agents mobiles.
Ces dernières sont en fait développées pour s’occuper d’un modèle spécifique des agents
mobiles ainsi que pour cibler certains domaines particuliers, ce qui signifie que les agents
créés par une plateforme ne peuvent pas s’exécuter sur d’autres. Il était alors indispensable de
proposer une normalisation (ou standardisation) des concepts et fonctionnalités des
plateformes d’agents mobiles, au moins afin d'assurer un certain niveau d'interopérabilité. Par
conséquent, deux standards sont développés par les organisations internationales de
standardisation pour faire face à ces problèmes à savoir : la norme MASIF [55] et la norme
FIPA [56].
 La norme MASIF [55] (Mobile Agent System Interoperability Facilities Specification,
Spécification d’équipements d’interopérabilité des systèmes agents mobiles) : est un
standard pour les systèmes d’agents mobiles, qui a été spécifié par l’OMG (Object
Management Group)2 ; une association américaine à but non lucratif créée en 1989
2
www.omg.org/
10
dont l’objectif est de standardiser et de promouvoir le modèle objet sous toutes ses
formes.
 La norme FIPA3 [56] (Foundation for Intelligent Physical Agents, Fondation pour les
agents physiques intelligents) : est un organisme sans but lucratif fondé en 1996 pour
promouvoir l'interopérabilité entre les agents logiciels hétérogènes et les systèmes
d'agents. Elle couvre un grand nombre des principaux domaines du développement des
agents.
1.5.3. Domaines d’applications des agents mobiles

L'émergence des plateformes d'agents mobiles appropriées, a encouragé l'industrie à
commencer investir dans l’utilisation de la technologie des agents mobiles pour développer
ses propres produits. En effet, plusieurs applications bénéficient clairement du paradigme des
agents mobiles comme [2][52]:
 Le commerce électronique : Les agents mobiles sont bien adaptés pour le commerce
électronique. Dans ce type d’applications, on peut confier à l’agent la tache de
dialoguer et négocier avec les services présents sur différents sites pour réaliser la
meilleure transaction possible.
 Recherche et filtrage d’information : Au lieu de déplacer de grandes quantités de
données sur le moteur de recherche pour créer des indexes de recherche, on peut
envoyer les agents mobiles à des sources d'information à distance où ils créent
localement des indexes de recherche qui peuvent ensuite être expédiés vers le système
d'origine.
 Services de réseaux de télécommunication : le soutien et la gestion des services de
télécommunication avancés se caractérisent par une reconfiguration dynamique de
réseau et personnalisation de l'utilisateur. les agents mobiles apportent de la flexibilité
pour ces systèmes en les gardant efficaces.
 Traitement parallèle : une autre utilisation potentielle des technologies de l'agent
mobile est d'administrer les tâches de traitement parallèles, étant donné que les agents
mobiles peuvent créer une cascade de clones dans le réseau.
 Dissémination de l'information. Les agents mobiles incarnent le soi-disant modèle
push Internet4. Les agents peuvent disséminer de l'information, comme les nouvelles
3
www.fipa.org
4
Décrit un style de communication par Internet, où la demande pour une transaction est initiée par le serveur. Cette technique
s'oppose donc au fonctionnement « classique » des transactions web (pull) où la demande de la transmission de l'information
est initiée par le récepteur ou le client.
11
et les mises à jour automatiques de logiciels, pour les vendeurs. Les agents apportent
les nouveaux composants logiciels, ainsi que des procédures d'installation, directement
aux ordinateurs clients où ils mettent à jour et gèrent le logiciel de manière autonome.
 Surveillance et notification. Cette application des agents mobiles met en évidence
leur nature asynchrone. Un agent peut surveiller une source d'information donnée sans
être dépendant du système dont il est issu, ainsi il peut notifier les nouvelles.
D’autre domaines ont aussi montrés beaucoup d’intérêts aux agents mobiles tel
que [2]: la fouille de données, l’intégration de données, l'efficacité énergétique et le comptage,
les capteurs multimédia sans fils, grille informatique, multimédia, sécurité, informatique
affective, environnement climatique et la météo, la formation en ligne, les services du web
sémantique, la localisation humaine, les systèmes d'information géographiques et les systèmes
de surveillance électronique de santé…etc.
1.6. Avantages des agents mobiles
La technologie des agents mobiles fournit plusieurs bénéfices pour surmonter

plusieurs problèmes dans des domaines différents. En plus, elle a été considérée comme une
solution prometteuse pour le problème de la conception et la mise en œuvre des systèmes
distribués en fournissant de nombreux avantages pour eux en profitant de leurs capacités. On
peut citer entre autre les avantages suivants [52]:
 Ils réduisent la charge réseau: généralement, les systèmes distribués impliquent
beaucoup d’interactions pour accomplir une tache, ce qui produit beaucoup de
trafiques réseaux. Les agents mobiles permettent de réduire ces interactions en
déplaçant la conversation localement. Ils sont aussi utiles lorsque de très gros volumes
de données sont stockés à des hôtes distants. Dans ce cas, les données doivent être
traitées dans leurs localités plutôt que les transférer sur le réseau.
 Ils surmontent la latence du réseau : la latence du réseau peut engendrer beaucoup
de difficultés, notamment dans les systèmes critiques, tel que le contrôle des systèmes
à temps réel, qui nécessite de répondre en temps réel aux changements dans leur
environnement. Les agents mobiles offrent une solution, car ils peuvent être envoyés à
partir d'un contrôleur central pour agir localement et exécuter directement les
directions du contrôleur.
 Ils encapsulent les protocoles : Dans les systèmes distribués, chaque hôte possède le
code qui implémente les protocoles d’échange de données. Pour modifier un
12
protocole, il faut changer le code sur toutes les machines du système et cela devient un
problème. Les agents encapsulent les protocoles, changer un protocole revient à
interagir avec un nouvel agent.
 Ils exécutent de manière asynchrone et autonome : les tâches à réaliser peuvent être
intégrées dans des agents mobiles, qui peuvent ensuite être distribués dans le réseau.
Après avoir été envoyés, les agents deviennent indépendants du processus qui les a
créés et peuvent fonctionner de manière asynchrone et autonome.
 Ils s’adaptent dynamiquement: les agents mobiles peuvent s’adapter aux
changements de manière autonome et se répartir eux-mêmes sur des machines du
réseau, afin de maintenir la configuration optimale pour résoudre un problème
particulier.
 Ils sont naturellement hétérogènes: les agents mobiles sont de nature hétérogène et
offrent des conditions optimales pour l'intégration transparente des systèmes basés sur
les réseaux.
 Ils sont robustes et tolérants aux pannes: l'agent mobile a la capacité de réagir
dynamiquement à des situations et des événements défavorables, ce qui facilite la
construction des systèmes distribués robustes et tolérants aux pannes.
1.7. Inconvénients des agents mobiles
Aucune technologie n’est sans inconvénients, y compris la technologie des agents

mobiles qui ne fait pas l’exception. Si les agents mobiles ont des avantages indéniables, ils ont
aussi des manques qui doivent être abordées pour faire des applications à base d'agents
mobiles qui fonctionnent de manière fiable. Nous citons ci-après dix raisons de l'échec des
agents mobiles [9].
 Les agents mobiles ne donnent pas les bonnes performances : en général, les agents
mobiles donnent des performances plus mauvaises que d'autres mécanismes, tels que
l'évaluation à distance. En plus, ils sont aussi très coûteux.
 Les agents mobiles sont difficiles à concevoir : le paradigme fournit l’autonomie des
composants, et par conséquence, il est difficile d'identifier clairement, dans une
conception, quels composants vont interagir et comment cette interaction peut être
modélisée.
 Les agents mobiles sont difficiles à développer : le développement d'une application
à base d’agents mobiles est une tâche effrayante. Le code doit être implémenté de
13
sorte qu'il fonctionne dans des environnements imprévisibles, ce qui est considéré
difficile et pénible. En outre, les technologies qui devraient soutenir le processus de
développement sont souvent juste des prototypes qui ne fournissent pas le type de
soutient requis pour développer des applications réelles.
 Les agents mobiles sont difficiles à tester et déboguer : la distribution et la mobilité
ajoutent de la complexité au processus de test et de débogage d’un logiciel. En fait, les
agents mobiles peuvent se déplacer d'un nœud à l'autre dans un ordre non prédéfini, et
comprendre et tester leur implémentation à partir de telle histoire d'exécution
complexe est très dur.
 Les agents mobiles sont difficiles à authentifier et à contrôler : les agents mobiles
doivent être authentifiés quand ils entrent un environnement. Le problème est qu’ils
sont associés a beaucoup d’identités et il n'est pas clair lesquelles devraient être
authentifiées et comment les mécanismes de contrôle d'accès devraient tenir compte
de cette information.
 Les agents mobiles peuvent être endoctrinés : les agents mobiles sont vulnérables
aux attaques venant des environnements d’exécution malveillants, quand ils voyagent
à travers les différents hôtes pour accomplir leurs tâches. Par exemple, un hôte
malveillant peut modifier le code ou l’image de mémoire d'un agent pour changer la
manière dont l'agent se comporte, et par conséquence il est possible de créer un agent
malveillant.
 Les agents mobiles ne peuvent pas garder les secrets : les agents mobiles ont été
préconisés en tant que des moyens pour implémenter des applications critiques. Pour
effectuer des transactions sensibles (par exemple, signer un contrat), il est souvent
nécessaire d'effectuer les opérations qui exigent le secret, telle qu'une clé privée.
Malheureusement, un secret ne peut pas être effectivement caché s'il doit être employé
par un agent sur un hôte à distance et l'agent ne peut pas interagir avec l’hôte d'origine.
 Les agents mobiles manquent d'une infrastructure omniprésente : les agents
mobiles ont besoin d’une infrastructure qui soutient les tâches de sérialisation,
transfert, et desérialisation de la représentation d'un agent. Cette infrastructure doit
être déployée sur chaque hôte qui peut éventuellement être le destinataire d'un agent.
Ceci est une exigence qui est difficile à satisfaire en particulier parce que les
infrastructures existantes ont été prouvées d’être vulnérables à un certain nombre
d'attaques.
14
 Les agents mobiles ne disposent pas d’un langage/ontologie partagé : les agents
mobiles ont besoin d’interagir avec l'environnement qu’ils visitent afin d'atteindre
leurs buts. Cette interaction exige que le format employé en échange de données et la
signification associée aux données est compris et convenu par l'agent et le partenaire
de l'interaction.
 Les agents mobiles sont étrangement similaires à des vers : le mécanisme des
agents mobiles a une certaine ressemblance frappante avec la façon dont les vers
malveillants se propagent à travers les réseaux. Les vers sont difficiles à supprimer.
Une infrastructure d'agents mobiles soutiendrait l'exécution des agents bénins et
malveillants et, en conséquence, elle serait enclinée à être mise à profit pour lancer des
attaques de type ver.
1.8. La communication entre les agents
Les agents peuvent coopérer pour résoudre des situations complexes par rapport à
leurs capacités individuelles, en interagissant entre eux afin de communiquer des messages,
des connaissances, des objectifs, des plans, …etc. En ce qui concerne la communication et
l'interaction entre les agents, il est important de discuter les différents aspects de leurs
sémantique, tel que [5]:
 Synchronisation. Selon une analyse temporelle, la communication entre les agents

peut être synchrone ou asynchrone. La communication est synchrone (blocage)
lorsque les agents impliqués se synchronisent avant de transférer n’importe quelle
donnée; il convient dans les scénarios où les transferts de données nécessite des
confirmations d'urgence, ou dans les dialogues interactifs. Alternativement, la
communication est asynchrone (sans blocage) lorsque les agents n’ont pas besoin de
réponses.
 Localité. Selon une analyse spatiale, l'interaction entre les agents peut être locale ou
distant. Lorsque l'interaction est locale, les agents se rencontrent à une place commune
et peuvent utiliser tout mécanisme de communication interprocessus connu, par
exemple la mémoire partagée, les fichiers, les variables d'environnement ou de tuyaux
(pipes). Lorsque l'interaction est à distance, les agents communiquent à partir de
différents nœuds par envoi de messages, RPC ou tout autre mécanisme de
communication à distance.
15
 Destination. Habituellement, quand un agent interagit avec d'autres agents, il suit un

pattern de communication point-à-point (unicast). Cependant, il y a des situations dans
lesquelles un agent interagit avec un ensemble dynamique d'agents en utilisant la
communication de groupe, suivant un pattern de communication diffusion (broadcast)
ou multidiffusion (multicast).
 Intermédiation. Enfin, l'interaction entre les agents peut également être directe ou
indirecte. Lorsque l'interaction est directe, les agents invoquent les méthodes des uns
des autres explicitement. Lorsque l'interaction est indirecte, les agents ne
communiquent pas directement; ils utilisent un service intermédiaire, comme Object
Request Brokers (ORB) ou serveurs d'espaces d'information partagés.
1.9. Conclusion
Nous avons présenté dans ce chapitre un tour sur la technologie de l’agent mobile, ses
origines, ses caractéristiques, son architecture, ses avantages et ses inconvénients. Nous avons
vu qu’il existe plusieurs domaines ou l’application des agents mobiles a porté beaucoup
d'intérêts notamment les systèmes distribués. Fournir les mécanismes nécessaires pour la
spécification des systèmes logiciels à base d’agents mobiles doit faciliter leur développement.
Dans les deux chapitres suivants, nous aborderons le langage UML et le langage π-
calcul que nous avons choisi pour la spécification des systèmes logiciels à base d’agents
mobiles.
16
Chapitre 2
UML et le π-calcul
2.1 Introduction
2.2 La modélisation avec UML
2.3 La spécification avec le π-calcul
2.4 Conclusion
UML et le π-calcul Chapitre 2
2.1. Introduction
La modélisation et l’analyse des systèmes logiciels à base d’agents mobiles dans les
premières phases de conception permettent d’améliorer largement leur développement, en
détectant les erreurs qui peuvent créer des problèmes graves après.
Dans ce chapitre nous allons aborder le langage UML et le langage π-calcul. Au début,
nous allons présenter le langage UML et les différents mécanismes de base nécessaires pour
faire comprendre la modélisation avec ce langage, comme les diagrammes UML, la méta-
modélisation avec UML et les mécanismes d’extension d’UML. Ensuite, nous allons faire un
tour sur le langage π-calcul commençant par expliquer la mobilité dans ce langage. Après,
nous exposerons sa syntaxe, sa sémantique, ses qualités et ses différentes variantes, ainsi que
d’autres concepts qui nous intéressent pour le reste de la thèse.
2.2. La modélisation avec UML
La modélisation consiste à la conception d’un modèle. Un modèle est une

représentation abstraite et simplifiée (i.e. qui exclut certains détails), d’une entité (phénomène,
processus, système, etc.) du monde réel en vue de le décrire, de l’expliquer ou de le prévoir
[11]. Plusieurs langages ont été développé pour exprimer les modèles dans les systèmes
orienté objet, le langage UML est le plus célèbre et le plus complet parmi eux. C’est un
produit de l’OMG1 (Object Management Group) qui a été adopté largement dans l’industrie
comme le standard incontournable des systèmes orienté objets. UML est de nature semi-
formel, il n’a pas de sémantique formelle. Cela lui a donné plus de flexibilité et d’adaptation à
plusieurs contextes.
UML est un langage qui permet de représenter des modèles, mais il ne définit pas le
processus d'élaboration des modèles, Toutefois, la littérature sur UML prône, pour tirer
avantage d'UML, de suivre un processus [58]: Itérative et incrémentale, Guidée par les
besoins des utilisateurs du système et Centrée sur l'architecture logicielle. D'après les auteurs
d'UML, un processus de développement qui possède ces qualités devrait favoriser la réussite
d'un projet. Des exemples de processus d'élaboration de modèles UML reprenant les
caractéristiques précédentes sont le RUP (Rational Unified process)2 d'IBM/Rationale, et le
cycle en Y (2TUP - 2 Tracks Unified Process)3 de Valtech.
1
www.omg.org/
2
http://www-136.ibm.com/developerworks/rational/products/rup
3
http://www.valtech.fr
18
2.2.1. Les diagrammes UML

Un diagramme UML est une représentation graphique, qui s’intéresse à un aspect
précis de modèle ; c’est une perspective du modèle. Chaque type de diagramme d’UML
possède une structure et véhicule une sémantique précise. Combinés, les différents types de
diagramme d’UML offrent une vue complète des aspects statiques et dynamiques d’un
système [58]. Une caractéristique importante des diagrammes d’UML, est qu’ils supportent la
notion d’abstraction qui permet de simplifier la représentation et mieux contrôler la
complexité dans l’expression et l’élaboration des solutions objet.
UML 2 comporte ainsi treize (13) types de diagrammes représentant autant de vues
distinctes pour représenter des concepts particuliers du système d’information. Ils se
répartissent en deux grands groupes [11] comme illustré dans la figure 2.1 :
FIG. 2.1 - Classification des types de diagrammes UML (tiré de [60]).

Ainsi le tableau ci-dessous décrit les différents diagrammes UML (voir TAB. 2.1) :
19
Nom de diagramme Description
Diagramme de classes il représente la description statique de système en intégrant dans

chaque classe la partie dédiée aux données et celle consacrée aux
traitements. C’est le diagramme pivot de l’ensemble de la
Diagrammes structurels (statiques)
modélisation d’un système.
Diagramme d’objets la représentation des instances des classes constitue l’objectif du

diagramme d’objet.
Diagramme de composants il représente les différents constituants logiciels d’un système.
Diagramme de il décrit l’architecture technique d’un système.

déploiements
Diagramme de paquetages montre les paquetages et éventuellement les relations entre eux.
Diagramme de structures montre la structure interne d'un classificateur et/ou l'utilisation de

composites la collaboration dans une occurrence de collaboration.
Diagramme de cas il est destiné à représenter les besoins des utilisateurs par rapport
d’utilisation (use case) au système.
Diagramme d’activités il donne une version des enchaînements des activités propre à une
Diagrammes comportementaux (dynamiques)
opération ou à un cas d’utilisation.
Diagramme état-transition il montre les différents états des objets en réaction aux
événements.
Diagramme de séquence il permet de décrire les scénarios de chaque cas d’utilisation en
mettant l’accent sur la chronologie des opérations en interaction
avec les objets.
Diagramme de graphe dont les nœuds sont des objets et les arcs (numérotés selon
communication
la chronologie) les échanges entre objets.
Diagramme global montre les aspects d'une interaction.
d’interaction
Diagramme de temps est un diagramme d'interaction qui décrit à la fois le
(timing)
comportement de classificateurs individuels et les interactions de
classificateurs, en se concentrant sur les temps d'occurrences des
événements qui provoquent des changements d'état.
TAB. 2.1 - Les différents diagrammes UML.
20
2.2.2. La méta-modélisation avec UML

Chaque élément utilisé dans les diagrammes UML a sa propre syntaxe et sa propre
sémantique, définie par le langage avec un méta-modèle. Un méta-modèle signifie
littéralement modèle du modèle. Le méta-modèle UML définit les concepts disponibles pour
la modélisation des applications, c.-à-d., il définit le langage pour spécifier un modèle, alors
qu'un modèle définit le langage pour décrire un domaine d'information. Chaque concept défini
dans une application est une instance d'un autre concept défini dans le méta-modèle. Le méta-
modèle UML a une syntaxe et une sémantique et il est décrit dans une combinaison de
notation graphique, langage naturel, et langage formel [57]:
La syntaxe : définie dans la spécification consiste en : une syntaxe abstraite et une syntaxe
concrète.
 La syntaxe abstraite donnée avec un méta-modèle définissant des relations entre les
éléments. Elle est présentée dans un diagramme de classe UML montrant les méta-
classes définissant les constructions et leurs relations.
 La syntaxe concrète définissant la notation graphique.
La sémantique : permet d’attribuer une signification aux expressions syntactiques. Elle
utilise le langage naturel et l’OCL.
 Langage naturel : la sémantique dynamique d’UML est décrite en anglais.

 OCL : les règles OCL sont utilisées pour décrire la sémantique statique d’UML.
2.2.3. Mécanismes d’extension d’UML

Le standard UML fournit des concepts et des notations, qui ont été soigneusement
conçus pour s’occuper et répondre aux besoins de modélisation de projets typiques de
développement de logiciels. Toutefois, en raison de la diversité des domaines d'application,
les développeurs peuvent nécessiter des notations ou des fonctionnalités supplémentaires au-
delà de celles définies dans le standard UML. Pour cette raison, UML fournit des mécanismes
internes pour étendre le langage de manière contrôlée. Ces mécanismes d'extension
comprennent [5][57]:
 Stéréotypes. Avec un stéréotype, nous pouvons créer un nouvel élément UML à partir
d'un existant en définissant ses propres propriétés spéciales (fournissant son propre
ensemble de valeurs étiquetées), sémantique (fournissant ses propres contraintes), ou
la notation (fournissant sa propre représentation graphique ou icône). Nous pouvons
21
penser à un stéréotype comme un méta-type, parce que chacun crée l'équivalent d'une
nouvelle classe dans le méta-modèle UML.
 Valeurs étiquetées. Chaque élément dans UML a son propre ensemble de propriétés;
par exemple, les classes ont des noms, des attributs et des opérations. Avec les
stéréotypes, nous pouvons ajouter de nouveaux éléments à l'UML, et avec une valeur
étiquetée, nous pouvons définir un nouveau type de propriété qui peut être attaché à un
élément. Nous pouvons penser à une valeur étiquetée comme une métadonnée, car sa
valeur s’applique à l'élément lui-même, et non pas ses instances.
 Contraintes. Tout dans UML a sa propre sémantique. Avec les contraintes, nous
pouvons ajouter de nouvelles sémantiques à tout élément. Essentiellement, une
contrainte spécifie une condition qui doit être vrai pour une ou plusieurs valeurs d'un
modèle (ou partie). Les contraintes peuvent être décrites par des explications
informelles (comme texte libre) ou par des expressions OCL.
Un ensemble cohérent d'extensions, défini à des fins spécifiques à l'aide de ces
mécanismes d'extensibilité, constitue un profil UML. En outre, il est à noter qu'il est possible
d'étendre le méta-modèle UML en définissant de nouvelles constructions selon la technique
de spécification décrite précédemment.
2.3. La spécification avec π-calcul
La spécification d’un système que l'on souhaite développer consiste à lui donner une
description formelle en utilisant les méthodes formelles. Elles sont utilisées dans l'ingénierie
logicielle pour garantir que le produit développé est la solution du problème considéré.
D’abord il faut construire un modèle du problème (la spécification) en utilisant un langage
formel. Ce modèle formel permet par conséquence de faire plusieurs taches : effectuer des
preuves mathématiques pour garantir que ce modèle possède les propriétés voulues
(vérification); valider le modèle à travers des simulations (simulation); développer
rigoureusement le logiciel, ce qui donne la capacité de prouver que l’implémentation est
cohérente par rapport à la spécification (génération de code correct).
Le π-calcul [22][61] est une algèbre de processus conçue pour spécifier les systèmes
concurrents avec communications mobiles. Le π-calcul utilise deux concepts pour modéliser
ces systèmes; un processus (également appelé l’agent) qui est une entité de communication
active dans le système, et un nom qui est quelque chose d'autre, par exemple une liaison de
communication, variable, donnée, …etc. Ce formalisme diffère des autres calculs par
22
l’autorisation du passage des canaux entre les processus et par conséquent l’augmentation du
pouvoir d'expression. Il peut être utilisé pour la modélisation, l'analyse et la vérification de
systèmes mobiles. Nous présentons dans les lignes qui suivent ce langage, sa syntaxe abstraite
ainsi que sa sémantique.
2.3.1. La mobilité dans le π-calcul

Robin Milner4 a noté dans son livre « Communicating and Mobile Systems : the π-
calculus » [22] qu’il y a plusieurs interprétations de la mobilité. Ces derniers diffèrent au
moins en deux aspects : quel genre de mouvements de l'entité, et dans quel espace elle bouge.
Robin Milner en cite trois types de mobilité.
 processus se déplacent dans l'espace physique des sites informatiques.
 processus se déplacent dans l'espace virtuel de processus liés.
 liens se déplacent dans l'espace virtuel de processus liés.
Le π-calcul est basé sur la troisième option. En effet, la localisation d’un processus
dans un espace virtuel des processus est déterminée par ses liens avec les autres processus. En
d’autres mots, les processus avec lesquels ce processus peut communiquer sont considérés ses
voisins (c- à- d. les processus avec lesquels il partage une voie de communication). Dans ce
cas, les mouvements d’un processus peuvent être décrits par les mouvements de ses liens avec
les autres processus et on parle ici d’une reconfiguration de la topologie du système en
question.
2.3.2. La syntaxe du π-calcul

La syntaxe du π-calcul [63] consiste en processus, sommation et préfixes, elle est
donnée par la grammaire BNF suivante:
P ::= M | P | P ' | (ν x) P | ! P | A(y1, … , yn)

M ::= 0 | π.P | M + M '
π ::= x<y> | x(y) | τ | [x = y]π | [x = y]π
Tel que :
 0 : est le processus inactif, c’est-à-dire qui ne fait rien; n’effectue aucune action.
 π.P : est le préfixe, il a une seule capacité exprimée par π, qu’il doit l’exécuter avant
de se comporter comme P.
4
Robin Milner (1934-2010) est le fondateur du π-calcul, c’est un informaticien britannique majeur gagnant de
prix Turing en 1991. Il est très connu dans le domaine de l’informatique théorique.
23
 x(y).P : est le préfixe de réception, il représente la réception de n’importe quel

nom y via x et continue comme P où le nom reçu remplacera y.
 x<y>.P: est le préfixe d’émission, il représente l’envoi de n’importe quel nom y

via x et continue comme P.
 τ.P : est le préfixe silencieux, il représente un agent qui peut évoluer en P sans
interaction visible avec l’environnement.
 [x = y] π.P : est le préfixe de correspondance, il représente un processus qui se

comporte comme π.P si, et seulement si les noms x et y sont identiques, sinon il
va se comporter comme le processus inactif.
 [x = y] π.P : est le préfixe de non-correspondance, il représente un processus qui

se comporte comme π.P si, et seulement si les noms x et y sont non identiques,
sinon il va se comporter comme le processus inactif.
 P | P’ : est la composition des processus, elle représente le comportement combiné de

P et de P’ exécutés en parallèle et qui peuvent procéder indépendamment et agir l’un
sur l’autre par l’intermédiaire des noms partagés.
 P + P’ : est la sommation des processus, elle représente le choix non-déterministe
entre processus, c’est-à-dire se comporter comme P ou P’.
 (ν x) P : est la restriction de nom, elle représente un processus qui se comporte
comme P mais la portée du nom x est limitée à P.
 ! P : est la réplication, elle représente la duplication infinie d’un processus qui évolue
en parallèle avec ses réplications.
 A(y1, … , yn): est le processus identifiant, où n est l'arité de A, a une définition A(x1,
def
… , xn)  P ou xi doit être par paires distinctes, et l’interprétation est que A(y1, … ,
yn) se comporte comme P avec yi remplaçant xi pour chaque i. Une définition peut
être considérée comme une déclaration d'agent, x1,…, xn en tant que paramètres
formels, et la marque A(y1, … , yn) comme invocation avec les paramètres effectifs y1,
… , yn.
De plus, nous définissons les raccourcis suivants:
def
iI Pi  P1 + . . . + Pn somme de plusieurs processus

def
iI Pi  P1 | . . . | Pn composition de plusieurs processus

def
x1  x1, x2,...., xn série de noms
24
2.3.3. Les noms libres et liés

Les noms libres d'un processus représentent sa connaissance (ou son lien) avec
d'autres processus de son environnement, et vice versa. En revanche, les noms liés d'un
processus ne sont pas importants pour son environnement. Les noms liés dans un processus
sont les noms qui se produisent liés par l’opérateur de réception ou de restriction. Une
constante est juste un nom qui ne se produit jamais lié par un opérateur de réception (une
entrée) ou de restriction. Formellement, étant donné un processus P, les ensembles de ses
noms libres fn(P) et ses noms liés bn(P) sont définies dans le tableau 2.2, avec fn(P) U bn(P)
représente l’ensemble de tous ses noms et fn(P)  bn(P) = ø.
P fn(P) bn(P)
0 ø ø
x<y>.Q {x,y} U fn(Q) bn(Q)
x(y).Q {x} U fn(Q)\{y} {y} U bn(Q)
(ν x)Q fn(Q) \ {x} bn(Q) U {x}
Q1 + Q2 fn(Q1) U fn(Q2) bn(Q1) U bn(Q2)
Q1 | Q2 fn(Q1) U fn(Q2) bn(Q1) U bn(Q2)
[x = y]Q {x,y} U fn(Q) bn(Q) \ {x,y}
!Q fn(Q) bn(Q)
A(y1, … , yn) fn(P)  {y1, … , yn} bn(A(y1, … , yn))
TAB. 2.2 - Les noms libres et les noms liés d'un processus
2.3.4. Notions importantes

Sujets et objets d’une action : dans une action de réception x(y), y est appelé l’objet et x est
appelé le sujet, il est positif dans ce cas. De même pour l’action d’émission x<y>, seulement
le sujet est négatif dans ce cas. On appelle aussi x le co-nom de x.
La complémentarité : Deux sujets sont dits complémentaires si l’un est le co-nom de l’autre.
Deux processus sont dits complémentaires s’ils sont préfixés par deux sujets
complémentaires.
La substitution : Une substitution dans P noté P{y/x}, est le résultat de substituer y pour tous
les occurrences libres de x dans P, avec un changement de noms liés si nécessaire pour
empêcher y de devenir lié dans P.
Le α-conversion : Deux processus sont α-convertibles, s’ils ne se diffèrent que par le choix
de noms liés.
25
2.3.5. La sémantique du π-calcul

La sémantique du π-calcul est décrite par un système de transitions non-étiquetées
(Réductions) ou par un système de transitions étiquetées (Transitions) sur l’ensemble de
processus de l’algèbre. La différence est que les réductions sont inférées directement à partir
de la syntaxe du processus, au contraire aux transitions qui sont inférées à partir des actions
d’émission et de réception. En fait, la sémantique de réduction spécifie seulement le
comportement dans le système indépendamment de son environnement, mais comment le
système interagit avec l’environnement est plutôt décrit par un système de transitions
étiquetées.
Les réductions
La sémantique de réduction du π-calcul, désignée par →, spécifie comment un système

représenté peut se développer au fil du temps. P → Q signifie que P peut être transformé en Q
par une étape de calcul atomique (unique), et chaque étape de calcul consiste en l'interaction
entre deux expressions normales [61]. La sémantique des réductions utilise la relation de
congruence structurelle (expliquée ci-après). Cette dernière fonctionne comme un système de
réécriture de termes qui relie ensemble deux processus capables d'agir les uns avec les autres.
Il existe plusieurs règles de réduction. Figure 2.2 montre ces règles. La première règle est
R-INTER, elle montre comment la communication peut se produire entre deux processus
complémentaires. C’est le seul axiome de →, et les autres sont des règles d’inférences. Les
deux règles R-PAR et R-RES illustre comment la réduction peut se produire sous la
composition et la restriction respectivement. La règle R-STRUCT dit que les expressions
structurellement congruentes ont les mêmes réductions.
FIG. 2.2 - Règles de la réduction [63].
26
 Congruence structurelle
La congruence structurelle permet d’identifier les processus qui représentent la même chose à
partir de leurs structures. En effet, deux processus P et Q sont congruents, noté P ≡ Q, si
l’expression de l’un peut se transformer en l’autre par l’utilisation des règles définies au
Figure 2.3.
FIG. 2.3 - Règles de la congruence structurelle [63].

Les Transitions
α α
La relation de transition est désignée par →, P→ Q signifie que P évolue en Q en exécutant
l’action α . Elle est définie par les règles d’inférence de la figure 2.4. Il ne figure pas dans le
tableau, les formes symétriques SUM-R, PAR-R, COMM-R and CLOSE-R des règles SUM-
L, PAR-L, COMM-L et CLOSE-L respectivement, dans lesquels les rôles des éléments
gauches et droits sont inversés.
27
FIG. 2.4 - Règles de transition [63].
2.3.6. Les graphes de flots (Flowgraphs)

Les graphes de flot sont une représentation graphique du π-calcul (cf. FIG. 2.5). Ils
sont introduits dans [64] et adaptés au π-calcul dans [22]. Un graphe de flot illustre la
structure d'un système à un certain état (à savoir les liens entre ses processus dans cet état), et
non pas ses propriétés dynamiques. Un processus (aussi appelé agent) est représenté sous la
forme d'un noeud ovale. Un lien de communication est représenté par une arête entre deux
ports (les deux terminaisons sous forme de points) de deux nœuds. Si le canal de
communication est un nom libre (ce qui signifie que le nom est connu publiquement), il est
désigné par une étiquette sur l’arête. Si le canal est limité aux agents communicants (ce qui
signifie qu'il est privé à ces agents), l'étiquette de l’arête sera positionnée sur les deux
terminaisons de l’arête reliant les deux agents. Dans ce cas, le sens de la communication est
indiqué par l'étiquette du canal. L'étiquette de port de l'agent qui envoie le message est
accentué par une ligne supplémentaire au-dessus de l'étiquette, par exemple, " a ".
28
A a
a
d B
FIG. 2.5 - Les éléments structurels de graphes de flot
2.3.7. Qualités du π-calcul

Le π-calcul fournit une théorie riche, ce qui permet de modéliser naturellement le
comportement d’une large gamme de systèmes. Dans ce qui suite, nous allons exposer
quelques capacités de ce langage inspirés de [61], le but est de donner une vue d’ensemble
expliquée par des exemples qu’on aura besoin pour comprendre le reste du travail. Un lecteur
intéressé de savoir plus peut se référer [61] ou plus de détails et d’exemples sont fournis.
Le passage d’un lien
Supposant qu’on a un système composé de trois processus qui s’exécutent en parallèle P, Q et

R. P partage un lien (nom) x avec R, et il souhaite l’envoyer à Q en utilisant le lien y. Q est
disposé à le recevoir. Alors, prenant P comme yx.P', et Q comme y(z).Q', Dans ce cas, la
transition devra être comme suite :
yx.P' | y(z).Q' | R τ P' | Q'{x/z}
Q'' est Q'{x/z}. Le diagramme montre le cas ou x  fn(Q), signifie que Q ne possède aucun lien
x avant la transition) et x  fn(P′) (signifie que P' n'a pas de lien x après la transition). Mais ces
deux conditions n’affectent pas la transition. C.à.d. même, si x  fn(Q) et x  fn(P′), on aura le
même résultat. On note aussi que la situation ne diffère pas beaucoup quand le lien y entre P
et Q est privé.
FIG. 2.6 - Passage d’un lien
29
L’intrusion dans la Portée
Supposant qu’on a un système composé de quatre processus qui s’exécutent en parallèle P, Q,

R et S. P partagent un lien (nom) x avec R, et il souhaite l’envoyer a Q en utilisant le lien y. Q
est disposé à le recevoir, mais il possède déjà un lien privé x à S. Alors, pour éviter toute
confusion le lien privé doit être renommé. On dit ici que P (ou l'action de passer le lien) fait
une intrusion (ou s’immisce) dans la portée du lien privé x entre Q et S. Alors, prenant P
comme yx.P', et Q comme y(z).Q', le comportement de ce système est représenté par la figure
2.7 et modélisé par le code suivant :
yx.P' | R | (ν x)(y(z).Q' | S) τ P' | R | (ν x')(Q'{x'/x}{x/z} | S{x'/x})
Q'' et S' sont Q'{x'/x}{x/z} et S{x'/x} respectivement où x' est le nouveau nom. Et bien
évidemment cela évite l’intrusion.
FIG. 2.7 - L’intrusion dans la portée d’un lien

L’extrusion de Portée
Supposant qu’on a un système composé de trois processus qui s’exécutent en parallèle P, Q et

R. P partagent un lien (nom) privé x avec R, et il souhaite l’envoyer a Q en utilisant le lien y.
Q est disposé à le recevoir, et il ne possède pas un lien x avant (x fn(Q)). Alors, prenant P
comme yx.P', et Q comme y(z).Q', le comportement de ce système est représenté par la figure
2.8 et modélisé par le code suivant :
(ν x)(yx.P' | R) | y(z).Q' τ (ν x) (P' | R | Q'{x/z})
FIG. 2.8 - L’extrusion de portée d’un lien

30
Dans le diagramme, Q" est Q'{x/z}, et il est proche du premier schéma (cf. FIG. 2.6). La
différence est que le processus P' reste partager le lien x avec R, le fait qu’il y a une restriction
au début de communication (ν x). Et lorsque ce lien est exporté vers Q, la portée de la
restriction est étendue; on dit que P (ou l'action de passer le lien) extrude la portée du lien
privé x. Deux remarques sont à soulignées ici:
 Restant dans x  fn(Q), et on suppose aussi en plus que x  fn(P′), signifie que P' ne
possède pas de lien x après la transition et, par conséquence ne peut plus communiquer
via le, selon la sémantique du π-calcul. Ici, c’est un cas particulier de l’extrusion qui
s’appelle la migration de portée de x, signifie que la portée de restriction de x est
migrée de P vers Q.
 Si x  fn(Q), signifie que Q possède un lien publique x avant la transition, alors, le lien
privé x doit être renommé avant l’interaction afin de préserver sa distinction du lien
public.
2.3.8. Variantes du π-calcul

Depuis son apparence, le π-calcul ne cesse pas d’être sujet d’extension par les
chercheurs afin de l’adapter à différentes situations. En effet, il en existe beaucoup et ce n’est
pas possible de les décrire toutes ici, parmi celles on trouve: le π-calcul polyadique, le π-
calcul asynchrone, le π-calcul probabiliste, le π-calcul stochastique, le π-calcul
temporisé…etc. Dans notre cas nous avons choisi le π-calcul polyadique [62] que nous avons
considéré suffisant pour répondre à nos besoins de spécification et de vérification de nos
systèmes.
Le π-calcul polyadique
Dans le π-calcul monadique (de base), les processus s’échangent des noms uniques. Le π-
calcul polyadique permet aux processus de s’échanger un vecteur de noms. Donc, un
processus émetteur peut avoir cette forme x<y1, …, yn>.P ou tous les yi sont distincts, alors
qu’un processus récepteur serait de la forme x(z1, …, zn).P ; n est un entier naturel positif. Le
π-calcul polyadique peut être codé en π-calcul monadique.
2.3.9. Un exemple complet

Prenant un exemple ou la mobilité est d’une importance centrale [22] pour
comprendre l’approche de modélisation avec le π-calcul (cf. FIG. 2.9). Imaginant des
véhicules en déplacement, chacun d’eux est connecté à un seul transmetteur. Tous les
31
transmetteurs ont des connections fixes avec un contrôleur principal. Lorsqu’il y a un

événement (par exemple l’évanouissement du signal) un véhicule peut être commuté vers un
autre transmetteur. Pour des raisons de simplification, considérant le cas d'un seul véhicule et
deux transmetteurs.
System1 System2
FIG. 2.9 - L’exemple du mouvement d’un véhicule
Considérant premièrement le transmetteur Trans, qui est en contact avec le véhicule

Car et le contrôleur central Control. Montrant ses liens actuels en tant que paramètres, nous le
représentons par l'expression :
Trans<talk1, switch1, gain1, lose1>
Le véhicule Car peut parler (talk1) via le transmetteur, mais à tout moment le
contrôleur central Control, peut dire au transmetteur de perdre le véhicule (lose1). On utilise
des équations récursives pour définir le comportement d'un transmetteur comme suit:
def
Trans(talk1, switch1, gain1, lose1)  talk.Trans(talk, switch, gain, lose) +
lose(t, s).switch<t, s>.Idtrans<gain, lose>
def
Idtrans<gain, lose>  gain(t, s).Trans(t, s, gain, lose)
On peut remarquer la transmission des noms (canaux) comme messages. Une action
positive comme lose(t, s) reçoit des noms, alors qu’une action négative comme switch<t, s>
envoie des noms. Alors, lose(t, s) est une construction de liaison de nom ; elle introduit les
noms liés t et s.
Le contrôleur Control, en disant à Trans de perdre le véhicule, délivre une nouvelle
paire de canaux pour transmettre au véhicule afin de remplacer sa paire de canaux ancienne. Il
délivre également la même paire à l'autre transmetteur (Idle), qui peut alors interagir avec le
véhicule. Dans notre formulation simple, Control délivre toujours un des deux paires des
canaux possibles:
32
def
Control1  lose1<talk2, switch2>.gain2<talk2, switch2> Control2
def
Control2  lose2<talk1, switch1>.gain1<talk1, switch1> Control1
Enfin, le véhicule Car peut soit parler ou, si demandé, commuter à une nouvelle paire
de canaux.
def
Car(talk, switch)  talk.Car(talk, switch) + switch(t, s).Car(t, s)
L'ensemble du système est assemblé dans un processus formé par une composition
restreinte de quatre processus :
def
System1  new talk1, switch1, gain1, lose1, talk2, switch2, gain2, lose2
(Car(talk1, switch1) | Trans1 | Idtrans2 | Control1)
Ou on utilise les définitions auxiliaires:

def
Transi  Trans<talki, switchi, gaini, losei>
def (i = 1, 2)
Idtransi  Idtrans<gaini, losei>
Le système System1 évolue au système System2 et vice versa (en appliquant les règles
de réaction).
*
System1 System2
Tel que:
def
System2  new talk1, switch1, gain1, lose1, talk2, switch2, gain2, lose2
(Car(talk2, switch2) | Trans2 | Idtrans1 | Control2)
2.4. Conclusion
Dans ce chapitre, nous avons évoqué la modélisation avec le langage UML qui est un
standard très répondu pour le développement des systèmes orienté objet. Nous avons introduit
le langage et exposé ses différents diagrammes, il ne prenait pas en charge les systèmes
mobiles, mais nous avons vu les différent mécanismes fournis par le langage lui-même pour
faire l’étendre afin de l’adapter aux différents types d’applications.
Nous avons aussi présenté le π-calcul, une façon de décrire et d’analyser les systèmes
constitués de processus qui interagissent les uns avec les autres, et dont la configuration se
change d’une manière continue. Nous avons présenté la syntaxe et la sémantique de ce
formalisme, en plus nous avons illustré comment la portée et la mobilité sont des notions
33
étroitement interdépendantes. Le but est de monter que la richesse théorique du π-calcul le

rend un bon choix pour la spécification et la vérification des systèmes concurrents et mobiles.
Dans le chapitre suivant, nous allons voir une étude comparative de différentes
approches proposées pour spécifier les systèmes logiciels à base d’agents mobiles en
focalisant sur celles qui sont basées sur UML.
34
Chapitre 3
Etude comparative des approches

existantes
3.1 Introduction
3.2 Travaux connexes
3.3 La classification des approches de modélisation
des systèmes logiciels à base d'agents mobiles
3.4 Le framework de comparaison
3.5 Conclusion
Etude comparative des approches existantes Chapitre 3
3.1. Introduction
La modélisation et la conception de systèmes logiciels à base d'agents mobiles ont

reçu une importante attention dans les dernières années. La construction d'un langage de
modélisation à partir de zéro est une tâche difficile, c’est ce qui a incité les chercheurs
d'importer les éléments essentiels de la réussite du paradigme orienté objet, et d’y introduire
les caractéristiques (fonctionnalités) appropriées pour soutenir le paradigme des agents
mobiles.
Ce chapitre recueille, catégorise et examine les approches actuelles de modélisation
des systèmes logiciels à base d'agents mobiles qui ont été développés dans le but de s’occuper
des phases d’analyse et de conception de ces systèmes. Nous nous sommes concentrés ici sur
les approches basées sur UML [57], et considérées comme langages complets car ils couvrent
multiples vues des systèmes logiciels. En outre, nous proposons un cadre pour la comparaison
de ces langages qui consiste en plusieurs facteurs identifiés à partir d'une revue
bibliographique. Une discussion approfondie sera ensuite effectuée, qui permet une meilleure
compréhension des avantages et inconvénients de différentes approches.
3.2. Travaux connexes
Seuls quelques travaux sont disponible dans la littérature qui examine les techniques et
outils pour la modélisation de systèmes logiciels basés agent mobile. Notre travail est
similaire à certains travaux, comme celui de [1] qui fournit un aperçu des méthodologies
orientées-agent existantes, il discute quelles approches ont été suivies pour assister dans toutes
les phases du cycle de vie d'une application à base d'agents, il est à noter que les chercheurs
ont travaillé sur l'extension des méthodologies déjà existantes pour inclure les aspects
appropriés des agents, ces extensions ont été réalisées principalement dans deux domaines: les
méthodologies orientée objet (OO) et les méthodologies ingénierie des connaissances (KE).
Melomey et al. [3] présente dans leur travail une évaluation des approches et des
méthodologies déjà proposées pour développer le paradigme des agents mobiles. En fait, ils
ont proposé un certain nombre de concepts nécessaires pour modéliser la mobilité afin de
surmonter les limitations des approches proposées en termes de modélisation de la mobilité de
l'agent, cependant les auteurs se mélangent entre les langages et les méthodologies de
modélisation. Belloni et Marcos [5] ont examiné plusieurs extensions UML de modélisation
des agents mobiles dans un objectif de définir une unique extension qui rassemble et intègre
36
les caractéristiques des autres. Hachicha et al. [42] ont évoqué plusieurs approches de
modélisation des applications à base d’agent mobile en utilisant UML. Cervenka &
Trencansky [48] ont fourni un aperçu sur les techniques de modélisation orientée agent,
cependant ils ont concentré sur les systèmes multi-agents. Melomey et al. [49] ont fourni une
étude comparative de quelques approches de modélisation des systèmes à base d’agents.
Bauer & Muller [50] ont fait un tour sur des approches et des méthodologies existantes pour
les applications à base d’agents, cependant la modélisation des agents mobiles n’était pas
l'intérêt central de ce travail.
D'autres approches peuvent être citées, mais il est intéressant de noter un problème
dans ces contributions, c’est le mélange de concept de langages de modélisation et de
méthodologies. Ainsi, dans notre étude, nous avons mis l'accent sur les langages de
modélisation parce que nous croyons qu'ils représentent la clé du succès d’un paradigme,
puisque les agents mobiles sont introduits dans différents domaines, et les méthodes ne
peuvent pas être générales, mais plutôt adaptées à des situations spécifiques. Donc, examiner
les méthodologies est au-delà de la portée de cette étude. En outre, on ne considère que les
applications à base d’agents mobiles avec emplacements statiques (mobile Computation). Les
applications avec des emplacements dynamiques (mobile Computing) sont au-delà de la
portée de notre travail.
3.2.1. Défis de modélisation et lacunes

La mobilité est le nouveau concept, qui caractérise les systèmes logiciels à base
d'agents mobiles. Sa modélisation représente un grand défi, car elle produit une
reconfiguration dynamique complexe du système en question tout au long de son exécution.
Ainsi, fournissant une approche qui a la capacité de la concevoir est tout à fait non triviale. En
effet, l'approche doit donner des réponses à des questions qui découlent de l'utilisation
d'agents mobiles [16], par exemple pourquoi un agent mobile se déplace d'un hôte à un autre,
quand l'agent se déplace, où l'agent se déplace, et comment il atteint l’hôte cible.
En ce qui concerne la sécurité des agents mobiles, plusieurs recherches ont proposé un
certain nombre de mécanismes, qui suivent différentes façons d’aborder les problèmes de
sécurité (mentionnés ci-dessous). Certains de ces mécanismes ont été intégrés dans les plates-
formes d'agents mobiles pour les rendre sécurisés pour la programmation réseau. D'autres
mécanismes peuvent être spécifiés par les concepteurs pour renforcer la sécurité de
l'application. En effet, plusieurs approches de modélisation offrent une vue de la sécurité, qui
permettent la description des différents mécanismes utilisés afin de prévenir la vulnérabilité
37
des applications a base d'agents mobiles. Ces mécanismes comprennent, par exemple:
l'authentification des agents et des plateformes d’agents mobiles, l'autorisation et le contrôle
d'accès aux ressources. Cependant, il n’est vraiment pas clair comment on peut définir des
idées standards pour la modélisation de la sécurité, parce que les agents mobiles sont
appliquées dans de nombreux domaines qui ont des contextes entièrement différents (chaque
domaine a ses propres particularités).
Dans les systèmes orientés objet, UML [57] a joué un rôle essentiel et décisif dans le
succès de cette technologie. En fait, en l'utilisant, vous pouvez modéliser toutes les parties de
développement d'une application orientée objet, de son étude de faisabilité jusqu'à son
déploiement. Les chercheurs ont suivi les méthodes appropriées du paradigme antécédent
pour la modélisation des agents mobiles afin de définir et de développer un langage de
modélisation qui a la capacité de jouer, dans le paradigme des agents mobiles, le même rôle
que UML a déjà joué dans le paradigme orienté objet.
Le cycle de vie de développement de systèmes logiciels à base d'agents mobiles est en
général composé de trois phases; la phase d'analyse, la phase de conception, et la phase
d’implémentation. En fait, dans ces systèmes, la dernière phase a récemment été enrichi d'une
manière satisfaisante par un grand nombre de différentes plates-formes qui soutiennent et
mettent en œuvre le paradigme des agents mobiles. En revanche, les approches proposées
pour l'analyse et la conception de systèmes logiciels à base d'agents mobiles ne sont pas très
répandues, ont une portée limitée et sont incomplètes en elles-mêmes. Figure 3.1 illustre le
l’état actuel du cycle de vie de développement de systèmes logiciels à base d'agents mobiles.
En cours de développement …
Server 3
Analyse Implémentation
Conception
Aglets, Ajanta,
Limité
AML, AUML, M-UML, Grasshopper,
MA-UML, MAM-UML… Voyager, JADE
Enrichi
…
FIG. 3.1 - Cycle de vie de développement des systèmes logiciels à base d'agents mobiles
3.3. La classification des approches de modélisation de systèmes

logiciels à base d'agents mobiles
Dans cette section, plusieurs approches de modélisation ont été examinées et quelques
autres sont seulement citées. Le but est de couvrir plusieurs points de vue sur les façons de
38
traiter ces systèmes. Ainsi, nous avons classé les propositions existantes de modélisation des
systèmes logiciels à base d'agents mobiles en trois grandes catégories (voir figure 3.2) :
Les approches basées sur UML: ces approches ont abordé le problème de
modélisation des applications à base d'agents mobiles en utilisant UML [57]; le
langage standard du paradigme orienté objet.
Les approches formelles: ces approches utilisent les méthodes formelles pour la
modélisation des applications à base d'agents mobiles.
Les approches hybrides: ces approches résultent d'une intégration hybride des
caractéristiques des deux catégories précédentes en plus d'autres approches inspirées
de divers paradigmes.
Hybrid
UML based Formal
approaches
approaches approaches
FIG. 3.2 – Classification des approches existantes de modélisation.
3.3.1. Les approches basées sur UML

Dans cette catégorie, les chercheurs ont tenté de relier le paradigme agent mobile au
paradigme orienté objet en étendant le standard de-facto de ce dernier afin de pouvoir
modéliser les agents mobiles. En fait, UML [57] fournit des mécanismes pour étendre lui-
même. Alors, sur la base de l'expressivité et l'extensibilité d’UML, les chercheurs l'ont adopté
et lui ajouté les artéfacts appropriés afin de soutenir le nouveau paradigme. Donc, nous nous
présentons ici quelques propositions que nous avons qualifié comme des langages complets le
fait qu’ils considèrent plusieurs vues d’un système.
AUML (Agent UML): Bauer et al. [13] proposent Agent UML (AUML) qui peut être
considéré comme l’extension UML la plus connue pour les agents. AUML offre la
possibilité de décrire le comportement interne d'un agent ainsi que son comportement
externe. Les parties centrales d’AUML sont le diagramme de classes d'agent et le
diagramme de protocole d'interaction qui étendent respectivement le diagramme de
classes et le diagramme de séquence UML. Il est développé dans un premier temps
pour s’occuper uniquement de systèmes multi-agents, mais ses diagrammes de
39
déploiement et d'activité ont été étendus par la suite [16] [40] afin de supporter la
modélisation de la mobilité de l'agent. Les nouvelles annotations introduites par
l'extension diagramme de déploiement AUML facilitent la modélisation de migration
de l'agent entre différents nœuds et les localités concernées par le mouvement. En
outre, la question du moment de mouvement peut être exprimée par le diagramme
d'activité AUML, c.-à-d. quand un agent mobile doit migrer. Multiples concepts et
notations ont été développés dans ce langage [51], mais les caractéristiques
essentielles des applications à base d'agents mobiles ne sont pas prises en compte. La
mobilité par exemple est décrite statiquement, en plus la sécurité est entièrement
omise.
AML (Agent Modeling Language): Cervenka et al. [14] [48] introduisent AML; une
extension de UML qui incorpore différents concepts et caractéristiques des systèmes
multi-agents. AML est actuellement considéré comme le langage de modélisation
orientée agent le plus complet. Il couvre la modélisation de la structure statique,
dynamique et le comportement des entités dans un système multi-agents. AML tente
également de fournir un support de modélisation a la mobilité, en reconnaissant et en
identifiant les propriétés de l'environnement de l'agent, l’hôte, et le comportement
(migration et clone). Le langage ne considère la mobilité que dans le niveau
d’implémentation lorsque le système multi-agent est déployé. Cela le rend inapproprié
pour la modélisation des applications réelles d'agents mobiles.
MAM-UML (Mobile-Agent Modeling with UML): Belloni et Marcos [5] [39]
proposent MAM-UML pour essayer de définir une extension UML unique qui
rassemble et intègre les caractéristiques d'une grande partie d’approches basées sur
l’extension d’UML. Les auteurs ont défini un ensemble de vues : organisationnelle,
cycle de vie, interaction et une vue de mobilité, matérialisées par un profil UML
appelé MAM-UML. Ce profil décrit en détail plusieurs caractéristiques intéressantes
d'une application basée agents mobiles, tels que l'itinéraire d'un agent mobile, les
différents types de mouvement et le plan des tâches.
M-UML (Mobile UML): Saleh et El-Morr [15] proposent une extension complète du
standard UML 1.4 appelée (M-UML), où tous les diagrammes ont été étendus pour
s’occuper de la modélisation des systèmes logiciels à base d'agents mobiles. Tout au
long d’un exemple illustratif, les auteurs présentent et décrivent les extensions
effectuées dans chacun des diagrammes UML, pour modéliser les aspects de la
mobilité. Les auteurs omettent les mécanismes de sécurité et leur modélisation. Les
40
auteurs se concentrent uniquement sur la modélisation de la mobilité. L'approche est

suffisamment expliquée, mais son expérimentation reste à exercer pour juger sa
qualité.
MA-UML (Mobile Agent UML): Hachicha et al. [42] ont proposé sept diagrammes
basés sur l'extension de diagramme d’état/transition et diagramme d'activité UML,
ainsi que le diagramme de séquence AUML. Les auteurs ont essayé d’aborder en
détails plusieurs aspects non-couverts par les autres extensions. Ils ont également
développé un outil CASE nommé MAMT (Mobile Agent Modeling Tool) [43] pour
soutenir l'utilisation du profil MA-UML et la génération automatique de code Java à
partir de ses diagrammes. cela simplifie considérablement la modélisation et la mise
en œuvre des applications d’agents mobiles. Nous avons découvrit avec surprise que
MA-UML est le dernier langage développé dans la littérature en ces dernières années
(qui traite différents vues d'applications à base d'agents mobiles). Cela montre que la
communauté de recherche a partiellement abandonné ce domaine en dépit de son
utilité.
En plus de ces langages, certaines propositions sont très intéressantes. Cependant, ce

sont des approches partielles car elles n’adressent pas tous les vues d'un système logiciel à
base d'agents mobiles. Klein et al. [17] proposent une extension d’UML pour les agents
mobiles; cependant, leur approche est limitée à une plate-forme spécifique d'agents mobiles
(plateforme Grasshopper [8]) et à une classe spécifique d'applications d'agents mobiles, en
plus ils ne fournissent pas de description de mobilité pour tous les vues et les aspects des
systèmes. Kang et al [19] proposent une approche pour modéliser les agents mobiles par une
extension de diagramme d'activité UML 1.5. Bahri et al. [20] proposent dans leur travail une
extension de plusieurs diagrammes UML 2.0 pour modéliser les systèmes logiciels à base
d'agents mobiles dans le but de s’occuper de nouveaux concepts introduits par ces systèmes
tels que la migration, le clonage et les localités. Kusek et Jezic [4] proposent d’étendre le
diagramme de séquence UML pour modéliser le comportement des agents avec mobilité; ils
ont concentré sur la capture de la création d'agent, les chemins de mobilité et l'emplacement
actuel de l'agent.
Bien que ces approches ont tenté de soutenir la modélisation des systèmes logiciels à
base d'agents mobiles, la quasi-totalité de ces techniques, en fait, ont été apporté du domaine
de systèmes multi-agents ou on se concentre davantage sur l'expression des relations inter-
agents. Du point de vue des systèmes distribués, la description de la mobilité (et ses
41
conséquences comme la sécurité) n’est pas décrit assez pour fournir des approches basées
UML, efficaces et robustes pour modéliser les applications à base d'agents mobiles comme
dans le cas des applications orientée objet avec UML.
3.3.2. Approches formelles

En génie logiciel, les méthodes formelles sont un type particulier de techniques basées
sur les mathématiques pour la spécification, le développement et la vérification des systèmes
logiciels [21]. L’utilisation des approches formelles, pour spécifier et vérifier le
fonctionnement des systèmes logiciels basés agents mobiles durant les premières étapes du
cycle de vie de développement est très intéressant, et il doit contribuer à la fiabilité et la
robustesse de la conception, en raison de la puissance de l'analyse mathématique approprié.
En fait, plusieurs formalismes ont été utilisés pour les agents mobiles, souvent inspiré des
deux formalismes efficaces; algèbres de processus et réseaux de Petri. Nous rappelons
certains d'entre eux dans cette section.
Dans le contexte des algèbres de processus, Milner [22] a proposé le langage π-calcul
pour la modélisation des agents mobiles; il offre la possibilité de mouvement de liens dans un
espace virtuel de processus liés afin de décrire la mobilité, en fait la plupart des approches
proposées sont basées sur ce formalisme. Jezic et Lovrek [47] ont présenté une approche de
spécification formelle et vérification de la migration et la communication des agents mobiles
dans un réseau en utilisant le formalisme π-calcul. Fourn et al. [23] ont proposé un calcul pour
les agents mobiles, avec une définition précise de la migration, d'échec et de détection de
pannes, ils utilisent le Join-calcul distribué qui est aussi expressif que le π-calcul asynchrone
pour coder leur calcul distribué, ce dernier soutienne les localités explicites et les primitives
pour mobilité, ce qui permet d'exprimer le mouvement des agents mobiles entre les nœuds
d’une manière claire. Oquendo et al. [24] ont proposé le π-ADL, conçu dans le projet
européenne ArchWare1, pour aborder la spécification des architectures dynamiques et
mobiles; c’est un langage formel, théoriquement bien-fondé qui est basé sur le π-calcul typé a
ordre supérieur (higher-order typed π-calculus), il peut être utilisé pour définir les
architectures statiques, dynamiques et mobiles. Autres travaux proposent formalismes pour la
description des agents mobiles. Schmitt et Stefani [28] ont présenté une extension π-calcul
pour spécifier la mobilité des agents dans des cas complexes. Dans le travail de Sewell et al.
[29], une architecture de communication entre les agents mobiles est formalisée en utilisant
une extension π-calcul. Bettini et.al [21] ont formalisé des propriétés des systèmes basés
1
http://www.arch-ware.org/
42
agents mobiles, les propriétés des agents sont exprimées de façon dynamique en fonction de
l'évolution de leurs localités. Cardelli et Gordon [34] ont proposé le « Mobile Ambients » qui
est un calcul pour décrire le mouvement des processus ainsi que les appareils. D'autres
approches formelles pour capturer la mobilité sont développées dans [35] et [36].
Dans le contexte des réseaux de Petri, plusieurs propositions ont été également
développées. En fait, elles bénéficient de ce formalisme qui est un modèle formel mature en
termes de représentation graphique, description mathématique, et outils. Xu et Deng [25] ont
tenté de modéliser les agents mobiles en utilisant les réseaux de Pétri de haut niveau. Xu et al.
[26] propose dans leur travail une approche pour la modélisation formelle de la mobilité
logique de l'agent en utilisant les réseaux prédicat/transition (PrT), ils représentent un système
d'agents mobiles comme un ensemble d'espaces d'agents, et les agents peuvent migrer d'un
espace à un autre. Xu et Schatz [27] ont essayé de concevoir les agents mobiles en utilisant les
réseaux de Petri haut niveau G-net.
3.3.3. Approches hybrides

La combinaison d'outils de modélisation visuelle de systèmes logiciels à base d'agents
mobiles et de méthodes formelles a reçue beaucoup d'attention ces dernières années.
L’objectif est d’essayer de fournir des langages de modélisation puissants permettant la
spécification et la vérification de ces systèmes, tenant en compte d’un côté les faiblesses des
modèles visuels en matière de sémantique formelle en raison de leur caractère semi-formel, et
de l’autre côté les faiblesses des modèles formels en matière de notations graphiques. Cela a
beaucoup encouragé des chercheurs de tenter de mélanger les deux afin de bénéficier des
avantages de chacun des deux. Dans sa thèse, Bahri [30] propose une approche hybride pour
modéliser les systèmes logiciels à base d'agents mobiles; son approche est basée sur une
extension UML et le formalisme réseaux de Petri imbriqués. L’approche bénéficie des
avantages d’UML et remède son insuffisance en termes de sémantique par l’utilisation des
réseaux de Petri imbriqués afin de permettre l'analyse formelle de ces modèles. Knapp et al.
[31] ont proposé une approche de modélisation semi-formelle/formelle pour les objets
mobiles en utilisant une extension de diagramme d’état/transition UML et le formalisme
MTLA [32], le but est d’étudier les concepts de raffinement. Latella et al. [37] ont proposé
une extension de diagramme d'état/transition UML accompagnée d’une sémantique formelle
pour la spécification du comportement des objets mobiles. Belghiat et al. [18] ont proposé une
approche combinée, fondée sur une extension d’UML et le π-calcul pour la modélisation et la
vérification des applications basées agents mobiles. Belghiat et al. [54] ont également
43
développé une transformation automatique entre les diagrammes de classes mobiles et les
ontologies OWL afin de permettre un raisonnement automatique.
Ils existent d'autres approches, qui proposent d'utiliser les motifs de conception pour
développer les systèmes logiciels basés agents mobiles comme dans [33], [44] et [45]. De
nombreux motifs de conception ont été identifiés dans la littérature pour les agents mobiles
tels que des motifs d’agent et des motifs d'interaction. Certains d'entre eux sont décrits en
utilisant UML tandis que d'autres ne sont pas.
3.4. Le cadre de comparaison
3.4.1. Critères de comparaison

Comme nous avons dit au début de ce chapitre, on s’intéresse uniquement sur les
langages de modélisation puisque les autres approches sont considérées comme des
contributions partielles. En fait, pour modéliser le niveau conceptuel de systèmes logiciels
basés agents mobiles, multiples fonctionnalités et caractéristiques doivent être présents dans
l'outil développé pour soutenir l'analyse et la conception de ces systèmes. Chhetri et al. [41]
ont proposé une ontologie intéressante pour décrire les concepts abstraits, et leurs
interrelations, nécessaires pour modéliser la mobilité de l'agent afin de fournir un support au
niveau conceptuel des applications d'agents mobiles. De manière analogue, Melomey et al. [3]
ont également proposé une autre ontologie dans le même but. Sur la base de ces deux
ontologies et passant en revue la littérature, essentiellement [42], [43], [5] et [46], nous avons
défini des exigences qu’on a considéré qu'ils représentent les facteurs de réussite de chaque
approche de modélisation proposée pour les applications à base d'agents mobiles.
 Structure interne; ce critère illustre la structure interne de chaque agent (y compris les
agents mobiles) impliqué dans l'application, comme ses attributs tels que la pro-
activité, la réactivité, l'autonomie, l'autorité.
 Cycle de vie; ce critère détermine le comportement d'un agent; en d'autres termes, le
chemin de mobilité (s’il existe) et le plan des tâches (décrit le plan d'exécution des
tâches par l’agent dans différents emplacements).
 Besoins d'exécution; ce critère illustre les besoins d'exécution pour chaque agent (y
compris les agents mobiles) impliqué dans l'application, par exemple, les ressources et
les services dont il a besoin, et les rôles qu'il vas jouer.
 Environnement d’exécution; ce critère décrit l'environnement d'exécution à savoir les
places, les régions, et les plates-formes d'agents.
44
 Mobilité; ceci est le critère le plus important qui doit être décrit en détail par un
langage de modélisation. Il est soutenu par les mécanismes de migration, invocation et
de clonage à distance et il est lié aux concepts de l'itinéraire, et l'emplacement.
 Interaction; ce critère illustre les mécanismes d'interaction adoptés en communication,
par exemple communication synchrone ou asynchrone.
 La sécurité; ce critère a un impact majeur sur la fiabilité du logiciel. Le langage de
modélisation doit permettre de décrire les mécanismes de sécurité adoptés, à savoir
comment protéger les entités de l'application de l'utilisation malveillante.
Autres critères générales sont inspirés des aperçus d'évaluation des langages de
modélisation en particulier à partir de [38].
 Outils; un bon langage de modélisation doit être soutenu par un outil CASE pour
faciliter son automatisation et son utilisation.
 Fondement théorique; un langage de modélisation qui a une base théorique solide est
considéré comme un langage puissant.
 Simplicité et clarté; déterminent l'acceptabilité du langage par l'utilisateur.
 Processus (méthodologie); un processus qui accompagne un langage de modélisation
devra améliorer largement la tache de développement.
3.4.2. Résultats de comparaison

Le tableau 3.1 illustre la notation que nous avons utilisée dans notre comparaison
inspirée de [46].
Symbole Déscription
Inconnu; pas assez d'informations pour
déterminer
Vraisemblablement pas pris en charge
Certainement pas pris en charge
Partiellement Pris en charge
Pris en charge
TAB. 3.1 - Légende de comparaison
Le tableau 3.2 ci-dessous résume la comparaison des cinq langages de modélisation

qui sont définis pour modéliser des systèmes logiciels à base d'agents mobiles.
45
Langages de AUML AML

MAM- M- MA-
modélisation UML UML UML
Structure interne
Cycle de vie
Caractéristiques de base
Besoins d'exécution
Environnement
d’exécution
Mobilité
Interaction
Sécurité
Autres caractéristiques
Fondement théorique
Simplicité et clarté
Processus
(méthodologie)
Outils
TAB. 3.2 - Comparaison entre les différentes extensions UML pour la mobilité.
3.4.3. Discussion sur la comparaison

Le tableau ci-dessus (cf. TAB. 3.2) résume les capacités de modélisation de chaque
langage en ce qui concerne les différentes caractéristiques que nous avons proposées. Les
lignes suivantes présentent les résultats de la comparaison:
 La structure interne des agents mobiles a été complètement prise en compte dans MA-
UML. En fait, un diagramme complet “Mobile Agent Diagram” est attribué pour
spécifier entièrement la structure interne des agents mobiles de l’application. C’est une
version étendue du diagramme de classes AUML, qui a en plus des propriétés
supplémentaires pour la modélisation des agents mobiles (par exemple
l'authentification, l'histoire, l'itinéraire). M-UML, à son tour, et dans une moindre
mesure propose une version étendue de diagramme de classes nommé “Mobile Class
46
Diagram” pour décrire la structure interne des agents mobiles. AUML et AML
soutiennent la structure interne pour seulement les agents stationnaires tandis que
MAM-UML ne la supporte pas du tout.
 Le cycle de vie des agents mobiles est pris en charge dans MAM-UML, MA-UML, et
M-UML. En fait, MAM-UML propose une vue complète “Life-cycle View” pour
spécifier le cycle de vie de l'agent mobile. La vue est décrite par l'utilisation de
diagrammes d'Interaction, d’Etat/Transition et d’Activité. MA-UML et M-UML
étendent les diagrammes d’Etat/Transition avec de nouveaux stéréotypes et des
valeurs étiquetées pour décrire tous les états atteints par l'agent mobile pendant sa
durée de vie. La fonctionnalité est omise dans AUML et AML.
 Le critère de besoins d’exécution est entièrement pris en charge par MAM-UML et
partiellement soutenu par MA-UML. En fait, MAM-UML fournit une vue complète
“Organizational View” pour décrire les besoins d'exécution des agents mobiles à
l'aide de diagramme de Classes et d’Objets. MA-UML prend en compte cette
caractéristique dans son diagramme “Mobile Agent Diagram". La fonctionnalité est
omise dans les langages AUML, AML et M-UML.
 L’environnement d’exécution des agents mobiles est supporté par AUML en utilisant
un diagramme étendu du diagramme de Déploiement. M-UML supporte également
cette caractéristique en utilisant des versions étendues des diagrammes de Composants
et de Déploiement. MA-UML fournit un diagramme complet “Environment diagram”
afin de concevoir l'environnement d'exécution, cependant, il ne représente que la
structure statique de l’application et il n'existe aucune mention sur le déploiement
d'agents. MAM-UML propose dans sa vue “ Mobility View ” d’utiliser les
diagrammes de Déploiement et de Composant pour concevoir l'environnement
d'exécution. L'environnement d'exécution est vraisemblablement non supporté par
AML.
 La mobilité des agents a été abordée dans tous les langages proposés ci-dessous avec
des degrés de profondeur différents. En fait, deux extensions de diagrammes
d’Activité et de Déploiement ont été définies par AUML afin de permettre la
modélisation de la mobilité des agents. MAM-UML fournit une vue complète
“Mobility View” pour supporter entièrement la fonctionnalité de mobilité. M-UML
fournit un support complet de la mobilité; il définit plusieurs notations pour modéliser
tous les aspects de la mobilité en différents vues. MA-UML fournit trois diagrammes
pour modéliser la mobilité; le “Itinerary diagram” pour décrire les tâches de l’agent et
47
les places où il s’exécute, le “Navigation Diagram” qui est une utilisation variante du
diagramme d'Etat/Transition pour décrire la planification de voyage de l'agent mobile,
et le “lifecycle diagram” qui est utilisé pour spécifier les différents états de l'agent
mobile dans différentes places. AML supporte partiellement la fonctionnalité de
mobilité. En effet, c’est dans la phase de déploiement où AML propose des notations
et des éléments afin de prendre en compte la mobilité, mais cela ne suffit pas, car il n'y
a pas de détails sur la modélisation de cette fonctionnalité importante.
 la fonctionnalité d'interaction pour les agents mobiles est supportée dans MAM-UML,
M-UML et MA-UML. MAM-UML fournit une vue complète “Interaction View”
pour modéliser cette caractéristique; la vue contient des collaborations et des
diagrammes d'interaction. M-UML fournit deux extensions de diagrammes de
Séquence et de Collaboration pour modéliser les interactions mobiles. MA-UML
fournit un diagramme complet “Mobile Agent Sequence Diagram” pour modéliser les
interactions entre les différents agents mobiles. AUML et AML ne supportent pas les
interactions mobiles, mais soutiennent les autres types d’interactions entre les agents.
 La sécurité est partiellement supportée par MA-UML en ajoutant certaines propriétés
(authentification, autorisation d'utilisateur, droits d'accès, et clés d'authentification)
dans son diagramme “Mobile Agent Diagram”, afin de spécifier cette fonctionnalité.
Les autres approches ne la soutiennent pas du tout.
 En ce qui concerne les critères généraux qui caractérisent un bon langage, il y a
beaucoup de tentatives pour développer des fondements théoriques surtout pour
AUML et M-UML. Cela est dû à l'importance accordée à établir la vérification et de
raisonnement sur les modèles de ces langages.
 Les différents langages sont simples à utiliser, sauf pour MAM-UML que nous
n’avons pas pu déterminer sa clarté en raison de l'absence de leur expérimentation.
 Aucun langage d’entre eux n’est associé à un processus.
 AUML, AML et MA-UML sont supportés par des outils CASE qui facilitent le
développement de leurs diagrammes. M-UML est vraisemblablement non supporté
(même s’il y a des tentatives sur leur diagramme d'Etat/Transition), tandis que MAM-
UML est sans aucun outil CASE.
En bref, voici le résumé de cette évaluation:

 On peut juger que M-UML est le langage le plus simple et le plus adapté pour les
systèmes logiciels à base d'agents mobiles qui supporte largement la modélisation de
48
nouvelles fonctionnalités (en particulier la mobilité) du paradigme et les lignes de

discussion dessus motivent notre opinion, nous pensons qu'une extension de M-UML
qui prend en compte les préoccupations ci-dessus pourrait présenter un outil de
modélisation complet et suffisant.
 MA-UML est également intéressant pour ces systèmes, mais le manque d’un
mécanisme de modélisation de l'architecture d’environnement d'exécution va entraver
son utilisation pratique. En outre, il y a une redondance dans la représentation de
l'information. En fait, MA-UML propose deux diagrammes “Itinerary Diagram” et
“Navigation diagram” pour décrire la même information qui est le plan de voyage de
l'agent. Aussi, l'utilisation combinée de diagrammes “Navigation diagram” et
“Lifecycle diagram” rendre la définition d'un autre diagramme “MA Activity
diagram” redondant.
 Nous nous convenons que le MAM-UML est très bien organisé par ses différents vues.
Mais en plus de ce que nous avons cité plus haut, ce profil n'a pas été expérimenté
suffisamment et il ne fournit pas des exemples illustratifs, ce qui empêche son
utilisation par les utilisateurs.
 AUML et AML ne sont pas appropriés pour modéliser des systèmes logiciels à base
d'agents mobiles. Il est clair que les deux langages sont développés au début pour
modéliser les systèmes multi-agents, et après ils ont essayé d'ajouter quelques
fonctionnalités pour modéliser les systèmes logiciels à base d'agents mobiles, ce qui
donne des langages non vraiment adaptés à ces derniers systèmes.
3.5. Conclusion
Dans ce chapitre, nous avons présenté un cadre comparatif pour les approches de
modélisation de systèmes logiciels à base d'agents mobiles qui permet d’améliorer la
compréhension des travaux antérieurs sur ce sujet. D’abord, nous avons présenté et identifié
les défis et les lacunes qui doivent être surmontés pour modéliser les applications basés agents
mobiles. Après, nous avons proposé de classer les approches dans trois grandes catégories
selon certains facteurs: les approches basées sur UML, les approches formelles et les
approches hybrides. On peut dire que la combinaison des approches visuelles, dites informels
(qui attirent l’attention de l'ingénieur), et les approches formelles (qui sont analysables)
représente un axe prometteur dans l’avenir proche.
49
Enfin, quelques remarques doivent être tirées de notre analyse et évaluation du

paradigme des agents mobiles et ses approches de modélisation:
 Les agents mobiles ont généré une excitation considérable dans la communauté de
recherche; mais ils ne sont pas traduits dans un nombre important d'applications
pratiques du monde réel.
 Il y a certainement encore d’autres approches pour la modélisation des systèmes
logiciels à base d'agents mobiles et il est impossible de les évoquer toutes ici.
 Les approches proposées ne sont pas complètes en eux-mêmes, et leurs auteurs, afin de
démontrer l'applicabilité des approches, présentent des exemples illustratifs faciles qui
ne sont pas assez complexe pour détecter les faiblesses des approches. Donc, il est
nécessaire de remettre en question toutes ces langages de modélisation contre des
applications du monde réel pour vérifier leurs exhaustivités.
 La combinaison et l'intégration d'outils de modélisation visuelle et méthodes formelles
fournissent des langages puissants pour spécifier et vérifier ces systèmes, tenant en
compte l'absence de la sémantique dans les modèles visuels d’une part et les notations
graphiques pour les modèles formels de l’autre part.
 Il y a un besoin urgent de définir un méta-modèle générique avec ses notations
associées pour élaborer une extension de référence unique qui intègre toutes les
fonctionnalités des approches proposées.
 En fait, la majorité des concepteurs n'ont pas suffisamment de maturité pour modéliser
la mobilité (et ses conséquences telles que la sécurité) et de supporter l'ensemble du
cycle de vie du paradigme des agents mobiles.
 Plus des chercheurs développent des outils puissants pour la modélisation des
systèmes à base d'agents mobiles, plus nous pouvons contrôler les problèmes difficiles
non résolus de ce paradigme comme la sécurité qui est une préoccupation essentielle
pour tels systèmes.
 À travers les différentes caractéristiques des agents mobiles que nous avons présentés,
nous pouvons dire que les agents mobiles ne représentent pas le paradigme idéale pour
tous les types d'applications distribuées, mais tout simplement une nouvelle possibilité
avec beaucoup d’avantages pour certains domaines et moins utiles pour d’autres.
Plus important encore, nous croyons que l'étude ci-dessus fournit un cadre clair, et bien
défini pour évaluer les différents problèmes associés aux approches de modélisation de
systèmes logiciels à base d'agents mobiles. Ce cadre comparatif n’est certainement pas
50
idéale, mais il est délibérément conçu d’être suffisant pour y servir de base viable pour des
futures améliorations et extensions.
51
Chapitre 4
Approche proposée
4.1 Introduction
4.2 Les diagrammes états-transitions mobiles
4.3 L'approche proposée
4.5 Discussion et leçons apprises
4.6 Conclusion
Approche proposée Chapitre 4
4.1. Introduction
Nous avons conclu l’évaluation dans le chapitre précédent par l’affirmation que la
solution, pour obtenir une approche puissante, est de développer une approche semi-formelle /
formelle qui devra permettre la modélisation et la vérification de tels systèmes.
Ainsi, nous introduisons dans ce chapitre les MSDs (Mobile statechart diagrams) qui
sont des extensions des diagrammes d’états-transitions M-UML. Ensuite, une approche
intégrée diagrammes MSDs / expressions π-calcul sera développée pour la modélisation et la
vérification des systèmes logiciels à base d'agents mobiles par la transformation des premiers
vers les derniers. La spécification π-calcul générée sera considérée comme une sémantique
formelle, qui sera utilisée par la suite pour l'analyse, telles que la détection précoce des erreurs
(deadlocks, livelocks, etc ...), vérifier si certaines propriétés sont satisfaites, et (ou) vérifier
l'équivalence entre les différents diagrammes, en utilisant des outils d'analyse π-calcul.
4.2. Les diagrammes d’états-transitions mobiles

Nous avons proposé les diagrammes d’états-transitions mobiles (MSDs, Mobile
Statechart Diagrams) comme extension des diagrammes d’états-transitions M-UML [15]. Ces
derniers ont été introduits pour modéliser le comportement des agents mobiles en exposant
leurs différents états. Ils peuvent être utilisés avec élégance pour représenter le comportement
des agents stationnaires et mobiles. Nous présentons ci-dessous (cf. TAB. 4.1) les éléments
structurels des MSDs, et nous nous concentrons sur les nouveaux éléments introduits pour
faire face à la mobilité dans ces diagrammes.
Une place est un nœud logique sur lequel les agents d'une application peuvent être
exécutés (un ou plusieurs états), elle est désignée implécitement. Le pseudo-état initial
représente le point de début d'exécution de l'agent. A un moment donné, l'agent peut se
trouver dans un état distinct sur une place particulière. Un état normal représente un état de
l'agent dans sa place de base. Un état mobile est représenté avec une boîte (M); c’est un état
accessible par l'agent hors de sa place de base. Une transition est une liaison unidirectionnelle
qui parte d'un état (l'état source) vers un autre état (l'état cible), elle peut porter une étiquette
selon la syntaxe Evènement [Condition] / Action, qui signifie si un événement produit, une
action sera exécutée si la condition est évaluée à vraie. Une transition est simple si les deux
états à ses deux extrémités sont situés dans la même place. Une transition mobile est
représenté avec une boîte (M); c’est une transition entre deux états accessibles par l'agent et
situés dans deux places différents; elle a plusieurs formes comme illustré dans (cf. TAB. 4.1).
53
L’état actuel atteint par un agent, soit à sa place de base ou à l'extérieur est représenté par une
boîte pointillée (M). Une transition à distance porte une boîte (R); elle se produit si un agent
mobile atteint un état tout en interagissant avec un autre agent à distance. Une transition avec
un stéréotype << agentreturn >> représente le retour de l'agent mobile à sa place d’origine en
atteignant un état sur elle. Si l'agent termine son exécution, il atteindra le pseudo-état final.
Les MSDs proposés étendent les diagrammes d’états-transitions M-UML [15] par:
─ La notion de place est implécitement introduite; elle est représentée par une valeur
étiquetée « place » dans la classe état.
─ Ajout des pseudo-états initiaux et finaux.
─ Ajout d'état composite non-concurrent normal, état composite non-concurrente mobile,
pseudo-état fork, pseudo-état join, état composite concurrent normal, état composite
concurrent mobile, les actions entry et exit d'un état.
─ Nous avons proposé également une extension à la sémantique M-UML pour faire
communiquer les diagrammes d'états-transitions mobiles, cela inclut la communication
unicast asynchrone locale, la communication multicast asynchrone locale, la communication
diffusion asynchrone locale, la communication unicast synchrone locale, la communication
multicast synchrone locale, la communication diffusion synchrone locale, la communication
réponse synchrone locale, la communication unicast asynchrone à distance, la communication
multicast asynchrone à distance, la communication diffusion asynchrone à distance, la
communication unicast synchrone à distance, la communication multicast synchrone à
distance, la communication synchrone diffusion à distance, la communication réponse
synchrone à distance.
54
Pseudo-States
Initial Pseudo-state Final Pseudo-state
Fork Pseudo-state Join Pseudo-state
States Placesp M M
Normal State Mobile State

Reached State
M
S2 S2
G1 G2 Gn G1 G2 Gn
Non concurrent Mobile Non-concurrent

Composite
States
M
S2 S2
G1 G2 Gn G1 G2 Gn
H1 H1 Hn H1 H1 Hn
Concurrent Mobile Concurrent
M M
M M
Mobile Transition Mobile Transition
M M M M
M
Transitions
Mobile Transition Normal Transition
M M M
<<agentreturn>> R
<<agentreturn>> Transition Remote Transition

Event [Condition] / Action
The complete label of a transition
Event [Condition] / Send Ag 1.Action Event [Condition] / RSend Ag 1.Action

Asynchronous unicast Asynchronous remote unicast
Event [Condition] / Send {Ag 1, ..., Agn}.Action Event [Condition] / RSend {Ag 1, ..., Agn}.Action
Asynchronous multicast Asynchronous remote multicast
Event [Condition] / Send Action Event [Condition] / RSend Action

Asynchronous broadcast Asynchronous remote broadcast
Event [Condition] / Call Ag1.Action Event [Condition] / RCall Ag 1.Action

Communication Synchronous unicast Synchronous remote unicast
Event [Condition] / Call {Ag 1, ..., Agn}.Action Event [Condition] / RCall {Ag1, ..., Agn}.Action
Synchronous multicast Synchronous remote multicast
Event [Condition] / Call Action Event [Condition] / RCall Action

Synchronous broadcast Synchronous remote broadcast
Event [Condition] / Reply Action Event [Condition] / RReply Action

Synchronous Reply Synchronous remote Reply
TAB. 4.1 - Les éléments structurels des MSDs.
55
4.3. L'approche proposée
Le comportement d'un système logiciel basé agents mobiles MASS est donné dans
notre approche par le comportement d'un réseau de k agents A1 ... Ak qui communiquent entre
eux. Ces derniers sont spécifiés par une collection de diagrammes d'états-transitions mobiles
MSD1, MSD2, ..., MSDK, un pour chaque agent.
Dans la section suivante, inspirée de [67], [68] et [69], nous définissons une syntaxe
abstraite textuelle au système logiciel basé agents mobiles, qui est composé de plusieurs
diagrammes d'états-transitions mobiles. Cette syntaxe est considérée comme une définition
formelle qui nous permet par la suite de définir formellement la translation vers le π-calcul.
4.3.1. Définition formelle

Le comportement d’un MASS est donné par le comportement de plusieurs MSDs qui
partagent des places. Nous décrivons un diagramme d'états-transitions mobile MSD en
utilisant plusieurs ensembles d'éléments qui ont les mêmes caractéristiques. Ensuite, nous
définissons plusieurs fonctions pour relier ces ensembles les uns des autres.
─ Définition 1: (définition de MASS)

Un système logiciel basé agents mobiles est un n-tuple MASS = (MASSname, P, MSD1, ....,
MSDk) où:
- MASSname: le nom du système.
- P : est l'ensemble de toutes les places qui peuvent exister dans un système.
- MSD1, ...., MSDk: sont les k statecharts mobiles communicants.
─ Définition 2: (définition de MSD)
Un diagramme d'états-transitions mobile MSD est défini par le 15-tuple suivant:

MSD = (MSDname, P, D, S, R, T, δS, δCmp, δReg, δK, δsrc, δtrg, δE, δC, δA)
Tel que:
- MSDname est le nom du diagramme d'états-transitions mobile
- P = {P1, P2, ...} est l’ensemble des places (plateformes) visitées.
- D = {I1, ...., F1....} est l’ensemble des pseudo-états.
- S = NS U MS U RS est l’ensemble des états tel que:
NS est l’ensemble des états normaux
MS est l’ensemble des états mobiles
RS est l’état actuel visité
56
- R = {R1, R2, ...} est l’ensemble des régions.

- T = KxSxExCxAxS est l’ensemble de toutes les transitions.
- K = {NT, MT, RT, AT} est l’ensemble des types de transitions tel que:
NT représente les transitions normales
MT représente les transitions mobiles
RT représente les transitions à distance
AT représente les transitions agentreturn
- E = {E1, E2, ...} est l’ensemble de tous les évènements.
- C = {C1, C2, ...} est l’ensemble de toutes les conditions.
- A = {A1, A2, ...} est l’ensemble de toutes les actions.
S
- δS: P 2 retourne les états exécutants sur une place.
- δCmp: S 2R retourne les régions d’un état composé.
- δReg : R 2S retourne les sous-états d’une région.
- δK : T K retourne le type de la transition.
- δsrc : T S D retourne la source de la transition.
- δtrg : T S D retourne la cible de la transition.
- δE : T E retourne l’évènement de la transition.
- δC : T C retourne la condition (s) de la transition.
- δA : T A retourne l’action (s) de la transition.
─ Definition 3: (fonction de transformation)

Soit MSDs est l'ensemble de tous les diagrammes d'états-transitions mobiles, PE est
l'ensemble de toutes les expressions de processus π-calcul. Nous définissons une fonction Ψ
pour représenter chaque diagramme d'états-transitions mobile par des expressions de
processus π-calcul comme suit:
Ψ : MSDs PE
Le but de la fonction est de donner la sémantique au MSDs en utilisant π-calcul, c.à.d.
pour chaque diagramme d'états-transitions mobile MSD  MSDs, Ψ (MSD)  PE.
─ Définition 4: (fonctions d'expression de processus)

Soit MSD  MSDs un diagramme d’états-transitions mobile, ELMMSD  MSD un ensemble
d’éléments de MSD, PI  PE est l’ensemble des identificateurs de processus π-calcul, et
N  PE est l’ensemble des noms π-calcul, Nous définissons les fonctions injectives
suivantes :
57
ΨN: ELMMSD N si ELMMSD  {E, C, A}

ΨPI: ELMMSD PI si ELMMSD  {P, S, D}
Cette fonction transforme chaque élément du diagramme d'état-transitions mobile
MSD vers un identificateur de processus π-calcul ou vers un nom (canal).
─ Definition 5: (distinction de places)

Nous définissons une fonction surjective δP qui identifie la place de n’importe quel état dans
le diagramme:
δP : S P
La fonction est l’inverse de la fonction δS, Elle localise pour chaque état sa place
d'exécution tel que:
 s  S,  ! p  P, telque δP (s) = p
Ou
 p  P, | δP-1({p}) |  1
Ce qui signifie que chaque place possède au moins un état.
─ Definition 6: (Classes d’équivalences)

Nous définissons une relation d'équivalence Q sur l'ensemble des états S comme suit:
Q = {<S1, S2> | S1, S2  S et δP (S1) = δP (S2)}

Cette relation d'équivalence définit une partition de l'ensemble S; nous définissons une
classe d'équivalence de s  S par :
[s]Q = {x  S | (s , x)  Q}
Ainsi, l'ensemble quotient (l’ensemble des classes d'équivalence) constitue une
partition de l'ensemble des états S où chaque partie regroupe les états qui se trouvent sur la
même place. Il est donné par:
S/Q = {[s]Q | s  S}
Cet ensemble quotient S/Q est correspondant à l'ensemble des places P du diagramme
d'états-transitions mobile :
S/Q  P
4.3.2. Formalisation des MSDs
Le comportement d'un système logiciel à base d'agents mobiles est donné par un
ensemble de diagrammes d'états-transitions mobiles communicants MSD1... MSDk. L'idée de
base dans notre formalisation est de donner à cet ensemble un système π-calcul
58
correspondant. Ce dernier consiste en un réseau de processus interagissant (cf. Fig.4.1). Il y a

une reconfiguration du système π-calcul à chaque fois un agent passe d'un état à un autre. En
outre, une reconfiguration profonde est apparue quand un agent se déplace d'une place à une
autre. Cela permet de capturer la fonction de mobilité qui est l'objectif de ce travail.
Un système π-calcul MSD1 (correspondant à un diagramme d’états-transitions mobile

dans l'ensemble) contient deux parties essentielles, le processus A1 (correspond à l'agent,
appelé processus agent) et les processus P1... Pn (correspondent aux différentes places, chacun
d’eux est appelé processus place). Le processus A1 consiste en trois parties essentielles; le
processus A1S1 qui modélise les états de l'agent (appelé le processus état), le processus A1PL0
qui représente le pool local de l'agent (appelé le processus pool local) et le processus A1RPL0
qui représente le pool à distance de l'agent (appelé le processus pool à distance).
Afin de permettre l'exécution valide du système π-calcul dérivé, plusieurs noms

(canaux) sont utilisés. “a1” est un canal local utilisé pour les communications privées
(données, ...etc) entre le processus état et le processus place. “m1” est un canal local entre le
processus place et le processus état utilisé pour envoyer et recevoir des demandes de
migration (du premier au dernier). “p1,..., pn” représentent les noms physiques des places; ce
sont des ports publics utilisés par les processus places pour la communication entre eux,
chaque place Pi a son propre port “pi”. “l1,..., ln” sont des constants utilisés pour représenter
les noms logiques des places, chaque “li” représente une place Pi. Nous supposons que les
agents sont conscients des localités des autres agents par le biais des noms logiques de leurs
places, mais pas des noms physiques de ces places.
A1
MSD1
evext1 A1PL0
A2
remote1 rtc1 evint1
A1RPL0
A1S1
a1
m1
MASS
p1 p2
P2 MSD2
P1
FIG. 4.1 – Un aperçu du système à un moment donné; une vue de processus π-calcul
59
4.3.2.1. Pseudo-états Initial et Final
─ Règle 1: (Pseudo-état initial)

Soit I1  D, S1  S, δtrg(I1) = S1, “start” est un canal qui représente l'événement de
démarrage d'exécution, et ΨPI(I1) = I1(start). La sémantique d’un pseudo-état initial est
donnée par le comportement du processus I1(start) comme suit:
def
I1(start)  start.S1
Un état pseudo-initial est relié à son état successeur par une transition d'achèvement
qui peut contenir des conditions et des actions explicites. Le processus I1(start) attend de
recevoir un événement (un signal) de démarrage d'exécution modélisé comme une action
d'entrée “start” avant de se comporter comme le processus correspondant au premier état S1.
S'il y a des conditions et des actions, ils seront traités comme dans les règles des états.
─ Règle 2: (Pseudo-état final)

Soit F1  D, ΨPI(F1) = F1(end). “end” est un canal qui représente l'événement de fin
d’exécution, et ΨPI(F1) = F1(end). La sémantique d'un pseudo-état final est donnée par le
comportement du processus F1(end) comme suite:
def
F1(end)  end.F1(end)
Un pseudo-état final est connecté à son état précédent par une transition d'achèvement
qui peut contenir des conditions et des actions explicites. Lorsque le processus F1(end) est
créé (c.-à-d. le processus correspondant à l'état prédécesseur se comporte comme ce
processus), il fait immédiatement une action de sortie “end” pour indiquer que l'exécution est
terminé. Un pseudo-état final n'a pas de successeur, il se comporte comme lui-même.
4.3.2.2. Places
Un processus place peut avoir trois comportements. Communiquer avec un processus

état, attendre de recevoir une intention de migration de celui-ci (si l'agent est à cette place), ou
attendre de recevoir une demande d'accueil si un agent veut visiter la place en question.
─ Règle 3: (place)
Soit P1  P, ΨPI(P1) = P1k(l1,..., ln, p1,..., pn, ....). Selon la situation actuelle de la place
(nombre k d'agents sur elle), son comportement est donné par les processus interconnectés
P1k(l1,..., ln, p1,..., pn, ....) comme suit:
60
def
P10(l1,..., ln, p1,..., pn)  p1(z1, m1).P11(l1,..., ln, p1,..., pn, z1, m1)
def
P11(l1,..., ln, p1,..., pn, z1, m1)  z1. P11(l1,..., ln, p1,..., pn, z1, m1) +
p1(z2, m2). P12(l1,..., ln, p1,..., pn, z1, m1, z2, m2) +
n
m1(y).(  [y = li] pi <z1, m1>.P10(l1,..., ln, p1,..., pn) )
i2
def
P1k(l1,..., ln, p1,..., pn, z1, m1,… , zk, mk) 
k

i 1
zi.P1k(l1,..., ln, p1,..., pn, z1, m1,… , zk, mk) +
p1(zk+1, m k+1).P1k+1(l1,..., ln, p1,..., pn, z1, m1,… , zk, mk, zk+1, mk+1) +
k
(  mj(y).(  [y = li] pi<zj, mj>.P1k-1(l1,..., ln,p1,..., pn, z1, m1,… , zj-1, mj-1, zj+1, mj+1,…,zk-1,
j 1 i j
mk-1) ))
Le comportement d'une place P1 est représenté par plusieurs processus interconnectés,
selon les agents existants sur la place. La première situation est que la place a zéro agent
s’exécute sur elle (c.-à-d. elle n’a qu’attendre de recevoir un agent par une migration); elle est
représentée par le processus P10(l1,..., ln, p1,..., pn). Ce dernier attend de recevoir un canal de
communication privé “a1” et un canal de migration local “m1” (qui sont appartenus à un
processus agent) via son port par l'action d'entrée “p1(z1, m1)”, puis il se comporte comme un
autre processus P11(l1,..., ln, p1,..., pn, z1, m1). Ce dernier représente la deuxième situation, c.-
à-d. quand un agent est sur la place. Dans ce cas, le processus place peut communiquer de
manière récursive avec le processus état (de l'agent) par l'action de sortie “z1”, attend de
recevoir une autre migration vers elle par l'action d'entrée “p1(z2, m2)” et se comporte comme
un nouveau processus P12(l1,..., ln, p1,..., pn, z1, m1, z2, m2) représentant la situation suivante,
ou attend la réception d'une demande de migration de son agent actuel. Le dernier est
représenté par une entrée sur le canal de migration “m1(y)”, P11 cherche alors la place voulue
(de l'agent) en utilisant la construction de correspondance “[y = li]”, puis il utilise le port
adéquat pour envoyer au processus place correspondant le canal de communication privé et le
canal de migration local en utilisant l'action de sortie “pi <z1, m1>”, il se comporte alors
comme P10(l1,..., ln, p1,..., pn), le processus représentant la situation précédente. La situation
quand k agents sont sur la place est représentée par le processus P1k(l1,..., ln, p1,..., pn, z1,
m1,… , zk, mk), il est une généralisation de ce que nous avons déjà expliqué.
61
Le mécanisme d'extrusion de la portée est utilisé ici pour passer le canal “z1” privé et
le canal “m1” de migration local d'un processus place à un autre processus place. Ces canaux
ne sont plus liés au processus place actuel (c.-à-d. ils seront libres), ils seront liés au processus
place cible lors de leur réception. Une communication est ensuite se produit entre le nouveau
processus place et le nouveau processus état en utilisant ces ports. Cette reconfiguration du
système est déclenchée par le fait que l'agent se déplace d'une place à une autre.
─ Règle 4: (configuration des places)

Soit P1,..., Pn  P, ΨPI(P1) = P1k1(l1,..., ln, p1,..., pn, ....), ... , ΨPI(Pn) = Pnkn(l1,..., ln, p1,..., pn,
....). Selon la situation actuelle de chaque place (k1, ..., kn nombre d'agents sur les places P1,
..., Pn respectivement, où k = k1 + ... + kn), le comportement d'une configuration des places
est donnée par le processus Pc(l1,..., ln, a1, m1, .... ak, mk) comme suit:
def
Pc(l1,..., ln, a1, m1, .... ak, mk)  (ν p1, ..., pn) (P1k1(l1,..., ln, p1,..., pn, ....) | ... |
P1kn(l1,..., ln, p1,..., pn, ....))
La configuration des places est représentée par la composition parallèle de plusieurs

processus places qui ont des situations différentes (selon le nombre d'agents sur chaque
place). La restriction (ν p1, ... , pn) rend ces canaux privés aux processus places.
4.3.2.3. Les états
Nous codons les états comme des définitions de processus, et un processus évoluera à
un autre à chaque fois l'agent atteint un nouvel état dans le diagramme.
─ Règle 5: (Etat)
Soit P1  P, S1  NS, δP(S1) = P1, et ΨPI(S1) = S1(a1). Nous modélisons la sémantique d'un
état simple d'un diagramme d'états-transitions mobile par le comportement du processus
S1(a1) comme suit:
def
S1(a1)  a1.S1(a1)
Le processus état communique avec le processus place (voir la règle 3) en recevant un

canal en utilisant l'action d’entrée “a 1”. En réalité, cela permet de spécifier la communication
entre l'agent et la place. Le processus place envoie et le processus état reçoit d'une manière
récursive.
62
Si S1 = RS, qui signifie que l’agent est dans l’état S1, alors le processus état
correspondant est celui qui va être présent dans la composition du processus agent (on
commence l’exécution à partir de ce processus qui va évoluer vers les autres).
4.3.2.4. Transition
La transformation des transitions est liée à leurs états d'origine. En fait, une transition
est modélisée par un changement de comportement dans le processus état source qui évolue
vers le processus état cible à la suite d'une interprétation de l'étiquette de transition selon la
syntaxe décrit dans le tableau 4.1.
Nous commençons par la transformation des transitions d'achèvement (c.à.d. la

transition sans événement déclencheur explicite), nous les considérons aussi sans conditions
ni actions, et on va les traiter progressivement.
─ Règle 6: (transition simple)

Soit P1  P, S1, S2  S, T1  T, δP(S1) = P1, δP(S2) = P1, δSrc(T1) = S1, δTrg(T1) = S2,
δK(T1) = NT, δE(T1) = ε, δC(T1) = ε, δA(T1) = ε, et ΨPI(S1) = S1(a1). La sémantique d'une
transition simple d'un état S1 à un autre état S2 est donnée par le comportement du processus
S1(a1) comme suit:
def
S1(a1)  a1.S1(a1) + τ.S2(a1)
Le processus état S1 communique avec le processus place par l'action d'entrée “a 1”

jusqu'à ce que quelque chose se produit modélisé comme une action silencieux “τ”, il se
comporte alors comme un autre processus S2 correspondant à l'état cible. Cela permet de
spécifier une transition simple de l'agent d'un état à un autre sur la même place.
─ Règle 7: (transition mobile)
Soit P1, P2  P, S1  S, S2  MS, T1  T, δP(S1) = P1, δP(S2) = P2, δSrc(T1) = S1, δTrg(T1)
= S2, δK(T1) = MT, δE(T1) = ε, δC(T1) = ε, δA(T1) = ε, et ΨPI(S1) = S1(a1, m1, t1,..., tn). Nous
modélisons la sémantique d'une transition mobile d'un état S1 à un autre état S2 dans le
comportement du processus paramétré S1(a1, m1, t1,..., tn) comme suit:
def
S1(a1, m1, l1,..., ln)  a1.S1(a1, m1, l1,..., ln) +
τ.m1<l2>.S2(a1, m1, t1,..., tn)
Le processus état est en contact avec le processus place comme dans les règles
précédentes. Quand il y a une migration à partir d'un état S1 sur une place P1 à un autre état
63
S2 sur une autre place P2, le processus état S1 demande la migration en envoyant le canal qui
représente la nouvelle place prévu (ici c’est l2) via le canal de migration en utilisant l’action
de sortie “m1<l2>”, puis il évolue vers un autre processus S2 correspondant au nouvel état. Le
processus place en question reçoit la demande et fait le reste (voir Règle 3).
Tous les types de transitions mobiles seront modélisés dans notre proposition de la
même manière, parce que nous sommes préoccupés ici par le fait que l'agent s’exécutera dans
une autre place différente de sa place actuelle.
─ Règle 8: (transition <<agentreturn>>)

Une transition <<agentreturn>> est similaire à une transition mobile. Elle ne diffère que par le
fait que l'agent mobile effectue un retour à sa place d'origine (de base), c.à.d. la place à partir
du quelle il est envoyé pour la première fois. Nous décrivons ça en demandant la première
place dans le diagramme, c.à.d. en utilisant le canal “l1”.
─ Règle 9: (transition à distance)

Une transition à distance se produite quand il y a une communication à distance, elle est
transformée comme dans les règles précédentes et la seule différence est dans l'action qui doit
être exécutée à distance (on le verra en Sect. 4.3.2.7)
4.3.2.5. Traitements des évènements

Nous expliquons ici le mécanisme de traitement des évènements dans les diagrammes
d'états-transitions mobiles. Un événement est quelque chose qui se produit dans un système et
qui déclenche un changement potentiel. Un MSD possède un pool local utilisé pour recevoir
des événements locaux et un pool à distance utilisé pour recevoir des événements à distance.
Nous supposons que les MSDs interagissent en envoyant les uns les autres des événements à
leurs pools qui ont des identifiants uniques (adresses). Les pools sont gérés par une stratégie
FIFO (First In First Out). Le pool local est représenté par un processus paramétré PL qui
inclut le mécanisme dispatcheur. Il envoie les événements un par un jusqu'à ce qu'aucun
événement n’est dans la file d'attente. La sémantique RTC (Run To Completion), qui signifie
qu’aucun évènement ne sera envoyé avant que le précédent est complètement exécuté, est
respectée. Le pool local reçoit des événements externes à l'aide d'un canal global “evext1” et
communique les événements reçus avec le processus état en utilisant un canal local privé
appelée “evint1”. Le pool à distance est représenté par un processus paramétré RPL. Il utilise
un canal global “remote1” pour recevoir des événements à distance, et les transfère au pool
local sur son canal externe “evext1”.
64
En ce qui concerne les événements attendus dans un diagramme d'états transitions

mobile, soit T1, T2, ..., Tn  T, δE(T1) = E1, δE(T2) = E2, ..., δE(Tn) = En, ΨN(E1) = e1,
ΨN(E2) = e2, …, ΨN(En) = en. Les événements attendus sont représentés dans les processus

par une série ordonnée de canaux e (c.à.d. e1, e2 ,...., en). evext1,... evextn représentent les
canaux publiques utilisés par les pools locaux des diagrammes pour recevoir des événements
locaux. remote1,..., remoten représentent les canaux publiques utilisés par les pools à distance
des diagrammes pour recevoir des événements à distance. evexti est le port du processus AiPL.
remotei est le port du processus AiRPL. evint1 représente un canal privé partagé par le
processus pool et le processus état pour communiquer les événements reçus. rtc1 est un canal
privé partagé par le processus pool et le processus état utilisé pour représenter l'étape run-to-
completion.
─ Règle 10: (agent)

Soit S1  S and S1=RS, La sémantique du processus correspondant à l'agent dans le
diagramme d'états-transitions mobile est donnée par le processus:
def
A1(a1, m1, evext1,...evextn, remote1,...remoten) 

(ν evint1, rtc1)(S1(a1, evint1, rtc1, e ) | PL(evint1, evext1, rtc1)) | RPL(remote1, evext1)
Le processus agent est construit par la composition parallèle de trois processus; le

processus état S1, le processus pool PL et le processus pool à distance RPL.
─ Règle 11: (transition avec évènement)

Soit P1, P2  P, S1, S2  S, T1  T, δP(S1) = P1, δP(S2) = P1, δSrc(T1) = S1, δTrg(T1) = S2,

δK(T1) = NT, δE(T1) = E1, δC(T1) = ε, δA(T1) = ε, ΨN(E1) = e1, et ΨPI(S1) = S1(a1, evint1 , e ).
Nous modélisons la sémantique d'un état avec une transition qui a un événement par le

comportement du processus paramétré S1(a1, evint1 , rtc1, e ) comme suit:
def
  
S1(a1,evint1,rtc1, e )  a1.S1(a1,evint1,rtc1, e ) + evint1(z).([z = e1] rtc1.S2(a1,evint1 ,rtc1, e ) +

i 1
[z= ei] rtc1.S1(a1,evint1,rtc1, e ))
Cette règle est similaire au (Règle 6), mais ici un déclencheur d'événement est
considéré. En fait, le processus état S1 attend de recevoir un événement en utilisant l'action
d'entrée “evint1(z)”, puis il procède à le comparer avec l'événement attendu “e1” en utilisant
une construction de correspondance “[z = e1]”. S'il existe une correspondance, le processus S1
envoie le canal “rtc1” au processus pool local (Règle 11) indiquant l'étape run-to-completion
et évolue après au processus qui modélise le prochain état S2. Sinon, s'il n'y a pas de
65
correspondance, c.a.d. “[z = ei]”, cela signifie que l'événement n’est pas un déclencheur pour
la transition; dans ce cas le processus envoie aussi le canal “rtc1” pour consommer
l'événement et se continue comme lui-même.
─ Règle 12: (le pool local des évènements)

Un pool local a une sémantique implicite dans MSD, La sémantique du pool local d'un MSD
est donnée par le processus PL0(evint1, evext1) comme suit:
def
PL0(evint1, evext1, rtc1)  evext1(x1).PL1(evint1, evext1, rtc1, x1)
def
PLn(evint1, evext1, rtc1, x1, ... , xn)  evext1(xn+1).PLn+1(evint1, evext1, rtc1, x1, ... , xn, xn+1) +
evint1< x1>.rtc1.PLn-1(evint1, evext1, rtc1, x2, ... , xn)
Le pool local de l'agent peut soit recevoir des événements d'agents externes ou
envoyer des événements à son agent correspondant. Dans le premier cas, le processus pool
local PLn reçoit un événement “xi” sur son canal publique extérieur par l'action d'entrée
“evext1(xi)”, puis il évolue à un autre processus PLn+1 qui représente la nouvelle situation
(c.a.d mettre l'événement dans le pool). Dans le second cas, il envoie un événement au
processus état sur son canal local par l'action de sortie “evint1<x1>”, et il attend de recevoir le
run-to-completion “rtc1” de cet événement envoyé (voir Règle 10). Lorsque ce canal est reçu,
le processus pool local se comporte comme PLn-1, le processus qui correspond au pool dans sa
dernière situation (c.à.d. supprimer l'événement du pool). PL0 est le processus correspondant
au pool quand il est vide, c.à.d. sans événements, et par conséquent il n'y a pas de dispatching;
seulement attente d'événements.
─ Règle 13: (le pool à distance des évènements)

Un pool à distance a une sémantique implicite dans MSD, La sémantique du pool à distance
d'un MSD est donnée par le processus RPL0(remote1) comme suit:
def
RPL0(remote1, evext1)  remote1(x1).RPL1(remote1, evext1, x1)
def
RPLn(remote1, evext1, x1, ... , xn)  remote1(xn+1).RPLn+1(remote1, evext1, x1,... , xn, xn+1) +
evext1<x1>.RPLn-1(remote1, evext1, x2,... , xn)
Le pool à distance de l'agent peut soit recevoir des événements des agents distants ou
transférer des événements reçus au pool local. Dans le premier cas, le processus pool RPLn
reçoit un événement “xi” sur son canal public à distance par l'action d'entrée “remote1(x1)”,
puis il évolue vers un autre processus RPLn+1 qui représente la nouvelle situation (c.à.d. mettre
66
l'événement dans le pool à distance). Dans le second cas, il transfère un événement au pool
local en utilisant l'action de sortie “evext1<x1>”, puis il se comporte comme RPLn-1, le
processus qui correspond au pool à distance dans sa dernière situation (supprimer un
événement du pool à distance). RPL0 est le processus correspondant au pool à distance quand
il est vide, c.à.d. sans événements à distance, et par conséquent il n'y a pas de transfère;
seulement attente d'événements distants.
4.3.2.6. Traitement des conditions
Une condition de garde est une expression logique qui doit être vraie pour effectuer la
transition. Son évaluation est déterminée en fonction de multiples facteurs (parfois l'agent en
tant que tel, tantôt en communication avec d'autres entités, ...). Ceci est lié à la condition elle-
même et pour cette raison nous adoptons un processus CE de qui est une abstraction de ces
facteurs. La communication entre le processus état et le processus CE détermine si la
condition est vérifiée.
En ce qui concerne les conditions de garde attendues d'un diagramme d'états-
transitions mobile, soit T1, T2, ..., Tn  T, δC(T1) = C1, δC(T2) = C2, ..., δE(Tn) = Cn, ΨN(C1)
= c1, ΨN(C2) = c2, …, ΨN(Cn) = cn. Toutes les conditions attendues sont représentées par une

série ordonnée de canaux c (c.à.d. c1, c2 ,...., cn ).
─ Règle 14: (transition avec condition)

Soit P1  P, S1, S2  S, T1  T, δP(S1) = P1, δP(S2) = P1, δSrc(T1) = S1, δTrg(T1) = S2,

δK(T1) = NT, δE(T1) = ε, δC(T1) = C1, δA(T1) = ε, ΨN(C1) = c1, ΨPI(S1) = S1(a1, c ). Nous
modélisons la sémantique d'un état avec une transition qui a une condition par le

comportement du processus S1(a1, c ) comme suit:
def
   
S1(a1, c )  a1.S1(a1, c ) + τ.(ν g)c1<g>.g(y).([y=true]S2(a1, c ) + [y=false]S1(a1, c ))
Une condition est représentée par un canal “c1”, qui est utilisé pour évaluer la
condition du garde. En fait, après une action interne “τ”, le processus état crée un nouvel
canal “ν g” et utilise l'action de sortie “c1<g>” et l'action d'entrée “g(y)” pour récupérer
l'évaluation actuelle de la condition en communiquant avec le processus d'évaluation de
conditions (voir Règle 15). La construction de correspondance “[y=true]” indique que la
condition est vérifiée, et par conséquent il y a un passage à l'état S2. La construction de
correspondance “[y=false]” indique que la condition n’est pas vérifiée, c.à.d. la transition ne
peut pas être effectuée et le processus continue comme lui-même.
67
─ Règle 15: (évaluation des conditions)

Soit “true” et “false” deux canaux représentent l'évaluation d'une condition (vrai ou faux), la

sémantique d'évaluation des conditions est modélisée par le processus CE(true,false, c )
comme suit:
n

def
 
CE(true,false, c )  ci(g).(g<true> + g<false>).CE(true,false, c )
i 1
Le processus reçoit une demande pour l'évaluation d'une condition par l'action d'entrée
“ci(g)”. Il utilise ensuite le canal “g” reçu pour renvoyer la valeur booléenne en émettant le
canal “true” ou “false” selon l'évaluation. Le choix parallèle utilisé dans le processus de
conditions garantira que toutes les évaluations des conditions sont effectuées en parallèle, et
celui qui est invoqué sera exécuté.
Le choix entre la garde vrai ou faux est non déterministe et les deux alternatives sont
possibles.
4.3.2.7. Traitement des actions
La documentation UML standard se concentre sur un seul diagramme d'états-

transitions au lieu de plusieurs diagrammes communicants. Elle ne spécifie pas précisément et
explicitement comment les diagrammes d'états-transitions communiquent entre eux, et ils
existent quelques travaux qui ont essayé de régler ce problème. De notre côté pour contourner
cette limitation, nous proposons l'utilisation des mécanismes suivants spécifiés dans le
standard UML [12][57]:
─ L'action d'envoi “Send” pour la communication asynchrone entre les diagrammes d'états
transitions mobiles.
─ L'action d'appel “Call” et l'action de réponse “Reply” pour la communication synchrone
entre diagrammes d'états-transitions mobiles.
En outre, nous avons proposé les mécanismes suivants pour les communications à
distance:
─ L'action d'envoi à distance “RSend” pour la communication asynchrone entre les

diagrammes d'états-transitions mobiles.
─ L'action d'appel à distance “RCall” et l'action de réponse à distance “RReply” pour la
communication synchrone entre les diagrammes d'états-transitions mobiles.
68
En ce qui concerne les actions attendues dans un diagramme d'états transitions mobile
soit T1, T2, ..., Tn  T, δA(T1) = A1, δA(T2) = A2, ..., δA(Tn) = An, ΨN(A1) = act1, ΨN(A2) =
act2, …, ΨN(An) = actn. Toutes les actions prévues sont représentés par une série ordonnée de
canaux act (c.à.d. act1, act2 ,...., actn).
─ Règle 16: (transition avec action)
Soit P1  P, S1, S2  S, T1  T, δP(S1) = P1, δP(S2) = P1, δSrc(T1) = S1, δTrg(T1) = S2, δK(T1)
= NT, δE(T1) = ε, δC(T1) = ε, δA(T1) = A1, done1 est un canal utilisé pour recevoir la
notification sur l’exécution de l'action avec succès. ΨN(A1) = act1, and ΨS(S1) = S1(a1, act ).
Nous modélisons la sémantique d'un état avec une transition qui a une action par le
comportement du processus S1(a1, act ) comme suit:
def
S1(a1, act )  a1.S1(a1, act ) + τ.(ν done1)(AHact1 | done1.S2(a1, act ))
Traiter une action dans une transition simple ou mobile est représenté par le
comportement du sous-processus AHact1. Après une action interne “τ”, le processus S1 se
comporte comme deux processus parallèles. D'une part, comme le processus AHact1 qui
représente l'exécution de l'action; son comportement sera détaillé ci-après. De l’autre part,
comme un processus qui attend de recevoir le canal “done1” (ce qui signifie que l'action est
exécutée avec succès), il va ensuite immédiatement évoluer au processus S2 qui correspond à
l'état suivant sur le diagramme.
En ce qui concerne les transitions à distance, la même transformation est adoptée, la
différence est dans le comportement du processus AHact1, où une communication à distance
est effectuée (c.à.d. l'agent actuel interagit à distance avec d'autres agents pour atteindre un
état).
- Pas de communication avec les autres MSDs.

def
AHact1(act1, done1)  act1.done1.0
Si aucune communication avec d'autres agents n’est nécessaire, le processus

AHact1(act1, done1) fait une action de sortie “act1” pour représenter l’exécution de l'action,
puis il envoie le canal “done1” à son processus parent S1(a1, act ) indiquant que la tâche est
faite avec succès, le processus ensuite mort, c.à.d. se comporte comme le processus nul.
─ Communication avec les autres MSDs.

Soit n le nombre de tous les diagrammes du système (tous sont concernés lors d'une
diffusion). m le nombre des agents concernés par un multicast. “done11” est un canal utilisé
69
pour recevoir une notification sur la finition de la multicast asynchrone ou la diffusion de

l'action avec succès. “evextk” est le canal externe utilisé par le pool d'un agent k pour recevoir
des événements de l'environnement. “remotek” est un canal public utilisé par le pool à
distance de l’agent k pour recevoir des événements de l'environnement
- Communication unicast (point à point) asynchrone local.

def
AHact1(evextk, act1, done1)  evextk<act1>.done1.0
- Communication multicast asynchronous local.

def
AHact1(evextk, act1, done1, done11) 
evexti< act1>.done11.0 | ... | evextj< act1>.done11.0 | done11.... done11.done1.0
m m
- Communication diffusion asynchronous local.

n
def
AHact1(evextk, act1, done1, done11)  
i 1
evexti< act1>. done11.0 | done11.... done11.done1.0
n
Quand une communication asynchrone est nécessaire, l'une des trois patterns devrait
être suivie : unicast, multicast, ou diffusion.
Dans un unicast (point à point), le processus AHact1(evextk, act1, done1) envoie l'action
au processus pool du diagramme concerné par l'action de sortie “evextk<act1>”, il informe
alors le processus parent S1(a1, act ) que la tâche est faite avec succès par l'action de sortie
“done1” et il mort après.
La deuxième façon est la diffusion multicast; le processus AHact1(evextk, act1, done1,

done11) envoie l'action simultanément au processus pools de m diagrammes concernés par
l'action de sortie “evexti<act1>”, et après chaque envoi une action de sortie “done 11” est
effectuée. Le processus AHact1(evextk, act1, done1) attend en parallèle m actions d'entrée
“done11” qui signifie la diffusion est terminée, il informe alors le processus parent S1(a1, act )
que la tâche est faite avec succès par l'action de sortie “done1” et il mort après.
La troisième façon est la diffusion; le processus AHact1(evextk, act1, done1, done11)

envoie l'action simultanément aux pools de n diagrammes par l'action de sortie
“evexti<act1>”, et après chaque envoi une action de sortie “done11” est effectuée. Le processus
AHact1(evextk, act1, done1, done11) attend en parallèle n actions d'entrée “done11” qui signifie
70
que la diffusion est terminée, il informe alors le processus parent S1(a1, act ) que la tâche est
faite avec succès par l'action de sortie “done1”, et il mort après.
- Communication unicast (point à point) synchrone local “call”.
Il existe deux positions, la position d'envoi, en utilisant l'action “Call” ou la position de

réception en utilisant l'action “Reply”.
def
AHact1(evextk, act1, done1, replyact1)  evextk<act1>.replyact1.done1.0
- Communication multicast synchrone local “call”.

def
AHact1(evextk, act1, done1, done11, replyact1) 
evexti<act1>.replyact1.done11.0 | ... | evextj<act1>.replyact1.done11.0 | done11.... done11.done1.0
m m
- Communication diffusion synchrone local “call”.

def
AHact1(evextk, act1, done1, done11, replyact1) 
n

i 1
evexti<act1>.replyact1.done11.0 | done11.... done11.done1.0
n
- Communication synchrone local “reply”.

def
AHact1(done1, replyact1)  replyact1.done1.0
Dans une communication synchrone, si le diagramme d'états transitions est dans la

position d'envoi (l'appelant), alors une des trois façons suivantes pourrait être suivie comme
pour la communication asynchrone décrite ci-dessus. La différence avec les communications
asynchrones est dans le fait que chaque fois que le processus envoie un événement par l'action
de sortie “evextk<act1>”, il se bloque jusqu'à ce qu'il reçoive une réponse. Ceci est modélisé
par l'action d'entrée “replyact1”. Le reste est comme dans les communications asynchrones.
Nous avons délibérément choisi de passer par le pool de l'appelé afin de ne pas troubler à son
exécution (respecter la sémantique run-to-completion dans ce diagramme et l'ordre des
événements).
Si l’agent est dans la position de réception (l'appelé), il envoie directement la réponse

par l'action de sortie “replyact1” au diagramme appelant sans passer par son pool, car il est
bloqué en attente d'une réponse (pour éviter l’interblocage).
71
- Communication unicast (point à point) asynchrone à distance.

def
AHact1(remotek, act1, done1)  remotek<act1>.done1.0
- Communication multicast asynchrone à distance.

def
AHact1(remotek, act1, done1, done11) 
remotei<act1>. done11.0 | ... | remotej<act1>.done11.0 | done11.... done11.done1.0
m m
- Communication diffusion asynchrone à distance.

def
AHact1(remotek, act1, done1, done11) 
n

i 1
remotei<act1>. done11.0 | done11.... done11.done1.0
n
- Communication unicast (point à point) synchrone à distance “call”.

Il existe deux positions, la position d'envoi en utilisant l'action appel à distance “RCall” ou la
position de réception en utilisant l'action de réponse à distance “RReply”
def
AHact1(remotek, act1, done1, rreplyact1)  remotek<act1>.rreplyact1.done1.0
- Communication multicast synchrone à distance “call”.

def
AHact1(remotek, act1, done1, done11, rreplyact1) 
remotei<act1>.rreplyact1.done11.0 | ... | remotej<act1>.rreplyact1.done11.0 |
m
done11.... done11.done1.0
m
- Communication diffusion synchrone à distance “call”.

def
AHact1(remotek, act1, done1, done11, rreplyact1) 
n
i 1
remotei<act1>.rreplyact1.done11.0 | done11.... done11.done1.0
m
- Communication synchrone à distance “ reply”.

def
AHact1(done1, rreplyact1)  rreplyact1.done1.0
La sémantique des communications asynchrones et synchrones à distance sont

similaires aux sémantiques des communications asynchrones et synchrones locales. La
72
différence réside dans le ciblage du pool à distance du diagramme concerné (pas les pools
locaux) par l'action de sortie “remotek<act1>” qui permet d’envoyer l'action “act1”.
─ Règle 17: (les actions entry et exit d’un état)

Une action entry est exécutée en entrant dans un état, alors qu'une action exit est exécutée lors
de la sortie d'un état. Une action entry peut être considérée comme une action sur la transition
émanant vers l'état, alors qu'une action exit peut être considérée comme une action sur la
transition sortante de l'état. Leur comportement est donc spécifié en utilisant les règles
précédentes.
4.3.2.8. Traitement transitions marquées
─ Règle 18: (transition marquée)

Soit P1, P2  P, S1, S2  S, T1 T, δP(S1) = P1, δP(S2) = P1, δSrc(T1) = S1, δTrg(T1) = S2,
δK(T1) = NT, δE(T1) = E1, δC(T1) = C1, δA(T1) = A1, ΨN(E1) = e1, ΨN(C1) = c1, ΨN(A1) =
 
act1, et ΨPI(S1) = S1(a1, evint1 , e , c , act ). Nous modélisons la sémantique d'un état avec une
transition marquée (qui a un événement, une condition et/ou une action) par le comportement
 
du processus paramétré S1(a1, evint1 , e , c , act ) comme suit:
def
   
S1(a1, evint1, e , c , act )  a1.S1(a1, evint1 , e , c , act ) +
evint1(z).([z = e1] (ν g)c1<g>.g(y).
 
([y=true] (ν done1) (AHact1(act1, done1) | done1.rtc1.S2(a1, evint1 , e , c , act )) +
 
[y=false] S1(a1, evint1 , e , c , act )) +
 
 i 1
[z= ei] rtc1.S1(a1, evint1 , e , c , act ))
Après la réception d'un événement (voir Règle 11) et l'évaluation de la condition (voir
Règle 14), l'action est exécutée par le processus manipulateur d'action (voir Règle 16) et par
conséquent il y a un changement au processus état S2 si la condition est vérifiée. Dans le cas
contraire, la transition ne peut être prise, l'action ne sera pas exécutée et le processus se
poursuit comme lui-même.
─ Règle 19: (transition mobile marquée)

La sémantique d'exécution d'un état avec une transition mobile marquée qui a un événement,
une condition et/ou une action est donnée comme dans (Règle 18). La différence est dans la
demande de migration comme illustré dans (Règle 7).
73
─ Règle 20: (transition <<agentreturn>> marquée)

La sémantique d'exécution d'un état avec une transition << agentreturn >> marquée qui a un
événement, une condition et/ou une action est donnée comme dans (Règle 18). La différence
est dans la demande de migration à la place d’origine comme illustré dans (Règle 8).
─ Règle 21: (transition à distance marquée)

La sémantique d'exécution d'un état avec une transition à distance marquée qui a un
événement, une condition et/ou une action est donnée comme dans (Règle 18). La différence
réside dans la communication à distance dans l'action comme illustré dans (Règle 9, 15).
4.3.2.9. Les états composites et les transitions complexes

Dans les prochaines règles, nous traitons les états composites. Nous commençons par
la transformation des états composites non-concurrents et les états composites non-
concurrents mobiles, après cela, nous traitons les états composites concurrents et les états
composites concurrents mobiles. Nous donnons ici seulement la structure générale de la
transformation par souci de simplicité; c.à.d. nous allons omettre, par exemple, les
événements, les conditions et les actions, parce que leur transformation est déjà expliquée
dans les sections précédentes.
─ Règle 22: (état composé non-concurrent normal)

Soit P1  P, S1, S2, S3  S, G1, ..., Gn  S, R1  R, T1, T2  T, T’1, T’2, ...  T, δP(S1) = P1,
δP(S2) = P1, δP(S3) = P1, δP(G1) = P1, …, δP(Gn) = P1, δReg(R1) = {G1, ..., Gn}, δCmp(S2) =
{R1}, δSrc(T1) = S1, δTrg(T1) = S2, δK(T1) = NT, δE(T1) = ε, δC(T1) = ε, δA(T1) = ε, δSrc(T2) =
S2, δTrg(T2) = S3, δK(T2) = NT, δE(T2) = ε, δC(T2) = ε, δA(T2) = ε, δSrc(T’i) = Gi, δTrg(T’i) =
Gi+1, δK(T’i) = NT, δE(T’i) = ε, δC(T’i) = ε, δA(T’i) = ε, i = 1..n. ΨPI(S1) = S1, ΨPI(S2) = S2.
Nous modélisons la sémantique d'un état composite non- concurrent par le comportement du
processus S2. Nous donnons également la sémantique des autres éléments liés pour
comprendre la transformation.
def
S1  a. S1 + τ. (ν finish)(S2|G1)
def
Gi  a. Gi + τ.Gi+1 i = 1.. n-1
def
Gn  finish.0 i=n
def
S2  a. S2 + finish.S3
Lorsqu’on affronte un état composite non-concurrent, le processus état S1 se comporte

comme deux processus parallèles partageant un canal local “finish”. Le premier est
correspondant à l'état composite non-concurrent englobant S2, l'autre Gi est correspondant au
74
sous-état direct actif de la seule région orthogonale de l'état composite non-concurrent. Ce

dernier processus va évoluer comme illustré dans les sections précédentes, seulement en
arrivant à son dernier état Gn son comportement se change. Ainsi, le processus Gn envoie le
canal “finish” indiquant que l'exécution est terminée. Le processus S2, lors de la réception de
ce canal, évoluera à S3, le processus correspondant à l'état suivant.
Les transitions pourraient avoir des événements, des conditions et/ou des actions, et
leur traitement sera comme illustré dans les sections précédentes. Par exemple, pour S2, nous
pouvons mettre le traitement des événements après avoir reçu le canal “finish”, cela signifie
que, après l’achèvement de l'exécution des sous-états, le processus d'état S2 prend le contrôle
et il sera dans la situation d'attente d'un événement pour passer à S3.
─ Règle 23: (état composé non-concurrent mobile)

Cette règle est similaire à la règle précédente. La seule différence est dans la demande de la
migration vers une autre place par la transition mobile.
─ Règle 24: (état composé concurrent normal)

Soit P1  P, S1, S2, S3  S, G1, ..., Gn  S, H1, ..., Hn  S, R1, R2 R, T1, T2  T, , T’1, T’2,
..., T”1, T”2, ...  T, δP(S1) = P1, δP(S2) = P1, δP(S3) = P1, δP(G1) = P1, …, δP(Gn) = P1,
δP(H1) = P1, …, δP(Hn) = P1, δReg(R1) = {G1, ..., Gn}, δReg(R2) = {H1, ..., Hn}, δCmp(S2) =
{R1, R2}, δSrc(T1) = S1, δTrg(T1) = S2, δK(T1) = NT, δE(T1) = ε, δC(T1) = ε, δA(T1) = ε,
δSrc(T2) = S2, δTrg(T2) = S3, δK(T2) = NT, δE(T2) = ε, δC(T2) = ε, δA(T2) = ε, δSrc(T’i) = Gi,
δTrg(T’i) = Gi+1, δK(T’i) = NT, δE(T’i) = ε, δC(T’i) = ε, δA(T’i) = ε, δSrc(T"i) = Gi, δTrg(T"i) =
Gi+1, δK(T"i) = NT, δE(T"i) = ε, δC(T"i) = ε, δA(T"i) = ε, i = 1..n. et ΨPI(S1) = S1, ΨPI(S2) =
S2. Nous modélisons la sémantique d'un état composé concurrent par le comportement du
processus S2. Nous donnons également la sémantique des autres éléments liés pour
comprendre la transformation.
def
S1  a.S1 + τ.(ν join)(S2|G1|H1)
def
Gi  a. Gi + τ.Gi+1 i = 1..n-1
def
Hi  a. Hi + τ.Hi+1 i = 1..n-1
def
Gn  join.0
def
Hn  join.0
def
S2  a. S2 + join.join.S3
Lorsqu’on affronte un état composé concurrent (un fork implicit), le processus état S1
se comporte comme trois processus parallèles partageant un canal local “join”. Le premier est
75
correspondant à l'état composé S2, les autres Gi et Hi correspondent respectivement aux sous-
états directs actifs des deux régions orthogonales de l'état composé concurent. Ces deux
derniers processus vont évoluer comme illustré dans les sections précédentes, seulement en
arrivant à leur dernier état le comportement se change. Ainsi, les processus G n et Hn envoient
le canal “join” pour indiquer que l'exécution est terminée (un join implicite). Le processus S2,
lors de la réception de ces deux canaux, évoluera à S3; le processus correspondant à l'état
suivant.
─ Règle 25: (état composé concurrent)

Cette règle est similaire à la règle précédente. La seule différence est dans la demande de la
migration vers une nouvelle place comme dans (Règle 7).
4.3.2.10. Le système complet

─ Règle 26: (diagramme d’états-transitions mobile)
Soit MSD1 = (MSD1name, P, D, S, R, T, δK, δsrc, δtrg, δE, δC, δA, δCmp, δReg) un diagramme
d’états transitions mobile et ΨPI(MSD1) = MSD1name(evext1, ..., evextn, remote1, ..., remoten),
Le comportement de ce diagramme d'états transitions mobile est défini dans le π-calcul par
l'expression de processus :
def
MSD1name (evext1, ..., evextn, remote1, ..., remoten) 
(ν a1, m1) (A1(a1, m1, evext1, ..., evextn, remote1, ..., remoten) | Pc(l1,..., ln, a1, m1))
Maintenant, nous avons tous les ingrédients nécessaires pour construire notre système
π-calcul correspondant au diagramme MSD1. Donc, nous devons nous rassembler en tant
qu’un processus l'ensemble du système formé par une composition restreinte de plusieurs
processus interactifs qui évoluent dynamiquement par le passage de messages entre eux.
En ce qui concerne la configuration des places, le processus Pc(l 1,..., ln, a1, m1) est
composé d'un processus actif (comme on le voit à la règle 3), c.-à-d. P11(p1, ... pn,a1, m1) , qui
correspond à la place de base de l'agent (la place sur lequel existe le premier état du
diagramme). Les autres sont passives à savoir Pi 0(p1, ... pn).
La restriction (ν a1, m1) permet d'établir des canaux privés de communication entre le
processus A1(a1, m1, evext1, ..., evextn, remote1, ..., remoten) et Pc(l1,..., ln, a1, m1).
─ Règle 27: (system logiciel à base d’agents mobiles)

Soit MASS = (MASSname, P, MSD1, ...., MSDk ) un system logiciel à base d’agents mobiles qui
consiste en k agents A1, ..., Ak distribués en n places et Ψ(MASS) = MASSname(evext1, ...,
76
evextn, remote1, ..., remoten). Le comportement de MASSname(evext1, ..., evextn, remote1, ...,
remoten) est donné par:
def
MASSname (evext1, ..., evextn, remote1, ..., remoten) 
k
(ν ak, mk) ( 
i 1
Ai(ai, mi, evext1, ..., evextn,remote1, ...,remoten) | Pc(l1,..., ln, a1, m1, .... ak, mk))
Le système est représenté par la composition des processus correspondant aux places
et agents. Ils sont regroupés par places et la restriction (ν a k, mk) rend ces canaux privés entre
chaque processus place et ses processus agents.
Il existe beaucoup de travaux dans la littérature qui tentent de transformer les

diagrammes d’états-transitions UML [57] et les statecharts d’Harel [71] vers des méthodes
formelles et il est impossible d'examiner chacun d'eux ici. Ainsi, nous considérons ici les plus
liés à notre contribution. En fait, les auteurs [46] ont fourni une catégorisation et une
comparaison de vingt-six (26) approches de formalisation des sémantiques des diagrammes
d'états-transitions. Dans [72], une sémantique formelle de diagrammes d'états-transitions est
donnée par une transformation basée sur la logique temporelle. Dans [73] et [74], l’algèbre de
processus CSP est utilisée pour définir une sémantique formelle pour les diagrammes d'états-
transitions. Autres formalisations de diagrammes d'états-transitions en utilisant les
formalismes PROMELA [75], Esterel [76], réseaux de Petri [77], et STATEMATE [78] sont
développés dans la littérature.
D'autres travaux peuvent être considérés, car ils semblent très proches de notre travail
dans l’utilisation du π-calcul comme formalisme cible des diagrammes UML. En fait, les
auteurs [79] ont proposé une formalisation des diagrammes d'états-transitions en utilisant le π-
calcul par une approche progressive. Dans [67] et [68], le π-calcul est utilisé pour formaliser
les diagrammes d'activité UML. Dans [80] une transformation automatique des spécifications
UML constituée de diagrammes de séquence et d'état-transitions vers le π-calcul est fournie.
La sémantique des diagrammes UML à mobilité a été traité dans [81] et [31]. En fait,
les auteurs en [81], ont proposé d’utiliser les réseaux de Petri imbriqués pour formaliser la
sémantique des diagrammes d’états-transitions mobile. Dans [31], une spécification de
machines d'états mobiles en utilisant la logique TLA est présentée et utilisée pour définir les
notions de raffinements.
77
En ce qui concerne toutes les études antérieures, nous remarquons les préoccupations
suivantes:
 Bien qu'il existe déjà une sémantique formelle pour les diagrammes d'état-transitions
M-UML dans [81], le domaine sémantique cible choisie est très limitée en sémantique
et en outils. En effet, les réseaux imbriqués ne sont pas supportés par des outils
d'analyse.
 Le travail présenté dans [79] a été fait sans tenir compte de la mobilité, en plus de la
stratégie fictive adoptée dans la formalisation qui considère souvent qu'il existe des
processus fictifs (non identifiés) qui accomplissent certaines tâches derrière la porte.
Par l'examen de cette approche, nous détectons rapidement qu'il est impossible
d'analyser et de vérifier une spécification π-calcul générée par cette formalisation en
utilisant des outils typiques (par exemple le MWB). Voilà ce qui nous a découragé
d’étendre cette formalisation aux diagrammes d’états-transitions mobiles.
 La définition informelle de la transformation sémantique dans plusieurs travaux
antérieurs (en particulier dans [79], [81]), ce qui les rend insuffisants pour définir la
transformation d’une manière complet.
 Les auteurs en [31] proposent une spécification de machines d'états UML mobiles au
moyen de MTLA, qui est une extension de la logique temporelle de TLA (Temporal
Logic of Actions) avec des modalités spatiales. L'approche peut être classée parmi
ceux qui utilisent les diagrammes d'états-transitions pour le raffinement, en plus de la
pauvreté du modèle cible (le formalisme MTLA) en outils.
Contrairement à tous ces travaux, notre contribution offre de nombreux avantages par
rapport à eux:
 Nous avons proposé les MSDs qui sont une extension très complète pour la
modélisation du comportement des systèmes logiciels à base d’agents mobiles. Nous
avons aussi donné une sémantique formelle pour ces diagrammes en utilisant le π-
calcul comme domaine sémantique cible; cela facilitera la description de ces
diagrammes et la capture de la mobilité. En outre, le π-calcul fournit une théorie riche
et plusieurs outils pour la spécification et l’analyse des systèmes concurrents avec
communications mobiles. Cela le rend plus approprié, comme formalisme cible pour
les diagrammes d'états-transitions mobiles, que d'autres formalismes y compris les
réseaux imbriqués (en [81]).
78
 Notre étude fournit une définition formelle complète de la transformation sémantique

entre les diagrammes d'état-transitions mobiles et le π-calcul. Contrairement à [79],
[81] et [31], notre approche permet de réaliser facilement l'automatisation de la
transformation et de son évolutivité.
 Nous présentons une approche complète et persistante au moins pour la spécification

et la vérification de la mobilité capturée dans ces diagrammes. Cela permet d'importer
les spécifications π-calcul générées dans les outils spécialisés (par exemple MWB) et
procéder à l'analyse.
 Notre approche est consacrée directement à la mobilité modélisée dans une extension
UML à des fins de vérification.
4.5. Discussion et leçons apprises
Nous avons essayé dans cette approche de fournir une formalisation compréhensible et
lisible en reliant immédiatement les éléments de diagrammes d'états-transition mobiles à leurs
expressions π-calcul correspondants.
Nous avons focalisé ici sur les éléments essentiels des diagrammes d'états-transitions
mobiles pour concentrer sur la mobilité (et la concurrence) qui est notre principale
préoccupation, et pour des fins de simplification. Nous n’avons pas donc considéré d’autres
éléments que nous avons jugé qu’ils n’affectent pas le comportement mobile de ces
diagrammes comme par exemple les pseudo-états historique et historique profond, les
jonctions et les décisions, mais notre formalisation peut être étendue à tous les éléments de
diagrammes d'états-transitions mobiles par un paradigme induction/récursion structurel grâce
à la définition formelle de la transformation.
La mobilité fournit par le π-calcul permet la modélisation triviale des mouvements de
l'agent. Dans notre approche, le mécanisme d’extrusion de portée dans le π-calcul est utilisé
pour modéliser la mobilité décrit dans les diagrammes.
Il n’est pas utile de discuter comment prouver est ce que la sémantique est préservée
après la transformation des diagrammes d'états-transitions mobiles en π-calcul, puisque le
premier est une notation et le dernier est un langage formel. Mathématiquement parlant, il n'y
a aucun moyen de prouver l’exactitude (correctness) de notre sémantique. Cependant, nous
pouvons vérifier la solidité (soundness) et l'exhaustivité (completeness) de la transformation
par vérification de modèle (model checking) en utilisant un outil de vérification (par exemple
MWB). On peut montrer que la conversion est saine (sound), c.-à-d. si l’outil de vérification
79
de modèle MWB dit qu'une erreur (le deadlocks par exemple) existe dans l'entrée, alors il
devrait être le cas que l'erreur (l’inter-blocage par exemple) existe dans la spécification
MSDs. Nous pouvons également montrer que la translation est complète, c.-à-d. si la
spécification a une erreur (l’inter-blocage par exemple), alors l’outil de vérification de modèle
sera sûr de la trouver. En fait, nous avons expérimenté notre transformation avec plusieurs
exemples du monde réel dans les deux directions (solidité et exhaustivité) et nous avons
obtenu de bons résultats.
4.6. Conclusion
Dans ce chapitre, nous avons proposé une approche intégrée semi-formelle / formelle
pour spécifier et vérifier les systèmes logiciels à base d'agents mobiles en utilisant les MSDs
et le π-calcul. L'approche consiste à définir un ensemble de règles formelles qui définissent la
sémantique formelle du comportement des éléments des diagrammes d'états-transition
mobiles (MSDs) en utilisant le π-calcul. Nous avons concentré sur les principaux éléments qui
modélisent le comportement mobile des agents dans ces diagrammes.
Comme extension de l’approche, nous prévoyons de l'étendre pour prendre en compte
tous les éléments des diagrammes d'états-transition mobiles, et par conséquent plus de
systèmes complexes seront couverts par l'approche. Nous prévoyons également de formaliser
d’autres diagrammes tels que les diagrammes de séquence mobiles et d’activité mobiles car ils
représentent différents aspects d'un système, et pour fournir une modélisation multi-vues.
Dans le chapitre suivant, nous allons illustrer et tester l’approche par une étude de cas
complet.
80
Chapitre 5
Etude de cas : modélisation et

vérification
5.1 Introduction
5.2 Etude de cas
5.3 Analyse et vérification
5.4 Conclusion
Etude de cas : modélisation et vérification Chapitre 5
5.1. Introduction
Dans ce chapitre, nous allons monter l‟utilité de notre approche proposée dans le
chapitre précédent. Nous allons commencer par donner une étude de cas complète modélisée
par trois MSDs. Ensuite, on va montrer comment générer le code π-calcul étape par étape.
Nous allons procéder par la suite à l‟analyse et la vérification de la spécification π-calcul
générée en utilisant l‟outil MWB (Mobility Workbench).
5.2. Etude de cas

Nous allons illustrer notre approche définie dans le chapitre précédent en l‟appliquant
sur une spécification d'un système logiciel à base d'agents mobiles emprunté de [15]. Elle
modélise un système de vote mobile VS, qui se compose de trois agents en interaction, un
agent stationnaire VA (autorité de vote), un agent mobile VC (collecteur de vote), et un agent
stationnaire VM (gestionnaire de vote). Le VC est mandaté par un VM; son rôle est de
recueillir les votes à partir des stations de vote. En période électorale, le VA commence le
processus de vote en envoyant le VC à son gestionnaire VM. Le VC obtient la liste des
électeurs du VM, puis en interagissant à distance avec l'agent VA il obtient le log de la liste.
Après cela, il visite les stations de vote à leur place pour recueillir les résultats du vote et
envoie-les au VM qui a mandate ce VC.
5.2.1. Modélisation en MSDs

Le comportement du système est défini par le biais de trois diagrammes d'états-
transitions mobiles communicants, un pour chaque agent, comme illustré au Figures (FIG.
5.1).
La figure 5.1 illustre le comportement de l'agent stationnaire VA qui s‟exécute sur la
place (P1). Tout d'abord, le VA est dans l'état IdleElection (IE) lorsque l'élection démarre, il
fait alors une transition vers l'état OnElection (OE). La transition a une action qui consiste à
envoyer un signal StartVotingProcess aux autres diagrammes par une communication
multicast asynchrone. Dans OE, VA peut soit recevoir un événement LogList, alors il exécute
une action LogList qui est une réponse à une communication synchrone avec VC et il reste
dans OE, ou recevoir un événement VotingResults, alors il exécute une action
AnnounceVotingResults et retourne à l'état IE.
La figure 5.2 montre le comportement de l'agent stationnaire VM qui s‟exécute sur la
place (P2). Tout d'abord, le VA est dans l'état VoteManagerIdle (VMI), il reçoit l'événement
StartVotingProcess et il fait un passage à l'état ReadyforVotingManager (RVM). En RVM,
82
quand il reçoit l'événement GetVotersList, il exécute une action qui consiste à envoyer un
signal VotersList au VC par une communication asynchrone; il fait alors une transition vers
l'état WaitforVoteCollectors (WVC). En WVC, quand il reçoit un événement Votes, il
exécute une action qui consiste à envoyer un signal VotingResults au VA par une
communication asynchrone à distance. Il fait alors une transition vers son premier état VMI.
La figure 5.3 illustre le comportement de l'agent mobile VC. Tout d'abord, le VC est
dans l'état ReadyToMove (RTM) à sa place de base (P1) quand il reçoit l'événement
StartVotingProcess, il se déplace alors par une transition mobile à l'état
VotingManagerReached (VMR) dans une autre place (P2). À VMR, l'agent mobile VC passe
par une transition normale à l'état WaitForList (WFL). La transition a une action qui consiste
à envoyer un signal GetVotersList au VM par une communication asynchrone pour obtenir la
liste des électeurs. A WFL, lorsque l'agent mobile reçoit un événement VotersList, le VC
interagit à distance avec VA en exécutant l'action à distance LogList qui consiste en un appel
synchrone pour obtenir le log de la liste, il se déplace ensuite vers l'état ReadyToCollectVotes
(RCV). Dans RCV, l'agent mobile VC se déplace par une transition mobile à l'état
WaitingForVote (WFV) à la place de la première station de vote (P3). La transition a une
action GetVote pour obtenir les votes. Enfin, l'agent mobile VC effectue une transition <<
agentreturn >> pour revenir à sa place de base (P1). La transition a une action qui consiste à
envoyer un message Votes à VM par une communication asynchrone pour lui donner les
résultats du vote de la station.
LogList / RReply VC.LogList
/Send {VC, VM}. StartVotingProcess

M
Idle Election On Election
(IE) (OE)
VotingResults /AnnounceVotingResults
FIG. 5.1 –Le diagramme d'états-transitions mobile du VA.
GetVotersList / Send VC.VotersList
StartVotingProcess /
M
Vote Manager Ready for Voting Wait for Vote
Idle (VMI) Manaer (RVM) Collectors (WVC)
Votes / RSend VA. VotingResults
FIG. 5.2 –Le diagramme d'états-transitions mobile du VM.
83
StartVotingProcess [VM ok]/

M M
ReadyToMove VotingManager-
(RTM) Reached (VMR)
M
/ Send VM.GetVotersList
/ RSend VM.Votes
M
<<agentreturn>>
WaitingForList
(WFL)
VotersList/RCall
R VA.LogList
M / GetVote M
WaitingForVote ReadyToCollect
(WFV) Votes (RCV)
M
FIG. 5.3 –Le diagramme d'états-transitions mobile du VC.
5.2.2. Dérivation du code π-calcul

Nous considérons les raccourcis suivants pour simplifier la dérivation:
def
evext  evext1, evext2, evext3, evext4
def
remote  remote1, remote 2, remote3, remote4
 def
l  l1, l2, l3
def

p  p1, p2, p3
def
e1  startvotingprcess, loglist, replyloglist, votingresults, announcevotingresults
def
e2  startvotingprcess,voterslist, getvoterslist, loglist,replyloglist, getvote,vote, votes
def
e3  startvotingprcess, getvoterslist, voterslist,votes, votingresults
La spécification π-calcul dérivée du système de vote mobile VS modélisé par trois

diagrammes d'états-transitions mobiles interconnectés, est donnée par les expressions de
processus suivantes:
L’agent mobile VC
─ Selon les règles 5, 7, 11 et 19, le comportement de l'agent mobile dans l‟état RTM est
donné par le processus:
84
 def 
RTM(a 2, m2, l , evext , remote , evint2,rtc2, e2 )  a2.RTM(a2, m2, l , evext , remote , evint2,rtc2, e2 ) + evint2(z).([z=startvotingprcess]

rtc2.m2<l2>.VMR(a2, m2, l , evext , remote , evint2,rtc2, e2 ) +

[z = voterslist] rtc2.RTM(a 2, m2, l , evext , remote , evint2,rtc2, e2 ) +

[z = vote] rtc2.RTM(a2, m2, l , evext , remote , evint2,rtc2, e2 ))
Le processus RTM interagit avec le processus place en utilisant le canal “a1”, et dans le même
temps il attend de recevoir une action d'entrée “evint2(z)” sur son canal interne du processus
pool. Si le canal reçu est “startvotingprcess”, le processus RTM envoie le canal “rtc2” au
processus pool pour consommer l'événement, puis il demande la migration vers la place P2 en
utilisant l'action de sortie “m2< l2>” et évolue au processus VMR. Sinon, le processus RTM
envoie le canal “rtc2” pour consommer l'événement, et se continue comme lui-même.
─ Les règles 6 et 16 décrivent le comportement de l'agent mobile dans l'état VMR à la place
P2 par les expressions π-calcul suivantes:
 def 
VMR(a2, m2, l , evext , remote ,evint2,rtc2, e2 )  a2.VMR(a2, m2, l , evext , remote , evint2,rtc2, e2 ) +

(ν done1) (AHgetvoterslist(evext3, getvoterslist, done1) | done1.WFL(a 2, m2, l , evext , remote ,evint2,rtc2, e2 ))
def
AHgetvoterslist(evext 3, getvoterslist, done1)  evext3<getvoterslist>.done1.0
Le processus VMR interagit avec le processus place P2 en utilisant le canal “a 2”, ou exécute
une action modélisée par un processus AHgetvoterslist avant de se comporter comme un
processus WFL. Le processus AHgetvoterslist permet un envoie asynchrone local à l'agent
VM par l'action de sortie evext3<getvoterslist> pour demander la liste des électeurs.
─ Les règles 9, 11, 16, et 21 spécifient le comportement de l'agent mobile dans l'état WFL à la
place P2 par les expressions π-calcul suivantes:
 def 
WFL(a 2, m2, l , evext , remote ,evint2,rtc2, e2 )  a2.WFL(a 2, m2, l , evext , remote ,evint2,rtc2, e2 ) +

evint2(z).([z=voterslist] rtc2.( ν done2)(AHloglist(evext1, loglist, rreplyloglist, done2) |done2.RCV(a2, m2, l , evext , remote ,evint2,rtc2, e2 )) +
 
[z = startvotingprcess] rtc2.WFL(a 2, m2, l , evext , remote ,evint2,rtc2, e2 ) + [z = vote] rtc2.WFL(a2, m2, l , evext , remote ,evint2,rtc2, e2 ))
def
AHloglist(remote1, loglist, rreplyloglist, done2)  remote1<loglist>.rreplyloglist.done2.0
Le processus WFL interagit avec le processus place P2 en utilisant le canal “a2” et dans le
même temps attend de recevoir une action d'entrée “evint2(z)” du processus pool. Si le canal
reçu est “voterslist”, le processus WFL envoie le canal “rtc2” au processus pool pour
consommer l'événement, puis il exécute une action modélisée comme un processus AHloglist
avant de se comporter comme un processus RCV. Le processus AHloglist fait un appel
synchrone à distance à l'agent VA par l'action de sortie “remote1<loglist>” pour obtenir le log
85
de la liste; le processus attend ensuite de recevoir le canal “rreplyloglist” pour terminer

l'exécution.
─ (Règles 7, 16 et 19) spécifient le comportement de l'agent mobile dans l‟état RCV à la place
P2 par l'expression π-calcul suivante:
 def 
RCV(a2, m2, l , evext , remote ,evint2,rtc2, e2 )  a2.RCV(a2, m2, l , evext , remote ,evint2,rtc2, e2 ) +

m2<l3>.(ν done3)(AHgetvote(evext4, getvote, done3) | done3.WFV(a2,m2, l , evext , remote ,evint2,rtc2, e2 ))
def
AHgetvote(evext 4, getvote, done3)  getvote.done3.0
Le processus RCV interagit avec le processus place P2 en utilisant le canal “a2”, ou demande
la migration vers la place P3 en utilisant l'action de sortie “m2< l3>”. Dans le dernier cas, le
processus RCV exécute une action modélisée par un processus AHgetvote avant de se
comporter comme un processus WFV. Le processus AHgetvote fait une action de sortie
"getvote" pour exécuter l'action.
─ (Règles 8, 16 et 20) spécifient le comportement de l'agent mobile dans l'état WFV à la place
P3 par les expressions π-calcul suivantes :
 def 
WFV(a2, m2, l , evext , remote ,evint2,rtc2, e2 )  a2.WFV(a2, m2, l , evext , remote ,evint2,rtc2, e2 ) +

m2<l1>.(ν done1) (AHvotes(remote3, votes, done1) | done1.RTM(a2, m2, l , evext , remote ,evint2,rtc2, e2 ))
def
AHvotes(remote3, votes, done1)  remote3<votes>.done1.0
Le processus WFV interagit avec le processus place P3 en utilisant le canal “a2”, ou demande
le retour à la place P1 en utilisant l'action de sortie “m2<l1>”. Dans le dernier cas, le processus
WFV exécute une action modélisée par un processus AHvotes avant de se comporter comme
un processus RTM. Le processus AHvotes fait un envoie asynchrone à distance à l'agent VM
par l'action de sortie “remote3<votes>” pour envoyer les votes de la station.
─ (Règle 12) spécifie le comportement du pool de l'agent mobile VC par les expressions π-
calcul suivantes (supposant que son taille est de deux évènements maximum, idem pour les
autres pools):
def
A2PL0(evint2, evext2, rtc2)  evext2(x1).A2PL1(evint2, evext2, rtc2, x1)
def
A2PL1(evint2, evext2, rtc2, x1)  evext2(x2).A2PL2(evint2, evext2, rtc2, x1, x2) + evint2<x1>.rtc2.A2PL0(evint2, evext2, rtc2)
def
A2PL2(evint2, evext2, rtc2, x1, x2)  evint2<x2>.rtc2.A2PL1(evint2, evext2, rtc2, x1)
86
Le processus A2PL0 représente le pool quand il est vide, donc il attend de recevoir un
événement “x1” sur son canal externe de communication en utilisant l'action d'entrée
“evext2(x1)” avant d'évoluer au processus A2PL1. Le processus A2PL1 représente le pool
quand il contient un événement, Alors soit il reçoit un autre événement à l'aide de “evext2(x2)”
et évolue à A2PL2, ou il envoie un événement au processus état sur son canal interne par
l'action de sortie “evint2<x1>” et se comporte comme A2PL0. Le processus A2PL2 représente
le pool quand il contient deux événements (c.à.d. complet), il a seulement la possibilité
d‟envoyer un événement au processus état et se comporte ensuite comme A2PL1.
─ (Règle 10) spécifie le comportement de l'agent mobile VC par le processus suivant:

 def 
A2(a2, m2, l , evext , remote )  (ν evint2,rtc2)(( ν e2 )(RTM(a2, m2, l , evext , remote ,evint2,rtc2, e2 )) | A2PL0(evint2, evext2, rtc2) )
Le comportement de l'agent mobile A2 est donné par la composition du comportement du

processus état RTM et le processus pool A2PL0. La restriction (ν evint2, rtc2) rend ces canaux
privés aux deux processus. La restriction (ν e2 ) rend ces canaux privés au processus RTM.
L’agent stationnaire VA (Autorité de vote)

Le comportement de l'agent VA est généré comme pour VC.
def
IE(a1, evext , remote ,evint1,rtc1, e1 )  a1.IE(a1, evext , remote ,evint1,rtc1, e1 ) + (ν done1, done11) (AHstartvotingprcess (evext2,
evext3,evext4,startvotingprcess, done1) | done1.OE(a1, evext , remote ,evint1,rtc1, e1 ))
def
AHstartvotingprcess (evext2, evext3,evext4, startvotingprcess, done1, done11)  evext2<startvotingprcess>.done11.0 |
evext3<startvotingprcess>.done11.0 | done11.done11.done1.0
def
OE(a1, evext , remote ,evint1,rtc1, e1 )  a1.OE(a1, evext , remote ,evint1,rtc1, e1 ) + evint1(z).([z=loglist] rtc1.(ν done1)(AHreplyloglist
(replyloglist, done1) | done1.OE(a1, evext , remote ,evint1,rtc1, e1 )) + [z = votingresults] rtc1.(ν done2)(AHannouncevotingresults
(announcevotingresults, done2) | done2.IE(a1, evext , remote ,evint1,rtc1, e1 )))
def
AHreplyloglist (replyloglist, done1)  replyloglist.done1.0
def
AHannouncevotingresults (announcevotingresults, done2)  announcevotingresults.done2.0
def
def
def
A1PL2(evint1, evext1, rtc1, x1, x2)  evint1<x2>.rtc1. A1PL1(evint1, evext1, rtc1, x1)
def
A1(a1, m1, evext , remote )  (ν evint1,rtc1)((ν e1 )(IE(a1, evext , remote , evint1, rtc1, e1 )) | A1PL0(evint1, evext1, rtc1))
87
L’agent stationnaire VM (Gestionnaire de Vote)

Le comportement de l'agent VM est généré comme dans VC.
def
VMI(a3, evext , remote ,evint3, rtc3, e3 )  a3.VMI(a3, evext , remote ,evint3, rtc3, e3 ) +
evint3(z).([z=startvotingprcess]'rtc3.RVM(a3, evext , remote ,evint3, rtc3, e3 ) +
[z = getvoterslist]'rtc3.VMI(a3, evext , remote ,evint3, rtc3, e3 ) +
[z = votes]'rtc3.VMI(a3, evext , remote ,evint3, rtc3, e3 ) )
def
RVM(a3, evext , remote ,evint3, rtc3, e3 )  a3.RVM(a3, evext , remote ,evint3, rtc3, e3 ) + evint3(z).
([z=getvoterslist] rtc3.(ν done1) (AHvoterslist(evext 2, voterslist, done1) | done1.WVC(a3, evext , remote ,evint3, rtc3, e3 )) + [z =
startvotingprcess] rtc3.RVM(a3, evext , remote ,evint3, rtc3, e3 ) + [z = votes] rtc3.RVM(a3, evext , remote ,evint3, rtc3, e3 ) )
def
AHvoterslist(evext 2, voterslist, done1)  evext2<voterslist>.done1.0
def
WVC(a3, evext , remote ,evint3, rtc3, e3 )  a3.WVC(a3, evext , remote ,evint3, rtc3, e3 ) + evint3(z).([z=votes] rtc3.(ν done1)
(AHvotingresults(evext2, votingresults, done1) | done1.VMI(a3, evext , remote ,evint3, rtc3, e3 )) + [z = startvotingprcess] rtc3.WVC(a3,
evext , remote ,evint3, rtc3, e3 ) + [z = getvoterslist] rtc3.WVC(a3, evext , remote ,evint3, rtc3, e3 ) )
def
AHvotingresults(evext 1, votingresults, done1)  evext1<votingresults>.done1.0
def
def
def
A3PL2(evint3, evext3, rtc3, x1, x2)  evint3<x2>.rtc3.A3PL1(evint3, evext3, rtc3, x1)
def
A3(a3, m3, evext , remote )  (ν evint3, rtc3)((ν e3 )(VMI(a3, evext , remote ,evint3, rtc3, e3 )) | A3PL0(evint3, evext3, rtc3))
La configuration des places du système
─ En Utilisant la règle 3, le comportement des places est spécifié par les expressions π-calcul
suivantes:
  def  
P10( l , p )  p1(z1, m1).P11( l , p ,z1,m1)
  def    
P11( l , p ,z1,m1)  z1.P11( l , p ,z1,m1) + p1(z2, m2).P12( l , p ,z1,m1,z2,m2) +
   
m1(d).([d=l2] p2<z1,m1>.P10( l , p ) + [d=l3] p3<z1,m1>.P10( l , p ))
  def    
P12( l , p ,z1,m1,z2,m2)  z1.P12( l , p ,z1,m1,z2,m2) + z2.P12( l , p ,z1,m1,z2,m2) +
 
p1(z3, m3).P13( l , p ,z1,m1,z2,m2,z3, m3) +
   
m1(d).([d=l2] p2<z1,m1>.P11( l , p ,z2,m2) + [d=l3] p3<z1,m1>.P11( l , p ,z2,m2)) +
   
m2(d).([d=l2] p2<z2,m2>.P11( l , p ,z1,m1) + [d=l3] p3<z2,m2>.P11( l , p ,z1,m1))
  def      
P13( l , p ,z1,m1,z2,m2,z3,m3)  z1.P13( l , p ,z1,m1,z2,m2,z3,m3) + z2.P13( l , p ,z1,m1,z2,m2,z3,m3) + z3.P13( l , p ,z1,m1,z2,m2,z3,m3) +
   
m1(d).([d=l2] p2<z1,m1>.P12( l , p ,z2,m2,z3,m3) + [d=l3] p3<z1,m1>.P12( l , p ,z2,m2,z3,m3)) +
88
   
   
m3(d).([d=l2] p2<z3,m3>.P12( l , p ,z1,m1,z2,m2) + [d=l3] p3<z3,m3>.P12( l , p ,z1,m1,z2,m2))
  def  
P20( l , p )  p2(z1, m1).P21( l , p ,z1,m1)
  def    
   
  def      
P22( l , p ,z1,m1,z2,m2)  z1.P22( l , p ,z1,m1,z2,m2) + z2.P22( l , p ,z1,m1,z2,m2) + p2(z3, m3).P23( l , p ,z1,m1,z2,m2,z3, m3) +
   
   
  def      
P23( l , p ,z1,m1,z2,m2,z3,m3)  z1.P23( l , p ,z1,m1,z2,m2,z3,m3) + z2.P23( l , p ,z1,m1,z2,m2,z3,m3) + z3.P23( l , p ,z1,m1,z2,m2,z3,m3) + \
   
   
   
  def  
P30( l , p )  p3(z1, m1).P31( l , p ,z1,m1)
  def    
   
  def      
P32( l , p ,z1,m1,z2,m2)  z1.P22( l , p ,z1,m1,z2,m2) + z2.P22( l , p ,z1,m1,z2,m2) + p3(z3, m3).P33( l , p ,z1,m1,z2,m2,z3, m3) +
   
   
  def      
P33( l , p ,z1,m1,z2,m2,z3,m3)  z1.P33( l , p ,z1,m1,z2,m2,z3,m3) + z2.P33( l , p ,z1,m1,z2,m2,z3,m3) + z3.P33( l , p ,z1,m1,z2,m2,z3,m3) +
   
   
   
Dans notre exemple, il y a trois places différentes P1, P2, P3 et nous avons trois agents A1,
A2, A3. Ainsi, chaque processus place peut communiquer avec trois agents au maximum.
Chaque processus place a donc l'une des quatre situations; aucune communication avec tout
processus agent (Pi0), en communication avec un processus agent (Pi1), en communication
avec deux processus agent (Pi2), et en communication avec trois processus agent (Pi 3). Le
processus place passe d'une situation à l'autre, soit en recevant les canaux de communication
d'un agent par l'action d'entrée “pi(zj, mj)” (un agent migre vers la place) ou en perdant les
canaux de communication d'un agent par l'action de sortie “p i<zj,mj>” (un agent sort de la
place).
89
─ En utilisant la règle 4, le comportement de la configuration des places est spécifié par

l‟expression π-calcul suivante :
 def      

Pc ( l ,a1, m1,a2, m2,a3, m3)  (ν p ) (P12( l , p ,a1, m1,a2, m2) | P21( l , p ,a3, m3) | P30( l , p ))
Le processus configuration des places est composé de différents processus place dans leur
situation actuelle (c.à.d. le nombre d'agents sur chaque place). P12 signifie que le processus
place (correspondant à la place P1) est dans la troisième situation, c.à.d. il communique avec
deux processus agent. P21 signifie que le processus place (correspondant à la place P2) est
dans la seconde situation, c.à.d. il communique avec un processus agent. P30 signifie que le
processus place (correspondant à la place P3) est dans la première situation, c.à.d. aucune
communication avec tout processus agent. La restriction (^p1, p2, p3) rend ces canaux locaux
aux différents processus places.
Le système de vote mobile VS (système de vote)
─ En utilisant les règles 26 et 27, le comportement du système logiciel à base d‟agents

mobiles est donné par le processus π-calcul suivant :
def  
VS( evext , remote )  (ν a1, m1,a2, m2,a3,m3, l )(A1(a1, m1, evext , remote ) | A2(a2, m2, l , evext , remote ) | A3(a3,m3, evext , remote )

| Pc ( l ,a1, m1,a2, m2,a3, m3))
Le comportement du système est donné par la composition des comportements des différents
processus agents et du processus configuration des places.
5.3. Analyse et vérification

La vérification dans le π-calcul est habituellement faite en vérifiant la bisimulation
d‟équivalences. Un processus plus complexe, qui représente une implémentation, se révèle
être bisimilaire à un processus plus simple qui représente une spécification. Le processus plus
simple devrait être si clair qu'il peut être considéré comme satisfaisant à des exigences
d'exactitude (correctness requirements) dans un sens intuitif, non pas avec la preuve
mathématique rigoureuse. Cela peut ne pas être le cas pour toutes les occasions, et il devrait y
être aussi une méthode de vérification de modèles utilisable avec spécification de logique
temporelle. Il y a des algorithmes de vérification de modèle pour le π-calcul par la logique de
spécification style mu-calcul [93, 94], mais la logique elle-même est très compliquée à décrire
ou à comprendre, et parfois les résultats ne sont pas obtenus dans des délais raisonnables,
même pour les épreuves d‟exigences d'exactitude très simples [95].
90
Dans notre approche, nous avons adopté l‟outil MWB (Mobility Workbench) pour
faire l‟analyse et la vérification des spécifications π-calcul générées. MWB implémente
plusieurs algorithmes qui fournissent différents types d‟analyses.
5.3.1. La logique modale

La logique modale [2][70] est une extension de la logique propositionnelle qui inclue
les notions de nécessité et de possibilité. Elle introduit deux opérateurs dits modaux 1 tel que :
-□p, l‟opérateur de nécessité (signifie que p est nécessairement vrai dans tous les états
du système).
-◊p, l‟opérateur de possibilité (signifie que p est possiblement vrai ; c a d existe un état
du système dans lequel p est vrai).
Elle a plusieurs variantes, et ces dernières sont proposées pour permettre plus de finesse dans
le traitement de la vérité par rapport les opérateurs classiques  et  . En effet, non seulement
les propriétés d‟un système en entier pourront être vérifiées, mais même les propriétés de
certains états d‟un système.
La variante de la logique modale qui nous intéresse ici est celle de Mads Dam [2] ou les seuls
atomes admissibles sont TT (uniformément vrai) et FF (uniformément faux). Sa syntaxe est la
suivante :
P ::= TT modalité « toujours vraie »
| FF modalité « toujours faux »
| not P négation
| P&P conjonction
| P|P disjonction
| [a]P modalité nécessaire en lecture
| [„a]P modalité nécessaire en écriture
| <a>P modalité possible en lecture
| <‟a>P modalité possible en écriture
| min Z . P plus petit point fixe
| max Z . P plus grand point fixe
[a]P exprime la contrainte « après avoir faire une lecture sur le port a, la condition P sera
vraie ». [„a]P exprime la même contrainte, mais en écriture. <a>P exprime la contrainte « on
est on mesure de faire une lecture sur le port a, après quoi on vérifie P ». <‟a>P exprime la
même contrainte, mais en écriture.
1
Les deux opérateurs modaux sont reliés par la relation □   ◊ 
91
Ces derniers opérateurs modaux présentés permettent la démonstration des propriétés finies
sur des processus (en utilisant des chaines finies d‟opérateurs), alors que la plupart des
processus qui nous intéressent et en travaille ont un comportement infini (leurs définitions
sont récursives). La solution est d‟utiliser une formule récursive. Un processus qui vérifie X =
<a> X peut faire l‟action a puis entrer dans un état qui vérifie X. La logique adopte ainsi la
notion du point fixe d‟une formule récursive en utilisant les opérateurs min (plus petit point
fixe) et max (plus grand point fixe).
La logique modale a l‟intérêt de pouvoir vérifier les propriétés de vivacité sur un modèle.
Ainsi, elle permet l‟analyse des processus ayant un comportement infini, pour lesquels une
vérification exhaustive de l‟espace d‟états est impossible. En résumé, son utilisation permet
de montrer des caractéristiques très fines sur un modèle π-calcul.
5.3.2. L’outil MWB

Le MWB (Mobility Workbench) [65][66] est un outil d‟analyse π-calcul écrit en
SML/NJ 2. Il permet l'automatisation de la vérification des spécifications π-calcul par laisser
l'ordinateur dessine des systèmes de transitions étiquetées (LTS, labeled transition systems)
comme dénotation pour les expressions de processus π-calcul. Il peut être utilisé pour:
 La simulation interactive de l'exécution des processus.
 La vérification de modèles (Model checking) des diagrammes d'états-transitions
mobiles pour vérifier si un diagramme représenté dans le π-calcul satisfait sa
spécification, ou vérifier l'exactitude (correctness) de certaines propriétés telles
que les deadlocks, livelocks, ... etc. La logique mu-calcul est utilisée dans l‟outil.
 La vérification de l‟équivalence (Equivalence checking) entre les différents
diagrammes d'états-transitions mobiles qui représentent diverses interactions en
vérifiant l'équivalence entre les expressions de processus π-calcul correspondants
(en utilisant la notion de bisimulation ouverte).
Dans l'outil MWB, l'approche adoptée pour vérifier les propriétés est l'approche “on-
the-fly”; cela signifie que la propriété est vérifiée lors de la génération de l'espace d'état, qui
est immédiatement arrêté lorsque la propriété échoue. Techniquement parler, cette vérification
est effectuée en dessinant, pour chaque expression de processus, un système de transitions
étiquetées (LTS) correspondant, et utiliser après la logique modèle (formules mu-calcul) pour
exprimer les propriétés. Cette logique modèle permet la vérification des caractéristiques
précises. Donc, étant donné une propriété, une réponse positive ou négative est obtenue par le
2
http://www.smlnj.org/
92
vérificateur de modèle (model checker), mais si la propriété n‟est pas satisfaite, l'outil ne
génère pas une trace montrant un cas où elle n'a pas été vérifiée. Ceci peut être corrigé à l'aide
d'une représentation graphique de l'évolution dynamique d'un modèle sous la forme d'un arbre
de différentes exécutions possibles, telles que dans [70].
Certaines représentations textuelles du π-calcul sont remplacés en MWB comme suit:
la restriction ν comme ^, l'action de sortie x comme ’x, l‟action interne τ par t et chaque
expression d'identificateur de processus dans le MWB va commencer avec le mot clé agent.
Nous pouvons importer la spécification π-calcul générée par le biais de la commande input
“file.pi”, ou saisir manuellement les déclarations des processus. La commande env est utilisée
pour imprimer toutes les déclarations des processus d'une spécification importée.
Pour effectuer la vérification dans les lignes qui suivent, nous considérons le système
VS de l‟exemple précédent. En plus, on prend un autre système VS_ qui est le même que VS
sauf que les agents sont distribués d‟une manière différente. En fait, les agents VA_ et VC_
sont sur la place P2_, alors que l‟agent VM_ est sur la place P1_. La génération du code π-
calcul pour VS_ sera de la même manière que la dérivation effectuée dans la section 5.2.2.
Simulation
La commande MWB step exécute de façon interactive un processus étape par étape. A chaque
étape (état) de la simulation, MWB nous montre les différentes actions possibles du processus
en cours d'exécution (numérotés de 0 à N). On peut alors choisir l'une des actions exposées et
MWB ensuite nous présente les nouveaux choix d'actions. Pour mettre fin à la simulation, il
faut taper q. La figure 5.4, montre la simulation de l‟exécution du processus pool de l‟agent
VC, nous pouvons voir le chargement de ce pool par deux évènements et son déchargement.
FIG. 5.4 –Application de la simulation.
93
Vérification de Modèles (model checking)

La commande MWB deadlocks vérifie si un processus peut inter-bloquer ou non, La
commande MWB check peut être utilisée pour vérifier d'autres propriétés de la spécification
qui sont exprimées en formules mu-calcul. Grâce à ce mécanisme de MWB, nous pouvons par
exemple, vérifier les propriétés suivantes (cf. FIG. 5.5):
 Propriété 1: vérifier une propriété essentielle qui est le deadlock dans les diagrammes,
le processus A1 ne souffre pas de deadlock, le processus A2 souffre de deadlock parce
qu‟il prévoit une communication synchrone (un call sur le diagramme). On peut voir
plus de détails en utilisant la simulation de l‟exécution.
 Propriété 2: vérifier si la sémantique run-to-completion des évènements est garantie;
c.-à-d. le processus poule d‟un diagramme n‟envoie un événement que si le précédent
est exécuté. La formule indique qu‟à chaque fois il y a une action d‟écriture sur le
canal « evint2 » dans le processus PL, on doit nécessairement attendre une action de
lecture sur le canal « rtc2 » (d‟une manière indéterminé).
La formule mu-calcul: (max Z . (['evint2][rtc2]TT & [i]Z ))
 Propriété 3: vérifier que l‟agent mobile se trouve toujours dans un état sur une place ;
c.-à-d. le processus place communique toujours avec le processus état (qui correspond
à l‟agent). La formule indique que le processus RTM est toujours dans la nécessité de
ne pas synchroniser sur un port « a2 » en sortie, et la propriété de sureté Z indique que
toutes les actions de lecture qu‟il peut les faire l‟amèneront vers un autre état ou Z est
a nouveau vraie.
La formule mu-calcul: (max Z . (['a2]FF & [i]Z))
94
FIG. 5.5 –Application de la vérification de modèles.
Vérification d’équivalence
La commande MWB eq vérifie si deux processus sont fortes ouverts bisimilaires. La
commande MWB weq vérifie si deux agents sont faibles ouverts bisimilaires. Les commandes
MWB eqd et weqd font en plus la distinction entre les canaux des deux processus vérifiés. La
commande MWB time affiche le détail du raisonnement, à savoir la performance de la
vérification d'équivalence.
Les deux diagrammes états-transitions mobiles VC et VC_ ont la meme structure, et la

différence est dans le comportement mobile dans chaque diagramme. Le VC visite les places
dans l‟ordre P1, P2, P3, P1, et le VC_ visite les places dans l‟ordre P2, P1, P3, P2. Grâce au
mécanisme de vérification d‟équivalence et en utilisant MWB, nous pouvons facilement
vérifier l‟équivalence existante entre le comportement mobile des deux agents VS et VS_ en
vérifiant l‟équivalence entre leurs processus π-calcul correspondants A2 et A2_. Figure 5.6
montre les détails de ces vérifications.
FIG. 5.6 –Application de la vérification d‟équivalence.
95
5.4. Conclusion
Dans ce chapitre, nous avons montré l‟application de notre approche. Nous avons
utilisé une étude de cas complet qui consiste en une spécification d‟un système de vote
électronique. Nous avons illustré étape par étape comment appliquer l‟approche et la façon
d'explorer ses différents avantages dans la modélisation et l'analyse. Nous avons aussi défini
les taches de vérification principales qu‟on peut faire avec le code π-calcul dérivé. Nous avons
essayé de donner une vue d‟ensemble de ce qu‟on peut vérifier et nous avons obtenu des
résultats encourageants.
Nous avons rencontré beaucoup de problèmes avec MWB qui est l‟outil le plus connus
pour la vérification des processus π-calcul. En effet, certains problèmes π-calcul ne
parviennent pas à mettre fin en plusieurs heures en utilisant cet outil et parfois se terminent
d‟une manière inattendue, ce qui nous a empêché de faire plus d‟exemples complexes de
vérification et d‟expérimentation. Une des solutions est celle adoptée dans [95], ou les auteurs
ont proposés de faire une transformation vers Promela [96] qui est le langage d‟entré du
vérificateur de modèles SPIN [59]. En effet, avec leur approche, on peut bénéficier de la
visualisation des contre-exemples lorsqu‟un résultat est négatif. En plus, les problèmes qui
prennent plusieurs heures avec MWB peuvent être résolus avec SPIN en moins d'une seconde.
Le problème avec cette alternative est que la transformation du π-calcul vers Promela cause
beaucoup de perte de sémantique (comme indiqué en [95]), ce qui réduit la richesse
sémantique de nos spécifications π-calcul générées. Une autre solution est d‟essayer
d‟améliorer l‟outil MWB (qui a un code-ouvert) par l‟implémentation d‟autres algorithmes de
vérification qui donnent des résultats meilleurs.
Dans le chapitre suivant, nous allons automatiser notre approche par la construction
d‟un outil complet qui va rendre notre approche réellement applicable et utilisable dans le
monde industriel.
96
Chapitre 6
L'environnement intégré
développé
6.1 Introduction
6.3 Transformation de graphes
6.4 L'environnement intégré proposé
6.5 Méta-modélisation des diagrammes MSDs
6.6 Exemple
6.7 Conclusion
L'environnement intégré développé Chapitre 6
6.1. Introduction
Dans ce chapitre, les idées de la modélisation multi-paradigme [82] sont adoptées pour
l’automatisation de la spécification et la vérification des applications basées agents mobiles.
En fait, deux formalismes sont utilisés; les MSDs et le π-calcul. Les diagrammes d’états-
transitions mobiles sont utilisés pour modéliser le comportement de chaque agent dans un
système logiciel à base d’agents mobiles, alors que le π-calcul est adopté comme le
formalisme de vérification cible pour tels diagrammes.
Nous avons prévu dans ce travail d’arriver à générer une très riche description du
comportement de chaque système modélisé dans notre environnement. Pour atteindre cet
objectif, nous avons proposé d’utiliser pour chaque agent un diagramme d’états-transitions
mobile et nous avons défini comment ils communiquent.
Pour mettre en œuvre notre environnement intégré, nous avons utilisé l'outil AToM3
[53], un outil multi-paradigme et ouvert, pour implémenter l'approche. En fait, nous avons
proposé un méta-modèle pour les diagrammes d’états-transitions mobiles. Après, nous avons
utilisé les capacités de l’AToM3 pour générer un environnement intégré qui soutient la
modélisation visuelle de ces diagrammes. Ensuite, nous avons développé une grammaire de
graphe qui transforme les diagrammes d’états-transitions mobiles vers le π-calcul. Cette
grammaire de graphe implémente la formalisation déjà proposée précédemment. La
spécification π-calcul dérivée est ensuite chargée dans un outil spécialisé (dans notre cas
l'outil MWB [65][66]) pour analyser et vérifier le comportement de ces systèmes.

Il existe plusieurs travaux dans la littérature qui utilisent la transformation des graphes
pour aborder le problème de vérification des modèles UML (et ses extensions), et il est
impossible de les rappeler tous ici. Donc, nous considérons que les contributions qui sont très
semblables à la nôtre, en particulier celles qui utilisent l'outil multi-paradigme AToM3. En
fait, dans [83], les auteurs ont développé un outil pour la vérification des modèles UML. Dans
[84], les auteurs ont proposé une approche intégrée pour la modélisation et l'analyse des
modèles UML (les diagrammes UML d’états-transitions et de collaboration) en les
transformant en modèles réseaux de Pétri colorés à l'aide de la transformation de graphe. Dans
[85], les auteurs ont développé un outil pour la vérification d’un sous-ensemble de
diagrammes UML en les transformant en un système de réécriture exprimé dans le langage
Maude.
98
La sémantique des diagrammes UML avec mobilité en AToM3 a été abordé dans [81]
et [86]. En fait, les auteurs en [81], ont proposé une approche pour la transformation
automatique des diagrammes d’états-transitions mobile vers les réseaux de Petri imbriqués en
utilisant la méta-modélisation et les grammaires de graphes pour la modélisation et l'analyse
des systèmes logiciels à base d'agents mobiles. Les mêmes motivations ont encouragé les
auteurs dans [86] de proposer une approche basée sur la méta-modélisation et la
transformation de graphe pour transformer les diagrammes d'activité mobiles vers les réseaux
de Petri imbriqués pour faire face à une autre vue de la modélisation de ces systèmes.
Bien que les deux dernières contributions sont très intéressants, le formalisme cible
adopté (les réseaux de Petri imbriqués) est très limitée en sémantique et en outils vis-à-vis le
π-calcul (qui est riche en théorie et en outils) dans la spécification des systèmes concurrents
avec communication mobile. En outre, alors que les tentatives précédentes se concentrent
uniquement sur un diagramme, nous considérons dans la nôtre plusieurs diagrammes
communicants afin de recueillir des informations complets pour générer une spécification π-
calcul riche.
6.3. Transformation de graphes

Les graphes fournissent une approche simple et puissante à une variété de problèmes
qui sont typiques à l'informatique en général, et à l’ingénierie dirigée par modèles en
particulier. En fait, pour la plupart des activités de cette dernière une série de notations
visuelles sont proposées, ces notations produisent les modèles qui peuvent être facilement vus
comme des graphes et donc les transformations de graphes sont impliquées.
La transformation de graphes a été utilisée largement pour l'expression de la
transformation de modèles. Particulièrement les transformations de modèles visuels peuvent
être naturellement formulées par des transformations de graphes, puisque les graphes sont
bien adaptés pour décrire les structures fondamentales des modèles.
6.3.1. Principe de transformation de graphes

Les grammaires de graphes [87] sont la généralisation de grammaires de Chomsky
pour les graphes. Dans l’AToM3, une grammaire de graphe est composée d'une action initiale,
quelques règles et une action finale. Les actions initiale et finale sont utilisées pour fournir
des informations nécessaires avant et après l'exécution des règles. Chaque règle possède un
graphe à sa gauche (LHS, Left-Hand Side) et un graphe à sa droite (RHS, Right-Hand Side).
Une règle est évaluée en comparant son LHS avec une zone dans un graphe d'entrée (appelé
99
graphe hôte). Si une correspondance est trouvée, la règle peut être appliquée et le sous-graphe
correspondant dans le graphe de l'hôte sera remplacé par le RHS de la règle. En outre, une
règle peut aussi avoir une condition qui doit être remplie pour appliquer la règle, ainsi que des
actions à effectuer lorsque la règle est exécutée. Un système de réécriture applique
itérativement les règles de correspondance de la grammaire de graphe sur le graphe hôte
jusqu’il n'y aura plus de règles applicables. Les règles sont également ordonnées dans cet outil
par une priorité accordée par l'utilisateur (haut vers le bas).
Règle de
transformation
R = (LHS, RHS)
Appliquer R
Graphe source Graphe destination
RHS
LHS
FIG. 6.1 - Principe de transformation de graphes.
6.3.2. Outils de transformation de graphes

Plusieurs outils de transformation de graphes existent actuellement, on peut citer
quelques exemples d’outils de transformation de graphes : AGG [88], FUJABA [89], AToM3
[53], VIATRA [90], GReAT [91], etc. Ici, le choix est porté sur AToM3 après étude des
différents outils et à cause des avantages qu’il présente. Nous pouvons citer parmi ces
avantages:
 sa simplicité,
 sa disponibilité,
 il est multi paradigmes, ce qui permet plusieurs diagrammes à la fois sur son canevas,
 et il permet les deux types de transformations utilisées à savoir les transformations de
type modèle vers code et les transformations de type modèle vers modèles.
100
6.3.3. Présentation de l’outil AToM3

AToM3 [53] « A Tool for Multi-formalism and Meta-Modeling » est un outil visuel
développé dans le laboratoire MSDL (Modeling, Simulation and Design Laboratory) de
l’université de McGill1 pour la modélisation multi-formalisme et la méta-modélisation, il est
écrit en Python2 et s’exécute sur différentes plateformes (Windows, Linux, etc.). Les deux
tâches principales d'AToM3 sont la méta-modélisation et la transformation de modèles.
Toutefois, il permet par extension de manipuler la simulation ainsi que la génération du code
à partir des modèles élaborés. Concernant la méta-modélisation, AToM3 supporte la
modélisation visuelle en utilisant le formalisme Entité/Relation ou le formalisme diagramme
de classes UML. Cela signifie que dans AToM3, nous pouvons choisir entre ces deux
formalismes pour méta-modéliser un nouveau formalisme. Une fois que nous développons le
méta-modèle du modèle en question, AToM3 peut produire automatiquement un
environnement de modélisation visuel, dans lequel on peut établir et éditer les nouveaux
modèles. Concernant la deuxième tâche qui est la transformation de modèles, AToM3 utilise
les grammaires de graphes afin d’exprimer la transformation (cf. les figures ci-dessous).
FIG. 6.2 - Présentation de l’outil AToM3.
1
http://msdl.cs.mcgill.ca
2
http://www.python.org
101
FIG. 6.3 - Le canevas de l’outil AToM3.
6.4. L'environnement intégré proposé

AToM3 nous permet de développer un outil intégré pour spécifier notre système sous
forme de plusieurs graphes qui représentent les différents diagrammes de modélisation d’un
système. En plus, il nous fournit une flexibilité dans la transformation vers le π-calcul. En
effet, on peut facilement implémenter notre approche formelle qui consiste à utiliser plusieurs
diagrammes en même temps.
6.4.1. L’architecture de l’outil
Dans notre environnement, nous avons adopté une approche combinée méta-
modélisation / grammaire de graphe en utilisant l'outil AToM3 (voir FIG. 6.4). L'approche se
compose de deux tâches essentielles; tout d'abord, nous avons proposé un méta-modèle pour
les diagrammes états-transitions mobiles pour générer un outil intégré AToM3, qui supporte la
modélisation visuelle de ces diagrammes. Deuxièmement, nous avons développé une
grammaire de graphe qui prend les diagrammes d’états-transitions mobiles modélisés dans
l'outil intégré, et nous retourne leurs expressions π-calcul correspondants stockées dans un
fichier sur le disque et importé dans le MWB pour commencer la vérification.
102
Modeling
Mobile
statechart Mapping Verification
diagram 1
. AToM3
. Visual Graph π-calculus MWB
canvas
. models
grammar
Mobile
statechart
diagram n
FIG. 6.4 - Architecture de l’outil proposé.
6.5. Méta-modélisation des diagrammes MSDs

Nous spécifions les formalismes au moyen de méta-modélisation. Le méta-modèle
proposé à une syntaxe abstraite et une syntaxe concrète ce qui facilite la description des
structures de modèles. Ce méta-modèle est initialement proposé au sein de notre équipe
[30], [92], et puis adapté dans ce travail.
6.5.1. Méta-modèle
Figure 6.5 montre le méta-modèle "EtatTransitionMobileMM" proposé pour les
diagrammes de statechart M-UML en utilisant AToM3. Il est développé en utilisant le méta-
formalisme (CD_classDiagramsV3) de l’AToM3 dans l’objectif d’avoir un outil intégrant qui
offre les outils nécessaires pour modéliser ces diagrammes. Le méta-modèle se compose de
cinq classes et onze transitions. Les classes "ETEtatInitial", "ETEtatFinal", "ETEtatSimple",
et "ETEtatMobile" pour représenter les différents états. Ils héritent d'une super-classe
"ETEtat". Les associations "ETTransitionSF", "ETTransitionIS",
"ETTransitionADistanceSS", "ETTransitionSS", "ETAgentReturnMS",
"ETTransitioMobileSM", "ETTransitioMobileMS", "ETTransitioMobileMM",
"ETTransitionADistanceMM", "ETTransitionMM", "ETTransitionMF" sont utilisés pour
représenter les différentes transitions dans un diagramme d’états-transitions mobile.
103
FIG. 6.5 - Le méta-modèle proposé de diagramme d’états-transitions mobile.
La classe «ETEtat»
-Cette classe représente d’une manière générale un état dans le diagramme d'état transition
mobile. Elle possède un attribut ETNom de type String pour donner un nom à l’état. Cette
classe est considérée comme la superclasse des classes suivantes: la classe « ETEtatInitial »,
la classe « ETEtatFinal », la classe « ETEtatSimple » et la classe « ETEtatMobile ».
La classe « ETEtatInitial »
-Cette classe représente l'état initial, elle est graphiquement représentée par un petit cercle
plein noir. Elle est reliée avec la classe « ETEtatSimple » par l'association
« ETTransitionIS ». Cette association possède les attributs PFS et PFD de type String pour
déterminer respectivement la plateforme source et la plateforme destination. L'attribut
Evenements et Activites de type String sont utilisés pour désigner respectivement
l'événement déclencheur de cette transition et les actions à exécuter durant cette transition.
L'association « ETTransitionIS » relie une seule instance de la classe « ETEtatInitial » à
104
une seule instance de la classe « ETEtatSimple » et elle est représentée graphiquement par
une flèche de couleur noire portant tous les attributs.
La Classe « ETEtatMobile »
Cette classe représente l'état mobile, elle est graphiquement représentée par un rectangle blanc
qui porte à son extrémité haute gauche un petit carré marqué par 'M'. Dans le cas où cet état
est l'état actuel, il sera représenté par un rectangle blanc qui porte à son extrémité haute
gauche un petit carré pointillé marqué par 'M', comme le montre la figure 6.6. Cette classe est
reliée à la classe « ETEtatSimple » par l'association « ETTransitionMobileMS » dans le cas
où une transition mobile existe entre cet état et un état simple.
-Cette classe est reliée à la classe « ETEtatSimple » par l'association « ETAgentReturnMS »
s'il existe une transition mobile de retour de l'agent mobile à sa plateforme d’origine. Ces
associations possèdent comme toutes les associations du méta-modèle, les attributs PFS,
PFD, Evenements et Activites. Elles relient une seule instance de la classe
« ETEtatMobile » à une seule instance de la classe « ETEtatSimple » et elles sont
graphiquement représentées par une flèche de couleur noire portant tous les attributs en
ajoutant un petit carrée marqué par "M" pour indiquer que ces transitions sont mobiles. De
plus, nous ajoutons un stéréotype «agentreturn» pour l'association « ETAgentReturnMS »,
afin de modéliser le retour de l'agent mobile vers sa plateforme de base.
La classe « ETEtatMobile » est reliée avec elle-même par trois associations:
 L’association « ETTransitionMM » qui modélise une transition simple entre deux
états mobiles, et elle est graphiquement représentée par une flèche noire portant tous
les attributs. Cette association relie une seule instance de la classe « ETEtatMobile »
à une seule instance d’elle-même.
 L’association « ETTransitionMobileMM » qui modélise la transition mobile entre
deux états mobiles. Elle se représente graphiquement par une flèche noire portant tous
les attributs, en ajoutant un petit carrée marqué par "M" pour indiquer que la transition
est mobile. Cette association relie une seule instance de la classe « ETEtatMobile » à
une seule instance d’elle-même.
 L’association « ETTransitionADistanceMM » qui modélise la transition à distance
entre deux états mobiles. Elle est représentée graphiquement par une flèche noire qui
porte tous les attributs, en ajoutant un petit carrée marqué par "R" pour indiquer la
transition à distance. Cette association relie une seule instance de la classe
« ETEtatMobile » à une seule instance d’elle-même.
105
-La classe « ETEtatMobile » est reliée à la classe « ETEtatFinal » par l'association

« ETTransitionMF », cette dernière « ETTransitionMF » relie une seule instance de la
classe « ETEtatMobile » à une seule instance de la classe « ETEtatFinal », elle est
représentée graphiquement par une flèche de couleur noire portant tous les attributs comme
toute relation simple.
Classe « ETEtatSimple »
Cette classe représente l'état simple (l'état où l'agent mobile se trouve dans sa plateforme de
base) de l'agent mobile, elle est représentée graphiquement par un rectangle blanc (cf. la
figure 6.6), de plus, un petit carré pointillé marqué par 'M' est ajouté à l’extrémité haute
gauche du rectangle pour designer l’état actuel (la plateforme qui possède l'agent mobile à
l’instant courant).
-Cette classe est reliée à la classe « ETEtatMobile » par l'association
« ETTransitionMobileSM » qui possède aussi les attributs PFS, PFD, Evénements et
Activités. Cette association relie une seule instance de la classe « ETEtatSimple » à une seule
instance de la classe « ETEtatMobile », elle est représentée graphiquement comme toutes les
transitions mobiles dans le méta-modèle.
-La classe « ETEtatSimple » est reliée avec elle-même par deux associations:
 L'association « ETTransitionSS » qui modélise la transition simple entre deux états
simples, elle est représentée graphiquement par une flèche noire portant tous les
attributs. Cette association relie une seule instance de la classe « ETEtatSimple » à
une seule instance d'elle-même.
 L’association « ETTransitionADistanceSS » qui modélise la transition à distance
entre deux états simples, elle est représentée graphiquement par une flèche noire
portant tous les attributs en ajoutant un petit carrée marqué par "R" pour montrer qu’il
s’agit d’une transition à distance. Cette association relie une seule instance de la classe
« ETEtatSimple » à une seule instance d’elle-même.
-La classe « ETEtatSimple » est reliée à la classe « ETEtatFinal » par l'association
« ETTransitionSF », cette association possède les attributs PFS, PFD, Evénements et
Activités. L'association « ETTransitionSF » relie une seule instance de la classe
« ETEtatSimple » à une seule instance de la classe « ETEtatFinal », elle est représentée
graphiquement par une flèche de couleur noire portant tous les attributs.
106
Classe « ETEtatFinal »
Cette classe représente l'état final, elle est représentée graphiquement par un cercle de fond
noir inscrit à l’intérieur d’un anneau de même couleur.
La figure 6.6 montre un diagramme d’états-transitions mobile construit avec l'outil généré.
FIG. 6.6 – L’outil intégré AToM3 pour les diagrammes d’états-transitions mobile.
6.5.2. La grammaire de graphe proposée

L’étape la plus importante dans un processus de mise en œuvre d’une transformation
de graphe dans AToM3 est la construction des règles de la grammaire. En effet, elle nécessite
une bonne compréhension des deux langages source et cible. La grammaire de graphe
(MobileStatechart2Picalculus) développée est basée sur les règles sémantiques définies et
décrites dans les chapitres précédents et on génère les expressions π-calcul correspondants
dans les actions des règles à l'aide du code python.
Toutes les règles de la formalisation ont été implémentées, et la grammaire de graphe
code automatiquement dans le π-calcul chaque spécification MSDs modélisée dans l'outil
intégré. Ensuite, La spécification π-calcul générée est automatiquement importée dans un outil
de vérification spécialisé (MWB).
107
La grammaire de graphe développée permet la transformation des diagrammes d’états-

transitions mobiles vers le π-calcul. Nous présentons ses différentes règles ci-dessous (cf.
TAB. 6.1) :
─ Règle 1: P2PI (Places to Pi-calculus),

Priorité: 1
Rôle: cette règle est utilisée pour générer les processus correspondants aux différentes places,
selon la formalisation développée précédemment.
─ Règle 2: IPS2PI (Initial Pseudo-State to Pi-calculus),

Priorité: 2
Rôle: cette règle est utilisée pour transformer le pseudo-état initial vers son expression de
processus correspondant selon la formalisation définie précédemment.
─ Règle 3: FPSSS2PI (Final Pseudo-State from Normal State, to Pi-calculus)

Priorité: 3
Rôle: cette règle transforme un pseudo-état final lié à un état normal vers leur expression de
processus π-calcul correspondant, selon la formalisation développée précédemment.
─ Règle 4: FPSMS2PI (Final Pseudo-State from Mobile State, to Pi-calculus)

Priorité: 3
Rôle: cette règle transforme un pseudo-état final liée à un état mobile vers leur expression de
processus π-calcul correspondant, selon la formalisation développée précédemment.
─ Règle 5: NSNT2PI (Normal State with Normal Transition, to Pi-calculus)

Priorité: 4
Rôle: cette règle transforme un état normal avec une transition normal à leur expression de
processus π-calcul correspondant. L’état normal peut aussi être composite concurrent ou
composite non-concurrent, et cette règle s’occupe de toutes les variantes selon la
formalisation développée précédemment. La règle s’occupe aussi de toutes les variantes des
transitions normales, que ce soit les transitions sans label (sans évènement, condition et
action), ou les transitions avec label (évènement, condition, et/ou action).
─ Règle 6: SSRT2PI (Normal State with Remote Transition, to Pi-calculus)

Priorité: 4
Rôle: cette règle transforme un état normal avec une transition à distance à leur expression de
processus π-calcul correspondant. L’état normal peut aussi être composite concurrent ou
108
transitions à distance, que ce soit les transitions sans label (sans évènement, condition et
action), ou les transitions avec label (évènement, condition, et/ou action).
─ Règle 7: NSMT2PI (Normal State with Mobile Transition, to Pi-calculus)

Priorité: 4
Rôle: cette règle transforme un état normal avec une transition mobile à leur expression de
processus π-calcul correspondant. L’état mobile peut aussi être composite concurrent ou
transitions mobiles, que ce soit les transitions sans label (sans évènement, condition et action),
ou les transitions avec label (évènement, condition, et/ou action).
─ Règle 8: MSNT2PI (Mobile State with Normal Transition to Pi-calculus)

Priorité: 5
Rôle: cette règle transforme un état mobile avec une transition normale à leur expression de
formalisation développée précédemment. Les différentes variantes des transitions normales
sont prises en compte.
─ Règle 9: MSRT2PI (Mobile State with Remote Transition, to Pi-calculus)

Priorité: 5
Rôle: cette règle transforme un état mobile avec une transition à distance à leur expression
formalisation développée précédemment. Les différentes variantes des transitions à distance
─ Règle 10: MSMT2PI (Mobile State with Mobile Transition, to Pi-calculus)

Priorité: 5
Rôle: cette règle transforme un état mobile avec une transition mobile à leur expression de
processus π-calcul correspondant, L’état mobile peut aussi être composite concurrent ou
formalisation développée précédemment. Les différentes variantes des transitions mobiles
109
─ Règle 11: MSART2PI (Mobile State with AgentReturn Transition, to Pi-calculus)

Priorité: 5
Rôle: cette règle transforme un état mobile avec une transition AgentReturn à leur expression
de processus π-calcul correspondant, L’état mobile peut aussi être composite concurrent ou
formalisation développée précédemment. Les différentes variantes des transitions
AgentReturn sont prises en compte.
─ Règle 12: CE2PI (Conditions Evaluator to Pi-calculus)

Priorité: 6
Rôle: cette règle est utilisée pour générer le processus d’évaluation de conditions selon la
formalisation définie précédemment.
─ Règle 13: MSD2PI (MSD to Pi-calculus)

Priorité: 7
Rôle: La règle génère les processus correspondant à chaque processus agent et qui sont
composés pour chacun d’eux d’un processus pool et un processus état.
─ Règle 14: MASS2PI (System to Pi-calculus)

Priorité: 8
Rôle: cette règle est utilisée pour générer le processus correspondant au système et qui est
composé des différents processus agents et le processus configuration de places.
110
Règle1- P2PI Règle2- IPS2PI
:=
:=
Règle3- FPSSS2PI Règle4- FPSMS2PI
:= :=
Règle5- SSST2PI Règle6- SSRT2PI
:= :=
Règle7- SSMT2PI Règle8- MSST2PI
:=
:=
Règle9- MSRT2PI Règle10- MSMT2PI
:= :=
Règle11- MSART2PI Règle12- CE2PI
:=
:=
Règle13- MSD2PI Règle14- MASS2PI
:= :=
TAB. 6.1 – La grammaire de graphe proposée.
111
Nous portons attention que, parallèlement, il y a la génération du code π-calcul (comme on a

déjà dit). Nous présentons en détails "Règle 7" pour comprendre comment faire (cf. TAB.
6.2), les autres règles ont le même principe à celui présentée ici et on ne va pas présenter tous
le code python.
Règle 7 : Un état simple avec une transition mobile vers pi-calculus

Nom: NSMT2PI (Normal State with Mobile Transition to pi-calculus)
Priorité: 4
Rôle: Cette règle transforme un état simple avec une transition mobile dans un diagramme de
d’états-transitions mobile vers une expression π-calcul. Dans la condition de la règle, on teste
si l'état et la transition mobile sont déjà transformés, si ce n’est pas le cas, le graphe de la LHS
est transformé au graphe de la RHS. Après, dans l'action de la règle on ouvre un fichier
"picalculus.txt" et nous y ajoutons le code π-calcul correspondant selon les règles sémantiques
définies précédemment.
Condition
:=
Action
TAB. 6.2 –Transformation d'un état simple avec une transition mobile vers π-calcul.
6.6. Exemple
Prenant comme exemple l’automatisation de l’étude de cas décrite dans le chapitre
précédent. Au début, l’outil intégré développé permet de spécifier le système VS en utilisant
les trois types différents des diagrammes sur le même canevas. Ensuite, un bouton permet de
lancer l’exécution de la grammaire de graphe qui prend le digramme d’états-transitions
mobile comme diagramme de conduite et récupérer l’information nécessaire à partir des
112
autres diagrammes afin de générer la spécification π-calcul adéquate. Figure 6.7 illustre
l’automatisation.
FIG. 6.7 – L’outil intégré développé.
6.7. Conclusion
Dans ce chapitre, nous avons développé un environnement intégré à l'aide de l'outil
multi-paradigme AToM3 pour l’automatisation de la modélisation et la vérification des
systèmes logiciels à base d'agents mobiles, en utilisant une approche combinée méta-
modélisation et grammaire de graphe. Nous avons utilisé plusieurs diagrammes MSDs
comme source, et le formalisme commun cible adopté dans notre travail est le π-calcul qui est
riche en théorie et en outils pour répondre aux questions nécessaires qui nous intéressent dans
un système.
Dans les futures travaux, nous prévoyons d'ajouter d'autres diagrammes UML mobile à
l’environnement (tels que les diagrammes de séquences et d'activité mobiles). De cette
manière, nous allons garantir que tous les vues d’un système à base d’agents mobiles seront
couvertes. Un autre problème qu’on en travaille actuellement est celui de cacher le processus
de vérification à l'utilisateur lambda, qui ne maitrise pas habituellement les techniques
formels.
113
Conclusion générale
Conclusion générale
Dans cette thèse, nous nous sommes intéressés par la proposition d’une approche pour la
modélisation et la vérification des systèmes logiciels à base d’agents mobiles en utilisant l’UML
et le π-calcul. Nous avons fait un tour sur la technologie des agents mobiles, ainsi que les deux
langages utilisés à savoir l’UML, comme langage de modélisation semi-formel, et le π-calcul,
comme langage de spécification formel. Nous avons évoqué par la suite les différentes approches
existantes dans la littérature en faisant une étude comparative qui permet de discuter les avantages
et les inconvénients de chacune d’elles. Après, sur la base de plusieurs motivations, notre choix
est porté sur l’extension des diagrammes d’états-transitions M-UML, nous les avons appelés les
MSDs (Mobile Statechart Diagrams). Ensuite, nous avons proposé une approche intégrée
MSDs / π-calcul, qui consiste en l’utilisation des diagrammes d’états-transitions mobiles pour
la modélisation du comportement de différents agents dans une application basée agents
mobiles. Après la transformation vers le π-calcul pour permettre la vérification. L’approche
dans son intégralité a été implémenté en utilisant une approche combinée méta-modélisation /
grammaire de graphe par le bais de l'outil AToM3. Le produit final de cette thèse permet à un
utilisateur d’utiliser des diagrammes d’états-transitions mobiles pour la modélisation du
comportement de différents agents d’une application basée agents mobiles (modélisation
visuelle en utilisant des graphes) et après, les faire transformer automatiquement vers un code
π-calcul qui est importé par la suite dans un outil spécialisé (MWB) pour commencer la
vérification.
Dans un futur travail, nous compterons d’inclure d'autres diagrammes UML et d’en
ajouter à notre environnement intégré (tels que les diagrammes de séquence et d'activité
mobiles). De cette manière, nous allons garantir que tous les vues d’un système à base
d’agents mobiles seront couvertes. Un autre problème qu’on en travaille actuellement est celui
de cacher le processus de vérification à l'utilisateur lambda, qui ne maitrise pas habituellement
les techniques formelles, cela en faisant une interface d’abstraction du processus de
vérification.
Autre perspective est la génération du code de l’application à partir de notre approche en
utilisant un middleware comme JADE. Cela va permettre de rendre notre approche pratique.
En effet, il permet à un utilisateur de développer une application sein en suivant notre
approche.
114
Bibliographie et Webographie
1. Iglesias, C. A., Garijo, M., & González, J. C. (1998, July). A survey of agent-oriented methodologies. In
International Workshop on Agent Theories, Architectures, and Languages (pp. 317-330). Springer Berlin
Heidelberg.
2. Outtagarts, A. (2009). Mobile agent-based applications: A survey. International Journal of Computer
Science and Network Security, 9(11), 331-339.
3. Melomey, D., Mouratidis, H., & Imafidon, C. (2007). An Evaluation of Current Approaches for Modelling
Mobility of Agents. Advances in Computing and Technology, The School of Computing and Technology
2nd Annual Conference, ICGES Press.
4. Kusek, M., & Jezic, G. (2006, May). Extending UML sequence diagrams to model agent mobility. In
International Workshop on Agent-Oriented Software Engineering (pp. 51-63). Springer Berlin Heidelberg.
5. Belloni, E., & Marcos, C. (2003). Modeling of mobile-agent applications with UML. In Proceedings of the
Fourth Argentine Symposium on Software Engineering (ASSE 2003) (Vol. 32, pp. 1666-1141).
6. Fuggetta, A., Picco, G. P., & Vigna, G. (1998). Understanding code mobility. IEEE Transactions on
software engineering, 24(5), 342-361.
7. Nwana, H. S. (1996). Software agents: An overview. The knowledge engineering review, 11(03), 205-244.
8. Grasshopper mobile agent system (2003). IKV++ GmbH, documentation and software. Available at:
http://www.grasshopper.de/
9. Vigna, G. (2004). Mobile agents: Ten reasons for failure. In Mobile Data Management, 2004. Proceedings.
2004 IEEE International Conference on (pp. 298-299). IEEE.
10. Braun, P., & Rossak, W. R. (2005). Mobile agents: Basic concepts, mobility models, and the tracy toolkit.
Elsevier.
11. Audibert, L. (2007). UML 2. http://www-lipn.univ-paris13.fr/audibert/pages/enseignement/cours.htm
12. Rumbaugh, J., Jacobson, I., & Booch, G. (2004). Unified modeling language reference manual, the. Pearson
Higher Education.
13. Bauer, B., Müller, J. P., Odell, J., & Agent-Oriented, J. O. (2001). Agent UML: A Formalism for Specifying
Multiagent Interaction. 22nd International Conference on Software Engineering (ICSE), Agent-Oriented
Software Engineering (pp. 91–103). Springer.
14. Červenka, R., Trenčanský, I., Calisti, M., & Greenwood, D. (2004, July). AML: agent modeling language
toward industry-grade agent-based modeling. In International Workshop on Agent-Oriented Software
Engineering (pp. 31-46). Springer Berlin Heidelberg.
15. Saleh, K., & El-Morr, C. (2004). M-UML: an extension to UML for the modeling of mobile agent-based
software systems. Information and Software Technology, 46(4), 219-227.
115
16. Mouratidis, H. (2002). Extending the unified modeling language to model mobile agents. Proceedings Agent
Oriented Methodologies Workshop, Annual ACM Conference on Object Oriented Programming, Systems,
Languages (OOPSLA).
17. Klein, C., Rausch, A., Sihling, M., & Wen, Z. (2000). Extension of the Unified Modeling Language for
mobile agents. Unified Modeling Language: Systems Analysis, Design and Development Issues, 116-128.
18. Belghiat, A., Chaoui, A., Maouche, M., & Beldjehem, M. (2014, October). Formalization of mobile UML
statechart diagrams using the π-calculus: an approach for modeling and analysis. In International
Conference on Information and Software Technologies (pp. 236-247). Springer International Publishing.
19. Kang, M., & Taguchi, K. (2004). Modelling Mobile Agent Applications by Extended UML Activity
Diagram. In Proceedings of the 6th International Conference on Enterprise Information Systems (ICEIS)’04
(pp. 519-522).
20. Bahri, M. R., Mokhtari, R., & Chaoui, A. (2009). Towards an extension of UML2. 0 to model mobile agent-
based systems. International Journal of Computer Science and Network Security, 9(10), 124-131.
21. Bettini, L., De Nicola, R., & Loreti, M. (2002, April). Formalizing properties of mobile agent systems. In
International Conference on Coordination Languages and Models (pp. 72-87). Springer Berlin Heidelberg.
22. Milner, R. (1999). Communicating and Mobile Systems: the π-calculus, Cambridge University Press.
23. Fournet, C., Gonthier, G., Lévy, J. J., Maranget, L., & Rémy, D. (1996, August). A calculus of mobile
agents. In International Conference on Concurrency Theory (pp. 406-421). Springer Berlin Heidelberg.
24. Oquendo, F. (2004). π-ADL: an Architecture Description Language based on the higher-order typed π-
calculus for specifying dynamic and mobile software architectures. ACM SIGSOFT Software Engineering
Notes, 29(3), 1-14.
25. Xu, D., & Deng, Y. (2000). Modeling mobile agent systems with high level Petri nets. In Systems, Man, and
Cybernetics, 2000 IEEE International Conference on (Vol. 5, pp. 3177-3182). IEEE.
26. Xu, D., Yin, J., Deng, Y., & Ding, J. (2003). A formal architectural model for logical agent mobility. IEEE
Transactions on Software Engineering, 29(1), 31-45.
27. Xu, H., & Shatz, S. M. (2002). A Design Model for Intelligent Mobile Agent Software Systems.
Computer Science Department, The University of Illinois at Chicago.
28. Schmitt, A., & Stefani, J. B. (2004, March). The kell calculus: A family of higher-order distributed process
calculi. In International Workshop on Global Computing (pp. 146-178). Springer Berlin Heidelberg.
29. Sewell, P., Wojciechowski, P. T., & Pierce, B. C. (1998, May). Location-independent communication for
mobile agents: a two-level architecture. In International Conference on Computer Languages (pp. 1-31).
Springer Berlin Heidelberg.
30. Bahri, M. R. (2010). Une approche intégrée Mobile-UML/Réseaux de Pétri pour l'analyse des systèmes
distribués à base d'agents mobiles (Doctoral dissertation, Doctoral thesis, University of Constantine,
Algeria).
31. Knapp, A., Merz, S., & Wirsing, M. (2004, July). Refining mobile UML state machines. In International
Conference on Algebraic Methodology and Software Technology (pp. 274-288). Springer Berlin Heidelberg.
32. Merz, S., Wirsing, M., & Zappe, J. (2003, April). A spatio-temporal logic for the specification and
refinement of mobile systems. In International Conference on Fundamental Approaches to Software
Engineering (pp. 87-101). Springer Berlin Heidelberg.
116
33. Aridor, Y., & Lange, D. B. (1998, May). Agent design patterns: elements of agent application design. In
Proceedings of the second international conference on Autonomous agents (pp. 108-115). ACM.
34. Cardelli, L., & Gordon, A. D. (2000). Mobile ambients. Theoretical computer science, 240(1), 177-213.
35. De Nicola, R., Ferrari, G. L., & Pugliese, R. (1998). KLAIM: A kernel language for agents interaction and
mobility. IEEE Transactions on software engineering, 24(5), 315-330.
36. Kuhn, T. A., & Von Oheimb, D. (2003, September). Interacting state machines for mobility. In International
Symposium of Formal Methods Europe (pp. 698-718). Springer Berlin Heidelberg.
37. Latella, D., Massink, M., Baumeister, H., & Wirsing, M. (2004, March). Mobile UML statecharts with
localities. In International Workshop on Global Computing (pp. 34-58). Springer Berlin Heidelberg.
38. Berard, E.V. (1995). A comparison of object-oriented methodologies. Technical report. Object Agency Inc.
39. Belloni, E., & Marcos, C. (2004, November). MAM-UML: an UML profile for the modeling of mobile-
agent applications. In Computer Science Society, 2004. SCCC 2004. 24th International Conference of the
Chilean (pp. 3-13). IEEE.
40. Poggi, A., Rimassa, G., Turci, P., Odell, J., Mouratidis, H., & Manson, G. (2003, July). Modeling
deployment and mobility issues in multiagent systems using AUML. In International Workshop on Agent-
Oriented Software Engineering (pp. 69-84). Springer Berlin Heidelberg.
41. Chhetri, M. B., Price, R., Krishnaswamy, S., & Loke, S. W. (2006, January). Ontology-based agent mobility
modelling. In System Sciences, 2006. HICSS'06. Proceedings of the 39th Annual Hawaii International
Conference on (Vol. 2, pp. 45a-45a). IEEE.
42. Hachicha, H., Loukil, A., & Ghedira, K. (2009). MA-UML: a conceptual approach for mobile agents'
modelling. International Journal of Agent-Oriented Software Engineering, 3(2-3), 277-305.
43. Hachicha, H., Loukil, A., & Ghedira, K. (2008, May). MAMT: an environment for modeling and
implementing mobile agents. In Sixth International Workshop From Agent Theory to Agent Implementation
(AT2AI-6) (pp. 75-82).
44. Tolksdorf, R. (1998, July). Coordination patterns of mobile information agents. In International Workshop
on Cooperative Information Agents (pp. 246-261). Springer Berlin Heidelberg.
45. Lima, E. F., Machado, P. D., Sampaio, F. R., & Figueiredo, J. C. (2004). An approach to modelling and
applying mobile agent design patterns. ACM SIGSOFT Software Engineering Notes, 29(3), 1-8.
46. Crane, M. L., & Dingel, J. (2005). On the semantics of UML state machines: Categorization and
comparison. In In Technical Report 2005-501, School of Computing, Queen’s.
47. Jezic, G., & Lovrek, I. (2004). Using Pi-Calculus for specification of mobile agent communication. In
IASTED Conf. on Software Engineering and Applications (pp. 356-361).
48. Cervenka, R., & Trencansky, I. (2007). The Agent Modeling Language-AML: A Comprehensive Approach
to Modeling Multi-Agent Systems. Springer.
49. Melomey, D., Imafidon, C. & Williams, G.(2007). A Comparative Study of Modeling Languages for Agent
Systems. Systems and Information Science Notes (SISN) (Vol. 2, pp 207-212).
50. Bauer, B., & Müller, J. P. (2004). Methodologies and modeling languages. Agent-based Software
Development, (pp 77-131).
51. Bauer, B., & Odell, J. (2005). UML 2.0 and agents: how to build agent-based systems with the new UML
standard. Engineering applications of artificial intelligence, 18(2), 141-157.
117
52. Lange, D. B., & Oshima, M. (1999). Seven good reasons for mobile agents. Communications of the ACM,
42(3), 88-89.
53. AToM3 home page, (online) available at: http://atom3.cs.mcgill.ca/
54. Belghiat, A., Chaoui, A., & Aldahoud, A. (2015). Bridging the Gap between Modeling of Mobile Agent-
based Systems and Semantic Web using Meta-Modeling and Graph Grammars. In The 7th International
Conference on Information Technology (ICIT).
55. Milojicic, D., Breugst, M., Busse, I., Campbell, J., Covaci, S., Friedman, B., Kosaka, K., Lange, D., Ono,
K., Oshima, M., Tham, C., Virdhagriswaran, S., & White, J. (1998). MASIF: The OMG mobile agent
system interoperability facility. Personal and Ubiquitous Computing, 2(2), 117-129.
56. FIPA, Foundation for Intelligent Physical Agents, (2002). FIPA Agent Management Support for Mobility
Specification. Document number dc00087c. Technical report, Geneva, Switzerland.
57. OMG, Object Management Group, (2011). Unified Modeling Language, Superstructure, version 2.4,
http://www.omg.org/spec/UML/2.4
58. Piechocki, L. (2007). UML, le langage de modélisation objet unifié.
59. Holzmann, G. J. (1997). The model checker SPIN. IEEE Transactions on software engineering, 23(5), 279-
295.
60. Fowler, M. (2004). UML distilled: a brief guide to the standard object modeling language. Addison-Wesley
Professional.
61. Milner, R., Parrow, J., & Walker, D. (1992). A calculus of mobile processes, I and II, Information and
computation, 100(1), 1-40.
62. Milner, R. (1993). The polyadic π-calculus: a tutorial. In Logic and algebra of specification (pp. 203-246).
63. Sangiorgi, D., & Walker, D. (2003). The pi-calculus: a Theory of Mobile Processes. Cambridge university
press.
64. Milner, R. (1979). Flowgraphs and flow algebras. Journal of the ACM (JACM), 26(4), 794-818.
65. Victor, B. (1994). A Verification Tool for the Polyadic π-Calculus. Licentiate thesis, Department of
Computer Systems, Uppsala University.
66. Victor, B., & Moller, F. (1994, June). The Mobility Workbench—a tool for the π-calculus. In Proceedings of
International Conference on Computer Aided Verification (pp. 428-440). Springer Berlin Heidelberg.
67. Lam, V. S. (2008). On π-calculus semantics as a formal basis for UML activity diagrams. International
Journal of Software Engineering and Knowledge Engineering, 18(04), 541-567.
68. Yang, D., & Zhang, S. S. (2004). Using π-calculus to formalize UML activity diagrams. In 10th Int. Conf.
and Workshop on the Engineering of Computer-based Systems, IEEE Computer Society, (pp. 47-54).
69. Posse, E. (2010). Mapping UML-RT state machines to kiltera. Technical Report 2010-569, School of
Comp., Queen’s Univ..
70. Marsden, E. (1999). Description formelle d’un protocole à méta-objets. Mémoire préparé dans le cadre du
Diplome d’Etudes Approfondies en Informatique Fondamentale et Parallélisme.
71. Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of computer programming,
8(3), 231-274.
118
72. Rossi, C., Enciso, M., & De Guzmán, I. P. (2004). Formalization of UML state machines using temporal
logic. Software & Systems Modeling, 3(1), 31-54.
73. Ng, M. Y., & Butler, M. (2003, September). Towards formalizing UML state diagrams in CSP. In Software
Engineering and Formal Methods, 2003. Proceedings. First International Conference on (pp. 138-147).
IEEE.
74. Yeung, W. L., Leung, K. R., Wang, J., & Dong, W. (2005, December). Improvements towards formalizing
UML state diagrams in CSP. In Software Engineering Conference, 2005. APSEC'05. IEEE.
75. Lilius, J., & Paltor, I. P. (1999). The semantics of UML state machines. TUCS Technical Report No. 273.
Turku Centre for Computer Science.
76. Seshia, S. A., Shyamasundar, R. K., Bhattacharjee, A. K., & Dhodapkar, S. D. (1999, September). A
translation of Statecharts to Esterel. In International Symposium on Formal Methods (pp. 983-1007).
77. Saldhana, J., & Shatz, S. M. (2000, July). UML diagrams to object petri net models: An approach for
modeling and analysis. In Proceedings of International Conference on Software Engineering and
Knowledge Engineering (pp. 103-110).
78. Harel, D., & Naamad, A. (1996). The STATEMATE semantics of statecharts. ACM Transactions on
Software Engineering and Methodology (TOSEM), 5(4), 293-333.
79. Lam, V. S.W, Padget, J. (2001). Formalization of UML Statechart Diagrams in the π-Calculus. In
Proceedings of Software Engineering Conference, IEEE.
80. Pokozy-Korenblat, K., & Priami, C. (2004). Toward extracting π-calculus from UML sequence and state
diagrams. Electronic Notes in Theoretical Computer Science, 101, 51-72.
81. Bahri, M. R., Hettab, A., Chaoui, A., & Kerkouche, E. (2009, December). 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 Formal Methods (SEEFM), 2009 Fourth South-East European
Workshop on (pp. 33-39). IEEE.
82. Vangheluwe, H., De Lara, J., & Mosterman, P. J. (2002, April). An introduction to multi-paradigm
modelling and simulation. In Proceedings of the AIS’2002 conference (AI, Simulation and Planning in High
Autonomy Systems), Lisboa, Portugal (pp. 9-20).
83. Guerra, E., & Lara, J. D. (2003). A framework for the verification of UML models. Examples using petri
nets. In JISBD’03. Alicante.
84. Kerkouche, E., Chaoui, A., Bourennane, E., Labbani, O. (2010). A UML and Colored Petri Nets Integrated
Modeling and Analysis Approach using Graph Transformation. Journal of Object Technology, 9(4).
85. Chama, W., Elmansouri, R., & Chaoui, A. (2012). Model checking and code generation for UML diagrams
using graph transformation. International Journal of Software Engineering & Applications, 3(6), 39.
86. Guerrouf, F., Chaoui, A., & Aldahoud, A. (2013). A graph transformation approach of mobile activity
diagram to nested Petri nets. International Journal of Computer Aided Engineering and Technology, 5(1),
44-57.
87. Ehrig, H., Rozenberg, G., & Kreowski, H. J. (1999). Handbook of graph grammars and computing by graph
transformation (Vol. 3). World Scientific.
88. AGG. Home page: http://tfs.cs.tu-berlin.de/agg/
119
89. FUJABA. Home page: http://www.fujaba.de/

90. VIATRA. Home page: http://dev.eclipse.org/viewcvs/indextech.cgi/gmt-home/subprojects/ VIATRA2/
index.html
91. GReAT. Home page: http://www.escherinstitute.org/Plone/tools/suites/mic/great/
92. Aissam, B. (2012). Transformation des modèles UML vers des ontologies OWL (Magister dissertation,
Université Mohamed Boudiaf de M'sila, Algérie).
93. Beste, F. B. (1998). The Model Prover - a sequent-calculus based modal-calculus model checker tool for
finite control-calculus agents. M.S. Thesis. Dept. of Computer Science, Uppsala University
94. Dam, M. (1993, August). Model checking mobile processes. In International Conference on Concurrency
Theory (pp. 22-36). Springer Berlin Heidelberg.
95. Song, H., & Compton, K. J. (2003). Verifying π-calculus processes by Promela translation. University of
Michigan, Tech. Rep. CSE-TR-472-03.
96. Holzmann, G. J. (1997). Promela language reference. Bell Labs.
120
Communications et Publications
Communications et Publications
Belghiat, A., Chaoui, A., Maouche, M., Beldjehem, M.: Formalization of Mobile UML
Statechart Diagrams using the π-calculus: An Approach for Modeling and Analysis. In
G. Dregvaite and R. Damasevicius (Eds.): ICIST, CCIS 465, pp. 236–247. Springer,
2014.
Aissam Belghiat and Allaoua Chaoui. «Bridging the Gap between Modeling of Mobile
Agent-based Systems and Semantic Web using Meta-Modeling and Graph Grammars».
In The 7th International Conference on Information Technology (ICIT), 2015, Jordan.
Aissam Belghiat and Allaoua Chaoui. «A π-calculus-based approach for the verification
of UML2 sequence diagrams». In ICSOFT, the 10th International Joint Conference on
Software Technologies, 2015, France.
Aissam Belghiat, Allaoua Chaoui, and Mokhtar Beldjehem. « Capturing and Verifying
Dynamic Program Behaviour Using UML Communication Diagrams and Pi-Calculus».
In IEEE International Conference on Information Reuse and Integration, 2015, USA.
Aissam Belghiat, Allaoua Chaoui, "A TGG Approach for a Bidirectional Automatic
Mapping between UML and pi-calculus", In Proceedings of the International
Conference on Intelligent Information Processing, Security and Advanced
Communication, ACM IPAC '15, 2015, Algeria.
Aissam Belghiat, Allaoua Chaoui, and Mokhtar Beldjehem.“Capturing and Verifying

Dynamic Systems Behavior Using UML and Pi-Calculus”. In Theoretical Information
Reuse and Integration (pp. 59-84). Springer, 2016.
Aissam Belghiat, Elhilali Kerkouche, Allaoua Chaoui and Mokhtar Beldjehem. “Mobile
Agent-Based Software Systems Modeling Approaches: A Comparative Study”. CIT.
Journal of Computing and Information Technology, 24(2), 149-163. 2016.
Aissam Belghiat, Allaoua Chaoui. “Mapping Mobile Statechart Diagrams to the π-

Calculus using Graph Transformation: An Approach for Modeling, Simulation and
Verification of Mobile Agent-based Software Systems”. International Journal of
Intelligent Information Technologies (IJIIT) 12(4), 2016.
121

Aissam Belghiat

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Aissam Belghiat

Transféré par

Droits d'auteur :

Formats disponibles

Université AbdelHamid Mehri - Constantine2

Faculté Des nouvelles Technologies de l’Information et de la

Soutenu publiquement le : 07/02/2017 devant le jury composé de:

Je voudrais également exprimer toute ma gratitude au Pr. Rachid Echahed (CNRS et

Je tiens à remercier aussi Dr. Mourad Maouche (Université de Philadelphia,

Je tiens à remercier Pr. DjamelEddine Saidouni de m’avoir fait l’honneur d’accepter

Keywords: Mobile UML; π-calculus; modeling; verification.

Mots clés: Mobile UML; π-calcul; modélisation; vérification.

‫كلمات مفتاحية ‪ ;π-calculus ;Mobile UML :‬نمذجة; تحليل‪.‬‬

Table des matières

2.3.4. Notions importantes….…..…………………….....………………….…………. 25

4.3.2.7. Traitement des actions…....……………....……………....……………....……68

Liste des figures

Liste des tableaux

Le paradigme de l'agent mobile est une extension des paradigmes client/serveur et

1.2. Evolution de la mobilité

Nous allons exposer dans cette section l’évolution de la mobilité de la technologie de

FIG. 1.1 – Le paradigme client-serveur [6].

1.2.2. Evaluation a distance

FIG. 1.2 - Le paradigme évaluation a distance [6].

1.2.3. Code à la Demande

FIG. 1.3 – Le paradigme code à la demande [6].

1.2.4. Agent Mobile (Mobile Agent)

FIG. 1.4 – Le paradigme agent mobile [6].

1.3. Systèmes logiciels à base d'agents mobiles

1.3.1. Concepts de base et architecture

Place: représente un emplacement logique, fourni par les plates-formes d’agents, où

Place1 Place1 Place2

FIG. 1.5 - Architecture d’un système logiciel à base d'agents mobiles

1.4. Les propriétés des agents

 Les compétences de communication: la capacité d’établir des relations de

 Notions mentales: la capacité d'acquérir ses propres connaissances comme résultat

 La capacité sociale: la capacité de communiquer et de coopérer avec d'autres agents

 Pro-activité: la capacité de générer des événements dans l'environnement entourant,

 Bienveillance: un agent mobile doté de caractéristiques mentionnées ci-dessus ne doit

1.5. Les plateformes d'agents mobiles

Outil Organisation URL

1.5.3. Domaines d’applications des agents mobiles

1.6. Avantages des agents mobiles

La technologie des agents mobiles fournit plusieurs bénéfices pour surmonter

1.7. Inconvénients des agents mobiles

Aucune technologie n’est sans inconvénients, y compris la technologie des agents

1.8. La communication entre les agents

 Synchronisation. Selon une analyse temporelle, la communication entre les agents

 Destination. Habituellement, quand un agent interagit avec d'autres agents, il suit un

2.2. La modélisation avec UML

La modélisation consiste à la conception d’un modèle. Un modèle est une

2.2.1. Les diagrammes UML

FIG. 2.1 - Classification des types de diagrammes UML (tiré de [60]).

Nom de diagramme Description

Diagramme de classes il représente la description statique de système en intégrant dans

modélisation d’un système.

Diagramme d’objets la représentation des instances des classes constitue l’objectif du

Diagramme de composants il représente les différents constituants logiciels d’un système.

Diagramme de il décrit l’architecture technique d’un système.

Diagramme de structures montre la structure interne d'un classificateur et/ou l'utilisation de

opération ou à un cas d’utilisation.

2.2.2. La méta-modélisation avec UML

 Langage naturel : la sémantique dynamique d’UML est décrite en anglais.

2.2.3. Mécanismes d’extension d’UML

2.3. La spécification avec π-calcul

2.3.1. La mobilité dans le π-calcul

2.3.2. La syntaxe du π-calcul