3.3 Les systèmes réactifs

Le paradigme des systèmes réactifs nous vient des langages comme Esterel [Berry et al., 1987,Berry, 1999] ou Lustre [Halbwachs et al., 1991], dans lesquels la propagation de l'information est conceptuellement instantanée. Dans cette section, nous décrivons brièvement ce paradigme et motivons nos choix quant à ce modèle d'exécution.

3.3.1 Systèmes réactifs et conversationnels

Les systèmes informatiques qui interagissent avec l'environnement peuvent être distingués en deux classes [Berry, 1989]:

• Les systèmes conversationnels ^3.1: Dans ces systèmes, le client émet des requêtes vers l'ordinateur. Celui-ci choisit s'il doit ou non y répondre, ainsi que le moment où il doit fournir la réponse. Dans ces systèmes, l'ordinateur est maître de l'interaction, et le client attend d'être servi. D'autre part, les choix internes de l'ordinateur font que ces systèmes sont le plus souvent non déterministes. Les exemples incluent les systèmes d'exploitation, les bases de données, les systèmes réseau.
• Les systèmes réactifs ou systèmes réflexes: Dans ces systèmes, c'est l'environnement qui est maître de l'interaction: le rôle de l'ordinateur est de réagir de façon continue aux stimuli externes en produisant des réponses instantanées. On trouve ces systèmes dans les domaines où le client ne peut pas attendre (systèmes temps réel), comme le contrôle de processus industriels, les systèmes embarqués, les pilotes de dispositifs, ou le traitement de signal. Le déterminisme est une propriété souvent désirable pour ces types de systèmes: les résultats émis doivent dépendre uniquement des informations reçues et de leur enchaînement temporel.

Les systèmes réactifs sont des programmes qui réagissent à l'environnement à la vitesse de l'environnement, alors que les autres systèmes réagissent à leur vitesse propre. Les systèmes conversationnels sont asynchrones et souvent non-déterministes, et les systèmes réactifs sont parfaitement synchrones et souvent déterministes [Berry, 2000].

3.3.2 Pour une gestion réactive de l'interaction

La plupart des systèmes comportent à la fois des éléments conversationnels et réactifs. Par exemple, le pilotage d'un avion est réactif, alors que la communication avec le sol est conversationnel. C'est le cas également des systèmes interactifs.

Certains services du système d'exploitation et du système de fenêtrage, comme la gestion du curseur de la souris ou le déplacement des fenêtres, sont éminemment réactifs. Au niveau de l'application, il existe également des éléments plus réactifs que d'autres. Dans une application de dessin vectoriel, par exemple, le réaffichage d'un dessin complexe peut prendre du temps, et s'effectue selon un mode conversationnel. Il est par contre souhaitable que le retour graphique associé aux déplacements d'objets soit réactif.

Le modèle à événements classique, bien qu'essentiellement conversationnel, est souvent utilisé pour décrire l'intégralité du comportement d'une application interactive. Nous pensons cependant que les parties intrinsèquement réactives d'une application interactive, en particulier celles relatives à la gestion des entrées, gagnent à reposer sur un modèle réactif. La file à événements n'y est pas nécessaire, elle est peu adaptée à la description de comportements réactifs, et ne donne aucune garantie en termes de temps réel.

3.3.3 Le modèle du synchronisme parfait

Figure: Exemple de circuit synchrone, où l'information est propagée de façon instantanée [Berry, 2000].

Les langages réactifs sont basés sur le modèle du synchronisme parfait, dans lequel les processus sont capables, au niveau conceptuel, de s'exécuter et d'échanger de l'information en un temps nul [Berry, 2000]. Ce modèle est équivalent au modèle 'zéro-délai' des circuits électroniques (figure 3.8). Bien que ce paradigme soit peu naturel pour des programmeurs classiques, c'est un standard pour les théoriciens du contrôle, les concepteurs de circuits électroniques, ou les utilisateurs de contrôleurs programmables.

Dans le paradigme réactif, un événement est un signal. Du point de vue logiciel, un programme réactif s'exécute en une séquence ininterrompue d'itérations appelées ticks, qui sont des réactions aux signaux d'entrée. L'hypothèse du synchronisme parfait est vérifiée en pratique si les réactions sont assez rapides pour qu'aucun signal provenant de l'environnement ne soit perdu.

Nous n'aborderons pas les détails concernant les différents langages réactifs existants (pour plus de détails, le lecteur est invité à lire [Berry, 2000]). Précisons simplement qu'il en existe deux styles: les langages impératifs et les langages à flots de données. Notre modèle d'exécution s'inspire du dernier.