2.2. Modélisation des interactions entre agents
Les échanges entre agents peuvent être
modélisés par des diagrammes de séquences, de
collaboration, d'activités ou d'états-transitions.
Diagrammes de séquences : ce sont une
extension des diagrammes de séquences d'UML. Connus aussi par diagrammes
de protocoles d'interactions.
Les messages échangés ne sont plus des noms de
méthodes mais des actes de communication. Ils sont
caractérisés aussi par l'utilisation des threads
d'interaction concurrents suivants :
- Emissions concurrentes : connecteur AND (a);
- 0 ou plusieurs émissions à la fois : connecteur
OR (b);
- 1 seule émission parmi plusieurs candidates : connecteur
XOR (c).
Diagrammes de collaboration : se construisent
comme dans les modèles objets, ce sont similaires aux diagrammes de
séquences.
Diagrammes d'activités : décrivent
les opérations entre agents et les événements qui les
déclenchent.
Diagramme d'états-transitions :
décrit les changements d'état lors des échanges
entre agents. 2.3. Modélisation des traitements internes des
agents
Les traitements internes des agents et leurs comportements
peuvent être modélisés par des diagrammes
d'activités ou d'états-transitions.
3. Le langage FIPA-ACL 3.1. Introduction
Dans des systèmes multi-agents, les interactions entre
agents font un concept fondamental. Pour assurer ces interactions les agents
ont besoin de communiquer dans un langage compréhensible par tous les
autres.
La compréhension du sens des symboles, ou à quoi
les symboles font référence, demande un standard rigoureux de la
sémantique et de la pragmatique. De plus il est nécessaire que
les agents sachent bien utiliser le vocabulaire pour atteindre leurs buts,
éviter les conflits, coopérer pour exécuter leurs
tâches et modifier l'état mental d'un autre agent [19].
- Notion d'actes de langage : les philosophes
du langage ont développé au cours des 25 dernières
années la théorie des actes de discours qui considère que
« dire quelque chose c'est en quelque sorte agir » [7]. Les paroles
sont interprétées comme des actions appelées actes de
discours. Cette théorie fournit un cadre qui identifie des types d'actes
de discours primitifs et permet de dériver de ces types primitifs
l'interprétation sous forme logique de n'importe quel verbe du langage
qui exprime un acte de discours quelconque. En effet, Les types de messages des
langages de communication entre agents sont appelés des actes de
langage.
3.2. Le langage ACL
Le langage ACL de la FIPA est plus récent et fondé
sur la théorie des actes de langage. Il a bénéficié
grandement des résultats de recherche de KQML.
3.2.1. La syntaxe du message ACL : la syntaxe du
message est assez similaire à celle de KQML. La figure ci-après
résume sur un exemple les éléments principaux du message
ACL.
Message ACL
|
Type d'acte
|
(request
:sender (agent-identifier :name i)
:receiver (set (agent-identifier
:name j)) :content
((action (agent-identifier :name j) (deliver box017 (loc 12
19)))) :protocol fipa-request
:language FIPA-SL
:reply-with order567)
|
|
Paramètres
du message
|
Figure A.2 : Exemple d'un message ACL
Essayons maintenant à définir en bref chaque
élément du message dans le tableau suivant :
|
Elément du message
|
Définition
|
|
Performatif(request)
|
Type d'acte de communication : représente la valeur
illocutoire d'un acte de langage.
|
|
sender
|
l'émetteur du message
|
|
receiver
|
le destinataire du message
|
|
content
|
le contenu du message
(l'information transportée par la performative)
|
|
protocol
|
contrôle la conversation
|
|
language
|
le langage dans lequel le contenu est représenté
|
|
reply-with
|
identificateur unique du message, en vue d'une
référence ultérieure
|
Tableau A.1 : Eléments d'un message
FIPA-ACL.
· Le langage utilisé dans le contenu du
message : le langage de contenu se réfère à la
valeur locutoire d'un message envoyé d'un agent à un autre,
c'est-à-dire au contenu "exprimé" de ce message, et à la
façon de présenter ce contenu. Un message FIPA-ACL supporte par
défaut les langages FIPA-SL, KIF (Knowledge Interchange
Format), XML et RDF ; FIPA-SL ayant été
spécifiquement défini par la FIPA [19].
· Le protocole utilisé : un
modèle structurant uniquement le format d'un message ne suffit pas en
lui même pour pouvoir structurer des conversations entre agents, ce qui
est nécessaire pour conserver la cohérence des échanges
successifs. Nous avons donc besoin de la notion de protocole pour supporter des
conversations valides, ce qui permet aux actes de langage de prendre tout leur
sens. Un tel protocole permet d'inclure le comportement d'un agent dans un
contexte particulier, auquel il doit se conformer en envoyant des messages
cohérents grâce à l'utilisation d'actes de langage
adaptés au discours.
· Actes communicatifs (performatifs) du langage
ACL : FIPA-ACL possède 21 actes communicatifs, exprimés
par des performative, qui peuvent être groupés selon leur
fonctionnalité de la façon suivante [19]:
- Passage d'informations: inform*, inform-if(macro act),
inform-ref(macro act), confirm*, disconfirm* ;
- Réquisition d'information : query-if, query-ref,
subscribe ;
- Négociation : accept-proposal, cfp, propose,
reject-proposal ;
- Distribution de tâches : request*, request-when,
request-whenever, agree, cancel, refuse ; - Manipulation des erreurs : failure,
not-understood.
Ces actes communicatifs peuvent être primitifs
ou composés [19]. Les actes communicatifs primitifs sont
définis de façon atomique, c'est-à-dire qu'ils ne sont pas
définis à partir d'autres actes (dans la classification ci-dessus
ils sont suivis d'une étoile "*"). En revanche, les actes communicatifs
composés sont définis à partir d'autres actes. Le tableau
suivant représente ces différents actes ainsi que leurs
sémantiques :
|
Performatif
|
Syntaxe
|
Sens
|
|
Accept Proposal
|
accept-proposal
|
L'émetteur accepte la proposition d'exécuter
certaines actions présentées à l'avance
|
|
Agree
|
agree
|
L'émetteur accepte d'exécuter certaines actions
|
|
Cancel
|
cancel
|
L'action de l'annulation d'une certaine action
déjà demandée qui a portée dans le temps
(c-à-d: n'est pas instantanée).
|
|
Call for Proposal
|
cfp
|
L'action de l'appel de propositions pour exécuter une
action donnée
|
|
Confirm
|
confirm
|
L'émetteur informe le destinataire qu'une
proposition donnée est vraie
|
|
Disconfirm
|
disconfirm
|
L'émetteur informe le destinataire qu'une
proposition donnée est fausse
|
|
Failure
|
failure
|
L'action de raconter un autre agent que l'action a
été essayée, mais a échouée
|
|
Inform
|
inform
|
L'émetteur informe le récepteur des informations de
l'émetteur connaît.
|
|
Inform If
|
inform-if
|
L'émetteur demande au destinataire une
confirmation ou une non-confirmation d'une certaine
proposition
|
|
Inform Ref
|
inform-ref
|
L'émetteur demande au destinataire un objet qui correspond
à une description envoyée.
|
|
Not Understood
|
not-understood
|
L'émetteur informe le destinataire d'un non
compréhension d'une action effectuée par le destinataire
|
|
Propose
|
propose
|
L'émetteur propose d'exécuter certaines actions
conditionnées à certaines préconditions données
|
|
Proxy
|
proxy
|
L'émetteur demande une transmission d'un
message à des agents dont la description est
donnée
|
|
Query If
|
query-if
|
L'action de demander à un autre agent si une proposition
donnée est vraie ou non
|
|
Query Ref
|
query-ref
|
l'émetteur demande du destinataire un objet
référencé par une expression
|
|
Refuse
|
refuse
|
L'émetteur refuse d'exécuter certaines actions
parce qu'il ne peut pas les exécuter
|
|
Reject Proposal
|
reject-proposal
|
L'action de rejet d'une proposition d'effectuer une action lors
d'une négociation
|
|
Request
|
request
|
L'émetteur demande du destinataire d'exécuter une
certaine action
|
|
Request When
|
request-when
|
L'émetteur veut que le destinataire effectue une action
lorsque certaine proposition donnée soit vraie
|
|
Request Whenever
|
request-whenever
|
L'émetteur veut que le destinataire effectue une action
dès que quelque proposition devient vraie et ensuite, chaque fois que la
proposition devient vraie à nouveau
|
|
Subscribe
|
subscribe
|
L'acte de demander une intention persistante d'informer
l'émetteur de la valeur d'une référence, et de le notifier
à chaque fois que l'objet référencé se change
|
Tableau A.2 : Actes communicatifs du langage
ACL
| 
