WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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

( Télécharger le fichier original )
par Jean-Marie MUNGUAKONKOKWA
ISP Bukavu - Licence en pédagogie appliquée option informatique de gestion 2009
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

2.1.1.5 Extensions et langages moins répandus

Les langages de communication entre agents et leurs extensions présentés dans cette section sont de toute évidence moins répandus que KQML et FIPA-ACL, mais ils en reprennent et partagent les fondements. Nous les présentons ici d'abord par souci de complétude, mais aussi parce qu'ils soulignent le besoin de contexte d'interaction et de conversation que nous avons identifié.

- KAoS de Bradshaw et al.75(*) 76(*), définit un langage de communication somme toute assez similaire à KQML. Il contient moins d'actes de langages, que les auteurs dénomment par « verbes », mais est très axé sur la notion de conversation.

Les messages de KAoS ont un paramètre permettant d'identifier une conversation, et un autre spécifiant le protocole d'interaction utilisé (conversation policies). Les conversations peuvent être imbriquées, et modélisées par une machine à états finis.

Les protocoles d'interaction sont organisés en suites, qui sont des « familles» de protocoles d'interaction, dans lesquels les rôles sont déclarés. Les rôles des différents protocoles sont classés soit comme initiateurs (client), soit fournisseurs du service (serveur). La suite permet de réutiliser les verbes d'un protocole, dans le but de l'étendre en une version plus spécifique ou élaborée. Un service est associé à une ou plusieurs suites. Le facilitateur se comporte comme un répertoire de services.

- COOL de Barbuceanu et Fox77(*), est quant à lui une extension de KQML orientée vers les conversations et leur coordination, et plus particulièrement la spécification opérationnelle de protocoles d'interaction, appelés ici classes de conversations. COOL ne redéfinit pas la sémantique et le format des messages de KQML, mais ajoute un certain nombre d'actes de langages comme Propose, Counter-propose, ou encore commit, de-commit.

COOL utilise un paramètre permettant d'identifier les conversations dans les messages, de la même manière que KAoS. Son originalité est qu'il définit un formalisme pour décrire les règles, états et transitions d'une classe de conversation. Dans ce formalisme les rôles sont explicites, et sont décrits au moyen d'une machine à états finis. Il ajoute également des règles de continuations, permettant de spécifier comment un agent pourra enchaîner plusieurs conversations, et des préconditions d'applicabilité de certains rôles à un message donné, par le biais d'un nouveau paramètre de message, internet. Il permet enfin de définir des interdépendances entre conversations et leurs états, ce qui constitue une forme de composition de conversations.

- AgenTalk de Kuwabara et al78(*), est plus axé sur la définition de protocoles d'interaction, à la manière de COOL, mais cette fois-ci sous la forme d'un langage de script. Le but est clairement d'opérationnaliser les définitions de protocoles en interprétant directement ces scripts, et non une description formelle. Un interpréteur est fourni par l'auteur, et appliqué à un projet de télé-organisation.

Une originalité de AgenTalk est la possibilité pour un script d'hériter d'un autre script, ce qui permet de concevoir un protocole d'interaction comme une extension d'un protocole existant. La encore nous retrouvons l'idée de composition de protocoles, sous une forme d'héritage particulière.

La présentation de ces trois ACL est intéressante car elle montre d'une part certaines réponses aux critiques faites à KQML dans ses débuts, et, d'autres part, la nécessité unanime de disposer d'une unité de modélisation de la communication plus large que le simple acte de langage : la conversation.

L'apparition de cette notion, notamment dans FIPA- ACL, marque je pense un virage important dans la communauté des SMA communiquants. De fait, l'idée d'agents fortement cognitifs, capables d'inférer par eux-mêmes la séquence du discours à suivre par simple raisonnement sur la sémantique des actes de langages, est peu à peu abandonnée, car peu réaliste dans l'état actuel des choses. Les concepteurs misent plus volontiers sur des séquences pré-établies, conçues pour une tâche donnée, mais réutilisables, que deviendront les protocoles d'interaction. Un tel protocole est donc une manière de spécifier une collaboration, en termes de communications.

Pour permettre aux agents de suivre ces protocoles prédéfinis, il est nécessaire de réifier (que j'utilise ici au sens de « rendre explicite ») un minimum les instances de conversations. D'où l'apparition et l'utilisation de paramètres identifiant la conversation (Conversation en KaoS ou COOL, ou Conversation-ID en FIPA ACL), et également d'un paramètre identifiant le protocole d'interaction qui la régit (protocol en FIPA-ACL). Le fait est que KQML n'inclut pas ces paramètres - même si une version modifiée, KQML-Lite, inclut protocol.

Dans cet ordre d'idée, un langage de communication entre agents devient plus un outil de coordination au sens large, c'est à dire de standardisation des conversations qui doivent être coordonnées correctement, qu'un langage définissant la sémantique des intentions de l'agent par rapport aux connaissances communiquées.

2.2.2 Systèmes multi-agents conversationnels

Conversation est un concept important dans ce travail de recherche, car c'est autour de lui et autres que s'articulent les différentes solutions proposées au Département d'Informatique de Gestion pour la gestion des réunions d'attribution des charges horaires. Il est donc essentiel de les définir et de les situer convenablement par rapport aux définitions que l'on trouve dans la littérature, afin d'éliminer d'éventuelles confusions.

2.2.2.1 Du contexte d'interaction à la conversation

Cette section définit précisément ce que j'entends par contexte d'interaction, mais développe aussi l'idée que ce contexte d'interaction est nécessaire à la spécification du comportement des agents.

Le contexte d'interaction est un contexte dans lequel tout agent se place lorsqu'il effectue plusieurs échanges de messages, ou interactions diverses, liées les unes aux autres par des relations de dépendance sémantique, par exemple de causes à effet, et par un objectif collectif temporaire. Ce contexte comprend aussi bien les interactions passées, déjà effectuées dans le cadre de cette tâche, que les interactions potentielles futures attendues de l'agent et des autres participants, c'est à dire les différents engagements et responsabilités pris implicitement ou explicitement par eux à ce sujet. Une bonne coordination dépend de ces engagements, et de leur connaissance partagée.

Les responsabilités associées aux interactions futures peuvent être modélisées de façon plus ou moins détaillée. Elles sont directement liées à la description du comportement de l'agent dans ce contexte, puisqu'il est censé se conformer à la description publique de ce comportement. Dans le cadre d'une conversation, nous exprimerons que ces responsabilités sont régies par un rôle dans un protocole d'interaction.

Protocoles multi-parties et rôles multiples. Les protocoles d'interactions ne sont pas nécessairement des dialogues impliquant uniquement deux interlocuteurs, comme c'est le cas dans le modèle client-serveur sous-jacent à l'appel de méthode distant. Une conversation peut impliquer un grand nombre d'agents, chacun devant suivre un comportement cohérent et coordonné par rapport aux autres.

Figure 3. Conversation multi-parties

Source : Denis Jouvin, Délégation de Rôle et Architectures Dynamiques de systèmes Mullti-agents conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse de Doctorat 2003.

Dans la définition d'un protocole d'interaction, les responsabilités sont regroupées en différents rôles, qui sont attribués à chaque participant et qui correspondent aux responsabilités et au comportement attendu de cet agent en particulier dans la conversation.

Multi-parties signifie que le protocole comporte plus de deux rôles.

Par extension, un rôle peut être associé à un groupe de participants ayant des comportements supposés identiques. Nous parlerons alors de rôle multiple. Le contexte d'interaction que représente la conversation comprend également les identités de tous les participants à la tâche collective, ainsi que les rôles qui leurs sont affectées.

La figure 4 montre, en notation intuitive par messages numérotés, un exemple abstrait des conversations multi-parties.

Définition d'une conversation.

Une conversation est un contexte d'interaction, effectuée dans le cadre d'une tâche collective, faisant état des messages déjà échangés, des interlocuteurs ou participants connus de la conversation, et des responsabilités et rôles qui leurs sont affectés, en termes d'échanges de messages potentiels.

Nous pouvons ajouter que la prise en compte des conversations multi-parties et à rôles multiples, est une différence majeure entre les systèmes multi-agents conversationnels et les systèmes à objets distribués ou orientés composants. Même lorsque des protocoles sont associés aux interfaces des composants, leur modélisation se limite au modèle client-serveur, c'est à dire à un dialogue initié par un seul composant client, avec le composant serveur.

2.2.2.2 Structure de message et réification de conversation

Pour pouvoir permettre aux agents de participer à plusieurs tâches collectives simultanément, la conversation elle-même doit être identifiée explicitement dans les messages, de façon à éliminer les ambiguïtés, en rattachant les messages aux contextes qui les concernent. Ce besoin a été reconnu par plusieurs Chercheurs [79(*)][80(*)][81(*)].

En pratique, dans un système donné, une partie des méta-informations de la communication sera implicite, une autre partie sera explicite, encodée dans les messages échangés. Cette partie explicite est plus importante dans les systèmes multi-agents que dans d'autres systèmes distribués, ce qui offre de multiples possibilités :

- Enrichir et désambiguïser la sémantique de chaque message, d'une façon générale ;

- Étendre le modèle d'interactions à des tâches collectives et conversations de plus de deux interlocuteurs ;

- Permettre aux agents de valider plus facilement que les autres participants respectent les rôles qui leurs sont attribués ;

- Permettre aux agents d'implémenter des protocoles plus compliqués ou optimisés, grâce à l'élimination d'ambiguïtés ;

- Enfin permettre aux agents d'effectuer plusieurs conversations simultanément.

Ces apports, que nous détaillerons plus avant en section 2, dépendent du degré de réification des conversations (simple identifiant, protocole, rôle, composition, etc.).

Figure 4. Exemple d'un message FIPA-ACL

Source : Denis Jouvin, Délégation de Rôle et Architectures Dynamiques de systèmes Mullti-agents conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse de Doctorat 2003.

Le concept de conversation est présent dans le modèle des messages de plusieurs ACL, notamment FIPA-ACL. La figure 4 donne une représentation synthétique de la structure des messages de FIPA-ACL. Cette structure de message comprend une liste de paramètres nommés, dont la valeur peut éventuellement être une liste.

Les paramètres prédéfinis sont donnés dans le tableau2, où nous traitons KQML et FIPA ACL ensembles, par soucis de clarté.

Tableau 2. Paramètre des messages KQML et FIPA ACL

Source : Denis Jouvin, Délégation de Rôle et Architectures Dynamiques de systèmes Mullti-agents conversationnels, Université Lyon I-Claude Bernard, Paris, Thèse de Doctorat 2003.

Au vu de ce tableau (en considérant surtout FIPA-ACL), nous observons que, sans compter le performatif, cinq paramètres sont liés à la gestion de la conversation : protocol, conversation-id, reply with, in-reply-to, et reply-by. En pratique, reply-with et in-reply-to sont peu utilisés, au profit de conversation-id qui identifie globalement la conversation. Le paramètre reply-to est essentiellement utilisé dans le cas de courtage de type recrutement (protocole recruiting).

Remarque. Le protocole d'interaction est référencé dans les messages, ainsi qu'un identifiant de la conversation. Par contre, les rôles ne sont pas réifiés : ils sont implicites, déduits du performatif du premier message reçu par les participants, durant l'initialisation de la conversation. La plupart des protocoles d'interactions de FIPA sont des dialogues. Le rôle complémentaire est alors implicite, et sa réification inutile, ce qui explique probablement pourquoi les standards actuels ne réifient pas les rôles.

Pour modéliser correctement des SMA conversationnels dans le cas général, nous ne pouvons imposer au modélisateur de limiter les conversations à des dialogues ; les conversations doivent pouvoir être multi-parties. Certaines tâches collectives nécessitent en effet par essence plus de deux rôles. A titre d'exemple, citons les protocoles de cryptographie et d'établissement de clef et les enchères sécurisées. Ces protocoles mettent souvent en jeu trois rôles ou plus, dont une tierce partie de confiance, qui doit explicitement être distincte des autres participants.

* 75 Jeffrey Bradshaw, Stewart Dutfield, Bob Carpenter, Renia Jeffers, Tom Robinson: KAoS: A Generic Agent Architecture for Aerospace Applications. Dans les actes de Conference on Information and Knowledge Management (CIKM), Baltimore, MD, USA, Décembre 1995. cité par Jouvin Dennis, Op.Cit

* 76 Jeffrey Bradshaw: KAoS: An Open Agent Architecture Supporting Reuse, Interoperability, and Extensibility. Dans les actes de Knowledge Acquisition Workshop (KAW).Novembre 1996., cité par Jouvin Dennis, Op.Cit

* 77 Mihai Barbuceanu, Mark Fox: COOL: A Language for Describing Coordination in Multi Agent Systems. Dans les actes de International Conference on Multi-Agent Systems (ICMAS), San Francisco, CA, USA, Juin 1995. V. Lesser, L. Gasser (éd.), AAAI Press

* 78 Kazuhiro Kuwabara, Toru Ishida, Nobuyasu Osato: AgenTalk: Coordination Protocol Description for Multiagent Systems. Dans les actes de International Conference on Multi-Agent Systems (ICMAS), San Francisco, CA, USA, Juin 1995. V. Lesser, L. Gasser (éd.), AAAI Press.

* 79 Marian Nodine, Amy Unruh: Constructing Robust Conversation Policies inDynamic Agent Communities. Dans les actes de International Workshop onSpecifying and Implementing Conversation Policies (SICP), Seattle, WA,USA, Mai 1999.

* 80 Mihai Barbuceanu, Mark Fox: COOL: A Language for DescribingCoordination in Multi Agent Systems.Dans les actes de InternationalConference on Multi-Agent Systems (ICMAS), San Francisco, CA, USA,Juin 1995. V. Lesser, L. Gasser (éd.), AAAI Press

* 81 Kazuhiro Kuwabara, Toru Ishida, Nobuyasu Osato: AgenTalk: CoordinationProtocol Description forMultiagent Systems. Dans les actes de InternationalConference on Multi-Agent Systems (ICMAS), SanFrancisco, CA, USA,Juin 1995. V. Lesser, L. Gasser (éd.), AAAI Press

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Piètre disciple, qui ne surpasse pas son maitre !"   Léonard de Vinci