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-aricace
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, Souaaret
Ch.otaia
taus ie. s memtres de ca_famitie .ECYR Y
et ale 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
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
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~
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]
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
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>
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
|