Jedi

Jedi est une plate-forme agent dont l’ambition est de mettre au coeur du processus de mod´elisation, non pas l’architecture de l’agent comme dans les approches classiques, mais les interactions entre agents et entre les agent et leur environnement. Les auteurs [Kubera et al., 2008] arguent que cette approche permet, tout en gardant l’autonomie des agents, une plus grande r´e-utilisation des composants d´evelopp´es et la s´eparation des connaissances sur les comportements de leur mise en oeuvre informatiquement.

Jedi est d´evelopp´e en JAVA et propose ainsi tous les concepts de la programmation orient´ee objet. Cette plate-forme est construite en respectant la m´_{ethodologie Ioda [Ma-} thieu et al., 2007] [Mathieu et al., 2001]. Les interactions sont d´efinies en distinguant les agents initiateurs de l’interaction des agents impliqu´es dans l’interaction.

Les auteurs d´efinissent un processus sp´ecifique de conception d’une simulation qui se d´ecrit en cinq ´etapes. La premi`ere ´etape consiste `a ´elaborer l’ensemble des familles d’agents. Une famille d’agents est une repr´esentation abstraite d’un ensemble d’agents en fonction de propri´et´es communes. La deuxi`eme ´etape d´etermine les primitives permettant de d´efinir les conditions d’activation des agents et pour ces activations les s´equences d’ac- tions. Les conditions d’activation s’expriment sous la forme d’une fonction qui identifie, pour une interaction donn´ee et un agent cible, un ensemble d’agents qui subiront l’in-

1.5. Plates-formes de simulation multi-agents

teraction. Cette fonction rend alors l’agent op´erationnel pour qu’il ex´ecute l’interaction propos´ee. La troisi`eme ´etape sp´ecifie les actions et primitives de perception des familles d’agents. Cette ´etape pr´ecise la mani`ere dont les primitives sont impl´ement´ees pour chaque famille d’agents. L’´etape suivante hi´erarchise les interactions en allouant une priorit´e `a chacune des interactions et une distance limite. En effet, les agents ne peuvent pas `a chaque pas de temps ex´ecuter plusieurs actions. Sachant que potentiellement `a un instant donn´e le contexte local `a un agent permettra de d´eclencher plusieurs interactions il faut les organiser pour que l’agent n’en choisisse qu’une. Les priorit´es allou´ees aux interactions permettent de construire cette hi´erarchie entre les diff´erentes interactions. Les auteurs distinguent le champ de perception qui permet de percevoir le contexte local `a l’agent de la notion de distance limite qui est la distance maximale autoris´ee par une interaction pour permettre `a un agent cible d’interagir avec ses voisins (ou environnement). La der- ni`ere ´etape d´efinit la dynamique de la matrice des interactions en sp´ecifiant les r`egles de modification et d’acc`es `a la matrice.

A l’instar de MadKit (section 1.5.4), la plate-forme Jedi consid`ere tous les compo- santes comme des agents pour unifier le traitement de ces composants. Le temps de la simulation est discr´etis´e et les agents sont situ´es dans un environnement spatial `a deux dimensions qui est repr´esent´e par une matrice de cellules, appel´e “grid”. Un agent est alors actif pour un pas de simulation s’il peut r´ealiser au moins une interaction.

Une classe Interaction r´eifie les interactions des agents. Chaque comportement des agents sp´ecialisera la classe Interaction en d´efinissant trois m´ethodes abstraites : d´eclen- cheurs, preconditions et actions. La m´ethode d´eclencheurs, qui prend en param`etre l’agent source et la liste des agents cible, permet de d´efinir les conditions d’activation de l’inter- action li´ees aux motivations de l’agent. La m´ethode preconditions qui prend en param`etre l’agent source et la liste des agents cible, d´efinit les conditions logiques d’activation de l’in- teraction permettant la r´ealisation effective de l’action. Et la m´ethode actions qui prend en param`etre l’agent source et la liste des agents cible, qui est ex´ecut´ee si les deux tests r´eussissent, effectuera tous les traitements n´ecessaires `a cette interaction.

Une classe AgentFamily qui est une sp´ecialisation de la classe Agent d´efinit le lien entre les interactions et les agents impliqu´es par cette interaction (correspond `a une ligne de la matrice des interactions). La matrice des interactions constitue une repr´esentation symbolique du comportement des agents. Il faut au pr´ealable d´efinir les classes d’inter- action, puis les classes d’agents pour ensuite li´e les interactions aux agents. La gestion de l’ex´ecution de la simulation est r´ealis´ee par une classe fille sp´ecialisation de la classe Moteur. Plus pr´ecis´ement, la m´ethode run de cette classe est en charge de l’ex´ecution de

l’algorithme principal illustr´e en figure 1.25.

Let A be the set of agents in the environment and Aact ⊆ A the set of

active agents

1. Reorder Aact according to a particular criterion

2. Set all agents in A operative

3. For each operative agent a∈ Aact do :

– Define the part of the environment H(a) perceived by a ; – Define the set of all neighboring agents N (a), and remove from

it all non-operative agents ;

– Let p = maximal priority in canPerform(a) ;

– Compute Pp(a) ; while Pp(a) = ∅, decrement p and compute

again ;

– If p = 0 and P0(a) =∅, then a cannot perform any interaction.

It remains operative but ends its simulation step ;

– Else, select an element fromPp(a), i.e. elements ((I, p, c, d), Targ)

containing an assignation element and a set of target agents, using the interaction selection process of the agent

– Perform the interaction I with a as source and Targ as targets ;

– Deactivate a and all agents in Targ

Fig. 1.25 – Algorithme principal d’ex´ecution de Jedi

Chaque agent dispose d’une “boˆıte noire” qui est le moteur de comportements dont une description est fournit dans [Devigne, 2007]. Ce dernier dispose de capteurs et d’effecteurs qui lui permet d’interagir avec l’ext´erieur. Le moteur de comportements est en charge du processus d´ecisionnel du choix du comportement `a adopter en fonction du but `a atteindre.

Cette approche de la simulation est proche de la notre car nous pla¸cons au centre de la mod´elisation et de la r´ealisation du mod`ele les interactions et le traitement des inter- actions au lieu de se focaliser sur les agents ce qui permet de s’extraire des diff´erentes notions associ´es `a la d´efinition des agents et de leur architecture interne. Mais les inter- actions sont conditionn´ees par le contexte local `a l’agent et l’´evaluation du contexte de l’agent est `a la charge de l’agent et se fait `a l’aide de requˆete entre l’agent et son envi- ronnement pour le mod`_{ele IODA. Par cons´equent, le processus interactionnel n’est pas} compl`etement ind´ependant de l’architecture de l’agent et la mod´elisation de l’agent se confond encore avec son ex´ecution. Notre objectif est de r´eifier le lien entre le contexte et l’interaction pour s´eparer distinctement la partie proc´edurale d’un agent (ex´ecution) de sa partie d´eclarative (mod´elisation), et pour rendre la simulation plus flexible en pouvant modifier dynamiquement ce lien.