U NE PLATE - FORME DE CONCEPTION MULTI

P OSITIONNEMENT DE LA DEMARCHE

N OTRE DEMARCHE

IV.2. U NE PLATE - FORME DE CONCEPTION MULTI - AGENT

Nous avons jusqu’à présent abordé la question d’un point de vue très général, point de vue qui s’est traduit par la conception d’un outil lui-même très général, véritable plate-forme de création de systèmes multi-agents, en liaison d’une part avec des ensembles quelconques de données, et d’autre part avec un ou plusieurs utilisateurs.

La figure IV.9 présentait une vision « conceptuelle » de l’interface entre un système complexe et un utilisateur. Nous allons maintenant nous attacher à en donner une vision « pratique ». Pour comprendre la manière dont s’est opéré ce passage de la théorie à la pratique, nous commencerons par rappeler le contexte dans lequel il a eu lieu, ce qui nous permettra, dans un premier temps, de mettre en évidence les principaux choix de conception, et dans un deuxième temps, de montrer l’articulation de ces choix au sein d’une solution générale et cohérente.

IV.2.1. CONTEXTE DE DEVELOPPEMENT

Initialement, la plate-forme a été développée pour servir de support au projet artistique Le Jardin des Hasards, qui constitue un jardin virtuel évoluant de manière continue sous les effets de la météorologie réelle d’un lieu particulier et avec lequel il est possible d’interagir (supra I.1.3). Travaillant en collaboration étroite avec un artiste, il était important de lui permettre d’expérimenter librement différents processus de génération des images. Il fallait donc concevoir un outil de création de tels jardins et non un jardin particulier, ce qui nous a conduit à développer une plate-forme de conception de systèmes multi-agents plutôt qu’un système multi-agent spécifique. De manière plus précise, cela signifie que nous nous sommes efforcés de faire un minimum d’hypothèses concernant la nature d’un agent ou de son environnement, laissant le soin à l’utilisateur de choisir les agents qu’il souhaite voir évoluer et de définir leur comportement, par l’intermédiaire d’un langage de script adjoint à la plate-forme. En cela, la démarche est proche de celle de l’environnement StarLogo [Resnick 1991b], dans lequel un langage de programmation très simple permet d’expérimenter les mécanismes à l’origine de phénomènes collectifs, en décrivant le comportement d’un individu et en dupliquant ce comportement sur un nombre arbitrairement grand d’individus.

Puisqu’il s’agissait de reproduire l’évolution d’un jardin, le modèle d’agent choisi est particulièrement simple, concernant aussi bien les capacités de représentation des agents que leurs capacités de communication, adoptant en cela une conception plus

« réactive^● » que « cognitive^● » [Drogoul 1993]. Nous verrons par la suite qu’il est pourtant possible, sur la base de ces capacités minimales, de concevoir des comportements très complexes grâce au langage de script.

Par ailleurs, ce jardin est conçu comme une interface entre un système météorologique et un utilisateur humain. C’est donc un système ouvert qui doit pouvoir échanger de l’information avec le monde qui l’entoure, et notamment avec d’éventuels utilisateurs humains. De ce point de vue, système météorologique et utilisateur humain ne sont pas si différents qu’on pourrait le croire. Le premier influence le jardin par l’intermédiaire des données numériques qui le caractérisent, température ou précipitations par exemple. Le second interagit grâce à des périphériques d’interface, clavier ou souris, qui eux-mêmes transmettent au jardin des données traduisant son activité. Dans un cas comme dans l’autre, le jardin reçoit des données d’un système qui lui est extérieur et chaque agent du jardin peut y réagir d’une manière qui lui est propre.

Enfin, jouer le rôle d’interface signifie également transmettre de l’information, en plus d’en recevoir. Le Jardin des Hasards est destiné à restituer, pour le spectateur, l’ambiance climatique d’un lieu particulier. L’image que le système multi-agent, et avec lui chaque agent, donne de lui-même, est fondamentale dans ce contexte. Une attention particulière a donc été apportée aux capacités de « concrétisation » des agents, c’est-à-dire les moyens dont ils disposent pour manifester leur présence de manière sensible, soit en s’affichant sous forme visuelle, soit en émettant des sons.

IV.2.2. ARCHITECTURE GENERALE

Ces différentes contraintes ont abouti à l’élaboration d’une architecture permettant la mise en œuvre flexible de systèmes multi-agents ouverts, en interaction avec un ou plusieurs autres systèmes, utilisateurs humains compris. La figure IV.10 en montre l’organisation globale. Elle met en évidence la distinction entre deux types d’agents : d’une part des agents que l’on pourrait qualifier d’agents d’information, dont le rôle est de récupérer des données en provenance d’un système complexe, l’utilisateur étant lui-même considéré comme un système complexe dont il s’agit de surveiller les actions ; d’autre part des agents constituant ensemble ce qui, dans l’exemple du Jardin des Hasards, s’apparente à un jardin virtuel, mais qui peut prendre potentiellement n’importe quelle forme. Le rôle de ces derniers agents, que l’on qualifiera d’agents de simulation, est de filtrer et de réorganiser le flux de données transmis par les agents

d’information afin d’en construire, à destination de l’utilisateur, une représentation visuelle et/ou sonore.

Agents d’information et de simulation peuvent communiquer par l’intermédiaire d’une structure de données commune sur laquelle les premiers peuvent écrire des informations que les seconds peuvent lire, comme dans le cas des tableaux noirs [Engelmore et Morgan 1988]. Chaque agent d’information peut y déposer des données dans un tableau qui lui a été réservé (infra IV.2.4). Tous les agents, quels qu’ils soient, ont accès à ces données mais ce sont les agents de simulation qui ont vocation à les lire et les traiter. Ces derniers évoluent dans un environnement simulé. Construits sur le modèle d’organismes végétaux ou animaux, ils disposent de ressources propres, peuvent émettre des signaux dans leur environnement, et sont capables d’effectuer des actions ou de prendre des décisions en réponse à ce qu’ils perçoivent (infra IV.2.5). Finalement, ces agents ont accès à leur propre représentation graphique et peuvent la modifier de manière à informer l’utilisateur de leur identité, d’éventuelles modifications de leur état interne, des actions qu’ils sont en train d’effectuer, etc. Les agents de simulation concourent ainsi à la composition d’images avec lesquelles l’utilisateur peut interagir. Grâce à deux agents dédiés à la gestion du clavier et de la souris, les agents de simulation sont renseignés sur l’activité de l’utilisateur et peuvent donc y réagir. Suivant la manière dont les agents de simulation ont été conçus, l’utilisateur peut déplacer des agents, modifier leurs ressources, inhiber certains de leurs comportements ou encore en activer d'autres.

figure IV.10 – Architecture générale de la plate-forme de conception de

IV.2.3. UNE BASE COMMUNE

La plate-forme que nous avons développée et utilisée peut donc être considérée à la fois comme un système d’information, un système de simulation multi-agent et un système d’interface. Ces trois fonctions ne correspondent pas, en pratique, à une séparation aussi nette, puisque toutes trois sont prises en charge par des agents qui possèdent les mêmes capacités de base. Nous allons maintenant décrire cette structure commune. Sans rentrer dans tous les détails de la conception de la plate-forme, cette partie sera nécessairement plus technique. N’étant pas indispensable à la compréhension de la suite, elle peut être laissée de côté par les lecteurs que cet aspect technique pourrait rebuter.

IV.2.3.1. Principe général

La caractéristique la plus importante pour comprendre ce qui suit réside dans la

« philosophie » qui a présidé à la conception de la plate-forme. En particulier, nous avons souligné l’importance accordée à la conception d’un outil de création ouvert plutôt que d’un système dédié, sans possibilités d’évolution. Ceci s’est traduit par une conception objet¹⁹ dans laquelle un agent correspond à une classe très simple, comprenant seulement quelques structures de données génériques et vides, et des méthodes pour les manipuler. Pour créer un système multi-agent particulier, l’utilisateur doit compléter la classe d’agent en précisant les « connaissances » d’un agent et les comportements lui permettant de les manipuler, d’agir dans son environnement ou encore d’interagir avec d’autres agents.

La deuxième contrainte était que ce processus de création d’un système multi-agent particulier soit accessible à des non-informaticiens. Dans un premier temps, cette contrainte s’est exprimée par un paramétrage de certaines des caractéristiques d’un agent, paramétrage accessible par l’intermédiaire d’un fichier de configuration. Dans un deuxième temps, en raison du nombre de caractéristiques qui devenaient exprimables par ce fichier de configuration, le paramétrage initial s’est progressivement transformé en un véritable langage de programmation. A la manière de StarLogo

19 Pour des raisons d’efficacité, liées notamment à la génération d’animations dont il était important, dans un contexte artistique, qu’elles soient aussi fluides que possible, le langage choisi pour l’implémentation de la plate-forme est le C++ [Schildt 1998]. Pour conserver par ailleurs un bonne portabilité à travers différentes machines, la plate-forme a été développée sous Linux.

[Resnick 1991b], ce langage offre la possibilité d’expérimenter rapidement des mécanismes collectifs basés sur les interactions d’agents aux comportements très simples, et il permet également la définition de comportements plus compliqués (se reporter à l’annexe A pour une description de la syntaxe du langage).

Le processus permettant de passer du fichier de configuration, écrit avec le langage de script, au système multi-agent opère en deux grandes étapes (voir figure IV.11). La première d’entre elles consiste à interpréter²⁰ le fichier de manière à en extraire la définition d’un certain nombre de familles d’agents, définition concernant aussi bien les ressources des agents de chaque famille que leurs comportements. A l’issue de cette étape, chaque famille est représentée par un agent de définition qui constitue le modèle selon lequel seront construits tous les agents de la famille²¹. La deuxième étape consiste à instancier ces agents de définition en autant d’agents que nécessaire et à confier ces agents à l’ordonnanceur, chargé de gérer leur exécution ultérieure.

IV.2.3.2. L’ordonnanceur

Les agents n’étant pas, d’un point de vue informatique, des processus autonomes, ils dépendent, pour leur exécution et leur activation, d’un ordonnanceur dont le rôle est double : d’une part tenir à jour la liste des agents ; d’autre part organiser la bonne d’agents dérivées de la classe d’agent de base. En pratique, l’utilisation d’agents particuliers plutôt que de classes est liée aux limitations du langage C++ qui ne permet pas la définition dynamique de nouvelles classes, contrairement par exemple au langage Smalltalk [Goldberg et Robson 1989].

figure IV.11 – Processus d’interprétation et d’instanciation conduisant d’un fichier de configuration contenant la description d’un système multi-agent au système lui-même.

alternance et la synchronisation des activations des différents agents. La gestion de la liste des agents est nécessaire du fait de la possibilité dynamique d’ajouter ou de supprimer des agents. Chaque agent est en effet susceptible de se dupliquer et ainsi donner naissance à un nouvel agent de même type, ou au contraire d’interrompre son exécution. La deuxième fonction de l’ordonnanceur est de gérer l’activation des agents.

Le principe de base consiste à parcourir la liste des agents et d’activer ceux qui doivent l’être, en fonction de leur période d’activation. Si l’on définit un cycle de simulation comme un parcours entier de la liste des agents, la période d’activation correspond au nombre de cycles entre deux activations successives.

IV.2.3.3. La structure de base d’un agent

Afin de permettre une gestion homogène des agents de la part de l’ordonnanceur, tous les agents héritent d’une classe commune agent. Celle-ci met en place les mécanismes de gestion des agents, par la définition d’attributs (numéro d’identification, période d’activation, âge) et de méthodes (initialisation, activation, terminaison, et également reproduction ou mort) très généraux. Un agent est par ailleurs défini par les ressources qu’il possède et les comportements qu’il peut exécuter.

S’agissant des ressources, le terme doit être entendu dans une acception large, c’est-à-dire qu’il peut s’agir aussi bien de variables décrivant l’état interne de l’agent (la quantité d’eau, de matières minérales, d’énergie, etc. dans le cas de simulations écologiques), que de variables utilisées pour construire une certaine forme de représentation du monde pour les agents (des informations concernant l’environnement ou les autres agents par exemple). Au niveau de la plate-forme, la distinction n’est pas faite entre ces différents types de ressources, mais plutôt entre les

figure IV.12 – Hiérarchie des classes d’agents utilisées dans la plate-forme.

agent

data_agent local_agent

visual_agent keyboard_agent

mouse_agent

différents types de variables (valeur numérique, textuelle, ou vecteur à deux dimensions), utilisables par l’agent, seules ou regroupées en tableaux.

Lorsqu’un agent est nouvellement créé, que l’ordonnanceur lui demande de s’activer, ou avant d’être supprimé, l’agent peut avoir un comportement autonome par lequel il peut exécuter des actions en réponse à ce qu’il perçoit de son environnement.

Dans le même temps, il peut mettre à jour ses ressources et ses représentations afin de prendre en compte les modifications de cet environnement. Ces différents comportements sont programmés grâce au langage de script de la plate-forme, avant d’être traduits de manière interne au moment de l’interprétation du fichier de configuration. A titre d’exemple, la figure IV.13 reproduit la définition d’une famille d’agents telle qu’elle pourrait apparaître dans un fichier de configuration (se reporter à l’annexe A pour la description précise de la syntaxe du langage de script). Lorsqu’il est interprété, cet exemple génère un agent de définition pour la famille toto, instancié ensuite à deux exemplaires. Au cours de son exécution, chaque agent initialise à 0 une variable locale appelée compteur, compte jusqu’à 10 puis termine son exécution en affichant à l’écran un message et son numéro d’identification.

22 le caractère # désigne le début d’une ligne de commentaires, les termes en gras sont des instructions ou des mots réservés du langage.

# déclaration de la famille « toto », de type agent, contenant 2 membres family toto agent 2

end_family

# comportement à exécuter lors de la création de l’agent init toto

# initialisation d’une variable « compteur » à 0 set compteur 0

end_init

# comportement courant, exécuté à intervalle régulier activate toto

# si la variable « compteur » est inférieure à 10, incrémenter la variable if {$compteur < 10}

# comportement exécuté lors de la suppression de l’agent end toto

# affiche un message à l’écran indiquant le numéro d’identité de l’agent puts {’fin de l\’agent toto ’ + $id}

end_end

figure IV.13 – Exemple de programmation d’un agent dans le langage de script de la plate-forme²².

IV.2.3.4. La programmation des comportements

Le paragraphe précédent montrait un exemple de programmation élémentaire du comportement d’un agent dans le langage de script de la plate-forme. L’intérêt principal de ce langage est qu’il permet de programmer simplement et de manière homogène les comportements des différents agents de la plate-forme, depuis les agents d’information (infra IV.2.4) jusqu’aux agents de simulation et d’environnement (infra IV.2.5). De la sorte, il est très facile d’expérimenter rapidement différents modèles de comportement pour ces agents, et de visualiser les résultats obtenus en terme de dynamique organisationnelle.

Nous n’indiquerons ici que les caractéristiques essentielles de ce langage, l’annexe A en proposant la présentation détaillée. Le langage permet d’une part de paramétrer l’agent et de déclarer les variables qu’il peut manipuler, d’autre part de programmer ses comportements d’initialisation (init ... end_init), d’activation (activate ... end_activate) et de terminaison (end ... end_end). L’écriture de ces comportements se base sur l’utilisation de variables et de primitives, combinées grâce à des structures de contrôle, selon des principes classiques de programmation impérative.

Les variables sont d’une part ce que nous avons désigné au paragraphe IV.2.3.3 comme les ressources de l’agent, d’autre part des variables désignant des signaux émis par d’autres agents, ou décrivant l’état de l’environnement (infra IV.2.5). En outre, chaque classe d’agent de la plate-forme possède des attributs incorporés au langage de script sous la forme de variables réservées (par exemple, le numéro d’identification d’un agent est accessible par l’intermédiaire de la variable id). Les agents peuvent consulter la valeur de ces différentes variables, ou les modifier par l’opération d’affectation (set). Outre qu’elle permet de décrire finement la gestion des ressources et des représentations des agents, l’utilisation de ces variables permet également à des agents localisés dans l’environnement de modifier leur position ou leur vitesse (infra IV.2.5 et annexe A), à des agents colorés de modifier leur couleur (infra IV.2.6.1 et annexe A), etc. De manière plus générale, on peut considérer l’aspect visuel d’un agent comme une ressource. Au même titre que n’importe quelle autre ressource, il sera donc possible, pour un agent, de la manipuler et de la modifier.

Par ailleurs, la manipulation de ces variables permet de mettre en place une communication élémentaire entre les agents, qui peut prendre au moins trois formes différentes :

• en utilisant l’environnement comme une sorte de tableau noir [Engelmore et Morgan 1988], les agents peuvent échanger de l’information, de manière locale ou globale ;

• les agents localisés dans l’environnement peuvent propager des signaux autour d’eux, que les autres agents peuvent percevoir (infra IV.2.5) ;

• un agent peut modifier à distance les variables d’un autre agent (dset), ce qui permet d’envisager une sorte d’envoi de messages entre agents.

Outre la manipulation des variables, un ensemble de primitives de base est disponible, permettant notamment à un agent de se reproduire ou de mourir (reproduce et die). L’ajout, à ces primitives, de structures de contrôle permet d’accéder à une véritable programmation des comportements des agents, notamment en organisant les instructions élémentaires en blocs d’instructions, et en soumettant leur exécution à certaines conditions. De ce point de vue, les structures de contrôle utilisées fonctionnent d’une manière très similaire à celles que l’on trouve dans la majorité des langages de programmation impératifs. On peut ainsi utiliser des structures du type si ... alors ... sinon (if ... else ... fi), ou tant_que ... faire (while ... end_while). Une instruction à branchement multiple (switch) est par ailleurs définie, qui s’apparente à une suite de si ... alors ... sinon imbriqués, et qui permet de programmer rapidement une architecture de décision pour un agent, proche de l’architecture de subsomption décrite par R. Brooks [Brooks 1999].

Nous allons maintenant nous intéresser à l’utilisation de cette plate-forme en tant que système d’information, système de simulation multi-agent, et enfin système d’interface. Nous illustrerons la description par un exemple, lié à la représentation d’un flux d’informations au format MIDI, codant une pièce musicale interprétée par un ensemble d’instruments. Cet exemple, simple dans sa mise en œuvre, fait en effet appel à chacune des trois fonctions de la plate-forme.

IV.2.4. UN SYSTEME D’INFORMATION

La première de ces fonctions est de récupérer des données provenant du fonctionnement d’un système complexe, grâce à des agents d’information, et à intégrer

ces données au niveau de la plate-forme elle-même, de manière à ce qu’elles puissent être utilisées par les agents de simulation.

En premier lieu, il faut remarquer qu’un agent d’information est un agent d’interface, puisqu’il doit communiquer à la fois avec la plate-forme de simulation multi-agent et avec un système complexe particulier. Il est donc nécessaire d’assurer la possibilité à ces agents d’information de transmettre les données qu’ils collectent à destination des agents qui seront chargés de les traiter. Pour ce faire, l’idée est d’utiliser une structure de données partagée dans laquelle les premiers peuvent écrire des informations que les seconds peuvent venir lire (figure IV.14). De ce point de vue, cette structure de données reprend les principes de communication distribuée introduits par le langage

Dans le document Du Jardin des Hasards aux Jardins de Données: (Page 121-137)