Ashley McNeile, Ella Roubtsova and Gerrit van der Veer
Metamaxim Ltd, UK and Open University of the Netherlands, The Netherlands
Human-computer interaction, Protocol Models, separation of concerns, CSP composition, local reasoning.
Current approaches to modeling human-computer interaction do not always succeed in producing behaviorally
complete models of manageable size and complexity. We argue that the reason for this lies in lack of sup-
port for parallel composition of partial behavioral descriptions, and propose the recently developed Protocol
Modeling approach as a superior alternative. The semantics of Protocol Modeling support separation and
composition of concerns in models of human-computer interaction, and the production of executable models
to explore and refine the desired behavior. Protocol Modeling supports a crucial property sought in modeling
methods if it is to scale to complex problems, namely the ability to reason about the modeled behavior of the
whole based on examination only of a part (sometimes called ”modular” or ”local” reasoning).
Human Computer Interaction (HCI), perhaps more
than any other aspect of a system, calls for the need
to be able to capture complex behavior. A user in-
terface may have multiple simultaneous states associ-
ated with different concurrent aspects of a user’s task.
This is the kind of situation which, if modeled in an
inappropriate way, can lead to high complexity driven
by combinatorial explosion, with the result that model
becomes intellectually unmanageable when applied to
a large problem.
Modeling approaches commonly used to model
HCI behavior fail to handle complexity well because
they use an unsatisfactory approach to decomposition
of a large problem into smaller, simpler parts. For
instance two widely promoted approaches, User Vir-
tual Machine (UVM) (M.Tauber, 1988; A. Dix, G.
Abowd, R. Bealle, J. Finlaj, 1998; D. Hix, H. Hartson,
1998; S. Payne, T. Green, 2000) and Coloured Petri
Nets (P. Palanque, R. Bastide, L. Dourte, C. Sibertin-
Blanc, 1993), support two basic methods of combin-
ing parts and hence to restructure a large model into
parts: linear merging and hierarchical structuring.
The first of these means concatenation of sub-models
such that some output states of one model become the
input states of another model. The second means re-
placing a node of a model by a sub-model which has
its own structure, a technique that can be applied re-
cursively to create a hierarchy of models.
While both of these techniques allow a problem
to be broken up, both result in parts that can only be
understood by reference to the rest of the model and
how all the parts work together. Moreover, neither
addresses the issue of multiple simultaneous states as-
sociated with different concurrent aspects of a user’s
task that is a common feature of HCI requirements,
for which a parallel (rather than linear or hierarchi-
cal) composition technique is essential. As a result
decomposition in these approaches does not gener-
ally support maintenance of intellectual control over
a model as complexity grows.
Our thesis is that the right way to achieve scalabil-
ity is through parallel composition of partial behav-
ioral descriptions in such a way that the parts can be
reasoned about independently of each other. In this
paper we examine the ability of the Protocol Model-
ing (PM) approach (A. McNeile, N. Simons, 2006) to
support this paradigm. Although the domain of HCI
is a novel application area for Protocol Modeling, it
appears well suited to it. This paper is structured as
Section 2 presents a case study and shows it as
both a conventional HCI model and a PM model.
Section 3 explains and illustrates the semantics of
the PM approach using the case study.
Section 4 concludes the paper by showing the role
of the PM approach in HCI design.
McNeile A., Roubtsova E. and van der Veer G. (2008).
In Proceedings of the Tenth International Conference on Enterprise Information Systems - HCI, pages 367-370
DOI: 10.5220/0001701503670370
We illustrate the UVM approach by modeling the
HCI of the search subsystem of the information
system BaMaS (BaMaS, 2007). BaMas collects
and provides information about links and bridge
programmes between Bachelor and Master degree
programmes in the Netherlands. After finishing a
Bachelor Programme at one university a student can
continue with a Masters Programme at the same or
another university, provided that his/her Bachelor
Programme is a recognized qualification for the
chosen Masters degree. A user of the BaMaS system
can choose an Institution (University) and a Bachelor
Programme and investigate which programmes this
Bachelor degree qualifies him or her to pursue. Alter-
natively, a user can choose an Institution or a Masters
Programme and find which Bachelor Programmes
meet the requirements for admission into this Masters
Programme, with or without a bridge program.
UVM of Search in BaMaS. The UVM HCI
model of the search subsystem is shown in Figure 1.
The states are depicted as ellipses. For example,
state AllB, AllM indicates that no selection of an
institute has been made by the user. State IB, AllM
means that an Institution for Bachelor has been
A transition is represented by an arc labelled by
the events that cause the transition. For exam-
ple, the transition from AllB, AllM to IB, AllM is
caused by event Select IB.
The human-computer interaction is modeled as a
whole, so the interaction during the selection of
an institute cannot be separated from the search of
information about the links and bridge programs
between Bachelor and Master courses. If the UVM
needs to be extended and redrawn, states and arcs
can be added but there is no guarantee that the
functionality of the initial UVM is preserved. Af-
ter extension or change the model must be fully
regression tested, and it is notoriously difficult to
ensure that it has not been ”broken” by a modification.
Protocol Model of Search in BaMaS. In order
to show the difference of UVM and PM models we
show the Protocol Model of the search functionality
in BaMaS without explanation of semantic details,
which are covered in the next section. The PM model
comprises (Figure 2) four small protocol machines:
Machine Selection for Bachelor represents the
human-computer protocol for selection of an in-
stitute and a programme for a Bachelor pro-
Select IM
Select PB
De-select PB
Select IM
De-select IM
Select IB
Select IB,
De-select IB
Select PM
De-select PM
Select PM,
De-select PM
Select PM,
De-select PM
Select IB,
De-select IB
Select PB,
De-select PB
Select BP,
De-select BP
Select IM,
De-select IM
Select IB,
Select PB
Select IB,
Select IM,
Select IB,
Select IM,
Select PM
Select IB,
Select PB,
Select IM,
Select PM
Select IB,
Select IM,
Select PM
Institution display screen
Show IM
Show IB
Show IB,
Show IM
Show IM
Select IM,
Select PM
Show IB,
Show IM
[ Links exist ] Show Links
Dashed arcs are labeled by De-selectIB, De-selectIM
Open UI
Programme display screen
Select PB,
Select PM
Show PM
Show PM
Show PB.
Show IB,
Show IM.
Show PB,
Show PM
Link display screen
Show PB
Select IM
De-select IM
Select IB,
De-select IB
Show IB,
Show IM
Show IB
Figure 1: UVM model of the search in BaMaS.
Machine Selection for Master similarly handles
the selection steps for a Masters programme.
Machine Display Screens presents the screens that
can be seen: the choice screen, the screen about
the chosen Institution, the screen about the cho-
sen programme and the screen presenting links
between programmes.
Machine Link Display presents the two possible
consequences of the choices of programmes: ”No
links” between programmes and ”Links exist”.
The composition of those protocol machines, as ex-
plained in the next section, models all the functional-
ity of the search subsystem.
This section provides a brief summary of the seman-
tics of Protocol Modeling. A fuller description is
given in (A. McNeile, N. Simons, 2006).
Events. An ”event” in PM (more properly ”event
instance”) is the data representation of an occurrence
in the environment as a set of data attributes. Every
event is an instance of an event type, and the type of
an event determines its metadata or attribute schema.
ICEIS 2008 - International Conference on Enterprise Information Systems
Both IB and PB
IB selected
PB unselected
Open UI
Selection for Bachelor
IB selected
PB selected
Select IB
De-select IB
Select PB
De-select PB
Select PB
Select IB
De-select IB
Display Screens
Select PM
Show IB,
Show Links
Show PB,
Show Links
Show Links
Show IB
Show IM
Open UI
Show PB,
Show PM
Both IM and PM
IM selected
PM unselected
Open UI
Selection for Master
IM selected
PM selected
Select IM
De-select IM
Select PM
De-select PM
Select IM
De-select IM
Show IM,
Show Links
Show PM,
Show Links
Select PB
Select PM,
Link Display
No links
Show Links
Select from LINK table where
(Bachelor Institution = ((if one is selected “selected IB” else “All” )
Master Institution = (if one is selected “selected IM” else “All”)
Bachelor Programme =(if one is selected “selected PB” else “All” )
Master Programme =(if one is selected “selected PM” else “All”));
if (size of select table = 0)
return "No Links";
else return "Links Exist";
State Function:
Figure 2: PM model of the search in BaMaS.
An attribute schema is being the set of data attributes
that completely define an instance of the event type.
A protocol machine has an ”alphabet” of event types
that it understands. For example, machine Selection
for Bachelor understands events {Open UI, Select
IB, Select PB, Show PB, Show Links, De-select PB,
De-select IB}
States and Variables. Between handling events, a
protocol machine rests in a well defined quiescent
state, meaning that it can undergo no further change
of state unless and until presented with a new event.
A machine may only be presented with a new event
when in such a state.
A state of Protocol Machine is specified by its
name and by values of local variables. A protocol
machine can remember information from events
in local variables. For example, protocol machine
Selection for Bachelor has local variables presenting
the chosen institution IB and the chosen programme
PB. Protocol machines can read values of local
variables of other composed protocol machines, but
cannot change them.
Behavior of a PM. When a protocol machine is
presented with an event it will either ignore it, accept
it or refuse it as follows:
When a machine is presented with an event that
is not represented in its alphabet, the machine
ignores it.
When presented with an event that is represented
in its alphabet, it will either accept it or refuse it.
Acceptance or refusal of an event by the machine
is determined by rules that the machine evaluates
based on the values of its accessible storage.
Note that ”refusal” means that the machine is unable
to handle the event at all, and this normally means
that some kind of error message is generated back
to the environment. How or where such an error is
generated is not of concern for modeling purposes.
Composition. Composing two protocol machines
yields another protocol machine. The alphabet of the
composed machines is the union of the alphabets of
the constituent machines; and the local storage of the
composed machine is the union of the local storages
of the constituent machines. The rules for whether
the composed machine accepts, refuses or ignores a
presented event are:
If both constituent machines ignore the event, the
composed machine ignores it;
If either constituent machine refuses the event, the
composed machine refuses it;
Otherwise the composed machine accepts the
These rules correspond to the parallel composition
operator (P k Q) of Hoare’s process algebra, Com-
municating Sequential Processes (C. Hoare, 1985).
The definition of a PM does not require that its
state is stored, and so it is possible to have the state
of a PM returned by a function (called the machine’s
State Function). This is exactly analogous to a
derived or calculated attribute, where the attribute’s
value is calculated on-the-fly when it is required.
Derived states are represented diagrammatically
by a double outline around the state. The protocol
machine Link Display (Figure 2) has derived states:
No links and Links exist. Protocol machines with
derived states take part in composition exactly like
machines with stored states. Applying the compo-
sition rules, event Show Links is accepted iff it is
accepted by all machines: Display Screens, Link
Display, Selection for Bachelor and Selection for
Master. If, for example, machine Link Display is in
the derived state No links, the event Show Link is
refused (not possible).
Local Reasoning in Protocol Models. An im-
portant property of CSP composition is that it
guarantees the ability to reason about the behavior
of the whole (the result of composition) based on
examination of the parts in isolation. This property
is known as local (or modular) reasoning and is
based on the fact that CSP composition ensures Ob-
servational Consistency (J. Ebert, G. Engels, 1994)
between a composite machine and its constituents.
Formally: If we take a sequence, S, of events that
is accepted by the composition (M
k M
), then the
subsequence, S
, of S obtained by removing all events
in S that are not in the alphabet of M
would be
accepted by the machine M
by itself. In other words,
composing another machine with M
cannot ”break
its trace behavior”. For our BaMaS example the local
reasoning means that, based on examination Selec-
tion for Bachelor alone, we can determine that the
sequence hOpenUI, SelectPB, SelectIM, SelectPMi
is not a possible sequence for Selection for Bache-
lorkSelection for Master, as hOpenUI, SelectPBi is
not a trace of Selection for Bachelor.
Local reasoning of this kind is an important in fa-
cilitating separate modeling of the parts of a software
system, and in retaining intellectual control overcom-
plexity as the model grows. This property of CSP
composition was established by Hoare in his work on
CSP (C. Hoare, 1985). However, Hoare did not con-
sider events with data or machines with derived states,
as are used by Protocol Machines. The full proof of
support for local reasoning for Protocol Machines can
be found in (A. McNeile, E. Roubtsova, 2008).
The Protocol Modeling approach makes it possible
make separate representations of parallel concerns
within an HCI model and use CSP for composition
of the parts. The use of CSP composition ensures
that the behavior of the PM component models is pre-
served in the result.
HCI models built using the PM approach are di-
rectly executable using a suitable tool. The key fea-
tures of such a tool are support for automatic com-
position of PMs, according to the CSP composition
rules. Protocol Modeling support is implemented in
the ModelScope tool (Metamaxim, 2006).
We thank Ad Slootmaker (Educational Technology
Expertise Center) and Evert van de Vrie (OU) for
sharing information about BaMaS.
A. Dix, G. Abowd, R. Bealle, J. Finlaj (1998). Human-
computer interaction. Prentice Hall Europe.
A. McNeile, E. Roubtsova (2008). CSP parallel composi-
tion of aspect models. To appear in the Proceedings of
the 12th International Workshop on Aspect-Oriented
Modelling, AOM 2008, Brussels, ACM DL.
A. McNeile, N. Simons (2006). Protocol Modelling.
A modelling approach that supports reusable behav-
ioural abstractions. Software and System Modeling,
BaMaS (2007). BaMaS.
C. Hoare (1985). Communicating Sequential Processes.
Prentice-Hall International.
D. Hix, H. Hartson (1998). Developing User Interfaces:
Ensuring Usability Through Product & Process. John
Wiley & Sons Inc.
J. Ebert, G. Engels (1994). Dynamic models and Behav-
ioural Views. LNCS 858.
Metamaxim (2006).
M.Tauber (1988). On Mental Models and the User Inter-
face. G. Van der Veer et al. ed. ”Working with Com-
puters: Theory Versus Outcome”.
P. Palanque, R. Bastide, L. Dourte, C. Sibertin-Blanc
(1993). Design of User-Driven Interfaces Using Petri
Nets and Objects. LNCS 685.
S. Payne, T. Green (2000). Usability Patterns for Applica-
tions on the World Wide Web. In D. Diaper ed. ”Task
Analysis for Human-Computer Interaction, Ellis Hor-
wood, Cambridge MA”.
ICEIS 2008 - International Conference on Enterprise Information Systems