Module d’ordonnancement
Paradoxalement, alors que le module d’ordonnancement joue clairement un rˆole fonda- mental dans le processus de simulation, c’est aussi le moins ´etudi´e et les outils r´eellement d´edi´es `a la conception et `a l’impl´ementation de diff´erentes techniques d’ex´ecution ne sont pas l´egion. Parmi les rares approches existantes, on peut noter que la plate-forme Ascape, dont les mod`eles de simulation sont bas´es sur la d´efinition d’un ensemble de r`egles comportemen- tales, permet `a l’utilisateur de modifier, `a l’aide d’une interface graphique, la mani`ere dont ces r`egles sont appliqu´ees sur les agents lors de l’ex´ecution : par type de r`egle (une r`egle sur une ensemble d’agents) ou par agent (un ensemble de r`egles sur un seul agent) [Parker, 2001]. Meurisse propose aussi un outil de simulation permettant de modifier l’ordre dans lequel les diff´erents comportements des agents seront ex´ecut´es1 [Meurisse & Vanbergue, 2001]. A l’aide d’une interface graphique et sans modification du code original, cet outil permet de tester plu- sieurs s´equences d’activation diff´erentes grˆace `a la manipulation de composants repr´esentant des comportements atomiques (des m´ethodes d’objets en fait). Cet outil est cependant destin´e `
a des utilisateurs non informaticien et son utilisation n´ecessite la d´efinition de comportements qui respectent une syntaxe de programmation particuli`ere qui ne couvre volontairement pas toutes les techniques d’ex´ecution possibles.
Swarm (et aussi maintenant RePast) fait aussi ici figure d’exception. Il est en effet possible de modifier assez facilement la mani`ere dont le syst`eme est ex´ecut´e en modifiant directement les listes d’activit´es qui sont d´efinies dans un swarm (cf. section3.3.3). Ce qui est normal ´etant donn´e que cette question fait partie int´egrante d’un processus de mod´elisation r´ealis´e dans le contexte de la plate-forme Swarm. Cependant, aussi souple soit-elle, la ”machine virtuelle” de Swarm impose elle aussi de d´efinir des dynamiques qui reposent en fait sur une unique politique d’ex´ecution dont le principe ne peut ˆetre modifi´e : la liste d’activit´es. Autrement dit, le noyau d’ex´ecution de Swarm contient d´ej`a la d´efinition de ce qu’est la dynamique des syst`emes qui s’ex´ecuteront sur lui. Dans le cadre de notre ´etude, nous nous int´eresserons `a la conception d’outils permettant de d´efinir des politiques d’ex´ecution sur lesquels aucune contrainte n’est impos´ee. Cependant, ce qu’il faut retenir de ces diff´erents exemples, c’est qu’ils ont le m´erite de constituer des approches qui placent la probl´ematique de l’ordonnancement `a sa vraie place car ils la rendent explicite et manipulable. Cette question doit en effet faire partie int´egrante de la mod´elisation d’un syst`eme. Les outils de conception que nous allons pr´esenter dans la section suivante conservent cette id´ee mais n’imposent pas de contrainte sur la nature de l’impl´ementation de la politique d’ordonnancement choisie.
5.2
La plate-forme MadKit
Dans cette section, nous allons pr´esenter les grandes lignes du mod`ele organisationnel Aalaadin, aujourd’hui beaucoup plus connu sous le nom du mod`ele Agent/Groupe/Rˆole AGR [Ferber & Gutknecht, 1998, Gutknecht & Ferber, 1998] et de la plate-forme MadKit [Gutknecht et al. , 2001,Gutknecht, 2001] qui est bas´ee sur celui-ci.
5.2.1 Le mod`ele AGR : Agent/Groupe/Rˆole
Inspir´e par les travaux de Gasser et la plate-forme MACE, le mod`ele Aalaadin se fonde lui aussi sur l’utilisation de concepts organisationnels. L’id´ee fondamentale de cette approche
1
est de consid´erer qu’une structure organisationnelle hi´erarchique permet de faciliter l’analyse, la conception et l’ex´ecution de syst`emes multi-agents h´et´erog`enes.
Le mod`ele Aalaadin est bas´e sur trois concepts cl´es : l’agent, le groupe, le rˆole. On parle ainsi du mod`ele AGR2 (figure 5.1).
Agent
Rôle
Groupe
est membre joue
contient 1..* 1..* 1..* 1..* * *
Fig. 5.1 – Le mod`ele Agent Groupe Rˆole.
Agent
Quasiment aucune contrainte n’est pos´ee sur l’architecture interne ou sur le mod`ele de l’agent. L’agent est simplement d´ecrit comme une entit´e autonome communicante qui joue des rˆoles au sein de diff´erents groupes. Cette tr`es faible s´emantique est volontaire. Aucune supposition n’est faite sur le processus d´ecisionnel de l’agent et celui-ci ne repose sur au- cun formalisme en particulier. Le but est de laisser toute libert´e au concepteur pour choisir l’architecture qui sera la mieux appropri´ee `a ses besoins.
Groupe
Le groupe est la notion primitive de regroupement d’agents. Dans une premi`ere approche, le groupe est donc vu comme un moyen de localiser un ensemble d’agents. Plus pr´ecis´ement, associ´e `a un ensemble de rˆoles, il d´efinit la structuration organisationnelle d’un syst`eme multi- agents usuel. Chaque agent peut ˆetre membre d’un ou de plusieurs groupes et les diff´erents ensembles peuvent donc se recouper librement. Par ailleurs, un groupe peut ˆetre cr´e´e dyna- miquement par un agent.
Rˆole
Dans le mod`ele Aalaadin, le rˆole est consid´er´e comme la repr´esentation abstraite d’une fonc- tion, d’un service ou d’une identification d’un agent au sein d’un groupe particulier. Chaque agent peut avoir plusieurs rˆoles. Un mˆeme rˆole peut ˆetre tenu par plusieurs agents. Les rˆoles sont locaux aux groupes. La tenue d’un rˆole dans un groupe pr´eexistant doit ˆetre demand´ee par l’agent et n’est pas forc´ement accord´ee. La maˆıtrise de l’h´et´erog´en´eit´e des situations d’in-
2
Il faut noter qu’il existe des extensions int´eressantes du mod`ele AGR, notamment [Amiguet et al. , 2003,
5.2 La plate-forme MadKit 97
teraction est rendue possible par le fait qu’un agent peut avoir plusieurs rˆoles distincts au sein de plusieurs groupes, et que les interactions sont toujours locales `a un groupe.
5.2.2 Principes d’impl´ementation utilis´es dans MadKit
La plate-forme MadKit3est l’incarnation de l’utilisation du mod`ele AGR. Dans MadKit, ce dernier est utilis´e `a la fois pour fournir une structure organisationnelle aux syst`emes multi- agents qui sont ex´ecut´es et pour son propre fonctionnement interne. L’impl´ementation de MadKit int`egre par ailleurs trois principes de conception suppl´ementaires : une architecture `
a micro-noyau, l’agentification syst´ematique des services et l’utilisation d’un mod`ele graphique componentiel.
Architecture `a micro-noyau
Seules les op´erations de base de la plate-forme sont impl´ement´ees dans le noyau4 : gestion de la structure organisationnelle, cycle de vie des agents, routage des messages et m´ecanismes internes pour la simulation.
Agentification syst´ematique des services
Hormis l’utilisation de la structure organisationnelle et l’envoi de messages, l’ensemble des services offerts par la plate-forme est individuellement incarn´e par un agent ou un ensemble d’agents : surveillance du fonctionnement et de l’´etat du syst`eme, connexions avec un r´eseau de noyaux, gestion des messages non locaux, outils de simulation et d’une mani`ere g´en´erale toutes les applications et extensions de la plate-forme. Outre l’utilisation du mod`ele AGR au niveau m´eta du fonctionnement de la plate-forme, le principal int´erˆet de cette approche est de permettre le remplacement d’un agent de mani`ere transparente pour le reste du syst`eme multi- agents : celui-ci n’a en effet aucune r´epercussion sur le routage des messages si sa position dans l’organisation reste inchang´ee. Par ailleurs, cette approche permet de faire b´en´eficier tous les syst`emes multi-agents qui sont ex´ecut´es sur la plate-forme de l’ensemble des fonctionnalit´es qui ont ´et´e impl´ement´ees par ailleurs : un agent, quelle que soit son architecture interne, peut potentiellement communiquer avec n’importe quel autre agent modulo sa place dans l’organisation.
Utilisation d’un mod`ele graphique componentiel
Chaque agent est responsable de sa propre interface graphique5. Ce qui permet de voir un agent comme une simple fenˆetre ou de lui associer une interface correspondant `a une application compl`ete selon les besoins. De plus, un agent peut aussi fonctionner sans interface graphique comme c’est le cas pour la majorit´e des agents syst`eme. La plate-forme elle-mˆeme supporte plusieurs modes de fonctionnement graphique (au-dessus du noyau) : en mode texte, sous la forme d’une application graphique traditionnelle (menus, exploration des archives, etc.) et en mode application web sous la forme d’une Applet Java.
3
www.madkit.org.
4L’ensemble du noyau fait aujourd’hui 75 kilos de bytecode. Un peu plus lourd que dans les premi`eres
versions de la plate-forme, le noyau actuel conserve cependant l’´etat d’esprit originel.
5.2.3 Historique des versions
Initi´ee par Gutknecht et Ferber, la premi`ere version de la plate-forme MadKit voit le jour `
a la fin de l’ann´ee 19976. Nous avons personnellement rejoint le projet lorsque la plate-forme ´etait dans sa version 1.3. A partir de l`a, on peut grossi`erement r´esumer les diff´erentes ´etapes qui ont amen´e la plate-forme dans sa version actuelle (4) de la fa¸con suivante. La 1.4 a int´egr´e la premi`ere version des outils de simulation que nous pr´esenterons dans la section suivante. Les versions 2.x ont consist´e dans une mise `a plat des diff´erentes nouveaut´es apport´ees par les versions pr´ec´edentes et dans l’am´elioration des m´ecanismes d’interfa¸cage graphique.
La version 3 correspond au portage du code source aux sp´ecifications 1.2 du langage Java. Ceci a ´et´e l’occasion d’une refonte du micro-noyau qui a entraˆın´e de nombreuses modifications sur certains points cl´es de la plate-forme, notamment au niveau de la gestion de la structure organisationnelle et de la synchronisation entre plusieurs noyaux qui est maintenant g´er´ee par un agent syst`eme sp´ecifique, le SiteAgent. Un nouveau niveau organisationnel, la communaut´e, a aussi ´et´e introduit `a cette occasion. Une communaut´e permet de distinguer des parties de l’organisation (un ensemble de groupes) qui correspondent `a une application en particulier, ce qui permet d’une part de clarifier la structure organisationnelle et d’autre part de limiter les ´echanges r´eseau dans un contexte distribu´e7.
Ces diff´erents changements sont cependant rest´es transparents pour l’utilisateur lambda, au contraire des modifications effectu´ees lors du passage `a la version 4. Utilis´e dans un pre- mier temps en interne par notre ´equipe, la qualit´e des outils logiciels propos´es par le projet Apache Ant8 pour la gestion et la compilation de code source nous a pouss´es `a repenser la modularisation du code source de mani`ere `a ce que l’ind´ependance des diff´erents modules soit effective `a la fois dans la gestion des sources, pour le d´eveloppement et l’ex´ecution.
A l’instar de nombreux logiciels libres actuels, la version 4 de la plate-forme fonctionne donc aujourd’hui sur un mod`ele d’application bas´ee sur l’utilisation de plugins dont la mise `
a jour se fait individuellement. Autrement dit, la plate-forme est aujourd’hui distribu´ee dans une version minimale en taille et dont on peut r´ecup´erer les diff´erentes parties via Internet selon les besoins. Ce changement ´etait par ailleurs n´ecessaire ´etant donn´e le nombre croissant et l’h´et´erog´en´eit´e des applications d´evelopp´ees par plusieurs dizaines de d´eveloppeurs. Cette ´evolution a co¨ıncid´e avec une importante mise `a jour de l’interface graphique principale et la mise en libre acc`es de l’ensemble du code source via le site Sourceforge9.