formal architectural abstractions for interactive software

Int. J. Human—Computer Studies (1998) 49, 675—715Article No. hc980223

Formal architectural abstractionsfor interactive software

PANOS MARKOPOULOS, PETER JOHNSON AND JON ROWSON

Department of Computer Science, Queen Mary and Westfield College, University of London,Mile End Road, London E1 4NS, UK. e-mail:markop, pete, [email protected]

(Received 30 September 1997 and accepted in revised from 25 June 1998)

This paper discusses formal interactor models, a class of abstractions for modelling userinterface software that incorporate elements of its structure. The abstraction—dis-play—controller (ADC) interactor model is one such abstraction which draws on researchinto user interface architectures and on earlier approaches to the formal specification ofuser interfaces. The ADC interactor model is specified formally using the LOTOSspecification language. As a concept and as a representation scheme the ADC interactormodel applies both to the user interface as a whole and also to its components. Thisproperty is preserved when interactors are combined to describe more complex entitiesor, conversely, when an interactor is decomposed into smaller-scale interactors. Thepaper includes a discussion of the ADC model and its use for the verification ofuser-interface software. ( 1998 Academic Press

1. Introduction

This paper investigates the application of formal methods for the design, specificationand verification of interactive systems. For many, the formal specification of the userinterface in an over-formalization (e.g. Bowen & Hinchey, 1995). Research in theaplication of formal methods to the study of human-computer interaction has challengedthis contention producing elegant abstractions of usability related properties (e.g. seeDix, (1991). It is argued hereby that the practical application of formal techniquesrequires that interactive systems be modelled at an intermediate level of abstractionwhich is relevant to the concerns of the software developer. Such models are genericallytermed interactor models and they are examined here as formal architectural abstrac-tions for interactive software. This paper provides an exposition of an interactor modeland of its properties, it examines some of the trade-offs involved in defining a formalarchitectural model, the limitations of the approach and the most pressing researchquestions which arise for the field of research.

The interactor model discussed in this paper builds on research into user-interfacearchitectures and on earlier approaches to the formal specification of user interfaces.Section 2 provides an overview of the related work. Research in software architectureshas provided a wealth of abstractions for user-interface software, which have been testedin practice for their validity and their relevance to the concerns of the software develop-ers. Research in the application of formal methods to the study of human—computer

1071-5819/98/110675#41 $30.00/0 ( 1998 Academic Press

676 P. MARKOPOULOS E¹ A¸.

interaction is presented selectively, illustrating a progression from abstract models ofinteractive systems to interactor models. Abstract models of interactive systems aremodels with minimal commitment to the internal structure of interactive systems whichafford expressions of design intuitions pertaining to their usability. It has been animportant objective of the research reported in this paper to attain formulations of thesedesign intuitions at the more concrete level of description supported by interactors.

Section 3 presents the abstraction—display—controller (ADC) interactor modeland its formal interpretation in LOTOS. It is argued that the specification of ADCinteractors in LOTOS. It is argued that the specification of ADC interactors in LOTOSencourages the modularity and re-use of specification components. A summary of sometheoretical results regarding the composition of complex interface specifications fromelementary interactors illustrate how ADC formalizes desirable properties of architec-tural models.

Section 4 discusses the verification of user-interface software in the framework of theADC interactor covering a wide range of topics: usability-related properties derivingfrom research in abstract models, dialogue verification and, finally, a conceptual andformal framework for assessing user interfaces against task specifications. The finalsection of the paper takes a critical view on this research and discusses what further stepsmust be taken to ensure that interactor models contribute usefully to the design ofinteractive systems.

2. Models of user interface software

2.1. ARCHITECTURES FOR USER-INTERFACE SOFTWARE

‘‘...The architecture of a software system defines that system in terms of computationalcomponents and interactions among those components...’’ (Shaw & Garlan, 1996).

Architectural styles (Shaw & Garlan 1996) or models (Cockton, 1990) are abstractions ofarchitectures which embody design knowledge pertaining to the structure of a particularclass of systems and, ideally, they ‘‘package’’ this knowledge and encourage its re-use.They are generic descriptions which may be instantiated to derive concrete architectures.This instantiation may be supported by software tools, in which case they are implemen-tation architecture models, of quite simply, it may be supported by a set of heuristics orconceptual aids for designing an architecture or directly a software system, in which casethey are conceptual architecture models. This section examines software architecturemodels specific to interactive systems.

Following the influential Seeheim model (Green, 1985), most software architectures forinteractive systems support the functional partitioning of interactive software, whichdistinguishes three different components: the application-specific functionality, the dia-logue structure of interaction and the presentation of the interface. These componentsmay be separated into layers, as was the case with the Seeheim model, or they may beconstituent components for objects in an object-based architecture. Object-basedarchitectures model the interface software as a composition of cooperating objects.This has several advantages concerning iterative design, support for distributed applica-tions and support for multi-thread dialogues. The model-view-controller (MVC) model

FORMAL ARCHITECTURAL ABSTRACTIONS 677

(Krasner & Pope, 1988) is such as implementation architecture model which emphasizesthe independence of its model from the view-controller pairs. A single model may havemany view-controller pairs as ‘‘dependants’’, as shown in Figure 1. The controllerhandles user input and modifies its model via a method call. The model may receive inputfrom any other object in the system via a method call. When its value changes it notifiesall its dependants that it has changed and it is up to them to update themselvesaccordingly.

An influential conceptual architecture model is the presentation-abstraction-control-ler (PAC) model by Coutaz (1987), which structures an interactive system as a hierarchi-cal composition of PAC triads; the hierarchical organization of these triads is illustratedin Figure 2. The controller component maintains the consistency between its corres-ponding presentation and abstraction, implements data flow and data transformationbetween PAC triads and specifies dialogue information. Recent developments of PAChave incorporated it within a layered architecture for multimodal systems and alsowithin a distributed systems architecture for modelling multi-user applications (Coutaz,1997).

The abstraction-link-view model (ALV) is an implementation architecture modelsupported by the Rendezvous user-interface management system (Hill, Brinck, Rohall,Patterson & Wilner, 1994). Multiple view-objects may be linked to the same abstraction-object (Figure 3) and multiple abstraction-objects may be accessed by the same view-object. The ALV model supports distinct composition hierarchies for the abstraction andthe view-objects. The view hierarchy resembles closely the geometrical containmenthierarchy of the displayed objects. Links maintain consistency between the values held inthe objects and maintain constraints between the tree structures (Figure 3). The linksmay also be organized in a tree structure themselves. Inter-object communication is

FIGURE 1. The MVC architecture (Krasner & Pope; 1988): A model and two view-controller pairs.Change notification Method call.

FIGURE 2. The PAC model (Coutaz, 1987) structures the interface system as a composition of PAC agents, butdoes not prescribe a particular communication and control mechanism. —— Translation of information;

Translate information or maintain consistency.

FIGURE 3. Composition of interactive objects in ALV: abstraction and view-objects are composed hierarchi-cally and links are drawn across the two composition hierarchies (Hill et al., 1994). — Part-of; link.


implicitly specified in the constraints. This can be contrasted with the MVC architecture,where each view-controller notifies its model of changes and each model keeps a list of itsdependants.

Coutaz (1997) identifies the need to formalize user-interface architecture to helpcommunicate clearly definition of concepts that normally rely on intuitions and sharedknowledge between software engineers. This papers takes a symmetric, but consistent,point of view: formal abstractions of interactive software must model the softwarearchitecture to render the formal specification and verification of interactive softwarea valid and useful tool for software designers. However, the ADC interactor discussedin the later sections does not formalize any particular software architecture,thus avoiding platform or language-dependent elements of these models. Rather,ADC formalizes some common traits of the architectures discussed here resultingin a more abstract model: ADC supports an object-based description of the inter-active system at an architectural level of detail, it defines objects with a similarfunctionality partitioning as the architectures discussed in this section and it formalizesthe composition of interactors within a process algebraic framework. The purpose ofADC is also very different to the architectural models discussed above. ADC is primarilydescriptive; it describes how user-interface software is structured rather than constrainhow it should be structured and it is intended for the analysis of the specified interactivesystem.

2.2. THE ROLE OF FORMALITY

The motivation for using formal specifications interactive system design is to opera-tionalize scientific and craft knowledge about human—computer interaction. This mo-tivation has remained a constant throughout the development of the research field, butthe perceived role of formality has shifted significantly in the last 10 years. Traditionally,the envisaged role of a formal method is to describe the essence of a system functionwithout premature commitment to implementation considerations. The underlyingphilosophy is that by sound engineering principles and rigorous reasoning, usable andeffective systems may be designed by an almost mechanical process of refinement ortransformation of specification (Harrison & Dix, 1990). Took (1990) suggests thatdesign should be specification-centered as opposed to specification-driven. Duke andHarrison (1994) refine this view and characterize the role of the specification as


integrative: it brings together contributions originating from different perspectives andallows the developer to check their consistency and, possibly, to identify issues whichrequire further consideration. However, they also point out that usability claims cannotbe made within a formal system along; the use of formal properties in rigorous softwaredevelopment does not guarantee that the result will be a usable system. Claims aboutusability must be validated by means other than formal verification. Further, theyexperienced difficulty in trying to communicate formal specifications to designers notaccustomed to formal methods.

Research in formal methods is increasingly leaning towards the view that formalmethods are a supplementary and not a replacement for techniques and methodspractised is software development (Bowen & Stavridou, 1993). Rather than dictatingnew methods and processes for software development formal methods researchersshould attempt to find out how their methods and tools may help within currentlyestablished practice (Holloway & Butler, 1996). Consequently, the design of an interac-tive system should not be driven by a formal method but may use it as a means ofrepresenting designs and assessing decisions. A formal specification notation is goodfor a specific job and for a well-defined scope of the problem domain. Not all designdecisions but, in fact, just a few may be based on the formal specification. Here, as inMarkopoulos (1997), formal methods are explored as a potentially useful toolfor the design of user interfaces which should not constrain the design process. Fields,Merriam and Dearden (1997) take this argument a step further suggesting thatinteractive systems design need not centre around the use of formal models. Rather, theysuggest that models of system, user, domain, etc., should be recruited on a per need basis,and can be both formal and informal, complementing each other without necessarilybeing integrated by reference to a common formal, conceptual or methodologicalframework.

This perception of the role of formality suggests the type of research pursued. Formalrefinement is not an important concern in user-interface design. Rather, to verifyinterface specifications and to reduce the cost of formalization are important priorities.Significant gains can be expected by the use of a standard specification language, existingtool support, by the modularity and re-use of specifications. Also, an important consid-eration is to relate interface specification to other modelling approaches in human—computer interaction.

2.3. ABSTRACT MODELS OF INTERACTIVE SYSTEMS

Generative user engineering principles (GUEPS), proposed by Thimbleby (1984), aimed tocapture design heuristics of principles for the design of usable interactive systems, toconvey them to practitioners through both a formal and an informal description and touse them generatively as design constraints. Canonical instances of these principles arepredictability, i.e. the possibility to infer the future behaviour of an interative computersystem from its current states, observability, the possibility to infer the internal workingsof an interactive system by observing its display, etc. Abstract system models of interac-tive systems (for short abstract models), were developed in an effort to formalize GUEPSin a manner general to all interative systems. A well-known and documented abstractmodel is the PIE model (Dix, 1991) discussed below in brief.


The PIE model describes an interactive system as a ‘‘black box’’ to which input is givenand of which output may be observed. The model relates user program P, which aresequences a commands, to the effects E they have, via an interpretation function I :PPE(see Figure 4). The effect may refer to the display, the entire informtion managed by theinteractive system, etc. Properties of interaction are expressed abstractly in terms ofrelations between these components, without referring to any internal representation ofthe system. The PIE model affords concise definitions of concepts such as the predicta-bility of the system, reachability properties, undoing commands, non-determinism, etc.For example, a system can be characterized as predictable if for any two programs p andq that have the same effect, then also their extension by the same program r will have thesame effect:

∀p, q, r: P D I(p)"I(q) ) I(pr)"I(qr).

PIE has been extended to the red-PIE model to represent the relationship between thedisplay (what the user sees) and the result (what the user wants to achieve throughinteracting with the system). The red-PIE model includes the definition of a mappingresult from the effect space to the result space R and a mapping display to the displayspace D (see Figure 4). A system is called observable if two programs that produceidentical displays also produce identical results:

∀p, q:P Ddisplay (I (p))"display(I(q)) ) result (I(p))"result(I(q)).

Observability describes the theoretical feasibility of observing the state of system ratherthan the user’s ability to perceive and process this information. This caveat applies alsoto predictability and to similar expressions of usability-related system properties dis-cussed throughout this paper.

While the PIE family of models has exercised significant influence on laterformal models of interactive systems it is very hard to apply in practice. PIE gives anunstructured description of the interface which does not portray adequately the structureof the interaction, or a constructive definition of the state of the user interface.The directedness of PIE does not portray how the interpretation function I issensitive to the display contents D, which is an essential aspect of graphical userinterfaces. Further, as is pointed out by Dix and Abowd (1996), PIE is not compositional,i.e. it does not help write specifications of interactive systems as compositions ofsmaller PIE descriptions. The need arises for a constructive model that will allow thedescription of the user interface as a composition of formally specified autonomous units.This need has prompted the development of the interactor models discussed in the nextsection.

FIGURE 4. The PIE and red-PIE models (Dix, 1991). Arrows represent mappings between sets.


2.4. THE CONCEPT OF AN INTERACTOR

Interactors are abstractions which are used to model interative systems as compositionsof independent entities. Faconti (1993) defines an interactor as:

‘‘...an entity of an interactive system capable of reacting to external stimuli; it is capable ofboth input and output by translating data from a higher level of abstraction to a lower levelof abstraction and vice versa.’’

This definition considers the user interface as a layered composition of interactors whichmediates between a user and the functional core of an interactive system. Each layer ofinteractors (or a single interactor) distinguishes two levels of abstraction for the dataflowing between the user and the functional core. The input functionality of theinteractor is to raise the abstraction level of the data is receives and the reverse holds foroutput which is communicated to the user. The distinction between interactors andabstract models is the constructivity which helps build complex specifications as com-positions of smaller scale ones. An interactor model becomes a useful engineering toolonce it is easy to use, describe and understand, if it encourages the systematic re-use ofspecifications and if it provides sufficient analytical leverage for the verification ofinteractive system designs.

The term interactor has been used also to refer to implementation constructs by Myers(1990). In the context of user-interface software architecture, the term interactor refers toobjects which are characterized by a display function and, in general, support both inputand output. While they did not use the term ‘‘interactor’’, the object triples of the MVC(Krasner & Pope, 1988) and the ALV (Hill et al., 1994) models discussed above supportthe notion of an interactors as an implementation construct. The PAC model (Coutaz,1987) supports this notion at a conceptual level.

Dearden and Harrison (1997) describe the trade-off among the operationality ofa model, its expressiveness and its re-usability. They defined operationality as the degreeto which a model supports the application of the design knowledge it encapsultes andexpressiveness as its ability to support the expression of salient interaction charac-teristics. They relate this trade-off to the abstraction level of a formal model. Abstractmodels, they argue, are not sufficiently expressive although they are re-usuable preciselybecause of their abstractness. Their application requires craft knowledge on the part ofthe designer in choosing appropriate abstractions and in deciding the appropriate set ofprinciples to apply to a system model. Thus, argue Dearden and Harrison, PIE modelsare not operational. Specification of a particular application are not re-usable althoughthey can be operational and expressive. Dearden and Harrison (1997) recommendmodels at an intermediate abstraction level which are generic for a particular class ofsystems. Their model of interactive case memories is such a model. By the same tokeninteractor models are seen here as generic abstractions for a whole range of systems andthe exposition below concerns mostly graphical user interface. Like abstract modelsinteractors are expressive and re-usable. The architectural nature of the model makes thechoice of abstractions, more straight-forward than in abstract models: interactors corres-pond directly to the architectural entities they model. Sections 3 and 4 argue that theADC model affords the expressions of interaction properties and facilitates their applica-tion for constructive and analytical use.


2.5. DIALOGUE VERIFICATION

Conventionally the term dialogue is interpreted as the syntactic structure of the interac-tion that a given system supports. Examples of dialogue properties are: deadlockfreedom (the interface does not terminate because of an inconsistent dialoguespecification), completeness (all intended and plausible interactions of the user withthe interface included in some requirements specification are specified behaviours ofthe UI), determinism (a user action in a given context has only one possible outcome)and general reachability (the possibility and ease of reacting a target state, or set ofstates, from an initials state, or set of states). In object-based interface architectures,the dialogue is encoded partly in each object and partly in the way the objects arecomposed together. This holds for interactor-based specifications too so the questionthat arises is when and how can interactor specifications be used as dialogue specifi-cations.

Results concerning the automatic verification of dialogue properties are surprisinglyscarce. Olsen, Monk and Curry (1995) describe techniques for dialogue verificationbut have not implemented the required verification tools. Probably, the most powerfuland practically applicable approach to the verification of formally specified dialogueis reported by Paterno (1993, 1997), who makes use of existing model-checkingtechnology (Bouali, Gnesi & Larosa 1994). In the framework of the interactor model ofPaterno and Faconti (1992), user interfaces are specified in LOTOS and dialogueproperties are specified using an action-based temporal logic. When it is feasible,theoretically and practically, a finite interpretation of the LOTOS specification isproduced and the dialogue properties are verified against this interpretation with the aidof a model checking tools. The modeller must classify interaction events, for example, asinput, output, error messages, task completion events, etc., and these ‘‘event-classdescriptions’’ can be used to specify generic dialogue properties. An example of sucha property of eventual feedback, i.e. a user input action shall (eventually) generatefeedback:

AG[user—input] E (ttttº

outputtt).

This expression can be interpreted as follows. Always (operator AG), from the statefollowing a user input, there exists (operator E) a sequence of events which lead up to anevent output. This sequence of events is specified by the formula tt

ttº

065165tt. For

example, if the user input is a mouse button click and the output is highlighting of theinteractor, then AG [click] E (tt

ttº

highlighttt) verifies that the specified interactor gives

feedback eventually when it is clicked. The designer must instantitate the generic formulain this manner and use model checking tools to verify that a design specification verifiesit. Another interesting property is that the press of a button will not be ignored, i.e. anappropriate event notify will be sent to the application AG [user—input] E (tt

ttunotify

tt).A practical limitation of this approach is that the designer needs an in-depth understand-ing of the LOTOS specification of the user interface and the temporal logic formulationof the dialogue properties. Section 4 examines some alternatives, but the main contri-bution of interactors is that they classify interaction events, helping actualize genericdialogue specifications in terms of the interface architecture and thus they guide thedesigner in expressing and applying dialogue requirements.


3. The ADC interactor model

3.1. INFORMAL DESCRIPTION

An ADC interactor holds two kinds of data which are distinguished by whether they aredisplayed or not. Display data is considered to be output either directly to the screen orindirectly through other interactors. Abstraction data is sustained by the interactor toprovide input to the application or to other interactors. A dedicated component, calledthe abstraction-display unit (ADU), encapsulates these state-components and the opera-tions to read and modify them. Operations are effected through interactions on the gatesof the ADU. Gates are architectural elements which ‘‘localize’’ interactions within theenvironment of the interactor. The ADU is ‘‘neutral’’ with respect to dialogue, i.e. it isalways ready to receive input and to send output on all its gates. The actual dialogueof the ADC is modelled entirely within a separate component, called the controllerunit (CU).

Figure 5 illustrates an ADC interactor with its ADU and CU components. It isillustrated as a barrel-shaped node. Its top arch is called that abstraction side, its bottomarch the display side and the vertical sides are called the controller sides. Gates are shownas arrows when corresponding interactions communicate data or as lines when no datacommunication takes place. Interactions on the gates of the ADU are enabled/disabledby the CU. The direction (inwards or outwards pointing arrow) and the side of a gate inthe diagram illustrate its role. The role can be dinp for graphical input, i.e. input whosemeaning is sensitive to the display content, dout for graphical output, ainp for non-graphical input, e.g. some value sent by the application or some other interactor, aout fornon-graphical output, e.g. some value sent from the interactor to the application or to

FIGURE 5. The internal structure of an interactor.


another interactor and c for control interactions. Roles classify gates with respect to theirpurpose, so that they are treated accordingly in the formal specification or in animplementation. For example, an interaction on a dout gate will update the display statebut should not affect the abstraction state. A graphical input, e.g. from a pointing device,will have an effect on both the display state—because of some instantaneous feedback—and to the abstraction state, e.g. by interpreting the effect of pointing.

A user interface can be modelled as a composition of interactors. For example, Figure6 shows a static list of strings which is displayed as a two-dimensional array ona window. Two slider interactors allow the displayed portion of the list to be scrolled intwo dimensions. Two slider interactors allow the displayed portion of the list to bescrolled in two dimensions. Each slider receives interactions and display coordinatesfrom its display side (notionally from a pointing device), provides feedback directly on itsdisplay and interprets its input to instruct the list interactor to scroll (suppose this isachieved by passing some integer value indicating the amount and the direction ofscrolling). The layout specification will describe that the sliders are adjacent to the rightand bottom edges of the list interactor. The dialogue specification must specify that theyare all ‘‘active’’ together and the sequencing of interactions across the three interactors,e.g. whether the position of the slider is updated before or after the contents of the list, etc.

Small-scale interactive components can themselves be thought of as interactors, e.g.the sliders above, buttons, menus, etc. The model applies to higher-level entities as well,in which case the abstraction level of input and output operations is correspondinglygreater. For example, an interactor can represent a text editor. An interaction by the usermay be, say, to select the name of a file to edit and the output may be an on-screenrepresentation of the file contents. The file selection may be supported by an interactorlike the scrollable list of Figure 6, but the text-editor can abstract away from this level ofdetail.

Clearly, the ADC model emphasizes the architectural elements of the interactor: itsgates, their role, their grouping to sides, the separate treatment of dialogue and datamodelling and the composition of interactors to form complex interface specifications.As mentioned already, there is an intentional similarity to the informally definedsoftware architectures discussed in Section 2. Compared to those ADC is more abstractin that it does not prescribe a particular configuration for composing interactors, e.g.a tree structure, and it abstracts away from the mechanism by which display and

FIGURE 6. A scrollable list as a composition of three interactors.


abstraction data are kept consistent within a single interactor. It is unwieldy to captureall diverse aspects of interface software within a single all-encompassing formal model,e.g. layout display content and properties, dialogue, etc. The formal interpretation of theADC interactor in the LOTOS formal specification language (ISO, 1989) is discussed inthe remainder of the paper. This formal model focusses on the architectural, the dialogeand the data flow aspects of the user interface.

3.2. FORMAL SPECIFICATION OF ADC INTERACTORS

In general, and ADC interactor is specified in LOTOS as a process formed by the parallelcomposition (denoted as D [2] D ) of processes ADU and CU:

process ADC [GcXGio]: noexit :"ADU [Gio] (a, ds, ds) D[Gio] DCU[GcXGio]

endproc

The ADU is a process which has three state parameters (listed in round brackets)modelling its abstraction, the next display and the current display respectively. The ADUinteracts with its environment through a set of input—output gates G

*0. Interactions on

these gates invoke operations to read or modify the state parameters. These operationsare specified in a dedicated data type, the abstraction-display data type (AD). ProcessCU specifies the temporal ordering of interactions on the gates of the interactor, i.e. itslocal dialogue. The CU synchronizes with the ADU at gates G

*0but also offers interac-

tions on a gate-set G#.

The signature for the generic data type AD is as follows:

type ad issortsabs, disp, dInpDta, aInpData, aOutData

opnsinput: dInpData, disp, abs P absecho: dInpData, disp, abs P disprender: disp, aInpData P dispreceive: abs, aInpData P absresult: abs P aOutData

endtype

The sorts abs and disp describe the state parameters, dInpData describes input arriving atthe display side (gate dinp), aInpData describes input arriving at the abstraction side (gateainp), and aOutData describes data which is sent to the ‘‘clients’’ of the interactor.Operations input and echo describe the interpretation of graphical input to update theabstraction and the display sorts of the interactor. Graphical input is given a specialtreatment because its interpretation is sensitive to the current content of the display. Thissensitivity is modelled syntactically by using the current display contents as an argumentof operations input and echo. Operations receive and render describe the interpretation ofnon-graphical input. Operation result is an interpretation of inquiry operation thatcalculates a value which will be sent to other interactors or to the functional core. An


abstract data type associated with a particular interactor will have custom identifiers forits sorts and operations. In general, the data type AD can have a variable number of sortsand for each sort a variable number of operations of the above categories, depending onthe gates and the sort of data communicated over a gate. Thus, for each sort of graphicalinput a pair of operations similar to input and echo have to be defined. The equationspart of the data type AD describe the relationship between the abstraction and thedisplay sorts and the semantics of the operations specified. The signature of AD definesfor all ADC interactors a classification of the data it manages and of the operations uponthe data. It is not necessary to specify an operation called ‘‘input’’, ‘‘echo’’, etc., in all datatypes associated with the interactors. Rather, there is a commitment that all operationshave the purpose and syntax of the operations defined here. This defines a consistentspecification style for the data type associated with all ADC interactors.

The operations of data type AD are linked to interactions by the ADU. At anyinstance the ADU offers a choice (denoted by the choice operator [ ]) between interac-tions on any of its gates. With each interaction, the ADU instantiates itself recursivelyand modifies its state parameters by applying the corresponding operations upon them.For brevity, in the specification extracts below ‘‘2’’ replaces a gate list where this isobvious from the context.

process ADU[dinp, dout, ainp, aout](a: abs, dc, ds: disp):noexit :"

dinp?x:dInpData; ADU [. . .] (input (x,ds, a), echo(x, ds, a), ds) []

dout!dc; ADU [ . . ] (a, dc, dc) []

ainp?x:aInpData; ADU[. . .] (receive(a, x), render (dc, x), ds) []

aout!result(a); ADU [. . . ] (a, dc, ds)

endproc

Process ADU has two state parameters holding values of sort disp. The parameter dsholds the current state of the display, i.e. the last value output on the display from gatedout. The parameter dc is the computed display which the interactor will output on thenext interaction on gate dout. The ADU does not necessarily output its most recentlycalculated display, so parameter ds is necessary to maintain a separate record of the valueof the display that is used to interpret all arriving user input. The ADU maps interactionson its gates to appropriate operations of the ADU, so that the operations correspond tothe role of each gate. For example, if there are several graphical input gates, e.g. press,click, point, then the ADU will apply for each input and echo operation to update theabstraction and the display. The CU can be any LOTOS process which synchroniseswith the ADU and which does not have any state parameters to read and store data.

The specification of these components is introduced here with the specification ofa simple slider. The slider is a canonical example for introducing a new model (see, forexample, Zave & Jackson, 1993) because it exhibits aspects of direct manipulation anda clear distinction between the abstraction and the display representations. Clearly, theslider esample is only meant to introduce the ADC model; the sections that followexamine the composition and the level of abstraction for modelling interactors, which areimportant issues for scaling up their use. The reader who is interested in larger scalespecification examples can refer to Markopoulos (1996, 1997) which report the spe-cification of the graphical interface to a small but significant multimedia application, asthe composition of 13 interactors.

FIGURE 7. The slider interactor and its illustration as an ADC interactor.


Figure 7 illustrates a typical slider interactor modelled as an ADC interactor. Theslider provides random access to an indexed set of data, e.g. a sequence of characters, orstatic images composing a movie. It is easier to specify sldr—ad in a modular fashion; theindex is specified as an abstract data type bounded»al and its graphical presentation isspecified by the data type sliderBar. These data types are specified in the appendix forcompleteness, and are combined by data type sldr—ad:

type sldr—ad is sliderBar, boundedVal

opns

input: pnt, sliderBar, boundValue P boundValue

echo: pnt, sliderBar, boundValue P sliderBar

render: sliderBar, rct P sliderBar

receive: boundValue, rct P boundValue

result: boundValue P Int

eqns

forall r:rct, p:pnt, sb: sliderBar, bv: boundValue

ofsort boundValue

receive(bv, r)*bv;ofsort sliderBar

echo (p, sb, bv)*changePnt (sb, p);

render (sb, r)*changeRect (sb, r);

ofsort Int

result (bv)"val(bv);

endtype

Here, operations receive and render specify the effect of resizing the enclosing window.Operation result specifies the extraction of an integer index from the bound»alueabstraction of this interactor. The process modelling the interactor slider is specified asfollows (where BV and SB are initial values for the state parameters):

process sldr[press, move, release, output, fromContainer, send]

:noexit :"

sldrADU[press, move, release, output, fromContainer, send]

(BV, SB, SB)

D[press, move, release, output, fromContainer, send]DsldrCU [press, move, release, output, fromContainer, send]

endproc


The ADU of the example has three input gates on the display side where press, move andrelease mouse events are input. These interactions are associated with the input ofa point, which is used as an argument by operations input and echo. The value returnedby operation result is output on gate send. The computed value of the display is outputon gate output.

process sldrADU[press, move, release, output, fromContainer, send]

(a: boundValue, dc, ds: sliderBar) : noexit :"

press?x:pnt; sldrADU[...] (input(x, ds, a), echo(x, ds, a), ds) []

move?x:pnt; sldrADU[...] (input(x, ds, a), echo(x, ds, a), ds) []

release?x:pnt; sldrADU[...] (input(x, ds, a), echo(x, ds, a), ds) []

send!result (a); sldrADU[...] (a, dc, ds), []

output!dc; sldrADU[...] (a, dc, dc), []

fromContainer?x:rct; sldrADU[...] (receive (a, x), render (dc, x), ds)

endproc

The CU for the interactor sldr is process sldrCº defined below by the synchronouscomposition of partial constraints of its behaviour. These are defined as distinct pro-cesses which describe the sequencing of interactions which effect clicking, dragging, inputand instant feedback, respectively:

process sldrCU[press, move, release, output, fromContainer, send] : noexit:"

((click[press, release] D D D drag[press, move, release])

D[move, release] DlazyInput [move, release, send])

Dpress, move, release, fromContainer, send] DinstantFeedback [press, move, release, output, fromContainer, send]

endproc

The example shows some of the advantages of using LOTOS. Process sldrCº is writtenas a parallel composition expression of processes which can be thought of as elementaryconstraints upon the interactions specified. Independent constraints are combined withthe interleaving operator which means that the corresponding temporal orderings arerelated by logical disjunction. Constraints upon the occurrence of interactions at a par-ticular gate are conjuncted by the synchronization of the corresponding processes overthat gate. The consistent use of this technique, is called the constaint oriented specificationstyle (Vissers, Scollo, van Sinderen & Brinksman, 1997) which affords increasedmodularity and re-usability of the specification components. The constraints combinedby sldrCº are specified as follows:

process click[press, release]: noexit :"

press?x:pnt; release?x:pnt; click[press, release]

endproc

process drag[press, move, release]: noexit :"

press?x:pnt; (repeat[move] ['release?x:pnt; drag[press, move, release])

endproc


process repeat[move]: noexit :"

move?x:pnt; repeat[move]

endproc

process lazyInput[move, release, send]: noexit :"

move?x:pnt; send?x:int; lazyInput[move, release, send] []

release?x:pnt; send?x:int; lazyInput [move, release, send]

endproc

proces instantFeedback [press, move, release, output, fromContainer,

send] :noexit:"

press?x:pnt; output?x:sliderBar; instantFeedback [. . .] []

move?x:pnt; output?x:sliderBar; instantFeedback [. . .] []

release?x:pnt; output?x:sliderBar; instantFeedback [. . .] []

fromContainer? x:rct; output?x:sliderBar; instantFeedback [. . . ] []

send?x: int; instantFeedback [. . .] []

output?x: sliderBar; instantFeedback [. . .] []

endproc

For example, process drag specifies that after an interaction press, repeated mousemovement is possible, which is interrupted by an interaction release. The interruption ofrepeat[move] is specified with the disable operator ['. Markopoulos (1997) discussesthe generality and re-usability of such elementary constraints. Input constraints likeclick, drag, repeat can be re-used in different contexts. For a total of 13 interactorscomposed in the case study of Markopoulos (1996), there were four input constraintswhich were re-used in various combinations. Other behaviours commonly encountered,for example, continuous feedback, toggles, triggering behaviours, etc., were identifiedduring the case study and specified also as elementary constraints. Re-use is achieved byactualizing the constraint fromal gate parameters with the appropriate gate identifiersfor each context and by combining the appropriate elementary constraints as necessaryfor each interactor specification.

An important consideration in developing the ADC model has been to help writing,reading and managing specifications of user interface software. This is achieved first byusing a standard specification language with a wide user base, rich documentation andtool support. The formalization of the ADC model describes a standardized style ofwriting and composing specifications rather than a syntactic or semantic extension of thelanguage which would be incompatible with the international standard (ISO, 1989).Interactors are specified by instantiating the ADC interactor model and the individuallyrequired adaptations are restricted to localized parts of the interactor specification: theequations component of the data type, the problem-specific data types composed by thedata type AD (like data type bounded»al and sliderBar of the example), and theconstraints component. On the other hand, the mapping between the dynamic compon-ent of the specification and the data specification component is described by the ADU ina standard way. While this does not reduce the expressiveness of the specificationlanguage, it results in a consistent specification style which, arguably, is easier to writeand to understand than unstructured LOTOS. The reuse of formal specifications can besupported at various levels: individual interactors or composite interactors can be


re-used in different design contexts, lower-level components of interactors like data typespecifications and dialogue constraints can be re-used for the definition of new interac-tors. Markopoulos (1997) examined also parameterization as a means of reusing com-mon temporal behaviour specification, i.e. starting, stopping, suspending, resuming andaborting the interactor. The ADC model helps identify and organize such behavioursand further practical applications of the model should help compile a richer taxonomy oftheir specifications.

3.3. COMPOSITION OF INTERACTOR SPECIFICATIONS

More complex interface specification can be built up by the hierarchical composition ofADC interactors. Composition is supported by the process algebraic operators ofLOTOS (see Appendix A.1). LOTOS behaviour expressions and their meanings ascompositions of interactors are discussed below. In general, the pair-wise composition ofinteractors can be expressed in LOTOS as a behaviour expression of the form

DF:"ADCA? ADC

B

where ? is one of the LOTOS operators D D, D D D, [', [ ] and D [G] D. The operator D [G] Ddescribes the partial synchronization of ADC

Aand ADC

Bover a gate-set G-G

AWG

B.

Full synchrionization D D and pure interleaving D D D are boundary cases of the partialsynchronization of behaviour expressions, where G"G

AXG

Band G"0, respectively.

A synchronization gate g3G may be assigned different roles for each of the twointeractors, which can be one of dinp, dout, ainp, aout and c (see Section 3.1). When twogates synchronize over a common gate a different type of connection is obtained for eachcombination of roles, e.g. (dinp, dout). Interactors ADC

Aand ADC

Bare not distinguished

here so a connection type is symmetric, e.g. the same type of connection corresponds tothe combinations (dinp, dout) and (dout, dinp). The range of all possible connection typesis examined below (see also Figure 8).

(a) Connection type (dinp, dinp). Both interactors receive data synchronously fromtheir display side. An example is a multiple selection of icons which are ‘(‘dragged’’.In the case the mouse position is read by both interactors.

(b) Connection type (ainp, dinp). The two interactors are also synchronized consumersof data. In this case though, the input arrives at the abstraction side for interactorA which interprets the input data independently of the display.

(c) Connection type (dout, dinp). This type of connection models the reuse of thegraphical output from interactor A as graphical input to interactor B. For example,an interactor may ‘‘capture’’ the instantaneous graphical output of an application.

(d) Connection type (aout, dinp). Data is sent from the abstraction side of A to thedisplay side of B, e.g., the sliders of Figure 6 send their results to an interactormodelling the array of strings.

(e) Connection type (c, dinp). The controller unit of interactor A constrains the inputon the display side of interactor B. This can specify a mode, e.g., a keyboardmodifier, where interactor A models the keyboard. Interactor B receives input atgate dinp only when interactor A synchronizes with it, which will be only when theappropriate key is pressed.

FIGURE 8. The range of connection types of ADC interactors.


(f ) Connection type (ainp, ainp). In this case also, the two interactors are synchronousconsumers. Consider,for example, that the interactors for the array of strings andthe two sliders can be resized following a menu command. One possible approachto modelling their composition is that they receive new screen coordinates syn-chronously at their abstraction sides.

(g) Connection type (dout, ainp). Data is sent from the display side of B to theabstraction side of A. This could be an exsample of a graphics-output pipeline,where each interactor manages one transformation of the graphics data structures.

(h) Connection type (aout, ainp). A value is communicated from A to B. For example,the slider of Figure 7 may compute a numeric value which it then sends to otherinteractors as input on their abstraction side. For example, a slider could helpselect from an ordered sequence of data elements by using the numbers as the offsetof the selected element.

(i—l) Connection types (c, ainp), (c, dout), (c, aout) and (c, c). In these cases the controllerof interactor A constrains and it constrained by, a gate of interactor B. This issimilar to type (e) above, where interactions on the common gate must satisfy theconjunction of constraints specified by the CUs of the two interactors.

(m—o) Connection types (aout, dout), (dout, dout) and (aout, aout) concern pairs ofinteractors which synchronize over common output gates. These can be useful formodelling multimodal output where different output modalities synchronize, e.g.sound and video output. In the next section, it is discussed how ruling out thesecases ensures that a deadlock can be effected only by inconsistent dialogues andnot by inconsistent data values. This will ensures that the dynamic behaviour isnot specified implicitly by the composition of two ADUs and so the composition


of two interactors can be transformed to an equivalent ADC interactor specification.However, there is no inherent reason for which connections (m—o) must be ruled out.

The choice operator [ ] can be used to specify alternative interactions. Consider, forexample, a set of interactors for drawing different shapes on a drawing package invokedby some interactor supporting logical disjunction, e.g. a palette or a set of radio buttons.The alternative interactors can be related by the choice operator and their compositioncan be synchronized with the ‘‘palette’’ interactor for their initialization. The disableoperator ['can help specify interruption. For example, the interruption of a tasksupported by an interactor, e.g. a dialogue box, can be modelled by composing thisinteractor with an ‘‘ok’’ or a ‘‘cancel’’ button using the disable operator of LOTOS.Choice and disable are potentially useful constructs for specifying human—computerdialogues, such as the dynamic deactivation of interactors, or in conjunction with theparallel operators for describing the dynamic activation of interactors. However, thecombination of dynamic composition operators with parallel composition expressionscan result in non-finite interpretations of the specification which makes verificationintractable (Patemo, 1997).

Consider the list interactor of Figure 6. The list interactor is specified as the compositionof its ADU and CU components (where ¸, SL are initial values for the state parameters):

process 1st [dinp, dout, ainp, aout] : noexit :"

IstADU[dinp, dout, ainp, aout] (L, SL, SL)

D[dinp, dout, ainp, aout] D1stCU[dinp, dout, ainp, aout]

endproc

Process 1stADº follows from the general definition of ADU:

process 1stADU[dinp, dout, ainp, aout] (a: lstel, dc, ds: scrLst) :

noexit :"

aout!result(a); 1stADU[dinp, dout, ainp, aout] (a, dc, ds) []

dout!dc; 1stADU[dinp, dout, ainp, aout] (a, dc, dc) []

ainp?x: 1stel; 1stADU[dinp, dout, ainp, aout] (receive(a, x),

render(dc, x), ds) []

dinp?x: pnt; 1stADU[dinp, dout, ainp, aout] (inputx, ds, a),

echo(xc, ds, a), ds) []

dinp?x: Int; 1stADU[dinp, dout, ainp, aout] (inputx, ds, a),

echo(xc, ds, a), ds)

endproc

The only constraint specified by lstCº is that the interactor give immediate feedback forall its input.

process lstCU (dinp, dout, ainp, aout.: no exist :"

ainp?X: lstel; dout?X:scrLst; 1stCU [dinp, dout, ainp, aout] []

aout?X:el 1stCU [dinp, dout, ainp, aout] []

dout?X:scrLst; 1stCU[dinp, dout, ainp, aout] []

dinp?X:Int; dout?X:scrLst; 1stCU [dinp, dout, ainp, aout]

endproc


The composition of the list and the slider interactor is specified as follows (where formalgate parameters have been actualized):

sldr[press, move, release, output, fromContainer, send]

D [send, fromContainer] D1st[click, output, fromContainer, send]

Note that both interactors may receive input from their container synchronously(connection type f ), while sldr sends its results to lst via gate send (connection type h).

The discussion so far shows how LOTOS operators can be used to combine interactorspecifications into more complex interface specifications. Markopoulos (1997) discussesa minimal set of ‘‘connectors’’ which are necessary to factor out communication depend-encies from individual iteractor specifications. Some of those are shown in Table 1, where[g] is short for a set G such that g3G. Most communication schemes discussed inMarkopoulos (1997) are supported directly by LOTOS process algebra operators. Theasynchronous communication of information to many interactors requires the introduc-tion of a special connector component specified abstractly below as eventQ. Its use as inTable 1 aims to free the producer and the consumers of data from constraints they wouldotherwise impose on each other because of the synchronicity of LOTOS. The behaviourexpression below suggests that some data x received on a gaate g is communicated on allof the gates g

1,2 ,g

nin any order. Note, that this abstract definition for the event

distribution scheme introduces a very high degree of parallelism into the specification:

process eventQ[g,g1, . . . , gn]: noexit :"

g?x:data; (send [g1] (x) D D Dsend [g2] (x) D D D. . .D D Dsend [gn] (x))AeventQ [g,g1, . . . , gn]

endproc

proces send [g] (x: data): exit :"g!x;exit endproc

The LOTOS operators and the connectors discussed are useful constructs for applyingthe ADC model to the formal specification of a graphical user interface; see Mar-kopoulos (1996, 1997). They are specific to the formal framework in which the interactormodel is represented. When using the ADC model as an informal design notation theexact communication mechanism between interactors need not be specified precisely, (cf.Markopoulos, Papatzanis, Johnson & Rowson, 1998). Graham (1997) interprets theADC interactor model as an implementation architecture in the Java programminglanguage. Java supports asynchronous communication between objects, so data flowand control communications pose different problems for their representation. Thus,depending on the representation framework (formal, informal, programming language)a different set of connectors is required. A constant concern in all these cases is tomaintain the independence of an interactor description from its context of use.

At this point it is worth reflecting upon the tension between modelling event and statusphenomena discussed by Dix and Abowd (1996). Events are momentary while statusrefers to a persistent state which can be sampled at any moment. Dix and Abowddiscriminate models of interactive software by whether they model input and output asevents or status. While the ADC model is an ‘‘event-in and event-out’’ model, the stateparameters a, dc and ds of the ADC interactor describe status and interactions can beassociated with data inout and output. The equations component of the AD data type

TABLE 1Connectors for the composition of interactors (XOR-related producers of data)

FIGURE 9. Synthesis applied to the synchronous compsition of two interactors.


can describe relationships between the abstraction and the display. However, whenspecifying compositions of interactors it is not possible to specify directly relationshipsbetween state components across the two interactors. Specifying such constraints iscumbersome and introduces an implementation bias in an event-based model. This is nota disadvantage altogether, particularly when describing the user-interface architecture.Dix and Abowd advocate modelling status input and output and invariants relatingthem. This affords concise and abstract specifications of status—status relationshipsbetween interactors. However, it can lead to specification which assume an ‘‘infinitelyfast’’ constraint satisfaction mechanism to maintain relationships across interactorswhich may even reside on distributed machines (Dix, 1991). Most of the limitations ofevent-in/event-out models that Dix and Abowd identify can be addressed with a judi-cious choice of abstraction level and scope of interactor description. As a rule of thumb,the relationship between two state components is easier to model inside a single ADCinteractor. The organization of interactors into layers can shield higher-level interactorsfrom inappropriate detail.

3.4. SYNTHESIS AND DECOMPOSITION OF ADC INTERACTORS

LOTOS behaviour expressions specifying the composition of interactors can be oper-ands in more complex behaviour expressions. It is desirable that the resulting expressionscan themselves be interpreted as ADC interactors. This is useful for determining notionssuch as the role of each gate, the type of connections, to instantiate generic constraintsand expressions of interaction requirements. Markopoulos, Rowson and Johnson (1997)


define the formal transformations of composition expressions to ADC interactor speci-fications. The relevant discussion can be summarized in the form of the followingtheorems.

Theorem 1 (Synthesis of synchronous composition expressions): A behaviour expressionwhich specifies the synchronous composition of two ADC interactor specificationsADCA and ADCB over a gate-set G, such that GWGA

oWGB

o"0, can be rewritten as

a strongly equivalent ADC interactor. The CU of the resulting interactor is formed bythe parellel composition of the two component CUs over the gate-set G and its ADU isformed by the parallel composition of the component ADUs over a gate-set:

G1"GA

ioWGB

ioWG,

where the gate-sets for interactors ADCA and ADCB are indicated accordingly (Figure 9).This rewriting, termed synthesis, preserves strong bisimulation equivalence (Milner,1989), denoted by &:

(ADUA

D [GAio] DCU

A) D [G] D (ADU

BD [GB

io] DCU

B)&(ADU

AD [G

1] D ADU

B)

D [GAioXGB

io] D (CU

AD [G] D CU

B).

Because of condition GWGAoWGB

o"0 synthesis does not apply to interactors which

synchronize on their output gates. This ensures that the dialogue is not specified by thedata component of an interface specification but it means that synthesis does not applyto the specification of the fusion of output by two interactors. Markpoulos (1997) showsthat the right-hand side of the above equivalence specifies an ADC interactor for whichthe roles of its gates are re-defined as follows:

GAB$065

"GA$065

XGB$065

, GAB!065

"GA!065

XGB!065

, GAB0

"GA0XGB

0,

GAB$*/1

"GA$*/1

XGB$*/1

!GAB0

, GAB!*/1

"GA!*/1

XGB!*/1

!(GAB0

XGAB$*/1

),

GAB#

"(GA#XGB

#)!(GAB

$*/1XGAB

!*/1XGAB

$065XGAB

!065).

The construction of G1

ensures that no synchronization between ADU and CU isintroduced by the rewriting transformation. This theorem can be simplified for the caseof interleaving where G"0:

(ADUA

D [GA*0] DCU

A) D D D (ADU

BD [GB

*0] DCU

B)&(ADU

AD D D ADU

B)

D [GA*0XGB

*0] D (CU

AD D D CU

B)

In the case of full synchronization, where G"(GA*0XGA

#)X(GB

*0XGB

#) and provided that

GWGA0WGB

0"0, the equation may be simplified to the following form:

(ADUA

D [GA*0] DCU

A) D D D (ADU

BD [GB

*0] DCU

B)&(ADU

AD [GA

*0XGB

*0] DADU

B)

D [GA*0XGB

*0] D (CU

AD DCU

B).


Theorem 2 (Synthesis of dynamic composition expressions): The composition of the ADCinteractor specifications with a dynamic composition operator, i.e. choice [ ] or disable[', can be rewritten as a strongly equivalent ADC interactor. The CU of this interactoris a behaviour expression which combines the two component CUs with the samedynamic operator. The ADU of the compound interactor is formed by the interleavedcomposition of the two component ADUs. The role of the gates are preserved in thecompound interactor:

(ADUA

D [GA*0] DCU

A)? (ADº

BD [GB

*0] DCU

B)&((ADU

AD D D ADU

B)

D [GA*0XGB

*0] D (CU

A?Cº

B),

where ? is either [ ] or [' and

GA#WGB

*0"0 ? GB

cWGA

*0"0 ? GA

*0WGB

*0"0.

Consider, the scrollable list of Section 3.2 which was specified by the synchronouscomposition of the interactors lst and sldr. By applying the synthesis transformation thiscomposition can be rewritten as a single interactor whose ADU and CU are specified asbelow:

adu [press, move, release, output, fromContainer, send, click]

(BV, SB, L, SL)

D[press, move, release, output, fromContainer, send, click] Dcu[press, move, release, output, fromContainer, send, click]

where the ADU for this interactor is defined as

procc adu [...] (BV:boundValue, SB:sliderBar, L: lstel, SL:scrLst):

noexit:"

sldrADU[press, move, release, output, fromContainer, send] (BV, SB, SB)

D[send, fromContainer] DlstADU[click, output, fromContainer, send] (L, SL, SL)

endproc

and the controller is defined as

process cu[...]:noexit:"

sldrCU[press. move, release, output, fromContainer, send]

D[send, fromContainer] D1stCU[click, output, fromContainer, send]

endproc

Markopoulos (1997) discusses synthesis in combination with the hiding operator ofLOTOS, and defines decomposition as a formal transformation which is the reverse ofsynthesis. Hiding internal detail is an important tool in scaling up specifications.Decomposition takes as input an interactor expression and results in LOTOS behaviourexpression combining two interactors. Decomposition is a useful complement of syn-thesis and is also necessary for the stepwise refinement of interactor specifications.


Markopoulos (1997) proposes an algorithmic solution to the decomposition problem forthe cases where the interface is spoecified using the constraint oriented style (Visserset al., 1991).

4. Analytical use of the ADC formal interactor model

This section discusses the specification and verification of usability related properties inthe context of the ADC interactor model. These properties are discussed in three parts:interpretations of predictability and observability related properties in the framework ofthe ADC interactor model, dialogue verification and the specification and verification ofuser task requirements.

4.1. PREDICTABILITY AND OBSERVABILITY

Following the discussion on abstract models, in Section 2.3, the formal expression ofpredictability and observability properties requires the formalization of two notions: theinstantaneous ‘‘state’’ and the distinct ‘‘views’’ of an interactive system, one reflecting itsinternal workings and the other reflecting its observation through a display. In theprocess algebraic framework of LOTOS, the state of a process corresponds to a behav-iour expression that describes its future behaviour. Thus, comparing states amounts tocomparing behaviour expressions, for example, they may be strong observational equiv-alent, weak observational equivalent, etc. (see, e.g., Milner, 1989; de Nicola, 1989).

Let P denote a behaviour expression describing an interactor. P may offer to itsenvironment a set of interactions, denoted as out(P). To specify only the interactionsoffered on a set of gates G, out

G(P) is defined as

outG

(P)"Mg3G D PNgNXMgNSvT D g3G?v3valueSet(g)?PNg:v; N,

where the relation Ng denotes that there is an observable transition labelled by g fromP to the behaviour described by the right-hand side of the relation: valueSet (g) denotesthe set of possible values that may be associated with interactions on gate g. Fora variable declaration g?x:s, where s is some sort identifier, let valueSet(g) include allpossible values of this sort. Otherwise, it may contain a single value that is output on gateg, by some value declaration g ! v.

Similarity of interactors. An interactor may be associated with multiple result opera-tions. For each gate g3G

aouta single interaction g ! result (A) is offered, where A is the

abstraction held by the interactor. Similarly the interactor outputs its display states D onthe display side as: dout!D. Two interactors P and Q ( or two behaviour expressionsdescribing two states of the same interactor) are called abstraction-similar (display-similar) when they are defined with identical gate-sets G

!065(respectively G

$065) and when

they output the same values on those. To exclude the contrived case where no events areoffered on a gate, the clause is added that these sets should not be empty:

similarA

(P, Q) iff outG!065

(P)"outG!065

(Q)O0,

similarD

(P, Q) iff outG$065

(P)"outG$065

(Q)O0,


Abstraction-side and display-side behaviours of an interactor. Interactors are character-ized by the behaviour they exhibit when observed from the obstraction or the displaysides. The abstraction-side behaviour of the interactor is observed by interaction at gatesG

!065and G

!*/1. The display-side behaviour is observed at gates G

$*/1and G

$063. They are

described by the pseudo-LOTOS expressions:

AP"hide (G

#XG

$*/1XG

$065) in P,

DP"hide (G

#XG

!*/1XG

!065) in P,

Abstraction and display equivalence. Two interactors P and Q (or two behaviour expres-sions describing two states of the same interactor) are called abstraction equivalent if theirabstraction-side behaviours are observationally equivalent, i.e. A

P"A

Q. They will be

called display equivalent when their display-side behaviour are observationally equiva-lent, i.e. D

P+D

Q.

The meaning of these definitions depends on the equivalence relation+theystipulate. The choice between equivalence relations for processes is a contentiousissue (cf. de Nicola, 1989), which, in the present context, impinges on the ability ofhumans to tell apart interactive behaviours and to detect and interpret differencesof the display contents. Without wishing to postulate a theory of user cognition,weak observational equivalence is used here as it distinguishes processes only withrespect to observable interactions with their environment and its verification is sup-ported by model checking tools, (e.g. Fernandez, Garavel, Munnier, Rasse, Rodriguez& Sifakis, 1992).

These definitions are used in Table 1 which is a summative classification of observabil-ity and predictability properties results comparable to an earlier classification by Abowd(1992). Consider, for example, the first row of Table 2. An interactor is called displaypredictable, if the similarity of two instances of its display implies that they are alsodisplay equivalent. In other words, the display status of the interactor determines itsdisplay-side behaviour. A symmetrical definition of result predictability can be written asin row 2 of Table 2.

The shaded rows of the table describe observability related properties. Each formalexpression has two ‘‘legs’’ which correspond to a static and a dynamic aspect of therequirement. For example, consider an electronic messaging application that operates inthe background, while the user is engaged in unrelated tasks. The user is alerted to thearrival of a new message by an icon being superimposed on the display. Consider alsoa user who from a change of the display infers that the state of the messaging applicationhas changed. When the display has not changed, i.e. there is no icon on the screen, theuser infers that no new message has arrived. A systems for which the implicationsimilar

D(P, Q) Nsimilar

A(P, Q) holds warrants the second inference but not the

first, so it is called statically honest. A system that displays a message-arrival icon withoutreason is still statically honest. An interface that satisfies the dynamic honesty require-ment similar

A(P, Q) Nsimilar

D(P, Q) will correct this problem. On the other hand,

a system that does not display the icon when a message arrives is dynamically honest butnot statically honest. Clearly, true honesty should require both conditions to hold.Therefore, observability properties require a logical equivalence between the predicatesthey relate.

TABLE 2Expressions of predictability and observability properties


Unfortunately, these definitions are too strong. For example, a closer look shows thatno reasonable ADC interactor can be display predictable. By the definition of the model,the display does not change until an output event take place. Let the state S represent allpossible states which an interactor can reach starting from its initial state. Immediatelybefore and immediately after any input action on the display side, similarity is main-tained:

∀P3S D gSvT3out$*/1

(P) ? P gSvT&&&" Q ) similar

D(P, Q).

However, the display behaviour after such an interaction does normally change, asa result of the input action. For the interactor to be predictable, the display sidebehaviour should never change:

∀P3S D gSvT3out$*/1

(P) ? P gSvT&&&" Q ) D

P+D

Q.

Clearly, this cannot be true for any useful interactive system, as this would mean thatuser interactions do not influence the behaviour of the system as it is observed from thedisplay. This problem arises because an event-based formalism is used to model status,a concept better described by a state-based formalism. The requires relationship betweenthe display status and its future behaviour breaks down between an input and an outputinteraction. Dix (1991) questions the feasibility of abstractions that model input andoutput by events and suggests that an ‘‘interactivity conditions’’ should be applied, i.e.that an output follows all input. This conditions can be enforced trivially as a temporalconstraint on the ADC interactor like the instant feedback constraint of Section 3.1 but itdoes not solve the problem. Rather, the similarity predicate should only apply to a subsetof the states of the interactor, say, to states that may precede an input. This will ensurethat the relevant properties hold whenever the user is able to influence the behaviour ofan interactor. Therefore, the similarity predicate is defined now as follows:

similarA

(P, Q) iff out!065

(P)"out!065

(Q)O0 ?out$*/1

(P)O0? out$*/1

(Q)O0,

similarD

(P, Q) iff out$065

(P)"out$065

(Q)O0 ?out$*/1

(P)O0? out$*/1

(Q)O0,

Unfortunately, the utility of these formal expressions is hard to demonstrate. Verificationby hand or by model checking of these properties depends very much on the judicious


choice of abstraction level and on crafting the data types used so that they produce finitesets of values. This can be quite hard if the specification addresses non trivial interaction.It is easier to detect when these properties do not hold (cf. Markopoulos, 1997).Currently, the properties of Table 2 are more aptly thought of as heuristics which havefound a lucid expression through abstract models but are not readily applicable for thepractical verification interactive systems. Further development of the ADC interactormodel could produce examples and specification styles for the data type component ofthe interactor that would facilitate the practical verification of these properties.

4.2. DIALOGUE VERIFICATION

Dialogue verification is revisited here in the context of the ADC interactor. By thedefinition of the ADC formal interactor model the dialogue specification of a singleinteractor is solely and exclusively modelled by the CU. Given a group of interactors,a CU which describes the combined dialogue specification may be factored out bya repeated application of the synthesis transformation described in Theorems 1 and 2.Even when the designed architecture does not involve a separable dialogue component,synthesis enables the designer to obtain a separate model of the interaction dialogue. Theroles of the ADC interactor gates provide a classification of interaction events, whichfacilitates the instantiation of generic dialogue properties as discussed in Section 2.5. Ingeneral, an appropriate classification of interactions will allow the verification of dia-logue requirements external to the interface model, e.g. relating to task action se-quencing, erroneous behaviour, etc.

For example, consider the slider interactor of Section 3.2. The specification of event-uall feedback (as in Section 2.5) for an event press can be instantiated as follows:

AG [press] E (ttttº

065165tt).

A complex configuration can be trasnformed, by synthesis, to a single interactor. Duringsynthesis the role of the gates is redefined (see Section 3.4). As a result, the formalspecification of dialogue properties is the same for a simple interactor as it is fora compound interactor, and their instantiation does not require an in-depth examinationof the architectural configuration of the interface.

A practical alternative for dialogue verification is to specify dialogue propertiesdirectly as LOTOS specifications. These dialogue specifications are identical to thoseused inside the CU of the interactor so the same set of processes can be used for bothpurposes, e.g. they could be taken from some ‘‘library’’ of pre-defined specificationcomponents. In this case however they are compared against a whole interface speci-fication. This approach to verification is supported by the CADP toolset by (Fernandezet al., 1992). For example, the LOTOS process below specifies that an occurrence of aninput on the display side is followed by the occurrence of an output before another inputis allowed. An output event is still allowed to happen without a prior input event.

process feedback [dinp. dout]: noexist :"

dinp; dout; feedback[dinp, dout]

[] dout; feedback[dinp, dout]

endproc


To verify that a press event must be followed eventually by an output event, theinteractor list is compared to process feedback. For this comparison all actions that arenot input or output on the display side are ‘hidden’; since they do not concern thisproperty. The list interactor can then be compared to the feedback property with respectto weak observational equivalence (Milner, 1989):

hide (G - Mpress, outputN) in P(sldrCU)"feedback [press, output]

Weak observational equivalence is chosen because it is recognized that each interactormay exhibit internal behaviour which is ignored and because all actions apart from dinpand dout are hidden. The hiding means that the property holds even if the feedback is notoffered immediately after the input event. This equivalence describes the same dialogueproperty as the logic formula above.

The ADC interactor provides a conceptual framework for specifying and verifyingdialogue properties. Interactors prompt the expression of dialogue properties interms of architectural constucts, here the gates of the interactors and their roles. LOTOSis very well equipped to define action succession properties and safety properties.ACTL is certainly more concise. The higher-level ACTL constructs, e.g. AG (always),[dinp]/, etc., are quite powerful constructs that some people may find moreintuitive than a process algebraic description. Both approaches require a goodunderstanding of the formalisms and a careful interpretation of the specifications written.Similarly, in practice, both approaches rely on the use of general-purpose verifi-cation tools. As more powerful and usable tools are developed, model checkingtechnology could aid user interface designers to analyse formal specifications of theirdesigns.

4.3. FORMALISING THE CORRESPONDENCE OF TASK AND INTERFACE ACTIONSEQUENCING

Dialogue verification techniques may help verify an interface model with respect to usertask requirements. For example, Paterno (1993, 1997) associates the occurrence ofa particular event with the successful completion of task and uses model checking toverify that this event can occur as a result of the user interacting with the specifiedinterface. Olsen et al. (1995) propose a state-based dialogue model and associatedsome dialogue states with the successful completion of a user task. The reachability ofthese states is considered as an indication that the taks is possible to achieve with thespecified interface. This section examines a more comprehensive comparison of a user-interface model with a task model which formalizes some intuitions underlying task-based design.

Task-based design approaches, e.g. ADEPT (Wilson & Johnson, 1996) and MUSE(Lim & Long, 1994), use task models prescriptively to inform the design of a userinterface. Wilson and Johnson (1996) describe some heuristics which guide the pro-gression from a task model to an interface design. For example, they suggest that taskactions, which are elementary components of task activity in their task model, should bemapped to commands that the user will issue to the system. Also, they argue, theinterface should not violate task sequencing knowledge, i.e. it should not force the usersto perform their tasks in a different order than that of the task model.

FIGURE 10. A framework for relating task and interface representations. Task and interface models at a givenlevel of abstraction implicitly assume the operation of lower-level entities. Actual flow of informa-

tion during interaction; Comparisons at a level of abstraction N.


Most task models used in task-based design approaches describe the decomposition oftasks to subtasks and the temporal ordering associated with the execution of thesesub-tasks. Decomposition and temporal ordering are straight-forward to specify witha process algebra (see e.g. Markopoulos, Wilson & Johnson, 1994; Markopoulos,Johnson & Rowson, 1997). Omitting the details of the specification style for task models,it is assumed here that both the task model (TM) and the interface model (IM) arespecified as LOTOS processes.

The general idea of relating tasks to interface models is illustrated in Figure 10.Tasks and interfaces may be modelled at a range of abstraction levels, i.e. with a differentgranularity of elementary interactions. The actual designation of abstraction levelsis not particularly important in the currrent context and there does not need to bea one-to-one correspondence between the abstraction levels indicated for tasks andinteractors. At one abstraction-level task actions describing physical interaction,perception and elementary motor movements by the user can be related directly tointeractions with physical input devices. At another level of abstraction for the userinterface, individual actions refer to abstractions of application functionality.Using Moran’s (1983) terms, higher level tasks which describes the intentions of the userare characterized as external, while tasks which pertain to knowledge about the opera-tion of the user interface re named internal. Levels of abstraction of user-interfacesoftware are designated here according to the Seeheim model (Green, 1985). Interactionmay involve all levels of abstraction concurrently, where tasks and interactors ateach level of abstraction rely on those of lower levels of abstraction. Rather than tryingto model or prescribe this layered view of interaction, task-based design defines aparticular level of abstraction at which it draws direct mappings from the task to theinterface model. Note that the framework illustrated a Figure 10 does not aim tomodel the psychological processes taking place as interaction unfolds, in contrast,e.g. to the interaction framework discussed by Blandford, Harrison and Barnard(1995). The objective here is to model the cognitive mappings of task knowledge tointerface behaviour at various levels of abstraction. The framework does not implya particular design process nor a standard set of abstraction levels through which thedesign should proceed.


The abstraction level at which task representations can be related directly to theinterface design is determined by the task analysis. For example, the actions of aninteractor which models the cursor of a text editing program may be at too low a level tocorrespond to the users’ knolwedge of actions in the task of writing an article. Incontrast, the task action of moving to the end of a document might be mapped todragging a slider bar.

Let TM be a LOTOS process modelling the task model, IM a process modelling theinterface model and G the set of gates over which the interactions with the interface areobserved. Interactions on other gates on the IM can be considered as ‘‘internal detail’’which is not directly of concern for the comparison with the task knowledge model. Thebehaviour of the interface which is related to the task representation is then described bythe following:

IMG

:"hide all but G in IM.

Let A be all task actions that have a direct correspondence to interface actions. Thecorrespondence of task actions to the actions of the interface model can be representedby a mapping R : A>G. Some task actions may not correspond directly to an interac-tion. For example, they may represent user knowledge of decisions or actions which arenot supported by the interface. The interface model should not support correspondinginteractions, however these actions are significant in describing task sequencing.

Some task actions may pertain to system specific tasks such as navigating throughdisplays or getting into an appropriate model of interactions. A different task re-quirement results if these interactions are modelled explicitly or not. If they are abstrac-ted away from, the task model is described independently of the tools that support thetask. The corresponding interactions must be considered as internal detail of theinterface model when this is verified with respect to the task. When such interactions aremodelled explictly in the interface model they must also be modelled in the task model,and the comparison of the two models assesses whether the interaction dialogue hindersor supports of task sequencing described in the task model. In this discussion it isassumed that the task model incorporates task actions necessary to interact with theinterface modelled by IM

G, and the mapping R is surjective. The task model is renamed

using the mapping R, so it is represented as TMR"TM[R(A)]. The following definition

is adapted from Brinksma (1989). The notation employed for discussing traces ofprocesses is explained in Appendix A.2.

4.3.1. Conformance of behaviour expressionsLet Q

1and Q

2be two processes and Let L be the set of all possible actions for all

processes. Q1

conf Q2

if

∀p3Tr (Q2) ? ∀A-L.

if &Q@1D ∀a A ) Q

1N Q@

1N/ a then &Q@

2D ∀a3A ) Q

2Np Q@

2N/ a

This expression is read as follows: If Q1

can perform some trace p and then behave likea process Q@

1and if Q

2can perform the same trace p and then behave like Q@

2, then the

following conditions are required: whenever Q@1

refuses of perform an action a from a setA and Q@

2must also refuse every action in A. In other words, Q

1conf Q

2means that


testing the traces of Q2

against the process Q1

will not lead to deadlocks that could notoccur with the same tests performed with Q

2itself.

Recalling the requirement on task sequencing mentioned earlier, it can be said moreformally that an interface, that behaves as IM, will not reach an impasse when per-forming a task, as described in TM, when it is possible to support a mapping of taskactions A to interactions on gates G of the interface, as defined by R so that: IM

Gconf

TMR. Conformance is not symmetrical and is sensitive to the nondeterminism that

results from the hidden internal behaviour of the interactive system. Primarily it requiresfrom the interface model that all task action sequences specified in the task model aresupported by IM, but it does not limit the interface to the task described by the taskmodel.

The conformance relationship can be tested. This means that a set of tests can bedefined which can assess whether an implementation (here the interface model) conformsto a given specification (here the task model). Brinksma (1989) has shown that a formalspecification of this set of tests, called the canonical tester, exists for every LOTOSprocess specification. Testing compares systems with respect to their response to a set offinite sequences of interactions with the environment, the tests. Formal testing willcompare a specification, e.g. of the interface, against processes specifying the tests.A formally specified test suite can be expanded and refined with implementationconstructs during the development of an interactive system. A realisation of a formallyspecified test suite may be used to test an implementation, possibly with the involvementof users. Testing can thus link the formal specification of interfaces and tasks with otherstates of the development of the user interface. A small set of tests may reveal interestingproblems with an interface design and can focus the attention to the designer on thebehaviours required by the task model.

The example below demonstrates how an interface design may be tested againsta task knowledge model. The task, which is fabricated for the purposes of the discussionconcerns the typesetting of a small text, e.g. a party invitation, which has alreadybeen composed with a word processor. An imaginary user experiments with thetypesetting, i.e. changing the fonts, letter sizes, column layouts margins, etc. Forbrevity, the task description is restricted to changing the orientation of the page andchanging the margins. The user can inspect the result of the page by a previewfacility where the text is displayed to resemble its appearance in printed form. A simplis-tic description of the task knowledge could be specified in the LOTOS language asfollows:

process produceInvitation [margins, orientation, preview,

observe, satisfied, close, decideAChange] : noexit :"

observation[preview, observe]Atypeset[margins, rientation, observe]Aterminate[margins, orientation, preview, observe, satisfied,

close, decideAChange]

endproc

process observation [preview, observe]: exit :"(preview; observe; exit) [] exit

endproc


process typeset [margins, orientation, obsertve]: exit :"

margins; observe; exit [] orientation; observe; exit

endproc

process terminate [margins, orientation, preview, observe,

satisfied, close, decideAChange] :noexit:"

decideAChange; produceInvitation [...] [] satisfied; close;

exit

endproc

From the task specification the canonical tester is produced automatically using theCOOPER component of the LITE toolset (Man8 as, 1995). The canonical tester isa LOTOS process which specifies the behaviour of a testing environment which can testthe conformance of an interface to the task model above. A set of finite tests are derivedmanually from the canonical tester. Each is a finite sequence of steps ending witha reserved event success, which signifies successful termination. For example, the tests t1and t2 below were produced from the canonical tester of produceInvitation.

process t1[preview, observe, margins satisified close, success]: exit :"

preview; observe; margins; observe; satisfied; close; success; exit

endproc

process t2[preview, observe, margins satisified close, success]: exit :"

preview; observe; orientation; observe; satisfied; close; success; exit

endproc

The test t1 describes a task action sequence where the user observes the preview display,sets the margins in any of the two ways supported, checks the result of this action, issatisified by it and terminates the task. The actions satisfied and change represent userdecisions and have no image on the interface model. The task action satisfied is hidden sothat actual test for the interface model is

hide satisified in t1

Hiding is applied after the generation of the canonical tester for reasons pertaining to themeaning of non-determinism for conformance testing (cf. Brinksma, 1989). Tests that areproduced from the canonical tester can be run againsta formal specification of a userinterface where task actions are mapped to interface actions by appropriate re-naming.The tests can also be tested directly against a running system. For example, t1 and t2were tested against a proprietary word processor which does not allow the orientation tobe modified in the preview model, and a later improved version of the same software,where this shortcoming has been improved. For the early version t1 succeeds and t2 isrejected. Both tests are successful with the later improved version. Formal testing of theADC specification of the two versions of the word processor were conducted using theLOLA test-bed tool (Quemada, Pavon & Fernandez, 1989). The verdict for t1 was ‘‘maysucceed’’ for both versions. The verdict for t2 was ‘‘must fail’’ for the early version and‘‘may succeed’’ for the second. These tests show that the early version is not conformantto the task model above while there is a positive indication for task conformance for thelater version of the word processor.


Establishing a correspondence between tasks and interface specifications is a long-standing aim of human—computer interaction research; consider, for example, the earlywork on Command Language Grammars by Moran (1981). Few attempts have beenmade to define this relationship explicitly and at a level of abstraction that describestasks macroscopically rather than as low-level interaction tasks. The conformancerelationship discussed here concerns not only the feasibility of performing a task but alsothe preservation of task sequencing for that task. Further, it allows explicit links toa theory of modelling user’s task knolwedge (Johnson, 1992).

5. Discussion

This paper has presented the formal specification in LOTOS of an architectural modelfor user interface software. An important concern throughout has been to delivera practicable formal model which will provide analytical power to user interface de-signers and which will facilitate the task of formal specification. This section examinessome open issues that need to be addressed and examines which further steps must betaken to enable the practical use of such formal models by practitioners in interactivesystem design.

The formal specification of the ADC interactor reflects the features and limitations ofthe LOTOS formal specification language. Specification and verification are supportedby widely used general purpose tools which are evolving as a result of continuingresearch in formal methods. LOTOS is particularly powerful in specifying the dynamicbehaviour of interactive systems, but is not equally adept at specifying state invariants ordisplay-layout properties. It can model the lifetime of interactors for which the connec-tions and the context of execution are specified statically in advance. However, theapproach discussed does not generalize easily to an indefinite number of interactors,created and destroyed dynamically or whose configuration changes dynamically.

To enhance the practical utility of formal models of user interface software, furtherwork is required to scale up their application and to use them cost-effectively. Mar-kopoulos (1996) reports an extensive case study in the formal specification of aninteractive system, which has had a formative role in the development of the ADCinteractor model. The study suggested that while the specification of user interfaces inLOTOS is facilitated by the ADC model there is an opportunity of re-using specificationcomponents which would be greatly enhanced by appropriate tool support. The develop-ment of tool support for the formal specification of ADC interactors is the subject of ongoing work. An early attempt to use the ADC interactor as an implementation architec-ture (Graham, 1997) suggests that an architectural model can provide the link betweenprototyping in a programming language and formal specification and analysis. Provid-ing tool support to bridge these two activities would greatly enhance the cost effec-tiveness of the formal specification.

Another important issue is that current research in the formal specification of interac-tive systems lacks empirical evidence as to validity of the representations proposed.Markopoulos et al. (1998) report a case study which aims to validate the ADC interactormodel as a design representation. The ADC interactor provides a conceptual frameworkfor the informal specification of user interfaces. This informal specification is seen as anintermediate step towards a formal specification, but also, as a useful notation in its own


right, which does not incur prohibitive formalisation costs. The case study compares thearchitectural description of user-interface designs using the ADC model to a task-baseddescription in UAN (Hix & Hartson, 1993), with respect to the ability of the twonotations to capture design recommendations that result from a usability evaluation.The case study results are very encouraging with respect to the coverage of design issuesby the architectural description.

The validity issue concerns also the analytical use of the interactor models. Analyticalresults from earlier formal models of user-interface software, both abstract and concrete,have been reproduced in the framework of the ADC model. It has been mentionedalready that a theoretically founded formalisation of usability related properties cannotbe derived from a model of the system only. Rather, system models must be related tomodels of user tasks, behaviour, domain models, etc. The discussion on task conform-ance is an example, albeit small, of how a formal framework can help relate diversemodelling approaches with the aid of some clearly defined principle for relating the tworepresentations.

6. Conclusion

An important motivation for the research reported has been to support a practicalapproach to the formal specicification and verification of interactive systems. A key toachieve this aim is the definition of appropriate abstractions. This paper has argued thatinteractors are appropriate intermediate-level abstractions which help specify genericand re-usable formalizations of user interface software. The formal ADC interactormodel forges a standard mapping of concepts of the domain to LOTOS languageelements and a standard style of writing specification relieving the specifier fromdecisions which are costly to resolve on a problem by problem basis. The ADC interactormodel borrows concepts originating from user interface software architectures. Ground-ing a formal model on software architectures results in representations relevant to theconcerns of a software developer which encapsulate design in re-usable specificationcomponents. This idea was demonstrated with the compositional specification of userinterface software, and also, with the definition of re-unsable and generic expressions ofproperties of an interactive system. Finally, the process algebraic specification of userinterfaces and of task knowledge provides a conceptual and formal framework forarticulating and validating user task knowledge requirements. In particular, a formaliz-ation was proposed of heuristics embodied in task-based design approaches, which helpbase user interface design on representations of users’ task knowledge.

This research is funded by EPSRC, grant GR/K79796. Acknowledgement is due to CNRS/IMAGfor the CADP toolset, to UPM University of Madrid, for the TOPO/LOLA toolset and to ITA,University of Twente, for the LITE toolset. The advice of anonymous referees is gratefullyacknowledged.

References

ABOWD, G. D. (1992). Formal aspects of human computer interaction, Ph.D. Thesis, University ofOxford, Technical Report YCS 161, University of York.


BLANDFORD, A. E., HARRISON, M. D. & BARNARD, P. J. (1995). Using interaction framework toguide the design of interactive systems. International Journal of Human—Computer Studies, 43,101—130.

BOLOGNESI, T. & BRINKSMA, E. (1989). Introduction to the ISO specification language Lotos. In P.VAN EIJK, C. VISSERS & M. DIAZ, Eds. ¹he Formal Description ¹echnique ¸otos. pp. 23—73.North-Holland: Elsevier.

BOUALI, A., GNESI, S. & LAROSA, S. (1994). The integration project for the JACK environment.Bulletin of the EA¹CS, 54, 307—223.

BOWEN, J. P. & HINCHEY, M. G. (1995). Ten commandments of formal methods. IEEE Computer,28, 56—63.

BOWEN, J. P. & STAVRIDOU, V. (1993). The industrial take-up of formal methods in safety-criticaland other areas: a perspective. In J. C. P. WOODCOCK & P. G. LARSEN, Eds. Formal MethodsEurope 1993: Industrial Strength Formal Methods. Lecture Notes in Computer Science, Vol.670, pp. 183—195. Berlin: Springer.

BRINKSMA, E. (1989). A theory for the derivation of tests. In P. H. J. VAN EIJK, C. A. VISSERS & M.DIAZ, Eds. ¹he Formal Description ¹echnique ¸otos, pp. 235—247. North-Holland: Elsevier.

COCKTON, G. (1990). The architectural bases of design re-use. In D. A. DUCE, M. R. GOMES,F. R. A. HOPGOOD & J. R. LEE, Eds. ºser Interface Management and Design, pp. 15—34. Berlin:Springer.

COUTAZ, J. (1997). PAC-ing the User Interface Architecture. In M. G. HARRISON & J.-C. TORRES,Eds. Design, Specification and »erification of Interactive Systems +97, 13—28. Wien: Springer.

COUTAZ, J. (1987). PAC, an object oriented model for dialog design. In H. J. BULLINGER

& B. SHAKIEL, Eds. IN¹ERAC¹ +87, pp. 431—436. North-Holland: Elsevier.DEARDEN, A. & HARRISON, M. (1997). Abstract models for HCI. International Journal of Hu-

man—Computer Studies, 46, 151—177.DE NICOLA, R. (1989). Extensional equivalences for transition systems. Acta Informatica, 24,

211—237.DIX, A. J. (1991). Formal Methods for Interactive Systems. New York: Academic Press.DIX, A. J. & ABOWD, G. (1996). Modelling status and event behaviour of interactive system.

Software Engineering Journal, 11, 334—346.DUKE, D. J. & HARRISON, M. D. (1994). From formal models to formal methods. In R. N. TAYLOR

& J. COUTAZ, Eds. Software Engineering and Human—Computer Interaction, ICSE+94 ¼ork-shop on Software Engineering and Human—Computer Interaction, Lecture Notes in ComputerScience. Vol. 896, pp. 159—173. Berlin: Springer.

FACONTI, G. P. (1993). ¹owards the concept of interactor. AMODEUS Project Report, ref.sm/wp8.

FERNANDEZ, J. C., CARAVEL, H., MOUNIERR, L., RASSE, A., RODRIGUEZ, C. & SIFAKIS, J. (1992).A toolbox for the verification of LOTOS Programs ICSE +92, 14th International Conferenceon Software Engineering, Melbourne, May 1992.

FIELDS, B., MERRIAM, N. & DEARDEN, A. (1997). DMVIS: design, modelling and validation ofinteractive systems. In M. G. HARRISON & J.-C. TORRES, Eds. Design, Specification and»erification of Interactive Systems+97, Wien: Springer.

GRAHAM, M. (1997). »alidation of the ADC interactor model as an implementation architecture. MScProject, Department of Computer Science, Queen Mary and Westfield College, University ofLondon, August.

GREEN, M. (1985). Report on dialogue specification tools. In G. E. PFAFF, ed. ºser InterfaceManagement Systems, pp. 9—20. Berlin: Springer.

HARRISON, M. D.& DIX, A. J. (1990). A state model of direct manipulation in interactive systems.In M. D. HARRISON & H. W. THIMBLEBT, Eds. Formal Methods in Human—ComputerInteraction, pp. 29—151. Cambridge: Cambridge University Press.

HILL, R. D., BRINCK, T., ROHALL, S. L., PATTERSON, J. F. & WILNER, W. (1994). The rendezvousarchitecture and language for constructing multiuser applications. ACM¹ ¹ransactions onComputer Human Interaction, 1, 81—125.

HIX, D. & HARTSON, R. H. (1993). Developing user interface: Ensuring usability through product andprocesses. New York: Wiley.


HOLLOWAY, C. M. & BUTLER, R. (1996). Impediments to the industrial use of formal methods.IEEE Computer, 29, 26—27.

ISO (1989). Information processing systems-open systems interconnection-¸O¹OS—A formal de-scription technique based on the tempral ordering of observational behaviour. ISO/IEC 8807,International Organisation for Standardisation, Geneva.

JOHNSON, P. (1992). Human—Computer Interaction: Psychology, ¹ask Analysis and Software Engin-eering. London: McGraw-Hill.

KRASNER, G. E. & POPE, S. T. (1998). A cookbook for using the model-view-controller userinterface paradigm in the smalltalk-80 system. Journal of Object Oriented Programming, 1,26—49.

LIM, K. Y. & LONG, J. (1994), ¹he MºSE Method for ºsability Engineering. Cambridge:Cambridge University Press.

MAN® AS, J. A. (1985) Getting to use the LOTOSPHERE integrate tool environment (LITE). In T.BOLOGNESI & J. VAN DE LAGEMAAT. Eds. ¸O¹OSphere: Software Development with ¸O¹OS.Dordrecht, Netherlands: Kluwer.

MARKOPOULOS, P. (1996). Case study in the formal specification of the SimplePlayerTM graphicalinterface for playing Quick¹imeTM movies, using the ADC interactor model. Technical Report712, Department of Computer Science, Queen Mary and Westfield College, University ofLondon.

MARKOPOULOS, P. (1997). A compositional model for the formal specification of user intefacesoftware. Ph.D. Thesis, Department of Computer Science, Queen Mary and Westfield College,University of London, Marchy 1997.

MARKOPOULOS, P., JOHNSON, P. & ROWSON, J. (1997). Formal aspects of task based design. In M.D. HARRISON & J. C. TORRES CANTERO, Eds. Design Specification and »erification ofInteractive System *97 pp. 209—224. Wien: Springer.

MARKOPOULOS, P., PPATZANIS, G., JOHNSON, P. & ROWSON, J. (1988). Validating semi-formalspecifications of interactors as design representations. In P. MARKOPOULOS & P. JOHNSON,Eds. Design Specification and »erification of Interactive Systems +98 Berlin: Springer.

MARKOPOULOS, P., ROWSON, J. & JOHNSON, P. (1997). Composition and synthesis with a formalinteractor model. Interacting with Computer, 9, 197—223.

MARKOPOULOS, P., WILSON, S. & JOHNSON, P. (1994). Representation and use of task knolwedgein a user interface design envirionment. IEE Proceedings-E, Computer and Digital ¹echniques,141, 78—84.

MILNER, R. (1989) Communication and Concurrency. UK: Prentice-Hall.MORAN, T. (1981). The command language grammar: a representation for the user interface of

interactive computer systems. International Journal of Man Machine Studies, 15, 3—50.MORAN, T. (1983). Getting into the system: external and internal task mapping analysis. In A.

JANDA, Ed. 2nd Conference of Human Factors in Computing Systems, CHI+83, New York:ACM Press.

MYERS, B. A. (1990), A new model for handling input: ACM ¹ransaction on Information Systems, 8,289—320.

OLSEN, D., MONK, M. A. & CURRY, M. (1995). Automatic dialogue analysis. Human—ComputerInteraction, 10, 40—78.

PATERNO, F. (1993). Definition of properties of user interfaces using action based temporal logic. In5th Conference in Software Engineering and Knowledge Engineering, Conference Proceedings,pp. 314—318.

PATERNO, F. (1997). Formal reasoning about dialogue properties with automatic support. Interac-ting with Computers, 9, 2.

PATERNO, F. & FACONTI, G. P. (1992). On the use of LOTOS to describe graphical interaction. InA. MONK, D. DIAPER, & M. HARRISON, Eds. People and Computer »II, Human—ComputerInteraction, BCS-HCI Conference Proceedings, pp. 155—173. Cambridge: Cambridge Univer-sity Press.

QUEMADA, J., PAVON, S. & FERNANDEZ, A. (1989) State exploration by transformationwith LOLA. ¼orkshop on Automatic »erification Methods for Finite State Systems,Grenoble, June.


SHAW, M. & GARLAN, D. (1996). Software Architecture: Perspective on an Emerging Discipline.Englewood Cliffs: Prentice Hall.

SUFRIN, B. & HE, J. (1990). Specification analysis and refinement of interactive processes. In: M. D.HARRISON, & H. W. THIMBLEBY, Eds. Formal Methods in Human—Computer Interaction, pp.153—200. Cambridge: Cambridge University Press.

THIMBLEBY, H. W. (1984). Generative user-engineering principles for user interface design. In B.SHACKEL, Ed. Proceedings IN¹ERAC¹+84, pp. 661—666. Amsterdam: North-Holland.

TOOK, R. (1990). Putting design into practice: formal specification and the user interface. In M. D.HARRISON & H. THIMBLEBY, Eds. Formal Methods in Human—Computer Interaction. pp.63—96.’ Cambridge: Cambridge University Press.

VISSERS, C. A., SCOLLO, G., VAN Sinderen, M. & BRINKSMA, E. (1991). Specification styles indistributed systems design and verification. ¹heoretical Computer Science, 89, 179—206.

WILSON, S. & JOHNSON, P. (1996). Bridging the generation gap: From work tasks to user interfacedesigns. In J. VANDERDONCKT, Ed. 2nd International ¼orkshop on Computer-Aided Design ofºser Interface, CDºI+96, pp. 77—94. Presses Universitaires de Namur.

ZAVE, P. & JACKSON, M. (1996). Where do operations came from? A multiparadigm specificationtechnique. IEEE ¹ransactions on Software Engineering, 22, 508—528.

Paper accepted for publication by Associate editor, Prof. M. Harrison

7. Appendix

7.1. SOME ELEMENTS OF LOTOS

This appendix introduces a few elements of the LOTOS language. The reader is referredto Bolognesi and Brinksma (1989) for a full tutorial. LOTOS is a hybrid specificationlanguage that consists of two-component languages: a processes algebra for the specifica-tion of the temporal ordering of the behaviour of system and the ACT-ONE abstractdata typing language. A system is described in LOTOS as a set of interacting processeswhich interact via gates. A simple process-definition is formulated as

process SidentifierT [Sgate listT](parameter list): SfunctionalityT :"

Sbehaviour expressionTwhere

Stype-definitionsTSprocess-definitionsT

endproc

The gate list specified the formal identifiers for the gates, i.e. the interaction pointsthrough which the process may communicate with its environment. The parameterlist refers to state parameters which are specified in ACT-ONE. The functionalitycan be designated as exit for a terminating process otherwise it is designated asnoexist. Behaviour expressions specify the sequencing of interactions. The simplestbehaviour expression is a process instantiation. More complex behaviour expressionsare built up by the composition of process instantiations with LOTOS operators.The LOTOS operators used in this paper and their meaning are summarized inTable A1.

A process may specify its participation is an interaction with an action declaration.This can be just a gate indentifier if no data communication is specified. It may involve

TABLE A1¹he syntax and semantics of the ¸O¹OS operators used in the paper

Name Syntax Axioms and inference rules

Inaction stopTermination exit exit d" stopAction prefix g; B g; B g" BChoice B

i[ ]B

2if B

1a"B@

1then B

1[ ]B

2a" B@

1if B

2a"B@

1then B

2[ ]B

2a" B@

2Enabling B

1AB

2if B

1a"B@

1, aOd then B

1AB

2a" B@

1AB

2if B

1d" stop then B

1AB

2i" B

2Disabling B

1['B

2if B

1a"B@

1, aOd then B

1['B

2a" B@

1['B

2if B

1d"B@

1then B

1['B

2d" B@

1if B

2a"B@

2then B

1['B

2a" B@

2Hiding hide G in B If B a" B@, a3G then hide G in B i" hide G in B@

If B a" B@, aNG then hide G in B a" hide G in B@Renaming B [H] if Ba a" B@ then B [H] H(a)&" B@ [H]Parallel composition B

1D [G] DB

2ifB

1a" B@

1,aNGXMdNthenB

1D[G] DB

2a" B@

1D [G] DB

2if B

2a" B@

2, aNGXMdN then B

1D[G] DB

2a" B

1D [G] DB@

2if B

1a" B@

1, B

2a" B@

2, aNGXMdN then B

1D[G] DB

2a" B@1

D [G] DB@2

TABLE A2Some notation to describe traces of processes. ¹races are sequences of observable actions

which describe transitions from the initial state q of a process to some other state r

Notation Meaning

q k1. .k

n&&" r &q12

qn3Q D q k

1&" q1

k2&" q

2P2Pq

n~1kn&" r

q Ne r q,r s&n*1 D q qn&" r

q Nk r &q1, q

23Q D q Ne q

1k&" q

2Ne r

q Nk1. .k

n r &q1. . q

n~13Q D q N

k1 q

1N

k22N

kn~1 q

n~1N

kn r

q Nk1. .k

n &/r3Q D q Nk1. . k

n rTr (q) D p3A* D &r3Q )) q Np r D


an output of some value, e.g., g ! v where v is a value. A LOTOS action declarationmay also take the form g?x:t, where x is a name of a variable and t is a sortidentifier indicating the domain of values over which x ranges. This corresponds to aset of possible actions for the behaviour expression. For example, g?x:integerspecifies a set of actions gSvT wjere SvT is in the domain of the integers. Supposeprocesses A and B are composed in parallel over a gate g as in A D[g] DB. If A offersa value over that gate, e.g. g!true and B offers any event g?x:Boolean, then the value trueis passed from A to B.

Table A2 illustrates some notation for describing the transitions and traces of LOTOSprcesses, where s k" r denotes a transition from a state s to a state r which is labelled byan action k.


A relation R-Q]Q is a strong bisimulation relation on Q iff ∀ (P, S)3R, ∀a3AX(q)the following holds:

P a" P@ N &S@ D (P@, S@)3R ) S a" S@,

S a" S@ N &P@ D (P@, S@)3R ) P a" P@,

Two processes P and S are called strong bisimulation equivalent if there exists a strongbisimulation relation R relating their initial states, i.e. (p

0, s

0)3R. By substituting aP

wih Na in the definitions above we obtain the weak bisimulation relation and the weakbisimulation equivalence, denoted as P+Q.

These definitions extend to full LOTOS processes. Two LOTOS behaviour expres-sions P and Q with all their free value-identifiers contained Mx

1,2, x

nN are weak (strong)

bisimuilation equivalent, if all instances [E1/x

1,2,E

n/x

n]P and [E

1/x

1,2 ,E

n/x

n]Q

are weak (respectively strong) bisimulation equivalent where E1,2, E

n, are closed value

expressions of the same sort as x1,2 ,x

nrespectively.

7.2. SPECIFICATION EXTRACTS FOR THE SCROLLABLE LIST EXAMPLE

The data types sliderBar and bounded»al specify the display and the abstraction datatypes for the slider interactor, or Section 3.2. Bounded»al supports three inquiry opera-tions that return the upper and lower bounds and the value that ranges between them,and operations to set this value:

type boundeVal is Integer

sorts

boundValue

opns

lo, val, hi: boundValue P Int

setVal: boundValue, Int P bound Value

incr. decr: boundValue P boundValue

eqns

forall b:boundValue, n: Int

of sort Int

val (setVal (b, n))"n;

lo(setVal(b, n))"lo(b);

hi(setVal(b, n))"hi(b);

ofsort bool

lo(b) le val (b)"true;

val(b) le hi(b)"true;

of sort boundValue

incr(setVal (b, n))"setVal(b, s(n));

decr(setVal(b, n))"setVal(b, p(n));

endtype

A simple and abstract model of a slider bar is characterized by two graphicalentities: a rectangle and a point. The data type Graphics which models suchbasic graphical entities is extended by sliderBar, but it is not necessary to describe


it below. The operations on a slider may change or return the value of the rectangle andthe point:

type sliderBar is Graphics

sorts

sliderBar

opns

mksliderBar: rct, pnt P sliderBar

changePnt: sliderBar, pnt P sliderBar

changeRect: sliderBar, rct P sliderBar

rect: sliderBar P rct

point: sliderBar P pnt

eqns

forall p:pnt,r:rct,sb:sliderBar

ofsort rect

rect (mksliderBar (r, p))"r;

rect (changeRect (sb, r))"r;

rect (changePnt (sb, p))"rect(sb);

ofsort pnt

point(mksliderBar (r, p)"p;

point(changeRect (sb, r))"point (sb);

point(changePnt (sb, p))"p;

endtype

The specification of the entities displayed, like sliderBar above, may use a standardmodel of the display at a uniform level of abstraction for all interactors. The specificationdata type for the abstraction like Bounded»al in this example, may specify the domainsemantics. Such specifications could be refined to increasing levels of detail withoutmodifying the interactor specification.

The data type ad for the list interactor is ls—ad defined as follows:

type ls—ad is lstElement, scrList

opns

input: pnt, scrLst, lstel P lstel

echo: pnt, scrLst, lstel P scrLst

input: Int, scrLst, lstel P lstel

echo: Int, scrLst, lstel P scrLst

render: scrLst, lstel P scrLst

receive: lstel, lstel P lstel

result: lstel P el

eqns

forall m:Int, p:pnt, s:scrLst, w,wold, wnew:lstel

ofsort lstel

input (p, s, w)"sel (w, pick(s, p));

input (m, s, w)"setstart (w, m);

receive (wold, wnew)"wnew;


ofsort scrLst

echo (p, s, we)"changeLne(s, pick(s, p));

render (render(s, wold), wnew)"render (s, wnew);

ofsort el

result (w)"which(w);

endtype

The data type ls—ad combined lstElements, which models a list of elements, and scr¸ist,which models the graphical display of the list. Its signature follows by substitution fromthe general definition of ad. The sort of the abstraction parameter is lstel and the sort ofthe display parameters of the interactor is scr¸st. lstElements defines an enquiry operatorwhich(lstel) that returns the selected element of the list. scr¸ist is associated withoperation pick(scr¸st,pnt) which returns an index of the displayed window (i.e. a line oricon number) given a cursor position pnt. An element selection for lstElements can be setby sel(lstel, Int). Finally, the position of the window with respect to the list, is set byoperation setstart(lstel, Int) which uses the data sent from the slider bar.

type lstElemets is Integer

sorts

lstel, el

opns

sel: lstel, Int P lstel

setstart: lstel, Int P lstel

which: lstel P el

wnstart: lstel P Int

eqns

forall W: lstel, N,M: Int

ofsort Int

wnstart(setstart(W, N))"N;

wnstart(sel (W, N))"wnstart (W);

ofsort lstel

sel (sel (W, N), M)"sel (W, M)

sel (setstart (W, N), M)"sel (W, M);

ofsort el

which (setstart (W, M))"which (W);

endtype

type scrList is Integer, Graphics

sorts

scrLst

opns

mkscrLst: rct, Int P scrLst

changeLne: scrLst, Int P scrLst

changeRect: scrLst rct P scrLst

pick: scrLst, pnt P Int

rect: scrLst P rct

line: scrLst P Int


eqns

forall l:Int, r:rct, sl:scrLst, p:pnt

orsort rct

rect(mkscrLst(r, l))"r;

rect(changeRect(sl, r))"r;

rect(changeLne (sl, l))"rect(sl);

ofsort Int

line(mkscrLst(r, l))"l;

line(changeRect(sl, r))"line (sl);

line(changeLne (sl, l))"1;

pick(changeLne (sl, l), p)"pick(sl, p);

endtype

formal architectural abstractions for interactive software

Documents