Technique et Science Informatique 14, no. 4 (1995)...

Palanque, Philippe and Bastide, Rémi. "Spécifications formelles pour l'ingénierie des interfaces homme-machine." Technique et Science Informatique 14, no. 4 (1995) 473-500..

Authors address: LIHS, Université Toulouse 1, Place Anatole France, F-31042 Toulouse CEDEX, France Contact Email: [email protected] Keywords: Formal specification, User Interface Design, Objects, Petri Nets. Abstract: The design of the dialogue structure of user-driven interfaces proves to be a difficult task. The

use of a formal specification technique is of great help by providing non-ambiguous, complete and concise descriptions. The usability of a formalism is increased if it provides formal analysis techniques that allow to prove properties about the design, thus giving an early validation of this design before the application is actually implemented. This paper presents such a formalism, called Interactive Cooperative Objects (ICO). It is an object-oriented language where the behavior of objects is described by high-level Petri nets. The paper first presents the characteristics of user-driven applications and introduces the potential benefits of the use of our formalism for the design of such applications. The formalism is then used on a case study, stating the properties that may be mathematically proven.

mailto:[email protected]

RECHERCHE

Spécifications formelles pour l'ingénierie des interfaces homme-machine Philippe Palanque, Rémi Bastide LIS - Université Toulouse I Place Anatole France 31042 TOULOUSE CEDEX Email: [email protected] - [email protected]

RESUME. La définition de l'interaction homme-machine dans les interfaces contrôlées par l'utilisateur est une tâche particulièrement difficile. L'utilisation d'une technique de spécification formelle est d'une grande utilité en fournissant des modèles complets, non-ambigus et cohérents. Les avantages de l'utilisation d'un formalisme sont accrus s'il offre des techniques d'analyse formelle permettant de prouver des propriétés sur la conception, favorisant ainsi une validation du fonctionnement de l'application avant sa mise en œuvre. Cet article présente un tel formalisme, appelé Objets Coopératifs Interactifs (ICO). Il s’agit d’un langage à objets dans lequel le comportement des objets est décrit par des Réseaux de Petri de Haut Niveau. L'article présente tout d'abord les caractéristiques des applications contrôlées par l'utilisateur et met en avant les avantages potentiels de l'utilisation de ce formalisme pour la conception de telles applications. Ensuite, ce formalisme est appliqué à un cas réel en détaillant les propriétés qui peuvent être mathématiquement analysées.

ABSTRACT. The design of the dialogue structure of user-driven interfaces proves to be a difficult task. The use of a formal specification technique is of great help by providing non-ambiguous, complete and concise descriptions. The usability of a formalism is increased if it provides formal analysis techniques that allow to prove properties about the design, thus giving an early validation of this design before the application is actually implemented. This paper presents such a formalism, called Interactive Cooperative Objects (ICO). It is an object-oriented language where the behavior of objects is described by high-level Petri nets. The paper first presents the characteristics of user-driven applications and introduces the potential benefits of the use of our formalism for the design of such applications. The formalism is then used on a case study, stating the properties that may be mathematically proven.

MOTS-CLES : Spécification formelle, Conception d'Interfaces Homme-Machine, Objets, Réseaux de Petri. KEY WORDS : Formal specification, User Interface Design, Objects, Petri Nets.

Technique et Science Informatique, 14 (4) 473-500, 1995

2

1. Introduction

La majorité des applications interactives développées à l'heure actuelle proposent à l'utilisateur un type d'interface graphique que l'on qualifie par l'acronyme anglo-saxon WIMP (Windows, Icons, Menus and Pointing). C'est pour ce type d'interfaces que les premiers standards de présentation et d'interaction ("look and feel") ont été définis et largement diffusés [IBM 89, OSF 89, SUN 85].

De par leurs qualités ergonomiques (facilité d'utilisation, concision, cohérence, flexibilité, ...), ces interfaces ont immédiatement acquis la faveur des utilisateurs.

Une des raisons principales de ce succès provient du fait que l'utilisateur reste maître de l'interaction avec l'application tout au long de la session de travail. D'un point de vue informatique on dit que ces applications relèvent de la programmation par événements ; d'un point de vue ergonomique, on qualifie ces applications de contrôlées par l'utilisateur.

Dans ce type d'interfaces, toute commande peut être initiée au moyen d'un élément graphique accessible par manipulation directe (icône, menu, bouton, ...). Ainsi, l'ensemble des commandes de l'application peut être visualisé à tout moment, réduisant d'autant la charge cognitive de l'utilisateur. L'interaction se caractérise à la fois par une grande liberté d'action (toute action licite à un instant donné est activable et présentée comme telle à l'utilisateur) et un niveau de guidage important (les actions illicites à un instant donné sont inactivables).

La mise en œuvre de ce type d'interfaces apporte toutefois une complexité nouvelle à la tâche des concepteurs. Pour le concepteur de telles interfaces la principale difficulté réside dans la conception du dialogue entre l'utilisateur et l'application. Le support de la communication entre ces deux interlocuteurs peut être considéré comme un langage et à ce titre peut être décrit en termes de lexique, syntaxe et sémantique. Ainsi, la conception du dialogue nécessite à la fois l'explicitation du langage d'interaction et de la répartition de la prise de parole dans cette interaction (c'est-à-dire la gestion de l'alternance du rôle d'émetteur et de récepteur entre l'homme et l'application). La conception du dialogue constitue l'objectif principal de cet article et les aspects lexicaux et sémantiques ne seront donc abordés que succinctement. Nous considérons que la partie lexicale est à la charge d'outils de type Systèmes de Gestion d'Interfaces Utilisateurs (SGIU) et que la partie sémantique est conçue par des techniques d'analyse à objets. Dans notre approche, la conception du dialogue exploite un formalisme (les Objets Coopératifs Interactif ou ICO, pour interactive Cooperative objects) fondé sur les réseaux de Petri et l'approche à objets. Les ICO sont définis de manière formelle, ce qui permet de décrire le dialogue de l'application de façon complète et non ambiguë tout en offrant la possibilité de vérifier mathématiquement les modèles.

Cet article commence par caractériser précisément le type d'interface que le formalisme des ICO vise à décrire (section 2). Les sections 3 et 4 exposent les problèmes spécifiques à la conception de telles interfaces et justifient l'introduction de ce nouveau formalisme. La section 5 est dédiée à la présentation du formalisme lui-même. La deuxième partie de l'article expose les principales facettes du


3

formalisme sur une étude de cas dans laquelle nous présentons tout d'abord la spécification de l'étude de cas puis sa conception (section 6) et enfin sa validation formelle (section 7).

2. Caractérisation des interfaces contrôlées par l'utilisateur

Les applications proposant une interface dirigée par l'utilisateur doivent être considérées comme des systèmes réactifs (par opposition à transformationnels [PNU 86]). Ces applications sont passives par rapport à leur environnement et réagissent aux stimuli qu'elles en reçoivent en déclenchant des opérations internes. D'une manière générale, le contrôle de l'application est externe, c'est-à-dire que l'application ne prédéfinit aucune séquence d'opérations, et se contente de répondre aux requêtes qu'elle reçoit. De plus, l'application ne réclame jamais de donnée à l'utilisateur, ce qui obligerait celui-ci à répondre avant d'avoir la possibilité d'effectuer une autre action. La seule exception à cette règle se produit dans le cas où une confirmation ou un paramètre complémentaire sont absolument nécessaires ; l'acquisition de cette information se fait alors par l'intermédiaire d'une fenêtre modale, qui interdit temporairement toute interaction avec le reste de l'application. Bien entendu le concepteur doit s'attacher à minimiser ce style d'interaction afin de respecter le caractère "contrôlé par l'utilisateur" de l'interface.

Lire évt

Ventiler évt

Non Terminé

INIT

Oui

FIN

Traite-1 évt

Traite-i évt ...

Traite-n évt

Traite-2 évt . . . . . .

Dialogue Etat du

Flot de contrôleFlot de données

Filed'événements

Figure 1. Structure de contrôle d'une application contrôlée par l'utilisateur

Une application contrôlée par l'utilisateur présente une structure "à plat" composée d'un ensemble de procédures de traitement d'événements ("traite-événements" ou "event-handlers") qui ne s'invoquent pas mutuellement (voir figure 1). Un module dédié, appelé gestionnaire d'événements et conceptuellement externe à l'application, gère une file d'attente d'événements et assure leur interprétation en distribuant cycliquement chacun d'entre eux au traite-événements approprié.


4

Traite-événements-Evt1; Evaluation de la précondition Accès en lecture aux variables d'état pour déterminer

l'action sémantique à réaliser Action sémantique Exécution de l'action sémantique choisie et

récupération des résultats Mise à jour de l'état Accès en écriture aux variables d'état, en fonction des

résultats obtenus Mise à jour de la présentation Mise en évidence du nouvel état sur la présentation

(activation / désactivation de commandes) Fin de Evt1.

Figure 2. Fonctionnement et structure générique d'un traite-événements

Dans la plupart des systèmes de gestion d'interfaces utilisateur (SGIU) la boucle de gestion d'événements et la file d'attente sont masquées aux concepteurs qui s'attachent seulement à concevoir les traite-événements et à les associer aux différents éléments de manipulation de l'interface (boutons, éléments de menu, ...).

Ces traite-événements ont un fonctionnement caractéristique décrit sur la figure 2. Lorsqu'un événement est transmis à un traite-événements, celui-ci détermine, en fonction de ses conditions d'activation et de la valeur des variables d'état, l'action sémantique à effectuer en réponse. Il exécute cette action sémantique, en reçoit le résultat, met à jour les variables d'état en fonction de ce résultat et fournit une rétroaction à l'utilisateur ("feed-back").

On peut résumer les différences entre applications directives et applications contrôlées par l'utilisateur par le tableau de la figure 3.

Type d'application

Caractéristiques Directive Contrôlée par

l'utilisateur ! Structure de l'application Contrôle centralisé

entrées distribuées contrôle distribué

entrées centralisées " Nature du contrôle Impérative déclarative

# Nature de l'application Transformationnelle Interactive / réactive

$ Rôles respectifs de l'utilisateur et de l'application dans la communication

Application = client Utilisateur = serveur

Application = serveur Utilisateur = client

Figure 3. Comparaison entre applications directives et applications contrôlées par l'utilisateur

! Les applications directives ont une structure de contrôle centralisée (décrite par les structures de contrôle conventionnelles des langages de programmation) et des entrées distribuées dans tout le code. Au contraire, dans les applications contrôlées par l'utilisateur, le contrôle est distribué et les entrées (qui se limitent à des événements déclenchés par l’utilisateur) sont centralisées (voir figure 1). La boucle de gestion des événements est le seul lieu où des entrées sont reçues. Les différents traite-événements coopèrent par des accès en lecture/écriture à un


5

ensemble de variables qui déterminent l'état courant du dialogue entre l'application et l'utilisateur (voir figure 2).

" Le contrôle dans les applications directives est décrit au moyen des structures de contrôle des langages algorithmiques. Les techniques de décomposition fonctionnelle descendantes s'appliquent assez bien à la conception du contrôle de ces applications. Le rôle du concepteur est de décrire par un algorithme structuré l'ensemble de tous les enchaînements d'actions possibles depuis l'initialisation de l'application jusqu'à sa terminaison, d'où le qualificatif "impératif" donné au contrôle. Au contraire, dans les applications contrôlées par l'utilisateur, la structure de contrôle est décrite de manière "déclarative" : cette structure ne peut être comprise qu'en examinant les interactions entre un ensemble de variables d'état et les traite-événements qui accèdent à ces variables. L'espace d'états du dialogue est déterminé par un ensemble de variables d'état partagées par les différents traite-événements (voir figure 2).

# Les applications directives sont qualifiées de transformationnelles dans la mesure où elles peuvent être considérées comme des boîtes noires qui fournissent toujours le même résultat en fonction des entrées qu'elles reçoivent. Les applications contrôlées par l'utilisateur, par contre, sont par nature réactives dans la mesure où les résultats qu'elles fournissent dépendent à la fois des entrées reçues, de l'état courant de l'application et des interactions ayant lieu durant le processus d'élaboration du résultat.

$ La meilleure manière de caractériser la différence fondamentale entre les applications directives et celles contrôlées par l'utilisateur est de caractériser les rôles respectifs de l'utilisateur et de l'application dans le cadre de la relation client serveur qui les lie. Une application directive considère l'utilisateur comme un serveur auquel elle réclame des informations, le plus souvent au moyen de primitives d'entrée bloquantes. A l'opposé, une application contrôlée par l'utilisateur reste passive par rapport à celui-ci et se contente de réagir à ses invocations, adoptant ainsi le comportement d'un serveur. L'utilisateur joue le rôle de client dans la mesure où il décide lui-même des services que l'application doit rendre et de leur enchaînement.

3. Les problèmes de l'ingénierie des interface homme-machine

Des problèmes spécifiques se posent tout au long du cycle de développement d'une application possédant une interface homme-machine contrôlée par l'utilisateur.

De nombreux modèles d'architecture ont été proposés pour les applications interactives. Le modèle ayant eu l'impact le plus important auprès des concepteurs d'application est sans nul doute le modèle de Seeheim [GRE 86]. Ce modèle structure la communication homme-machine en trois composants conceptuels pour l'IHM : la présentation, le dialogue, et l'interface du noyau fonctionnel (voir figure 4).

Une analogie a souvent été faite entre cette structure à trois composants et les trois niveaux classiques de description des langages : niveau lexical, niveau syntaxique et niveau sémantique. De nombreuses mises en gardes [BEA 91] ont déjà


6

été formulées à l’encontre d’une prise en compte trop littérale de cette structuration. Cette interprétation a servi de motivation pour l’usage de techniques de description de langages dans le cadre de la conception des IHM. Nous montrons en section 4.1 les limitations de ce type d’approches mais la distinction entre lexique, syntaxe et sémantique nous paraît significative (à un niveau conceptuel) pour caractériser le rôle des différents composants du modèle de Seeheim.

Presentation Dialogue fonctionnelUtilisateur

Composant Contrôleur Interfacedu noyaudu fonctionnel

Noyau

Figure 4. Le modèle de Seeheim

• Le composant Présentation prend en charge les aspects lexicaux de la communication homme-machine, à la fois en entrée et en sortie. Ce composant gère les interactions physiques et doit transformer les actions de l'utilisateur en unités de dialogues plus abstraites.

• Le composant Dialogue supporte les aspects syntaxiques de l'interaction. Il structure l'interaction homme-machine à un haut niveau, et assure la répartition du contrôle entre l'utilisateur et le système. Il joue le rôle de médiateur entre le composant Présentation et le composant Interface du Noyau Fonctionnel.

• Le composant Interface du Noyau Fonctionnel donne une interprétation sémantique aux informations reçues du composant dialogue. L'exécution de l'action sémantique ainsi construite est à la charge du noyau fonctionnel lui-même.

Le composant Dialogue pose des problèmes particuliers, du fait des

caractéristiques spécifiques (détaillées plus haut) des applications offrant une interface contrôlée par l'utilisateur. Le travail présenté ici porte principalement sur l'ingénierie de ce composant et propose une méthode formelle couvrant les différentes étapes de son cycle de développement : spécification, conception, validation. Les sections 3.1 et 3.2 présentent les problèmes spécifiques posés par le composant Dialogue pour chacune des phases ci-dessus.

Les techniques habituellement mises en oeuvre dans le cadre du génie logiciel (et

notamment l'approche à objets) sont exploitables pour la conception du Noyau Fonctionnel et de l'Interface du Noyau Fonctionnel. Les phases de spécification, conception, validation et implémentation du composant Interface du Noyau Fonctionnel et du Noyau Fonctionnel lui-même ne seront pas abordées dans cet article. Nous avons montré dans [PAL 93a] comment le formalisme proposé dans cet article s'intègre dans une démarche de conception où ces deux composants sont spécifiés et conçus par des techniques à objets.


7

Pour le composant Présentation les phases de spécification, conception et implémentation ne peuvent être facilement distinguées, car la construction de ce composant s'appuie sur un ensemble de règles ergonomiques [SCA 86] et de normes de présentations (User Interfaces Guidelines [IBM 89]) qui guident la tâche du spécifieur. De plus, avec l'utilisation des éditeurs intégrés dans les SGIU, la spécification de la représentation externe de l'interface se résume à une tâche d'édition graphique. Les divers outils intégrés dans les SGIU interprètent cette représentation externe et génèrent directement le code qui implémente ce composant. Les tâches de conception et d'implémentation sont ainsi réalisées de manière semi-automatique.

La validation du composant présentation est du ressort des travaux d'ergonomie et de psychologie cognitive. Cette validation a pour but de s'assurer de l'adéquation de la présentation aux caractéristiques intrinsèques de l'utilisateur, et est réalisée par l'analyse des interactions d'un groupe d'utilisateurs avec l'interface. Pour ce faire deux dimensions sont à considérer : le choix des éléments de manipulation [VAN 93], et la disposition spatiale des éléments de manipulation à l'intérieur d'une fenêtre et entre différentes fenêtres de l'application [KIM 93].

3.1. Spécification du composant Dialogue

La spécification du composant Dialogue concerne plusieurs aspects : la description du langage de commande et la description des interactions entre le système (l'application que l'on spécifie) et son environnement (l'utilisateur).

• Le langage de commande de l'interface correspond à l'ensemble des séquences valides de commandes. Ces séquences peuvent être décrites en spécifiant l'ensemble des états possibles pour le dialogue et leurs relations [COU 90 p141]. De nombreux formalismes tels que les grammaires hors-contexte [AHO 86, OLS 83], les diagrammes d'états et leurs dérivés [WAS 85, KIE 83, JAC 86] ont été utilisés pour modéliser le dialogue dans l'interaction homme-machine. Ces formalismes, adéquats pour la modélisation des applications directives, atteignent leurs limites dans le domaine des interfaces contrôlées par l'utilisateur (cf. section 4). Ils sont en effet mal adaptés à la modélisation d'activités concurrentes (particulièrement nécessaire pour les dialogues multi-fils), manquent souvent de mécanismes permettant de structurer les modèles et de prendre en compte l'aspect structure de données. Un certain nombre d'extensions, visant à remédier aux problèmes de ces formalismes ont été proposés, malheureusement le plus souvent au détriment de leur définition formelle. Pour illustrer ce propos, on peut citer [VAN 88] qui remarque que de nombreuses extensions apportées aux automates à états ont simplement pour but de leur donner un pouvoir d'expression approchant celui des réseaux de Petri.

• Toute spécification se doit de décrire l'interaction entre le système spécifié et son environnement. Dans le cadre des IHM contrôlées par l'utilisateur cette spécification a des caractéristiques particulières : l'environnement est un être humain dont le comportement n'est pas modélisable. De plus, on souhaite donner à l'utilisateur le plus de liberté d'action possible dans ses interactions avec l'application, ce qui a pour effet d'accroître la difficulté de cette étape qui est


8

particulièrement critique dans la mesure où la qualité de sa réalisation détermine l'utilisabilité de l'application.

3.2. Conception, implémentation et validation du composant Dialogue

La conception et l'implémentation du composant Dialogue posent des problèmes particuliers dans le cadre d'applications contrôlées par l'utilisateur. En effet, seules les techniques relevant de la programmation par événements permettent une implémentation efficace de telles applications. La mise en oeuvre de ces techniques pose des problèmes que l'on ne rencontre habituellement que dans le cadre de la conception d'applications réactives.

De même, le dialogue des applications contrôlées par l'utilisateur se prête mal aux techniques conventionnelles de test. En effet, ces techniques supposent que l'on peut considérer les composants logiciels comme des boîtes noires transformationnelles qui traitent des données en entrée et produisent des résultats qui peuvent être comparés à des valeurs nominales. Comme nous l'avons expliqué précédemment, l'état de l'application est déterminant pour caractériser les interactions futures. Les outils de test disponibles, qui prennent uniquement en compte les entrées de l'utilisateur et les résultats produits sur l'écran, ne permettent pas de valider entièrement le fonctionnement de ce composant. En effet, si l'état n'est pas pris en compte lors du test, seules les séquences de commandes explicitement testées peuvent être considérées comme validées. On ne possède pas d'information sur la validité d'un ordonnancement différent des mêmes commandes ou d'une séquence de commandes incluant celle testée. Dans le cadre des applications contrôlées par l'utilisateur le nombre des commandes disponibles est très grand et leur séquencement n'est pas imposé. On est donc confronté à l'explosion combinatoire des séquences de commandes qu'il serait nécessaire de tester.

Les méthodes formelles ont pour but de donner une description en intention de l'espace d'état et les techniques de validation raisonnent sur cette description sans énumérer explicitement l'ensemble des états possibles, ni les séquences de commandes conduisant à ces états. Un autre intérêt est de permettre la preuve d'un certain nombre de propriétés sur les modèles avant leur implémentation. Certaines des propriétés que notre approche permet de vérifier sont présentées en section 7.1.1.

4. Les approches formelles dans les interfaces homme-machine

Les problèmes liés à l'ingénierie des systèmes interactifs, que nous avons détaillés en section 3, sont aujourd'hui largement reconnus et bien identifiés. Les travaux dans ce domaine sont nombreux, et bien que partant des mêmes constatations empiriques, proposent des points de vue et des solutions remarquablement variés.

Malgré cette grande diversité, on peut dégager des constantes dans les approches proposées, ce qui nous paraît témoigner du fait que l'on s'approche d'une bonne maîtrise du domaine et de ses caractéristiques. Dans les approches les plus récentes, on constate toujours les caractéristiques suivantes :


9

• une exigence de formalisation : les approches simplement fondées sur l'utilisation d'outils, d'aussi haut niveau soient-ils, ont montré leurs limites. La plupart des propositions récentes s'appuient explicitement sur des approches formelles, en utilisant le plus souvent des formalismes généraux plutôt que de proposer des notations ad hoc. La conception du dialogue bénéficie ainsi des avancées réalisées dans d'autres domaines du génie logiciel ;

• la prise en compte des aspects "structures de données" et "structures des traitements" : les paradigmes de l'approche à objets ont clairement fait apparaître qu'on ne peut maîtriser la conception d'un système sans prendre en compte ses aspects statiques (ou structurels) en même temps que ses aspects dynamiques (ou comportementaux). Les méthodes formelles de conception d'IHM intègrent donc toutes ces deux composantes, souvent en tentant de marier le plus harmonieusement possible deux formalismes dédiés chacun à l'un de ces deux aspects ;

• l'introduction de mécanismes de structuration : comme n'importe quel autre composant logiciel, l'interface doit être intelligible, réutilisable et maintenable. Tout formalisme se doit donc d'introduire des mécanismes de structuration et de composition, afin de produire des composants de taille suffisamment réduite pour que leur validation soit simple et qu'ils restent compréhensibles. Cette structuration doit autoriser et favoriser la construction de nouvelles interfaces à l'aide de composants prédéfinis et parfaitement spécifiés, et permettre la modification ou l'extension aisées d'interfaces déjà construites ;

• la prise en compte explicite du parallélisme : ce point peut paraître surprenant au premier examen. Tout d'abord, les interfaces sont souvent mises en œuvre au moyen de langages de programmation conventionnels et séquentiels. De plus, l'être humain lui-même, qui sera en définitive le moteur de l'interaction homme-machine, a des capacités d'action concurrente très limitées. Toutefois la prise en compte du parallélisme au niveau de la spécification est de première importance. En effet, même si l'utilisateur n'interagit avec le système que par l'intermédiaire d'un dispositif purement séquentiel (par exemple un clavier), les systèmes multifenêtres lui permettent de mener de front des tâches parallèles. Ces tâches sont même le plus souvent concurrentes, en ce sens qu'elles peuvent évoluer de manière indépendante, mais doivent se synchroniser et coopérer lorsqu'elles accèdent à des données qu'elles partagent. Il est donc nécessaire, lors de la spécification, de disposer d'un formalisme permettant de représenter cette concurrence conceptuelle. D'autre part, au point de vue purement technique, de nombreux systèmes d'exploitation modernes proposent des primitives de parallélisme interne (« threads ») qui sont particulièrement utiles pour augmenter le niveau d'interactivité et de réactivité du dialogue [SUN 93], et qui sont exploitées dans de nombreux SGIU. Ces primitives sont toutefois d'assez bas niveau, et il est utile de disposer d'un formalisme permettant d'utiliser des primitives concurrentes tout en faisant abstraction des détails d'implémentation.

4.1. Les approches classiques

Un certain nombre d'approches formelles ont été proposées pour la conception d'interfaces homme-machine depuis l'utilisation des automates à état par D. Parnas


10

[PAR 69] pour la modélisation d'interfaces en mode texte. Ces approches utilisées dans le cadre des applications directives ne sont pas applicables aux interfaces contrôlées par l'utilisateur. Les approches classiques les plus reconnues peuvent être regroupées en deux classes : les grammaires hors contexte et les machines à état.

Le principal usage des grammaires hors contexte dans le domaine des interfaces homme-machine est dû aux travaux de Olsen. Le générateur d'interfaces SYNGRAPH [OLS 83] offre la possibilité de générer automatiquement une interface utilisateur à partir d'une spécification formelle par grammaire hors contexte.

Même si elles ont été largement utilisées, leur usage est aujourd'hui abandonné car elles sont mal adaptées à la fois à la description de la concurrence et à la modélisation des données. De plus, elle n'offrent pas de représentation graphique, alourdissant d'autant la tâche de conception.

Grâce à la possibilité de représenter aisément les états et les opérateurs de changement d'états d'un système, les machines à états ont été utilisées dès les premières tentatives de formalisation des interfaces homme-machine. Les principaux travaux dans ce domaines sont ceux de Wasserman [WAS 85] et plus récemment ceux de Jacob [JAC 86].

Ces travaux n'échappent pas aux critiques habituellement adressées aux machines à états. Ces critiques portent principalement sur :

• la difficulté de modélisation du parallélisme (dont la prise en compte induit une explosion du nombre des états représentés) ;

• l'absence de primitives de structuration des modèles dans le formalisme de base. La structuration est toutefois souvent artificiellement introduite, parfois au détriment du caractère formel de la spécification [HAR 88] ;

• l'absence de prise en compte de l'aspect structure de données dans le formalisme de base : on ne représente que la dynamique du système. Les données sont cependant occasionnellement prises en compte par des notations ad hoc sans caractère formel.

4.2. Les nouvelles approches

Les nouvelles approches de spécification d'interfaces homme-machine ont pour objectif la construction de systèmes interactifs dirigés par l’utilisateur, qui requièrent des formalismes au pouvoir d'expression supérieur à ceux des formalismes utilisés dans les approches classiques. Ces approches intègrent toutes, dans une certaine mesure, les caractéristiques décrites au début de la section 4.

Le tableau de la figure 5 classifie les principales approches formelles selon les

formalismes qu'elles offrent pour la description du comportement et des données. On peut remarquer que tous les formalismes de description du comportement autorisent la prise en compte du parallélisme et offrent des possibilités de vérification formelle.


11

Formalisme pour la description dcomportement

Formalisme pour la description des données

Abowd [ABO 90] CSP, CCS Z Carneiro [CAR 93] StateCharts, Réseaux de Petri,

CCS Abstract Data views, Object Charts

DeCarolis [DEC 93] Réseaux de Petri Colorés, Trellis Prédicats Harrison [HAR 93] Partial order logic Agents Palanque, Bastide Réseaux de Petri de haut niveau Objets Paterno [PAT 92] CSP, CCS (LOTOS) ACT-ONE (LOTOS) Systa [SYS 93] Joint actions systems Objets

Figure 5. Tableau récapitulatif des principales approches formelles

5. Le formalisme des Objets Coopératifs Interactifs

Le formalisme des Objets Coopératifs Interactifs peut être assimilé à un langage à objets dédié à la construction d'interfaces homme-machine. En tant que tel, il se situe dans la catégorie des langages fortement typés autorisant l'héritage, le polymorphisme et l'instanciation dynamique. Les objets interagissent par invocation de services.

Une classe d'ICO décrit la structure de ses instances par quatre composants : le comportement, les services, l'état et la présentation, qui seront détaillé dans les sections suivantes. Dans une application interactive, à chaque fenêtre correspond une instance d'une classe d'ICO.

5.1. Architecture d'une application conçue par ICO

L'architecture présentée ici décrit comment les objets instanciés lors de l'exécution interagissent pour fournir les fonctionnalités offertes par l'application. Cette architecture distingue trois catégories de classes : les classes d'objets passifs, d'objets non interactifs et d'objets interactifs. Les classes d'objets passifs correspondent aux structures de données de l'application ; ces classes sont dépourvues de comportement et de présentation. Par exemple, dans le cas d'une application s'appuyant sur un Système de Gestion de Bases de Données (SGBD), ces classes décriraient la structure des relations du SGBD. Les objets non interactifs sont responsables de la plupart des traitements et peuvent accéder aux objets passifs pour effectuer leurs traitements ; leur activité est arbitrairement complexe et éventuellement concurrente, ce qui rend nécessaire la description de leur comportement. Il ne sont toutefois jamais directement activables par l'utilisateur, et sont donc dépourvus de présentation. Les objets interactifs sont en relation directe avec l'utilisateur et peuvent accéder à la fois aux objets passifs et aux objets non interactifs de l'application.

Fondée sur l'approche à objets, cette architecture diffère fortement de celle de Seeheim, dans la mesure où les objets peuvent participer à plusieurs couches. Dans


12

cette architecture, les trois couches de l'architecture de Seeheim ne correspondent pas aux frontières entre les objets, mais aux composantes des objets, comme montré sur la figure 6.

ObCS

Objets Interactifs Objets non interactifs

Dialogue PrésentationNoyau fonctionnel

Couches du modèle de Seeheim

Utilisateur

Objets Passifs

Interface Noyau Fonctionnel

Figure 6. Architecture d'une application interactive modélisée par Objets Coopératifs

5.2. Le comportement

Le comportement décrit comment un objet réagit aux stimuli extérieurs en fonction de son état interne. Ce comportement est décrit par un réseau de Petri de haut niveau appelé ObCS (Object Control Structure) [HOO 89, BAS 92]. Le dialecte de réseau de Petri utilisé est appelé réseau de Petri à Objets (RPO) [SIB 85] ; nous présentons ici ses caractéristiques en faisant tout d'abord référence au modèle classique des réseaux de Petri et en montrant comment les RPO étendent leur pouvoir d'expression.

Les réseaux de Petri [BRA 83, MUR 90] sont un formalisme dédié à la modélisation des systèmes à événements discrets. Un réseau de Petri modélise un système par un ensemble de variables d'état (appelées places et représentées graphiquement par des ellipses) et par un ensemble d'opérateurs de changement d'état (appelés transitions et représentés par des rectangles). L'état d'un système est modélisé à tout instant par une distribution de jetons dans les places du réseau. A un instant donné, plusieurs places du réseau peuvent être marquées par un nombre quelconque de jetons. Les places et les transitions sont reliées par des arcs d'entrée qui définissent les conditions pour qu'un opérateur de changement d'état soit autorisé. Les arcs d'entrée et les arcs de sortie (reliant une transition à une place) spécifient l'effet de l'opérateur de changement d'état sur le marquage du réseau. On appelle occurrence d'une transition l'activation d'un tel opérateur de changement d'état. Une transition est franchissable si chacune de ses places d'entrée contient au moins un jeton. L'occurrence d'une transition retire un jeton de chacune des places d'entrée et dépose un jeton dans chacune des places de sortie. De plus, un poids (qui est un entier n) est associé à chacun des arcs permettant de prendre ou de déposer n jetons à la fois. De manière générale, une transition peut consommer ou produire des jetons : le nombre de jetons pris dans les places d'entrée peut être différent du nombre de jetons déposés dans les places de sortie.


13

Les limites des réseaux de Petri pour la modélisation de systèmes complexes sont bien connues. Tout d'abord, les jetons qui circulent dans le réseau sont des entités indifférenciées et le réseau de Petri décrit donc uniquement la structure de contrôle du système sans référence à sa structure de données. Ensuite, le formalisme de base des réseaux de Petri n'offre pas de primitives de structuration. Enfin, l'utilisabilité du formalisme est insuffisante.

Les réseaux de Petri de haut niveau [MUR 90] sont des formalismes dérivés des réseaux de Petri et incluant des extensions visant à surmonter ces limitations. Un exemple de réseau de Petri à Objets est présenté sur la figure 7. Ce réseau décrit le comportement très simplifié d’un distributeur de billets de banque. Seules sont modélisées les fonctions permettant l’insertion de la carte, la saisie du montant à retirer et le retrait de la carte et des billets. Ce réseau décrit les enchaînements possibles d’actions, aussi bien à l’initiative de l’utilisateur qu’à l’initiative du système. L’interaction commence lorsque l’utilisateur insère sa carte. Il peut ensuite saisir le montant à retirer. Si ce montant est incompatible avec le solde de la carte, un message d’erreur est affiché, et le montant doit être saisi à nouveau. Dans le cas contraire, les billets sont délivrés par la machine et l’utilisateur doit retirer la carte et les billets pour que le système revienne à son état initial, prêt à servir un autre client.

Cet exemple nous permet d’illustrer comment le formalisme des RPO étend le pouvoir d’expression des réseaux de Petri standards :

• les jetons circulant dans l'ObCS ne sont plus des entités indifférenciées mais des valeurs complexes, pouvant référencer d'autres objets du système. Ceci permet de modéliser l'aspect structure de données du système en s'appuyant sur les techniques de l'approche à objets (encapsulation, héritage, polymorphisme) ;

• les arcs du réseau sont étiquetés par des variables qui jouent le rôle des paramètres formels des transitions et qui permettent de spécifier le flux des objets dans l'ObCS et non plus seulement la production et la consommation de ressources comme c'est le cas dans les réseaux de Petri classiques ; dans l’exemple de la figure 7, les jetons circulant dans le réseau représentent la carte bancaire (dénotée par la variable c), le montant à retirer (variable m) et le solde de la carte (variable s).

• les transitions contiennent une action, qui peut créer ou détruire des objets mais aussi invoquer des méthodes sur les objets associés à ses paramètres formels. Ceci permet d'enrichir la sémantique d'une transition en montrant son effet non seulement sur la dynamique du système mais aussi sur la valeur des données manipulées ; dans la figure 7, la transition T2 invoque la méthode Solde de l’objet carte, dénoté par la variable c ;

• la franchissabilité d'une transition est conditionnée non seulement par la présence de jetons dans ses places d'entrée mais aussi par la valeur de ces jetons, ce qui est exprimé au moyen d'une condition booléenne appelée précondition. Graphiquement la précondition d'une transition est incluse dans un pentagone dans le cas où elle n'est pas identiquement vraie. Ainsi, la précondition de la transition T4 permet de s’assurer que le solde de la carte est suffisant avant de délivrer le montant demandé.


14

<c>

<c>

<m>

<m><s>

<s>

<c>

<m>

<c>

Transition T6,

service utilisateur

Transition avecprécondition

TransitionT2

s := c.solde

T4

Donner(m)

Correct(s,m)

T6

Retirer carte

<m>

T8

T6 T7

T1

T5T4

T3T2

<s>

Prêt

Soldecalculé

Donner(m)

Retirer billetsRetirer carte

Erreur("solde insuffisant")

Correct(s,m) not Correct(s,m)

Montantsaisi

Saisie montant

Prêt a saisirle montant

s := c.solde

Carteprésente

Insérer carte

Légende

associée au

Retirer carte

et action

d'invocation

Prêt Place avec un

marquage initialjeton pour

Figure 7. Réseau de Petri décrivant le comportement simplifié d’un distributeur de billets.

5.3. Les services

Un ICO offre un ensemble de services appelé Serv. Les services de l'objet définissent l'interface (dans le sens informatique du terme) de l'objet avec son environnement. Dans le cas des applications contrôlées par l'utilisateur, cet environnement sera à la fois l'utilisateur du système et d'autres objets de l'application. L'interface d'un ICO est définie conformément aux concepts de l'approche à objets par un ensemble de services offerts par la classe de l'objet. Les services destinés à être déclenchés par l'utilisateur sont représentés dans l'ObCS par des transitions spéciales appelées transitions utilisateur (par exemple les transitions T1, T3, T6 et T7 de la figure 7). Les services offerts aux autres objets de l'application sont représentés dans l'ObCS par des transitions appelées transitions de services. La représentation graphique de ces diverses transitions est illustrée en


15

légende des figures 7 et 12. La communication par invocation de services est formellement décrite en termes de réseaux de Petri ce qui permet la validation des communication entre diverses fenêtres de l'application [BAS 92].

5.4. L'état

L'état d'un ICO est défini par le marquage de son ObCS. Les places du réseau constituent les variables d'état, l'état du réseau est donc défini à la fois par la répartition des jetons dans ces places et par la valeur de ces jetons. Le type d’une place caractérise la structure des jetons que cette place peut contenir. Ce type est un n-uplet de classes et on appelle arité d’une place la longueur de ce n-uplet. Une place d’arité 0 ne contient que des jetons indifférenciés identiques à ceux rencontrés dans les réseaux de Petri classiques.

L’intégration de la représentation de l’état (places et marquage) avec celle du comportement (arcs et transitions) permet de caractériser l'influence de l'état de l'objet sur les services qu'il est capable d'exécuter : il ne peut prendre en compte une requête concernant un des service qu'il offre que si une des transitions associées à ce service est franchissable pour le marquage courant. Réciproquement, l'exécution d'un service qui correspond au franchissement d'une transition, modifie le marquage du réseau et donc l'état de l'objet. La définition d’une classe inclut la spécification d’un marquage initial, déterminant l’état des instances au moment de leur création.

5.5. La Présentation

La présentation d'un ICO est définie par deux éléments. Tout d’abord un ensemble structuré d'interacteurs (noté Int), dont la construction peut être réalisée au moyen des éditeurs graphiques d'interface, représente la partie visible de la présentation. Chaque type d'interacteur est susceptible de réagir à un ensemble prédéfini d'événements (appelé Evt) déclenchés par l'utilisateur. Enfin, une fonction d'activation (notée Act), associe à un couple (interacteur, action de l'utilisateur sur cet interacteur) un et un seul des services offerts par l'ICO.

Cette fonction permet de spécifier quel service de l’application doit être déclenché par le système en réponse à une action de l’utilisateur.

5.6. Définition formelle

La définition formelle des ICO faisant appel à des outils mathématiques et des notations complexes, nous présentons ici la définition simplifiée de la structure d’une classe, suffisante pour décrire de façon précise l’exemple de la section 6. La définition complète, incluant la définition du marquage, de la franchissabilité des transitions et de la règle de franchissement, nécessite environ trente pages, et le lecteur intéressé peut se référer à [PAL 92].

La définition d’une classe d’ICO nécessite de définir formellement neuf éléments : ICO = <C, V, P, T, Pre, Post, Serv, Disp, Act>


16

1. C est un ensemble de classes, décrivant les classes utilisées par l’ICO. Une classe c1 est utilisée par c2 si c1 est un des éléments du type d’au moins une des places de l’ObCS de c2.

2. V est un ensemble de variables. Cet ensemble est muni d’une fonction Type V CV : → , associant à chaque variable une classe.

3. P est l’ensemble des places. Cet ensemble est muni d’une fonction Type P CP: *→ , associant à chaque place un n-uplet de classes. Le n-uplet <c1, …, cn> est appelé type de la place P1.

4. T est l’ensemble des transitions. 5. Pre est la fonction d’incidence avant : Pre: *P T V× → 6. Post est la fonction d’incidence arrière : Post: *P T V× →

Pre et Post permettent de definir les variables portées par les arcs d’entrée et de sortie des transition, respectivement.

7. Serv est l’ensemble des services offerts par la classe. 8. Disp est la fonction de disponibilité, définie par Disp Serv T: ( )→

(où (T) est l’ensemble des parties de T), telle que : * ∀ ∈ ≠ ∅s Serv Disp s, ( ) * ∀ ∈ ∩ = ∅s s Serv Disp s Disp s, ' , ( ) ( ' ) si s s≠ ' La fonction Disp matérialise l’association des services offerts par la classe à des transitions de son ObCS.

9. Act est la fonction d’activation définie par Act Int Evt Serv: ( )× → où Int est l’ensemble des interacteurs de la présentation et Evt est l’ensemble des événements auxquels ces interacteurs peuvent réagir.

6. Exemple d'utilisation du formalisme : un éditeur de table relationnelle

L’exemple que nous proposons pour illustrer l’utilisation des ICO est suffisamment simple pour que ses spécifications soient faciles à exposer mais présente néamoins une structure de dialogue assez riche qui serait difficile à décrire précisément sans une notation adéquate.

6.1. Spécification informelle

Il s'agit de concevoir une application permettant la manipulation des enregistrements stockés dans une table relationnelle.

Le dialogue homme-machine proposé est indépendant de la structure des enregistrements stockés dans la table (nombre et type de leurs champs). Le seul prérequis sur cette structure est que les enregistrements ont un attribut qui leur sert de clé, et dont la valeur sert à identifier de manière unique chacun d’entre eux. Dans l’étude de cas, les enregistrements représentent des véhicules automobiles, pour servir par exemple à la gestion d’un garage de location.


17

Le dialogue est piloté par l'utilisateur, par opposition aux dialogues directifs que l'on rencontre dans la plupart des Systèmes de Gestion de Base de Données (SGBD) relationnels.

Figure 8. Représentation externe de l'éditeur de véhicules

Les actions offertes à l’utilisateur sont les suivantes : • ajouter un véhicule à la table ; • sélectionner un véhicule afin de modifier ses attributs ou de le supprimer ; • supprimer de la table le véhicule sélectionné ; • modifier la valeur des attributs du véhicule sélectionné ; • quitter l'application. En fonction de l’état du dialogue, certaines des opérations ci-dessus peuvent ne

plus être autorisées : par exemple on pourrait interdire à l’utilisateur de quitter l’application alors que des modifications sur la valeur d’un véhicule n’ont pas été sauvegardées. La fonction de l’ObCS est précisément de formaliser ce type de contraintes de séquencement entre actions.

L'application se présente sous la forme d'une fenêtre composée d’une zone d'édition dans laquelle les attributs du véhicule sélectionné peuvent être édités, d’une zone de commande qui permet de déclencher les services de l’application, et d’une zone de défilement qui montre la liste des véhicules présents dans la table.

Lorsqu’une action d’édition est faite sur un attribut, le bouton Remplacer aura pour effet de valider cette modification, alors que le bouton Rétablir permettra de restaurer les valeurs initiales. Pour respecter les conventions de l’environnement hôte, la commande de sortie de l’application est située dans le menu système, accessible depuis la barre de titre.

Dans les sections suivantes nous allons présenter en détail la conception par ICO de l'éditeur de véhicules spécifié ci-dessus. L’exemple peut être conçu en définissant


18

deux classes : La classe Véhicule représentant les données manipulées, et la classe Editeur_de_Véhicules représentant l’application elle-même.

6.2. Modélisation de la classe passive Véhicule

Passive Class VéhiculeServicesAffiche; -- Présente les valeurs des attributs dans la fenêtre.Ajoute; -- Ajoute le véhicule à la table relationnelle.Clone : <Véhicule>; -- Crée un nouveau véhicule identique à l’objet

courant.Correct : <BOOLEAN>; -- Le véhicule vérifie-t-il les contraintes

d'intégrité?Détruit; -- Détruit le véhicule de la table relationnelle.

ServicesIdent : STRING; -- Identifiant du véhicule (numéro d’immatriculation).Marque: STRING;Autoradio : BOOLEAN;Puissance : INTEGER;

Figure 9. La classe d'objets passifs véhicule

La figure 9 montre la spécification de la classe Véhicule. Cette classe est une classe d’objets passifs, et donc dépourvue d’ObCS. Les classes d’objets passifs sont destinées à être implantés dans un langage à objets classique, tel C++, par lequel on définit le code de leurs services. L’implémentation nécessiterait l’utilisation de classes de plus bas niveau (par exemple, un classe Table_Relationnelle permettant au véhicule de s’enregistrer) qui n’apparaissent pas dans la spécification.

Le service Correct permet de vérifier qu’une instance de cette classe répond aux contraintes d'intégrités définies par le modèle de la BD (par exemple assurer la non-duplication des identifiants, que l'identifiant est non vide, …). Le véhicule est en outre capable de s'ajouter ou de se détruire dans sa table, et d'afficher ses valeurs dans une fenêtre. Le service Clone permet de produire une copie d’un objet de classe Véhicule. Le noyau fonctionnel fait appel à des classes prédéfinies INTEGER, STRING et BOOLEAN. L’étape de définition du noyau fonctionnel doit définir l’ensemble C des classes utilisées par l’ICO, soit ici C = {INTEGER, STRING, BOOLEAN, Véhicule}.

6.3. Modélisation de l’ICO Editeur de Véhicules

La fenêtre de manipulation interactive des véhicules est décrite par un Objet Coopératif Interactif dont la classe est présentée sur la figure 10.


19

Class Editeur_de_véhicules;ServicesEditer; -- Effectuer une opération d'édition quelconque sur

-- les attributs du véhicule sélectionné.Remplacer; -- Remplacer le véhicule courant par celui en cours d'édition.Ajouter; -- Ajouter le véhicule en cours d'édition et le sélectionner.Supprimer; -- Détruire le véhicule en cours d'édition. En sélectionner un

autre-- s'il en reste, sinon en créer un avec des valeurs par défaut.

Rétablir; -- Annuler toute édition effectuée sur le véhicule, et-- restaurer ses valeurs initiales.

Sélectionner <clé : STRING>;-- Sélectionner le véhicule dans la liste et afficher la-- valeur de ses attributs dans la zone d'édition.

Quitter; -- Quitter l'application (fermer la fenêtre).ObCS-- l'ObCS de cette classe est présenté en figure 12

Figure 10. La classe d'Objet Coopératif Interactif Editeur_de_véhicules

6.3.1.Présentation

Interacteurs Action de l'utilisateur Service activé PushButton Ajouter Click Ajouter PushButton Supprimer Click Supprimer PushButton Remplacer Click Remplacer PushButton Rétablir Click Rétablir MenuItem Fermeture Click Quitter EntryText Immatriculation Any (Click, Keyboard,…) Editer EntryText Marque Any (Click, Keyboard,…) Editer RadioButtonList Puissance Click Editer CheckBox Autoradio Click Editer ListBox Table Click Sélectionner

Figure 11. Fonction d'activation Act, des services de l'Editeur_de_véhicule

La modélisation de la présentation a pour but de faire le lien entre la spécification de l'interface qui a été réalisée lors de l'étape de spécification (cf. section 6.1) et les services offerts à l'utilisateur par la classe d’ICO. Plus précisément, la tâche à réaliser consiste à rattacher les éléments de la fenêtre (les interacteurs) aux services de la classe Editeur_de_véhicules qu'ils déclenchent. Cette modélisation consiste en la définition de la fonction d'activation Act, présentée sous forme de tableau sur la figure 11. La colonne de gauche définit l’ensemble Int des interacteurs. L’ensemble Evt des événements est déduit de Int d’après les spécifications des interacteurs dans la boîte à outils utilisée.

6.3.2. Dialogue

L'ObCS de la figure 12 définit de façon formelle le dialogue homme-machine de l'ICO Editeur_de_véhicule. Pour accroître la lisibilité des spécifications, les


20

ensembles P, T, et V, ainsi que les fonctions Pre, Post, et Disp ont tous une représentation graphique équivalente, illustrée sur la figure 12. On a :

P= {Défaut, Edité, Liste, Sélectionné}, l'ensemble des places. T = {T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12}, l'ensemble des

transitions V = {o, d, x} l’ensemble des variables, toutes de classe Véhicule. Les fonctions Pré et Post sont représentée respectivement par les arcs entrants et

sortant des transitions. On a par exemple : Pré(Défaut, T2) = <o> et Post(Sélectionné, T2) = <o> La fonction Disp est représentée en inscrivant le nom du service dans les

transitions auxquelles il est associé. On a par exemple Disp(Ajouter) = {T2, T6}.

Défaut

Liste

Sélectionné

Edité

o.affiche selectionner

d.correct dup.correct

éditer

rétablird := o.clone

éditerremplacer o.détruit; d.ajoute;

ajouter d.ajoute;

clé = o.ident

o.affiche

supprimer

o.affiche

supprimer

o.create;o.affiche

o.correct

éditerx.détruit; x.détruit;

T1

T2

T3

T4T5T6 T7

T10

T11

T8quitter T9

<clé>

<o,d>

<x>

<o>

<o,d>

<o>

<o>

<o>

<x>

<o>

<o> <o>

<d> <d> <o>

<o,d> <o,d>

<o,d>

<x>

<x>

<o>

<o> ajouter o.ajoute; <o>

Edité : <o,d : n_uplet>; Selectionné, Liste, Défaut: <o : n_uplet>;

o.correct

Défaut

éditerT1

Précondition

Place avec un marquage initial

Type des places

Arc inhibiteur

Arc avec variable

Transition T1 reliée auservice utilisateur éditer

<o>

Figure 12. ObCS de l'Editeur_de_véhicule

Avec le marquage initial donné en figure 12, on dispose d'un véhicule avec des valeurs par défaut dans la place Défaut. Seuls sont actifs les éléments de la zone d'édition (la transition T1, associée au service Editer, est franchissable), et le bouton Ajouter (transition T2). Après avoir fixé les valeurs désirées pour le véhicule, l'utilisateur invoque le service Ajouter (transition T2) qui fait passer le véhicule dans l'état Sélectionné. A partir de cet état, l'utilisateur peut invoquer le service


21

Supprimer (transition T3), qui le ramène au marquage initial. Plus probablement, il choisira d'Editer (transition T4) le nouveau véhicule, stockant ainsi dans la place Edité le couple <o, d> qui désigne respectivement le véhicule initial et celui résultant de la modification. Après quelques actions d'édition successives, il pourra choisir de Remplacer (transition T5) le véhicule courant par celui qu'il a édité, d'Ajouter (transition T6) un nouveau véhicule avec les nouvelles valeurs d'attribut ou de Rétablir (transition T7) les valeurs initiales du véhicule.

Après quelques itérations de ce processus de modification et d'ajout de véhicules, on se retrouve dans l'état illustré par la figure 8 : la place Liste contient un certain nombre de jetons de type <Véhicule>, les places Sélectionné et Défaut sont vides, et la place Edité contient un jeton, indiquant ainsi qu'un véhicule est en cours de modification. Dans la zone de commande, seuls les boutons Remplacer, Ajouter et Rétablir sont activables, car seules les transitions utilisateur auxquelles ils sont reliés (respectivement T5, T6 et T7) sont franchissables.

Figure 13. Fenêtre de l'éditeur de véhicule avec un message d'erreur

La figure 13 montre un message d'erreur déclenché par l'évaluation de la précondition d.Correct() de la transition T6, dans le cas où le véhicule ne vérifie pas les contraintes d'intégrité (en particulier si l'identifiant est vide). L'interacteur correspondant (le bouton Ajouter) n’est pas désactivé car l'état actif ou inactif des interacteurs dépend du marquage de l'ObCS alors que l'évaluation des préconditions dépend de la valeur des objets et n'est effectuée que lors du franchissement de la transition, c'est à dire une fois que l'interacteur a été activé. Ceci permet de distinguer au moment de la conception les conditions dépendant de l’état du dialogue et celles dépendant de valeurs gérées par le noyau fonctionnel.


22

7. Validation mathématique d'une conception par ICO

7.1. Principes de validation

L'analyse du fonctionnement d'un système d'ICOs peut être réalisée au niveau de chacun des ICO (par analyse individuelle de l'ObCS de chaque ICO) ou bien au niveau du système d'objets dans son ensemble en analysant la communication entre objets. Dans cette section nous présentons succinctement l'analyse individuelle des objets, qui relève de techniques bien connues d'analyse de réseaux de Petri, et nous présenterons ensuite les principes de l'analyse de la communication entre objets.

7.1.1. Analyse individuelle

L'utilisation des Objets Coopératif Interactif permet au concepteur d'utiliser les propriétés mathématiques des réseaux de Petri pour valider sa conception. Les réseaux de Petri proposent des techniques algébriques de vérification statique (c’est-à-dire indépendante de l'exécution) de "bonnes propriétés" sur le comportement des objets du système. De nombreux résultats sont disponibles dans ce domaine [PET 81, BRA 83].

• Disponibilité des services : dans une interface contrôlée par l'utilisateur, il est souvent nécessaire de désactiver provisoirement l'accès à certaines fonctionnalités en fonction de l'état courant de l'application. On doit toutefois s'assurer que toute fonctionnalité offerte par l'application pourra tôt ou tard être activée par l'utilisateur. De même, le concepteur peut vouloir s'assurer que, quel que soit l'état du dialogue, certaines commandes de l'application pourront redevenir accessibles (par le déclenchement d'une séquence de commandes appropriée). Ce problème est directement lié à la propriété de vivance dans les réseaux de Petri : pour qu'un service donné puisse devenir accessible il suffit qu'une des transitions à laquelle il est relié soit vivante. De plus certaines opérations telles que l'aide ou le déplacement de fenêtre doivent toujours être activables par l'utilisateur. Ceci peut être déterminé par l'étude de l'ensemble des marquages accessibles.

• Limitation des ressources : il est souvent utile de rendre compte dans un modèle des limites sur l’utilisation de ressources [BRA 83]. Ce type de restriction est lié au caractère borné des places d'un réseau de Petri : une place p d'un réseau est dite k-bornée, où k ∈ , si son marquage ne contient jamais plus de k jetons. Dans le cas de l'exemple de l'éditeur de véhicules, la vérification d'une telle propriété nous permettra d’assurer qu'un seul véhicule peut être en cours d’édition à un instant donné.

• Réinitialisation du réseau : lors de la modélisation d'un système, il est intéressant de s'assurer que l'état initial peut toujours être à nouveau atteint. Cette propriété est liée à l'analyse des séquences de transitions dans un réseau. Pour un état initial donné, un réseau est dit réinitialisable s'il existe une séquence de transitions finie qui permet de revenir dans cet état, ce qui est une propriété souhaitable pour la plupart des systèmes.


23

7.1.2. Analyse de la coopération

La coopération entre Objets Coopératifs Interactifs respecte un protocole de type client-serveur. Ce protocole est lui-même formellement défini en terme de réseaux de Petri [BAS 89], ce qui permet d'utiliser les techniques d'analyse des réseaux de Petri pour valider la coopération entre objets d'un système.

Cette analyse est cruciale notamment pour la modélisation des applications de type collecticiels pour lesquelles la communication entre utilisateurs est très fréquente. Nous avons montré dans [PAL 92] l'application de ce type d’analyse dans le cadre de la conception de collecticiels.

7.2. Validation de l'exemple

L'analyse d’une application interactive modélisée par ICO permet d’assurer qu’elle vérifie un certain nombre de propriétés nécessaires à son bon fonctionnement. Cette analyse est fondée à la fois sur le calcul des composantes conservatives et des composantes répétitives de l'ObCS de l'éditeur de véhicules (figure 12). Pour la recherche de ces composantes, nous utilisons l'algorithme présenté dans [PAL 91] qui permet le calcul des composantes conservatives et répétitives stationnaires en une seule passe.

7.2.1. Composantes conservatives

Soit un vecteur de pondération des m places d’un réseau R dont la matrice d’incidence est C=Post-Pre. f est un vecteur à m composantes. f est appelé

composante conservative si et seulement si [PAL 91]: f CT • = 0, où f T est le transposé du vecteur des transitions

Une composante conservative est donc un ensemble de places pour lequel le nombre total de jetons reste fixe quelles que soient les transitions franchies. Ce nombre reste égal au marquage initial de cet ensemble de places [BRA 83].

C est définie par Post - Pré où Post (resp. Pré) est une matrice dont les lignes sont les places de l'ObCS, les colonnes sont les transitions et les éléments sont les variables étiquetant les arcs de sortie (resp. d'entrée) des transitions. L'analyse du modele est réalisée sur le reseau sous-jacent, i.e. sans tenir compte du type des objets évoluant dans le réseau mais uniquement de leur nombre. Ainsi, dans la matrice C apparaît un 1 (resp. -1) dans la case (Pi, Tj) s'il y a un arc entre la place Pi et la transition Tj (resp. il y a un arc entre la transition Tj et la place Pi). Un 0 signifie soit qu’il n'y a pas d'arcs entre Pi et Tj, soit qu'il y a à la fois un arc entre Pi et Tj et un arc entre Tj et Pi.


24

Pour le réseau de la figure 12, on a C = T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11P1 : Défaut 0 - 1 1 0 0 0 0 0 0 0 0 P2 : Edité 0 0 0 1 - 1 - 1 - 1 0 0 0 0 P3 : Liste 0 0 0 0 0 1 0 0 0 0 - 1 P4 : Sélectionné 0 1 - 1 - 1 1 1 1 0 0 0 0 L'ensemble des invariants de place du RdP correspond à toutes les solutions

positives pour l'équation f CT • = 0; Ces solutions peuvent etre trouvées en recherchant toutes les combinaisons

linéaires de lignes qui annulent une ligne. Le calcul n'est pas présenté ici mais le résultat est qu'il existe une seule composante conservative stationnaire P1+P2+P4 (ce qui peut être vérifié aisément sur la matrice ci-dessus). Un autre exemple d’analyse peut être trouvé dans [PAL 95b].

Dans le RPO étudié on a comme marquage initial Mo(Défaut) = 1 ; donc la composante conservative : Défaut + Edité + Sélectionné = 1.

Le fait que la cardinalité de la composante conservative soit 1 démontre le caractère séquentiel du franchissement des transitions accédant à l'objet contenu dans ces places. Ces transitions sont toujours mutuellement exclusives. Une cardinalité supérieure à 1 aurait au contraire signifié le parallélisme potentiel du franchissement de ces transitions.

Du fait de l'association entre services et transitions (cf. section 5.2), cette

composante conservative a des conséquences sur la disponibilité des services : • il y a non ambiguïté des commandes : le fait que les services Ajouter,

Détruire et Editer soient associés à plusieurs transitions pourrait introduire de l'indéterminisme sur le franchissement d'une des transitions, lorsque le service est actionné par l'utilisateur. Or toutes les transitions de chacun de ces services sont reliées à une place différente de la composante conservative, ce qui a pour conséquence qu'une seule des transitions associée à un service est franchissable pour un marquage donné ;

• le service Editer est associé à trois transitions T1, T4 et T8, chacune de ces transitions ayant en entrée une place différente de la composante conservative (la place Défaut est en entrée de la transition T1, la place Sélectionné est en entrée de la transition T4 et la place Edité est en entrée de la transition T8). Avec la remarque du paragraphe précédent, on déduit que, quel que soit le marquage du réseau, une et une seule des transitions du service Editer est franchissable. Cette caractéristique du réseau et l'invariant de place égal à 1 ont pour conséquence que le service Editer associé à ces trois transitions est toujours activable.

7.2.2. Composantes répétitives

Soit s un vecteur caractéristique d’une séquence s d’un réseau R dont la matrice d’incidence est C. s est un vecteur à n composantes. s est appelé composante répétitive stationnaire si et seulement si [PAL 91] : C s. = 0


25

Notons que la séquence de franchissement s doit être effectivement franchissable à partir d’un marquage accessible pour que s soit un invariant de transitions.

Le fait qu'une transition appartienne à une composante répétitive signifie que, si elle est franchissable une fois, alors il existe une séquence de transitions du réseau qui permettra de la rendre à nouveau franchissable. Le calcul des composantes répétitives n’est pas détaillé ici, mais son principe est similaire à celui du calcul des composantes conservatives.

L'ensemble des composantes répétitives de l'ObCS de la figure 12 est : T4+T5 ; T4+T7 ; T2+T3 ; T4+T6+T11 ; T1 ; T8 ; T10, qui correspondent aux services : Editer-Rétablir, Editer-Remplacer, Ajouter-Supprimer, Editer-Ajouter-Supprimer, Editer, Sélectionner.

On remarque que chacune des transitions de l'ObCS appartient à une composante répétitive sauf la transition Quitter. Cette caractéristique est un gage de bonne qualité du modèle car elle signifie que, pour chacune des transitions de l'ObCS, l'utilisateur peut toujours parvenir dans un état où cette transition est activable.

8. Conclusion

Cet article est consacré à la conception des application contrôlées par l'utilisateur. Dans la première partie nous avons caractérisé ce type d'application et montré les problèmes inhérents à leur conception. En réponse à ces problèmes, nous avons présenté un nouveau formalisme appelé Objets Coopératifs Interactifs. Nous avons montré que ce formalisme, alliant l'approche à objets et les réseaux de Petri, permet à la fois la spécification, la conception et la validation mathématique des applications contrôlées par l'utilisateur.

Le formalisme des ICO a fait l’objet d’autres travaux, traitant notamment de la génération automatique d'un système d'aide contextuelle [PAL 93b] et de techniques permettant l’implémentation directe d’une spécification par ICO [PAL 94]. Le formalisme des ICO se prête à une implémentation du type de celle proposée par UIDE [GIE 92], où l’on dispose d’un modèle embarqué du dialogue qui peut être directement exploité par le moteur de l’application pour définir le comportement de l’interface à l’exécution.

L'approche que nous proposons est bien adaptée à la conception des interfaces dites à manipulation indirecte, où l'utilisateur interagit de manière discrète avec l'application par l'intermédiaire d'interacteurs (menus, boutons, etc.). Notre approche est moins bien adaptée à la description de dialogues continus tels que ceux offerts par les applications dites à manipulation directe, dans lesquelles l'utilisateur agit directement sur une représentation graphique des objets de l'application (par exemple les applications de type éditeur graphique). Toutefois, même dans ce type d'application le formalisme reste bien adapté pour la description du dialogue à un niveau où l'interaction peut être considérée comme discrète, c’est à dire au niveau du dialogue général, ou au contraire au niveau le plus fin de l’interaction.

A court terme, les développements actuels autour du formalisme des Objets Coopératifs Interactifs portent sur la construction d'un environnement de développement s'intégrant à un SGIU de haut niveau, permettant l'édition graphique


26

des modèles, leur validation formelle et leur prototypage. Parallèlement à ces développements, nous travaillons à la prise en compte d'aspects méthodologiques visant à étudier l'intégration des Objets Coopératifs Interactifs dans les méthodes d'analyse et de conception à objets, et à augmenter le niveau d'abstraction du formalisme des ObCS afin de masquer, dans une certaine mesure, la complexité intrinsèque des réseaux de Petri, et à proposer une approche permettant d’intégrer modèles de tâches et modèle du système [PAL 95a]. A plus long terme nous envisageons l'utilisation des Objets Coopératifs Interactifs (et notamment leurs aspects temporels non présentés dans cet article), pour la conception d'interfaces multimodales, afin d'étendre le domaine d'application du formalisme, limité à l'heure actuelle aux applications interactives contrôlées par l'utilisateur.

9. Remerciements

Les auteurs souhaitent exprimer leur reconnaissance à Michel Beaudouin-Lafon pour ses relectures minutieuses des versions préliminaires de ce texte, ainsi qu’aux relecteurs anonymes de la revue TSI, dont les commentaires ont grandement contribué à la mise au point de cet article. Nos remerciements vont également à Robert Valette, pour ses conseils précieux concernant l’analyse des réseaux de Petri.

Les auteurs sont associés au CENA de Toulouse, au sein duquel une partie des travaux présentés ici ont été réalisés. La société ILOG a mis à notre disposition les outils logiciels qui permettent le développement d’outils informatiques supportant notre approche.

10. Bibliographie

[ABO 90] ABOWD G.D. Agents: Communicating Interactive Processes Proc of INTERACT'90. Elsevier Science (North Holland), p. 143-148

[AHO 86] AHO A.V., SETHI R., ULLMAN J.D. Compilers : principles, techniques and tools. Addison-Wesley, Readings, Mass. 1986.

[BEA 91] BEAUDOUIN-LAFON M. User Interface Management Systems : Present and Future. Eurographics Conference, Vienna, Austria, September 1991.

[BAS 89] BASTIDE R., SIBERTIN-BLANC C. Conception par objets de systèmes parallèles. 2ième Congrès Software Engineering and its Applications EC2, TOULOUSE 1989.

[BAS 92] BASTIDE R. Objets Coopératifs : Un formalisme pour la modélisation des systèmes concurrents. Thèse de l'Université Toulouse III. Février 1992.

[BRA 83] BRAMS G.W. (nom collectif) Réseaux de Petri : Théorie et Pratique. T.1 : théorie et analyse ; T.2 modélisation et applications. ISBN 2-903-60713-3 Masson 1983

[CAR 93] CARNEIRO L.M.F., COWAN D.D., LUCENA C.J.P. ADVcharts : a Graphical Specification for multi-modal Interactive Systems - Abstract Data Views in Perspectives. York Workshop on Formal Methods for the Design of Interactive Systems, York, 1993.

[COU 90] COUTAZ J. Interface Homme-Ordinateur : Conception et Réalisation. Dunod Informatique ISBN 2-04-019635-8. 1990.

[DEC 93] DECAROLIS B., ROSIS F. Modelling Adaptive Interaction in OPADE by Petri Nets. York Workshop on Formal Methods for the Design of Interactive Systems, York, 1993.


27

[GIE 92] GIESKENS D.F., FOLEY J.D. Controlling user interface objects through pre- and postconditions. Proceedings of the ACM CHI'92 conference, Monterey 1992. p. 189-194.

[GRE 86] GREEN M. A survey of three dialogue models. ACM Transaction on graphics. Vol. 5, n° 3, July 1986. p. 244-275.

[HAR 88] HAREL D. On visual formalisms. Communications of the ACM, vol. 31, n°5, 1988. p.514-530.

[HAR 93] FIELDS B., HARRISON M., WRIGHT P. From Natural Language Requirements to Agent-Based Specification : An Aircraft Warning Case Study. York Workshop on Formal Methods for the Design of Interactive Systems, York, 1993.

[HOO 89] European Space Agency. HOOD Reference Manual, issue 3.0; ESA, ref. WME/89-173/JB; Sept. 1989.

[IBM 89] IBM Corp. Common User Acces : Advanced Interface Design Guide. June 1989. [JAC 86] JACOB R.J.K. A specification language for Direct-Manipulation User Interfaces.

ACM Transactions on Graphics, Vol. 5, n° 4, October 1986. p. 283-317. [KIE 83] KIERAS D., POLSON G. A generalised transition network representation for

interactive systems. Proceedings of the ACM CHI'83 conference, Boston 1983, p. 103-106.

[KIM 93] KIM W.C., FOLEY J.D. Providing High-Level Control and Expert Assistance in the User Interface Presentation Design. Proceedings of the INTERCHI'93 conference, Amsterdam 1993, p. 430-437.

[MUR 90] MURATA T. Petri Nets: Properties, Analysis and Applications. Proceedings of the IEEE, vol. 77, n° 4, April 1989.

[OLS 83] OLSEN D.R. SYNGRAPH : a graphical User Interface Generator. ACM Computer Graphics, Vol. 23, n° 3, July 1983. p. 43-50.

[OSF 89] OSF/Motif, Programmer's Reference Manual, Revision 1.0. Open Software Foundation, Eleven Cambridge Center, Cambridge MA 02142, 1989.

[PAL 91] PALUDETTO M. Sur la commande de procédés industriels : une méthodologie basée objets et réseaux de Petri. Thèse Université Paul Sabatier. Déc 1991.`

[PAL 92] PALANQUE P. Modélisation par Objets Coopératifs Interactifs d'interfaces homme-machine dirigées par l'utilisateur. Thèse de doctorat de l'Université Toulouse I (France), 1992.

[PAL 93a] PALANQUE P., BASTIDE R., DOURTE L, SIBERTIN-BLANC C. Design of user-driven interfaces using Petri nets and objects. In Fifth Conference on Advanced Information Systems Engineering (CAISE'93) (Paris, 8-11 June 1993). p. 569-585.

[PAL 93b] PALANQUE P., BASTIDE R., DOURTE. Contextual help for free with formal dialogue design. In HCI International 93 Orlando (USA) (8-13 August 1993). p. 615-620.

[PAL 94] PALANQUE P., BASTIDE R., SENGES V. Automatic code generation from a High-Level Petri Net Based Specification of Dialogue. In EWHCI 94, St.Petersburg (Russia) (2-6 August 1994).

[PAL 95a] PALANQUE P., BASTIDE R. SENGES V. Task model-System model: towards an Unifying Formalism. In HCI International 95, 6th International Conference on Human Computer Interaction, Yokohama, Japan (July 9-14, 1995).

[PAL 95b] PALANQUE P., BASTIDE R. Verification of an Interactive Software by Analysis of its Forma Specification. In INTERCAT’95, Lillehamer, Norway (June 27-29, 1995).

[PAR 69] PARNAS D.L. On the use of transition diagrams in the design of a user interface for an interactive computer system. 24 th ACM Conference 1969. p. 379-385.

[PAT 92] PATERNO F., FACONTI G. On the Use of LOTOS to Describe Graphical Interaction Proc. of the HCI'92 Conference, p 155-174, BCS Conference Series, Monk, Diaper & Harrison Eds. 1992.

[PET 81] PETERSON J.L. Petri net theory and the modeling of systems. Prentice-hall. 1981.


28

[PNU 86] Pnueli A Applications of Temporal Logic to the Specifcation and Verification of Reactive Systems: A Survey of Current Trends. Lecture Notes in Computer Science n° 224 p.510-584. Springer Verlag 1986.

[SCA 86] SCAPIN D. Guide ergonomique de conception des interfaces homme-machine. Rapport de recherche I.N.R.I.A. n° 77. Octobre 1986.

[SIB 85] SIBERTIN-BLANC C. High-level Petri nets with Data Structure. 6th European Workshop on Petri Net and applications, Espoo (Finland), June 85.

[SUN 85] SUN Microsystems Inc. Programmer's Reference Manual for the Sun Window System. SUN Microsystems Inc., 2250 Garcia Avenue, Moutain View, CA 94043, 1985.

[SUN 93] SUN Microsystems Inc. SunOS 5.3 Guide to Multithread Programming. SUN Microsystems Inc., 2250 Garcia Avenue, Moutain View, CA 94043, 1993.

[SYS 93] SYSTA K. Specifying User Interfaces in DisCo. York Workshop on Formal Methods for the Design of Interactive Systems, York, 1993.

[VAN 88] VAN BILJON W.R. Extending Petri Nets for specifying Man-Machine dialogues. International Journal of Man-Machine Studies, Vol. 28, 1988. p. 437-455.

[VAN 93] VANDERDONCKT J.M., BODART F. Encapsulating knowledge for intelligent automatic interaction objects selection. In Proceedings of INTERCHI'93 (Amsterdam The Netherlands, 24-29 April 1993) ACM, New York 1993, p.424-429.

[WAS 85] WASSERMAN A.I. Extending State / Transition Diagrams for the specification on Human-Computer Interaction. IEEE Transaction on Software Engineering Vol. 11, n° 8, August 1985. p. 699-713.

Technique et Science Informatique 14, no. 4 (1995)...

Documents

Transcript of Technique et Science Informatique 14, no. 4 (1995)...