Vue d’ensemble du paquetage EASI

Le paquetage EASI pour MadKit a ´et´e d´evelopp´e de fa¸con `a permettre les communications multi-parties tout en b´en´eficiant d’une infrastructure d´ej`a existante. Il s’agit donc d’une bi- blioth`eque pour la mise en oeuvre du mod`ele EASI, contenant `a la fois l’environnement et les primitives d’accession `a celui-ci. Les messages sont transmis directement dans la boˆıte aux lettres des agents, comme pour une communication par le noyau.

La distribution des messages est effectu´ee par l’environnement et non plus seulement par le noyau MadKit, comme l’illustrent les figures 6.12 et 6.13. La plate-forme distribue les messages par invocation d’une m´ethode du micro-noyau, laquelle effectue la s´election des r´ecepteurs et d´epose le message dans leurs boˆıtes aux lettres. Dans le cadre du paquetage EASI, le noyau n’est utilis´e que lors de la phase d’initialisation des agents, pour d´ecouvrir l’environnement. L’agent peut choisir pour communiquer d’utiliser soit le noyau de MadKit, soit l’environnement.

Noyau

message (id, groupe, rˆole)

Figure 6.12 – Fonctionnement initial de MadKit

La figure 6.14 donne le passage de l’architecture abstraite introduite en d´ebut de chapitre `a cette impl´ementation, en pr´ecisant les diff´erents flux d’information dans le paquetage. Les modules fonctionnels sont r´epartis entre deux composants, l’environnement et le syst`eme-expert. Nous avons choisi l’environnement de d´eveloppement de syst`emes `a base de r`egles JESS [Hill, 2003] pour impl´ementer l’environnement de communication. Il s’agit de syst`emes experts fond´es sur les arbres RETE [Forgy, 1982] ´ecrit en Java. Nous avons choisi les arbres RETE car, tout comme nos propres algorithmes (section 4.4), il sont fond´es sur une pr´e-classification des entit´es pour am´eliorer l’efficacit´e de l’appariement.

Du fait de la philosophie MadKit du “tout est agent”, l’environnement est encapsul´e en tant qu’agent. Il est activ´e par les agents localement par une invocation directe. Il v´erifie la syntaxe

6.3. Une biblioth`eque pour la plate-forme MadKit environnement Noyau Noyau environnement message (filtres)

(id, groupe, rˆole)

Figure 6.13 – Initialisation et fonctionnement du paquetage EASI

donn´ees module fonctionnel lois flux (description) flux (filtre) flux (message) flux (autre)

v´erification ´etat filtres

´etat transmission Agent Kernel Environnement Syst`eme expert JESS communication cycle de vie groupes et roles

Figure 6.14 – Flux d’informations du paquetage pour MadKit

des filtres et des descriptions qui lui sont transmis, puis modifie la base de r`egles (respective- ment de faits) du syst`eme-expert. Lorsqu’un message est ajout´e, celui-ci est stock´e le temps de l’appariement. Lorsqu’un couple agent/message est trouv´e par le syst`eme-expert, celui-ci active la transmission du message pour l’agent via l’environnement.

nement se charge de faire le lien entre les actions des agents et la gestion du syst`eme-expert. Il est `a noter que dans cette impl´ementation, il est possible de cr´eer plusieurs environnements de communication fonctionnant en parall`ele, comme cela a ´et´e r´ealis´e dans la section 7.1.2.

Une impl´ementation avec JESS Nous introduisons ici les ´equivalences entre les actions des agents et leur r´epercussion sur le syst`eme expert.

En langage objet, les cat´egories d’entit´es sont des classes diff´erentes. A cette fin, nous d´eclarons les diff´erentes classes avant de les utiliser pour l’appariement :

( d e f c l a s s agent EASIAgent )

Une fois les classes d´efinies, chaque entit´e est ajout´ee grˆace `a un appel `a definstance ou enlev´ee (undefinstance). Un raccourci int´eressant propos´e par JESS est la traduction de tous les attributs d’une classe impl´ement´ee sous forme de Java Beans en tant que champs de l’objet dans le syst`eme. De la mˆeme fa¸con, la mise `a jour est r´ealis´ee de fa¸con automatique via la fonction update.

Les filtres sont de la forme (partie gauche implique partie droite), auxquels sont ajout´es le nom et la priorit´e du filtre.

Arguments: name , p r i o r i t y , lhs , rhs ( d e f r u l e name l h s ( not ( e x i s t s ( messageEnvironment ( i d ? i d ) ( r e c e i v e d ? r e c e i v e r ) ) ) ) => rhs ( a s s e r t ( messageEnvironment ( i d ? i d ) ( r e c e i v e d ? r e c e i v e r ) ) ) )

Nous avons choisi d’ajouter `a chaque message une liste de faits indiquant les agents ayant d´ej`a re¸cu ce message. Grˆace `a cela, un mˆeme agent ne re¸coit pas plusieurs fois le mˆeme message si plusieurs filtres sont valides. Il est `a noter que dans certains contextes applicatifs, il peut ˆetre pr´ef´erable de laisser l’agent recevoir plusieurs fois le mˆeme message grˆace `a des filtres diff´erents. En effet, la connaissance du filtre par lequel la transmission est r´ealis´ee apporte une information suppl´ementaire `a l’agent sur son contexte. Ce fonctionnement est le cadre g´en´eral de l’algorithme.

Le retrait s’effectue `a l’inverse par un undefrule.

Un exemple de r`egle ´ecrite avec le langage JESS est un filtre pour l’´ecoute flottante pos´e par un agent a1 :

( d e f r u l e ecoute

( agent ( i d ? r e c e i v e r ) (OBJECT ?a ) )

?me<−(messageedt ( i d ? i d ) (OBJECT ?m) ( sender ? sender ) ) ( agent ( i d ? sender ) ( type ” c l i e n t ” ) )

6.4. Conclusion ( t e s t ( eq ? r e c e i v e r ”a1” ) ) ( not ( e x i s t s ( messageEnvironment ( i d ? i d ) ( r e c e i v e d ? r e c e i v e r ) ) ) ) => ( c a l l ?a p e r c e i v e ?m) ( a s s e r t ( messageEnvironment ( i d ? i d ) ( r e c e i v e d ? r e c e i v e r ) ) ) )

Le terme OBJECT permet de d´esigner un objet du langage JAVA. Cette r`egle permet `a l’agent a1 d’´ecouter tous les messages ´emis par les agents dont la propri´et´e type a pour valeur client.

6.4

Conclusion

Dans ce chapitre, nous avons introduit diff´erents outils de mise en oeuvre de notre mod`ele d’environnement de communication. Nous avons tout d’abord introduit une architecture abs- traite de l’environnement, et d´evelopp´e les diff´erents modules aff´erants. Nous avons discut´e son lien avec l’architecture de r´ef´erence propos´ee par [Weyns et al., 2007], et une architecture d’agent minimale.

Ensuite, nous avons propos´e un prototype d’environnement de communication r´ealis´e en Java. La distribution du syst`eme multi-agents est r´ealis´ee par une architecture client-serveur. Nous avons ´etendu le langage RuleML pour obtenir une description satisfaisante des filtres et montr´e comment la gestion des algorithmes propos´es en section 4.4 est effectu´ee par des structures appropri´ees.

Enfin, nous avons montr´e l’int´egration d’une biblioth`eque pour l’environnement de commu- nication au sein d’une plate-forme existante - MadKit - et les effets sur son fonctionnement. Nous avons ´egalement propos´e une gestion des descriptions et filtres par le biais d’un syst`eme expert.

Les impl´ementations des mod`eles EASI et EARI ont donn´e lieu `a des exp´erimentations, les- quelles sont expos´ees dans le chapitre suivant. Ensuite, nous approfondissons la fa¸con d’exploiter nos mod`eles grˆace `a des protocoles opportunistes, et nous montrons comment le mod`ele EARI permet la mise en oeuvre de mod`eles d’interactions norm´es.

Chapitre 7

Exp´eriences et ´el´ements

d’exploitation des mod`eles

Sommaire

7.1 Exp´erimentation du mod`ele EASI `a l’aide d’un syst`eme expert . . 150 7.1.1 Impl´ementation du mod`ele par un arbre RETE . . . 150 7.1.2 Exp´eriences . . . 152 7.2 Impl´ementation des mod`eles EASI et EARI `a l’aide d’algorithmes

adapt´es . . . 159 7.2.1 Evaluation du mod`ele EASI . . . 160 7.2.2 Evaluation du mod`ele EARI . . . 164 7.3 Exploitation des mod`eles EASI et EARI . . . 167 7.3.1 D´efinition de protocoles opportunistes . . . 167 7.3.2 Mise en oeuvre d’un syst`eme multi-agents norm´e fond´e sur la logique

d´eontique . . . 170 7.4 Conclusion . . . 173

Dans ce chapitre, nous introduisons tout d’abord les r´esultats des exp´erimentations men´ees sur la gestion des communications multi-parties. En particulier, nous ´etudions l’impl´ementation de l’environnement par un arbre RETE, ainsi que par nos algorithmes fond´es sur la pr´e- classification des entit´es.

En seconde partie, nous exposons des ´el´ements d’exploitation des mod`eles EASI et EARI. Nous proposons une nouvelle notation AUML pour les communications multi-parties, et l’utili- sons pour la d´efinition de protocoles opportunistes. Nous montrons ensuite comment instancier au sein de l’environnement un mod`ele norm´e fond´e sur la logique d´eontique.

7.1

Exp´erimentation du mod`ele EASI `a l’aide d’un syst`eme ex-

pert

Nous avons d´ecrit en section 6.3 une biblioth`eque pour la mise en oeuvre du mod`ele sur la plate-forme MadKit. Comme nous l’avons soulign´e en section 6.13, les filtres peuvent ˆetre consid´er´es comme des r`egles, et les descriptions des entit´es comme des faits. Nous nous int´eressons donc ici aux performances li´ees `a l’utilisation d’un syst`eme-expert pour g´erer l’environnement.

Un syst`eme `a base de r`egles est constitu´e de trois parties, le moteur d’inf´erence, la base de r`egles et la base de faits. Un fait peut d´eclencher une r`egle, et ce processus est g´er´e par le moteur d’inf´erence. Nous avons choisi de mod´eliser les entit´es en tant que faits, et les conditions de r´eception en tant que r`egles. En pratique, l’ajout d’une entit´e Message pourra donc d´eclencher une ou plusieurs r`egle(s) d’envoi de ce message. L’agent Environnement, une fois lanc´e, initialise le syst`eme expert, puis ne g`ere que les inscriptions des agents dans l’environnement, par un ´echange initial de messages avec l’agent demandeur. La biblioth`eque est centralis´ee, ce qui permet aux agents d’utiliser directement les m´ethodes de l’environnement.