IHM: vers l'utilisation de langages concurrents

Christophe Tronche
LRI, CNRS URA 410, Bâtiment 490
Université de Paris-Sud, F91405 ORSAY Cedex
(+33) 1 69 41 66 25
ch@tronche.com (formerly tronche@lri.fr).

RÉSUMÉ

INTRODUCTION

Afin d'étayer ce point de vue, nous examinons dans une première partie l'influence de la séquentialité sur les IHMs, nous indiquons une approche possible de la concurrence, et pourquoi selon nous la programmation concurrente n'est intéressante en IHM que si le langage de programmation assiste le programmeur dans sa tâche. Enfin nous donnons quelques exemples de traitements courants en IHM exprimés dans le langage concurrent Ada.

Influence de la séquentialité

Bloquage de l'interface (et de l'application)

Dans les autres boîtes à outils cependant, une application interactive se décompose en deux phases : dans un premier temps, l'utilisateur décrit dans un style plus ou moins déclaratif les interacteurs et les différents objets qui dépeignent son interface, par exemple une application Motif débute généralement par des centaines, voire des milliers, de déclarations d'objets réactifs et de leurs différents attributs. L'application contient ensuite une instruction qui donne le contrôle à l'interface. Cette dernière communique ensuite avec le reste de l'application en appelant différentes routines par des ``callbacks''. Notons que cette structuration d'une application interactive favorise une interface figée : si des interacteurs peuvent être créés et détruits à tout moment, il n'y a aucune raison de distinguer entre les interacteurs créés ``avant'' et ``après'' un certain point dans la vie de l'application.

Dans un monde séquentiel, la ``callback'' devra s'exécuter dans un laps de temps suffisamment court (laps de temps que l'interface ne spécifie d'ailleurs pas). Si cette prescription n'est pas observée, des problèmes analogues à ceux survenants dans les boîtes à outils évoquées dans le paragraphe précédent se produiront : bloquage du processus, plus de réaffichage, éventuellement bloquage de l'interaction. Par exemple quand une application Windows ou MacIntosh charge un fichier, le bouton ``Cancel'' est souvent inactif simplement parce que l'application ne peut pas reprendre la main pour traiter l'événement tant que l'appel de chargement de fichier est pendant.

En général, il est recommandé aux programmeurs de gérer ce genre de contraintes par eux-mêmes, notamment par les guides de programmation. Cette solution n'est pas satisfaisante pour au moins deux raisons :

1. Le tandem langage / système d'exploitation ne fournit généralement aucun mécanisme pour gérer les contraintes de temps.

2. Dans certain cas, le programmeur n'a aucun moyen d'empêcher un bloquage à l'intérieur de la ``callback''. Un exemple est la résolution d'une adresse par un browser Web Unix : lorsque la ``callback'' lançant l'affichage d'une nouvelle page est déclenchée, l'application doit convertir le nom de la machine distante en adresse IP, un appel bloquant en Unix, ce qui fait que la page n'est pas rafraîchie tant que l'adresse n'a pas été résolue. Pendant ce temps, l'utilisateur ne peut rien faire : même s'il réalise que l'adresse est erronée et que la résolution prendra plusieurs dizaines de secondes, il ne peut interrompre l'opération.
   Les deux principes piliers du génie logiciel et de l'interaction homme-machine ont ici été simultanément violés. D'une part un problème d'implémentation (la résolution des adresses est bloquante) ressurgit au niveau de l'application : faute d'abstraction. D'autre part, l'utilisateur n'a pas le contrôle de son application.

Impossibilité d'extension des modèles.

Des boîtes à outils comme X ``trichent'' d'ailleurs avec leur modèle d'événement en entrée pour tenter de présenter un modèle plus abstrait au programmeur. Par exemple, l'appui sur la touche ``SHIFT'' puis sur une lettre correspond stricto sensu à deux événements clavier successifs; cependant X envoie dans l'événement ``appui sur la touche A'' l'état de la touche SHIFT pour éviter au programmeur d'avoir à garder lui-même la trace de l'état de certaines de ces touches ``stratégiques'' du clavier.

Signalons que l'écriture d'applications collecticielles nécessite la prise en compte d'événement provenant de plusieurs sources (réseau notamment), dont la problématique est proche de celle de l'interaction à multiples dispositifs d'entrées.

Impossibilité de prendre en compte et de manipuler correctement des données multimédia au niveau de l'interface

Mauvaise prise en compte des modèles existants et de la décomposition de l'application.

La modélisation orientée-objet, une famille de méthodes d'analyse / conception parmi les meilleures découvertes jusqu'ici, est particulièrement performante pour les interfaces homme-machine. Ceci est parfaitement naturel, puisque la philosophie de ces méthodes et de modéliser directement les ``objets'' du monde réel par des objets informatiques. Or les interfaces hommes-machines s'appuient sur des métaphores du monde réel (par exemple le bouton), suivant en cela une démarche parallèle à celle des méthodes orientée-objets. Les tenants de ces méthodes souhaitent une modélisation intrinsèquement concurrente [3,11]. En effet, dans le monde réel, les objets ont tendance à fonctionner concurremment. Pour la même raison, les ``interfaces'' du monde réel sont à flux d'entrée multiples : pour lancer un enregistrement avec mon magnétoscope, je dois appuyer simultanément sur ``record'' et ``play''. Il est intéressant de noter que Booch et Meyer indiquent que l'absence de concurrence limite la possibilité de créer des composants réutilisables. Or si les boîtes à outils graphiques sont de bons exemple de réutilisation de code réussie, les exemples de composants réutilisables multimédia ou multi-utilisateurs ayant réussi à trouver une large audience sont extrêmement rares.

La concurrence comme solution

Une première approche

Si l'on implémente ces mécanismes dans un langage non-parallèle tel que C++, on peut imaginer créer une classe décrivant les objets concurrents qui effectue les appels systèmes nécessaires pour obtenir du système d'exploitation une ``thread'' de calcul. Toutes les classes d'interacteurs hériteront de cette classe pour s'exécuter concurremment. Ceci pourrait s'écrire en C++ :

class concurrentObject {
	// Méthodes de gestion de
	// la concurrence
	void lock();
	void unlock();
	...
};

class interactor: public concurrentObject {
	// Méthodes communes à tous 
	// les interacteurs.
	void redraw();
	void acceptInput(const XEvent &);
	...
};

class pushButton: public interactor {
	// Méthodes spécifique à 
	// l'interacteur pushButton.
	void activate();
	bool enfonce();
	...
};

Un problème : le verrouillage des objets

La solution : un langage qui garantit le verrouillage

Commencons par définir la racine des interacteurs :

   protected type INTERACTOR_BEHAVIOUR is
     procedure REDRAW;
     procedure ACCEPT_INPUT(ITEM : in XEVENT);
   end INTERACTOR_BEHAVIOUR;

   type INTERACTOR is abstract 
	tagged limited record
	 OBJECT : INTERACTOR_BEHAVIOUR;
      end record;

A la différence du code C++ précédent, l'interacteur est ici un objet dont tous les accès sont automatiquement verrouillés (un protected record dans le jargon Ada). C'est aussi une classe abstraite au sens de C++. Le PushButton s'écrit :

   protected type PUSH_BUTTON_BEHAVIOUR is
     procedure ACTIVATE;
     function ENFONCE return BOOLEAN;
   end PUSH_BUTTON_BEHAVIOUR;
  
   type PUSH_BUTTON is new INTERACTOR with
      record
        ITEM : PUSH_BUTTON_BEHAVIOUR;
     end record;

Le PUSH_BUTTON hérite des méthodes de INTERACTOR, en l'occurrence les méthodes REDRAW et ACCEPT_INPUT.

Les ``protected records'' de Ada implémentent des moniteurs de Hoare avec la sémantique suivante : les fonctions sont à lecture seule, donc plusieurs agents (par exemple plusieurs utilisateurs) peuvent lire concurremment l'état du bouton (par la fonction ENFONCE). En revanche un seul peut, à un instant donné, modifier l'état du bouton (par la fonction ACTIVATE).

Plusieurs sources d'événements sont possibles, par exemple :

   task SERVER_X;
   task GRAPHIC_TABLET;

   task body SERVER_X is
      E : XEVENT;
   begin -- SERVER_X
      loop
	 GET_NEXT_EVENT(E);
	 DISPATCH_EVENT(E);
      end loop;
   end SERVER_X;

   task body GRAPHIC_TABLET is
      E : TABLET_EVENT;
   begin -- GRAPHIC_TABLET
      loop
	 GET_NEXT_EVENT(E);
	 DISPATCH_EVENT(E);
      end loop;
   end GRAPHIC_TABLET;

Les deux tâches s'exécutent en parallèle. La méthode DISPATCH_EVENT effectue présumément des appels aux méthodes des interacteurs (des appels d'entrées dans le jargon Ada). Si les deux sources d'événements opèrent sur des objets distincts, les opérations se déroulent concurremment. Si les deux tentent d'accéder simultanément au même objet, l'une d'entre elles est mise en attente.

Un langage concurrent riche tel que Ada fournit de nombreux mécanismes de synchronisation, qui peuvent être utilisés pour exprimer facilement des contraintes telles que ``Appuyer simultanément sur les boutons Record et Play''. Pour une revue complète de ces mécanismes, on consultera [4]. Nous nous contenterons d'indiquer ici comment exprimer une contrainte de temps :

   task VIDEO is
      accept VIDEO_FRAME(A_FRAME : in FRAME);
   end task;

   task body VIDEO is
   begin
      loop
	 select
	    accept VIDEO_FRAME
		(A_FRAME : in FRAME) do
	       DISPLAY(A_FRAME);
	    end VIDEO_FRAME;
         then abort
	   delay 0.1;
	 end select;
      end loop;

Dans cet exemple, la tâche obtient et affiche une trame en 0.1 seconde. Si l'opération ne peut être effectuée dans le temps imparti, l'opération est avortée.

Un autre avantage important, outre un verrouillage correct est l'efficacité : le compilateur peut construire un graphe d'utilisation des tâches pour optimiser l'allocation des ``threads'' de calcul, une opération relativement coûteuse. Ceci est pour le moins très difficile si la concurrence est fournie par une bibliothèque.

Notons que si le support du langage pour la concurrence est nécessaire, elle n'est pas suffisante. Le noyau exécutif du langage doit coopérer avec le système d'exploitation pour assurer le bon fonctionnement global. Par exemple, si l'ensemble des tâches Ada est implémenté à l'intérieur d'un seul processus Unix, un appel tel que XNextEvent (extraction du prochain événement de la file) est bloquant et bloque toutes les tâches, et non seulement celle qui exécute l'appel. A ce moment, c'est sans intérêt. Au contraire, si le noyau d'exécution affecte une ``thread'' du système d'exploitation à chaque tâche, seules celles qui sont en attente d'événements sont bloquées, pendant que les autres peuvent continuer à faire agir les autres objets.

CONCLUSION

BIBLIOGRAPHIE

1. Michel Beaudouin-Lafon and Philippe Brun. A taxonomy and evaluation of formalisms for the specification of interactive systems. In Proc. Of HCI'95, 1995.

2. Michel Beaudouin-Lafon and Joëlle Coutaz. Scoop / rapport de recherche 1994-1995. Technical report, SCOOP working group, 1995.

3. Grady Booch. Object-Oriented Analysis and Design. Benjamin Cummings, 2nd edition, 1994.

4. Alan Burns and Andy Wellings. Concurrency in Ada. Cambridge Press, 1995.

5. Stéphane Chatty. Extending a graphical toolkit for two-handed interaction. In Proc of ACM UIST'94, 1994.

6. Joëlle Coutaz. Interfaces Homme-ordinateur -- Conception et Réalisation. Dunod, 1990.

7. Adele Goldberg. Smalltalk-80 -- The Interactive Programming Environment. Addison-Wesley Publishing Company, 1984.

8. Charles A. R. Hoare. Monitors: An operating system structuring concept. Comm. ACM, 10:549--557, 1974.

9. ISO. Ada 95 reference manual. Technical report, 1995. ISO international standard ISO/IEC 8652:1995.

10. Mark A. Linton, John M. Vlissides, and Paul R. Calder. Composing user interfaces with InterViews. IEEE Computer, pages 8--22, February 1989.

11. Bertrand Meyer. Object Oriented Software Construction. International Series in Computer Science. Prentice Hall, 1988.

12. Laurence Nigay and Joëlle Coutaz. A design space for multimodal systems: concurrent processing and data fusion. In Proc. Of INTERCHI'93, pages 172--178, 1993.

13. John K. Ousterhout. TCL and the TK Toolkit. Addison-Wesley Publishing Company, 1994.

14. Bjärne Strøustrup. The design and evolution of C++. Addison-Wesley Publishing Company, 1994.