5.3 Dynamique de l'application
Dans cette section, nous allons décrire plus précisément comment se cons- truisent les états (dé nition 4.5.1, page 113) et les ordonnançables (dé ni- tion 5.2.1, page 134), et comment l'utilisateur doit les modéliser dans le cadre du framework.
Pour faciliter la conception de l'application, nous avons dé ni un modèle de composition des états, qui peut servir intuitivement à décrire la structure des objets du jeu. Certains états sont tout simplement un ensemble de don- nées, mais la plupart d'entre eux re éteront, les objets virtuels qui composent l'application.
5.3.1 Composition d'états
D'un point de vue génie logiciel, les objets du jeu seront représentés dans notre framework par des états. L'approche traditionnelle pour la conception des objets du jeu est de les composer à partir d'autres objets du jeu. A n de faciliter la conception d'une application en dé nissant des dépendances logiques entre les états qui re ètent la nature des objets du jeu, le framework ore la possibilité d'assembler des états en un état composé. Ainsi, les états sont arrangés hiérarchiquement, en un arbre de compositions (on rappelle que selon la dé nition 4.5.1 page 113 la composition est stricte, un état ne peut pas appartenir à deux états distincts), la racine de cet arbre étant l'état du jeu lui même. Cette hiérarchie est dé nie par l'utilisateur lors de la conception du jeu.
Il y a deux manières diérentes de dé nir les sous-états d'un état. un état, éventuellement lui-même composé ;
un ensemble dynamique d'états duplicata (que nous étudierons plus en détail au paragraphe 5.3.1.2 page 138).
Nous utiliserons dans la suite le terme de composant d'état pour désigner soit un état, soit un ensemble d'états duplicata.
5.3.1.1 Couplage entre état et composant d'état
Du point de vue des réplications, le couplage entre un état et un de ses composants d'état est faible : quand un état est répliqué sur un hôte distant, seules ses données propres sont répliquées : les données propres des sous- états ne sont pas envoyées sur un hôte distant si leurs propres modèles de réplication ne sont pas déclenchés. De manière similaire, l'instruction update (voir dé nition 5.2.3 page 136) ne met à jour que les données propres d'un état, et pas celles de ses composants d'état.
Cependant, du point de vue de la synchronisation de la mémoire des ré- exes, le couplage est fort : quand un ré exe dé ni un état comme étant né- cessaire au calcul tous ses sous-états sont également considérés comme étant nécessaires. Ainsi, lorsque l'instruction ash (voir dé nition 5.2.2 page 135) est invoquée pour un état, la mise à jour est eectuée sur tout l'arbre des sous-états de la copie locale. Cela permet de faciliter la description d'un ré exe opérant sur une hiérarchie d'états représentant un objet du jeu. 5.3.1.2 Duplicata et patrons d'états
A côté des objets persistants d'un monde virtuel, il existe un grand nombre d'objets créés et détruits souvent, en nombre imprévisible, et ré- pondant à la même description et aux même propriétés de réplication.
Par exemple :
les états représentant les diérentes machines clientes sur le serveur un ensemble de personnages non-joueurs
les balles tirées par une arme
Pour représenter plus simplement de tels objets, nous introduisons les notions de patrons d'états et d'états duplicata.
L'utilisateur du framework peut dé nir une famille d'états en donnant un patron d'états. Les états crées à l'aide de ces patrons sont appelés états duplicata. Un patron d'états dé ni la structure et les ordonnançables des états duplicata qu'il permet de créer.
Ainsi, plusieurs états peuvent être créés et avoir des cycles de vie indé- pendants en suivant la même description fournie par l'utilisateur. Ils ont la même structure et les mêmes ordonnançables. Ils ont également le même état
5.3. DYNAMIQUE DE L'APPLICATION 139 parent dans la hiérarchie des états : ce ne sont pas simplement des instances diérentes d'un même état. Les états duplicata ne partagent aucune donnée et aucun sous-état : nous avons en eet décrit plus tôt comment les états sont arrangés hiérarchiquement en un arbre.
Si les états duplicata sont bien des états au sens de la dé nition 4.5.1 (page 113), les ensembles d'états duplicata utilisés pour dé nir leur apparte- nance à un état composé n'en sont pas. Ils ont cependant des propriétés en commun, dues au fait que ce sont des composants d'états et peuvent donc être utilisés dans la dé nition des ordonnançables. Nous commettrons donc parfois l'abus de langage.
Lorsqu'on a dé ni un ordonnançable pour un patron d'états cet ordon- nançable sera utilisé par tous les états duplicata issus de ce patron.
5.3.2 Dynamique des états
Les états peuvent être créés ou détruits dynamiquement à travers l'utili- sation d'une fabrique d'états intégrée au framework, et qui peut être utilisée par le développeur dans un ré exe, ou déclenchée par une réplication d'un hôte distant lorsque l'hôte local l'y autorise. La fabrique d'états utilise les descriptions des états fournies par le développeur, qui incluent la structure de l'état, ses ordonnançables et la manière dont il s'initialise et se détruit. 5.3.2.1 Création d'états
La fabrique d'états est capable de créer un état selon une description locale ou distante. La création des éventuels sous-états durant la création de l'état lui-même n'est pas automatique, et est dé nie par l'utilisateur.
Dé nition 5.3.1 Quand un état est créé, tous ses ordonnançables sont dits instanciés.
5.3.2.2 Destruction d'états
Par défaut, les sous-états sont également détruits s'il y en a. Cependant, l'utilisateur peut dé nir un autre comportement lors de la destruction d'un état dans la fabrique d'états. Il devra alors préciser à quel nouvel état les sous-états non détruits devront être attachés en remplacement de l'ancien parent dans l'arbre hiérarchique des états (nous n'avons cependant pas encore intégré cette possibilité dans le prototype du modèle que nous présenterons ultérieurement).
5.3.3 Dynamique des ordonnançables
On dé nit deux classes d'états que l'utilisateur doit décrire quand il veut construire un ordonnançable :
Dé nition 5.3.2 Les états utiles d'un ordonnançable sont les composants d'états (états ou ensembles d'états duplicata) intervenant dans la description de la temporalité (condition de déclenchement), du code du ré exe de cet ordonnançable, et des éventuels autres attributs de l'ordonnançable (portée et propriétés de communication, dans le cas où l'ordonnançable est un modèle de réplication). L'instruction ash (dé nition 5.2.2, page 135) met à jour les copies de tous les états utiles d'un ordonnançable ainsi que leurs sous-états. L'utilisateur peut ainsi simpli er la dé nition des états utiles d'un ordonnan- çable en jouant sur la composition des états.
Dé nition 5.3.3 Les états observés d'un ordonnançable sont les compo- sants d'états (états ou ensembles d'états duplicata) dont la mise à jour (par l'instruction update, dé nition 5.2.3, page 136, par une réplication provenant d'un hôte distant autorisé, ou par un ajout ou destruction d'état duplicata dans le cas des ensembles d'états duplicata) provoque un test de véri cation de la temporalité (condition de déclenchement) d'un ordonnançable.
Nous pouvons désormais dé nir les notions d'activation et de déclenche- ment d'un ordonnançable :
Dé nition 5.3.4 Un ordonnançable instancié est dit activé si et seulement si au moins un de ses états observés est créé et si tous ses états utiles sont créés.
5.4. SÉMANTIQUE OPÉRATIONNELLE 141