1994 annual conference on Ergonomics : "ergonomics for all" 19th-22nd April 1994 University of Warwick, Coventry, UK
FORMAL SPECIFICATION OF HCI FOR INCREASING SOFTWARE'S ERGONOMICS Philippe Palanque and Rémi Bastide L.I.S., University Toulouse I, 1, Place Anatole France 31042 Toulouse Cedex FRANCE Tel: (33) 61 63 35 88 - Fax: (33) 61 63 37 98 - Email:
[email protected]
This paper aims at asserting the impact of formal specifications on the ergonomics of software user interfaces. It is shown that the use of an object-oriented design methodology featuring a formal specification and integrating human factors in the design process, is the best way to ensure quality both in the software and ergonomics domain. The method we propose is based both on Petri nets and on the object oriented approach. The use of such a method allow to ensure predictability of commands, absence of deadlocks and offers the possibility to automatically generate both contextual help and contextbased guidance.
Introduction This paper aims at asserting the impact of formal specifications on the ergonomics of software interfaces. Evaluations performed a few years ago in software engineering by Bóhm (1976) have shown that 70% of the total cost of an application is dedicated to the maintenance. This maintenance costs result from different kinds of problems that can be classified in three main categories : a) correction of errors appearing during the use of the software, b) addition of new functionalities or the modification of software features, c) improvement of the user interface when it appears that users are reluctant to use the software (or when they use only a few of its functionalities). Since this statement, software engineering tried to provide answers to this problem in several ways. Maintenance problems of category (a) are related to the reliability of the software. They have tentatively been solved by various techniques such as design methods and formal specifications. Design methods help in solving this kind of problems by structuring the design process in several stages that can be verified individually. The formal notations are usually used in the framework of a design
method and allow the production of concise, complete and non-ambiguous models. Moreover, if those formal notations are mathematically founded, it is possible to mathematically verify the specifications, thus ensuring at an early stage in the design process (before implementation) the smooth functioning of the software. Problems of category (b) are related to the evolutivity of software. They have been solved by a modular approach to software construction, particularly well supported by object-oriented techniques that enhance reuse of reliable software components. Those components are reliable because they have been previously designed and tested. Maintenance problems of category (c) are related to software usability. These problems are taken into account by human factors and ergonomics studies. However, in spite of frequent reports recommending to take human factors into account, in order to reduce maintenance costs (for example Norman and Draper (1986), Rubinstein and Hersh (1984)), their integration in software development is still occasional. In order to offer a structured solution to this problem, various proposals integrating some aspects of the above solutions have been presented in the form of design methodologies integrating human factors in software design (for example Barthet, Palanque and Alquier (1991), Lim, Long and Silcock (1992)) or design methodologies directly related to user interface design, for example Wasserman (1985). A lot of other work has been done in this area, still not integrating all of the above recommended solutions (i.e. an object-oriented design methodology featuring a formal specification and integrating human factors in the design process). Nevertheless, those solutions proved to be successful as long as the proposed interaction style remained simple (e.g. menu-driven style proposed in the classical text-based software). Nowadays, ergonomists recommend a user-driven interaction style, allowing multi-threaded dialogue. This interaction style is much harder to manage by the conventional software design techniques due to the reactive nature of a software featuring such a user interface, see Palanque, Bastide, Sibertin and Dourte (1993). As we have shown in previous articles (for example Bastide and Palanque (1990), Palanque, Bastide (1993), Palanque et al. (1993)) the design of this kind of software makes the use of formal methods necessary. These methods are used in order to produce a complete and non-ambiguous specification that can be mathematically validated in order to compensate for the difficulties in the testing of this kind of interfaces. While the use of formal specification method is usually costly, it may, in return, enhance the ergonomics of software in various ways.
Interactive Cooperative Objects The ICO formalism is an object-oriented language specially designed for the modeling and implementation of event-driven interfaces, see Palanque et al. (1993) Bastide and Palanque (1990). In this language, an object is an entity featuring four components: data structure, operations, presentation and behavior. The data structure of an object is a set of attributes, each of them having a name and a type. This type is either a simple type or an object class. Objects communicate according to a client-server relationship, and an object offers to its environment a set of operations called services. The ObCS (Object Control Structure)
of an object fully defines its behavior: the availability of its services, but also how it processes service requests, the operations it performs on its own behalf, and the services it requires from other objects as a client. The ObCS of an ICO is defined by a high-level Petri net. Each object's service is associated with one or several ObCS’ transitions. A service request may be accepted only when one of its associated transitions is enabled, and it is performed by the occurrence of such a transition. Services of an ICO which are at the user’s disposal are called user services. An ObCS may include transitions which are not associated to any service: they correspond to the object's spontaneous activity. The presentation of an object states its external look. This presentation is a structured set of widgets. The user-system interaction will only take place through those components. Each user action on a widget may trigger one of the ICO's user service. The relation between user services and widgets is fully stated by the activation function which associates to each couple (widget, user action) the service to be triggered. When modeling a window by an ICO, the sequencing and synchronization constraints for the availability of services offered to the user are expressed in the ObCS. Transitions relate to the object's services, stating their availability, and user services relate to widgets through the activation function. Thus the active or inactive state of the widgets may be known by looking at the ObCS' marking: the fact that no transition associated to a service is enabled by the current marking means that this service is not currently available to the user.
Architecture of an application The Seeheim model originally presented by Green (1985) is a well-known framework, which has proved to be very efficient and is, in a somewhat implicit way, at the foundation of several User Interface Management Systems (UIMS). The Seeheim model presents a linguistic point of view towards the humancomputer interaction, structuring this communication in semantic, syntactic and lexical levels. This structuring produces three conceptual components: the Application interface, the Dialogue and the Presentation. • The Application interface relates the user interface to the semantics of the application. The application objects offer to the outside world services and processing rules that totally define this semantics. The abstract object implemented by the Application can be handled only through this interface (interface in the software meaning). • The Presentation is responsible for the lexical aspects of the dialogue, in input as well as in output. This component handles the physical interactions, and must translate the user's actions into more abstract dialogue units. • The Dialogue component handles the syntactical aspects of the dialogue. It structures the man / machine interaction at a high-level, and ensures the distribution of control between the user and the system. It mediates between Application interface and Presentation components. A common misconception about the Seeheim model is to consider it as an architecture, which would produce applications structured in three layers. Of course such an architecture would not hold, since most often each high-level software entity is concerned both in the core semantics and in user interaction. The layer
organization would artificially separate those two aspects of an object into unrelated software components, while the main concept of the object-oriented approach is to produce highly coherent and loosely coupled components. The Seeheim model has to be considered as a conceptual one, and in an object-oriented approach each application object needs to be structured as a "micro-Seeheim" as such, thus gathering in the same entity semantics, dialogue and presentation. The belief that interface and application design may be completely separated seems to us obsolete and battered down by the object-oriented approach. Our architecture distinguishes between two kinds of objects: • non interactive objects bear the core semantics of the application, including the application’s database, if any, functions for achieving the needed computations, and so on; they do not deal with user interaction and are shared by all ICOs. • interactive objects (ICOs) support the application’s user interface; they define the dialogue structure, and maintain the coherence between the state of the non interactive objects and what is shown to the user by the Presentation; each window in an application is associated to a class of ICO.
Interactive Cooperative Objects
Non interactive Objects
Application Kernel Dialogue Application interface Seeheim Layers
Presentation
User
Figure 1. Architecture of an ICO-based application Validation of the interface Petri Nets (see for example Peterson (1981)) are one of the very few formalisms coping with concurrency in a formal way. In this section we will fill in the gap between the mathematical tools available for studying nets properties and the validation of a concrete system, by showing how results of the PN theory may be used to prove properties of the behavior of an application modeled by ICOs. The results of PN theory enable to prove on one hand properties of marked nets, which are valid for a net provided with a given initial marking, and on the other hand, to prove marking-independent properties which are less accurate but more general. Since the initial marking of the ObCS of an object is defined by the class it belongs to, these two kinds of results can be used. The mechanisms for the objects’ cooperation are defined in such a way that the validation of a model may be processed in two separate steps: • unitary validation studies the behavior of a single object, making a “good cooperation” assumption upon its relationships with other objects, that is: the servers of the object are able to process all its requests, and its clients send as many requests for its services as it may process;
•
cooperation validation studies the behavior of a set of objects according to the way they are cooperating through the client / server relationship; it enables to know whether the objects cooperate in such a way that each server fulfills the needs of its clients, i.e. whether the cooperation preserves the objects’ behavior properties set out by the unitary validation. When modeling an interface, unitary validation enables to prove that the dialogue of each window is designed in such a way that it meets the requirements. Cooperation validation concerns both ICO / non-ICO and ICO / ICO cooperation: the former enables to ensure that the user’s requests may be satisfied by the application’s functional kernel and that the ICO’s presentation reflects the state of the functional kernel, and the latter is needed as soon as an application may open several windows.
Ergonomics benefits •
•
•
•
From the ergonomics point of view, the benefits of such a method are: automatic context-based guidance i.e. the widgets are activated and inactivated automatically, always showing the legal user action. This problem relates to the question "what?" which corresponds to the interrogation "What can I do from now on?" that naturally arises to new users. In such user-driven interfaces, the screen presented to the user must reflect the internal state of the application. It is therefore possible to determine visually which actions are currently enabled. This feature is commonly achieved in most present software by graying out or otherwise inactivating the widgets which allow to trigger the actions that are not available. automatic generation of contextual help, (Palanque et al. (1993), Sukariviya and DeGraaff (1992), Aaronson and Caroll (1987)). Contextual help is specifically concerned with the current state of human-computer interaction and should ideally answer two basic questions that the user may be interested in: "why not?" and "how?". The question "why not?" naturally comes to the user's mind as soon as he wishes to trigger an action whose triggering widget is currently grayed out. In current software, usually not only is the question unanswered but it cannot even be asked. Actually a user's action on a grayed out widget is simply ignored. The question "How?" stands for "How can I make that action available again?". The answer to this question should naturally complement that of the question "why not?" by providing the sequence of commands to trigger in order to enable the desired command; the predictability of a command i.e. the fact that the user must be able to foresee the effect of issuing a command (a same command has always the same effect when it is activated in the same state); the absence of deadlock is the insurance that for any unavailable action it exists a sequence of actions allowing to make it available (this sequence of actions can be given to the user by the contextual help system).
Perspectives This paper presents the ergonomics benefits of the use of formal methods for
the design of user interfaces. The proposed method, based on Petri nets and the object oriented approach, addresses the well-known drawbacks of classical Petri nets by allowing the structuring of models in an object-oriented way (encapsulation, inheritance, client-server relationship, etc.). A design process for building user-driven interfaces is supported by the method by providing a set of methodological rules helping the designer to build his models, see Palanque et al. (1993). At the present time, our efforts are on the construction of an integrated development environment supporting this method. This environment will integrate a graphical presentation editor, a syntactic editor allowing the edition of ICOs, several analysis modules allowing to prove design properties of the models and an ICO interpreter acting as a run-time kernel.
References Aaronson, A. and Carroll, J.M. 1987, The answer is in the question : A protocol study of intelligent help. Behavior and Information Technology, 6, 393-402. Barthet M.F., Palanque Ph., Alquier A.. 1991, L'ergonomie et la conception MERISE : un complément à la méthode. Proceedings of congress AFCET "Autour et à l'entour de MERISE”, Nice (F). Bastide, R. and Palanque, Ph.. 1990, Petri Net Objects for the design, validation and prototyping of user-driven interfaces. Proceedings of Interact’90 Elsevier (ed.),. 625631, Cambridge (UK). Bóhm, B. W. 1976, Software Engineering, IEEE Transactions on Computing, 12261241. Green, M. 1985, Report on dialogue specification tools.. In Günther E. Pfaff (ed.), User Interface Management Systems, Proceedings of the workshop on User Interface Management Systems, Seeheim , FRG. Springer Verlag. Lim, K.Y., Long J.B. and N Silcock 1992, Integrating Human factors with the Jackson System Development method: an illustrated overview. In Ergonomics 1992, 35, 10, 1135-1161. Norman, D. A. and Draper, S. W., (eds.), 1986, User Centered System Design : New Perspectives on Human Computer Interaction, Lawrence Erlbaum Associates, Publishers, Hillsdale, New Jersey (USA). Palanque Ph., Bastide R., Sibertin-Blanc C., Dourte L. 1993, Design of User-Driven Interfaces using Petri Nets and Objects. Proceedings of Conference on Advanced Information Systems Engineering : CAISE 93” Lecture Notes in Computer Science n° 685, Paris (France). Palanque, Ph. and Bastide, R. 1993, Reliable User-Driven Interfaces for Critical Systems. Workshop IFIP WG 13.2 "Methodology for User Centered Design”, Amsterdam, (NL). Palanque, Ph., Bastide, R. and Dourte L. 1993, Contextual Help for Free with Formal Dialogue Design. Proceedings of the 5th International Conference on HumanComputer Interaction, (HCI International'93). Elsevier. Orlando, Florida (USA). Peterson, J.L. 1981, Petri net theory and modeling of systems. Prentice-hall. Rubinstein, R. and Hersh, H., 1984, The Human Factor : Designing Computer Systems for People, Digital Press, Bedford, Massachusetts, (USA). Sukariviya, P. and De Graaff, J. 1992, Automatic generation of context-sensitive "Show & Tell" Help. Technical Report GIT-GVU-92-18. Atlanta, Georgia. Graphics, Visualization and Usability center, Georgia Institute of Technology. Wasserman A.I. 1985, Extending state/transition diagrams for the specification of human-computer interaction. IEEE Transactions on Software Engineering 11, 8, 699-713.
