De la plate-forme comme système multi-agent

Revenons un instant sur notre schéma d’architecture initial. Nous avons présenté l’archi- tecture unifiée qui sert de base à la plate-forme, avec le noyau agentifié pour permettre l’ex- tension des opérations primitives, des agents d’observation et de contrôle de la plate-forme, des mécanismes de communication distribués agentifiés, un environnement graphique lui- même conçu en terme d’agents coopératnts.

Pour conclure sur cette partie examinant les mécanismes réflexifs de MADKIT, on note que finalement, cette plate-forme d’exécution de systèmes multi-agents peut se voir elle- même comme un système multi-agent ayant pour but de fournir le plus de facilités à d’autres systèmes en construction. Si nous reprenons la représentation graphique que nous avons utilisé aux chapitres précédents, nous pourrions la représenter telle que sur la figure6.15.

ance Surveilla Groupe de communications Groupe système Launcher G-Box Communicator GroupSync M i Monitor KernelAgent subscriber

subscriber subscriber subscriber subscriber

Monitor M it M it Monitor

Groupe IHM

FIG. 6.15 – La plate-forme comme système multi-agent

6.6

Conclusion

Comme on a pu l’observer, ce chapitre a parfois dépassé le cadre du strict modèle “agent- groupe-rôle” qui était le cœur de notre discours jusqu’ici. Nous sommes néanmoins resté

sur le même thème : que faut-il pour implémenter des systèmes multi-agents ouverts et hétérogènes ?

MADKITest notre contribution sur ce thème, et nous avons voulu montrer l’intérêt d’une structuration organisationnelle des applications multi-agents et comment cela peut être uti- lisé pour fédérer des modèles distincts et structurer le fonctionnement même de la plate- forme. Le trait distinctif de cet outil par rapport à d’autres plate-formes est d’être voulu dès le départ comme l’étude d’un middleware multi-agent, avec ses mécanismes d’extensions, son adaptabilité et sa neutralité vis à vis des architectures internes. Nous verrons plus avant au chapitre8quelques applications développées sur cette base et justifiant ce souci de généri- cité.

Pour finir, remarquons que nous n’avons jamais vraiment envisagé que la validation de cette approche implantoire ne pouvait venir simplement de l’architecture ou la réalisation de cette plate-forme en soi. Le critère essentiel pour juger de l’intérêt du modèle Agent-Groupe- Rôle du point de vue de la mise en œuvre était avant tout la diversité applicative et architecturale des systèmes multi-agents déployés sur cet outil.

FIG. 6.16 – Base communautaire d’agents et d’applications

Cela imposait de ne pas juger que par nos propres expérimentations et nous a rapidement conduits à ouvrir l’usage de cette plate-forme le plus possible (que ce soit par le mode de

distribution, la facilité de partage de “packs” d’agents ou même le souci de qualité et la facilité de prise en main de l’outil). Nous étions d’abord notre propre cobaye : la réintégration du paradigme agent dans le fonctionnement même de la plate-forme a permis de très vite valider les choix techniques7_.

Un travail annexe au développement proprement dit a donc consisté à favoriser l’utilisa- tion de l’outil et le partage d’agents ou de modèles entre utilisateurs [Gasser, 2000]. L’effort le plus tangible de construction d’une telle communauté a été la réalisation d’une base de données en ligne où tout concepteur peut décrire son application, voire publier et partager des modèles ou des instances d’agents (figure6.16). La validité de cet échange de modèles vient des propriétés de cloture de la structuration organisationnelle et de leur mise en oeuvre au plus bas niveau de la plate-forme : il n’a pas de risque de conflits directs et la cohabitation de plusieurs “systèmes” est alors possible.

7_{Et montrer qu’au moins le concepteur jugeait l’outil utilisable, ce qui n’est pas toujours un critère vérifié.}

Approche méthodologique

Revenons à une remarque qui a amorcé notre réflexion au tout début de ce document, quand nous imaginions que les systèmes multi-agents puissent faire partie à terme du cata- logue des techniques de construction logicielle classique. Une des contraintes qu’il faudrait assumer pour cela est de penser l’intégration des modèles et techniques agents dans l’op- tique générale du génie logiciel classique, notamment l’articulation avec les méthodologies de conception et de gestion des cycles de développement.

Cela se confirme d’ailleurs par l’intérêt récent des industriels mettant en place des projets autour de ce type de techniques, et qui insistent sur les aspects de validation et réutilisabilité des systèmes ainsi contruits [Parunak, 1998] [Baumgärtel et al., 1996].

Il faut bien admettre que malgré quelques travaux initiaux, comme [Kendall et al., 1995] ou [Burmeister et Sundermeyer, 1990], souvent élaborés à partir d’analyses a posteriori, l’im- portance accordée à la réflexion sur les méthodologies de conception dans les agents est un mouvement récent. Dans [Treur, 1998], Jan Treur identifie cinq domaines d’action dans le cadre des méthodes de conception de systèmes à agents, du domaine à l’outil :

– Etude des techniques de conception, par l’élaboration de méthodes et modèles pour obtenir une description complète d’un système à agent. Cela concerne par exemple l’élaboration ou l’adaptation de langages de modélisation ou de spécification.

– Définition et analyse de propriétés. En particulier par les méthodes et techniques per- mettant de spécifier les propriétés requises d’un système et l’interdépendance entre ces propriétés, par exemple via des outils d’analyse formelle et de vérification.

– Guides, méthodes et techniques d’implémentation, pour des prototypes ou des sys- tèmes opérationnels, ainsi que l’émergence d’outils et plate-formes généraux.

– Outils d’aide à la conception : implémentation d’outils de vérification, d’aide au de- sign, de prototypage rapide, de validation.

– Réutilisabilité : définition de méthodes et techniques pour spécifier et maintenir des modèles et modules réutilisables, et ce à plusieurs niveaux : pour les modèles d’orga- nisations, pour les agents individuels et pour les composants internes.

Il y a en particulier un consensus général sur le fait que les modèles et guides du pro- cessus méthodologiques classiques (KADS, conception par objets) ne sont pas applicables directement aux approches multi-agents, et qu’une réflexion méthodologique sur les modèles agents s’impose.

Nous ne pourrons donc pas échapper à cette préoccupation : avancer la généricité d’une approche organisationnelle, comme nous l’avons fait jusqu’ici se doit d’aller de pair avec l’examen des conséquences de ce modèle d’un point de vue d’analyse ou de conception, et c’est l’objet de ce chapitre. Prévenons tout de suite que notre objectif n’est pas de proposer une méthodologie complète : cela serait par trop audacieux, et de toutes façons notre mo- dèle ne nous le permettrait pas. En effet, nous avons insisté sur le fait que le cadre “Agent - Groupe - Rôle” était volontairement partiel, et ne cherchait pas à entrer dans une architec- ture spécifique d’agent ou un modèle de communication. Une méthodologie complète serait donc vouée à l’échec. Par contre, il nous paraît plus intéressant d’examiner - toujours par cet axe organisationnel - comment l’abstraction des structures que nous manipulons pour- rait faciliter le travail de conception, et voir comment articuler notre approche avec d’autres plus spécialisés. Il s’agit là de proposer un cadre méthodologique organisationnel, apte à compléter d’autres méthodes et modèles.

7.1

Méthodologie multi-agents

Il s’agit avant tout de tirer parti des modèles, méthodes et outils déjà proposés pour faciliter la construction de systèmes multi-agents.

Le rôle d’une méthodologie est de passer d’un cahier des charges à une implémentation, et de pouvoir gérer le cycle de vie global d’une application. Tout ceci couvre des besoins comme la spécification initiale, l’architecture, un cadre d’implémentation, mais encore l’ex- pression des modèles utilisés dans un but de maintenance ou de réutilisation.

Reprenons les points énumérés par [Drogoul, 2000] qui caractérisent selon lui une mé- thodologie :

– La définition des étapes du projet, des guides de conception pour chacune, et les suc- cessions possibles entre elles

– Un langage commun de description ou de modélisation pour faciliter l’expression du problème et la réutilisation éventuelle

– Le choix d’un niveau de description adéquat et les conséquences opérationnelles qui en découlent

– Un ensemble structuré de directives, qui inclut la définition des étapes mentionnées plus haut, des conseils de conception pour chacune des étapes, et des règles de transi- tion entre ces étapes.

utilisée pour partager et transmettre l’expérience acquise durant ce processus, soit entre les concepteurs, soit à destination d’autres concepteurs.

– L’utilisation d’une terminologie homogène, qui possède une signification à chaque étape et qui facilite les transitions entre étapes (souvent une terminologie graphique à base de diagrammes ou d’organigrammes).

– L’utilisation d’abstractions conceptuelles opérationnelles, c’est-à-dire de structures suf- fisamment abstraites pour permettre un choix suffisant de techniques au moment de l’implémentation, mais assez concrètes pour éviter au concepteur d’utiliser des tech- niques dépassées ou non pertinentes.