retour aux mémos     retour au modèle     back to SimMasto home page   retour à la page d'accueil

Relations entre agents et espace, l'interface ground_manager


Quelques remarques sur les contraintes de généricité

  1. Pour conserver une certaine généricité, nous allons  faire en sorte que les agents ne connaissent pas la nature de leur support. Nous allons donner aux agents une référence sur un objet « ground_manager » qui s'occupera de toutes les requêtes de l'agent concernant son environnement. L'agent ne doit pas avoir « conscience » des éléments de programmation qui l'entoure, il possède juste une référence sur les actions possibles. Le ground Manager est chargé d'appliquer ces actions.
  2. Pour pouvoir utiliser différents types d'agents  (exemple : loup, mouton) en réutilisant certaines méthodes (exemple : se déplacer). On utilise généralement l'héritage, mais un problème apparaît avec la gestion de Repast Simphony. En effet en mode de représentation GIS, tous les agents du même type  doivent posséder le même type de géométrie. Cette contrainte s'applique même sur les classes héritées. On ne pourra pas donc pas utiliser des méthodes d'héritage pour créer des agents de type différent. Puisqu'il n'est pas possible d'utiliser l'héritage, on va donc utiliser une interface « Agent » qui va servir de marqueur.

G        On peut utiliser le nom d'une interface comme type de variable, ce qui signifie que l'on accepte en paramètre toutes les classes qui implémentent cette interface. Ainsi, on pourra utiliser des méthodes d'interactions des agents avec d'autres agents ou des agents avec le terrain sans tenir compte du nom de la classe (il suffit que celle ci implémente l'interface « agent »). On  peut créer autant de classe  représentant un type particulier d'agent que nécessaire, ce seront toujours des « Agents ».

  1. De la même façon, pour pouvoir traiter différents supports, nous allons donner aux agents, dans une procédure d'initialisation, une référence sur un objet dont la classe implémente l'interface « Ground_Manager ». Les agents pourront appeler les méthodes définies dans l'interface Ground_Manager sans connaître la classe de l'objet appelé (et donc la nature du support).

Diagramme de classe représentant la structure des éléments de la simulation

Définition de l'interface Ground_Manager.

§         Avant de commencer à programmer le comportement des agents et les méthodes correspondantes dans leur gestionnaire de terrain, il faut définir quels sont les rôles que doivent remplir  les agents et le gestionnaire de terrain.

§         Les agents sont les éléments les plus sujets à des modifications, on va essentiellement définir les interactions de base permettant aux agents de connaître leur environnement et de pouvoir interagir avec. Une fois que l'on aura défini ces fonctions de base, on pourra les utiliser pour créer des interactions plus complexes.

§         La création d'un agent dans la simulation ne peut pas se faire sans savoir sur quel type de support on le place, la fonction de placement des agents doit donc être prise en charge par le gestionnaire de terrain (le gestionnaire de simulation - ContextCreator - gère normalement la création)

§         Un agent doit pouvoir connaître son emplacement. Comme ses coordonnées vont dépendre de la nature du terrain, il faut que ce soit le Ground_Manager qui soit capable de renvoyer les coordonnées d'un objet donné.

§         Un agent doit pouvoir se déplacer. Or, là aussi le déplacement va dépendre du support. L'agent va donc demander au Ground_Manager de le déplacer (selon une distance choisie par l'agent en mètre). C'est au Ground_Manager de s'adapter et d'effectuer les tests et les conversions nécessaires pour adapter le déplacement de l'agent dans le terrain.

§         Un agent possède une certaine représentation de son environnement, puisque le terme de distance dépend également du terrain, le gestionnaire de terrain doit pouvoir renvoyer à l'agent tous les objets qui lui sont visibles selon un champ de vision donné (spécifié par l'agent en mètres).

§         Pour finir, puisqu'un agent peut se déplacer à l'intérieur des terrains, il faut que le gestionnaire de terrain puisse lui envoyer non pas les coordonnées du terrain où veut se rendre l'agent, mais un point à l'intérieur du terrain.

Si on récapitule les quelques informations ci dessus, on peut réaliser l'interface Ground_Manager :

Public interface Ground_Manager
{
     
/**
       
* @param o an object contained in the projection
       
* @return the coordinate of the object in the projection
       
*/
     
public Coordinate give_object_coordinate(Object o);
     
/**
       
* @param fa a reference to an instance of field agent
       
* @return a point within the area of the field agent
       
*/
     
public Coordinate get_internal_point(Field_Agent fa);
     
/**
       
* @param a : the object to move
       
* @param c : the destination coordinate
       
*/
     
public void move_Object(Agent a,Coordinate c);
     
/**
       
* @param a : the agent which is looking around him
       
* @param radius the field of view
 *
@return an array list of the object which are in the field of view of the agent
       
*/
     
public ArrayList<Object> find_object(Agent a, double radius);
     
/**
       
* @param context :the context where the current projection is
       
* @param nb_agent : the number of agents to add in the projection
       
*/
     
     
public void add_agents(Context context,int nb_agent);
}

 


Mémo 17 - Auteur J.Le Fur/Q.Baduel, adaptation  22.01.13 par jlefur

retour aux mémos     retour au modèle     back to SimMasto home page   retour à la page d'accueil