UNIVERSITE BLAISE PASCAL UFR SCIENCES EXACTES ET NATURELLES DEPARTEMENT DE MATHEMATIQUES ET INFORMATIQUE 63177 AUBIERE CEDEX Matrise dInformatique

RAPPORT DE STAGE

Prsent par

Nicolas DUMOULIN

Sujet : Modlisation dune colonie de chauve-souris vampires en vue de raliser une application ludo-ducative.

Lieu du stage : Cemagref, groupement de Clermont-Ferrand Unit de Recherche LISC 24, Avenue des Landais BP 50085 63172 Aubire Cedex Dure du stage : 5 mois

Remerciements

Je tiens tout dabord remercier Frdric Amblard, mon matre de stage, pour ses conseils pertinents et sa confiance, et pour mavoir motiv (sans le vouloir ;-) poursuivre mes tudes vers un DEA.

Merci de manire gnrale toute lquipe du LISC pour sa bonne humeur permanente, et pour leur chaleureux accueil. Je tiens galement remercier les membres de la javalist de lUniversit de Strasbourg (www.sogid.com/javalist/) et ceux du Forum Hardware.fr (forum.hardware.fr), pour leur prcieuse aide en langage Java.

I.

Sommaire

I. II.

SOMMAIRE ...................................................................................................................................................... 3 RESUME : ......................................................................................................................................................... 4

III. ABSTRACT :..................................................................................................................................................... 4 IV. V. 1. INTRODUCTION ............................................................................................................................................. 5 PRESENTATION DE L'ENTREPRISE......................................................................................................... 6 LE CEMAGREF ............................................................................................................................................. 6 1.1. Le budget ................................................................................................................................................... 7 1.2. Les ressources humaines............................................................................................................................ 8 2. LE CEMAGREF EN REGION AUVERGNE-LIMOUSIN ....................................................................................... 9 2.1. Trois Units de Recherche et d'Expertise .................................................................................................. 9 3. LE LABORATOIRE D'INGENIERIE DES SYSTEMES COMPLEXES (LISC)............................................................... 9 PRESENTATION DE L'ETUDE................................................................................................................... 11 LE SUJET ........................................................................................................................................................ 11 PLANNING DU STAGE ..................................................................................................................................... 12 DESCRIPTIF DES OUTILS ACQUIS..................................................................................................... 13 LE LANGAGE JAVA ........................................................................................................................................ 13 LES LOGICIELS UTILISES ................................................................................................................................ 14 LES SYSTEMES MULTI-AGENTS ...................................................................................................................... 14 3.1. Dfinitions................................................................................................................................................ 14 3.2. Modlisation par systmes multi-agents .................................................................................................. 15 L'ETUDE..................................................................................................................................................... 16

VI. 1. 2. VII. 1. 2. 3.

VIII. 1.

LE VAMPIRE DESMODUS ROTUNDUS .............................................................................................................. 16 1.1. Prsentation gnrale de lespce ........................................................................................................... 16 1.2. Renouvellement de lespce ..................................................................................................................... 16 1.3. Vie sociale................................................................................................................................................ 17 2. MODELISATION ............................................................................................................................................. 18 2.1. Cadre thorique : le dilemme du prisonnier itr.................................................................................... 18 2.2. Caractristiques retenues pour notre modle .......................................................................................... 19 2.3. Lapproche multi-agents.......................................................................................................................... 20 2.4. Le modle de simulation .......................................................................................................................... 21 2.5. Reprsentation graphique des relations .................................................................................................. 27 3. LAPPLICATION ............................................................................................................................................. 33 3.1. Prsentation gnrale .............................................................................................................................. 33 3.2. Durant la simulation................................................................................................................................ 36 IX. 1. 2. CONCLUSION................................................................................................................................................ 40 BILAN ............................................................................................................................................................ 40 PERSPECTIVES ............................................................................................................................................... 40 2.1. Exploration du modle............................................................................................................................. 40 2.2. Ralisation du jeu .................................................................................................................................... 40 REFERENCES BIBLIOGRAPHIQUES ...................................................................................................... 41

X.

II. Rsum :
Le but de cette tude est de modliser une colonie de chauve-souris vampires dans le but de dterminer par la simulation les caractristiques idales pour raliser un jeu, ce jeu tant destination d'une exposition au Musum National dHistoire Naturelle et devant mettre en vidence les enjeux de la coopration chez les vampires. Le but de ce calibrage est de mettre le joueur dans des situations proches de la ralit, mais de faire apparatre rgulirement les vnements exceptionnels qui gnrent un besoin de coopration.

III. Abstract :

This study aims at modelling a vampire bats colony, in order to find by simulations the ideal characteristics of the corresponding game. This game is dedicated to an exposition at the Musum National dHistoire Naturelles in France, and must highlight the cooperations stakes by vampire bats. This calibration must on the one hand put the player in situations near of the real cases, and on the other hand, it must also force the appearance of exceptional events, which generate a need for cooperation.

IV. Introduction

Ce rapport a pour objectif de rendre tat de la premire partie de mon stage de Matrise d'Informatique, qui s'est droul sur le site clermontois du CEMAGREF (Centre national d'Etudes sur le Machinisme Agricole, le Gnie Rural, les Eaux et Forts), au sein du Laboratoire d'Ingnierie pour les Systmes Complexes (LISC). Ce stage est exceptionnellement prolong, et durera 5 mois au lieu de 3 mois. Le but de ce stage est de concevoir une application ludo-ducative permettant dillustrer laspect primordial de la coopration dans les socits de vampires (chauves-souris). Cette application sera ensuite utilise par le Musum dHistoire Naturelle de Paris en vue dune exposition sur la coopration chez les animaux. La stratgie utilise ici, est de dvelopper dans un premier temps une plate-forme de simulation qui permettra de caler le jeu, afin de faire apparatre des cas intressants.

V. Prsentation de l'entreprise

1.

Le CEMAGREF

Institut de recherche pour l'ingnierie de l'agriculture et de l'environnement, le Centre national d'Etudes sur le Machinisme Agricole, le Gnie Rural, les Eaux et Forts, le Cemagref, est un tablissement public caractre scientifique et technologique (EPST). Il a t cr en 1981 et est plac sous la double tutelle du ministre de l'Education nationale, de l'Enseignement Suprieur, de la Recherche et de la Technologie et du ministre de l'Agriculture, de la Pche et de l'Alimentation. Outre la contribution au progrs des connaissances, le CEMAGREF diffuse des mthodes de diagnostic et de contrle, il dveloppe des outils de gestion et de ngociation, il conoit des technologies innovantes (exemple : la conduite automatique de tracteurs, dtection du potentiel dinondation dun cours deau) et apporte son expertise aux services publics et aux entreprises. Les mthodologies scientifiques constituent un apport essentiel la recherche en ingnierie. Modlisation, information gographique et informatique scientifique sont privilgies. Ces recherches contribuent au dveloppement durable des territoires. Elles aident protger et grer les hydrosystmes et les milieux terrestres, dynamiser les activits qui les valorisent et prvenir les risques qui leur sont associs. Ses objets d'tude sont donc le plus souvent des systmes complexes, en relation avec des questions de socit et sa dmarche est presque toujours interdisciplinaire.

Les activits du CEMAGREF Ses orientations scientifiques sont regroupes en 4 dpartements et concernent : le fonctionnement des hydrosystmes, le gnie des quipements et services pour l'eau et les dchets, la gestion des territoires dominante rurale, le gnie des quipements dans le secteur agricole et alimentaire.

Les hydrosystmes et leurs relations avec l'agriculture d'une part, la gestion des risques naturels d'autre part, sont deux thmatiques scientifiques prioritaires pour les annes venir. Les mthodologies scientifiques constituent un apport essentiel la recherche en ingnierie.

1.1.

Le budget

Le budget consolid s'lve 56,5 M (370 MF) dont plus de 15 M (100MF) de recettes de rsultats. L'activit scientifique est donc ngocie avec les nombreux partenaires qui assurent l'essentiel des moyens de fonctionnement des units de recherche. Chaque anne, plus de 150 7

contrats de recherche et de transferts sont signs.

Le budget

1.2.

Les ressources humaines

Le CEMAGREF emploie un peu moins de mille personnes titre permanent. Deux tiers des emplois sont financs par le budget civil de la recherche et du dveloppement. Le dernier tiers est mis disposition principalement par le ministre de l'agriculture, de la pche et de l'alimentation.

Les effectifs

2.

Le CEMAGREF en rgion Auvergne-Limousin

Le CEMAGREF de Clermont-Ferrand est une des 9 dlgations rgionales de l'Institut, celle de la Rgion Auvergne-Limousin. Au mme titre que le CNRS, l'INRA ou l'INSERM, il fait partie, en tant qu'EPST, du paysage de la recherche publique en Auvergne et s'applique dvelopper ses partenariats scientifiques, d'enseignement suprieur et formation ou de transfert dans cette rgion.

2.1.

Trois Units de Recherche et d'Expertise

Les activits de recherche du CEMAGREF en rgion Auvergne sont conduites sur 2 sites : Aubire et Montoldre. Le CEMAGREF de Clermont-Ferrand (Aubire) accueille 4 Units de Recherche et d'Expertise (URE) : DFCF : Dynamiques et Fonctions des espaces ruraux TSCF : Technologies, Systmes d'information et procds pour l'agriculture et l'agroalimentaire LISC : Laboratoire d'Ingnierie des Systmes Complexes

3.

Le Laboratoire d'ingnierie des systmes complexes (LISC)

Lunit de recherche participe des projets scientifiques en collaboration avec les quatre dpartements scientifiques du Cemagref. Elle a pour mission dvaluer et de dvelopper des mthodes de modlisation de systmes complexes. Ce travail est men en collaboration troite avec les quipes thmatiques de ltablissement et des partenaires extrieurs au travers de projets communs, souvent interdisciplinaires. Le thme de recherche de lunit, MAGESTYC (Modles pour l'Aide la GESTion des sYstmes Complexes), vise laborer, tester, valider des mthodes de modlisation gnriques utilisables dans les domaines dactivit du Cemagref : cosystmes, dynamiques sociales et interactions avec le milieu, interactions entre quipements et milieux naturels. Le travail de recherche se concentre particulirement sur lutilisation de modles gomtriques dynamiques, qui permettent de dfinir lvolution locale de formes, diverses chelles. Ces modles sont labors dans une dmarche incrmentale, en troite liaison avec des experts du terrain et des domaines abords. Leur confrontation aux historiques de donnes disponibles et lapprciation des acteurs est une question particulirement sensible. Les applications principalement vises sont des outils de gestion de la connaissance, gnralement destins aux experts dun domaine, ou directement des outils daide la dcision ou la ngociation pour les acteurs de terrain. Dans ce cadre, le LISC s'efforce de rpondre aux questions suivantes lorsqu'elles se rapportent aux domaines thmatiques des quipements agro-alimentaires, des aspects "qualit alimentaire", de l'eau, de la fort et de la gestion de l'espace rural : 9

Recueillir l'information pertinente pour un problme partir de bases de donnes (statistiques, data mining) Mettre en place et valider des simulations de systmes constitus d'agents en interaction, et rechercher des mthodes de rsolution de problmes distribus (systmes multi-agents) Intgrer des connaissances expertes aprs leur recueil et leur formalisation (systmes base de connaissances) Intgrer des systmes d'information cohrents, utilisables, et ouverts, raisonns par rapport une perspective d'aide la dcision ou de ngociation

10

VI. Prsentation de l'tude

1. Le sujet

Le Musum d'Histoire Naturelle de Paris prpare une exposition pour 2003 portant sur la coopration dans le domaine animal. Une partie de l'exposition est consacre l'altruisme rciproque, et particulirement au cas observ dans les socits de vampires (chauve-souris). En effet, les vampires se nourrissent de sang chaque soir, mais il arrive qu'ils rentrent bredouilles de leur chasse. Or, sils restent deux soirs sans russir se nourrir de sang, ils meurent d'inanition. Cest pour cela, que les vampires sentraident en rgurgitant du sang ceux qui en ont besoin. Ce phnomne de coopration est dcrit thoriquement par le dilemme du prisonnier itr en thorie des jeux (Von Newman et Morgenstern, 1947). Le Musum dsire pour cette partie, disposer d'une application ludo-ducative installe sur des bornes interactives, afin que les visiteurs puissent apprcier les enjeux de la coopration chez les animaux. Le LISC, laboratoire situ au Cemagref Clermont-Ferrand, a donc dcid de rpondre cette demande en en proposant la ralisation un stagiaire. Le but du stage est donc de raliser l'application demande sur une priode de 5 mois (de Avril fin Aot). Cette application comportera deux objectifs. Tout d'abord, elle devra permettre de simuler l'volution d'une colonie de vampires en fonction de paramtres spcifiques. Cette simulation permettra alors dterminer les paramtres saillants pour la ralisation du jeu. La seconde partie sera de raliser le jeu lui-mme, permettant d'illustrer aux joueurs l'importance de la coopration. La plate-forme de simulation devra tre conviviale. Elle proposera diffrentes botes de dialogue, pour ajuster les paramtres de la simulation, et diter les proprits des vampires et de la colonie. Elle proposera galement un graphe permettant de reprsenter les changes faits entre les vampires en temps rel. La plate-forme de simulation et le jeu devront tre ralis en Java, afin que lapplication soit entirement portable notamment sur les bornes et quelle laisse la possibilit de proposer le jeu sur une page web. Lapplication raliser comportera un habillage graphique sommaire et permettra aux commanditaires de modifier l'interface graphique de manire simplifie. Jusqu maintenant, rien navait t encore dvelopp dans ce cadre. Il ny a donc pas dexistant. Rien ntait impos quant aux logiciels utiliser pour la conception et le dveloppement.

11

2.

Planning du stage

Premier mois

Bibliographie sur l'espce tudie (le vampire desmodus rotundus) Recherche d'outils technologiques de modlisation et de dveloppement Documentation sur les systmes multi-agents. Analyse et spcification du modle exploiter. Implmentation du modle. Poursuite de l'implmentation du modle. Dveloppement de l'interface graphique. Dveloppement d'un mode de visualisation des relations entre les vampires. Exploration des simulations, pour trouver les espaces de paramtres intressants pour le jeu. Poursuite du dveloppement de l'interface graphique. Rdaction du rapport de stage. Poursuite de lexploration des simulations. Spcification du scnario du jeu avec le Musum dHistoire Naturelle. Conception du jeu. Dveloppement du jeu. Dveloppement doutils ddis la modification du contenu du jeu (graphisme et textes).

Deuxime mois

Troisime mois

Quatrime mois

Cinquime mois

12

VII. Descriptif des outils acquis

Durant ce stage, j'ai surtout approfondi mes connaissances en modlisation UML, et en Java. J'ai manipuler des logiciels permettant de construire des modles UML (Poseidon), et de dvelopper en Java (JEdit). J'ai galement dcouvert le domaine des systmes multi-agents.

1.

Le langage Java

Java est un langage orient objet qui a t cr par la socit Sun en 1995. Malgr des difficults lies surtout au manque de performances (qui ont tendance s'effacer), ce langage est aujourd'hui largement utilis travers le monde. Ses points forts sont : sa portabilit, qui est son principal atout. En effet, les programmes dvelopps en Java sont ensuite excuts par une machine virtuelle, qui sert d'interface entre l'application et le systme d'exploitation. Ainsi, ces programmes peuvent tre excuts sur n'importe quelle plate-forme et sous n'importe quel systme d'exploitation, pourvu qu'une machine virtuelle Java y soit installe. sa fiabilit. Le langage Java est fortement typ (plus que le C++), et n'offre pas la possibilit de manipuler des pointeurs, ce qui supprime bon nombre d'erreurs gnres invitablement dans d'autres langages. le grand nombre de classes fournies par le JDK (Java Development Kit). Parmi celles-ci, on trouve celles qui permettent de manipuler des flux (fichiers, socket, donnes provenant d'internet...), des bases de donnes, des structures de donnes, etc. Un ensemble de classes permet galement de dvelopper rapidement des interfaces graphiques trs compltes. sa proximit syntaxique du langage C++. Celle-ci permet de passer de l'un l'autre sans trop de mal.

Ses points faibles sont : La prsence obligatoire de la machine virtuelle sur la machine utilisatrice. Labsence de gestion de la mmoire pour le programmeur, ce qui empche toute optimisation, celle-ci tant compltement gre par la machine virtuelle. Limpossibilit dimplmenter les hritages multiples, ceci en vue dviter des erreurs de programmation. Nanmoins Java offre une autre possibilit pour contourner ce problme qui est lutilisation dinterfaces. 13

Dans le cadre de mon tude, le modle ne prsentant pas des proportions leves, lutilisation de la machine virtuelle na pos aucun problme. Jai surtout apprci ce langage pour sa facilit dutilisation et la documentation exhaustive des classes fournies. La version du JDK que jai utilise est la 1.4, la 1.3 est encore largement utilise, mais la 1.4 apportait de nouvelles fonctionnalits fortes intressantes comme lamlioration de la gestion des composants Swing (interface graphique), une classe ddie aux entres sorties dimages (imageio), la prise en charge de la molette des souris, et bon nombre de nouvelles mthodes dans diverses classes.

2.

Les logiciels utiliss

Nayant pas de logiciels imposs pour la conception et le dveloppement, jai donc choisi de faire mes propres recherches et trouver les outils qui seraient les mieux adapts pour mon contexte. Poseidon (www.gentleware.com) est un logiciel en shareware qui permet de construire des modles UML, et de gnrer le code Java correspondant au modle (classes, attributs, mthodes, accesseurs/modificateurs d'attributs, commentaires JavaDoc). Il possde galement la capacit de faire du "reverse engineering", c'est--dire qu' partir d'un ensemble de fichiers Java existants, il reconstruit un diagramme de classes UML correspondant. JEdit (www.jedit.org) est un Environnement de Dveloppement Intgr (EDI) en freeware. Il permet de faciliter le dveloppement de gros projets en offrant une saisie semi-automatique du code, et des scripts de compilation gnrs automatiquement. Ce logiciel permet galement lintgration de modules supplmentaires qui existent en trs grand nombre. Parmi ceux-ci, on pourra trouver un explorateur de classe qui permet de naviguer plus aisment dans le code, ou encore un enjoliveur de code, qui automatise lindentation selon les prfrences dfinies par lutilisateur.

3.

Les systmes multi-agents

3.1. Dfinitions

Un agent est une entit qui peut tre vue comme percevant et agissant de faon autonome sur son environnement. En voici une dfinition (Ferber, 1995) : On appelle agent une entit physique ou virtuelle a. qui peut tre capable dagir dans un environnement, b. qui peut communiquer directement avec dautres agents, c. qui est mue par un ensemble de tendances (sous la forme dobjectifs individuels ou dune fonction de satisfaction, voire de survie, quelle cherche optimiser), 14

d. qui possde des ressources propres, e. qui est capable de percevoir (mais de manire limite) son environnement, f. qui ne dispose que dune reprsentation partielle de cet environnement (et ventuellement aucune), g. qui possde des comptences et offre des services, h. qui peut ventuellement se reproduire, i. dont le comportement tend satisfaire ses objectifs, en tenant compte des ressources et des comptences dont elle dispose, et en fonction de sa perception, de ses reprsentations et des communications quelle reoit. Un systme multi-agents est donc un systme compos dagents, de ressources et doprateurs qui ont pour rle de grer la coordination des tches de chaque agent et linfluence que chacun des agents peut avoir sur lenvironnement. Les agents interagissant galement entre eux, ils vont crer un rseau de relations. Ces relations peuvent tre des relations daccointances (reconnaissances dagent) ou des relations de communicabilit. La dualit agent/environnement est au cur des systmes multi-agents, puisque lenvironnement va structurer le comportement des agents (contraintes), et les agents vont galement modifier leur environnement.

3.2.

Modlisation par systmes multi-agents

Le besoin dutiliser les systmes multi-agents comme support de simulation vient des limites des techniques de simulation traditionnelles (modles dterministes et stochastiques). Les mthodes de simulation classiques reprsentent les individus de manire agrge, tandis que la simulation par systme multi-agents considre chaque individu, ce qui apporte plus de cohrence dans le modle et une plus grande souplesse et modularit des individus. Pour (Bousquet, 1994), laborer un systme multi-agents revient reproduire un monde artificiel ressemblant au monde observ, en ce sens quil est compos de diffrents acteurs, de faon y mener des expriences diverses et varies. A travers cette approche, il est possible de reprsenter directement les individus dun systme, leurs comportements et leurs interactions. Cest--dire, quau lieu de modliser les systmes en sappuyant sur des quations diffrentielles, sur des matrices de transitions ou toute autre reprsentation formelle, une structure de donne est propose pour chaque entit existante dans le systme (Campos, 2000).

15

V III.
1.

L'tude

Le vampire desmodus rotundus

Gerald Wilkinson de lUniversit de Maryland (USA), accompagn de Robin Weiss, Michael Jones et Terri Lamp a pass 26 mois (entre 1978 et 1983) au Costa Rica pour tudier le comportement des vampires desmodus rotundus (Wilkinson, 1990).

1.1.

Prsentation gnrale de lespce

Le sujet tudi est le vampire commun (desmodus rotundus), qui vit en Amrique Centrale et se nourrit exclusivement de sang quil se procure en incisant laide de ses dents la peau des vaches et chevaux, et en lchant le sang qui sort ainsi de la plaie. Il pse en moyenne entre 95 et 140 grammes, et son esprance de vie est comprise entre 14 et 20 ans.

Figure 1.1 Un desmodus rotundus

Pour rester en vie, le vampire doit consommer 2 30 millilitres de sang toutes les 60 heures, sinon il meure dinanition. Il chasse une fois par jour (la nuit) en groupe. Ses chasses ne sont pas toujours fructueuses, et son taux de russite varie en fonction de lge. Un adulte ( partir de 2 ans) a un taux de russite la chasse de 97%, tandis quun jeune vampire de 3 mois rentrera bredouille 3 fois sur 10. Ce taux de russite crot donc de 70% 97% entre 3 mois et 2 ans, qui correspond lapprentissage du jeune vampire.

1.2.

Renouvellement de lespce

Les femelles sont en ge de procrer partir de 10 mois. Leur priode de gestation dure entre 6 et 8 mois. Les femelles ont une porte de un vampire par an. A la naissance les petits psent entre 5 et 7 grammes, et durant le premier mois de leur vie, ils seront nourris par le lait maternel. Au bout dun mois, leur poids a doubl, il est pass 12 grammes. De 1 mois 3 mois, la mre 16

nourrit son petit de sang quelle rgurgite. A partir de 3 mois, le petit commence tre autonome, il part lui-mme la chasse en qute de sang, mais conserve un lien privilgi avec sa mre. Ses chasses ntant pas encore efficaces, il doit pouvoir demander du sang sa mre. A 5 mois, il a termin sa croissance, il a donc atteint un poids adulte. Il sera compltement sevr 10 mois, lorsquil aura atteint sa maturit sexuelle.

1.3.

Vie sociale

Les vampires vivent en colonies de 100 individus, et se rpartissent en sous-groupes dune quinzaine dindividus. Chaque sousgroupe loge dans une niche, leurs niches prfres tant les troncs darbres creux. Les femelles changent rgulirement de sousgroupe. Les mles eux, dfendent leur place dans la niche, et restent donc tout le temps dans la mme. En gnral, les femelles sont regroupes avec leurs petits tout en haut de la niche, et les mles eux se placent sur les parois un peu plus bas, et se battent pour tre le plus haut possible. Ce comportement fait quune femelle voit plusieurs mles. Figure 1.2 Rpartition des vampires dans la niche. (extrait de Pour la science n150 Avril 1990 p.62)

Les vampires communiquent en mettant des sons trs aigus. Lquipe de Gerald Wilkinson a montr que ces signaux taient semblables dun vampire ses descendants, ce qui leur permet didentifier un membre de leur ligne, et que les vampires taient capables den identifier un autre grce ces sons, mme aprs plusieurs annes. Lorsquil est rassasi, un vampire a une rserve de 60 heures de survie. Le lendemain dune chasse infructueuse, il doit absolument se procurer du sang sinon il mourra avant la prochaine chasse. Au bout de deux jours sans russite la chasse, le vampire va demander une femelle de lui rgurgiter une partie du sang quelle possde dans son estomac, car seules les femelles acceptent de le faire. Celle-ci se rserve tout de mme le pouvoir de refuser ou accepter selon plusieurs critres qui concerne les liens de parents et les affinits qui se crent au fil du temps. Les rgurgitations nont lieu que lorsque le vampire demandeur est rellement en danger de mort. Cela signifie galement que les vampires sont capables de dtecter si un autre individu est affam ou pas. 17

Lors dune rgurgitation, le vampire perd moins que lautre ne gagne. Pour mieux comprendre ce phnomne, observons la courbe de la figure 1.2. La courbe reprsente le nombre dheures gagnes au cours de la digestion. On remarque que la courbe nest pas linaire, et que de ce fait, durant la premire journe qui suit une chasse fructueuse le fait de cder un peu de sang ne fait perdre que trois heures de survie, tandis quau bout de deux jours sans approvisionnement une petite quantit de sang va alimenter beaucoup plus lorganisme du receveur.

Figure 1.3 Le vampire receveur est plus avantag que le donneur nest gn. (extrait de Pour la science n150 Avril 1990 p.63)

2.

Modlisation
2.1. Cadre thorique : le dilemme du prisonnier itr

Le propos de la thorie des jeux est ltude de toute situation prsentant des caractristiques semblables celles des jeux de socit, cest--dire de situations o des individus font des choix en interaction, dans un cadre stipul lavance. Le dilemme du prisonnier est un type de jeu o des individus ont intrt sentendre, plutt qu ne pas sentendre, mais o chacun peut gagner ne pas respecter un ventuel accord, si les autres sy tiennent. Tel est le cas lorsque deux suspects sont incits se dnoncer lun lautre. Voici lnonc de ce jeu qui est expos par (Axelrod, 1984) : P1 et P2 sont deux prisonniers qui 18

ont le choix entre cooprer et trahir, chacun dentre eux ne connaissant pas la dcision de lautre. Le tableau 2.1 prsente les gains raliss par les deux prisonniers en fonctions de leurs dcisions. En observant les gains, on observe que, a priori, il est prfrable de trahir car on gagne plus quen cooprant (5 ans de remise de peine ou 1 contre 3 ans ou 0), et ce quelque soit le choix de lautre prisonnier. Hors si les deux prisonniers suivent ce raisonnement, il ralise un gain moins lev que sils avaient coopr tous les deux, do le dilemme. P2 Coopre P1 Coopre Trahit (3,3) (5,0) Trahit (0,5) (1,1)

Tableau 2.1 Le dilemme du prisonnier On appellera stratgie lensemble des rgles qui dterminent les choix faits par lindividus. Lorsque ce type jeu est itr, le nombre de stratgie devient vite extrmement grand (il crot exponentiellement avec le nombre de coups). Parmi ces stratgies, (Delahaye, 1992) en retient 12, dont : La stratgie mchante (toujours trahir). La stratgie gentille (toujours cooprer). La stratgie du donnant-donnant, consistant riposter par un trahison toute trahison de lautre. La stratgie lunatique consistant faire son choix au hasard.

Dans le cas du dilemme du prisonnier itr, o le nombre ditration nest pas connu lavance, la meilleure stratgie adopter est le donnant-donnant . Le contexte de la coopration chez les vampires illustre parfaitement le dilemme du prisonnier itr. La stratgie adopte par les vampires est le donnant-donnant , qui leur permet dliminer des profiteurs, car les vampires favorisent ceux qui font partie de leurs bonnes relations.

2.2.

Caractristiques retenues pour notre modle

Modliser un cosystme est une tche complexe dune part, et dautre part tous les aspects de la ralit ne nous intresse pas dans le cadre de la ralisation du jeu. Pour commencer, nous ne considrerons pas laspect spatial dans notre modle, car ce sont ltat des relations de coopration entre les vampires dans un sous-groupe et lvolution de la population qui nous intressent. La rpartition des vampires se fera donc juste au niveau de lagrgat sous-groupe . Dun point de vue dmographique, on introduit dans le modle une dynamique de population par un taux de natalit et un processus de mortalit, qui se compose de la mort naturelle et de la mort 19

par manque de nourriture (on ne prend pas en compte les accidents qui pourraient survenir lors des sorties nocturnes). Les mles adultes ne sont pas considrs, car ils ne participent pas aux changes de sang. De cette manire, nous les prenons en compte pendant leur phase de sevrage, car ce moment, ils participent aux rgurgitations mre - petit. Notre modle ne comportera donc les mles quentre le moment de leur naissance et 10 mois. Etant donn que durant les deux premiers mois, le petit vampire est compltement dpendant de sa mre et quil ne chasse pas encore, les petits seront inclus dans le modle partir de 2 mois. De plus, comme la gestation ninfluence a priori pas le comportement de la mre, elle ne sera pas prise en compte. Donc tous les ans, une mre fera natre un petit de 2 mois.

2.3.

Lapproche multi-agents

Dans notre cas, il apparat assez clairement que lindividu vampire est un agent de notre systme. Il nous reste dfinir son comportement, et galement un ordonnanceur qui va dclencher les vnements au niveau de la colonie et des sous-groupes. Lordonnancement se fera plusieurs niveaux. Au niveau de la colonie seront dclenches successivement les diffrentes phases dune journe pour chaque sous-groupe. Et chaque sousgroupe dclenchera les tapes pour chaque vampire quil contient. Chaque journe de la simulation se dcoupera effectivement en plusieurs phases : Cration Cration : durant cette phase, les femelles vampires sont sollicites pour crer de nouveaux vampires. Chaque femelle ayant ses propres caractristiques, les naissances seront disperses sur la dure de la simulation. Chasse : les vampires reoivent leur ration de sang, en fonction dun tirage alatoire, qui dpend videmment de leur taux de russite. Migration : les femelles ont la possibilit de changer de sous-groupe, si elles nont pas de petits, et en fonction dun facteur alatoire. Requtes : cest ce moment que les vampires affams peuvent demander du secours auprs dautres vampires. Croissance : tous les vampires vieillissent dun jour, changent de classe dge si ncessaire ou meurent sils ont trop vieux, ou sils nont plus assez de rserves.

Chasse

Migration

Requtes

Croissance Figure 2.1 Les phases dune journe

20

2.4.

Le modle de simulation

2.4.1.

Modlisation du systme

Notre systme comportant une agrgation au niveau des formations de sous-groupes, nous allons retrouver galement cette structure dans notre modle. Nous allons avoir besoin dune classe coordinatrice, qui contiendra tous les paramtres de la simulation et les mthodes qui permettront de les manipuler. Cette classe sera la classe Simulateur, que nous dcouvrons sur la figure suivante :

Figure 2.2 Diagramme de classe UML : les diffrents niveaux dagrgation Dans la classe Simulateur, nous retrouverons donc tous les paramtres pouvant initialiser une simulation et des indicateurs sur lvolution de la colonie, qui sont :
iDuree (le i signifie que la variable est un entier, selon la notation polonaise) : la dure

en jours de la simulation.
iNbJoursEcoules : le nombre de jours couls durant la (les) simulation(s). iNbNaissances : le nombre de naissances survenues. iNbMigrations : le nombre de migrations. iNbRegurgitations : le nombre de rgurgitations faites entre vampires. iNextIdentifiant : identifiant pouvant tre attribu un nouveau vampire en respectant

lunicit. Ce nombre est incrment automatiquement lors dune attribution dun identifiant 21

un vampire.
iTaille : taille initiale de la colonie. iTailleSsGroupe : taille initiale moyenne des sous-groupes. fFecondite : proportion initiale de jeunes vampires par rapport lensemble de la

population.
fFreqRegurgiteParente : proportion initiale des rgurgitations mre - petit par rapport

lensemble des rgurgitations.

fMortaliteInfantile : probabilit pour un jeune vampire de moins de 10 mois de mourir. iEsperanceVie : Limite dge en jours pour un vampire. fTauxReussite{3mois;5mois;10mois;VampireFemelle} : taux de russite la chasse

lge correspondant. Entre deux paliers, ce taux de russite suit une volution linaire et est recalcul tous les jours.
iNbHeuresPerdues et iNbHeuresGagnes : nombres dheures de survie perdues et gagnes

lors dune rgurgitation.

iAgeMinEchange : ge partir duquel un vampire participe des rgurgitations autres que

dans le cadre mre petit. Voici maintenant la description de ses mthodes :

init() : qui comporte autant de paramtres que la classe possde dattributs. Cette mthode

va tout simplement initialiser une colonie de vampire en respectant les paramtres fournis. Le paramtre de retour sert signaler si linitialisation sest droule correctement, ou si une incohrence dans les paramtres a t rencontre (nombre de groupes nul, etc.).
open(String) : permet dinitialiser une simulation partir dun fichier contenant ltat

dune simulation (conditions initiales et tats des vampires).

save(String) : permet de la mme manire de sauvegarder ltat dune simulation dans un

fichier.
run() : dclenche la simulation pendant autant de jours que prcis dans les conditions

initiales.
run(int nb) : dclenche la simulation sur nb jours. Cette fonction va notamment permettre

de faire du pas--pas.
isAlive() : renseigne si une simulation est en cours.

Le simulateur possde une colonie, qui elle-mme possde plusieurs groupes qui sont composs de plusieurs vampires. La mthode run() de la classe Simulateur va appeler successivement les cinq mthodes de la classe Colonie, qui vont elles-mmes appeler les mthodes correspondantes pour chacune des instances de la classe SousGroupe. Ces cinq mthodes correspondent aux cinq phases dcrites plus haut (figure 2.1). 22

Lorsquun vampire meurt ou quun mle est retir de la simulation 10 mois, on veut nanmoins pouvoir les garder en mmoire pour consulter leur tat plus tard. Cest pour cela que deux associations ont t ajoutes entre la classe Simulateur et la classe Vampire comme on peut le voir sur la figure ci-dessous.

Figure 2.3 Diagramme de classe UML : conservation des individus sortis du modle 2.4.2. Modlisation de lagent vampire

Pour commencer, nous pouvons dgager quatre catgories dge pour nos vampires : Entre 3 et 5 mois, nous parlerons de chasseur enfant . Le vampire est alors en pleine croissance, et commence chasser. Entre 5 et 10 mois, nous parlerons de chasseur dbutant . Le vampire a termin sa croissance, et amliore ses capacits de chasseur. Entre 10 mois et 2 ans, nous parlerons de jeune femelle . A cet ge, les mles ne sont plus pris en compte, le vampire est sevr, mais il na pas encore les comptences dun chasseur adulte. Plus de 2 ans, nous parlerons de femelle .

Figure 2.4 Diagramme de classe UML : diagramme dhritage des vampires

Vampire et VampireJeune sont des classes abstraites, qui permettent de spcifier des proprits

et mthodes communes. Nous retrouvons bien nos quatre catgories de vampires : ChasseurEnfant, ChasseurDebutant, JeuneFemelle et VampireFemelle. 23

Approchons maintenant de plus prs de la classe Vampire pour observer leurs proprits et mthodes.

Figure 2.5 La classe Vampire Un vampire a quatre proprits :

iIdentifiant: est lidentifiant unique du vampire, qui va permettre de suivre un individu. iAge : est lge du vampire iNbHeuresRestantes : est le nombre dheures de vie restantes au vampire avant quil ne

meure dinanition.
fTauxReussite : est son taux de russite la chasse.

Pour le nombre dheures restantes, nous avions galement la possibilit dutiliser le contenu stomacal du vampire (qui sexprimait alors en millilitres), mais dans ce cas, les quantits auraient diffr dun vampire lautre selon son ge. Tandis que cet indicateur a la mme smantique quelque soit lge du vampire. Intressons-nous ensuite ses mthodes :
getAgeMin() et getAgeMax() renseignent les bornes de la priode dexistence du vampire, et serviront surtout dterminer si un vampire change de catgorie dge. creer() va servir au renouvellement de lespce. Bien sr, cette fonction ne sera effective

que pour les vampires adultes. nest pas implmente pour linstant, elle vise reproduire graphiquement une chasse.
partirChasser() resultatChasse() correspond au tirage alatoire pondr par le taux de russite de chaque

vampire qui va dterminer si le vampire eu une chasse fructueuse ou non. 24

isMovable() va dterminer si le vampire est apte migrer vers une autre niche. On peut

noter que les vampires qui ne sont pas des femelles de plus de 10 mois rpondront toujours quils ne sont pas aptes. La dcision des femelles dpendra de la prsence dun petit duquer, et dun facteur alatoire qui est pass en paramtre de la fonction et dpend dun paramtre initial propre la simulation.
migrer() fait migrer le vampire dans un nouveau groupe dtermin alatoirement. chercherRegurgitateur() permet de trouver un vampire qui demander du sang. Cette

recherche se fait dans lordre qui suit : Le vampire cherche dabord les vampires envers qui il a une dette, ensuite ceux avec qui il a dj eu une relation, et enfin les autres femelles de sa niche. Le choix dun vampire dans lune de ces catgories se fait alatoirement.
connaitre() renseigne si on a dj eu affaire un vampire dans le cadre de rgurgitations. demanderSang()

correspond lmission dune requte destination dun donneur

potentiel.
traiterRequete() correspond au traitement dune requte provenant dun demandeur de

sang. Retourne la rponse la requte : acceptation ou refus.

donnerSang() et recevoirSang() ne font quincrmenter et dcrmenter le nombre dheures du donneur et du receveur. La prsence de ces fonctions vise aussi reproduire graphiquement ces actions. vieillir() correspond la dernire phase de la journe (voir 2.2 et figure 2.1). mourir() dplace le vampire de la colonie vers le cimetire (VampiresMorts, voir plus

bas).
recalculeTauxReussite() recalcule le taux de russite en fonction des paramtres du

modle et de son ge. La classe VampireFemelle possdera lattribut supplmentaire iNbJoursSansCreation qui renseignera sil est temps pour la femelle davoir une nouvelle progniture, ou sil est trop tt. Une femelle va galement possder une stratgie qui dfinira son comportement et sa prise de dcision lors des demandes de rgurgitation. Voici le diagramme :

Figure 2.6 Diagramme de classe UML : gestion des stratgies Les stratgies font partie des paramtres initiaux, on peut initialiser une simulation avec plusieurs stratgies et la mthode init() les attribuera alatoirement aux femelles, ou bien on 25

peut initialiser une simulation avec une stratgie unique, et par la suite ajouter une stratgie uniquement pour un ou plusieurs individus. Un objet Simulateur a donc au moins une stratgie de dfinie et chaque femelle en possde une. Une stratgie comporte la limite de dons faits sans que lautre vampire ne nous aide en retour, et une probabilit daccepter finalement lorsque toutes les conditions sont runies. 2.4.3. Gestion des relations

Nous allons maintenant nous intresser la manire dont sont entretenues les relations entre les vampires. Chaque relation contient une trace des vnements survenue entre les deux vampires. Il existe 4 vnements que lon reprsentera par des entiers, en voici les correspondances : 1. Le vampire a accept de donner. 2. Le vampire a refus de donner. 3. Lautre vampire de la relation a accept de donner du sang au vampire. 4. Le vampire a subit un chec lors de sa requte. Lvnement 0 sera la reprsentation dun non-vnement. Pour stocker cette trace, javais opt dans un premier temps pour un tableau ayant pour dimension la dure de la simulation, ainsi au i-me lment du tableau correspondait lvnement du i-me jour. Cette structure ntait pas du tout adapte, et jai pu le vrifier en me heurtant de multiples dpassements de capacit mmoire lors de simulation sur plusieurs annes. En effet, le nombre dvnements entre deux vampires reste assez rduit. Je me suis donc ensuite tourn vers une table de hachage, pour quil y ait autant dlments que dvnements. Lvnement du jour i reoit tout simplement la cl de hachage i, on a ainsi une association jour/vnement. Voici le diagramme qui illustre tout ceci :

Figure 2.7 Diagramme de classe UML : gestion des relations 26

On retrouve ici les caractristiques nonces plus haut. Un vampire peut accder lhistorique de ses relations. Depuis une relation, on peut atteindre son propritaire et lautre vampire concern. Les attributs bAppartientSsGroupe et bVivant renseignent si lautre vampire de la relation est dans le mme sous-groupe, et sil est toujours vivant. Voici ensuite quelques explications sur les mthodes :
majBAppartientSsGroupe() et majBVivant() permettent de mettre jour les attributs

correspondants lorsque cela est ncessaire.

dette() renvoie si le vampire a une dette envers lautre vampire de la relation. Cest--dire

si le dernier change venait de lautre vampire.

nbDonsGratuits(int index) renvoie le nombre de dons qua fait le vampire lautre sans quil laide en retour depuis le jour index.

nous renseigne sur le rsultat de la dernire requte fructueuse, cest--dire, quel est le dernier vampire a avoir aid lautre.
ResultatDernierRequete()

2.4.4.

Synthse

Au final on obtient le diagramme suivant pour ce qui est du modle de simulation dune colonie de vampire :

Figure 2.8 Diagramme de classe UML : le modle de simulation

2.5.

Reprsentation graphique des relations

Une des tches durant ce dbut de stage fut de concevoir une structure permettant de visualiser les relations entre les vampires, afin dobserver directement lensemble des changes ayant lieu 27

au sein de la colonie. Lide est de reprsenter les vampires dun mme sous-groupe sur un cercle, et de disposer ces mmes cercles nouveau sur un cercle. Lobjectif que je me suis ensuite fix tait que cette structure puisse sadapter dautres systmes de manire gnrique. Jai alors tabli les spcifications suivantes : Le graphe pourra contenir plusieurs niveaux dagrgation. Il pourra ainsi reprsenter une quelconque classification arborescente. Par la suite on notera A(CG) larbre associ au graphe circulaire CG. Par exemple : Soit trois groupes de vampires, avec deux groupes qui en contiennent 3 et le troisime qui en contient 4, on obtient le graphe CG suivant :

Figure 2.9 Exemple de graphe circulaire Et larbre A(CG) correspondant est :

10

Chaque nud du graphe pourra tre soit un nouveau graphe, soit une feuille, cest--dire un des objets issus de la classification. Un lien pourra ventuellement tre ajout entre deux objets. Mais ce lien ne pourra tre tabli 28

quentre deux nuds qui ont la mme profondeur dans larbre On disposera dune fonction qui permettra de rapprocher les objets qui sont le plus lis dans un mme graphe de manire clarifier la reprsentation graphique. Par exemple :

Avant

Aprs

Voici le diagramme de classe issu de ces spcifications :

Figure 2.10 Diagramme de classe UML : reprsentation graphique des relations La classe principale est CircularGraph, elle possde une liste de nuds qui ont comme contenu soit une nouvelle instance de CircularGraph, soit un objet qui implmente linterface GraphicNode, dans notre cas il sagit dun objet Vampire. Ce polymorphisme permet davoir 29

plusieurs niveaux dagrgation, comme souhait lors de nos spcifications. Un nud peut comporter plusieurs liens vers dautres nuds qui ont la mme profondeur dans larbre correspondant au graphe. Linterface GraphicNode contient les mthodes devant tre implmentes par les objets ajouter dans le graphe. Parmi ces mthodes, les plus importantes sont :
isLeaf() renseigne si lobjet est une feuille (le cas chant, il sagit dune instance de la classe CircularGraph). paintGraphicNode() permet de dessiner les objets contenus dans le graphe, ainsi lorsquun objet CircularGraph veut safficher, il appelle cette mthode pour tous les objets quil

contient.
containsPoint() nous indique si lobjet contient le point pass en paramtre. Cela servira

notamment pour savoir quel objet du graphe correspond un vnement souris. Notre classe Vampire implmente donc linterface GraphicNode et hrite galement de la classe Ellipse2D qui fait partie des classes fournies par le JDK, ce qui permettra de dessiner les vampires comme des cercles rouges (voir figure 2.9). Deux attributs lui ont galement t ajouts, taille dfinit le diamtre du cercle dessiner et drawIdentiant dfinit si lidentifiant du vampire doit tre affich ou non (les afficher surcharge parfois laffichage). Revenons maintenant sur la classe CircularGraph, dont voici le dtail de ses attributs et mthodes :
x, y, displayWidth, displayHeight dterminent le rectangle dans lequel doit tre dessin le

graphe lcran.
marge est lespace laiss sur le bord de la surface de dessin pour amliorer la lisibilit. Celle-

ci va varier lorsquon ajoutera des nouveaux niveaux de graphes.

angle est langle de rotation du graphe par rapport sa position originale (voir mthode rotate() plus bas). drawLinksDifferentGroup indique si lon doit dessiner les liens entre deux nuds qui

nont pas le mme pre (par exemple les nuds 1 et 4 dans la figure 2.9). sert activer/dsactiver loption antialias dans le dessin des composants graphiques qui est gr par la machine virtuelle (fourni par le JDK). Cette option amliore sensiblement laffichage en liminant le crnelage qui peut apparatre mais peut parfois ralentir les performances.
antialias addLink(gn1,gn2) permet dajouter un lien entre deux nuds. Cependant les deux nuds

doivent avoir la mme hauteur dans larbre correspondant au graphe. Et cette mthode doit tre appele sur le graphe racine, car la mthode va galement ajouter des liens (invisibles) entre les sous-graphes de mme niveau quelle aura du parcourir, cela servira lors de loptimisation du placement des nuds (voir mthode optimize() plus bas).
swap(index1,index2) permet tout simplement dchanger le placement de deux nuds,

bien sr ils doivent garder le mme pre donc cet change ne peut se faire quentre deux nuds qui ont le mme pre. 30

optimize() est la fonction qui va permettre de repositionner au mieux les nuds comme

voulu dans les spcifications. La mthode utilise est un algorithme que jai labor de manire empirique dont voici lnonc :
entre : cg une instance de la classe Circulargraph sortie : cg une instance de la classe Circulargraph optimise dbut pour chaque nud node du graphe faire si node nest pas une feuille alors node.optimize() fin pour pour chaque couple (nodei,nodej), nodeinodej, de cg.nodesList en prenant dabord les nuds qui ont le plus grand ordre (nombre de liens) faire // on calcule la somme des distances avec les nuds auxquels un // sommet est li, et on soustrait la somme des distances en //cas dchange des deux nuds. gain_i = 0 ; gain_j = 0 ; pour chaque liens de nodei avec linked_nodei faire

gain_i = gain_i + distance(node,linked_nodei) ; gain_j = gainj distance(node,linked_nodei) ; fin pour pour chaque liens de nodej avec linked_nodej faire

gain_j = gain_j + distance(node,linked_nodej) ; gain_i = gaini distance(node,linked_nodej) ; fin pour // analyse des rsultats si gain_i + gain_j > 0 alors si (gain_i>0 OU nodei nest pas marqu) ET (gain_j>0 OU nodej nest pas marqu) alors changer les deux sommets marquer les sommets qui ont un gain strictement positif fin si fin si

31

fin pour fin

getNodePath(GraphicNode gn) retourne un vecteur contenant le chemin complet de la racine jusquau nud gn. clear() permet de vider entirement le contenu du graphe. getDistance(index1,index2) retourne le nombre de pas quil y a entre deux nuds qui

sont sur un mme graphe. Deux nuds voisins auront une distance de 1, tandis que les nuds 4 et 6 de la figure 2.9 auront une distance de 2.
calculateCoordinates() recalcule toutes les coordonnes de tous les nuds en fonction

de ltat actuel du graphe.

rotate(int shift) permet dappliquer une rotation dangle shift sur le graphe. Cette

mthode est destine pouvoir modifier les angles de vue du graphe afin de le rendre plus clair.

32

3.

Lapplication
3.1. Prsentation gnrale
3.1.1. La fentre principale

Une fois le modle implment, il fallut concevoir linterface qui allait permettre de tester puis dexplorer le modle. Lapplication se prsente comme une fentre avec une barre de menu, un volet de visualisation avec deux onglets et des boutons pour un accs rapide aux fonctions importantes. Voici un aperu lors du lancement de lapplication :

Figure 3.1 Lapplication au dmarrage On remarque la barre de menu qui permettra de charger/sauvegarder ltat dune simulation, dactiver/dsactiver laffichage de la trace des actions effectues (correction de bugs), et de paramtrer les options daffichage du graphe circulaire. Nous retrouvons les deux onglets, le premier permettant de voir les principales caractristiques de la colonie et daccder aux informations de chaque vampire en utilisant larbre qui est situ sur la gauche (qui est vide pour 33

linstant), le second lui contient le graphe circulaire permettant de voir les changes faits entre vampires. En dessous se trouve une range de boutons qui permettra de dclencher les tapes dune journe une une. Et encore en dessous, deux groupes de boutons, le premier permet de dclencher la simulation sur plusieurs jours, et le second permet de modifier/sauvegarder ltat de la simulation. Pour linstant, aucune initialisation na t faite, donc aucune information nest encore affiche. Les seules actions possibles sont douvrir un fichier, ou dditer les paramtres de la simulation afin dinitialiser une colonie de vampires.

3.1.2.

Initialisation des paramtres

Il existe deux moyens pour initialiser les paramtres de la simulation : A partir dun fichier, que nous choisissons laide dune bote de dialogue (figure 3.2), laquelle nous accdons par le menu FileOpen ou en cliquant sur le bouton Open . La bote de dialogue permet de visualiser un rsum du contenu du fichier slectionn, car il nest pas forcment vident de nommer un fichier de manire loquente.

Figure 3.2 Chargement dun fichier Cette visualisation permet aussi de voir si un fichier nest pas compatible (conflits de version, extension partage par une autre application) comme illustr sur la figure 3.3.

34

Figure 3.3 gestion des fichiers non compatibles En ajustant tous les paramtres laide de la bote de dialogue de la figure 3.4 qui est accessible par le bouton Editer .

Figure 3.4 Edition des paramtres de la simulation La case Stratgies va permettre dajouter/diter/supprimer la liste des stratgies. Il est bien sr possible dinitialiser une premire fois le modle, et ensuite de retoucher quelques 35

paramtres. 3.1.3. Dclenchement de la simulation

Il se rsume aux boutons dj cits auparavant.

Figure 3.5 Le stepper Le stepper (pas pas) permet de dclencher une une les tapes dune journe afin dobserver avec prcision les effets de ces diffrents vnements.

Figure 3.6 Les dclencheurs Ces trois boutons vont permettre de simuler une colonie sur 1 jour, 10 jours ou la dure prdfinie lors de lajustage des paramtres.

3.2.

Durant la simulation

Une fois la simulation initialise, il existe de nombreux indicateurs de ltat du modle qui permettent dobserver son volution.

3.2.1.

Indicateurs globaux

Ils sont regroups dans la case Infos sur ltat de la colonie de vampires (figure 3.7) du premier volet (figure 3.1) et renseignent sur ltat global de la colonie et sur le nombre dvnements survenus.

Figure 3.7 Les indicateurs globaux 36

3.2.2.

Indicateurs et modificateurs des individus

Toujours sur le premier volet, larbre situ gauche permet de voir la rpartition des vampires par catgories dge et par groupe (figure 3.8), dajouter/supprimer un vampire ou den diter les proprits. Les vampires sont reprsents par leur identifiant. Chaque groupe est affich avec sa taille entre parenthse, ce qui permet de voir rapidement la rpartition des vampires dans la colonie. Les boutons situs juste au-dessous permettent donc de manipuler les vampires. Grce au premier nous allons pouvoir ajouter un nouveau vampire en spcifiant son ge et ses caractristiques (voir figure 3.9), ces mme caractristiques vont pouvoir tre modifier laide du deuxime bouton (voir figure 3.10). Quant au troisime, il permet tout simplement de supprimer le vampire slectionn. Le fait de pouvoir diter les proprits dun vampire est important, car, de cette manire, nous allons pouvoir introduire facilement des cas limites dans le modle pour susciter des phnomnes plutt difficiles obtenir. Nous pourrons ainsi affiner la population de vampires qui a t gnre de manire uniforme lors de linitialisation. Dans les proprits dun vampire, nous allons retrouver la liste de ses relations (figure 3.10), et de la mme manire, que nous avons pu modifier les vampires, nous allons pouvoir modifier ces relations (figure 3.11). Une relation est reprsente par lidentifiant de lautre vampire, et ses vnements par le couple [jour de lvnement] [type de lvnement], la smantique des types tant indique dans la bote de dialogue correspondante (figure 3.11).

Figure 3.8 Vue arborescente de la colonie

37

Figure 3.9 Ajout dun nouveau vampire

Figure 3.10 Edition dun vampire

Figure 3.11 Edition dune relation

38

3.2.3.

Visualisation graphique

A laide de la structure dveloppe au chapitre VIII.2.4, il est possible de visualiser directement la prsence de dialogues entre les diffrents vampires. Ces derniers peuvent rapidement apparatre en grand nombre, lalgorithme prcdemment expos permet alors damliorer la lisibilit du graphe. Il est galement possible dappliquer une rotation sur chacun de graphes laide de la souris, sur la figure 3.12 une rotation est applique sur le niveau du graphe reprsentant la colonie (la racine), et sur les figures 3.13 une rotation est effectue uniquement sur un sous-groupe. Loption Enable mouse zoom permet dactiver/dsactiver la fonction de zoom qui consiste pouvoir largir ou rtrcir le graphe laide de la souris. Ces possibilits de pouvoir dformer le graphe ont pour but daugmenter encore la lisibilit, en y ajoutant cette foisci une interactivit, en effet il est plus facile de percevoir un objet si lon peut le manipuler.

Figure 3.12 Rotation au niveau de la racine du graphe

Figure 3.13 Rotation dun sous-groupe

39

IX. Conclusion
1. Bilan
Le stage nest pas termin, compte tenu quil reste deux mois pour le raliser. Lensemble des objectifs prvus dans le planning a t atteint. Les principales difficults rencontres durant ce stage ont t : Lapprentissage de techniques de simulation multi-agents que je ne connaissais pas jusqualors. Le fait de mener ce projet seul. Nanmoins, le fait dtre seul a t particulirement enrichissant, car cela ma permis de couvrir tous les problmes pouvant apparatre durant un projet de cette envergure. La gestion dun aussi grand nombre de classes (la version actuelle de lapplication comptabilise 42 classes et un peu plus de 6000 lignes de code).

La dcouverte de la technique de simulation par systmes multi-agents qui est une technique largement utilise dans la modlisation de systmes complexes, a t un point fort de mon stage.

2.

Perspectives
2.1. Exploration du modle

Le modle tant exploitable, il reste maintenant lexplorer la recherche de paramtres adquats pour la colonie. Ces paramtres devront permettre des conditions de jeux idales pour lexposition, savoir que les demandes de rgurgitation doivent apparatre rgulirement et que la stratgie donnant-donnant reste la meilleure stratgie pour la survie de la colonie.

2.2.

Ralisation du jeu

Un rendez-vous est prvu le 8 Juillet avec nos correspondants au Musum dHistoire Naturelle, afin de se mettre daccord sur le scnario et le droulement du jeu. Durant ce rendez-vous, nous laborerons galement les spcifications du contenu, et plus prcisment des graphismes qui ne seront pas totalement livrs cette date. De cette manire, je pourrais dvelopper le jeu sur la base de ces spcifications, et prvoir des outils permettant de modifier tous les lments graphiques du jeu, ainsi que les textes.

40

X. Rfrences bibliographiques
Axelrod R. (1984) The Evolution of Cooperation. Basic Books, New York. Bousquet F. (1994) Des milieux, des poissons, des hommes : tude par simulations multi-agents. Editions de lORSTOM, Paris. Campos A. (2000) Une architecture logicielle pour le dveloppement de simulations visuelles et interactives individu-centres : application la simulation dcosystmes et la simulation sur le Web. Thse de doctorat, Universit Blaise Pascal Clermont-Ferrand II, 8 Septembre 2000. Delahaye J.P. (1992) Laltruisme recompos ?. Pour la science, n 181. Ferber J. (1995) Les systmes multi-agents. Vers une intelligence collective. InterEditions, Paris. Von Newman J. et O. Morgenstern (1947) Theory of games and economic behavior. Princeton University Press, Princeton. Wilkinson G. (1990) Food Sharing in Vampire Bats. Univ. Press, Baltimore and London.

41