5.4.1 Expressions de base
Dans un système multi-agent simple, on peut voir un agent comme un ou plusieurs processus déigné par un nom unique. L’important est d’avoir au sein du système un seul canal d’entrée par agent. Plus précisement, le comportement d’un agent va être représenté par un jeu d’équations de la forme
Aj(id, v1j, .., vkj) = Pj
Avec Pj un processus (au sens du π-calcul) et id une constante qui représente le nom de l’agent. Les vijseront les paramètres de l’agent, c’est à dire ses variables et attributs internes.
5.4.2 Quelques exemples
Commençons par un exemple simple : un agent demande à un autre de réaliser pour lui une certaine tâche. On supposera que nos deux entités ont été définies par deux structures d’agentAetBet qu’ils seront désignés par leur nom (au sens de la MAAM que nous avons décrite précédemment).
Notre scénario sera le suivant : après demande de l’agent de type A, on suppose que l’agent de typeBva accepter ou non la tâche t selon une condition P(t) dont on posera l’application comme primitive. Après réponse, l’agent de typeAexécutera alors une primi- tive Q1 si la réponse était positive et Q2dans le cas contraire.
Voici une description dans la MAAMde ces deux agents :
A(x,t,y) =defν(c)(y(request,t,c).
c(m).((m = agree) ?Q1; (m = refuse) ?Q2))
B(x) =def x(m,z,k).(m = request) ?
Examinons maintenant ce que donne l’évaluation de cet exemple dans le modèle. On va considérer comme situation initiale deux agents a et b définis respectivement comme étant de modèleAetB. On supposera que le testPappliqué à la tâche t retournera vrai.
(1) {|A(a,t,b), B(b)|} (2) {|ν(c)(b(request,t,c).c(m).. , b(m,t,k).(m = request)..|} (3) {|c(m)((m = accept) ?Q1; (m = refuse) ?Q2)), (request = request) ? (P(t) ?c(accept) ;c(refuse)) |} (4) {|c(m).((m = accept) ?Q1; (m = refuse) ?Q2)), (P(t) ?c(accept) ;c(refuse))|} (5) {|c(m).((m = accept) ?Q1; (m = refuse) ?Q2)), c(accept)|} (6) {|((accept = accept) ?Q1; (accept = refuse) ?Q2)|} (7) {|Q1|}
Le nom c est ici utilisé un peu comme le “customer” dans la terminologie des langages d’acteurs [Agha et Hewitt, 1987], qui recevra la réponse de l’agent b et désignera donc la continuation du comportement défini par a.
Grâce à l’opérateur de restriction ν(c), le nom c est garanti unique, et de cette manière la réponse ne peut être confondue avec la réponse d’un hypothétique agent x de modèleA car les messagesacceptetrefusene sont pas directement gérés parxmais bien par un processus dont le canal d’entrée c est unique.
Remarque 3 Dans cet exemple, les agents disparaissent une fois que leur action se termine. Dans
un scénario plus réaliste, le comportement des agents serait décrit par des équations récursives pour permettre un maintien de leur activité.
5.4.3 Expression du modèle agent-groupe-rôle
Nous allons donner dans cette section une sémantique opérationnelle du modèle agent- groupe-rôle basée sur le π-calcul et en utilisant une description de type CHAMétendue. Ce modèle utilise les définitions classiques du π-calcul et y rajoute deux opérateurs.
En soi, ce modèle de calcul ne peut pas traduire toute la dynamique de l’organisation telle qu’on l’a exprimée dans le modèle organisationnel. Si nous sommes en mesure d’expli- citer la structuration des groupes vus comme un ensemble de solutions, et les rôles comme des aspects architecturaux de l’agent, il nous manque encore l’expression des mécanismes d’entrée et sortie de groupe ou de demande et abandon de rôle. Nous verrons dans la section
Nous allons maintenant faire le lien entre l’idée d’agent et de groupe que nous venons de formaliser avec le concept de rôle.
5.4.4 Agent et contexte social
En fait, on aboutit à une sorte d’incohérence, ou tout au moins de cercle vicieux. D’une part, le modèle agent-groupe-rôle ne nous autorise pas à expliciter l’architecture interne des agents. Mais d’autre part, si nous ne pouvons pas briser cet aspect unitaire et opaque de l’agent, nous ne pourrons en donner qu’une expression purement descriptive dans ce forma- lisme, ce qui ne serait guère satisfaisant.
La solution consiste en fait à se reposer sur le modèle lui-même : dans la vision agent- groupe-rôle, l’agent est vu comme une entité active agissant dans un certain nombre de groupes selon des rôles qui en structurent les interactions.
Notre hypothèse sera donc de supposer que l’agent établit ses actions en fonction de ses interactions. En revenant au modèle, cela veut dire que l’on envisage les comportements comme étant structurés par les contextes des différents rôles que l’agent va tenir. Nous pou- vons alors définir le comportement d’un agent comme l’ensemble des comportements qu’il va associer aux à ses rôles.
Chaque comportement de rôle est donc représenté comme un processus, c’est à dire comme un ensemble d’équations de processus. De ce fait, le comportement d’un agent va être représenté comme un n-tuple hA0, .., Ani où chaque Aisera représenté par un jeu d’équa- tions de processus de forme Aij(id, v1ji , .., vikj) = Pji avec Pji dénotant un processus et id une constante désignant l’identité de l’agent, c’est à dire un nom unique qui fédère l’ensemble de ses comportements de rôles.
Un de ces comportement de rôle, A0, va avoir un sens particulier : c’est le comportement principal de l’agent qui va assurer la cohésion de tous les rôles joués par l’agent. C’est là que la connaissance globale de l’agent sera définie, à savoir toute information ne se réfèrant pas à un des rôles de l’agent. Ce comportement sera appelé le comportement propre de l’agent.
Il y a quelques restrictions sur la manière de décrire le comportement d’un agent avec ce modèle. A l’exception du comportement A0, la contrainte suivante s’applique sur tout comportement interne d’un agent :
Contrainte 1 Toute équation Ai
j définissant le comportement de rôle i d’un agent ne peut inclure de désignation d’un autre comportement, à l’exception du comportement de rôle i lui-même ou du comportement global A0.
Donc, pour tout comportement de rôle tel que Ai
j(id, vi1j, .., vnji ) =def Pjiet pour toute définition Arkprésente dans Pji, r = i où r = 0.
En fait, cette contrainte signifie qu’un rôle ne peut invoquer directement un autre rôle. Tous les rôles sont opaques les uns par rapport aux autres au sein d’un même agent, et tout
partage d’information entre deux comportements de rôle transitent par le comportement propre A0.
Une conséquence de cette modélisation est qu’il faut pouvoir cloisonner les différents comportements de rôle d’un agent. Cette séparation s’exprime naturellement par le place- ment dans différentes solutions de la MAAM. Il reste aussi à empêcher un agent x de com- muniquer directement avec le comportement propre d’un agent y, puisque toute interaction s’exprime par rapport aux deux rôles qui la séparent.
La manière la plus générique de résoudre ce dernier point est d’associer un groupe privé (au sens du modèle agent-groupe-rôle), qui sera représentée dans la MAAM par une autre solution étiquetée, et dans laquelle un agent placera son comportement propre à la création. La construction d’un agent ayant le comportement propre A(a, v1, .., vn)se fait alors comme suit :
NewAgent(A)=def
in Orig.ν(a).(new a.in a.A(a,v1,..,vn))
Une simple opération de restriction ne serait pas suffisante dans ce cadre, car il convient d’éviter toute réecriture potentielle lors de l’arrivée future d’information via un rôle quel- conque qui ne correspondrait pas au comportement du rôle choisi.
Les communications entre le comportement propre et les divers rôles d’un agent sont fait par la primitive in qui permet le transfert d’un processus entre deux solutions. De ce fait, le comportement de rôle d’un agentadans un groupegenvoyant une requêtereqavec les arguments a1, .., anavec pour continuationcpeut être décrit par l’expression suivante :
SendSelf(a,g,req(e1,..,en),c) =def
ν(c1)(in a.a(req(e1,..,en),c1).c1(r).in g.c(r))
Le messagereqest alors encapsulé dans un processus qui est transféré dans le groupe propre (de nom a). Quand un résultat est envoyé à la continuation c1, l’information est renvoyée dans le groupeget le résultat finalement transmis à la continuation finalec.