retour aux mémos
retour au modèle
retour à la page d'accueilLa logique de programmation pour la simulation consiste à :
Isoler le gestionnaire de configuration de simulation dans une classe (définir le contexte),
Identifier et construire le type de projection spatiale
Isoler le gestionnaire de terrain dans une autre classe (et interface)
L'élément le plus abstrait et le plus basique est le contexte (dans Repast « context ») dans lequel les agents vont évoluer.
G Le contexte est immatériel mais englobe l'ensemble de la simulation. C'est l'infrastructure minimum permettant de stocker des agents sans ajouter de notion d'espace ou de relation.
G Un contexte peut posséder des attributs représentant les « lois » qui régissent les agents et l'environnement. On peut voir l'écoulement du temps, la gravité et les lois de la physique en général comme des éléments de notre contexte.
G De plus un contexte peut contenir des sous contextes, en effet l'application des lois change selon le lieu.
G De manière générale, tous les éléments du modèle vont appartenir au contexte principal ou à ses sous contextes.
G Un seul attribut nous intéresse et par défaut n'est pas renseigné, ils s'agit de la ligne « class name » qui correspond à la classe java où le simulateur va aller chercher le contexte. On va l'appeler « ContextCreator » qui est assez explicite.
Remarque: A cet endroit il y a deux façons de procéder, soit on repère une classe qui va créer le contexte (cette classe doit implémenter l'interface « ContextBuilder ») soit on repère une classe qui représente le contexte lui même (cette classe doit étendre la superclasse « DefaultContext »).
G Éclipse ouvre alors une fenêtre pour la création de votre classe, vous devez recopier à la lettre près le nom que vous avez mise pour le class name du contexte dans le fichier model.score.
Une fois la classe créée vous devez préciser qu'elle doit implémenter l'interface « ContextBuilder ».
package tuto;
import repast.simphony.context.Context;
import repast.simphony.dataLoader.ContextBuilder;
public class ContextBuilder implements ContextBuilder
{
@Override
public Context build(Context context)
{
return context;
}
}
Par défaut, cette fonction renvoi null, nous allons modifier le contexte passé en paramètre et l'utiliser comme paramètre de sortie.
Nous allons y ajouter une projection de type géographie qui servira de modèle pour la simulation.
Une fois le contexte défini, il faut définir une zone réelle dans laquelle les agents pourront évoluer. On appelle ces zones des projections. Ce sont des supports permettant aux agents de se déplacer et d'interagir entre eux ou avec leur environnement. Toujours en ramenant ce concept à notre réalité, nous pouvons dire que nous évoluons sur un plan continu en forme de sphère ( le globe terrestre).
Dans Repast Simphony, il existe quatre types de projections différentes :
Il s'agit de plans où la position des agents est représentée par des coordonnées réelles (décimales). On peut choisir le nombre de dimensions dans lequel les agents évoluent ( 1D, 2D , 3D ou ND). Il est peu probable que les positions de deux agents se superposent exactement, mais on peut les faire interagir entre eux selon la distance qui les sépare.
Leur fonctionnement est semblable à celui des espaces continus. On peut choisir le nombre de dimensions de la grille, qui va en fait correspondre aux dimensions d'une matrice de cases indexées par des coordonnées entières. L'utilisation des grilles est plus simple que celle des espaces continus, notamment en ce qui concerne les déplacements et les interactions entre agents (il peuvent interagir lorsqu'il arrivent sur la même case par exemple)
Ce mode de représentation est plus compliqué à utiliser que les deux précédents mais il permet une gestion de l'affichage des SIG. Dans cet espace, tous les éléments sont représentés par une géométrie (dans Repast « geometry », voir glossaire, p.Erreur ! Signet non défini.) particulière. Les éléments du même type doivent apparaître avec la même géométrie.
Pour illustrer cette représentation, nous pouvons prendre pour exemple un SIG simple sur lequel évolue un type d'agent. La construction se fera comme si il y avait deux couches, celle regroupant les éléments terrains (qui auront une géométrie de type polygone) et celle regroupant les agents d'un même type (que l'on prendra la plupart du temps de type point).
G Remarque : La gestion des géométries à été reprise de la librairie de JTS Topology Suite. Plus d'informations et de documentations sont disponibles à l'adresse http://www.vividsolutions.com/JTS/JTSHome.htm.
Note : Un quatrième type n’a pas été traité ici, il s’agit des graphes ou réseaux.
La manipulation des agents et leurs interactions avec leur environnement ne se fait pas de la même façon selon le support sur lequel ils évoluent mais les rôles attendus sont les mêmes. Ainsi, le terrain doit pouvoir remplir les services suivants :
Dans la suite de cette chaîne de traitement, nous allons essayer de conserver un maximum de généricité en déclarant une interface « Ground_Manager » qui contiendra les méthodes abstraites permettant de remplir les rôles que l'on attend du terrain. Cette astuce permet de faire en sorte que les agents puissent faire des requêtes sur le terrain sans connaître la nature de celui ci. Pour changer le support de la simulation il suffira donc d'envoyer aux agents une référence sur un gestionnaire de terrain particulier.
Lors de la simulation, l'agent pourra demander au terrain :
§ «Quelle est ma position (quelles sont mes coordonnées) ? »
§ «Je veux me déplacer de x mètres dans la direction y »
§ «Quels objets puis-je percevoir depuis ma position ? ».
Les agents devront donc posséder des caractéristiques indépendantes du terrain (par exemple un déplacement en mètre par heure et un champ de vision exprimé en mètres). Le gestionnaire de terrain s'occupe ensuite des conversions nécessaires pour le traitement.
1. Dans un espace continu, les coordonnées des agents sont exprimées par une suite de nombres décimaux. Il faut donc :
§ rajouter des tests pour savoir à quelle distance sont les agents les uns des autres,
§ effectuer des parcours pour tester la présence des agents dans une zone de l'espace continu...
De plus si l'on veut faire correspondre des données terrain, il faut définir chaque zone. Dans ce cas, il est donc plus simple d'utiliser une grille.
2. Dans le cas d'une grille :
§ on se repère grâce aux cases et aux éléments qu'elles contiennent.
§ Les coordonnées sont donc exprimées par des valeurs entières délimitées par les dimensions de la grille.
§ Les agents doivent avoir un déplacement en cases et chaque case doit représenter un certain nombre de mètres (ou d’une autre unité).
§ De plus leur vitesse doit correspondre au terrain, ce qui peut se révéler délicat car les déplacements en cases évoluent si l'on augmente ou diminue la vitesse des agents en mètres et si l'on modifie l'intervalle de temps représenté par un tic.
Dans la situation 1, si le déplacement de l'agent en mètres est trop faible, l'agent ne bougera pas d'une case car son déplacement est inférieur à la taille d’une case. Donc ses coordonnées ne vont pas évoluer (les coordonnées sont entières, un déplacement inférieur à 1 sera ignoré).
Dans la situation 2 : l'agent a un déplacement qui correspond à deux cases, L'agent B ne pourra jamais atteindre son objectif au point C, il oscillera donc indéfiniment.
3. Dans le cas d'une projection de type Géographie, le traitement est moins intuitif, la gestion se fait principalement par traitement géométrique.
§ Tous les agents sont associés à des géométries. Il n'est pas possible de les déplacer directement. Il faut déplacer leur géométrie.
§ Si l'agent est un point, on peut récupérer ses coordonnées, si il représente un polygone terrain, on peut récupérer son centroïde (c'est à dire un point situé aux coordonnées moyennes de tous les points) ou un point à l'intérieur du polygone, ce qui est plus réaliste dans certains cas.
§ Pour tester leur interaction, on peut rechercher le terrain qui possède une géométrie associée en intersection avec la géométrie d'un agent.
§ Pour tester les élément vus par un agent, on créé un polygone en forme de rond autour de l'agent et on récupère la liste des objets dont la géométrie associée est en intersection avec ce rond.
G Par défaut, Repast Simphony ne permet pas d'utiliser directement des fichiers .shp comme support, mais il est possible d'utiliser les API de Geotools (intégrées à Repast Simphony) pour pouvoir intégrer rapidement le SIG que nous avons récupéré. Une aide détaillée sur l'utilisation de Geotools et de la gestion des SIG est disponible à l'adresse http://docs.codehaus.org/display/GEOTDOC/Home
Il est possible d'utiliser dans une même simulation plusieurs projections différentes et de différents types (espace continu, grille ou géographie). Cependant, l'interface graphique impose des restrictions et créer plusieurs configurations est soumis aux règles suivantes :
Les différentes projections ont toutes leurs avantages et inconvénients. Pour représenter des agents se déplaçant sur différents types de terrains, deux solutions sont envisageables :
retour aux mémos
retour au modèle
retour à la page d'accueil