recours a l'interpretation abstraite pour la validation d'une demarche de specification de scripts de dialogues MONO-FILS, multi-fils et hypermedia

Efrem Mbaki Luzayisu
FUNDP-Institut d'Informatique
21, rue grandgagnage B-5000 Namur Belgique
Tel +32-(0)81-72 52 59 Fax +32-(0)81-72 49 67
emb@info.fundp.ac.be 
Résumé — L'expansion de l'ordinateur pour le traitement de tâches ménagères, éducationnelles et professionnelles, d'une part, et le développement des techniques d'interaction et des nouvelles technologies de l'information et de communication, d'autre part, sont à la base de la croissance spectaculaire de la qualité et de la quantité de l'interactivité  entre l'homme et l'ordinateur. Afin de mieux gérer cette évolution, des méthodes de conception d'interfaces s'avèrent indispensables. En vue de répondre partiellement à cette préoccupation, nous travaillons pour la construction  d'une méthodologie de spécification de dialogues mono-fils, multi-fils et hypermédia. Ce papier définit le contexte de nos recherches, présente notre démarche scientifique et montre pourquoi et comment nous utiliserons la théorie d'Interprétation Abstraite pour valider certains de nos résultats.                                                                                                                                                                                 Mots clé : dialogue, interface utilisateur, mono-fil, multi-fil, parallélisme, hypermédia, navigation, script, hyperliens.

1. Introduction
La qualité de l'interface utilisateur (IU) devient aujourd'hui un critère prépondérant de choix d'un logiciel au même titre que ses fonctionnalités. Dans un tel contexte, il nous semble impérieux de réfléchir sur  des méthodes de conception d'IU qui tiennent compte de cette réalité. Ainsi, de façon à répondre en partie à la préoccupation susmentionnée, nous visons à construire une méthodologie  de spécification des dialogues mono-fils, multi-fils et hypermédia. Il s'agit dans cette communication de présenter un cahier des charges d’un système de validation formelle de ces trois types des dialogues, système basé sur le principe d’interprétation abstraite.

Pour une meilleure ébauche, nous découpons cette communication en sept sections dont la première traite de trois sortes de dialogues (mono-fil, multi-fil et parallèle). La deuxième décrit les dialogues hypermédia. La troisième définit le contexte de nos recherches. La quatrième présente un exemple illustrant notre préoccupation. La cinquième aborde la spécification et la validation des scripts de dialogues. La sixième parle de l'implémentation de l'outil case que nous projetons de réaliser. La septième et dernière section présente succinctement l'état de nos travaux actuels.
2. Dialogues mono-fils, multi-fils et parallèles
Rappelons que l'IU d'une application informatique est la partie du programme de l'application que l'homme voit et avec laquelle il interagit  [9]. Les interactions entre un homme et une application via son IU constituent la conversation de l'application dite aussi dialogue homme-machine (DHM) relatif à l'application. Dans le cas où l'usager converse avec une seule IU, on parle 

de dialogue mono-fil. Mais, l'informatisation de la quasi totalité des tâches nécessitant un effort plus ou moins considérable de la part de l'homme et le fait que l'ordinateur soit utilisé pour des tâches tant ménagères, éducationnelles que professionnelles font qu' aujourd'hui, rares soient les utilisateurs d'ordinateur travaillant avec une seule application en exécution. La quasi totalité des sessions informatiques actuelles font appel à plusieurs programmes, logiciels ou collecticiels  simultanément. Dans un tel environnement, trois possibilités sont envisageables:
1.	malgré le lancement de plusieurs programmes, l'utilisateur décide de les exécuter séquentiel-lement. Il commence un "premier", le termine et passe au suivant et ainsi de suite. Dans ces conditions, on assisterait à une séquence de dialogues mono-fils;
2.	l'utilisateur interagit avec une seule IU à la fois mais peut, pour plusieurs raisons (de son propre gré, recherche d’une information manquante, complétude d’une tâche commencée,…)  interrompre l'IU courante et passer la main à une autre IU ouverte. Dans ce cas, le DHM est dit multi-fil [3];
3.	le système informatique utilisé, doté des mécanismes de parallélismes ou de multimodalités (sensori-visuelles ou gestuelles), permet à l'utilisa-teur d'interagir avec plusieurs IU à la fois. Ce genre des DHM de plus en plus courant est dit parallèle et, est difficile à gérer ou à modéliser.  
3. Dialogue hypermédia
L'hypertexte est une révolution dans la façon de gérer l'information et les connaissances. Il permet de relier, par des hyperliens, entre eux des milliards de documents et rend possible une navigation personnalisée infinie sur ce que l'on appelle "toile" (web); les infrastructures de transport à haut débit et les immenses capacités de stockage aujourd'hui offertes, comme la généralisation de l'usage individuel de l'ordinateur contribuent à créer les conditions les plus favorables pour un usage intensif et réellement novateur de cette technologie [4]. Les discussions sur des hyperliens portent essentiellement sur le caractère non linéaire de la navigation. Les chercheurs analysent et proposent des méthodes sur le comment aider l'utilisateur à naviguer avec les hyperliens sans qu'il soit complètement désorienter par rapport à son objectif. Dans la longue liste des techniques des traitements des hyperliens, nous retenons les trois suivants [11]: 

1.	la navigation orientée-concepteur.  Le concepteur se fonde sur sa vision globale des choses pour établir des liens sémantiques entre non seulement les différents composants de son IU, mais encore avec ceux d'autres IU. Le danger de cette technique provient du fait que les concepteurs des IU n'investissent pas tous les mêmes efforts dans la recherche des liens sémantiques. Et souvent, les concepteurs renvoient leurs utilisateurs vers d'autres sites hypermédia sans se donner la peine de valider la qualité  sémantique des hyperliens qui s’y trouvent.  Quand bien même il peut exister un bon plan de navigation pour l'application en soi, l'utilisateur pourrait se retrouver désorienté au cas où un hyperlien l’enverrait  vers une UI problématique (avec des liens totalement aléatoires). Suivant cette technique, le concepteur est le seul responsable de la bonne ou mauvaise navigation des utilisateurs;

2.	la navigation orientée-utilisateur. Sur base d'une enquête auprès d'un certain nombre d'utilisateurs experts d'une matière donnée, le concepteur réalise le plan de navigation hyperliens correspondant à l'IU de son application. Cette technique pose certainement problème pour un site ouvert dans la mesure où, qu'importe la matière considérée, il est quasiment impossible d'analyser un échantillon représentatif d'utilisateurs experts d'autant plus que le monde Web, fief de la navigation hypermédia, est un véritable toile international, un réseau de taille infinie. Ici, la responsabilité est partagée entre les utilisateurs experts qui auraient proposées des liens et le concepteur, le réalisateur des liens ;
  
3.	la navigation orientée-cas-raisonnés. Cette technique combine les avantages de deux premières susmentionnées et, ajoute un facteur intelligent. Sa particularité est qu’elle partage la responsabilité entre trois acteurs: le concepteur, l'utilisateur et le système [10]. L'idée est de disposer au départ d'un ensemble (une base) de plans de navigation proposés par le concepteur ou des experts utilisateurs. A l’exploration, pour un utilisateur donné, un plan de navigation tiré de la base lui est proposé en fonction de son profil et de ses  perspectives courantes. Suivant  le parcours de l’exploration, le système, non seulement augmente, diminue ou modifie l’espace de navigation mais aussi, met à jour sa base de plans de navigation au cas où il capterait de la part de l’utilisateur des nouvelles intentions non encore envisagées.
4. Définition du contexte  de nos recherches
Nos recherches portent essentiellement sur les dialogues mono-fils, multi-fils et hypermédia. Il s'agit de construire une méthodologie intégrant la spécification de ces trois types de dialogues. La motivation d'un tel sujet se justifie par les caractéristiques actuelles des DHM qui, deviennent de plus en plus interactifs et très diversifiés. Et cela, avec une qualité (d'image, de son, de formulaire,…) de plus en plus excellente. Cette évolution  est due par le progrès constant des technologies de l'information et de la communication (TIC) et des technologies d'interaction (TI). Ne pouvant aborder le sujet dans toute sa généralité, nous nous limitons aux applications  de gestion hautement interactives. Et donc, nos UI ne contiendront que des objets interactifs de type formulaire (fiche, label, edit, group box, combobox,…). 
Mais, il faut insister sur le fait que nous nous intéressons seulement à la spécification des dialogues et, n'abordons pas l'aspect présentation. L'approche utilisée pour gérer les hyperliens est plus ou moins un mélange  de la navigation orientée-concepteur et la navigation orientée-utilisateur.
 
En effet, partant de l'analyse de la tâche et respectant les contraintes de la méthodologie TRIDENT (tool for an interactive development environment) dans le cas mono-fil [7], nous obtenons une modularisation (une architecture) hiérarchique à quatre niveaux: niveau du coordinateur principal (niveau 0), niveau des tâches (niveau 1), niveau des sous-tâches (niveau 2) et niveau des sous-sous-tâches (niveau 3). Comme son nom l’indique, le coordinateur principal est le patron de l’architecture ; il a pour tâche le pilotage de la hiérarchie en créant, supprimant, activant et désactivant des instances de tâches  et des liens inter tâches. Si ces dernières sont gérées par le coordinateur principal, elles sont à leur tour coordinatrices de sous-tâches; chaque composant tâche de l’architecture est responsable du bon déroulement des échanges et d’ordonnancement d’exécution de  ses sous-tâches. Ces dernières jouant le même rôle pour les composants de niveau 3. 

De ce qui précède, le plan de navigation d'une application multi-tâches contient deux types de liens: des liens linéaires et  non linéaires ou hyperliens.  Les premiers (linéaires) sont directement déduits de l'énoncé textuel et de l'analyse de la tâche.  Ayant opté de spécifier les scripts suivant l'approche orienté-objet, nous munissons chaque composant coordinateur de l'attribut AT_SCENARIO dont le contenu est un système de propositions logiques indiquant des liens chronologiques et synchroniques de ses (sous-) tâches. Les liens non linéaires proviennent de l'expérience des utilisateurs routiniers qui, informent le concepteur d'éventuels liens ou connections qu'ils auraient exploités ou souhaiteraient avoir dans l'IU. Pour la spécification,  nous munissons chaque objet de l'architecture d'un attribut AT_HYPERLIENS dont le contenu est un ensemble des hyperliens activables à partir  de cet objet. 
Ainsi, le plan de navigation complet d’une application multi-tâches sera  conçu en instanciant l’architecture (navigation orientée-concepteur) et en considérant  les éventuels hyperliens inter (sous-) tâches (navigation orientée-utilisateurs). Pendant l’exécution ou l’exploration d’un composant de l’architecture, si l’utilisateur manifeste l’intention  de sauter vers un autre composant, à condition que le plan de navigation le prévoit, le composant en exécution ou visité informe son coordinateur  de l’intention de l’utilisateur. Si le coordinateur courant a en charge le composant ciblé, il répond automatiquement au besoin de l’utilisateur. Sinon, lui aussi à son tour informe son supérieur de l’intention de l’utilisateur. Ce scénario continuera jusqu’à ce que  le composant visé soit atteint. 

Par exemple, supposons que l'objet relatif à la sous-tâche ST2 de la figure 1 ci-dessous dispose d'un hyperlien vers l'objet de la sous-sous-tâche SST111. 

Figure1— Architecture d'une application Multi-tâches
L'activation de cet hyperlien produira une séquence d'événements (evt) et de primitives (pr) illustrée dans la figure 2.

Figure2—Séquence d'ouverture de SST111 partant de ST21.
Pour que notre  système fonctionne sans embûches, nous nous limitons dans le cadre d’un intranet (un réseau local) d’une entreprise de gestion. Dans ces conditions, nous sommes sûr que les différents coordinateurs de l'architecture décrite ci-dessus n’auront à gérer autres composants que ceux contenus dans la hiérarchie. 
5. Exemple illustrant le besoin méthodologique
Une ASBL (Association Sans But Lucratif) de la Belgique offre un certains nombre de services aux Malades dont :
1.	le déplacement (simple ou aller-retour ) de la maison vers une institution hospitalière pour des soins médicaux ou une hospitalisation;
2.	le transfert d’un malade d’un hôpital vers un autre ;
3.	la garde à domicile d’un malade ;
4.	la réalisation des courses pour un malade ;
5.	l’encadrement d’un groupe de malades lors d’une visite guidée ou un voyage récréatif,…

Ces services sont rendus en complicité avec des Bénévoles qui, sont des volontaires recrutés par l’ASBL. Aussi, Cette dernière utilise, entre autres, six programmes informatiques aidant chacun   à la gestion de  l’une de six tâches suivantes : la Gestion des Malades (T1), le Transport des Malades (T2), la Gestion des Bénévoles (T3), la  Comptabilité générale (T4), l’Atlas routier électronique (T5) et le Courrier électronique (T6). Bien qu’autonomes, ces programmes sont inter dépendants car, par exemple, pour enregistrer une demande de transport, l'agent de l'ASBL doit exécuter le programme relatif à la gestion des malades pour vérifier si la personne qui téléphone ou pour qui on téléphone  est bel et bien membre de l'ASBL et, est en ordre des cotisations. Une fois que la demande est enregistrée,  l'agent procède à une proposition d'affectation. Pour y parvenir, d'abord, il lance la recherche d’un Bénévole par code postal ou par disponibilité et ensuite, il téléphone ou envoie un e-mail au bénévole trouvé. Une connexion hypermédia vers l’atlas routier  électronique  peut servir  pour aider un bénévole à décider sur une proposition de demande de transport qui lui est affectée. De même, au service de Comptabilité, le calcul de la prime d’un bénévole ou de la facture d’un malade se fait sur base des informations recueillies auprès de services de Gestion des Bénévoles, de Gestion des Malades et celui de Transport des  Malades. 

Les connexions qui existent entre les différentes tâches ainsi que les exigences techniques de programmes utilisés rendent les DHM multi-fils et hypermédia. La méthodologie à construire doit pouvoir aider à la spécification des DHM d'une telle application.
6. Spécification et validation des scripts de dialogues
Comme nous pouvons le comprendre, une bonne gestion de dialogues relatifs à l’architecture présentée ci-dessus dépend fortement du langage utilisé pour décrire les actions des différents coordinateurs. En ce qui nous concerne, nous optons pour  une notation spéciale; Le script relatif à un coordinateur est décrit sous forme d’un système de propositions  contenant de connecteurs logiques (ET, OU, NEGATION, et IMPLICATION ) ainsi que des symboles de déclenchement,  d'ordonnancement  et de terminaison de sous-scripts. Un effort considérable est fourni pour que les connecteurs logiques gardent plus ou moins leur sémantique usuelle et que chaque proposition du  système ait une valeur de vérité (ou une valuation) VRAIE avant, pendant et après l’exécution du script. Une façon d’analyser la cohérence d’un script serait d’utiliser un outil abstrait pouvant vérifier l'invariance de  la valuation d’un script avant, pendant et après son exécution. Il suffirait donc qu'en un instant donné,  une proposition ait une valuation FAUSSE pour conclure de l'incohérence du script correspondant. 

Etant donné qu'une telle analyse, pour être indépendante d'une plate-forme d'implémentation, doit se faire en dehors de l'exécution proprement dite du script, nous utiliserons l’interprétation abstraite (IntAb) qui, se définit comme une méthodologie générale pour exprimer des analyses statiques ; des traitements que l’on peut appliquer à une spécification en dehors de son implémentation proprement dite [2]. L’objectif de l'IntAb est de déduire du texte d'une spécification (d'un programme) des informations permettant de l'optimiser ou de vérifier certains aspects de correction [5,6] . Le principe de base de la méthode est d'exécuter la spécification (le programme) sur un domaine abstrait au lieu de l'exécuter sur le domaine de calcul normal. Cependant deux hypothèses doivent être satisfaites:
1.	les éléments du domaine abstrait représentent des propriétés utiles du domaine standard;
2.	les calculs sur le domaine abstrait doivent être réalisés de manière suffisamment efficace et doivent converger en un temps fini.

Par rapport à notre objectif, nous prendrons comme valeurs abstraites,  les valuations de (sous-)scripts et de propositions logiques. Les calculs se feront suivant les versions abstraites de nos symboles spéciaux et connecteurs logiques. Pour systématiser (automatiser) ces calculs, nous proposerons un algorithme général pour lequel nous montrerons l'admissibilité (qu'il donne bien les résultats escomptés), l'optimalité (qu'il est le meilleur ou l'un des meilleurs qui puissent être utilisés) et la terminaison (qu'il se termine en un temps fini). 
7. Implémentation
Parmi les critiques formulées en l'encontre de techniques de spécification formelle, nous pouvons citer la difficulté qu'ont les concepteurs à les appliquer à cause de leur attachement au langage mathématique non accessible au commun des mortels.  Pour échapper à cette remarque, nous pensons réaliser en Java un outil case graphique d'apprentissage pour la méthodologie à construire. Profitant des nouvelles techniques multimédia et d'interaction, nous rêvons réaliser un outil convivial, très interactif et ergonomique pouvant être utilisé, d'une part, par des experts concepteurs en Interface Homme-Machine (IHM) et, d'autre part, par des étudiants en science informatique. Par rapport à la seconde utilisation, cet outil consisterait un élément du projet VESALE ( visual user interface design education supported by a computer-

aided learning environment) [1] qui, vise à définir un environnement multimédia pour l'enseignement du cours d'IHM.
8. Travaux actuels
Après avoir  étendu l'architecture de TRIDENT de telle sorte qu'elle supporte non seulement les dialogues mono-fils, mais aussi multi-fils et hypermédia et, spécifier les attributs, événements et primitives des objets utilisés dans l'architecture étendue [8], nous cherchons présentement à clarifier :
1.	Les domaines concret et abstrait des analyses statiques à réaliser;
2.	Les opérations d'abstraction et de concrétisation pour le passage du domaine concret vers le domaine abstrait et inversement;
3.	Les opérations concrètes et abstraites élémentaires ainsi que l'algorithme général de calcul.

Parallèlement, nous réfléchissons sur les types des données et sur les différentes structures statiques et dynamiques du langage de règles devant piloter l'outil case à implémenter.

Bibliographie 
 [1] 	Bodart F.et al. (Equipe VESALE), VESALE: document de spécification, Institut d'Informatique, FUNDP, Mars 1999 http://www.info.fundp.ac.be/~emb/FrnSpec.doc 
[2] P. Cousot and R. Cousot, Abstract interpretation: A unified lattice model for static analysis of programs by construction or approximation of fixpoints. In Conference Record of Fourth ACM Symposium on Programming Languages (POPL' 77), pages 238-252, Los Angeles, California, January 1977.
 [3] Hill, R. : Event-Response Systems – A Technique for Specifying Multi-Threaded Dialogues. In Proceedings of ACM Conference on Human Factors in Computing Systems and Graphics Interface CHI+GI’87 (Toronto, 5-9 April 1987). ACM Press, New York (1987) 241-248. 
[4] Jean Michel, Les NTIC, les NTE: Pour une réflexion collective sur leur impact dans les formations d'ingénieurs, ENPC (Paris), http://wwwparis.enpc.fr/~michel-j/tic-nte.html
[5] Le Charlier B., L'Analyse Statique des Programmes par Interprétation Abstraite, Nouvelles de la Science et des Technologies, 9(4):19-25, 1992
[6] Le Charlier B.,  Abstract Interpretation and Application to Interactive System Verification, Design, Specification and Verification of Interactive Systems '96, Namur, Belgium, pp 46--72, 1996. 
[7] Leheureux J.-M., Architecture logicielle de la méthode TRIDENT, Institut d’Informatique (FUNDP), Namur, 1995
[8] Mbaki Luzayisu E., Extending software architecture and dialog’s objects specification in TRIDENT methodology,  Institut d’Informatique (FUNDP), 1999.
[9] Myers B. A., User Interface Software Technology, ACM Computing Surveys, Vol. 28, N°1, March 1996
 [10] Stein A., Thiel U. and Tien A., Towards Coherent Hypermedia Navigation by Pragmatic Dialogue Modeling, GMD-Forschungszentrum Informationstechnik GmbH, october 1991
 [11] Graphics,Visualization, & Usability (GVU) Center’s Word Wide Web User Surveys – GVU’s www User Survey Published Papers. Présentation et résultats de différentes études réalisées auprès d’utilisateurs du Web : http://www.cc.gatech.edu/gvu/user_surveys/papers/