Module: Les Systèmes Multi-Agents

Les plateformes de développement

Orientées SMA
Cas de la plateforme Jade
TP4, TP5, TP6

Master2, Informatique, Sétif

25 novembre 2019

1 Les plateformes de développement Orientées SMA

Les environnements de développement ou les plates-formes multi-agent sont néces-

saires pour renforcer le succès de la technologie multi-agent. Les plates-formes multi-
agent permettent aux développeurs de concevoir et réaliser leurs applications sans perdre
de temps à réaliser des fonctions de base pour la création et l’interaction entre agents et
éliminent, dans la plupart des cas, la nécessité d’être familier avec les différents concepts
théoriques des systèmes multi-agent.
Dans cette section nous présentons sommairement quelques plates-formes de déve-
loppement de SMA.
Il existe un nombre important d’environnements de développement des applications
orientées agents : il y a aussi bien des produits commerciaux que des logiciels dans le
domaine public. Parmi les plates-formes fournies comme logiciels libres, il y a quelques
unes plus connues pour avoir été utilisées dans le développement de plusieurs applica-
tions : JADE, M ACE, ZEU S et M ADKIT pour les agents cognitifs, et SW ORM pour
les agents réactifs. Il faut noter que cette liste n’est pas unique, et qu’il y a aussi d’autres
plates-formes qui ont été utilisées avec beaucoup de succès pour bâtir diverses applica-
tions.

1
1.0.1 JADE (Java Agent Development Framework)

JADE (Java Agent Development Framework) est une plate-forme multi-agent déve-
loppée en Java par CSELT (Groupe de recherche de Gruppo Telecom, Italie) qui a comme
but la construction des systèmes multi-agent et la réalisation d’applications conformes à
la norme FIPA. JADE comprend deux composantes de base :
- Une plate-forme agents compatible FIPA et
- Un paquet logiciel pour le développement des agents Java.
La plate-forme multi-agent JADE sera présentée dans la section 2, car c’est cette plate-
forme que nous utiliserons dans ce présent cours et TP.

1.0.2 MACE

MACE est le premier environnement de conception et d’expérimentation de diffé-

rentes architectures d’agents dans divers domaines d’application. Dans MACE, un agent
est un objet actif qui communique par envoi de messages. Les agents existent dans un
environnement qui regroupe tous les autres agents et toutes les autres entités du sys-
tème. Un agent peut effectuer trois types d’actions : changer son état interne, envoyer
des messages aux autres agents et envoyer des requêtes au noyau MACE pour contrô-
ler les événements internes. Chaque agent est doté d’un moteur qui représente la partie
active de l’agent. Ce moteur détermine l’activité de l’agent et la façon dont les messages
sont interprétés. MACE a été utilisé pour développer des simulations d’applications dis-
tribuées.

1.0.3 ZEUS

ZEUS est une plate-forme multi-agent conçue et réalisée par British Telecom (Agent
Research Programme of BT Intelligent Research Laboratory) pour développer des appli-
cations collaboratives. ZEUS est écrit dans le langage Java et il est fondé sur les travaux de
la FIPA. L’architecture des agents ZEUS est similaire à la majorité des agents collaboratifs.
Elle regroupe principalement les composantes suivantes :
— une boîte aux lettres et un gestionnaire de messages qui analyse les messages de
la boîte aux lettres et les transmet aux composantes appropriées ;
— un moteur de coordination ;
— un planificateur qui planifie les tâches de l’agent en fonction des décisions du mo-

2
 teur de coordination, des ressources disponibles et des spécifications des tâches ;
plusieurs bases de données représentant les plans connus par l’agent, les res-
sources et l’ontologie utilisée ;
— un contrôleur d’exécution qui gère l’horloge locale de l’agent et les tâches actives.
— L’environnement comporte trois bibliothèques : une avec des agents utilitaires,
une avec des outils pour la construction des agents, et une avec des composants
agents.
ZEUS met un fort accent sur la méthodologie de développement, fondée sur la no-
tion de rôle. ZEUS a été utilisé pour développer plusieurs applications réelles comme
les ventes aux enchères et la simulation de la fabrication des ordinateurs. Les caractéris-
tiques des domaines d’applications de ZEUS ont été définies par les concepteurs ; parmi
ces caractéristiques, on peut mentionner :
- chaque agent crée un plan qui nécessite un raisonnement explicite pour atteindre
son but ;
- la résolution de problèmes nécessite une coopération entre agents ;
- le rôle de chaque agent consiste à contrôler un système externe qui réalise une
tâche du domaine d’application, la résolution de problème est ainsi effectuée par
ce système externe et contrôlée par les agents.

1.0.4 MADKIT

MADKIT [Gutknecht et Ferber, 2001] est une plate-forme développée par le Labora-
toire d’Informatique, de Robotique et de Microélectronique de Montpellier (LIRMM) de
l’Université Montpellier II. MADKIT est libre pour l’utilisation dans l’éducation. MAD-
KIT est écrit en Java et est fondé sur le modèle organisationnel ALAADIN (agent, groupe
et rôle). Il utilise un moteur d’exécution où chaque agent est construit en partant d’un
micro-noyau. Chaque agent a un rôle et peut appartenir à un groupe. Il y a un environ-
nement de développement graphique qui permet facilement la construction des applica-
tions.

1.0.5 SWARM

SWARM est une plate-forme multi-agent avec agents réactifs. L’inspiration du modèle
d’agent utilisé vient de la vie artificielle. SWARM est l’outil privilégié de la communauté
américaine et des chercheurs en vie artificielle. L’environnement offre un ensemble de

3
bibliothèques qui permettent l’implémentation des systèmes multi-agent avec un grand
nombre d’agents simples qui interagissent dans le même environnement.

1.0.6 netLogo

Un cours complet sera dédié à cette plaeforme.

NB : Pour ce présent cours dédié aux masters, informatique, Sétif, nous avons opté pour
la plateforme de développement Jade.

2 La plateforme Jade

2.1 Bref description de JADE

JADE (Java Agent DEvelopement framework) est une plate-forme multi-agent créé
par le laboratoire TILAB (Telecom Italia SPA).
JADE permet le développement de systèmes multi-agents et d’applications conformes
aux normes FIPA. Elle est implémentée en JAVA et fourni des classes qui implémentent «
JESS » pour la définition du comportement des agents.
JADE possède trois modules principaux (nécessaires aux normes FIPA).
— DF « Director Facilitor » fournit un service de « pages jaunes» à la plate-forme ;
— ACC «Agent Communication Channel » gère la communication entre les agents ;
— AMS « Agent Management System » supervise l’enregistrement des agents, leur
authentification, leur accès et l’utilisation du système.
Ces trois modules sont activés à chaque démarrage de la plate-forme.

2.2 La norme FIPA

La FIPA (Foundation for Intelligent Physical Agents) est une organisation à but non
lucratif fondée en 1996 dont l’objectif est de produire des standards pour l’interopération
d’agents logiciels hétérogènes. Par la combinaison d’actes de langages, de logique des
prédicats et d’ontologies publiques, la FIPA cherche à offrir des moyens standardisés
permettant d’interpréter les communications entre agents de manière à respecter leur
sens initial, ce qui est bien plus ambitieux que XML, qui ne standardise que la structure
syntaxique des documents. Afin d’atteindre ce but, le FIPA émet des standards couvrant :

4
 — Les applications (applications nomades, agent de voyage personnel, applications
de diffusion audiovisuelles, gestion de réseaux, assistant personnel. . . ) ;
— Les architectures abstraites, définissant d’une manière générale les architectures
d’agents ;
— Les langages d’interaction (ACL), les langages de contenu (comme SL, CCL, KIF
ou RDF) et les protocoles d’interaction ;
— La gestion des agents (nommage, cycle de vie, description, mobilité, configura-
tion) ; Le transport des messages : représentation (textuelle, binaire ou XML) des
messages ACL, transport (par IIOP, WAP ou HTTP) de ces messages.
Ces standards évoluent, et sont régulièrement mis à jour, ainsi que de nouveaux stan-
dards qui sont nouvellement proposés. Les standards qu’édicte la FIPA ne constituent
pas vraiment une plate-forme de construction multi-agents. Ce n’est pas non plus l’ob-
jectif que s’est fixé la FIPA. Tout au plus, la FIPA normalise une plate-forme d’exécution
standardisée dans un but d’interopérabilité.
Ces normes s’appliquent donc pour la plupart en phase de déploiement. Elles n’abordent
pas les phases d’analyse ni de conception. Elles peuvent cependant guider certains choix
d’implémentation.
Dans la plate-forme JADE, deux méthodes sont fournies par la classe Agent afin d’ob-
tenir l’identifiant de l’agent DF par défaut et celui de l’agent AMS : getDefaultDF() et res-
pectivement getAMS(). Ces deux agents permettent de maintenir une liste des services
et des adresses de tous les autres agents de la plate-forme. Le service DF propose quatre
méthodes afin de pouvoir :
— Enregistrer un agent dans les pages jaunes (register).
— Supprimer un agent des pages jaunes (deregister).
— Modifier le nom d’un service fourni par un agent (modify).
— Rechercher un service (search).
Le service AMS s’utilise généralement de manière transparente (chaque agent créé est
automatiquement enregistré auprès de l’AMS et se voit attribué une adresse unique). Ces
deux services fournissent donc les annuaires qui permettent à n’importe quel agent de
trouver un service ou un autre agent de la plate-forme.

5
 F IGURE 1 – Architecture logicielle de La plate-forme JADE

2.3 Langage de communication de la plate-forme JADE

Le langage de Communication de la plate-forme JADE est FIPA-ACL (Agent Com-

munication language). La classe ACLMessage représente les messages qui peuvent être
échangés par les agents.
La communication de messages se fait en mode asynchrone. Lorsqu’un agent sou-
haite 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(). Lorsqu’un agent souhaite
recevoir un message, il doit employer la méthode receive() ou la méthode blockingReceive().
Un message ACL dispose obligatoirement des champs de la Table-1.
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.

6
 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

TABLE 1 – Les performatives en Jade

2.4 Comportements des agents dans la plate-forme JADE

Un agent 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 chaque comportement qui le compose
est en fait un objet de type Behaviour. Des agents multi-thread peuvent être créés mais il
n’existe pour l’heure actuelle aucun support fournis par la plate-forme (excepté la syn-
chronisation de la file des messages ACL). Afin d’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 « ready » 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 d’une méthode action(), qui constitue le traite-
ment à effectuer par celui-ci. Ainsi que d’une méthode done(), qui vérifie si le traitement
est terminé.
Dans les détails, l’ordonnanceur exécute la méthode action() de chaque objet Behaviour
présent dans la file des tâches de l’agent. Une fois cette méthode terminée, la méthode
done() est invoquée. Si la tâche a été complétée alors l’objet Behaviour est retiré de la file.
L’ordonnanceur est non-préemptif et n’exécute qu’un seul comportement à la fois, on

7
peut donc considérer la méthode action() comme étant atomique. Il est alors nécessaire de
prendre certaines précautions lors de l’implémentation de cette dernière, à savoir éviter
des boucles infinies ou des opérations trop longues. La façon la plus classique de pro-
grammer un comportement consiste à le décrire comme une machine à états finis. L’état
courant de l’agent étant conservé dans des variables locales.
Enfin, il existe également quelques méthodes supplémentaires afin de gérer les objets
Behaviour :
— reset() qui permet de réinitialiser le comportement ;
— onStart() qui définit des opérations à effectuer avant d’exécuter la méthode action() ;
— onEnd() qui finalise l’exécution de l’objet Behaviour avant qu’il ne soit retiré de
la liste des comportements de l’agent ;
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, par exemple la classe SequentialBehaviour est supportée et exécute des sous-
comportements de manière séquentielle. Toutes les classes prédéfinies dans JADE hérite
de la classe Abstraite Behaviour. On peut les citer :
— Classe SimpleBehaviour (abstraite) : modélise un comportement simple. Sa mé-
thode reset() n’effectue aucune opération.
— Classe CompositeBehaviour (abstraite) : modélise un comportement composé.
Les actions effectuées par cette classe sont définies dans les comportements en-
fants.
— Classe F SM Behaviour : Cette classe hérite de CompositeBehaviour et éxecute
des comportements enfants suivant un automate à états finis défini par l’utilisa-
teur. Lorsqu’un comportement enfant termine, sa valeur de fin retournée par la
fonction onEnd() indique le prochain état à atteindre. Le comportement corres-
pondant à cet état sera exécuté à la prochaine exécution de la classe. Elle se termine
lorsque qu’un comportement associé à un état final à été exécuté.
— Classe SenderBehaviour : elle étend la classe OneShotBehaviour et encapsule une
unité atomique qui effectue une opération d’envoie de message.
— Classe ReceiverBehaviour : Elle encapsule une unité atomique qui effectue une
opération de reception de message. Ce comportement s’arrête dès qu’un message
a été reçu. S’il n’y a pas de message dans la file d’attente de l’agent ou que le
message ne correspond pas au MessageTemplate du constructeur de cette classe,

8
 alors il se met en attente.
On peut aussi citer d’autres classes par exemples :
- Classe W akerBehaviour (abstraite),
- Classe P arrallelBehaviour,
- Classe SequentialBehaviour,
- Classe CyclicBehaviour(abstraite),
- Classe OneShotBehaviour (abstraite).

NB : Les behaviours précédents seront expliqués en cours.

3 Travaux Pratiques

3.1 Explication :

Soient trois agents fibo (suite de Fibonacci), carre et classeur :

f ibo : fn+2 = fn+1 + fn

avec : f0 = 0, f1 = f2 = 1
donc :
agF ibo produit {0, 1, 1, 2, 3, 5, 8, 13, 21, 34, ...}
agCarre produit {0, 1, 4, 9, 16, 25, ...}
et un agent agClasseur procède au classement des nombres envoyés, au fur et à me-
sure du traitement, par agF ibo et agCarre.
agClasseur produit donc {0, 0, 1, 1, 1, 2, 3, 4, 5, 8, 9, ...}

9
3.2 Contenu du TP :

Ce TP dédié au déploiement d’agents par la plateforme Jade.

3.2.1 Scénario

Il est demandé d’implémenter, en Java/Jade, le scénario de déploiement suivant :

— L’agent agClasseur envoie un message simultané aux agents :
* agF ibo dont le contenu est : "Merci agent Fibo de m’envoyer une suite de nombres
de Fibonacci !" ;
* agCarre dont le contenu est : "Merci agent Carre de m’envoyer une suite de nombres
de Carre !" ;
— L’agent agF ibo répond par "Ok je suis d’accord !" à agClasseur et commence à pro-
duire des nombres de Fibonacci.
— L’agent agCarre répond par "Ok je suis d’accord !" à agClasseur et commence à
produire des nombres carrés.
— L’agent agClasseur récupère, au fur et à mesure, les nombres générés par agF ibo
et agCarre et, dès que le nombre de nombres générés par chaque agent arrive à
N (entier), l’agent agClasseur envoie un message aux agents agF ibo et agCarre,
leur disant, "Merci c’est terminé !", provoquant l’arrêt d’envoi de nombres par ces
deux agents.
— Les agents agF ibo, agCarre et agClasseur mettent fin à leurs cycles de vie.

3.2.2 TP4, Plateforme Jade, Behaviours

— Télécharger le fichier jade.jar.

— Lancer l’outil graphique de Jade et familiarisez-vous avec les agents proposés
(AMS, DF,ACC) ainsi que la notion de Containers.
— Déployer les agents agClasseur, agCarre et agF ibo en codant les différents scripts
(Behaviours).

3.2.3 TP5, Plateforme Jade, Communication

Déployez le scénario décrit auparavant, en insistant sur la communication et l’envoi

de message entre les trois agents.

10
 L’exécution peut se faire en mode console (Pas besoin d’interface graphique). Le com-
portement, par le biais d’affichage du déroulement du scénario, doit se faire sur trois
containers différents.

3.2.4 TP6, Déploiement sur réseau :

Déployez votre scénario sur réseau, un container sur chaque host.

1. agClasseur sur Container1 associé à host1 .

2. agCarre sur Container2 associé à host2 .

3. agF ibo sur Container3 associé à host3 .

Le responsable de la matière SMA,

Abdelhafid Benaouda

11