Modélisation d'un système multi-agents : application à la réunion d'attribution des charges horaires au département d'informatique de gestion

3.3. ANALYSE ET INTEGRATION DU PROTOCOLE CONTRACT-NET DANS LES REUNIONS D'ATTRIBUTIONS DES CHARGES HORAIRES AU DEPARTEMENT D'INFORMATIQUE DE GESTION

3.3.1. Analyse du Protocol Contract-net

Le protocole Contract Net est le protocole d'interaction le plus utilisé dans les systèmes multi-agents. Il repose sur un mécanisme d'allocation de tâches régi par le protocole d'appel d'offres qui est utilisé dans les organisations humaines. Ce protocole est basé sur le rôle d'initiateur (appelé Manager) et le rôle participant (voir figure 4.1) que nous détaillons dans la suite de cette section.

a) Le rôle initiateur du Contract Net

La figure 4.2 est un automate qui modélise l'activité du rôle initiateur. L'initiateur commence par envoyer un appel à proposition (cfp) qui contient la description de l'action à exécuter et une expression de pré-condition contenant un paramètre de proposition. Dans une extension de ce protocole, on ajoute un Timeout pour éviter des attentes infinies de l'initiateur. Le Timeout est indiqué dans l'attribut reply-by du message Cfp.

Voici un exemple de message cfp issue de^85(*). Dans ce message l'agent i demande à l'agent j de lui faire une proposition pour la vente de 50 prunes.

(cfp

: sender (agent-identifier : name i)

: receiver (set(agent-identifier :name j))

: content

"((action (agent-identifier :name j)

( sell plum 50))

( any ?x (and (= (price plum) ?x) (< ?x 10))))"

: ontology fruit-market

: langage fipa-sl)

Figure 9. Message cfp

Nous considérons que les actions de communication (actions d'envoi ou de réception de messages) sont génériques, elles sont supportées par l'agent qui joue le rôle. La gestion de communication est une compétence de base de l'agent, supportée par la majorité des plates formes multi-agents. Les données nécessaires à la préparation du message Cfp sont :

(i) la description de l'action à exécuter,

(ii) la pré-condition et

(iii) le(s) paramètre(s) de proposition.

Figure 10. Le rôle initiateur du protocole FIPA Contract Net

Source : Tarek Jarraya, Réutilisation des protocoles d'interaction et Démarche orientée modèles pour le développement multi-agents, Université de Reims Champagne-Ardenne, 8 décembre 2006.

Après la réception de toutes les propositions, l'initiateur doit les évaluer pour en choisir une.

En cas d'utilisation de Timeout, l'évaluation a lieu juste après son expiration, même si l'initiateur n'a pas encore reçu toutes les réponses, qui sont au nombre des participants moins les réponses Refuse reçues. Toute proposition reçue, après l'expiration du Timeout, sera automatiquement rejetée en envoyant un message Reject-proposal. Dans certains cas, cette évaluation peut aboutir à un rejet total de toutes les propositions. L'évaluation des propositions est une action décisionnelle propre à chaque agent. De ce fait, elle doit être considérée comme un paramètre du rôle. Cette action décisionnelle est considérée comme une boîte noire qui prend comme paramètre une liste de propositions et qui peut retourner la proposition sélectionnée.

Dans le cas où une proposition est sélectionnée, l'initiateur envoie un message Accept-proposal au participant dont la proposition est acceptée et un message Reject-proposal aux autres participants. A la fin de l'interaction, l'initiateur reçoit de la part du participant un

Inform-done pour confirmer l'exécution de l'action. Il peut recevoir à la place du Inform-done un Inform-result qui contient le résultat retourné suite à l'exécution de l'action.

L'activité du rôle peut se terminer par :

- un échec dans les cas suivants : (i) l'initiateur ne reçoit aucune proposition, (ii) aucune proposition n'est acceptée, ou (iii) l'initiateur reçoit un message Failure,

- un succès, après la réception du message Inform-done ou Inform-result.

D'après cette analyse nous pouvons dire que toutes les actions et les décisions de ce rôle peuvent être décrites de façon générique. Cependant, nous ne constatons que l'exécution de ce rôle nécessite : (i) la description de l'action à réaliser, (ii) la liste des agents participants et

(iii) le processus d'évaluation des propositions evaluate-Proposals.

b) Le rôle participant du contract-net

La figure 4.3 est un automate qui modélise l'activité du rôle participant. A la réception du Cfp, le participant évalue son intérêt pour l'action en fonction de ses ressources et de ses compétences. Si l'action est intéressante, le participant formule une proposition en se basant sur la description de l'action et l'expression de pré-condition, qui est donnée dans le message Cfp. Le participant donne une valeur au paramètre de proposition.

Voici un exemple de message propose issue de^86(*). Dans ce message agent j propose à agent i de lui vendre 50 prunes à 5$.

(cfp

: sender (agent-identifier : name j)

: receiver (agent-identifier :name i)

: content(

"((action j (sell plum 50))

(=(any ?x (and (= (price plum) ?x) (< ?x 10))) 5))"

)

: ontology fruit-market

: in-reply-to proposal2

: langage fipa-sl)

Figure 11. Message propose

Le participant peut aussi refuser de faire une proposition. Pour ce faire, il envoie un message Refuse à l'initiateur. L'action décisionnelle de faire une proposition Decide_to_Propose, est considérée comme interne à l'agent. Elle prend comme paramètres la description de l'action à exécuter ainsi que l'expression de la pré-condition et peut retourner comme résultat une proposition.

A la réception d'un Accept-proposal, le participant s'engagera à exécuter l'action décrite dans le Cfp sous les conditions définies dans l'expression de pré-conditions et avec la proposition qu'il vient de soumettre. L'exécution de l'action dépend des compétences et des ressources de l'agent, elle ne fait pas partie de la description du rôle d'interaction. Si le participant parvient à exécuter l'action, alors il envoie un message Inform-done ou Inform-result contenant le résultat de l'exécution de l'action. Si le participant échoue dans l'exécution de l'action, alors il envoie un message Failure contenant la raison de l'échec. Dans le cas où le participant reçoit un message Reject-proposal, il quitte l'interaction.

L'activité du rôle peut se terminer par un :

Figure 12. Le rôle participant du protocole FIPA Contract Net

Source : Tarek Jarraya, Réutilisation des protocoles d'interaction et Démarche orientée modèles pour le développement multi-agents, Université de Reims Champagne-Ardenne, 8 décembre 2006.

- échec, à la réception d'un message Reject-proposal, ou l'envoie d'un message Failure.

- succès, après l'envoie du message Inform-done ou Inform-result.

En résumé, l'activité de ce rôle peut être décrite de façon générique. Cependant, son exécution nécessite la spécification du processus de construction de la proposition.

* ⁸⁵ FIPA. Fipa acl message structure specification. Technical report, 2002.

* ⁸⁶ FIPA. Fipa-acl message structure specification. Technical report, 2002.