A Framework for Machine-Assisted User Interface Verification

A Framework for Machine-Assisted User Interface Veri cation Peter Bumbulis1 , P. S. C. Alencar2 , D.D. Cowan1, C.J.P. Lucena3 1 Computer Science Department, University of Waterloo, Waterloo, Ontario, Canada 2 Departamento de Ci^encia da Computaca~o, Universidade de Braslia, Braslia, Brazil 3 Departamento de Informatica, Pontifcia Universidade Catolica do Rio de Janeiro,

Rio de Janeiro, Brazil

Abstract. In this paper we present a formal framework for machineassisted user interface veri cation. We focus on user interfaces constructed with tools that are based on a visual scripting formalism. As these tools do not provide a language for describing user interfaces (user interfaces are constructed by direct manipulation) we introduce one. Noting that user interface construction with these tools consists of \wiring" components together, we base the syntax of our language on an existing module interconnection language: in this context a user interface is described as a hierarchy of interconnected component instances. We de ne the semantics of user interfaces using execution sequences; this allows us to reason about their ongoing behavior. We embed the semantics in higher order logic (as mechanized by the HOL system) to allow us to verify properties using formal proof.

1 Introduction Graphical user interfaces (GUIs) are being used increasingly in security- and safety-critical applications. In this context it is important to be able to verify that they behave as intended. As empirical evidence suggests that \the only reliable method for generating quality user interfaces is to test prototypes with actual end users and modify the design based on the users' comments and performance" [28], the issue of verifying that a user interface implementation meets certain formal requirements arises. In this paper we describe a framework for doing this based on (machine-assisted4 ) formal proof: we construct mathematical descriptions of both the user interface and the property to be veri ed and then (mechanically) prove a theorem of the form property ` implementation description satis es description where `satis es' is some satisfaction relation5. If we are to have con dence in the signi cance of such proofs we must ensure that the formal speci cation of 4

Experience has shown that machine-assisted proofs are more trustworthy than those done by hand [9]. 5 In this paper we describe implementations and descriptions as sets of state sequences and use subset containment as the satisfaction relation.

the property to be veri ed accurately describes the designer's intentions, and we must ascertain that the mathematical model of the user interface truly re ects its behavior. The rst issue has been well addressed by the user interface community (see [13, 3, 38], and the references contained therein) and we will not discuss it further. The second issue, on the contrary, seems to have been neglected. We address this second issue by mechanically deriving the mathematical model of the user interface from its implementation.

1.1 Outline Attempting to verify properties of user interface implementations presents a number of diculties, not the least of which is that, in general, there is not a clean separation between the user interface and rest of the application [29]. However, there is a class of GUI development tools (GUIDTs) that enforce such a separation. These tools describe a user interface as a hierarchy of interconnected component instances, with primitive component instances forming the leaves of the hierarchy. We restrict our attention to user interfaces constructed with these tools. In Sect. 2 we brie y describe these tools and informally describe the behavior of user interfaces constructed with such tools. To be able to reason formally about a user interface we need to have a description of it in a formalism with a well de ned syntax and semantics. Unfortunately, the tools just alluded to provide neither. Our solution to this problem is (just as in hardware design) to construct a model of the user interface and then reason about this model. We are still left with the problem of verifying that the model is an accurate representation of the implementation, but we have reduced the problem to verifying that the representations of the primitive components and the semantics of connecting components is accurate. This only has to be done once. Section 3 sketches the syntax and semantics of the language that we use to model user interfaces. We discuss the representation of the properties to be veri ed in Sect. 4, and their mechanical veri cation in Sect. 5. We nish with conclusions, and an outline of future work.

2 Implementations Following Meyers [30] we use the term UIMS to denote a GUI development tool (GUIDT) that has a signi cant run-time component. UIMSs typically provide the user interface designer with a set of primitive components and a scripting language for connecting them. Commercial examples of UIMSs include PARTS Workbench [11], Visual Age [17], Visual Basic [26], and VX
REXX [42]. While early UIMSs only provided presentation components (menus, buttons, dialog boxes, and the like), most recent UIMSs (including the ones listed) also provide application interface primitives such as database and le accessors and facilitate the creation of new application-speci c primitives. This allows for a clean separation between the user interface and the rest of the application. When developing

applications with such tools the tasks of user interface designers and application programmers can be characterized as using and constructing primitive components, respectively. Traditionally UIMSs have used a conventional programming language for scripting: specifying the behavior of a user interface essentially consists of coding callback routines. A more recent approach (as exemplarized by PARTS Workbench and Visual Age) is to provide a visual formalism for scripting: specifying the behavior of a user interface with these tools consists of \wiring" components together by direct manipulation. Fig. 1 shows one step in the construction of a (trivial) user interface using PARTS Workbench. The user interface designer speci es which components are used and how they are connected but does not specify the behavior of the constituent primitive components. In this paper we will restrict our attention to user interfaces constructed with such systems.

Fig. 1. Trivial PARTS Workbench example. In the completed user interface, the slider will track the motion of the dial and vice-versa.

2.1 Semantics Wiring components together binds functions to call sites. For example, Fig. 2 gives a possible C++ [37] interpretation of the behavior of the user interface under construction in Fig. 1. Additional things to note are that presentation and application interface components also present a well de ned interface to the runtime environment (in this case modeled with the functions dispatch and

redraw.) The runtime environment translates events generated by the user's actions into (serialized) calls to dispatch which will modify state and/or invoke actions. To avoid undesirable visual artifacts and to improve performance, component implementations typically do not update the screen directly in response to a dispatch'ed event. Instead, they simply notify the runtime environment that the view of the component should be updated. After the call to dispatch returns, the runtime environment will call redraw to perform the screen update.

class Valuator private: int value; public: void (*changed)(int); void set(int i) if (value != i) value = i; =* ... *=; (*changed)(i); f

f

f

g

g

;

== ==

virtual void dispatch(Event) = =* f ... set(.) ... g *= 0; virtual void redraw(Region) = 0;

10

g

class Dial : public Valuator class Slider : public Valuator void dset(int i) d.set(i); void sset(int i) s.set(i); f

f

main() d.changed = sset; s.changed = dset;

f f

=* =*

... *= g d; ... *= g s;

g

g

f

== ==

bind d.changed to s.set bind s.changed to d.set

20

g

Fig. 2. Code for Fig. 1.

3 The Model 3.1 Syntax To be able to reason about a user interface, we need a description of it in some well de ned formalism (language). Unfortunately, systems such as PARTS Workbench and Visual Age do not provide such a description: typically the designer constructs the user interface using tools that manipulate some undocumented internal representation. While each tool provides a formalism for describing a particular view of the user interface (e.g. dialogs for attributes, code or graphs

for scripts), none gives a complete description6 . As a result, we introduce our own language for describing user interfaces. Noting that the interface construction in the context of a visual programming language typically consists of \wiring" components together by direct manipulation, we base the syntax of our language on (the static subset of) an existing module interconnection language Darwin [18]. We describe a user interface as a hierarchy of interconnected component instances, with primitive component instances forming the leaves of the hierarchy. Each component instance has a number of ports available for binding. For example, Fig. 3 is a description of user interface under construction in Fig. 17. Each port has a type (in the usual sense), kind (observer or action)8 , and polarity (requires or provides.) Only ports of the same type and kind and opposite polarity may be wired together.

f

gui components inst d:Dial s:Slider bind d.changed -- s.set bind s.changed -- d.set

g

Fig. 3. Syntax for Fig. 1. Work is currently under way on implementing a GUIDT that uses this language to represent user interfaces.

3.2 The Formal System If we are to verify properties of user interfaces by formal proof we need to express the semantics of the user interface and the properties to be veri ed in some formal system. We use higher order logic9 . Higher order logic extends rst-order logic 6 7

Designers can save their work in les; unfortunately the le formats are proprietary. This is an oversimpli cation for the purposes of exposition. Almost all components are parameterized with attributes as well. These attributes are used to specify things such as the size and position of the component, as well as the visual hierarchy and initial values. 8 Observers are provided to inspect the state of a component; actions are provided to modify it. To simplify the following discussion we will not make any further mention of observers. 9 Essentially rst order logic enriched with the typed lambda calculus. [5] is a good introduction.

by allowing higher order variables (i.e. variables whose values are functions) and higher order functions (i.e. functions whose arguments and/or results are other functions). Using higher order logic has a number of advantages: 1. Reliable and robust proof-assistants such as HOL [14], PVS [33] and Isabelle [35] exist; 2. It will be easy to formalize the semantics of the UIMS scripting languages that we are interested in; and 3. It is simple to embed the various logics and formalisms used to express user interface speci cations in higher order logic. For example, temporal logic [23, 19, 40] and Statecharts [10]10 have both been embedded.

3.3 Semantics There is a general consensus in the user interface community that user interfaces are best described as reactive systems [15]; what is of interest is how they interact with their environment. As a result many of the formalisms proposed for user interface speci cation model behavior as a sequence of states. CSP [4], Petri nets [6], LOTOS [34], temporal logic [20] and Statecharts [24] all have been used. Similarly, we model a GUI as a 4-tuple h; ; C ; i with the following components: {  , a nite set of state variables. { , a set of states. Each state s in  is a function mapping names in  to values. { C, a set of state sequences referred to as a command. State sequences can be nite or in nite. Additionally, nite state sequences can be terminated or aborted. Formally, C is a subset of   [   0 [  ! , where   ,   0 and  ! denote the set of all terminated nite, aborted nite and in nite state sequences, respectively. This allows us to reason about a broader class of properties. It allows us, for example, to distinguish between failure and divergence. { , an initial condition. This assertion characterizes the states at which execution of the GUI can begin. A state satisfying  is called an initial state. We express commands in an extension of Dijkstra's guarded command language [12] based on a mechanization by Tredoux [39]. Figure 4 provides a summary of the notation used in this paper. The second formula gives the meaning of the assignment command x := exp. It asserts the existence of states s and s0 such that the s0 follows s, and that s0 should be obtained essentially by evaluating the expression exp in the state s and binding the result to the value of x in the state s0 . The subsequent development does not depend on this formalism; all we require is a means for expressing sequential composition and non-deterministic 10

Day formalizes STATEMATE's step-dependent semantics [16]; this is quite dierent from the (micro-step based) semantics for Statecharts found in the literature.

` skip = (e: 9s: e = pair (s; s)) ` 8x exp: x := exp = (e: 9s s: (e = pair (s; s)) ^ (s = bnd (exp s) x s)) ` 8c1 c2 : c1 8 c2 = (e: c1 e _ c2 e) ` 8c1 c2 : c1; c2 = (e: c1 e ^ :TERM e_ (9e1 e2 : c1 e1 ^ TERM e1 ^ c2 e2 ^ ( rst e2 = last e1 ) ^ (e = e1  e2 ))) ` 8P c: P ?! c = (e: P ( rst e) ^ c e) ` 8c: rec c = (e: 9col: (9m: maxproduct c e col m) _ infproduct c e col) ` 8c: atomic c = (e: 9e: c e^ (TERM e )(e = pair ( rst e; last e)) j (e = abort pair ( rst e; last e))))

` 8c: arb value c = (e: 9v: c v e)

Fig. 4. Guarded command language as mechanized by Tredoux [39], with some additions. choice. We have chosen to use an imperative formalism since not only are mechanizations available in the higher order logic context for a variety of programming logics [27, 39], but also because of the the possibility of using symbolic execution [21] to help in constructing various proofs [8]. We de ne a little-step computation of a user interface h; ; C ; i to be any state sequence satisfying the command  ?! (rec C ) and a big-step computation of h; ; C ; i to be any state sequence satisfying the command  ?! (atomic (rec C )). Big-step computations are useful for reasoning about the presentation aspects of the user interface. As discussed in Sect. 2.1, the display usually changes only after an event dispatch has completed. We note that although we have avoided dealing with concurrency in this stage of our work, the present approach can in principle be extended to a concurrent one through the use of another formalism for describing the commands, e.g. the temporal logic of actions (TLA) [22].

3.4 Specifying Components

We de ne for each type of component a predicate ` 8s0 cmd p1 : : : pn: component s0 cmd p1 : : : pn = de ning relations which is true if and only if cmd is a command which expresses the behavior of the component when connected as speci ed by the parameters and started in state s0 11. This relation typically gives a relation for each provided port in

11

A similar approach is used for hardware veri cation [25].

terms of the required ports and relation de ning the behavior of the component in terms of the provided port de nitions.

Primitive Components. We assume that the de nitions for the primitive

components are provided; when a new primitive is constructed, the user interface designer is presented not only with an implementation, but also with a speci cation of its intended behavior in this form. For example, the de nition of a valuator (which we will use to model both sliders and dials) might be given as follows: ` 8s0 cmd id v0 set changed: valuator s0 cmd id v0 set changed = (set = (v: ((s: v = s id) ?! skip)8 ((s: :(v = s id)) ?! ((id := (s: v)); changed v))))^ (v0 = s0 id)^ (cmd = arb value set) This formula essentially gives the same semantics for the behavior of the valuator as described informally in Fig. 2. It also states that in the start state the valuator has value v0 . Note the use of arb value 12 in the de nition of the behavior of the valuator. We model the user's actions as entering an arbitrary value. In a more realistic example there would be further constraints on the value, for example that it is a whole number in the range [0; 80].

Composite Components. Composite components are de ned in terms of the constituent components. For example, the speci cation of the user interface of Fig. 1 would look like: ` dial = valuator ` slider = valuator ` 8s0 cmd: gui s0 cmd = (9scmd dcmd sset dset:

slider s0 scmd `s` (INT 0) sset dset^ dial s0 dcmd `d` (INT 0) dset sset^

(cmd = scmd 8 dcmd))

This does not give us a closed form expression for the behavior; instead it is speci ed as a system of recursive equations. Note that the actions that the user interface can perform include those that can be performed by the slider and the dial. Also note the use of existential quanti cation for hiding. 12

See Fig. 4 for a de nition.

Note that although the primitive components must be described by hand, the composite component descriptions can be mechanically derived from the syntax of the description of the user interface.

4 Properties In this section we present the semantics of the property representations and show how to encode these representations in higher order logic. Formally properties are sets of state sequences: given a set of states  , a property P is any subset of   [  ! . P is a little-step property of a GUI h; ; C ; i if  ?! (rec C )  P holds, and a big-step property if  ?! (atomic (rec C ))  P holds. For example, we can express the property that the slider must track the dial as follows:

` 8e P: invariant e P = :ABORT e ^ (8n: wl n C length e  P (elt (wl n) e)) ` 8c: tracks c = (8e: c e  invariant e (s: s `s` = s `d`)) To verify that the GUI possesses this property we have to prove a theorem of the form: ? { 8s0 c: gui s0 c  tracks ((s: s = s0 ) ?! rec (atomic c)) This is a trivial property; but it is instructive to verify. We note that the attempt to derive consequences from speci cations not only point out aws in the speci cation but also in the formalization as well. Many dierent formalisms have been developed for specifying user interfaces (See the bibliographies of [3, 30], for example.) We can view speci cations expressed in these formalisms as properties. We say that a GUI big-step satis es a speci cation if the speci cation is a big-step property of the GUI and little-step satis es a speci cation if the speci cation is a little-step property of the GUI. To be able to mechanically verify implementations against these speci cations we must represent speci cations as sets of state sequences, and verify that the axioms and inferences rules of the formalism are valid.

5 Mechanical Veri cation In order to accomplish a machine assisted veri cation process we use the version of higher order logic mechanized by Gordon's HOL system [36]. The advantages of using HOL include the fact that mechanizations exist for a wide class of formalisms that have been used to specify user interfaces, including CSP [7], CCS [31], Statecharts [10], Temporal Logic [19, 39], and the Temporal Logic of Actions (TLA) [41].

The HOL system consists of a meta-language ML and a logic. The HOL logic is a natural deduction logic: assertions in the logic are sequents of the form (?; t), where ? is a set of assumptions and t is the conclusion. A sequent (?; t) asserts that if all of the formulas in ? are true, then so is t. A theorem is a sequent that has a proof, i.e. is either an axiom, or follows from other theorems by a rule of inference. To ensure that the only way to get theorems is by proof, theorems are isolated in the abstract data type thm. There are ve initial theorems corresponding to the ve axioms of the HOL logic; only the (functions representing the) eight primitive inference rules of the logic have access to the internal representation of a thm. ML's type system ensures that the only only way to get new theorems is by using these primitive inference rules. Derived inference rules can be implemented as ML procedures; in practice most proofs use these derived rules. Goal-directed proofs are simulated with tactics: functions that, given a goal, return a list of subgoals and a procedure for combining their proofs into a proof of the original goal. Properties are best proved using some sort of embedded logic for the formalism used to represent commands. For example, Hoare logic, or Dijkstra's predicate transformers can be used for guarded command languages. Even so, the proofs are tedious to construct and we are investigating ways of further mechanizing the process. In particular, we are investigating the use of symbolic execution as described in [8] to aid in the construction of proofs of state-invariant properties. The key step in such a proof would be the proof of a lemma of the form ? { 8s0 c: gui s0 c  (8s: P s  P (exec c s)) where exec c s returns the state of the GUI after executing command c from state s. Symbolic execution (implemented as an animation conversion) would be used to prove theorem of the form: ? { exec c s = s Conversions are a special class of inference rules in HOL that map terms of the logic to a theorem asserting equality of those terms to other terms. Each step of the animation is done by a systematic speci cation, unfolding, and simpli cation of the description of the command.

6 Conclusions We have constructed a preliminary prototype of the system described in this paper using Tredoux's mechanization of execution sequence semantics as a basis [39] and have constructed several proofs using Hoare logic. This has pointed out the need for more automation. Work is currently underway to construct a more

complete prototype through which we will be able to generate both an implementation (in Tk/Tcl [32]) and a speci cation from a particular description. Work is proceeding on embedding a logic-based speci cation framework for Abstract Data Views, an object-oriented formal model for specifying interfaces. Abstract Data Views (ADVs) are Abstract Data Objects (ADOs) or objects that have been speci cally augmented to support the speci cation of interfaces [2, 1]. We are also investigating the mechanization of ADVs (both the Temporal Logic and Statechart variants) to leverage on existing user interface speci cation work that we have done. The generality of the semantics adopted for the user interface descriptions (based on state sequences) ensures the feasibility of these mechanization procedures. In fact, the experimentation with these interface description styles have motivated us to attempt to construct a classi cation of the various properties that one would like to verify formally about user interfaces. In contrast with a at logical description of user interface components, the ADV formal model allows us to describe user interface abstractions structured from primitive components and to reason about local and global properties (modular veri cation) of the GUI components. Thus, in the ADV context, we can prove a more general class of user interface properties than the ones that can be proved within the framework of the formalism presented in this paper. To achieve this goal, we have to represent the logical ADV descriptions by state sequences and embed the ADV logic in higher order logic. Furthermore, we have to seek a suitable formalism for expressing the commands (as e.g. the Temporal Logic of Actions (TLA) [22]). As we can in principle represent both the implementation descriptions and the ADV descriptions in this formal framework (based on the same semantics: state sequences), it should be possible to prove in some sense the equivalence between the two description levels.

References 1. P. S. C. Alencar, D. D. Cowan Cowan, C. J. P. Lucena, and L. C. M. Nova. A Formal Speci cation of Reusable Interface Components (to appear). Technical report, Computer Science Department, University of Waterloo, Waterloo, Ontario, Canada, 1994. 2. P.S.C. Alencar, L.M.F. Carneiro-Con, D. D. Cowan, and C.J.P. Lucena. Towards a Logical Theory of ADVs. In Proceedings of the Workshop on the Logical Foundations of Object-Oriented Programming (to appear), August 1994. 3. Heather Alexander. Formally-based tools and techniques for human-computer dialogues. Ellis Horwood Limited, 1987. 4. Heather Alexander. Structuring dialogues using CSP. In M. Harrison and H. Thimbleby, editors, Formal Methods in Human-Computer Interaction, chapter 9, pages 273{295. Cambridge University Press, 1990. 5. Peter B. Andrews. An introduction to mathematical logic and type theory : to truth through proof. Academic Press, 1986. 6. Remi Bastide and Philippe Palanque. Petri net objects for the design, validation and prototyping of user-driven interfaces. In Proceedings of IFIP INTERACT'90:

7. 8.

9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.

Human-Computer Interaction, Detailed Design: Construction Tools, pages 625{ 631, 1990. A. J. Camilleri. Mechanizing CSP trace theory in higher-order logic. IEEE Transactions on Software Engineering, 16(9):993{1004, 1990. Juanito Camilleri and Vincent Zammit. Symbolic animation as a proof tool. In Thomas F. Melham and Juanito Camilleri, editors, Higher Order Logic Theorem Proving and Its Applications: 7th International Workshop, volume 859 of Lecture Notes in Computer Science, pages 113{127, Valletta, Malta, 19{22 September 1994. Springer-Verlag. Avra Cohn. The notion of proof in hardware veri cation. Journal of Automated Reasoning, 5(2):127{140, June 1989. Nancy Day. A model checker for Statecharts. Technical Report TR-93-35, UBC, October 1993. Digitalk. PARTS Workbench User's Guide, 1992. Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, Englewood Clis, New Jersey, 1976. Alan Dix and Colin Runciman. Abstract models of interactive systems. In Peter Johnson and Stephen Cook, editors, People and Computers: Designing the Interface, pages 13{22. Cambridge University Press, September 1985. Michael J.C. Gordon. HOL: A proof generating system for higher-order logic. In Graham Birtwistle and P. A. Subrahmanyam, editors, VLSI Speci cation, Veri cation and Synthesis, chapter 3, pages 73{128. Kluwer Academic Publishers, 1988. D. Harel and A. Pnueli. On the development of reactive systems. In Krzysztof R. Apt, editor, Logics and Models of Concurrent Systems, volume 13 of Series F: Computer and System Sciences, pages 477{498. Springer-Verlag, 1985. i-Logix Inc., Burlington, MA. The Semantics of Statecharts, January 1991. IBM. VisualAge: Concepts & Features, 1994. Imperial College of Science, Technology and Medicine. Darwin Overview, 1994. Amit Jasuja. Temporal logic in HOL, August 3 1990. In HOL distribution: . C. W. Johnson. Applying temporal logic to support the speci cation and prototyping of concurrent multi-user interfaces. In Proceedings of the HCI'91 Conference on People and Computers VI, Groupware, pages 145{156, 1991. Ralf Kneuper. Symbolic execution: a semantic approach. Science of Computer Programming, 16:207{249, October 1991. Leslie Lamport. The temporal logic of actions. ACM Transactions on Programming Languages and Systems, 16(3):872{923, May 1994. Z. Manna and A. Pnueli. Veri cation of concurrent programs: a temporal proof system. Technical Report CS-83-967, Stanford Univ., 1983. Lynn S. Marshall. A formal description method for user interfaces. PhD thesis, University of Manchester, 1986. Tom F. Melham. Higher order logic and hardware veri cation. Cambridge University Press, New York, 1993. Microsoft Corporation. Microsoft Visual Basic Programmer's Guide, 1993. M.J.C. Gordon. Mechanizing programming logics in higher-order logic. In Graham M. Birtwistle and P. A. Subrahmanyam, editors, Current Trends in Hardware ftp://

lal.cs.byu.edu/pub/hol/holsys.tar.gz

Veri cation and Automated Theorem Proving (Proceedings of the Workshop on Hardware Veri cation), pages 387{439, Ban, Canada, 1988. Springer-Verlag. 28. Brad A. Myers. State of the Art in User Interface Software Tools, chapter 5, pages

110{150. Ablex, Norwood, N.J., 1992.

29. Brad A. Myers. Why are human-computer interfaces dicult to design and implement? Technical Report CMU-CS-93-183, School of Computer Science, Carnegie Mellon University, July 1993. 30. Brad A. Myers. User interface software tools. Technical Report CMU-CS-94-182, School of Computer Science, Carnegie Mellon University, August 1994. 31. Monica Nesi. A formalization of the process algebra CCS in higher order logic. Technical Report 278, University of Cambridge Computing Laboratory, December 1992. 32. John K. Ousterhout. Tcl and the Tk Toolkit. Addison-Wesley, 1994. 33. S. Owre, J. M. Rushby, and N. Shankar. PVS: A prototype veri cation system. In Deepak Kapur, editor, 11th International Conference on Automated Deduction, LNAI 607, pages 748{752, Saratoga Springs, New York, USA, June 15{18, 1992. Springer-Verlag. 34. F. Paterno and G. Faconti. On the use of LOTOS to describe graphical interaction. In A. Monk, D. Diaper, and M. D. Harrison, editors, Proceedings of the HCI'92 Conference on People and Computers VII, pages 155{173. Cambridge University Press, September 1992. 35. Lawrence C. Paulson. Isabelle: A Generic Theorem Prover, volume 828 of Lecture Notes in Computer Science. Springer-Verlag, 1994. 36. SRI International under contract to DSTO Australia, Cambridge, England. The HOL System: Description, 1989. 37. Bjarne Stroustrup. The C++ Programming Language. Addison-Wesley, second edition, 1991. 38. Kari Systa. Specifying user interfaces in DisCo. SIGCHI Bulletin, 26(2):53{58, 1994. Presented at a Workshop on Formal Methods for the Design of Interactive Systems, York, UK, 23rd July 1993. 39. G. Tredoux. Mechanizing execution sequence semantics in HOL. South African Computer Journal, 7:81{86, July 1992. Proceedings of the 7th Southern African Computer Research Symposium, Johannesburg, South Africa. Also available as part of the HOL distribution: . 40. Gavan Tredoux. Mechanizing nondeterministic programming logics in higher-order logic. Technical report, Laboratory for Formal Aspects of CS, Dept Mathematics, University of Cape Town, Rondebosch 7700, South Africa, March 22 1993. 41. Joakim von Wright and Thomas Langbacka. Using a theorem prover for reasoning about concurrent algorithms. In G. v. Bochmann and D. K. Probst, editors, Comftp://lal.cs.byu.edu/pub/hol/holsys.tar.gz

puter Aided Veri cation: Proceedings of the Fourth International Workshop, CAV '92, number 663 in Lecture Notes in Computer Science, pages 56{68. Springer-

Verlag, June/July 1992. 42. Watcom International Corporation, Waterloo, Ontario, Canada. WATCOM VX REXX for OS/2 Programmer's Guide and Reference, 1993.


This article was processed using the LATEX macro package with LLNCS style