Briques de base

Le formalisme de synchronisation utilise principalement deux sortes d’objets : les

Mod`eles et les Caches. Les Mod`eles sont des composants de calcul, et les Caches sont

des abstractions des donn´ees servant d’entr´ees et de sorties `a ces calculs. Les Mod`eles lisent donc leurs entr´ees dans des Caches, puis ´ecrivent leurs sorties dans d’autres Caches. Les Caches mettent alors `a jour les donn´ees r´eelles de mani`ere synchrone. Cette architecture basique est illustr´ee sur la figure 3.1. Nous utilisons dans toute la suite la convention d’´ecriture suivante : le terme Mod`ele employ´e avec une majuscule a le sens particulier qui est d´ecrit dans ce chapitre, employ´e avec une minuscule il d´esigne le mod`ele au sens de repr´esentation de la r´ealit´e, comme employ´e plus couramment par les scientifiques.

Une de ses propri´et´es les plus remarquable et utile est que les donn´ees de la simu-lation sont stock´ees dans une structure totalement s´epar´ee des composants de calcul, qui est toujours maintenue dans un ´etat coh´erent (en admettant que la mise `a jour soit instantan´ee). Cette structure de donn´ees repr´esente l’´etat de la simulation, et suffit `a d´emarrer ou `a reprendre une simulation. Non seulement cela permet des simulations plus stables, puisque les Mod`eles lisent toujours des donn´ees coh´erentes, mais cela r´esoud aussi ´el´egamment, en th´eorie, le probl`eme de l’arrˆet et et de la reprise des simulations, ainsi que celui de la sauvegarde indispensable des r´esultats.

Fig. 3.1 : Sch´ema des objets de simulation et de leurs liens. On distingue principalement les Mod`eles, les Caches (il y a en fait plusieurs objets Caches non repr´esent´es ici), les donn´ees de la simulation et le Manager r´ealisant l’avancement dans la simulation. La structure des donn´ees de la simulation est dupliqu´ee au sein des Caches, qui l’isolent des Mod`eles, ce qui assure une ´evolution synchrone. Les Mod`eles lisent leurs entr´ees dans les Caches, ´ecrivent leurs sorties dans la structure dupliqu´ee stock´ee dans les Caches. Ils transmettent aussi une information temporelle au Manager qui permet de fixer dynamiquement le pas de temps de la simulation. L’op´eration de mise `a jour recopie les donn´ees locales des Caches vers les donn´ees de simulation. C’est cette op´eration qui est r´ealis´ee de mani`ere synchrone.

3.1.1 Caches

Les Caches servent d’interface vers les donn´ees r´eelles, et font ´evoluer ces donn´ees r´eelles en les mettant `a jour sur demande. Ils ont un lien vers les donn´ees r´eelles et une copie interne de ces donn´ees dans laquelle ils stockent temporairement les nouvelles valeurs, d’o`u la d´enomination choisie.

Liens avec les Mod`eles

Les Caches communiquent avec les Mod`eles `a travers deux interfaces sp´ecifiques aux comportements diff´erents, qui pr´eservent la synchronisation des donn´ees de si-mulation. Ces deux interfaces permettent aux Mod`eles de collecter dans la liste des donn´ees externes les valeurs des variables d’entr´ee et de transmettre leurs variables de sortie.

La premi`ere interface est le Getter. Un Mod`ele peut, `a partir d’un lien vers un Getter, lire une valeur. Dans ce cas le Cache renvoie la valeur stock´ee dans la structure de donn´ees externe. La seconde interface est le Setter. Un Mod`ele peut utiliser cette interface pour sp´ecifier la future valeur `a affecter `a la donn´ee externe. Le Cache copie cette valeur et la conserve jusqu’`a la prochaine mise `a jour.

3.1. Briques de base 45 le Setter agit sur la copie interne situ´ee dans le Cache, il n’y a aucun risque que la valeur renvoy´ee par le Getter soit modifi´ee par un Mod`ele interagissant avec le Setter. En revanche, il est souhaitable qu’un seul Mod`ele puisse interagir avec un Setter donn´e, sans quoi la valeur en cache risque d’ˆetre ´ecras´ee. L’interface Getter n’impliquant aucune modification, plusieurs Mod`eles peuvent sans probl`eme lire la valeur d’un mˆeme Getter.

Mise `a jour

La valeur associ´ee au Cache peut ˆetre mise `a jour de plusieurs fa¸cons, suivant le type de la valeur et le syst`eme simul´e.

La fa¸con ´evidente de mettre `a jour est de copier la nouvelle valeur dans la structure de donn´ees externe. Cependant, dans certains cas, conserver deux exemplaire d’une donn´ee peut ˆetre un gaspillage de m´emoire. En particulier, quand la donn´ee contient une grande quantit´e d’information (une image par exemple) mais n’est modifi´ee que sur une petite partie de ces informations, une autre strat´egie peut ˆetre choisie : on peut cr´eer le Cache comme un Getter du « gros » type de donn´ee, et comme un Setter du type de donn´ee « variation », qui contient juste les informations n´ecessaires `a la mise `a jour.

En plus d’apporter des b´en´efices en terme d’occupation m´emoire et de vitesse d’ex´ecution (car les op´erations de copie sont d’autant plus coˆuteuses que les informa-tions `a copier sont nombreuses), ce choix peut ˆetre naturel pour certains mod`eles, qui par d´efinition calculent la variation d’une donn´ee et pas une valeur.

Coh´erence

Un Cache est dit dans un ´etat coh´erent lorsque la mise `a jour ne causerait pas de changement significatif dans la valeur de la donn´ee externe. Significatif peut ici prendre plusieurs sens, selon les intentions et le choix de mod´elisation pour le couplage des Mod`eles. On peut ˆetre tr`es strict et poser que tout changement de valeur est significatif, ou encore poser un seuil en de¸c`a duquel on consid`ere la variation comme n´egligeable. Cette d´efinition est importante pour assurer la convergence du syst`eme dans certains cas, en particulier ceux comportant des boucles de r´etroaction.

3.1.2 Mod`eles

Les Mod`eles sont responsables de tous les calculs de simulation. Ils peuvent ˆetre pourvus d’un ´etat interne qu’ils doivent faire ´evoluer.

Entr´ees, Sorties, ´Etat

Un Mod`ele poss`ede une liste d’entr´ees I, qui sont autant de liens vers des interfaces Getters.

L’´etat d’un Mod`ele est un ensemble de donn´ees qui lui sont propres, et ne sont accessibles en ´ecriture que depuis l’int´erieur du Mod`ele. Ces donn´ees sont accessibles par des Caches, comme les entr´ees et les sorties, sauf que dans le cas de l’´etat le Mod`ele poss`ede le Cache et pas juste des liens vers des Getters et des Setters. Ainsi, on respecte le principe de s´eparation des donn´ees et des calculs, l’´etat des Mod`eles ´etant stock´e dans la structure de donn´ees externe. Cela est n´ecessaire car un Mod`ele pourrait ´eventuellement ne pas ˆetre persistant en m´emoire, alors que son ´etat devrait l’ˆetre. Un exemple de ce type sera d´etaill´e dans la partie 3.2.3.

Certains Mod`eles n’ont pas besoin d’´etat, et dans ce cas l’architecture de simulation pr´esent´ee ne leur impose rien de particulier. La pr´esence ou non d’un ´etat pour un Mod`ele n’affecte en rien les fonctions de calculs pr´esent´ees ci-apr`es.

Calculs

Un Mod`ele doit d´efinir trois fonctions qui seront utilis´ees dans l’algorithme de simulation.

La premi`ere est la fonction cumul :

OC(t) = cumul(t, tprev, I(tprev)) (3.1) o`u OC est une liste des sorties « cumulatives », t est le temps courant, tprev est la date du dernier appel `a cumul, et I est la liste des entr´ees.

Cette fonction permet de repr´esenter l’´evolution du Mod`ele durant l’intervalle de temps [tprev, t], pendant lequel les entr´ees I sont suppos´ees constantes. En pratique ce sont souvent des op´erations d’int´egration dans le temps, qui cumulent au fil du temps les effets des entr´ees, d’o`u le nom de la fonction et des sorties associ´ees.

La seconde fonction est la fonction trans :

OT(t) = trans(I(t)) (3.2)

o`u OT est une liste des sorties « transitoires ».

Cette fonction permet au Mod`ele de r´eagir instantan´ement aux changements de ses entr´ees. Un exemple de Mod`ele purement transitoire serait un additionneur qui se contente de faire la somme de ses entr´ees. Un tel Mod`ele n’a pas de m´emoire du pass´e, pas de notion d’´ecoulement du temps.

Il existe bien sˆur des cas de Mod`eles utilisant les deux fonctions, comme on le verra dans les exemples aux chapitres 4 et 5.

`

A part ces fonctions de calcul, les Mod`eles d´efinissent une troisi`eme fonction time, utilis´ee pour la synchronisation :

tn(t) = time(t, I(t)) (3.3)

Ici tn est la date la plus lointaine `a laquelle un appel `a la fonction cumul du Mod`ele doit avoir lieu. Ceci permet en particulier, pour les mod`eles faisant une int´egration temporelle, de fixer une borne sup´erieure au pas de temps. Mais les Mod`eles peuvent aussi s’en servir pour g´en´erer des ´ev`enements, par exemple.

3.2. Hi´erarchies 47