Multi-Agent - lifl.fr · Interaction protocol name : FIPA Contract Net Description : implementation of the FIPA contract net protocol ... Spécification des protocoles d’interaction

AOSE Conception d’applications multi-agent

Conception d’ApplicationsMulti-Agent

Jean-Christophe Routier Equipe [email protected] http://www.lifl.fr/SMAC

DEA d’Informatique

USTL http://www.lifl.fr/˜routier/enseignement 1

AOSE Conception d’applications multi-agent

Plan� Introduction

! contexte,

! actes de langages.

� Methodologies

! Gaia,

! RIO.

� Programmation

! MadKit,

! Magique.


AOSE Introduction

L’existant

Toujours plus de modularite et de reutilisabilite :

Objets �! Composants �! Agents

� la distribution : RPC, puis CORBA.

� le multi-threading : concurrence et objets actifsacteurs (Carl E. Hewitt 1979)

Intuitively, an actor is an active agent which plays a role...


AOSE Introduction : acteur

Langages d’acteurs

1

n A n+1

B 1

spécifier un

remplaçant

n+1n Message

envoyer

des messages

Boite à lettres

1

A

Acteur = enchaınement totalement ordonne de comportements


AOSE Introduction : AOP

“Agent Oriented Programming” (Shoham 1990)

“Agenthood is in the mind of the programmer”

Yoav Shoham propose un nouveau paradigme base sur une vue societale du calcul :

Constuire des systemes informatiques par des societes d’agents

Les caracteristiques principales sont :

� les agents sont des processus autonomes et concurrents ;

� les agents sont des systemes cognitifs, programmes en termes de croyances,buts, decisions/choix,

� les agents sont des systemes capables de raisonnements, specifies en termes delogique ;

� les agents communiquent par des actes de langage.



Systeme AOP

Shoham propose qu’un systeme pour l’AOP ait trois composants :

� un systeme logique pour specifier l’etat mental et le comportement des agents,

� un langage de programmation interprete pour programmer les agents enutilisant une version simple du systeme logique,

� un processus d’“agentification” pour generer des agents executables a partir deleurs specifications.

Il propose une logique utilisant le temps et le langage Agent0.



Agents in AOP

Autonomie agents agissent sans intervention humaine directe et exerce un controlesur leur propre etat.Ils ne sont affectes qu’a travers des messages et pas par manipulations directes.

Concurrence les agents s’executent independamment les uns des autres.

Reactivite les agents reagissent rationnellement aux evenements de leurenvironnement.

Proactivite les agents font plus que simplement reagir, ils generent des evenementset agissent dans le but d’accomplir un objectif.

La proactivite est la difference essentielle avec les objets concurrents.

+ les agents sont cognitifs


AOSE Introduction : objets et composants

Agents et objets

(cf. article J. Odell)

nombreux points communs : interactions et envois de messages,

mais en OO :

� l’objet est passif (reactif),

� l’objet “serveur” d’une methode n’a pas le choix,

! il est pourtant le mieux (seul ?) place pour en connaıtre les consequences,

! pas toujours adapte en environnement concurrent/competitif =) systemesouverts

� la granularite “objet” limite les abstractions representables () design patterns -mais insuffisants)


AOSE Introduction : objets et composants

Agents et composants

unites de deploiement... (but : reutilisables), auto-“suffisants”

mais composants :

� pas de meta-information (sur les services fournis),

� pas autonomes,

� pas de proactivite,

+ ADL (Architecture Description Language) : description des dependances des composants+ MDA (Model Driven Architecture) : description de systemes formels (PIM)

evidemment, on peut avec objets et/ou composants combler ces differences, maispas en “natifs”


AOSE Introduction : actes de langages

Theorie des actes de langages

acte de langage �! acte social

� “How to do things with words” (J.L. Austin 1962)

! performatifs : dire quelque chose c’est faire quelque chose

! informatifs : enonces vrai ou faux (descriptifs)

� John Searle. Actes illocutoires (informer, ordonner, avertir, ...) :

! informatifs : Il est 14h30 (description d’une realite),

! directifs : Qui est la ?, Taisez-vous ? (faire executer qque chose a auditeur),

! promissifs : Je viendrai la semaine prochaine (engagement de l’orateur),

! expressifs : Je suis fatigue (description d’un etat de l’orateur),

! declaratifs : J’ai casse la machine (changement de la realite).



Langages de communications entre agents� KIF (KNOWLEDGE INTERCHANGE FORMAT) : langage de contenu

langage d’externalisation de connaissances base sur une semantique declarative

� KQML (KNOWLEDGE QUERY AND MANIPULATION LANGUAGE) :

,! format de messages + protocole de traitement des messages

� FIPA-ACL (AGENT CONTENT LANGUAGE) : equivalent de KQML + semantique formelle



KQML

Message

Communication

��

��

Informations relatives à la communication : expéditeur,destinataire(s), identifiant de message, mode de synchronisation, etc.

Logique de la communication : type d’acte de langage, capacitésd’interprétation

Contenu de la communication : une expression dans un langage dereprésentation des connaissances (KIF par exemple)

Contenu

Exemple :

SL0

( :sender:receiver:reply−with

:ontology:langage:performative

:content

msgIDstockAgentbankAgent

tell

enterpriseOntology

(PRICE productA ?price) )

Niveau communication

Niveau message

Niveau contenu



Foundation for Intelligent Physical Agent

HP, IBM, Sun, Motorola, BT, FT, Boeing, : : :

“promouvoir des technologies et des specifications qui facilitentl’interoperabilite de systemes d’agents intelligents dans un environnementcommercial ou industriel”

� Propositions technologiques : specificationslangages de communication et de contenu, protocoles d’interactions, services minimaux deplate-formes (AGENTCITIES)

� Propositions applicatives : definitions de services

Messages ontologies : FIPA_Contract_Net_ontology

��

��

��

��

��

��/cfp /propose /accept

/not_understood/failure/reject/refuse

/inform_done/inform_ref

BID CHOOSE DO

Micro−roles :

:

initiator (1)

Interaction protocol name : FIPA Contract Net Description : implementation of the FIPA contract net protocol

Participant (+) Initiator micro−roles



Langages de contenu

Semantique ?

Ontologies

Formalismes de representation des connaissances :

� logique,

� procedures/methodes,

� reseaux semantiques,

� langages de frames

dessous−à−droite

E

parallélogramme

est−uncube

région−de

dessous−à−gauche

��

��

��

��

attributrelation

marqueur A B

A B

E

� RDF (RESOURCE DESCRIPTION FRAMEWORK) (Web Semantique)(�! OWL (WEB ONTOLOGY LANGUAGE))



RDF

Langage XML, permettant de coder la connaissance par des statements

sujet – predicat – objet

<?xml version=’1.0’?><rdf:RDF

xmlns:rdf=’http://www.w3.org/1999/02/22-rdf-syntax-ns]’xmlns:RDFNsId1=’http://www.w3.org/2001/vcard-rdf/3.0]’><rdf:Description rdf:about=’http://somewhere/JohnSmith/’>

<RDFNsId1:NRDFNsId1:Given=’John’RDFNsId1:Family=’Smith’/>

<RDFNsId1:FN>John Smith</RDFNsId1:FN><RDFNsId1:EMAIL

rdf:value=’[email protected]’rdf:type=’http://www.w3.org/2001/vcard-rdf/3.0]internet’/>

</rdf:Description></rdf:RDF>



Programmation orientee interactions

necessite d’exprimer/representer/formaliser le deroulement des conversations

notions de regles sociales/conventions

differents niveaux dans une conversation :

Semantique Description du contenu du messageIntention Description de l’intention grace aux performatifsInteraction Description de la coordination, la structure de la conversation

niveaux d’abstraction dans un SMA :

Competences applicatives Connaissances metierModeles d’agents et competences systemes Conception orientee agentsGestionnaire de conversation Conception orientee interactionsTransport des messages Plateforme ou conteneur d’agents



Langages orientes interactions

APRIL langage symbolique pour creation de protocoles,

AGENTTALK idem + creation de protocoles par specialisation (heritage),

,! description explicite du protocole : etat + transition.

AGENTUML complements a UML pour representer protocoles d’interaction

Munindar P. Singh (1996) :

“We introduce interaction-oriented programming (IOP) as an approach toorchestrate the interactions among agents. IOP is more tractable andpractical than general agent programming, especially in settings such asopen information environments, where the internal details of autonomouslydeveloped agents are not available.”


AOSE Genie Logiciel Agent: Pieges

Les pieges du developpement oriente agent

Jennings & Wooldridge

� Pieges politiques

! You oversell agent solutions.

! You get dogmatic about agents.

� Pieges de management

! You don’t know why you want agents.

! You want to build generic solutions to one-off problems.

� Pieges conceptuels

! You believe that agents are a silver bullet.

! You forget agents are software.

! You forget agents are multi-threaded software.


AOSE Genie Logiciel Agent: Pieges� Pieges d’analyse et de conception

! You ignore related technologies.

! Your design doesn’t exploit concurrency.

! You forget legacy.

� Pieges au niveau “Agent”

! You want your own agent architecture.

! Your agents use too much AI.

! Your agents use no AI.

� Autres pieges

! You see agents everywhere.

! You have too few agents.

! You spend all your time implementing infrastructure.

! Your agents interact too freely or in an unorganised way.

! Your system lacks structure.


AOSE Genie Logiciel Agent: Methodologies

Methodologies orientees agents� Aalaadin

� Voyelles

� Gaia

� Rio



Aalaadin

Groupes, Roles et Agents

contains

OrganizationOrganizational Structure

Interaction

Group Structure

Role

Agent

Group

Agent Class

instantiates as

is defined between

defines

holds

Core Concepts

instantiates as

is member

handles

contains



Voyelles

Agents, Environnements, Interactions, Organisations

Instanciation

MODELES

AEIO

OUTILS

AEIO

RECURSION − EMERGENCE

Principes Mécanisme

Problèmeopérationnel

SMAProblèmeagentifié

Analyse Conception

Choix



Gaia

Proposition de processus d’analyse et de conception de SMA.

Design

Requirements

hierarchyGoal

Use CasesSequenceDiagrams

Roles

ConcurrentTasks

Agent Classes

Conversations

ArchitectureAgent

DiagramsDeployment

Capturing Goals Use CasesApplying Refining Roles Agent ClassesCreating Constructing

ConversationsAssembling

Agent Classes System Design

Analysis



RIO

Roles, Interactions, Organisations

Définition de l’occurence des agents abstraits^

Définition du graphe d’interaction

Choix des implémentations des interfaces de compétencesAssociation entre agents abstraits et agents concrets

Définition d’éléments génériques

Instanciation de la société dans un SMA

Spécification des roles composites

Spécification des protocoles d’interaction

Pré/Post−conditions sur les messages

Informations produites lors du protocoleOntologies des messages échangésDescription textuelle de l’objectif du protocoleDéfinition des micro−roles et de leur symbole

Définition des roles composites

Définition des agents abstraits

^

^

^

Interfaçage micro−role/interface de compétence^

Spécification d’une société d’agents

Définition du système multi−agents abstrait

Transformation de message pour l’adapter à l’interface

Association roles abstraits et organisations


AOSE Genie Logiciel Agent: Modeles

Modeles d’organisation

Necessite de definir l’“environnement des agents”, leurs accointances () diffusionmessages).

Modèle de diffusion (broadcast)Modèle hiérarchique Modèle orienté groupes Modèle holonique Modèle peer−to−peer



Modeles d’agent� logiques

Do(suck)

(2,2)(2,1)(2,0)

(1,2)(1,1)(1,0)

(0,2)(0,1)(0,0)

dirt dirt

In(x, y) L’agent est en (x, y)

Dirt(x, y) Il y a des poussières en (x, y)

Facing(d) L’agent est orienté dans la direction d

(1)

(2)

(3)

(4)

(5)

Do(forward)Facing(north)

Facing(north)

Do(forward)Facing(north) Dirt(0, 0)In(0, 0)

In(0, 1)

In(0, 2)

Dirt(0, 1)

Dirt(0, 2) Do(turn)

In(0, 2) Facing(east) Do(forward)

In(x, y) Dirt(x, y)

� reactifs (ex : architecture de subsumption de Brooks)

RechargerFSM

FSM

FSM

Explorer

OutputInputEsquiver


AOSE Genie Logiciel Agent: Modeles� BDI (BELIEFS DESIRES INTENTIONS)

l’environnement)

Fonction de miseà jour des croyances

ActionCroyances Fonction de générationde désirs

Désirs Filtre Intentions

Effets de bord dusà l’exécution de l’action

en provenance de Capteurs (informations

� a couches

(controle en deux passes)

Informationsperçues

Actionsexécutées

Actionsexécutées



Actionsexécutées

... ... ...

Couche 1

Couche 2

Couche n Couche 1 Couche 1

Couche 2 Couche 2

Couche n Couche n

(a) Couches horizontales (b) Couches verticales

(controle en une passe)

(c) Couches verticales



Plateformes� agents mobiles : GRASSHOPPER, VOYAGER, AGLETS

� agents BDI : AGENTBUILDER, JACK

� FIPA : ZEUS, JADE

� orientee organisation : MADKIT, VOLCANO, MAGIQUE

� simulation : SWARM (cf. partie du cours de Sebastien Picault)


AOSE Gaia

Gaia


AOSE Gaia

Gaia

M. Wooldridge, N.R. Jennings, D. Kinny

“The methodology is general, in that it is applicable to a wide range ofmulti-agent systems, and comprehensive, in that it deals with both themacro-level (societal) and the micro-level (agent) apect of systems.”

Les applications cibles sont des applications de “grande taille” satisfaisant lesproprietes :

� les agents sont des entites logicielles a gros grain (processus)

� le but est d’obtenir un systeme qui maximise une mesure globale choisie memesi du point indviduel des agents on atteint pas un optimal

,! les agents sont cooperatifs et bienveillants

� les agents sont heterogenes

� relativement peu d’agents (� 100)


AOSE Gaia

Les principaux concepts� le systeme : organisation, la societe.

� les roles : la fonction dans le systeme.

! responsabilites : liveness et safety responsibilitiesliveness assure que “something good happens”safety garantit que “nothing bad happens”

! permissions : � droits

! protocoles : la maniere d’interagir avec les autres roles.

analyse et conception sont considerees comme des processus de constructionsincrementales de modeles du systeme


AOSE Gaia

Processus d’analyse

L’organisation du systeme est vue comme une collection de roles qui interagissent.Le modele organisationnel est donc defini par :

le modele des roles et le modele des interactions

Ce sont ces modeles qui doivent etre precises lors de l’analyse.

1. identifier les roles du systeme,sortie : liste des roles cle decrits informellements.

2. pour chaque role identifier les protocoles associes,sortie : un modele des interactions entre les roles,

3. en se basant sur les modeles des protocoles elaborer les modeles de roles,sortie : un modele complet pour les roles.

4. iterer les etapes 1 a 3


AOSE Gaia

Modele des roles

role = fonction (dans une organisation)

permissions droits sur les ressources (= information/connaissance)

� identifient les ressources qui peuvent etre legitimement utilisees pour tenir lerole,

� precisent les limites d’utilisation de ces ressources.

responsabilites decrit la fonction du role

liveness definit le “cycle de vie” de l’agent

safety liste de predicats


AOSE Gaia

Liveness

liveness expression :RoleName = expression

Operateurs :

x:y x followed by y xjy x or y occurs

x� x occurs 0 or more times x+ x occurs 1 or more times

x!

x occurs infinitely often [x] x is optional

xjjy x and y interleaved

Exemple :un role CoffeeFiller qui doit remplir une cafetiere si elle est vide, puis s’assurer queles travailleurs sont avertis qu’elle est pleine.

CoffeeFiller = (Fill.InformWorkers.CheckStock.AwaitEmpty)!


AOSE Gaia

Safety

Les responsabilites de liveness sont souvent insuffisantes.

Certains invariants doivent etre maintenus.

=) enumeration de predicats

Exemple :dans le cas du role CoffeeFiller il faut s’assurer que

� coffeeStock > 0


AOSE Gaia

Template de description d’un role

ROLE SCHEMA : name of role

DESCRIPTION : short english description of the rolePROTOCOLS : protocols in which the role plays a partPERMISSIONS : “rights” associated with the roleRESPONSIBILITIES

LIVENESS : liveness responsibilitiesSAFETY : safety responsibilities

Exemple :

ROLE SCHEMA : CoffeeFillerDESCRIPTION : This roles involves ensuring that coffe is kept filled, and informing the workers when fresh coffee has been brewed

PROTOCOLS : Fill, InformWorkers, CheckStock, AwaitEmptyPERMISSIONS : reads supplied coffeeMaker // name of coffee maker

coffeeStatus // full or emptychanges coffeeStock // stock level of coffee

RESPONSIBILITIES

LIVENESS : CoffeeFiller = (Fill.InformWorkers.CheckStock.AwaitEmpty)!

SAFETY : � coffeeStock > 0


AOSE Gaia

Modele de protocoles

exprimer les relations (inevitables) entre les roles du systeme

purpose breve description de la nature de l’interaction,

initiator le(s) role(s) qui initie(nt) l’interaction,

responder le(s) role(s) avec le(s)quel(s) interagit l’initiateur,

inputs les informations utilisees par l’initiateur lorsqu’il active le protocole,

outputs les informations fournies au/par le responder au cours de l’interaction,

processing breve description de tout process effectue par l’initiateur au cours del’interaction.


AOSE Gaia

Template de protocole

purposeinitiator responder inputs

processing ! outputs

Exemple :

FillCoffeeFiller CoffeeMachine supplied coffeeMaker

Fill coffee machine ! coffeeStock


AOSE Gaia

Conception

Il ne s’agit pas (pour GAIA) de determiner comment un agent realise un role.

L’objectif est :

“de transformer les modeles issus de l’analyse en abstractions desuffisamment bas niveau pour qu’elles soient attaquables par destechniques de conception classiques”

Developpement de 3 modeles :

1. modele des agents : quels types d’agents pour le systeme ;

2. modele des services : quels sont les principaux services attaches aux agents ;

3. modele des accointances : quelles accointances pour les agents.


AOSE Gaia� modele d’agent :

! type = distribution des roles

! + information de cardinalite (occurrence d’agents d’un type donne dans lesysteme)

,! n, m::n, �, +

� modele de services : documenter les services

,! inputs, outputs, pre-conditions, post-conditions

� modele d’accointances : graphe des liens de communication entre les typesd’agentles types de messages echanges ne sont pas definis.


AOSE Gaia

Processus de conception

1. Creer un modele d’agent :

� agreger les roles en types d’agents et les organiser en une hierarchie detypes,

� documenter les instances (cardinalites)

2. developper un modeles de services a partir de l’etude des protocoles et desproprietes des roles,

3. developper une modele d’accointances (a partir des modeles d’agent etd’interaction).


AOSE RIO

RIO : Roles, Interactions etOranisations


AOSE RIO

Les grandes lignes� Approche dans le meme esprit que Gaıa :

! roles (abstraits et concrets)

! protocoles d’interactions (formalisme “graphique”)

! organisations

=) reifications des differentes notions

� specifications executables de protocoles d’interaction,

� permettre un deploiement automatise

! faciliter transition : analyse! realisation

! construction incrementale et interactive du SMA

(CEEMAS2003, KES’03, IKE’03)


AOSE RIO : Protocoles d’interactions

Protocoles : elements syntaxiques

Passage d’information

Typage des messages

Transformation syntaxique

Interface de compétence

Place

Typage des messages

Post−conditionsPré−conditions

Instanciation d’un nouveauprotocole d’interaction

Typage des messages

Place

Typage des messages

Post−conditionsPré−conditions

Transformation syntaxique

Protocole d’interaction

Êtats initiaux et finaux

(liés à un micro−role)Êtats intermédiaires Insertion/Extraction d’information

(respectivement)

mi Motif de message

Etat intermédiaire nécessitantl’instanciation d’un nouveauprotocole d’interaction

m2

m3

m4

m5

Etat initial d’un protocole

m1

Etat intermédiaire nécessitantl’utilisation d’une compétence

��

m2

m3

m4

m5

(input+,output*)Etat final d’un protocole

m6

�� Interface de compétence

deux micro−rolesÊnvoi de message entre

(liés à un micro−role)



Description d’un protocole

^

��

��

��

��m1

(m1, m2)

m2 m3

(m3, (m4, m5))

m4

m5

information injectéeinformation extraite

Micro−roles initiateur(s) : A

Liste des micro−roles :

Ontologie(s) des messages : ontologie_X, ontologie_Y

Micro−role A Micro−role CMicro−role B

Description textuelle du but du protocole d’interaction : Ce protocole ...

Nom du protocole d’interaction : monProtocole

^ ^ ^

Exemple : FIPA Contract-Net

Messages ontologies : FIPA_Contract_Net_ontology

��

��

��

/cfp /propose /accept



BID CHOOSE DO

Micro−roles :

:

initiator (1)

Interaction protocol name : FIPA Contract Net Description : implementation of the FIPA contract net protocol

Participant (+) Initiator micro−roles



Specifications executables

vue de l’interaction : globale pour son concepteur et locale pour l’agent

vues locales �! Reseaux de Petri Colores �! code java

Fichier de description de la spécification en XML

�� m1

(m1, m2)

m2 m3

(m3, (m4, m5))

m4

m5

information injectéeinformation extraite

Micro−roles initiateur(s) : A

Liste des micro−roles :

Ontologie(s) des messages : ontologie_X, ontologie_Y

Micro−role A Micro−role CMicro−role B

Description textuelle du but du protocole d’interaction : Ce protocole ...

Nom du protocole d’interaction : monProtocole

Calcul de la vue locale

selon le micro−role C

RdPC

XMLen

RdPCen

Java

RdPCen

.class

monProtocole_C.xml

monProtocole_C.java

monProtocole_C.class


selon le micro−role B

RdPC

XMLen

RdPCen

Java

RdPCen

.class

monProtocole_B.xml

monProtocole_B.java

monProtocole_B.class


selon le micro−role A

RdPC

XMLen

RdPCen

Java

RdPCen

.class

monProtocole_A.xml

monProtocole_A.java

monProtocole_A.class

Spécifique àl’implémentation

Spécifique àl’implémentation

Indépendant de l’implémentation

Indépendant de l’implémentation



Projection sur les vues locales

Projection selon le micro−role Initiator

��

��

��

/cfp /propose /accept



BID CHOOSE DO

/cfp

/refuse/not_understood

��

/propose

CHOOSE

/reject

/accept

/failure

/inform_done

/inform_ref

Etape 0 Etape 1 Etape 2



Le reseau de Petri Colore

/cfp

tr_4_8tr_4_7tr_2_4tr_2_3tr_0_1

4_8

to_terminal_4_8

4_7

to_terminal_4_7

2_42_3

to_terminal_2_3

0_1

inbox

terminal

token Participant outbox

/propose

/not_understood/refuse

/failure/inform_done

/inform_ref

/reject/accept


AOSE RIO : la demarche

La demarche methodologique

Définition de l’occurence des agents abstraits^

Définition du graphe d’interaction

Choix des implémentations des interfaces de compétencesAssociation entre agents abstraits et agents concrets

Définition d’éléments génériques

Instanciation de la société dans un SMA

Spécification des roles composites

Spécification des protocoles d’interaction

Pré/Post−conditions sur les messages

Informations produites lors du protocoleOntologies des messages échangésDescription textuelle de l’objectif du protocoleDéfinition des micro−roles et de leur symbole

Définition des roles composites

Définition des agents abstraits

^

^

^

Interfaçage micro−role/interface de compétence^

Spécification d’une société d’agents

Définition du système multi−agents abstrait

Transformation de message pour l’adapter à l’interface

Association roles abstraits et organisations

1. �-role : role intervenant dans un protocole d’interaction.protocoles obtenus par creation, specialisation ou com-position

2. role composite : obtenu par agregation de �-roles(coherence logique)

3. agent abstrait : reunion de roles composites

,! tenir compte des dependances entre roles composites

,! precision des cardinalites des agents abstraits

,! choix de l’organisation retenue (accointances)

4. agent concret : deploiement de la societe d’agents (leSMA)

,! liaison entre interfaces de competences etimplementation

,! utilisation d’un modele d’agent generique etdynamique (cf. partie sur Magique)



Synthese de la demarche

AC 2

µ 32µ 23µ 22µ 12µ 11 µ 21 µ 31

ι 1 ι 2 ι 3

xι µ xy

Distribution de fournitures

Recherche de fournisseurs

Magasinier

Acheteur Fournisseur

Client

Réception des feuilles de frais

Guichetier Missionnaire

Emission des ordres de missions

Directeur Secrétaire Président

Gestion de fournitures Gestion des frais de mission

Magasinier

Distribution de fournitures

()

,

Acheteur

Recherche de fournisseurs

()

, Secrétaire( ,Emission des ordres de missions )

Guichetier( ,Réception des feuilles de frais )µ 21 ι 2( , )

µ 32 ι 3( , )

µ 12 ι 1( , )µ 11 ι 1( , )µ 23 ι 2( , )µ 31 ι 3( , )

µ 22 ι 2( , )

RC : Role Composite

RC 1 RC 2 RC 3

RC 1 RC 3

AA 1

RC 2

AA2

AA : Agent Abstrait

AA 1 AA2 AA2

AC 1 AC 3 AC 2

AC : Agent Concret

Gestion des frais de missions

Gestion de fournitures

Secrétaire delaboratoire

AC 1

: Protocole d’Interaction : Micro−Role

Secrétaire de laboratoire



Concretisation

la plate-forme JANEIRO

cf. These de Yann Secq (2 decembre)


AOSE MadKit

MadKit


AOSE MadKit

MULTI-AGENT DEVELOPMENT KIT

Jacques Ferber, LIRMM

http://www.madkit.org/

“MadKit a ete motive par la necessite de fournit une plate-forme agentgenerique, fortement parametrable et “scalable”. Le but est de construireune couche de fondation pour differents modeles d’agents et de rendre lesservices de base facilement extensibles et remplacables.”

� s’appuie sur le modele conceptuel Aalaadin : Agent/Groupe/Role


AOSE MadKit

Agent “entite communicante jouant des roles dans des groupes”pas d’architecture agent specifiee

Groupe “agregation d’agents” (permet dans un premier temps un “marquage” desagents) :

� un agent peut appartenir a plusieurs groupes simultanement,

� les groupes peuvent se recouvrir,

� tout agent peut creer un groupe et tout agent peut demander a rejoindre ungroupe

� un groupe peut etre local ou distribue

Role “representation abstraite de la fonction d’un agent”

� un agent peut tenir plusieurs roles,

� un role est local a un groupe,

� pour tenir un role au sein d’un groupe il faut en faire la demande, cela peutetre refuse.


AOSE MadKit

Architecture� architecture a base d’un micro-noyau,

� agentification des services,

� modele de composants pour l’interface graphique.

auto-definition de MadKit (mis a part le micro-noyau)


AOSE MadKit

Le micro-noyau

noyau enrobe dans un “KernelAgent”

� Controle des groupes locaux et des roles

,! responsable de la bonne gestion des membres d’un groupe et des rolesdetenus au sein du groupe

� Gestion du cycle de vie des agents

,! lancement/mort des agents, gestion du nommage des agents

� Distribution des messages

noyau extensible au niveau applicatif par des “agents autorises”


AOSE MadKit

Programmation avec MadKit

Programmation des agents en :JAVA, PYTHON, SCHEME (KAWA), BEANSHELL et JESS (et ...).

Un agent dans MadKit est constitue de 4 methodes essentielles :

activate code execute quand un agent est cree

live code principal, typiquement une boucle quasi infinie decrivant lecomportement

end code execute quand l’agent “meurt”,

initGUI description du JavaBean utilise comme interface graphique de l’agent


AOSE MadKit

En JAVA

import madkit.kernel.*;public class HelloWorldAgent extends Agent f

public void activate()f

println("Java Hello World Agent");

g

public void live()fint n = 10;while (n > 0)f

println("I am OK : "+n);pause(1000);n = n-1;

g

g

public void end()f

println("I am dead, arghhh");

g

g


AOSE MadKit


AOSE MadKit

import makdit.kernel.*;import makdit.libs.messages.StringMessage;public class CounterAgent extends Agent f

boolean counting = false;public void activate()f

println("I am a counter");createGroup(true,"demo.counter",null,null);//cree groupe distribue “demo.counter”requestRole("demo.counter","counter",null);//demande role “counter” ds “demo.counter”

g

public void live()fint n = 0;Message m;while (true) f

if (!counting)f

println("I am stopped and wait for a start message");m = waitNextMessage();this.handleMessage(m);

g else f

println("counting: " + n++); pause(1000);m = nextMessage();this.handleMessage(m);

g g g

void handleMessage(Message m)f

if (m instanceof StringMessage) f // :-(String s = ((StringMessage)m).getString();if (s.equals("start")) counting=true;else if (s.equals("stop")) counting=false;

g g

g


AOSE MadKit


AOSE MadKit

Remarques� API riche,

� pas de modeles comportementaux fournis (c’est du domaine applicatif),

� la programmation des agents est tres “classique” (� COO),

� mais pas de reification des notions de Groupe et de Role.


AOSE Magique

Magique


AOSE Magique

Modele et plateforme

Fournir un contexte (methodologie + environnement + langage) facilitant ledeveloppement d’agents et donc de SMA :

,! “programmation orientee agent”

,! agents a gros grain, distribues

,! favoriser la reutilisabilite des agents

� le developpement d’un agent doit etre au maximum independant dudeveloppement d’un(e application) SMA particulier(ere)

,! proposer un environnement de developpement et de deploiement des agents

,! se baser sur un langage existant (ne pas reinventer la roue)

,! simplicite de programmation/apprentissage


AOSE Magique

Agents, Competences et Hierarchies

MAGIQUE = MULTI-AGENT HIERARCHIQUE

� modeles d’agents et d’organisation d’agents(modele d’agent “structurel” et pas comportemental)

� framework de developpement de SMA

� approche orientee agent de la conception d’applications


AOSE Magique : modeles

Agents et competences



Une definition consensuelle...

Un agent est defini par ses capacites :

DEFINITION 1. Un agent est une entite douee de competences.

... mais trop vague...



Definition

DEFINITION 2. Un agent atomique est une entite douee de deuxcompetences : une pour interagir et une pour acquerir de nouvellescompetences.Un agent est un agent atomique qui a acquis des competences au traversd’interactions.

L’ensemble de ses competences determinent les roles qu’un agent peutjouer.

� differenciation des agents par leur “education” (plus de “classe”)

� evolution dynamique par echange de competences avec les autres agents

� importance des fonctionnalites offertes (“interface”) par une competence plutotque la competence elle-meme

[AISB 2001]



Avantages� developpement facilite

� efficacite

� robustesse

� autonomie et evolutivite

� evolution dynamique

Remarque

disparition de la notion de classe



Les differents niveaux d’abstraction

Fonctionnalités "applicatives" ou "métiers"

système

la notion d’agent

Compétencesintrinséques à

au modèle d’agentCompétences liées

Compétences applicatives

Gestion descompétences

Communication

Gestion des

d’interactionprotocoles

Gestion des organisationsconnaissances

Base de

bases de donnéesAccés aux

graphiqueInterface

Moteurd’inférence

Fonctionnalités "systèmes"

Compétences



Vous avez dit competences ?

� concept : ensemble coherent de fonctionnalites accessibles au travers deprotocoles d’interaction

� implementation : composant logiciel =) “interface”

� service = exploitation d’une competence



Implementation de modeles d’agent

,! Il suffit de definir les competences propres au modele cible :

� Aaladin/MadKit : competences de gestion des groupes

� application au modele Magique :Competences de prise en compte de la hierarchie.



Hierarchies



Multi Agent hierarchIQUE

Un modele d’organisation d’agents

,! un SMA est organise a sa creation en une hierarchie stricte d’agents

,! les liens hierarchiques representent les canaux de communication par defautentre agents

,! le controle est distribue et la structure hierarchique permet de le factoriser et decontroler la granularite de cette distribution

,! evolution dynamique du SMA :

� remise en cause de la structure hierarchique au profit de relationsprivilegiees (accointances) [arbre �! graphe]

� ajout/retrait d’agents

� evolution des competences des agents



Superviseurs et specialistes

,! on distingue deux statuts d’agent :

� superviseur : racine d’une (sous-)hierarchie

� specialiste : feuille de la hierarchie

,! un agent possede des competences (qui peuvent evoluer)

,! un agent a une tache a accomplir

� sa realisation requiert l’exploitation de competences

� l’agent peut posseder ou non ces competences ?

,! mecanisme de delegation de competences



Delegation de competences (1)

L’agent S1 doit accomplir une tache necessitant les competences c, c1 et c2 :

� c : pas de pb : connue en interne

� c1 : un agent “en-dessous” de lui a lacompetence, S1 delegue a qui de droit

� c2 : personne dessous, S1 transmetune requete de realisation a son super-viseur S qui repete le processus :

� S transmet a S2 qui connaıt un agentcompetent

� S2 applique le meme processus : larequete arrive a l’agent competent A2

qui la realise



Delegation de competences (2)

L’agent S1 doit accomplir une tache necessitant les competences c, c1 et c2 :

� c : pas de pb : connue en interne

� c1 : un agent “en-dessous” de lui ala competence, S1 delegue a quide droit

� c2 : S1 a pour accointance A2 quiest competent, il lui transmet di-rectement la requete



Avantages,! souplesse de developpement :

� reutilisabilite : l’agent realisateur n’a pas a etre connu a priori

� independance agent !SMAil suffit d’avoir dans le SMA un agent competent sans presupposer de sa“classe”

,! accroissement de fiabilitel’agent realisateur peut changer :

� resistance aux pannes

� efficacite (en cas de surcharge d’unagent competent)

� gestion de la concurrence



Dynamicite

,! Structurelle

� ajout/retrait d’agents au SMA

,! Communication

� creation de relations d’accointances privilegiees

� auto-organisation du SMA en fonction de son “execution”

� reponse au probleme du choix de la “bonne” structure

� non determinisme de l’organisation d’une session a l’autre

,! Individuelle : echange de competences entre agents

� evolutivite et autonomie

[PRIMA 2003]



Dynamicite structurelle (recruter de nouveaux collaborateurs competents)

a. SP doit satisfaire les requetes venant des �-users et de SU, il est submerge de requetes pour �.

b. SP a cree 3 agents apprentis et leur a enseigne �, il leur distribue les requetes pour � et soulage ainsisa charge.



Dynamicite des communications (avoir un bon carnet d’adresses)

a. Debut : le SMA est organise hierarchiquement, les requetes a des services (lignes doubles enpointilles) utiliset l’organisation hierarchique par defaut et SP1 est atteint.

b. Auto-organisation : le lien de communication direct qui correspond a une dependance concrete avecSP1 est cree.

c. SP1 disparaıt : les requetes au service utilisent l’organisation par defaut, SP2 est atteint.

d. Auto-organisation : un lien de communication direct est cree avec SP2.



Dynamicite individuelle (partager la connaissance)

a. Debut : le SMA est organise hierarchiquement, les requetes a des services (lignes doubles enpointilles) utilisent l’organisation hierarchique par defaut et SP est utilise.

b. Echange : la competence � est “apprise” par SU aupres de SP.

c. SU utilise son “propre” �. pour faire ce qu’il doit.

d. SU peut eventuellement etre deconnecte du systeme.



Echange de competences

Echange effectif : transfert de bytecodes entre plate-formes

la compétence C

C

D

G

E F

1

2C

D

G

E

CC 3

Agent A

Dépot de classes

Plateforme P1

Dépot de classes

Plateforme P2

Donner lacompétence C

Transfert de la compétence C etdes classes dont

elle dépend

Agent B

Instanciation de


AOSE Magique : programmation

API etEnvironnement de developpement



l’API� sur-couche de JAVA

� permet la distribution des agents sur reseau heterogene (via des plateformes)

� delegation transparente de competences

� echange dynamique effectif de competences entre agents (meme distants et sanshypothese sur le bytecode)

� communication synchrone ou asynchrone

� environnement de construction et deploiement d’agents et de SMA

� facilite d’utilisation

http://www.lifl.fr/MAGIQUE/



Des agents conformes au modele :public class Agent extends AtomicAgent f

...protected void initBasicSkills() throws SkillAlreadyAcquiredException f

addSkill(new fr.lifl.magique.skill.system.DisplaySkill());addSkill(new fr.lifl.magique.skill.system.AddSkillSkill(this));addSkill(new fr.lifl.magique.skill.system.LearnSkill(this));addSkill(new fr.lifl.magique.skill.system.ConnectionSkill(this));addSkill(new fr.lifl.magique.skill.magique.BossTeamSkill(this));addSkill(new fr.lifl.magique.skill.magique.ConnectionToBossSkill(this));addSkill(new fr.lifl.magique.skill.magique.KillSkill(this));

g

g

Creation d’un autre modele d’agent : fournir les competences necessaires...



Creer un agent

import fr.lifl.magique.*;...

// creation d’un agent atomiqueAgent myAgent = createAgent("myName");// l’agent apprend des competencesmyAgent.addSkill("SkillOne");myAgent.addSkill("SkillTwo");myAgent.addSkill("SkillThree", params);// il rejoint une hierarchie (= SMA)myAgent.connectToBoss("[email protected]:4444");...

Pas de notion de classes pour les differents agents...



Creer une competence

import fr.lifl.magique.*;import fr.lifl.magique.skill.*;...public class ASkill implements Skill f

public ASkill() f...g

// l’agent pourra utiliser <ability>public void ability(...) f

...

g

g



Invocation de competence

� Programmation objet :object.ability(arg...);

� Magique : “reification de l’invocation”perform("ability",arg...);

ask (asynchrone), askNow (synchrone), concurrentAsk (concurrent)

+ envoi de messages avec destinataire nomme



Ping-Pong

2 roles, 1 competence par role : ping et pong

import fr.lifl.magique.*;import fr.lifl.magique.skill.*;public class PongSkill extends MagiqueDefaultSkill f

public PongSkill(Agent a)f super(a); g

public void pong() fSystem.out.println("pong");// requete sur la competence ping d’un agent "anonyme"this.perform("ping");

g

g // PongSkill

import fr.lifl.magique.*;import fr.lifl.magique.skill.*;public class PingSkill extends MagiqueDefaultSkill f

public PingSkill(Agent a)f super(a); g

public void ping() f

System.out.println("ping");// requete sur la competence pong d’un agent "anonyme"this.perform("pong");

g

g // PingSkill



import fr.lifl.magique.*;import fr.lifl.magique.platform.*;

public class PingImp extends AbstractMagiqueMain f

// args[0]=super hostName:port + args[1] = verbose levelpublic void theRealMain(String[] args) f

if (args.length==2)Agent.setVerboseLevel(Integer.parseInt(args[1]));

Agent a = createAgent("ping");a.addSkill(new PingSkill(a));a.connectToBoss("super@"+args[0]);

g

g

java fr.lifl.magique.Start PingImp 5555 127.0.0.1:4444

similaire pour un agent “pong” et pour super (sans competence)



L’environnement de developpement

� construction de l’organisation hierarchique

� constitution des agents par ajout de competences

� deploiement distribue

� controle/commande des agents via une console




AOSE Magique : applications

Exemple : diapo-conference

application pour “tele-conferences” distribuees

� diffusion de document (sous forme d’URL)

� 2 roles :

,! conferencier (unique) : possesseur de la “tele-commande”.

,! auditeur

� echange des roles possible

� Assistant :

,! aide a l’utilisation

,! aide a la cooperation

[TSI-CP2001,CADUI2002]


AOSE Magique : applications� a chaque fonctionnalite correspond une competence :

,! 2 clients pourraient avoir des implementations differentes de la meme(interface de) competence

,! evolutivite

,! adaptabilite (en fonction du support)

� la telecommande : echange physique de la competenceremoteControlSkill =) changement dynamique de role







Organisation des ressources



Les autres ?



L’assistant

� mise en evidence d’evenementsdistribution requiert la valorisa-tion d’evenements : arrivees/departsd’intervenants, notification de messages, etc.interface : contextualisation de la gestion desmessages.

� aide a la participation a la cooperationaide a la decision : indication de correlationentre ressource courante et les ressources pro-pres

,! demande d’intervention, transmission auconferencier, etc.

� modelisation des autres intervenants en vue defutures collaborations

,! construction d’une representation descompetences des intervenants rencontres : aidea la tenue de futures conferences ou recherchede competences



L’organisation et l’echange de competences

��

��

��

��

Agents Client

Agent Coordinateur

ConférencierAuditeur

Agent 1

Agent 1

Agent 2

Agent 2

ZapperSkill

ZapperSkill

Asking for the

Speaker Listener

SpeakerListener

remote control

Giving the

remote control

Evolution dynamique de roles



Magique prend en charge la communication et la distribution

Developpement independant des competences (evolutivite et adaptabilite)

import fr.lifl.magique.*;...

// creation d’un agent "vide"Agent myAgent = createAgent("myName");// l’agent apprend ses competencesmyAgent.addSkill("MaZapperSkill");myAgent.addSkill("MaHTMLSkill");myAgent.addSkill("MonAssistantSkill");... autres enrichissement de competences ...

...



Exemple : RAGE� framework pour le calcul distribue type “Grid Computing”

� facilite d’utilisation et de deploiement :uniquement les notions de tache du calcul a effectuer et de resultat calcule

! heriter de AbstractTask

! implementer :public abstract void compute();public abstract boolean finished();

� aspect agent transparent pour l’utilisateur final

initiated

started

finished

suspended

compute

init()

compute()

compute()suspend()

finished() == true

[AISB02,JAISB02]



Un exemple

public class PiTask extends AbstractTask f

public Double pi;private int crtIter = 0, inner = 0, niter, chunk;public PiTask(String factId, String taskId, int niter) f

super(factId, taskId);this.niter = niter; chunk = niter/10;

g

public void compute() f

double x, y;for( ; (crtIter % chunk) < chunk; crtIter++) f

x = Math.random(); y = Math.random();if (Math.sqrt(x*x + y*y) <= 1.0)

inner ++;

g

pi = new Double(4*((double)inner/(double)niter));

g

public boolean finished() f

return crtIter == niter;

g

public double percent() f // Percent of progressreturn (double) (crtIter * 100)/(double)niter;

g

g

N = +I =



Conception : identification des roles et des competences.

Boss role is responsible of all the interactions with the user part

Task Dispatcher role has to dispatch tasks and deal with fault tolerancy.

Platform Manager role manages the agents that will compute the tasks, and mustensure that there are always available tasks for these agents.

Reckoner Agent role is the worker of the framework, it computes tasks, and sendback the results of this computation.

Repositories Manager role manages the storage of results.

Result Repository role is a mirror of the database of results.



Conception : choix de la structure organisationnelle

��

��

TaskDispatcher

RepositoriesManager

Boss

PlatformManagerReckonerAgent

ReckonerAgent

ReckonerAgent

ReckonerAgentReckonerAgent

ResultRepository

PlatformManager

TaskManager

ReckonerAgent

ReckonerAgent

ReckonerAgent



Exemple : systeme de “workflow”� systeme de circulation de documents (mail “evolue”),

� notion de circuit de documents (circulation sequentielle et parallele),

� communication asynchrone (+ connexion/deconnexion),

� fonctions de creation, validation, suivi de documents,



Les agents, leurs roles et leurs competences

Workflow = graphe de circulation + document.Chaque workflow est gere par un agent dedie

� SERVEUR DE CONNEXIONS : Permettre la gestion des utilisateurs au sein del’application. Etablir le lien entre le login et l’agent utilisateur (“pages jaunes”)..inscription, connexion (recuperation de msg), deconnexion, envoi de message

� AGENT UTILISATEUR : Assurer l’interface entre l’utilisateur et l’application workflow.creer un workflow, consulter ses messages (recevoir), suivre l’evolution d’un workflowemis

� ADMINISTRATEUR D’AGENTS WORKFLOW : Gerer la creation dynamique des “agentsworkflow”.creer un agent workflow, detruire un agent worklow

� AGENT WORKFLOW : Responsable de la gestion d’un workflow donne.initialiser, faire circuler le document (envoi, validation), gerer le suivi

L’existence des agents workflow (et de leur administrateur) est transparente pour lesutilisateurs.



Le SMA

2 hierarchies

� les agents utilisateurs “sous” le serveur de connexions

� les agents workflow “sous” l’agent administrateur

Ces deux hierarchies doivent etre reliees, plusieurs solutions possibles :

� un seul agent pour le serveur et l’administrateur

� l’un est “sous” l’autre

� ils sont tous les deux connectes a un meme agent superviseur

Ces choix n’ont aucun impact sur le developpement des agents et on peut passer del’un a l’autre facilement.Il est tres facile d’envisager plusieurs agents administrateur et plusieurs agentsserveurs de connexions.



Remarques� pas de gestion des dependances de competences,

� interactions et competences trop fortement couplees,

� pas de reification de la notion d’organisations,

,! pas de hierarchies multiples (plans de communication)

la suite : JANEIRO


Documents

Multi-Agent - lifl.fr · Interaction protocol name : FIPA Contract Net Description : implementation of the FIPA contract net protocol ... Spécification des protocoles d’interaction