Francis Jambon
email: jambon@ensma.fr

Patrick Girard
email: girard@ensma.fr

Yamine Aït-Ameur
email: yamine@supaero.fr

Interactive System Safety and Usability Enforced with the Development Process

This paper introduces a new technique for the verification of both safety and usability requirements for safety-critical interactive systems. This technique uses the model-oriented formal method B and makes use of an hybrid version of the MVC and PAC software architecture models. Our claim is that this technique -that uses proofs obligations-can ensure both usability and safety requirements, from the specification step of the development process, to the implementation. This technique is illustrated by a case study: a simplified user interface for a Full Authority Digital Engine Control (FADEC) of a single turbojet engine aircraft.

1.

Introduction

Formal specification techniques become regularly used in the area of computer science for the development of systems that require a high level of dependability. Aircraft embedded systems, the failure of which may cause injury or death to human beings belong to this class. On the one hand, user-centered design leads to semi-formal but easy to use notations, such as MAD [START_REF] Scapin | Towards a method for task description : MAD in Working with display units[END_REF] and UAN [START_REF] Hix | Developping user interfaces: Ensuring usability through product & process[END_REF] for requirements or specifications, or GOMS [START_REF] Card | The Psychology of Human-Computer Interaction[END_REF] for evaluation. These techniques could express relevant user interactions but they lack clear semantics. So, neither dependability nor usability properties can be formally proved. On the other hand, adaptation of well-defined approaches, combined with interactive models, gives partial but positive results. Among them, we find the interactors and related approaches [START_REF] Duke | Abstract Interaction Objects[END_REF][START_REF] Paternò | A Theory of User-Interaction Objects[END_REF], model-oriented approaches [START_REF] Duke | Abstract Interaction Objects[END_REF], algebraic notations [START_REF] Paternò | On the LOTOS use to describe graphical interaction in[END_REF], Petri nets [START_REF] Palanque | Modélisation par Objets Coopératifs Interactifs d'interfaces homme-machine dirigées par l'utilisateur[END_REF] or temporal logic [START_REF] Brun | XTL: a temporal logic for the formal development of interactive systems in Formal Methods for Human-Computer Interaction[END_REF][START_REF] Abowd | A Formal Technique for Automated Dialogue Development[END_REF]. Thanks to these techniques, some safety as well as usability requirements may be proved. Nevertheless, theses formal techniques are used in the development process in a limited way because of two constraints:

• Formal techniques mostly depend on ad hoc specification models -e.g. interactorsand do not concern well-known software architecture models as Arch, MVC or PAC. As a consequence, these unusual models make the specification task hard to use by most user interfaces designers. • Few of these formal techniques can preserve formal semantics of the requirements from the specification to the implementation steps. Most of them can prove ergonomic properties at the specification level only. So, it cannot be proved that the final software is exactly what has been specified.

This article focuses on the B method [START_REF] Abrial | The B Book: Assigning Programs to Meanings[END_REF][START_REF] Lano | The B Language Method: A guide to practical Formal Development[END_REF]. On the one hand, compared to VDM and Z, it makes possible the definition of a constructive process to build whole applications, with the respect of all the rules by the use of a semi-automatic tool [12].

On the other hand, the interactive system can be specified with respect to well-known software architecture models as Arch [START_REF] Aït-Ameur | A Uniform approach for the Specification and Design of Interactive Systems: the B method[END_REF]. In this paper, we will show how the B method can be used to specify a critical system, the FADEC user interface case study, and how dependability as well as user interface honesty can be proved. This work may be considered as a new step towards the definition of an actual interactive development method based on formal approaches. Our first results [START_REF] Aït-Ameur | A Uniform approach for the Specification and Design of Interactive Systems: the B method[END_REF][START_REF] Aït-Ameur | Using the B formal approach for incremental specification design of interactive systems in Engineering for Human-Computer Interaction[END_REF] focus on low-level interaction mechanisms, such as mouse and window control. We showed that the B method might be used with profit in interactive development. Our aim in this article is to apply the method on critical systems for two main reasons. First, we believe that critical systems are applications of primary importance for safe methods. In addition, critical systems introduce special needs in terms of flow of control. So, we focus on two main points: (1) how can the specification of both critical systems and the B method influence software architecture -e.g. how B method constraints can be interpreted into well known HCI approaches-and ( 2) what are the benefits of using the B method for the specification process of critical systems. The paper is organized as follows: in section 2, the B method is presented, and some previous results in applying formal approaches in HCI context are briefly summarized. In section 3, a study upon architecture models suitable for both critical systems and the B method is detailed. Last, the fourth section describes the specification of the case study and explains how the safety and usability requirements can be formally checked.

The B Method and Interaction Properties [14]

The B method allows the description of different modules, i.e., abstract machines that are combined with programming in the large operators. This combination enables designers to build incrementally and correctly -once all the proof obligations are proved-complex systems. Moreover, the utmost interest in this method, in our case, is the semi-automatic tool it is supported by.

The Abstract Machine Notation

The abstract machine notation is the basic mechanism of the B method. J.-R. Abrial defined three kinds of machines identified by the keywords MACHINE, REFINEMENT and IMPLEMENTATION. The first one represents the high level of specification. It expresses formal specification in a high abstract level language. The second one defines the different intermediate steps of refinement and finally the third one reaches the implementation level. Do note that the development is considered to be correct only when every refinement is proved to be correct with respect to the semantics of the B language. Gluing invariant between the different machines of a development are defined and sets of proof obligations are generated. They are used to prove the development correctness. A theorem prover including set theory, predicates logic and the possibility to define other theories by the user, achieves the proof of these proof obligations. The proving phase is achieved either automatically, by the theorem prover, or by the user with the interactive theorem prover. The model checking method, which is known to be often overwhelmed by the number of states that are needed to be computed is not used in the present version of the B tool [12].

Description of Abstract Machines

J.-R. Abrial described a set of relevant clauses for the definition of abstract machines.

Depending on the clauses and on their abstraction level, they can be used at different levels of the program development. In this paper, a subset of these clauses has been used for the design of our specifications. We will only detail these clauses. A whole description can be found in the B-Book [START_REF] Abrial | The B Book: Assigning Programs to Meanings[END_REF]. The typical B machine starts with the keyword MACHINE and ends with the other keyword END. A set of clauses can be defined in between. In our case, these clauses appear in the following order:

-INCLUDES is a programming in the large clause that allows to import instances of other machines. Every component of the imported machine becomes usable in the current machine. This clause allows modularity capabilities. -USES has the same modularity capabilities as INCLUDES except that the OPERATIONS of the used machines are hidden. So, the imported machine instances cannot be modified.

-SETS defines the sets that are manipulated by the specification. These sets can be built by extension, comprehension or with any set operator applied to basic sets. -VARIABLES is the clause where all the attributes of the described model are represented. In the methodology of B, we find in this clause all the selector functions which allow accessing the different properties represented by the described attributes. -OPERATIONS clause is the last clause of a machine. It defines all the operations -functions and procedures-that constitute the abstract data type represented by the machine. Depending on the nature of the machine, the OPERATIONS clause authorizes particular generalized substitutions to specify each operation. The substitutions used in our specifications and their semantics is described below.

Other syntax possibilities are offered in B, and we do not intend to review them in this article, in order to keep its length short enough.

Semantics of Generalized Substitutions.

The calculus of explicit substitutions is the semantics of the abstract machine notation and is based on the weakest precondition approach of Dijkstra [START_REF] Dijkstra | A Discipline of Programming[END_REF]. Formally, several substitutions are defined in B. If we consider a substitution S and a predicate P representing a postcondition, then [S]P represents the weakest precondition that establishes P after the execution of S. The substitutions of the abstract machine notation are inductively defined by the following equations. Do notice that we restricted ourselves to the substitutions used for our development. The reader can refer to the literature [START_REF] Abrial | The B Book: Assigning Programs to Meanings[END_REF][START_REF] Lano | The B Language Method: A guide to practical Formal Development[END_REF] for a more complete description:

[SKIP]P ⇔ P (1)

[S1 || S2]P ⇔ [S1]P ∧ [S2]P (2)
[PRE E THEN S END]P ⇔ E ∧ [S]P

[ANY a WHERE E THEN S END]P ⇔ ∀ a (E ⇒ [S]P) (4) [SELECT P1 THEN S1 WHEN P2 THEN S2 ELSE S3 END]P ⇔ (P1⇒[S1]P) ∧ (P2⇒[S2]P) ∧ ((¬P1 ∧ ¬P2)⇒[S3]P) (3)
[x:=E]P ⇔ P(x/E) (5)
The substitution (6) represents the predicate P where all the free occurrences of x are replaced by the expression E. Do notice that when a given substitution is used, the B checker generates the corresponding proof obligation, i.e., the logical expression on the right hand side of the operator "⇔". This calculus propagates a precondition that must be implied by the precondition set by the user. If not, then the user proves the precondition or modifies it. For example, if E is the substitution [x+1] and P the predicate x ≠ 2, the weakest precondition is x ≠ 1.

Interaction Properties

Proving interaction properties can be achieved by the way of model checking or theorem proving [START_REF] Campos | Formally Verifying Interactive Systems: A Review[END_REF]. Theorem proving is a deductive approach to the verification of interactive properties. Unless powerful theorem provers are available, proofs must be made "by hand". Consequently, they are hard to find, and their reliability depends on the mathematical skills of the designer. Whereas model checking is based on the complete verification of a finite state machine, and may be fully automated. However, one of the main drawbacks of model checking is that the solution may not be computed due to the high number of states [START_REF] Campos | Formally Verifying Interactive Systems: A Review[END_REF]. The last sessions of EHCI as well as DSV-IS show a wide range of examples of these two methods of verification. For instance, model checking is used by Palanque et al. who model user and system by the way of object-oriented Petri nets -ICO- [START_REF] Palanque | Validating interactive system design through the verification of formal task and system models[END_REF]. They argue that automated proofs can be done to ensure first there is no cycle in the task model, second a specific task must precede another specific task (enter_pin_code and get_cash in the ATM example) and third the final functional core state is the final user task (get_cash and get_card). These proofs are relative to reachability. Furthermore, Lauridsen uses the RAISE formalism to show that an interactive application -functional core, dialogue control and logical interaction-can be built using translations from the functional core adapter specification [START_REF] Lauridsen | Systematic methods for user interface design[END_REF]. Then, Lauridsen shows that his refinement method can prove interaction properties as predictability, observability, honesty, and substitutivity.

In the meantime, Paternó and Mezzanotte check that unexpected interaction trajectories expressed in a temporal logic -ACTL-cannot be performed by the user.

The system -a subset of an air traffic control application-is modeled by interactors specified with LOTOS [START_REF] Paternò | Formal verification of undesired behaviours in the CERD case study[END_REF]. Brun et al. use the translation from a semi-formal taskoriented notation -MAD- [START_REF] Scapin | Towards a method for task description : MAD in Working with display units[END_REF] to a temporal logic -XTL- [START_REF] Brun | XTL: a temporal logic for the formal development of interactive systems in Formal Methods for Human-Computer Interaction[END_REF] and prove reachability [START_REF] Brun | Utilisation des spécifications formelles dans le processus de conception des Interfaces Homme-Machine[END_REF].

Our approach in this article -with the B method-deals with the first method, i.e., theorem proving. Yet, the method does not suffer from the main drawbacks of theorem proving methods, i.e., proving all the system "by hand". In our former studies [START_REF] Aït-Ameur | A Uniform approach for the Specification and Design of Interactive Systems: the B method[END_REF][START_REF] Aït-Ameur | Using the B formal approach for incremental specification design of interactive systems in Engineering for Human-Computer Interaction[END_REF], about 95% of the proofs obligations, regarding visibility or reachability, were automatically proved thanks to the "Atelier B" tool. Our present work -the FADEC user interface specification-has been successfully and fully automatically proved. All proof obligations, regarding safety and honesty, have been distributed in the separate modules of the system specification, as we will see later on. Moreover, since the specification is incrementally built, the proofs are also incrementally built. Indeed, compositionality in B ensures that the proofs of the whole system are built using the ones of the subsystems. This technique simplifies considerably the interaction property verifications. And then, this incremental conception of applications asserts that the proofs needed at the low-level B-machines of the application, i.e. the functional core, are true at the higher levels, i.e. the presentation. So, the reliability is checked by construction.

The FADEC Case Study and its Software Architecture

A FADEC (Full Authority Digital Engine Control) is an electronic system that controls all the crucial parameters of aircraft power plants. One of the system roles is to lower the cognitive load of pilots while they operate turbojet engines, and to reduce the occurrence of pilot errors.

Our case study focuses on the startup and the shutdown procedures of a single turbojet engine aircraft. In our scenario, the pilot controls the engine ignition -off, start, run-and the fuel valve -closed, open. The engine states can be perceived via the fuel pressure -low, normal, high-and the engine temperature -low, normal, high. The system interface is composed of lights and push buttons. The interface layout adopts the dark cockpit philosophy which minimizes distracting annunciation for pilots, i.e. only abnormal or transition states are visible. So, the normal parameters of the engine during flight do not light up any interface lights.

In this section, we start with an analysis of constraints imposed by the B language over architecture design. Secondly, we explain why "pure" MVC and PAC models fail against B requirements. Lastly, we describe our hybrid model, named CAV.

Rules for B Architecture Design

Our case study belongs to the safety-critical interactive-system category. More precisely, as in common interactive systems, the user controls the software system, but, as a reactive system, a third part, that evolves independently from both the software system and the user, must also control the system. In first approximation, the software may be modeled as a unique view that displays some functional core under a specific interactive control. Our first idea for designing such a system was to use a well-known multi-agent model, such as MVC or PAC, because acceptability of formal methods is greatly influenced by using domain standard methods.

The interactive system specifications must however stay in the boundaries of the B language constraints. We selected three kinds of constraints that relate to our purpose. These main constraints are: 1. Modularity in the B language is obtained from the inclusion of abstract machine instances -via the INCLUDES clause-and, according to the language semantics, all these inclusions must form a tree. 2. The substitutions used in the operations of abstract machines are achieved in parallel. So, two substitutions -or operations-used in the same operation cannot rely on the side-effects of each other. So, they are not allowed on the abstract machines specifications. 3. Interface with the external world, i.e. the user actions as well as the updates of system state must be enclosed in the set of operations of a single abstract machine.

Classical Multi-Agent Architecture Models

As we explained in the upper section, our first impulse was to apply directly a classical multi-agent approach to our problem. Nevertheless, we discovered rapidly that none of them could be used without modification. In this section, we briefly describe MVC and PAC architecture models and relate how they are inappropriate.

MVC is an acronym for "Model, View, Controller". It is the default architecture model for the Smalltalk language [START_REF] Goldberg | Smalltalk-80: The Interactive Programming Environment[END_REF], and became the first agent-based model for The PAC model, for "Presentation, Abstraction, Control" was proposed in 1987 by J. Coutaz [START_REF] Coutaz | an Implementation Model for the User Interface[END_REF]. Opposed to MVC, it is absolutely independent from languages. Agents are made of facets, which express complementary and strongly coupled computational services. The Presentation facet gives the perceivable input and output behavior of the object. The Abstraction facet stands for the functional core of the object. As the application itself is a PAC agent, no more component represents the functional core.

There is no application interface component. The Control facet insures coherency between Presentation and Abstraction. It solves conflicts, synchronizes the facets, and refreshes the states. It is also takes charge of communication with other agents -their Control facets. Lastly, it controls the formalism transformations between abstract and concrete representations of data. The PAC model gives another dimension as interactive objects are organized in hierarchies. Communication among the Control facets in the hierarchy is precisely defined. Modification to an object may lead its Control facet to signal this modification to the Control facet of parent object, which may in turn communicate this modification to its siblings. This allows all the parts of the application to correctly refresh. We believe that this precise point -i.e. the honesty property-may be directly addressed in a B development. It is the basis for the refinement steps we intend to conduct.

Presentation Abstraction

User

Control

Other PAC agents PAC solves the problem of MVC, because the Control facet is the only responsible for synchronizing the other two facets. Unfortunately, PAC does not respect the third rule on a unique entry point. In classical interactive systems, the unique entry point is the user. So, the Presentation facet may be considered as the unique entry point of the program. But, in safety critical systems, the reactive system itself is another external entity that must be taken into account. For that purpose, the presentation facet does not seem to be a good candidate.

The Hybrid CAV Model (Control-Abstraction-View)

We propose an hybrid model from MVC and PAC to solve this problem. The model uses the external strategy of MVC: the outputs of the system are devoted to a specific abstract machine -the View-while inputs are concerned by another one -the Controlthat also manages symmetrical inputs from the reactive system which is directed by the third abstract machine -the Abstraction. The Control machine synchronizes and activates both View and Abstraction machines in response to both user and aircraft events, though assuming its role of control.

To limit exchanges between control and the two other components, a direct link is established between the View and the Abstraction, to allow the former to extract data from the latter. This point is particularly important in the B implementation of this model, because of the second rule we mentioned upper, that enforces to pay particular attention to synchronization problems between machines. This last point is mainly discussed in the following section.

The FADEC User Interface Specification in B

In this section, we detail the development process we used for the case study, and we focus on HCI requirement satisfaction. The first step consists in modeling the FADEC, using the CAV architecture model we described in the previous section. The second step concentrates on safety requirements, that concerns inputs. The third step pays attention to honesty property, mainly outputs. Lastly, we illustrate the expressive power of the B method with iterative resolution of side effects on our specification.

Two kinds of requirements must be fulfilled:

• The system must be safe, i.e. the pilot must not be able to damage the engine. For example, the fuel pressure must be normal in order to begin the startup sequence.

• The system must be honest, i.e. the user interface lights must reflect the exact engine parameters -pressure and temperature-at any moment.

Modeling the FADEC User Interface

Applying our architecture model to the FADEC case study is straightforward. Each B machine encapsulates few attributes.

The Engine abstract machine -the Abstraction-models the functional core of the FADEC, e.g. the engine control parameters in the VARIABLE clause, and the variation sets of them in the SETS and INVARIANT clauses. The SETS are defined in respect to the logical description of the system, and a unique "SetProbeData" is defined for both the fuel pressure and the engine temperature:

Safety Requirements

The first requirement of the FADEC is safety. For instance, the start mode must not be used if the fuel pressure is not normal. This property must always be satisfied. In B, this requirement may be enforced with an INVARIANT clause that applies on the variables Ignition and FuelPress. The Engine abstract machine which represents the system functional core is responsible for it, with the following B expression:

(Ignition = start FuelPress normal)
We do not pay attention to what action is done. We only focus on the fact that never abnormal fuel pressure may be observed when startup is processing. In the semantics of B, the invariant must equal true at the initialization of the abstract machine, at the beginning and at the end of any operation. Note that the substitutions of the initialization as well as the operations are assumed to be executed in parallel.

Of course, the startup operation of the engine must satisfy this invariant, so the operation is guarded by an ad-hoc precondition PRE that ensures the operation will never be used if the fuel pressure is different from normal:

startup = PRE FuelPress = normal THEN Ignition := start END ;
For HCI, what is interesting now is: Is the user able to make an error? Whatever the user does, the B specification of the engine machine ensures that it will not be possible to violate the invariant. What about user actions and user interface state now? In our architecture model, the Control abstract machine is responsible for user inputs and for functional core actions activation. As a consequence, it must include an instance of the Engine abstract machine, and must use its operations within their specifications. Using B allows propagating the conditions. A new guard can/must be set for the operation used when the pilot presses the startup button. We do not give the engine the responsibility for controls, we propagate this semantic control to the user interface. One basic solution is to guard the activation of the startup button in the Control abstract machine by the precondition engine.FuelPress normal: This basic solution suffers from two main drawbacks:

• The redundancy of preconditions is needed by modular decomposition of the B abstract machines • The pilot's action on the system is blocked without proactive feedback, i.e. the pilot can press the startup button and nothing happens.

A more clever design is to delegate the safety requirements of the functional core to the user interface. In this new design, the user interface startup button is disabled while the startup sequence cannot be initiated for safety reasons. Now the user interface is in charge with the safety requirements of the system. Two modifications are needed:

• The startup operation of the Control abstract machine is now guarded by the state of the startup button:

view.StartButtonEnabled = TRUE
• The invariant must ensure that the startup button is disabled when the fuel pressure is not normal and enabled otherwise:

( (engine.FuelPress = normal ∧ view.StartButtonEnabled = TRUE) ∨ (engine.FuelPress ≠ normal ∧ view.StartButtonEnabled = FALSE) )
The B semantics -and the Atelier B tool-checks for the validity of these assertions, and ensures for the compatibility of all abstract machines operations. Our software is now assumed not to allow the pilot doing anything wrong that can damage the turbojet engine.

Usability Requirements

Honesty is a well known property in user interfaces [START_REF] Gram | Design Principles for Interactive Software[END_REF]. In safety critical systems, system honesty is crucial because user actions depend on the user capacity to evaluate the state of the system correctly. This point assumes the displayed state is the state of the actual system. Ensuring user interface honesty requires the specification to prove that the system state -represented by Engine variables-is always reflected in the pilot interface -represented by View variables. Like safety requirements, this requirement stands for an always true invariant. It seems conspicuous that the honesty property must be stipulated in the INVARIANT clause of the View abstract machine. However, updates of the Engine and View variables are achieved in parallel by the operations of the Control abstract machine, because of the B semantics constraints -quoted in the §3.1. As a result, it is impossible to get the Engine variables update before the View variables update. As a consequence, the honesty property must be stipulated in the INVARIANT clause of the Control abstract machine only. For example, the light FuelValveClosed must be on only when the fuel valve is closed. We can express it by an exhaustive invariant that gives the two right solutions:

( (engine.FuelValve = closed ∧ view.FuelValveClosed = TRUE) ∨ (engine.FuelValve ≠ closed ∧ view.FuelValveClosed = FALSE) )
Our software architecture model assumes that the Control abstract machine really acts. So, the operation of the Control abstract machine, which is used when the pilot presses the close button, i.e. the close_fuel_button_pressed action, must update both the Engine state and the View state:

Specificity of Asynchronous Systems

In critical systems such as the FADEC, some parts of the system change without any interaction with the user. For example, a probe whose control is obviously outside of the system updates the fuel pressure. A real-time kernel is in charge of interrogating every probe and sending responses to the whole system. In our analysis, the real-time kernel is out of our scope. Nevertheless, its entry point into our system must be defined. We propose to manage the aircraft in a way that is symmetric to the user. As stated in figure 1, it is controlled by the Engine abstract machine. When events are initiated by the aircraft power plant, their entry point is the Control abstract machine. So doing, the Control is completely in charge of updating the internal state -functional core-and the external state of the application -view. More, it can also ensure that the state of interaction is also correct. Because we were focusing on HCI, we did not really pay attention to this side of the application. In our sense, one of the most interesting result of our study is the following: the B method helped us to discover a hazardous but important side-effect. The automatic prover detected a problem with fuel pressure invariant as soon as we introduced the action that updates this pressure into the functional core: on the one hand, the fuel pressure must be normal during the startup sequence, otherwise, the pilot cannot press the start button. On the other hand, if the fuel pressure falls down when the Engine abstract machine is in start mode, the turbojet engine must stop. We did not take this case into account. Fortunately, the B semantics does not allow this. Therefore, the Engine abstract machine must be enhanced: As a result, the Control abstract machine must update the View accordingly:

Conclusion

A previous work [START_REF] Aït-Ameur | A Uniform approach for the Specification and Design of Interactive Systems: the B method[END_REF][START_REF] Aït-Ameur | Using the B formal approach for incremental specification design of interactive systems in Engineering for Human-Computer Interaction[END_REF] show that the B language can be used to specify WIMP interactive systems and ensure usability properties. This work shows that the B method can enforce safety and usability in a process-control interactive system with asynchronous behavior. Moreover, this study covers specification and design topics: we define a new software architecture model, that allows an actual instantiation with the B method, and we describe an empiric method for modeling safety-critical interactive systems in B. Four points may be enlightened:

safety and usability are ensured by using invariant that are relatively easy to find from the non formal description of the system behavior, incremental development can be achieved with this method, which is particularly suitable in HCI domain, using the B tool is very helpful for ensuring specification completeness, as we discovered during our analysis, the modules and then the whole specification may be completely validated thanks to the prover, in a whole automated way.

At the end of the last step, the specification must be considered as safe respect with to the requirements -safety and usability.

This work is a second step towards a real method for specifying, designing and implementing interactive systems with the B method. The perspectives are numerous. First, we need to use the B refinement theory to implement the specifications we realized. This step, which has already been initiated, will lead us to pay a particular attention to the connections with user interface toolkits. Then, a more exhaustive study must be accomplished to evaluate what properties may be enforced using the B language, and what properties cannot. This will then allow us to design a safety critical system with the collaboration of a set formal methods to avoid limitations among each methods.

Fig. 1 .

 1 Fig. 1. The three components of the Model-View-Controller software architecture model

Fig. 2 .

 2 Fig. 2. The three facets of the Presentation-Abstraction-Control software architecture model

Fig. 3 .

 3 Fig. 3. The three components of the Control-Abstraction-View software architecture model

  start_button_pressed = PRE engine.FuelPress = normal THEN engine.startup || … END ;

  update_fuel_press (fuel_data) = PRE fuel_data ∈ SetProbeData THEN FuelPress := fuel_data || SELECT Ignition = start ∧ fuel_data ≠ normal THEN Ignition := off END END ;

  -INVARIANT clause describes the properties of the attributes defined in the clause VARIABLES. The logical expressions described in this clause remain true in the whole machine and they represent assertions that are always valid. -INITIALISATION clause allows giving initial values to the VARIABLES of the corresponding clause. Do note that the initial values must satisfy the INVARIANT clause predicate.

	Jambon, F., Girard, P. and Aït-Ameur, Y. Interactive System Safety and Usability enforced with the
	development process, in Proc. Engineering for Human-Computer Interaction (EHCI'01) (Toronto, Canada,
	May 11-13, 2001), PREceedings, pp. 61-76.

  Jambon, F., Girard, P. and Aït-Ameur, Y. Interactive System Safety and Usability enforced with the development process, in Proc. Engineering for Human-Computer Interaction (EHCI'01) (Toronto, Canada, May 11-13, 2001), PREceedings, pp. 61-76.

  Jambon, F., Girard, P. and Aït-Ameur, Y. Interactive System Safety and Usability enforced with the development process, in Proc. Engineering for Human-Computer Interaction (EHCI'01) (Toronto, Canada,[START_REF] Jambon | Interactive System Safety and Usability enforced with the development process[END_REF], PREceedings, pp. 61-76. HCI. This model splits the responsibility for user interface into autonomous agents that communicate by messages, and are divided into three functional perspectives: Model stands for application data, and their access. It is the only object that is allowed to communicate with other Model objects. View is in charge of graphical outputs. It gives the external representation of the domain data, using Model objects services to extract the data to be presented. It also presents the perceivable behavior of the agent. This separation between Model and View allows a Model to own several Views. Lastly, Controller is responsible for inputs, and for making perceivable the behavior of the agent. It also manages the interactions with the other Controllers. When the user gives some input, the associated Controller triggers a Model function. Then, the Model sends a message to all its Views to inform them for a change. Each View may request for the new state of the Model, and can refresh the graphical representation if needed. The main problem with MVC is the double link between the View and the Model. This point violates the first rule we identified, which concerns B abstract machine inclusion order. More precisely, the Model cannot access the View -for sending it a message-if the View must ask the Model for data to be visualized.

	User
	Controller	View
	Model

  Jambon, F., Girard, P. and Aït-Ameur, Y. Interactive System Safety and Usability enforced with the development process, in Proc. Engineering for Human-Computer Interaction (EHCI'01) (Toronto, Canada, May 11-13, 2001), PREceedings, pp. 61-76.

  Jambon, F., Girard, P. and Aït-Ameur, Y. Interactive System Safety and Usability enforced with the development process, in Proc. Engineering for Human-Computer Interaction (EHCI'01) (Toronto, Canada, May 11-13, 2001), PREceedings, pp. 61-76.

	Control
	Abstraction
	(Engine)

  Jambon, F., Girard, P. and Aït-Ameur, Y. Interactive System Safety and Usability enforced with the development process, in Proc. Engineering for Human-Computer Interaction (EHCI'01) (Toronto, Canada, May 11-13, 2001), PREceedings, pp. 61-76.Another consequence is that the operation of the View abstract machine must properly update the variable:

	close_fuel_button_pressed =
	BEGIN
		engine.close_fuel ||
		view.update_ui( engine.Ignition, closed,
		engine.FuelPress, engine.EngineTemp,
		view.StartButtonEnabled	)
	END ;
	update_ui (ignition, fuel_valve, fuel_press, engine_temp, start_button_enabled) =
	PRE	ignition ∈ SetIgnition ∧ fuel_valve ∈ SetFuelValve ∧ engine_temp ∈ SetProbeData ∧ fuel_press ∈ SetProbeData ∧ start_button_enabled ∈ BOOL
	THEN
		ANY fvc WHERE fvc ∈ BOOL ∧ ( (fuel_valve = closed) ⇒ (fvc = TRUE) ) ∧ ( (fuel_valve ≠ closed) ⇒ (fvc = FALSE) )
		THEN
		FuelValveClosed := fvc
		END || ...
	END

Yamine AÏT-AMEUR is now Professor at ENSAE-SUPAERO, ONERA-DTIM, 10 av. Edouard Belin, BP 4032, 31055 Toulouse cedex, France.

[START_REF] Jambon | Interactive System Safety and Usability enforced with the development process[END_REF], PREceedings, pp. 61-76.

Acknowledgements

We thank Hervé BRANLARD and Joël MITARD for their documentation about operational FADEC procedures, and Sylvie FERRÉS for the English review.

MACHINE

The Control abstract machine is the centralized control of the system. So, it does not need to define any functional core nor presentation variables which are already defined in the Engine and View abstract machines respectively. On the other hand, it must include the sets, the variables and the operations of both instances of Engine and View:

The sets, the variables and some of the invariants of the three abstract machines are now precisely defined. We can focus on the INVARIANT clauses that ensure safety.


Guillaume Texier
email: texier@ensma.fr

Fabrice Depaulis
email: depaulis@ensma.fr

Laurent Guittet
email: guittet@ensma.fr

End-User Class Definition in CAD Systems

The object-oriented paradigm is very used in CAD systems. It permits users to create objects and to interrogate their attributes to use them in other processes. While some CAD or drawing systems support end-user programming in order to abstract building functions, none of them permit creating classes where several functions (constructor and selectors) share the same data. A data model that permits to abstract a class from one of its instances built by the end-user is described in this paper. The proposed technique permits the user not only to describe interactively the class constructor, but also to build the class selectors without any programming knowledge. The created class can be used directly thanks to a specific interpretation mechanism, or the corresponding code can be generated and compiled to have persistent classes. This technique has been used in a CAD system that permitting end-user specialization.

Introduction

In order to increase the usability of interactive systems, and particularly of Computer Aided Design (CAD) applications, customization seems unavoidable. In the meantime, this adaptation cannot be realized by end-users, who generally have no sufficient expertise in programming. In this paper, we describe how end-users with no programming knowledge may define true domain specific classes.

A class can be viewed as a description of a set of objects that share the same structure and the same behavior. It is composed of a set of attributes (properties) and a set of subroutines or functions. Each class owns two components [START_REF] Masini | Les Langages à Objets[END_REF]:

• The static component is composed of attributes, e.g.

named fields with values. Object states are represented by these fields. • The dynamic component is characterized by the methods that represent the common behavior of objects that belong to the same class. Methods are used to handle the object fields. They represent the actions that can be done on or by objects, and permit the transitions between the states attributes describe. Defining interactively new classes consists in describing both attributes and methods. Methods can be structured into three categories: In order to create new classes, the main difficulty comes from the fact that several functions that share the same data have to be defined interactively. The goal of this paper is to propose a specific data structure that permits to overcome this problem.

Two kinds of techniques permit end-users to create programs interactively. On the one hand, programming by demonstration [START_REF] Cypher | Watch What I Do: Programming by D e m o n s t r a t i o n[END_REF], which from the Human Computer Interaction research field, consists in recording user interaction in order to abstract programs. Another definition might be creating a program from an example of its execution. On the other hand, a technique to record the building process of geometric objects in order to reevaluate it with different data has been proposed by geometric modeling community. This technique is called parametric geometry [START_REF] Shah | Parametric and Feature-based CAD/CAM: Concepts, Techniques and Applications[END_REF]. Even if these two techniques permit recording programs, they cannot be directly used to describe classes. Actually, they cannot be used to group different methods together in one class and then to describe the attributes of that class.

The solution we suggest in this paper is based on a parametric model augmented by abstraction principles that come from programming by demonstration techniques. In the next section, the advantages and drawbacks of programming by demonstration and parametric geometry are studied in the perspective of interactive class definition. The third section is dedicated to the description of our approach. It focuses on the way constructors and attributes may be described. Section 4 details the generalization phase, while section 5 details an example.

End-user programming methods

End-user programming methods generally consist in abstracting a program from an example of its execution. In our context, it means that a class may be abstracted from one of its instances. So the user has to define not only how the object is built (abstracting the class constructor) but also the way the attributes are computed (abstracting the selectors). Two slightly different approaches have been developed to capture a program without explicit programming. The first one is known as programming by demonstration, the second one is called parametric geometry.

Programming by demonstration

Programming by demonstration (PBD) has been introduced to permit end-users to create programs without explicit programming. This technique is used in several domains: games, desktop applications, drawing applications, and so on. For example the Topaz system [START_REF] Myers | Scripting Graphical Applications by Demonstration[END_REF] creates macros that can generalize some drawing actions. Other systems are able to generate programs in neutral language that can be used by other systems. For example the EBP system [START_REF] Pierra | The EBP system : Example Based Programming for Parametric Design[END_REF] generates FORTRAN programs for exchanging CAD geometry.

Programming by demonstration means creating a program using an example of its execution. An important notion brought by the programming by demonstration technique is the abstraction method. In classical programming languages, the program manipulates variables by their names. Conversely, PbD allows the "program" to directly manipulate variables through their values. The link between names and values is made in a symbol table, called the context [START_REF] Pierra | The EBP system : Example Based Programming for Parametric Design[END_REF]. Thus, every program variable is referenced without ambiguity regardless of its value. Creating a program, that deals only with variable names, from an example of its execution needs to associate each variable name with each value. This is the task of the dynamic context. For each created value in the example, a new variable name (whose data type is defined by the value) is added to the dynamic context. These variable names may be used in the generated program.

The ability to specify program parameters must also be provided by programming by demonstration systems. There are two main approaches to define the parameters of programs constructed by demonstration. The implicit manner described by Bauer [START_REF] Bauer | Programming by Examples[END_REF] or Lieberman [START_REF] Lieberman | Tinker: A Programming by Demonstration System for Beginning Programmers[END_REF] consists in creating several examples of the same program. Then, the system automatically infers the parameters after an analysis of the different examples. With the explicit manner, the PBD user has to define which values are program parameters. The other values are considered by the PBD system as constants. This paper follows the second approach.

The two main advantages of PBD are the program abstraction and the parameter definition. For our purpose, PBD might be a good approach; for example, Mondrian [START_REF] Lieberman | Mondrian: a Teachable Editor[END_REF] allows end-users to create new objects and to include them as native objects in the interactive system. However, it does not allow the user to define parts or attributes onto the designed objects. The main drawback of programming by demonstration regarding class definition is that in reexecution mode, the internal data of the program cannot be accessed by other programs. This is a real difficulty for designing class attributes.

Parametric geometry

The parametric geometry comes from the CAD field. In this area, geometrical objects are often made by constrained constructs; for example a line can be explicitly parallel to another line [START_REF] Shah | Parametric and Feature-based CAD/CAM: Concepts, Techniques and Applications[END_REF][START_REF] Zalik | An Interactive Constraint-Based Graphics System with Partially Constrained Form-Features[END_REF]. The goal of parametric geometry is to permit the dynamic modification of geometrical entities; for example if a circle is created using the intersection of two lines as center (Figure 1), the modification of one of these lines leads to move the circle. Figure 1 shows an example of a parametric construct: a circle whose radius is calculated an another circle radius and whose center is the intersection of two lines. In parametric geometry, each entity records the sequence of functions that are used for its creation. This sequence of functions can be seen as a building tree like in Figure 1, and might be seen as a good starting point for program creation. Unfortunately, most of CAD systems that use parametric geometry do not really have the necessary tools to abstract programs. In parametric geometry, there is no notion of parameters or constants: all the nodes of the tree can be modified and then the objects that depend on the modified nodes are re-evaluated. The main advantage of this approach is that it permits a program (a building process) to access internal data (building process nodes) of another program. So this technique can be easily used to define classes with constructors and selectors. But, this method has two drawbacks. The first one concerns the abstraction of the program. Extracting independent programs from the recorded sequence of functions is rarely given to the user. The second one is that few systems offer the possibility to define program parameters. Parametric geometry does not offer the possibility to explicitly define the signature of classes.

Data model for class definition

We propose a model based on a functional parametric model (which allows recording the building process), enhanced with attributes process definition.

The parametric model

The main characteristic of the parametric models regarding the classical geometric models is the possibility to save the building process of each geometrical entity.

Figure 2 shows an EXPRESS [START_REF] Schenck | I n f o r m a t i o n Modelling The EXPRESS Way[END_REF] schema that represents the parametric model. Rectangles represent classes, thin lines represent attributes, and thick lines represent inheritance relations (not used on Figure 2). The Object class owns an attribute called Parameters which is a list of Object.

Each class of our model have an optional link to a geometric, numeric or textual value which depends on the class (the current instance attribute). As an example, the Circle class has a link with the geometric circle class whereas the Number class is linked to the standard float class. This link is optional because during the construction, some geometrical entity could be destroyed. For example, two solids used in a boolean operation can be deleted from the data base during this operation. But, their representation in the parametric model must be persistent while objects refer to them in their building process. The attribute named parameter represents the list of parametric model instances used to create an instance. Then, every parametric model instance knows its parameters. The set of these linked instances can be represented as a tree (see Figure 1), and when one node of this tree is modified, the whole tree is recomputed. The building tree of an entity made of two concentric circles is shown on Figure 3. The C3 circle is built using two literal positions (literal data are data directly provided by the end-user). The C8 circle has the same center as C3 and its radius is one time and a half bigger. The parametric model instances are represented by rectangles on the figure. The link between the objects and their parameters are represented by arrows. The mixed lines show each object current instance.

Contrariwise the usual terminology, the building process is not exactly a tree but a Direct Acyclic Graph (DAG). The C3 object (see Figure 3) is used several times in the building process.

This kind of building DAG is used by our class definition model to describe all the construction or computation processes.

Class definition

Defining interactively new classes requires solving two problems:

1. Defining constructor parameters in order to permit the instantiation of different objects with different values, 2. Defining object attributes and selectors that may be used by other processes.

Constructor definition.

Our proposition consists in abstracting the class constructor from a parametric object that represents an instance of this class as it is made in programming by demonstration.

As seen in the previous section, each parametric model object keeps its own building process in a DAG which leaves are values directly provided by the user. In order to define a constructor, this building process is used, and the effective parameters of the instance are identified among the nodes and the leaves of the DAG. A boolean attribute (Class_Constructor_Param) (see Figure 4) has been introduced. It indicates if a parametric model object represents a class constructor parameter. The default value is false. Then, by default, all the leaves of the building DAG are considered as constants and the nodes are considered as local variables. It is up to the user to decide which are the instance constructor parameters among the objects the DAG of the example contains. On Figure 5, the building process parameters of the entity are represented by thick rectangles. The grayed one indicates a constant and the others are local variables of the building process. So, in this example, the relation between the radius of the two circle will have always the same value whatever the value of the two parameters.

When the class is generated from the DAG, the objects that represent effective parameters are transformed in formal parameters (i.e. the generator does not take into account their own building tree, the expression used to provide their values is ignored when the class constructor is generated). For example, if the user indicates that the center of a circle is a parameter, then, at generation time, a position object replaces this center object in the class constructor.

Attributes definition.

The possibility to define attributes and their computation functions is essential to define classes although, at our knowledge, it is not provided by any programming by demonstration or parametric system. Passing from interactive program description to interactive class definition requires offering the user the possibility to describe not only the building process of the objects, but also processes able to access the attributes of objects. Object attributes, as the center or the radius of a circle for example, have an essential role in parametric models. Related to PBD works, they act for the user intent, which is explicitly given by CAD users during the drawing phase.

The method we propose for the definition of an attribute and its computation function consists in associating a parametric model object to a string and a parametric building tree. The name of the attribute is represented by the string. The object holds the type of the attribute and its computation function as a building tree. Figure 6 shows the modification adduced to the parametric model in order to define attributes. The list of class attributes is defined by the attribute named Attribute. An attribute is defined by its name which is a character string and by a parametric model object representing its type. This object has its own building DAG as all the objects of the parametric model. Then, when the value of a parameter of the instance is modified, the instance value is re evaluate and also the values of its attributes.

As an example, an attribute that represents the distance between the two wires of the circles is added to the entity Wheel described on Figure 5. This attribute is named Tire Size. The link between the C8 object (the wheel) and its attribute is represented by the triple arrow on Figure 7. It is important to notice that the leaves of the attribute building DAG are either class building DAG nodes or constants. Indeed, the attributes of an object represent the internal structure of this object. The values of the attributes have to be computed at object instanciation time. So, these values computation must only rely to constants or values of object building parameters.

Constructor generation.

In order to abstract the class constructor from the building DAG of the instance example, the internal variables, the constants and the parameters contained in the building DAG must be distinguished. The formal parameter definition is realized using the list of objects that represent constructor parameters. Every object from the building DAG which is neither a class parameter nor a computation result is considered as a constant in the building process. The transformation of the effective parameters of the example instance in formal parameters of the class entails differences between the class constructor DAG and the instance building DAG. Indeed, the computation processes of the values of the effective parameters are not taken into account in class constructor DAG. Thus, the following rule can be stated:

An object named O belongs to a class constructor DAG only if a path between the root object and O (not included) exists and contains no parameters.

Figure 8 shows the way a class constructor DAG is abstracted from the building DAG of an example instance. Parameters are represented by thick rectangles, constants by grayed rectangles, and the remainder are internal variables. The objects used at creation time to affect values to parameters are not taken into account (the objects named O0 and O1 do not appear in the class constructor DAG and the link between O4 and O2 has been destroyed).

Application

Once the class has been defined by the user, it can be used following two ways. The first one consists in directly using the generated DAG to create new instances. The second one regards the generation of the code that corresponds to the class.

Direct instanciation

The re interpretation of the class interactively created permit the user to test the new classes. Then, He/She can immediately correct the design mistakes because He/She can always access the example and re generate the class. This re interpretation stage can be compared to the debug stage in classical programming.

The class instanciation consists in copying the parametric structure of the example. The whole building DAG, the constructor DAG and the computation DAG of the attributes are duplicated without their links to the geometric model. Then, a non-evaluated tree that represents the class is created. Every time the end-user creates a new instance of the class, the non evaluated tree is duplicated and the objects that represents formal parameters are substituted by objects (the effective parameters) provided by the user. At last, the tree is evaluated using effective parameter values, which results in creating the new instance (see Figure 9). Figure 9 illustrates the dynamic creation of a new class from an example of its instances. This interactive definition method is similar to the abstraction method described in programming by demonstration, which consists in creating a program from an example of its execution. In oriented object paradigm, this kind of instanciation is called prototyping [START_REF] Cohen | Models of Concept[END_REF].

Code generation

Once the class is being tested using the direct instanciation mode, it must be recorded in a persistent form. This is done by applying standard compilation techniques while crossing the DAG structure.

The code generator can be used either to define new classes for application specialization or to exchange data between heterogeneous parametric systems.

Example of application : TexAO

The TexAO system is a "light" CAD system that permits end-users to define new classes and then, to integrate them in the system in order to specialize it. This application uses the model described upper to generate new classes. The following example demonstrates how easy it is for end-user to define new classes and to specialize his/her application.

The motion rod

In order to present how our system works, a typical example of mechanical entity, a motion rod, is used. The drawing is shown in Figure 10, exactly as the end-user realizes it. We can describe it using the class paradigm. So, it might be composed of:

• A constructor with three parameters that represent two characteristic points (P1 and P2) of the motion rod and its thickness (H), • A numerical attribute which stands for the motion rod length, • A geometrical attribute which represents the center of the motion rod. This two attributes are calculated from the remainder of the drawing.

Building the example

TexAO essentially reacts as any parametric system but it allows associating parameters and a signature to any constructive process, in order to convert it into a class.

Parameters may be defined by two methods:

• a prior,i by creating a new object which will be a parameter of any construction that may use it in the future, • a posteriori, by selecting existing objects that become parameters of the construction that references them. While our users are expert users, they generally prefer the first solution: the class extraction process is completely deterministic, and end-users perfectly know what they are doing.

In order to create a new parameter, the end-user activates a specific command (make parameter)(see Figure 11) and selects or creates a object that stands for the effective value of the parameter in the example. The parameter name is provided using a modal dialog box. Then, a new button that represents the parameter is created in the interface (Figure 11). It is used by the user to select the parameter and to use it in any construction. The attribute definition is realized in the same way as the parameter definition. The end-user selects a specific command "add attribute", then he/she selects or creates the value of the attribute and then the system asks him/her for providing the attribute name with a specific dialog box (Figure 12). At last, the user selects the "make object" command to generate the class. The generation begins as soon as the user has provided the root object that represents the example and the name of the class. Then, new commands are automatically added to the interface in order to permit the user to handle the new class (for the constructor and for the attribute computation functions).

The TexAO system has now a new class called Motion Rod in its specific component. This class acts exactly as native system classes. The end user has specialized its application without explicit programming but only by demonstrating an example for the new class.

Conclusion

The interactive definition of new object classes is an important goal to achieve in order to permit end-users specialization of interactive applications. A class is composed of two main parts, the constructor used to create new instances and the attributes selectors used to access internal values of these instances.

Two great methods allow end-users to define programs:

• Programming by demonstration provides techniques able to abstract a program from an example of its execution, and allow the specification of the program signature (i.e. distinction between parameters, constants and internal values) • Parametric geometry is able to preserve in a specific structure the building process of any geometrical or topological entity in order to re evaluate it when one of its values is modified.

Unfortunately, none of these techniques provides the necessary structure to define new classes, and more particularly class attributes. Programs created by programming by demonstration are independent and cannot generally share internal values. Parametric models offer sometimes the possibility to associate a signature to the building process, but they cannot associate several computation processes to a single object.

Our solution to define interactively new classes is based on a standard parametric model augmented with specific characteristics that permit to get together in a same structure several building processes. More precisely: 1 . The possibility to distinguish parameters, constants and internal variables (which comes from programming by demonstration) has been added. Thus, it is now possible to define real signature for class constructors and for attribute functions. 2. A mechanism permits the association of attributes to the class. In fact, each attribute is defined by a parametric function that can access any constructor value to generate its proper value. This function is the attribute selector in the class.

Our solution presents two important advantages. First, it can be applied to any parametric model able to store some functional building process. Second, end-users do not need any programming or algorithm expertise to create complete classes, they simply use a conventional parametric CAD system in a particular way. This class definition model has been implemented in a small CAD system that owns all the standard functionalities in order to show that our method can be really applied. It might be very interesting to evaluate this approach with real users. The need for specific (firm dependent) CAD components is very strong, and our approach might solve this problem.

In the future, we think about adding the possibility to define methods to modify the attribute. And, we will try to use our approach to interactively define forms features. Another interesting point is to study how this method can be applied to other kinds of systems such as games or desktop applications.

•

  Constructors are used to create class objects. They consist in assigning values to class attributes. The values come from input parameters. • Selectors are used to recover class attributes of objects. They generally have no parameter. • Modifying methods are used to change the class attribute values. They usually have input parameters.

Figure 1 :

 1 Figure 1: Building tree in a parametric construct

Figure 2 :

 2 Figure 2 : Parametric model class

Figure 3 :

 3 Figure 3: Building tree example: the wheel

Figure 4 :Figure 5 :

 45 Figure 4 : Class parameter notion in the parametric model Let us detail the example shown on Figure 3, called wheel: the parameters of this entity are the center of the circles and a point from the small circle. C8 : Circle

Figure 6 :

 6 Figure 6: Attribute notion in our parametric model

Figure 7 :

 7 Figure 7 : Tire Size attribute definition

Figure 8 : Constructor DAG abstraction 3 . 2 . 4

 8324 Figure 8 : Constructor DAG abstraction

Figure 9 :

 9 Figure 9 : Dynamic instanciation

Figure 10 :

 10 Figure 10 : Motion rod definition

Figure 11 :

 11 Figure 11 : Parameters definition

Figure 12 :

 12 Figure 12 : Attribute definition


Guilaume Texier

Laurent Guittet

Patrick Girard
email: girard@ensma.fr

The dialog tool set : a new way to create the dialog component

Introduction

To help graphical and interactive applications designers in their task, several architecture models have been proposed. They all recommend to separate the application in three components which are the presentation, the dialog component and the specific component. Beyond these architectures, several tools have been proposed to create these components. These tools can be divided in two great families: the presentation toolkits called toolkits in the following and the top down generators.

The toolkits are made of different classes that represent presentation elements called widgets. A crude control mechanism is offered by toolkits. It is a matter of the callbacks which are used to link the widgets to specific component actions, regarding the events received by widgets. This control mechanism can be easily used to create a small application, but when the application enlarges the encapsulated code in the callbacks becomes hard to write and to maintain. Meanwhile, toolkits are universally used, and the method to create an application which consists of using the callbacks to define the dialog component is very spread. Moreover toolkits permit to locally and dynamically modify the application because their widgets can be dynamically instantiated and taken into account by the application.

The top down generator and particularly the model based systems [START_REF] Szekely | Beyond Interface Builders: Model-Based Interface Tools[END_REF] use specific languages to describe the application and are able to generate the dialog component and the presentation component from this description. These tools permit to explicitly design the dialog component of the application which is necessary to write and to maintain the application when it becomes big (many actions provided by the dialog component) and/or when the dialog is structured (a structured dialog is a dialog mode where a task can use the result of an other task to be executed). Meanwhile, there are few or no top down generator that permit to dynamically and locally modify the dialog component. With most of them, the dialog component can be modified only by changing its description and then the application have to be rebuilt.

Our proposition is to use new tools as presentation widgets which permit to create explicitly the dialog component. This dialog specific toolkit is called the dialog tool set. It is composed of several classes which are reification of dialog elements. Thus, any people that understand how to create the presentation component using widgets could easily define a dialog component able to manage a complex dialog like structured dialog. So, these persons would be able to easily create more complex applications.

This tool set is completely independent from the presentation component. So, its behavior is completely disconnected from the manner the user provides data. Then, it can be used to easily create multi-modal applications allowing a universal access to the application functionality.

In the following section of this paper, the concept of presentation toolkit is discussed, and particularly the way to design the presentation using this kind of tools. The next section deals with the dialog tool set, the similitude and the differences between the dialog tool set and the toolkits are pointed out.

The presentation toolkits

A presentation toolkit (or toolkit) is a library of interaction objects called widgets. The presentation of an interactive application is created by instantiating widgets as windows, menus, buttons, etc. The widgets have two important roles in the presentation component : 1. They are in charge of transforming information that come from input devices (keyboard, mouse, microphone,…) into application usable data. 2. They offer services to manage output devices (screen, speakers, force feedback devices, …), permitting the system to show its state. Several advantages are offered to the designers by toolkits. First, they permit to reuse interaction tools which have a higher abstraction level than the drivers provided by the input/output devices. Then, the implementation of the presentation component is really simplified. Second, the aspect and the behavior of the widgets are the same for all the application built with one toolkit. This make the application more usable regarding the familiarity of the application [START_REF] Dix | Human-Computer Interaction[END_REF].

Presentation definition

The aspect definition of interactive applications is entirely devoted to the toolkit regarding the Arch [START_REF] Bass | The Arch Model : Seeheim revisited[END_REF] architecture model. To create the presentation component, several widgets are instanced. Then, at running time, the user interactions are transformed by a specific program (often called event handler) in event representing the user action on a widget. When an event is received by a widget, it has two behavior: an internal behavior and an external behavior.

The internal behavior represent a self reaction of a widget to an event. As an example, when the user push on the mouse button and when the mouse pointer is on a button, this last one sinks. Generally, the internal behavior can not be modified. Some widgets have only an internal behavior (menu buttons are only used to display menus).

The external behavior represent the application reaction to the user interactions. This behavior has to be explicitly described by the designer with callbacks. Callbacks are functions which are called when an event is send to a widget. They are different for each widgets and for each events. Thanks to this mechanism, the application can be directly controlled by the presentation component. Indeed, specific component actions can be called using callbacks.

In this case, the toolkits insure two services which are a presentation service and permit an application control role.

Meanwhile, big problems can occur when the same callback has to perform a different work regarding the application state. As an example, a mouse click may has several meanings. It can be used to select an object or to compute a position for the system. Then, to manage this ambiguity, a lot of information have to be registered in the presentation component. In consequence, the code of the presentation component highly grows up when a new functionality is added to the application. Moreover, the experience has shown that real interfaces contain often hundreds of callbacks, which makes the code harder to modify and maintain [START_REF] Myers | Survey on User Interface Programming[END_REF]). That's why, the architecture models for interactive systems recommend to separate the presentation and the control.

Events CallBack Widget

Specific Component

User

Presentation Control

Figure 1: Interactive system control

The Figure 1 shows the manner toolkits control interactive systems using the event/widget/callback paradigm.

The way to design an application using a toolkit for presentation and control is very spread. Because widgets have several advantages.

Firsts, they are very generic, they can be reused for any kind of applications. Second, they can be directly instanced using a standard programming language. And third, they can be dynamically instanced, so they allow the user to adapt the interface of its system to make it more usable [START_REF] Dix | Human-Computer Interaction[END_REF]. Meanwhile, they can not be used to control a structured and multi-object dialog. For this kind of dialog, the dialog component must be explicitly described [START_REF] Pierra | Towards a taxonomy for interactive graphics systems[END_REF], and the callback mechanism can not be used because it represent an implicit dialog control that modelize only interactions but neither the application state nor the dialog state.

In the next section, the dialog tool set we have proposed is demonstrate. We focus on the ease and on the similarity of use of these tools and the presentation toolkits.

3

The dialog tool set

The dialog tool set is a set of gadgets that permit a designer to create a dialog component (respecting the ARCH [START_REF] Bass | The Arch Model : Seeheim revisited[END_REF] architecture model and based on the element defined in H 4 (Pierra, et al., 1995) by the same way he/she makes the presentation component using widgets.

The dialog tool set classes

This tool set is composed of four family of classes that represent different elements needed to describe a dialog component supporting structured tasks and multi-objects tasks.

3.1.1

The tokens The Tokens are the information units used to capture, at various levels of abstraction the user input (e.g. number, position, circle, and line…) in the dialogue tool set.

3.1.2

The questionnaires The questionnaires represent the system tasks in the dialog component. In fact, they are the signatures of the functions called by the dialog component to realize treatment on the specific domain component. So, they link the dialog component with the specific domain component. They are defined by the command used by the user to activate the task they represent, by the types of tokens used by the task to call functions of the specific domain component and by the types of the returned token when the task returns a result.

3.1.3

The diagets The diagets organize the different questionnaires of the application in abstraction levels. All the questionnaires dedicated to the creation of geometric entity are brought together in the "creation" diaget. The "Calculator" diaget is shaped by the questionnaires dealing with arithmetic's operations. Diagets contain ATN (Augmented Transition Networks) (Green, 1986) that aggregate tokens to call a questionnaire implementation.

3.1.4

The monitor The monitor manages all the diagets. It recovers the tokens coming from the presentation and sends them to all the diagets from the lower abstraction level to the higher abstraction level.

At running time, the monitor is in charge of recovering the tokens that come from the presentation component. Then, they are transmitted to each diaget regarding the order of the hierarchy. When, a diaget received a token that it waits, it changes of state (notion of consumption), when it has received all the tokens needed to call a questionnaire, it realize this action and then it transmit the resulting token to the monitor (notion of production). Then, the monitor transmit this token to the higher diaget in the hierarchy. The fact that the diagets do not know who produces the tokens they received and who consumes the tokens they produce insure the independence between the tasks. This independence permit to define a structured dialog.

It is important to notice that the tokens representing user input are created in the toolkit events. Meanwhile the dialog component does not know the manner the tokens are created. Thus, regardless the modality used to create a token, the dialog component behavior is the same. An example of multi-modal application has been created with this toolkit, the user could choose command with menu button or with a voice recognition system. The transition from a full WIMP application to the multi-modal application did not entail any modification of the dialog component.

Diaget vs widget

There are many similarities between the diagets and the widgets, but their respective goals are completely different.

The widgets are use to create the presentation component, they are reifications of presentation concepts whereas the diaget are use to implement the dialog component, they are reifications of control concepts.

The first similarity concerns the types of elements composing these tools. To create the presentation component, two kinds of widgets are instantiated: the containers and the terminals (Fekete, 1996). The containers are only used to organize the terminal widgets in order to improve the presentation. The terminal widgets are used either to call an application functionality, either to display data, or both. By the same way, the dialog tool set has two kinds of control objects: the monitor and the diagets. The monitor is used to organize the diagets regarding the dialog semantics. The diagets are in charge of controlling the calls of the application functions.

Concerning the action calls, a similitude also exists between widgets and diagets. Widgets call actions (callbacks) when they receive some specific events. The called callback depends on the event received by the widget. Actions (the questionnaires) are called when the diaget receives a certain list of token. A similitude can be made between the widget behavior and the diaget behavior. In fact, in the dialog tool set, the diagets are like widgets, the token lists represent the events and finally, the callbacks are represented by the questionnaires (Figure 2). This similitude enlights that the proposed approach is the natural extension, for the dialog design of the way to create graphical interfaces with toolkits. Nevertheless, the proposed dialog tool set presents an essential advantage to control the application regarding standard toolkits: it permits an easy representation of the contextual aspect of user inputs because it is based on automata. The last similar point between the diaget and the widget is the dynamic instanciation. Using the dialog tool set, the dialog component can be dynamically modified. Then, our tool set can be used to create an adaptive system where the user can define new functions using programming by demonstration techniques [START_REF] Cypher | Watch What I Do: Programming by Demonstration[END_REF], these functions are dynamically added to the dialog component by instantiating new questionnaires and new tokens. Anyway, this dialog tool set has been used in the TexAO [START_REF] Texier | User Defined Objects are First Class Citizen[END_REF] system which is an adaptive CAD system.

Conclusion

Toolkits are the most used environments in the Human Computer Interaction field. They permit to reuse, rather easily, interaction tools which are friendly to create every kinds of applications. The callback mechanism appears to be adequate for the control of applications when the tasks are autonomous and slightly structured. Inversely, when the tasks are recursively decomposed into sub-tasks, the dialog language becomes strongly structured and contextual, the callback mechanism is completely inadequate. Then, the dialog component code is spread in callbacks, and the application becomes hard to maintain.

This paper presents a new kind of toolkit that permits the designer to explicitly create the dialog component. This toolkit, called the dialog toolset, is based on several classes that permit to define and to organize the system tasks in order to control their activation regarding to user inputs. The main characteristic of these tools is that they can be used exactly as the widgets. So, they keet the genericity and ease of use of the widget. The way to create the dialog component consists of creating diagets (diaget + gadget) (representation of the widgets in the dialog toolset) and to link them to the specific domain component functions using questionnaires (representation of the callbacks) and tokens (representation of the events). Then to create the dialog component, the designer retrieves the well known method consisting of linking objects to actions via callbacks regarding events.

Moreover, the dialog toolset is perfectly adapted to the management of multi-modal application. The independence between the dialog component and the presentation component permits to adapt existing WIMP application to over modalities without modification of the dialog component.

Figure 2 :

 2 Figure 2: Diaget as widget