Corporation in Pittsburgh . His contribution to this work was the result of an independent study project under the supervision of Gregory Abowd within the Master of Software Engineering program at Carnegie Mellon . The authors would also like to acknowledge the enthusiastic support from Ed Clarke and various of his students at Carnegie Mellon for help in understanding SMV . 9 . References -LSB- 1 -RSB- Addison , M. and Thimbleby , H. Manuals as structured programs . In People and Computers IX : Proceedings of HCI ? 94 , G. Cockton , S.W. Draper , and G.R.S. Weir , eds. , Cambridge University Press , pp. 67 ? 80 , 1994 . -LSB- 2 -RSB- Arnold , A. Finite Transition Systems , Prentice Hall International , 1994 . -LSB- 3 -RSB- Atlee , J. Gannon , J. State-based model checking of event-driven system requirements . IEEE Transactions on Software Engineering , 19 -LRB- 1 -RRB- :24 ? 40 , January 1993 . -LSB- 4 -RSB- Burch , J. Clarke , E. , McMillan , K. , Dill , D. and Hwang , J. Symbolic model checking : 1020 states and beyond . In Lecture Notes in Computer Science , Springer-Verlag , 1990 . -LSB- 5 -RSB- Clarke , E. , Emerson , E. and Sistla , A. Automatic verification of finite-state concurrent systems using temporal logic specifications . In ACM Transactions in Programming Languages and Systems . 8 -LRB- 2 -RRB- :244 ? 263 , April 1986 . -LSB- 6 -RSB- Dix , A. , Finlay , J. , Abowd , G. and Beale , R. HumanComputer Interaction . Prentice-Hall International , 1993 . -LSB- 7 -RSB- Green , M. Report on dialogue specification tools '' , in Pfaff -LRB- ed -RRB- , User interface management systems , Springer Verlag , pp 9-20 , 1985 . Reprinted in `` The separable User Interface '' , Edmonds , E. -LRB- ed . -RRB- , London : Academic Press , 1992 . -LSB- 8 -RSB- Hill , R.D. Event-response systems - a technique for specifying multi-threaded dialogues . In Carroll , J.M. & Tanner , P.P. -LRB- Eds . -RRB- , Human factors in computing systems and graphics interface , CHI + GI '87 Conference Proceedings , ACM , pp. 241-248 , 1987 . -LSB- 9 -RSB- Monk , A. F. and Curry , M. B. Discount dialogue modelling with Action Simulator . In People and Computers IX : Proceedings of HCI ? 94 . Cambridge University Press , 1994 In press . -LSB- 10 -RSB- McMillan , K. Symbolic Model Checking : An approach to the state explosion problem . Carnegie Mellon University , Computer Science Department , Technical Report CMU-CS-92-131 , 1992 . Ph.D. dissertation . -LSB- 11 -RSB- Newman , W.M. . A system for interactive graphical programming , Proceedings of the Spring Joint Computer Conference , pp. 47-54 . Reprinted in `` The separable User Interface '' , Edmonds , E. -LRB- ed . -RRB- , London : Academic Press , 1992 . -LSB- 12 -RSB- Olsen , D. Propositional production systems for dialogue description . In Human Factors in Computing Systems : Proceedings of CHI ? 90 . ACM Press , pp. 57 - 63 , 1990 . -LSB- 13 -RSB- Olsen , D. , Monk , A. and Curry , M. Algorithms for automatic dialogue analysis using propositional production systems . To appear in Human-Computer Interaction , 1995 . -LSB- 14 -RSB- Thimbleby , H. Combining systems and manuals . In People and Computers VIII : Proceedings of HCI ? 93 , J. Alty , D. Diaber and S. Guest , eds. , Cambridge University Press , pp. 479 ? 488 , 1993 . -LSB- 15 -RSB- Wang , H.-M . and Abowd , G.D. . A tabular interface for automated verification of event-based dialogues . Department of Computer Science , Carnegie Mellon University , Technical Report CMU-CS-94-189 , October 1994 . late pre - and post-condition semantics of a production system in a tabular form . There is no evidence to support this claim and some anecdotal experience shows that students do not find it all that straightforward to go from a set of loosely expressed task scenarios to a development of a structured tabular representation . The main problem is that they find it hard to grasp what dialogue state is all about . Apart from that formulation problem , there is one advantage of the tabular representation . Assuming that you are comfortable with the list of events you want to model and the state of the dialogue , the tabular representation gives a good visual cue as to when the dialogue formulation process is complete ? you simply have to fill in all of the cells in the table . From an engineering perspective , that is an advantage . Efficient techniques for dialogue verification address one of the difficulties in dialogue development ? computational state explosion . But there is another problem ? descriptive state explosion , or the difficulty in representing a dialogue description in a compact for communication purposes . Indeed , as discussed earlier , this is one of the reasons a notation like PPS has been offered as a suitable dialogue description language . In its current form , large dialogue descriptions -LRB- many events or many dialogue state fields -RRB- will produce unwieldy tabular descriptions and unless there is some convenient way of collapsing the table while still communicating its meaning to the designer , this approach is likely to fail . This is a current research question for us in this work . Another underlying assumption in this work is that dialogue properties are both important in the early stages of interactive system design and difficult enough to get right that designers will need the assistance of these kinds of techniques and tools . There is not enough evidence to establish that assumption . One type of property that seems very amenable to automated verification is the undo problem , but as is discussed above -LRB- and in Chapter 8 of -LSB- 6 -RSB- -RRB- , real undo is not a dialogue property but an application property . There is no reason why application semantics can not be brought explicitly into the state of Action Simulator/PPS productions , but that will only serve to exacerbate the descriptive state explosion problem . SMV is a state-based language ; it does not treat events as first-class state transition labels . This means that events must be encoded as non-deterministically set state variables . This is a technicality , but the practical ramifications are that some dialogue properties can not be adequately expressed as CTL expressions . We saw an example of this in Section 5.6 on weak task connectedness where the actual property that can be stated with CTL is stronger than the property we would like to express . It is unclear at the moment whether there is a reasonable alternative to SMV that would circumvent this problem or perhaps another way to translate the tabular dialogue description into SMV . The work described here is based on a production rule for - malism for dialogue description and analysis . In -LSB- 6 -RSB- , we have described a much wider range of dialogue models which vary along a number of dimensions such as overall expressive power of the underlying model -LRB- e.g. , regular expressions vs. BNF grammars -RRB- , support for concurrency -LRB- e.g. , state transition networks vs. statecharts -RRB- and overall ease of notation -LRB- graphical vs. textual -RRB- . It is the ultimate goal of this research to investigate the development of general dialogue analysis tools which will allow for automatic translation between various dialogue models , allowing a designer to take advantage of particular notations as and when they are appropriate . One part of the overall dialogue development that we have not yet addressed is the question of visualization of the verification task back into the dialogue simulator . Frequently , when a property fails verification , SMV will provide a counterexample . This counterexample is potential evidence for the dialogue designer that could assist in repairing the dialogue model . It would be useful if that evidence were simulated for the designer to help detect the problem . This visualization does not seem to be an inherently difficult problem , but it will only be useful for properties that are expressed as global constraints -LRB- always holding at every point along all possible execution paths -RRB- . Only global constraint properties will produce useful counterexamples . The example we used in this paper was a rather small example of the dialogue for a photocopier . In -LSB- 15 -RSB- , we performed a similar analysis on a slightly more complex example of a personal digital assistant . 7 . Conclusions In this paper , we have shown how separate technologies from within the HCI research community -LRB- Olsen?s PPS and the Action Simulator -RRB- and Software Engineering research community -LRB- model checking and the SMV tool -RRB- can be combined to provide a much more complete dialogue development method that supports both validation and verification . A tabular representation of a dialogue model using preand post-condition semantics in a production rule format is used to synthesize an initial dialogue model and simulate that model to validate against a set of requirements scenarios . This tabular representation is then translated into the finite state representation of a state-of-the-art model checker , SMV , which allows for the automated verification of any property which can be expressed in the branchingtime logic of CTL . We demonstrated how 9 different dialogue properties could be expressed in CTL . All of these properties were variants on the general question of dialogue reachability . 8 . Acknowledgments Hung-Ming Wang is currently an employee of TransArc Template : We have defined a special ? stuck ? action that is enabled when no other pre-conditions are matched . This property is expressed to state that there is no possible execution path that has the stuck event enabled . 5.3 Weak task completeness Question : Can the user find a way to accomplish a goal from initialization ? Reaching a goal , from the dialogue perspective , is understood as being able to reach a particular dialogue state . So , we might ask whether the user can always set the photocopier to the multiple copies state . Template : For a given state predicate , there is a possible execution path from the initial state that will end up satisfying that predicate . 5.4 Strong task completeness Question : Does the dialogue model ensure that a user can always accomplish a goal ? This is slightly stronger than the previous example , because now we are concerned that the user not be able some actions that prevent reaching some dialogue state . So , for example , the user will always have to turn on the photocopier when it starts in the off state -LRB- Ready = notOK -RRB- Template : From the initial state , regardless of execution path , there is some state eventually attainable . 5.5 State inevitability Question : From any state in the dialogue , will the model always allow the user to get to some critical state ? We usually want to make sure that no matter how the user interacts with the system , she is always able to get to certain designated important states . Template : It is always true -LRB- i.e. , at every point along all execution paths , starting at any possible state -RRB- that some other dialogue state must be reached . 5.6 Weak task connectedness Question : From any state , can the user find some way of getting to a goal state ? This is similar to weak task completeness , only we do not restrict the user from starting at the initial state . Template : Because of the way the state machine is encoded and because SMV forces us to encode actions or events as state information , we must express a property which is stronger than the question states . We can only say that it is always true -LRB- at all points along every execution path , including every intended first user action -RRB- there is an execution path that at some point satisfies the goal dialogue state . We would rather not have to include the information that this must hold regardless of the intended first user action , but we are unable to state that in the current model . 5.7 Strong task connectedness Question : From any state , can the user find some way to get to a goal state via a particular action ? This property is stronger than the previous one because we now want to dictate what action it is that the user performs to ultimately achieve the desired dialogue state . So we want to make sure that , for example , the user can get to the photocopier state with Copies = OneCopy by doing the Req_mult_copies action . Template : It is always true -LRB- at every point along every possible execution path -RRB- that if the dialogue begins in some state then it is eventually true along some execution path that the user can perform a particular action that results in the goal state always being achieved in the next state . 5.8 Reversibility Question : Can the effect of a given action be reversed in one action ? This is a version of undo at the dialogue level . A user may wish to reverse the effect of an action by getting back to the same choice of actions at the previous stage . Note that without application semantics included in the dialogue model , this property does not ensure that the effect on the system is reversed . Template : It is always true -LRB- at every point along every possible execution path -RRB- that in a certain action is performed in a certain state , then that original state can be reached in the subsequent state by some action . 5.9 State floatability Question : Can a user go from one state to another without entering some undesired state . It might be undesirable to have to go through some states of the dialogue to reach some goal state . For example , we would not want to have to turn off the photocopier in order to reset the default settings . Template : It is always true -LRB- at every point along every possible execution path -RRB- that if you start in some state you can get to another state without entering an undesired state first 6 . Discussion Using advanced model checking technology , we have a computationally tractable framework in which to verify certain reachability properties of a finite state dialogue model . Coupled with the simulation capability of the tabular representation , we now have a dialogue development model that supports both validation and verification exercises . There are several points that need to be addressed at this point . This work represents a very pleasing synergy between HCI and Software Engineering , but there are some problems with this approach . There is an underlying assumption in the Action Simulator work that designers find it easy to formu - it easy to simulate the dialogue . As Monk and Curry have explained , this supports the validation task between a set of real world scenarios and the formal dialogue model . 4 . Model checking with SMV We have already stated that PPS is formally equivalent to a finite state representation of a dialogue . Automated verification of finite state machines is a relatively well-researched area in formal methods of software engineering -LRB- see -LSB- 2 -RSB- for a summary -RRB- . Clarke leads a group at Carnegie Mellon University that have been looking at the use of temporal logic and finite state model checking , mainly to verify properties in hardware systems . There have been attempts to apply this work in model checking to requirements specifications of software systems -LSB- 3 -RSB- . To apply model checking , one needs to transform the system to be verified into an appropriate structure that the model checking tool can accept . Wang and Abowd -LSB- 15 -RSB- have demonstrated how a mechanical translation from the tabular specification of dialogue -LRB- and more generally , any PPS description -RRB- can be represented in SMV for subsequent verification . Once a model is encoded , a designer can specify certain properties as branching-time temporal logic expressions that need to be verified . Figure 3 shows a simple example of a state machine and the corresponding graph of execution paths that begin at state S0 . This graph is referred to as the computation tree , and properties that are to be verified over this graph are expressed in the Computation Tree Logic -LRB- or CTL -RRB- . A CTL expression indicates a predicate over the state of the system and the scope over which that property should hold1 . For example , with the photocopier example , we could form the predicate ? Copier = Copying ? to check whether the copier is in the copying state . All normal first-order logical connectives can be used to formulate these predicates -LRB- and , or , not , implication -RRB- . The scope of the CTL expressions is best S0 S1 S2 S0 S1 S2 S0 S1 S0 S2 S1 ... ... ... Figure 3 . A state transition network and the corresponding execution tree understood by looking at the computation tree in Figure 3 . From any point -LRB- node -RRB- in the graph , say S0 , the scope for a property can indicate that all branches must satisfy the property , or only one branch must satisfy the property . For any given branch , we also indicate whether the property must hold along the entire path or only at one point in the path or all the way along the path up to a certain point . Together , these CTL expressions can be used to express a wide variety of properties , some of which represent interesting dialogue properties , as we will demonstrate . Colloquially , we can express properties of the form : ? a property always holds everywhere ? a property holds inevitably or unavoidably -LRB- at some point along all branches -RRB- ? a property possibly holds -LRB- at some point along some branch -RRB- ? a property must/may holds at the next step The real value to doing this translation from the tabular specification into SMV is that these properties can be checked rather efficiently for very large state spaces -LSB- 4 -RSB- . 5 . Dialogue properties In this section , we outline the set of dialogue properties that can be expressed in CTL and , therefore , are amenable to automated verification . For each property , we will provide a high level question that characterizes the property , a brief justification for the property as an important dialogue property and a -LRB- natural language -RRB- template for the property that can be verified in SMV . Further details on these properties and some others are contained in -LSB- 15 -RSB- . 5.1 Rule set connectedness Question : From an initial state , can an action be enabled ? We assume that events are introduced into the dialogue model for a purpose . If some action can never be enabled -LRB- its pre-condition never matches the current state regardless of execution path -RRB- , then there is a problem . Template : For a given action , the precondition for that action holds at some point along some execution path 5.2 Deadlock freedom Question : From an initial state , is it true that the dialogue will never get into a state in which no actions can be taken ? We wish to avoid situations in which no actions can occur , for obvious reasons 1 . For the purposes of this paper , we will not show the exact syntax of CTL , as we feel that it?s idiosyncracies do not enhance the understanding . The interested reader is directed to -LSB- 15 -RSB- for a detailed description of properties discussed in this paper in the CTL language . PPS 's are amenable to automatic analysis . Olsen , Monk & Curry -LSB- 13 -RSB- describe seven reachability questions that can be asked of a PPS and some algorithms for answering them . That work defines a theoretical framework for expressing the reachability properties , but no computational framework for verifying them . We use those reachability properties as input for the computational model of SMV . In summary , there are various ways of specifying a dialogue model . Many of them can be thought of as state machines in which actions from the user or the application cause changes to some current dialogue state that determines what actions can have effect at any given point . There are two practical problems in using this kind of model in design . One is how one specifies the states and transition to build the model , the other is how one copes with the computational problem of analyzing them . Though Olsen , Monk and Curry outline a theoretical framework for expressing various dialogue reachability properties , they provide no computational framework for verifying those properties . In the Section 3 we discuss a solution to the description problem using PPS with a tabular interface . In Section 4 we discuss how model checking with SMV provides an adequate computational framework . 3 . A tabular interface to PPS Monk & Curry -LSB- 9 -RSB- describe a tabular interface to PPS , called the Action Simulator1 . This is illustrated in Table 1Columns are headed with PPS field names -LRB- Ready , Copier etc. -RRB- . Directly under these labels is the current state . Each production rule takes two rows in the table . The name of the action and the pre-conditions appear in the first row and the post-conditions in the second row . For pre-conditions , a blank cell means that any value for that field will match . For post-conditions , a blank cell means that that field is unchanged by the production . In Table 1 , actions currently available because their pre-conditions match the current state , are shaded . The use of incomplete condition vectors -LRB- blank table cells -RRB- to describe a set of states is the key to the expressiveness of a PPS specification . For a large system , the number of rules needed is much less than the number of transitions needed in a typical state machine . Using this interface it is possible to specify PPS style dialogue models very succinctly . The tabular format for the dialogue specification also makes 1 . Demonstration copies of the Action Simulator using the widely available spreadsheet Excel -LRB- Microsoft -RRB- is available by FTP by e-mailing Andrew Monk . Ready Copier Copies Toner Density Current State OK Copying OneCopy Normal ID_accepted noOK OK OneCopy Normal Cancel_ID OK notOK Req_mult_copies OK notCopying OneCopy Multiple ResetCopies OK notCopying Multiple OneCopy Darker OK Normal Dark CancelDarker OK Dark Normal Copy OK notCopying Copying FinishedCopying OK Copying notCopying Table 1 . A PPS dialogue model specified in tabular format 2 . Approaches to dialogue specification The concept of a dialogue model comes from work on separable user interfaces or user interface management systems -LRB- UIMS -RRB- . The Seeheim model -LSB- 7 -RSB- , for example , has three major components : presentation , dialogue control and application interface model . The use of STNs to describe humancomputer dialogue goes back to Newman 's -LSB- 11 -RSB- work in this area . More recent work such as Hill 's -LSB- 8 -RSB- influential event response language -LRB- ERL -RRB- also use transitions within a state space , triggered by user actions , to describe human-computer dialogue . Olsen -LSB- 12 -RSB- describes a production system notation that gets around some of the problems of state explosion described above . A propositional production system -LRB- PPS -RRB- makes it easier to enumerate states and state transitions by factoring the state space into fields of mutually exclusive conditions . A PPS description is a generalization of ERL and is formally equivalent to finite state machines . Thus PPSs have all the general characteristics needed in a notation for describing dialogue models . They are also the basis of the tabular interface to be described in the next section and so will be described in some detail here . We will use the example of an interface to a photocopier , also used in Section 3 , to illustrate this description . As an example of the way PPS describes state , imagine that the copier can be : ready or not_ready , copying or not_copying , with the setting single copies with the settings single copy or multiple copies , normal toner density or darker . These would be expressed as fields of mutually exclusive conditions . Field Ready -LRB- OK , notOK -RRB- Field Copier -LRB- Copying , notCopying -RRB- Field Copies -LRB- OneCopy , Multiple -RRB- Field Toner_Density -LRB- Normal , Darker -RRB- Combining these fields results in a state space of 16 possible states . In addition to these standard fields there are special fields , for example user actions such as requesting multiple copies , darker toner etc. can be gathered together in an input field . Input Field User -LRB- Cancel_ID , Req_mult_copies , Reset_copies , Darker , CancelDarker , Copy -RRB- Olsen also discusses the use of actions coming from the application . ID_accepted might be a message from some physical key mechanism that allows users to identify themselves as bone fide users of the copier . Finished_copying is a message from the copier mechanism . These are termed semantic fields . Semantic Field Copier -LRB- ID_accepted , Finished_copying -RRB- The dialogue is specified as a number of production rules using a pre - and post-condition semantics . For example , the rule cancel_ID , OK - > notOK , will ? fire ? when the two pre-conditions are satisfied by the current dialogue state and will result in the state satisfying the post-condition . If we are in the state -LRB- OK , notCopying , OneCopy , Normal -RRB- , then pre-condition for the above rule is satisfied if the user performs the action cancel_ID , resulting in a new state -LRB- notOK , notCopying , OneCopy , Normal -RRB- , Much of Olsen 's work is concerned with details necessary to make PPSs execute . These details are not relevant here as a dialogue model is only concerned with what actions -LRB- input and semantic fields in Olsen 's terms -RRB- are available at any point and how this changes were an action to occur . This is neatly compactly by the pre-conditions and post-conditions to a rule . To follow a path through the state space one repeats the cycle : 1 . compute what actions are available given the current state , i.e. , what rules have all their pre-conditions satisfied bar a semantic or input condition ; 2 . select one action from amongst these 3 . change the current state according to the post-conditions of the relevant rule -LRB- the possibility that there may be more than one rule available for the same action is discussed later -RRB- . Olsen does not distinguish between events and states . Thus though input fields and semantic fields can not appear on the right hand side of a rule because they are external to the dialogue model , they are represented by conditions as with any other field . At execution each user input has to be presented and cancelled in turn . For our purposes it is convenient to treat any condition that can not be changed by the dialogue model as an event , whether it comes from the user , the world or the application . Semantic actions have mainly to do with details of implementation but may need to be considered as they define what conditions are important in terms of the user 's task . For example , because of its side effect we know that setting notOK defines the end of the user 's interaction with the copier . Thus one of the checks we need to make is that one can get to this state from any other that is reachable from the start state . recorder may be in and eight actions that a user may take , that is , pressing one of seven buttons or inserting a tape . A state transition network -LRB- STN -RRB- was then built by specifying for each state what new state , if any , resulted when each of these actions was taken . The papers cited are concerned with using this STN to generate correct manuals for the device . Their help system analyzes the STN to answer questions such as `` how do I get from record-pause to off-tapeout in the smallest number of steps ? '' However , it is also possible to analyze the STN to answer more general questions . One may rank states in terms of their distance from the start state -LRB- off-tape-out -RRB- i.e. , count the minimum number of transitions/actions required to get from the start state to each other state . One can then verify that the commonest states are most easily reachable . Similarly , one can identify transitions that require more than say two actions to reverse , to verify that users can in principle undo their mistakes . All these questions concern reachability , that is whether or how easily one can get from one dialogue state to another . The main contribution of this paper is to describe another technique for automated analysis of reachability that can be carried out on a dialogue model . But first the problem of scale must be addressed . Compared with most human-computer interfaces , 28 states is very small . Imagine one is specifying the dialogue for changing the appearance of some selected text in a word processor . The selected text may be in one of 10 fonts , in one of 8 sizes and the styles italic , bold and underline can be applied in any combination . This amounts to 10 x 8 x 3 = 240 dialogue states and this is only a small part of the func - Real world Dialogue Figure 1 . Dialogue development requirements Model synthesis validation verification run-time generation tionality of the word processor . This is not a problem for the user because these states are very visible and the dialogue is very flat , i.e. , most of the transitions are available all of the time . It is a problem for a designer wishing to analyze a dialogue specification as described above . First , simply enumerating all the dialogue states and the transitions between them is potentially very tedious . Second , analyzing very large STNs is computationally expensive and may not be practical . In the next section we examine some of the solutions that have been suggested for the descriptive problem . We then go on in the rest of the paper to describe a solution which addresses both the descriptive and the analytic problem . Our approach , depicted in Figure 2 , is a marriage of two separate techniques . The first is a dialogue simulation tool proposed by Monk and Curry called the Action Simulator -LSB- 9 -RSB- . The second technique is automated model checking with the Symbolic Model Verifier -LRB- SMV -RRB- , developed at Carnegie Mellon by Clarke and colleagues -LSB- 5 -RSB- , -LSB- 10 -RSB- . The Action Simulator is an attempt to provide a reasonably compact dialogue representation in a comprehensible form . SMV provides a computationally feasible approach for the verification of large state machines . Real world Action Figure 2 . Our dialogue development method requirements Simulator synthesis validation Symbolic verification Model Verifier translation Abstract A number of notations exist by which a designer can specify the behavior of a human-computer interface in relatively formal terms . In this paper we show how many of the dialogue specifications described using these notations are amenable to automated analysis to detect potential problems such as user actions that are never enabled or have effects that are hard to reverse . In many situations , a dialogue specification can be thought of as a finite state machine in which the transition between states is signalled as an event from the user or system . The trouble with this state transition model is that states quickly multiply presenting two problems to the analyst : -LRB- i -RRB- how to easily describe all of the possible dialogue states and state transitions ; and -LRB- ii -RRB- how to analyze a very large STN . This paper reviews possible solutions to both of these problems . A tabular interface to Olsen?s Propositional Production System is described and goes some way towards solving the descriptive problem . This representation is also useful for simulating requirements scenarios in a validation exercise . For the analytic problem , we make use of finite state model checking technology that allows for automated analysis of very large state machines . We demonstrate how eight categories of dialogue verification properties can be analyzed with this approach . Together , dialogue simulation and automated verification leads to a more complete analytic framework for dialogue development . 1 . Introduction When designing a human-computer interface , thought must be given to decide which actions are made available to a user at any given point . For example , on a time-sharing system only minimal functionality should be available until the user has successfully logged in . Even in a relatively modeless user interface , such as a modern word processor , there are actions that are only available to a user when some specific state has been achieved . Specifying these constraints describes an important aspect of the behavior of the user interface . Such a description is a dialogue model . In this paper , we are concerned with the development of effective techniques to support the design and analysis of a dialogue model . The design of any model is an incremental process . The designers have coarse ideas at first . They try out these ideas and refine them until a satisfactory model is obtained . A model may take the form of natural language , a storyboard , an executable prototype , or a formal specification . In our work , we emphasize a formal dialogue model , but whatever form the model takes , a good one is : ? easy to create and modify ; ? easy to understand with a meaning easily communicated to others ; ? readily analyzable to determine its properties ; ? integrable with other design tasks . Figure 1 depicts the activities involved in dialogue model development . We begin with a real world situation that places constraints on the dialogue to be developed . From these real world requirements , the designer must synthesize the dialogue model and validate that it meets those requirements . The designer must analyze the dialogue for problems , such as the existence of user actions that are never enabled or have effects that are hard to reverse . Verification checks the dialogue model for these kinds of internal consistencies . Violation requires the designer to modify the dialogue model . Finally , a good dialogue model can then be used to help generate run-time behavior . We are not concerned in this paper with the generation of run-time behavior , as this area is already well established . A seminal example of a dialogue model is provided by Addison & Thimbleby -LSB- 1 -RSB- , -LSB- 14 -RSB- . Their analysis of the interface to a video recorder describes 28 states that the video A formal technique for automated dialogue development Gregory D. Abowd College of Computing Georgia Institute of Technology Atlanta , GA 30332-0280 abowd@cc.gatech.edu Hung-Ming Wang Transarc Corporation Pittsburgh , PA 15219 mwang@transarc.com Andrew F. Monk Department of Psychology University of York Heslington , YORK YO1 5DD , U.K. am1@unix.york.ac.uk Paper to appear in the proceedings of the First Symposium on Designing Interactive Systems ? DIS ? 95 , Ann Arbor , MI , August 1995 .

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

automated verification
formal methods
model checking
simulation