Conception et réalisation d'un système multi- agents pour les enchères en ligne

Bibliographie

[RDJ, 99] Robert ORFALI, Dan HARKEY, Jerri EDWARDS

Titre: CLIENT/SERVEUR GUIDE DE SURVIE

Date : Novembre 1999

[BRN, 95] Bernard Fabrot

Titre : Réinstaller Windows

Date : 1995

[ROU,02] Siegfried Rouvrais, Université de Rennes

Titre : « Utilisation d'agents mobiles pour la construction de

services distribués »

Date : Juillet 2002

[DCO,95] Douglas Comer, tcp/ip

Titre : architecture, protocoles, applications

Date : 2005

[ Fig ,1] Image : Architecture client-serveur

Lien : http://www.mpandco.com/images/client_serveur.jpg

[FRA, 04] Laurent Franck

Titre : architecture client/serveur,

département de génie électrique en informatique, INSA de Toulouse Date : 2004

[CAB, 07] Cabani Adnane

Titre : these pour obtenir le titre de docteur en informatique

Réseaux pair a pair et simulation distribuées Application a la simulation Multi-agent

Date :16/7/2008

[ferb,95] Les Systèmes Multi-Agents-Ferber, J --Inter Editions, 1997.

[woold,2001] An Introduction to MultiAgent Systems--Wooldridge, M. --Wiley 2002.

[Brio t,2001] Principes et Architectures des SMA--Briot, J.-P.,

Demazeau, Y., -I Hermes, 2001.

in agent-based systems, Proceedings of the first European Conference on Cognitive Science'95:117-132, 1995

[Ferber, 1995] Ferber J., Les systèmes multi-agents : vers une intelligence

collective, InterEditions, ISBN : 2-72-96-0572-X, 1995.

[Ferber, 1999] Ferber J., Multi-Agent Systems - An introduction to distributed
artificial intelligence, Addison-Wesley, ISBN 0-201-36048-9, 1999.

[Maes, 1995] Maes P., Intelligent Software, Scientific American, volume 273,
numéro 3, septembre 1995, pp.84-86.

[Drogoul, 1998] A. Drogoul, J.-D. Zucker, LIP6 1998/041: Rapport de Recherche LIP6 - 30 pages -Octobre/October 1998

[Varela, 1989] Varela F., Connaitre les sciences cognitives : tendances et perspectives.

Paris : Seuil, ISBN : 2-02-010474-1, 126 p, 1989.

[BIB 01] Il y a beaucoup des articles qui expliquent PersonaLogic, Bargain Finder

et Jango (et qui les comparent avec leurs alternatives), il suffit de faire une recherche sur google.

[BIB 02] Chavez Anthony, Pattie Maes, "Kasbah: An Agent MarketPlace

for Buying and Selling Goods", in proceedings of The First International Conference on The Practical Application of Intelligent Agents and

Multi-Agent Technology (PAAM"96), pp. 75-90, 1996. Asc/ [e-mail]

[BIB 03] R. Guttman and P. Maes, "Agent-mediated Integrative Negotiation

Retail Electronic Commerce." in the proceedings of

the Workshop on Agent Mediated Electronic Trading (AMET"98), Minneapolis, Minnesota, April 1998.

[BIB 04] P. Wurman, M. Wellman, and W. Walsh, "The Michigan

Internet AuctionBot: A Configurable Auction Server

for Human and Software Agents." in proceedings of the Second

International Conference on Autonomous Agents (Agents"98), May 1998.

"Representing agent interaction protocols in UML".

[BEL 00] Bellifemine F., Giovani C., Tiziana T. Rimassa G., "Jade Programmer's

Guide" Jade version 2.6 ( http://www.fipa.org/specs/fipa00001/), 2000.

[BEL 99] Bellifemine F., Poggi A., Rimassa G., "JADE -- A FIPA-compliant
agent framework", CSELT internal technical report. Part of this report has been also published in Proceedings of PAAM'99, London, pp.97-108, April 1999.

Annexe A.

~ Le progres technologique n'abolitpas les obstacles; il en change simplement la nature o - Huxley, Aldous

La plate~~orme Jade

Java A_gent DEvelopment Framework

1. Introduction

Pour construire un s_ystème multi-a_gent (SMA) on utilise une plate-forme multi-a_gent. Une plate-forme multi-a_gent est un ensemble d'outils nécessaire a la construction et a la mise en service d'a_gents au sein d'un environnement spéci fique. Ces outils peuvent servir é_galement ' l'anal_yse et au test du SMA ainsi créé. Ces outils peuvent etre sous la forme d'environnement de pro_grammation (API) et d'applications permettant d'aider le développeur. Nous allons étudier dans cette partie la plate-forme JADE(Java A_gent DEvelopment framework).

2. Bref description de JADE

JADE (Java A_gent DEvelopement framework) est une plate-forme multi-a_gent créé par le laboratoire TILAB et décrite par Belli femine et al. Dans [BEL 99], [BEL 00]. Elle permet le développement de s_ystèmes multi-a_gents et d'applications con formes aux normes FIPA. Elle est implémentée en JAVA et fourni des classes qui implémentent o JESS » pour la dé finition du comportement des a_gents. JADE possède trois modules principaux (nécessaire aux normes FIPA).

· DF « Director Facilitor » ;

· ACC «Agent Communication Channel »;

· AMS « Agent Management System ».

Ces trois modules sont activés à chaque démarrage de la plate-forme.

3. Architecture logiciel de la plate-forme JADE

Chaque instance de l'environnement d'exécution de JADE s'appelle un conteneur (container) car il peut contenir plusieurs a_gents. L'ensemble des conteneurs acti fs s'appelle une plate forme. Dans une plate forme, un conteneur spécial appelé conteneur principal (Main-container) doit toujours etre en activité, les autres conteneurs s'enre_gistrent auprès de celui-ci des qu'ils démarrent. Le conteneur principal héber_ge les a_gents techniques de Jade (DF, AMS, RMA, Dumm_yA_gent, ...).

La fi_gure suivante représente des modules sous forme des services de base qui sont le Director_y Facilitator (DF) et l'A_gent Mana_gement S_ystem (AMS), mais le service (MTS) sera char_gé a la demande, L'AMS est un autre composant important car ce service e ffectue la correspondance entre l'a_gent et leur identi ficateur (AID), Il n'_y a qu'un AMS par plate-forme.

Fig.1 : Architecture logiciel de La plate-forme JADE.

4. Architecture de la bibliotheque des classes

JADE est compose des packa_ges suivantes :

- JADE.CORE : implante le no_yau du s_ysteme et possede les classes 'Agent' et'behaviours' - Le package JADE.LANG : contient un sous packa_ge' JADE.LANG.ACL' pour chaque lan_ga_ge de communication utilise jade.

- JADE.CONTENT : contient l'ensemble du classes qui definissent les ontolo_gie.

- JADE.DOMAIN : contient toutes les classes java qui representent les entites a_gent mana_gement definies par FIPA particulierement AMS, DF.

- JADE.GUI : contient les classes utiles pour creer des GUIs,l'edition des messa_ges et la description des a_gents.

- JADE.MTP : contient une interface java que chaque MIP (MESSAGE TRANSPORT PROTOCOL) doit implementer.

- JADE.PROTO : contient les classes qui modelisent les protocoles standards d'interaction, et permettre aux pro_grammeurs d'ajouter d'autres protocoles.

5. Outils de debogage de JADE

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 (agentification de service).

5.1. Agent RMA (Remote Management Agent) :

Le RMA permet de contrôler le c_ycle de vie de la plate-forme et tous les a_gents la composant. L'architecture répartie de JADE permet le contrôle a distance d'une autre plate-forme. Plusieurs RMA peuvent etre lances sur la meme plate-forme du moment qu'ils ont des noms distincts.

Figure 2 : L'interface de l'agent RMA

5.2. Agent Dammy

Cette interface permet la composition et l'envoi de messa_ges ACL et maintient une liste de messa_ges ACL envo_yés et re_cus. Cette liste peut etre examinée par l'utilisateur et chaque messa_ge peut etre vu en détail ou meme édité.ou bien le sauve_gardé sur le disque et renvo_yé plus tard.

Figure 3 : L'interface de l'agent Dammy.

5.3. Agent Direcory Facilitator

L'inter face du DF peut etre lancée a partir du menu du RMA .Cette action est en fait implantée par l'envoi d'un messa_ge ACL au DF lui demandant de char_ger son interface _graphique. L'inter face peut etre juste vue sur l'hOte oil la plate-forme est exécutée. En utilisant cette interface, l'utilisateur peut intera_gir avec le DF.

Figure 4 : L'interface de l'agent DF.

5.4 Agent Sniffer

Quand un utilisateur décide d'épier un agent ou un groupe d'agents, il utilise un agent sniffer. Chaque message partant ou allant vers ce groupe est capté et affiché sur l'interface du sniffer.

Figure 5 : L'interface de l'agent Sniffer

5.5 Agent Inspector

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

Figure 6 : L'interface de l'agent Inspector.

6. Cycle de vie d'un agent

Figure7 : Le cycle de vie d'un agent.

Voici la description des di fférents états d'un a_gent en accord avec la spéci fication de la FIPA :

-Initiated : l'objet a_gent est créé mais n'est pas encore enre_gistré aupres du service de nomma_ge (AMS).

- Active : l'objet a_gent est enre_gistré aupres du service de nomma_ge (AMS), il possède désormais une adresse unique et peut donc communiquer avec les autres a_gents.

- Suspended : l'exécution de l'a_gent est suspendu.

- Waiting : l'a_gent est bloqué et doit attendre un événement comme un messa_ge par exemple. -Transit : l'a_gent rentre dans cet état lorsqu'il mi_gre dans un autre conteneur.

-Deleted : l'a_gent est détruit et supprimé du service de nomma_ge (AMS).

7. Les Behaviours (Comportements)

Un comportement dé finie les taches qu'e ffectue un a_gent. Quelque soit le t_ype du Behaviour, il doit implémenter la méthode action() qui dé finit la sé_quence des instructions a exécuter et lorsque la méthode done() retourne true elle s'arrete.

La méthode block() d'un comportement permet de bloquer ce dernier. Suite a l'arrivée d'un

nouveau messa_ge.

Pour ajouter un comportement a la file des comportements de l'a_gent, on utilise la méthode addBehaviour(new BehaviourClass(Parametres)) de la classe 'a_gent'.

On distingue plusieurs types de comportement, les plus utilisés sont:

- Classe o Behaviour o : c'est la classe de base a partir de laquelle sont dérivés les autres classes de Behaviours.

Exemple :

public class MonBehaviour extends Behaviour{

// Ici vous pouvez declarer des variables

// Un Behaviour possède un constructeur

public MonBehaviour(/*paraml, param2,...*/){

// Initialisation du Behaviour.

}

public void action(){

// Traitement

// cette méthode est exécutée jusqu'a ce que la méthode done() retourne true.

}

public boolean done() {

return valeurBooleenne_;

}
}

- Classe OneShotBehaviour : c'est une spécialisation de la précédente, la méthode action() est exécutée une seule fois (par dé faut, la méthode done() retourne true). Donc vous n'avez pas a redé finir la méthode done().

- Classe CyclicBehaviour : la méthode action() est exécutée en répétition, la méthode done() retourne false. N'oublier pas de bloquer le Behaviour a la fin de la méthode action(), car il fait une boucle infinie (_gaspilla_ge de CPU). Le Behaviour sera débloqué quand un nouveau messa_ge est inséré dans la file de l'a_gent.

- Classe WakerBehaviour: la méthode action() est exécutée apres un temps donne en parametre (exprime en millisecondes) et une seule fois.

- Classe TickerBehaviour : la méthode action() est exécutée chaque t milliseconde (t est donne en parametre a la creation du Behaviour).

8. Communication entre agents

La communication entre agents se fait par un langage qui est FIPA-ACL(Agent Communication 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 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(). 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 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 :Les champs d'un message ACL.

Tous les attributs de la classe ACLMessa_ge peuvent etre obtenus et modi fies par les methodes set/_get(). Le contenu des messa_ges peut etre aussi bien du texte que des objets car la serialisation Java est supportee.

8.1. Envoi d'un message

Exemple : Le code suivant correspond a l'envoi d'un messa_ge a l'a_gent « Yacine » dans le but de l'in former que (Le match de football est termine)

ACLMessa_ge ms_g = new ACLMessa_ge (ACLMessa_ge.INFORM)_; ms_g.addReceiver (new AID ("Yacine", AID.ISLOCALNAME))_; ms_g.setLan_gua_ge (" Fran_cais ");

ms_g.setOntolo_gy (" match")_;

ms_g.setContent ("le match de football est terminé ");

send (ms_g)_;

8.2. Reception d'un message.

Exemple : on bloque le comportement jusqu'a l'arrive du ms_g.

ACLMessa_ge ms_g = receive (); I f (ms_g! = null) {

// traiter le messa_ge

}Else { Block ();

}

. Conclusion

Le rôle de la plate-forme JADE est de réaliser la couche communication inter-agents de façon à pouvoir faire une argumentation sans l'intervention de l'humain et donc dans cette optique de les rendre autonome. On se sert pour cela du langage ACL pour que les agents s'échangent leurs messages.

Annexe B

~ La machine d'arithmitique ait des e~~ets qui approchentplus de la pensee que tout ce que ont les animaux mais elle ne ait rien qui puisse aire dire qu'elle a de la volonte, comme les animaux »-Blaise

Pascal.

AUML

Agent Unified Modeling Language

1. Introduction

Les faiblesses d'UML pour la représentation des systèmes multi-agents ont conduit une équipe de chercheurs travaillant dans différentes entreprises ou universités (Siemens, University Paderborn, Intelligent Automation, Fujitsu...) a concevoir AUML. L'objectif est de mettre au point des sémantiques communes, des méta-modèles et une syntaxe générique pour les méthodologies agents. AUML est un des fruits de la coopération entre FIPA (Foundation of Intelligent Physical Agents) et l'OMG (Object Management Group). Par rapport a UML, AgentUML propose des extensions pour la représentation des agents que nous détaillerons dans cette annexe.

2. Principes sur UML

UML (Unified Modeling Language) [Odell, 1 998] unifie et formalise les méthodes de plusieurs approches orientées objets. UML prend en charge plusieurs types de modèles :

· Les cas d'utilisation : la spécification des actions que le système ou la classe peut réaliser en interaction avec les acteurs extérieurs. Ils sont souvent utilisés pour décrire comment un utilisateur communique avec son logiciel.

· Les modèles statiques : ils décrivent la sémantique statique des données et des messages d'une manière conceptuelle et d'une manière plus proche de l'implémentation (il s'agit des diagrammes de classes et de packages).

· Les modèles dynamiques : ils incluent les diagrammes d'interaction (i.e., les diagrammes de séquence et les diagrammes de collaboration), les schémas d'état et les diagrammes d'activité.

· Les modèles d'implémentation : ils décrivent la répartition des composants sur différentes plateformes (i.e., les modèles de composants et les diagrammes de déploiement).

3. Déficiences d'UML

L'idée générale d'AUML est de combler les déficiences d'UML pour la modélisation des systèmes a agents. Parmi ces déficiences, on trouve [Marc03] :

· Des relations entre classes statiques (agrégation, généralisation, et association) mais qui semblent tout de même adéquats. Il est possible d'utiliser des associations de classes et des stéréotypes pour étendre UML avec des relations spécifiques pour les agents.

· Les accointances sont des relations importantes entres agents, Il s'agit d'une relation dynamique entre des instances et UML n'est pas très adapté pour les représenter.

· Un certain nombre de concepts de haut niveau (comme les engagements, les contrats, etc.) peuvent etre relativement bien représentés avec UML mais d'autres (comme les croyances et les intentions) ne le peuvent pas.

· Il est difficile de representer l'etat interne des agents. Il faudrait un modele proposant des concepts de haut niveau o cognitif » (BDI, BC, GAP, ...).

· UML n'est pas efficace pour representer des connaissances fonctionnelles (buts, planification, processus, etc.). Pourtant beaucoup de methodologies agents utilisent les buts et la decomposition de buts en sous-buts.

· Il n'est pas evident que les approches de modelisation à etats finis soient adaptees pour les agents. Les agents ont des espaces d'etats vastes qu'il n'est pas evident de partitionner en un plus petit nombre de macro-etats de plus haut niveau. Les agents peuvent apprendre et s'adapter à differentes choses et des parametres comme les croyances interagissent pour influencer le comportement de facons subtiles. Ces systemes sont dynamiques, non lineaires et ont un comportement emergeant.

4. AUML

AUML [Odell,00] est base sur la methode UML (Unified Modeling Language) qui est une methode de genie logiciel utilisee pour les developpements en langages orientes-objets. Elle est dejà largement utilisee par la communaute des concepteurs-objet et son succes continue de croitre.

Comme nous l'avons dejà vu, par rapport aux objets, les agents ont des activites autonomes et

des buts. C'est cette difference qui entraine l'insuffisance d'UML pour modeliser les agents et les systemes multi-agents. Aussi AUML remplace-t-il la notion de methode par celle de service. Ses principales extensions sont :

- Diagramme de classes d'agent qui est une reformulation du diagramme de classes d'objets,

- Diagramme de sequence qui permet une meilleure modelisation des interactions entre

agents,

- Diagramme de collaboration qui complemente le diagramme de sequences en proposant

une autre lecture et vision des interactions entre agents.

5. Presentation generale des extensions d'AUML 5.1. Le diagramme de classes d'agent

Une classe d'agent represente un agent ou un groupe d'agents pouvant jouer un role ou avoir un comportement determine, Une classe d'agent comporte :

-Description de la classe d'agent et des roles;

-Description de l'etat interne ;

-Actions, methodes et services fournis ;

-Messages echanges

Fig.1 : Diagramme de classe d'agent.

- Nom de la classe agent/ role1, role2,...: Un agent d'une classe donnée peut avoir plusieurs roles (un détaillent peut etre acheteur ou vendeur) .

- Description des états: Définition de variables d'instance qui refletent l'état de l'agent, - Actions (Plans): deux types d'actions peuvent etre spécifies: action pro-active exécutée

par l'agent lui meme si une pré-condition devient vraie, et ré-active résultant d'un message recu d'un autre agent. En d'autres termes les actions sont les plans qu'a un agent.

- Méthodes: Elles sont définies comme dans UML, avec éventuellement des pré-conditions, post-conditions ou invariants.

- Envoi et reception de messages: description des messages émis

et recus par l'agent en précisant les protocoles.

-Un automate : représente les changements d'état induits par les échanges de messages.

5.2. Protocoles d'interaction (AIP : Agent Interaction Protocol):

Exemple de representation :

· Un decoupage en couches :

Dans le protocole de la figure ci-dessus, aucune precision n'est donnee sur le traitement ou la construction des messages :

- La construction de la requete (par Submitter) peut etre un processus complexe decrit par un diagramme d'activites ;

- Le traitement de cette requete (par Solver) peut etre decrit par un autre diagramme d'activites ou de sequence.

- Ce decoupage en couches reifie les processus inter-agents et ceux internes a chaque agent.

La couche superieure : c'est le protocole qui est representee sous la forme de package ou de template.

- Un package agrege des morceaux de modeles pour former un ensemble conceptuel ;

- Un template est un modele ayant des parametres (Trois types de parametres : role, contraintes et actes de communication) qui sont specialises a l'instanciation.

La deuxieme couche : les echanges entre agents :

ü Diagrammes de sequences :

Nommage des acteurs : nom-agent/rOle:classe ;

- Les messages echanges ne sont plus des noms de methodes mais des actes de communication ; -Les threads d'interaction concurrents :

-emissions concurrentes : connecteur and ;

0 ou plusieurs emissions a la fois : connecteur or ;

1 seule emission parmi plusieurs candidates : connecteur xor

ü Diagrammes de collaboration :

Se construisent comme dans les modeles objets ;

Similaires aux diagrammes de sequences ;

ü Diagrammes d'activites :

Decrivent les operations entre agents et les evenements qui les declenchent ; Comparables aux reseaux de petri colores :

Representation graphique des processus ;

Representation des traitements concurrents et asynchrones ; Representation de communications simultanees avec divers participants

Diagrammes d'etats de transitions :

Decrit les changements d'etat lors des echanges entre agents ; Facilite la description des contraintes sur les protocoles.

La troisieme couche : les traitements internes de l'agent : -Diagramme d'activites pour chaque agent ;

-Diagramme d'etats-transitions pour chaque agent.

6. AUML et les autres methodologies

Les objectifs entre AUML et nombre de methodologies (Gaia, MaSE, etc.) orientees agent sont communs : partir de methodologies ou langages de modelisation orientes objet et les etendre au paradigme agent ;

Des representations (diagramme ou modele) entre AUML et diverses methodologies

7. Limitations d'AUML

-Les diagrammes sont desordonnes et peuvent etre mal interpretes ;

-L'expression de toutes les informations necessaires sur les protocoles peut les rendre illisibles ;

-Les cas de redondance sont difficiles a identifier et corriger ;

-La description des actions temporelles (telles que le timeout, deadline, ...) est difficile a exprimer ;

- La notion d'historique des echanges n'existe pas ;

-La terminaison des interactions n'est pas toujours specifiee.

8. Conclusion

Aujourd'hui AUML n'est pas encore un langage de modelisation fini et adopte par la communaute car aucune specification finale n'a ete publiee officiellement mais plusieurs publications sur des extensions d'UML ont etes publiees par les membres du groupe. Actuellement, leurs travaux se concentrent sur les interactions, plus specifiquement sur les protocoles d'interaction, mais aussi sur d'autres aspects connexes comme les langages d'interaction, la coordination, les roles des agents. D'autres travaux portent egalement sur les architectures, et les ontologies.