La génération des diagrammes AUML à partir d'un programme Jade

République Algérienne Démocratique et Populaire

Ministère de l'enseignement supérieur et de la recherche
scientifique

Université Larbi Ben M'hidi OUM el Bouaghi

Faculté des sciences exactes et sciences de la nature

et de la vie

Département de Mathématiques et Informatique

MtMOIRE DE FIN D~tTUDES

En vue de l'obtention du

Diplôme de Master en Informatique
Option : systèmes distribués

Theme :

Reafise par : MECIBAH Zina
Sous fa direction de : Dr. MOKHATI Farid

lur~

: Dr.Gueram et Mr.Gahmous

PROMOTION : JUIN 2012

Nemerciement

j; rends mes_prefondes gratitude's d mon dieu qui m'aide d
readser ce modeste travail

j; remercie mon encadr^. eur .. Dr: .07 1"1 RIDpour

son encadr^. ement; sa comprehension et sa gentillesse 4h/rant
tout le temps de^. ma memoire.

Ales remerciements vont aux memeres dejury qui ont
accepte d^~examiner mon travad^-

taus mes enseegnants sans exception.

De^-a^ricace

Je agdie ce moaeste travallet ma_prefonde^. gratitude^. ..

Trout a^~añora ux de^. ux gramfi héros ae ma vie .. mes tre's
chers _parents MECTR ~ mar et _O/ 0 Fatiña qui ont
toujours été falpour mot qui m'ont Winne unmagnifique
modith de^. caaeur et delpersévérance et qui m'ont ofert sans
condition thur soutien moralet _financier. J'espere qu'i á
trouveront duns ce travailtoute ma reconnaissance et tout
mon amour.

mes tre's ch^.dres _rimers.. .9laiii4 mine_$ Sabrina, Souaa^ret

Ch^.otaia

taus ie^. s memtres de ca_famitie .ECYR Y et a^le ca_famitie

NOV 0 sans exception.

taus mes amens surtout: C IL 7ahima et 2O2 RE

Aracira et d thurs _families.

taus ceux qui sont_proches de^. mon cieur et dbntje nal~as

cite le nom.

touts mes coi*ues a la_promotion 7899:7897.

Generation des diagrammes AllitiC d _partir de _programmes JADE

Sommaire

Sommaire

Introduction générale

Chapitre1 : JADE

Introduction...... ...	... 1
1. JADE (Java Agent Development Framework)	...........2
2. Le langage de communication entre agents FIPA ACL......	3
3. Les protocoles d'interaction dans la norme FIPA...	7
3.1 Le protocole Contract Net...	8
4. L'architecture logicielle de JADE......	......10
5. Les agents JADE...	... 11
5.1 Le cycle de vie d'un agent JADE... ...	12
5.2 La communication entre les agents JADE...	... 14
5.3 Les comportements « Behaviours » en JADE	......16
5.4 Le service page jaune « DF »	...21
5.5 Les agents techniques dans JADE « Outils de débogage »	...22
6. les domaines d'utilisation de JADE......	.........26
Conclusion... ... ...	........... 26
Chapitre2 : AUML
Introduction...... .............	.....27
1. Brève description d'AUML	...........27		2. Les différents niveaux d'AUML
...28	3. Les diagrammes AUML... ...
.........32
3.1. Le diagramme de classe AUML...	........ 33
3.2. Le diagramme de séquence AUML ..........	35
Conclusion ... ...	.............45

Generation des diagrammes AllitiC d _partir de _programmes JADE

Sommaire

Chapitre3 : Approche proposée et présentation de l'outil
développé

Introduction...... ... ...46

1. L'approche proposée 46

1.1. Translation du programme JADE vers le diagramme de classe AUML 47

1.2. Translation de programme JADE vers le diagramme de séquence AUML 48

1.3. La génération du fichier XML correspond aux diagrammes générés... 48

2. Les règles de transformation .....49
2.1. Génération de diagramme de classe AUML à partir de programme JADE..49 2.2. Génération de diagramme de séquence AUML à partir de programme

JADE... ... ... ...50

2.3. Diagrammes AUML vers document XML 54

3. Présentation de l'outil développée 55

4. Etude de cas... .......... ...56

Conclusion... ... ... 76

Conclusion et perspectives

Generation des diagrammes Atilt/LL d _partir de _programmes JADE

La liste des figures

Liste des figures

Chapitre1 : JADE

ü Figure 1.1 : les conteneurs dans JADE ... ü Figure 1.2 : Etapes du protocole réseau contractuel ü Figure 1.3 : le protocole FIPA-Contract-net ...		......3 ....9 ...........9	ü Figure 1.4 : Architecture logicielle de la plate-forme JADE ...
10		ü Figure 1.5 : Le cycle de vie d'un agent JADE ...
13		ü Figure 1.6 : Le graphe d'héritage de la classe Behaviour.
... ........17		ü Figure 1.7 : L'agent RMA
..............22		ü Figure 1.8 : L'agent Dammy... ...
... ............23		ü Figure 1.9 : L'agent DF...
..............24		ü Figure 1.10 : L'agent Sniffer
.......25

ü Figure 1.11 : L'agent Introspector... ... ...25
Chapitre2 : AUML

ü Figure2.1 : la notation du package en AUML .....29

ü Figure2.2 : les paramètres du package AUML ...29

ü Figure2.3 : notation du package AUML avec des informations supplémentaires... ......30

ü Figure2.4 : la notation du Template en AUML... 30

ü Figure2.5 : Exemple d'un protocole d'interaction générique... ....31

ü Figure2.6 : deuxième notation du Template AUML... ...31

ü Figure2.7 : un protocole d'interaction spécifié avec plus de détails, a l'aide d'un ensemble de diagramme ...... ... 32

ü Figure2.8 : exemple de diagramme de class AUML... ... 33

ü Figure2.9 : exemple de diagramme de class AUML avec la représentation des capacités ... ... ..........34

ü Figure2.10 : exemple de diagramme de class AUML avec la représentation des services ... ... ... ...35

ü Figure2.11 : les différents branchements en AUML... 36

Generation des diagrammes Atilt/LL d _partir de _programmes JADE

La liste des figures

ü Figure2.12 : des techniques pour exprimer les communications concurrentes avec un agent jouant des rôles différents, ou recevant des CAs

différents ... ... ..........37

ü Figure2.13 : format de base pour la communication... 38

ü Figure2.14 : la notation de la ligne de vie en AUML ...... ....39

ü Figure2.15 : exemple d'échange de message dans AUML... 40

ü Figure2.16 : Notation des messages synchrones et asynchrones ........41

ü Figure2.17 : la notation de la contrainte de temps en AUML .........42

ü Figure2.18 : la notation de la contrainte du temps alternative en AUML.............42

ü Figure2.19 : Notation des boucles sur la même ligne de vie... ... ....43

ü Figure2.20 : restreindre le nombre de destination en AUML... ........44

ü Figure2.21 : exemple de protocole d'interaction...... ..........45

Chapitre3 : L'approche proposée et description de l'outil
développé

ü Figure 3.1 : l'approche proposée... ..........47

ü Figure 3.2 : la classe Agent_with_role... ... ... 49

ü Figure 3.3 : Equivalence entre un classe d'agent JADE et une class dans le diagramme de class AUML ... ........50

ü Figure 3.4 : la class ACLMessage_with_role... ...51

ü Figure 3.5 : l'interface de l'outil développée... 56

ü Figure 3.6 : capture écran pour le diagramme de class généré... ... 63

ü Figure3.7 : vue étendue de diagramme de classe généré ...64

ü Figure 3.8 : lignes de vies des différents agents 65

ü Figure 3.9 : diagramme de séquence AUML généré par outil... ........66

Generation des diagrammes Atilt/LL d _partir de _programmes JADE

La liste des tables

Liste des tables

Chapitre1 : JADE

ü Tab 1.1 : actes de communication du modèle FIPA ACL ... 5

ü Tab 1.2 : les champs d'un message ACL en JADE... 15

Chapitre2 : AUML

ü Tab 2.1 : les différents formats possible pour l'étiquette du label de la ligne de vie du diagramme de séquence AUML ... 39

Chapitre3 : Approche proposée et présentation de l'outil
développé

ü Tab 3.1 : l'équivalence entre les différents branchements qui existent dans le diagramme de séquence AUML et le programme JADE ... ........53

Resume

Une nouveCCe approche de generation de diagrammes AU.ML à partir du code JADE est proposee dans ce memoire. En effet, cette approche se pCace dans Ce conte xte de retro-ingenierie des S.MA et vise comme objectif d^%aider Ces utiCisateurs qui ne sont pas hien famiCiarises avec Ca pCateforme JADE de comprendre Ces appCications deveCoppees sur JADE. Notre approche est supportee par un outiC visueC et interactif que nous avions deveCoppe dans C%environnement ECLIPSE. Cet outiCpermet d%anaCyser dans un premier temps C%appCication JADE avant d%en generer deux diagrammes AU.ML: diagramme de cCasse et diagramme de sequence. Le premier est utiCise pour capturer Ces aspects statiques de C^%appCication tandis que Ce deuxieme est utiCise pour decrire Ce comportement coCCectif des agents impCiques dans C^%interaction. Notre outiCpermet egaCement de generer une description formeCCe ecrite en X.ML offrant une description standardpouvant etre utiCisee par Ca pCus part des outiCs de modeCisation agent.

Génération d~s diagrammes AlliviL dpartir d~ programmes JADE

Introduction généra

Introduction générale

1. Cadre et motivations

Le domaine des SMA «Systèmes Multi Agents» est relativement jeune. Malgré que ses prémices remontent à l'IA «Intelligence Artificielle», les SMA n'ont vraiment été étudiés qu'a partir des années 80 [Mic05] mais prennent actuellement toute leur ampleur.

Le SMA peut être vue selon FERBER & GHALLAB (1988) comme une communauté d'agents autonomes travaillant en commun, selon des modes parfois complexes de coopération, coordination, concurrence, pour aboutir à un objectif global comme par exemple : la résolution d'un problème, l'établissement d'un diagnostic ...etc. [Mou00]. Il touche une grande variété de domaines d'applications tels que : les systèmes multi-experts d'aide à la décision ; l'enseignement intelligent assisté par ordinateur ; la gestion des activités de production ; l'imagerie médicale ; les travaux urbains ; la télémédecine ; la simulation du comportement des fourmis et l'étude de l'émergence des structures ; l'interprétation des images satellitaires ; la traduction automatique ; la robotique...etc. [Mou00]. Donc, le contexte actuel nous amène à penser que l'utilisation des SMA va suivre une croissance importante dans les années qui suivent. Il est alors nécessaire d'avoir des outils pour développer facilement des SMA fonctionnels et compétents. Ainsi que créé des langages de modélisation, de programmation, ou des spécifications plus générales sur les interactions entre agents [Mic05]. Pour cela de nombreux efforts ont été donnés par la FIPA (Foundation for Intelligent Physical Agents) pour créer des standards dans ce domaine.

Dans ce mémoire, nous proposons une nouvelle approche de génération de diagrammes AUML à partir du code JADE. En effet, cette approche se place dans le contexte de rétroingénierie des SMA et vise comme objectif d'aider les utilisateurs qui ne sont pas bien familiarisés avec la plateforme JADE de comprendre les applications développées sur JADE. Notre approche est supportée par un outil visuel et interactif que nous avions développé dans l'environnement ECLIPSE. Cet outil permet d'analyser dans un premier temps l'application JADE avant d'en générer deux diagrammes AUML: diagramme de classe et diagramme de séquence. Le premier est utilisé pour capturer les aspects statiques de l'application tandis que le deuxième est utilisé pour décrire le comportement collectif des agents impliqués dans

Generation d~s diagrammes AlliviL dpartir d~ programmes JADE

Introduction generate

l'interaction. Notre outil permet également de générer une description formelle écrite en XML offrant une description standard pouvant être utilisée par la plus part des outils de modélisation agent.

2. Organisation du mémoire

Ce mémoire est organisé en trois chapitres :

ü Le premier chapitre présente la plate forme multi agent JADE, nous allons présenter des notions de base sur la FIPA, l'architecture logicielle du JADE, les agents JADE et enfin les domaines d'utilisation de cette plate forme.

ü Le deuxième chapitre présente le formalisme Agent UML.

ü Finalement, le dernier chapitre est consacré à la présentation de notre approche ainsi que la description de l'outil développée.

Chapitre -01-

La plate forme multi agents

JADE

Dans ce chapitre

Introduction.

1. JADE (Java Agent Development Framework).

2. Le langage de communication entre agents FIPA ACL.

3. Les protocoles d'interaction dans la norme FIPA. 3.1 Le protocole Contract Net.

4. L'architecture logicielle de JADE.

5. Les agents JADE.

5.1 Le cycle de vie d'un agent JADE.

5.2 La communication entre les agents JADE.

5.3 Les comportements « Behaviours » en JADE.

5.4 Le service page jaune « DF ».

5.5 Les agents techniques dans JADE « Outils de débogage ».

6. les domaines d'utilisation de JADE.

Conclusion.

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

Introduction

Les SMA sont conçus et implantés idéalement comme un ensemble d'agents interagissant selon les modes de coopération, de concurrence ou de coexistence. Ces agents peuvent être des agents réactifs, des agents cognitifs ou bien des agents hybrides, suivant leur rôle. La résolution d'un problème par un SMA permet dans un premier temps, de n'affecter à chaque agent qu'une partie du problème complexe à résoudre et dans un second temps, de transformer des contraintes globales en contraintes locales qui sont résolues par coordination entre les agents.

Pour construire un SMA il est préférable d'utiliser une plate-forme multi-agent qui offre un ensemble d'outils utilisé pour la construction et la mise en service d'agents au sein d'un environnement spécifique. Les outils peuvent être utilisés pour analyser les SMA, créer les SMA ou bien tester les SMA. Ces outils peuvent être sous la forme d'environnement de programmation (API) et d'applications permettant d'aider le développeur à la programmation d'un SMA ainsi que son débogage. Il existe de nombreuses plates-formes pour le développement de SMA : JACK, Jadex, Madkit, JADE...etc.

Nous avons opté dans le cadre de notre travail pour la plateforme JADE (Java Agent DEvelopment framework) pour les avantages qu'elle procure et qui nous allons la présenter en détail dans le reste de ce chapitre.

Chapitre i : La plate forme multi agents JADE

1. JADE (Java Agent Development Framework)

JADE (Java Agent Development Framework) est une plateforme multi agents répartie (multi-hôtes) développé par F.Bellifemine & A. Poggy, G. Rimassa, P. Turci par la société Telecom Italia Lab « Tilab, anciennement CSELT » en 1999 [Lot05]. JADE a comme but :

ü simplifier la construction des systèmes multi-agents « SMA » interopérables.

ü l'exécution des SMA.

ü la réalisation d'applications conformes avec le standard FIPA (FIPA, 1997) pour faciliter la communication des agents JADE avec des agents non JADE.

ü essayer d'optimiser les performances d'un système d'agent distribué.

JADE développée en Java, fonctionne sous tous les systèmes d'exploitation [5] , inclut tous les composants obligatoires qui contrôlent un SMA [Oli02], et possède une architecture très précise permettant la construction dite « normalisée » d'agents [9]. Pour tout cela la plateforme JADE contient :

1. Un runtime Environment : l'environnement où les agents peuvent vivre. Il doit être activé pour pouvoir lancer les agents.

2. Une librairie de classes : que les développeurs utilisent pour écrire leurs agents.

3. Une suite d'outils graphiques: qui facilitent le débogage, la gestion et la supervision de la plateforme des agents.

JADE fournit aussi des classes qui implémentent JESS pour la définition du comportement des agents [Fer05]: JESS (outil de raisonnement à base de règles) est le moteur qui exécute tout le raisonnement nécessaire. On a donc la possibilité de créer des agents JADE intelligents en délégant le raisonnement à d'autres outils [Oli02].

Chaque instance du JADE est appelée conteneur « container en anglais », qui peut contenir plusieurs agents. Ainsi qu'un ensemble de conteneurs constituent une plateforme et chaque plateforme doit contenir un conteneur spécial appelé main-container et tous les autres conteneurs s'enregistrent auprès de celui-là dès leur lancement.

Un main-container se distingue des autres conteneurs car il contient toujours deux agents spéciaux appelés AMS et DF qui se lancent automatiquement au lancement du main-container. Ainsi on a un conteneur par machine et lorsque l'on lance un conteneur :

ü soit il est seul, il devient alors le conteneur principal (main container)

ü soit on lui indique l'adresse du conteneur principal [10].

Chapitre i : La plate forme multi agents JADE

Figure 1.1 : les conteneurs dans JADE [You09]

2. Le langage de communication entre agents FIPA ACL

La communication entre les agents permet de lier un ensemble d'agents et permet d'augmenter les capacités perceptives des agents en leur permettant de bénéficier des informations et du savoir-faire des autres agents. Sans communication, un agent n'est qu'un individu isolé, sourd et muet qui ne fait qu'agir sur lui-même. La communication donc s'appuie sur des langages de communication standard.

FIPA ACL «FIPA Agent Communication Language » est l'un des langages de communication entre les agents crée par FIPA dont la spécification consiste en un ensemble de types de message («actes de communication ») et en un ensemble de protocoles d'interaction de haut niveau. Cependant, FIPA ACL est indépendant de la langue et le contenu est conçu pour fonctionner avec n'importe quel contenu de la langue et avec toutes les approches de spécification de l'ontologie.

Le but de la FIPA ACL est d'interagir entre les agents quelque soit le protocole qu'ils utilisent. Pour que les agents puissent supporter/utiliser un nouveau protocole, il suffit d'implémenter une nouvelle interface. Cependant, Dans FIPA ACL, la communication des agents est basée sur l'envoi de messages.

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

Les actes de communications en FIPA ACL : La FIPA défini la notion de l'acte de communication « communication act » comme une classe spéciale d'actions qui correspondent aux blocs les plus simples de dialogue entre les agents. Un acte de communication possède une signification bien définie, déclarative, indépendante du contenu d'un autre acte. L'idée de base des actes de communication est la théorie des actes de discours «speech act» proposée par Searle [3]. Les actes de communication sont accomplis à travers l'envoi de messages d'un agent à un autre en utilisant les spécifications établies par la FIPA. Un message FIPA ACL contient un ensemble de paramètres. Le seul paramètre obligatoire est la « performative » (c'est-à-dire, l'acte de communication). Néanmoins, la plupart des messages doivent contenir des paramètres tels que l'expéditeur, le destinataire et le contenu.

Actions	Syntaxe		Définition - Sens	Accept Proposal
accept- proposal	Communication de l'accord de l'expéditeur d'effectuer une action qui lui a été préalablement soumise.		Agree
agree	Communication de l'accord de l'expéditeur pour effectuer une action, sans doute dans le futur.		Cancel
cancel	Communication de l'annulation de l'accord donnée préalablement par l'expéditeur pour effectuer une action.		Call for Proposal
cfp	Communication par l'expéditeur d'une demande d'effectuer une certaine action.		Confirm
confirm	Communication par l'expéditeur de la confirmation de la validité (selon les règles de l'agent) de la proposition préalablement reçue.		Disconfirm
disconfirm	Communication par l'expéditeur de la confirmation de la non validité (selon les règles de l'agent) de la proposition préalablement reçue.		Failure
failure	Communication par l'expéditeur de l'échec d'une action essayée.		Inform
inform	Communication par l'expéditeur d'une proposition, pensée vrai par celui-ci.		Inform If
inform-if	Communication par l'expéditeur d'une proposition (pensée vrai par celui-ci), et demande au receveur une confirmation ou une non-confirmation. Macro-action impliquant l'usage de "request".

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

Inform Ref	inform-ref		Communication par l'expéditeur d'une demande de l'objet qui correspond à une description envoyée. Macro-action impliquant l'usage de "request".	Not Understood
not- understood	Communication par l'expéditeur d'un non compréhension d'une action effectuée par le destinataire.		Propagate
propagate	Communication par l'expéditeur d'un message à propager à des agents dont la description est fournie. Le destinataire du message traite le sous-message à propager comme s'il lui était directement destiné et envoie le message "propagate" à l'agent qu'il a identifié		Propose
propose	Communication par l'expéditeur d'une proposition d'action conditionnée à certaines préconditions données.		Proxy
proxy	Communication par l'expéditeur d'une demande d'une transmission d'un message à des agents dont la description est donnée.		Query Ref
query-ref	Communication par l'expéditeur d'une demande par l'expéditeur de l'objet référencé par une expression.		Refuse
refuse	Communication par l'expéditeur de son refus d'effectuer une action donnée, et en donne les raisons.		Reject Proposal
reject- proposal	Communication, pendant une négociation, par l'expéditeur de son refus d'effectuer des actions.		Request
request	Communication par l'expéditeur d'une demande au destinataire d'effectuer une action.		Request When
request- when	Communication par l'expéditeur d'une demande, au destinataire, d'effectuer une action quand une proposition donnée devient vrai.		Request Whenever
request- whenever	Communication par l'expéditeur d'une demande, au destinataire, d'effectuer une action dès qu'une proposition done devient vrai, et à chaque fois que celle-ci redevient vrai.		Subscribe
subscribe	Communication par l'expéditeur d'une demande d'un objet donnée par une référence envoyé par l'expéditeur, et de renotifier l'agent ayant souscrit dès que l'objet en question change.

Tab 1.1 : actes de communication du modèle FIPA ACL [Oli04]

Chapitre i : La plate forme multi agents JADE

·:* Structure des messages FIPA ACL:

1. Structure des messages de communication simple (non macro-action) : Le message minimum type du FIPA ACL contient tout d'abord [Oli04]:

ü le type du message envoyé = syntaxe de ce message.

ü l'expéditeur du message.

ü le destinataire du message.

ü le contenu du message

Cependant, ces messages minimums ne suffisent pas toujours pour communiquer [Oli04]: on peut avoir besoin, pour la compréhension du message et pour la rapidité de celle-ci ainsi que la rapidité de traitement du message, d'indiquer d'autres informations telles que:

ü le langage utilisé dans le contenu du message ("language ...").

ü le protocole utilisé.

ü l'ontologie auquel le message se rattache ("ontology ...").

ü la référence d'un message antérieur auquel le message actuel se rattache ("inreply-to ..."), ou la référence d'un message ultérieur attendu en retour ("reply-with...").

ü la référence de la conversation.

Exemple : L'agent A veut informer l'agent B du temps qu'il fera demain, selon ses prévisions[Oli04]:

(inform

: sender (agent-identifier: name_A)

:receiver (set (agent-identifier : name_B))

:content "weather (tomorrow, raining)"

:language Prolog)

2. Structure des messages de communication de macro-action: La structure des messages de communication de macro-action est différente vu qu'elle utilise la structure de l'action de communication simple "inform". Cependant, le contenu du message est différent [Oli04]: il donne le nom de l'agent pour lequel il attend une action, ainsi qu'un autre message où est contenue la demande.

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

Exemple [Oli04]: (request

:sender (agent-identifier : name A)

:receiver (set (agent-identifier : name B))

:content

"( (action (agent-identifier :name B) (inform-if: sender (agent-identifier :name B) :receiver (set (agent-identifier :name A))

:content \"in( lannion, normandy)\"

:language Prolog)) )"

:language fipa-sl)

3. Les protocoles d'interaction dans la norme FIPA

Un protocole d'interaction est définit comme un ensemble de règles qui guident l'interaction entre plusieurs agents. Donc l'utilisation de protocole permet d'arriver plus vite à la solution car les agents connaissent quels sont les messages qu'ils peuvent recevoir pour un état donné de l'interaction, quels sont les messages qu'ils peuvent envoyer et quelles sont les règles qui guident le choix lorsqu'il y a indéterminisme entre plusieurs messages possibles. Les agents convergent plus vite vers la solution.

Pour un état donné du protocole d'interaction : il existe un nombre fini de messages admis en émission ou réception. Si un agent accepte d'utiliser un protocole, il accepte de se conformer à ce protocole et respecter les règles (syntaxique, sémantique). De plus, il approuve la sémantique du protocole.

Parmi les notions fondamentales qui caractérisent un protocole d'interaction [Tar06]:

ü un protocole d'interaction est un pattern d'interaction. Donc il est nécessaire de le représenter d'une manière générique, indépendamment du contexte d'application.

ü chaque protocole d'interaction a un but.

ü un protocole d'interaction fait intervenir deux ou plusieurs agents. Chaque agent joue un rôle qui permet de l'identifier au cours de l'interaction.

Chapitre i : La plate forme multi agents JADE

ü Un protocole d'interaction définit les règles d'ordonnancement des messages et les actions auxquelles le protocole fait appel. Ces règles permettent de régir une interaction.

Une partie des protocoles d'interaction fournis par FIPA est énumérée ici [11]:

ü FIPA-Request.

ü FIPA-Querry.

ü FIPA-Contract-Net.

ü FIPA-Request-When.

ü FIPA-Iterated-Contract-Net.

ü FIPA-Auction-English.

ü FIPA-Auction-Dutch.

ü FIPA-Brokering.

ü FIPA-Recruiting.

ü FIPA-Subscribe.

ü FIPA-Propose.

Nous détaillons dans ce qui suit le protocole FIPA-Contract-Net.

3.1. Le protocole Contract Net

Le protocole réseau contractuel ("Contract Net" en anglais) est utilisé dans les SMA pour résoudre le problème d'allocation des tâches (Davis et Smith, 1983). Les agents coordonnent leurs activités grâce à l'établissement de contrats afin d'atteindre des buts spécifiques.

Les agents peuvent prendre deux rôles: Gestionnaire ou Contractant.

Le gestionnaire commence par décomposer la tâche en plusieurs sous-tâches et annonce chaque sous-tâche sur un réseau d'agents (les contractants). Les agents qui reçoivent une annonce de tâches à accomplir évaluent l'annonce. Les agents qui ont les ressources appropriées, l'expertise ou l'information requise pour accomplir la tâche, envoient au gestionnaire des soumissions ("bids" en anglais) qui indiquent leurs capacités à réaliser la tâche. Le gestionnaire rassemble toutes les propositions qu'il a reçues et alloue la tâche à

Chapitre i : La plate forme multi agents JADE

l'agent qui a fait la meilleure proposition. Ensuite, le gestionnaire et les contractants échangent les informations nécessaires durant l'accomplissement des tâches.

Figure 1.2: Etapes du protocole réseau contractuel [14]

L'avantage de ce protocole est que les rôles des agents ne sont pas spécifiés d'avance. Donc n'importe quel agent peut agir comme un gestionnaire ou bien comme un contractant. Cette flexibilité permet de nouvelles décompositions des tâches: un contractant pour une tâche spécifique peut agir comme un gestionnaire en décomposant sa tâche et en annonçant les sous-tâches à d'autres agents. Cependant, Un problème qui peut survenir avec le réseau contractuel est qu'une tâche puisse être attribuée à un contractant moins qualifié pour la résoudre si un contractant plus qualifié est occupé au moment de l'annonce des tâches.

Figure 1.3 : le protocole FIPA-Contract-net [4]

Generation des diagrammes AlliviL d _partir de _programmes JADE

Cha_pitre 1 : La _plate forme multi agents JADE

4. L'architecture logicielle de JADE

JADE fournit une couche homogène qui cache complètement la complexité et la diversité du réseau des agents et possède une architecture très précise permettant la construction dite « normalisée » d'agents (reprend l'architecture de l'Agent Management

) [Fer05] et

Reference Model proposé par FIPA inclut tous les composants obligatoires qui

contrôlent un SMA. Ces composants sont l'AMS, le DF et MTS.

Figure 1.4 : Architecture logicielle de la plate-forme JADE [Fer05]

1. AMS « Agent Management System » : dans JADE, il y a une méthode fournie par la classe Agent permet d'obtenir l'identifiant de l'agent AMS : getAMS().

2. DF « Directory Facilitator » : dans JADE, On a un DF par défaut dans le conteneur principal et pour obtenir l'identifiant de l'agent DF, la classe Agent fournie la méthode : getDefaultDF() .

Dans JADE, il faut utiliser le jade.domain.DFService pour chercher et/ou publier des services dans un DF [10] . Cependant, l e service DF propose quatre méthodes afin de pouvoir :

ü Enregistrer un agent dans les pages jaunes (register). « il est recommandé de faire le registre dans setup » [Fer05].

ü Supprimer un agent des pages jaunes (deregister) [Fer05]. « il est recommandé de faire le deregister dans takeDown» [Oli04].

ü Modifier le nom d'un service fourni par un agent (modify) [Fer05].

Chapitre i : La plate forme multi agents JADE

ü Rechercher un service (search) [Fer05].

Donc les deux agents DF et AMS permettent de maintenir une liste des services et des adresses de tous les autres agents de la plate-forme.

3. MTS: MTS est un service permet la communication entre plusieurs plates-formes mais MTS sera chargé à la demande pour ne conserver par défaut que les fonctionnalités utiles à tout type d'utilisation [Fer05].

La plate-forme multi agent JADE peut être distribué sur plusieurs machine « les machines pas nécessairement possèdent le même système d'exploitation » et les configurations peuvent être modifié au démarrage des agents en les déplaçant d'une machine à une autre, ce qui permet une très grande portabilité des agents [9].

5. Les agents JADE

De point de vue de la programmation concurrente, un agent est un objet actif, ayant un thread de contrôle. Ainsi que JADE utilise un modèle de programmation concurrente "un thread-par-agent" au lieu d'un modèle "un thread-par-comportement" pour éviter une augmentation du nombre de threads d'exécution exigés sur la plate-forme d'agents.

L'agent Jade est conforme au standard FIPA 2002 et il possède toujours un état (APACTIVE, AP-DELETED...).

Dans JADE : Tout est objet : un agent est constitué de plusieurs classes, dont certaines

clefs :

ü Tout agent hérite de la classe : jade.core.Agent. « La classe Agent représente une super-classe commune pour tous les agents définis par l'utilisateur ».

ü L'identifiant d'un agent est une instance de la classe : jade.core.AID.

Les agents JADE sont actifs (ils peuvent dire Non et ils sont faiblement couplés), communiquent et interagissent avec les autres agents grâce à des messages et rend des services.

D'un point de vue plus technique, Jade est orienté vers une programmation concurrente où chaque agent est en « compétition ». Les concepteurs de Jade ont ainsi fait le choix de créer un thread (code parallelisable) par agent plutôt qu'un thread par comportement. Néanmoins, via le planificateur de tâches, un comportement peut se bloquer lui même pour éviter de gaspiller du CPU (Ex : pendant qu'il attend des messages).

Un agent se défini en étendant la classe jade.core.Agent :

Generation des diagrammes AlliviL d _partir de _programmes JADE

Cha_pitre i : La _plate forme multi agents JADE

import jade.core.agent;

public class monAgent extends Agent;

Chaque agent est identifié par un AID qui est récupérable via la méthode getAID(). Enfin pour personnaliser l'agent, il est obligatoire dans la méthode setup():

ü Enregistrer les langages de contenu.

ü Enregistrer les Ontologies.

ü Enregistrer les Services auprès du DF.

ü Démarrer les Comportements (behaviors).

Le nom d'un agent est défini sous la forme : <nom-agent>@<nom-plate-forme> et il doit être globalement unique (sur toutes les plateformes).

Les principales méthodes de la classe agent sont les suivantes :

ü getArguments() : pour obtenir les arguments d'un agent.

ü doDelete() : pour tuer un agent.

ü takeDown() : appelée quand un agent meurt .

Exemple d'agent JADE:

package firstAgent; import jade.core.Agent;

/** This example shows a minimal agent that just prints "Hello World!" and then terminates. */

public class HelloWorldAgent extends Agent {

protected void setup()

{

System.out.println("Hello World! My name is "+getLocalName()); // Make this agent terminate

doDelete();

}

}

5. 1. Le cycle de vie d'un agent JADE

Un agent JADE peut être dans l'une des différents états de son cycle de vie définis par les spécifications FIPA. Ces états sont représentés par des constantes dans la classe Agent qui figure dans les packages fournis avec la plateforme JADE :

Generation des diagrammes AllitiL d _partir de _programmes JADE

Cha_pitre i : La _plate forme multi agents JADE

Figure 1.5: Le cycle de vie d'un agent JADE [4]

ü AP INITIATED : l'objet Agent est construit, mais il n'est pas encore enregistré dans _

l'AMS, il ne possède ni un identificateur ni une adresse et ne peut pas communiquer avec d'autres agents.

ü AP_ACTIVE : l'objet Agent est enregistré avec l'AMS, il possède un nom correct et peut accéder à toutes les caractéristiques du JADE.

ü AP_SUSPENDED : l'objet Agent est actuellement stoppé. Son thread interne est suspendu et aucun comportement ne peut s'exécuter.

ü AP WAITING : l'objet Agent est bloqué. Son thread interne est en sommeil. Il peut se _

réveiller quand une condition est vérifiée (typiquement quand un message arrive).

ü AP_DELETED : l'exécution du thread interne de l'agent est terminée. L'agent n'est plus enregistré avec l'AMS.

ü AP_TRANSIT : un agent mobile entre dans cet état quand il migre à un nouvel emplacement. Le système continue à mémoriser les messages afin de les lui envoyer au nouvel emplacement.

ü AP COPY : cet état est utilisé intérieurement par le JADE pour cloner un agent. _

ü AP_GONE : cet état est utilisé intérieurement par le JADE quand un agent mobile a migré vers un nouvel emplacement et a pris un état stable.

La classe Agent fournit avec JADE possède des méthodes publiques qui permettent de changer l'état d'un objet Agent. Par exemple, la méthode doWait () permet de passer un agent de l'état AP_ACTIVE à l'état AP_WAITING.

Generation des diagrammes A11.7v1L d _partir de _programmes JADE

Cha_pitre 1 : La _plate forme multi agents JADE

5. 2. La communication entre les agents JADE

Pour parler d'un véritable système multi-agents et non pas d'un ensemble d'agents agissant d'une manière individuelle, il est nécessaire de voir comment les agents communiquent et s'échangent les messages.

Chaque agent JADE possède une sorte de boite aux lettres sous forme d'une liste qui contient les messages « conformes aux spécifications de la FIPA (FIPA-ACL)» qui lui sont envoyés par les autres agents selon l'ordre chronologique de leur arrivée.

La classe ACLMessage du package jade.lang.acl de JADE représente les messages qui peuvent être échangés par les agents. Cependant, les informations nécessaires pour envoyer un message JADE sont: l'ensemble des récepteurs du message, le contenu du message et l'acte de communication. Cependant, La communication de messages se fait en mode asynchrone.

Lorsqu'un agent souhaite envoyer un message, il doit créer un nouvel objet ACLMessage, compléter ces champs avec des valeurs appropriées et enfin appeler la méthode send() et lorsqu'un agent souhaite recevoir un message « La réception d'un message JADE est aussi simple que l'envoi » il suffit d'appeler la méthode reveive() ou la méthode blockingReceive() de la classe Agent pour récupérer le première message non encore lu de l'agent. Cependant, Tous les attributs de la classe ACLMessage peuvent être obtenus et modifiés par les méthodes set/get (). Le contenu des messages peut être aussi bien du texte que des objets car la sérialisation Java est supportée [Fer05].

Les messages JADE sont composés en général de :

ü L'émetteur du message : un champ rempli automatiquement lors de l'envoi d'un message.

ü L'ensemble des récepteurs du message : un message peut être envoyé à plusieurs agents simultanément.

ü L'acte de communication : qui représente le but de l'envoi du message en cours (informer l'agent récepteur, appel d'offre, réponse à une requête,...)

ü Le contenu du message.

ü Un ensemble de champs facultatifs : la langue utilisée, l'ontologie, le timeOut,

l'adresse de réponse...

Exemple d'envoi de message dans JADE [Ben09] ACLMessage message = new ACLMessage

(ACLMessage.« nom_de_acte_de_communication »); message.addReceiver(«nom_du_recepteur » );

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

message.setContent(«contenu_du_message ») ;

send (message);

Exemple de réception de message dans JADE [Ben09] ACLMessagemessageRecu = receive();

Un message ACL dispose obligatoirement des champs suivants :

Performative		type de l'acte de communication	Sender
expéditeur du message		Receiver
destinataire du message		reply-to
participant de la communication		content
contenu du message		language
description du contenu		encoding
description du contenu		ontology
description du contenu		protocol
contrôle de la communication		conversation-id
contrôle de la communication		reply-with
contrôle de la communication		in-reply-to
contrôle de la communication		reply-by
contrôle de la communication

Tab 1.2 : les champs d'un message ACL en JADE [Fer05]

Remarque

ü C'est très souvent le Behaviour qui crée le message, mais il délègue à l'agent l'envoi (Agent.send()), et la réception (Agent.receive()).

ü l'une des forces de la POA par rapport à la POO, est l'aptitude d'un agent à refuser de considérer, de traiter des messages. Dans Jade cela se fait au moyen d'une instance de la classe jade.lang.acl.TemplateMessage que l'on passe en paramètre à la méthode Agent.receive().

ü Il n'y a pas de dépendance temporelle entre les agents communicants.

ü L'émetteur et le récepteur peuvent ne pas être joignables en même temps.

ü Le récepteur peut même ne pas exister ou ne pas être directement connu de l'émetteur, par exemple: « tous les agents intéressés par la musique » comme destination [Zac09].

ü la Communication est Peer-to-Peer [5].

Chapitre i : La plate forme multi agents JADE

5. 3. Les comportements « Behaviours » en JADE

L'une des propriétés importante d'un agent est son autonomie : un agent ne doit pas se limiter à réagir aux événements externes, mais il doit être aussi capable de prendre l'initiative de nouveaux actes communicatifs d'une façon autonome et doit être capable de gérer plusieurs tâches de manière concurrente en réponse à différents évènements extérieurs. Afin de rendre efficace cette gestion chaque agent de JADE est composé d'un seul thread et non un thread par comportement. Cela signifié qu'un agent exécute un Behaviour à la fois mais l'agent peut exécuter plusieurs Behaviours simultanément en choisissant un bon mécanisme de passation d'un Behaviour à un autre (c'est à la charge du programmeur et non pas à la charge du JADE) [BYo09].

Un agent JADE utilise l'abstraction Comportement pour modéliser les tâches qu'un agent peut exécuter et les agents instancient leurs comportements selon leurs besoins et leurs capacités. Cependant, Les comportement d'un agents JADE sont des instances de la classe jade.core.behaviours et pour qu'un agent exécute une tâche on doit le lui attribuer par la méthode addBehaviour(Behaviour b) de la classe jade.core.Agent. Donc un comportement d'un agent est la conséquence:

ü De ses observations de l'environnement.

ü De ses connaissances.

ü De ses interactions avec les autres agents.

Pour implémenter un comportement, le développeur doit définir un ou plusieurs objets de la classe Behaviour, les instancier et les ajouter à la file des tâches de l'agent. Il est à noter qu'il est possible d'ajouter des comportements et sous-comportements à un agent ailleurs que dans la méthode setup ().

Tout objet de type Behaviour dispose :

1. d'une méthode action () (qui constitue le traitement à effectuer par celui-ci)

2. d'une méthode done() (qui vérifie si le traitement est terminé).

Il existe également quelques méthodes supplémentaires afin de gérer les objets Behaviour:

1. reset () qui permet de réinitialiser le comportement;

2. onStart () qui définit des opérations à effectuer avant d'exécuter la méthode action();

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

3. onEnd () qui finalise l'exécution de l'objet Behaviour avant qu'il ne soit retiré de la liste des comportements de l'agent;

Il y a deux méthodes qui sont héritées pour gérer la file de comportements d'agents : addBehaviour(Behaviour) et removeBehaviour(Behaviour).

Les comportements d'un agent JADE sont stockés dans une File (FIFO) avec remise :

1. Prendre un comportement.

2. exécuter la méthode action () : non interrompue (pas Thread) « atomique » donc il est alors nécessaire de prendre certaines précautions lors de l'implémentation de cette méthode, à savoir éviter des boucles infinies ou des opérations trop longues. La façon la plus classique de programmer un comportement consiste à le décrire comme une machine à états finis. L'état courant de l'agent étant conservé dans des variables locales.

3. Tester done : si la méthode done() retourne true donc retirer le comportement de la file sinon remet à la fin du file.

La plate-forme JADE fournit sous forme de classes un ensemble de comportements ainsi que des sous-comportements prêt à l'emploi. Elle peut les exécuter selon un schéma prédéfini.

Figure 1.6 : le graphe d'héritage de la classe Behaviour [Loï02]

1. Les Behaviours simples : La plate-forme JADE offre trois types de Behaviours simple:

1.1.One-shotBehaviour : Un one-shotBehaviour est une instance de la classe

jade.core.behaviours.OneShotBehaviour. Il a la particularité d'exécuter sa tâche

une et une seule fois puis il se termine. La classe OneShotBehaviour implémente

la méthode done()et elle retourne toujours true.

Chapitre i : La plate forme multi agents JADE

1.2.CyclicBehaviour : Un cyclic Behaviour est une instance de la classe jade.core.behaviours.CyclicBehaviour. Il a la particularité d'exécute sa tâche d'une manière répétitive. La classe CyclicBehaviour implémente la méthode done()qui retourne toujours false.

1.3.GenericBehaviour : Un Generic Behaviour est une instance de la classe jade.core.behaviours.Behaviour. Le Generic Behaviour vient entre le OneshotBehaviour et le Cyclic Behaviour de faite qu'il n'implémente pas la méthode done() et laisse son implémentation au programmeur, donc il peut planifier la terminaison de son Behaviour selon ces besoin.

2. Les Behaviours planifiés : Pour planifier une tâche d'un agent JADE, il existe deux types de Behaviours :

2.1.WakerBehaviour (timeouts) : Le WakerBehaviour est implémenté de façon à exécuter la méthode onWake() après une période passée comme argument au constructeur. Cette période est exprimée en millisecondes. Le Behaviour prend fin juste après avoir exécuté la méthode onWake().

2.2.TickerBehaviour (timeouts répétés): Le TickerBehaviour est implémenté pour qu'il exécute sa tâche périodiquement par la méthode onTick(). La durée de la période est passée comme argument au constructeur.

3. Les Behaviours composés : Les Behaviours (simples et planifiés) ne peuvent pas répondre d'une manière efficace à tous les besoin d'un développeur d'un système multi-agents. Pour cela JADE offre un ensemble de Behaviours composés pour présenter des tâches complexes. La classe mère de toutes les autres complexes est la classe jade.core.behaviours.CompositeBehaviour. noter que l'ordre d'exécution des Behaviours est à la charge des deux méthodes scheduleFirst()et scheduleNext()que les classes héritant de la classe CompositeBehaviour doivent implémenter. Le programmeur n'est pas dans l'obligation d'utiliser directement la classe CompositeBehaviour car il on dispose de trois classes filles. 3.1.SequentielBehaviour : Dans le SequentielBehaviour: Le Behaviour commence

par exécuter le premier sous-Behaviour et lorsque termine son exécution (sa

méthode done() retourne true), il passe au prochain Behaviour, et ainsi de suite.

Cependant, Les sous-Behaviours sont ajoutés au sequentielBehaviour par la

méthode addSubBehaviour() et l'ordre de l'ajout détermine l'ordre d'exécution.

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

3.2.FSMBehaviour : FSMBehaviour est une sorte de Behaviour qui implémente un automate à états finis dont chaque état correspond à l'exécution d'un sous-Behaviour.

3.3.ParallelBehaviour : Le parallelBehaviour est un Behaviour qui permet d'exécuter plusieurs Behaviours en parallèle. L'ajout de sous-Behaviour se fait par la méthode addSubBehaviour(). Si on veut que le parallelBehaviour termine dès qu'un de ses sous-Behaviours termine alors on doit passer à son constructeur l'argument WHEN_ANY et pour attendre la fin de tous les sous-Behaviours on doit lui passer l'argument WHEN_ALL.

3.4.Combiner plusieurs Behaviours composés : Il est possible de combiner les différents comportements composés pour créer des comportements plus complexes.

Remarque

ü Pour Enlever un comportement on utilise la méthode : removeBehaviour (...).

ü S'il n'existe pas un comportement donc l'agent est Mis en veille .

ü La méthode Behaviour.block() permet de mettre l'agent en sommeil afin de ne pas consommer de ressources systèmes en attendant un nouvel événement (ou message), comme il pourrait le faire avec une boucle infinie. L'agent est alors dormant jusqu'à ce qu'il reçoive un nouveau message dans sa mailbox.

Exemple d'utilisation des Behaviours simples [BYo09]:

Import jade.core.Agent;

Import jade.core.behaviours.Behaviour;

Import jade.core.behaviours.CyclicBehaviour;

Import jade.core.behaviours.OneShotBehaviour;

public class SimpleAgent extends Agent {

protected void setup() {

// Ajouter un OneShotBehaviour

addBehaviour(new OneShotBehaviour(this) {

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

Public void action() {

System.out.println ("***Bonjour tous le monde \n je suis l'agent : " + getLocalName() + " ***");

}

})

// ajouter un CyclicBehaviour qui affiche chaque fois : cyclique

addBehaviour(new CyclicBehaviour(this) {

public void action()

{

System.out.println("cyclique... ");

}

});

addBehaviour(new RandomBehaviour());

}

private class RandomBehaviour extends Behaviour

{

private int aleatoire ;

public void action()

{

aleatoire = (int) (Math.random()*10);

System.out.println("aleatoire ="+ aleatoire);

}

public boolean done() {

Return aleatoire == 4;

}

Generation des diagrammes AllitiL dyartir de yrogrammes JADE

Chayitre 1 : La ylate forme multi agents JADE

public int onEnd()

{

myAgent.doDelete(); return super.onEnd();

}

}}

5. 4. Le service page jaune « DF »

Le dialogue avec l'agent DF se fait à partir d'un objet appelé DFAgentDescription, qui donne la description (les services) d'un agent que connaitra l'agent DF. Dans un premier temps, il faut créer cette description :

DFAgentDescription dfd = new DFAgentDescription ()

La définition d'un service se fait à partir de la classe ServiceDescription : ServiceDescription sd = new ServiceDescription();

sd.setType(<nom_type_service>);

sd.setName (<nom_service>);

Lorsque le service est créé, il faut enfin l'ajouter dans le DFAgentDescription de l'agent, puis enregistrer cette description au DFAgent :

dfd.addServices(sd);

try

{

DFService.register(this, dfd);

}

catch (FIPAException e)

{

<code d'erreur>

}

A partir d'une certaine DFAgentDescription, recensant un ensemble de services, il est alors possible de rechercher des agents proposant ses services :

1. Création de la DFAgentDescription comprenant nos services recherchés : DFAgentDescription dfd = new DFAgentDescription();

ServiceDescription sd = new ServiceDescription();

sd.setType( "buyer" );

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

dfd.addServices(sd);

2. Retrouver les agents dans un tableau :

DFAgentDescription[] result = DFService.search(this, dfd);

3. Parcourir le tableau pour retrouver les agents : for (int i=0; i<result.length; i++) {

Iterator iter = result[i].getAllServices();}

5. 5. Les agents techniques dans JADE « Outils de débogage »

Pour supporter la tâche difficile du débogage des applications multi-agents, des outils ont été développés dans la plate-forme JADE. Chaque outil est empaqueté comme un agent, obéissant aux mêmes règles, aux mêmes possibilités de communication et aux mêmes cycles de vie d'un agent générique.

1. Agent RMA « Remote Management Agent » : L'agent RMA permet de :

ü Démarrer les autres outils.

ü contrôler le cycle de vie de la plate-forme et tous les agents la composant « superviser les états des agents, par exemple arrêter et remettre en marche un agent »

ü créer et commencer l'exécution d'un agent sur un hôte éloigné, à condition qu'un réceptacle d'agents s'exécute déjà sur cet hôte.

Figure 1.7: L'agent RMA

Chapitre i : La plate forme multi agents JADE

Toute la communication entre les agents et RMA et toute la communication entre cette interface et l'AMS est faite par ACL via une extension ad hoc de l'ontologie des agents de gestion FIPA et plusieurs RMA peuvent être lancés sur la même plate-forme du moment qu'ils ont des noms distincts.

2. Agent Dammy « Visualisation des messages »

L'outil Dummy est un très puissance outil pour inspecter les échanges de messages entre agents. Ainsi que l'Agent Dummy permet aux utilisateurs d'interagir avec les agents JADE d'une façon particulière. L'interface graphique permet la composition et l'envoi de messages ACL et maintient une liste de messages ACL envoyés et reçus et éventuellement sauvegarder ces messages. Cette liste peut être examinée par l'utilisateur et chaque message peut être vu en détail ou même édité. Plus encore, le message peut être sauvegardé sur le disque et renvoyé plus tard.

Figure 1.8 : L'agent Dammy

Chapitre i : La plate forme multi agents JADE

3. Agent Direcory Facilitator :

L'interface du DF peut être lancée à partir du menu du RMA .Cette action est en fait implantée par l'envoi d'un message ACL au DF lui demandant de charger son interface graphique. L'interface peut être juste vue sur l'hôte où la plate-forme est exécutée. En utilisant cette interface, l'utilisateur peut interagir avec le DF.

Figure 1.9 : L'agent DF

4. Agent Sniffer :

L'agent sniffer est utilisé lorsqu'un utilisateur décide d'épier un agent ou un groupe d'agents « écouter, débugger, sauvegarder en fichier les conversations multi-agent ». Pour cela chaque message partant ou allant vers ce groupe est capté et affiché sur l'interface du sniffer. L'utilisateur peut voir et enregistrer tous les messages, pour éventuellement les analyser plus tard.

L'agent sniffer utilise une notation proche d'UML et L'agent peut être lancé du menu du RMA ou de la ligne de commande suivante :

Java jade.Bootsniffer:jade.tools.sniffer.sniffer

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

Figure 1.10 : L'agent Sniffer

5. Agent Introspector : Cet agent permet de :

ü Visualiser les messages envoyés/reçus.

ü Visualiser les comportements actifs et non actifs.

ü gérer et contrôler le cycle de vie d'un agent s'exécutant et la file de ses messages envoyés et reçus.

Figure 1.11 : L'agent Introspector

Generation des diagrammes AlliviL d partir de programmes JADE

Chapitre i : La plate forme multi agents JADE

6. les domaines d'utilisation de JADE

Même si la plate forme multi-agents JADE est un projet récent, difficile à vendre, difficile de trouver des personnes le connaissant et a été conçu selon des critères d'avantage académiques qu'industriels, et même s'il n'a été distribué en Open Source que très récemment, il a été utilisé par de nombreux projets internationaux et dans des domaines différents tel que: le soutien de travail collaboratif, e-learning, e-tourisme, gestion de réseau de divertissement, la gestion des connaissances...etc.

Conclusion

Dans ce chapitre, nous avons présenté l'une des plates formes multi agents : JADE « Java Agent Developement Framework ». Elle est compatible avec la norme FIPA, donc JADE est considéré un standard. En utilisant JADE, il est facile d'implémenter un agent simple « agent cognitif ou bien réactif ». JADE utilise des techniques avancées (Système Expert JESS) et permet de commencer par quelques agents simples puis faire évoluer l'architecture avec l'application. Par ailleurs, JADE offre aux développeurs des systèmes multi agents la possibilité de planifier les tâches d'un agent d'une manière efficace et assez transparente.

Chapitre -02-

AUML

·
· Dans ce chapitre

Introduction.

1. Brève description d'AUML.

2. Les différents niveaux d'AUML.

3. Les diagrammes AUML.

3.1. Le diagramme de classe AUML.

3.2. Le diagramme de séquence AUML.

Conclusion.

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

Introduction

L'évolution des approches basées agents, a crée presque les même besoins des approches orientées objet. Par conséquent, il fallait trouver comme pour les systèmes orientés objet, des outils capables de donner une dimension méthodologique à l'approche agent qui permettrait de mieux maîtriser sa richesse [Jam00]. Actuellement, la modélisation objet est basée sur un standard baptisé UML (Unified Modeling language). Bien qu'il représente une réelle avancée dans le domaine de modélisation des systèmes complexes, UML ne permet pas de tenir comptes toutes les spécificités des SMA. Ces insuffisances ont rendu nécessaire de penser à des outils de modélisation et de programmation orientés agent [Sté05]. Plusieurs formalismes et langages on été émergés dans la littérature pour la spécification et la modélisation des SMA, nous citons entre autre AUML (Agent UML).

Dans ce chapitre nous introduisons le formalisme AUML (Agent Unified Modeling Language) qui s'appuie sur UML, c'est à dire il étend UML pour décrire les spécificités des SMA. Les extensions apportées à UML sont :

v' la représentation des threads simultanés d'interaction (par exemple transmission de messages à plusieurs agents) permettant ainsi à UML de modéliser les protocoles d'interactions entre agents, par exemple le réseau contractuel [2].

v' la notion de rôle qui étend celle fournie par UML et permet de modéliser un agent qui joue plusieurs rôles [2].

1. Brève description d'AUML

AUML « Agent UML » est un projet relativement jeune proposé par Bauer, Odell et al en 1999 [Zei09] et les premiers travaux de spécification ont débuté en 2003 [Mic05]. AUML vise à proposer un ensemble de notations mieux adaptées au paradigme multi-agent, en étendant le langage UML.

AUML est développé par l'équipe FIPA appelée FIPA Modeling Technical Committee (Modeling TC) [Mic05] qui a pour but les objectifs suivants :

v' Faire progresser l'état de l'art de la modélisation orientée agent [Mic05].

v' Permettre aux développeurs de mieux comprendre comment modéliser des applications orientées agent [Mic05].

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

1' recommander une technologie pour l'adoption d'une sémantique, un méta-modèle et une syntaxe abstraite communes pour l'analyse et la conception des méthodologies basées sur agents [2].

v' être en accord avec les spécifications existantes de FIPA (Foundation for Intelligent Physical Agents) et OMG (Object Management Group) [2].

V' avoir un aperçu rapide du déroulement d'un protocole. rappelons que les protocoles d'interaction du modèle FIPA-ACL sont spécifiés en AUML [Ale03].

1' Représentation du comportement interne à un agent [Jam00].

Notons qu'AUML est un formalisme de modélisation qui est actuellement difficile à cerner [Mic05]. Certaines parties comme les interactions entre agents sont clairement définies car les apports d'AUML figurent au niveau des diagrammes d'interaction (famille de diagrammes regroupant le diagramme de séquence, le diagramme de collaboration et les diagrammes temporels) [Sté05] tandis que d'autres comme le diagramme de classe ont subis des changements récents qui ont nécessité un total remaniement de la vision d'AUML.

2. Les différents niveaux d'AUML

AUML est organisé en 3 niveaux :

1. Niveau 1 : ce niveau permet de représenter le protocole global [Jam00] c'est à dire ne fournit qu'une spécification de base sur le protocole. En effet, on retrouve dans ce niveau : le diagramme de séquence, Package et Template « gabarit » [Jam00].

+ Le diagramme de séquence : est détaillé ultérieurement.

+ Package : En UML le package est un regroupement d'éléments de modélisation susceptible de contenir n'importe quel élément [1]. Notons que le package est uniquement un élément d'organisation et n'a pas de réalité concrète dans le système physique final [1]. En effet, dans le premier niveau d'AUML le protocole est luimême un paquet [Jam00]. Ainsi tout élément hors le package est externe au protocole [Mic05] donc le package délimite un système fermé.

v' Notation : le package en AUML est représenté par un rectangle aux bordures pleines avec un onglet en haut à gauche auquel il est écrit le mot clé « sd » (sequential diagram) suivit du nom du protocole [Mic05].

Generation des diagrammes Yl.tiltiL d partir de programmes JYl.DE

Chapitre 2 : Yl.tiltiL

Figure 2.1: la notation du package en AUML [Gen03]

Les paramètres du package : dans les packages d'AUML on utilise des commentaires pour représenter les paramètres. En effet, les paramètres sont préfixés par <<parameters>> et ceci permet de réduire la taille du diagramme dans le cas de nombreux paramètres [Gen03].

Figure 2.2: les paramètres du package AUML [Gen03]

Le développeur a besoin de savoir dans le diagramme AUML: l'ontologie, le
langage descriptif, et le langage de communication entres les agents utilisés

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

dans un protocole. Pour cela ces informations sont spécifiées dans les paramètres du protocole, mais ces informations peuvent être omises s'il n'y a pas de doute [Mic05].

Figure 2.3: notation du package AUML avec des informations supplémentaires
[Gen03]

+ Template « Gabarit »: Un Template « Gabarit » est un élément paramétrable, dont les paramètres sont attachés quand le nouveau modèle est produit [Jam00]. L'utilisation des Template est important car au lieu de définir une composante réutilisable. La personnalisation des paquets devrait être incluse [Jam00]. En effet, les paramètres du Template sont divisés en trois catégories : les paramètres de rôle, les contraintes et les actes de communication [Zei09].

Figure 2.4: la notation du Template en AUML [Jam00]

~énératIon ~~s ~~agrammes 2t'LLMJ à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

1' Notation :

~ le Template est représenté à travers un package avec un trait interrompus dans le coin haut droit du package [Zei09].

Figure 2.5: Exemple d'un protocole d'interaction générique [Zei09] ~ deuxième notation :

Figure 2.6: deuxième notation du Template AUML [Gen03]

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

2. Niveau 2 : Le deuxième niveau représente les interactions entre les agents grâce à des diagrammes d'interactions : diagrammes de séquences, diagrammes de collaborations, diagrammes d'activités ou bien diagrammes d''etats/transitions. [Zei09].

3. Niveau 3 : La modélisation d'un protocole exige, la représentation intérieure qui survient dans un agent lors de l'exécution d'une procédure [Jam00]. Pour cela le troisième niveau est consacré pour la représentation correspond aux processus internes aux agents qui sont principalement modélisés par des diagrammes d''etats/ transitions [Zei09].

Figure 2. 7: un protocole d'interaction spécifié avec plus de détails, a l'aide d'un
ensemble de diagramme [Jam00]

3. Les diagrammes AUML

AUML est une extension de la notation UML pour la modélisation d'agents. Cette extension concerne :

v' le diagramme de classes, qui représente la structure statique du SMA.

v' Les diagrammes d'interactions comme le diagramme de séquence. Ceux ci permettent de modéliser le comportement dynamique du système.

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

3.1.Le diagramme de classe AUML

Les diagrammes de classes sont utilisés pour représenter le point de vue statique [Ste99]. Ainsi, le diagramme de classes dans AUML a pour but de représenter un système entier d'agents, et non simplement des agents individuels ou fortement regroupés [Mic05]. En effet, une classe agent est une classe UML qui peut aussi spécifier [Zei09] :

v' L'identificateur de l'agent [Ste99].

~ un ensemble de rôles [Zei09].

v' des actions [Zei09].

v' des capacités [Zei09].

~ une description des services [Zei09].

~ un ensemble de protocoles [Zei09].

1' des contraintes [Zei09].

Figure 2.8: exemple de diagramme de class AUML [Ste99]

+ La représentation des capacités : Une capacité est composée des parties suivantes [Ste99]:

a) Les entrées: représente les entrées nécessaires de l'agent pour atteindre sa tâche.

b) Sortie : représente ce qui génère la capacité à la fin du travail.

c) Contraintes d'entrées.

d) Contraintes de sortie.

e) Les contraintes d'entrées-sorties.

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

f) Description : Une description en langage naturel de la capacité.

Figure 2.9: exemple de diagramme de class AUML avec la représentation des capacités [Ste99]

+ La représentation de service : Un service est composé des parties suivantes [Ste99]:

a) Nom: Le nom du service.

b) Description : Une description en langage naturel du service.

c) Type : Le type de service.

d) Protocole : Une liste des protocoles d'interaction soutenue par le service.

e) Langue de communication Agent : Les langues de communication utilisées dans ce service.

f) Ontologie : Une liste des ontologies pris en charge par le service.

g) Langue du contenu : Une liste des langues de contenu pris en charge par le service.

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

Figure 2.10: exemple de diagramme de class AUML avec la représentation des services
[Ste99]

3.2. Le diagramme de sequence AUML

Les diagrammes d'interaction sont des diagrammes dynamiques, qui décrivent le comportement collectif des agents. On retrouve dans les diagrammes d'interaction deux types de diagramme [Jam00] :

1. Le diagramme de séquence.

2. Le diagramme de collaboration.

Le diagramme de séquence est défini comme suit en UML: "le diagramme de séquence est un diagramme qui montre les interactions des objets disposés dans la séquence temporelle. En particulier, elle montre les objets participant à l'interaction et la séquence de messages échangés. Contrairement à un diagramme de collaboration, un diagramme de séquence comprend des séquences de temps, mais ne comprend pas les relations entre objets." [Gen03]. En effet, le diagramme de séquence en AUML est initialement adopté par la

~énératIon ~~s ~~agrammes 21'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

FIPA pour exprimer des protocoles d'interaction des agents. Ainsi, on considère des agents et non des objets, donc il faut lire agents au lieu des objets dans la précédente définition. Les diagrammes de séquence dans les systèmes multi agents sont des schémas qui expriment l'échange de messages dans les protocoles [Gen03]. Donc les déférences qui existent entre le diagramme de séquence en UML et en AUML sont :

a) Dans le diagramme de séquence AUML il existe une spécification plus riche du rôle d'un agent [Jam00].

b) L'extension du diagramme de séquence donne des étiquettes (acte de communication), aux flèches au lieu du message style orienté objet [Jam00].

c) l'ajout de nouveaux types de branchements dans les diagrammes de séquence AUML afin de prendre en compte l'indéterminisme du comportement d'un agent. La figure 11 montre les trois types de branchement: branchement ET (a), branchement OU (b) et branchement XOR (c) [Zei09].

Figure 2.11: les différents branchements en AUML [Zei09]

Generation des diagrammes AtiltiL dyartir de yrogrammes JADE

Chayitre 2 : AtiltiL

Figure 2.12: des techniques pour exprimer les communications concurrentes avec un agent
jouant des rôles différents, ou recevant des CAs différents [Jam00]

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

Les barres parallèles dans la figure 12 indiquent que l'agent de réception est capable de traiter plusieurs communications concurremment [Jam00]. Ainsi Chaque bar d'activation indique que l'agent peut utiliser un différent rôle ou un processus différents, pour l'acte de communication. Notons que le sens est le même (exemple : la figure (a) = la figure (b)) donc le choix est fondé sur la clarté visuelle [Jam00].

Le diagramme de séquence AUML se compose de deux dimensions:

v' Verticale: pour le temps.

v' Horizontale: pour les différents rôles ou bien pour les agents jouant un rôle spécifique [Mic05].

Figure 2.13: format de base pour la communication [Jam00] + La ligne de vie dans le diagramme de séquence AUML

La ligne de vie AUML est en contradiction avec la ligne de vie d'UML2. En UML2, une ligne de vie représente un participant individuel dans l'interaction. En AUML, la ligne de vie définie la période durant laquelle un rôle existe pour une interaction, elle est représenté par une ligne verticale [Mic05]. Il est possible de représenter plusieurs agents sur la même ligne de vie [Gen03]. Ainsi une ligne de vie ne représente pas nécessairement un agent, mais aussi un rôle joué par un ou plusieurs agents [Gen03].

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

Figure 2.14: la notation de la ligne de vie en AUML [Gen03]

La ligne de vie dans le diagramme de séquence AUML est composée de deux éléments: un label représente dans une boite au-dessus de la ligne de vie et une ligne verticale en pointille.

Plusieurs formats sont possibles pour l'étiquette du label:

							Pour indiquer que Client est un rôle indépendant des agents qui jouent ce rôle donc la ligne de vie ne représente pas nécessairement un agent, mais aussi un rôle joué par un ou plusieurs agents [Gen03].
			: Client
							BOB serait le cas d'un agent jouant le rôle d'un client [Jam00].
		BOB/Client
							Pour indiquer que BOB est une personne indépendante de n'importe quel rôle joués [Jam00].
	BOB: Personne
							Format de base pour l'étiquette de boite. Utiliser Pour spécifier qu'un rôle doit être jouaient par une classe d'agents « le nom de la classe doit apparaitre » [Jam00].
Nom_agent / role: Personne
							Exemple :	BOB/ Consommateur: Personne

Tab 2.1: les différents formats possible pour l'étiquette du label de la ligne de vie du
diagramme de séquence AUML

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

L'étiquette contient ainsi la cardinalité du rôle : Il existe trois formats pour la cardinalité du rôle [Gen03]:

~ n qui représente le nombre exact d'agents jouant ce rôle dans cette interaction.

~ m op n qui représente une plage de valeurs pour la cardinalité rôle. (op désigne

les opérateurs >,> =, <, <=) m et n se réfèrent respectivement à la partie

inférieure et la limite supérieure de la fourchette de valeurs.

~ une condition ou une formule logique qui représente le nombre d'agents. + L'échange de messages

Dans les diagrammes de séquence AUML, les messages sont ordonnés selon un axe de temps déroulant selon la dimension verticale de haut en bas. Cependant, les diagrammes de séquence n'utilisent les numéros de séquence, comme les diagrammes de collaboration pour représenter le message mais l'ordre des messages est implicitement défini par l'axe des temps [Gen03].

Figure 2.15: exemple d'échange de message dans AUML [Gen03]

Un message définit une communication particulière entre deux lignes de vie. Les expéditeurs et les récepteurs d'un message peuvent être sur la même ligne de vie ou non [Gen03]. Deux situations doivent être prises en considération dans la ligne de vie de l'expéditeur et la même chose pour la ligne de vie du récepteur:

1. L'expéditeur veut recevoir le message.

~énératIon ~~s ~~agrammes 4'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLMJ

2. L'expéditeur veut être omis de l'ensemble des bénéficiaires. Les messages peuvent être :

1. Asynchrones : dans ce cas la flèche est vide.

2. Synchrones : dans ce cas la flèche est pleine.

Figure 2.16: Notation des messages synchrones et asynchrones [Mic05]

L'acte de communication est annoté dans le diagramme de séquence AUML sur la flèche dont l'expéditeur est l'origine de la flèche et le récepteur est à sa pointe [Mic05]. Ainsi, le langage et l'ontologie sont écrits dans un commentaire lié au diagramme. Ainsi, en raison de clarté le contenu du message n'est pas toujours inclus, mais peut être ajouté à la droite de la flèche [Mic05].

Les échanges de message peuvent comporter des contraintes, et celles ci se notent prés de l'origine entre crochets « [] » [Mic05].

[condition] <<blocking>> [condition]

(a) (b)

a)- pour noter une contrainte non bloquante [Gen03].

b)- pour noter une contrainte bloquante [Gen03].

Les contraintes de temps permettent d'imposer un certain rythme dans le protocole [Mic05]. Deux notations existent dans le diagramme de séquence AUML:

~énératIon ~~s ~~agrammes 21'LLM1 à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

Les bornes inférieures et supérieures peuvent être soit des nombres naturels tels que {0..3} (le message doit être reçu après 3 unités de temps) ou bien sur le temps d'observation tels que {0..t+3} (le message doit être reçu entre maintenant et le temps d'observation plus 3 unités de temps) [Gen03]. Les contraintes de temps absolues sont écrites sous une forme libre c'est-à-dire ça peut être une date comme 23/04/2003 14:00 ou une heure ou toute combinaison de ces deux contraintes [Gen03].

Figure 2. 17: la notation de la contrainte de temps en AUML [Gen03]

Figure 2. 18: la notation de la contrainte du temps alternative en AUML [Gen03]

Generation des diagrammes YlliitiL d partir de programmes JYlDE

Chapitre 2 : YlliitiL

Ainsi, quand le message est envoyé et reçu par la même ligne de vie, il est nécessaire de spécifier si l'émetteur reçoit ou non le message : l'origine barrée de la flèche signifie que l'émetteur est exclu des destinataires [Mic05].

Figure 2.19: Notation des boucles sur la même ligne de vie [Gen03]

Il est possible de restreindre aussi le nombre de destinataires en spécifiant le nombre de récepteurs à la pointe de la flèche (par exemple « <5 ») [Mic05].

~énératIon ~~s ~~agrammes 2t'LLMJ à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

Figure 2.20: restreindre le nombre de destination en AUML [Gen03]

+ Exemple d'interaction [Ste99] :

1' L'acheteur envoie une demande de propositions au vendeur.

v' Le vendeur dispose de trois options à choisir dans le délai:

· Faire une proposition.

· refuser (avec des raisons différentes).

· dire qu'il ne comprenait pas.

v' Si le vendeur a fait une proposition, l'acheteur a le choix de rejeter ou d'accepter

v' Si l'acheteur accepte la proposition du vendeur, dans ce cas, chaque fois le vendeur informe l'acheteur sur son état.

v' L'acheteur peut annuler l'exécution de la proposition à tout moment.

~énératIon ~~s ~~agrammes 2t'LLMJ à yartIr ~~ yrogrammes DT

C~~pItre 2 : LLM~

Figure 2. 21: exemple de protocole d'interaction [Zei09]

Conclusion

Dans ce chapitre nous avons présenté le formalisme AUML : les principaux diagrammes et les différentes notations utilisées par ce formalisme qui ne sont pas complètement standardisées. Nous nous intéressons dans ce qui reste de ce mémoire aux diagrammes de classes et de séquences pour la compréhension des applications multi-agents écrites dans JADE.

Chapitre -03-

Approche propos~e et

presentation de l'outil

developpe

Dans ce chapitre
Introduction.

1. L'approche proposée.

1.1. Translation du programme JADE vers le diagramme de classe AUML 1.2. Translation du programme JADE vers le diagramme de séquence AUML.

1.3. La génération du fichier XML correspond aux diagrammes générés.

2. Les règles de transformation.

2.1.Génération de diagramme de classe AUML à partir de programme JADE.

2.2.Génération de diagramme de séquence AUML à partir de programme JADE.

2.3.Diagrammes AUML vers document XML.

3. Présentation de l'outil développée

4. Etude de cas

Conclusion.

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

Introduction

Nous allons présenter dans ce chapitre une nouvelle approche pour la compréhension des applications multi-agents développées sur la plateforme JADE. L'approche proposée consiste en la génération de diagrammes Agent UML à partir de programme JADE. Plus particulièrement, nous nous intéressons aux diagrammes de classes et de séquence AUML. Ce dernier offre une description semi-formelle permettant aux utilisateurs des SMA notamment ceux qui ne sont pas bien familiarisés avec la plateforme JADE de comprendre l'application développée sur JADE dans l'objectif de sa maintenance.

En effet, Le choix de la plateforme JADE est justifié par les points suivants:

ü JADE diminue l'effort de la programmation car elle inclut tous les composants obligatoires pour contrôler un SMA « DF et AMS » et offrir une librairie de classes que les utilisateurs peuvent utiliser et étendre ainsi qu'un ensemble d'outils graphiques qui permettent le débogage et l'administration du SMA à concevoir.

ü JADE simplifie l'implémentation d'un SMA à travers un Middleware répondant aux spécifications de la FIPA et assure une communication transparente par l'échange de messages dans le langage normalisé FIPA-ACL.

ü JADE est indépendante de tout modèle d'agent et actuellement représente la plateforme la plus utilisée.

Pour valider notre approche, nous avons développé un outil la supportant qui permet d'une part la génération de diagrammes AUML et, d'autre part, la génération d'un fichier XML correspondant aux diagrammes AUML générés fournissant ainsi des données pouvant être traitées dans l'objectif de maintenir l'application SMA développée et être utilisée par d'autres environnements de développement (XML est un standard).

1. L'approche proposée

Dans cette section, nous allons présenter la nouvelle approche proposée pour la génération des diagrammes AUML ainsi que le fichier XML à partir d'un code JADE. Le

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

processus de développement de notre approche est représenté dans la figure 3.1, et expliqué en détail dans le reste du chapitre.

Prétraitement

Programme JADE

Programme JADE compatible

Diagramme de class
AUML

Diagramme de séquence
AUML

Fichier XML

Figure 3.1 : l'approche proposée

1.1. Translation du programme JADE vers le diagramme de classe AUML

Dans cette étape, les différentes classes qui constituent l'application SMA sont translatées vers le diagramme de classe AUML. Chaque classe dans le diagramme de classe AUML correspond à une classe JADE.

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

Dans notre application, le diagramme de classes AUML est composé d'un ensemble de classes, chaque classe contient les informations suivantes :

ü La liste des variables utilisées.

ü La liste des méthodes.

ü Et la liste des rôles joués par cet agent. Notons que dans la plate forme JADE,
chaque rôle est représenté par un ensemble de comportements « Behaviours ».

En plus, nous allons représenter la relation d'héritage qui existe entre les différentes classes. Les règles de passages seront énoncées en détail dans la section suivante (section 3).

1.2. Translation du programme JADE vers le diagramme de séquence AUML

C'est l'étape la très importante dans notre travail parce que dans cette étape nous allons traduire une description écrite dans JADE vers un diagramme d'interaction dynamique « le diagramme de séquence AUML ».

Nous avons trouvé plusieurs difficultés durant la recherche des différents messages envoyé et reçu par les agents, parce que dans JADE nous avons plusieurs types de Behaviours et seulement le OneShotBehaviour est susceptible de transformer vers un diagramme de séquence, pour les autres il n'existe pas d'équivalence en AUML. Pour cela nous avons traité seulement le OneShotBehaviour.

Les règles de translation seront également présentées en détail dans la section suivante (section 3).

1.3. La génération du fichier XML correspond aux diagrammes générés

C'est la dernière étape dans notre application. Après la génération des diagrammes AUML, nous avons transformé la description graphique vers un document XML pour simplifier aux utilisateurs de notre application de faire des traitements sur les diagrammes générés.

Generation des diagrammes A d partir de programmes JADE

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

2. Les règles de transformation

2.1. Génération de diagramme de classe AUML à partir de programme JADE

Dans notre application, chaque classe JADE correspond à une classe dans le diagramme de classe AUML comme illustre la figure 3.3. En effet, on trouve dans les diagrammes AUML une notion très importante qui est la notion de rôle qui permet de modéliser un agent qui joue plusieurs rôles. Cependant, dans la plate forme multi agent JADE il n'existe pas la notion du rôle donc pour résoudre ce problème nous allons créer un classe d'agent JADE Agent_with_role qui hérite de la class jade.core.Agent et qui redéfinit la méthode addBehaviour dans le but d'associer pour chaque comportement le nom du rôle joué car chaque rôle dans JADE est défini par un ensemble de comportements. Donc dans notre application, les agents dans la classe mère agent sont remplacés par des agents dans la classe mère Agent_with_role.

import jade.core.Agent;

import jade.core.behaviours.Behaviour;

public class Agent_with_role extends Agent {

protected String role;

protected void setup() {

}

//redéfinir la méthode addBehaviour

public void addBehaviour(String role, Behaviour b) {

addBehaviour(b);

this.role = role; } }

Figure 3.2: la classe Agent_with_role

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

.

{

}

.

.

}

<<Agent_name>>
name_class

Vars:

Type_var var1; Type_var var2; ...

Type_var varn;

Methodes: #void setup()

#void takeDown()

Methode 1; Methode 2; ...

Methode n;

Roles :

role1
role2

<<Agent_name>>
Super_class

public class name_class extends super_class {

protected void setup()

protected void takeDown()

{
}

Methode 1;
Methode 2;

.

Methode n;

Type_var var1; Type_var var2; .

.

Type var varn;

//la déclaration des variables

//la déclaration des méthodes

addBehaviour(Behaviour1, role1);
addBehaviour(Behaviour2, role1);
addBehaviour(Behaviour3, role2);

Figure 3.3 : Equivalence entre un classe d'agent JADE et une class dans le diagramme de
class AUML

2.2. Génération de diagramme de séquence AUML à partir de programme JADE

Comme nous l'avons mentionnée auparavant, l'étape la très importante dans notre travail est la génération de diagramme de séquence AUML parce que les principaux apports d'AUML se trouvent au niveau de ce diagramme. Ils permettent notamment d'exprimer clairement les processus de communication entre agents qui impliquent des structures conditionnelles. Pour cela, dans cette section nous fournissons les règles de transformation

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

d'un programme JADE vers le diagramme de séquence AUML. En effet, Les rôles du diagramme de séquences AUML sont :

1. présenter les interactions entre agents avec une dimension temporelle.

2. présenter tous les agents/rôles impliqués.

3. présenter les messages échangés suivant un ordre chronologique.

Cependant, dans JADE on ne trouve pas une classe spécifique pour les rôles pour cela on ne peut pas représenter les rôles mais nous avons représenté les interactions qui existent entre les agents à travers les messages échangés. A ce stade, nous avons trouvé des difficultés pour représenter les différents messages échangé entre les agents suivant un ordre chronologique. Pour résoudre ce problème nous avons redéfinir la class ACLMessage parce que tous les messages dans JADE sont des instances de cette classe.

Habituellement, Dans la méthode addReceiver de la class ACLMessage on a seulement comme paramètre : l'identificateur de l'agent récepteur, mais cette information n'est pas suffisante pour déterminer le rôle de l'agent récepteur ainsi que le placement du message dans la ligne de vie. Pour cela, nous avons redéfini la classe ACLMessage pour redéfinir la méthode addReceiver. Nous avons ajouté comme paramètre dans cette méthode le nom du rôle de l'agent récepteur ainsi que le placement du message dans la ligne de vie comme il est illustré par la figure suivante.

import jade.core.AID;

import jade.lang.acl.ACLMessage;

public class ACLMessage_with_role extends ACLMessage {

public void addReceiver(AID r, String name_role,int numero) {

addReceiver(r);

}

}

Figure 3.4: la class ACLMessage_with_role

Chapitre 3 : Approche proposée et presentation de l~oatil d~veloppe

Dans le diagramme de séquence AUML on ne trouve pas seulement des messages échangés entre les agents suivant un ordre chronologique mais on trouve aussi des nouveaux types de branchements afin de prendre en compte l'indéterminisme du comportement d'un agent. Le tableau suivant illustre l'équivalence entre les différents branchements qui existent dans le diagramme de séquence AUML et le programme JADE.

Code JADE

Notation AUML

ACLMessage_with_role message = new

ACLMessage_with_role(ACLMessage.INFORM); message.setContent(contenu _du_message);

message.addReceiver(agent_recepteur, role_recepeteur,placement_message); send(message);

INFORM

if(condition)

{

ACLMessage_with_role message = new

ACLMessage_with_role(ACLMessage.INFORM);

message . setContent (contenu du message) ; message.addReceiver(agent_recepteur, role_recepeteur,placement_message); send(message);

[condition] INFORM

}

INFORM

INFORM

AC1

A

...

Generation des diagrammes A d partir de programmes JADE

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

ACLMessage_with_role message = new ACLMessage_with_role(ACLMessage.INFORM);

message.setContent(contenu_du_message); if (condition)

{

message.addReceiver(agent_recepteur1, role_recepeteur,placement_message);

send(message);

} else

{ message.addReceiver(agent_recepteur2, role_recepeteur,placement_message);

send(message); }

switch (paramètre) {

case(valeur1): {

send(message1)

}

case (valeur2) {

send(message2)

}

... case(valeurn) : {

send(messagen) } }

Tab 3.1 : l'équivalence entre les différents branchements qui existent dans le diagramme
de séquence AUML et le programme JADE.

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

2.3. Diagrammes AUML vers document XML

Après la génération des diagrammes AUML, notre application exporte le fichier XML qui doit être valide; c'est-à-dire bien formé et respecte notre DTD.

Le DTD

<!DOCTYPE Configuration[

<!ELEMENT Configuration (Empty_Diagrams_AUML|Diagrams_AUML)>

<!ELEMENT Empty_Diagrams_AUML EMPTY>

<!ELEMENT Diagrams_AUML (Diagram_Class_AUML, Diagram_Sequence_AUML)> <!ELEMENT Diagram_Class_AUML (Super_Class*)>

<!ELEMENT Super_Class (Name_Super_Class,Agent*)>

<!ELEMENT Name_Super_Class (#PCDATA)> <!ELEMENT Agent (name_Agent, Vars, Methodes, Roles)>

<!ELEMENT name_Agent (#PCDATA)> <!ELEMENT Vars (Empty_Vars| Var*)> <!ELEMENT Empty_Vars EMPTY>

<!ELEMENT Var (Name_Var, Type_Var)> <!ELEMENT Name_Var (#PCDATA)> <!ELEMENT Type_Var (#PCDATA)>

<!ELEMENT Methodes (Empty_Methodes| Methode*)>

<!ELEMENT Empty_Methodes EMPTY> <!ELEMENT Methode (#PCDATA)>

<!ELEMENT Roles (Empty_Roles|Role*)> <!ELEMENT Empty_Roles EMPTY>

<!ELEMENT Role (Name_Role,List_Behaviour)> <!ELEMENT Name_Role (#PCDATA)> <!ELEMENT List_Behaviour (Behaviour*)>

<!ELEMENT Behaviour (Name_Behaviour,Type_Behaviour)>

<!ELEMENT Name_Behaviour (#PCDATA)> <!ELEMENT Type_Behaviour (#PCDATA)>

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

<!ELEMENT Diagram_Sequence_AUML (Empty_Message|Message*)>

<!ELEMENT Empty_Message EMPTY>

<!ELEMENT Message (Transmitter, (Simple_Rceiver | XOR_Receiver))>

<!ELEMENT Transmitter (#PCDATA)>

<!ELEMENT Simple_Rceiver (Receiver, Act_of_Communication,

Content_of_message)>

<!ELEMENT Receiver (#PCDATA)>

<!ELEMENT Act_of_Communication (#PCDATA)>

<!ELEMENT Content_of_message (#PCDATA)>

<!ELEMENT XOR_Receiver (Rceivers|Receiver_with_Condition)>

<!ELEMENT Rceivers (Simple_Rceiver⁺)> <!ELEMENT Receiver_with_Condition

(Receiver,Act_of_Communication,Content_of_message, Content_of_Condition)> <!ELEMENT Content_of_Condition (#PCDATA)>

]>

3. Présentation de l'outil développée

Dans cette partie nous nous intéressons à la présentation de l'outil développé. Ce dernier est un environnement pour la génération des diagrammes AUML ainsi que le fichier XML d'un programme JADE. Il présente précisément :

ü Un éditeur pour l'application SMA.

ü 3 fenêtres d'édition graphiques pour les deux diagrammes AUML (2 fenêtre
pour le diagramme de séquence et une fenêtre pour le diagramme de classes).

ü Editeur pour le fichier XML généré.

Generation des diagrammes A11.7vIL d partir de programmes JADE

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

Figure 3.5 : l'interface de l'outil développée

4. Etude de cas

Après avoir donné une brève description de notre application on présente dans cette partie un scénario pour la génération de diagrammes AUML ainsi que le fichier XML pour un code JADE concrète. L'exemple choisi est le problème Acheteur/Vendeur. Ce dernier peut être résolu en JADE à travers 7 class c'est-à-dire 7 agents.

ü Classe Personne.

ü Classe Acheteur qui hérite de la classe Personne.

ü Classe Vendeur qui hérite de la classe Personne.

ü Classe colporteur qui hérite de la class Vendeur.

ü Classe telemarketing qui hérite de la class Vendeur.

ü Classe AgentA qui hérite de la class Acheteur.

ü Et enfin, la classe AgentB qui hérite de la class telemarketing.

Génération des diagrammesA~MC d partir de programmes JADE

Chapitre 3 : Approche proposée et présentation de l^~oatil développé Le code de l'agent AgentA est le suivant :

package Memoire_mecibah_zina;

import java.text.NumberFormat; import java.text.ParsePosition;

import jade.core.AID;

import jade.core.behaviours.OneShotBehaviour; import jade.lang.acl.ACLMessage;

import jade.lang.acl.MessageTemplate;

public class AgentA extends Acheteur { protected void setup()

{

//envoyer une requete pour obtenir la liste des produits disponibles

OneShotBehaviour demande = new OneShotBehaviour() {

public void action()

{

ACLMessage_with_role msg = new

ACLMessage_with_role(ACLMessage.REQUEST);

msg.setContent("donner moi la liste des produits SVP");

msg.addReceiver(new AID("AgentB", AID.ISLOCALNAME),"telemarketing",1);

send(msg);

}

};

//Traiter le message qui contient le prix du produit:

final OneShotBehaviour traiter_prix = new OneShotBehaviour() {

public void action()

{

ACLMessage message = null;

while (message == null)

{

message = receive();

}

String msg = message.getContent();

int pos1 = msg.lastIndexOf(":");

int pos2 = msg.indexOf("D",pos1);

String prix = msg.substring(pos1+1,pos2);

float Prix = 0;

NumberFormat formatNombres = NumberFormat.getInstance();

Prix = formatNombres.parse(prix,new ParsePosition(0)).floatValue();

Chapitre 3 : Approche proposée et presentation de l~oatil d~veloppe

if (Prix > 50000)

{

ACLMessage_with_role msg1 = new ACLMessage_with_role(ACLMessage.CANCEL);

msg1.setContent("Ignorer la demande");

msg1.addReceiver(new AID("AgentB", AID.ISLOCALNAME),"telemarketing",5);

send(msg1);

}

}

};

//Behaviour qui permet d'accepter ou rejeter la proposition :

OneShotBehaviour accepter_ou_rejeter_propose = new OneShotBehaviour() {

public void action()

{

ACLMessage message = null ;

while (message == null)

{

message = receive() ;

}

int propose = 0;

if(message == receive

(MessageTemplate.MatchPerformative(ACLMessage.NOT_UNDERSTOOD)))

{

propose = 2;

//ajouter un behaviour.

}

if(message == receive(MessageTemplate.MatchPerformative(ACLMessage.REFUSE)))

{

propose = 3;

//ajouter un behaviour.

}

if(message == receive(MessageTemplate.MatchPerformative(ACLMessage.PROPOSE))) {

if (message.getContent().contains("La liste des produits disponible est:")&& message.getContent().contains("Computer DELL"))

{

} else

{

}

}

propose = 0;

propose = 1;

Chapitre 3 : Approche proposée et presentation de l~oatil d~veloppe

switch(propose)

{

case(0):

{

ACLMessage_with_role msg = new

ACLMessage_with_role(ACLMessage.ACCEPT_PROPOSAL);

msg.setContent("la proposition est acceptable,

Donnez moi le prix");

msg.addReceiver(new AID("AgentB", AID.ISLOCALNAME),"telemarketing",3);

send(msg);

addBehaviour("Acheteur", traiter_prix); break;

}

case(1):

{

ACLMessage_with_role msg = new

ACLMessage_with_role(ACLMessage.REJECT_PROPOSAL);

msg.setContent("rejeter la proposition");

msg.addReceiver(new AID("AgentB", AID.ISLOCALNAME),"telemarketing",3);

send(msg); break;

}

}

};

}

addBehaviour("Acheteur",demande);

addBehaviour("Acheteur",accepter_ou_rejeter_propose);

}

}

Le code de l'agent AgentB est le suivant : package Memoire_mecibah_zina;

import jade.core.AID;

import jade.core.Agent;

import jade.core.behaviours.OneShotBehaviour; import jade.lang.acl.ACLMessage;

import jade.lang.acl.MessageTemplate;

public class AgentB extends telemarketing { protected void setup()

{

//l'ajout d'un nouveau produit :

produit a = new produit(); produits.add(a);

Chapitre 3 : Approche proposée et presentation de l~oatil d~veloppe

//Enregistrement de la description de l'agent dans DF (Directory Facilitator)

OneShotBehaviour enregisterDF = new OneShotBehaviour() {

public void action()

{

register_in_DF();

}

};

//Behaviour qui permet d'accepetr la proposition

final OneShotBehaviour accepter_proposition = new OneShotBehaviour()

{

public void action()

{

ACLMessage_with_role msg = new

ACLMessage_with_role(ACLMessage.INFORM);

msg.setContent("le prix du computer DELL est:" +

"70000" +"DA" );

msg.addReceiver(new AID("AgentA", AID.ISLOCALNAME),"Acheteur",4);

send(msg);

ACLMessage message2 = null ; while (message2 == null)

{

message2 = receive() ;

}

if (message2.getContent().equalsIgnoreCase("Ignorer

la demande"))

{

System.out.println("\n oops !!!");

}

else

{

System.out.println ("\n Bravo");

}

}

};

//Behaviour qui permet de rejeter la proposition

final OneShotBehaviour rejeter_proposition = new OneShotBehaviour()

{

public void action()

{
}

};

Chapitre 3 : Approche proposée et presentation de l^~oatil d~veloppe
//attente de message (de l'agent Acheteur <<AgentA>>)

OneShotBehaviour recevoir_message = new OneShotBehaviour() {

public void action()

{

ACLMessage message = receive(MessageTemplate.MatchPerformative(ACLMessage.REQUEST));

while (message == null)

{

message = receive() ;

}

boolean message_adequat = false;

if (message.getContent().equalsIgnoreCase("donner

moi la liste des produits SVP"))

{

message_adequat = true;

}

char test = 'N';

if(message_adequat != false) {

if(produits.size() == 0)

{

test = 'R'; }

else

{

test = 'P';

}

}

switch (test)

{

case('R'):

{

ACLMessage_with_role msg = new

ACLMessage_with_role(ACLMessage.REFUSE);

msg.setContent("la liste des

produits est vide");

msg.addReceiver(new AID("AgentA",

AID.ISLOCALNAME),"Acheteur",2);

send(msg);

break;

}

case('N'):

{

ACLMessage_with_role msg = new ACLMessage_with_role(ACLMessage.NOT_UNDERSTOOD);

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

msg.setContent("pas compris");

msg.addReceiver(new AID("AgentA",

AID.ISLOCALNAME),"Acheteur",2);

send(msg);

break;

}

case('P'):

{

ACLMessage_with_role msg = new

ACLMessage_with_role(ACLMessage.PROPOSE);

msg.setContent("La liste des

produits disponible est: Computer DELL");

msg.addReceiver(new AID("AgentA",

AID.ISLOCALNAME),"Acheteur",2);

send(msg); break;

}

}

ACLMessage message2 = null ;

while (message2 == null)

{

message2 = receive() ;

}

if (message2.getContent().contentEquals("la proposition est acceptable, Donnez moi le prix"))

{

}

else {

}

addBehaviour("telemarketing",accepter_proposition);

addBehaviour("telemarketing",rejeter_proposition);

}

};

addBehaviour("telemarketing",enregisterDF); addBehaviour("telemarketing", recevoir_message );

}

}

Après l'exécution du code JADE du problème Acheteur/Vendeur par de notre outil, nous avons obtenu la figure suivante pour le diagramme de class.

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

Figure 3.6 : capture écran pour le diagramme de classe généré

Dans notre outil, les sous classes de n'importe qu'elle class mère dans le diagramme de classe AUML sont obtenues par un clique sur cette classe comme il est illustré la figure suivante.

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

Figure 3.7 : Vue étendue de diagramme de classe généré
64

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

Dans notre outil, nous avons utilisé deux fenêtres pour représenter le diagramme de séquence. La première fenêtre est utilisée pour la représentation de la ligne de vie de chaque agent (durée de vie de l'agent est représentée à travers la durée de vie de chaque rôle) et la deuxième fenêtre est utilisée pour illustrer le diagramme de séquence décrivant l'échange des messages entre les agents selon un ordre chronologique.

Figure 3.8 : Lignes de vie des différents agents

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

Figure 3.9 : diagramme de séquence AUML généré par outil

Finalement, le fichier XML généré est le suivant :

<?xml version = "1.0" encoding="UTF-8"?>

<Configuration>

<Diagrams_AUML>

<Diagram_Class_AUML>

<Super_Class>

<Name_Super_Class>Agent</Name_Super_Class> <Agent>

<name_Agent>Agent_with_role</name_Agent> <Vars>

<Var>

<Name_Var>role</Name_Var>

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

<Type_Var>String</Type_Var>

</Var>

</Vars>

<Metho des>

<Metho de>public void addBehaviour(String role, Behaviour b)

</Metho de>

<Metho de>protected void setup()</Metho de>

</Metho des>

<Roles /> </Agent> </Super_Class>

<Super_Class>

<Name_Super_Class>Agent_with_role</Name_Super_Class>

<Agent>

<name_Agent>Personne</name_Agent>

<Vars>

<Var>

<Name_Var>Sexe {Homme, Femme}</Name_Var> <Type_Var>enum</Type_Var>

</Var> <Var>

<Name_Var>name</Name_Var>

<Type_Var>String</Type_Var>

</Var> <Var>

<Name_Var>prenom</Name_Var>

<Type_Var>String</Type_Var>

</Var>

Chapitre 3 : Approche proposée et presentation de l~oatil d~veloppe

<Var> <Name_Var>date_naissance</Name_Var>

<Type_Var>String</Type_Var>

</Var> <Var>

<Name_Var>sexe</Name_Var>

<Type_Var>Sexe</Type_Var>

</Var> <Var>

<Name_Var>Pays_de_residence</Name_Var> <Type_Var>String</Type_Var>

</Var> </Vars> <Metho des>

<Metho de>public void set_name(String name)</Metho de>

<Metho de>public void set_prenom(String prenom)</Metho de>

<Metho de>public void set_pays(String pays)</Metho de>

<Metho de>public void set_date_naissance(int jour, int mois, int

annee)</Metho de>

<Metho de>public void set_sexe(Sexe sexe)</Metho de> <Metho de>public String get_name()</Metho de>

<Metho de>public String get_prenom()</Metho de> <Metho de>public String get_pays()</Metho de>

<Metho de>public String get_date_naissance()</Metho de> <Metho de>public Sexe get_sexe()</Metho de>

<Metho de>protected void setup()</Metho de>

<Metho de>protected void takeDown()</Metho de>

Chapitre 3 : Approche proposée et presentation de l~oatil d~veloppe

</Metho des>

<Roles />

</Agent>

</Super_Class>

<Super_Class>

<Name_Super_Class>Personne</Name_Super_Class> <Agent>

<name_Agent>Acheteur</name_Agent>

<Vars />

<Metho des>

<Metho de>protected void setup()</Metho de> <Metho de>protected void takeDown()</Metho de> </Metho des>

<Roles />

</Agent>

<Agent>

<name_Agent>Vendeur</name_Agent>

<Vars>

<Var>

<Name_Var>produits</Name_Var>

<Type_Var>ArrayList</Type_Var>

</Var>

</Vars>

<Metho des>

<Metho de>public void register_in_D F()</Metho de>

<Metho de>public void addProduct (produit p)</Metho de> <Metho de>public void DeleteProduct (produit p)</Metho de>

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

<Metho de>public ArrayList get_list_produits()</Metho de>

<Metho de>public boolean existe_produit( produit p)</Metho de> <Metho de>protected void setup()</Metho de>

<Metho de>protected void takeDown()</Metho de> </Metho des>

<Roles />

</Agent>

</Super_Class>

<Super_Class>

<Name_Super_Class>Acheteur</Name_Super_Class> <Agent>

<name_Agent>AgentA</name_Agent>

<Vars />

<Metho des>

<Metho de>protected void setup()</Metho de>

</Metho des>

<Roles>

<Role>

<Name_Role>Acheteur</Name_Role>

<List_Behaviour>

<Behaviour>

<Name_Behaviour>traiter_prix</Name_Behaviour> <Type_Behaviour>OneShotBehaviour</Type_Behaviour> </Behaviour>

<Behaviour>

<Name_Behaviour>demande</Name_Behaviour> <Type_Behaviour>OneShotBehaviour</Type_Behaviour>

Chapitre 3 : Approche proposée et presentation de l~oatil d~veloppe

</Behaviour>

<Behaviour> <Name_Behaviour>accepter_ou_rejeter_propose</Name_Behaviour> <Type_Behaviour>OneShotBehaviour</Type_Behaviour>

</Behaviour>

</List_Behaviour>

</Role> </Roles> </Agent> </Super_Class>

<Super_Class>

<Name_Super_Class>Vendeur</Name_Super_Class>

<Agent> <name_Agent>colporteur</name_Agent>

<Vars /> <Metho des>

<Metho de>protected void setup()</Metho de>

<Metho de>protected void takeDown()</Metho de>

</Metho des>

<Roles /> </Agent> <Agent> <name_Agent>telemarketing</name_Agent>

<Vars /> <Metho des>

<Metho de>protected void setup()</Metho de>

<Metho de>protected void takeDown()</Metho de>

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

</Metho des>

<Roles />

</Agent>

</Super_Class>

<Super_Class>

<Name_Super_Class>telemarketing</Name_Super_Class> <Agent>

<name_Agent>AgentB</name_Agent>

<Vars />

<Metho des>

<Metho de>protected void setup()</Metho de>

</Metho des>

<Roles>

<Role>

<Name_Role>telemarketing</Name_Role>

<List_Behaviour>

<Behaviour>

<Name_Behaviour>accepter_proposition</Name_Behaviour> <Type_Behaviour>OneShotBehaviour</Type_Behaviour> </Behaviour>

<Behaviour>

<Name_Behaviour>rejeter_proposition</Name_Behaviour> <Type_Behaviour>OneShotBehaviour</Type_Behaviour> </Behaviour>

<Behaviour>

<Name_Behaviour>enregisterD F</Name_Behaviour> <Type_Behaviour>OneShotBehaviour</Type_Behaviour>

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

</Behaviour> <Behaviour>

<Name_Behaviour>recevoir_message</Name_Behaviour> <Type_Behaviour>OneShotBehaviour</Type_Behaviour>

</Behaviour> </List_Behaviour>

</Role>

</Roles>

</Agent>

</Super_Class> </Diagram_Class_AUML>

<Diagram_Sequence_AUML>

<Message> <Transmitter>AgentA</Transmitter>

<Simple_Rceiver>

<Receiver>AgentB</Receiver> <Act_of_Communication>REQUEST</Act_of_Communication> <Content_of_message>donner moi la liste des produits

SVP</Content_of_message>

</Simple_Rceiver>

</Message>

<Message>

<Transmitter>AgentB</Transmitter>

<X0R_Receiver>

<Rceivers>

<Simple_Rceiver>

<Receiver>AgentA</Receiver>

<Act_of_Communication>RE FUSE</Act_of_Communication>

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

<Content_of_message>la liste des produits est vide</Content_of_message>

</Simple_Rceiver>

<Simple_Rceiver>

<Receiver>AgentA</Receiver> <Act_of_Communication>NOT_UNDERSTOOD</Act_of_Communication> <Content_of_message>pas compris</Content_of_message>

</Simple_Rceiver>

<Simple_Rceiver>

<Receiver>AgentA</Receiver> <Act_of_Communication>PROPOSE</Act_of_Communication>

<Content_of_message>La liste des produits disponible est: Computer DELL</Content_of_message>

</Simple_Rceiver>

</Rceivers> </X0R_Receiver>

</Message> <Message> <Transmitter>AgentA</Transmitter>

<X0R_Receiver>

<Rceivers> <Simple_Rceiver>

<Receiver>AgentB</Receiver> <Act_of_Communication>ACCEPT_PROPOSAL</Act_of_Communication>

<Content_of_message>la proposition est acceptable, Donnez moi le prix</Content_of_message>

</Simple_Rceiver> <Simple_Rceiver>

Chapitre 3 : Approche proposée et presentation de l~oatil d~veloppe

<Receiver>AgentB</Receiver> <Act_of_Communication>REJECT_PROPOSAL</Act_of_Communication>

<Content_of_message>rejeter Ia proposition</Content_of_message> </Simple_Rceiver>

</Rceivers>

</XOR_Receiver>

</Message>

<Message>

<Transmitter>AgentB</Transmitter>

<Simple_Rceiver>

<Receiver>AgentA</Receiver>

<Act_of_Communication>IN FORM</Act_of_Communication>

<Content_of_message>Ie prix du computer DELL est:" + "70000"

+"DA</Content_of_message>

</Simple_Rceiver>

</Message> <Message> <Transmitter>AgentA</Transmitter>

<XOR_Receiver>

<Receiver_with_Con dition>

<Receiver>AgentB</Receiver> <Act_of_Communication>CANCEL</Act_of_Communication>

<Content_of_message>Ignorer Ia demande</Content_of_message> <Content_of_Con dition> Prix > 50000 </Content_of_Con dition> </Receiver_with_Con dition>

</XOR_Receiver>

</Message> </Diagram_Sequence_AUML>

Chapitre 3 : Approche proposée et presentation de l~outil d~veloppe

</Diagrams_AUML> </Configuration>

Conclusion

Nous avons présenté dans ce chapitre l'approche proposée pour la génération d'une description graphique à travers les diagrammes AUML « le diagramme de classe et le diagramme de séquence» d'un programme JADE ainsi que pour la génération du fichier XML correspondant aux diagrammes générés. Nous avons également présenté notre outil implémentant l'approche proposée sur une étude de cas concrète.

Conclusion et _pers_pectives

Conclusion et perspectives

L'objectif de ce travail est de proposer une nouvelle approche pour, d'une part, la génération d'une description graphique à travers les deux principaux diagrammes d'Agent UML « diagramme de classe et de diagramme de séquence » à partir de programme JADE et, d'autre part, d'en générer un fichier XML qui permet de faire des traitements ultérieurs sur les diagrammes générés. Cette approche est supportée par un outil visuel implémentée dans l'environnement Eclipse permettant d'aider les utilisateurs de comprendre les applications JADE à travers les diagrammes AUML.

Comme perspectives à moyen termes, nous envisageons de :

ü Tenir compte des autres comportements « Behaviours » qui n'ont pas été traité par notre outil, en enrichissant le diagramme de séquence AUML par des nouveaux éléments de modélisation.

ü Étendre l'outil développé afin qu'il supporte la maintenance des applications JADE.

Generation des diagrammes AlliviL d partir de programmes JADE

Bibliographie

Bibliographie

ü [Mic05] : Mickael Albert, « Elaboration d'une passerelle AUML vers Jade », Ecole Polytechnique de l'Université de Nantes, 2005.

ü [Mou00] : A. MOUSSAOUI, « La planification de processus d'usinage dans un atelier intelligence artificielle », 2000.

ü [Fer05] : FERGUEN Adel, « La plate-forme JADE », 2005.

ü [Lot05] : Lotfi RAMDANI, « Systèmes Multi-Agents », Université Paris Sud XI, 2005.

ü [You09] : Youghourta BENALI, « Créez votre premier agent avec JADE et ECLIPSE », 2009.

ü [Zac09] : Zach Lewkovicz, « Plate-forme JADE », 2009.

ü [Oli02] : Olivier Fourdrinoy, « Création d'une librairie de Balises pour l'insertion d'agents JADE dans des pages Jsp », Faculté Jean Perrin, Université d'Artois, Lens, 2002.

ü [Tar06] : Tarek Jarraya, « Réutilisation des protocoles d'interaction et Démarche orientée modèles pour le développement multi-agents », Université de Reims Champagne Ardenne, 2006.

ü [Loï02] : Loïc Pélissier et Régis Lhoste, « Jade, Java Agent DEvelopment framework », 2002.

ü [Ben09] : Youghourta BENALI, « Les communications des agents JADE », 2009.

ü [Oli04]: Olivier Duro ET William Hoarau, « Systeme Multi-Agents», 2004.

ü [BYo09]: Youghourta BENALI, « Les Behaviours dans JADE», 2009.

ü [Gen03]: Geneva, Switzerland, « Foundation for Intelligent Physical Agents», 2003.

ü [Ste99]: stefano lorenzelli, « Agent UML », 1999.

ü [Jam00] : James Odell, H. Van Dyke Parunak, Bernhard Bauer, « Extension de UML pour des systèmes basés agents »,2000 .

ü [Sté05] : Stéphane Daviet, Fabrice Guillet, Henri Briand, Adina Magda Florea, Vincent Philippé, « modélisation des interactions entre individus avec Agent UML », 2005.

ü [Bra10] : Brakni Ilhem, « Planification multi-agents pour la composition dynamique », Université de Tébessa -Algérie-, 2010.

Generation des diagrammes AllitiC d partir de programmes JADE

Bibliographie

ü [Zei09]: Zeineb Graja, « méthode formaad: vers une approche dirigée par les modèles pour la conception d'applications à base d'agents », université de Sfax faculté des sciences économiques, 2009.

ü [Ale03]: Alexandre VIOLLET, « Un protocole entre agents pour l'alignement d'ontologies », université Joseph Fourier (UJF), 2003/2004.

ü [1]: http://www.freewebs.com/fresma/Formation/UML/UML-11-Paquetage.pdf

ü [2]: http://turing.cs.pub.ro/auf2/html/chapters/chapter6/chapter 6 3 1.html

ü [3]: http://theses.univ-

lyon3.fr/documents/getpart.php?id=lyon3.2010.dongmo c&part=244435

ü [4]: http://theses.univ-

lyon2.fr/documents/getpart.php?id=lyon2.2008.nfaoui eh&part=152229

ü [5] : www.emse.fr/~vercouter/cours/.../presentation Jade Wade.ppt

ü [6] : http://turing.cs.pub.ro/auf2/html/chapters/chapter6/chapter 6 5 1.html

ü [7] : http://turing.cs.pub.ro/auf2/html/chapters/chapter6/chapter 6 5 2.html

ü [8] : http://www.loria.fr/~chevrier/Enseign/PRIM3 10/jade.pdf

ü [9] : http://20-notes-sur-java-pour-le-web.over-blog.com/article-3279214.html

ü [10] : http://www.agora.2ia.net/mediawiki/index.php?title=Jade

ü [11]: http://turing.cs.pub.ro/auf2/html/chapters/chapter5/chapter 5 4 1.html