Intégration de Vector-DEVS dans le cadriciel

Plusieurs problèmes se posent du point de vue logiciel et en particulier, dans la méthodologie : la connaissance de tout l’espace dans lequel évolue un phénomène est contenue dans l’exécutif du gestionnaire de forme. Pratiquement cela induit des duplications de données géographiques en mémoire dans le cas où plusieurs formes évoluent dans un même espace. Cela impose aussi des procédures lourdes à implémenter de recherches spatiales et d’entrée sortie de données géogra-phiques, pour un objet : l’exécutif n’a pas cette vocation. Pour éviter ces problèmes les contraintes spatiales sont gérées par le gestionnaire spatial dans l’environnement.

Dans le cas de Vector DEVS, le Gestionnaire spatial est lié à chaque gestionnaire de formes et possède la connaissance de la totalité de l’espace sur lequel se déroule la simulation. Pratique-ment, il offre à l’exécutif du gestionnaire de forme un conteneur pour tous les états concernant l’environnement ainsi qu’un ensemble de méthodes pour manipuler ces informations.

Le gestionnaire spatial est une entité ayant la connaissance de la totalité des propriétés spatiales du cadre de la simulation. Il fournit aux modèles les informations permettant de mettre à jour leurs propriétés spatiales. Pour cela il doit travailler sur les types de représentation de l’espace matri-ciel et vectoriel, et fournir des translations éventuelles entre ces différents types de représentation (rasterisation et vectorisation).

Le gestionnaire spatial agit comme un proxy du SIG. La totalité de l’espace dans lequel se déroule la simulation est chargé au début de la simulation. Pendant la simulation les sorties ayant des répercussions sur cet espace sont stockés sous forme d’événements par le gestionnaire spatial. Ces données sont ensuite renvoyées au SIG à la fin de la simulation.

L’intégration de vector-DEVS dans le cadriciel est faite grâce au package vector-DEVS pré-senté en figure 4.19. Ce package contient les classes spécifiques aux techniques de modélisation par propagation d’interfaces où chaque agent est un modèle atomique. Dans l’interface graphique

CHAPITRE 4 4.4. MODÉLISATION DE PROPAGATION D’INTERFACE vector-DEVS moteur_DEVS cadres_expérimentaux stockage interface_graphique Access Parser Noeud-Agent Noeud-Domaine-Vectoriel Noeud_Executif Gestionnaire-Forme Executif-Forme Agent Composant-Agent Editeur-Agent Panel-Gestionnaire-Forme Composant-Modèle-Vectoriel Panel-Agent Composant-Controle Composant-Domaine-Vectoriel modeling Composant_Domaine Composant_Controle Parser_De_Domaine Noeud_Domaine Composant_Domaine Panel_Modèle_Atomique Panel_Modèle_Composition Composant-Executif Editeur-Executif Composant_Modèle_Atomique DSDEVS_Network DSDEVS_Executive AtomicModel FIG. 4.19: Le package Vector-DEVS

CHAPITRE 4 4.5. CONCLUSION

senté par un objet Composant-Modèle-Vectoriel contenant les agents de type Composant-Agent possédant un éditeur de code pour l’objet de type Agent, héritant de AtomicModel et définissant son comportement. Chaque objet Composant-Modèle-Vectoriel est aussi associé à un objet de type Composant-Executif et son éditeur, pour modifier le code de l’objet Executif-Forme asso-cié, qui est chargé de la dynamique du modèle.

Les objets Agent, Executif-Forme et Gestionnaire-Forme peuvent être simulés par de objets

Simulatoret DSDEVS-Coordinator standard et ne nécessitent donc pas la création spécifique de

classes à cet effet. Les modèles vector-DEVS sont stockés par des objets de type

Noeud-Domaine-Vectoriel, Noeud-Executif et Noeud-Agent et accédés grâce à un objet Parser spécifique héritant

de Parser-De-Domaine. Comme pour le package raster-DEVS, le Parser est spécifique car il doit réaliser le chargement d’un Composant-Domaine-Vectoriel qui affiche les états des objets Agent à l’intérieur du cadre expérimental sans pour autant charger un composant par objet Cell comme cela aurait été le cas avec un parser de modèle diagramme.

4.5 Conclusion

Ce chapitre a présenté les différents ajouts réalisés au cadriciel pour permettre l’intégration de différentes techniques de modélisation et de simulation. Il existe une grande quantité de pa-radigmes de modélisation, chacun étant adapté à un problème donné. A chaque paradigme est associé une technique de modélisation et de simulation. Ainsi, plus un modélisateur a de technique à disposition, plus il aura de solutions à ses problèmes. Nous avons voulu dans cette perspective, ajouter trois techniques adéquates au cadriciel afin de traiter des problèmes environnementaux.

La première, feedback-DEVS, est utile à la spécification de modèles adaptatifs, auto-apprenants, autorisant la construction de modèles empiriques. L’intégration de cette technique a été facilitée par sa similarité avec la technique DEVS classique déjà présente dans le cadriciel.

La seconde technique basée sur les automates cellulaires, est la méthode la plus fréquemment utilisée pour l’étude de systèmes ayant des dimensions spatiales. Pour rendre cette technique

dis-CHAPITRE 4 4.5. CONCLUSION

ponible, nous avons du ajouter des modes de représentation de l’espace à notre outils et développer les cadres expérimentaux et les interfaces vers des outils d’analyse spatiales (SIG).

Enfin, la troisième technique ajoutée, Vector-DEVS est une approche originale adaptée des méthodes mathématiques de "front tracking" [Glimm et al., 1996] permettant l’étude de la pro-pagation d’un phénomène par la simulation de la dynamique de son interface physique. Pour intégrer cette approche nous avons cherché à appliquer le formalisme DSDEVS [Barros, 1997] pour qu’il prenne en compte la gestion de l’espace. Ce formalisme a été choisi car il autorise la définition de modèles à structure dynamique. Les coté spatial a été introduit par la défini-tion des concepts d’agent géographique (modèle atomique géo-référencé) et de gesdéfini-tionnaire de

forme(réseau DSDEVS intégrant une dynamique structurelle et spatiale). La spécification formelle Vector-DEVS a été présentée et son ajout dans le cadriciel effectué d’un point de conception orien-tée objet. L’intégration logicielle de cette technique est en cours de réalisation et constitue une des principales perspectives de recherches.

Pour chacune des trois techniques ajoutées, nous avons précisé les classes et packages obtenus à l’issue de leur intégration.

CHAPITRE 5

Implémentation

J

modé-lisation présentées dans le chapitre 4. La première concerne la validation des choix d’architecture logicielle, certains problèmes ne devenant apparents que lors de l’implémentation de l’outil. Ainsi, l’expérience de ce développement nous a conduit d’abord à redéfinir l’architecture de classes du cadriciel afin qu’il puisse mieux correspondre aux attentes des utilisateurs. Nous avons ensuite pu-blié le logiciel sur plusieurs sites web afin de faire valider les choix logiciels par la communauté la plus large possible. Le deuxième objectif poursuivi lors de ce développement à été de satisfaire le besoin d’un outil de modélisation convivial dans notre laboratoire. JDEVS est largement utilisé dans plusieurs projets de recherche ; trois des modèles développés sont d’ailleurs présentés dans le chapitre 6.

Ce chapitre est décomposé en quatre sections, la première présente les différents modules de JDEVS. Les techniques de modélisation et de simulation intégrées dans le logiciel sont ensuite détaillées dans les trois dernières sections.