L Guittet
email: guittet@ensma.univ-poitiers.fr

P Girard
email: girard@ensma.univ-poitiers.fr

G Pierra
email: pierra@ensma.univ-poitiers.fr

Dialogue verification using the EXPRESS language

This paper presents some preliminary results in using the formal language EXPRESS to verify dialogues of Interactive systems. These results demonstrate that many static verifications can be achievedand that tools integrating EXPRESS verification should be very useful for a priori interactive system validation

INTRODUCTION

Formal specification of interactive systems usually consists in defining a model associated with a formal language [START_REF] Palanque | Modélisation par Objets Coopératifs Interactifs d'interfaces hommemachine dirigées par l'utilisateur[END_REF][START_REF] Duke | Towards a Theory of Interactors, Amodeus Esprit Basic Research Project[END_REF][START_REF] Paterno | A Theory of User-Interaction Objects[END_REF]. Our approach is slightly different. We have started from an existing model of interactive systems (the H 4 model) with existing tools for interactive systems building. The dialogue description in the model is made by extended ATN. The whole system has been developped for Computer-Aided Design (CAD) systems and is really suitable for them. Despite attempting reasoning upon these transition networks, we decided to use another formal language, in fact the EXPRESS language, and its associated tools, to verify some properties of the dialogue.

In the first two sections, we give a short description of the CAD domain and its specificities, and we explain the main characteristics of the H 4 approach. In the third section, we describe the main parts of the EXPRESS language, giving examples which are applied to our case. In the fourth section, we show how EXPRESS modelling allows us to verify many concrete propoerties. Last, we explain the limitations of the method and the development we planned for this work.

CAD systems specificity

CAD systems are powerful design systems that allow users to build complex models, such as mechanical models, architectural models, and so on. We will try, in this section, to expose the basis of CAD specificities that lent us to our specific model. We begin with tasks characteristics, and follow by object description. Our examples belong to the technical domain, but are really very simplified to avoid for readers'lack of background in this domain. We will describe our problem, related to the Taxonomy for Interactive Graphics Systems [START_REF] Pierra | Towards a taxonomy for interactive graphics systems[END_REF] resulting from discussions that took place during the Eurographics Workshop on Design, Specification and Verification of Interactive Systems'95 (Bonas, France), in the Working Group on Taxonomy

The major characteristic of technical or architectural design is its preciseness. Objects are completely and explicitely defined by users (lines are defined by their two end points, sweeps by their sweeped face and sweeping vectors, and so on). These explicit relations require users to express them. While relations should apply between distinct objects, users'tasks have to be multi-object tasks. More, because CAD systems are powerful, they allow users to perform structured tasks. These two points are illustrated on the following example:

Assume the goal of a user is: "I want to build a circle whose centre is the end of this line, and whose radius is the distance between that point and the end of that line". The expected result is shown on figure 1 This example allows us to classify the tasks: the distance subtask is intended to elaborate 'something' (that we call token) which is used as a parameter for the higher degree subtask (here the distance), which elaborates itself another token for another task. Producing any token which is not used as parameter by any task should be considered at least as an error of the user, and perhaps as a design error of dialogue. At the opposite, the circle creation task does not produce anything to be used by any higher-level task.

This particular point led us splitting tasks in two main categories: production subtasks: which produce some token for another task, and terminal tasks, which do not produce anything for task usage. For example, object management (creating, deleting, structuring, ...) or window management (zooming, translating, ...) are the realm of terminal tasks, while expressions (extremity, distance, numerical expressions, ...) are typical production subtasks. By extension, simple value inputs or object selection must be considered as production subtasks.

Conceptual objects are highly structured in CAD area. Solids are the inner part of closed shells; shells themselves consist of faces, and so on. When selecting a line, does the user want to select either that line, either the face it belongs, or the solid it limits? Depending on the dialogue process state, the answer may vary.

Conceptual objects are also relational objects. Hidden surface visualisation is a good example of this point: each object's visibility cannot be computed on its own. For all this reasons, it does not exist any direct mapping between conceptual objects and presentation objects.

The hierarchical interactors solution

According to the taxonomy, these systems support multi-object and structured tasks, and the conceptual objects are structured and relational objects. It is well known, in Software Engineering, that these complex systems, even if designed according to object oriented methods, have to be splitted up into subsystems. The Arch (or Slinky [START_REF] Bass | A Metamodel for the Runtime Architecture of an Interactive System[END_REF])) model precisely provides for such a macrostructuring of systems. But Software Engineering principles also require the interfaces, specification and relationships between these subsystems to be precisely defined, and require each system to correspond to one unique abstraction. According to this principle, we will describe our model by use of the Arch model.

We identified four components with hierarchical decomposition. Two components from the four exactly match with the components of the ARCH model: the functional core, and the dialogue component. The first one is in charge of conceptual objects hierarchy. The second one exactly reflects the task/subtask hierarchy. The presentation component is devoted to the pipeline viewing (both for inputs and outputs), and reflects the hierarchy of space transformations [START_REF] Phigs | Programmers Hierarchical Interactive Graphics System -Functional Description[END_REF][START_REF] Carson | Introduction to the Computer Graphics Reference Model[END_REF]. Last, the interaction toolkit component implements the logical input devices whose hierarchic composition is generally accepted [START_REF] Duce | An Approach to Hierarchical Input Devices[END_REF][START_REF] Duke | Towards a Theory of Interactors, Amodeus Esprit Basic Research Project[END_REF][START_REF] Paterno | A Theory of User-Interaction Objects[END_REF]. These four hierarchies explain the name we chose for our model.

The fifth ARCH component has to be detailed. It is the domain adaptor component that implements the exchange mechanism between the Dialogue Component and the Domain Specific Component. We propose using the term of questionnaire for modelling such an exchange mechanism.

For example, assume we want to design the syntactic call of the questionnaire for the "select entity" subtask. The semantic role of this subtask is to return the nearest entity from a given position (simple mouse click or elaborated 3D position). It may fall down if the model is empty. So, the questionnaire may be as follows, in an Ada like formalism: The domain adaptor component also insures the feedback of the corresponding procedures through a direct projection on the rendering functions of the presentation component. This direct access from the Domain Adaptator Component results from two points:

(1) the decoupling of domain obects and tasks, and (2) the need for projecting the domain objects (alone or not) on the presentation area.

The following figure summarize the H 4 architecture model for interactive graphic application that support multi-object structured tasks and whose the objects are both structured and relational objects. The formal definition of this model may be found in [START_REF] Guittet | Contribution à l'Ingéniérie des Interfaces Homme-Machine -Théorie des Interacteurs et Architecture H4 dans le système NODAOO[END_REF].

H 1

Interation toolkit component

Domain adaptator component

Questionnaires implementation H 3 The H 4 architecture model has been used to develop a complete Computer Aided Design system for mechanical purpose that uses the Motif toolkit. The dialogue interactors are specified in an ATN-based specification language and the complete dialogue component is generated as an Ada program.

Domain specific component

Conceptual objects hierarchy H 2

Dialogue component

Control interactors hierarchy

The application structure can be synthesized as in figure 6, which focusses on the dialogue component: we can see the hierarchy of interactors, and the monitor that manages tokens. This structure will be modelized in the EXPRESS language in the next sections.

The EXPRESS Language

The EXPRESS language has been developed to describe the information required to design, build, and maintain products [START_REF] Schenk | Information Modeling: The EXPRESS Way[END_REF]. The langage, described in

5

(EXPRESS 1994), is since September 1994 an international standard. In this section, after having given a short overview of the EXPRESS language, we explain some of its feature using examples of our system.

Overview

This modelling language, used in STEP (Standard for the Exchange of Product Model Data), is object-based (as opposed to Entity-Relationship modelling language) and syntactically compilable but yet, non-executable. EXPRESS has been developed in parallel with its usage, which gave it a pragmatic flavour. This language only deals with the specification of the static aspects of data.

The major concepts used to describe models are entity types, supertypes or subtypes, and constraints.

Entity types describe collections of entity instances with similar properties, common relationships and semantics. Entity instances belonging to the same entity type have the same attributes. Each entity instance is uniquely identifiable by definition (two entity instances with the same attribute values can be distinguished).

Attributes describe the properties of entity types. Attribute values are either values of simple or defined types, or instances of entity types (a "has-a" relationship). The three kinds of attributes are:

• explicit: this property has a static value, which is independent from other attribute values.

• derived: the value is a result of a function over other attribute values.

• inverse: the value represents the coupling between "subject" entiies and "user" entities that refer the subject [START_REF] Schenk | Information Modeling: The EXPRESS Way[END_REF].

Supertypes define a "is-a" relationship between entity types and one or more refined versions of them. Refined entities are called supertypes and every refined versions are called subtypes. Subtypes inherit attributes and constraints from their supertype (in direct and transitively indirect mode), and also add specific attributes or restrict supertype properties. Inheritance refers to the mechanism of sharing properties and constraints using the supertype structure. The supertype relationship is transitive.

Constraints, used to restrict entity instances or values, are local rules (applied to every individual instance) or global rules (applied to entity instances of different entity types or to particular entity types). Unlike most data modeling formalisms that only capture cardinality or set-oriented constraints on data conforming to data models, EXPRESS enables modeling any kind of constraints. Thanks to several built-in functions, and to a pascal-like procedural language, functions may be defined. These functions, in turn, may be used to define constraints. Uniqueness constraints restrict attributes or set of attributes to have unique values within the extent of entity types. Inverse attributes constrain the existence dependencies between entity instances of different entity types.

3.2.

Simplified example

The token tree

The following example shows the main features that can be found in an EXPRESS specification.

Figure 12 : Physical file

The following table establishes the correspondance between actions an numbers in the physical file (#301 for example)

Verifications and Validation

Our goal was to use the EXPRESS language to verify the correctness of dialogues. Checking physical files against well-written EXPRESS models ensures properties. In this section, we explain what kinds of properties we have checked with our models, and then, we present the first results that validate our approach.

Verifications

Our EXPRESS model of hierarchical interactors verifies two kinds of properties: individual properties on each interactor, and global properties on the whole hierarchy, over token exchanges.

Individual properties

Different levels of verifications can be achieved. Some of them have been yet detailed in the previous section:

• at structural level, it is easy to ensure the connectivity and the state reachability in the automata. The "WHERE" rules ensure such verifications, • at lexical level, we can verify that every command and parameter which are defined in its input list is actually used in each interactor, • at syntactical level, we can verify the absence of ambiguity (for example, two transitions starting from the same state must have different keys),

• at semantic level, input parameter lists for actions must be consistent with the parameters stored into the interactors. Each state maintains, in its 'params' attribute, the set of parameters that have not been yet concumed. When transitions with action are fired, coherency verifications can be made between the action parameters, the set of parameters in the initial state of the transition, and the token used to fire the transition.

We shall notice that this kind of verifications is rarely stated by authors, because most work do not concern multi-object dialogues.

Global properties

Some global properties may easily be verified using EXPRESS. For example, every consumable token in one interactor has to be producible by the subhierarchy of interactors below itself. In the same way, the opposite property is: every producible token in each interactor must potentially be consumed by the subhierarchy of interactors upper itself.

Validation

We validated our approach using the EXPRESS tool ECCO Toolkit [START_REF] Staub | ECCO Toolkit: an Environment for the Evaluation of EXPRESS Models and the Development of STEP based IT Applications[END_REF]. We built a whole EXPRESS model (bigger in this paper) and wrote an instance generator. The ECCO toolkit has been able to check every rule we mentionned above.

Future works

The preliminary results we have presented in this paper demonstrate that verification of interactive dialogue may is possible using an EXPRESS modelisation. Nevertheless, lot of work has to be done... We can verify physical files, but we cannot use these files to generate interactive applications (as we do with ATN files). So, we have either to modify our dialogue compiler to let it accept EXPRESS instances as input, or to create a translator from ATN files to EXPRESS physical files.

In a more general way, we only verify the dialogue. This must be extended to the presentation of the application.

Last, every verification we made is static. No dynamic verification is possible. Enhancing verifications with dynamic aspects would make necessary using another part of EXPRESS definition, the EXPRESS-C procedural language.

Figure 1 :Figure 2 :Figure 3 :

 123 Figure 1: The user's goal Applying Norman's theory of activity (Norman 1986) is straightforward. The goal/subgoal hierarchy which is expressed above may be mapped to the task/substask hierarchy shown on figure 2: Create-Circle-By-Center-And-Radius

Figure 4 :

 4 Figure 4: A questionnaire for a production subtask

  Guittet L., Girard P., & Pierra G. Dialogue verification using the EXPRESS language. Eurographics Workshop on Design, Specification and Verification of Interactive Systems (DSV-IS'97), Eds. M.D. Harrison & J.C. Torres, Granada, Spain, vol. Conference proceedings,4-6 June 1997, pp. 457-471.

Figure 6 :

 6 Figure 6: The hierarchical interactors

  verification using the EXPRESS language. Eurographics Workshop on Design, Specification and Verification of Interactive Systems (DSV-IS'97), Eds. M.D. Harrison & J.C. Torres, Granada, Spain, vol. Conference proceedings,4-6 June 1997, pp. 457-471.

Figure 13 :

 13 Figure 13: Coherency between actions and parameters

  The following description (nxt figure) must be added to the description of figure11:

	ENTITY state ;	ENTITY transition ;
	...	...
	DERIVE params:BAG [0:?] OF parameter =calcule(trans);	WHERE
	INVERSE trans : SET [0:?] OF transitions for s_end;	action_coherency :BAG(action.in_list)= s_begin.params+key
	END_ENTITY ;	;
		END_ENTITY ;

This tree, which results form the SUPERTYPE and SUBTYPE clauses, describes the lexical elements ot the language. Commands have a name which is an attribute. They should be considered as the keywords of the language. Their unicity is assumed by the UNIQUE clause. The parameters, which are specialized in numbers, positions or system objects (here, lines and circles), have each a specific attribute: their associated value. 7 the whole set of produceable tokens from the interactors which are lower than the one which is given as parameter. States are the stable states of interactors. Optional prompts are sent to users before inputs. Transitions, which connect initial states (s_begin) to terminal states (s_end), and which are associated with optional actions (OPTIONAL), are fired when the current token is the key attrobute. When the action is present, it is triggered by the functional core. Input parameters which have not been concumed are given to the action. Coherency verification between given and expected parameters will be detailed later.

System description

Interactors

System instances

The EXPRESS language is a data-oriented modelling language. So, it allows defining models. The above description is a partial view of the Hierarchical Interactors model.

The power of the EXPRESS environment is to provide for verifications against EXPRESS models. What is to be verified is called "instances" or "physical files". Next figure presents such a physical file, which supports the definition of the dialogue conforming to the task/subtask hierarchy of section 2. (#301,#302,#303),(#310,#311,#312),#301) #301=state('initial',$) #302=state('circle_by',$) #303=state('circle_by_center_and',$) #310=transition(#301,#302,#13,$) #311=transition(#302,#301,#3,$) #312=transition(#303,#300,#2,#7) --and the system #1000=system( (#1,#2,#3,#11,#12,#13),(#2,#3),(#101,#102,#103))


Francis Jambon
email: jambon@ensma.fr

Error Recovery Representations in Interactive System Development

Keywords:

This paper deals with human error resistance. In the first part of it, a short state-ofthe-art of human error resistance, i.e., error prevention and error correction will be presented. Then, error correction, which is usually divided into three sequential tasks: detection, explanation, and recovery will be described.

The second part of the paper will put emphasis on error recovery, which is our main object of study. First and foremost, through an example, we will see what makes the distinction between forward and backward error recovery, i.e., how the system is able to restore its previous state after an error occurrence. In addition to it, the three different kinds of backward error recovery -undo, cancel, and stop -will be illustrated.

Then, the limits of the current distinction between forward and backward error recovery will be highlighted. As a consequence, the paper proposes a new representation of error recovery based on two dimensions: error additional cost and system state degradation. In the context of time-critical systems, another dimension will be introduced: time.

INTRODUCTION

Although human errors are often observed in human-computer interaction, they are usually overlooked or ignored by most interface designers. Poor support for human error management in interactive system development may be an explanation of the designer's attitude. In this paper, taking into account designers' point of view, our aim is to support design for error recovery practices in interactive system development thanks to models. We all know that novice, very young, or elderly people make more often errors than expert users. So, in order to create "User Interfaces for All", designers must include good human error resistance strategies into the user interface life cycle. In this article, we propose a new distinction between error recovery methods in order to help practitioners to choose between recovery alternatives.

RELATED WORK

Human Error

Human Error has been widely studied from the cognitive science perspective [START_REF] Leplat | Erreur humaine, fiabilite humaine dans le travail[END_REF][START_REF] Rasmussen | Information processing and Human-Machine Interaction : An approach to cognitive engineering[END_REF][START_REF] Reason | Human error[END_REF] as well as from the applied science perspective [START_REF] Swain | Handbook of human reliability analysis with emphasis on nuclear power plant applications[END_REF][START_REF] Nicolet | Catastrophes ? Non merci ! La prévention des risques technologiques et humains[END_REF]. The definition of "human error" is an important topic, but cannot be reviewed here. For an overview on this topic, we suggest reading [START_REF] Reason | Human error[END_REF].

One of the most significant result of human error studies -from the designer's point of view -is the evaluation of the Human Error Probability. As an example, the THERP method [START_REF] Swain | Handbook of human reliability analysis with emphasis on nuclear power plant applications[END_REF] focuses on nuclear power plant control rooms. More recent works suggest that -extended -interface specification notations can be used to detect a breakdown during human-computer interaction [START_REF] Johnson | Supporting Error-Driven Design[END_REF].

With these results, designers can evaluate human error rates and their consequences on the system state, at the very first step of the design process. So, at this stage, human error resistance strategies can be defined in order to prevent or limit the consequences of human errors.

Error Resistance Strategies

Error resistance can be achieved by means of two strategies: error prevention and error correction [START_REF] Lewis | Designing for Error[END_REF]. Error prevention can result from forcing functions [START_REF] Norman | The design of every day things[END_REF]), operator's selection, or training. But error prevention will never get rid of all human error occurrences. That's why error correction -sometimes called error managementhas to be actually supported in interactive systems.

Human error resistance is mostly supported -when that is the case -by user interface designers through prevention. Designers ought to follow the prevention strategy, for self-evident reasons. Unfortunately, they usually deal with human error only with the prevention strategy. And yet, scientific published works (Lenman & Robert, 1994a), as well as aircraft accident reports (Ministère de l'équipement des transports et du tourisme, 1994) 1 stress the need for correction. In the former report, the authors criticize the fact that the human-system interface has given the crew too little chance to correct their disastrous error. Now, let's explore error correction.

Error Correction

As an operator, correcting an error or a system failure, can be achieved by following three sequential tasks: Error detection, i.e., the user needs to know that an error occurred ; Error explanation, i.e., the user must understand the nature of the error -do note that for the "undo" function, the user does not always need to know that ; Error recovery, i.e., the user has to counteract the effects of the error (Lenman & Robert, 1994a). Some systems have embedded auto-correction features [START_REF] Lewis | Designing for Error[END_REF]): in such systems, the error correction is achieved by the system which is in charge of the corrections tasks -detection, explanation, and recovery.

Error detection and explanation are the first steps of error correction. They are primarily related to the interface presentation. In this paper, we focus on the recovery part of the error correction which involves the definition of the recovery procedures. Although error detection and explanation are not our topic, we assume that they are compulsory in a perspective of design for error. For self-evident reasons, error recovery is void if the user cannot neither detect nor understand the error ! Figure 1 summarizes the strategies that will help us to overcome human error and highlights our topic of study.

FORWARD VERSUS BACKWARD ERROR RECOVERY

Dix, Finlay, Abowd, & Beale [START_REF] Dix | Human-computer interaction[END_REF]) make a distinction between backward and forward error recovery. This distinction is now commonly used in interactive system development. However, we suggest that this distinction is not as useful as it could be from the designers' point of view. So we propose our own complementary taxonomy.

Backward error recovery

Backward error recovery is an attempt to restore the system state after an error has occurred. Backward recovery can be considered as the only real "recovery" function, since the unexpected effects of error are totally removed. Backward error recovery can be seen as a function to go back in time. As a result, novice users usually use it as a fail-safe learning method. According to Yang [START_REF] Yang | Anatomy of the design of an undo support facility[END_REF] -in (Lenman & Robert, 1994a) -there are three kinds of backward error recovery commands: undo, cancel, and stop.

• The undo function is the most famous one, and most editors -for texts or graphicsimplements an undo function. Unfortunately, the undo function is also the most complex one. Designers have to do with the presentation, the granularity, the scope, and the range of the undo function. Moreover, current implementations of the undo function seem to fall short of user expectations [START_REF] Lenman | Investigating the granularity of the Undo function in human-computer interfaces[END_REF].

• The stop function is used to terminate the process under execution. For example, a user can make the choice to stop a long printing command when he realizes that many users are waiting for the printer. However, the stop function is not always implemented as a pure backward recovery: in the former example, the user can stop the printing command while the printer is working, so, some pages may have been printed uselessly.

• The cancel function is used to abandon commands under specification. For example, a user can cancel the typing of an e-mail message if the addressee has just entered the user's office. However, as for the undo function, the cancel function has to deal with its scope: the user must know which command(s) are concerned by the recovery.

Forward error recovery

In forward error recovery, the user has to execute unexpected tasks to recover the fault. Usually the final result -the system state -is non-optimal. For example, if you break a dish plate, you have to use glue to recover your error. Of course, the final dish plate is not as nice as the unbroken one. In civil aviation, a lot of emergency procedures (Airbus Industrie, 1992) are forward recovery procedures. In these procedures the "error" is a system failure. The result is generally a non-optimal state of the aircraft: after an engine fire, the latter can remain inoperative for the flight.

Forward recovery is commonly the only way to recover from technical failure or human error in critical systems like nuclear power plants, chemical plants, aircraft, vessels, etc. In these systems, side-effects of many actions cannot be easily removed. As Lenman & Robert (1994a) say "Forward error recovery is an important topic, and more research is needed concerning these questions". [START_REF] Dix | Human-computer interaction[END_REF] use the example of an house of cards to show the difference between backward and forward error recovery: "for example, in building a house of cards, you might sneeze whilst placing a card on the seventh level, but cannot undo the effect of your misfortune except by rebuilding".

Limits of this classification

3.3.a. Erroneous task granularity

Dix et al. suppose that you cannot undo the fall of your house of card after placing a wrong card. Obviously Dix et al. consider that the erroneous task is placing one card on the house. But that's not so obvious, if we consider that the real task is building an eight level house of cards. You may place a card in a wrong way, and then, the house falls down. Now collect all the fallen cards: that's a backward error recovery because you have undone the effect of your error. The system is exactly in the state before the beginning of your task "building the house of cards". Rebuilding the house of cards is now considered as a new task occurring after the recovery. So, the difference between backward and forward recovery is relative to the granularity of the erroneous task.

3.3.b. Additional cost of error

It is assumed that backward error recovery -undo, cancel, & stop -is the best way for a user to recover from an unexpected error. Clearly, pressing the "undo" button after a typing error is easy. Yet to achieve this goal, the user must retype the right letter, word, paragraph, or why not, the document. The cost of an error is clearly the cost of the correction task, as well as the cost of the correctly executed task. So, many users may prefer to use forward error recovery in order to move the system to a non-optimal state but at a lower cost. This is a critical topic from the designer's point of view.

Representations of Error Recovery

In order to avoid confusion between backward and forward error recovery, we propose a new taxonomy of error recovery. This taxonomy is based on two dimensions: Error additional cost and system state degradation.

3.4.a. Error additional cost

The first dimension, the error additional cost, represents the cost of the tasks the user has to perform in addition to the normal error-free task in order to manage the error. In other words, the error additional cost is the difference between the error-free task and the addition of the erroneous task, the recovery, and the new task performed to achieve the goal. This cost can be evaluated as the time needed to ensure the completion of the tasks, as well as the cognitive or the conative [START_REF] Dorwell | Towards a conception for an engineering discipline of human factors[END_REF]) cost of the additional tasks. It represents, for the user's point of view, the extra cost or the disappointment generated by his error (or system failure).

3.4.b. System state degradation

The second dimension, the system state degradation, is the difference between the achieved and expected system states after recovery. This dimension shows whether the user's goal has been fully achieved or not. It is an important issue from the user's point of view. We suppose that, at the second time, the user succeeds in performing the task without error .

3.4.c. Graphical editor example

Let us study a typical task in a graphical editor like MacDraw®. The user's task is to create a perfect circle. The user forgets to press the shift key before drawing, so the circle is in fact an oval. The user can choose to manage the error by the undo function of MacDraw®, and re-draw the circle. This is a backward error recovery. As shown on Figure 2, the cost is high because the user must activate the undo function and to redraw. Moreover, the system state degradation is void because the goal, a perfect circle, has been achieved.

That's why the user can choose to turn his oval into an approximate circle by direct manipulation. This is a forward error recovery. As shown on Figure 2, the cost of the recovery task is low because the user has to perform a simple direct manipulation. Moreover, the system state is not optimal (the circle is not perfect) but enough satisfactory for the user's need.

The user can also choose not to recover the error. As shown on Figure 2, the cost of the recovery task equals zero, but the system state degradation is high because the circle is still an oval.

This example shows how a designer can evaluate, for every significant task, the possible recovery functions from the user's point of view according to our dimensions. Let us see their applications to time-critical systems.

3.4.d. Time-critical systems

In time-critical systems, the recovery functions are not always possible. The time is also an additional dimension of interest to think about recovery. In order to illustrate the importance of time, we present the example of an aircraft pilot who has forgotten to extend the landing gear of an aircraft during the final path before landing.

As shown on Figure 3, the pilot can recover his error by backward error recovery -extend the gears -before T 1 and then land safely. The cost of this recovery is low and the system state is optimal: we deplore neither waste of time nor extra use of kerosene. Do note that the pilot can also choose to use a forward error recovery here, but it proves to be less interesting. After T 1 the pilot does not have enough time to extend the gears before touching down the runway. So he has to go-around and to re-try the landing. This a forward error recovery: the cost is high for the pilot -the go-around task -, and the system state is not optimal because of waste of time and kerosene.

After T 2 , it is too late, the aircraft is on the runway and the pilot has neither enough time to extend gears nor to go-around. The cost of the recovery equals zero but the system state degradation is high because the aircraft has crashed on the runway.

We assume that a graph can help designers visualizing the consequences of error recovery functions for critical tasks. These dimensions can also help designers to choose whether they implement or not recovery functions with respect to the cost the user will have to take care of.

CONCLUSION

As a conclusion, we hope we have provided designers a new way to understand the user's point of view in error recovery. We assume that these dimensions can also be used to understand system failure recovery in safety-critical systems. By doing so, we hope that these dimensions can ensure more safety in the conception of the interface of these systems. Of course, these dimensions can also be used in the design process of desktop computer interfaces in order to evaluate the real benefits of recovery. During the workshop, we would like to discuss the possible ways to include error management in the development process of user interface by the way of models and formalisms. Then, we would like to evaluate the usability of our dimensions of analysis in this context.

Figure 2 :

 2 Figure 2: Error recovery in the graphical editor example.

Figure 3 :

 3 Figure 3: Error recovery in the landing aircraft example.

ACKNOWLEDGMENTS

The author would like to acknowledge the CLIPS-IMAG laboratory which partially support this work. Many thanks to Sylvie Ferrès for the English review of the article.

BIBLIOGRAPHY

Airbus Industrie. (1992). Flight Crew Operating Manual A320.


G Patry
email: patry@ensma.fr

P Girard
email: girard@ensma.fr

From Adaptable Interfaces to Model-Based Interface Development: The GIPSE Project

Developping specialized versions of applications is usually made by computer experts. The GIPSE system has been designed to allow end-users to specialise their application by creating new functions. As it allows this task by Programming by Demonstration techniques, without any use of textual programming language, GIPSE can be used by non computer literates.

Starting from GIPSE, we propose to rely two approaches which, at a first glance, seem very different: model-based interface development and user-adaptable applications. We argue that these two approaches may converge, bringing user enpowerment to formal approaches, and conversely, bringing formal insurance to end-user developments.

Introduction

With the advent of personal computing, computer programming trend is to design applications for the widest possible user groups. They try to address needs of a large population with very different requirements. The same drawing package may be intended to be used for designing the outline of a mechanical structure, the appearance of a building, or the disposal of a flat. To accommodate such different purposes, these applications usually provide a large number of low level functions that can be combined by end users to fulfil their needs. This allows multiple uses, but is also very tedious when the same kind of operations needs to be done over and over.

The removal of these drawbacks may be done by using the Programming by Demonstration (PbD) paradigm that can be summarized as follow: while the user uses a PbD system, this system generalizes the interactive session (the example) to compute a program. For example, achieving the same task on two objects may be generalized on a whole set of objects. Many systems have been developped over this idea [START_REF] Cypher | Watch What I Do: Programming by Demonstration[END_REF]]. In the CAD area, our laboratory has been involved in major projects that have led to powerful PbD systems [Pierra, Potier, & Girard 1996].

At the same time, interface development drastically changed. Theories and models have been developped. Computer-Aided Design of User Interface (CADUI) became a great center of interest. Model-Based systems [Puerta 1997] seem to be now one of the best approaches to build powerful interactive applications: from one or different models (user-task model, dialogue model, presentation model) model-based systems construct powerful interfaces that may be connected to functional cores in order to build the whole interactive application. The major strength of these systems is the ability to check the formal description of the models.

Model-based systems allow a user-centered approach of interface design. Nevertheless, two major drawbacks may be pointed out: (1) they require that their users learn abstract models and languages, and (2) they only work in one way, from models to the generated application. When generated, the system has to be tested, and any modification requires a modification of the models to generate a new system.

The goal of this position paper is to propose a solution to these problems. Using PbD techniques, we are now able to design a system that allows much more than a simple adaptability of interfaces: it allows a real interactive definition of new applications. And because of the underlying models we use, it permits reverse engineering from the interactive

The H 4 Model

Presented by L. Guittet [Guittet 1995], the H 4 model has been designed to be a suitable model for CAD systems. These systems are well-known to possess several characteristics : using the taxonomy proposed in [Pierra 1995], they can be described as supporting multi-object and structured tasks, reflecting a goal/subgoal hierarchy [Norman 1986]. Their conceptual objects are highly structured (the user may access several levels of objects, such as sets of entities, or only one component of a given set), and relational (the state of one object may depend on the state of another domain's object).

The H 4 model belongs to the ARCH family [Bass, et al. 1992]. It's dialogue controller is composed of a hierarchic set of agents, named interactors, relatively to the theory of Interactors ( [START_REF] Duke | [END_REF]Faconti & Paterno' 1990 ;[START_REF] Paternó | A semantics-based approach for the design and implementation of interaction objects[END_REF]).

Each of these corresponds to a task level, and is defined by the nature of the information it accepts as input. They produce output informations that are the result of the task. Common interactors in drawing applications include designation (picking graphical entities), information (giving information such as center or extremity of entities), calculus (projection, distance), and creation. Communications between interactors are managed by a Monitor.

Interactors may accept information from any lower interactor in the hierarchy, via the Monitor. The communication unit is a typed element, named Token, that may either be commands (order to initiate actions) or data (parameters of actions). Tokens are transmitted by the monitor to the next interactor waiting for such a token, conforming with the interactor hierarchy.

The H 4 model describes the dynamic behaviour of an application as an advanced automaton.

Each Interactor has a current state and accepts or refuses tokens that are proposed by the Monitor. Acceptation fires a transition and allows the storing of the token in a register.

Transitions may have actions as attributes. Such actions are called when their associated transition is triggered, using the register content 's as parameters.

The H 4 model has been implemented in an application generator that allows the complete generation of interactive systems from formal descriptions of both the user-task model and the dialogue model. It is, in fact, a model-based system.

The GIPSE System

GIPSE (Generateur d'Interface par Programmation Sur Exemple, for Programming by

Example Interface Generator) is a major enhancement of the above generator. Moreover the above functionalities, it is a run-time environment allowing the extension of the application's kernel by the way of adding new functions, as well as new kinds of entities that can be manipulated by the system as native entities. The motivation behind our system is to allow end users to customise their generic applications into task-specific ones. Some applications already allow this, by the way of simple macro recorder facilities (Microsoft Word © or Excel © are good examples here), but most of complex tasks, involving loops or conditional statements, must be expressed in an interpreted language that must be already masterised by users. In contrast, the goal of GIPSE is to create, implement and integrate whole new functionnalities to applications without actually coding them.

The goals of GIPSE can be stated as following: • GIPSE should allow the extension of existing applications.

• The intended targets are either developers who want to specialise their generic system, either CHI experts who want to design interactive applications from some functional core, or end-users who want to extend/customise their application. None should have to be a computer specialist to do this. • Dialogue extension should be specified by means of Programmation by Demonstration (PbD) rather than conventional textual programming.

As it has been underlined, GIPSE implements the H 4 model. It is mainly structured in two components. The first one is responsible for the dynamic behaviour of the application, while the other is responsible for the creation and execution of actions recorded by the user.

Dynamic behaviour

In order to allow indifferent use of regular (hard coded) and extended (macro) actions by the user, the dialogue controller responsible for the dynamic behaviour of the application has itself to be dynamic and extensible. As it is unknown at compile time which actions will (or will not) be included in the application, and the exact stucturation of the actions into interactors, the dialogue controller has to allow adjunction and removal of dialogue threads (that is, successions of command and parameters leading to one action call). The GIPSE system is based on a dynamic version of the H 4 model. Monitor and Interactors are loaded/created at run time via a textual description of their structure and representation. They are maintained in the system as a set of interpreted data rather than a set of functional calls.

The dynamic nature of the controller force the existence of a general dispatcher, responsible for the actual call of the function when requested by an interactor. Interactors call the dispatcher by the way of a message identifying the action to be performed and the parameters.

The dispatcher sends back the response of the action with a report indicating success or failure. From the Interactor's point of view, there is no difference between regular actions and extended ones, both being described as triplets (action reference, parameters, return) and sent to the dispatcher.

The effort made for differentiating macro-actions from hard-wired ones is put on the dispatcher. Separation is done by the way of a database (cf Fig. 1) created during the initialisation of the application: during application's launch, regular actions send their description, while a macro component gives the description for all recorded macros. Later, when the dispatcher gets a message referencing an hard-wired action, it calls the corresponding function in the domain adaptator component, passing the arguments the function needs. When the action is a macro, a dialogue is established between the dispatcher and the Macro-recorder, resulting in the sequential execution of actions given by the latter to the former.

Adding new functionalities

Our experience with PbD in CAD allowed us to easily include a powerful PbD system in GIPSE. Once any PbD function is recorded, it can be integrated seamlessly in the application. This is done by an Integrate command, that prompts (1) for the action to be integrated, (2) for the nature of the action, in terms of task level (thereby identifying an interactor), and (3) for the representation associated with the action. This representation is composed of a label to be displayed on a menu button (which position depends on the chosen interactor), and a help line. As an alternative to (2) it is possible to create a new interactor. In this case, the user is prompted for the name of the new component and its position in the hierarchy. From this point, the new component(s) will behave as if it was created at initialisation time.

Similarly, but with the opposite effect, it is possible to remove any action from any interactor. This may be necessary if the goal of the user is not to expand his/her application, but to specialize it. In this case, removing some functions using no-more-to-be-used parameters or performing no-more-to-be-used actins is essential. This is done with a Disintegrate command that prompts either for the action or the command to be removed. The removal is done at the dialogue controller level and actions still exist at their own level (macro for an PBD-Macro, Domain Adaptator level for hard-wired ones). Any command/action uniquely associated with the action/command to be removed will also be removed.

It should be noticed that any action can be (Dis)integrated from the controller. This operation is done at the dialogue controller level, whereas identification of the nature of an action is done by the dispatcher.

Adding new kinds of objects

The couple made by the dynamic implementation of H 4 model and a macro-recorder allows the adjunction and removal of functionalities to a preprogrammed kernel. Using extended actions to define new kinds of interaction objects makes up for the second step towards a complete CADUI. Such a goal can be achieved by two steps. First it must be possible to create new categories of model objects, new types. Second, these types, to be useful, should also be usable as parameters for new functions.

Any PBD-program creating objects in the application model can be used as the basis for the definition of a new type. The new kind of object is defined as a named group of every object created as a result of the execution of the PBD program. This PBD program can be considered as the type definition, while instances of this type are the result of this action with effective associated parameters. Defining new kinds of objects also involves the automated definition of some functionalities that are associated with this type, such as designation or geometric transformations. They can be inherited from the components of the object: translation of such an object, for example, is a set iteration of the translation on all its components.

New object typing implies the use in the application model of a special set that we call a extended set (x-set for short). Such a set, once created, has a unmodifiable name. Instances of the type are multiples x-set using the same name. Any PBD program resulting in an instance of a new type (that is, used as type definition) begins with creating a x-set with the type as name. During its execution, it add any created object to this set. These objects still exist on their own (independently from the typed object), and may even be part of a user defined set.

The use of new types as function parameters is straightforward. As the parameters are graphically designed, the developer uses the designation function to provide an object of the type of interest. The Macro recorder will then record an x-set along with the name of that particular x-set, as the formal parameter of the action being recorded. From a (macro's) developer's point of view, there is no difference between the use of a standard type or a new one in creation of a new action. In fact, if the developer is not the end user, the latter may not know that there is different kind of objects and actions. If the commands of the macro system are removed from the application, he/she may not even know that there is a macro system.

Related works

GIPSE is a development and run-time environment based on programming by demonstration technique. The development part is expressed in terms of actions and action-tasks levels. In the following, we summarise the main differences between our work and previous works in the related domains.

GIPSE may be assimilated to task-oriented systems. While the creation of new functionalities is straightforward, it does not eliminate the needs for analysing the intent of these actions: how will end-users use them? What tasks are to be used as subtasks? What is the task level for this action? … There are the questions the developer must answer while extending his application.

The absence of more advanced descriptions, such as presentation model or user model, as well as the absence of advanced tools (design critics for example), would make GIPSE a low-end Model Based system [Szekely 1996 ;Wilson & Jonhson 1996] compared to existing ones such as Janus [Balzert 1995 ;Balzert, et al. 1996], Humanoid [Szekely, et al. 1995], Trident [Bodart, et al. 1995] … Nevertheless, the goal and method of GIPSE differ from the ones of these systems. GIPSE has been designed as a specialisation/extension system from an existing, programmed, kernel, whereas these systems have been designed with the goal of easing the whole development process. They generate the code of an application (MasterMind [START_REF] Szekely | Declarative interface models for user interface construction tools : the MASTERMIND approach[END_REF]) or a file description that can be used by existing UIMS generators (FUSE [Lonczewski & Schreiber 1996]), via a formal description of various aspects of the application. In contrast, GIPSE does not need a formal textual description of the task to be added to the application nor it does generate compilable code. GIPSE allows the modification, during execution of the target application, of the existing dialogue structure and components. These modifications are then stored as description of the new dialogue, and restored the next time the application is run. GIPSE is interpreting the task model of the application at run time, much like ITS [Wiecha, Bennet, & al 1989 ;Wiecha, et al. 1990] and Humanoid do for their model.

What is completely new in GIPSE is the dual access between resulting applications and underlying models: we can generate applications from models, and we can see, and best, evaluate, the models that are generated by customized applications as well as entirely new applications coming from interactive design.

Conclusion

In this paper, we have described a system using Programming by Demonstration to allow endusers to customize their applications. More, without any programming knowledge, end-users are able to create powerful applications from existing ones.

Because of the undelying models of our system, we think that it is possible to rely two approaches, which seem, at a first glance, very different: the model-based interface development approach and user-adaptable applications. Despite their obvious difference, we argue that these two approaches may converge, bringing user enpowerment to formal approaches, and conversely, bringing formal insurance to end-user developments.

Bibliography [Balzert 1995] Balzert H. From OOA to GUI : The JANUS-System. InterAct95, 1995. p. 319-324.

Fig

  Fig. 1 : the GIPSE System architecture

From Adaptable Interfaces to Model-Based Interface Development: The GIPSE Project. ERCIM Workshop on User Interfaces for All (UI4ALL'97), Ed. N. Carbonell, Pub. INRIA Lorraine, Obernai, France, 3-4 november 1997, pp. 127-133.

Patry G. & Girard P.

Patry G. & Girard P. From Adaptable Interfaces to Model-Based Interface Development: The GIPSE Project. ERCIM Workshop on User Interfaces for All (UI4ALL'97), Ed. N. Carbonell, Pub. INRIA Lorraine, Obernai, France, 3-4 november 1997, pp. 127-133.