Le TOOLKIT Zeus :Architecture et approches

Auteur Muthanna Alshoufi

Zeus est une plateforme qui consiste en un ensemble de composants, écrits en Java, qui peuvent être catégorisés en trois groupes fonctionnels (librairies) comme le montre le figure ci-dessous : librairie de composants d'agent, un outil de construction d'agent, et un ensemble des utilités d'agents incluant le NameServer, le Facilitateur et les agents de visualisation.

Composants du TOOLKIT Zeus

C'est une collection de classes qui forment les blocks essentiels des agents. Ensemble ces classes implémentent la fonctionnalité agent-level indépendante de l'application dans les agents collaboratifs. Pour communiquer, la librairie de composants d'agents fournie :

• performative-based agent communication language, dans notre cas c'est KQML.
• Un système asynchrone de passage de messages basé sur les sockets
• Un éditeur pour décrire les ontologies du domaine spécifique
• Un langage de représentation de connaissance frame-based pour représenter les concepts du domaine

Pour le raisonnement et la coordination multi-agents, la librairie de composants d'agents fournie :

• general-purpose planning and scheduling system convenable au domaine d'applications orientées-tâche.
• un engin de coordination contrôlant le comportement social d'un agent, i.e quand et comment il interagit avec les autres agents et le type d'abréviation qu'il crée avec eux.
• une librairie de protocoles de coordination prédéfinis et réutilisables.
• Des téchniques de représentation de connaissance et une base de donnée pour décrire et restaurer les ressources et les compétences d'un agent.

Ensemble, les composants de la librairie permettent de construire un agent zeus générique et indépendant de l'application,cet agent-ci peut être personnalisable et implémenté dans certaines applications en l'imprégnant avec les ressources spécifiques du problème,compétences, information, relations organisationnelles et les protocoles de coordination.

L'architecture d'un agent générique Zeus qui n'est pas très différente de celles dans la littérature

L'agent Zeus générique comporte les composants suivants :

• Mailbox : traite les communications entre l'agent et les autres agents.
• Message Handler : traite les messages venant du Mailbox et les envoie aux bons composants de l'agent.
• Co-ordination Engine : prend la décision concernant les objectifs de l'agent, par exemple, comment sont-ils recherchés, quand les abandonner, etc. En outre cet engin est responsable de coordonner les interactions de l'agent avec les autres agents sachant utiliser ses protocoles de coordination et sa stratégie.
• Acquaintance Database : décrie les relations de l'agent avec les autres agents appartenant à la même société, et ses croyances sur la capacité de ces agents-là. Le « Co-ordination Engine » utilise les données stockées dans cette base de donnée quand il établit des gestions collaboratives avec les autres agents.
• Planner/Scheduler : fait le planning des tâches de l'agent en se basant sur les décisions prises par le Coordination Engine et par les ressources et spécifications de tâche disponible.
• Resource Database : maintien une liste des ressources disponible pour l'agent et lui appartenant. La base des données des ressources supporte aussi une interface directe aux systèmes externes.
• Onology database : stocke la définition logique de chaque fact-type, ses attribues légales, l'échelle des valeurs légales de chaque attribue, toutes contraintes sur les valeurs des attribues, et les relations entre les attribues de la réalité et autres réalités.
• Task/Plan Database : fournit les descriptions logiques des paramètres de planning connus par l'agent.
• Execution Monitor : maintient l'horloge interne de l'agent, lance, arrête, et surveille les tâches ayant été mises en scheduling afin d'être exécutée ou términée par le Planner/Scheduler. Il signale au Planner l'état de terminaison des tâches qu'il surveille.

En réalité, les développeurs des systèmes multi-agents n'ont pas besoin de savoir les détails de la librairie de composants d'agent pour créer leurs systèmes. Donc, on va présenter l'approche au design de l'agents et brièvement décrire l'environnement visuel supportant cette approche. L'approche au design de l'agent Zeus nécessite que les développeurs considèrent qu'un agent quelconque soit composé de trois couches : couche de définition, couche d'organisation et couche de coordination.

Les différentes couches formant l'agent

Au niveau de la couche de définition, l'agent est représenté comme une entité de raisonnement autonome, dans le terme de ses compétences, modèle de rationalité, ressources, croyances, préférences, etc.
Au niveau de la couche d'organisation, par exemple, de quels agents il doit se méfier, quelles relations il a avec les autres agents, etc.
Au niveau de la couche de de coordination, l'agent est représenté comme une entité sociable, dans le terme de ses techniques de négociation et coordination.
Au dessus de la couche de coordination se trouvent les protocoles implémentant la communication entre agents, et au dessous de la couche de définition il y a l'interface du programmeur qui autorise à l'agent d'être lié aux programmes externes lui offrant des ressources et/ou utilisant ses compétences.

Les étapes du design d'un agent Zeus

1. Domain Study : à l'étape initiale, le développeur analyse le domaine du problème afin d'identifier les agents potentiels et de créer une ontologie des concepts dans le domaine. Le choix des agents candidats dépend largement de la granularité dans laquelle le problème est modelé, et sera très domain-specific et problem-specific. Cependant, à ce stade du design seulement les concepts du domaine majeur nécessitent d'être identifiés et définis ; les concepts de niveau plus bas peuvent être reportés jusqu'à la seconde itération du processus de design quand le domaine sera mieux compris.
2. Agent definition : une fois tous les agents candidats sont identifiés, alors le développeur diagnostique les attributs signifiantes de chaque agent. Exemple, sur un agent à ce stade de définition, un manageur en charge d'une usine comprenant un nombre de ligne de production (des machines identiques), chacune entre elles peut effectuer de différentes tâches. Le manageur a à sa disposition un certain nombre de ressources, et la production d'un article pourrait consommer une quandité de ces ressources, en concidérant un processus de production qui dure un intervalle de temps limité. Le rôle du manageur est de produire des articles en fonction de la demande des clients. Pour faire cela, le manageur a à faire le scheduling sur les demandes des clients en utilisant les ressources disponibles, machines libres et le coût et temps nécessaire pour accomplir la tâche. Une demande typique d'un client est de la forme «produisez-moi un article u donné v en temps w à coût x ». Pour aider le processus du scheduling de manager, il conserve une agenda de ses engagements courants.
3. Or, la phase de définition de l'agent consiste à :
   • Identifier les tâches que l'agents peut achever, exemple : les différentes tâches que les machines dans l'usine peuvent accomplir et les articles qu'elles produisent.
   • Déterminer le nombre de tâches que l'agent peut exécuter simultanément,exemple: le nombre des lignes de production indépendantes dans l'usine.
   • Identifier durant combien de temps l'agent pourra arranger ses activités, exemple : la période maximale durant laquelle le manager de l'usine satisfait les demandes.
   • Identifier les ressources initiales dont l'agent a besoin, ex : les ressources initiales disponibles pour le manager.
4. Task definition : à ce stade du design, les tâches ayant été identifiées à la phase de définition sont définies selon leurs pré conditions, effets, coût, duré et contraintes. Typiquement les pré conditions d'une tâche sont consommées pour produire ses effets, et les expressions du coût et la duré d'exécution de tâche sont fonctions des effets et/ou des pré conditions, alors que les contraintes d'une tâche sont soit relatives aux pré conditions et/ou aux effets de tâche soit imposent quelques restreints d'applicabilité sur l'opérateur.
5. Agent Organisation : à ce stade du design, le développeur identifie la connaissance de chaque agent. Pour qu'un agent A fasse connaissance avec un autre agent B, il faut que les ressources que l'agent A croit que l'agent B produit soient spécifiées, tout au long de la relation organisationnelle que l'agent A pense partager avec l'agent B. De plus, pour chacune des ressources dont l'agent A croit que l'agent B peut produire, les croyances de l'agent A sur le coût moyen que l'agent B réserve pour cette ressource sont identifiées.
6. Agent co-ordination : cette phase comporte l'identification des protocoles de coordination appropriés nécessaires pour chaque agent et lui servant dans ses interactions sociables avec les autres agents lors de l'exécution de ses devoirs.
7. Code generation and task implementation : l'étape finale, toutes les informations nécessaires, pour générer le code source automatiquement pour chaque agent, doivent être disponibles. Les seuls ingrédients manquants sont les codes de programmes implémentant le corps des tâches primitives. Le Agent Building Software fournie un outil de génération de code qui peut automatiquement générer les programmes des agent un par un à partir de leur spécification. En outre, pour chaque tâche primitive, il génère un («stub code») pouvant être utilisé par le programmeur avec le corps de tâche appropriée.

Le package d'outils Zeus comporte un agent NameServer et Facilitator pour la captation des informations, avec un agent Visualiser pour visualiser ou débugger les sociétés des agent Zeus. Une société d'agents Zeus peut contenir n'importe quel nombre de ces outils agents, avec au moins un agent NameServer.
Les agents NameServer ont seulement un Mailbox et un Message Handler, en plus ils conservent un horloge socity-wide, et par conséquence lors de l'initialisation, l'agent s'inscrit avec le NameServer et fait synchroniser son horloge interne à celui du NameServer.
Les agents Facilitator ont un Mailbox et un Message Handler pour recevoir et répondre aux requêtes venant d'un agent, et une Acquaintance Database pour stocker les capaciés des agents. Ils fonctionnent en faisant des requêtes périodiquement sur tous les agents dans la société concernant leurs capacités, et stocker les réponses dans la base de données.
Les agents visualiser pour montrer, analyser ou débuuger les sociétés des agents Zeus. Ils fonctionnent en faisant des requêtes sur les autres agents et leurs états et processus, et ensuite interpréter les réponses récoltées pour créer un modèle du comportement collaboratif des agents, ce modèle est maintenu mis à jour et peut être affiché en utilisant les outils de visualisation supportées par les agents Visualiser :

• Report Tool : montre la décomposition/distribution society-wide des tâches actives et l'état de l'exécution.

• Society Viewer : affiche tous les agents appartenant à une société et leurs interrelations organisationnelles. En plus, il peut montrer les messages échangés entre les agents durant le processus de solution du problème

• Control Tool : qui est utilisé pour montrer et/ou modifier les états internes des agents individuels et cela se passe de manière remote. Donc, le comportement d'un agent peut être redéfini en Runtime en utilisant cet outil pour modifier ses tâches, ressources, ou base de données, ou même en lui affectant de nouveaux rôles de traitement de messages et/ou une coordination de graphes.
• Statistics Tool : Les statistiques des agents individuels et agents society-wide dans des formats différents

Haut