Rochester Institute of Technology
RIT Scholar Works
Theses
Thesis/Dissertation Collections
1989
Statemaster: a user interface management system
based on statecharts
Pierre Wellner
Follow this and additional works at:
http://scholarworks.rit.edu/theses
This Thesis is brought to you for free and open access by the Thesis/Dissertation Collections at RIT Scholar Works. It has been accepted for inclusion
in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact
Recommended Citation
Statemaster: A User Interface Management System based
on
Statecharts
Pierre Wellner
February, 1989
Masters thesis, submitted
to
the RIT Department of Computer Science.
Approved by:
Professor John A. Biles
Dr. Acco Hengst
Abstract
Designing
andimplementing
a userinterface
(UI)
is
among the
costliesttasks
in
developing
interactive
software systems.As
aresult,
much workis
being
done
in
the
area ofUser Interface
Management Systems
(UIMSs).
These
systems make
it
easierto
develop
complex userinterfaces
morequickly
because
specification of userinterface dialogs is
at a closerlevel to that
atwhich
UI
designers
expressthemselves.
This
paperdescribes
the
generic structure of aUIMS
and several examples of previousworkin
the
field.
Many
UIMSs
areimplemented
as explicit state machinesthat
use conventionalstate
transition
diagrams
orstate metaphorsto specify
dialogs.
The
rest ofthis
paperdescribes
the
design
andimplementation
ofStatemaster,
an event-drivenUIMS based
on statecharts.Statecharts
are ahierarchical
extension of statediagrams
well suitedfor
describing
complexreactive systems with a
compact,
visual notation.These
diagrams
aredirectly
implemented
by
Statemaster
with an object-oriented architecturein
the
C++
programming
language. Statemaster
has
been
found
to
be
generalenough
to
implement
a wide range of userinterface
dialogs. It
canbe
used as aprototyping
tool
for
UI
development,
andit is
efficientenoughto
be
used asthe
final,
target-intent
implementation.
Keywords
Acknowledgements
The ideas
presentedin
this
paper were refinedthrough
numeroushelpful
discussions
withSteve
Dacek
andPaul
Wlodarczyk,
and asthe
first
real userof
Statemaster,
Linda
Isaacson
also provided valuablefeedback.
I
especially
thank
Linda
Malgeri
for her
many
suggestions andunfailing
support.The
Table
ofContents
Chapter
1
:Introduction
1
1.1
Difficulties
in
developing
userinterfaces
1
1.2
User
Interface Management Systems
2
1.3
Collaborative design
andthe
UI Engineer
2
Chapter
2:
Previous
work andbackground
4
2.1
Generic
structure of aUIMS
4
2.1.1
Code
anddata
objects5
2.1.2
Specification
time
system5
2.1.2.1
Graphics
andtext
editors6
2.1.2.2 Interaction
module editors6
2.1.2.3
Dialog
definition
editors6
2.1.3
Runtime
system7
2.2
State based
UIMSs
7
2.2.1
State
transition
diagrams
7
2.2.2
Newman's Reaction Handler
8
2.2.3 Drawbacks
ofstatetransition
diagrams
8
2.2.4
Wasserman's
system10
2.2.5
Jacob's
system10
2.2.6 Trillium
11
2.2.7 Dan
Bricklin's Demo II
program12
2.2.8 HyperCard
13
2.3
Statecharts
14
2.3.1
Grouping
14
2.3.2
Concurrency
15
2.3.3
Broadcasting
andconditionaltransitions
15
2.4 Object-oriented
programming
andC++
17
2.4.1
Classes
18
2.4.2
Constructors
18
2.4.3
Inheritance
18
Chapter 3
:Description
ofStatemaster
20
3.1
Goals
andFeatures
20
3.1.1
Run
arbitrary
dialogs
20
3.1.3
Single Implementation
22
3.2
How
to
useStatecharts
andStatemaster
23
3.2.1
States
23
3.2.2
XorGrouper
States
24
3.2.3
Events
25
3.2.4
AndGrouper
States
25
3.2.5 Actions
26
3.2.6
Behaviors
27
3.3
Implementation
ofStatemaster
30
3.3.1
The
specification-timesystem30
3.3.2
Run-time
system32
3.3.2.1
State
objects32
3.3.2.2
Transitions
34
3.3.2.3
Events
35
3.3.2.4
Actions
36
3.3.2.5
Behaviors
36
3.3.2.6 The dispatcher
37
3.3.2.7
The
mainloop
38
3.3.2.8 The
input
event queue38
3.3.2.9
Soft
Enlisting
-an alternative
implementation
. .39
3.3.3 Communication
with application software41
3.3.3.1
Layer 3
42
3.3.3.2
Layer 2
43
3.3.3.3
Layer 1
44
3.3.4 User-settable
defaults
andstart-up
system configuration45
3.4
Equipment
andTools
45
Chapter
4: Experience
withStatemaster
47
4.1
Graphics
47
4.2
Behaviors
47
4.3
Using
Statemaster
48
4.4
Example
Statemaster
dialog
49
Chapter
5:
Ideas
for
the
Future
ofStatemaster
andConclusion
50
5.1
Short
term
ideas
50
5.1.1
Minor
optimizations50
5.1.2
Include
files
50
5.1.4
A
library
ofC functions
51
5.1.5
Soft
enlisting
anddynamic
events51
5.1.6
Commands
51
5.2 Medium
term
ideas
52
5.2.1
Storable
&
retrievable objects52
5.2.2 Modular
interaction
techniques
52
5.2.3
Building
blocks
and container objects53
5.2.4
Implicit
linking
ofstateswith graphics54
5.2.5
Statechart
specificationtools
54
5.2.6
Translation
tools
54
5.2.7 Action
language
55
5.3
Long
term
ideas
56
5.3.1
Integrated
system vs. set oftools
56
5.3.2
The
centralizeddata
approach56
5.3.3
Managing
the
evolutionaUIMS
57
5.3.4
Metaphors
for
statecharts, actions,
behaviors
59
5.3.5
Use
statemasterto
implement its
ownspecificationtools
60
5.3.6
Undo
support60
5.3.7
Default
userinterface
60
5.3.8 User
tailorable
userinterfaces
60
5.3.9 Automatic
macrodetection
60
5.4
Conclusion
60
Appendix:
Example Statemaster
dialog
62
Chapter 1
:
Introduction
Designing
andimplementing
aneffectivegraphical userinterface
(UI)
is
oftenamong
the
largest
and costliesttasks in
developing
interactive
software systems.As
aresult,
many
systemstoday
have
poorly
developed
UIs,
andthey
aredifficult
to
understand orhard
to
use.To
make effective userinterfaces
easierto
create,
much effortis
being
directed
towards the
development
ofUser
Interface Management Systems
(UIMSs),
which offer powerful meansfor specifying
andmodifying
userinterfaces.
This
paperdescribes
severalUIMSs
and points outthat many
areimplemented
as state machines.Although
conventional statediagrams have
significantadvantages,
they
sufferfrom
drawbacks
that
makethem
impractical for
specification of complex user
interfaces. Statemaster is
based
on a graphical notation(Statecharts)
that
overcomesthese
drawbacks,
andit
canbe
usedboth
for
userinterface
prototyping
andtarget-intent
implementation.
1. 1 Difficulties
in
developing
userinterfaces
There
are no guidelines ordesign
elementsthat
can guarantee a userinterface
willbe learnable
andeasy to
use.Consequently,
the only
reliable methodfor
creating
quality
userinterfaces is
to test
prototypes with actual users andmodify the
design based
ontheir problems,
success,
andfeedback
[Myer87]. This
process ofiteratively designing, implementing,
testing
andredesigning
is
very time consuming
and expensive.The
problemis
compounded
by
the
fact
that in many
organizations,
the
people whodesign
the
dialog
and graphicsofthe UI
have
avery
different
setofskillsfrom
those
whoimplement
the UI
software.The
designers
arethe
experts on what people wantfrom
the
application andhow
they
wantto
performthe task.
They
think
in
words andpictures,
andtheir
notationstend to
be
informal.
The
implementors,
onthe
otherhand,
think
in terms
ofhow
the
machine can performthe task.
In
orderto
create aworking
system,
they
use preciseformal
This
situationis
very
similarto the
onethat
existedin
the
field
of expertsystems
in
the
nineteen seventies.Expert
systems wereimplemented
in
a generalprogramming
language
such asLISP,
andthe
domain
experthad
knowledge
that
could notbe
easily
expressedin
terms
offormal
rules.Knowledge
engineershad
to
bridge
the gap,
translating
the
domain
expert'sknowledge
into formal
specificationsthat
couldbe
implemented
ona machine.This
was adifficult
andtime consuming
task,
so a greatdeal
ofeffortwas putinto
the
development
of expert-systembuilding
tools
,whichbring
the
formal
specification of
knowledge
closerto the
level
at whichdomain
experts expressthemselves,
using
visual specificationlanguages
withrules, examples,
andobject
hierarchies [Wate86].
Many
classes of expert systems now canbe
developed in
afraction
ofthe time
and resourcesthat
were requiredin
the
seventies.1.2 User Interface Management Systems
Similarly,
to
reducethe
cost ofdeveloping
graphical userinterfaces,
UIMSs
have been developed for
making
userinterfaces
easierto
create and modify.As
with expert systembuilding
tools,
UIMSs
bring
the
specification of userinterface
dialogs
closerto the way
in
whichdesigners
expressthemselves.
UIMSs
provide a software architecturethat
is
general enoughfor
a range of userinterface dialogs
to
be implemented
withthe
same system.They
separatethe
userinterface
softwarefrom
the
application andoften provideit
with somehardware
independence.
The
goal ofthese
systems,
ofcourse,
is
to
shorten
the
design-implement-test cycle,
thus
facilitating
the
development
ofquality
userinterfaces.
1.3 Collaborative
design
andthe
UI Engineer
Design
andimplementation
of userinterfaces
atXerox
andin
other organizationsis done
by
teams
ratherthan
by
individuals.
Human
factors
(HF)
designers,
graphicartists,
and software engineers worktogether
ondialogs.
Organizational
issues
canplay
animportant
rolein
the
use of aUIMS [Bigh87].
Users
ofthe
UIMS
mustbe
ableto
share anddiscuss
UI
specifications withother members ofthe
team.
confirm or
deny
because
the
definition
ofprogramming
is
very
nebulous.Some
peoplefeel
that
using
a spreadsheetis
too
high
level
to
be
considered"programming,"
while others
feel that
"programming" skills are required evento
use a graphicseditor.At
Xerox,
for
example,
human
factors designers
do
nothave
the
programming
skills requiredto
develop
complete userinterfaces
using
currently
availableUIMSs.
They
may
use aUIMS
such asTrillium
orHyperCard
to
illustrate
components oftheir
designs,
but
ultimately their
designs
areimplemented
by
programmers.At
the
risk ofcreating
yet anotherjob
title,
the
people whoactually
implement
the
userinterfaces
couldbe
called"UI
Engineers"because
ofthe similarity
ofthis
job
to that
of aknowledge
engineer.A
knowledge
engineer mustimplement
adomain
expert'sknowledge
using
expert systembuilding
tools.
Similarly,
aUI
engineermustimplement
ahuman
factors designer's
dialog
using
aUIMS
[Bett87].
The
first
knowledge
engineers wereAl
programmers whoonly
learned
whatthey
had
to
aboutthe
domain
they
werebuilding
an expert systemfor.
Today,
knowledge
engineers oftenhave
a strongerbackground in
the
domain
ofthe
expertsystem
than
they
do
in
Al
programming.The
UI
Engineers
oftoday,
onthe
otherhand,
have
strongerbackgrounds
in programming
than
in
human
factors
design. UIMSs
are not yet atthe
point where ahuman
factors
designer
canimplement
his
orher
creativeideas for interactive
graphicaluserChapter 2: Previous
work and
background
The design for Statemaster has been
influenced
by
researchin
several areas.It is
most relatedto
previous workdone
withUIMSs,
especially those that
have
state-based architectures.Other
key
ideas
camefrom
Statecharts,
an enhanced graphical state-transitionnotation,
andfrom
object-orientedprogramming
languages.
This
chapterbegins
with adetailed
discussion
ofthe
generic structure of aUIMS;
then,
afterdiscussing
state machines andStatecharts,
it discusses
several examples of previousUIMSs
and object-oriented programming.2.1 Generic
structure of aUIMS
Most
existing
UIMSs have
acommonstructure,
whichis
illustrated
by
Figure
2.1.
The
systemsdescribed in
this
chapter are structuredin this
way,
althoughvery
different
approaches existfor
implementing
each ofthe
components.Specification-time
systemI
Code
&data
objects
I
__i
Output
Elements
Dialog
Definition
Interaction
Module
Library
Run-time
systemUser
Application
Software
I
Figure 2.1
All UIMSs have
a specification-time system and a run-timesystem,
althoughthey
are sometimes so wellintegrated
that
it is
hard
to
distinguish
them.
Specification
time
is
whenthe
userinterface is
formally
defined
by
the
designer
or software engineer.Run-time is
whenthe
userinterface
actually
responds
to
userinputs
andcommunicateswiththe
application software.2. 1. 1
Code
anddata
objectsThe
code anddata
objects are created at specificationtime,
andthe
runtimesystem uses
them
to
respondto the
user.These
code anddata
objects canbe
broken
up roughly
into
three
parts:the
outputelements,
the
interaction
module
library,
andthe
dialog
definition.
The
output elementstypically
are madeup
of graphics andtext
messages.They
may take the
form
oftext
files,
bitmap
arrays,
sounds,
melodies ordisplay
lists
that
draw
compleximages.
The
interaction
modulelibrary
implements
the
basic
techniques
by
whichthe
user
interface
interacts
withthe
user.An
example of aninteraction
modulemight
be
a simpletext-entry
facility,
a scrollbar,
or a graphicbutton.
Interaction
modulescanbe
implemented
athigh
orlow levels.
At
alow
level,
aninteraction
module mightimplement
no morethan
somedevice-specific
code.
At
ahigh
level,
aninteraction
module mightimplement
complexinput
techniques
with graphicfeedback
suchasscrollbars
orwindows.The
dialog
definition
is
sometimes referredto
asthe
"glue"
that ties the
otherpieces
together.
It determines how
interaction
modules referto
graphic ortextual
elements , andit
usually
determines
the
positions andlayout
ofthose
elements.
It
alsodetermines
what syntaxis
expectedfor
userentries,
andwhich
inputs
aremeaningful.2. 1.2 Specification
time
systemAt
specificationtime,
the
abovethree types
of code anddata
objects are2. 1.2. 1
Graphics
andtext
editorsEditing
the
output elementsis
usually
done
withtext
editors and graphicdesign
tools.
Object-oriented
graphicstools
like
MacDraw
arethe
mostusefulbecause
complexgraphicalinterfaces
aretypically
composedofobjectslike
fill
regions,
lines, bitmaps,
andtext.
The
graphicstools
also must compresstheir
outputsinto
encodeddata
structuresto
minimizethe
spacethey
take up
onthe
runtime system.2. 1.2.2 Interaction
module editorsInteraction
modules areusually
codedin
a conventionalprogramming
language for
maximumflexibility
and optimal performance.For
example,
if
acertain
kind
ofbutton
were neededin
the
interaction
modulelibrary,
the
programmer might write a program
using
aneditor,
C
compiler,
anddebugger.
The interaction
modules often canbe
modifiedonly
withprogramming
tools,
sothey
are moredifficult
to
changethan
otherpartsofthe
UIMS
and, consequently,
are often consideredfixed.
A fixed
library
has
the
advantagethat the
UI
willlook
and actconsistently
withothersbuilt
from
the
samelibrary. It has
the
disadvantage, however,
oflimiting
the
designer
to the
library's
primitives.The
interaction
modules are criticalin
determining
the
range and styles of userinterfaces
that
the
UIMS
canimplement.
If
a new style ofinteraction
is
desired,
then
sometimes new modules mustbe
addedto
the
library
by
aprogrammer.2. 1.2.3
Dialog
definition
editorsThe
dialog
definition
editororganizes or"glues"
interaction
modules and useroutputs
together
to
construct a userinterface.
It
allowsthe designer
to
try
different
layering,
organization, and syntaxto
see whatis
most effective.Dialog
definition
is
oftenthe
area whereiterative
design is
mostneeded,
soit
is
these
editorsthat
mostUIMSs
stress.Often the
dialog
definition
editors are meantto
be
usedby
non-programmers(i.e.
Trillium
andHyperCard
- see sections2.2.6
and2.2.8).
Sometimes
the
difference
between editing the
dialog
definition
andediting the
interaction
modulesis
fuzzy.
A
powerfuldialog
editor
may
be
ableto
constructhigh level
interaction
modules,
andthe
programming tools
usedfor
constructing
interaction
modules alsocanbe
usedto
constructdialogs. The
choiceis
determined
by
the
capabilities of eachtool
2.1.3 Runtime
systemThe
runtime system uses allthe
code anddata
objects createdby
the
specification system andactually
runsthe
userinterface
by
responding to
userinputs
andcommunicating
withthe
application software.The
runtime systemis
often used asaprototype,
whichlets
the
designer
try
his ideas
to
get afeeling
for
whatthe
interface
looks
like,
but is
not usedasthe
final
product.Many
UIMSs
areimplemented
withhigh
level dynamic languages [ie
Smalltalk
orLisp)
and run onhardware
with powerful processors andlarge
virtual memory.
Some
ofthese
features
may
be
impossible to
implement
onthe
cost constrainedtarget
hardware.
Consequently,
the
systemhas
to
be
reimplementedto
fit
withinmemory,
disk
andMIPS limitations.
Usually
the
target
runtime systemis
implemented
in
alanguage
more suitedto
low-level
control andefficiency,
and althoughtime
is
savedby
applying
experiences gainedfrom
prototyping,
the final
system must nevertheless gothrough
its
owndevelopment
cycle.2.2
State
based
UIMSs
Finite
state machines are usedin
theoretical
computer scienceto specify
andmodel
arbitrary
computations.Many
UIMSs
use explicit state machinesto
specify
dialogs because
they
are simple and general.2.2.
1
State
transition
diagrams
State
machines canbe
intuitively
representedby
statetransition
diagrams.
These
diagrams
are much easierto
understandthan textual
specifications.Three
properties of state transitiondiagrams
makethem
a good representationfor
userinterface
dialogs
[Jaco85]:
In
each statethey
make explicitthe interpretation
of all possible userinputs.
They
showhow
to
changeto
a state wherethe
interpretations
aredifferent.
They
emphasizethe time
sequences of userinputs
andsystemactions.State
transition
diagrams
provide a top-level point ofview onthe
dialog
that
2.2.2 Newman's Reaction
Handler
Newman's
"Reaction
Handler"[Newm68]
is
generally
consideredto
be
the
first UIMS.
It
was a systemfor
implementing
simple userinterfaces
from
conventional state
transition
diagrams.
The
example usedin
his
paperis
asystem
for
drawing
rubberband lines
with alight
pen.The
specificationfor
that
systemis
the
statediagram
illustrated
in Figure 2.2..
initial-state
button-press
button
-press
pen-movement
display
line
-~
select-starting-point
button-press
^P^
'store-starting-point
Figure
2.2
Specification
of rubberbanding
for Newman's
Reaction Handler
This
exampleillustrates
a state machinethat
respondsto
two
events:button-press and pen-movement.
The
system starts outin the initial-state
and abutton-press
brings it
to the
select-starting-point state.Here,
pen-movementdoes
not changethe
state ofthe
systembut
anotherbutton-press
causes atransition
to
rubberbanding
afterexecuting
the
store-starting-point action representedby
the
triangle.
In
rubberbanding
every
pen-movement executesthe display-line
action until anotherbutton-press,
whichbrings
the
systemback to the initial
-state.2.2.3 Drawbacks
of statetransitiondiagrams
Despite
alltheir
advantages, conventional statetransition
diagrams have
(a)
Conventional
statediagrams
are'flat.'
They
are not groupedto
providedepth,
hierarchy
ormodularity,
and,
therefore,
do
not supporttop-down
orbottom-up
development.
(b)
Conventional
statediagrams
are uneconomical whenit
comesto
transitions.
An
eventthat
causesthe
sametransition
from
alarge
numberof states must
be
attachedto
eachstate separately.(c)
Conventional
statediagrams
require exponential growthin
states asthe
system grows
linearly,
because
every
possible state mustbe
representedexplicitly.
(d)
Conventional
statediagrams
areinherently
sequential,
andcan noteasily
represent concurrent activities.
The
following dialog
design
statementsillustrate
the
type
ofthings that
aredifficult
to
representwith conventionalstatediagrams.
"Job
programming
consists ofthe
following
three
modes:basic
features,
added
features,
and expertapplications."
[difficult because
of(a)]
"No
matter whereyouarein the
userinterface,
pressing the
Reset icon
willbring bring
youback
to
the walkup
screen,
exceptif
you'rein
afault
[difficult
because
of(b)]
"While in
the
basic features
mode, the
number padis
active,
as arethe
following
columns: papersize,
copy
contrast,copy
output,
[difficult
because
of(d)]
Since
Newman's Reaction
Handler,
many
morestate-basedUIMSs have been
developed,
and mostattemptto
address some or all ofthese
drawbacks. The
following
sectionsdiscuss
systemsthat
attemptto
overcomethese
limitations
by
extending
statetransitiondiagrams
orby
abandoning transition
diagrams
altogether
in favor
of state metaphors.The
following
sectionsdescribe
Wasserman's
RAPID/USE
system andJacob's
visualprogramming
system,
both
ofwhich use statediagrams to
specify
userinterfaces.
Other
systems,
such as
Trillium,
Demo
n
andHyperCard
don't
use statetransition
diagrams,
but
instead
use ametaphorfor
states.Trillium
uses"frames,"
HyperCard
uses"cards,"
and
Demo II
uses2.2.4
Wasserman's
systemWasserman's
RAPID/USE
system[Wass85]
is
similarto
Newman's but
includes
a graphic editorfor specifying
statediagrams.
He found
that
in
using
his
system,
he
often neededto
createvery
large
and complexdiagrams
that
couldnot
be
easily
written or understood.This
often arosefrom
the
desire
to
specify
errorhandling
andhelp
facilities.
To
solvethis
problemhe
introduced
"subconversations"
as a means
for
onediagram
to
invoke
anotherdiagram
and represent
diagram
hierachies.
An
example of subconversationsin
the UI
ofan automated
teller
machineis
illustrated in Figure 2.3.
Figure 2.3
Use
ofsubconversationsin RAPID/USE
Each
ofthe
boxes
labeled <deposit>,
<withdrawal>,
and <balance> referto
separate statediagrams. These diagrams
musthave
a statelabeled
"exit,"
which makes
them
return controlto the
calling
diagram.
The RAPID/USE
system
is
currently
available as a productfrom
Interactive
Development
Environments.
It is
integrated
witharelationaldatabase
and a suite of othersoftware
engineering tools
that
canperformconsistency
checks and create anexecutableprototypeof
the
userinterface.
2.2. 5 Jacob
's
systemJacob's
system[Jaco85]
is
similarto
Wasserman's
in that
it
uses a graphic"subdiagrams,"
which are
essentially the
samething
asWasserman's
subconversations.
In
contrastto
Wasserman's
system,
however,
he
provides away
ofspecifying concurrency
through the
use of "codiagrams."When
diagram
A
makes a codiagramcallto
diagram
B,
then
diagram
B
is
entered atthe
statefrom
whichB
last
executed a codiagram call.B is
then
traversed
until
it
makes another codiagram call.If B
callsA,
for
example, then
A
would resume executionfrom
the
point whereit had
calledB.
Although
this
approach
does
provide away
ofspecifying
concurrency,
it
does
not seemto
indicate
the concurrency
in
a clear visualway,
andhis
paperdoes
notillustrate
whatcodiagramcallslook
like.
2.2.6 Trillium
Trillium
[Hend86]
originally
wasdeveloped
atXerox
for
designing
hard
userinterface
panelsfor
copiers.Its
dialog
definition
editorsdo
not use statetransition
diagrams,
but
they
do
allowthe
designer
to
placeitems
such asbuttons, icons,
light bars
anddials
onthe
screen.All
the
genericUIMS
components are
very
wellintegrated.
The
specification-time and run-time modules are almostindistinguishable,
allowing the
designer
to
immediately
run,
suspend,
and edithis
orher interface
atany time.
Trillium's
interaction
modules are calleditemtypes
and areimplemented in Interlisp.
They
have
been
extendedfar beyond
their
original set ofhard
panelcontrols,
and nowTrillium
is
usedinside
and outside ofXerox to
prototype avariety
ofscreenbased
graphical userinterfaces.
A
dialog
is
constructedin
Trillium
by
placing
itemtypes
and artwork ontoInterfaces, Frames,
andSuperframes.
The
structure ofTrillium
dialogs
has
much
in
common with a state machine.Each
frame
canbe
thought
of as astate,
and"frame
changes"
are
like
statetransitions.
Several
frames
cancontain
the
sameSuperframe
to specify
grouping,
and aframe
can contain severalsimultaneously
active superframesto specify
concurrency.A large
part ofthe
effortthat
goesinto
implementing
aTrillium
prototypecannot
be
us,edin
the target implementation
if it
runs ondifferent hardware
because
Interlisp
codeis
noteasily
portedto
embedded systems.The
codeAnother
problem withTrillium
is
that
it has
inadequate
facilities
for
presenting
the
overall structure of a complexdialog.
The
only way to
understand
how
adialog
is
puttogether
is
to
examineevery
frame
to
see whatsuperframes
it
pointsto
and alsoto
examinethe
"change
frame"buttons,
which execute state
transitions.
This is because
Trillium
does
not provideany
visual representation of
its dialogs.
One
reasonfor
this
is
that the
"superframe"
relationship
is difficult
to
representin
a compact visualway
that
preservesthe
properties ofgrouping
and concurrency.2.2.7 Dan Bricklin's
Demo
II
programDemo
II
is
aPC-based
tool
meantfor
prototyping
PC
applications,
demonstrations,
andtutorials.
[Bric87]
Demo
II
dialogs
are"slide
shows," and
a
"slide"
is
the
metaphorfor
a state.There
aretwo types
of slides:text
andbitmapped,
andeach slidefills
the
entire screen.Special
editors areincluded
for
designing
the
appearance ofslides.Text
slidescanbe
overlayedto
allowdisplaying
ofseveralslides at once.The bottom
slideis
the
"background," andoverlayed slides can
be
partially transparent to
allowlower
slidesto
showthrough. Each
slide pointsto
alist
of event-actionpairs,
which arecalledthe
Run
Actions.
The View
Slide
action performs a statetransition to
anotherslide.
Most
ofthe
other actions arefor
creating interaction
modules andprovide a general purpose
programming
language.
The
runtime systempasses each user event
to
the
activeslide,
andthe
slide executesthe
actionassociated with
that
event.If the
slidedoes
nothave
that
eventin
its
Run
Actions,
it
canoptionally
passthe
eventto
another slide.Otherwise,
the
"Global Run
Actions"aresearched.Demo
II
is
an event-driven state machinebased
onslides,
andit
addressessome of
the
drawbacks
ofconventionalstatediagrams
by
providing
grouping,
but
it
doesn't
provideconcurrency.Grouping
in Demo II
is
done
withthe
Use
action.
A
set ofslidesthat
mustbe
grouped all canhave
adefault
actionto
Use
the
same slide.Grouping
the
slidesvisually
is
alsoeasy
withDemo IPs
overlay
mechanism.Specifying
concurrency
is
not muchbetter
than
with conventionalstatediagrams,
however. The
best
the
designer
cando
is
link
allthe
concurrentstatesby
a chain ofUse
actions.This
will work when a singleslide
in
the
group
needs eachevent,
but it
will not work when several slidesUnlike
Trillium,
Demo
II
clearly
separatesthe
specificationtime
systemfrom
the
runtime system.In
fact,
the
runtime system canbe
separated anddistributed
without royalties.Unfortunately,
the
systemis
completely
dependent
onthe
IBM
PC's
text
screenarchitecture,
andits
usefulnessis
limited
to
PC-compatible
text
screenhardware.
As
with mostUIMSs it is difficult
for
the
designer
to
get atop-level
or globalpoint of viewof
his
design
withDemo II.
The
designer
can seeonly
one slide ata
time
and must edit a slideto
see whatit is
connectedto. With
smalldesigns
this
does
not present aproblem,
but
asthe
userinterface
grows morecomplex,
it
becomes difficult
to track
which slides are usedby
which,
and whatthe
overall structure of
the
interface
is.
2.2.8
HyperCard
HyperCard
[Good87]
runs onthe
Macintosh
and,
like
Trillium,
is
graphics-based
andhas
completely
integrated
specification and runtime
systems.It
has
excellentbuilt-in
graphicseditors,
andit
allowsthe
designer
to
edit aspecification and
immediately
run and suspendit. HyperCard
is
also astate-based
system,
andits
metaphorfor
a stateis
the
"card."Consequently,
the
user
interface is
called a"stack."
State
transitions
aredone
with "links"between
cards.Usually
links
areinvoked
by
"buttons,"
whichare
simply
icons
that
execute an action when clicked onby
the
mouse.A
usefulfeature
ofHyperCard
is
that
link buttons
canbe
specifiedby
example.For
more complexactions ageneralpurpose
language is
providedcalledHypertalk,
which allows aprogrammerto
code"scripts."
HyperCard
events are passedto the
current card.If that
carddoes
nothave
ascript associated with
the
event, then
it is
passedto the
background
card.If
the
background
card can'thandle
the
eventit
goesto the
stack.Grouping
in
HyperCard,
therefore,
is
done
by
putting
several cards onthe
same
background.
Only
onebackground
is
active at atime,
so a card with abackground
cannotbe
the background to
an other card.This
meansthat
groupings cannot
be
nestedmorethan
onelevel
deep.
Concurrency
is
notreally
possiblein
HyperCard
either.Several
buttons
cangiven event.
It is
notpossiblefor
several cardssharing
the
samebackground
to
be
activeatthe
sametime.
HyperCard is
fast,
intuitive
andsimpleto use,
andit includes
a generalforms
package,
withfast
search and retrieve capabilities.The
systemis
inherently
based
on abutton based
style ofinteraction. This
decision
wasprobably
madein
orderto
keep
the
system simple and consistent withMac
users'
expectations,
but HyperCard's
dialog
modeldoes
not seemto
work wellfor
more general userinterfaces.
Allowing
concurrent responsesto
non windowbased
eventsis
difficult,
anddialog
hierarchies
deeper
than
afew
levels
cannot
be
specified.HyperCard
also suffersfrom
the
lack
of atop-level
visual representation ofdialog
structure,
making
it
difficult
to
navigatethrough
large
stacks.2.3 Statecharts
Statecharts
[Hare87aJ
are a graphical notationthat
extends conventionalstate
transition
diagrams
to
overcometheir
drawbacks
whilepreserving
all oftheir
benefits. Although
not usedby
any
UIMSs,
the
notationhas
been
usedto specify
state-of-the-art avionics systems atthe Israel
Aircraft
Industries,
and
it is
usedby
a softwareengineering
product(STATEMATE
by i-Logix,
Inc.)
for
designing
complexrealtimesoftware andhardware
systems.The
two
most
important
additionsthat
Statecharts
bring
to
statediagrams
aregrouping
andconcurrency.2.3.1
Grouping
If
several stateshave
identical
transitions triggered
by
the
sameevent, then
those
statescanbe
groupedin
Statecharts,
and asingletransition
is
specifiedfrom
the group instead.
In
Figure
2.4,
there
is
a switchthat
toggles
between
statesA
andB.
When
event
g
occurs,
poweris
turned
offto the
switch andit
becomes
inactive,
whether
it
wasin
stateA
orB.
Event
h
returns powerto the
switch.In the
v statecharts representation,
State D is
an
XorGrouper
containing
A
andB.
This
meansthat
being
in
stateD
is
the
same asbeing
eitherin
stateA
orB,
but
notboth. The little
arrowpointing
to
B
showsthe
default
state(off)
that
is
Conventional diagram
Statechart diagram
Figure
2.4
Grouping
in
statechartshave
in
common.From
the top-down
pointofview,
A
andB
canbe
thought
of as a refinement ofD.
This
capability
ofgrouping
states,
when appliedhierarchically
to
large
collections ofstates,
can eliminate a greatdeal
of explicit statetransitions
and make statediagrams
mucheasierto
understand.This
approachis
simpler and morevisually
intuitive
than
the
"subconversation"approach used
by
Wasserman
andJacobs.
2.3.2
Concurrency
When
several small state machines are active atthe
sametime,
the total
number of possible statesis
the
product ofthe
number of statesin
each machine.A
Statechart
representation ofthis
case usesAndGrouper
states,
making
it
growlinearly
while conventional state representations grow exponentially.Figure
2.5
illustrates
two
toggle
switches,
both
of which are active atthe
sametime.
When
eventp
occurs,
both become
inactive.
In
Statecharts,
State
Y
is
an
AndGrouper.
Being
in
stateY
is
the the
same asbeing
in both F
andG
atthe
sametime,
whereboth F
andG
areXorGroupers.
Compared
to
Jacob's
means ofspecifying
concurrency,this
approachis
much morevisually
intuitive,
andit
works as a simple extension ofthe
grouping
principledescribed
above.2.3.3
Broadcasting
andconditionaltransitions
Statecharts
canbe
made evenmoreflexible flexible
by
adding the
concepts ofConventional diagrams
_9 .
Statecharts
diagrams
YAND
Figure
2.5
Concurrency
in
Statecharts
used
in
the
context ofconventional statediagrams,
andthey
provide a goodway to
specify
what are sometimes referredto
as"implications
andconstraints."
upA
A-On
r
\
downA
->Broadcast(upB)
upB
B-On
downB
lf(ln(A-On))
A-Off
Switch A
B-Off
Switch B
D
Figure2.6
State
Transition
Diagrams
An implication
is
whenan actionin
the
userinterface has
an additional effectin
another,
separate part ofthe
interface.
This is
representedby
tying
anadditional action
to
a statetransition.
For
example,
in
Figure
2.6,
assumethat the
eventdownA
turns
offswitchA
andthat this
mustautomatically
turn
on switchB if
it is
off.The
transition
for
turning
offA
must executethe
had
actually occurred,
soany transitions
that
depend
onthat
event willbe
executed.
A
constraintis
when an actionin
the
userinterface
canonly
occur undercertain conditions.
This
canbe
specified with statetransition
diagrams
by
using
conditionaltransitions.
Let
ussay that in the
above example switchB
is
constrainedto stay
on aslong
asA
is
off.A
condition wouldbe
addedto the
transition
from
B-On
to
B-Off. Unless
the
value ofIn(A-On)
is
true,
then
stateB-Off
cannotbe
entered.The ideal
UIMS
shouldbe based
on a representationthat effectively
represents
the
cognitive structure of userinterface
dialogs.
In
otherwords,
it
should
accurately
reflectthe
constructsthat
designers
and userskeep
in
mindwhen
thinking
aboutthe
system.This
paperis based
onthe
idea
that
statecharts
is
a good representation ofthis
cognitive structure.Statemaster
implements dialogs
in
terms
of statechartsin
the
hopes
that
this
representation will make user
interfaces
easierto create,
understand and modify.2.4
Object-oriented
programming
andC+
+Statemaster
is
alsobased ideas from
object-orientedprogramming
languages.
These
languages
provide apowerfulprogramming
paradigmthat
encouragesmodularity
andthe
reuse ofexisting
code.They
arewidely
usedin
programming
expertsystems,
andthey
facilitate
the
development
ofeffectivegraphic user
interfaces.
Although
object-orientedlanguages
areprimarily
tools,
their
features benefit
non-programmerdesigners
as well.Both
HyperCard
andTrillium
areobject-oriented,
andStatemaster
is
implemented in
C++,
arelatively
new object-orientedprogramming
language.
C
+ +
is
a general purposelanguage
designed
by
Bjarne
Stroustrup
atAT&T
Bell Laboratories [Stro86].
It is
a supersetofC
that
retainsthe efficiency
ofC
while
providing strong
type-checking
andfacilities for
object-orientedprogramming.
Programs in
C
+ +
tend to
be
shorter,
easierto understand,
andeasier
to
maintainthan
equivalent programsin
C. Some
ofthe
features
of2.4.7
Classes
Classes
providedata
abstraction,
whichis
the
separation of adata
object'srepresentation
from how
it
is
used.A
familiar
example ofdata
abstraction
is
how
the
department
ofmotorvehiclesinterfaces
to the
outside world.When
a car owner needsto
find
out someinformation
about
his driver's
license,
he
does
not walkinto
the
DMV,
openup
afiling
cabinet ,find his
record ofconvictions and
copy
it
into
his
notebook.Instead,
he
mustfill
out aform,
or call a certain phone number.If
the
DMV
becomes
computerized or changestheir computers, the telephone
number andform
stay the
same.No
onebesides
DMV
employeesneedto
know
aboutthe
change.The
C
built-in
type
float
worksin the
same way.All
a programmer needsto
know
about afloat
objectis
how
to
useit.
Two
floats
canbe
addedtogether
withoutconcernfor how
they
are representedinternally
.With
C
+ +
,the
programmer can createhis
own classesto
providedata
abstraction.To do
this
he
specifiesthe internal
representationfor
a class andthe
operationsthat
canbe
performed onit.
The
classthen
becomes
a programmerdefined
type,
andany
other part ofthe
program can useit in
the
same
way that
it
uses abuilt
in
type
without concernfor how it is
implemented. The C++
translator
signals a syntax error when aninstance
of a classis
not used properly.If
the
implementation
ofthe
class needsto
changethen
all changes canbe limited
to the
class codeitself. The
restofthe
systemcan remain unchangedas
long
asthe
interfaces
are maintained.2.4.2 Constructors
Constructors
provide guaranteedinitialization
ofclass objects.Declaring
an object guaranteesthat
its
constructor willbe
calledbefore it is
ever used.When
an object goes out ofscope,
it is
implicitly
destroyed
with a callto
its
destructor. Constructors
anddestructors
savethe
programmerfrom
having
to
explicitly
allocatememory,
setinitial
values,
and cleanup
afterwards.Forgetting
to to
do
these
things
atthe
righttime
is
oftenthe
cause ofterribly
annoying
bugs.
2.4.3 Inheritance
The derived
class can redefine some ofits
parent'sfunctions,
andit
canaddits
own
data
structures.These
redefinedfunctions
are called"virtual
functions."
A
virtualfunction
implicitly
checksthe
objecttype
anddetermines
atruntimewhich redefined
function
mustbe
called.Let
ussay
for
example,
that
a programmer needed severalkinds
of classesthat
he
candisplay:
Button, Folder, Clock,
andWindow.
With
inheritance,
the
programmer canimplement
adifferent
DisplayO
function
for
each class,and
let
them
allinherit
from
the
base
classDisplayableObject.
If
alist
ofDisplayableObjects
needsto
be
putup
onthe
screen,
the
programmer cansimply
tell
eachobjectto
DisplayO
itself
andlet it figure
outspecifically
whichC
function
needsto
be
executed.Similarly,
there
may
be
severalkinds
ofButtons,
each of whichlooks
slightly
different
but has
some propertiesin
common with regular
Buttons.
Inheritance
canbe
usedto
define
aSpecializedButton
class.This
class can reusethe
codefrom
the
regularChapter 3
:Description
of
Statemaster
This
chapterbegins
with abrief
description
ofthe
goals andfeatures
ofStatemaster,
then
it describes
how
to
useStatemaster
anddescribes
its
implementation
.3.
1 Goals
andFeatures
Figure
3.1
illustrates
the three primary
goalsthat
Statemaster
attemptsto
achieve.
Arrows
pointto the
features
that
respondto those
goals.Goals
Features
Run
arbitrary
dialogs
Not
limited
to
specificapplications or user
input devices.
Allow
quick prototypinIterative
dialog
design.
Single
Implementation
Target
system uses*"
the
same code asthe
prototype.
Based
onStatecharts
General
purposesoftwarespecification.
Conceptual-level
specification
Data-driven
Minimal coding
andrecompiling.
I/O independent
nput
Device
Independent.
Graphics Independent.
Application Independent.
OS
Independent.
Hardware
Independent.
Target-intent
performanceFigure 3.1
Goals
andFeatures
ofStatemaster
3.
1. 1 Run arbitrary dialogs
The
system mustbe
ableto
implement
avery
wide range ofdialogs.
Some
examples
include:
Simple
command-line text-baseddialogs
usedby
trained
copier vservicerepresentatives.
Cascade-based
graphicaldialogs
that
respondto
hard
button
pressesby
Touch-based
dialogs
withdozens
ofsimultaneously
active screen segmentsthat
individually
respondto
inputs.
Highly
interactive image
editing
dialogs
that
acceptinput
from
multipledevices.
Mouse
andmenu-baseddialogs
running
on graphic workstationsthat
usewindowsand
pop-up
menus.The
wide range ofdialogs
to
be
supported requires a specificationtechnique
that
is
general and ableto
describe large
and complex systems.Statecharts
have
been
shownto
be
capable ofdescribing
complex avionicssystems,
andthey
are usedby STATEMATE,
a commercial softwareengineering
productfor
designing
realtime systems.The
otherfeature
that
enablesStatemaster
to
be
usedfor
arbitrary
dialogs
is
its
I/O
independence.
It
does
not assumeany
specific means ofdisplaying
graphics
(e.g.
Xwindows
orNews);
it
does
not requireinput
from
any
specificdevices
(e.g.
touch
orhard
buttons),
andit does
not assumeany
specificapplication
(e.g.
copierorimage
editing).All input
and outputto
Statemaster
is
done
through
awelldefined,
layered
communicationsprotocol similarto
the
ISO
referencemodel[Tane81]. To interface Statemaster
with anI/O
device
orapplication
software,
one choosesthe
most appropriatelevel
of communicationand
implements
adriver for
that
level.
The
rest ofthe
code remainsunchanged.
3.1
.2Allow
quickprototyping
Any
general purposeprogramming
language like
C
orC++
wouldbe
adequate
for
implementing
dialogs if
generality
werethe only
goal.In
orderto
allow quickprototyping,however,
the
specification mustbe
at a conceptuallevel,
closeto the way
in
whichdesigners
expressthemselves.
Statecharts
aremuch closer
to
this level
than
any
general purposeprogramming
language.
Furthermore,
Statecharts
naturally
createsbuilding
blocks
through
its
grouping
mechanism.Using
these
building
blocks,
the
designer
panspecify
dialogs
at ahigh level
orat alow-level,
then
group
andlink
them
together.
Statemaster
canbe
used as aprototyping tool
only
by
someone withprogramming
skills.This
personmightbe
calleda"UI
Engineer,"
because
ofthe
similarity
between
this
job
andthat
ofa"Knowledge
Engineer."
implementing
anexpertsystem, the
knowledge
engineer mustimplement
the
domain
expert'sknowledge
using
an expert systembuilding
tool.
Similarly,
the
UI
Engineer
mustimplement
the
HF
designer's
dialog
using
Statemaster,
and
he
or she shouldhave
someunderstanding
ofboth
the
domain
(UI
design
in
this
case),
andthe
implementation.
3.
1.3 Single Implementation
Many
UIMSs
generate a runtime prototypethat
cannotbe
used asthe target
implementation.
The
two
separate runtimeimplementations
arenecessary
because
the
UIMS
oftendepends
onfeatures
ofits
native environmentthat
cannot
be
easily
implemented
on cost constrainedtarget
hardware.
The
two
systems are often programmedin
different languages
andhave
very
different
software architectures eventhough
they
aresuperficially
alike.They
have
different bugs
anddifferent
performance.The
target implementation
must gothrough
its
owndevelopment
cycle,
whichis
partially
redundantto
that
ofthe
prototype.
Statemaster
canbe
usedboth
for
prototyping
andfor
the
target
implementation.
The
singleimplementation
savesdevelopment
time
andmakes
the
prototype more accuratein terms
ofbehavior
and responsetime.
The
primary
meansby
whichit
accomplishesthis
goalis
through
hardware
independence.
It is implemented
in
C++,
which canbe
portedto any
processor with a
C
compilerand providesthe
low-level
control andefficiency
ofC.
Statemaster
does
notdepend
on specialfeatures
ofany
particularoperating
system(e.g. UNIX
orMSDOS),
andit
does
notdepend
on virtualmemory
or garbage collection.As
aprototype,
it is
ableto
run on aPC
or workstationlong
before
the target
hardware
has
been
built
or evendesigned.
3.2
How
to
useStatecharts
andStatemaster
The
statechartsthat
Statemaster
usesto
represent userinterface
dialogs
arebased
onDavid Harel's
statecharts,
but
they
have
been
adaptedto
moreeasily
specify
userinterface dialogs.
The statecharting
conventionsdescribed in
this
section
have
been
usedsuccessfully
by
UI
engineersto specify working
Statemaster dialogs.
The
three
fundamental
components of statecharts areStates, Events,
andActions. Behaviors
are madeup
ofEvent
-Action
pairs.
3.2.1
States
Each
staterepresentsa specific configurationofthe UI
at a pointin time.
The
entire
UI
dialog
is
representedby
a state machinethat
is
composed of acollection of
states,
only
some of which are active atany
given moment.As
the
user andthe
applicationinteract
withthe
dialog,
the currently
activestates change.
It
is important
to
distinguish
States
from Bitmaps.
Many
stateshave
specificbitmaps
associated withthem,
and whenever oneofthese
statesis
active,
its
bitmap
appears onthe
screen.A
state andits
bitmap
are notthe
same,
however.
A
single statemay
use severaldifferent
bitmaps,
andthe
systemcanchange states without
changing
bitmaps.
A
State
is
representedin
Statecharts
by
abox
with roundedcorners,
asillustrated in
Figure3.2.
The
name ofthe
state appearsinside
the
box
or onthe
box's
upper edge.The
state nameis
alwaysin lower
case.If
the
nameis
composed ofseveral
words, then
they
arejoined
by
underscores..
f
an other statestate
**_
Figure
3.2
Simple
statesIn
Statecharts
there
arethree
different
kinds
of states: simplestates,
AndGrouper
states,
andXorGrouper
states.AndGroupers
andXorGroupers
3.2.2
XorGrouper
States
When
anXorGrouper
stateis
active,
one andonly
one ofits
childrenis
active.The
Xor
relationship determines
that
if
one child statebecomes
active,
then
all other children
become inactive.
XorGroupers
look
like
simplestates,
except
that
they
have
child statesinside,
andthey
have
XOR
following
their
names.
r
paper
supply
selectorXOR
(
trayl
E PAPER
SUPPLY
E PAPER SUPPLYtray2
E PAPER SUPPLY
automatic
Figure 3.3
An
XorGrouper
stateFigure 3.3
shows a statechartfor
the
papersupply
selectorfor
a copiermachine.
The
papersupply
selector stateis
anXorGrouper
withthree
child states.
That
meansthe
selector canbe
in
one ofthree
positions,
but
it
cannot
be in
morethan
one position at atime.
The
default
arrow pointsto
automatic,
meaning that
when papersupply
selectoris
enteredfor
the
first
time the
automatic state willbe
enteredinstead
of one ofthe
othertwo
child3.2.3 Events
Events
areusually
inputs
to
Statemaster.
An
Event
canbe
causedby
the
user, the
application,
or statemasteritself.
The
papersupply
selectorin
Figure
3.3
respondsto only
one event:E_PAPER_SUPPLY.
It
couldbe
generatedwhen
the
user presses abutt