2.3 L’univers IODA : quelques outils
Une méthode, un cadre formel, des algorithmes ne valent, nous l’avons dit, que s’ils sont implémentés, testés, appliqués à des situations réelles. Autour de IODA, ou plutôt au-dessus, se sont donc construits un certain nombre d’outils, le premier étant une plateforme d’expérimentation, JEDI. La séparation déclaratif/procédural permet de générer automatiquement une grande partie du code de simulation à partir du modèle conceptuel : c’est le rôle de JEDI-Builder. Enfin, pour un ensemble d’agents et d’interactions donné, il est possible de générer automatiquement des matrices d’inter- action et de soumettre les simulations qu’elles engendrent à un processus évolution- niste : c’est ce que fait LEIA, un navigateur dans l’espace des simulations. La figure 2.5 résume cette pyramide d’outils dont nous allons dire quelques mots.
2.3.1 JEDI : une plateforme d’expérimentation
✑ http://www.lifl.fr/SMAC/projects/ioda/jedi/ La méthode IODA se veut particulièrement adaptable aux besoins de ses utilisa- teurs dans divers domaines applicatifs, tout particulièrement lorsqu’ils ne sont pas formés à l’algorithmique ou à la programmation. Il serait paradoxal, dès lors, de vou- loir diffuser cette approche par le biais d’une plateforme unique, qui plus est écrite en Java et d’un haut niveau de technicité. De plus, le meilleur moyen de s’assurer que l’approche orientée interactions est indépendante d’un langage et même du para- digme objet, consiste à réaliser des implémentations du moteur sous des architectures diversifiées. Nous en verrons d’ailleurs quelques exemples plus loin (cf. §3.2.1, §3.3.1 et §3.3.2).
Le rôle de la plateforme JEDI (pour : Java Environment for the Design of agent Inter- actions), entièrement développée par Kubera [134], n’a donc pas pour objectif d’être LA plateforme universelle de diffusion de l’approche. En revanche, elle est destinée à expérimenter tous les détails de l’approche orientée interactions, tous ses algorithmes, toutes ses politiques, et à en donner une implémentation aussi fiable et efficace que possible. C’est en quelque sorte pour IODA une « théorie matérialisée » selon le mot de Bachelard [59, p. 16]. L’étude des biais de simulation et des façons de les évi- ter [12] a été au cœur de la conception de cette plateforme. Actuellement JEDI compte près de 15 000 lignes de code réparties dans une centaine de classes et d’interfaces, et peut faire tourner plusieurs centaines de milliers d’agents. Elle est extrêmement modulaire et actuellement distribuée par l’équipe SMAC sous la forme d’une archive JAR. Nous donnons sur la figure 2.6 un diagramme de classes extrêmement simplifié du « cœur » de JEDI.
Au-delà de ces considérations de génie logiciel, le point le plus important résulte de la séparation déclaratif/procédural : il est en effet possible d’automatiser dans une très large mesure le passage d’un modèle conceptuel IODA au modèle computation- nel correspondant et à son implémentation au sein de JEDI, grâce à un environnement de développement intégré qui s’appuie sur la plateforme : JEDI-Builder (fig 2.7).
JEDI-Builder met en œuvre la méthodologie associée à IODA (cf. §2.2.2) en per- mettant à l’utilisateur de concevoir son modèle de simulation de façon interactive,
Figure 2.6 –Diagramme de classes simplifié à l’extrême du cœur du simulateur JEDI. notamment en créant la matrice d’interaction par glisser-déposer, puis en analysant les primitives nécessaires à chaque classe d’agent et en générant soit le code complet, soit le squelette du code à écrire. La figure 2.8 montre que les tâches dévolues au seul programmeur sont réduites d’une part à la définition des déclencheur, condition et actions des interactions, et d’autre part à l’écriture du code des primitives : la tâche, lourde, de concevoir une simulation multi-agents, est donc en partie automatisée, le reste étant découpé en petites portions de code indépendantes les unes des autres.
Enfin, JEDI contribue à la diffusion de l’approche orientée interactions, sous la forme d’une applet qui met en scène d’une part des agents identifiés par leur cou- leur et placés dans une grille 2D, d’autre part des interactions très simples (comme se dupliquer, tuer un autre agent, etc.). Cet outil à vocation pédagogique permet de construire des simulations par des modifications incrémentales de la matrice d’inter- action pour en voir aussitôt le résultat (fig. 2.9), et en dépit de la simplicité de ses comportements, autorise la reproduction de phénomènes assez intéressants comme des dynamiques de ségrégation à la Schelling [193] ou de réactions chimiques os- cillantes du genre BZ [64, 220].
✑ http://www.lifl.fr/SMAC/projects/ioda/jedi/demonstration.php
2.3.2 LEIA : un navigateur dans l’espace des simulations
Dans une simulation multi-agents, l’espace des simulations possibles est généra- lement réduit à l’espace des paramètres qui peuvent modifier l’état des agents ou le déroulement des comportements [204]. Il en va tout autrement avec IODA, puisque l’affectation des interactions aux familles d’agents fait partie des « éléments » consti- tutifs du modèle. L’espace des simulations possibles s’accroît donc considérablement. Loin de constituer un handicap pour la conception de simulations, c’est au contraire une situation particulièrement favorable. En effet, dans de nombreux domaines, il peut être intéressant d’examiner des variantes d’un modèle donné pour savoir si les hypothèses qui ont été formulées et testées sont nécessaires, suffisantes, ou s’il existe des alternatives radicalement différentes pour rendre compte du même phénomène.
L’outil LEIA (pour : LEIA lets you Explore your Interactions for your Agents) conçu par Gaillard et al. [4] est une sorte de « navigateur » qui permet d’explorer l’espace des
2.3 – L’UNIVERS IODA : QUELQUES OUTILS
Figure 2.7 –Vue de l’IDE JEDI-Builder (emprunté à Kubera [134]).
Topologie de l'environnement
Identificateur des interactions
Matrice d'interaction brute Préconditions, déclencheur et
actions des interactions
Matrice de mise à jour Matrice d'interaction raffinée
Primitives abstraites des entités Halo des entités
Attributs des entités Primitives de l'environnement
Matrice de mise à jour ordonnée Identificateur des entités
A C B D E F G H I J K L + + + + + + Attributs de l'environnement M
Défini dans JEDI
Édité dans JEDI-Builder
Édité après génération de code par JEDI-Builder
Figure 2.8 –Répartition des tâches entre JEDI, JEDI-Builder et le développeur lors de l’utili- sation de JEDI-Builder pour l’implémentation d’un modèle IODA (emprunté à Kubera [134]).
Figure 2.9 – L’applet de démonstration de JEDI, dans laquelle on peut interactivement construire une matrice d’interaction à partir des agents et des interactions existantes (à gauche) et en visualiser immédiatement le résultat dans la simulation (à droite).
Figure 2.10 –Une vue du navigateur LEIA, avec ici quatre simulations lancées en parallèle. L’utilisateur peut choisir un mode de sélection automatique ou interactif, et définir ses propres critères d’évaluation en plus ou à la place des critères intrinsèques prédéfinis.
simulations de façon soit automatique, soit interactive. Il consiste à définir, pour un ensemble d’agents et un ensemble d’interactions fixés, un modèle dit « de base ». Ce modèle est transformé par un certain nombre d’opérateurs (qui peuvent être choisis selon les objectifs visés), tels que le déplacement d’une interaction d’une case de la matrice vers une autre, l’ajout ou la suppression d’une interaction dans une case, la modification de la priorité, etc., de façon à produire N modèles « dérivés ». Ces N mo- dèles sont exécutés dans autant d’instances de JEDI en parallèle, et un score leur est attribué. Ce score peut être calculé selon des critères intrinsèques au déroulement de la simulation (existence de cycles dans les comportements, densité des agents, évolu- tion des populations, etc.) ou selon des critères propres au domaine considéré. Enfin, les meilleurs modèles (sélectionnés sur leur score ou par un observateur humain) sont hybridés à l’aide d’opérateurs de fusion de matrices afin de créer un nouveau « modèle de base », et le processus est itéré autant que nécessaire (fig. 2.10).