Compte-rendu de la réunion du groupe ASA

8 Mars 2002, Paris

Présents : Jnejla Amara (LIPN), ean-Paul Barthès (JPB), Carole Bernon (CB), Sylvie Cazalens (SC), Yves Demazeau (YD), Amal El Fallah Seghrouchni (AEF), Fabricco Enembreck (UTC), Pierre Glize (PG), Zahia Guessoum (ZG), Hosam Hanna (Grec, Caen), Gil Klein (LIPN), Chrsitian Lemaître (LANIA, Mexique), Laurent Magnin (LM), Philippe Mathieu (PM), Guillaime Mulko, Michel Occello (MO), Lilia Rejeb (LERI, Reims), Serge Stinckwich (CREYC, Caen), César Tacla (UTC), Erwan Tranvouez (ET)

Objet : Qu’appelle-t-on SMA adaptatif ? De quel(s) benchmark(s) a-t-on besoin ?

Rédacteurs du compte-rendu : CB et PG

Compte-rendu de la réunion du 05 octobre 2001 du groupe ASA (ZG)

Travail sur l’exemple de la vente aux enchères.

Présentation de méthodologies sans plate-forme ou de plates-formes sans méthodes. Permet de trouver les points communs entre les plates-formes.

Présentation d’Adelfe (SMAC/IRIT) qui s’intéresse aux systèmes multi-agents adaptatifs et qui considère que les enchères ne sont pas un problème adéquat en ce sens.

D’où le sujet de la prochaine réunion (celle d’aujourd’hui) qui doit répondre à la question : comment rendre ce problème adaptatif  ? à quel niveau ajouter de l’adaptation ?

Compte-rendu succinct de la réunion du groupe de travail MSEAS d’Agent Link II à Amsterdam en décembre 2001 (CB)

Voir les transparents dans les documents joints (disponible aussi sur http://www.irit.fr/SMAC rubrique Documents/Présentations).

Un besoin de benchmark pour comparer les différentes méthodologies orientées agent a été évoqué ainsi que la nécessité d’une ontologie commune. Des présentations ont été effectuées par les personnes suivantes : Paolo Marques, Gerd Wagner, Joris Hulstijn, Mark d’Inverno, Paolo Giorgini. Pour plus d’informations, consulter le site web de MSEAS (Methodologies and Software Engineering for Agent Systems) : http://polaris.ing.unimo.it/MSEAS.

Idée du déroulement de la réunion de ce jour : accord sur les diverses définitions d’un SMAA et choix d’un benchmark.

Mais, le besoin d’un benchmark serait un problème récurrent évoqué depuis le début d’Agent Link … (YD)

Á titre d’information, il est possible de s’inscrire à une liste de discussion ABSE (Agent-Based Software Engineering) maintenue par Franco Zambonelli. Toutes les informations utiles se trouvent à l’adresse http://groups.yahoo.com/groups/abse. La prochaine réunion informelle de ce groupe aura lieu à Bologne, en juillet 2002, en parallèle avec AAMAS. La prochaine réunion « sponsorisée » par Agent Link II se déroulera au début 2003.

Présentation « Une implémentation de l'exemple de la vente aux enchères en Corba » (SC et Philippe Lamarre) (voir les transparents dans le fichier pdf joint)

Résumé fourni par SC :

Corba est une norme proposée par l'OMG qui permet d'utiliser des objets distribués distants ou non. Il nous a paru intéressant d'étudier comment on pourrait implémenter en Corba le problème de la vente aux enchères choisi par le groupe ASA. Nous avons présenté une solution basique, que des étudiants de DESS ont pu mettre en œuvre lors de leur cours d'initiation à Corba (18h). Deux services Corba sont utilisés : le service de NOMMAGE et le service de NOTIFICATION. Le premier assure un service de pages blanches : la salle de vente s'y déclare tandis que les acheteurs vont le consulter pour trouver un nom et une adresse de salle de vente. Le service de notification permet à la salle de vente de créer un canal de diffusion qui est utilisé en mode push. Les événements générés par la salle de vente sont indiqués au service de notification sur le canal créé. Le broadcast aux acheteurs abonnés à ce canal est assuré par le service de notification (en mode push aussi). Pour pouvoir s'abonner au canal, un acheteur doit avoir contacté la salle de vente en demandant le catalogue, qui contient, outre la description des produits, l'adresse du service de notification utilisé et le numéro de canal.

La solution exposée ne prend pas en compte les problèmes de synchronisation. Ceux-ci peuvent être résolus en utilisant des services Corba supplémentaires (par exemple : "Time Service", normé : http://www.omg.org/technology/documents/corbaservices_spec_catalog.htm, ou un Scheduling service : http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/orbsvcs.html).

Discussion :

Le but de la présentation est de montrer comment le problème de la vente aux enchères peut être implanté en utilisant des objets. Ceci afin de permettre une comparaison avec un domaine non multi-agent.

Discussion sur le thème « A-t-on besoin des agents si on peut tout faire en objets » ? (PM), si tout est objet, comment différencier un agent ? Ici, la présentation veut juste s’attacher à montrer comment un concepteur « objet » peut implanter l’application demandée. On peut sans doute tout faire avec des objets mais plus ou moins facilement, ce que peut apporter la technologie agent c’est une simplification, le fait de permettre de développer plus facilement certains types d’application. Si on fait très bien les choses en objets, autant continuer.

L’implantation présentée ici a été réalisée dans la cadre d’un enseignement et ne comporte pas d’adaptation ou d’intelligence. On applique les enchères hollandaises, on établit un prix de départ puis on le baisse jusqu’à acquisition ou atteinte d’un prix plancher. Les gestions de propositions d’enchères sont traitées en FIFO sans considérer le problème des délais d’acheminement des messages, on ne fait pas respecter l’ordre d’émission des offres et cela peut être néfaste au déroulement de l’application (AEF). Besoin d’estampillage qui n’est pas géré par CORBA.

La conclusion est que la réalisation est très naturellement spécifiable en objets, que certains services de CORBA (tel le service de notification) ressemblent à des concepts agents (broker).

Discussion sur les « benchmarks »

La vente aux enchères fait penser à un problème de blackboard (PG). Que faut-il comme caractéristiques à une application pour être considérée comme benchmark ? D’après la présentation de Sylvie, il faut que cela débouche sur une implantation concrète. Il faut donc une spécification initiale suivie d’une implantation par différentes techniques dans un but de comparaison.

YD considère qu’un benchmark unique n’est pas chose possible, on ne peut tout comparer en une seule application. Il faudrait disposer de quatre benchmarks : un benchmark au niveau de l’analyse, un au niveau de la conception, un au niveau du développement (par exemple, l’application présentée par Sylvie) et un au niveau du déploiement (la RoboCup de Sony). Travaille dur une gestion d’agendas qui est un problème plus poussé que celui de l’emploi du temps.

AEF : il n’est pas facile de différencier les différentes phases.

LM : la vente aux enchères est un exemple trop simple, il faudrait un système plus complexe ou une vente aux enchères plus complexe dans le style de celle réalisée sur eBay ou un profil des acheteurs et des vendeurs est effectué (niveau de confiance).

Pour PG, la vente aux enchères est un système à agents mais non un système multi-agent car il n’y a pas d’activité collective cohérente. Quelle pourrait être la fonction collective réalisée ? vendre tout ?

Pour SC, un SMA correspond plutôt à la résolution de problèmes.

Pour PG, si on considère un système physiquement distribué, on pourrait, par exemple, observer que l’exécution peut être améliorée par le collectif mais ce ne serait toutefois pas une résolution de problème.

La fonction collective du système implique des agents coopératifs ou compétitifs (AEF), on n’a pas forcément une résolution de problème. Pour la vente aux enchères on pourrait atteindre un consensus sur une vente plus ou moins rapide, l’aspect est centralisé.

Si on a plusieurs vendeurs et/ou plusieurs acheteurs, il peut y avoir formation de coalitions (ZG), l’exemple proposé est sans doute trop simplifié.

Il n’y a pas forcément coopération, quelle est la fonction de satisfaction (PG).

A l’origine, le terme de « benchmark » n’était pas employé, mais le problème était qualifié de « toy-problem » (PM) dans le but de comparer les différentes plates-formes existantes et de fédérer la communauté autour de problèmes communs. S’il y a eu évolution vers un benchmark, un benchmark de quoi ?

Il faudrait trouver un problème spécifique aux SMA ou un problème pour lequel la résolution serait mieux que ce qui existe déjà (AEF).

On a donc deux sortes de problèmes : définir un benchmark dans le but d’une comparaison interne à la communauté et trouver des domaines d’application pour trouver ce qui est spécifique aux SMA ou ce qui est mieux que mes autres (ZG).

Quel est l’objectif à atteindre ?

Au début du groupe, on voulait comparer des approches et des plates-formes (MO). Si on fait une comparaison avec l’extérieur, comment se positionner par rapport aux autres approches ? Trouver dans quels cas utiliser les SMA, comment se démarquer…

On a besoin de plusieurs benchmarks qui peuvent servir aux deux comparaisons (PG). Il faut aussi se confronter aux autres.

Peut-on concevoir une application en faisant autre chose que des objets ? (PM), tout est-il objet ?

Présentation du problème de « l’emploi du temps » (CB)

Voir document joint.

Il serait nécessaire de spécifier l’interface de représentation afin de normaliser et de tous travailler sur la même base (JPB).

Il faudrait spécifier des contraintes pour empêcher de n’utiliser qu’un agent (PM). Par exemple, interdire de centraliser l’information. Comment juger si toutes les contraintes sont vérifiées ?

Il faudrait trouver ce qu’apportent les différentes variantes, quelles sont leurs différences, que cherche-t-on à montrer/tester ? (YD)

Aucune version ne fait référence au fait que le système peut être ouvert : on pourrait, bien entendu, ajouter des acteurs (au sens UML) en temps réel.

Chaque acteur pourrait spécifier ses préférences sur les contraintes sans que les autres agents le sachent (AEF). La stratégie de changement des contraintes est-elle connue des autres de manière à changer son propre comportement en conséquence ?

La croyance est possible, la capacité de perception d’un agent est intrinsèquement limitée, on va lui interdire de connaître plus de X contraintes par exemple (capacité d’oubli) (PG). Tout agent a une perception limitée de son environnement.

Qui utilise le système ? les acteurs physiques ? des agents-assistants les représentant dans le système ? (ZG)

Un acteur est-il représenté dans le système par un agent ? (PM)

Cela dépend de la méthode employée, chacun est libre de faire ce qu’il veut. On considère qu’un « acteur réel » est capable de modifier/consulter ses contraintes, un enseignant va modifier ses contraintes, par exemple. De même pour un groupe d’étudiants, peut être pas pour une salle… (PG)

Comment est effectué le changement de contraintes ? elle est simulée via une interface ?

On pourrait donc dire des différentes versions proposées que chacune d’entre elles permet de tester une caractéristique particulière, un aspect particulier (YD) :

· Version 1 : résolution de problème sans relâchement de contraintes ;

· Version 2 : résolution de problème avec relâchement de contraintes ;

· Version 3 : adaptabilité à un environnement dynamique ;

· Version 4 : adaptabilité à un système ouvert.

Présentation « INformations et COnnaissances Distribuées » (ET)

Présentation d’un formalisme de représentation des comportements d’agents (RCA). Formalisme semi-formel graphique.

Un modèle d’agent générique est proposé (communication – couche syntaxique et sémantique –, décision – gestionnaire de plan comportemental –, connaissances – sociales (accointances) et individuelles (compétences, croyances métier) –, expertise – sociale et individuelle) .

Ce travail constitue un outil de partage entre les concepteurs. Pour l’instant, il est semi-formel et il n’y a pas encore de validation mais il est plus simple à représenter que les réseaux de Pétri (colorés).

Discussion sur les SMA et les SMA adaptatifs

Basée sur les définitions de l’équipe SMAC/IRIT (cf. transparents joints)

Est-ce que SMA adaptatif signifie « SMA coopératif » ? Quelle est la différence avec un système rationnel ?

Il n’y a pas de connaissance complète de la fonction globale pour les parties en interaction (PG).

Ne serait-il pas plus juste d’utiliser le terme de « proactivité » au lieu de « distribution du contrôle » ? (AEF)

Quelle est la différence entre cette définition est celle de SMA ? (ZG)

Quelle est la propriété faisant qu’un SMA est adaptatif ?

Serait-ce qu’il est capable de s’adapter à son environnement (LM).

Le concept de « SMA adaptatif » n’est pas intéressant mais celui de « SMA ouvert », oui (YD). C’est un système dans lequel les agents peuvent évoluer, de même que les interactions, … il s’agit donc de maintenir l’intégrité fonctionnelle i.e. qu’un cours d’exécution, le système se réorganise de manière à garantir la fonction du système. Mais, cela n’empêche pas d’utiliser le terme « adaptatif » pour ceux qui le veulent.

Un système adaptatif serait un système ouvert particulier, relation d’inclusion (LM).

Pour PG, l’ouverture signifie ajout de composants et cela est différent de l’adaptativité. Par exemple, si on considère un problème du voyageur de commerce dans lequel les contraintes changent, on sera peut être capable de trouver une solution mais pas forcément la meilleure. La solution c’est l’adaptation.

Les systèmes situés existent (YD).

On s’en fiche, si on a un système qui résout un problème, c’est déjà pas mal et s’il est adaptatif c’est encore mieux (JPB). Le problème c’est comment spécifier la fonctionnalité (dépend de la fonction du système).

Il y a adaptation à plusieurs niveaux (ZG). Un SMA c’est un ensemble d’agents. On a des agents réactifs et cognitifs, on parle plutôt d’agent réactif adaptatif si on ne connaît pas toutes les variations de l’environnement.

Quel est le rôle d’un benchmark ?

Pour l’emploi du temps, il concernerait les phases d’analyse et de conception.

Il est utopique de pouvoir penser qu’un benchmark puisse couvrir tous les types de systèmes (YD).

Rappels

Un article existe sur la vente aux enchères, le demander par mail à PM (mathieu@lifl.fr).

La liste des toy-problems est disponible sur le site web du groupe ASA (http://www-poleia.lip6.fr/~guessoum/asa.htm) mais les critères d’interaction qui avaient été définis dans des réunions précédentes n’y figurent pas.

Les JFSMA auront lieu du 28 au 30 octobre 2002 à Lille (http://www.lifl.fr/jfiadsma2002).

La prochaine réunion…

Á Paris, le 24 mai 2002.

Á Lille, les 30 et 31 octobre 2002, en conjonction avec les JFSMA sur deux demi-journées pour libérer le 31 après-midi.

Il serait souhaitable de se situer par rapport aux axes définis dans les SMA, en complétant un schéma de ce type :

Éventuellement proposer un benchmark adapté aux problèmes abordés par chacun.

Travail à réaliser :

· Étude de la variante 1 de l’emploi du temps, en ajoutant éventuellement des contraintes sur les salles ;

· Présentation de 20 mn sur ce travail :

– 10 mn pour la conception,

– 10 mn pour la réalisation,

– Une éventuelle démonstration.

– Informations à faire parvenir à JPB : barthes@utc.fr

· Améliorer l’énoncé et le rediffuser (voir le nouvel énoncé en document joint) ;

· Spécifier les interfaces et diffuser le code Java correspondant s’il existe.