CH1'83 Proceedings
December 1983
Executable Specifications for a Human-Computer
Interface
Robert J.K. Jacob
Naval Research Laboratory
Washington, D.C. 20375
It is useful to be able to specify a proposed h u m a n - c o m p u t e r interface formally
before building it, particularly if a m o c k u p suitable for testing can be obtained directly
from the specification. A specification technique for user interfaces, based on state
transition diagrams, is introduced and then demonstrated for a secure message syst e m application. A n interpreter that executes the resulting specification ~s then
described. S o m e problems that arise in specifying a user interface are addressed by
particular features of the technique: To reduce the complexity of the developer's task,
a user interface is divided into the semantic, syntactic, and lexical levels, and a
separate executable specification is provided for each. A process of stepwise
refinement of the syntactic specification, leading from an informal specification to an
executable one is also presented. Since the state diagram notation is based on a nondeterministic model, constraints necessary to realize the system with a deterministic
interpreter are given.
Writing a formal specification of the user
interface of a c o m p u t e r system before building
it permits the interface designer to consider a
variety of possible user interfaces and describe
t h e m precisely and compactly without actually
having to code them. It also permits the application of h u m a n performance models to the
specifications to obtain information about the
user interfaces they describe before building
t h e m [1, 15]. The specifications can be checked
for certain undesirable properties of the user
interface, such as almost-alike states [14],
interactive deadlock [4], and character-level
ambiguity [18]. Further benefits accrue if a prototype or m o c k u p of the user interface of the
proposed system can be constructed directly
from the specification. Problems with the proposed user interface can then be identified early
in the design process, w h e n they are easier to
fix. While m a n y prcspective users will f_nd a formal specification of a proposed system difficult
to understand, they will have m u c h less trouble
evaluating a m o c k u p system and identifying
deficiencies in its user interface, both through
informal demonstrations and formal experi-
ments.
This paper describes a specification technique for user-computer interfaces and its use
in the development of a secure military message
system. The specifications are executed interpretively to provide a working prototype of the
system. The paper describes the specification
technique by m e a n s of an example. Then, it
shows the decomposition of both the design process and the specification itself into the semantic, syntactic, and lexical levels and describes
how stepwise ref.nement can be used at the syntactic level. The constraints on the specification
necessary for a system to be realized with a
deterministic interpreter are given, and the
implementation of the interpreter is described.
Overview
Permission to copy without fee all or part of this material is granted
provided that the copies are not made or distributed for direct
commercial advantage, the ACM copyright notice and the title of the
publication and its date appear, and notice is given that copying is by
permission of the Association for Computing Machinery. To copy
otherwise, or to republish, requires a fee and/or specific permission.
©
1983 ACM 0'89791-121-0/83/012/0028
$00.75
of the
Speci~t.ion
Technique
Time s e q u e n c e is a n i m p o r t a n t a s p e c t of
the surface structure of an interactive system
as seen by a user. Specifications based on state
transition diagrams are most suitable for
describing interactive h u m a n - c o m p u t e r interfaces largely because they represent time
sequence explicitly, in contrast to BNF, in partitular, where it is implicit [12]. The state transition model has also been found useful in
describing a user's mental model of an interactive computer system [4, IS]. Several investigators have proposed different specification nora-
28
CH1'83 Proceedings
December 1983
t i o n s b a s e d on s t a t e
transition diagrams
[2, 3, 5, 6, 14, 17, 20]. E a c h p r o v i d e s s o m e unique
b e n e f i t s b u t also h a s s o m e d i s a d v a n t a g e s [10].
Only a few a r e s u f f i c i e n t l y f o r m a l o r c o m p l e t e to
b e e x e c u t e d d i r e c t l y , a n d fewer still h a v e i n t e r p r e t e r s [5, 19].
The p r e s e n t t e c h n i q u e is b a s e d o n t h e s t a t e
t r a n s i t i o n d i a g r a m s i n t r o d u c e d in [12] a n d h a s
b e e n r e f i n e d b a s e d o n e x p e r i e n c e a p p l y i n g it to
a m e s s a g e s y s t e m . It is a n a t t e m p t to s y n t h e s i z e t h e m o s t useful f e a t u r e s of p r e v i o u s
n o t a t i o n s a n d to p e r m i t a n i n t e r p r e t e r to exec u t e t h e specification. Using this a p p r o a c h , a
w o r k i n g p r o t o t y p e of a r e c e i v e - o n l y s e c u r e military message system has been specified and
c o n s t r u c t e d as one m e m b e r of a f a m i l y of p r o t o t y p e s built in t h e S e c u r e Military M e s s a g e Syst e m s p r o j e c t a t t h e Naval R e s e a r c h L a b o r a t o r y .
E x p e r i e n c e with t h e p r o t o t y p e h a s s h o w n t h a t
t h e d e s i g n of the u s e r i n t e r f a c e is c r i t i c a l in a
m u l t i - l e v e l - s e c u r e s y s t e m , b o t h to e n s u r e t h a t
t h e u s e r m a i n t a i n s t h e s e c u r i t y of t h e s y s t e m
a n d to p r e v e n t s e c u r i t y c o n s i d e r a t i o n s f r o m
h a m p e r i n g t h e p r o g r e s s of his o r h e r work.
I l ~ u r e I. Specification of the prototype message system syntax-first diagram.
o L O G N A M E display an e m p t y login template and
a prompt for the user's name, respectively, and
are described in a separate lexical-level
specification in the s a m e notation, iQDIT and
i L O G O U T are input tokens whose internal details
are
also
described
in the
lexical-level
specification, login is a nonterminal consisting
of the entire log-in sequence; its definition is not
shown here, but it does have two possible exits,
depending on whether the user entered valid
login data. The setup nonterminal initializes a
user session and displays incoming messages.
The e m d n o n t e r m i n a l d e s c r i b e s t h e u s e r c o m m a n d s a n d is given below.
When t h e s y s t e m is s t a r t e d , t h e login t e m plate and then the prompt for the user's name
a r e d i s p l a y e d . The u s e r c a n t h e n a t t e m p t to log
in or e l s e e n t e r a q u i t c o m m a n d to exit f r o m t h e
system entirely. If the login is successful, the
user is prompted for a c o m m a n d , or he m a y log
out. After each c o m m a n d other than logout, a
fresh c o m m a n d template (oCMD) is displayed,
and the user is prompted ( o C M D N A U E ) to enter
another c o m m a n d name.
Text form. This s a m e diagram can be
represented in text form, as shown in Figure 2.
The diagram in this form is the actual input to
t h e i n t e r p r e t e r , as well as t o t h e p r o g r a m t h a t
p r o d u c e d F i g u r e 1. E a c h d i a g r a m begins with a
h e a d e r line t h a t gives t h e n a m e of t h e d i a g r a m
(This is t h e n a m e b y w h i c h it could be called as a
nonterminal from another diagram.) and the
n a m e ( s ) cf its exit s t a t e ( s ) . Then, e a c h t r a n s i t i o n is l i s t e d in a line of t h e f o r m :
st:
oLOGIN -~prornptlog
I}etsils a n d E x a m p l e of t h e S p e c i f i c a t i o n T e c h nique
To d e s c r i b e t h e t e c h n i q u e , c o n s i d e r a s e c t i o n of t h e s y n t a x p o r t i o n of t h e e x e c u t a b l e
s p e c i f i c a t i o n of t h e p r o t o t y p e m e s s a g e s y s t e m ,
as s h o w n in F i g u r e 1. (The full e x e c u t a b l e
s p e c i f i c a t i o n is g i v e n in [11].) E a c h s t a t e is
r e p r e s e n t e d as a circle. The s t a r t s t a t e is t h e
one at t h e left side of t h e d i a g r a m ; t h e e n d s t a t e
(or s t a t e s ) is n a m e d inside its circle. E a c h t r a n s i t i o n b e t w e e n two s t a t e s is s h o w n as a d i r e c t e d
arc. It m a y be l a b e l e d with o n e or m o r e of t h e
following:
• The n a m e of a n i n p u t t o k e n (which b e g i n s with
i followed by a n a m e in u p p e r c a s e , like iQU1T)
• Art o u t p u t t o k e n (o followed by u p p e r c a s e , like
N.,0G~Auz)
• A n o n t e r m i n a l (in all lower c a s e , like login),
w h i c h is defined b y a s e p a r a t e d i a g r a m t h a t is
c a l l e d like a s u b r o u t i n e a n d m u s t b e t r a v e r s e d
f r o m s t a r t to e n d to c o m p l e t e t h i s t r a n s i t i o n
• A condition, w h i c h m a y m a k e a r b i t r a r y t e s t s
on e x t e r n a l v a r i a b l e s a n d m u s t be t r u e for this
t r a n s i t i o n to b e t a k e n ( t e s t r s t , shown h e r e , is
a s p e c i a l t y p e of c o n d i t i o n t h a t e x a m i n e s t h e
s t a t e t h r o u g h w h i c h a called n o n t e r m i n a l
d i a g r a m with s e v e r a l e x i t s r e t u r n e d )
denoting a transition from state st to state
promptlog that produces output token oLOGIN.
E x a m p l e s of how i n p u t t o k e n s , n o n t e r m i n a l s ,
etud c o n d i t i o n s a r e e x p r e s s e d in this n o t a t i o n
a p p e a r in F i g u r e 2. The use of v a r i o u s t y p e f a c e s
in t h e p r i n t e d v e r s i o n is incidental; t h e plus
signs d e n o t e "user-visible" s t a t e s , d i s c u s s e d
later.
• Art a c t i o n , which m a y m a n i p u l a t e t h e e x t e r n a l
v a r i a b l e s a n d w h i c h will b e e x e c u t e d if this
t r a n s i t i o n is t a k e n (no e x a m p l e s a p p e a r in Figu.re 1).
Descr'i.pti, o~ o f tolce~s a n d nonterrninals
c a g e d by re, m-q, The o u t p u t t o k e n s oLOGIN a n d
29
CH1'83 Proceedings
December 1983
e m d -*ret
m m ~ -*er~d
st:
oLOGIN -*prornptlog
prornptlog :
o L O G N A M E -*getlog
+getlog :
+getLog :
login -*gotlog
iQUIT ~end
go ttog :
gottog :
e o n d : t e s t r e t ( " o k " ) ; -*set'up
c o n d : t e s t r e t ("bad"); -*badlog
badlog:
oBADLOG -~st
se~'up :
setup -*prornptcrnd
+getcn:
+getcn:
+getcn:
iDISPLAY_.MSG -*ce_display
iCOPY_MC -*ce_copy
iCREATE_MF -*ce_create
c¢_d~,.Rolmj:
ce_co2~Y:
ce_cre~te :
oCLRERR -*do_display
oCLRERR -*do_copy
oCLRERR -*do_create
do--d~,sptcgu:
do_copy:
do_create:
display_xnsg -wrest
c o p y _ m e -,test
create_.mf -.test
test:
test:
test:
cond:testret ("noshow"); -->vet
cond:testret ("show'); -*show
eond:testret ("err"); -*err
sho~:
scroll -*ret
err:
oCMDERR -*ret
1oromptcmd: o C M D N A M E -~getcrnd
+getc~,zz~:
+getcmd:
c m d -,ready
iLOGOUT -*end
ready:
oCMD --~rornptcrnd
.
c ~ p y _ m c -* (vtosho'w,err)
I F i g u r e 2. Text f o r m of first d i a g r a m of t h e
m e s s a g e s y s t e m specification.
AddShional nonterm~,nals. F i g u r e 3 shows
m o r e of the s p e c i f i c a t i o n of t h e p r o t o t y p e m e s sage s y s t e m . First, it shows a p o r t i o n of t h e
d i a g r a m for the c m d n o n t e r m i n a l , which was
called f r o m Figure 2. (Most of t h e individual
c o m m a n d s left o u t b e c a u s e t h e y a r e r e p e t i t i v e . )
c m d o b t a i n s a c o m m a n d n a m e , calls t h e
a p p r o p r i a t e n o n t e r m i n a l d i a g r a m ( s u c h as
c o p y _ m e ) t o g e t t h e a r g u m e n t s to t h e c o m m a n d if a n y a n d e x e c u t e it, and t h e n d e c i d e s
w h e t h e r to r e t u r n i m m e d i a t e l y , to display outp u t using t h e s c r o l l n o n t e r m i n a l a n d t h e n
return,
o r to display a n e r r o r m e s s a g e
(oCMDERR) a n d r e t u r n . F i g u r e 3 also shows t h e
n o n t e r m i n a l t h a t o b t a i n s t h e a r g u m e n t s to one
of t h e c o m m a n d s and e x e c u t e s it ( c o p y m c ) .
Act/o~,s a n d co~,dit'~orts. An a c t i o n or condit i o n is r e p r e s e n t e d as one o r m o r e f u n c t i o n
calls. F u n c t i o n n a m e s in u p p e r c a s e (e.g.,
COPY ME) d e n o t e c o m m a n d s
that create,
modify, or display m e s s a g e s y s t e m d a t a o b j e c t s .
These c o m m a n d s c o n s t i t u t e t h e s e m a n t i c s of
the system and are described and implemented
separately.
F u n c t i o n s n a m e s in lower c a s e
r e p r e s e n t o p e r a t i o n s o n local v a r i a b l e s (like
equal or ~ i g n . ) ; m a n y of these would be provided by a t y p i c a l p r o g r a m m i n g language, but,
to k e e p the i n t e r p r e t e r l a n g u a g e simple, t h e y
a r e t r e a t e d as e x t e r n a l f u n c t i o n s here. A variable n a m e p r e c e d e d by an a s t e r i s k d e n o t e s a
promptn:
oMSGNUM -*getn
+getn:
i M S G N U M -.prornptf
pro rnptf.
oFILENAME -*getf
+getfl
iF~LENAME -*test
act:COPY_ME( *voCMDERR,
viMSGNUM, GLOBAL c u r m f ,
viFILENAME);
test:
~nd=equal(voCMDERR, "OK");
-*~'tO$]zo~
cond:NOT equal(voCMDERR, "OIC);
-*err
test:
I I~qgure 3. Additional diagrams
message system specification.
from
the
reference parameter; a~l other parameters are
passed by value. The actual value received by an
input token (such as the actual number entered
for the token i M ~ N U H ) is available in a variable
n a m e d v plus the token n a m e (e.g., viI~SGNUM).
When output tokens are to display variable data
(rather than constemt messages or prompts),
such data m a y be passed to them with
similarly-named variables (e.g., the variable
v o C M D E R R contains the actual error message
that will be displayed by the token o C M D E R R it
was set by C O P Y ~.). All variables contain
character strings of arbitrary length.
30
CH1'83 Proceedings
December 1983
Three Levels of the Specification
that machine are described in a separate
specification [8]. The details of the semantic-
To r e d u c e t h e c o m p l e x i t y of t h e d e s i g n e r ' s
t a s k , t h e p r o c e s s of d e s i g n i n g a u s e r i n t e r f a c e is
d i v i d e d i n t o t h r e e levels. A specific n o t a t i o n
s u i t a b l e f o r e a c h level is t h e n p r o v i d e d . Foley
a n d Wallace [6] i n t r o d u c e d t h e n o t i o n of d e s c r i b ing a n i n t e r a c t i v e u s e r i n t e r f a c e a t t h e sern~nt#,c, s~mtactt'Lc, a n d lexi,c a / l e v e l s , a n d t h a t m o d e l
is followed h e r e . An a t t e m p t is m a d e to deli n e a t e t h e t h r e e levels m o r e p r e c i s e l y , p a r t i c u larly with r e s p e c t to o u t p u t , a n d to p r o v i d e a
specific n o t a t i o n for s p e c i f y i n g e a c h of t h e m
separately to an interpreter.
level
specification
of
the
user
interface
are
thereby partitioned from the syntactic- and
lexical-level
specifications
and
treated
separately [12].
The Syntactic Level
The specification of the syntactic level
describes the seq'~e~tce of the logical input, output, and semantic operations, but not their
internal details. A logical input or output operation is an input or output token. Its internal
structure is described in the lexical-level
specification,
while
the
syntactic-level
s p e c i f i c a t i o n calls it b y its n a m e , like a s u b r o u tine, a n d d e s c r i b e s w h e n t h e u s e r m a y e n t e r it
a n d w h a t will h a p p e n n e x t if he d o e s (for a n
i n p u t t o k e n ) o r w h e n t h e s y s t e m will p r o d u c e it
(for a n o u t p u t t o k e n ) .
The s y n t a c t i c - l e v e l
s p e c i f i c a t i o n is w r i t t e n e n t i r e l y in s t a t e t r a n s i t i o n d i a g r a m n o t a t i o n a n d is d i r e c t l y e x e c u t a b l e .
Figures
1 through 3 show syntactic-level
specifications.
A t r a n s i t i o n in o n e of t h e s e
d i a g r a m s m a y call a lexical d i a g r a m for a t o k e n ,
a n o t h e r s y n t a c t i c d i a g r a m for a n o n t e r m i n a l
s y m b o l , or a n a c t i o n o r c o n d i t i o n c o n s i s t i n g of
one or m o r e of t h e s e m a n t i c f u n c t i o n s d e f i n e d
above.
With t h e p r e s e n t t e c h n i q u e , a s t a t e t r a n s i tion m a y be associated with an input token or an
output-token, but not both. Treating outputs as
separate tokens on separate transitions (rather
than as a special kind of action) in the
syntactic-level
specification
permits
the
specification to be m o r e symmetric in the way it
describes input and output. It is analogous both
to Shneiderman's multi-party adaptation of B N F
[16] and Singer's version of state transition
diagram notation [17] in that similar kinds of
tokens or transitions are used separately for
input and output.* It differs from most other
state transition diagram-based notations that
have been used to describe the syntax of
interactive languages in that they describe user
input on state transitions, but then append to
the transitions actions that both produce output
and modify internal data. Thus they describe
the input syntax clearly but confound the output
with internal actions and input transitions.
The three levels are defined by Foley and
van D a m [7]: The sezruzntic level describes the
functions performed by the system. It tells
what information is needed to perform each
function and the result of performing it. The
xb,rttactW,c level describes the sequences of
inputs and outputs. For the input, this m e a n s
the rules by which sequences of words (to/cons)
in the language are formed into proper (but not
necessarily semantically meaningful) sentences.
The tez'/cat level determines h o w input and output tokens are actually formed from the primitive hardware operations (lezezn.es).
The S e m a n t i c Level
In the actual specification, the semantic
level is concerned with the manipulation of
internal variables; no actual input or output
operations are described at this level, although
the manipulation of values read in. as inputs and
the generation of values to be displayed as outputs
are
described.
The
semantic-level
s p e c i f i c a t i o n c o n s i s t s of d e s c r i p t i o n s of functions t h a t o p e r a t e o n t h e s e i n t e r n a l d a t a , t h a t
is, t h e f u n c t i o n p a r a m e t e r s , t h e i r t y p e s , a n d t h e
e f f e c t s of t h e f u n c t i o n s . S p e c i f i c a t i o n of the
e f f e c t s is not c o n s i d e r e d h e r e , as it is a g e n e r a l
p r o b l e m in s o f t w a r e s p e c i f i c a t i o n , n o t u n i q u e to
u s e r i n t e r f a c e s . T e c h n i q u e s s u c h as p s e u d o c o d e o r a l g e b r a i c s p e c i f i c a t i o n s would b e
a p p r o p r i a t e . The s e m a n t i c f u n c t i o n s a r e s i m p l y
s u p p l i e d to t h e s p e c i f i c a t i o n i n t e r p r e t e r as c o d e
in a c o n v e n t i o n a l p r o g r a m m i n g l a n g u a g e (C).
In t h e p r o t o t y p e m e s s a g e s y s t e m i m p l e m e n t a t i o n , t h e b u l k of t h e s e m a n t i c f u n c t i o n s
a r e i m p l e m e n t e d in a s e p a r a t e p r o g r a m w r i t t e n
in LISP [9]. The LISP i n t e r p r e t e r r u n s as a
separate process and provides the semantic
operations upon request from the process running t h e s t a t e d i a g r a m i n t e r p r e t e r . The functions actually executed by the diagram interp r e t e r s i m p l y s e n d r e q u e s t s to a n d r e c e i v e o u t p u t f r o m t h e p r o c e s s r u n n i n g t h e LISP p r o g r a m ,
w h i c h m a y t h u s b e viewed as a n a b s t r a c t
m a c h i n e t h a t i m p l e m e n t s t h e s e m a n t i c s of t h e
m e s s a g e s y s t e m . The o p e r a t i o n s p r o v i d e d b y
*Th.is could obviously be extended to more than
two-way conversations by choosing better names for the
directions of the multi-party conversation than the
present i ~ I ] N A I E
and oTOI~NAItl]K which stand for
inpv2 and ozdput token names.
31
CH1'83 Proceedings
December 1983
Lexical Level
The lexical level specification describes the
physical e m b o d i m e n t of e a c h of the input and
o u t p u t tokens, including identifying the devices,
display windows, and positions with which t h e y
a re associated and t h e primitive l exem e s t h a t
c o n s t i t u t e t h e m . All information about the
organization of a display into areas and the
assignment of input and output tasks to
hardware devices is confined to this level.
The executable lexical-level specification is
written in the same state transition diagram
notation, avoiding introducing another notation
and another interpreter. As shown in Figure 4,
the lexical-level specification consists of a
separate state diagram for each input or output
token, each of which m a y be called from the
syntactic-level diagrams just as they call other
sub-diagrams for nonterminals. At this level,
output is described by special actions tacked
onto the state transitions; such actions are
expressed and coded as function calls in the
same way as the semantic actions; and they perform the actual output. These functions m a y
only be called at the lexical level. At the syntactic level, output is only performed by output
token transitions, to avoid mixing output actions
with input transitions. At the lexical level, all
outputs (other than lexical echoes) have already
been separated from inputs.
For an input token, the lexical-level
specification gives the sequence of primitive
input lexemes (for example, key presses) and
the device for each lexeme by which the token is
entered as well as any lexical output that is produced. Lexical output constitutes prompts and
acknowledgments for the individual lexemes
that m a k e up a token; most often, it consists of
echoes. The lexical-level specification consists
of state diagrams that call lexemes, which are
either individual hardware input actions (with
haines entirely in upper case, like NEWLINE) or
else sub-diagrams that directly call those
hardware actions (with names of the form l followed by a lexeme n a m e in upper case, like ]IJLany upper- or lo'wer-cese alphabetic character). Lexical outputs (echoes) are given using
the special output actions.
For
an
output
token,
the
lexical
specification tells how (that is, with which devices, windows, positions, formats, colors, and the
like) the token is presented to the user. The
actual information to be presented by an output
token m a y have been set by a semantic action
(for semantic output) or m a y be constant (for
syntactic output). The lexical specification gives
the format in which the data should be
displayed, and, in the case of syntactic output,
the
contents.
The
lexical-level output
The
oBADLOG
st:
refresh.:
p'rizzt:
-~ret
1ERRWIN -.refresh.
1REFRESH -sprint
-*ret a e t p r i n t ( " S o r r y , t r y again or press ESC to exit");
oCMDERR - , r e t
st:
1ERRWIN -~ref r e s h
refresh,:
1REFRESH -*p'r/nt
Im'¢nt:
-Fret aetprint(voCMDERR);
iCOPY_MC -~ret
st:
1CMDWIN -~get'~t
gent:
1FKEY7 -~re t
a c t p r i n t ("copy_mc");
i.FIT.]~[AME -vret
st:
1CMDWIN -~flrstch.~r
flrstc har :
IULCHAR -*more
act:{ print(vlULCHAR);
assign(*viFILENAME, vIULCHAR)];
~'l,oTe:
1ULCHA_R -*m,ore
act:~ print (vlULCHAR);
append(*viFILENAME, vlULCHAR)I;
more:
NEWLINE
-~ret
I F i g u r e 4. Examples of lexical specifications]
from t h e message syst em .
specification is also w r i t t e n in s t a t e d i a g r a m
notation, again calling t he special actions to perf o r m t h e actual output. Some primitive objects
used for producing o u t p u t are defined as o u t p u t
lexemes, specified in t hei r own sub-diagrams. In
part i cul ar, all window selections a r e c o n s i d e r e d
l exem es (e.g., INAI~WI[bO, so t h a t e a c h t o k e n
specification c a n m ake explicit which window it
uses by calling t h e l exem e for t h a t window,
r a t h e r t h a n putting t hat i n f o r m a t i o n in t h e output f u n c t i o n definitions.* The d i a g r a m is executable, like t he o t h e r diagrams, but it is generally just a linear s e q u e n c e of l e x e m e and function calls.
*$hneiderrnan [16] introduced a comparable
scheme to an extended form of BNF. By malting the window selection an output lexeme here, the notation n e e d
not be extended to handle this situation.
32
CH1'83 Proceedings
Stepwise
Refinement
Specifieaticm
December 1983
of
the
a c c e p t i n g d i f f e r e n t ,~,nput t o k e n s (or t e s t i n g conditions), r a t h e r t h a n d i f f e r e n t o u t p u t t o k e n s ,
s i n c e a t r a n s i t i o n w i t h a n o u t p u t t o k e n is always
" s e l e c t e d . " This is a c t u a l l y a s p e c i a l c a s e of a
more general restriction that must be placed on
t h e s e s p e c i f i c a t i o n s to m a k e t h e m r e a l i z a b l e b y
a deterministic interpreter,
i r r e s p e c t i v e of
w h e t h e r o u t p u t is s p e c i f i e d b y s e p a r a t e t o k e n s .
The s y n t a x d i a g r a m s d e s c r i b e a n o n d e t e r m i n i s tic a u t o m a t o n , w h i c h is s i m u l a t e d b y a d e t e r m i n i s t i c i n t e r p r e t e r . The i n t e r p r e t e r s e l e c t s a n
a r b i t r a r y p a t h , t r i e s it, and, if it r e a c h e s a d e a d
end, b a c k t r a c k s a n d t r i e s a n o t h e r p a t h i n s t e a d .
In a n i n t e r a c t i v e s y s t e m , it is m e a n i n g l e s s to
backtrack over a path that has already gene r a t e d o u t p u t to t h e u s e r . The following cons t r a i n t will prevent this: Starting at each sta.te
at w h i c h t h e r e is a for~c, the i n p u t s t h a t 'will
ca;use the rnach~ne to r e a c h a n y tv~ns4,t'ion t h a t
w i l l p r o d u c e a n outp~JJ~ to the u s e r m u s t be disjo~,nt . f r o m the i,r,p u t s th,a;~ ~uiU cause i,t to r e a c h
m,~y other trcm.s/tgon w/t/z an output. That is,
f r o m a n y s t a t e , t h e s a m e initial i n p u t c a n n o t
c a u s e two d i f f e r e n t o u t p u t t r a n s i t i o n s , e v e n
though subsequent input might disambiguate
them.
Syntax
While t h e first a s p e c t of t h e s y n t a x to b e
d e s i g n e d should u s u a l l y b e t h e i n p u t s y n t a x ,
m o r e d e t a i l s m u s t e v e n t u a l l y b e p r o v i d e d , still
a t t h e s y n t a c t i c level, to yield a c o m p l e t e (executable)
specification.
Beginning
with
a
s p e c i f i c a t i o n of t h e i n p u t language, a d e s c r i p t i o n
of t h e o u t p u t is a d d e d in a p r o c e s s of s t e p w i s e
refinement that leads to a complete syntactic
specification.
The first s t e p is a d i a g r a m of t h e i n p u t s y n t a x only, with no a c t i o n s o r o u t p u t s . At e v e r y
s t a t e in this s p e c i f i c a t i o n , t h e c o m p u t e r is waiting for i n p u t f r o m t h e u s e r . Next, i n f o r m a l
d e s c r i p t i o n s of t h e a c t i o n s a n d o u t p u t s a r e
a d d e d to e a c h t r a n s i t i o n , b u t t h e s e q u e n c e of
the actions, outputs, and conditions associated
with a n y single t r a n s i t i o n is n o t f o r m a l l y
specified. In t h e t h i r d s t e p , new s t a t e s a r e
i n t r o d u c e d into the d i a g r a m s . E a c h individual
a c t i o n a n d c o n d i t i o n is p u t on its own s t a t e t r a n sition, a n d e a c h o u t p u t o p e r a t i o n is d e f i n e d as a
s e p a r a t e o u t p u t t o k e n a n d p u t o n its own t r a n s i tion. This m e a n s t h a t new " i n t e r n a l " s t a t e s a r e
i n t r o d u c e d into the s p e c i f i c a t i o n , in which t h e
s y s t e m is n o t waiting f o r u s e r i n p u t . The u s e r
n e v e r o b s e r v e s t h e s y s t e m in a n y of t h e s e
s t a t e s ; he o n l y s e e s it in t h e s t a t e s in w h i c h i t is
waiting for input. The l a t t e r a r e c a l l e d u s e r v i s i b l e s t a t e s a n d m a y be m a r k e d with plus
signs in t h e s p e c i f i c a t i o n . In t h e f o u r t h s t e p , t h e
individual a c t i o n s a n d c o n d i t i o n s a r e s p e c i f i e d
f o r m a l l y , t h a t is, as f u n c t i o n calls to specific
s e m a n t i c - l e v e l f u n c t i o n s . F i g u r e s 1 t h r o u g h 3 all
show s y n t a c t i c - l e v e l s p e c i f i c a t i o n s c o r r e s p o n d ing to t h i s s t e p . Finally, p r o v i s i o n s f o r handling
e r r o r s a n d f e a t u r e s , s u c h as help, a b o r t c o m m a n d , a n d e s c a p e t o m o n i t o r , a r e m a d e in
t h e fifth s t e p . S t a t e t r a n s i t i o n s for t h e s e p u r p o s e s a r e a d d e d to s o m e or all of t h e u s e r - v i s i b l e
states.
To aid in the early stages of this process of
stepwise refinement, the specification interpreter m a y be told to provide stubs for missing
sub-diagrams in a specification and simply to
print descriptions of actions instead of trying to
execute them. Thus, the specification in its
early, informal stages m a y still be parsed,
drawn, and executed automatically.
Implementation
The s p e c i f i c a t i o n i n t e r p r e t e r is w r i t t e n in C
( a b o u t 2000 lines of c o d e ) a n d r u n s u n d e r UNIX
on a VAX. A c o m m o n f r o n t end, c o n s t r u c t e d
with YACC a n d LEX f r o m a BNF d e s c r i p t i o n of t h e
s p e c i f i c a t i o n l a n g u a g e , is u s e d to p a r s e t h e
specification, b o t h for i n t e r p r e t i n g it a n d for
c o n v e r t i n g it to d i a g r a m f o r m . The s e m a n t i c
functions and the output functions used by the
lexical-level s p e c i f i c a t i o n a r e c o d e d in C a n d
t h e n linked w i t h t h e i n t e r p r e t e r .
Devicei n d e p e n d e n t facilities for f u l l - s c r e e n t e x t t e r m i nals a n d also g r a p h i c a l o u t p u t d e v i c e s a r e available to these f u n c t i o n s .
Condtmions
This paper has presented a technique for
specifying the user interface of an interactive
computer system and described h o w it has been
used to produce a formal and executable
specification of the user interface of a military
message system. The technique permits the
designer of a user interface to describe the
interface completely and obtain a prototype of it
directly from the specification. The notation
uses state transition diagrams to emphasize the
time sequence aspects of the user-visible
behavior of the system. It permits both the
specification and the design process to be
separated into the semantic, syntactic, and lexical levels, and it supports a process of stepwise
refinement at the syntactic level.
Restrictions on Nondeterminiscm
I n t r o d u c i n g o u t p u t t o k e n s into t h e s y n t a x
d i a g r a m s on t h e i r own s e p a r a t e t r a n s i t i o n s
i m p l i e s t h a t t h e r e s h o u l d not b e a "fork" in a
diagram (a state with m o r e than one transition
leading from it) where there is an output token.
That is, any state with a choice of transitions
leading from it m u s t m a k e that choice by
33
CH1'83 Proceedings
December 1983
12.
Acknowledgments
I would like to thank Connie Heitmeyer,
Mark Cornwell, and Carl Landweh_r for their helpful suggestions and c o m m e n t s on this work.
This work was supported by the Naval Electronic
Systems Command under the direction of H.O.
Lubbes.
13.
References
I.
T. Bleser and J.D. Foley, "Towards Specifying and Evaluating the H u m a n Factors of
User-Computer I n t e r f a c e s , " Pron. H u m a n
14.
Factors 'in Computer Systems Conference,
pp. 309-314 (1982).
MUMPS Development Committee, MUMPS
L a ~ l u a g e Stmzdard, American National
Standards Institute, New York (1977).
3.
M . E . Ccnway, "Design of a Separable
Transition-Diagram Compiler," Comm. ACM
6 pp. 396-408 (1963).
4.
J. Darlington, W. Dzida, and S. Herda, "The
Role of Excursions in Interactive S y s t e m s , "
InterTza,tionaZ Journal of Man-Machine St udies 18 pp. 101-112 (1983).
5.
M.B. F e l d m a n and G.T. Rogers, "Toward the
Design
and
Development
of
Styleindependent Interactive Systems," Pron.
H u m a n Factors i n Computer S y s t e m s
Conference, pp. 111-116 (1982).
6.
J.D. Foley and V.L. Wallace, "The Art of
Graphic
Man-Machine
Conversation,"
Proceedings of the IEEE 62pp. 462-471
(1974).
7.
J.D. Foley and A. van Dam, Ft~ndamenta/.s
off
In~vac~ve
Computer
Graphics,
Addison-Wesley, Reading, Mass. (1982).
8.
C.L. Heitmeyer, "An I n t e r m e d i a t e Comm a n d Language (ICL) for the Family of Milit a r y Message Systems," Naval Research
Laboratory Technical Memorandum 7590450:CH:ch (13 November 1981).
9.
C.L. Heitmeyer, C.E. Landweh_r, and M.R.
Cornwell, "The Use of Quick Prototypes in
the Military Message Systems Project,"
ACM SIGSGFT So l~zvare Engineer~z~g Notes
7 pp. 85-87 (1982).
10. R.J.K. Jacob, "Survey and Examples of
Specification Techniques for User Interfaces," NRL Report,
Naval Research
Laboratory, Washington, D.C. (1963).
11. R.J.K. Jacob, "Formal Specification of the
User Interface of a Receive-only Secure Military Message System P r o t o t y p e , " Naval
Research Laboratory Technical Memorandum 7590:RJ:rj (1983).
2.
15.
18.
17.
18.
19.
20.
34
R.J.K. Jacob, "Using Formal Specifications
in the Design of a Human-Computer Interface," Comm. ACM 26 pp. 259-264 (1983).
T.P. Moran, "The Command Language
Grammar: A Representation for the User
Interface of Interactive Computer Syst e m s , " Interr~ational Journal o f ManMachine S t u d i e s 15pp. 3-50 (1981). The
Interaction
Level
of
the
Command
Language G r a m m a r is similar to a s t a t e
transition diagram specification.
D.L. Parnas, "On the Use of Transition
Diagrams in the Design of a User Interface
for an Interactive Computer S y s t e m , "
Pron. 24th Na.~iona,l ACM Conference, pp.
379-385 (1969).
P. Reisner, " F o r m a l G r a m m a r and H u m a n
Factors Design of an Interactive Graphics
S y s t e m , " IEEE Tra~sazfJ, ons on So#zvare
Erugineer/ng SE-7 pp. 229-240 (1981).
B. Shneiderman, "Multi-party G r a m m a r s
and Related F e a t u r e s for Defu_ing Interactive Systems," [EEE Transactions on Syst em s, Man,, and Cybe~n.etics SMC-12(2)pp.
148-154 (March 1981).
A. Singer, " F o r m a l Methods and H u m a n
Factors in the Design of Interactive
Languages," Ph.D. dissertation, Computer
and Information Science Dept., Univ. Mass a c h u s e t t s (1979).
H. Thimbleby, "Character-level Ambiguity:
Consequences for User Interface Design,"
Intel,'n,ational Jou~"n,a2 of Ma~-Mach,ine St'udies 16 pp. 211-225 (1982).
A.I. Wasserman and D.T. Shewmake, "Rapid
Prototyping of Interactive Information Syst e m s , " ACM SIGSOFT So]2"ware Eag/~,eerNoSes 7 pp. 171-180 (1982).
W.A. Woods, "Transition Network G r a m m a r s
for Natural Language Analysis," Comm.
ACM 13 pp. 591-606 (1970).