(These.cwk)

Sujets

• réseau
• réseaux

Informations

• Publié par: Ucto
• Nombre de lectures: 42
• Langue: Français

Extrait

Chapitre 2
Les SugarCubes v1
Ce chapitre décrit la première version des SugarCubes. Il est basé en grande partie sur un article publié
dans la revue Software Practice and Experiences [BS1], qui introduit la première implémentation de
l’Approche Réactive au dessus de Java.
L'implémentation de l' Approche Réactive au-dessus de Java a pour objectif de fournir des moyens
d'expression simples, avec une sémantique précise, de la concurrence et du parallélisme. À ce titre, les
SugarCubes proposent des outils permettant d’implémenter des systèmes réactifs au-dessus de Java.
Contrairement à beaucoup de formalismes de l' Approche Synchrone/Réactive, les SugarCubes ne se
limitent pas à l’implémentation de systèmes statiques où tous les composants sont connus au démarrage et
dont les interconnexions sont statiquement définies. En particulier, ils permettent de décrire des systèmes
dont le nombre de composants parallèles peut dynamiquement évoluer en cours d’exécution. Cette
approche des systèmes réactifs dynamiques s’avère plus en phase avec un langage généraliste comme le
langage Java qui considère des systèmes souvent dynamiques en particulier lorsque ceux-ci mettent en jeu
le réseau.
L'Approche Réactive propose un ensemble de primitives exprimant l'ordonnancement et le contrôle des
tâches d'un programme. Une caractéristique importante de ces primitives est que leur exécution nécessite
souvent plusieurs étapes. Ces primitives ont un état propre (une mémoire de leur avancement) qui régit
leur évolution au cours des différentes étapes de leur exécution.
Les SugarCubes proposent une implémentation originale de l’ Approche Réactive au-dessus de Java
dans laquelle les primitives réactives sont implémentées par des objets. Il ne s’agit donc pas à proprement
parler d’un langage à part entière avec une grammaire spécifique. Chaque primitive est décrite par une
classe Java particulière. Un programme réactif est une collection d’objets instanciés à partir de ces
classes. Ainsi, un objet-instruction encapsule l’état de l’instruction réactive qu’il représente dans un
programme. À chaque réaction du système, une méthode particulière de cet objet-instruction exécute le
comportement de la primitive réactive si celle-ci doit être exécutée. L’état de l’instruction est modifié en
conséquence afin de mémoriser l’effet d’une activation et préparer la suivante, jusqu'à ce que la primitive
ait été totalement exécutée.
Exemple :
Merge Program p = new Me rge(
new Seq (
Seq Seq new Seq(new Pri nt("HelloWorld"),new Stop())
,new Gener ate("e")
Seq Generate Await Print )
,new Seq(new Awai t("e"),new Pr int("e!"))
Print Stop ) ;
Fig. 4 : Arbre syntaxique d'un programme SugarCubes. Chaque nœud est un objet Java.16 Chapitre 2 : Les SugarCubes v1
Les primitives utilisées dans l’exemple précédent sont décrites dans la suite de ce chapitre.
Un objet-instruction contient éventuellement des références sur les sous-instructions sur lesquelles agit
l’opérateur réactif correspondant. Par exemple, l’opérateur binaire de mise en séquence (Fig. 4), est
représenté en SugarCubes par une classe particulière qui possède deux champs. Ces champs référencent
la première instruction à exécuter et la seconde instruction à exécuter en séquence dès que la première aura
terminé son exécution. Ainsi, un programme réactif est constitué d’un arbre d’objets dont chaque nœud est
un opérateur contrôlant l’exécution d’une ou plusieurs sous-instructions. Les feuilles de cet arbre sont des
primitives n’ayant pas de contrôle sur d’autres instructions.
Un système réactif est censé réagir le plus rapidement possible à toute modification de son
environnement d’exécution. Comme nous l’avons vu dans l’introduction, l’ Approche Réactive répond à ce
problème en proposant de découper l’exécution du système en instants logiques qui deviennent les instants
de réaction aux modifications de l’environnement. Cela signifie qu’un système est activé périodiquement
et réagit immédiatement au cours d’un instant d’exécution à toute modification de son environnement.
Cette notion de réaction transparaît évidemment au niveau des primitives utilisées dans les formalismes
réactifs pour décrire un programme. Cependant, dans l’ Approche Réactive, l’exécution d’une réaction
(c'est-à-dire d’un instant) du système peut nécessiter un certain nombre de micro-étapes afin d’aboutir à un
état stable en fin de réaction. L’ Approche Réactive considère ainsi des micro-étapes (micro-steps)
successives qui composent une réaction (un instant ou macro-step) du système. Ces micros étapes
permettent au cours d’une activation de faire progresser le système vers un état stable marquant la fin de la
réaction en cours. En SugarCubes, on parlera d’activation pour décrire l’exécution d’une micro-étape;
tandis que l’on parlera de réaction pour décrire l’exécution d’un instant logique du système pouvant mettre
en jeu plusieurs micro-étapes successives.
2.1 Mécanisme d’exécution : instructions et machines
Les SugarCubes sont un ensemble de classes Java qui implémentent les primitives réactives, les
machines virtuelles chargées de leur exécution et les éléments implémentant l’environnement d’exécution.
On peut donc découper les SugarCubes en 3 sous-ensembles logiques :
• les instructions réactives. Ce sont des objets qui implémentent les primitives réactives; par
exemple, l’opérateur de séquence, l’opérateur de parallélisme, la primitive de génération d’un
événement, la primitive de préemption, etc. …
• les machines réactives. Ce sont des objets utilisés pour exécuter les programmes construits à
partir de primitives réactives. Typiquement, une machine réactive (i)possède un programme qu’elle
active cycliquement, (ii)définit les instants d’exécution et (iii)gère l’environnement d’exécution
(environnement événementiel, objet Java par défaut, etc.…).
• les classes implémentant l’environnement d’exécution, comprenant entre autres, les événements.
2.1.1 Instructions
Une primitive réactive est implémentée par une classe particulière et son utilisation dans un programme
réactif est obtenue par instanciation de la classe désirée à la construction du programme. Toutes les
primitives réactives répondent à certain nombre de méthodes déclarées dans la classe abstraite
Instruction dont toute s les primitives SugarCubes héritent.
Un objet-instruction peut être activé par un appel de sa méthode activ. L ’instruction réagit alors à cette
activation en exécutant une micro-étape de son comportement. À la fin de l’activation, l’instruction
retourne un statut représentant l’état d’avancement de son exécution au cours de l’instant. En particulier,
ce statut révèle s’il est nécessaire à l’instruction activée d’exécuter d’autres micro-étapes pour l’instant
courant avant de parvenir à un état stable.
Le statut retourné correspond à l’une des trois valeurs suivantes : TERM, STOP ou SUSP, déclarées Chapitre 2 : Les SugarCubes v1 17
dans l’interface ReturnCodes. C es différentes valeurs sont retournées dans les conditions suivantes :
• TERM (pour terminée) signifie que l’exécution de l’instruction est complètement terminée (pour
cet instant et les instants futurs). Ainsi, si on l’active aux instants suivants, rien ne se passera et
l’instruction retournera toujours TERM.
activ TERM activ TERM
Fig.5 : le statut TERM indique la terminaison
d'une instruction réactive.
• STOP (pour stoppée) signifie que l’exécution d’une instruction est stoppée dans un état stable
pour l’instant courant. Son exécution pourra reprendre, à l’instant suivant, à partir de l’endroit
précis où celle-ci s’est arrêtée pour l’instant courant. L’exécution n’est donc pas définitivement
terminée; simplement il n’y a plus rien à exécuter pour l’instant courant. Par analogie avec la
signalisation routière qui demande au véhicule arrivant à un panneau STOP de s’arrêter avant de
redémarrer, le statut STOP marque un point d’arrêt de l’exécution d’un programme a