Formal Specication of User Interface Design

Guidelines
Judith Alyson Bowen
March 16, 2005
Abstract
Formal specication allows us to design and model the behaviour of computer
systems and test their correctness prior to implementation. For any sort of
computer system, the problems of being sure you have asked for the right
thing (validating the specication against the users requirements) and then
being sure you are implementing the right thing (verifying the implementation
relative to the specication) are important and hard problems. If the system
also has a user interface, which is true in the majority of cases, there are the
analogous additional problems of making sure that the interface allows any
interaction that is required, and works in a usable way. Graphical user interface
design guidelines are used in both the design and evaluation of user interfaces
to try and ensure that the systems we build are usable. This project aims to
use formal methods to specify systems and their graphical user interfaces and
model guidelines for interface design. These will then be used together as the
basis for proving the usability properties of a specied system given by the
design guidelines.
i
Acknowledgments
I would like to thank my supervisor, Professor Steve Reeves, for his support,
encouragement and advice during this project. I would also like to thank
Greg Reeve for his willingness to talk over ideas and provide helpful advice on
a wide range of subjects. Thanks to the Computer Science department and
Waikato University Scholarships department for providing funding to support
my work. Also, for helpful comments on presentations and papers based on
this work I would like to express my gratitude to Petra Malik, David Streader,
the attendees of FM in NZ 2004 and the anonymous reviewers for ZB2005.
Finally, none of this would have been possible without the ongoing support of
Jane Stokes and the light relief provided by Mac and Mabel.
iii
Contents
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Dening the Problem . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Report Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Formal Specication of Graphical User
Interfaces 15
2.1 Why Do It? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Abstraction Levels and Details . . . . . . . . . . . . . . . . . . . 19
2.3 Experimenting With Dierent Approaches . . . . . . . . . . . . 21
2.4 The Z Interface Specication Framework . . . . . . . . . . . . . 27
2.5 Simple Interface Specication Example . . . . . . . . . . . . . . 46
3 User Interface Design Guidelines 55
3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2 Guideline Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3 Using Guidelines in the Design Process . . . . . . . . . . . . . . 58
3.4 Introducing Guidelines to the Specication Process . . . . . . . 60
4 Formal Specication of Guidelines 63
4.1 Structure and Abstraction in Guideline Documents . . . . . . . 65
4.2 Formatting the Guideline Specication . . . . . . . . . . . . . . 70
4.3 Putting the Guidelines to Work . . . . . . . . . . . . . . . . . . 75
5 Examples and Applications 81
5.1 Renement Assistance . . . . . . . . . . . . . . . . . . . . . . . 81
5.2 Tests and Proofs . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 Bringing it Together . . . . . . . . . . . . . . . . . . . . . . . . 100
v
5.4 A Safety Critical System . . . . . . . . . . . . . . . . . . . . . . 103
5.5 A Real World Interface . . . . . . . . . . . . . . . . . . . . . . . 136
6 Assisting Designers 167
6.1 Making the Design Process Easier . . . . . . . . . . . . . . . . . 167
6.2 Renement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
6.3 Design Processes and Support Tools . . . . . . . . . . . . . . . . 179
7 Conclusions 187
7.1 Overview of Project Goals . . . . . . . . . . . . . . . . . . . . . 187
7.2 Summary of Results . . . . . . . . . . . . . . . . . . . . . . . . 188
7.3 Problems Encountered and Solutions Found . . . . . . . . . . . 191
7.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
7.5 Final Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
8 Appendices 199
vi
List of Figures
1 Renement from Specication to Implementation . . . . . . . . 2
2 Blackbox Model of System . . . . . . . . . . . . . . . . . . . . . 2
3 Blackbox Model of Interface and System . . . . . . . . . . . . . 3
4 -chart GUI Example . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Hello World -chart Example . . . . . . . . . . . . . . . . . . . 50
6 Categorisation of Guidelines . . . . . . . . . . . . . . . . . . . . 67
7 Event Generator Decision Tree . . . . . . . . . . . . . . . . . . . 84
8 Widget Options for FontSizeControl . . . . . . . . . . . . . . . . 87
9 Interface Given by Knight and Brilliant . . . . . . . . . . . . . . 104
10 Interface Given by Knight and Brilliant . . . . . . . . . . . . . . 134
11 Magnetic Current Control . . . . . . . . . . . . . . . . . . . . . 134
12 Opening Screen of GNOME PDFViewer . . . . . . . . . . . . . 160
13 Hello World Designs One and Two . . . . . . . . . . . . . . . . 169
14 Hello World Design Three . . . . . . . . . . . . . . . . . . . . . 169
15 Example GUI Created in Visual Basic . . . . . . . . . . . . . . 182
16 Extended Visual Basic Tool Prototype . . . . . . . . . . . . . . 185
17 Event Generator Decision Tree . . . . . . . . . . . . . . . . . . . 217
18 Event Responder Decision Tree . . . . . . . . . . . . . . . . . . 217
19 Display Decision Tree . . . . . . . . . . . . . . . . . . . . . . . . 218
vii
1 Introduction
1.1 Background
Designing and building complex computer software systems is a dicult task
requiring precision. Before we can start to build a system we must gather
the requirements of the systems users and ensure that we fully understand
what these are. From this we determine what it is that the nal system is
supposed to do, and, equally importantly, what it should not do. We must
also identify what the inputs to the system are and what its outputs are. At
this rst stage in the software development cycle we are not concerned with
how these things will be achieved, but we must nd a way to describe and
understand them so we can be sure we have a correct description. We do
this by building some abstract model of the system which we can use as the
basis for such understanding. Once we are sure we have correctly captured the
required behaviours for our system and are sure that both our understanding
and our abstract model are correct we can move on to the process of actually
building the system.
Z [52] [1] is a formal language used to specify and design software sys-
tems with the aim of producing demonstrably correct software. It is based on
set theory and mathematical notation, and uses semantics based on classical
mathematics which allows us to perform formal proofs using predicate calcu-
lus. Once we have a specication of a system in Z we can then use renement
to assist us with the building of that system based on the model. One of the
advantages of this is that we have a renement theory in Z which allows us
to prove the correctness of our nal system, if we can prove it is a correct
renement of our model. There may be many possible nal systems which
we can derive from our model, but as long as each can be shown to follow
a formal renement from the Z specication then any one of them will be a
correct implementation of the system.
Renement is generally not performed as one step from specication to
1
implementation. In [19] Diller states that:
the distance between the specication and programming language
constructs may sometimes seem far too great to bridge. Thus in
these cases it is often a good idea to write another specication
which uses less abstract data types and more algorithmic con-
structs in it.
The eect of this is that it leads us to perform a series of renements, starting
with the original most abstract specication and moving towards a concrete
implementation, with each stage producing a less abstract specication. If we
think of a line connecting the most abstract specication to the nal concrete
implementation then our renements are points along that line, where each
point represents a specication which is more concrete than those that precede
it and more abstract than those that come after it. This is illustrated in gure
1.
Figure 1: Renement from Specication to Implementation
We stated that in specications we are interested in identifying the inputs
and outputs of the system. We are not interested in the detail of how these
inputs are dealt with by the system or how the outputs are generated. This
is often described as a blackbox model and can be visually described as in
gure 2.
Figure 2: Blackbox Model of System
2
Having specied a provably correct system and then rened it to a provably
correct implementation, we need to provide a way for users to interact with
the system. This is done through the user interface. User interfaces in gen-
eral and graphical user interfaces (GUIs) in particular consist of some visual
representation of a system and some method for a user to interact with that
system. In recent years, this has most commonly been via the WIMP model
(Windows, icons, menus and pointers) but new methods of interaction (virtual
reality tools, walk through interfaces, gesture based interaction, speech input
etc.) are becoming increasingly common. In terms of an abstract model of a
system however, all of these methods of interaction can be viewed in the same
way. Namely they provide a way for the user to provide input to and receive
output from the system. Considered in this way we can extend the model we
gave in gure 2 to that given in gure 3
Figure 3: Blackbox Model of Interface and System
In our formal specications we may have abstracted away the details of
how the user interaction occurs, but in the research eld of Human Computer
Interaction (HCI) these are the very details which must be examined with as
much care as we might examine the formal specication. It is not enough that
a system is provably correct in its behaviour if a user is unable to interact with
the system in a way which allows them to derive this behaviour. We need,
therefore, to not just build correct systems, but systems which allow people
to correctly use them most of the time. Dierent research areas within the
HCI eld focus on dierent ways of achieving this. These may be divided into
those things that occur at the design stage, such as gathering user require-
ments, task modelling, interface prototyping etc., and those that occur after a
3
prototype or implementation has been built and which involve various forms
of usability evaluation such as heuristic testing, cognitive walkthroughs, user
studies etc. As such, the goals of this HCI research can be likened to the goals
of those working in formal methods, that of nding ways of ensuring that sys-
tem implementations meet the given requirements. The dierence is that the
requirements of the formal specication are usually those of the underlying
system behaviour, whereas the requirements considered in HCI are those of
the user and the behaviour of the interface to that system.
Having reasoned that the aims of formal specication and HCI research
have much in common, we begin to consider how we can nd ways to bring
together work from these areas. In particular, we consider what parts of inter-
face design and HCI can usefully be incorporated at the formal specication
stage. Our investigations into dierent HCI concerns led us to focus on GUI
design guidelines. These are bodies of information containing best-practice
knowledge of interface design. They are rules which inform designers of the
things they could, and should, do when building their GUIs to ensure they do
not include known usability problems. Generally, guidelines are consulted dur-
ing the implementation of an interface, but they can also be used as part of the
evaluation process in heuristic testing. Having a set of rules which exist prior
to implementation with known qualities that are required is not unusual within
formal specication. We have already stated that prior to specifying a system
we gather such requirements and use this as a basis for that specication. We
felt that this similarity between guidelines and the sorts of requirements we
might use in a specication was an interesting area for research and may lead
to exactly the sort of links we were looking for between formal specication
and usability issues of GUIs.
1.2 Related Work
Including the interface to a system within the formal specication of that
system is not a new idea. Many research projects have focused on exactly this
4
problem and have derived dierent ways of capturing the interface in a way
which allows an abstract specication to be described. A good introduction to
the background of this research can be found in the publications of Dix [22],
and the two collections of papers both entitled Formal Methods in HCI, [43]
and [27].
Historically, the sorts of interfaces which were being formalised were very
dierent from todays GUIs, with their increasingly complex modes of interac-
tion. Early interfaces were often nothing more than command line interactions
where users typed in commands which could be interpreted by the system.
Describing these kinds of interfaces formally required identifying the possi-
ble commands a user could issue and the allowable sequence of events that
could occur in a system in response to these commands. In this respect, much
of this earlier work described interactive systems by treating the interface as
a separate system and isolating it from the underlying system specication.
This is still a common way of thinking about interfaces, not just in formal
specication, but also in the interface design world. This separation is often
portrayed as a sensible approach and its proponents base many of their ideas
on the description of the Seeheim Model give by Pfa [44]. One of the poten-
tial problems of such a separation, however, is that it becomes very dicult to
prove properties about the whole system, or be sure that when the two parts
are brought back together they will inter-operate as expected.
There is a considerable body of work on specifying interactive systems
which concentrates on the behaviour of the interactivity without considering
the interface itself. Such work often includes descriptions of interactivity as
event/action pairs and examines the allowable behaviours of interactions. This
is then used to prove properties about the interface such as the reachability of
all possible system states. The most notable method based on interaction as a
sequence of events and actions is the PIE method. PIE was rst described by
Dix and Runciman [21] and is based on the notion of a triple, < P,I,E > where
P is a set of programs (and programs themselves are a sequence of commands),
5
E is a set of possible eects (the things that happen in the system in response
to the programs) and I is a function from P to E. Whilst PIE concentrates on
the interactions which may occur in the system there is no attempt to capture
how that interaction will occur. An adaptation of the method called red-PIE
makes a further distinction between eects which are visible to the user and
those which are not. It uses the assumption that some way of providing the
described interaction will be given in a nal implementation and does not
consider whether or not this will be graphical or textual, or how usable it will
be for the users. This is not an uncommon feature of much of the research
which has been done on specifying interfaces, or rather, specifying interactive
systems.
Another popular approach to formalising interfaces is the use of the In-
teractor model. First described by Duke and Harrison in [23], Interactors are
self-contained units which detail structures and relationships of concern to in-
terface designers. An Interactor consists of: an internal state which represents
some part of the system functionality which is being controlled by the interface;
a perceivable state which represents what the information that the user can
perceive about the system via some presentation; the actions that cause these
two states to change. Interactors have been used by many dierent people in
such areas as task analysis, dialogue modelling, events and process modelling
and modelling of temporal issues.
One of the things that both PIE and Interactors have in common is their
focus on the behaviour of the interaction, rather than on the representation of
the interface itself. This is common to much of the other work in this area,
even where that work has been used to prove properties of the interface such
as observable dierence between system states after events, as is found in
the work of Anderson [3]. Despite using terminology such as displays and
perceivable states these are abstract concepts within such work: the methods
used do not describe the interface itself, just the interaction between user and
system. Whilst this in no way undermines the usefulness of such methods it
6
does mean that they were not suitable for our aim of describing the interfaces
in a way which allowed us to consider human factors by way of including design
guidelines.
Research that is more focused on formalisms that include usability issues of
interfaces includes the work of Jacquot and Quesnot [32] which aims to build
interface models which can be used to highlight early mismatches between
users expected behaviour and interaction constraints of interfaces. Their work
looks at the links between events, procedure activation and feedback reaction.
It includes a formal description language used to describe the interface and
creates an initial plan using a procedure which has been developed along the
lines of other formal task analysis methods used in HCI such as GOMS [11],
PAC [13] etc. Once again, however, this work does not concern itself with
interfaces at a level where we may be able to consider the sorts of specic
requirements we nd in design guidelines.
An example of works which do focus very clearly on details about appear-
ance of interfaces in a manner designed to incorporate usability factors are
those by Kim and Foley [38] and Sears [49]. These use the idea of examining
the complexity of interfaces based on layout metrics derived for the position-
ing of the interface elements such as buttons, scrollbars, menus etc. (we will
hereafter refer to such things by the generic term widgets). Kim and Foley
assign a cost formula to their layouts based on measurements of time and
user preferences for navigation of interfaces. Such work contains much more
detailed descriptions of interfaces, but is less concerned with the overall be-
haviour of the interface and its link to the underlying system. There is also
an area of research which looks at ways of automatically generating user in-
terfaces. Researchers in this area have developed many dierent formalisms
which they then use for describing the interface. This subsequently allows
them to automatically generate the described interface. There is a great deal
of interesting and informative work in this area, such as that by Bodart, Hen-
nebert, Leheureux and Vanderdonckt [9] and many other contributers to the
7
CADUI conferences [10].
The amount and the range of work which has been done across the spectrum
of the use of formalisms in interface design and HCI shows just what a dicult
problem it is. Despite the many dierent approaches that have been tried there
still does not appear to be one accepted method that adequately captures all
of the things we might expect. Consequently, there is also research based
on trying to determine why this is and what the problems are. Jacob [31]
comments that
Previous user interface specications have suered because they
lacked an acceptable language for describing the semantics of the
interface, that is the actions that the system performs in response
to the users commands. A complete description of such actions
clutters the specication.
and goes on to list what he believes is needed to successfully specify interfaces:
The specication of a user interface should be easy to understand
and take less eort to produce than the software that implements
the user interface.
It must be powerful enough to express nontrivial system behaviour
with a minimum of complexity.
It should be possible to produce a prototype directly from the spec-
ication.
It should be related to the users mental model of the system itself.
These are large and dicult problems to tackle. Similar concerns have been
raised by Rou [48] who describes how specications are often too complicated
to be understood except by a small group of people, and that the specication
should be capable of supporting the design. It is clear, therefore, that in
tackling the problems we have chosen to focus on, we will have many other
considerations to deal with. Many of the issues raised in the literature will
need to be addressed as they arise within our own research.
8
Whilst I have tried to discuss many of the important works we have come
across in our research, there are, not surprisingly, too many to detail in full. Of
those we have not discussed, however, there are some particularly interesting
examples which should be mentioned as having had an impact on our thoughts
and direction during this project. These are the works by Rosis and Pizzutilo
[15], Fevzi Belli [8], Sufrin [53], Syst a [54] and Gray and Johnson [25].
1.3 Dening the Problem
We were interested in nding ways of incorporating interface design concerns
into formal specications. Specically we wanted to look at how, and indeed if,
it was possible to somehow use interface design guidelines at the specication
stage. From the literature it was clear that many dierent approaches had
been taken to formalising interactivity and interfaces. In addition, several
dierent areas of work had looked at ways of trying to formalise particular HCI
concerns such as temporal issues in interfaces and layout metrics of interfaces.
The results gained from some of this work encouraged us to believe that there
was a sound basis for the fundamental idea of our research and allowed us to
dene more clearly what it was we wanted to study.
The focus of this project then was to look at whether it was possible to
include user interface design guidelines at the specication stage. In particu-
lar we wanted to know how we could actually make this inclusion and what
the benets would be at both the specication stage and the implementation
stage. Our initial research led us to widen the scope of the project to also
include considerations of levels of abstraction within both specications and
guidelines. This in turn made us consider what were useful ways of specify-
ing the interface in the specication which would enable us to subsequently
include the guidelines. Finally we wanted to see whether we could apply the
same sort of formal proofs and testing which we would expect to use on our
specications to test for adherence to the design guidelines.
In formulating a plan to try and solve these questions we had to make
9
a number of early decisions which would allow us to focus our work. There
are many dierent sets of interface design guidelines in existence both in the
public and private domain. Although there is clearly a core of these dierent
guidelines which contains much that is common to them all, there are also
many elements within them which are domain specic or based on dierent
values. While we wanted to produce a general solution which would allow any
guidelines to be incorporated into formal specications we decided to focus
on three dierent sets of guidelines for the purposes of our research. The
rst of these is Smith and Mosiers Guidelines for Designing User Interface
Software [51] which is an early example of a comprehensive set of guidelines
often referred to by other sets of guidelines. The second is the Apple Human
Interface Guidelines [4]. This is a platform-specic set of guidelines which
include not only general best-practice knowledge but also platform-specic
design and appearance issues. The third set we chose to concentrate on is
the GNOME Human Interface Guidelines (1.0) [24]. Again this is platform-
specic, but as part of the GNU project the guidelines have been developed and
contributed to by a large body of people and are continually evolving. Whilst
these were the focus of our research we also made reference to a number of other
guidelines, most notably the Microsoft MSDN Interface Design Rules [40],
CUErgos Ergonomic Guidelines for User-Interface Design [12], and IBMs
Design Concepts [28], as well as useful points of reference such as the Isys
Interface Hall of Shame [29] and Nielsens Alertbox columns [2].
It was also clear that if we were to nd a way to successfully include our
chosen guidelines into formal specications we would need to decide upon a
consistent way of describing interfaces within that specication. As we have
already discussed, there have been many dierent approaches taken to this
problem, but for our purposes we would need to settle upon a method which
would be appropriate for guideline inclusion. There was no one single solution
from previous research which was appropriate for this task and so we would
need to nd our own way of using Z to describe interfaces within specications.
10
Not only did we need to nd a method for using Z for this purpose, but we
also needed to do so in a way which would enable us to formally verify the
specication, including verifying that our stated guidelines had been met.
1.4 Report Outline
Section two of this report examines the merits and potential problems of in-
cluding the user interface within a formal system specication. A number of
dierent approaches to specifying the GUI are discussed before we present an
interface description framework which has been devised as the basis for the rest
of our work. At the end of this section we present a small example interface
and show how this could be specied using the framework we have given.
Section three discusses system design guidelines in general and interface
design guidelines in particular. Some background to guidelines is given, in-
cluding how they are generated as well as some insight into why they are used
and the benets they can give us. Ways of using guidelines in the design pro-
cess are discussed along with some of the problems that can occur. Finally we
describe how and why they may be used as part of a formal specication.
Section four shows how we can follow the interface specication framework
presented in section two for describing the guidelines themselves. We dis-
cuss the importance of this in relation to our work and show how this allows
us to bring guidelines into the specication in a simple, but eective, man-
ner. Methods for making the guidelines work with the interface specication
are presented and discussed, and examples given from a number of dierent
guideline sets. At the end of this section we begin to outline what benets
incorporating the guidelines into specications may have and how we can go
about achieving this practically.
Section ve presents a number of examples of applications of our work.
First we present examples showing the prime uses of our work in interface
specication. We then discuss how we can use proofs and testing to gain the
most benet from our work. We next present two larger examples to show our
11
work in context. The rst of these larger examples looks at applications of
our work to safety critical systems, using an example from a proposed nuclear
power plant interface. The second shows how our work can be applied to an
existing application.
Section six considers the process of designing interfaces from the perspec-
tive of the designer rather than the formal specier. In this section we show
how our work can be used to assist designers in their decision making giving
them greater creative freedom in their designs. We discuss making our work
accessible and understandable for people who are not Z experts or experienced
in formal specication and show how possible support tools may assist with
this.
Finally we present our conclusions. Here we revisit our original goals and
show how these have been met and what we have achieved during the process.
In this section we also present some of the problems and challenges we have
encountered and describe how these were overcome or used as a basis to change
the direction of the work and further the overall project. We discuss possible
future work leading on from this project before presenting a summary of our
nal conclusions.
1.5 Summary
To summarise, we had identied the problem we wished to investigate with
our research which was to nd a way to include user interface design guidelines
into the formal specication of a system given in Z. We then wanted to see if we
could use these guidelines to prove some properties of the specication which
were given by those guidelines. Finally we wanted to determine how useful
this would be both at the formal specication stage and at the implementation
stage and whether we could be sure that such a specication meant that we
would implement an interface which adhered to the guidelines.
We had also satised ourselves that there was no previous research which
was directly related to this problem, although there is a large body of work
12
relating to interface specication which we could use to help direct our work.
There has also been work done on formalising various usability issues and this
again may prove useful in our research.
Our plan was to rst investigate the nature of guidelines and see how we
thought they could be included in specications. Then we would look at nding
a method of formally specifying GUIs in Z. Next we would see how we could
use this formal specication with the guidelines to prove properties about the
specied interface. This would give us an indication of how useful such work
may be and suggest ways of improving our methods. Finally we would try to
determine how useful we felt this would be, and how easy it would be for both
formal methods practitioners and interface designers to adopt.
13
2 Formal Specication of Graphical User
Interfaces
2.1 Why Do It?
One of the aims of this project is to nd a way to incorporate GUI design
guidelines into a formal specication of the system. In order to do this we
need to include a description of the GUI itself as part of our specication.
However, our reasons for wanting to include GUIs within a specication in
general go beyond the scope of just this project. There are a number of im-
portant considerations which make this inclusion desirable. If we believe that
formally specifying a system prior to implementing it is a good thing, which
we do, then we can apply the same arguments we use to support this belief to
support the inclusion of GUIs into those specication.
In [31], Jacob comments that:
The user interface is a critical element in a software system and
one is handicapped in trying to design a good user interface without
a clear and precise technique for specifying such interfaces.
There are many dierent methods used to provide a description of an inter-
face prior to building it. These include things like paper sketches of possible
versions of the interface, building non-functional or partially-functional pro-
totypes, using the results of task analysis methods such as GOMS [11] as the
basis etc. Whilst these methods can be very successful at providing some ini-
tial artefact that can be shared by designers and end-users as a discussion tool,
and can be the basis for the implementation of the GUI, there is no way of
formally verifying or proving properties of such models. This is no dierent to
the idea of making informal notes and plans for the system design; it is better
than doing nothing, but is is not as reliable as having an unambiguous model
which can be formally proven to adhere to behavioural requirements and have
particular properties.
15
There are, in addition, some problems with using models such as incremen-
tal prototypes as the basis for interface design. If an early prototype contains
an error or problem which is not noticed at the prototype stage then it is pos-
sible for this to be built into the nal system where it will undoubtedly cause
problems at some later stage. If we have a design procedure which allows for
a formal model of the underlying system and an informal model for the GUI,
then it is virtually impossible to usefully compare the two things or show how
they can be linked together until we are at the implementation stage. By
then, if there are any problems with the linking it is much harder to x them.
Making changes at this stage is harder and more costly than getting it right
at the specication stage.
When we write a formal specication of a system what we are concerned
with is the what rather than the how. That is, we specify the things that the
system will do, but we do not want to include the details of how this will be
achieved. Typically this means that we choose a level of abstraction which
allows us ignore considerations of how the system will be nally implemented.
We do not want to consider programming languages, or programming styles, or
data types: our focus is on capturing the behaviour of the system in isolation
from such detail. This allows us to use formal languages, such as Z, which
can then subsequently be used to prove properties of our specication and
ensure that the behaviour we have described is what we expect and is correct.
We can also, by a process of renement, transform this correct specication
into an implementation and be sure that we still have the desired and correct
behaviour. It is easy, and not uncommon, to dismiss the GUI as being part
of the how, and assume therefore that it should not be included within an
abstract description.
The GUI is itself just another part of the entire system which also has
behaviour which can be abstracted away from its implementation. This be-
haviour may include things like displaying information or receiving user input,
and we can specify such behaviour without any consideration of how these will
16
be implemented in a nal system in just the same was as we can the under-
lying system. In some cases parts of the system functionality are the same as
the interface functionality. For example if the system provides an operation
to change some part of the systems state it is entirely possible that this will
ultimately be achieved by some user interaction with the interface. There are
other parts of the GUI behaviour however that may be entirely separate from
the underlying system operations.
If we consider the behaviour of modern GUIs and the way users interact
with them, we know that we are often presented with dierent windows during
our interaction. Sometimes we have one main window which remains visible
for the duration of our session with the application and other windows in the
form of dialogues or pop up windows will appear and disappear. Or it may
be that the application itself has a number of windows which are required
and visible at all times, for example toolboxes and palettes used in graphics
programmes. It is clear that the visibility and presence of dierent windows
at dierent times can be considered to be part of the systems state, and
correctness of the behaviour of this part of the state is just as important as
the correctness of any other part of the system state. In fact if we have correctly
specied a system operation but that operation can never be invoked because
the interface to the system has not been correctly specied and the user has
no way of accessing that operation then the system we have described is not
correct, it no longer allows the behaviour we require because parts of the state
have become unreachable. Removing considerations of the interface in our
specication therefore does not allow us to be sure we have fully and correctly
specied the system. Jacky [30] describes one of the purposes of specication
as:
.. to provide a complete and unambiguous description of what the
system will do.
If we concentrate our eorts on specifying the behaviour of the system without
considering the GUI at all then we cannot truly be said to be providing a
17
complete description of that system.
It is, of course, possible to maintain the idea of separating the GUI and the
underlying system and still formally specify the GUI. The two things can be
done as individual models with the intention of bringing them together once
they have been rened separately and we are ready to move onto implementa-
tion. We feel, however, that it is not enough to have just a formal specication
of the interface, but that it needs to be part of the entire system specication.
The two things are inherently connected and should be related together at the
earliest possible stage to avoid problems with trying to bring the two things to-
gether later. If we have two separate models of the one system which have been
separately validated and veried, then once we have completed the process of
bringing the two specications together, which may not be a straightforward
task, we have to reverify our whole system, or risk introducing errors in the
whole implementation.
It is true that specifying user interfaces in a formal language such as Z
can lead to something which is inherently much more complex than other
design models. For example paper-based designs and prototypes are relatively
straightforward artefacts which a designer and potential future user can discuss
with a reasonable level of understanding, and so may seem preferable to using a
formal notation. However informal notations can hide many problems. There
is no guarantee that what one person understands from the informal model is
the same as what the other person understands. There may be ambiguity and
while they appear easy to interpret and can show that a GUI can do what is
required, they may also hide unwanted behaviour and not necessarily expose
underlying problems.
Depending on the scale of the project the interface and underlying system
may be built by the same person/people, or by dierent people. Both groups
need to share the same vision of the system and understand how they work
together, the vision must be the same. At the implementation stage, depending
on the programming language and programming paradigm we are using, we
18
may separate the interface and the system, just as we may separate parts of the
system itself. But this separation is just a way of managing the implementation
and it is vital that all those involved in this implementation are working to
the same goal. A single, veried formal specication of the entire system is
the most appropriate way to ensure that not only is the goal the same, but
the goal is the correct one.
With a clear understanding that formally specifying the GUI is an impor-
tant part of the software engineering process, and that it should be part of
the overall system specication, we now need to look at how we can go about
achieving this in a clear and useful manner in Z. The rest of this section looks
at some of the dierent issues we faced and the dierent models we considered,
before we present the framework that we decided upon.
2.2 Abstraction Levels and Details
When we write specications we do so to create a formal and unambiguous
model of a system that we can verify, validate and prove properties about.
At the same time we also want to create something that is clearly expressed,
easy to understand and has enough detail to adequately capture the system
requirements without being overly complicated. Including the GUI into the
specication should do nothing to change the readability or clarity of that
specication.
Traditionally, models of GUIs, which may include such things as sketches
or paper prototypes, often exist at just one level of abstraction, that of the
actual GUI. We consider pictures of the interface (by which we mean textual
descriptions as well as actual drawings) as the meaning of the interface and
cannot easily nd models of the GUI which abstract away from this. So we may
talk about the GUI in terms of mouse-clicks on particular parts of the screen,
or about menus and buttons, the actual widgets of the GUI. It is hard to ignore
these low-level widgets without going back to the abstraction of models such
as PIE [21] and Interactors [23] which model the interaction between system
19
and interface rather than the GUI itself. We have already stated that these
models, although useful for many purposes, do not suit our work.
The challenge then is to nd the correct balance between describing too
much implementation-style detail or too little of the actual GUI. This problem
of capturing the detail of the GUI concisely is one of the things that leads many
people to the belief that we should not be including the GUI in specications
at all. Delisle and Garlin [17] present the argument that the specication
abstraction becomes complicated by adding presentation details and this can
obscure important system properties. However we feel that the problem is not
in the inclusion of GUI details, but in the inclusion of too much detail at the
wrong level of abstraction.
Johnson [37] presents arguments for representing GUIs in specications
as well as a method for doing so in Z. He describes how user input can be
abstracted away from the users actual input and represented in operation
schemas as input observations. His work in [37] presents changes to the GUI
as operation schemas which update parts of the system via parameters to other
operation schemas. Similarly for information to be displayed to the user via
output he describes operations on displays which change values to match those
of the system. This was very similar to want we wanted to achieve, although
we still wanted to include a more detail about the widgets of the interface
which Johnson abstracts away in his operation schema.
A dierent approach taken in the work of Syst a [54] uses a temporal logic
in conjunction with DisCo, an object-oriented formal specication method for
reactive systems [33]. The work itself does describe specic widgets at the
level of implementation, but examination of his methods in consideration with
Johnsons work [37] led us to think more about widgets and abstractions of
widgets which ultimately led to our decision to use a categorisation of widgets
in our own work. How we actually decided upon our nal model and how it
would be used is described at the end of this section.
At the same time as we were considering these issues of abstraction and
20
detail level, we were looking at dierent approaches to formalising the GUI
by experimenting with dierent ways of writing such specications in Z. Many
dierent approaches were considered, and rejected, but those which held the
most interest and which ultimately contributed to our nal model are discussed
next.
2.3 Experimenting With Dierent Approaches
Our research into the dierent approaches that have been taken to formally
specifying interactive systems, particularly those where Z had been used, had
already given us some ideas about the way we wanted to describe GUIs for-
mally. We identied the following three things which we needed to include in
our specication:
1. The system and its operations
2. The behaviour of the interface in terms of its widgets
3. The interaction between the interface and the system
The rst item is already well-documented in Z text books and case studies
such as [57] and [6]. It is not our intention to try and nd new and innovative
ways to use Z to describe systems, rather we are keen to use traditional styles
of Z and nd a way of describing the GUI in a way which ts in with this.
We began by looking at dierent ways of describing the GUIs behaviour in
terms of its widgets. Implementations of GUIs have much of their behaviour
encapsulated in events and event-handlers which provide much of the linking
between interface and system, so our focus became widgets and events. Early
work involved describing individual widgets, such as buttons, in Z and looking
at the dierent levels of detail required. Although this would not be abstract
enough for our nal model it did give us the opportunity to try out dierent
styles of Z and see which were most useful.
After several false-starts and attempts which were not satisfactory, we nar-
rowed the scope of our experimentation to focus on three dierent methods
21
of specication. The rst described individual widgets using schemas, with
observations to represent all of the attributes of that widget. So, for example,
we might describe a button as:
Button
shape : ButtonShape
color : ButtonColor
icon : ButtonIcon
textLabel : Label
eventGenerated : Event
Each of the dierent widgets of the interface could be described in this way,
with the eventGenerated observation replaced by an eventReceived observation
for widgets where this was more appropriate.
Our second method involved dening widgets as cross-products of sets of
things such as labels, events etc. and then describing parts of the GUI in
axiomatic denitions as follows:
BUTTON == ButtonName ButtonLabel Event
ROneButtons : PBUTTON
ROneButtons = (ROneUp, up, MoveUp),
(ROneStop, stop, Drop),
(ROneDown, down, MoveDown)
The third method involved the use of promotion. We described local oper-
ations on single widgets such as buttons, sliders etc. and then described the
interface as collections of these widgets with the local operations promoted
onto the global components. For example:
AllPushButtons = [pbuttons : ButtonID PushButtonW]
22
UpdatePushButtonW
PushButtonW
AllPushButtons
bid? : ButtonID
bid? dompbuttons
PushButtonW = pbuttons bid?
pbuttons

= pbuttons bid? PushButtonW

Using each of these methods we worked on three dierent examples, a

simple HelloWorld program, a shape drawing program, and sections of a
safety-critical system. The rst of these examples is reproduced at the end
of this section where we use it as an example of the Z framework we nally
decided upon. The other two examples are presented in section ve of this
report where we look at applications of our work.
The results of using these dierent methods on the dierent examples were
varied. The rst method, which we named the WERR method for Widgets,
Events, Relationships and Rules, allowed us to capture a lot of detail about the
GUI, but was very poor in terms of abstraction. This was not a problem for the
very small HelloWorld example which has only two widgets and one system
operation, but for the safety-critical example it was too involved and quickly
led to a specication which was overly long and hard to read. In contrast
the second method was much more abstract and led to more concise speci-
cations, but it had many similarities to the PIE model [21] in that it became
apparent that while it could usefully capture the interaction between system
and interface it was not good at capturing the behaviour of the interface. The
idea behind the promotion method was to try and describe individual widget
types and then describe the overall GUI as a collection of these widgets which
could be identied if required using identication numbers. The main problem
with this method was that we generally use promotion for collections of things
23
which behave in the same way, so that we have one local operation which can
apply to each item in the collection. However for widgets, even those which are
of the same type, for example all of the buttons, their behaviour may be very
dierent depending on their relationship with the underlying system. This
meant that the usual promotion model was not suitable.
Our experimentation had given us a number of ideas and possibilities that
were to develop into our nal solution, which we present next. However, there
was one other area of work we were exploring which took a dierent approach
to GUI specication and is worth discussing. Our aim was to use Z as the
formal language for our work, for the reasons given in section one of this report.
However, we were mindful that one of the problems of using a language like
Z to specify GUIs is that it is very removed from the language and notations
that the designers of interfaces generally use. As such our work may encounter
resistance when presented as a method that can be used not just by formal
experts, but also by those designers. We were interested in looking at a more
visual way of describing GUIs without losing the benets we required from
a formal model. For these reasons we began to investigate the use of the
-Charts language.
-Charts is a formal modelling or specication language, for specifying
reactive systems. It has a visual representation and a formal semantics which
is given in Z. A full description of -Charts and its Z model can be found in
[45] and [46]. Our reason for being interested in using -Charts was that we
wanted to see if having a visual model of the GUI, using a language with an
underlying Z representation, would give us additional benets over just having
a description in Z. We can consider GUIs as reactive systems in that they wait
for some input from the user and then they do something in response to that
input. If we ignore any temporal issues related to this and think of user actions
as a sequence then we can model this using -Charts.
As an example consider a system which has one operation and one control.
The system starts in some initial state and has an operation which moves it
24
to a nal state. The GUI has one control which allows the user to initiate
this change from initial to nal state. We can model this using the following
composed -chart:
OneSystem
Init
Final
FinalEvent
OneControl
NotActive
UserInput/FinalEvent
{FinalEvent}
Active
/
Figure 4: -chart GUI Example
This models the system as a reactive system which starts in the initial
state and waits for input from some part of the GUI. When it receives the
input notication via the FinalEvent signal it moves to its nal state. In
composition with this we have a control which we describe as NotActive until
some user input, represented by the signal UserInput, activates it. It then
makes a transition to its Active state and emits the FinalEvent signal. In the
next step the control becomes inactive again. This is a very simple model and
we would expect that if we had specied the same system directly into Z we
would likewise have a similarly simple model. We would perhaps have some
schema representing the system, an initialisation schema and operation schema
to show the start state of the system and how it might change. For the GUI
we might have a schema describing the control and possibly similar operation
schemas to show activation. If, however, we perform the translation of this -
chart into its Z representation, what we get is not at all simple. The underlying
Z model for -Charts not only describes the behaviour of the reactive system,
but also has to capture the semantics of the -Charts language. That is, the
25
Z model of the chart is necessarily more complex than the Z model of just
the reactive system itself. So the Z we get from the translation of this chart
contains twelve axiomatic denitions and twenty schemas, much more than
we supposed we would need for such a simple specication. Now imagine we
wanted to model a system with one hundred controls rather than just one, the
resulting Z specication for just the GUI would be enormous and complicated
to the point of being unusable. With the additional problems of trying to
integrate this with the rest of the specication of the underlying system we
are faced with a not very practical or useful solution.
Despite these problems we do not entirely dismiss the notion of using -
charts to provide a visual representation. The fact that we have this visual
language with its underlying Z model (however complex that model may be)
is useful if we can abstract away from the actual Z model of specic -charts.
What we mean by this is that we can use a -chart as a supporting diagram
within our specication without using its underlying Z model, but rather using
it to support the Z specication that we have created independently. Of course
this relies on our having a clear understanding of the meaning of the -charts
we create and being sure that they do indeed represent the same thing as we
have described in our specication. We will return to this point at the end of
this section.
At the end of these investigations we had a much clearer view of how we
were going to specify GUIs. We would use an abstraction of the widgets which
would interact with the system and an abstraction of the events which would
be used in the implementation to provide this link. As it was our intention
to provide methods that could be used by others we needed to describe this
specication method in a way which made the process clear to others. We
have developed a framework for the specication of GUIs in Z which allows
us to specify the GUI in a clear and useful manner at a suitable level of
abstraction, and which subsequently allows us to include design guidelines
into the specication. We present this framework next, and in section four we
26
will show how this can be extended to include design guidelines.
2.4 The Z Interface Specication Framework
Having made the decision to describe GUIs at a level of abstract GUI ob-
jects which can be subsequently rened to particular widgets, we next needed
to consider exactly what these GUI objects were and how we could describe
them in a way to show their relationship to the underlying system. There
are standard, commonly used widgets which are used in GUIs regardless of
the programming language or platform, such as buttons, scrollbars, menus etc,
however these are too low level for our early abstract specications. We want
to capture information about the behaviour of particular types of widget with-
out needing to describe actual widgets until we reach a level in our renement
process where it is appropriate to do so.
Rather than actual widgets, we began to consider the behaviour of the
system and the behaviour of the GUI so that we could determine what the
relationship between these is. By examining a range of dierent GUI building
tools and languages, we began to identify these behaviours which allowed us to
begin to categorise widgets into behavioural types. These types were identied
by their relationship to the underlying system state and to each other, rather
than by any notion of how a user would interact with them. Whilst it may seem
odd to ignore the users interaction it is in fact exactly the level of abstraction
we require. At the early stages of specication we are not interested in whether
a user is clicking on some object in the GUI, or dragging a mouse across
something else. What we want to know is what are the states of the system
and the states of the interface and what are the behaviours that cause these
states to change. In our system specication we describe changes in state by
way of operations, and we now propose to extend this to include GUI objects
that have a causal link to those operations.
Whilst the abstract categorisation of widgets we will describe focuses on
behaviour, it is possible to determine where commonly used, real widgets would
27
t into this categorisation. For example, if we consider a scroll-bar, we can
examine the usual behaviour of a scroll-bar and use this to determine which
category it will t under. This will not only prove useful when we move on
to including guidelines in the specication, but also ensures that we are not
tied to one particular set of existing widgets. Any widgets can be described
in this abstract manner as we are sure they can be described in terms of the
behaviours we have identied. The categories we derived from the behavioural
typing are split into two distinct groups, controls and displays. Controls are the
active parts of the GUI which cause changes in the system state or respond to
such changes. Displays are the state of the GUI itself and they can be thought
of as an abstract view of what the user may perceive in terms of, for example,
windows etc. They are abstract because they do not include any actual design
notions or particular widgets or placements of those widgets, they just give us
an idea of the state of part of the GUI in terms of the controls it oers to a
user. Our categorisation is as follows:
Controls
Event Generators
Cause an operation to occur
Action Controls
Linked to a single operation
Selection Controls
Oer a choice
Binary Selection Controls
Choice leads to one operation or another
Value Selection Controls
Choice generates a value for an operation
Single Value Selection Controls
Generates a single value for an operation
Multi-Value Selection Controls
Generates multiple values for an operation
28
Event Responders
React to an operation
Responders
React to a single operation
Value Responders
Respond to a value from an operation
Single Value Responders
Respond to a single value
Multi-Value Responders
Respond to multiple values
Displays
Status Displays
Provide a static view of part of system state
Containers
Describe a state of the GUI
RootWindow
The main constant state of the GUI
SubWindows
Non-static states of the GUI
Dialogue
Temporary display state
Frame
Subset of window state
Palette
Non-static subset of controls
With this categorisation as our basis we were then able to think about how
these dierent categories may interact with the underlying system, and from
this propose a consistent method of describing this in our specications. We
29
will describe a particular framework which can be used for specifying GUIs
in a formal Z specication which can be used for any system/GUI pair. This
framework includes a naming convention which provides a clear and concise
view for the reader of any specication structured in this way as to how the
dierent parts of the specication are related to each other. For the purposes
of describing the framework we use Greek characters to name things, but in a
real specication we would expect that these would be replaced by suitably
meaningful names. So when we refer to something as Control or Operation
we assume that the Greek characters are name parameters which will be re-
placed with actual names within the specication. When we describe two items
with the same parameter placeholder. e.g. Control and Operation it means
that the same replacement is made in both cases, i.e. stands for the same
parameter in each case.
Another point worth making here is our use of the word event both in
our category of EventGenerators and within the framework itself as the set
EVENT. We use this term as it helps capture the concept of something which
can happen dynamically and is causal. However, we are not attempting to
describe the low-level programming concept of an event (also known as a call-
back) which links widgets to functions in GUI software code. We use the same
term for convenience but it should be remembered that we are describing an
abstract Z type called EVENT rather than an actual piece of code.
In order to describe how our framework can be used to specify our sys-
tem/GUI pair we introduce a simple example system, called System which has
a single observation, called stateElementOne which is a natural number. We
will describe operations on this system as we need to throughout our explana-
tion. This is an intentionally trivial example of a system and is used purely
for convenience to show how the framework is used in general.
Our example system is given in Z as:
30
System
stateElementOne : N
Controls can be considered as the parts of the GUI which the user interacts
with, and which, in turn, interact with the underlying system or other parts
of the GUI via system operations. We will begin by looking at each of the
sub-categories of controls in turn and explaining how these can be described
in the Z specication.
Event Generators
Event generators are the things which cause a change in the system state. We
will structure our Z specication using the standard Xi/Delta style which mod-
els changes as operations upon the system state. We will show a link between
the operations and the event generators by way of a common input/output
observation which is taken from the set we call EVENT.
Action Controls
We will give our example system an operation called Operation specied as
follows:
Operation
System
aevent? : EVENT
aevent? = Event stateElementOne

= stateElementOne + 1
aevent? ,= Event stateElementOne

= stateElementOne
31
Now we describe an action control for this system which has an output
Event
ActionControl
acstate : CONTROLSTATE
aevent! : EVENT
acstate = Active aevent! = Event
acstate = NotActive aevent! = NoEvent
This schema has an observation called acstate which is of type CONTROL-
STATE, we dene this as:
CONTROLSTATE = Active [ NotActive
We use this to suggest some notion of user interaction where a value of Ac-
tive means that a user has interacted with the control (in whatever manner
necessary). For example, in the case of a button, Active would imply that
the user has clicked on that button. At the specication level we are not in-
terested in the micro-process of the users mouse-clicks on widgets, but it is
useful to consider the two states of the control in this abstract way. We have
also introduced the type called EVENT and shown two possible values which
are Event and NoEvent. EVENT is an enumerated set which will contain all
possible events within our specication as well as the special value NoEvent.
In order to suggest the causal link between control and operation, we add the
following to our specication:
ActiveOperation = ActionControl >>Operation
We use the Z piping operator >> as it not only conjoins the schemas, but
also merges the input/output observations with the common name giving us
a single event. More detailed explanations on the Z piping construct and its
uses can be found in [30] and [19]. We will use this convention for all of the
32
interactions between controls and system operations.
Selection Controls
Selection controls dier from event generators in that they typically have some
value associated with them. A concrete example of a selection control would
be a menu, when the user interacts with the menu and makes their selection
it is not enough to know that a selection has been made, we also need to know
what that selection is. Each selection in the case of a menu is linked to a dif-
ferent system operation. Selection controls can be further divided into binary
selection controls and multi-value selection controls. Often, multi-value con-
trols are the result of grouping together binary value controls. For example a
checkbox is a binary value selection control, it is either selected or not selected,
but it is common to group checkboxes together to form a button group, which
is itself a multi-value selection control.
Binary Selection Controls
Binary selection controls have two possible states: they are either selected, or
not selected. This may result in two dierent operations, one for each of their
states, or they may just be linked to one operation in their selected state. This
gives two possible schema for these types of control. It is up to the specier to
decide which is the most appropriate for any given situation. In the same way
that we dened an active state for action controls, we dene a selected state
for selection controls.
SELECTEDSTATE ::= Selected [ NotSelected
The operation this control will interact with can be dened in a similar manner
to Operation. So, for a binary selection control which generates one event
only we may have:
33
Operation
System
bevent? : EVENT
bevent? = Event stateElementOne

= stateElementOne 1
bevent? ,= Event stateElementOne

= stateElementOne
SelectionControl
bselState : SELECTEDSTATE
bevent! : EVENT
bselState = Selected bevent! = Event
bselState = NotSelected bevent! = NoEvent
We can dene ActiveOperation in the same way as we have done for the
action control.
ActiveOperation = SelectionControl >>Operation
And for a binary selection control which can generate two dierent events we
will have:
SelectionControl
bselState : SELECTEDSTATE
bevent! : EVENT
bselState = Selected bevent! = Event
bselState = NotSelected bevent! = Event
ActiveOperation = SelectionControl >>Operation
ActiveOperation = SelectionControl >>Operation
34
Where Operation is some other system operation designed to react to the
bevent? value of Event.
Another possibility we should mention here is the case where more than
one control in the GUI is linked to the same event, as in the case, for example,
where a menu item and a button perform the same task. In this case we just
extend our description of event observations in the operation schema and use
schema conjunction for the activeoperation denition.
SelectionControl
aselState : SELECTEDSTATE
asevent! : EVENT
aselState = Selected asevent! = Event
aselState = NotSelected asevent! = NoEvent
Then we update the operation schema to show its response to this control
Operation
System
aevent? : EVENT
asevent? : EVENT
aevent? = Event asevent? = Event
stateElementOne

= stateElementOne + 1
aevent? ,= Event asevent? ,= Event
stateElementOne

= stateElementOne
Then we can dene the active notion of this operation as
ActiveOperation = (ActionControl SelectionControl )>>Operation
35
Value Selection Controls
Value selection controls will either have a given set of possible values or a
range of allowable values. When they are activated they have some set of
values which will be used within the resulting operation. In some cases there
may be more than one value and we model this as a separate case. One of the
things we need to be careful of is the type of the value that is generated. We
need to ensure it is compatible with the type of the value that is required by
the operation. This check is helpful as it reminds us that similar care will be
required during implementation.
Single Value Selection Controls
We rst describe the type of operation such a control may relate to:
Operation
System
gevent? : EVENT
geventValue? : N
gevent? = Event
stateElementOne

= stateElementOne +geventValue?
gevent? ,= Event
stateElementOne

= stateElementOne
Then we describe the control itself:
36
singleValSelectionControl
gcstate : CONTROLSTATE
gsetvalue : N
gevent! : EVENT
geventValue! : N
gcstate = Active gevent! = Event
gcstate = NotActive gevent! = NoEvent
geventValue! = gsetvalue
Once again we dene the ActiveOperation by conjoining these two:
ActiveOperation = singleValSelectionControl >>Operation
Multi-Value Selection Controls
Our last event generating control types are those controls that generate mul-
tiple event values at a time. These are often implemented as groups of single
value selection controls, e.g. something which can pass multiple settings back
to the system at a time. First we describe a modied system by adding a
second observation which this type of control can be used with:
NewSystem
stateElementOne : N
stateElementTwo : N
Now we look at the individual selection items which will be used in the overall
multi-value selection control:
singleValSelection
selectionState : SELECTEDSTATE
setValue : N
37
singleValSelection
selectionState : SELECTEDSTATE
setValue : N
And now we describe the overall state of the control:
multiValSelectionControl
singleValSelection
singleValSelection
zcstate : SELECTIONSTATE
zevent! : EVENT
zeventValue! : seq N
zcstate = Selected cstate = Selected cstate = Selected
zcstate = Selected zevent! = Event
zcstate = NotSelected zevent! = NoEvent
zeventValue! = setValue)

setValue)
Note that our sequence eventValue! contains all of the values from the single
selection controls irrespective of whether or not they have changed. We are
always interested in all of the values.
38
Operation
NewSystem
zevent? : EVENT
zeventValue? : seq N
zevent? ,= Event
stateElementOne

= stateElementOne
stateElementTwo

= stateElementTwo
zevent? = Event
stateElementOne

= zeventValue? 1
stateElementTwo

= zeventValue? 2
Now we put these together in our usual way:
ActiveOperation = multiValSelectionControl >>Operation
We use a sequence of values rather than a set. This is important as it ensures
that the correct value is passed to the correct observation in the operation
schema. We always generate the values we want in the dened order. In the
case of a button group, therefore we always pass all of the values even if noth-
ing has changed.
Event Responders
Like the event generators, this category of widget types is linked to underlying
operations, but in this case they are responding to system operations rather
than generating them. Event responders make some change to their state in
response to some operation. The description of event responders and the op-
erations they are linked to is similar to that of event generators, but in this
case the input and output events are reversed.
Responders
These are the event responder group widgets which are equivalent to the action
controls of the event generator group. They do not receive any values they
39
simply change their state in a given manner. We consider this simplest form
of responders as things which have two possible states which in this abstract
description we will call On or O. At an implementation level this could mean
anything at all it is just a convenient notation for a binary state control.
RESPONSESTATE ::= On [ O
Operation
System
aevent! : EVENT
stateElementOne

= stateElementOne + 1
aevent! = Event
ResponseState
arvstate : RESPONSESTATE
Responder
ResponseState
aevent? : EVENT
aevent? = Operation arvstate

= On
aevent? ,= Operation arvstate

= O
It may be that the event responder reacts to two dierent events: one to put it
in its On state and one to put it in its O state. In this case we simply add this
information to the predicate part of the schema and describe it accordingly, in
much the same way as operations which responded to more than one control.
40
Responder
ResponseState
aevent? : EVENT
bevent? : EVENT
aevent? = Event arvstate

= On
bevent? = Event arvstate

= O
We now link the event responder and operation as we have the event genera-
tors, using piping:
ActiveOperation = Operation>>Responder
It is, of course, also possible that two dierent operations may be responsible
for the two dierent response, in this case our ActiveOperation will be dened
slightly dierently:
ActiveOperation = (Operation Operation)>>Responder
It may appear that we have introduced unnecessary complexity into this
description by having a separate schema for the observation of RESPONSES-
TATE. The purpose of doing this and then including a primed and unprimed
copy of this schema (by way of the notation) is to aid the readers under-
standing of the specication. Conventionally we expect to see primed observa-
tions in schema indicating a new state after some change has been made. This
is exactly what we are conveying here, a new state for the RESPONSESTATE
observation, and so we feel that this notation is clearer and more in keeping
with standard Z specications.
Value Responders
These are the event responders which are interested not only in a system oper-
ation, but also in the new value of some part of the system state following that
operation. They are widgets which somehow show some part of the system
41
state, which is changeable. Although we refer to values, and in the example
use a numeric value, it is not necessarily the case that the value in question is
numeric. The system may have some observation with allowable values such
as normal, high, critical and the responder, which in the implementation may
be a light or some other indicator, has some way of representing this value.
We again need to consider both single-value and multiple-value responders.
Single-Value Responders
Operation
System
bevent! : EVENT
beventVal ! : N
bevent! = Event
stateElementOne

= stateElementOne + 1
beventVal ! = stateElementOne

ResponseState
brvstate : RESPONSESTATE
brvValue : N
SingleValueResponder
ResponseState
bevent? : EVENT
beventValue? : N
bevent? = Event brvState

= On
event? ,= Event brvState

= O
brvValue

= beventValue?
42
ActiveOperation = Operation>>SingleValueResponder
Multiple-Value Responders
Operation
NewSystem
devent! : EVENT
deventValue! : seq N
devent! = Event
stateElementOne

= stateElementOne + 1
stateElementTwo

= stateElementTwo 1
deventValue! = stateElementOne

stateElementTwo

)
ResponseState
drvstate : RESPONSESTATE
drValues : seq nat
MultiValueResponder
ResponseStatedevent? : EVENT
deventValue? : seq N
devent? = Event vState

= On
drvValues

= deventValues?
ActiveOperation = Operation>>MultiValueResponder
Displays
Our second major category are the displays, these are sub-categorised as either
Status Displays or Containers. StatusDisplays are individual widgets which in
43
an implementation may be things such as labels. Containers are larger parts
of the GUI state which appear in the specication as conjunctions of other
schemas. Displays consist of all of the widgets which make up the GUI.
Status Displays
These are widgets which provide some information about the underlying sys-
tem state to a user in some form or another. In this way they are similar to
event responders, however, unlike event responders they do not react to under-
lying system operations, they have a static value. The clearest way to dieren-
tiate the two is to consider event responders as items whose state changes over
a period of time in response to changes in the system state, whereas status
displays are items which provide a snapshot of the current value of some part
of the system state at some dened point. We describe them in the following
way:
Display
System
DisplayValue : N
DisplayValue = stateElementOne
Most commonly status displays will in fact be either custom widgets or in-
corporated as part of other widgets. For example if we consider the concrete
example of a selection control within, say, a preferences window, it may be
that before the user makes a selection it is useful for them to know the current
system state relating to that selection. The selection value of this particular
widget prior to user interaction is then determined by the current system value
for that preference, in this way the control is both a selection control and a
status display.
Containers
A GUI is made up of a collection of displays which are implemented as win-
dows, dialogue boxes, pop-up windows etc. Each one of these has an overall
44
state which can be described as a collection of the states of its components.
We can therefore simply describe these using schema inclusion:
Container
ActionControl
SelectionControl
For every system that we describe there must be exactly one display which
is called the RootDisplay or RootWindow. This is the window which is used
to determine that the system is running and includes the controls which a
user needs to begin and end interaction with the system. Displays may also
need to be considered as a special case of EventResponders in that they have
observations such as size, or visibility, which may change in response to some
user action. For example, it is common for a window to have buttons along
the top title bar which allow the user to resize the window to its minimum
and maximum sizes as well as close the window. There is no change to the
underlying system in this case, but there is a change to the state of the GUI
and we therefore still need to capture this change. We can do this as follows:
WINDOWSIZE ::= Minimised [ Maximised [ Standard [ UserDened
Control
aevent : EVENTacstate : CONTROLSTATE
acstate = Active aevent = Event
acstate = NotActive aevent = NoEvent
RootWindowResponseState
rwstate : RESPONSESTATE
45
RootWindow
RootWindowResponseState
Control
aevent : EVENT
aevent = Event rwstate

= On
Notice that our event observations have lost the ! and ? symbols denoting
input and output. This is because these observations are now contained within
the RootWindow rather than being linked to some system operation.
Displays are not necessarily the only types of widgets which will interact
with other widgets rather than system operations, but in each case we can
successfully follow the pattern given above to signify this.
It is now useful to look at a specic example of how we can use this model.
We will do this by way of introducing a simple example system with a GUI.
The example is purposely simplistic as the aim is to show the application of
the framework to an actual system/GUI pair rather than attempt to describe
a real-world example. In section ve of this report we will move on to larger,
more realistic examples, which use both our GUI description framework and
incorporate guidelines.
2.5 Simple Interface Specication Example
The system we will use for this example is one which upon some prompt from
a user will give them the message Hello World. That is all we know about
the system, we have no idea what sort of input the user will provide, nor how
we should return the message (e.g whether it is to be an audio message, a
visual message etc.). Using the described framework we reach the following
specication:
46
First we dene the required types for the specication.
MESSAGE ::= HelloWorld [ NoMessage
EVENT ::= MessageEvent [ DisplayMessageEvent [ NoEvent
CONTROLSTATE ::= Active [ NotActive
RESPONSESTATE ::= On [ O
Now we describe the system itself which consists of a single observation which is the
current message.
System
currentMessage : MESSAGE
The initial state of the system has no message.
InitSystem
System
currentMessage

= NoMessage
There is one system operation which will change the system state so that its cur-
rentMessage observation will be HelloWorld if the input observation has a value
of MessageEvent. If this is the case the output observation will be DisplayMes-
sageEvent, otherwise it will be NoEvent, and the currentMessage observation will
not change.
47
ShowMessageOperation
System
smevent? : EVENT
dmevent! : EVENT
smevent? = MessageEvent
currentMessage

= HelloWorld
dmevent! = DisplayMessageEvent
smevent? ,= MessageEvent
currentMessage

= currentMessage
dmevent! = NoEvent
Now we describe the controls which will allow the user to interact with the system.
First we have an ActionControl
ShowMessageControl
smcstate : CONTROLSTATE
smevent! : EVENT
smcstate = Active smevent! = MessageEvent
smcstate = NotActive smevent! = NoEvent
Secondly we have a Responder
MessageResponse
messageDisplay : RESPONSESTATE
48
MessageResponder
MessageResponse
dmevent? : EVENT
dmevent? = DisplayMessageEvent messageDisplay

= On
dmevent? ,= DisplayMessageEvent messageDisplay

= O
Now we link the operation to the controls.
ActiveShowMessageOperation =
ShowMessageControl >>ShowMessageOperation>>MessageResponder
Finally we describe the RootWindow for this system.
RootWindow
ShowMessageControl
MessageDisplay
We have now produced an abstract specication of an interactive system and
its GUI, based on our described framework for specifying GUIs in Z. There
are many things we could now do with such a specication, starting with
validating it to ensure it behaves as we expect, and moving on to renement
to ultimately produce an implementation of such a system. For the purposes
of this example, however, we will look at an additional way of supporting the
readers of our specication.
In section 2.2 where we described possible approaches we had considered
for formalising GUIs we discussed how we can use -charts as a visual aid,
if required, within our specication. For this simple example we now show
how this may be done, and also how we can be sure that the -chart correctly
captures the meaning as we have specied it in Z. First we describe the system
in the -chart given in gure 5:
49
HelloWorld
NoMessage SystemMessage
MessageEvent/DisplayMessageEvent
GUIDisplay
MessageOff MessageOn
DisplayMessageEvent
{DisplayMessageEvent}
Figure 5: Hello World -chart Example
Now we want to ensure that this model captures the same meaning as our
Z specication. As previously discussed we do not want to work from the Z
model of the -chart due to the additional overhead that this creates in our
specication, but what we can do is examine the model and ensure that at
least the transitions describing the reactive nature of the model are equivalent
to those we have given in our specication.
The Z model of the -chart contains the following declarations for signals:
Signal ::= SMessageEvent [ SDisplayMessageEvent
These make up the inputs and outputs of the system, which in our Z speci-
cation are the set EVENT. We see that if we take into account the -chart
convention of prexing signals with a letter S then the set Signal is a subset
of EVENT. They are not equivalent as Signal does not require the value of
NoEvent.
50
Now we look at the transitions given in the Z model of the -chart:
HelloWorldNoMessageSystemMessage
HelloWorldNoMessage
HelloWorldSystemMessage

i
HelloWorld
? : PSignal
active : P
State
o
HelloWorld
! : PoutputI
HelloWorld
active(HelloWorld)
SMessageEvent i
HelloWorld
? (o
HelloWorld
!
HelloWorld
)
o
HelloWorld
! = SDisplayMessageEvent
This rst transition schema tells us that c
HelloWorld
, i.e. the start state, is
NoMessage (from the schema HelloWorldNoMessage) and that the after state
of c
HelloWorld
is SystemMessage (from the schema HelloWorldSystemMessage

)
with the condition that the input set contains the signal SMessageEvent and
the output set contains SDisplayMessageEvent. If we compare this informally
with our Z specication where we stated:
ShowMessageOperation
System
smevent? : EVENT
dmevent! : EVENT
smevent? = MessageEvent
currentMessage

= HelloWorld
dmevent! = DisplayMessageEvent
smevent? ,= MessageEvent
currentMessage

= currentMessage
dmevent! = NoEvent
we can informally deduce that these have the same intention. CurrentMessage

51
takes on the new value of HelloWorld (which is equivalent to SystemMessage
in the -chart), if MessageEvent is the value of the input observation, and at
the same time we have an output observation with the value of DisplayMes-
sageEvent. We can do the same with the transition from the GUIDisplay
chart.
GUIDisplayaMessageOMessageOn
GUIDisplayMessageO
GUIDisplayMessageOn

i
GUIDisplay
? : PSignal
active : P
State
o
GUIDisplay
! : PoutputI
GUIDisplay
active(GUIDisplay)
SDisplayMessageEvent i
GUIDisplay
? (o
GUIDisplay
!
GUIDisplay
)
o
GUIDisplay
! =
Here we see that the start state is MessageO and the after state is MessageOn
with the condition that DisplayMessageEvent is in the input set. Again we can
informally decide that this has the same meaning as:
MessageResponder
MessageResponse
dmevent? : EVENT
dmevent? = DisplayMessageEvent messageDisplay

= On
dmevent? ,= DisplayMessageEvent messageDisplay

= O
The purpose of introducing -charts into this example was to show how we
can use their visual nature to help support understanding. If we want to be
certain, as indeed we should, that the -charts we create really do mean the
same as our Z specication then we would expect to perform proofs to show a
52
renement between the two models to ensure that this really is the case. Such
proof work is beyond the scope of this project where we do not include -charts
as part of our solution to including guidelines within the formal specications.
It is, however, useful to see examples of how we can make informal use of
-charts as a visual aid, and we believe this is an interesting area for future
research.
53
3 User Interface Design Guidelines
3.1 Background
Graphical user interfaces are complex systems which have a number of dicult-
to-satisfy requirements. They must not only present the user with the ability
to interact with an underlying system fully, i.e. allow the user to perform all
required actions, but they must also themselves interact with the underlying
system functionality. In addition, as the purpose of the interface is to allow
human interaction with the system, there are usability issues which require
that the design of the GUI enables the user to be able to interact with it in
a reasonably intuitive manner and without constant reference to manuals or
help les. This issue of usability is a major component within the research
eld of human computer interaction (HCI) and is understood to be a large
and dicult problem. Many dierent methods and tools have been developed
to assist with our understanding of the complexities of this task, and research
in areas as diverse as cognitive psychology and algebraic modelling is ongoing
to further this understanding.
The use of design guidelines is an important part of the work included in
the HCI discipline, and one which can give a substantial benet in the design of
interfaces. Guidelines are the product of ltering and combining the knowledge
and experience gained from user-testing of interfaces and results from research
in psychology over a number of years. They can be seen as a best-practice,
or how-to, which helps us in our goal of designing better GUIs. While the
use of guidelines alone does not guarantee that the GUIs we design will be
usable, they do ensure that we avoid some of the common, known pitfalls and
allow us to concentrate our user-testing eorts on nding new and unexpected
problems. In [20], Dix describes guidelines as design rules which are:
.. mechanisms for restricting the space of design options, prevent-
ing a designer from pursuing design options which would be likely
to lead to an unusable system.
55
As such they are an attempt to provide designers with enough information to
understand the implications that some of their design decisions may have on
users and to help them avoid already understood mistakes. They are intended
to constrain the design space rather than the designer. That is, they give
freedom of design within an environment where some potential problems have
already been removed. For example, consider a guideline which states that:
Provide a clear way of leaving the modal window, such as a Cancel
button in an alert.
which is taken from the GNOME guidelines [24]. This does not put any con-
straints on the design of a modal window, other than to ensure that somewhere
in the window there will be a cancel button.
Guidelines are not intended to replace usability testing, or task modelling,
or any of the other important and valuable stages within the design life-cycle.
They are one important part of a process which aims to ensure we build usable
interfaces and thereby usable systems. Whilst we may hope that many of the
common guidelines would be inherently understood by our designers and as
such automatically included in their designs, this ignores the fact that when
designers are working within the many dierent demands and complexities of
interface design it is easy to lose sight of simple, underlying principles in the
face of other large and dicult decisions which need to be made.
Guidelines may be very general, in that they apply across the board to
many of the dierent kinds of interfaces and systems we can imagine, or they
may be domain specic and context dependent. In either of these cases their
use provides two clear benets. Firstly they ensure that all designers, however
inexperienced, are able to draw on the experience of other designers and re-
searchers from a number of years. Secondly, their use ensures that during the
later process of user testing of the interfaces we are not continually re-nding
the same problems time and time again. Rather than testing for common
GUI problems, guidelines aim to ensure we design them out of our interfaces
wherever possible.
56
3.2 Guideline Types
Although we have described guidelines as a single entity, in fact there are many
dierent types and categories of guidelines. Not all computer guidelines are
software related; guidelines also exist for the design of the hardware used to
run our systems. These are, however, outside the scope of this work. Software
guidelines do not necessarily only apply to interface design, but can also apply
to the underlying software system we are describing. Such guidelines may
include things such as particular algorithms which should be used in particular
cases. While we do not focus on these in this work, it is assumed that inclusion
of such guidelines would be a relatively straight-forward step following on from
our work in describing interface design guidelines.
We can further sub-categorise interface design guidelines both in their scope
and their application. We can consider a range from the purely aesthetic (such
guidelines may be termed style-guides or house-style rules) to safety-critical
guidelines such as may be used within the design of safety-critical systems
such as medical software or nuclear power station control software. Of course,
between these two extremes there is a wide-range of guidelines which are in
use by everyday software designers. The second way to categorise guidelines
is by the strictness with which they must be enforced.
Whilst we have described how using guidelines aids designers in building
better and more usable software, often their use is not mandated. We expect
and hope that commonly-held guidelines will be used, but there are no hard
and fast rules regarding their application. There are, however, guidelines which
must be used in particular situations. These are more commonly described as
standards. The use of standards is usually set and governed by national or
international bodies, such as the IEEE Standards Association for example, and
those wishing to be veried or supported by such an organisation must strictly
adhere to these standards. Within our work we do not distinguish between
these dierent categories, rather we treat all guidelines from the aesthetic to the
safety critical concerns with equal importance and assume that all guidelines
57
should be applied as a mandatory step where possible. Of course there are
many cases, as we shall see in later examples, where it is not possible for all
guidelines to be included. However, it is expected that the system specication
would clarify these cases rather than leaving it up to a designer to decide
whether or not to apply a particular guideline in a particular instance. We
will discuss this further in the next section of this report where we examine
notions of priority and importance within sets of guidelines.
3.3 Using Guidelines in the Design Process
There are many dierent methods, often described as life-cycles, used in de-
signing and building user interfaces. This is not dissimilar to the dierent
approaches taken to designing entire software systems, and we recognise that
interface building is often included as one part within such methods. What-
ever the approach, or life-cycle, used, there are generally four basic activities
involved when we design interactive systems: Identifying the users needs and
establishing the requirements; developing alternative designs; building proto-
types of the design; and evaluating the prototypes. Presumably once we have
evaluated the designs there will be changes required, and as such we can con-
sider the process to be iterative. Irrespective of the methods used by particular
designers, there is an understanding that focusing on the users as early as pos-
sible and involving them throughout the process will lead to fewer iterations
and easier to use systems.
Involving users is not, of course, as straightforward as it may sound. The
reality of building software systems is that the designers are often physically
far-removed from the end-users. Not only that, it is often unrealistic to expect
end-users to know exactly what it is they want the nal solution to be other
than in functional terms of what they expect it to do. This is where the
benets of using design guidelines can be seen. As we have stated, guidelines
are the result of years of design experience and research, and as such their
use provides a body of historical users which can be drawn upon. By this we
58
mean that it is not necessary to involve actual users in making design decisions
in areas where we already have a clear understanding of what the implications
of such decisions may be on users. We need to be clear here that we are not
in any way advocating removing users from the process, rather that we use
them more wisely. For example, when we consider the expense, in both time
and money, or performing user-studies, we want to ensure that the studies we
conduct are maximised. If each system we design is considered in a vacuum,
i.e. without careful consideration of past projects and lessons learned, then
our user-testing will undoubtedly uncover many of the same problems time
and time again. This is something of an extreme example; however, even if the
number of repeated problems is relatively small they are still an unnecessary
overhead if they can be removed altogether.
Having convinced ourselves that the use of design guidelines will be bene-
cial we then need to consider how they may be used. Numerous bodies of work
containing guidelines have been published. Some freely available to all design-
ers, such as the GNOME Human Interface Guidelines or the Apple Human
Interface guidelines, whilst others are proprietory documents used privately
within organisations. We expect that designers will have access to these works
and will make reference to them throughout the design process. However,
there may be a number of problems with this process. Firstly this relies on
designers remembering to make reference to the guidelines at all stages of the
design process. Recall that we stated that the design is an iterative process.
It is therefore not enough that the guidelines are considered in the rst stages
of the design, but rather we must ensure that at each iteration as the design
changes we maintain adherence to the guidelines. This process also relies on
the designers being able to locate the relevant guidelines, correctly interpret
them and understand when to use them. Guidelines may be numerous and
distributed across many documents and resources, making this a dicult task.
In [5] Balbo notes that the Smith and Mosier guidelines [51], for example, con-
tain 944 separate recommendations. It seems unrealistic to expect designers
59
to be able to nd and apply each of these at the appropriate time at every
stage of the design process in what is often a time-pressured work environ-
ment. As we shall see later, many guidelines are also described in abstract or
very general terms which may also make them dicult to apply. In a study of
interface menu guidelines [16], de Souza and Bevan discovered that designers
were often confused by the terminology used in the guidelines, and on average
had diculties in understanding or applying 66% of the guidelines.
3.4 Introducing Guidelines to the Specication Process
Before we can begin to specify a software system we need to gather the require-
ments of that system. Only when we have understood those requirements can
we begin to consider a model for that system which we can formally describe
using a specication language such as Z. Given that we understand the need
to have all of the requirements before we can begin the specication process,
and given that we expect the specication to take all of those requirements
into consideration, it becomes clear that including interface design guidelines
in the specication is a logical choice to make. We have stated that guide-
lines allow us to eliminate design decisions which may impact adversely on our
users. Put another way, they are requirements of a usable system. If we con-
sider guidelines in this way, as a super-set of requirements which apply to all
of our software design projects, then it becomes clear why we should include
them in our specication. Omitting guidelines has the same aect as ignoring
any other requirement: it leads to a specication which is either incomplete or
which does not accurately describe the required system.
Having understood that incorporating design guidelines is a desirable thing
to do we next need to consider how exactly we can achieve this. We have
already stated that guidelines may be long documents containing numerous
rules, so it will not be benecial to restate every single guideline in every spec-
ication we write. Apart from the duplication of eort, the sheer number of
guidelines will make our specications long and unreadable, and therefore ul-
60
timately useless. We also need to consider levels of abstraction. Often our aim
in specifying a system, particularly in the rst instance, is to be as abstract
as possible. We are interested in ensuring we capture the requirements and
properties of a desired system rather than worrying about low-level implemen-
tation details. We need to consider how then we can include the notion of
guidelines, which we may think of as very low level, referring as they do to the
actual interface of the system at this early and abstract stage.
In the previous section of this report we described a framework for describ-
ing interfaces within a Z specication. Part of this framework used the notion
of categorising interface widgets, providing diering levels of abstraction which
could be used at dierent stages in the specication process. We can apply
this same framework to our guidelines. This gives us a number of benets.
Categorising the guidelines into dierent levels of abstraction will allow us to
remain consistent in the abstraction level of our specication. Also, by using
the same framework for describing the guidelines as we do for describing the
interface itself we are able to select only the guidelines which are applicable at
any given time and at any given level of abstraction. In short we will create an
annotated specication of the guideline set which both formally describes the
guidelines and which aids the specier in their usage within their specication.
The next section describes this process in detail.
61
4 Formal Specication of Guidelines
We are now, nally, at the point where we can begin to look at ways of including
design guidelines in our formal specications. We have proposed a framework
for describing GUIs as part of a specication, and discussed dierent levels of
abstraction to be used depending on our stage of renement. If we are to now
successfully include guidelines in the specication we need to consider how
guidelines are described, what is their level of abstraction, how meaningful are
they to our GUI description and how can we use them to prove properties of
our interface specication.
Guidelines are typically presented in documents which contain not just the
guidelines themselves, but also a great deal of supporting text. They are not
just a list of rules which can be used as a checklist by the GUI designer, rather
they are comprehensive documents containing background and explanation as
to the purpose and meaning of the guidelines as well as suggestions about when
they should be applied. In platform-specic guidelines such as those given by
GNOME [24] and Apple [4] there is also information about ways of doing things
that are particular to those platforms and include usage of their own bespoke
widgets and terminology. In order to be able to understand the guidelines a
designer needs to carefully work their way through these large documents and
become familiar with the background and scope of the documents before they
can begin applying the guidelines in the GUIs they build.
Unfortunately, the benets of providing such detailed documents with the
background and context details may be oset by the disadvantages. Namely,
that the length and structure of these documents makes it dicult to isolate
actual individual guidelines and be sure all have been captured by a GUI
design. The actual guidelines may be spread throughout the document, or may
be repeated in dierent sections. The GNOME guidelines [24], for example, are
presented over seven chapters, and while some of these chapters are structured
to make it easy to nd guidelines for specic types of widgets, such as the
63
chapter on controls or menus, others are dedicated to more general concepts
such as feedback. Within this chapter on feedback there are guidelines relating
not only to the GUI in general, but also to specic widgets or types of control.
This can make it hard to pinpoint the relevant guidelines for the system in
question, and even harder to be sure that none have been missed without a
great deal of double checking of the document and cross-referencing between
the document and the implementation. Not only that, but the wording of
guidelines may not make it clear how exactly they relate to the GUI being
designed and it may be unclear how exactly they should be applied. The
introductory section of the Smith and Mosier guidelines [51] states that:
Design guidelines such as those proposed here must be generally
worded so that they might apply to many dierent system appli-
cations. Thus generally-worded guidelines must be translated into
specic design rules before they can actually be applied.
This idea of translating the guidelines into specic rules for specic purposes is
exactly what we propose to do to ensure that we can use the guidelines within
our specications.
The rst problem we have is that we need to take a set of guidelines and
translate them in such a way that is is possible to extract particular guidelines
for use in the specication. We need to nd a general process for doing this.
It is not enough to take one particular set of guidelines and translate it in a
suitable manner. Our aim is that any set of guidelines in any domain can be
used in this way and so we need to provide a general process that will work
across all sets of guidelines. Secondly, even if we do nd a way of organising
the guidelines appropriately we need to nd a way to actually use them within
specications. Not only is the language and terminology used in the guidelines
likely to be dierent from that used in the specication, the level of abstraction
is also likely to be dierent.
Just as we have provided a framework for describing GUIs in Z within a
specication we now need to nd a way to t the guidelines into this framework
64
and make them useful. The rest of this section looks at how we go about
achieving this.
4.1 Structure and Abstraction in Guideline Documents
In section two of this report we stated that we wanted to be as abstract as
possible in our initial descriptions of the GUI in order to retain the benets of
abstraction we expect from our specications. We achieved this by identifying
behavioural categories of widgets and using this as the basis for our abstraction.
Similarly, when we introduce guidelines into the specication we need to ensure
that the abstraction level is the same, otherwise we will introduce meaningless
rules into the specication. For example, consider the following from the Apple
guidelines [4]:
Some image wells (the user picture in the Picture pane of Accounts
preferences, for example) must always contain an image
There is no obvious way of usefully including this in a specication. It is a
very detailed and low-level guideline which does not t in with our idea of an
abstract system description where we describe widgets at the level of event
generators or displays. On the other hand, if we consider a guideline which is
very general, such as:
Always provide feedback to the user in response to their actions
we still have a problem. While this is very abstract in that it does not refer to
actual widgets or low-level implementation details, there is still no obviously
useful way we can use such a guideline within our specications.
In many ways the problem is similar to the one we were faced with when we
were trying to determine the most useful way of specifying the GUI. We needed
to include enough information to capture the important behavioural aspects of
the GUI without getting caught up in low-level implementation details. In the
case of the guidelines we need to include enough information to capture their
65
requirements which seem to relate to a GUI implementation, but again we
want to achieve this without having to consider those implementation details.
We solved the problem of GUI specication by categorising the widgets of
the interface based on behavioural properties. We now need to consider if we
can nd a similar categorisation within the guidelines which will allow us to
move them from an implementation context to a specication context.
As we have already discussed, guideline documents contain not just guide-
lines, but also supporting text and documentation. The organisation of the
information diers between dierent sets of guidelines, but in most cases there
is, at some stage, some structuring of the information within the document
under various headings. The GNOME guidelines [24] for example, contains
chapters such as Usability Principles, Windows, Controls and Feed-
back. Some of these, like the chapters on Windows and Controls clearly
suggest a categorisation similar to that we have used in our GUI specication
framework, whereas others, such as Usability Principles and Feedback do
not. What we discovered from examining the various guideline documents and
their structure is that there is a range within the guidelines, starting with the
most general, which we can consider to be guiding principles rather than hard
and fast rules that can be applied to a GUI design, and ending with the most
specic, which we can consider as actual rules given by the guidelines. Within
this range dierent types of guidelines and principles were evident which led us
to describe the hierarchy given in gure 6, which portrays the dierent layers
of this hierarchy.
66
Figure 6: Categorisation of Guidelines
When we began to reorganise guidelines into these categories, we found that
apart from the innermost group of widget-specic guidelines, the other layers
still contained guidelines with widely diering levels of detail. For example, in
the Structure category we had some very general principles such as:
Group related data
as well as detailed, low-level guidelines such as:
Align checkboxes in groups vertically
It was clear from this that rather than trying to reorganise the existing struc-
ture of the guideline documents it would be more useful to completely restruc-
ture them as new documents. What we needed was not the guidelines as they
were given, but a formal representation of those guidelines arranged in a suit-
able manner. In fact what we needed was a specication of the guidelines.
This would not necessarily be a formal Z specication, but rather a formally
structured document which would describe the guidelines in a language that
would make it easy to relate them to the GUI description in our Z specication.
We would structure this guideline specication using the same widget cate-
gories we had already dened. In this way, a guideline such as provide feedback
to user actions, can be redened at a level where it does become useful by
67
describing it in terms of these categories. So while provide feedback to user
actions does not mention any particular widget or widget type, it instead
suggests that this is something that should be true of all things in the GUI.
If we can redene what this means, then we can redene the guideline in a
more useful manner. Feedback is the notion of a system notifying the user that
something has happened. Therefore, when things happen within the system in
response to something the user has done, the user should be informed somehow
that the change has occurred.
For each category in our guideline description we need to ensure that they
include this guideline in a way that is meaningful for that category. For exam-
ple, at the top of our category hierarchy we have controls and displays. If we
consider what it means to say that all controls must provide feedback we can-
not really nd a more useful denition than this, as the category is too general
still. If we move down to the next category level and look at event generators,
however, we can nd a sensible way of describing feedback. When the user
interacts with an event generator it becomes active and the resulting operation
causes some change to the system state, feedback means that the user should
be informed of this system change. The users view of the system is, of course,
through the GUI, and so this system change must be reected back to the GUI
somehow. We dont need to concern ourselves with the implementation details
here of how this would be achieved, but with this understanding we can now
perhaps nd a meaningful way of describing this guideline in relation to event
generators. We can repeat this for the other categories of widgets and dene
the meaning of feedback for each one in an appropriate manner based on their
behaviour.
We have focused on one particular example of a general guideline here, but
we can generalise this for all of these types of guidelines. It gives us an example
of how we can think about abstract concepts in a less abstract way without
having to go into implementation details. We can start with the most general
principles and work our way through the categories until we reach a point
68
where we can meaningfully dene them. That is, we work our way through
the guideline documents and redene the general in terms of more specic
guidelines that can be related to each widget category.
Of course, we have already said that not all guidelines are general, some are
so specic that they really do have no meaning except at the implementation
stage where we will have actually dened things like the image wells referred
to in our earlier example. For each of these specialist guidelines we can in
fact leave them as they are, apart from rewording them in a more formal
manner if required. We will determine what the category is of the widget
being described and then include this guideline in that categorys section of
the guideline specication. In this way we can produce a document which both
reects the way we have chosen to formally specify our GUIs and also retains
the low-level implementation guidelines which will be useful as we rene our
specication to something more concrete.
We have found that there are some general principles given in some guide-
line documents which we are unable to satisfactorily nd a way of dening in
terms of widget categories at all. For example, the principle
Put the user in control
from the GNOME guidelines [24]. Even if we try to consider this for each
of our lowest levels of sub-categories like, for example, a multi-value selection
control, we cannot derive a useful way of describing this requirement. We do
not consider this a real problem. This is an example of the sorts of principles
designers should be aware of and should understand from reading the back-
ground and context information rather than being a rule we can specify. It is
not our intention to translate the guideline documents in their entirety into
a usable specication (just as the guideline documents themselves do not at-
tempt to cover every single usability issue), but rather to nd a way to include
the information that will be useful at the specication stage.
69
4.2 Formatting the Guideline Specication
We have decided that we need to produce a document which will be a formally
structured version of the guidelines. This will organise the guidelines into
the same categories as the widget hierarchy and will translate all applicable
guidelines in terms of those widget categories. The document then will be
organised to follow the widget categories so that it will be easy to locate
relevant guidelines both at the early specication stage and also later when we
begin to rene the specication.
We have said that we want the document to be formal so that it can be
considered as a kind of specication of the guidelines, we need to decide what
the language of this document will be. Our rst idea was to take each of
the guidelines and turn them into a Z predicate with the intention that we
could then just take these predicates and put them into our specication and
we could subsequently perform proofs to ensure that they were satised by
the specication. There were, however, a number of problems that became
apparent with this approach. Suppose we have the following guideline which
we want to describe in terms of action controls:
Give all action controls a unique key board shortcut
To turn this into a Z predicate we think about the two key parts of the guide-
line. Firstly ActionControls must have some observation to represent a key-
board shortcut, secondly no two ActionControls should have the same keyboard
shortcut. From this we derive the following:
aac, abc : ActionControl aac.akey = abc.akey aac = abc
The problem with this is that rstly it presumes we have some type Ac-
tionControl in our specication and that we describe all widgets which are
ActionControls as instances of this type. If we look at our framework for de-
scribing GUIs this is not actually the case. Each control or display is described
in its own schema and is not of a predened control type or display type. There
70
is no way for this predicate to be meaningfully included in our specication as
we do not have anything of type ActionControl to prove it about. Secondly,
it assumes that even if we do have things of a type ActionControl they will
have an observation called akey which may not be the case. So we have a
problem with identifying the things in our specication that the guidelines
relate because we do not group the GUI widgets into common types. We also
have a problem of ensuring that our descriptions of the widget types include
the necessary observations for the guideline and that we use the same naming
conventions in both guidelines and specication.
We decided, therefore, that rather than turning each guideline into a pred-
icate we would give a description of the guideline which would provide enough
information about that guideline to allow the specier to correctly interpret it
within any specication. Each guideline then will be described in three parts.
First we will state the actual guideline, next we will describe how this should
be used within a specication by describing the guideline in terms of the struc-
ture of the specication, and nally we will give an indication of how this can
be used to derive a proof that can be performed upon the specication. So
if we return to our feedback guideline, for example, it would appear in our
guideline document under the EventGenerator section as:
EventGenerators
Guideline: All EventGenerators must provide feedback to the
user.
Usage: Following a user action there must be some change to
the system state. There must not be an EventGenerator linked to
an operation in the specication which, when it has a Controlstate
with the value Active, does not cause the System to change.
Validation : Each EventGenerator in the specication should be
tested to ensure that there is no state of the ActiveOperation for
this EventGenerator where the Controlstate has a value Active and
the System state before the operation is the same as the System
71
state after the operation.
Being able to understand and use this description relies on the fact that the
specication has been written following the framework we have provided for
describing the GUI in Z. It expects that there may be some controls described
in the specication that are EventGenerators, but it no longer relies on this
being a Z type in the specication, just that we can identify which things in
the specication the EventGenerators are (we would expect supporting text
in the specication to make this identication or use of naming conventions
such as SomeOperationEventGenerator). Using this guideline description also
requires that anything that is an EventGenerator will have an observation of
type Controlstate which can have a value of Active and that the EventGener-
ator in conjunction with the operation it is linked to will be described as an
ActiveOperation. If we look again at the example we presented at the end of
section two, we can see that when we follow the framework we do indeed meet
these requirements:
ShowMessageOperation
System
smevent? : EVENT
dmevent! : EVENT
smevent? = MessageEvent
currentMessage

= HelloWorld
dmevent! = DisplayMessageEvent
smevent? ,= MessageEvent
currentMessage

= currentMessage
dmevent! = NoEvent
72
ShowMessageControl
smcstate : CONTROLSTATE
smevent! : EVENT
smcstate = Active smevent! = MessageEvent
smcstate = NotActive smevent! = NoEvent
ActiveShowMessageOperation =
ShowMessageControl >>ShowMessageOperation>>MessageResponder
Of course, not every guideline can be ultimately used to create a predicate
and be formally proven within a specication. For some guidelines, following
the usage information in the guideline document will be enough to ensure that
the guideline is adhered to by the specication. For example consider the
following consistency guideline:
ActionControls
Guideline: Be consistent in the terminology of ActionControls.
Usage: Label ActionControls with consistent names. ActionCon-
trols should be labelled with a verb which describes their action.
Give all ActionControls an observation of type CONTROLLABEL.
Dene the values for CONTROLLABEL to include a verb for each
of the operations in the system which are linked to ActionControls.
Validation : Following the usage description will ensure the
guideline is satised.
In this case following the instructions given in the guideline is enough to en-
sure that our specication satises that guideline and no further proof work
is required. When we begin the renement process and our widget descrip-
tions become more and more specic these types of guidelines become more
common. This is because many of the more specic guidelines relate to visual
73
aspects of specic widgets and we can use similar methods of describing what
observations their descriptive schemas should include to ensure that they meet
these guidelines.
In order to create our guidelines document then, we will do the following.
Working through the original guideline document we will identify each of the
guidelines and the widget categories that they apply to. Under each of the
category headings we will format the guideline as described above. Guidelines
which apply to specic widgets will appear at the end of the category they
belong to, so for each category we will begin with the most general guidelines
which apply to everything in that category and as we move down the doc-
ument we will get more and more specic until we reach the guidelines for
actual widgets. There will be some general guidelines, or principles, which will
produce multiple guidelines in our document when we consider their meaning
in terms of the widget categories. For example, the guideline Be consistent
can lead to guidelines to ensure not just the consistency of the terminology
used, as we described above, but also a guideline that states that all controls
with the same label perform the same operation as this provides the user with
a consistent GUI.
The act of translating the original guidelines into our new guideline docu-
ment should be carefully performed. It requires a clear understanding of what
each of the guidelines really means and what intent we want to capture when
we apply them to our specications. Although this may appear to add another
overhead to the design process, this translation only needs to be done once,
and then the document is available for all subsequent specications. One of
the advantages of this process is that in spending the time to decide what
each of the guidelines really means and describing it unambiguously we can
be sure that there will be no confusion when we come to use these guidelines.
One common problem with the existing use of guidelines by designers is that
they can be interpreted in dierent ways. We hope that we can eliminate this
problem with our methods. In Appendix A we give an example of the sort of
74
document we would produce if we were to reformat the GNOME guidelines
[24] in this way.
One thing we have not considered yet is whether guidelines are mandatory
or not. Sometimes we may have principles which are desirable, but not es-
sential, or the type of project we are working on may dictate how important
certain guidelines are. The easiest way to deal with this is to assign priori-
ties to the guidelines during the construction of the guideline document. For
example we could use a numeric priority where a priority of one means that
a guideline is mandatory and must be included, and then we assign dierent
numbers for diering levels of importance. When we come to use the guideline
document for a particular specication the designer then needs to be informed
as to what priority level they are working to. For example if it is a priority
three project, then they must use all of the guidelines with a priority of one to
three. In this way the guideline document can be tailored for specic projects
without any additional work beyond the initial construction of the guideline
document. We have not adopted this idea of priorities within any of our exam-
ples in this project, but we consider it a useful addition and worthy of further
attention in any future work.
4.3 Putting the Guidelines to Work
We now have a framework for specifying the GUI and a framework for creating
the guidelines document. The nal stage is to show how we can use these two
things together in a useful way. We will present a small example here to
show the process for using the guideline document in conjunction with our
specication.
For this example we will return to the HelloWorld system we described in
section two. Based on the requirements of the system, and using our framework
to assist with our Z presentation, we produced the following specication:
75
First we dene the required types for the specication.
MESSAGE ::= HelloWorld [ NoMessage
EVENT ::= MessageEvent [ DisplayMessageEvent [ NoEvent
CONTROLSTATE ::= Active [ NotActive
RESPONSESTATE ::= On [ O
Now we describe the system itself which consists of a single observation which is the
current message.
System
currentMessage : MESSAGE
The initial state of the system has no message.
InitSystem
System
currentMessage

= NoMessage
There is one system operation which will change the system state so that its cur-
rentMessage observation will be HelloWorld if the input observation has a value
of MessageEvent. If this is the case the output observation will be DisplayMes-
sageEvent, otherwise it will be NoEvent, and the currentMessage observation will
not change.
76
ShowMessageOperation
System
smevent? : EVENT
dmevent! : EVENT
smevent? = MessageEvent
currentMessage

= HelloWorld
dmevent! = DisplayMessageEvent
smevent? ,= MessageEvent
currentMessage

= currentMessage
dmevent! = NoEvent
Now we describe the controls which will allow the user to interact with the system.
First we have an ActionControl
ShowMessageControl
smcstate : CONTROLSTATE
smevent! : EVENT
smcstate = Active smevent! = MessageEvent
smcstate = NotActive smevent! = NoEvent
Secondly we have a Responder
MessageResponse
messageDisplay : RESPONSESTATE
77
MessageResponder
MessageResponse
dmevent? : EVENT
dmevent? = DisplayMessageEvent messageDisplay

= On
dmevent? ,= DisplayMessageEvent messageDisplay

= O
Now we link the operation to the controls.
ActiveShowMessageOperation =
ShowMessageControl >>ShowMessageOperation>>MessageResponder
Finally we describe the RootWindow for this system.
RootWindow
ShowMessageControl
MessageDisplay
Now if we wish to include guidelines in this specication what do we need to
do? If we look at the specication we see that we have two dierent categories
of widgets described: one ActionControl and one Responder. For this small
example then the only parts of the guideline document we will need to be con-
cerned with are the parts that describe the ActionControl and the Responder
guidelines. Under the ActionControl section we may have the following:
Guideline: Give all action controls a unique keyboard shortcut.
Usage: Give all ActionControls an observation of type KeyShort-
cut. Dene the set of allowable values for KeyShortcut to include a
unique value for each of the ActionControls described in the spec-
ication.
Validation: Following the usage described will ensure the guide-
line is satised.
78
To satisfy this guideline we rst need to follow the usage information given.
We rene our specication with this additional information so that we have
an additional type description, and an amended description for the ShowMes-
sageControl.
KEYSHORTCUT ::= S [ NoKey
ShowMessageControl
smcstate : CONTROLSTATE
smevent! : EVENT
smckey : KEYSHORTCUT
smckey = Ssmcstate = Active smevent! = MessageEvent
smcstate = NotActive smevent! = NoEvent
Next we would look to the validation information to see if further work is
required. In this case we do not have to do anything else to satisfy the guideline.
There is only one ActionControl in the specication so we only require one value
for the KEYSHORTCUT type. We provide the NoKey value to allow us to
use this observation in subsequent renements should we want to include this
observation in the schema of some other type of control. The value of S that
we give to the smckey observation in ShowMessageControl is an abstract value.
We do not know what this will be in the nal implementation, but if we have
a number of controls with this observation we will be able to see that they do
not have the same value.
We have shown how we would use the guideline document in conjunction
with a small specication by way of this small example. In the next section of
this report we will move onto some larger examples, and discuss some dierent
applications for our work.
79
5 Examples and Applications
5.1 Renement Assistance
Our initial investigations into our method of specifying interfaces and formally
describing guidelines presented us with dierent ways of applying this work.
One of the applications of including guidelines at the specication stage is
to assist with the renement of that specication. The interface specication
framework described in section 2.7 of this report can be used in conjunction
with the specication of guidelines described in section 4 to help determine
which particular types of widgets, or actual widgets, should be used in the
implementation. Not only does this make the job of the specier and designer
easier by guiding their choices throughout the design process, but it also pro-
vides another benet. By using the guidelines to assist in the choice of widget
we will often automatically incorporate the particular requirements given by
the guidelines directly into our specication. By this we mean that if we use
the guidelines and framework to assist with the renement, we necessarily
produce a renement which satises those guidelines.
As an example of this consider the following partial specication segment.
This specication relates to a dialogue window where a user is able to set
certain options for the way their text is displayed within an application.
In this simplied example we will describe text as a sequence of some set of
elements called CHAR and suggest that the appearance of the text is controlled
by three things only: the type, size and style of the text font. We describe
these using the given sets FONTTYPE and FONTSTYLE and the enumerated
set FONTSIZE which has three possible values.
[CHAR, FONTTYPE, FONTSTYLE]
FONTSIZE ::= Small [ Medium [ Large
We also describe the set EVENT which is the set of possible events which may
occur and two other enumerated sets which describe the behaviour of the in-
81
terface. We do not elaborate again here on the meaning of CONTROLSTATE
or SELECTION, but as described previously in section 2.7 they are intended
to capture the notion of user interaction with the interface which causes these
states to change. For example we may imagine that when a user moves the
mouse over a button and clicks then the CONTROLSTATE of that button will
take a value of Active.
EVENT ::= ChangeFontSizeEvent [ ChangeFontTypeEvent [
ChangeFontStyleEvent [ NoEvent
CONTROLSTATE ::= Active [ NotActive
SELECTION ::= Selected [ NotSelected
Next we describe the state we are interested in which is captured in the
TextDisplay schema. We have some text which has the three previously de-
scribed font properties.
TextDisplay
text : seq
1
CHAR
fsize : FONTSIZE
ftype : FONTTYPE
fstyle : PFONTSTYLE
Finally for this example we will consider just a single system operation which
allows the font size to be changed. A full specication would of course have
similar operations for changing the other properties of the font.
82
ChangeFontSize
TextDisplay
eventValue? : FONTSIZE
event? : EVENT
event? ,= ChangeFontSizeEvent fsize

= fsize
event? = ChangeFontSizeEvent fsize

= eventValue?
text

= text
ftype

= ftype
fstyle

= fstyle
We can now begin to consider the specication for the interface to this
small system. Before we can describe the type of control that will cause the
ChangeFontSize operation to occur, we need to consider the behaviour that we
wish the control to exhibit. From this we will infer the type of the control using
our widget hierarchy. Recall that when we described the widget hierarchy in
Section 2.7 we noted that it was possible for widgets to fall under multiple
categories. We need to keep this in mind as we use the widget hierarchy as
the basis for the start of our renement. We will consider each of the major
categories in turn as a decision tree. We work our way down the tree by
examining the questions at each branch and choosing the appropriate path.
When we reach a point where we do not yet know the answer to one of the
questions, or we have reached a leaf representing a specic widget, we stop.
This may mean we stop right at the rst branch at the top of the tree because
we do not yet know enough, or we are still dealing with the interface at too
abstract a level. We will then continue with this partially rened specication
until we either do know more or we decide we can leave further decisions to
the designer.
For example, we may begin by considering whether the widget is a control
or a display. If it will interact with the underlying system then it is a control,
83
so we must decide what sort of control it is. If activation of this control will
cause an a system operation to occur then what we are dealing with is an
event generator. The decision tree for event generators is shown in gure 7.
We work down this tree as previously described until we have chosen one of
the nodes or leaves as our currently most rened description.
Figure 7: Event Generator Decision Tree
We subsequently repeat this for each decision tree within the widget hi-
erarchy. The decision trees for all of the categories are given in Appendix B
.
In our example there are three possible font sizes which we have described
as Small, Medium or Large. We want the user to be able to change the size
of the text font by selecting a new value from the control, so there are a
range of possible outcomes depending on the users choice. If we refer to
gure 7 this leads us to a SelectionControl. Further, because we know that
there are dierent possible values which must be captured we want a Value
SelectionControl. Finally we need to consider whether the control will produce
a single value when activated or whether it will produce several values. In
the case of setting the text to a font size we need to consider only a single
value at any given time, so we can rene our choice to that of a Single Value
84
SelectionControl.
We describe this by rst considering each individual selection choice as a
Binary SelectionControl, and then grouping these together (this mirrors the
actual way in which we create, for example, button groups when we design
an interface). This may appear to give us enough information to continue.
However, one thing which we have not yet considered is whether or not this
is the only category this widget falls under. In fact another purpose of this
control is to indicate to the user what the current setting for font size is, which
will assist them with making changes. For example if the user wants to reduce
the size of the font it is important that they know if the current font size is the
smallest, otherwise they may try to further reduce the font by selecting the
Small option but the font size will not change. This control, therefore, is also
a StatusDisplay. We use the selection observations to capture this information
by ensuring that the before state of the control always matches the current
system state.
SmallSizeSelector
sselected : SELECTION
MediumSizeSelector
mselected : SELECTION
LargeSizeSelector
lselected : SELECTION
85
ChangeFontSizeControl
TextDisplay
SmallSizeSelector
MediumSizeSelector
LargeSizeSelector
cstate : CONTROLSTATE
event! : EVENT
eventValue! : FONTSIZE
(fsize = Small sselected = Selected
mselected = NotSelected lselected = NotSelected)
(fsize = Medium sselected = NotSelected
mselected = Selected lselected = NotSelected)
(fsize = Large sselected = NotSelected
mselected = NotSelected lselected = Selected)
sselected

= Selected mselected

= NotSelected
lselected

= NotSelected
mselected

= Selected sselected

= NotSelected
lselected

= NotSelected
lselected

= Selected sselected

= NotSelected
mselected

= NotSelected
(sselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Small )
(mselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Medium)
(lselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Large)
The use of TextDisplay in this schema may appear strange at rst given that
this control will be used in conjunction with the ChangeFontSize operation
to change the value of the fsize observation. However, we are only including
TextDisplay to ensure that we have the current value of fsize which is required
86
for the StatusDisplay role of this control. We use this slightly more verbose
method to ensure both consistency with our GUI description framework and
to provide clarity for the reader. We now describe ActiveChangeFontSize in
the usual way:
ActiveChangeFontSize = ChangeFontSizeControl >>ChangeFontSize
At this stage we are ready to use the guidelines to assist with further
renement. Often this process will lead us to a specic implementation decision
as the rest of this example will demonstrate. The guidelines we will use here
are taken from the Apple Human Interface Guidelines [4].
There are seven possible widget types within theSingle Value SelectionCon-
trol category. For this example we will consider two of them and show how
we can make a correct decision regarding their appropriateness in this situa-
tion. Let us suppose we are considering rening our ChangeFontSizeControl to
either a RadioButtonGroup or a CheckBoxGroup, which would appear in our
interface implementation as follows:
Figure 8: Widget Options for FontSizeControl
If we refer to our chosen set of guidelines we nd the following information:
Use radio buttons for a set of mutually exclusive choices
Use checkboxes to indicate one or more options that must be either
on or o
87
Within our guideline specication we could describe these two types of widgets
as schemas with these guidelines included as predicates:
RadioButtonGroup
radiobuttons : FRadioButton
2 #radiobuttons 8

1
a : radiobuttons a.selected = Selected
CheckBoxGroup
checkboxes : PCheckBoxes
2 #checkboxes 8
a : checkboxes a.selected = Selected
In our ChangeFontSizeControl specication, the observations labelled Small-
SizeSelector, MediumSizeSelector and LargeSizeSelector represent the sets ra-
diobuttons or checkboxes in the guidelines. If we inspect the predicate part of
ChangeFontSizeControl we see that we describe the selected behaviour of the
individual selection controls such that exactly one is selected at any given time.
If we compare this with the RadioButtonGroup and CheckBoxGroup schemas
from our guidelines we can see that we have exactly the same constraints on
the RadioButtonGroup, whereas the selection behaviour of the CheckBoxGroup
is unconstrained. We can use this information to guide our choice and rene
our ChangeFontSizeControl to something which includes a RadioButtonGroup.
We have shown with this example how the process of renement can be
aided both by the widget hierarchy and decision trees and reference to at
this early specication stage. The nal part of this section of examples will
demonstrate some of the proofs we can perform and how to resolve problems
that may arise from this.
88
5.2 Tests and Proofs
One of the purposes of specifying systems prior to implementation is to ensure
that we have correctly understood the requirements of the system and have
subsequently designed something which will correctly meet these requirements.
We have already stated that interface design guidelines can be considered to
be part of the requirements of a system. As such we want to be able to gain
the same assurances from our specications, namely that we have correctly
specied a system whose interface will respect the guidelines.
The next example shows how our methods can be used to prove that a
proposed interface has the desirable properties given by guidelines and, con-
versely, how we can identify areas within our specication which do not satisfy
those guidelines.
For this example we will consider the interface to a simple graphical shapes
system consisting of just three operations. The system is to show a picture
of a particular shape based on user choice. The user can choose from three
dierent shapes: a circle, a square or a triangle. Once the user has selected a
shape it is displayed until they make a dierent choice. Repeatedly selecting
the same shape will have no eect as the shape will remain displayed from the
rst choice. The only time the system may display no shape is when it rst
starts up. An initial specication to this system is:
SHAPE ::= Circle [ Square [ Triangle [ NoShape
EVENT ::= DrawCircleEvent [ DrawSquareEvent [ DrawTriangleEvent [
ChangeShapeEvent [ NoEvent
CONTROLSTATE ::= Active [ NotActive
First we describe the system and its operations:
System
currentShape : SHAPE
89
InitSystem
System
currentShape

= NoShape
DrawCircleOperation
System
dcevent? : EVENT
sdevent! : EVENT
sdeventValue! : SHAPE
dcevent? = DrawCircleEvent currentShape

= Circle
sdevent! = ChangeShapeEvent sdeventValue! = Circle
dcevent? = NoEvent currentShape

= currentShape
sdevent! = NoEvent
DrawSquareOperation
System
dsevent? : EVENT
sdevent! : EVENT
sdeventValue! : SHAPE
dsevent? = DrawSquareEvent currentShape

= Square
sdevent! = ChangeShapeEvent sdeventValue! = Square
dsevent? = NoEvent currentShape

= currentShape
sdevent! = NoEvent
90
DrawTriangleOperation
System
dtevent? : EVENT
sdevent! : EVENT
sdeventValue! : SHAPE
dtevent? = DrawTriangleEvent currentShape

= Triangle
sdevent! = ChangeShapeEvent sdeventValue! = Triangle
dtevent? = NoEvent currentShape

= currentShape
sdevent! = NoEvent
Then we describe the interface to the system:
DrawCircleControl
dcControlState : CONTROLSTATE
dcevent! : EVENT
dcControlState = Active dcevent! = DrawCircleEvent
dcControlState = NotActive dcevent! = NoEvent
DrawSquareControl
dsControlState : CONTROLSTATE
dsevent! : EVENT
dsControlState = Active dsevent! = DrawSquareEvent
dsControlState = NotActive dsevent! = NoEvent
91
DrawTriangleControl
dtControlState : CONTROLSTATE
dtevent! : EVENT
dtControlState = Active dtevent! = DrawTriangleEvent
dtControlState = NotActive dtevent! = NoEvent
ShapeDisplayResponder
displayedShape : SHAPE
ShapeDisplay
ShapeDisplayResponder
sdevent? : EVENT
sdeventValue? : SHAPE
sdevent? = ChangeShapeEvent displayedShape

= sdeventValue?
sdevent? = NoEvent displayedShape

= displayedShape
ActiveDrawCircleOperation =
DrawCircleControl >>DrawCircleOperation>>ShapeDisplay
ActiveDrawSquareOperation =
DrawSquareControl >>DrawCircleOperation>>ShapeDisplay
ActiveDrawTriangleOperation =
DrawTriangleControl >>DrawCircleOperation>>ShapeDisplay
92
RootWindow
ShapeDisplay
DrawCircleControl
DrawSquareControl
DrawTriangleControl
We can now use this example in conjunction with some guidelines and try
to prove some of the properties given by those guidelines about the system .
We use the GNOME Human Interface guidelines [24] for this example.
The original system requirements for our example stated that
Repeatedly selecting the same shape will have no eect as the shape
will remain displayed from the rst choice
We can observe that our system adheres to this requirement, as if we per-
form the DrawCircleOperation when the currentShape observation of System
is Circle, the resulting system state has currentShape

also having the value of

Circle. However, if we consider this at an interface level what happens? The
user activates the DrawCircleControl, perhaps for the rst time, and a circle
appears in the display window. If they then activate the DrawCircleControl
again no change is observed in the interface. This is the correct behaviour
for our system, but to the user it appears that their action has had no eect.
This may not appear to be a problem in this toy example as it would seem
obvious that as a circle is already displayed then no action is necessary if circle
is selected again. In larger more complex interfaces, where a similar condition
may occur, it is not always so obvious that this is the case, an action may
relate to a hidden part of the underlying system state, and a similar lack of
response in that instance is not so intuitively interpreted. It is partly for this
reason that the guidelines used for this example contain the following:
Provide appropriate feedback to the user in response to their ac-
93
tions.
As we have discussed previously this is too abstract a guideline to be of imme-
diate assistance within our specication, but in our guideline document we will
have considered its meaning in terms of each of the widget categories. If we
look at the categories used in our interface description we can see which of these
has a feedback guideline and use the information in the guideline document
to see if this holds in our specication. The guidelines for EventGenerators
contains the following:
Guideline: All EventGenerators must provide feedback to the
user.
Usage: Following a user action there must be some change to
the system state. There must not be an EventGenerator linked
to an operation in the specication which, when it has a CON-
TROLSTATE observation with the value Active, does not cause
the system to change.
Validation: Each EventGenerator in the specication should be
tested to ensure that there is no state of the ActiveOperation which
includes the EventGenerator where the CONTROLSTATE obser-
vation has a value Active and the system state before the operation
is the same as the system state after the operation.
We can, therefore, use this information to restate the guideline in the termi-
nology of our specication as follows:
There must not be an EventGenerator linked to an operation in the specica-
tion which, when it has a controlstate with the value Active, does not cause
the System to change.
The EventGenerators and their operations in the specication are:
DrawCircleControl and DrawCircleOperation
DrawSquareControl and DrawSquareOperation
DrawTriangleControl and DrawTriangleOperation
94
The operations already contain a before System state and an after System
state, so now we can derive the following predicates:
exists DrawCircleControl ; DrawCircleOperation
dcControlState = Active System

= System
exists DrawSquareControl ; DrawSquareOperation
dsControlState = Active System

= System
exists DrawTriangleControl ; DrawTriangleOperation
dtControlState = Active System

= System
In fact we can simplify these predicates further, we have already dened the
conjunction of each EventGenerator with its operation in the ActiveOperation
schema. If we replace the references to the EventGenerator and operation with
this, we have:
ActiveDrawCircleOperation dcControlState = Active
System

= System
ActiveDrawSquareeOperation dsControlState = Active
System

= System
ActiveDrawTriangleOperation dtControlState = Active
System

= System
If each of these can be proven to be true in our specication then we can
be sure we have satised the guideline. For this example we will test just
the rst of these predicates, using Z/EVES. Trying the predicate in Z/EVES
and instantiating the appropriate observations during the proof gives us the
following proof summary:
try ( ActiveDrawCircleOperation dcControlState = Active
System = System

);
95
rewrite;
instantiate currentShape == Circle;
rewrite;
instantiate currentShape == Circle, displayedShape == Circle;
displayedShape == Circle
reduce;
Z/EVES returns
false
Had we correctly specied our system in accordance with this guideline we
would have expected a result of true. This shows that we have failed to satisfy
the predicate and therefore the guideline.
Having seen there is a problem we need to nd out what it is. Our proof
has shown that if the System is in a state where the currentShape observation
is Circle and the DrawCircleControl is active, then the DrawCircleOperation
produces a new state of the System where the currentShape observation is
also Circle, i.e. the state has not changed. We must now consider how we
may change our interface specication so that this behaviour does not occur.
There are several possible solutions: one would be to reset the system back
to NoShape if the same control is activated more than once in succession.
Examination of our original system requirements however lead us to discount
this as it does not adhere to the requested behaviour. Another solution may
be to introduce an error indicator so that a message can be displayed to the
user explaining the system behaviour. If we refer again to our guidelines we
nd we have additional information which can assist us
Sometimes it does not make sense to allow the user to interact with
a control in the current context ... At these times, make the control
insensitive to minimize the risk of user error. While a control is
insensitive, it will appear dimmed and will not be able to receive
the focus.
96
The guideline document then assists us in rening our specication to follow
this described pattern. The guideline document given in Appendix A contains
the following:
Action Controls
Guideline: If an ActionControl is to be inactive in a display do
not remove it, give it a disabled state.
Usage: Give ActionControls which may be inactive in a display
an observation ABLESTATE. Dene the set of allowable values of
ABLESTATE as follows:
ABLESTATE ::= Enabled | Disabled
Any ActionControl in a disabled state must not be able to be acti-
vated by a user.
Validation: Show that the following holds true for all ActionCon-
trols which have this observation:
When the ABLESTATE observation of the control is Disabled then
the CONTROLSTATE is NotActive.
When the CONTROLSTATE observation of the control is Active
then the ABLESTATE is Enabled.
The state of the system which leads to an ActionControl being dis-
abled and subsequently enabled again must be dened.
We can include this within our example which gives us the renement
ABLESTATE ::= Enabled [ Disabled
97
DrawCircleControl
dcAState : ABLESTATE
dcControlState : CONTROLSTATE
dcevent! : EVENT
dcAState = Disabled dcControlState = NotActive
dcControlState = Active dcAState = Enabled
dcControlState = Active dcevent! = DrawCircleEvent
dcControlState = NotActive dcevent! = NoEvent
Note that we use the two dierent implications within the predicate because
the conditions are not transitive, that is if dcAState is Enabled it does not
hold that dcControlState must be Active, likewise if dcControlState is NotAc-
tive it does not hold that dcAState must be Disabled. We similarly rene the
DrawSquareControl and DrawTriangleControl. We also need to dene predi-
cates which determine when the controls are Enabled and when they are Dis-
abled.
DrawCircleControlPred
System
DrawCircleControl
currentShape = Circle dcAState = Disabled
currentShape ,= Circle dcAState = Enabled
We do likewise for the DrawSquareControl and DrawTriangleControl. Now we
must include these in the denitions of the ActiveOperations:
98
ActiveDrawCircleOperation =
(DrawCircleControl >>DrawCircleOperation>>ShapeDisplay)
DrawCircleControlPred
ActiveDrawSquareOperation =
(DrawSquareControl >>DrawCircleOperation>>ShapeDisplay)
DrawSquareControlPred
ActiveDrawTriangleOperation =
(DrawTriangleControl >>DrawCircleOperation>>ShapeDisplay)
DrawTriangleControlPred
Our proof is now much simpler. In order for the after state of an operation
to be the same as the before state, currentShape and currentShape

must be the
same, but for each possible value of currentShape we have added the constraint
that the control required to cause currentShape

to display that same shape

is not active and therefore the operation can no longer take place. We have
therefore rened our specication so that it adheres to the guideline. We can
again use Z/EVES to prove this.
try ( ActiveDrawCircleOperation dcControlState = Active
System = System

);
rewrite;
instantiate currentShape == Circle;
rewrite;
instantiate currentShape == Circle, displayedShape == Circle;
displayedShape == Circle
reduce;
cases;
prove by reduce;
next;
99
instantiate currentShape == Circle, dcAState == Enabled,
displayedShape == Circle, displayedShape == Circle;
reduce;
instantiate currentShape == Circle, dcevent! == DrawCircleEvent;
prove by reduce;
next;
Completing all cases produces ...
true
We can see from this example that it is possible to not only identify prob-
lems with interfaces from their specications if they do not adhere to guidelines,
but it is also possible to use the guidelines to assist with rectifying the prob-
lem. This process can be repeated for all of the relevant guidelines being used
until we have a nal specication which we are sure (because we have proved
it) satises all requirements including those given by the guidelines.
5.3 Bringing it Together
The previous examples have shown how we can use our work in dierent ways.
It can assist us in producing a specication of a system and system interface
which which can be proven to adhere to a set of specic guidelines. It can also
be used to help rene the specication to describe more specic widgets based
on the guidelines.
In our examples so far we have concentrated on small aspects of the Z
specication and have abstracted away some of the detail not required to show
the application of our methods. Within a full system specication we would
normally expect to see a lot more information about both the operations and
states of the system as well as the interface. As well as the formal Z, we would
expect supporting text to assist the understanding of the Z as well as diagrams
and charts. Our work is no dierent in that respect and we would similarly
expect to include such supporting information.
100
One area we have not focused on so far are guidelines relating to visual
aspects of the GUI. Such guidelines are often concerned with both the appear-
ance of particular widgets and the spatial relationships between those widgets.
We have deliberately not focused on spatial relationships between widgets for
the reasons presented in section 2.4 regarding levels of detail within a specica-
tion and readability and usefulness of overly-detailed specications. However,
there are, in fact, ways of including this information, as well as other visual
concepts which does not cause these problems. We can do this by dening
particular relationships and widget formats and then using these denitions
within the specication rather than the lower level detail.
Many of the visual aspects included in guidelines are found in platform
specic guidelines such as those given by Apple [4] and GNOME [24]. It is often
the case that at the specication stage we do not want to concern ourselves
with this type of low level detail, we are more concerned with a more abstract
view of the system. However eventually we will rene our specications to
specic implementations which will need to take such things into consideration.
Particular examples of visual guidelines include such things as dening dierent
types of appearances for widget categories. In [4], for example, we have the
following:
Icon Buttons
An icon button behaves like a bevel button, but does not have a
rectangular edge around it; the entire button is clickable, not just
the icon.
Size of icon: 32 x 32 pixels recommended.
Text: Small system font. The text should be below the icon
At rst it appears that this level of detail requires a much more detailed spec-
ication than we have so far presented. The fact that the size of the widget is
given in pixels may appear to return us to the notion of a pixel-level descrip-
tion of each screen of an interface which we previously stated was unhelpful
to the point of being unusable. However, if we consider the whole design and
101
implementation process we nd that the platform-specic nature of these pro-
vides something more which we can use within our specications to solve this
problem. We can do this if we take platform-specic guidelines in the context
of the design and development environments used to actually build such soft-
ware. Organisations and groups responsible for operating systems and window
managers such as the AppleOS, Windows, GNOME etc. provide libraries of
their specic widget sets which are direct implementations of the eects given
in the guidelines. What this means is that whilst is may appear that guidelines
which refer to the size of an icon in pixels or particular appearances such as
bevelled or brushed metal require much more detailed specications in order
to be able to prove satisability of these guidelines, this is actually not the
case.
When using the appropriate operating system libraries or design environ-
ments (for example Apples Interface Builder) we nd that many of these
guidelines can be abstracted into more general commands which the design
environment will take care of. For example if we create a small icon button
in the Apple Interface builder we automatically get the 32x32 pixel size and
small system font size as default behaviour. All the designer needs to know
is that it is a small icon button that is required. This is precisely the sort of
additional information we can include in our specications as text information
to allow us to retain a more abstract description without losing the precision
of the guidelines. Within the specication we will state that our widgets are
to be taken from a particular widget library or that a particular GUI building
tool will be used. We can use the descriptions given in these interface tools
directly in our specication with a reference to their detailed meaning. For
example if we give a predicate to a button such as
isBevelButton
then we can include in our specication the information which explains what
102
this predicate means in terms of our widget library, i.e. what the appearance,
size, text requirements are for this particular widget. We can then excuse
ourselves from talking any further about these details which are now captured
within our specication by this predicate.
It should be stated again that is not our intention to produce all speci-
cations at such a low level of abstraction. Certainly in the early stages of a
specication we do not want to be limited by considerations about operating
system platforms or widget libraries. However if we are to produce methods
which are usable in general in software design and implementation we must
also recognise that once renement towards a more concrete implementation
begins these are exactly the sorts of guidelines we will need to include if our
processes are to be successful.
We will now consider two further examples which are of larger systems.
The rst shows how are work may be applied in very specialised areas such as
the design of safety critical systems. The second takes an existing real-world
application and re-evaluates it within the context of our work.
5.4 A Safety Critical System
Our rst large example is that of part of an interface to a safety critical system.
Such systems are frequently identied as those where a correct formal speci-
cation is essential, for example the Radiation Therapy machine described by
Jacky in [30]. Similarly we should expect that the interfaces to such systems
are treated with equal importance and that their correct usage by operators is
a clear incentive for the work presented in this report. The notion of system
failure in interactive systems where interfaces do not correctly interact with
the system has been covered comprehensively by Johnson in works such as [36]
and [37]. One of our intentions is to extend this idea to include the failure of
a user to correctly interact with an interface as another form of such a system
failure. In this example we show how potential problems in the design of a
safety critical interface may be avoided by using our methods.
103
The example we present here is taken from the work by Knight and Bril-
liant given in [39]. In this paper Knight and Brilliant use a variety of dierent
specication techniques to capture the requirements for building a digital con-
trol system to the University of Virginia Reactor which is used for the training
of nuclear engineering students. We reproduce this particular example partly
because it is a clearly dened example of a safety critical system, and partly
to show how our dierent approach to interface specication may capture par-
ticular usability problems which was not part of the scope of the work in [39].
Knight and Brilliant present a suggested interface for one part of the digital
system which was partially automatically generated using a technique based
on Borlands Object Windows Library (OWL) and a lexical description of the
interface using Z. They do not present their example as a nal interface; it was
work in progress and the authors comment that much subsequent revision of
the lexical description and specication took place after consultation with the
nuclear technicians. We suggest that there are some possible problems with
the interface they present which could have been avoided by incorporating
guidelines at the specication stage and we use our example to identify these
and show how they may be avoided.
The example interface for a shim rod control system given in [39] is shown
in gure 9
Figure 9: Interface Given by Knight and Brilliant
The description for this section of the interface and its functionality is given
104
in [39] as follows:
Note: the present operators console refers to the non-computerised version of the
console used to derive the specication for the new system.
Recall that the three safety control rods (also called shim rods)
provide gross control of reactivity and are an element of the safety
system. For each of these control rods, the present operators con-
sole includes a set of four lights:
Engaged
This light indicates whether the rod is magnetically coupled to its
drive mechanism
Up
This light indicates whether the rod is fully withdrawn
Down
This light indicates whether the drive mechanism is at its lowest
level
Seated
This light indicates whether the rod is fully inserted into the core,
regardless of the position of the drive mechanism.
For each control rod there are also displays indicating the rod height
and the magnetic current to the rod attachment mechanism. To
allow the operator control of each rod, there are controls allowing
the operator to set the magnet current and to raise and lower the
rod. The operator can either move the rod by a small increment
or move the rod continuously at a predetermined speed.
The standard operating procedures in the current manual system
allow the operator to move the rods only when the neutron ux
measurement exceeds a prescribed threshold (thereby indicating
that the instrument is operating).
105
We begin by specifying the described behaviour of this part of the system
which is concerned with the levels and movement of the rods and the position
and state of the drive mechanism. As each of the shim rods has the same
operations and interface elements, we will present only those detailed oper-
ations and interface elements relating to shim rod one here. The complete
specication for all three shim rods is given in Appendix C.
The drive mechanism for the rods has two states, which we describe using
a free type. The position of the mechanism may be at any point within the
range of its movement, but we are only required to note when it is at its lowest
point. We therefore give a free type with the values of lowest or other for this
observation.
DriveMechanismState ::= Coupled [ Uncoupled
DriveMechanismPosition ::= Lowest [ Other
The position of any of the three rods, if not fully withdrawn or inserted, is
given a numeric value so that it is possible to determine its position to within
1/100 of the insertion tube height at any given time.
RodPosition ::= Withdrawn [ Inserted [ Intermediate0 . . 100))
We use a constant for the numeric values of RodAttachmentMechanism for
ease of reading in the specication,
RodAttachmentMechanism == N
and give a global value for the Neutron Flux Threshold which provides the
safety functionality for this part of the system.
NFluxThreshold : N
106
We start be describing each of the components of the Shim Rod System, i.e.
each of the three individual shim rods.
ShimRodOne
dms1 : DriveMechanismState
dmpos1 : DriveMechanismPosition
rp1 : RodPosition
ram1 : RodAttachmentMechanism
ShimRodTwo
dms2 : DriveMechanismState
dmpos2 : DriveMechanismPosition
rp2 : RodPosition
ram2 : RodAttachmentMechanism
ShimRodThree
dms3 : DriveMechanismState
dmpos3 : DriveMechanismPosition
rp3 : RodPosition
ram3 : RodAttachmentMechanism
Next we dene the Shim Rod System which is made up of each of these rods,
as well as an observation regarding the value of the Neutron Flux.
ShimRodSystem
ShimRodOne
ShimRodTwo
ShimRodThree
NeutronFlux : N
107
Each of the shim rods can be moved provided the neutron ux constraint is
met. Movement may be up or down and may be one increment at a time, or
a continuous movement. In order to dene these operations we rst need to
dene the set called EVENT which are the permitted events that occur in this
system. These are the events which will link the interface specication to the
system operations. The values for this set are identied during the process of
specifying the system operations, we identify each of the events required as we
describe the operation and use this to build up values for the set.
EVENT ::= SROneRodMoveUpEvent [ SROneRodMoveDownEvent [
SRTwoRodMoveUpEvent [ SRTwoRodMoveDownEvent [
SRThreeRodMoveUpEvent [ SRThreeRodMoveDownEvent [
SROneCurrentChangeEvent [ SRTwoCurrentChangeEvent [
SRThreeCurrentChangeEvent [ SROneEngagedEvent [
SROneDisengagedEvent [ SRTwoEngagedEvent [
SRTwoDisengagedEvent [ SRThreeEngagedEvent [
SRThreeDisengagedEvent [ SROneDMLowerEvent [
SROneDMRaiseEvent [ SRTwoDMLowerEvent [
SRTwoDMRaiseEvent [ SRThreeDMLowerEvent [
SRThreeDMRaiseEvent [ SROneRodWithdrawnEvent [
SROneRodInsertedEvent [ SRTwoRodWithdrawnEvent [
SRTwoRodInsertedEvent [ SRThreeRodWithdrawnEvent [
SRThreeRodInsertedEvent [ SROneRodHeightEvent [
SRTwoRodHeightEvent [ SRThreeRodHeightEvent [
SROneRodIntermediateEvent [ SRTwoRodIntermediateEvent [
SRThreeRodIntermediateEvent [ NoEvent
Now we can dene the actual operations of the system. The movement of
each rod depends upon the rods starting position, the amount of the move-
ment and the relationship between these two things. For both the upward
and downward movement operations we therefore describe the ve possible
movements seperately and then combine them using schema disjunction into
108
a single RodMoveOperation schema.
SROneRodMoveUpNoMove
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Withdrawn rp1

= rp1
srorwevent! = SROneRodWithdrawnEvent
srorievent! = None
srormidevent! = None
srorhevent! = None
srorhvalue! = 0
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
109
SROneRodMoveUpFully
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Inserted srouvalue? 100 rp1

= Withdrawn
srorwevent! = SROneRodWithdrawnEvent
srorievent! = None
srormidevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 0
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
110
SROneRodMoveUpFromBottom
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Inserted srouvalue? < 100
rp1

= Intermediate(100 srouvalue?)
srormidevent! = SROneRodIntermediateEvent
srorwevent! = None
srorievent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = (100 srouvalue?)
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
111
SROneRodMoveUpWithdraw
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
Intermediate

rp1 srouvalue? 0 rp1

= Withdrawn
srorwevent! = SROneRodWithdrawnEvent
srorievent! = None
srormidevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 0
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
112
SROneRodMoveUpPartial
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
Intermediate

rp1 srouvalue? > 0

rp1

= Intermediate((Intermediate

rp1) srouvalue?)
srormidevent! = SROneRodIntermediateEvent
srorwevent! = None
srorievent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = (Intermediate

rp1) srouvalue?
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
113
SROneRodMoveUp
ShimRodOne
srouevent? : EVENT
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
NeutronFlux NFluxThreshold
srouevent? = SROneRodMoveUpEvent
(SROneRodMoveUpNoMove
SROneRodMoveUpFully
SROneRodMoveUpFromBottom
SROneRodMoveUpWithdraw
SROneRodMoveUpPartial )
srouevent? ,= SROneRodMoveUpEvent
(rp1

= rp1 dms1

= dms1
dmpos1

= dmpos1 ram1

= ram1
NeutronFlux

= NeutronFlux
srorwevent! = None
srorhevent! = None)
114
SROneRodMoveDownNoMove
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Inserted rp1

= rp1
srorievent! = SROneRodInsertedEvent
srorhevent! = None
srorievent! = None
srormidevent! = None
srorhvalue! = 100
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
115
SROneRodMoveDownFully
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Withdrawn srodvalue? 100 rp1

= Inserted
srorievent! = SROneRodInsertedEvent
srorwevent! = None
srormidevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 100
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
116
SROneRodMoveDownFromTop
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Withdrawn srodvalue? < 100
rp1

= Intermediate(0 +srodvalue?)
srormidevent! = SROneRodIntermediateEvent
srorwevent! = None
srorievent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 0 +srodvalue?
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
117
SROneRodMoveDownInsert
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
Intermediate

rp1 +srodvalue? 100 rp1

= Inserted
srorievent! = SROneRodInsertedEvent
srorwevent! = None
srormidevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 100
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
118
SROneRodMoveDownPartial
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
Intermediate

rp1 +srodvalue? < 100

rp1

= Intermediate((Intermediate

rp1) +srodvalue?)
srormidevent! = SROneRodIntermediateEvent
srorwevent! = None
srorievent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = (Intermediate

rp1) +srodvalue?
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
119
SROneRodMoveDown
ShimRodOne
srodevent? : EVENT
srodvalue? : 0 . . 100
srorievent! : EVENT
srormidevent! : EVENT
srorwevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
NeutronFlux NFluxThreshold
srodevent? = SROneRodMoveDownEvent
(SROneRodMoveDownNoMove
SROneRodMoveDownFully
SROneRodMoveDownFromTop
SROneRodMoveDownInsert
SROneRodMoveDownPartial )
srodevent? ,= SROneRodMoveDownEvent
(rp1

= rp1 dms1

= dms1
dmpos1

= dmpos1 ram1

= ram1
NeutronFlux

= NeutronFlux
srorievent! = None
srorhevent! = None)
SROneTotalMove = SROneRodMoveUp SROneRodMoveDown
This completes the move operations for shim rod one.
The other behaviour of this part of the system is to control the magnetic
current to each of the rods.
120
SROneCurrentChange
ShimRodOne
srocevent? : EVENT
srocvalue? : N
srocevent? = SROneCurrentChangeEvent ram1

= srocvalue?
srocevent? ,= SROneCurrentChangeEvent ram1

= ram1
dmpos1

= dmpos1
rp1

= rp1
dms1

= dms1
The drive mechanism may also be raised or lowered, so we provide operations
for this. As we are concerned only with the mechanism being at its lowest
point, or not, we describe just the operation to cause it to be at its lowest
point irrespective of its starting position.
SROneLowerDriveMechanism
ShimRodOne
srodmevent! : EVENT
dmpos1

= Lowest
srodmevent! = SROneDMLowerEvent
dms1

= dms1
rp1

= rp1
ram1

= ram1
Similarly for the raise operation it is enough to show that the drive is no
longer at its lowest point, we do not need to detail its actual height.
121
SROneRaiseDriveMechanism
ShimRodOne
srodmevent! : EVENT
dmpos1

= Other
srodmevent! = SROneDMRaiseEvent
dms1

= dms1
rp1

= rp1
ram1

= ram1
There are some operations which will not be controlled from this part of
the system, however they are linked to controls which will appear in this part
of the system interface. For example the requirements we used as our basis
describes an Engaged light. However, there is no operation in our specied
system so far which controls whether or not any of the rods are engaged or not
as this requirement was not given for this part of the system. We can assume
that this system operation is controlled by some other part of the over all
system which we are not describing in this example. For completeness we will
describe operations which engage and disengage the rods but we will provide
no controls in this part of the interface to cause these operations to occur,
these would be provided in some other part of the system interface.
SROneEngageRod
ShimRodOne
sroeevent! : EVENT
dms1

= Coupled
sroeevent! = SROneEngagedEvent
rp1

= rp1
dmpos1

= dmpos1
ram1

= ram1
122
SROneDisengageRod
ShimRodOne
sroeevent! : EVENT
dms1

= Uncoupled
sroeevent! = SROneDisengagedEvent
rp1

= rp1
dmpos1

= dmpos1
ram1

= ram1
Having described the underlying behaviour of the Shim Rod System we can
now move on to the interface elements required to provide this functionality to
the user. We use the original system description provided as the basis for this
interface, starting with the widgets required to provide the desired functional-
ity and then categorising them using our widget hierarchy categories based on
their desired behaviour. Once again to avoid duplication we present the details
for the shim rod one controls of the interface only here, the specication for
the controls for shim rods two and three can be found in Appendix C.
The interface requirements start with a description of four lights.
For each of these control rods, the present operators console in-
cludes a set of four lights:
Engaged - this light indicates whether the rod is magnetically cou-
pled to its drive mechanism
Up - this light indicates whether the rod is fully withdrawn
Down - This light indicates whether the drive mechanism is at its
lowest level
Seated - This light indicates whether the rod is fully inserted into
the core
123
Each of these lights have an on or o state which is dependent on some value
within the system state which may change. We can therefore identify them as
event responders and describe them accordingly.
We start by describing a free set for an observation of whether or not a
light is on.
LIGHTSTATE ::= LightOn [ LightO
Now we use the model given by our framework in section 2.7 to describe the
behaviour of these event responders.
SROneEngagedResponseState
el 1state : LIGHTSTATE
SROneEngagedLight
SROneEngagedResponseState
sroeevent? : EVENT
sroeevent? = SROneEngagedEvent el 1state

= LightOn
sroeevent? = SROneDisengagedEvent el 1state

= LightO
sroeevent? ,= SROneEngagedEvent
sroeevent? ,= SROneDisengagedEvent
el 1state

= el 1state
ActiveSROneEngageRod =
SROneEngageRod>>SROneEngagedLight
ActiveSROneDisengageRod =
SROneDisengageRod>>SROneEngagedLight
We follow the same model for describing each of the other lights required.
124
SROneDownResponseState
dls1 : LIGHTSTATE
SROneDownLight
SROneDownResponseState
srodmevent? : EVENT
srodmevent? = SROneDMLowerEvent dls1

= LightOn
srodmevent? = SROneDMRaiseEvent dls1

= LightO
srodmevent? ,= SROneDMLowerEvent srodmevent?
,= SROneDMRaiseEvent dls1

= dls1
ActiveSROneDMLower =
SROneLowerDriveMechanism>>SROneDownLight
ActiveSROneDMRaise =
SROneRaiseDriveMechanism>>SROneDownLight
The Up light and the Seated light both respond to the rods TotalMove oper-
ations and as such can be seen to operate as a pair, if one is on the other must
be o and vice versa (although there is no problem with both being o). We
therefore describe them as a pair of lights in one schema and link them to the
TotalMove operation in the usual way.
SROneUpLightResponseState
uls1 : LIGHTSTATE
SROneSeatedLightResponseState
sls1 : LIGHTSTATE
125
SROneUpSeatedLight
SROneUpLightResponseState
SROneSeatedLightResponseState
srorwevent? : EVENT
srorievent? : EVENT
srormidevent? : EVENT
(srorwevent? = SROneRodWithdrawnEvent
uls1

= LightOn sls1

= LightO )
(srorievent? = SROneRodInsertedEvent
uls1

= LightO sls1

= LightOn)
(srormidevent? = SROneRodIntermediateEvent
uls1

= LightO sls1

= LightO )
We do not show the link between the TotalMove operation and the Lights
immediately as we also need to consider the rod height display control which we
will give rst. The rod height display is also categorised as an event responder,
based on the required behaviour, which gives us the following specication:
SROneRodHeightResponseState
srorhdisplay : 0 . . 100
SROneRodHeightDisplay
SROneRodHeightResponseState
srorhevent? : EVENT
srorhvalue? : 0 . . 100
srorhevent? = SROneRodHeightEvent
srorhdisplay

= srorhvalue?
srorhevent? ,= SROneRodHeightEvent
srorhdisplay

= srorhdisplay
126
Next we have the magnetic current display which is also an event responder.
SROneMCDisplayResponseState
sromcdisplay : N
SROneMagneticCurrentDisplay
SROneMCDisplayResponseState
srocevent? : EVENT
srocvalue? : N
srocevent? = SROneCurrentChangeEvent
sromcdisplay

= srocvalue?
srocevent? ,= SROneCurrentChangeEvent
sromcdisplay

= sromcdisplay
The nal part of the interface specication relates to the controls which
cause the rods to move and the magnetic current to change. All of these
controls will be event generators as they will cause system operations to occur,
in addition they will each pass a single value to the operation and as such
will be described as single value selection controls. We begin by describing
a selection state which will be used to indicate when a user has activated a
control.
SELECTEDSTATE ::= Selected [ NotSelected
127
SROneMoveUpControl
sromuselected : SELECTEDSTATE
sromusetvalue : 0 . . 100
srouevent! : EVENT
srouvalue! : 0 . . 100
sromuselected = Selected srouevent! = SROneRodMoveUpEvent
sromuselected = NotSelected srouevent! = None
sromusetvalue = srouvalue!
SROneMoveDownControl
sromdselected : SELECTEDSTATE
sromdsetvalue : 0 . . 100
srodevent! : EVENT
srodvalue! : 0 . . 100
sromdselected = Selected
srodevent! = SROneRodMoveDownEvent
sromdselected = NotSelected
srodevent! = None
sromdsetvalue = srodvalue!
Now we can link the movement controls and displays to the operations.
ActiveSROneTotalMove =
(SROneMoveUpControl SROneMoveDownControl )
>>SROneTotalMove>>(SROneUpSeatedLight
SROneRodHeightDisplay)
The nal part of our interface description is the magnetic current change
control.
128
SROneMagCurrentChangeControl
sromccselected : SELECTEDSTATE
sromccsetvalue : N
srocevent! : EVENT
srocvalue! : N
sromccselected = Selected
srocevent! = SROneCurrentChangeEvent
sromccselected = NotSelected
srocevent! = None
sromccsetvalue = srocvalue!
ActiveSROneCurrentChange = SROneMagCurrentChangeControl >>
SROneCurrentChange>>SROneMagneticCurrentDisplay
Generally, once this part of the specication was completed we would begin
testing to ensure we have specied the correct behaviour and that our spec-
ication captures that behaviour correctly. This may include things such as
ensuring specic safety constraints cannot be broken within this system, and
also that the information displayed in the interface is always correct given the
current underlying system state. Testing of specications is a complex and
dicult task. Methods of verifying specications through animation of the
specication itself or translating the specication into some executable lan-
guage are well researched, and well documented in works such as those by
Diller [19], Jacky [30] and West and Eaglestone [56] to select just a few. Like-
wise the procedures for testing and validation of formal specication is a large
research area and includes such work as Hamlet [26], Myers [42] and many
others. It is not our intention to repeat descriptions of this work here or show
how it may be achieved. We provide one example of a specication test which
may usefully be performed as an indication of how such work can be applied to
129
our interface specication and then move onto the focus of our example, that
of showing how guidelines may be used to improve this interface and nding
ways of testing for their correctness.
The verication test we show here is that of ensuring the engaged light
is always on after the EngageRod operation has successfully engaged the rod.
First we try the negative case where we test if it is possible for the light to be
o after this action. We use Z/EVES for our testing and begin by loading our
specication into Z/EVES which allows us to perform type checking on the
given specication before we begin our other tests.
We give the following test to Z/EVES:
try ActiveSROneEngageRod [
dms1 := Uncoupled, dms1

:= Coupled, dmpos1 := Lowest,

dmpos1

:= Lowest, rp1

:= Inserted, ram1

:= 100,
rp1 := Inserted, ram1 := 100, el 1state := LightO ,
el 1state

:= LightO ];
Z/EVES returns
false
which is what we expect in this case. Now if we repeat the test with the after
state of the light dened to be LightOn
try ActiveSROneEngageRod [
dms1 := Uncoupled, dms1

:= Coupled, dmpos1 := Lowest,

dmpos1

:= Lowest, rp1

:= Inserted, ram1

:= 100,
rp1 := Inserted, ram1 := 100, el 1state := LightO ,
el 1state

:= LightOn];
Z/EVES returns
130
true
which shows us that this part of the interface has the correct behaviour.
At this stage we are ready to test to see if there are any problems with our
specication in respect of the guidelines. Guidelines used for such a specialised
system will combine both general interface guidelines which are applicable
across all interfaces, as well as guidelines which are specic to the domain of
this particular interface. As we did not have access to a set of guidelines used
in such a design domain, this example uses some general guidelines from Smith
and Mosier [51].
The specication as it as been described so far is still missing one element.
Recall that as part of our framework we have stated that each application must
have one Window which is described as the RootWindow. This is to ensure
that there is at least a description of some interface which is visible when the
application is running. For this example where we are describing one part of
a larger system we still use the notion of a RootWindow but in this case it
will be the entire interface we are concerned with for the shim rod control
system. We could then describe this as the conjunction of all of the controls
and display widgets that have been specied, which would leave all decisions
about how the layout and visual design of the interface to the person who
implements the interface. The specication could, in fact, be a specication of
the interface given by Knight and Brilliant which we presented in gure 9 as
all of the controls we have included in the specication appear in this interface.
We have stated that there are problems with this interface which could be
avoided if we include guidelines into our specication. We will now make some
renements to that specication using information given by the guidelines
and see how that may exclude the interface given in gure 9 as a possible
implementation.
In Smith and Mosier we have the following guideline:
Logical Data Organization
Ensure that displays are formatted to group items on the basis of
131
some logical principle.
A specication of these guidelines, following the format we have described,
may include this as follows:
Frames
Guideline: Use Frames to group related Controls together.
Usage: Use Frames within Displays to group related items. A
Frame is described in a schema which includes the schemas of the
related Controls. The Display should be described as the conjunc-
tion of its relevant Frames and other Controls.
Validation: Identify items which are to be grouped and ensure
that a Frame has been described which is the conjunction of only
those grouped items.
Within our specication as it stands we do not have any frames described,
so clearly this guideline does not currently hold in the specication. However,
we do have elements in our interface which should be grouped together, namely
the controls for each of the separate shim rods. We have already described
the state schemas for these controls and now we can consider grouping them
together within another state schema. We should have one group for elements
relating to shim rod one, one for the elements relating to shim rod two and
one group for elements relating to shim rod three. If we use the guideline
information to assist us with deciding how to specify the RootWindow we can
see that rather than just describing a single window as the conjunction of all of
the widgets we should instead describe three frames, one for each set of shim
rod controls, and then combine these to describe to RootWindow. This leads
to the following partial renement for the specication:
132
ShimRodOneFrame
SROneEngagedLight
SROneDownLight
SROneUpSeatedLight
SROneRodHeightDisplay
SROneMagneticCurrentDisplay
SROneMoveUpControl
SROneMoveDownControl
SROneMagCurrentChangeControl
We describe the frames for the other shim rods similarly and then combine these for
the complete interface.
ShimRodInterface =
ShimRodOneFrame ShimRodTwoFrame ShimRodThreeFrame
If we now look again at the interface given by Knight and Brilliant which
we repeat in gure 10 we see that a specication of this interface could not
satisfy the guideline given as the complete interface can only be described as a
collection of all of the shim rod widgets. Although the widgets for each shim
rod are positioned together there is no clear demarkation between them and
the magnetic current change control for shim rod one is next to the magnetic
current display and light for shim rod two which is confusing. This confusion
is exactly what the grouping guideline is intended to avoid.
133
Figure 10: Interface Given by Knight and Brilliant
There is another serious problem with this interface which we can avoid
if we make reference to the guidelines. If we assume that we have rened
our specication to the point where the implementation given in gure 10
is acceptable (apart from the lack of identiable grouping), then each of the
actual widgets selected for use in the interface should adhere to the guidelines
for that specic widget. The magnetic current control in this example has been
rened to a slider control, each of the shim rods has the following control:
Figure 11: Magnetic Current Control
The problem with this is that when using the slider there is no way of
telling what the new value of the magnetic current will be from looking at the
control. In a safety critical system we would expect a degree of precision in
such a control which can only be achieved if the user can see exactly what
eect their changes will have as they make them. If we refer to Smith and
Mosier [51] and look at the guidelines for slider controls, we nd the following:
134
2.4.1/3 Labeling
Label each scale clearly with its description and measurement units
Within our specication of the guidelines we would expect to see this under
the Selection Controls section.
Slider Controls
Guideline: Ensure Sliders have values displayed.
Usage: Sliders should contain an observation DisplayValue with
a type which is the same as the output eventValue!. The predicate
of the Slider schema should contain the following:
DisplayValue = eventValue!
Validation: Following the usage description will ensure the guide-
line is satised.
This is another example of how the information given in the guidelines ensures
that if we rene to a particular widget then we can be sure that widget will
adhere to the guidelines if we describe it in accordance with the guideline
specication.
We have seen in this example how two important problems with an interface
can be avoided using our methods. In the interface to something as safety-
critical as a nuclear power plant we want to ensure that users are not confused
about which control relates to which shim rod or what value they are changing
the magnetic current to as they operate the change control. By identifying
these problems at the specication stage we can hope that subsequent user-
testing of our proposed interface would highlight other, unknown, problems
of the interface, the tester would not be distracted by nding (we hope) the
sorts of problems we have identied which are already known to be common
problems of interfaces which have been identied in guidelines.
135
5.5 A Real World Interface
This example begins with the supposition that we wish to specify an applica-
tion for the GNOME desktop manager on a Linux system. The application
provides functionality for opening, reading and printing PDF les. For this
example we will concentrate on specifying the interface of the system, provid-
ing abstract descriptions of only those system operations which are necessary
to show the underlying connectivity between system and interface. Included
in the specication will be guidelines from the GNOME interface guideline
specication given in Appendix A and we will show how we can perform some
validation tests using Z/EVES to ensure we have correctly incorporated the
required guidelines. We will then look at the specication of an actual imple-
mentation of such a system, the GNOME PDF Viewer, and endeavour to prove
whether or not it is a correct renement of our specication, or rather, more
importantly, whether or not it too adheres to the same GNOME guidelines.
We start by identifying the dierent types of things our system will need
to do in order to provide the required functionality. It will need to be able to
navigate through and browse a le system and identify les of the correct type
i.e. les with a .pdf extension. Then it will need to provide a list of these les
and allow for selection of one le. Once a le has been selected the system
needs to load the data and display it in a manner which allows the user to
navigate between dierent parts of that le.
Having decided what the system should do, we next consider the actions
a user will need to perform to interact with the system, then we can consider
what widgets will be required for these actions. The user needs to be able
to interact with the system in a way which allows them to view a selection
of les that can be opened by the application. Then they need to be able to
select and open one of these les, and subsequently navigate through that le
for reading purposes as well as print it. From this we can identify that there
are at least four distinct controls required, as well as two dierent window
views, one where there is no open le and one where there is an open le. For
136
convenience, and to assist with our proofs later, we will dene a set of readable
les. However, generally we would be more abstract in our specication and
just describe the set FILENAME without giving any values.
FILENAME ::= FileOne [ FileTwo [ FileThree [ NoFile
CONTROLSTATE ::= Active [ NotActive
EVENT ::= OpenFileEvent [ PrintFileEvent [ MoveFileForwardEvent [
MoveFileBackwardEvent [ FileDisplayEvent [ None
PRINTINGSTATE ::= Printing [ NotPrinting
EOF : N
PdfViewerApplication
openFile : FILENAME
printState : PRINTINGSTATE
lePos : N
openFile = NoFile lePos = 0
lePos 0
lePos EOF
InitPdfViewerApplication
PdfViewerApplication
openFile

= NoFile
printState

= NotPrinting
lePos

= 0
137
OpenFileControl
ofevent! : EVENT
ofeventvalue! : FILENAME
ofstate : CONTROLSTATE
cvalue : FILENAME
ofstate = Active ofevent! = OpenFileEvent
ofeventvalue! = cvalue
ofstate = NotActive ofevent! = None
OpenFileOperation
PdfViewerApplication
ofevent? : EVENT
ofeventvalue? : FILENAME
ofevent? = OpenFileEvent openFile

= ofeventvalue?
lePos

= 1
ofevent? ,= OpenFileEvent openFile

= openFile
lePos

= lePos
printState

= printState
ActiveOpenFile = OpenFileControl >>OpenFileOperation
PrintFileControl
pfevent! : EVENT
pfstate : CONTROLSTATE
pfstate = Active pfevent! = PrintFileEvent
pfstate = NotActive pfevent! = None
138
PrintFileOperation
PdfViewerApplication
pfevent? : EVENT
pfevent? = PrintFileEvent printState

= Printing
pfevent? ,= PrintFileEvent printState

= printState
openFile

= openFile
lePos

= lePos
ActivePrintFile = PrintFileControl >>PrintFileOperation
MoveFileForwardControl
mevent! : EVENT
mstate : CONTROLSTATE
mstate = Active mevent! = MoveFileForwardEvent
mstate = NotActive mevent! = None
MoveFileForwardOperation
PdfViewerApplication
mevent? : EVENT
(mevent? = MoveFileForwardEvent lePos < EOF)
lePos

= lePos + 1
lePos = EOF lePos

= lePos
mevent? ,= MoveFileForwardEvent lePos

= lePos
printState

= printState
openFile

= openFile
139
ActiveMoveFileForward =
MoveFileForwardControl >>MoveFileForwardOperation
MoveFileBackwardControl
mfbevent! : EVENT
mfbstate : CONTROLSTATE
mfbstate = Active mfbevent! = MoveFileBackwardEvent
mfbstate = NotActive mfbevent! = None
MoveFileBackwardOperation
PdfViewerApplication
mfbevent? : EVENT
(mfbevent? = MoveFileBackwardEvent lePos > 0)
lePos

= lePos 1
lePos = 0 lePos

= lePos
mfbevent? ,= MoveFileBackwardEvent lePos

= lePos
printState

= printState
openFile

= openFile
ActiveMoveFileBackward =
MoveFileBackwardControl >>MoveFileBackwardOperation
FileDisplayResponse
fdle : FILENAME
140
FileDisplayResponder
FileDisplayResponse
fdevent? : EVENT
fdeventValue? : FILENAME
fdevent? = FileDisplayEvent fdle

= fdeventValue?
fdevent? ,= FileDisplayEvent fdle

= fdle
FileDisplayOperation
PdfViewerApplication
fdevent! : EVENT
fdeventValue! : FILENAME
fdeventValue! = openFile
fdevent! = FileDisplayEvent
ActiveDisplayFile = FileDisplayOperation>>FileDisplayResponder
InitDisplay
OpenFileControl
OpenFileDisplay
FileDisplayResponder
PrintFileControl
MoveFileForwardControl
MoveFileBackwardControl
Having created a basic abstract specication for our interface and underlying
system, we can now look at the guidelines and see what additional information
141
we can include at this level of abstraction. We are designing our PDF viewing
application for the GNOME desktop system and so will use our specication
of the GNOME guidelines, which is given in Appendix A. From this guideline
specication we can see that the only applicable guidelines at this level of
abstraction are those which apply to ActionControls and Displays as these are
the only categories of widgets we have in our specication at the moment.
From the guideline specication we have:
Action Controls
Guideline: Provide unique keyboard shortcuts for ActionCon-
trols.
Usage: Give all ActionControls an observation KEYSHORTCUT.
Dene a set of allowable values for KEYSHORTCUT including the
null value of NoKey. This null value allows the observation to be
used by other Controls where the presence of a keyboard shortcut
key is not mandatory.
Validation: For all ActionControls ensure that the KEYSHORT-
CUT observation does not have a value of NoKey. In addition
ensure that no two ActionControls have the same value for the
KEYSHORTCUT observation unless they generate the same event.
Guideline: If an ActionControl is to be inactive in a display
do not remove it, give it a disabled state.
Usage: Give ActionControls which may be inactive in a display
an observation ABLESTATE. Dene the set of allowable values of
ABLESTATE as follows:
ABLESTATE ::= Enabled | Disabled
Any ActionControl in a disabled state must not be able to be acti-
vated by a user.
142
Validation: Show that the following holds true for all Action-
Controls which have this observation:
When the ABLESTATE observation of the control is Disabled then
the CONTROLSTATE is NotActive.
When the CONTROLSTATE observation of the control isActive
then the ABLESTATE is Enabled.
The state of the system which leads to an ActionControl being dis-
abled and subsequently enabled again must be dened.
Guideline: RootWindows should use the application name as their
title.
Usage: Give all RootWindows an observation WINDOWTITLE.
Dene the allowable set of values for WINDOWTITLE as:
WINDOWTITLE ::= Application | FileName | FilePath |
Activity | Description | NoWindowTitle
Validation: For all RootWindows ensure that the WINDOWTI-
TLE observation is Application.
Guideline: Give all RootWindows the following window com-
mands:
Close, Maximise, Minimise
Usage: The specication must describe four Controls as follows:
143
CloseWindowControl
cwcstate : CONTROLSTATE
cwcevent : EVENT
cwcstate = Active
cwcevent! = CloseWindowEvent
cwcstate = NotActive cwcevent! = None
MaximiseWindowControl
maxwcstate : CONTROLSTATE
maxwcevent : EVENT
maxwcstate = Active
maxwcevent! = MaximiseWindowEvent
maxwcstate = NotActive maxwcevent! = None
MinimiseWindowControl
minwcstate : CONTROLSTATE
minwcevent : EVENT
minwcstate = Active
minwcevent! = MinimiseWindowEvent
minwcstate = NotActive minwcevent! = None
Dene the values for WINDOWSIZE and WINDOWVISIBLE as:
WINDOWSIZE ::= Minimum | Maximum | Standard |
UserDened
WINDOWVISIBLE ::= Visible | NotVisible
144
Dene the following response state for all RootWindows:
WindowResponseState
wsize : WINDOWSIZE
wvisible : WINDOWVISIBLE
All RootWindows should include the three previously dened Con-
trols as well as an inclusion of primed and unprimed copies of Win-
dowResponseState.
Validation: For all RootWindows ensure that the following things
are true:
If the cwcevent observation is CloseWindowEvent then the wvisible

observation must be NotVisible.

If the minwcevent observation is MinimiseWindowEvent then the
wsize

observation must be Minimum .

If the maxwcevent observation is MaximiseWindowEvent then the
wsize

observation must be Maximum .

Taking the information given by these guidelines into consideration, we can
now rene our interface description.
145
FILENAME ::= FileOne [ FileTwo [ FileThree [ NoFile
CONTROLSTATE ::= Active [ NotActive
PRINTINGSTATE ::= Printing [ NotPrinting
EVENT ::= OpenFileEvent [ PrintFileEvent [ MoveFileForwardEvent [
MoveFileBackwardEvent [ FileDisplayEvent [ CloseWindowEvent [
MinimiseWindowEvent [ MaximiseWindowEvent [ None
KEYSHORTCUT ::= A [ B [ C [ D [ E [ F [ G [ NoKey
ABLESTATE ::= Enabled [ Disabled
WINDOWTITLE ::= Application [ FileName [ FilePath [ Activity [
Description [ NoTitle
WINDOWSIZE ::= Minimum [ Maximum [ Standard [ UserDened
WINDOWVISIBLE ::= Visible [ NotVisible
Note that for the KEYSHORTCUT set we provide values from A to G as well
as the null NoKey value, these are not intended to be actual values, e.g. A
could represent the key combination Control O and should not be interpreted
to mean the key A. These are abstract values but are listed to show that
they have dierent values. This would become important if values were to be
duplicated across the interface.
EOF : N
PdfViewerApplication
openFile : FILENAME
printState : PRINTINGSTATE
lePos : N
openFile = NoFile lePos = 0
lePos 0
lePos EOF
146
InitPdfViewerApplication
PdfViewerApplication
openFile

= NoFile
printState

= NotPrinting
lePos

= 0
OpenFileControl
ofevent! : EVENT
ofeventvalue! : FILENAME
ofstate : CONTROLSTATE
cvalue : FILENAME
ofkey : KEYSHORTCUT
ofastate : ABLESTATE
ofkey = A
ofastate = Disabled ofstate = NotActive
ofstate = Active ofevent! = OpenFileEvent
ofeventvalue! = cvalue
ofstate = NotActive ofevent! = None
OpenFileOperation
PdfViewerApplication
ofevent? : EVENT
ofeventvalue? : FILENAME
ofevent? = OpenFileEvent openFile

= ofeventvalue?
lePos

= 1
ofevent? ,= OpenFileEvent openFile

= openFile
lePos

= lePos
printState

= printState
147
ActiveOpenFile = OpenFileControl >>OpenFileOperation
PrintFileControl
pfevent! : EVENT
pfstate : CONTROLSTATE
pfkey : KEYSHORTCUT
pfastate : ABLESTATE
pfastate = Disabled pfstate = NotActive
pfstate = Active pfevent! = PrintFileEvent
pfstate = NotActive pfevent! = None
pfkey = B
PrintFileOperation
PdfViewerApplication
pfevent? : EVENT
pfevent? = PrintFileEvent printState

= Printing
pfevent? ,= PrintFileEvent printState

= printState
openFile

= openFile
lePos

= lePos
ActivePrintFile = PrintFileControl >>PrintFileOperation
148
MoveFileForwardControl
mevent! : EVENT
mstate : CONTROLSTATE
mfkey : KEYSHORTCUT
mfastate : ABLESTATE
mfastate = Disabled mstate = NotActive
mstate = Active mevent! = MoveFileForwardEvent
mstate = NotActive mevent! = None
mfkey = C
MoveFileForwardOperation
PdfViewerApplication
mevent? : EVENT
(mevent? = MoveFileForwardEvent lePos < EOF)
lePos

= lePos + 1
lePos = EOF lePos

= lePos
mevent? ,= MoveFileForwardEvent lePos

= lePos
printState

= printState
openFile

= openFile
ActiveMoveFileForward =
MoveFileForwardControl >>MoveFileForwardOperation
149
MoveFileBackwardControl
mfbevent! : EVENT
mfbstate : CONTROLSTATE
mbkey : KEYSHORTCUT
mbastate : ABLESTATE
mbastate = Disabled mfbstate = NotActive
mfbstate = Active mfbevent! = MoveFileBackwardEvent
mfbstate = NotActive mfbevent! = None
mbkey = D
MoveFileBackwardOperation
PdfViewerApplication
mfbevent? : EVENT
(mfbevent? = MoveFileBackwardEvent lePos > 0)
lePos

= lePos 1
lePos = 0 lePos

= lePos
mfbevent? ,= MoveFileBackwardEvent lePos

= lePos
printState

= printState
openFile

= openFile
ActiveMoveFileBackward =
MoveFileBackwardControl >>MoveFileBackwardOperation
150
CloseWindowControl
cwcstate : CONTROLSTATE
cwcevent : EVENT
cwkey : KEYSHORTCUT
cwcstate = Active cwcevent = CloseWindowEvent
cwcstate = NotActive cwcevent = None
cwkey = E
MaximiseWindowControl
maxwcstate : CONTROLSTATE
maxwcevent : EVENT
maxkey : KEYSHORTCUT
maxwcstate = Active maxwcevent = MaximiseWindowEvent
maxwcstate = NotActive maxwcevent = None
maxkey = F
MinimiseWindowControl
minwcstate : CONTROLSTATE
minwcevent : EVENT
minkey : KEYSHORTCUT
minwcstate = Active minwcevent = MinimiseWindowEvent
minwcstate = NotActive minwcevent = None
minkey = G
FileDisplayResponseState
fdle : FILENAME
151
FileDisplayResponder
FileDisplayResponseState
fdevent? : EVENT
fdeventValue? : FILENAME
fdevent? = FileDisplayEvent fdle

= fdeventValue?
fdevent? ,= FileDisplayEvent fdle

= fdle
FileDisplayOperation
PdfViewerApplication
fdevent! : EVENT
fdeventValue! : FILENAME
fdeventValue! = openFile
fdevent! = FileDisplayEvent
ActiveDisplayFile = FileDisplayOperation>>FileDisplayResponder
RootDisplayResponseState
rdwsize : WINDOWSIZE
rdwvisible : WINDOWVISIBLE
OpenFileDisplayResponseState
ofdwsize : WINDOWSIZE
ofdwvisible : WINDOWVISIBLE
152
RootDisplay
RootDisplayResponseState
CloseWindowControl
MaximiseWindowControl
MinimiseWindowControl
rdtitle : WINDOWTITLE
OpenFileControl
rdtitle = Application
cwcevent = CloseWindowEvent rdwvisible

= NotVisible
maxwcevent = MaximiseWindowEvent rdwsize

= Maximum
minwcevent = MinimiseWindowEvent rdwsize

= Minimum
OpenFileDisplay
OpenFileDisplayResponseState
ofdtitle : WINDOWTITLE
FileDisplayResponder
PrintFileControl
MoveFileForwardControl
MoveFileBackwardControl
CloseWindowControl
MaximiseWindowControl
MinimiseWindowControl
ofdtitle = FileName
cwcevent = CloseWindowEvent ofdwvisible

= NotVisible
maxwcevent = MaximiseWindowEvent ofdwsize

= Maximum
minwcevent = MinimiseWindowEvent ofdwsize

= Minimum
We now have a specication of a simple interface for our PDF application
which we expect satises the GNOME guidelines at this level of abstraction.
If we wish to fully satisfy ourselves this is the case, and especially for larger
153
specications constructed over a longer period of time by perhaps one or more
people, we would want to perform the validation tests given in the guidelines.
We will do this here to give an example of the process. The tests given here
were done by loading the specication into Z/EVES and giving the commands
shown.
Test that for all Action Controls the following predicate is true:
keyshortcut = NoKey
As an example, we give the following to Z/EVES
try OpenFileDisplay [cwkey := NoKey];
Proving gives ...
false
try ActivePrintFile [
pfstate := Active, pfkey := NoKey, pfastate := Enabled,
printState := NotPrinting, printState

:= Printing,
openFile := FileOne, openFile

:= FileOne, lePos := 1,
lePos

:= 1];
Proving gives ...
false
And to satisfy ourselves that the problem with the proof is the value of pfkey,
we can also do
154
try ActivePrintFile [
pfstate := Active, pfkey := B, pfastate := Enabled,
printState := NotPrinting, printState

:= Printing,
openFile := FileOne, openFile

:= FileOne, lePos := 1,
lePos

:= 1];
Proving gives ...
1 EOF
true
Z/EVES cannot resolve this fully as we do not have a dened value for EOF,
however if we assume a value of, e.g. 10, for EOF then we can resolve this to
true.
For our next guideline test we want to ensure that when controls are dis-
abled they cannot be made active, so we test that
ablestate = Disabled controlState = NotActive
We might start to do this with the following tests :
try ActiveOpenFile[
ofstate := Active, ofkey := A, ofastate := Disabled,
printState := NotPrinting, printState

:= NotPrinting,
openFile := NoFile, openFile

:= FileOne];
Proving gives ...
false
And again we want to ensure that the predicate we are interested in is what
155
makes the result false, and so do
try ActiveOpenFile [
ofstate := NotActive, ofkey := A, ofastate := Disabled,
printState := NotPrinting, printState

:= NotPrinting,
openFile := NoFile, openFile

:= NoFile, lePos := 0,
lePos

:= 0, cvalue := NoFile];
Proving gives ...
ofeventvalue?: FILENAME 0 EOF
We can then instantiate eventvalue?
instantiate eventvalue? == FileOne
Proving gives ...
0 EOF
true
which we can again evaluate trivially to true by assuming a value for EOF
greater than or equal to 0
Next we test the application and document window title guidelines in a similar
manner
try RootDisplay [
rdwsize := Standard, rdwsize

:= Standard, rdwvisible := Visible,

rdwvisible

:= Visible, cwcstate := NotActive, maxwcstate := NotActive,

minwcstate := NotActive, rdtitle := Activity, cwcevent := None,
cwkey := E, maxwcevent := None, maxkey := F,
minwcevent := None, minkey := G, ofevent! := None,
ofeventvalue! := FileOne, ofstate := NotActive, ofkey := A,
ofastate := Enabled, cvalue := FileOne];
Proving gives ...
156
false
try RootDisplay [
rdwsize := Standard, rdwsize

:= Standard, rdwvisible := Visible,

rdwvisible

:= Visible, cwcstate := NotActive,

maxwcstate := NotActive, minwcstate := NotActive,
rdtitle := Application, cwcevent := None,
cwkey := E, maxwcevent := None, maxkey := F,
minwcevent := None, minkey := G, ofevent! := None,
ofeventvalue! := FileOne, ofstate := NotActive, ofkey := A,
ofastate := Enabled, cvalue := FileOne];
Proving gives ...
true
And nally we test the guidelines relating to the window management controls.
cwcevent = CloseWindowEvent wvisible

= NotVisible
minwcevent = MinimiseWindowEvent wsize

= Minimum
maxwcevent = MaximiseWindowEvent wsize

= Maximum
First we test a negative case for the MaximiseWindowControl, which we expect
to be false
try RootDisplay [
rdwsize := Standard, rdwsize

:= Standard, rdwvisible := Visible,

rdwvisible

:= Visible, cwcevent := None,

maxwcevent := MaximiseWindowEvent, minwcevent := None];
Proving gives ...
false
157
Then we check that the correct behaviour can also be proved
try RootDisplay [
rdwsize := Standard, rdwsize

:= Maximum, rdwvisible := Visible,

rdwvisible

:= Visible, cwcevent := None,

maxwcevent := MaximiseWindowEvent, minwcevent := None,
cwcstate := NotActive, cwkey := E, maxwcstate := Active,
maxkey := F, minwcstate := NotActive, minkey := G,
rdtitle := Application, ofevent! := None,
ofeventvalue! := NoFile, ofstate := NotActive, cvalue := NoFile,
ofkey := A, ofastate := Enabled];
Proving gives ...
true
Next we repeat for the CloseWindowControl
try RootDisplay [
rdwsize := Standard, rdwsize

:= Standard, rdwvisible := Visible,

rdwvisible

:= Visible, cwcevent := CloseWindowEvent,

maxwcevent := None, minwcevent := None];
Proving gives ...
false
158
try RootDisplay [
rdwsize := Standard, rdwsize

:= Standard, rdwvisible := Visible,

rdwvisible

:= NotVisible, cwcevent := CloseWindowEvent,

maxwcevent := None, minwcevent := None, cwcstate := Active,
cwkey := E, maxwcstate := NotActive, maxkey := F,
minwcstate := NotActive, minkey := G, rdtitle := Application,
ofevent! := None, ofeventvalue! := NoFile, ofstate := NotActive,
cvalue := NoFile, ofkey := A, ofastate := Enabled];
Proving gives ...
true
This is not intended to be a complete testing and validation solution for
this example, rather it is intended to show the process of how we would go
about validating this specication against our included guidelines.
The nal stage of this example is to look at the specication of the actual
GNOME PDF Viewer application to see whether or not it is a correct imple-
mentation of our specication, and more importantly, whether or not we can
prove the same guideline properties hold in the application. GNOME PDF
viewer has a considerably larger interface than that proposed in the simpli-
ed example specication above, as it contains a number of dierent views,
screens, menus, dialogues etc. However for the purposes of this example we
will just consider the parts of this specication relating to the the opening
display, or RootWindow, in order to show the proposed process and usefulness
of our method. The RootWindow of the GNOME PDF Viewer is shown in
gure 12.
159
Figure 12: Opening Screen of GNOME PDFViewer
The specication of this part of the interface describes the two controls
which are displayed as buttons across the top part of the window, as well as
the menus and menu items and the window management controls at the top
right corner of the window. This part of the interface is equivalent to what we
have previously described as the RootDisplay, i.e. it is the rst visible window
when the application is launched.
If this actual implementation had been based on our example specication,
then we would expect to be able to prove that this is a renement of our
specication. In fact, of course, this real-world application is not based on
our specication, however as it has been designed specically for the GNOME
window management system we would expect that at the very least it will fol-
low the GNOME guidelines. As such, we would expect the tests we performed
on our example specication to also hold on a specication of this real system.
The specication of the RootWindow is given in Appendix D.
We will start by repeating the tests for guideline compliance we performed
160
on our example specication. For each of the ActionControls in the RootWin-
dow we want to test for the following :
keyshortcut = NoKey
If we inspect the component parts of the RootWindow, namely FileMenu,
ViewMenu, HelpMenu, OpenFileButton and IconButton which are given in
Appendix D, we can see that this does hold, except for IconButton, which is
specied as:
IconButton
iblabel : LABEL
ibicon : ICON
ibcstate : CONTROLSTATE
ibastate : ABLESTATE
ibevent! : EVENT
ibkey : KEYSHORTCUT
iblabel = NoLabel
ibicon = GNOMEDropDownArrow
ibastate = Disabled ibcstate = NotActive
ibcstate = Active ibevent! = None
ibkey : NoKey
The KEYSHORTCUT observation, which is called ibkey in this schema, does
have a value of NoKey. This is not the only problem with the IconButton
specication. In our example specication we did not rene the Controls to
particular widgets, and so were interested only in abstract guidelines relating
to Controls in general. In this case, however, where a Button is the chosen
widget, we would expect not only the Control guidelines to apply to IconBut-
ton, but also all guidelines relating to EventGenerators, the category Buttons
belong to. Recall the feedback guideline given in [24] which we dened for
161
EventGenerators as:
Guideline: All EventGenerators must provide feedback to the
user.
Usage: Following a user action there must be some change to
the system state. There must not be an EventGenerator linked
to an operation in the specication which, when it has a CON-
TROLSTATE observation with the value Active, does not cause
the system to change.
Validation: Each EventGenerator in the specication should be
tested to ensure that there is no state of the ActiveOperation which
includes the EventGenerator where the CONTROLSTATE obser-
vation has a value Active and the system state before the operation
is the same as the system state after the operation.
If we inspect the description of IconButton we see that it also violates this
guideline. There is nothing in our description of IconButton that ensures that
when ibcstate is Active ibevent! takes a particular value which is subsequently
linked to an operation. What this means for the actual implementation of this
interface is that clicking on this button has no eect, it is entirely redundant.
Presumably the designer did not give the button a keyboard shortcut as this
would be pointless for a button that does nothing, but the discovery of this
problem with the guidelines led us to inspect this part of the specication
more closely which highlighted the larger problem, i.e. that the button does
nothing. If we had been given this specication prior to implementation we
would have noted this problem and either ensured that the IconButton did
perform some function, or was removed from the interface as redundant.
Our second test was to ensure that when controls are disabled they cannot
be made active
ablestate = Disabled controlstate = NotActive
162
This is true of all of the controls in the specication which have an observa-
tion of type ABLESTATE, and for all of the menu items, which are selection
controls, the equivalent test
ablestate = Disabled selectedstate = NotSelected
also holds true.
Our next test on the example specication was on the windowtitle observa-
tion. For a RootWindow the following should hold
windowtitle = Application
and this is true within this specication.
Finally we test the window management control guidelines. We can see
that the RootWindow description contains the three controls required, and we
can test that their behaviour meets the guidelines.
cwcevent = CloseWindowEvent wvisible

= NotVisible
minwcevent = MinimiseWindowEvent wsize

= Minimum
maxwcevent = MaximiseWindowEvent wsize

= Maximum
We repeat the tests used on our example and obtain the same results. The
RootWindow description in the reverse engineered case is more complex than
in our rst description as it contains the menu items also, this means that the
proofs have to be extended somewhat to include the additional information.
163
For example the second proof test now looks like
try RootWindow [
rwsize := Standard, rwsize

:= Maximised, rwvisible := Visible,

rwvisible

:= Visible, crwevent := None, mrwevent := None,

mxrwevent := MaximiseWindowEvent, cbcstate := NotActive,
maxbcstate := Active, minrbcstate := NotActive, ofevent! := None,
rwtitle := Application, ofbcstate := NotActive, ofastate := Enabled,
rwresizable := Yes, minrblabel := NoLabel , maxblabel := NoLabel ,
minrbicon := GNOMEMinimise, maxbicon := GNOMEMaximise,
mxrevent := MaximiseWindowEvent, cblabel := NoLabel ,
cbicon := GNOMEClose, fmlabel := File, fmicon := NoIcon,
fmkey := NoKey, omlabel := Open, omicon := GNOMEOpenFolder,
omkey := CtrlO, omselstate := NotSelected, omastate := Enabled,
omevent! := None, cmlabel := Close, cmicon := GNOMEClose,
cmkey := CtrlW, cmselstate := NotSelected, cmastate := Enabled,
cmevent! := None, qlabel := Quit, qicon := GNOMEQuit,
qkey := CtrlQ, qselstate := NotSelected, qastate := Enabled,
qevent! := None, vmlabel := File, vmicon := NoIcon,
vmkey := NoKey, fslabel := FullScreen, fsicon := NoIcon,
fskey := F11, fsselstate := NotSelected, fsevent! := None
fsastate := Enabled, hmlabel := Help, hmicon := NoIcon,
hmkey := NoKey, comlabel := Contents, comicon := GNOMEContents,
comkey := F1, comselstate := NotSelected, comastate := Enabled,
comevent! := None, amlabel := About, amicon := GNOMEAbout,
amkey := NoKey, amselstate := NotSelected, amastate := Enabled,
amevent! := None, ofblabel := Open, ofbicon := GNOMEOpenFolder,
iblabel := NoLabel , ibicon := GNOMEDropDownArrow,
ibcstate := NotActive, ibastate := Enabled, ibevent! := None];
164
However, the key point of the tests, and more importantly, the results, remain
the same.
The full specication of the GNOME PDFViewer application describes ten
separate views or windows (some are dialogues, others pop-up windows). In
this example we have looked at just one of these windows, the RootWindow,
and tested for only four abstract guidelines. Even with this very small appli-
cation of the work however we were able to discover a major problem with this
interface, and one which could have been avoided had the specication been
done and the guidelines tested prior to implementation.
165
6 Assisting Designers
One of the aims of our work is to not only provide methods that can be
used by those familiar with formally specifying systems and conducting formal
proofs, we also want to provide methods that will benet those who design
and implement GUIs. In this section we look at the benets we believe our
work will provide to these designers, the problems we may encounter with this
and some possible solutions.
6.1 Making the Design Process Easier
Designers of GUIs are faced with an increasingly dicult task as the interactive
devices and methods of interaction they are designing for continue to expand
and evolve. The growth in ubiquitous computing and portable devices means
that designers are no longer concentrating on WIMP style GUIs for desktop
machines. GUIs are getting smaller and more complex, as they are required
for devices such as mobile phones and PDAs, and have to cater for users who
expect all of the interaction they can get from a desktop computer on these
small devices. At the same time, desktop computers themselves are the subject
of new and dierent styles of interaction as researchers look at methods such as
speech, aective computing, 3-D input and output devices and others. Ongoing
research into these areas is constantly suggesting new and innovative ways for
us to interact with computers. There are far too many examples of such
work to expand on this here, but some particularly interesting information on
aective computing (interaction via human emotions and senses) can be found
at [41] and novel interaction methods for PDAs at [50]. Faced with these
increasing challenges, we believe that removing one of the current overheads
of such design work, that of having to consult and follow guideline documents,
will be of benet to designers and allow them to concentrate more on these
interaction issues and the overall design of the GUI.
Designing and building GUIs is generally an iterative process. Once re-
167
quirements have been gathered and analysed in conjunction with other con-
cerns such as the results of task analysis and identication of users, the de-
signer begins the process of creating prototypes and design ideas. These are
subsequently rened, based on testing and consultation with end-users and the
designers of the other parts of the system to ensure that the design is satis-
factory. One of the problems of such a method is that at each iteration, when
changes are made, the designer needs to be sure that they are still adhering
to the guidelines they are working with. We have already stated that existing
guideline documents are often large and complicated to navigate, so this re-
examination at each stage of the iterative process can be a large overhead in
the overall design process.
If we can provide designers with an unambiguous formal specication of the
GUI then it frees them from having to worry about some of the issues relating
to guidelines and they can then concentrate on other aspects of the design.
For each iteration of the design they can then be sure that they will still be
adhering to the guidelines. Of course we will still require that they will be
familiar with the guidelines and with the general good principles of design as
a background to inform their work, but they wont be required to continually
work through the existing guideline documents and try to work out what each
guideline really means in terms of their design and how they can go about
trying to apply them within their implementations. For those designers who
rely on their memory of the guidelines rather than re-consulting them at each
iteration there is less chance of things being forgotten or overlooked.
It could be argued that formally specifying the GUI restricts design deci-
sions too much and that once we have rened the specication we will have
already done a large part of the job of the designer and created the GUI al-
ready, reducing their role to that of merely coding the implementation. We,
however, would argue that the opposite is in fact true. Just as there are many
dierent possible implementations of a system that will satisfy its specica-
tion, so there are many dierent implementations of a GUI that will satisfy
168
the specication of that GUI. If we consider our earlier HelloWorld system,
for example, and suppose that we have rened that further to specic widgets
so that we have the ActionControl dened as a Button and the Responder de-
ned as a TextField, there are many dierent ways of correctly implementing
this GUI. For example, each of the designs given in gures 13 and 14 are im-
plementations of the specication we provided for this system and rened as
described.
Figure 13: Hello World Designs One and Two
Figure 14: Hello World Design Three
Rather than constraining the creativity of the designer, we merely con-
strain the design space to ensure that whatever they produce will satisfy the
169
guidelines, as long as it satises the specication.
Of course, these benets we have described are only useful if the designer
can understand the specication, or at least a renement of that specication,
well enough to use it as the basis for their implementation. Similarly, we
would not expect that they abandon current design tools such as paper-based
prototypes or partial implementations, rather we would expect that they would
use the specication as the basis for these. In order to be sure that what they
implement or propose at any iterative design step really is correct, we must
be able to formally rene the specication to a level where the designer can
successfully use it. We must also nd ways to prove that the renement is a
correct one. This leads us on to the notion of renement for GUI specications
which we will discuss next.
6.2 Renement
Having found ways of specifying GUIs in a manner which allows us to prove
properties of that GUI in respect of design guidelines, we want to be sure that
the ultimate implementation is a true renement of the specication. In this
way we can be sure that the implementation satises the guidelines.
We have already shown how using both the widget hierarchy and the guide-
lines can assist us with making the general widgets in our specication more
specic and this allows us to produce partial renements with increasingly
more detail about the GUI. The nal step is to bridge the gap between this
more detailed GUI description and the actual implementation.
Of course, renement of abstract formal models into more concrete systems
in general and renement of Z specications in particular are areas of work
which have been very well researched. Notable work in this area includes that
of Derrick and Boiten [18], de Roever and Engelhardt [14] and Woodcock and
Davies [57] to name just a few. These works, and others, provide dierent
methods for dening the relations between abstract and concrete systems and
rules and simulations for proving the correctness of such relations. Clearly
170
we can use these established methods to rene our specications regardless
of the additional information we have included to describe the GUI part of
the system. What we would like to do, however, is look at additional, less
formal methods which would allow designers to take a specication which has
been rened and use this as the basis for their GUI implementation. Also we
want to ensure that they have some method of looking at the prototypes they
have developed and being sure that they are still correctly implementing the
specication.
In traditional methods of formal renement we are not concerned with the
choice of how we represent data and the data types used in the implementa-
tion. As long as we can prove that the program (which Woodcock and Davies
dene as a series of operations upon a data type [57]) acts in a corresponding
manner on both our abstract and concrete versions of the system (where the
correspondence is dened by the retrieve relation), then we can be satised
that they are the same.
For the purposes of assisting designers this formal process of renement
may not be the most appropriate or helpful method of communicating the
specication. It is not that we believe that there is no benet to such designers
in learning these formal processes, rather that we recognise it is a big leap
from their usual methods of design. If we can provide ways of rening the GUI
elements of the system to something that is recognisable to the designers this
gives us another tool to work with. Rather than trying to replace traditional
methods of renement we look upon this as an additional process which allows
us to communicate more eectively with the GUI designer.
In section ve of this report we presented an example showing how we
can use the guidelines to assist with a partial renement of our specication.
In that example we discussed how we could rene a SelectionControl to a
specic widget, namely a RadioButton group. We will return to this example
here and show how we can further rene this to something which is useful
and informative to the GUI designer. We had dened a SelectionControl for
171
changing the font size of some text as follows:
SmallSizeSelector
sselected : SELECTION
MediumSizeSelector
mselected : SELECTION
LargeSizeSelector
lselected : SELECTION
172
ChangeFontSizeControl
TextDisplay
SmallSizeSelector
MediumSizeSelector
LargeSizeSelector
cstate : CONTROLSTATE
event! : EVENT
eventValue! : FONTSIZE
(fsize = Small sselected = Selected
mselected = NotSelected lselected = NotSelected)
(fsize = Medium sselected = NotSelected
mselected = Selected lselected = NotSelected)
(fsize = Large sselected = NotSelected
mselected = NotSelected lselected = Selected)
sselected

= Selected mselected

= NotSelected
lselected

= NotSelected
mselected

= Selected sselected

= NotSelected
lselected

= NotSelected
lselected

= Selected sselected

= NotSelected
mselected

= NotSelected
(sselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Small )
(mselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Medium)
(lselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Large)
We then suggested that given the information in the guidelines and our knowl-
edge of the system requirements a RadioButton group was an appropriate re-
nement, in addition the RadioButton group would need to be a StatusDisplay
in order to show the current system value of the font size prior to user selec-
173
tion. As a rst step we could then reect this renement in our specication
as follows:
SmallSizeRadioButton
sselected : SELECTION
MediumSizeRadioButton
mselected : SELECTION
LargeSizeRadioButton
lselected : SELECTION
174
ChangeFontSizeRadioButtonGroup
TextDisplay
SmallSizeRadioButton
MediumSizeRadioButton
LargeSizeRadioButton
cstate : CONTROLSTATE
event! : EVENT
eventValue! : FONTSIZE
(fsize = Small sselected = Selected
mselected = NotSelected lselected = NotSelected)
(fsize = Medium sselected = NotSelected
mselected = Selected lselected = NotSelected)
(fsize = Large sselected = NotSelected
mselected = NotSelected lselected = Selected)
sselected

= Selected mselected

= NotSelected
lselected

= NotSelected
mselected

= Selected sselected

= NotSelected
lselected

= NotSelected
lselected

= Selected sselected

= NotSelected
mselected

= NotSelected
(sselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Small )
(mselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Medium)
(lselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Large)
If we were to give this to a designer they would certainly be able to determine
that they needed to put a RadioButton group into the GUI and that the in-
dividual RadioButtons within this group would represent the three choices for
font size. However, how are they to interpret things like cstate or TextDis-
175
play? What we want to be able to do is provide them with just enough infor-
mation to be able to correctly implement this.
Just as in traditional renement methods we focus on the operations, or
program, and consider inputs and outputs to these, we can do the same with
the widgets. Consider what we need to know if we want to implement a widget
in some programming language. As well as the type of the widget we need
to know what its behaviour is when activated i.e. what event it generates.
We have already considered this notion of outputs of widgets when we created
our GUI specication framework, and so have captured this information in
abstract observations of type EVENT and things we call EventValues. From
the Z description of the RadioButton group above we should then be able
to determine the information that is relevant to the designer. By relevant
we mean what is the minimum amount of information they need to correctly
implement this widget.
If we look at an example of some code which would produce the widget
we require, we gain a clearer picture of the link between the two things. We
will use Java for this example but it is not intended that this is interpreted
as a Java-specic method. In appendix E we give all of the code for a Java
class called RBGroup.java which creates a Radio Button group with the three
values of small, medium and large and displays them in a window. We will
refer to the relevant parts of this code for the rest of this example.
The Java code which creates, and initialises the RadioButton group is as
follows:
smallrb = new JRadioButton("Small");
mediumrb = new JRadioButton("Medium");
largerb = new JRadioButton("Large");
smallrb.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
resetText(8);
176
}
});
mediumrb.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
resetText(12);
}
});
largerb.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
resetText(12);
}
});
if(size == s){
smallrb.setSelected(true);
mediumrb.setSelected(false);
largerb.setSelected(false);
}
else if (size == m){
smallrb.setSelected(false);
mediumrb.setSelected(true);
largerb.setSelected(false);
}
else {
smallrb.setSelected(false);
mediumrb.setSelected(false);
largerb.setSelected(true);
}
The information the designer needs to successfully and correctly implement
this RadioButton group is:
177
The names of each of the individual radio buttons for the group
The event that will be generated upon activation
The event value that will be passed to the event upon activation
The current system value which determines which button starts with a
value of selected
There is a direct correspondence between these requirements and the Z schemas
we have given above. The names of each of the individual radio buttons
are given in the individual RadioButton selection schemas. The value of the
event! observation in the ChangeFontSizeRadioButtonGroup schema shows
that whichever of the RadioButtons is selected the same event should be gen-
erated but the eventValue! will be dierent depending on which is active. For
example:
(sselected

= Selected cstate = Active

event! = ChangeFontSizeEvent eventValue! = Small )
tells us that if the Small RadioButton is selected then an event which changes
the font size is required and a value of Small must be passed with that event.
Finally the current system value required to set one of the RadioButtons to
selected is given by the system observation fsize as follows:
(fsize = Small sselected = Selected
mselected = NotSelected lselected = NotSelected)
We can see from this that there is a clear correspondence between our
rened Z specication and the actual code. The framework we have used as the
basis for the GUI description ensures that the designer need only understand
the relevant key points, such as the concept of a CONTROLSTATE for each
widget which indicates that they have been interacted with and the event! and
178
eventValue! observations, which relate to the creation of individual widgets.
The bridge between the rened specication and the implementation then is
small enough for the GUI to be correctly designed even without the knowledge
and skills required to perform a formal renement proof. Of course we would
still expect that this should be done once the GUI is designed in order to fully
satisfy ourselves that the solution is a correct one, but we do not rely on the
GUI designers alone to be able to perform such a task.
6.3 Design Processes and Support Tools
Throughout this report we have referred to software engineering processes and
suggested that we expect a particular set of activities to occur prior to the
building of software systems. First the requirements are gathered and analysed,
and these are then used as the basis for a formal specication. The formal
specication is then validated and amended as required. Finally through a
process of renement we transform the specication into something which is
implementable and check it via renement proof theory for correctness before
the system is actually implemented. We would hope that some version of
these events would take place prior to the implementation of any new software
system. However, we recognise that this is not always the case.
Variations on this process range from those we consider good practice,
which closely model the description we have given above, to the worst-case
scenario where with no prior planning a system is coded and debugged as the
only step of development. We do not suggest that this is common practice
amongst serious software developers, but there are many dierent procedures
followed which may fall into the range between these two extremes. Addition-
ally there are many cases of software engineers working with existing systems
or legacy systems to produce replacements, upgrades or enhancements where
prior to their involvement no formal model of these systems existed.
For these reasons we have already considered it useful to discuss the no-
tion of reverse-engineering. That is, taking an existing implementation and
179
developing a formal Z specication of it. This then allows us to not only
introduce guidelines into this specication and check whether or not the im-
plementation adheres to them, it also allows us to check if the implementation
is correct with regard to a specication which has been developed subsequently,
as may be the case when working with existing and legacy systems. Finally,
it provides another way for GUI designers, who may have been working inde-
pendently from the rest of the development team, to verify their prototypes in
respect of the specication. We have already given examples of this process
of reverse-engineering in section ve of this report and shown how we can use
our understanding of the GUI framework to perform this task.
It is also useful, however, to consider not just reverse-engineering of existing
implementations but also how we may introduce the specication at some other
stage of development, or in situations where GUI design is taking place as a
separate activity from the design and development of the system as a whole.
GUI designers may be working on building prototypes or experimenting with
design ideas very early on in the development life-cycle and this could be
occurring at the same time as, or quite independently from, the development
of the system specication. It would be useful in these cases to nd ways
of assisting these designers in producing specications of these designs and
prototypes during this experimentation phase. This not only allows the entire
design team to communicate in the common language of the specication, but
it also familiarises the GUI designers with such formal specications and makes
the idea of using formal notations such as Z less alien to them.
One way to achieve this is through the use of support tools. The idea behind
such tools would be to nd ways of interpreting early designs and prototypes
and automatically generating a partial specication from them. The specica-
tions would necessarily be partial because the information would include only
the GUI and not the underlying system. However, if the specication were
suitably organised in keeping with the standard framework it should allow for
a relatively easy integration with the rest of the system specication. We are
180
not suggesting the sorts of tools often proposed by researchers such as those in
the CADUI community [10] who seek to nd ways to automatically generate
GUIs. In the case of our tools, the designer would develop their prototype or
design idea in the usual way and then the tool would reverse-engineer this into
a partial specication.
An important consideration when proposing such tools is to make them
attractive for designers to use. There is, therefore, little point in proposing
some new design environment or development language which would incorpo-
rate the capabilities we have described if designers are quite happy with the
design tools they already have access to. For this reason we propose developing
add-on tools for existing design environments and programming languages so
that they can be used in conjunction with the tools already available.
It is beyond the scope of this project to develop such tools. However, we
were interested in testing the fundamental idea to see if such tools could be
developed and used in the way we have proposed. We therefore developed two
prototypes for add-on tools and performed some small experiments by way of
proving that such a thing would be feasible.
We rst chose one common design environment and one common GUI
programming language to be the targets for these prototypes. We decided
upon Microsoft Visual Basic 6.0 and Java using the Java Swing libraries. The
advantage of Microsoft Visual Basic 6.0 is that not only is this a popular
prototyping environment for GUIs due to the ability to drag and drop widgets
onto forms to quickly and easily try out designs, but also because it is possible
to build components in Visual Basic which can then be incorporated into any
other Visual Basic project. Our idea then was to build a component which any
user of Visual Basic could incorporate into their project and use to interrogate
their designs with the aim of producing a partial specication. A detailed
description of the programming and usage of components in Microsoft Visual
Studio projects can be found in the Microsoft online documentation [55]. The
Java Swing library contains hierarchical classes used for creating a wide range
181
of widgets and GUI elements and as such Java seemed a good choice for the
target programming language.
The Visual Basic component works by interrogating the underlying code
and elements of a particular Visual Basic form which is used to layout the
widgets of the GUI. It builds up collections of the widgets which have been
used, and then outputs details of these into a text le formatted as a L
A
T
E
X
description of a Z specication. The sort of information we were able to output
during this experiment related to the properties of each of the widgets, and so
much of it was very low-level and visual in nature. However, it was useful to
see that we were able to gather this information and output it in a Z format.
The biggest drawback we found was that the event(s) that could be generated
by widgets are not contained as properties of those widgets so the component
was unable to derive information about these. As an example of the sort of
output we were able to obtain we created the GUI given in gure 15 and then
activated the analysis component. A section of the output text le which has
been run through L
A
T
E
X follows the example GUI.
Figure 15: Example GUI Created in Visual Basic
182
PARENT ::= Example [ OptionChoices
TAORIENTATION ::= Horizontal [ Vertical [ NoneScrollbar
CBLABEL ::= DoubleUnderline [ Strike [ DoubleStrike [ Super [
Sub [ Underline
TASIZE ::= Small [ Medium [ Large
TASCROLLBAR ::= SELECTION ::= Selected [ NotSelected
CheckboxCBDUnderline
label : CBLABEL
parent : PARENT
selected : SELECTION
label = DoubleUnderline
parent = OptionChoices
TextAreaTheText
parent : PARENT
size : TASIZE
scrollbar : TASCROLLBAR
parent = Example
size = Large
scrollbar = Vertical
The Java tool works by taking the source code le of any Java class and
performing text analysis on it to identify all widgets and widget methods which
set the properties of those widgets. It then produces a similar output to the
Visual Basic component. The Java Swing library uses the convention that all
widget classes have a name that is preceded by a capital J followed by the
name of that widget, for example JButton, JScrollbar etc. The tool uses this
183
convention by identifying all declarations of objects whose type begins with a
capital J and whose second letter is also capitalised. In this way we do not
accidentally identify any other classes, such as JarEntry or JobImpressions,
which are not GUI components or widgets. The advantage of this tool over the
Visual Basic component is that we are able to identify the events generated
or received by widgets via the AddActionListener methods which all of the
Swing components use to set their behaviour on activation. Whilst we have
created this very simple prototype using text analysis on source code les, we
believe it would be possible to create a much more sophisticated tool using
Java reection [35] and the Java Bean technology [34]. This would also allow
compiled classes to be analysed at runtime.
There was one other use we considered for these add-on tools which was
based on a dierent approach and reasoning behind such tool support. In [47],
Reeves suggests developing a tool similar to Tarskis World [7] which could be
used to both develop GUIs and derive a formal specication of that GUI as well
as assist in teaching people how to develop those formal specications. This
would be done by allowing the user to develop descriptions of the GUI they
wanted to build and then checking whether or not the graphical representation
of the GUI was correct in terms of those descriptions. We decided to see if we
could build some of these ideas into our prototype tools so that the user could
not only produce a specication from their GUI design, but could also check
as they went along if their design adhered to certain properties at all.
We extended the Visual Basic component so that users could set up predi-
cates that they wanted to test in their GUI design (using a very small subset of
the properties we could test) and then created a window which would display
the information regarding their current GUI in respect of these predicates.
Figure 16 shows a screenshot of this which is based on the same GUI example
given in 15.
184
Figure 16: Extended Visual Basic Tool Prototype
It was never our intention to spend time on development of tools as part
of this project. However we feel that the small examples we have provided are
interesting and worthwhile examples of useful extensions to our work. We will
discuss this further in the future work section of this report.
185
7 Conclusions
7.1 Overview of Project Goals
We began this project with the aim of investigating the possibilities of including
GUI design guidelines into formal specications. In particular we wanted to
know if we could include the GUI of a system into a Z specication of that
system and subsequently also include design guidelines in a way which would
prove useful. What we wanted to be able to do was to see if it was possible
to prove properties given by the guidelines about a specication as a way of
showing that the specication adhered to those guidelines. We then wanted
to be able to rene our specication to an implementation whose GUI would
similarly adhere to those guidelines.
The rst part of the project involved investigating existing methods of
specifying GUIs and looking at ways of using such methods in a Z specication.
This led us to an understanding of some of the problems that exist in this area,
particularly the diculties of getting the correct level of abstraction for the
GUI in our specication, keeping the specication readable and usable, and
capturing both the behaviour of the GUI and the interaction between the GUI
and the underlying system.
The next stage of our research was to look at the guidelines themselves. We
needed a clear understanding of the sorts of information that was contained in
standard guideline documents. By focusing on particular sets of guidelines we
were able to get a clearer picture of how such documents were structured and
the sorts of problems we may encounter when trying to include them in our
specication. We found that we faced a similar problem when dealing with
the abstraction levels of the guidelines as we had when looking at the issue
of specifying the GUI. We also had to nd a way of using the guidelines in
conjunction with the framework we had devised for the GUI specication.
Following on from this we had to bring these two parts of our research
together in order to see what, if any, benets this would give. We began looking
187
at larger examples and dierent applications of our methods in order to see
what formal proofs or informal reasoning we could do about the guidelines. We
also began to investigate the idea of reverse-engineering so that we could nd
ways of proving that particular implementations of GUIs were renements
of specications and therefore that they did, or did not, satisfy particular
guidelines.
Finally, we wanted to be sure that the methods we developed would be
usable and useful for others. We wanted our work to be accessible not only
by formal methods practitioners but also by GUI designers who may tradi-
tionally be less familiar with a formal language such as Z. This meant that
we had to nd general methods for specifying GUIs which could be used for
any system/GUI pair and which was described in a way which would make
it easy to understand, and follow, by anyone producing such a specication.
We also needed to ensure that a way was found, and described, for taking any
guidelines document and formatting it. Again this would need to be done in
such a way that it could be used for any such document.
The rest of this section looks at the results we achieved, some of the prob-
lems we encountered along the way, the potential for future work in this area
and our nal conclusions at the end of the project.
7.2 Summary of Results
Having completed our work on this project, we can now look back and identify
a number of results we have achieved and contributions we have made to
further research into the area of formal methods and GUI design.
Firstly, we have developed a framework for specifying the GUI as part of a Z
specication of a complete system. The framework uses a categorisation of wid-
gets based on their behaviour which we have developed to support this work.
Because the categorisation is based on widget behaviour it is not limited to
particular sets of widgets for particular programming languages or paradigms,
nor is it limited to existing methods of interaction only. In theory, any new
188
widget or dierent set of widgets can easily be positioned within our hierarchy
simply by identifying the type of behaviour (or behaviours) it exhibits. The
framework can assist those involved in formal specication by providing them
with a structured way of including the GUI of a system in their Z specication
and showing the interaction between the underlying system and the GUI. The
framework is not limited to any particular type of system or style of interface;
indeed there is no necessity for the interface to be graphical at all: the methods
we have described can be applied equally well to non-graphical interfaces or
system/GUI pairs of dierent types. As part of the background to using the
framework we have also provided supporting diagrams which allow speciers
to identify the appropriate category within the hierarchy at any stage in the
renement of their specication.
Secondly, we have created a process for taking guidelines documents and
structuring them in a formal manner in a way which makes it easy for them to
be used in conjunction with the GUI specication. The process involves cre-
ating a document which is structured by category using the widget categories
and hierarchy we have already described. Then, by working through a guide-
line document, we identify each guideline in the document, identify which of
the widget categories it has a suitable and relevant meaning for, and include
a description of that guideline under that category. The guideline is described
in three parts. First we give the actual guideline in as clear and unambiguous
a way as possible. Next we describe how this guideline can be used for this
widget category within the specication, including any additional information
we need to add to the specication to achieve this. Finally we describe how
we can validate our specication to show that it adheres to the guideline. For
very specic guidelines, such as those relating to specic, individual widgets
(such as buttons or scroll-bars etc.) we have described how these would be
included in the document so that they can be used during renement as the
general widget categories are made more specic.
With the GUI specication framework and formalised guideline document
189
in place we have gone on to show how these can successfully be used within
our formal specications. We have provided examples which show how we
can perform proofs and tests on our specications to show whether or not
they satisfy particular guidelines. We have also shown how we can use the
information in the guideline documents to nd suitable ways of xing or
rening the specication when it is found to not satisfy a particular guideline.
Also, through the use of examples, we have shown how the guideline document
can assist in the renement of our specications to less general widgets by
describing properties of the specic widgets which may match the requirements
of our system.
In another use of examples we have shown the application of our methods
to dierent types of systems and at dierent stages in the design process. We
have specied parts of both a safety-critical system and a real-world system and
their interfaces, and shown how by including guidelines in the specication we
can identify, or prevent, GUI problems. We have also discussed ways of reverse-
engineering existing GUIs as a way of showing whether it is a renement of
a specication, and therefore whether the guidelines used in the specication
can be shown to have been adhered to in the design of that GUI, and also as a
way of supporting designers in their understanding and usage of these formal
methods.
Finally, we have discussed ways of making our work more attractive to
the designers of GUIs by highlighting the benets that such methods may
bring them. We have also shown how support tools can be used to assist with
this and also assist with the reverse-engineering of GUIs. We have presented
prototypes of two such tools which we have built in order to see how practical
this idea is and suggested ways of developing these further into fully-edged,
usable tools.
In terms of the initial aims and goals of this project we have been able
to satisfactorily meet those goals and provide examples and evidence to show
how those goals have been met. We have also provided the information and
190
background necessary to allow others to follow the methods described in this
report and use it as a basis for further research. This report has concentrated
on our successful results and the methods we have developed following on from
our experimentation and those results. There were, of course, many things that
we encountered during the research that caused problems, forced us to change
the direction of our thinking or proved to be ultimately unhelpful in our nal
solutions. We will discuss some of these issues next and describe how we were
able to overcome them.
7.3 Problems Encountered and Solutions Found
One of the earlier considerations of our work, which involved trying several dif-
ferent approaches and re-assessments, was how exactly to represent the notion
of GUI events which cause system operations to occur. When we implement
a GUI the links from the widgets to the system operations are provided via
events and an event handler which manages the task of catching the events as
the user interacts with the GUI. This event handler then passes the events on
to the interested parts of the system, i.e the things which will respond to those
events. There may be many such events present in a running system at any
given time and we rely on the event handler to manage the correct processing
of these.
When we specify a system in Z we are interested in describing states of a
system and the changes that can occur to those states via system operations,
but this is not described in a causal manner in the way we may think of GUI
events causing operations to occur. For example we may reason about the GUI
that if I press button A then light B will come on, but this is not the way we
generally describe such actions and reactions in Z. Within our specications we
wanted to show the link between the GUI activity and the system operations,
but in doing so we did not want to break away from a standard Z style, or
indulge in too low-level a representation of GUI/system interaction.
One idea that we returned to a number of times before nally rejecting it
191
as too low-level, and overly-complicated, was that of having a global set of
current events in the specication. The idea was that when the Controlstate
of a widget was Active there would be a function which would add the relevant
event to the global current event set. In return, the operations would contain
a check on the values of this global set and the after states would only change
if a particular event was present. Then another function would be used to
remove the event from the global event set. This seemed to be an appealing
solution for a number of reasons, not least because it meant that we had
a global observation of events which could represent at any given time the
actual events in progress in the system, which was a close model for the actual
implementation with its event-handling mechanism. In fact, this similarity to
the implementation proved to be one of the main problems with this solution.
We found that we were using the specication to describe low-level event-
handling properties which was not our intention at all. We really wanted
to describe the behaviour of the GUI by showing some link between widgets
and operations at a more abstract level and not resort to this sort of detailed
analysis of how a GUI actually works in context. Eventually, therefore, we
abandoned this idea of a global event set and investigated other options which
led us to the solution we have presented in our framework.
This problem of event-handling is linked to another issue, that of the tem-
poral nature of GUIs. In an abstract specication we may generally be happy
to ignore considerations of temporal issues within a system. However, there are
guidelines which deal directly with timing issues in GUIs and systems. In par-
ticular, guidelines exist which require a certain level of responsiveness within
a system so that when a user interacts with a system they receive a response
within a certain time-frame. We felt that because many of these temporal
issues are caused by things outside of the actual system we may be specifying,
e.g. the length of time it takes for a response may be linked to processor activ-
ity, memory management etc., we did not want to bring such external details
into our specications. We have, therefore, chosen to omit such considerations.
192
There are, of course, ways to include some temporal notions which are relevant
within our specication, particularly as regards keeping users informed about
the length of tasks. We will return to this in the future work section of this
report.
Another issue which arose during our research occurred when we began
looking at the process of converting the guideline documents into a form which
could be used with our specications. At rst we wanted to be able to include
every guideline in the document and spent considerable time struggling with
some of the more abstract guidelines in order to try and achieve this. In fact
we have determined that it is not reasonable or practical to do this. The
initial aim of our project was to incorporate guidelines in a useful manner; by
including abstract principles and trying to mould them into our framework we
found that we were doing quite the opposite: we were making our work less
useful and too general. Given that the existing use of guidelines in GUI design
is not intended to be a complete solution for building usable interfaces, but
rather is just one part of the work required to achieve this, we do not feel that
this inability to include all of the guidelines is a major concern. By including
only those guidelines which we can use practically within our specications we
have a more robust and usable solution than if we tried to include everything.
A somewhat unusual concern which was raised during our work was that
of the seemingly trivial nature of some of the examples we were working on.
Often we would focus on one particular guideline as a way of demonstrating
a particular part of our process or of investigating a particular approach. The
result of this was that we would spend a lot of time and go into a lot of detail to
prove or disprove something which appeared quite trivial in the wider context
of the whole system. In fact this is the nature of guidelines if we look at them
individually in this way. Often the guideline requirement may appear to be
either obvious, in that we expect designers to satisfy them automatically, or too
trivial to be important. The very fact that such guideline documents exist, and
are used and encouraged, however, gives testament to the fact that this is quite
193
clearly not the case. What may seem obvious when viewed in isolation may
easily be forgotten or overlooked in the wider context of overall system design.
Additionally, if we consider the eect of not just one guideline being ignored
in just one place in a GUI design, but rather a number of such guidelines
being ignored throughout the GUI design, then we can appreciate that this
cumulative eect is of much more concern. We concluded, therefore, that while
our microscopic examination of individual guidelines may seem unjustied at
rst, it is a necessary step to satisfy ourselves that the process we have adopted
is correct and works, and when we consider the eect of multiplying the minor
issues we were able to correct or prevent it is clear that the process is indeed
a worthwhile one and produces justiably useful results.
Finally, we started the project with very clear goals as to what we wanted
to achieve. As we got further into our research we realised that there were a
number of things which required much more detailed analysis and work than
we were able to do without losing sight of the actual aims of our work. Whilst
we have succeeded in providing the framework and process required to achieve
our initial goals, there is certainly more to be discovered in particular areas
of our work. We will address these next as we discuss future work which our
research has suggested.
7.4 Future Work
Our investigations into guidelines and GUI specications have exposed a num-
ber of areas where additional, interesting work could be performed. This work
encompasses both using guidelines within specications as well as GUI speci-
cation in general.
We have discussed earlier in this report the notion of priorities within sets
of guidelines and suggested one possible way of incorporating these into our
work. We feel, however, that there are potentially more investigations which
could be done in this area. Priorities encompass considerations of whether
guidelines are mandatory or optional. This could be true in all situations,
194
or in just some. In addition they may determine whether one guideline has
priority over another if they are conicting. These priorities may not be xed
but may depend on the type of system being designed or the expected users
of such a system. For example, a system designed for expert users may have
dierent requirements to a system for novice users, and these could be reected
in the priorities of guidelines. It would be interesting to explore this further to
see what additional information would be required in the guidelines documents,
or the specication, to incorporate these ideas.
We have also described how we chose to ignore temporal considerations
in our work, both in the GUI specication and in guidelines of a temporal
nature. While there has been research conducted into temporal properties of
interactive systems, often involving the use of temporal logics, we believe it is
possible to include some of these ideas into our framework for Z specications.
In particular we would be interested in looking at extensions to our work
to incorporate this whilst still maintaining our use of standard Z. Further
investigations into this may also identify ways in which this would allow us
to include guidelines with temporal requirements and therefore increase the
spectrum of guidelines we can usefully include.
The support tools we presented in section six were very basic. They were
designed as a proof of concept and as such are very simple prototypes with
limited functionality. Designing and building fully-functional tools of this na-
ture requires deeper research into a number of areas. Work needs to be done to
identify what the most useful types of such tools would be for designers. What
is it that they should provide and how much automation can we realistically
build into them before they start to become as complex, and potentially di-
cult to use, as some theorem provers? Once this work was completed then the
process of designing, building and testing such tools could begin. This would
lead the way for further research into how they could be usefully integrated
into the design process.
In terms of the formal specication of GUIs in Z there are also a number
195
of areas we feel warrant further work. We have already stated that we believe
there are potential benets in incorporating the visual models given by the
-Charts language. This would require work to prove formally the renement
relation between the Z model of a -chart describing a GUI/system pair and
a description of the same GUI and system given using our Z framework.
This leads us to renement in general, which is another area that warrants
more research in relation to our work. We have discussed traditional formal
renement methods which use simulation and proof rules and we have also
shown how we can make informal links between specications and implemen-
tations of GUIs to make this more accessible to non-formal people. We would
like to investigate this further to see if the links between this formal and in-
formal method can be clearly identied and expressed, and developed into a
theory. This could then be used to underpin our informal renement model as
it would allow us to use the formal renement rules whilst remaining seemingly
informal.
7.5 Final Summary
The presented research is based on the thesis: It is possible to usefully include
graphical user interface design guidelines into the formal specication of sys-
tems in Z. This report on the research and procedures followed shows how we
have investigated this statement. Our work is divided into three major parts:
formally specifying GUIs in Z, generating guidelines documents which allow
us to easily incorporate the guidelines into the specication and nding ways
of using these guidelines to prove properties of GUI specications. As well as
these three main areas of research other issues which have proved both inter-
esting and helpful in our nal results include: using visual notations to support
GUI specication, formal and informal renements for GUI specications and
support tools for GUI designers.
Our conclusion is that it is indeed possible to usefully include guidelines
into formal specications. We describe ways of using guidelines to identify
196
potential errors in specied systems, nd errors in existing implementations
and assist with the renement of specications. The research process includes
developing a framework for describing GUIs in a Z specication and a method
for transforming any guidelines document into a format which allows it to
be used in conjunction with this framework. We also provide a number of
examples of how our work can be applied in both small toy problems, and in
large real-world, and safety-critical systems. Furthermore, we show how our
work can be made more accessible for those who are not formal experts and
describe potential support tools which can be developed to aid this further.
Our research, the results we have obtained, and the presentation of both
of these things in this report mean that not only can we satisfy ourselves that
we have successfully addressed the research thesis, but also that others may
reuse our methods and build upon them in research of their own.
197
8 Appendices
Appendix A
The GNOME Human Interface Guidelines(1.0)
This appendix contains sections of the GNOME Human Interface Guidelines [24]
described in a format suitable for use in conjunction with a Z specication of
a graphical user interface.
The guidelines have been organised within their categories in accordance
with the widget category hierarchy described in section two of the main body
of this report. The guideline specication format is in accordance with that
given in section four of the main body of this report.
CONTROLS
Guideline: Be consistent in the naming of all Controls.
Usage: Ensure that any Controls that have the same name perform the
same function. For example, two EventGenerators with the same name should
generate the same event.
Validation: Each Control in the specication should be checked to ensure
that is has a unique Label observation. Any controls which have the same Label
observation must have the same behaviour, i.e. generate or receive the same
event.
Guideline: Use Frames to organise Controls into functional groups.
Usage: Use Frames within Displays to group related items. A Frame is de-
scribed in a schema which includes the schemas of the related Controls. The
Display should be described as the conjunction of its relevant Frames and other
Controls.
Validation: Identify items which are to be grouped and ensure that a Frame
has been described which is the conjunction of only those grouped items.
199
Event Generators
Refer to all Control guidelines.
Guideline: All EventGenerators must provide feedback to the user.
Usage: Following a user action there must be some change to the system
state. There must not be an EventGenerator linked to an operation in the
specication which, when it has a CONTROLSTATE observation with the
value Active, does not cause the system to change.
Validation: Each EventGenerator in the specication should be tested to
ensure that there is no state of the ActiveOperation which includes the Event-
Generator where the CONTROLSTATE observation has a value Active and
the system state before the operation is the same as the system state after the
operation.
Action Controls
Refer to all EventGenerator guidelines. Guideline: If an ActionControl is
to be inactive in a display do not remove it, give it a disabled state.
Usage: Give ActionControls which may be inactive in a display an observation
ABLESTATE. Dene the set of allowable values of ABLESTATE as follows:
ABLESTATE ::= Enabled | Disabled
Any ActionControl in a disabled state must not be able to be activated by a
user.
Validation: Show that the following holds true for all ActionControls which
have this observation:
When the ABLESTATE observation of the control is Disabled then the CON-
TROLSTATE is NotActive.
When the CONTROLSTATE observation of the control isActive then the
200
ABLESTATE is Enabled.
The state of the system which leads to an ActionControl being disabled and
subsequently enabled again must be dened.
Guideline: Provide unique keyboard shortcuts for ActionControls.
Usage: Give all ActionControls an observation KEYSHORTCUT.
Dene a set of allowable values for KEYSHORTCUT including the null value
of NoKey. This null value allows the observation to be used by other Controls
where the presence of a keyboard shortcut key is not mandatory.
Validation: For all ActionControls ensure that the KEYSHORTCUT ob-
servation does not have a value of NoKey. In addition ensure that no two
ActionControls have the same value for the KEYSHORTCUT observation un-
less they generate the same event.
Buttons
Refer to all ActionControl guidelines.
Guideline: Use title case for Button labels.
Usage: Give all Buttons an observation BUTTONLABELSTYLE. Dene
the set of allowable values of BUTTONLABELSTYLE to include at least the
following values:
BUTTONLABELSTYLE ::= TitleCase | Uppercase | Lowercase |
SentenceCapitalisation | UndenedCase
Validation: For all Buttons ensure that the observation BUTTONLABEL-
STYLE has the value TitleCase.
Selection Controls
Refer to all EventGenerator guidelines.
201
Binary Selection Controls
Refer to all SelectionControl guidelines.
Value Selection Controls
Refer to all SelectionControl guidelines.
Single Value Selection Controls
Refer to all ValueSelectionControl guidelines.
Single Checkboxes
Refer to all SingleValueSelectionControl guidelines.
Guideline: Provide an access key in all Checkbox labels that allows the user
to set or unset the Checkbox directly from the keyboard.
Usage: Give all single Checkboxes an observation ACCESSKEY. Dene
the set of allowable values of ACCESSKEY including the null value of NoAc-
cessKey. This null value allows the observation to be used by other Controls
where the presence of an access key is not mandatory.
Validation: Ensure that the value of the ACCESSKEY observation is not
NoAccessKey for all single Checkboxes.
Guideline: Use sentence capitalization for Checkbox labels.
Usage: Give all Checkboxes an observation CHECKBOXLABELSTYLE.
Dene the set of allowable values of CHECKBOXLABELSTYLE to include at
least the following values:
CHECKBOXLABELSTYLE ::= TitleCase | Uppercase | Lowercase |
SentenceCapitalisation | UndenedCase
202
Validation: For all Checkboxes ensure that the observation CHECKBOXLA-
BELSTYLE has the value SentenceCapitalisation.
RadioButtons
Refer to all SingleValueSelectionControl guidelines.
Guideline: RadioButtons are used in groups to select from a mutually
exclusive set of options. Only one RadioButton within a group may be set at
any one time.
Usage(1): Where a set of RadioButtons is described by a schema which
includes single SelectionControls the schema must include a predicate which
constrains these single SelectionControls so that exactly one has a selection
value of Selected.
Example:
RadioButtonGroup
rbOne
rbTwo
rbThree
rboneselected = Selected
rbtwoselected = NotSelected rbthreeselected = NotSelected
rbtwoselected = Selected
rboneselected = NotSelected rbthreeselected = NotSelected
rbthreeselected = Selected
rboneselected = NotSelected rbtwoselected = NotSelected
Validation: Following the usage description will ensure the guideline is sat-
ised.
Usage(2): Where a single SelectionControl is described by a type RA-
203
DIOBUTTON and a set of RadioButtons is described as a set of elements of
type RADIOBUTTON the following should be included as a predicate in the
schema containing the set.

1
a : RADIOBUTTON a radiobuttons a.selected = Selected
Validation: Following the usage description will ensure the guideline is sat-
ised.
Guideline: Use sentence capitalization for RadioButton labels.
Usage: Give all RadioButtons an observation BUTTONLABELSTYLE. De-
ne the set of allowable values of BUTTONLABELSTYLE to include at least
the following values:
BUTTONLABELSTYLE ::= TitleCase | Uppercase | Lowercase |
SentenceCapitalisation | UndenedCase
Validation: For all RadioButtons ensure that the observation BUTTONLA-
BELSTYLE has the value SentenceCapitalisation
Guideline: Do not place more than about eight RadioButtons under the
same group heading.
Usage(1): Where a set of radio buttons is described by a schema which
includes single selection controls ensure that no more than 8 such controls are
included in the schema.
Validation: Following the usage description will ensure the guideline is sat-
ised.
Usage(2): Where a single selection control is described by a type RADIOBUT-
TON and a set of RadioButtons is described as a set of elements of type RA-
DIOBUTTON the following should be included as a predicate in the schema
204
containing the set.
#radiobuttons 8
Validation: Following the usage description will ensure the guideline is sat-
ised.
Guideline: Try to align groups of RadioButtons vertically rather than hori-
zontally.
Usage: Give all RadioButton groups an observation ORIENTATION. Dene
the set of allowable values of ORIENTATION as:
ORIENTATION ::= Vertical | Horizontal | UndenedOrientation
Validation: For all RadioButton groups ensure that the value of ORIEN-
TATION is Vertical.
ListBoxes
Refer to all SingleValueSelectionControl guidelines.
Guideline: Make the ListBox large enough that it can show at least four
items at a time without scrolling.
Usage: Give ListBoxes an observation VISIBLELINES with a type of 4 . .
MaxValue, where MaxValue is some previously dened value.
Validation: Following the usage description will ensure the guideline is sat-
ised.
Guideline: Do not use ListBoxes with lists containing less than ve items,
use Checkboxes, RadioButtons or an OptionMenu if there are fewer items.
Usage: Give all ListBoxes an observation which is a set of LISTITEMS. De-
ne the allowable set of values for LISTITEMS.
205
Validation: For all ListBoxes ensure that the cardinality of the set of LIS-
TITEMS is greater than 5.
Menus
Refer to all SingleValueSelectionControl guidelines.
Guideline: Menus should have a maximum of 15 items and a minimum of 3.
Usage: Give all Menus an observation which is a set of MENUITEMS. De-
ne the allowable set of values for MENUITEMS.
Validation: For all Menus ensure that the cardinality of the set of MENU-
ITEMS is between 3 and 15.
Sliders
Refer to all SingleValueSelectionControl guidelines.
Guideline: Label Sliders with a text label using sentence capitalization.
Usage: Give all Sliders an observation SLIDERLABELSTYLE. Dene the set
of allowable values of SLIDERLABELSTYLE to include at least the following
values:
SLIDERLABELSTYLE ::= TitleCase | Uppercase | Lowercase |
SentenceCapitalisation | UndenedCase
Validation: For all Sliders ensure that the SLIDERLABELSTYLE observa-
tion has a value of SentenceCapitalisation.
Multiple Value Selection Controls
Refer to all ValueSelectionControl guidelines.
Checkbox Groups
206
Refer to all MultipleValueSelectionControl guidelines.
Guideline: Do not place more than about eight Checkboxes under the same
group heading. If you need more than eight, try to use blank space, heading
labels or Frames to divide them into smaller groups. Otherwise, consider using
a Checkbox list instead.
Usage: Checkbox groups are described in schemas containing Checkbox con-
trols. Ensure no more than eight such controls are included in the schema.
Validation: Following the usage description will ensure the guideline is sat-
ised.
Guideline: Try to align groups of Checkboxes vertically rather than hori-
zontally.
Usage: Give all Checkbox groups an observation ORIENTATION. Dene the
set of allowable values of ORIENTATION as:
ORIENTATION ::= Vertical | Horizontal | UndenedOrientation
Validation: For all Checkbox groups ensure that the observation ORIENTA-
TION has the value of Vertical.
Event Responders
Refer to all Control guidelines.
Responders
Refer to all EventResponder guidelines.
Value Responder
Refer to all EventResponder guidelines.
207
Single-Value Responder
Refer to all ValueResponder guidelines.
Text Entry
Refer to all SingleValueResponder guidelines.
Guideline: Label the TextEntry with a text label using sentence capital-
ization.
Usage: Give all TextEntries an observation TEXTENTRYLABELSTYLE.
Dene the set of allowable values of TEXTENTRYLABELSTYLE to include
at least the following values:
TEXTENTRYLABELSTYLE ::= TitleCase | Uppercase | Lowercase |
SentenceCapitalisation | UndenedCase
Validation: For all TextEntries ensure that the TEXTENTRYLABELSTYLE
observation has the value SentenceCapitalisation.
Numeric Entry
Refer to all SingleValueResponder guidelines.
Guideline: Right-justify the contents of NumericEntries.
Usage: Give all NumericEntries an observation JUSTIFICATION. Dene
the set of allowable values of JUSTIFICATION as:
JUSTIFICATION ::= Left | Right | Centre | UndenedJustication
Validation: For all NumericEntries ensure that the JUSTIFICATION obser-
vation has the value Right.
Multiple-Value Responder
208
Refer to all ValueResponder guidelines.
DISPLAYS
Status Display
Refer to all Display guidelines.
Container
Refer to all Display guidelines.
Guideline: Give every Window a title with the exception of Alerts and Tool-
boxes.
Usage: Give all Windows an observation WINDOWTITLE. Dene the al-
lowable set of values for WINDOWTITLE as:
WINDOWTITLE ::= Application | FileName | FilePath |
Activity | Description | NoWindowTitle
Validation: For all Windows ensure that for those which are not Alerts or
Toolboxes the WINDOWTITLE observation is not NoWindowTitle. For Alerts
and Toolboxes ensure that the WINDOWTITLE observation is NoWindowTi-
tle.
RootWindow
Refer to all Container guidelines.
Guideline: RootWindows should use the application name as their title.
Usage: Give all RootWindows an observation WINDOWTITLE. Dene the
209
allowable set of values for WINDOWTITLE as:
WINDOWTITLE ::= Application | FileName | FilePath |
Activity | Description | NoWindowTitle
Validation: For all RootWindows ensure that the WINDOWTITLE observa-
tion is Application.
Guideline: Give all RootWindows the following window commands:
Close, Maximise, Minimise
Usage: The specication must describe four Controls as follows:
CloseWindowControl
cwcstate : CONTROLSTATE
cwcevent : EVENT
cwcstate = Active cwcevent! = CloseWindowEvent
cwcstate = NotActive cwcevent! = None
MaximiseWindowControl
maxwcstate : CONTROLSTATE
maxwcevent : EVENT
maxwcstate = Active maxwcevent! = MaximiseWindowEvent
maxwcstate = NotActive maxwcevent! = None
210
MinimiseWindowControl
minwcstate : CONTROLSTATE
minwcevent : EVENT
minwcstate = Active minwcevent! = MinimiseWindowEvent
minwcstate = NotActive minwcevent! = None
Dene the values for WINDOWSIZE and WINDOWVISIBLE as:
WINDOWSIZE ::= Minimum | Maximum | Standard |
UserDened
WINDOWVISIBLE ::= Visible | NotVisible
Dene the following response state for all RootWindows:
WindowResponseState
wsize : WINDOWSIZE
wvisible : WINDOWVISIBLE
All RootWindows should include the three previously dened Controls as well
as an inclusion of primed and unprimed copies of WindowResponseState.
Validation: For all RootWindows ensure that the following things are true:
If the cwcevent observation is CloseWindowEvent then the wvisible

observa-
tion must be NotVisible.
If the minwcevent observation is MinimiseWindowEvent then the wsize

obser-
vation must be Minimum .
If the maxwcevent observation is MaximiseWindowEvent then the wsize

ob-
servation must be Maximum .
Guideline: All RootWindows should include at least a File and a Help Menu.
211
Usage: Ensure that the specication includes schemas which describe a
FileMenu and a HelpMenu. These must be included in the description of the
RootWindow.
Validation: Following the usage description will ensure the guideline is sat-
ised.
SubWindow
Refer to all Container guidelines.
Guideline: Document based windows should use the current document
name for the title.
Usage: Give all SubWindows an observation WINDOWTITLE and an ob-
servation WINDOWCONTENT. Dene the allowable set of values for WIN-
DOWTITLE and WINDOWCONTENT as:
WINDOWTITLE ::= Application | FileName | FilePath |
Activity | Description | NoWindowTitle
WINDOWCONTENT ::= Document | Query | Controls |
UndenedContent
Validation: For all SubWindows ensure that if the WINDOWCONTENT ob-
servation has a value of Document, then the WINDOWTITLE observation is
FileName.
Guideline: Give all SubWindows the following window commands:
Close, Maximise, Minimise
Usage: The specication must describe four Controls as follows:
212
CloseWindowControl
cwcstate : CONTROLSTATE
cwcevent : EVENT
cwcstate = Active cwcevent! = CloseWindowEvent
cwcstate = NotActive cwcevent! = None
MaximiseWindowControl
maxwcstate : CONTROLSTATE
maxwcevent : EVENT
maxwcstate = Active maxwcevent! = MaximiseWindowEvent
maxwcstate = NotActive maxwcevent! = None
MinimiseWindowControl
minwcstate : CONTROLSTATE
minwcevent : EVENT
minwcstate = Active minwcevent! = MinimiseWindowEvent
minwcstate = NotActive minwcevent! = None
Dene the values for WINDOWSIZE and WINDOWVISIBLE as:
WINDOWSIZE ::= Minimum | Maximum | Standard |
UserDened
WINDOWVISIBLE ::= Visible | NotVisible
Dene the following response state for all SubWindows:
213
WindowResponseState
wsize : WINDOWSIZE
wvisible : WINDOWVISIBLE
All SubWindows should include the three previously dened Controls as well
as an inclusion of primed and unprimed copies of WindowResponseState.
Validation: For all SubWindows ensure that the following things are true:
If the cwcevent observation is CloseWindowEvent then the wvisible

observa-
tion must be NotVisible.
If the minwcevent observation is MinimiseWindowEvent then the wsize

obser-
vation must be Minimum .
If the maxwcevent observation is MaximiseWindowEvent then the wsize

ob-
servation must be Maximum .
Dialogue
Refer to all SubWindow guidelines.
Guideline: Use the command name that opened the Dialogue for the win-
dow title.
Usage: Give all Dialogues an observation WINDOWTITLE. Dene the al-
lowable set of values for WINDOWTITLE as:
WINDOWTITLE ::= Application | FileName | FilePath |
Activity | Description | NoWindowTitle
Validation: For all Dialogues ensure that the WINDOWTITLE observation
has a value of Activity.
Frame
Refer to all SubWindow guidelines.
214
Guideline: Rather than using bordered Frames, use Frames without bor-
ders. Use bold titles to make the categories stand out.
Usage: Windows and SubWindows should contain the observations BOR-
DERSTYLE and TITLESTYLE. Dene the set of allowable values for BOR-
DERSTYLE and TITLESTYLE as follows:
BORDERSTYLE ::= Border | NoBorder
TITLESTYLE ::= PlainTitle | BoldTitle
Validation: For all Frames ensure that the BORDERSTYLE observation has
a value of NoBorder and the TITLESTYLE observation has a value of BoldTi-
tle.
Toolbar
Refer to all SubWindow guidelines.
Guideline: Allow Toolbars to be turned on and o.
Usage: Give all Toolbars observations TOOLBARSTATUS and WINDOWVIS-
IBLE. Dene the sets of allowable values for these as:
TOOLBARSTATUS ::= ToolbarOn | ToolbarO
WINDOWVISIBLE ::= Visible | NotVisible
Validation: For all Toolbars ensure that the following two things are true:
If the TOOLBARSTATUS observation is ToolbarOn then the WINDOWVIS-
IBLE observation must be Visible.
If the TOOLBARSTATUS observation is ToolbarO then the WINDOWVIS-
IBLE observation must be NotVisible.
Guideline: In general dont use vertical Toolbars.
215
Usage: Give all Toolbars an observation ORIENTATION. Dene the set of
allowable values of ORIENTATION as:
ORIENTATION ::= Vertical | Horizontal | UndenedOrientation
Validation: For all Toolbars ensure that the ORIENTATION observation is
Horizontal.
216
Appendix B
Decision Trees for Renement
Having described a framework for specifying user interfaces, which includes a
widget category hierarchy, we have discussed in section 5.1 how we use this
to assist with rening our specication to particular types of widgets. The
decision trees used for this process are given here.
Figure 17: Event Generator Decision Tree
Figure 18: Event Responder Decision Tree
217
Figure 19: Display Decision Tree
218
Appendix C
Specication of the Nuclear Interface Example from Section 5.3
The description for this section of the interface and its functionality is given
in [39] as follows:
Note: the present operators console refers to the non-computerised version of the
console used to derive the specication for the new system.
Recall that the three safety control rods (also called shim rods)
provide gross control of reactivity and are an element of the safety
system. For each of these control rods, the present operators con-
sole includes a set of four lights:
Engaged
This light indicates whether the rod is magnetically coupled to its
drive mechanism
Up
This light indicates whether the rod is fully withdrawn
Down
This light indicates whether the drive mechanism is at its lowest
level
Seated
This light indicates whether the rod is fully inserted into the core,
regardless of the position of the drive mechanism.
For each control rod there are also displays indicating the rod height
and the magnetic current to the rod attachment mechanism. To
allow the operator control of each rod, there are controls allowing
the operator to set the magnet current and to raise and lower the
rod. The operator can either move the rod by a small increment
or move the rod continuously at a predetermined speed.
219
The standard operating procedures in the current manual system
allow the operator to move the rods only when the neutron ux
measurement exceeds a prescribed threshold (thereby indicating
that the instrument is operating).
The drive mechanism for the rods has two states which we describe using a
free type. The position of the mechanism may be at any point within the
range of its movement, but we are only required to note when it is at its lowest
point, we therefore give a free type with the values of lowest or other for this
observation.
DriveMechanismState ::= Coupled | Uncoupled
DriveMechanismPosition ::= Lowest | Other
The position of any of the three rods, if not fully withdrawn or inserted, is
given a numeric value so that it is possible to determine its position to within
1/100 of the insertion tube height at any given time.
RodPosition ::= Withdrawn | Inserted | Intermediate0 . . 100
We use a constant for the numeric values of RodAttachmentMechanism for
ease or reading in the specication,
RodAttachmentMechanism == N
and give a global value for the Neutron Flux Threshold which provides the
safety functionality for this part of the system.
NFluxThreshold : N
220
We start be describing each of the components of the Shim Rod System, i.e.
each of the three individual shim rods.
ShimRodOne
dms1 : DriveMechanismState
dmpos1 : DriveMechanismPosition
rp1 : RodPosition
ram1 : RodAttachmentMechanism
ShimRodTwo
dms2 : DriveMechanismState
dmpos2 : DriveMechanismPosition
rp2 : RodPosition
ram2 : RodAttachmentMechanism
ShimRodThree
dms3 : DriveMechanismState
dmpos3 : DriveMechanismPosition
rp3 : RodPosition
ram3 : RodAttachmentMechanism
Next we dene the Shim Rod System which is made up of each of these rods,
as well as an observation regarding the value of the NeutronFlux.
221
ShimRodSystem
ShimRodOne
ShimRodTwo
ShimRodThree
NeutronFlux : N
Each of the Shim Rods can be moved provided the neutron ux constraint is
met. Movement may be up or down and may be one increment at a time, or
a continuous movement. In order to dene these operations we rst need to
dene the set called Events which are the permitted events which occur in this
system. These are the events which will link the interface specication to the
system operations. The values for this set are identied during the process of
specifying the system operations, we identify each of the events required as we
describe the operation and use this to build up values for the set.
222
EVENT ::= SROneRodMoveUpEvent | SROneRodMoveDownEvent |
SRTwoRodMoveUpEvent | SRTwoRodMoveDownEvent |
SRThreeRodMoveUpEvent | SRThreeRodMoveDownEvent |
SROneCurrentChangeEvent | SRTwoCurrentChangeEvent |
SRThreeCurrentChangeEvent | SROneEngagedEvent |
SROneDisengagedEvent | SRTwoEngagedEvent |
SRTwoDisengagedEvent | SRThreeEngagedEvent |
SRThreeDisengagedEvent | SROneDMLowerEvent |
SROneDMRaiseEvent | SRTwoDMLowerEvent |
SRTwoDMRaiseEvent | SRThreeDMLowerEvent |
SRThreeDMRaiseEvent | SROneRodWithdrawnEvent |
SROneRodInsertedEvent | SRTwoRodWithdrawnEvent |
SRTwoRodInsertedEvent | SRThreeRodWithdrawnEvent |
SRThreeRodInsertedEvent | SROneRodHeightEvent |
SRTwoRodHeightEvent | SRThreeRodHeightEvent |
SROneRodIntermediateEvent | SRTwoRodIntermediateEvent |
SRThreeRodIntermediateEvent | None
Now we can dene the actual operations of the system. The movement of
each rod depends upon the rods starting position, the amount of the move-
ment and the relationship between these two things. For both the upward
and downward movement operations we therefore describe the ve possible
movements separately and then combine them using schema disjunction into a
single MoveUp or MoveDown Operation schema, and nally using conjunction
into a TotalMove schema.
223
SROneRodMoveUpNoMove
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Withdrawn rp1

= rp1
srorwevent! = SROneRodWithdrawnEvent
srorievent! = None
srormidevent! = None
srorhevent! = None
srorhvalue! = 0
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
224
SROneRodMoveUpFully
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Inserted srouvalue? 100 rp1

= Withdrawn
srorwevent! = SROneRodWithdrawnEvent
srorievent! = None
srormidevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 0
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
225
SROneRodMoveUpFromBottom
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Inserted srouvalue? < 100
rp1

= Intermediate(100 srouvalue?)
srormidevent! = SROneRodIntermediateEvent
srorievent! = None
srorwevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = (100 srouvalue?)
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
226
SROneRodMoveUpWithdraw
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
Intermediate

rp1 srouvalue? 0 rp1

= Withdrawn
srorwevent! = SROneRodWithdrawnEvent
srorievent! = None
srormidevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 0
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
227
SROneRodMoveUpPartial
ShimRodOne
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
Intermediate

rp1 srouvalue? > 0

rp1

= Intermediate((Intermediate

rp1) srouvalue?)
srormidevent! = SROneRodIntermediateEvent
srorievent! = None
srorwevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = (Intermediate

rp1) srouvalue?
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
228
SROneRodMoveUp
ShimRodOne
srouevent? : EVENT
srouvalue? : 0 . . 100
srorwevent! : EVENT
srorievent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
NeutronFlux NFluxThreshold
srouevent? = SROneRodMoveUpEvent
(SROneRodMoveUpNoMove
SROneRodMoveUpFully
SROneRodMoveUpFromBottom
SROneRodMoveUpWithdraw
SROneRodMoveUpPartial )
srouevent? = SROneRodMoveUpEvent
(rp1

= rp1 dms1

= dms1
dmpos1

= dmpos1 ram1

= ram1
%t2ShimRodTwo

= ShimRodTwo
%t2ShimRodThree

= ShimRodThree
NeutronFlux

= NeutronFlux
srorwevent! = None
srorhevent! = None)
229
SROneRodMoveDownNoMove
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Inserted rp1

= rp1
srorievent! = SROneRodInsertedEvent
srorwevent! = None
srormidevent! = None
srorhevent! = None
srorhvalue! = 100
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
230
SROneRodMoveDownFully
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Withdrawn srodvalue? 100 rp1

= Inserted
srorievent! = SROneRodInsertedEvent
srorwevent! = None
srormidevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 100
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
231
SROneRodMoveDownFromTop
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
rp1 = Withdrawn srodvalue? < 100
rp1

= Intermediate(0 + srodvalue?)
srormidevent! = SROneRodIntermediateEvent
srorwevent! = None
srorievent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 0 + srodvalue?
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
232
SROneRodMoveDownInsert
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
Intermediate

rp1 + srodvalue? 100 rp1

= Inserted
srorievent! = SROneRodInsertedEvent
srorwevent! = None
srormidevent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = 100
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
233
SROneRodMoveDownPartial
ShimRodOne
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
Intermediate

rp1 + srodvalue? < 100

rp1

= Intermediate((Intermediate

rp1) + srodvalue?)
srormidevent! = SROneRodIntermediateEvent
srorwevent! = None
srorievent! = None
srorhevent! = SROneRodHeightEvent
srorhvalue! = (Intermediate

rp1) + srodvalue?
dms1

= dms1
dmpos1

= dmpos1
ram1

= ram1
NeutronFlux

= NeutronFlux
234
SROneRodMoveDown
ShimRodOne
srodevent? : EVENT
srodvalue? : 0 . . 100
srorievent! : EVENT
srorwevent! : EVENT
srormidevent! : EVENT
srorhevent! : EVENT
srorhvalue! : 0 . . 100
NeutronFlux NFluxThreshold
srodevent? = SROneRodMoveDownEvent
(SROneRodMoveDownNoMove
SROneRodMoveDownFully
SROneRodMoveDownFromTop
SROneRodMoveDownInsert
SROneRodMoveDownPartial )
srodevent? = SROneRodMoveDownEvent
(rp1

= rp1 dms1

= dms1
dmpos1

= dmpos1 ram1

= ram1
NeutronFlux

= NeutronFlux
srorievent! = None
srorhevent! = None)
SROneTotalMove = SROneRodMoveUp SROneRodMoveDown
235
SRTwoRodMoveUpNoMove
ShimRodTwo
srtuvalue? : 0 . . 100
srtwevent! : EVENT
srtievent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
rp2 = Withdrawn rp2

= rp2
srtwevent! = SRTwoRodWithdrawnEvent
srtievent! = None
srtmidevent! = None
srtrhevent! = None
srtrhvalue! = 0
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
236
SRTwoRodMoveUpFully
ShimRodTwo
srtuvalue? : 0 . . 100
srtwevent! : EVENT
srtievent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
rp2 = Inserted srtuvalue? 100 rp2

= Withdrawn
srtwevent! = SRTwoRodWithdrawnEvent
srtievent! = None
srtmidevent! = None
srtrhevent! = SRTwoRodHeightEvent
srtrhvalue! = 0
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
237
SRTwoRodMoveUpFromBottom
ShimRodTwo
srtuvalue? : 0 . . 100
srtwevent! : EVENT
srtievent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
rp2 = Inserted srtuvalue? < 100
rp2

= Intermediate(100 srtuvalue?)
srtmidevent! = SRTwoRodIntermediateEvent
srtievent! = None
srtwevent! = None
srtrhevent! = SRTwoRodHeightEvent
srtrhvalue! = 100 srtuvalue?
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
238
SRTwoRodMoveUpWithdraw
ShimRodTwo
srtuvalue? : 0 . . 100
srtwevent! : EVENT
srtievent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
Intermediate

rp2 srtuvalue? 0 rp2

= Withdrawn
srtwevent! = SRTwoRodWithdrawnEvent
srtievent! = None
srtmidevent! = None
srtrhevent! = SRTwoRodHeightEvent
srtrhvalue! = 0
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
239
SRTwoRodMoveUpPartial
ShimRodTwo
srtuvalue? : 0 . . 100
srtwevent! : EVENT
srtievent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
Intermediate

rp2 srtuvalue? > 0

rp2

= Intermediate((Intermediate

rp2) srtuvalue?)
srtmidevent! = SRTwoRodIntermediateEvent
srtievent! = None
srtwevent! = None
srtrhevent! = SRTwoRodHeightEvent
srtrhvalue! = (Intermediate

rp2) srtuvalue?
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
240
SRTwoRodMoveUp
ShimRodTwo
srtuevent? : EVENT
srtuvalue? : 0 . . 100
srtwevent! : EVENT
srtievent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
NeutronFlux NFluxThreshold
srtuevent? = SRTwoRodMoveUpEvent
(SRTwoRodMoveUpNoMove
SRTwoRodMoveUpFully
SRTwoRodMoveUpFromBottom
SRTwoRodMoveUpWithdraw
SRTwoRodMoveUpPartial )
srtuevent? = SRTwoRodMoveUpEvent
(rp2

= rp2 dms2

= dms2
dmpos2

= dmpos2 ram2

= ram2
NeutronFlux

= NeutronFlux
srtwevent! = None
srtrhevent! = None)
241
SRTwoRodMoveDownNoMove
ShimRodTwo
srtdvalue? : 0 . . 100
srtievent! : EVENT
srtwevent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
rp2 = Inserted rp2

= rp2
srtievent! = SRTwoRodInsertedEvent
srtwevent! = None
srtmidevent! = None
srtrhevent! = None
srtrhvalue! = 100
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
242
SRTwoRodMoveDownFully
ShimRodTwo
srtdvalue? : 0 . . 100
srtievent! : EVENT
srtwevent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
rp2 = Withdrawn srtdvalue? 100 rp2

= Inserted
srtievent! = SRTwoRodInsertedEvent
srtwevent! = None
srtmidevent! = None
srtrhevent! = SRTwoRodHeightEvent
srtrhvalue! = 100
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
243
SRTwoRodMoveDownFromTop
ShimRodTwo
srtdvalue? : 0 . . 100
srtievent! : EVENT
srtwevent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
rp2 = Withdrawn srtdvalue? < 100
rp2

= Intermediate(0 + srtdvalue?)
srtmidevent! = SRTwoRodIntermediateEvent
srtwevent! = None
srtievent! = None
srtrhevent! = SRTwoRodHeightEvent
srtrhvalue! = 0 + srtdvalue?
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
244
SRTwoRodMoveDownInsert
ShimRodTwo
srtdvalue? : 0 . . 100
srtievent! : EVENT
srtwevent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
Intermediate

rp2 + srtdvalue? 100 rp2

= Inserted
srtievent! = SRTwoRodInsertedEvent
srtwevent! = None
srtmidevent! = None
srtrhevent! = SRTwoRodHeightEvent
srtrhvalue! = 100
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
245
SRTwoRodMoveDownPartial
ShimRodTwo
srtdvalue? : 0 . . 100
srtievent! : EVENT
srtwevent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
Intermediate

rp2 + srtdvalue? < 100

rp2

= Intermediate((Intermediate

rp2) + srtdvalue?)
srtmidevent! = SRTwoRodIntermediateEvent
srtwevent! = None
srtievent! = None
srtrhevent! = SRTwoRodHeightEvent
srtrhvalue! = (Intermediate

rp2) + srtdvalue?
dms2

= dms2
dmpos2

= dmpos2
ram2

= ram2
NeutronFlux

= NeutronFlux
246
SRTwoRodMoveDown
ShimRodTwo
srtdevent? : EVENT
srtdvalue? : 0 . . 100
srtievent! : EVENT
srtwevent! : EVENT
srtmidevent! : EVENT
srtrhevent! : EVENT
srtrhvalue! : 0 . . 100
NeutronFlux NFluxThreshold
srtdevent? = SRTwoRodMoveDownEvent
(SRTwoRodMoveDownNoMove
SRTwoRodMoveDownFully
SRTwoRodMoveDownFromTop
SRTwoRodMoveDownInsert
SRTwoRodMoveDownPartial )
srtdevent? = SRTwoRodMoveDownEvent
(rp2

= rp2 dms2

= dms2
dmpos2

= dmpos2 ram2

= ram2
NeutronFlux

= NeutronFlux
srtievent! = None
srtrhevent! = None)
SRTwoTotalMove = SRTwoRodMoveUp SRTwoRodMoveDown
247
SRThreeRodMoveUpNoMove
ShimRodThree
srthuvalue? : 0 . . 100
srthwevent! : EVENT
srthievent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
rp3 = Withdrawn rp3

= rp3
srthwevent! = SRThreeRodWithdrawnEvent
srthievent! = None
srthmidevent! = None
srthrhevent! = None
srthrhvalue! = 0
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
248
SRThreeRodMoveUpFully
ShimRodThree
srthuvalue? : 0 . . 100
srthwevent! : EVENT
srthievent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
rp3 = Inserted srthuvalue? 100 rp3

= Withdrawn
srthwevent! = SRThreeRodWithdrawnEvent
srthievent! = None
srthmidevent! = None
srthrhevent! = SRThreeRodHeightEvent
srthrhvalue! = 0
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
249
SRThreeRodMoveUpFromBottom
ShimRodThree
srthuvalue? : 0 . . 100
srthwevent! : EVENT
srthievent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
rp3 = Inserted srthuvalue? < 100
rp3

= Intermediate(100 srthuvalue?)
srthmidevent! = SRThreeRodIntermediateEvent
srthievent! = None
srthwevent! = None
srthrhevent! = SRThreeRodHeightEvent
srthrhvalue! = 100 srthuvalue?
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
250
SRThreeRodMoveUpWithdraw
ShimRodThree
srthuvalue? : 0 . . 100
srthwevent! : EVENT
srthievent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
Intermediate

rp3 srthuvalue? 0 rp3

= Withdrawn
srthwevent! = SRThreeRodWithdrawnEvent
srthievent! = None
srthmidevent! = None
srthrhevent! = SRThreeRodHeightEvent
srthrhvalue! = 0
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
251
SRThreeRodMoveUpPartial
ShimRodThree
srthuvalue? : 0 . . 100
srthwevent! : EVENT
srthievent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
Intermediate

rp3 srthuvalue? > 0

rp3

= Intermediate((Intermediate

rp3) srthuvalue?)
srthmidevent! = SRThreeRodIntermediateEvent
srthievent! = None
srthwevent! = None
srthrhevent! = SRThreeRodHeightEvent
srthrhvalue! = (Intermediate

rp3) srthuvalue?
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
252
SRThreeRodMoveUp
ShimRodThree
srthuevent? : EVENT
srthuvalue? : 0 . . 100
srthwevent! : EVENT
srthievent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
NeutronFlux NFluxThreshold
srthuevent? = SRThreeRodMoveUpEvent
(SRThreeRodMoveUpNoMove
SRThreeRodMoveUpFully
SRThreeRodMoveUpFromBottom
SRThreeRodMoveUpWithdraw
SRThreeRodMoveUpPartial )
srthuevent? = SRThreeRodMoveUpEvent
(rp3

= rp3 dms3

= dms3
dmpos3

= dmpos3 ram3

= ram3
NeutronFlux

= NeutronFlux
srthwevent! = None
srthrhevent! = None)
253
SRThreeRodMoveDownNoMove
ShimRodThree
srthdvalue? : 0 . . 100
srthievent! : EVENT
srthwevent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
rp3 = Inserted rp3

= rp3
srthievent! = SRThreeRodInsertedEvent
srthrhevent! = None
srthwevent! = None
srthmidevent! = None
srthrhvalue! = 100
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
254
SRThreeRodMoveDownFully
ShimRodThree
srthdvalue? : 0 . . 100
srthievent! : EVENT
srthwevent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
rp3 = Withdrawn srthdvalue? 100 rp3

= Inserted
srthievent! = SRThreeRodInsertedEvent
srthwevent! = None
srthmidevent! = None
srthrhevent! = SRThreeRodHeightEvent
srthrhvalue! = 100
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
255
SRThreeRodMoveDownFromTop
ShimRodThree
srthdvalue? : 0 . . 100
srthievent! : EVENT
srthwevent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
rp3 = Withdrawn srthdvalue? < 100
rp3

= Intermediate(0 + srthdvalue?)
srthmidevent! = SRThreeRodIntermediateEvent
srthwevent! = None
srthievent! = None
srthrhevent! = SRThreeRodHeightEvent
srthrhvalue! = 0 + srthdvalue?
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
256
SRThreeRodMoveDownInsert
ShimRodThree
srthdvalue? : 0 . . 100
srthievent! : EVENT
srthwevent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
Intermediate

rp3 + srthdvalue? 100 rp3

= Inserted
srthievent! = SRThreeRodInsertedEvent
srthwevent! = None
srthmidevent! = None
srthrhevent! = SRThreeRodHeightEvent
srthrhvalue! = 100
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
257
SRThreeRodMoveDownPartial
ShimRodThree
srthdvalue? : 0 . . 100
srthievent! : EVENT
srthwevent! : EVENT
srthmidevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
Intermediate

rp3 + srthdvalue? < 100

rp3

= Intermediate((Intermediate

rp3) + srthdvalue?)
srthmidevent! = SRThreeRodIntermediateEvent
srthwevent! = None
srthievent! = None
srthrhevent! = SRThreeRodHeightEvent
srthrhvalue! = (Intermediate

rp3) + srthdvalue?
dms3

= dms3
dmpos3

= dmpos3
ram3

= ram3
NeutronFlux

= NeutronFlux
258
SRThreeRodMoveDown
ShimRodThree
srthdevent? : EVENT
srthdvalue? : 0 . . 100
srthievent! : EVENT
srthmidevent! : EVENT
srthwevent! : EVENT
srthrhevent! : EVENT
srthrhvalue! : 0 . . 100
NeutronFlux NFluxThreshold
srthdevent? = SRThreeRodMoveDownEvent
(SRThreeRodMoveDownNoMove
SRThreeRodMoveDownFully
SRThreeRodMoveDownFromTop
SRThreeRodMoveDownInsert
SRThreeRodMoveDownPartial )
srthdevent? = SRThreeRodMoveDownEvent
(rp3

= rp3 dms3

= dms3
dmpos3

= dmpos3 ram3

= ram3
NeutronFlux

= NeutronFlux
srthievent! = None
srthrhevent! = None)
SRThreeTotalMove = SRThreeRodMoveUp SRThreeRodMoveDown
The other behaviour of this part of the system is to control the magnetic
current to each of the rods.
259
SROneCurrentChange
ShimRodOne
srocevent? : EVENT
srocvalue? : N
srocevent? = SROneCurrentChangeEvent
ram1

= srocvalue?
srocevent? = SROneCurrentChangeEvent
ram1

= ram1
dmpos1

= dmpos1
rp1

= rp1
dms1

= dms1
SRTwoCurrentChange
ShimRodTwo
srtcevent? : EVENT
srtcvalue? : N
srtcevent? = SRTwoCurrentChangeEvent
ram2

= srtcvalue?
srtcevent? = SRTwoCurrentChangeEvent
ram2

= ram2
dmpos2

= dmpos2
rp2

= rp2
dms2

= dms2
260
SRThreeCurrentChange
ShimRodThree
srthcevent? : EVENT
srthcvalue? : N
srthcevent? = SRThreeCurrentChangeEvent
ram3

= srthcvalue?
srthcevent? = SRThreeCurrentChangeEvent
ram3

= ram3
dmpos3

= dmpos3
rp3

= rp3
dms3

= dms3
The drive mechanism may also be raised or lowered, so we provide operations
for this. As we are concerned only with the mechanism being at its lowest
point, or not, we describe just the operation to cause it to be at its lowest
point irrespective of its starting position.
SROneLowerDriveMechanism
ShimRodOne
srodmevent! : EVENT
dmpos1

= Lowest
srodmevent! = SROneDMLowerEvent
dms1

= dms1
rp1

= rp1
ram1

= ram1
Similarly for the raise operation it is enough to show that the drive is no longer
at its lowest point, we do not need to detail its actual height.
261
SROneRaiseDriveMechanism
ShimRodOne
srodmevent! : EVENT
dmpos1

= Other
srodmevent! = SROneDMRaiseEvent
dms1

= dms1
rp1

= rp1
ram1

= ram1
SRTwoLowerDriveMechanism
ShimRodTwo
srtdmevent! : EVENT
dmpos2

= Lowest
srtdmevent! = SRTwoDMLowerEvent
dms2

= dms2
rp2

= rp2
ram2

= ram2
SRTwoRaiseDriveMechanism
ShimRodTwo
srtdmevent! : EVENT
dmpos2

= Other
srtdmevent! = SRTwoDMRaiseEvent
dms2 = dms2
rp2

= rp2
ram2

= ram2
262
SRThreeLowerDriveMechanism
ShimRodThree
srthdmevent! : EVENT
dmpos3

= Lowest
srthdmevent! = SRThreeDMLowerEvent
dms3

= dms3
rp3

= rp3
ram3

= ram3
SRThreeRaiseDriveMechanism
ShimRodThree
srthdmevent! : EVENT
dmpos3

= Other
srthdmevent! = SRThreeDMRaiseEvent
dms3 = dms3
rp3

= rp3
ram3

= ram3
There are some operations which will not be controlled from this part of the
system, however they are linked to controls which will appear in this part of the
system interface. For example the requirements we used as our basis describes
an Engaged light. However, there is no operation in our specied system so
far which controls whether or not any of the rods are engaged or not as this
requirement was not given for this part of the system. We can assume that
this system operation is controlled by some other part of the over all system
which we are not describing in this example. For completeness we will describe
operations which engage and disengage the rods but we will provide no controls
in this part of the interface to cause these operations to occur, these would be
263
provided in some other part of the system interface.
SROneEngageRod
ShimRodOne
sroeevent! : EVENT
dms1

= Coupled
sroeevent! = SROneEngagedEvent
rp1

= rp1
dmpos1

= dmpos1
ram1

= ram1
SROneDisengageRod
ShimRodOne
sroeevent! : EVENT
dms1

= Uncoupled
sroeevent! = SROneDisengagedEvent
rp1

= rp1
dmpos1

= dmpos1
ram1

= ram1
264
SRTwoEngageRod
ShimRodTwo
srteevent! : EVENT
dms2

= Coupled
srteevent! = SRTwoEngagedEvent
rp2

= rp2
dmpos2

= dmpos2
ram2

= ram2
SRTwoDisengageRod
ShimRodTwo
srteevent! : EVENT
dms2

= Uncoupled
srteevent! = SRTwoDisengagedEvent
rp2

= rp2
dmpos2

= dmpos2
ram2

= ram2
SRThreeEngageRod
ShimRodThree
srtheevent! : EVENT
dms3

= Coupled
srtheevent! = SRThreeEngagedEvent
rp3

= rp3
dmpos3

= dmpos3
ram3

= ram3
265
SRThreeDisengageRod
ShimRodThree
srtheevent! : EVENT
dms3

= Uncoupled
srtheevent! = SRThreeDisengagedEvent
rp3

= rp3
dmpos3

= dmpos3
ram3

= ram3
Having described the underlying behaviour of the Shim Rod System we can
now move on to the interface elements required to provide this functionality to
the user. We use the original system description provided as the basis for this
interface, starting with the widgets required to provide the desired functional-
ity and then categorising them using our widget hierarchy categories based on
their desired behaviour. The interface requirements start with a description of
four lights.
For each of these control rods, the present operators console in-
cludes a set of four lights:
Engaged - this light indicates whether the rod is magnetically cou-
pled to its drive mechanism
Up - this light indicates whether the rod is fully withdrawn
Down - This light indicates whether the drive mechanism is at its
lowest level
Seated - This light indicates whether the rod is fully inserted into
the core
Each of these lights have an on or o state which is dependent on some value
within the system state which may change. We can therefore identify them as
266
event responders and describe them accordingly.
We start by describing a free set for an observation of whether or not a
light is on.
LIGHTSTATE ::= LightOn | LightO
Now we use the model given by our framework in section 2.7 to describe the
behaviour of these event responders.
SROneEngagedResponseState
el 1state : LIGHTSTATE
SROneEngagedLight
SROneEngagedResponseState
sroeevent? : EVENT
sroeevent? = SROneEngagedEvent
el 1state

= LightOn
sroeevent? = SROneDisengagedEvent
el 1state

= LightO
sroeevent? = SROneEngagedEvent
sroeevent? = SROneDisengagedEvent
el 1state

= el 1state
SRTwoEngagedResponseState
el 2state : LIGHTSTATE
267
SRTwoEngagedLight
SRTwoEngagedResponseState
srteevent? : EVENT
srteevent? = SRTwoEngagedEvent
el 2state

= LightOn
srteevent? = SRTwoDisengagedEvent
el 2state

= LightO
srteevent? = SRTwoEngagedEvent
srteevent? = SRTwoDisengagedEvent
el 2state

= el 2state
SRThreeEngagedResponseState
el 3state : LIGHTSTATE
SRThreeEngagedLight
SRThreeEngagedResponseState
srtheevent? : EVENT
srtheevent? = SRThreeEngagedEvent
el 3state

= LightOn
srtheevent? = SRThreeDisengagedEvent
el 3state

= LightO
srtheevent? = SRThreeEngagedEvent
srtheevent? = SRThreeDisengagedEvent
el 3state

= el 3state
268
ActiveSROneEngageRod =
SROneEngageRod>>SROneEngagedLight
ActiveSROneDisengageRod =
SROneDisengageRod>>SROneEngagedLight
ActiveSRTwoEngageRod =
SRTwoEngageRod>>SRTwoEngagedLight
ActiveSRTwoDisengageRod =
SRTwoDisengageRod>>SRTwoEngagedLight
ActiveSRThreeEngageRod =
SRThreeEngageRod>>SRThreeEngagedLight
ActiveSRThreeDisengageRod =
SRThreeDisengageRod>>SRThreeEngagedLight
We follow the same model for describing each of the other lights required.
SROneDownResponseState
dls1 : LIGHTSTATE
SROneDownLight
SROneDownResponseState
srodmevent? : EVENT
srodmevent? = SROneDMLowerEvent
dls1

= LightOn
srodmevent? = SROneDMRaiseEvent
dls1

= LightO
srodmevent? = SROneDMLowerEvent
srodmevent? = SROneDMRaiseEvent
dls1

= dls1
269
SRTwoDownResponseState
dls2 : LIGHTSTATE
SRTwoDownLight
SRTwoDownResponseState
srtdmevent? : EVENT
srtdmevent? = SRTwoDMLowerEvent
dls2

= LightOn
srtdmevent? = SRTwoDMRaiseEvent
dls2

= LightO
srtdmevent? = SRTwoDMLowerEvent
srtdmevent? = SRTwoDMRaiseEvent
dls2

= dls2
SRThreeDownResponseState
dls3 : LIGHTSTATE
270
SRThreeDownLight
SRThreeDownResponseState
srthdmevent? : EVENT
srthdmevent? = SRThreeDMLowerEvent
dls3

= LightOn
srthdmevent? = SRThreeDMRaiseEvent
dls3

= LightO
srthdmevent? = SRThreeDMLowerEvent
srthdmevent? = SRThreeDMRaiseEvent
dls3

= dls3
ActiveSROneDMLower =
SROneLowerDriveMechanism>>SROneDownLight
ActiveSROneDMRaise =
SROneRaiseDriveMechanism>>SROneDownLight
ActiveSRTwoDMLower =
SRTwoLowerDriveMechanism>>SRTwoDownLight
ActiveSRTwoDMRaise =
SRTwoRaiseDriveMechanism>>SRTwoDownLight
ActiveSRThreeDMLower =
SRThreeLowerDriveMechanism>>SRThreeDownLight
ActiveSRThreeDMRaise =
SRThreeRaiseDriveMechanism>>SRThreeDownLight
The Up light and the Seated light both respond to the rods TotalMove oper-
ation and a such can be seen to operate as a pair, if one is on the other must
be o and vice versa (although there is no problem with both being o). We
therefore describe them as a pair of lights in one schema and link them to the
TotalMove operation in the usual way.
271
SROneUpLightResponseState
uls1 : LIGHTSTATE
SROneSeatedLightResponseState
sls1 : LIGHTSTATE
SROneUpSeatedLight
SROneUpLightResponseState
SROneSeatedLightResponseState
srorwevent? : EVENT
srorievent? : EVENT
srormidevent? : EVENT
(srorwevent? = SROneRodWithdrawnEvent
uls1

= LightOn sls1

= LightO )
(srorievent? = SROneRodInsertedEvent
uls1

= LightO sls1

= LightOn)
(srormidevent? = SROneRodIntermediateEvent
uls1

= LightO sls1

= LightO )
SRTwoUpLightResponseState
uls2 : LIGHTSTATE
SRTwoSeatedLightResponseState
sls2 : LIGHTSTATE
272
SRTwoUpSeatedLight
SRTwoUpLightResponseState
SRTwoSeatedLightResponseState
srtrwevent? : EVENT
srtrievent? : EVENT
srtmidevent? : EVENT
(srtrwevent? = SRTwoRodWithdrawnEvent
uls2

= LightOn sls2

= LightO )
(srtrievent? = SRTwoRodInsertedEvent
uls2

= LightO sls2

= LightOn)
(srtmidevent? = SRTwoRodIntermediateEvent
uls2

= LightO sls2

= LightO )
SRThreeUpLightResponseState
uls3 : LIGHTSTATE
SRThreeSeatedLightResponseState
sls3 : LIGHTSTATE
273
SRThreeUpSeatedLight
SRThreeUpLightResponseState
SRThreeSeatedLightResponseState
srthrwevent? : EVENT
srthrievent? : EVENT
srthmidevent? : EVENT
(srthrwevent? = SRThreeRodWithdrawnEvent
uls3

= LightOn sls3

= LightO )
(srthrievent? = SRThreeRodInsertedEvent
uls3

= LightO sls3

= LightOn)
(srthmidevent? = SRThreeRodIntermediateEvent
uls3

= LightO sls3

= LightO )
We do not show the link between the TotalMove operation and the Lights
immediately as we also need to consider the rod height display control which we
will give rst. The rod height display is also categorised as an event responder,
based on the required behaviour, which gives us the following specication:
SROneRodHeightResponseState
srorhdisplay : 0 . . 100
274
SROneRodHeightDisplay
SROneRodHeightResponseState
srorhevent? : EVENT
srorhvalue? : 0 . . 100
srorhevent? = SROneRodHeightEvent
srorhdisplay

= srorhvalue?
srorhevent? = SROneRodHeightEvent
srorhdisplay

= srorhdisplay
SRTwoRodHeightResponseState
srtrhdisplay : 0 . . 100
SRTwoRodHeightDisplay
SRTwoRodHeightResponseState
srtrhevent? : EVENT
srtrhvalue? : 0 . . 100
srtrhevent? = SRTwoRodHeightEvent
srtrhdisplay

= srtrhvalue?
srtrhevent? = SRTwoRodHeightEvent
srtrhdisplay

= srtrhdisplay
SRThreeRodHeightResponseState
srthrhdisplay : 0 . . 100
275
SRThreeRodHeightDisplay
SRThreeRodHeightResponseState
srthrhevent? : EVENT
srthrhvalue? : 0 . . 100
srthrhevent? = SRThreeRodHeightEvent
srthrhdisplay

= srthrhvalue?
srthrhevent? = SRThreeRodHeightEvent
srthrhdisplay

= srthrhdisplay
Next we have the magnetic current display which is also an event responder.
SROneMCDisplayResponseState
sromcdisplay : N
SROneMagneticCurrentDisplay
SROneMCDisplayResponseState
srocevent? : EVENT
srocvalue? : N
srocevent? = SROneCurrentChangeEvent
sromcdisplay

= srocvalue?
srocevent? = SROneCurrentChangeEvent
sromcdisplay

= sromcdisplay
SRTwoMCDisplayResponseState
srtmcdisplay : N
276
SRTwoMagneticCurrentDisplay
SRTwoMCDisplayResponseState
srtcevent? : EVENT
srtcvalue? : N
srtcevent? = SRTwoCurrentChangeEvent
srtmcdisplay

= srtcvalue?
srtcevent? = SRTwoCurrentChangeEvent
srtmcdisplay

= srtmcdisplay
SRThreeMCDisplayResponseState
srthmcdisplay : N
SRThreeMagneticCurrentDisplay
SRThreeMCDisplayResponseState
srthcevent? : EVENT
srthcvalue? : N
srthcevent? = SRThreeCurrentChangeEvent
srthmcdisplay

= srthcvalue?
srthcevent? = SRThreeCurrentChangeEvent
srthmcdisplay

= srthmcdisplay
The nal part of the interface specication relates to the controls which cause
the rods to move and the magnetic current to change. All of these controls
will be event generators as they will cause system operations to occur, in
addition they will each pass a single value to the operation and as such will be
described as single value selection controls. We begin by describing a selection
277
state which will be used to indicate when a user has activated a control.
SELECTEDSTATE ::= Selected | NotSelected
SROneMoveUpControl
sromuselected : SELECTEDSTATE
sromusetvalue : 0 . . 100
srouevent! : EVENT
srouvalue! : 0 . . 100
sromuselected = Selected
srouevent! = SROneRodMoveUpEvent
sromuselected = NotSelected
srouevent! = None
sromusetvalue = srouvalue!
SROneMoveDownControl
sromdselected : SELECTEDSTATE
sromdsetvalue : 0 . . 100
srodevent! : EVENT
srodvalue! : 0 . . 100
sromdselected = Selected
srodevent! = SROneRodMoveDownEvent
sromdselected = NotSelected
srodevent! = None
sromdsetvalue = srodvalue!
278
SRTwoMoveUpControl
srtmuselected : SELECTEDSTATE
srtmusetvalue : 0 . . 100
srtuevent! : EVENT
srtuvalue! : 0 . . 100
srtmuselected = Selected
srtuevent! = SRTwoRodMoveUpEvent
srtmuselected = NotSelected
srtuevent! = None
srtmusetvalue = srtuvalue!
SRTwoMoveDownControl
srtmdselected : SELECTEDSTATE
srtmdsetvalue : 0 . . 100
srtdevent! : EVENT
srtdvalue! : 0 . . 100
srtmdselected = Selected
srtdevent! = SRTwoRodMoveDownEvent
srtmdselected = NotSelected
srtdevent! = None
srtmdsetvalue = srtdvalue!
279
SRThreeMoveUpControl
srthmuselected : SELECTEDSTATE
srthmusetvalue : 0 . . 100
srthuevent! : EVENT
srthuvalue! : 0 . . 100
srthmuselected = Selected
srthuevent! = SRThreeRodMoveUpEvent
srthmuselected = NotSelected
srthuevent! = None
srthmusetvalue = srthuvalue!
SRThreeMoveDownControl
srthmdselected : SELECTEDSTATE
srthmdsetvalue : 0 . . 100
srthdevent! : EVENT
srthdvalue! : 0 . . 100
srthmdselected = Selected
srthdevent! = SRThreeRodMoveDownEvent
srthmdselected = NotSelected
srthdevent! = None
srthmdsetvalue = srthdvalue!
280
Now we can link the movement controls and displays to the operations.
ActiveSROneTotalMove =
(SROneMoveUpControl SROneMoveDownControl )>>
SROneTotalMove>>(SROneUpSeatedLight
SROneRodHeightDisplay)
ActiveSRTwoTotalMove =
(SRTwoMoveUpControl SRTwoMoveDownControl )>>
SRTwoTotalMove>>(SRTwoUpSeatedLight
SRTwoRodHeightDisplay)
ActiveSRThreeTotalMove =
(SRThreeMoveUpControl SRThreeMoveDownControl )>>
SRThreeTotalMove>>(SRThreeUpSeatedLight
SRThreeRodHeightDisplay)
The nal part of our interface description is the magnetic current change con-
trol.
SROneMagCurrentChangeControl
sromccselected : SELECTEDSTATE
sromccsetvalue : N
srocevent! : EVENT
srocvalue! : N
sromccselected = Selected
srocevent! = SROneCurrentChangeEvent
sromccselected = NotSelected
srocevent! = None
sromccsetvalue = srocvalue!
281
SRTwoMagCurrentChangeControl
srtmccselected : SELECTEDSTATE
srtmccsetvalue : N
srtcevent! : EVENT
srtcvalue! : N
srtmccselected = Selected
srtcevent! = SRTwoCurrentChangeEvent
srtmccselected = NotSelected
srtcevent! = None
srtmccsetvalue = srtcvalue!
SRThreeMagCurrentChangeControl
srthmccselected : SELECTEDSTATE
srthmccsetvalue : N
srthcevent! : EVENT
srthcvalue! : N
srthmccselected = Selected
srthcevent! = SRThreeCurrentChangeEvent
srthmccselected = NotSelected
srthcevent! = None
srthmccsetvalue = srthcvalue!
282
ActiveSROneCurrentChange = SROneMagCurrentChangeControl >>
SROneCurrentChange>>SROneMagneticCurrentDisplay
ActiveSRTwoCurrentChange = SRTwoMagCurrentChangeControl >>
SRTwoCurrentChange>>SRTwoMagneticCurrentDisplay
ActiveSRThreeCurrentChange = SRThreeMagCurrentChangeControl >>
SRThreeCurrentChange>>SRThreeMagneticCurrentDisplay
283
Appendix D
Specication of Opening Window of GNOME PdfViewer
Application
This is the specication of the RootDisplay, i.e. the initial window of the
GNOME PDFViewer application, and some parts of the system functionality.
We begin by dening the given sets and constants required.
CONTROLSTATE ::= Active [ NotActive
ABLESTATE ::= Enabled [ Disabled
SELECTEDSTATE ::= Selected [ NotSelected
EVENT ::= AboutEvent [ CloseWindowEvent [ FullScreenEvent [
HelpEvent [ MaximiseWindowEvent [ MinimiseWindowEvent [
NoEvent [ OpenFileEvent [ OpenFileDialogEvent [ QuitEvent
DRAGRESIZABLE ::= Yes [ No
LABEL ::= Cancel [ Close [ Contents [ FullScreen [ Ok [ Open [ Quit
About [ File [ Help [ NoLabel [ View
ICON ::= GNOMEAbout [ GNOMEClose [ GNOMEContents [
GNOMEDropDownArrow [ GNOMEHelp [ GNOMEMaximise [
GNOMEMinimise [ GNOMEOpenFolder [ GNOMEQuit [ NoIcon
WINDOWTITLE ::= Activity [ Application [ Description [ FileName [
FilePath [ NoTitle
WINDOWSIZE ::= Maximised [ Minimised [ Standard [ UserDened
WINDOWVISIBLE ::= Visible [ NotVisible
KEYSHORTCUT ::= CtrlO [ CtrlW [ CtrlQ [ F11 [ F1 [ NoKey
RESPONSESTATE ::= On [ O
[FILENAME]
[FILEPATH]
These denitions immediately give us some control over the implementation
of the interface by dening specic allowable values for things like icons and
labels. Whilst this may seem a very low level activity for the specication
285
these can be used in conjunction with the guidelines to ensure certain proper-
ties of these values hold. For example we can ensure consistency of labelling
throughout our interface by ensuring that all values used come from the given
sets dened in the specication and further we can then ensure that wherever
a particular label is given to a widget all other widgets with the same label
perform the same operation.
We dene the underlying system rst, this consists of the actual system
state and the system operations. We do not give all system operations here,
just those which are accessible to a user in this particular state of the interface,
i.e. from the RootDisplay. The system consists of a set of les which can be
loaded and the lepaths for each of these les.
System
currentFiles : PFILENAME
currentFilePaths : PFILEPATH
The initial state of the system is such that there are no les loaded, and
therefore no le paths stored.
InitSystem
System
currentFiles

=
currentFilePaths

=
The operations that can be performed on the system state from this state of
the interface are to open a new le and to quit the application. We therefore
next describe these partial operations.
286
OpenFileOperation
System
ofevent? : EVENT
fname? : FILENAME
fpath? : FILEPATH
ofevent? = OpenFileEvent
currentFiles

= currentFiles fname?
currentFilePaths

= currentFilePaths fpath?
ofevent? ,= OpenFileEvent currentFiles

= currentFiles
currentFilePaths

= currentFilePaths
systemState

= systemState
This is not a total operation as it does take into consideration the requirements
that the chosen le exists or that the lepath is correct. The full specication
of such a system would take care of this by including these requirements within
the precondiction of such an operation and describing the error conditions.
The QuitAppOperation describes what happens upon termination of the ap-
plication, the currentFiles and currentFilePaths sets are reset to empty before
the system ends, in this way we can suggest that the application release any
les back to the operating system before it terminates.
QuitAppOperation
System
qevent? : EVENT
qevent? = QuitEvent currentFiles

=
currentFilePaths

=
qevent? ,= QuitEvent currentFiles

= currentFiles
currentFilePaths

= currentFilePaths
Next we describe the parts of the interface elements which are available, in
this case where we are describing an implementation of a real system, we are
287
describing the actual widgets which the interface is comprised of. The rst
three widgets described are used to interact with other parts of the interface
and control the overall window state.
MinimiseRWindowButton
minrblabel : LABEL
minrbicon : ICON
minrbcstate : CONTROLSTATE
mrwevent : EVENT
minrblabel = NoLabel
minrbicon = GNOMEMinimise
minrbcstate = Active mrwevent = MinimiseWindowEvent
minrbcstate = NotActive mrwevent = None
MaximiseRWindowButton
maxblabel : LABEL
maxbicon : ICON
maxbcstate : CONTROLSTATE
mxrevent : EVENT
maxblabel = NoLabel
maxbicon = GNOMEMaximise
maxbcstate = Active mxrevent = MaximiseWindowEvent
maxbcstate = NotActive mxrevent = None
288
CloseRWindowButton
cblabel : LABEL
cbicon : ICON
cbcstate : CONTROLSTATE
crwevent : EVENT
cblabel = NoLabel
cbicon = GNOMEClose
cbcstate = Active crwevent = CloseWindowEvent
cbcstate = NotActive crwevent = None
Next we describe the operational widgets, i.e. those which the user will use
to interact with the underlying system state.
OpenFileButton
ofblabel : LABEL
ofbicon : ICON
ofbcstate : CONTROLSTATE
ofastate : ABLESTATE
ofevent! : EVENT
ofblabel = Open
ofbicon = GNOMEOpenFolder
ofbcstate = Active ofevent! = OpenFileEvent
ofbcstate = NotActive ofevent! = None
ofastate = Disabled ofbcstate = NotActive
The next widget we describe is the somewhat unusual widget called IconBut-
ton. It is included because it is a part of the interface which we are reverse
engineering. However, as soon as we describe it we can see that it is unusual
because there is no EVENT value given for the ibevent! observation. This is
because making this button active (by clicking on it in the interface) does in
fact have no eect, the process of reverse engineering this interface immedi-
289
ately highlights a problem with it, that of having a redundant button. We
include it in this specication for completeness of the example.
IconButton
iblabel : LABEL
ibicon : ICON
ibcstate : CONTROLSTATE
ibastate : ABLESTATE
ibevent! : EVENT
iblabel = NoLabel
ibicon = GNOMEDropDownArrow
ibastate = Disabled ibcstate = NotActive
Having described the visible buttons, we now move on to the menu items
which are available. We describe each of the menu items as individual pieces
of state rst and then describe the overall state of each of the menus.
OpenMenuItem
omlabel : LABEL
omicon : ICON
omkey : KEYSHORTCUT
omselstate : SELECTEDSTATE
omastate : ABLESTATE
omevent! : EVENT
omlabel = Open
omicon = GNOMEOpenFolder
omkey = CtrlO
omselstate = Selected omevent! = OpenFileDialogEvent
omselstate = NotSelected omevent! = None
omastate = Disabled omselstate = NotSelected
290
CloseMenuItem
cmlabel : LABEL
cmicon : ICON
cmkey : KEYSHORTCUT
cmselstate : SELECTEDSTATE
cmastate : ABLESTATE
cmevent! : EVENT
cmlabel = Close
cmicon = GNOMEClose
cmkey = CtrlW
cmselstate = Selected cmevent! = CloseWindowEvent
cmselstate = NotSelected cmevent! = None
cmastate = Disabled cmselstate = NotSelected
QuitMenuItem
qlabel : LABEL
qicon : ICON
qkey : KEYSHORTCUT
qselstate : SELECTEDSTATE
qastate : ABLESTATE
qevent! : EVENT
qlabel = Quit
qicon = GNOMEQuit
qkey = CtrlQ
qselstate = Selected qevent! = QuitEvent
qselstate = NotSelected qevent! = None
qastate = Disabled qselstate = NotSelected
291
FileMenu
fmlabel : LABEL
fmicon : ICON
fmkey : KEYSHORTCUT
OpenMenuItem
CloseMenuItem
QuitMenuItem
fmlabel = File
fmicon = NoIcon
fmkey = NoKey
FullScreenMenuItem
fslabel : LABEL
fsicon : ICON
fskey : KEYSHORTCUT
fsselstate : SELECTEDSTATE
fsastate : ABLESTATE
fsevent! : EVENT
fslabel = FullScreen
fsicon = NoIcon
fskey = F11
fsselstate = Selected fsevent! = FullScreenEvent
fsselstate = NotSelected fsevent! = None
fsastate = Disabled fsselstate = NotSelected
292
ViewMenu
vmlabel : LABEL
vmicon : ICON
vmkey : KEYSHORTCUT
FullScreenMenuItem
vmlabel = File
vmicon = NoIcon
vmkey = NoKey
ContentsMenuItem
comlabel : LABEL
comicon : ICON
comkey : KEYSHORTCUT
comselstate : SELECTEDSTATE
comastate : ABLESTATE
comevent! : EVENT
comlabel = Contents
comicon = GNOMEContents
comkey = F1
comselstate = Selected comevent! = HelpEvent
comselstate = NotSelected comevent! = None
comastate = Disabled comselstate = NotSelected
293
AboutMenuItem
amlabel : LABEL
amicon : ICON
amkey : KEYSHORTCUT
amselstate : SELECTEDSTATE
amastate : ABLESTATE
amevent! : EVENT
amlabel = About
amicon = GNOMEAbout
amkey = NoKey
amselstate = Selected amevent! = AboutEvent
amselstate = NotSelected amevent! = None
amastate = Disabled amselstate = NotSelected
HelpMenu
hmlabel : LABEL
hmicon : ICON
hmkey : KEYSHORTCUT
ContentsMenuItem
AboutMenuItem
hmlabel = Help
hmicon = NoIcon
hmkey = NoKey
294
RootWindowResponseState
rwsize : WINDOWSIZE
rwvisible : WINDOWVISIBLE
295
RootWindow
RootWindowResponseState
mrwevent : EVENT
mxrwevent : EVENT
crwevent : EVENT
rwtitle : WINDOWTITLE
rwresizable : DRAGRESIZABLE
MinimiseRWindowButton
MaximiseRWindowButton
CloseRWindowButton
FileMenu
ViewMenu
HelpMenu
OpenFileButton
IconButton
rwtitle = Application
rwresizable = Yes
(mrwevent = MinimiseWindowEvent rwsize

= Minimised
rwvisible

= rwvisible
mxrwevent = None crwevent = None)
(mxrwevent = MaximiseWindowEvent rwsize

= Maximised
rwvisible

= rwvisible
mrwevent = None crwevent = None)
(crwevent = CloseWindowEvent rwvisible

= NotVisible
rwsize

= rwsize
mrwevent = None mxrwevent = None)
rwvisible

= rwvisible rwsize

= rwsize
The remaining menu items are left at a more abstract level in this speci-
cation as they activate other parts of the interface by opening new windows
296
which are not described in this example.
HelpWindowResponseState
hwrstate : RESPONSESTATE
HelpWindow
HelpWindowResponseState
cmevent? : EVENT
cmevent? = HelpEvent hwrstate

= On
cmevent? ,= HelpEvent hwrstate

= O
AboutWindowResponseState
awrstate : RESPONSESTATE
AboutWindow
AboutWindowResponseState
amevent? : EVENT
amevent? = AboutEvent awrstate

= On
amevent? ,= AboutEvent awrstate

= O
ActiveContentsMenuItem = ContentsMenuItem>>HelpWindow
ActiveAboutMenuItem = AboutMenuItem>>AboutWindow
297
CloseOFDialogueWindowButton
cdblabel : LABEL
cdbicon : ICON
cdbcstate : CONTROLSTATE
cdwevent : EVENT
cdblabel = NoLabel
cdbicon = GNOMEClose
cdbcstate = Active cdwevent = CloseWindowEvent
cdbcstate = NotActive cdwevent = None
OpenFileDialogueResponseState
ofdwsize : WINDOWSIZE
ofdwvisible : WINDOWVISIBLE
When we describe the window management control behaviour for resizing or
closing the window we need to ensure that these are mutually exclusive and
so this is included in the predicate.
298
OpenFileDialogueWindow
OpenFileDialogueResponseState
cdwevent : EVENT
mdwevent : EVENT
mxdwevent : EVENT
ofdtitle : WINDOWTITLE
ofdresizable : DRAGRESIZABLE
CloseOFDialogueWindowButton
ofdtitle = Activity
ofdresizable = Yes
(mdwevent = MinimiseWindowEvent ofdwsize

= Minimised
ofdwvisible

= ofdwvisible
mxdwevent = None cdwevent = None)
(mxdwevent = MaximiseWindowEvent ofdwsize

= Maximised
ofdwvisible

= ofdwvisible
mdwevent = None cdwevent = None)
(cdwevent = CloseWindowEvent ofdwvisible

= NotVisible
ofdwsize

= ofdwsize
mdwevent = None mxdwevent = None)
ofdwvisible

= ofdwvisible ofdwsize

= ofdwsize
299
Appendix E
Code for RBGroup.java Example
import java.awt.*;
import javax.swing.*;
import java.awt.event.*;
public class RBGroup extends JFrame {
//Declare the individual radio buttons
JRadioButton smallrb;
JRadioButton mediumrb;
JRadioButton largerb;
//Required main function
public static void main(String args[]){
RBGroup myGui = new RBGroup(m);
myGui.show();
}
//Constructor requires one argument representing current
// system textsize
public RBGroup(char currentSize){
//set up the window
setTitle("Radio Button Group");
setSize(400,400);
setLocationRelativeTo(null);
//initialise the radio buttons
smallrb = new JRadioButton("Small");
mediumrb = new JRadioButton("Medium");
largerb = new JRadioButton("Large");
301
//call the function to determine which radio button
//is set at start
setSelectionValues(currentSize);
//create the button group and add each button
//a button group ensures that the buttons behave as a proper
// radio button group
// i.e. selecting one will deselect all others
ButtonGroup rbgroup = new ButtonGroup();
rbgroup.add(smallrb);
rbgroup.add(mediumrb);
rbgroup.add(largerb);
//create a panel to put the buttons together in the window
JPanel radioPanel = new JPanel(new GridLayout(0, 1));
radioPanel.add(smallrb);
radioPanel.add(mediumrb);
radioPanel.add(largerb);
//add action listeners to each button to show what happens
//when they are selected
smallrb.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
resetText(8);
}
});
mediumrb.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
resetText(12);
}
});
302
largerb.addActionListener(new ActionListener(){
public void actionPerformed(ActionEvent e){
resetText(12);
}
});
//add the panel of radio buttons to the window
getContentPane().add(radioPanel);
}
//Function to determine which radio button should be selected
//at start up based on the value of size
private void setSelectionValues(char size){
if(size == s){
smallrb.setSelected(true);
mediumrb.setSelected(false);
largerb.setSelected(false);
}
else if (size == m){
smallrb.setSelected(false);
mediumrb.setSelected(true);
largerb.setSelected(false);
}
else {
smallrb.setSelected(false);
mediumrb.setSelected(false);
largerb.setSelected(true);
}
}
303
public void resetText(int n){
//do nothing this is a dummy placeholder for some system operation
}
}
304
References
[1] ISO/IEC 13568. Information TechnologyZ Formal Specication
NotationSyntax, Type System and Semantics. Prentice-Hall Interna-
tional series in computer science. ISO/IEC, rst edition, 2002.
[2] Alertbox. Current Issues in Web Usability.
Bi-weekly column by Dr. Jakob Nielsen, principal, Nielsen Norman Group,
http://www.useit.com/alertbox/.
[3] Stuart Anderson. Proving properties of interactive systems. In Harri-
son and Monk, editors, People and Computers: Designing for usability.
Cambridge University Press, 1986.
[4] Apple Human Interface Guidelines, 2004,
http://developer.apple.com/documentation/UserExperience/
Conceptual/OSXHIGuidelines/index.html.
[5] S. Balbo. Software tools for evaluating the usability of user interfaces.
In Y. Anzi and K. Ogawa, editors, Proceedings of the 6th International
Conference on HCI, Pacicon 1805 Yokohama (Japan), 1995.
[6] Rosalind Barden, Susan Stepney, and David Cooper. Z in practice.
Prentice-Hall, Inc., 1995.
[7] J. Barwise and J. Etchemendy. The language of rst-order logic. Num-
ber 23 in CSLI Lecture notes. CSLI Publications, 1993.
[8] Fevzi Belli. Finite-state testing and analysis of graphical user interfaces.
In ISSRE, pages 3443, 2001.
[9] F. Bodart, A. Hennebert, J. Leheureux, and J. Vanderdonckt. Towards
a dynamic strategy for computer-aided visual placement. In S. Levialdi
T. Catarci, M. Costabile and G. Santucci, editors, Proceedings of Advanced
Visual Interface, pages 7887. North-Holland, 1994.
305
[10] CADUI: International Conference on Computer-Aided Design of User In-
terfaces,
http://www.hcirn.com/res/event/cadui.php.
[11] S. Card, P. Moran, and A. Newell. The Psychology of Human Computer
Interaction. Lawrence Erlbaum Associates, 1983.
[12] Cornell University Ergonomics Web,
Ergonomic Guidelines for User-Interface Design,
http://ergo.human.cornell.edu/ahtutorials/interface.html.
[13] J. Coutaz. Pac: An object oriented model for dialog design. In H.-J.
Bullinger and B. Shakel, editors, Human-Computer Interaction: INTER-
ACT87, pages 431436. North-Holland, Amsterdam, 1987.
[14] W.-P. de Roever and K. Engelhardt. Data Renement: Model-Oriented
Proof Methods and their Comparison. Cambridge University Press, 1998.
[15] Fiorella de Rosis, Sebastiano Pizzutilo, and Berardina de Carolis. For-
mal description and evaluation of user-adapted interfaces. Int. J. Hum.-
Comput. Stud., 49(2):95120, 1998.
[16] Flavio de Souza and Nigel Bevan. The use of guidelines in menu interface
design: Evaluation of a draft standard. In Proceedings of the IFIP TC13
Third International Conference on Human-Computer Interaction, pages
435440. North-Holland, 1990.
[17] N. Delisle and D. Garlan. Formally specifying electronic instruments. In
IWSSD 89: Proceedings of the 5th international workshop on Software
specication and design, pages 242248. ACM Press, 1989.
[18] John Derrick and Eerke Boiten. Renement in Z and Object-Z: Founda-
tions and Advanced Applications. Formal Approaches to Computing and
Information Technology. Springer, May 2001.
306
[19] Antoni Diller. Z. An Introduction to Formal Methods (Second Edition).
John Wiley and Sons, 1994.
[20] A. Dix, J. Finlay, G. Abowd, and R. Beale. Human-Computer Interaction.
Prentice Hall, 2nd. edition, 1997.
[21] A. Dix and C. Runciman. Abstract models of interactive systems. People
and Computers: Designing the Interface, pages 1322, 1985.
[22] Alan J. Dix. Formal methods an introduction to and overview of the
use of formal methods within hci. In A. Monk and N. Gilbert, editors,
Perspectives on HCI: Diverse Approaches, chapter 2, pages 943. London
Academic Press, 1995.
[23] D.J. Duke and M.D. Harrison. Abstract interaction objects. In Proceedings
of Eurographics 93, Computer Graphics Forum, 1993.
[24] GNOME Human Interface Guidelines(1.0), 2002
http://developer.gnome.org/projects/gup/hig/1.0/.
[25] P.D. Gray and C.W. Johnson. Requirements for the next generation of
user interface specication languages. In Proceedings of The Design, Speci-
cation And Verication Of Interactive Systems, pages 113133. Springer
Verlag, 1995.
[26] Richard G. Hamlet. Software quality, software process, and software test-
ing. Advances in Computers, 41:191229, 1995.
[27] M. Harrison and H. Thimbleby. Formal methods in human-computer in-
teraction. Cambridge University Press, 1990.
[28] IBM Design Concepts,
http://www-3.ibm.com/ibm/easy/eou ext.nsf/publish/567.
307
[29] Isys Information Architects Inc., Interface Hall of Shame,
http://digilander.libero.it/chiediloapippo/Engineering
/iarchitect/target.htm.
[30] J. Jacky. The Way of Z: Practical programming with formal methods.
Cambridge University Press, 1997.
[31] Robert J. K. Jacob. Using formal specications in the design of a human-
computer interface. In Proceedings of the 1982 conference on Human
factors in computing systems, pages 315321. ACM Press, 1982.
[32] J.-P. Jacquot and D. Quesnot. Early specication of user-interfaces: To-
ward a formal approach. In Proceedings of the 19th International Confer-
ence on Software Engineering, pages 150160. ACM Press, 1997.
[33] Hannu-Matti J arvinen and Reino Kurki-Suonio. DisCo specication lan-
guage: marriage of actions and objects. In Proceedings of the 11th Inter-
national Conference on Distributed Computing Systems, pages 142151.
IEEE Computer Society Press, 1991.
[34] Java Beans Description and API,
http://java.sun.com/j2se/1.4.2/docs/guide/beans/index.html.
[35] Java Reection Description and API,
http://java.sun.com/j2se/1.4.2/docs/guide/reflection
/index.html.
[36] C. W. Johnson. A probabilistic logic for the development of safety-critical,
interactive systems. Int. J. Man-Mach. Stud., 39(2):333351, 1993.
[37] C. W. Johnson. Using Z to support the design of interactive safety-critical
systems. IEE/BCS Software Engineering Journal, 10(2):4960, 1995.
[38] Won Chul Kim and James D. Foley. Providing high-level control and
expert assistance in the user interface presentation design. In INTERCHI
308
93: Proceedings of the INTERCHI 93 conference on Human factors in
computing systems, pages 430437. IOS Press, 1993.
[39] J. Knight and S. Brilliant. Preliminary evaluation of a formal approach
to user interface specication. In Proceedings of the 10th International
Conference of Z Users on the Z Formal Specication Notation, pages 329
346, 1997.
[40] Microsoft MSDN User Interface Design Guidelines,
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/dv evtuv/html/etori
UserInterfaceDesignGuidelines.asp.
[41] MIT Aective Computing,
http://affect.media.mit.edu/.
[42] Glenford J. Myers. Art of Software Testing. John Wiley and Sons, Inc.,
1979.
[43] Philippe Palanque and Fabio Paterno. Formal Methods in Human-
Computer Interaction. Springer-Verlag New York, Inc., 1997.
[44] G. E. Pfa. User Interface Management Systems. Springer-Verlag New
York, Inc., 1985.
[45] G. Reeve. The syntax and semantics of -charts. Technical Report
04/2004, Department of Computer Science, University of Waikato, 2004.
[46] G. Reeve and S. Reeves. -charts and z: Examples and extensions. In Pro-
ceedings of APSEC2000.IEEE Computer Society, pages 258263, 2000.
[47] Steve Reeves. A teaching and support tool for building formal models of
graphical user-interfaces. Technical Report 95/21, Department of Com-
puter Science, University of Waikato, 1995.
309
[48] Christopher Rou. Workshop on formal specication of user interfaces
(abstract). In Conference companion on Human factors in computing
systems, page 441. ACM Press, 1995.
[49] Andrew Sears. Layout appropriateness: A metric for evaluating user in-
terface widget layout. Software Engineering, 19(7):707719, 1993.
[50] Senseboard Technologies,
http://www.senseboard.com/product.php.
[51] S. Smith and J. Mosier. Guidelines for designing user interface soft-
ware. Technical Report ESD-TR-86-278, Mitre Corporation, Bedford,
MA, 1986.
[52] J. M. Spivey. The Z notation: A reference manual. Prentice-Hall Inter-
national series in computer science. Prentice Hall, 2nd. edition, 1992.
[53] B. A. Sufrin. Formal methods and the design of eective user interfaces.
In M. D. Harrison and A. F. Monk, editors, People and Computers: De-
signing for Usability. Cambridge University Press, 1986.
[54] Kari Syst a. Adding user interface to a behavioural specication. In
Engineering for Human-Computer Interaction, Proceedings of the IFIP
TC2/WG2.7 Working Conference on Engineering for Human-Computer
Interaction, pages 227244, 1995.
[55] Features of Visual Basic ActiveX Components,
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/vbcon98 /html/
vbconolecomponentsyoucancreatewithvisualbasic.asp.
[56] Margaret M. West and Barry M. Eaglestone. Software development: two
approaches to animation of z specications using prolog. Softw. Eng. J.,
7(4):264276, 1992.
310
[57] J. Woodcock and J. Davies. Using Z: Specication, Renement and Proof.
Prentice Hall, 1996.
311