Moteur réactif

Modèle réactif Junior est le fruit des travaux menés autour des SugarCubes [13]. Junior reprend les principales instructions définies dans le formalisme des SugarCubes en donnant `a celles-ci une sémantique formelle. La sémantique initiale de Junior , `a base de règles de réécritures, est définie dans [39]. Pour permettre différentes implémentations basées sur ce mˆeme modèle opérationnel, une interface de programmation (API) générique a été créée. Cette API définit un certain nombre d’instructions pour créer des programmes réactifs. Dans le cadre de l’utilisation d’un modèle réactif pour un environnement graphique comme celui des Icobjs (cf. section 5), nous proposons certaines simplifications ou ajouts au modèle existant pour tenir compte des caractéristiques et des besoins spécifiques de ce type d’environnement. La section 2.1 présentera les différentes notions qui caractérisent l’approche réactive et le modèle d’exécution de Junior . A la suite de cela, nous détaillerons l’API de ` Junior (section 2.2) et nous donnerons quelques exemples pour illustrer son utilisation. Pour finir, nous décrirons les modifications apportées `a l’API de Junior pour réaliser celle de Reflex (section 2.3). Ces modifications sont introduites dans la perspective de définir un moteur réactif dédié aux environnements graphiques. Elles se manifestent principalement par des ajouts et des retraits d’instructions et par des modifications apportées aux instructions existantes. 2.1 Approche réactive La principale caractéristique d’un système réactif [36] est de réagir, rapidement et en continu, aux activations et aux modifications de l’environnement. A l’inverse des programmes ` transformationnels que l’on exécute en utilisant des paramètres, et qui retournent un résultat au moment o`u ils se terminent, les systèmes réactifs ne se terminent généralement pas. Ils sont exécutés en continu et, en réponse `a chaque activation, ils réagissent en modifiant leur environnement. L’approche réactive considérée dans ce document s’articule autour de quatre notions principales. Approche Réactive = instant + concurrence + diffusion d’événements + dynamisme

Définitions

La notion d’instant Un instant représente la réaction du système `a une activation. L’instant peut ˆetre vu comme une unité de temps dans l’évolution discrète du système. A la différence des systèmes ` dits temps réel o`u l’on se base sur un temps physique, l’instant représente une unité de temps logique. Contrairement `a Esterel et aux modèles synchrones o`u la durée d’un instant est considérée comme nulle, dans l’approche réactive, aucune hypothèse n’est faˆıte sur cette durée (cf. figure 2.1). La durée d’un instant est le temps entre l’activation du système et le retour du système `a un état stable, c’est-`a-dire lorsqu’il ne peut plus évoluer dans l’instant. Instant i Instant i+1 Activation Activation Fig. 2.1 – Notion d’instant La durée d’un instant étant non nulle, le système évolue donc progressivement vers un état stable `a chaque instant. Il est possible de découper l’exécution au cours d’un instant en plusieurs micro-étapes. Chacune de ces micro-étapes reflète une partie de l’évolution du système pour arriver `a l’état stable. Les instructions que nous allons présenter plus bas ont une sémantique qui se base sur cette notion de micro-étape. La concurrence Tout comme le modèle synchrone (cf. Esterel), le modèle réactif définit un moyen pour exprimer l’exécution en parallèle de plusieurs composants. Un instant se termine au moment o`u chacun des composants du système réactif a atteint un état stable (cf. figure 2.2). Instant i P1 P2 P3 || Instant i+1 P1 P2 P3 || Fig. 2.2 – Concurrence Dans la figure 2.2, P1, P2 et P3 représentent chacun un des composants qui sont exécutés en parallèle dans le système réactif. Chacun des composants évolue `a sa manière aux modifications apportées `a l’environnement d’exécution du système. La découpe en micro-étapes peut aussi ˆetre appliquée `a l’exécution de chacun des composants exécutés en parallèle. La diffusion d’événements Dans le modèle réactif, les composants concurrents utilisent des événements pour communiquer entre eux. Ces événements permettent également `a différents composants du système 2.1. APPROCHE REACTIVE ´ 17 en attente sur un mˆeme événement de se synchroniser. Les événements sont diffusés, c’est- `a-dire qu’ils sont transmis `a tous les composants. La notion d’instant permet de définir la notion de diffusion instantanée qui signifie qu’au cours d’un instant, un événement est vu de la mˆeme manière par tous les composants. Si un événement est vu présent par un composant du système, il ne peut pas ˆetre vu absent par un autre composant au cours du mˆeme instant, et inversement. Ce mécanisme est celui du langage Esterel [8]. Un événement diffusé au cours d’un instant donné n’est présent qu’au cours de celui-ci. A l’instant suivant, il sera considéré ` comme absent, excepté s’il est de nouveau diffusé. Il faut noter que la diffusion est instantanée. Cela signifie qu’au cours d’un instant donné, tous les composants verront l’événement généré de la mˆeme manière. Par contre, les composants n’auront pas nécessairement une vue cohérente sur le statut d’un événement au cours d’une micro-étape. Pour maintenir l’état de cohérence, on ne peut faire aucune hypothèse quant `a l’absence d’un événement pendant un instant et on ne peut ˆetre sˆur qu’un événement est absent qu’`a la fin de l’instant. Donc, on ne peut réagir instantanément `a une absence d’événement et cette réaction doit ˆetre retardée `a l’instant suivant. Cela constitue une des différences majeures entre l’approche réactive et l’approche synchrone. Cela évite en mˆeme temps les cycles de causalité [7] que l’on peut avoir avec Esterel. Principalement, les cycles de causalité sont dus `a l’invalidation d’hypothèses faites au cours de l’exécution. Voici un exemple de cycle de causalité : signal S in present S else emit S end end Ce programme teste la présence du signal local S et s’il est absent, alors il émet le signal dans le mˆeme instant. Si l’hypothèse est faite que S est absent pour l’instant courant alors la réaction est d’exécuter la branche else et d’émettre S pour ce mˆeme instant, ce qui est en contradiction avec l’hypothèse initiale. Inversement, si on fait l’hypothèse que S est présent alors il n’est pas émis, ce qui est également une contradiction. En reportant la réaction `a l’absence `a l’instant suivant, il est impossible de rencontrer de tels problèmes. La réaction retardée `a l’absence donne une plus grande modularité `a la programmation. En effet, la mise en parallèle de plusieurs composants ne peut plus générer de problème de causalité. Le dynamisme Le dynamisme concerne la possibilité d’ajout et/ou de retrait de composants en cours d’exécution. Les ajouts et les retraits de composants ne sont pas des opérations instantanées. La notion d’instant permettant de garantir la stabilité du système `a la fin de celui-ci, ces opérations sont uniquement effectuées entre deux instants. Comme nous l’avons fait remarquer dans le paragraphe précédent, aucun problème de causalité ne peut apparaˆıtre dans la combinaison de plusieurs composants en parallèle, donc dans l’ajout de composants. Le retrait d’un composant peut ˆetre considéré comme une préemption de ce composant. A la différence d’ ` Esterel, le modèle réactif ne permet pas la préemption forte, c’est-`a-dire qu’il n’est pas possible d’interrompre définitivement l’exécution d’un comportement qui n’a pas atteint un état stable au moment o`u un événement est généré. Le modèle réactif permet uniquement la préemption faible et ne permet pas de stopper immédiatement l’exécution d’un  Instant i P1 P2 P3 || Instant i+1 P1 P2 P3 || Evénements Evénements Fig. 2.3 – Dynamisme programme au moment o`u un événement est généré. Le programme doit atteindre un état stable pour l’instant courant avant d’ˆetre préempté, c’est-`a-dire qu’il doit avoir fini l’exécution de son comportement pour l’instant courant. Le modèle réactif propose deux mécanismes de retrait de composant : • une simple préemption (primitive Until) • une préemption dans laquelle on garde l’état du composant préempté pour pouvoir le réutiliser dans un autre environnement d’exécution (primitive Freezable). Ces opérations sont effectuées par l’intermédiaire d’instructions décrites dans la section 2.2.

Modèle d’exécution

Nous venons de décrire un système réactif comme un ensemble de composants exécutés en parallèle dans un environnement commun et répondant aux activations. En fait, chacun de ces composants est décrit `a l’aide d’instructions réactives que nous détaillerons dans l’API de Junior (section 2.2). Ces instructions réactives sont enregistrées et exécutées par une machine réactive. Les instructions Les instructions réactives en Junior sont des objets Java avec un certain nombre de méthodes déclarées. L’exécution d’une instruction réactive retourne un statut qui indique l’état de l’instruction. Les trois statuts retournés sont TERM, STOP et SUSP. Dans la version Storm, le statut WAIT a été rajouté. C’est cette version que l’on considère ici. • TERM indique que l’instruction a complètement terminé son exécution pour l’instant courant et les suivants. Si l’on réactive une instruction qui a renvoyé le statut TERM, il ne se passera plus rien et elle renverra toujours le statut TERM. • STOP indique que l’instruction a atteint un état stable et a terminé son exécution pour l’instant courant, mais qu’il y aura encore quelque chose `a effectuer aux instants suivants. L’exécution reprendra `a l’endroit o`u l’instruction s’est stoppée. • SUSP indique que l’instruction n’est pas encore dans un état stable et doit donc ˆetre ré-exécutée au cours du mˆeme instant. • WAIT a été rajouté dans la version Storm de Junior pour des questions d’efficacité. Ce statut est renvoyé par les instructions événementielles pour indiquer qu’elles sont en attente d’un événement et qu’il n’est pas nécessaire de les réactiver tant que l’événement   n’est pas présent ou tant que la fin d’instant n’a pas été déclarée. Cela évite de repasser `a chaque micro-étape sur l’ensemble des instructions en attente d’un événement, et d’exécuter seulement celles dont l’événement déclencheur a été généré. Le statut WAIT n’apparaˆıt pas directement dans la spécification de Junior . Nous l’utiliserons tout de mˆeme dans la suite des explications, car les modifications que nous avons apportées sont basées sur la sémantique et l’implémentation de Storm