Multi A gents
i q
u
E
Magique est un projet de recfherche de l'équipe SMAC du LIFL.
Les personnes impliquées à ce jour sont :
Un agent est au départ une coquille vide dans laquelle on greffe des compétences. Cette compétence peut aller de la capacité à réaliser un calcul élémentaire jusqu'à la capacité à résoudre des gros problèmes de planification ou d'optimisation combinatoire. Notre propos consiste donc à séparer clairement l'agent, de ce qu'il sait faire. Les compétences d'un agent résultent d'une API particulière que chaque spécialiste peut développer et n'a a priori rien à faire dans une plate-forme de base. Si mon souhait est de développer une application de calcul distribué, je n'ai que faire d'un système m'obligeant à définir le travail de l'agent par un réseau de pétri ou un contract-net. De plus nous souhaitons que la distinction soit faite entre agent et agent intelligent. La coïncidence fallacieuse entre ces deux termes dessert selon nous la notion d'agents. Un agent intelligent (pour lequel se pose d'ailleurs l'interminable classique problème de la définition du terme intelligent) n'est qu'un cas particulier d'agent auquel on a donné des compétences faisant intervenir des techniques d'intelligence artificielle (réseaux de neurones, systèmes experts, logique temporelle, etc.).
Reste maintenant à savoir quelles sont les compétences minimales que l'on est en droit d'attendre d'un agent. La réponse est évidente : savoir communiquer avec ses semblables et savoir apprendre de nouvelles compétences. Quid de KQML, ACL ou autres langages de haut niveau permettant l'interaction entre agents. C'est à la couche applicative de fournir cela. Si l'agent sait communiquer il suffit de lui faire envoyer des objets ACL pour qu'il puisse communiquer en ACL. Notre point de vue est que la plate-forme doit offrir cette possibilité sans l'imposer ce qui lui permet du coup de s'adapter à toutes les possibilités.
Magique est une plate-forme de développement d'applications multi-agents basée sur ces idées. Elle n'oblige l'utilisateur ni à utiliser une organisation complexe et statique pour tout type de problème, ni à utiliser un langage de communication unique pour chaque développement. Magique offre par contre toutes les facilités pour les intégrer. Grâce aux notions compétences, d'accointances et aux services de délégation de compétences, concevoir une application physiquement distribuée à base d'agents à travers un réseau hétérogène est aussi facile que d'en concevoir une simulation centralisée. La plate-forme Magique doit donc être vue comme un framework pour la construction d'applications multi-agents, ou, plus précisément comme un framework permettant une approche orientée agents de la résolution de problèmes, de la même manière que l'on parle d'approche orientée objet.
Nos soucis permanents lors du développement des concepts et de la plate-forme ont été la simplicité et l'ouverture. Nous avons voulu que pour une personne connaissant Java, la prise en main soit aussi rapide, facile et naturelle que possible, et que de plus l'utilisateur ne se sente ni limité ni contraint pour développer ses applications SMA.
Après avoir présenté les grandes lignes de Magique, nous présenterons le concept d'agent que nous utilisons. Le but est dans ce cas de présenter l'état d'esprit de notre modèle, celui qui doit donc guider le développeur : un agent est construit incrémentalement par enrichissement dynamique de compétences. Ensuite nous présenterons le modèle d'organisation hiérarchique de SMA qui définit la structure d'accointances par défaut et offre un mécanisme de délégation de requêtes automatique. Une fois ces concepts présentés, nous pourrons aborder la partie pratique avec la présentation de l'API. Cette présentation sera illustrée par la réalisation complète d'un petit exemple très simple. Quelques petites applications sont enfin présentées rapidement.
Dans Magique, un agent est une entité possédant un certain nombre de compétences. Ces compétences permettent à un agent de tenir un rôle dans une application multi-agents. Les compétences d'un agent peuvent évoluer dynamiquement (par échanges entre agents) au cours de l'existence de celui-ci, ce qui implique que les rôles qu'il peut jouer (et donc son statut) peuvent également évoluer au sein du SMA. Un agent est construit dynamiquement à partir d'un agent élémentaire "vide", par enrichissement/acquisition de ses compétences.
Du point de vue de l'implémentation, une compétence peut être perçue comme un composant logiciel regroupant un ensemble cohérent de fonctionnalités. Les compétences peuvent donc être développées indépendamment de tout agent et donc réutilisées dans différents contextes. Une fois ces compétences créées, la construction d'un agent Magique se fait très simplement par un simple mécanisme d'enrichissement de l'agent à construire avec ces compétences. L'ajout de nouvelles compétences (et donc fonctionnalités) dans une application SMA est donc facile.
Concrètement, Magique existe sous la forme d'une APIjava permettant le développement de systèmes multi-agents (SMA) hiérarchiques. Dans ce cas, Magique correspond à un framework générique pour le développement de SMA. Le concepteur de SMA peut donc s'appuyer sur les fonctionnalités offertes par Magique telles que la communication entre agents, la distribution de l'application, l'évolution dynamique, etc. Il a la charge de développer les compétences applicatives dont il a besoin.
Pour toute personne connaissant le langage Java, l'apprentissage de Magique est très simple et l'utilisation de l'API permet de mettre en oeuvre très rapidement et facilement des applications SMA distribuées. En outre, le mécanisme de délégation et la modularité induite par les compétences facilitent la réutilisabilité des agents et de leurs compétences dans différents contextes ou applications.
Enfin un environnement graphique permet la création des agents et de la structure organisationnelle du SMA qui les regroupent ainsi que le déploiement et l'exécution de ce SMA sur un réseau de machines hétérogènes.
Les avantages offerts par notr approche (dynamicité, ouverture, etc.) seront détaillés et présentés au cours de l'article.
Nous avons décrit dans les grandes lignes Magique, nous allons maintenant détailler les différentes notions importantes juste esquissées ici. Tout d'abord, nous parlerons d'agents et de compétences et présenterons notre proposition de définition d'agent construit à partir d'un agent atomique. Ensuite nous introduirons le modèle d'organisation hiérarchique de nos SMA ainsi que le mécanisme de délégation qui en découle. Nous présenterons plus en détail les principes de la programmation avec Magique et l'illustrerons à travers un petit exemple. Enfin nous terminerons par l'environnement graphique de construction des agents et des SMA.
Cependant, pour cette même raison, la définition précédente peut également être accusée d'être trop vague puisqu'elle permet trop de liberté d'interprétation selon les compétences attachées à l'agent. C'est pourquoi nous allons la préciser en fixant un ensemble minimal de compétences.
Nous affirmons que simplement deux compétences initiales sont nécessaires et suffisantes pour définir cet agent atomique à partir duquel toutes les autres définitions d'agent peuvent être établies. Ces compétences sont : pour la première, une compétence qui permet à l'agent d'apprendre de nouvelles compétences, et pour la seconde, une compétence de communication (avec les autres agents -- qui pourraient être humains ou logiciels).
Ces compétences sont en effet nécessaires. Sans la "compétence d'acquisition", un tel agent ne serait qu'une coquille vide incapable de faire quoique ce soit. Sans la "compétence de communication", un agent est isolé du "reste du monde" et perd de ce fait tout intérêt.
De plus la communication est nécessaire à l'acquisition de nouvelles compétences. Elles sont suffisantes puisqu'il suffit à un agent d'utiliser sa compétence d'interaction pour entrer en contact avec un agent compétent et d'utiliser sa compétence d'acquisition pour apprendre de nouveaux talents auprès de celui-ci. Ainsi, n'importe quelle capacité peut être "donnée" à un agent par apprentissage auprès d'un "enseignant".
En conséquence nous proposons la définition d'agent suivante
:
Sans volonté d'entrer dans des débats philosophiques, on peut quand même remarquer que cette définition s'applique également à l'"agent humain", qui, puisqu'il peut communiquer et est capable d'acquérir de nouvelles connaissances, peut évoluer pas à pas à travers ses interactions avec les autres agents (humains et de l'environnement). La communication (initialement à travers les seuls cinq sens, puis, après quelques temps d'évolution, avec la contribution du langage) et l'apprentissage semble effectivement être ses uniques capacités initiales, et elles permettent une éducation complète et complexe. En outre, les personnes qui souffrent de troubles de la communication ou de l'apprentissage ont des difficultés à rejoindre la communauté (le "SMA humain").
Il en résulte que les différences entre les agents proviennent de leur éducation, c'est-à-dire des compétences qu'ils auront acquises au cours de leur "existence". Ces compétences peuvent ou bien avoir été données lors de leur création par le programmeur, ou avoir été dynamiquement apprises suite à des interactions avec d'autres agents (maintenant si l'on considère le programmeur comme un agent, le premier cas est inclus dans le second). Cette vision n'introduit pas de limitation dans les capacités de l'agent. Attribuer des compétences à un agent c'est lui offrir la possibilité de tenir un rôle particulier dans un SMA auquel il appartient.
Avec cette possibilité d'évolution dynamique d'un
agent, il n'est plus possible d'utiliser le terme de "classe" d'agents.
Même si pour différents agents vous partez d'un base commune,
dans la mesure où ils peuvent (et vont probablement) recevoir une
éducation différente due à leurs "expériences"
individuelles, ils vont bientôt diverger et il sera de ce fait impossible
de les considérer comme appartenant à une même "classe".
Cette notion n'a définitivement plus de sens dans ce contexte. Cela
constitue une différence forte entre une telle programmation orientée
agents et la programmation orientée objets.
Les compétences constituent dans notre vision la substantifique moelle des agents. Une compétence est un ensemble de fonctionnalités qui peuvent être exploitées par un agent. Nous voulons que tout soit exprimable en terme de compétences, même la manière de gérer les compétences elles-mêmes. On peut parler dans ce cas de méta-compétences, et même celles-là doivent pouvoir évoluer dynamiquement comme cela a été expliqué précédemment.
D'un point de vue plus pragmatique, une compétence devrait être vue comme un composant dont l'interface publique désigne les capacités qu'un agent peut exploiter. La granularité et le degré de complexité d'une compétence ne peuvent pas être définitivement énoncés. La capacité d'analyser un message XML ou la capacité d'additionner deux entiers peuvent chacune représenter une compétence bien que leurs complexités seraient très probablement considérées comme se situant à des niveaux différents. De plus, savoir si il faut grouper dans une seule compétence les quatre opérations arithmétiques de base (addition, soustraction, multiplication et division) ou les séparer en quatre compétences ne peut pas être clairement établi. Cependant, il devrait être possible d'avoir un assentiment général sur le fait que les capacités d'analyse XML et l'addition doivent se situer dans des compétences différentes. Une compétence doit en effet représenter un ensemble cohérent de capacités. Convenir qu'à une compétence doit correspondre une et une seule capacité (ou réciproquement) pourrait sembler raisonnable, mais la réponse n'est pas aussi simple, et dans tous les cas cela risque de ne pas résister à la réalité des programmeurs... Les problèmes qui apparaissent ici sont les mêmes que ceux habituellement (et universellement) rencontrés en génie logiciel, et en conception objet en particulier, concernant la décomposition en objets.
Nous avons présenté le principe de création des agents Magique. Nous allons maintenant aborder le problème de l'organisation de ces agents dans un SMA.
Il faut cependant préciser que si la structure de base est hiérarchique, ce n'est pas la seule structure d'accointance possible avec Magique. Des liens "directs" entre agents (i.e. en dehors de la hiérarchie) peuvent être créés (éventuellement dynamiquement et automatiquement comme les liens d'accointances présentés plus loin). On peut par exemple disposer d'une forêt de hiérarchies dont les racines sont liées directement, ou avoir des liens d'accointances directs entre des agents présents dans différents sous-arbres d'une hiérarchie afin d'alléger les communications. À l'extrême on pourrait ne pas avoir de hiérarchie du tout, tous les liens d'accointances sont des liens directs, cependant on perd alors la possibilité d'utiliser le mécanisme de délégation de requêtes présenté par la suite.
Une hiérarchie représente la structure initiale des accointances du SMA et induit le support par défaut des communications entre les agents. Un lien hiérarchique représente donc l'existence d'un lien de communication entre ces agents, et lorsque deux agents d'une même structure hiérarchique communiquent, le chemin emprunté par les messages qu'ils s'échangent suit les relations d'accointances et colle, par défaut, à la hiérarchie. Cette communication est alors essentiellement verticale.
Avec uniquement ces communications, le modèle serait probablement trop rigide. C'est pourquoi Magique offre la possibilité de créer des liens directs (i.e. en dehors de la hiérarchie) entre deux agents. Nous les appellerons liens d'accointances (par opposition aux liens hiérarchiques même si ceux-ci désignent également des accointances).
La décision de la création de tels liens dépend de la politique de l'agent. L'idée visée est cependant la suivante : après quelques temps d'évolution du SMA, si il apparaît des requêtes privilégiées (fréquentes) entre deux agents pour une compétence, la décision peut être prise de créer dynamiquent un lien d'accointance entre ces deux agents pour la compétence concernée. L'intérêt est évidemment de diminuer les communications et de mettre en évidence des liens "naturels" d'interaction entre les agents. Ces liens correspondent aux communications horizontales. Une stratégie de création de liens d'accointance peut donc être spécifiée au niveau des agents.
Ainsi, dans Magique, il existe une organisation de communication par défaut : la hiérarchie. Mais cette structure est destinée à évoluer en accord avec le comportement dynamique du SMA en favorisant les relations les plus fréquentes. Il en résulte, qu'après un certain temps, le SMA devrait plus ressembler à un graphe. L'intérêt est que, la structuration étant dynamique et auto-adaptative, le concepteur d'un SMA peut se reposer en partie sur ce mécanisme lors de la conception de l'organisation de son SMA.
Un des avantages de cette délégation transparente
est d'accroître la fiabilité du système : l'agent qui
exécutera la compétence étant indifférent pour
l'invocateur, il peut changer entre deux "appels" à la même
compétence (qu'il ait disparu du système suite à une
panne ou qu'il soit surchargé ou...).
Un autre avantage apparaît lors de la phase de conception des agents et des compétences. Dans la mesure où la recherche d'un agent compétent est automatiquement réalisée par la hiérarchie, quand une requête pour une compétence est écrite, il n'est pas nécessaire de désigner à la conception un agent particulier pour la réalisation d'une compétence donnée. Les destinataires des requêtes ne seront donc pas nommés. Il en résulte qu'un même agent pourra être plus facilement réutilisé dans différents contextes (i.e. différentes applications multi-agent) pour autant qu'un agent compétent (peu importe lequel) soit présent. Il en résulte que lorsque vous concevez un SMA avec Magique, le point important n'est pas tant les agents présents que les compétences présentes.
Un point important dans Magique est la possibilité pour un SMA d'évoluer dynamiquement. Cette dynamique opère à plusieurs niveaux :
L'utilisation de l'API est très simple pour toute personne connaissant le langage Java. Elle constitue un framework de développement offrant aux programmeurs les fonctionnalités de base lui permettant de mettre en oeuvre ses propres outils applicatifs.
Ce framework s'appuie sur la notion de plate-forme. Tout agent doit appartenir à une plate-forme. L'idée est a priori d'avoir une plate-forme par machine. Ces plates-formes constituent la couche basse de Magique et permettent la distribution et l'échange physique des compétences. Si la plate-forme n'est pas un agent à part entière, elle est malgré tout administrée par un "agent plate-forme". Les interactions entre les agents applicatifs et les plates-formes Magique ou entre deux plates-formes se font donc via un agent.
Les agents utilisés dans Magique correspondent à ceux présentés à cette section. Ils sont construits à partir d'un agent atomique par acquisition de compétences. Ainsi, un agent Magique devra par défaut posséder des compétences additionnelles : les compétences pour gérer la hiérarchie, d'autres pour la dynamicité (connexion, création,... ), etc.. Ces compétences sont "livrées" de base par le framework.
Du point de vue méthodologique, la construction d'applications
avec Magique doit suivre la démarche suivante :
Les méthodes publiques de ces compétences seront les fonctionnalités (par abus de langage appelées également compétences) qui pourront être utilisées et donc invoquées par l'agent.
On peut à cette occasion faire remarquer que l'API permet
la création d'agents autres que les agents Magique. Il suffit
d'enrichir un AtomicAgent des compétences que l'on souhaite
pour obtenir un autre "type" d'agent.
En ce qui concerne l'organisation du SMA, celle-ci se crée à travers la mise en place de liens d'accointances qui peuvent être ou non hiérarchiques (voir ici). On peut donc obtenir des SMA sans aucune hiérarchie mais on perd alors la possibilité d'utiliser le mécanisme de délégation de requêtes présentés maintenant.
object.ability(arg...);
pour faire un appel à une méthode ability, vous devez maintenant écrire :
perform("ability",arg...);
Cela a pour effet que la compétence nommée "ability" sera "invoquée" (sans avoir à savoir par qui. Evidemment, Magique offre également la possibilité de préciser un destinataire si besoin est, ceci est d'ailleurs indispensable lorsque deux agents n'ont pas relation d'accointance à travers une hiérarchie mais par un lien direct.).
La primitive perform est dédiée à l'invocation de compétence pour lesquelles on n'attend pas de réponse. Il existe principalement trois autre primitives : ask quand une réponse asynchrone est désirée, askNow pour une réponse immédiate et concurrentAsk pour une invocation concurrente.
L'avantage de cette délégation du point de vue du programmeur,
en comparaison des appels nominatifs, est qu'il n'a pas besoin de connaître
explicitement les agents qui seront présents dans l'application.
Les références se situent en effet au niveau des compétences
et il suffit pour le concepteur de savoir que la compétence est
présente dans le SMA, sans nécessairement connaître
l'agent compétent. Le code produit gagne alors en réutilisabilité.
L'application SMA gagne, quant à elle, en robustesse car l'agent
réalisateur d'une compétence n'étant pas nécessairement
prédéfini, il peut éventuellement varier au fil du
temps, si un agent devient indisponible ou surchargé par exemple.
Ainsi, pour qu'un agent agent, acquiert dynamiquement une nouvelle compétence de nom "skill", il suffit que la ligne suivante soit interprétée :
agent.perform("addASkill",new Object[]{"skill",...args...});
Pour que cette même compétence lui soit cette fois enseignée par un agent de nom "teacher@...", il faut cette fois interpréter :
agent.perform("learnSkill", new Object[]{"skill","teacher@...",...args...});
Cet enseignement sera effectif y compris si "teacher@..." se
trouve sur une autre plate-forme/machine que agent et sans qu'aucune
hypothèse ne soit nécessaire sur la présence du bytecode
de "skill" sur la machine hôte de agent. Il suffit
que l'agent "teacher@..." "possède" ce bytecode, celui-ci
sera transmis d'une plate-forme à l'autre si nécessaire.
| Soit n un entier naturel, f(n)= |
|
La compétence CollatzSkill nécessite un peu
plus d'explications. En effet, pour accomplir sa tâche elle doit
faire appel aux autres compétences. C'est ici qu'interviennent les
primitives
Magique d'invocation de compétences mentionnées
précédemment. Dans ce cas particulier puisqu'il s'agit de
calcul nécessitant que la réponse à une requête
soit connue avant de poursuivre, c'est la méthode askNow
qui doit être utilisée. Ainsi, pour invoquer la méthode
isEven
de la compétence
ParitySkill, sur l'Integerx il
faut écrire :
Boolean value = (Boolean) askNow("isEven",x);
On obtient pour la compétence CollatzSkill, le code
complet donné ci-dessous (NB : seules les méthodes publiques
sont accessibles et donc considérées comme "méthodes
de la compétences").
public class CollatzSkill extends MagiqueDefaultSkill {
private Boolean testParity(Integer x) {
private Integer xByTwo(Integer x) {
private Integer threeTimesPlus1(Integer x) {
public void conjecture(Integer x) {
private void conjecture() {
Le code source complet de la compétence
CollatzSkill.
Les méthodes conjecture permettent de tester la conjecture.
On peut noter aussi l'invocation de la compétence display, grâce à la primitive perform car ici il n'y a pas de réponse attendue. Il s'agit de déléguer à la compétence qui convient (par défaut DisplaySkill présente dans tout agent Magique gère cette invocation) la réalisation de l'affichage demandé. Il suffit donc d'adapter cette compétence pour obtenir l'affichage pour tout format ou type de support.
Voici donc pour les compétences impliquées. On voit que Magique n'apporte que peu de particularités en comparaison de classe et méthodes Java. La seule vraie différence et que pour certains appels, là où en objet on écrit :
objet.method(args...);
avec Magique on a :
perform("method",args...); // ou ask/askNow
La différence notable est que le destinataire n'a pas à être nommé (à la différence de la programmation objet). Un des intérêts évident est que la compétence pourra facilement être réutilisé dans différents contextes (cela est facilement imaginable pour les quatre premières compétences) et avec différents agents. On peut d'ailleurs remarquer que nous avons étudié les compétences sans même encore avoir discuté des agents qui seront impliqués dans le SMA. C'est ce que nous allons faire maintenant.
la structure hiérarchique choisie
Venons-en à la création de nos agents. Magique se base sur la notion de plate-forme, qui est en fait l'équivalent pour Magique de la JVM. Cette plate-forme prend en charge les problèmes liés à la distribution qui est ainsi masquée pour le développeur. A priori, on ne trouve qu'une plate-forme par machine même si cela n'est pas une obligation. Un agent est donc créé par une plate-forme et il faut ensuite faire son "éducation" en lui enseignant les compétences que l'on souhaite lui donner
Le code ci-dessous présente la création de l'agent possédant
la seule compétence ParitySkill. Cet agent doit se rattacher
dans la hiérarchie à son superviseur. C'est ce qui est fait
par l'appel à la méthode connectToBoss. Ici on suppose
que ce superviseur se trouve dans la même plate-forme (ce superviseur
n'a besoin d'aucune compétence particulière, il n'est là
que pour chapeauter les agents "mathématiques") et qu'il doit lui
même être connecté au superviseur global appelé
"super"
placé dans une autre plate-forme sur la machine
host1.lifl.fr.
Cette simple commande de connexion va suffire pour gérer les communications
distantes entre les agents. On note que cette requête est la même
que les agents soient distants ou pas. Il s'agit simplement de demander
la création d'une relation d'accointance hiérarchique.
public class ParityImp extends AbstractMagiqueMain {
// args[0] = super host name
Pour les autres agents il en va de même. Il faut juste savoir
quels agents évoluent sur la même machine et donc dans la
même plate-forme.
//args[0] = supermath hostName
public class AdderImp extends AbstractMagiqueMain{
public void theRealMain(String[] args) {
Agent adder = createAgent("adder");
adder.addSkill(new AdderSkill());
adder.connectToBoss("supermath@"+args[0]);
}
}
Le code source complet de création de l'agent
additionneur
Pour que le calcul se fasse, il faut invoquer la compétence
conjecture,
cela peut être fait par exemple après la création de
l'agent collatz (cf. code ci-dessous). Mais avec le mécanisme
de délégation, cette invocation aurait pu être fait
par n'importe quel autre agent.
public class CollatzImp {
// args[0] = super host name
Si en plus des programmes, ParityImp, CollatzImp
et AdderImp, on dispose des autres MultiplierImp,
DividerImp,
SuperImp
écrits sur le même principe (en supposant donc que tous ces
agents se trouvent sur des plates-formes - donc a priori machines - différentes),
on peut maintenant en exécutant ces programmes sur leur machine
respectives "exécuter" ce SMA.
java fr.lifl.magique.Start chap5.SuperImp}
java fr.lifl.magique.Start chap5.ParityImp superHost:port
java fr.lifl.magique.Start chap5.CollatzImp superHost:port
java fr.lifl.magique.Start chap5.AdderImp superMathHost:port
java fr.lifl.magique.Start chap5.MultiplierImp superMathHost:port
java fr.lifl.magique.Start chap5.DividerImp superMathHost:port
Une fois les agents déployés, l'environnement fournit
une interface déportée pour suivre le comportement de chaque
agent et une commande par shell permet d'interagir directement avec les
agents au cours de leur "vie", pour leur apprendre une nouvelle compétence
par exemple.
l'environnement de développement et de déploiement
La fenêtre de construction des agents à
gauche
et les fenêtres d'exécution et de shell
à droite
Grâce à l'échange dynamique offert par Magique, le déploiement se fait sans contrainte. Il suffit qu'un démon spécifique tourne sur les machines que l'on vise pour pouvoir y distribuer n'importe quel agent avec n'importe quelle compétence. Il n'est pas nécessaire de copier quelque code ou paquetage que ce soit avant cette distribution. La répartition des compétences se fera dynamiquement au déploiement, lors de la création des agents par enseignement de compétences grâce aux agents plate-forme.
L'API Magique a été utilisée pour développer cette environnement graphique, ainsi le déploiement des applications ou l'interaction avec les agents en cours d'exécution sont rendus possible par la présence d'agents invisibles pour l'utilisateur et qui interagissent avec l'environnement et les agents déployés par l'utilisateur.
Dans le cadre d'un article collectif du groupe ASA, un prototype pour une application de vente aux enchères a été réalisé avec Magique.
L'interface des agents. Le commissaire priseur (en haut
à gauche)
et les trois acheteurs appliquant chacun leur stratégie.
À nouveau, le développement d'une telle application est facilité par l'utilisation de la plate-forme Magique. L'identification des compétences liées aux rôles d'acheteur et vendeur est assez facile et les interactions impliquées peuvent donc être mises en oeuvre de manière générique. Il est ensuite possible de facilement adapter chaque agent en particularisant par exemple la stratégie d'achat qu'il utilise.
architecture des applications RAGE
Si l'aspect "agent intelligent", trop souvent systématiquement sous-entendu avec le terme agent, n'est pas présent dans les agents utilisés ici, ce genre de problème entre cependant clairement dans les applications de "coopération pour la résolution de problèmes distribués". En outre, nous sommes convaincus qu'une "approche agent" de la conception d'un tel système facilite grandement le travail du concepteur. C'est ce que nous illustrons ici.
Dans cette application, chacun des intervenants dispose d'un ensemble de ressources documentaires ("diapositives"). Dans une première version de cette application, ces ressources sont décrites par des documents html.
L'application doit permettre à l'utilisateur de diffuser ces documents auprès des autres. Il ne peut cependant le faire qu'à la seule condition qu'il soit détenteur de la télécommande (unique) associée à l'application. Cette télécommande lui permet de parcourir et de diffuser ses ressources. Mais elle tient également lieu de "pointeur" que le conférencier peut utiliser pour attirer l'attention des autres utilisateurs sur un point précis du document diffusé, ce pointeur étant visible par tous les utilisateurs en temps réel.
On distingue donc deux rôles dans cette application : celui de conférencier pour celui qui détient la télécommande, et celui d'auditeur pour les autres participants. Comme dans une conférence réelle, le conférencier peut à tout moment céder la télécommande à un auditeur. Les rôles respectifs tenus par les intervenants évoluent alors dynamiquement. Une attention particulière a été portée au respect de la conformité avec la tenue des conférences réelles.
Une présentation plus détaillée de l'application peut être obtenue ici.
Dans cette application, les rôles des intervenants peuvent être
amenés à évoluer. L'évolution dynamique des
rôles
conférencier -> auditeur est facilement prise
en compte par Magique. Puisque dans Magique, les agents apprennent
et oublient effectivement des compétences. Les échanges
de compétences sont réels, indépendamment de toute
hypothèse sur le code de ces compétences et de la distribution
sur le réseau des agents. L'agent conférencier pourra
donc, comme cela se passe lors du passage de micro dans une conférence
réelle, donner la compétence de gestion de la télécommande
au nouveau
conférencier et de ce fait la perdre. Et
il ne s'agit pas ici de la simple modification de la valeur d'un attribut
quelconque mais d'une mutation concrète de l'agent et du rôle
qu'il tient, et donc en quelque sorte de ses droits dans l'application.
Evolution dynamique de rôles par échange
de compétences
Cette application illustre concrètement un intérêt
de l'échange de compétences.