• Aucun résultat trouvé

4.2.3 Intégration de Feedback-DEVS dans le cadriciel

La figure 4.4 présente le package feedback-DEVS contenant les classes spécifiques à cette technique. Comme les liens vers les composants spécifiques sont donnés par une instance de la classe feedback-DEVS.Access, il n’est pas nécessaire de modifier les classes des packages du cadriciel. Nous avons vu que les modèles Feedback-DEVS sont couplés à l’intérieur de mo-dèles de composition DEVS classiques, les classes Coordinateur et

Composant-Modèle-Composition ne sont donc pas redéfinies. Il est cependant nécessaire de développer la

classe Noeud-Composition-Feedback, différente de la classe Noeud-Modèle-Composition, car elle doit permettre le stockage de liens vers des ports d’entrée de type feedback. Le modèle ato-mique de type feedback est différent du modèle atoato-mique classique, ce qui nécessite l’ajout d’une classe Model héritant de AtomicModel et de la classe simulateur associées

Feedback-Simulator. L’intégration d’une technique comme feedback-DEVS est facilitée par sa très forte

similarité avec la technique classique DEVS directement disponible dans le cadriciel. Dans le cas de l’étude de systèmes distribués spatialialement les données à traiter sont de nature différente. Les sections suivantes présentent les techniques de modélisation pour les problèmes spatialisés, tech-niques définies pour l’environnement afin de prendre en compte la dimension spatiale des modèles.

4.3 Modélisation par automate cellulaire

Les modélisations les plus courantes de phénomènes spatiaux s’élaborent en affectant aux zones de l’espace dont la surface est identique, un caractère discret : nous les appellerons les cellules. Pour spécifier un modèle cellulaire, il suffit de spécifier le comportement d’une cellule. Chaque cellule doit pouvoir échanger des informations avec les cellules de son voisinage. Le voi-sinage est constitué habituellement des cellules situées aux points cardinaux mais peut aussi être dynamique et fonction d’autres attributs. Les modèles cellulaires sont les plus courants des mo-dèles spatialement distribués, il était nécessaire de les inclure dans l’environnement. Cependant, la transcription de la technique d’automate cellulaire en DEVS ayant déjà été l’objet de travaux com-plets, nous n’en présenteront pas en détail les spécifications. Toutefois pour les lecteurs intéressés,

CHAPITRE 4 4.3. MODÉLISATION PAR AUTOMATE CELLULAIRE

FIG. 4.5: Modèle couplé représentant un domaine de neuf cellules (C1..9), couplées entre elles par

des liaisons de port à port aux points cardinaux (Nord, Sud, Est et Ouest), et possédant un port d’entrée et de sortie chacune (IN et OUT)

nous conseillons la consultation de [Wainer et Giambiasi, 2001]. Il existe deux formes principales de spécification de modèles cellulaires avec DEVS :

– en considérant chaque cellule comme un modèle atomique. Les couplages internes corres-pondent alors aux fonctions de voisinage et l’ensemble des cellules corresponds à un do-maine. La figure 4.5 présente un modèle couplé comportant neuf cellules. Ce type de spéci-fication est le plus souple car il autorise la manipulation de domaines composés de cellules hétérogènes. Soulignons toutefois que le passage nécessaire par des ports de messages, de-vienne vite un handicap lors de la simulation.

– En considérant un modèle atomique comme un ensemble de cellules. Chaque cellule est alors un des état de ce modèle et les fonctions de voisinages sont spécifiées par les fonctions de transitions. De tels modèles sont appelés multicomposants [Zeigler, 2000]. La figure 4.6

CHAPITRE 4 4.3. MODÉLISATION PAR AUTOMATE CELLULAIRE

FIG. 4.6: Modèle atomique multicomposants représentant un domaine de neuf cellules (E1..9)

possédant un port général d’entrée et de sortie (IN et OUT)

ticomposants sont limités car constitués d’un ensemble de cellules homogènes, les mêmes règles de transitions s’appliquant pour toutes ces cellules ; toutefois ils ont un avantage en matière de vitesse de simulation car ils peuvent s’affranchir des couplages internes de voisi-nage et donc des lourds passages de données.

L’intégration de la technique de modélisation cellulaire dans le cadriciel est faite grâce au package raster-DEVS présenté en figure 4.7. Ce package contient les classes spécifiques aux tech-niques de modélisation par automate cellulaire où chaque cellule est un modèle atomique. Dans l’interface graphique de modélisation, chaque domaine que l’on veut représenter par un ensemble de cellules est figuré par un objet Composant-Modèle-Raster contenant les différentes catégories de cellules de type Composant-Cell possédant un éditeur de code pour l’objet de type Cell, héri-tant de AtomicModel et définissant son comportement. Chaque objet Composant-Modèle-Raster est également associé à un objet de type Cell-Domain héritant de CoupledModel ce qui permet de spécifier les couplages internes par structures de maillages plutôt que des interconnexions de ports. Les objets Cell et Cell-Domain peuvent être simulés par des objets Simulator et

Coordina-torstandard et ne nécessitent donc pas la création de classes particulières à cet effet. Les modèles cellulaires sont stockés par des objets de type Noeud-Domaine-Raster et Noeud-Cell et récupèrés grâce à un objet Parser spécifique héritant de Parser-De-Domaine. Le Parser est spécifique car il doit réaliser le chargement d’un Composant-Domaine-Raster qui affiche les états des objets Cell

CHAPITRE 4 4.3. MODÉLISATION PAR AUTOMATE CELLULAIRE moteur_DEVS cadres_expérimentaux stockage interface_graphique raster-DEVS modeling Composant_Domaine Composant_Controle Parser_De_Domaine Noeud_Domaine Composant_Domaine Panel_Modèle_Atomique Panel_Modèle_Composition Access Parser Noeud-Domaine-Raster Noeud_Cell Editeur-Cell Panel-Cell Composant-Modèle-Raster Panel-Domaine-Raster Composant-Controle Composant-Domaine-Raster Cell-Domaine Cell Composant-Cell AtomicModel CoupledModel FIG. 4.7: Le package raster-DEVS