A Framework for Prototyping and Mechanically User Interfaces

Peter Bumbulis P. s. c.

Verifying a Class of

Alencar

Computer Science Department University of Waterloo, Waterloo

Waterloo, Ontario N2L 3G1

Departamento de Citncia da Computac;k Universidade de Brasilia

Brasilia, Brazil

D.D. Cowan C . J .P. Lucena

Computer Science Department University of Waterloo, Waterloo

Depart amento de Informktica Pontificia Universidade Cat6lica do Rio de Janeiro

Waterloo, Ontario N2L 3G1

Abstract Increasing importance is being attached to the

ability of ensuring that graphical user interfaces (GUIs) behave as ezpected, as they are being used in more applications where safety and security are critical. Prototyping is the preferred approach to creating GUIs because of the need to allow the user to test many of the issues associated with usability. Unfortunately it is often dificult to verify that prototype-based implementations always behave as ezpected. In this paper we present a jhameluork for prototyping GUI-based applications in which both an implementation (prototype) and a formal model of that implementation are mechanically derived from a description of the application. The model can then be used to support proofs of behavior, while the prototype can be used to test functionality and usability.

Keywords: User interfaces, rapid prototyping, validation.

1 Introduction As graphical user interfaces (GUIs) are becom-

ing more and more common for security- and safety- critical applications it is becoming increasingly impor- tant to CMUX that GUI-based applications behave as expected.

Unfortunately, traditional specification-based ap- proaches to formal software development are not likely to be directly applicable to user interface construc-

280 1066-1387B5 $4.00 0 1995 IEEE

Rio de Janeiro, Brazil

tion. Even proponents of formal software development techniques have noted that "Formal techniques were not much help to us in designing the user interface." [l]. User interface design falls within the domain of human-computer interaction (HCI) engineering. Jwt as one goal of software engineering is "sero defect" software, a goal of HCI engineering is to eliminate uuser error" [2]: this goal is of particular relevance to security- and safety-critical applications. Many HCI techniques involve prototyping; indeed, empirical evi- dence suggests that "the only reliable method for gen- erating quality user interfacm is to test prototypes with actual end users and modify the design based on the users' comments and performance" [3]. In order to determine if prototypes behave as expected, fault' detection techniques can be applied.

One fault detection technique often used in con- junction with prototyping is testing. While testing can be effective there are limitations, especially with re- spect to GUI-based applications. First, it is often m- cult to construct an oracle that determines acceptable application behavior: usually it is left for somebody to visually examine the results and guess whether system has behaved correctly. This is an error-prone proce dure. Second, test data selection is often problematic: unless carefully done, the results produced wiU be no better than with random testing [6].

'"Software may contain fault., which may cause c+rorr in executions of that roftware, possibly manifested in failunr in the ryrtem of which the roftware is part." [SI.

r- - I

In this paper we present a framework for prototyp- ing GUI-based applications which admits an approach to fault detection based on formal proof. In this frame- work, both an implementation (prototype) and a a for- mal model of that implementation are mechanically derived from a description of the application. The prototype can be used for testing with end users, and the derived model can used as the basis for mechani- cal reasoning about correct behavior. This framework does not preclude testing; indeed, the models that we construct also could be used as test oracles.

To have confidence in the significance of our proofs we need to have confidence that our models are faithful2. We address this issue by restricting our at- tention to applications that can be described as a hi- erarchy of interconnected component instances, and by modeling the components in such a way so that, roughly speaking, the composition of faithful models of components is a faithful model of the corresponding composition of components. This reduces the problem of verifying that models are faithful to the problem of verifying that the models of the primitive components are faithful. This problem can be tackled with exist- ing software engineering techniques, be it testing or formal development. Designing the primitive compo- nents with reuse in mind will reduce the amortized cost of verification.

In practice, a range of applications can be expressed in this fashion: there exist commercially available tools such as PARTS Workbench [6] and Visual Age [7] that, for the most part, structure applications in this way. Unfortunately, the lack of an accessible for- mal syntax8, not to mention semantics, makes these tools unsuitable for our needs. As a result we propose a slightly different approach to prototyping GUI-based applications, one that can be adapted for use with any toolkit* that follows a notificution-Bused model [ll].

Toolkits that follow a notification-based model pro- vide a notifier that will act as the main thread of the application. The notifier obtains events from the o p erating system, possibly translates them into higher- level events, and then invokes previously registered

aThe precise definition of faithfulness depends on the prop- erties we arc modeling.

SApplicationr are constructed using tools that manipulate some undocumented internal representation. While each tool providca a formalism for describing a particular view of the pro- totype (e.g. dilrlogr for attributes, code or graphs for scripts), none gives a complete description. A complete description of the prototype can be found in the save file; unfortunately the format of this file is usually proprietary.

'We ure the term toolkit to refer not only to interface li- braries such M Motif [SI but to interface builders such M Visual Basic [SI and VX-REXX [lo].

281

callback procedures. Most toolkits provide interface objects such as buttons and sliders that register call- back procedures directly with the notifier; applications register callback procedures with these interface ob- jects. These interface objects are commonly referred to as widgets.

2 General framework Rather than prototyping applications directly us-

ing an existing imperative language we instead de- scribe applications using an interconnection language, IL, and (mechanically) derive prototypes and models from these descriptions as illustrated in Fig. 1 (below the dashed line.)

............. *. .. .:: Original V I ' .:.

. . . . . . . . . . . . . . a - ..

c-5 prototype >&z-=

Figure 1: General framework.

Another possible use for IL that we are investigat- ing is user interface re-engineering: we can construct an IL prototype of an existing user interface and then use this prototype as a basis for reasoning. This pos- sibility is indicated by the dotted part of Fig. 1.

IL is intended to be used in conjunction with an ex- isting toolkit; the widgets provided by this toolkit wil l be used in implementing the primitive components. Note that we do not assume the existence of a uni- versal set of primitives; each application will typically require some application specific primitives as well.

There are two Merent roles associated with the development of &based applications: the user inter- face designer, or just designer, and the developer. The tasks of the designer and developer can be character- ized as using and constructing primitive components, respectively. The designer constructs applications us- ing components supplied by the developer. If a re- quired component is not available the designer can

T I I. " -T---

# Slider'build name: Create a slider named "name".

proc Slider'build {name} {

# These should be attributes.

set vo 0 ;# Hinimum value for slider. set v1 80 ; # Haximum value for slider. set tickhtervel 20 ;# Spacing between tick marks. set Length 160 ;# Length (in screen units) of slider.

# Construct the physical representation.

scale $name -orient horizontal-from $VO -to $Vl \

pack $name -tickinterval (tickhterval -length $Length -command tname'set

# Construct the model.

# Create variable that will hold value o f the slider.

global $name'value set tname'value ""

# If the value of the slider changes $namerset will update the # position o f the pointer and then invoke (name'changed.

proc $name'set {value} 'I global Sname'value if \I' ! \ Ccequal \$\{$name'value\} \$value\] \I' \{

set $name'value \$value $name set \$value Sname'changed \$value

Figure 4: Slider in Tk/Tcl.

283

# ! /xhbin/wishr -f source oxtoral.tk

proc Xain'build {root} { Fr.m.'build $root.f Dial'build $root .f .d Slider'bdld $root.f.s proc (root .f .d'changod {valuo) \

"$root .f ..'sot \$value" proc $root .f . s'changod {valuo} \

"$root .f .d'aot \SviLuo" 1 Main'build ""

Figure 5: Generated Tk/Tcl code for the example.

Figure 6: Tk/Tcl version of example.

instance a unique name and using this aa a p r h for the names of all variables and procedures associated with that instance. 3.2 Constructing models

We are also interested in reasoning about how GUI- based applications interact with their environment. For example, we would like to be able to prove that the dial and slider in Fig. 6 track each other. To do this we model the behavior of an application a se- quence of states with each consecutive plrir of states in the sequence representing some action. Roughly speaking, we model applications predicates on state sequences: if P is a predicate representing an appli- cation A then P e is true if and only if e M a possible behavior of A. If P is a model of Pig. 6 then to prove that the slider and the dial track each other we have to prove a theorem of the form t- Ve. P e 3 Q e, where Q is a predicate expressing the fact that for all states in a given state sequence, the value of the slider is equal to the value of the dial.

If we are to generate models for IL-baaed applica- tions mechanically we must be able to model com- ponents as predicates and be able to espresa predi- cates representing applications in terms of the predi- cates representing their constituent components. For- tunately such a representation is poosible.

We make the observation that a collection of wid- gets can be described as a set of mutually recursive functions. For example, if we model the state of the prototype in Fig. 6 with the values of the two variables d and s (representing the values of the dial and the slider, respectively) then its behavior can be modeled with the following ML expression: fun gui 0 - lot fun sotDial v =

if (!d = v) thon (1 0180 (d := v; setS1id.r v)

and aotS1id.r v = if (!s = v) thon ()

01.0 (a := v; setDial v) in whilo true do cas. uaorlction () of

("dial" ,v) => setDial v I ("alidor",~) => sotslidor v

end ; The function gui models the possible ways in which the user can interact with the application: the user can either set the dial or the slider to some value. The while loop models the behavior of the notifier. What follows is a formabation of this observation.

The formal system we use to express and reason about our models is a version of type theory [14, 151

called higher-order logic [16]. Higher-order logic ex- tends firstorder logic by allowhg higher-order vari- ables (i.e. variables whose values are functions) and higher-order functions (i.e. functions whose arguments and/or results are other functions.) One advantage of using higher-order logic is the existence of reliable and

The existence of such proof assistants is impor- tant for two reasons: 1) experience has shown that machinoassisted proofs are more trustworthy than those done by hand [19], and 2) for some proofs, sig- niticant portions can be automated. The proof assis- tant that we use is HOL. HOL embeds a higher-order logic" in the functional programming language ML [20]. Axioms and primitive rules of inference are en- capsulated in an abstract data type thm; ML's strong typing ensures that theorems (objects of type thm) can only be obtained from these axioms and inference rules. The embedding in ML allows an arbitrary de- gree of mechmbation while still guaranteeing sound- ness.

We model a GUI-based application as a triple (E, 0, C) with the following components:

robust proof-&tants Such as HOL[17] and PVS [la].

e C, a set of states.

e 8, an initial condition. This assertion character- izes the states at which execution of the GUI can begin. A state satisfying 0 is called an initial state.

C, an assertion characterizing the possible behav- iors resulting from a single action by the environ- ment (such as a button press). Such assertions are referred to as commands. Behaviors are state sequences. Behaviors can be finite or infinite; fi- nite behaviors must have at least one element. We denote finite behaviors as (SI, . . . , sn) and in- finite behaviors as ( S I , . . . ) . If b is a behavior, then length b E M U {U} denotes the number of states in the behavior, with st b i denoting the ith state. We also use first b to denote the first state of the behavior and, if b is finite, last b to denote the last state.

We define the composition of two behaviors b1 e bl to be b1 if bl is infinite, and the sequence obtained by appending all but the first element of b2 to b1 if b1 is finite and firstbl = lartbl. If b1 is finite and first bl # last b1 then b1 e b l is undefined.

A (little-step) computation of a user interface (C, 8, C) is defined to be any non-eztensible compo- sition of behaviors from C that starts from a state in

6Appendix A contains a brief introduction to the HOL logic.

0. A behavior b is said to be non-extensible with re- spect to C if b is infinite, or if b is finite and b e b' is not defined for any b' satisfying C.

We define atomic b to be (first b, last b) if b is finite and ({firrtb,}W) if b is infinite. We extend this defi- nition to commands (predicates on behaviors) in the usual fashion, i.e. for any predicate P on behaviors (atomicP)b holds iff there is some behavior b' such that Pb' and b = atomicb'. A big-step computa- tion of (C,O,C) is defined to be a computation of (C, 8, atomic C). Big-step computations are useful for reasoning about presentation aspects.

Rather than explicitly constructing predicates for C and 0 we instead construct a predicate P that charac- terizes C and 8, i.e. we construct a predicate P such that P t c holds iff t = 0 and c = C. If we are to mechanically construct P from a description such as that found in Fig. 3, we need to be able to express P in terms of predicates describing components.

Specifying components We define for each type of component a predicate component a0 cmdpl . . . pn which is true if and only if cmd is a command which expresses the behavior of the component when con- nected as speciiied by the parameters and started in state so'. This relation typically gives a relation for each input port in terms of the output ports and a re- lation defining the behavior of the component in terms of the input ports. Note that we can view input ports as procedures provided by the component and output ports as procedures that are required by the compo- nent. If i l , . . . , in are the input ports and 01, . . . , om are the output ports then component will have the fol- lowing form (ignoring parameters dealing with state, for the moment):

component cmd il . . . in 01 . . . om = (il = PI 01 . . . om)/\

(in = Pn 01 . . . om)A (d= Pi1 ...in)

Note that this is actually a constant definition in higher order logic defining component to be the func- tion A c d i l . . . in 01 . . . om. (. . .) A . . . A (. . . )'.

We need to introduce a formalism for express- ing commands (i.e. for expressing P and the Pi) to make reasoning more tractable. We choose to repre- sent commands using a formalism similar to Nelson's

'A similar approach is used for hardware verification [21]. 'In higher order logic predicates are simply boolean-vdued

functions.

285

. -- I

rkipb = 38.b = (8)

(assign E ) b = 3r b. b = (8 , E 8 )

(c1 0 C)) 6 = c1 b v C) b (c1 ; c)) b = c1 b A (length b = w )

V 3bl b) . ~1 bl A C ) ba A (b = bl b l ) ( P - - - ( c ) b = P ( f i r s t b ) A c b

Figure 7: Primitives and operations for building com- mands.

extension [2718 of Dijkstra’s guarded command lan- guage [26]. We have chosen such a formalism since not only are mechanbations available for a variety of programming logics [22, 231, but also because of the the possibility of using symbolic execution [24] to help in constructing various proof [26]. The subsequent development does not depend on the particular for- malism chosen; all that is required is a means of ex- pressing sequential composition and non-deterministic choice.

Figure 7 provides a partial summary of the defini- tions used in this paper, defining primitives skip and assign and operators ‘U’, ‘;’, and ‘-’. For example, the first line in Fig. 7 defines skip to be the predi- cate Ab. 38. b = ( U ) , i.e. for any behavior b skip b holds iff b is of the form ( a ) , for some state 8. Infix no- tation t used for the binary predicates to improve readability. Missing from Fig. 7 is the definition of a repetitive construct dond: its definition is consider- ably more involved than the rest. Informally, dondc means “repeatedy execute c until no longer possible.” It can be verified that our sequence-based semantics agrees with the usual semantics for guarded command hguages’O.

Given this notation, we can define the little-step semantics of a user i n t e rhe (E, C, 0) to be the com- mand 8 4 (do-odC) and the big-step semantics of (E, C , 8) to be the command 8 - (do-od (atomic C)).

Although we have avoided dealing with concurrency at this stage of our work, the approach presented can d y be extended to handle concurrent descriptions by introducing an interleaving or shuffle operator. The difficulty lies not in specifying concurrent behavior, but in reasoning about it.

DNclson’s extension d o w s for partial commaadl and drops

loby deriving Dijkrtra’i calculus of predicate transformers, for the law of exduded miracle.

example.

Primitive components We assume that d&- tions for the primitive components are provided; when a new primitive is constructed, the user interfsce de- signer is presented not only with an impbmentation, but also with a specification of its (intended) behav- ior. For example, (ignoring initial conditions) the def- inition of a dial” might be given as follms:

dial cmd 8 q ret changed= (ret= (Au.

(q(An. (n=u)) - o(q (An. -(n=u)) - skip)

(assign ( 8 (An. U)) ; changedu)))) A(cmd=(%. ret U))

In the above example ‘3’ is just the existential quantifier ‘3’ “lifted” to work on predicates: for all b, (3. R i ) b=(3i. Rib). The above formula character- bes dials by specifying the behavior of a dial given the behavior of the components to which it is connected. For example, the semantics of ret can be stated in- formally as follows: “ifu is equaZ to n then do noth- ing; eLe set n to U and then ezccute ‘changdv’ ” where n is the state component that holdr the cur- rent value of the dial. Similarly, the semurtica of cmd can be stated informally as “ezecute ‘ret U’ for some arbitrary value u.” The parametem 8 and q are used to d e h e the state component allocated to a partic- ular dial instance: these parameters will be instanti- ated with functions that update and query a partic- ular state component, respectively. Examples of such functions can be found in the definition 6f gui below.

Composite components Models are automati- cally generated for composite components from their IL descriptions. The model of a composite component is defined in terms of the models of it6 constituent components. For example, the specification generated for the user interface of Fig. 2 looks (more or less) like:

gui cmd=(3cmdl cmdi ret1 ret) . slider cmdl (Af (8, d) . (f 8, d ) ) (AP ( 8 , d ) . P U ) #et1 .et)

Adial cmdl (Af (8, d ) . ( 8 , f d ) ) (AP ( 8 , d ) . P d ) ret) ret1 A(mzd=cmd10 cmda))

In general, states are modelled with tuples. In the above example, states are modelled with pairs, the first component holding the value of the slider and the second component holding the value of the dial. Note that we do not have a closed form expression

“Sliden arc modelled similarly.

for the behavior; instead we are left with a system of recursive equations.

4 Summary and future work We have constructed a preliminary prototype of the

system described in this paper. Currently this consists of IL to Tk/Tcl and IL to HOL translators, and a number of HOL theories and tactics. Essentially all of the basic features of the proposed framework have been implemented.

Work is underway on constructing a more complete prototype with a richer set of primitives. Concur- rently, we are attempting to identify (and classify) formal properties that GUI-based applications should possess as well as investigating how to mechanise the various proots that arise.

A Appendix: The HOL logic The following is a brief introduction to the HOL

logic; a complete formal definition can be found in the reference manual [28].

Terms in the HOL logic are expressions that denote values and have syntax

t ..- ..- c I v I ( 2 t‘) I AV. t

where c ranges over constants, v over variables, and t and t’ over terms. t t ’ denotes the value obtained by evaluating the function denoted by t at 2’; AV. 1 denotes the function whose value at z is obtained by substituting c for v in t .

To prevent inconsistencies such as Russell’s paradox syntactically well-formed terms must be well-typed, i.e. have types consistent with the types of their sub- terms. Types in the HOL logic are expressions that denote sets”: a term of type U denotes an element of U. If t is a term we write t: U to denote that t has type U. Such explicit type information will usu- ally be omitted, however, when it is clear from form or context what the type must be. Types have syntax

U ::= c I v I (Ul,. . . ,u,)qp where c ranges over atomic types, v ranges over type variables, op ranges over type operators and U, along with its subscripted variants, range over types. Type constants and type variables can be distinguished syn- tactically: the names of type variables must begin with the symbol ‘*’. To improve readability, a num- ber of commonly used binary type operators have in- fix forms. For example, ‘+’ is a distinguished (infix) type operator that constructs function spaces between

‘2Strictly rpeaking thir is not true; the prerence of type vari- abler complicater matters. Full detaik can be found in [ZS].

types. The HOL logic contains only two primitive types: :boo1 (just the truth values T and F) and :ind (an infinite collection of distinct elements). All other types must be constructed from these Using ‘+’. For convenience, the HOL system comes with a variety of derived types and type operators.

Features to note about the HOL logic include:

Formulas are represented with t e r m of type :bool; predicates are represented with function8 with range :bool. For example, if P is defined to be A n . 3 m . n = 2 x m t h e n P z b trueifandonlyif z is an even natural number.

e A Milner-style polymorphic typing discipline is used. Type variables may be free in a term of the logic, but quantification over type variables is not allowed.

Binding conventions are used to reduce the number of parenthesis needed in terms and types. Function ap- plications associate to the left: the term f1 fa . . . fn z is parenthesized as (. . . ((f1 f2)fS). . . fn)z. In types, ‘-+’ associates to the right: u1 4 u2 + . . . + U,, + U is parenthesised as u1 + (01 + (... + (U,, 4 U). . .)). In terms with variables bound by ‘V’, ‘Y, ‘ E ’ , or ‘A’, the scope of the binder extends as far to the right of the ‘.’ as possible. For example, the term (Vz. z = Ay. zy) is parenthesized as (Vz. (z = Ay. zy)) not ((Vz. z) = (Ay. zy)).

References [l] C. B. Jones, K. D. Jones, P. A. Lindsay, and

R. Moore, Mural : a formal development sup- port aystem, Springer-Verlag, 1991.

[2] Bill Curtis and Bill Hefley, “A WIMP no more”, ACM interactions, pp. 23-34, Jan. 1994.

[3] Brad A. Myers, State of the Art in User Interfuce Software Tools, chapter 5 , pp. 110-150, Ablex, Norwood, N.J., 1992.

[4] Michal Young and Richard N. Taylor, “ R e thinking the taxonomy of fault detection tech- niques”, Tech. Rep. TR62P, Software Engineer- ing Research Center, Department of Computer Sciences, Purdue University, Sept. 1991, An ear- lier version of this paper appeared in Proceedings of the 11th International Conference on Software Engineering, Pittsburgh, May 1989.

[5] Dick Hamlet and Ross Taylor, “Partition testing does not inspire confidence”, in Proceedings of

287

I---- --- 1 - -----

the Second Workshop on Software Testing, Veri- fication and Analysis, Lee J. White, Ed. July 19- 21 1988, pp. 206-215, IEEE Computer Society Press.

Digitalk, PARTS Workbench User's Guide, 1992.

IBM, VisualAge: Concepts d Features, 1994.

Open Software Foundation, OSF/Motif Program- mer's Reference, Revision 1.1, 1991.

Microsoft Corporation, Microsoft Visual Basic Programmer's Guide, 1993.

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

Dan Heller, XView Programming Manual, vol. 7 of The X Window System, O'Reilly & Associates, Inc., Sebastopol, CA, 1990.

Imperial College of Science, Technology and Medicine, Darwin Overview, 1994.

John K. Ousterhout, Addison- Wesley, 1994.

A. Church, "A formulation of the simple theory of types", The Journal of Symbolic Logic, vol. 5,

Tcl and the Tk Toolkit,

pp. 56-68, 1940.

Peter B. Andrews, A n introduction to mathemat- ical logic and type theory : to truth through proof, Academic Press, 1986.

M. Gordon, "Why higher-order logic is a good formalism for specifying and verifying hardware", in Formal Aspects of VLSI Design: Proceedings of the 1985 Edinburgh Workshop on VLSI. 1986, pp. 409-4 17, Nort h-Holland.

M. J. C. Gordon and Tom F. Melham, Introduc- tion to HOL: a theorem proving environment for higher order logic, Cambridge University Press, New York, 1993.

[20] G. Cousineau, M. Gordon, G. Huet, R. Milner, L. Paulson, and C. Wadsworth, The MI, Hun& book, INRIA, 1986.

[21] Tom F. Melham, Higher order logic and hardware verification, Cambridge University Press, New York, 1993.

[22] M.J.C. Gordon, "Mechanisiig progrmming log- ics in higher-order logic", in Current 'Itan& in Hardware Verification and Automated Thwnm Proving (Proeccdings of the Workrhop on Hun& ware Verification), Graham M. Bittwbtle and P. A. Subrahmanyam, Eds., Banff, C&, 1988, pp. 387-439, Springu-Verhg.

[23] G. Tredoux, "Mechanising execution sequence semantics in HOL", South Africa@ Computer Journal, vol. 7, pp. 81-86, July 1998, Proceed- ings of the 7th Southern African Computer €b search Symposium, Johannesburg, South Mea. Also available as part of the HOL distribution: ftp://Ial.cs. byu.cdu/pub/hol/holryc.trr.gz.

[24] Ralf Kneuper, "Symbolic execution: a semantic approach", Science of Computer Programming, vol. 16, pp. 207-249, Oct. 1991.

[25] Juanito Camilleri and Vincent Zammit, "Sym- bolic animation as a proof tool", in Higher Or- der Logic Theorem Proving and Ib Applications: 7th International Workshop, Thomar F. Melham and Juanito CamiUeri, Eds., Valletta, Malta, 19- 22 September 1994, vol. 859 of Lecture Noter in Computer Science, pp. 113-127, Springer-Verlag.

[26] Edsger W. Dijkstra, A Discipline of Program- ming, PrenticoHall, Englewood clifts, New Ju- sey, 1976.

[27] Greg Nelson, "A generalisation of Dijkstrr'r cal- culus", ACM ~ n s a c t i o n s on Programming Lan- guages and Syrtems, vol. 11, no. 4, pp. 517-561, Oct. 1989.

l281 SRI International under contract to DSTO Aus- . a

[la] S. Owre, J. M. Rushby, and N. S h a n k , "PVS: A prototype verification system", in 11th In- Reference, 1989. ternational Conference on Automated Deduction, Deepak Kapur, Ed., Saratoga Springs, New York, USA, June 15-18, 1992, LNAI 607, pp. 748-752, Springer-Verlag .

[19] Avra Cohn, "The notion of proof in hardware verification", Journal of Automated Reasoning, vol. 5, no. 2, pp. 127-140, June 1989.

tralia, Cambridge, England, The HOL Syrtem: