RESEARCH
CONTRIBUTIONS
~i!~~i¸I!!
i ~i~~!~!~~i~~i ii ,~i!ii~
:!ilil~i~¸~!I;
;:!; ~!~2
~ iii~;;'iil;
~iili¸i;¸ ;!iii~¸i~,~;,~i;'!~ii!i:;i!!i;i'~ii!i!~,~:i,i!!i!~
,i~il~iii~,ii,i;!'i~¸~ ;ii: ,i!i;iJ'~!:il
¸!!II;!~:~" ~iiI!!
Using Formal
Specifications in the
Design of a
Human-Computer
Interface
R O B E R T J . K. J A C O B N a v a l R e s e a r c h L a b o r a t o r y
Robert ].K. Jacob is investigating
formal specification techniques
for describing user-computer
interaction for both the design
and construction of user
interfaces for computer systems.
This work was supported
by the Naval Electronic
Systems Command under the
direction of H. O. Lubbes.
Author's Present Address:
Robert J.K. Jacob,
Computer Science and
Systems Branch, Code 7590,
Naval Research Laboratory,
Washington, D.C. 20375.
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
0001-0782/83/0400-0259 75¢.
April 1983
Volume 26
Number 4
INTRODUCTION
Formal specification t e c h n i q u e s h a v e b e e n applied to
m a n y aspects of s o f t w a r e d e v e l o p m e n t . T h e i r v a l u e is
that t h e y p e r m i t a designer to describe the e x t e r n a l beh a v i o r of a s y s t e m precisely w i t h o u t s p e c i f y i n g its internal i m p l e m e n t a t i o n . H o w e v e r , s u c h t e c h n i q u e s h a v e b e e n
applied only rarely to the specification of user interfaces,
despite the fact that the user interface is increasingly
being r e c o g n i z e d as a critical e l e m e n t in m a n y s o f t w a r e
systems. O n e is h a n d i c a p p e d in trying to design a good
user interface w i t h o u t a clear and precise t e c h n i q u e for
specifying such interfaces.
T h e design of the user interface for a m i l i t a r y m e s s a g e
system has a special i m p o r t a n c e b e c a u s e of its role in
m a i n t a i n i n g the security of classified messages. E n f o r c e m e n t of s y s t e m security r e q u i r e s that the user u n d e r s t a n d
the security-related c o n s e q u e n c e s of his or her actions,
but often s u c h c o n s e q u e n c e s are not intuitively obvious.
Recent e x p e r i m e n t a l results indicate that c o m m u n i c a t i n g
the security implications of an action and obtaining
m e a n i n g f u l a p p r o v a l or d i s a p p r o v a l f r o m a user can be
v e r y difficult [18].
In the Military Message S y s t e m (MMS) project at the
Naval R e s e a r c h Laboratory, f o r m a l s p e c i f i c a t i o n techniques are being used to c o n s t r u c t a f a m i l y of s e c u r e
message s y s t e m s [6, 7]. C o m p a t i b l e s p e c i f i c a t i o n techniques m u s t t h e r e f o r e be applied to the h u m a n - c o m p u t e r
interfaces for such systems. Rapid p r o t o t y p e s of m i l i t a r y
message s y s t e m s will t h e n be c o n s t r u c t e d based on t h e s e
specifications [8], and, later, full-scale p r o t o t y p e s will be
built.
This paper describes the specification of the user interface m o d u l e for the f a m i l y of m e s s a g e systems, s u r v e y s
specification t e c h n i q u e s that can be applied to h u m a n c o m p u t e r interfaces, p r o v i d e s e x a m p l e s of specifications,
and presents s o m e conclusions [10].
USER INTERFACE SPECIFICATIONS FOR THE
MILITARY MESSAGE SYSTEM FAMILY
Each m e m b e r of the M M S f a m i l y consists of several c o m ponents. T w o are of interest here: the U s e r A g e n t and the
Data Manager. As s h o w n in Figure 1, the user c o m m u n i -
ABSTRACT: Formal specification
techniques are valuable in software development because they
permit a designer to describe the
external behavior of a system precisely without specifying its interna• implementation. Although formal specifications have been applied to many areas of software
systems, they have not been
widely used for specifying user interfaces. In the Military Message
System project at the Naval Research Laboratory, the user interfaces as well as the other components of a family of message systems are specified formally, and prototypes are then implemented
from the specifications. This paper illustrates the specification of
the user interface module for the
family of message systems. It then
surveys specification techniques
that can be applied to
h u m a n - c o m p u t e r interfaces and
divides the techniques into two
categories: those based on state
transition diagrams and those
based on BNF. Examples of both
types of specifications are given.
Specification notations based on
state transition diagrams are preferable to those based on BNF because the former capture the surface structure of the user interface
more perspicuously. In either notation, a high-level abstraction for
describing the semantics of the
user interface is needed, and an
appllcation-speclfic one is used
here.
Communications of the ACM
259
RESEARCHCONTRIBIrrlONS
cates with the User Agent via a U s e r Command Language
(UCL). Once it receives a c o m m a n d from the user, the
User Agent translates the c o m m a n d into a s t a n d a r d
f o r m - - a statement in the Intermediate Command Language (ICL)--and passes that to the Data Manager. Information returned by the Data Manager in response to user
requests is delivered to the User Agent, which is responsible for displaying it to the user. This division permits n e w
systems with different user interfaces to be constructed
from an existing system with relative ease. If the user
interface is changed, only the User Agent must be modified so that it will translate from the new UCL into the
standard ICL; the Data Manager and other system components need not be changed. For example, two members of
the MMS family could provide the same basic functions
but differ in their user interfaces. They would have two
USER
f.]ssr
O~mmand
~,~e
USER
AGENT
Intm'~'~diate
Cammand
Language
DATA
MANAGEH
FIGURE 1. Components of the Military Message System.
different User Agents but would share the same Data
Manager. Separating the user interface in this w a y makes
it possible to experiment with different user interfaces
and to evaluate them from their specifications (as Reisner
[15] and Embley [3] do) as well as from a prototype (as
Hanau and Lenorovitz [5] do).
This division also makes the specification of the user
interface clearer. Previous user interface specifications
have suffered because they lacked an acceptable language
for describing the "semantics" of the interface, that is, the
actions that the system performs in response to the user's
commands. Since a complete description of such actions
is in fact a specification of the entire system, putting it in
the user interface specification clutters that specification
with detail that belongs at another level [2]. W h a t is
needed is a high-level model that describes the operations
that the system performs. Then, the user interface specification would describe the user interface in terms of the
model, while the internal details of the model would be
described in a separate specification.
The design used in the Military Message System project
provides one solution to this problem. The ICL is an abstract model of the services performed by a message system and is described in a separate specification [7]. The
user interface specification, then, needs only to describe
the syntax of the UCL using a language specification technique and the semantics of the UCL using ICL statements.
PROPERTIES OF A SPECIFICATION TECHNIQUE
In selecting a technique for specifying a h u m a n - c o m p u t e r
interface, one should seek the following properties:
• The specification of a user interface should be easy to
understand. In particular, it must be easier to understand and take less effort to produce than the software
that implements the user interface.
• The specification should be precise. It should leave no
doubt as to the behavior of the system for each possible
input.
• It should be easy to check for consistency.
260
Communications of the ACM
• The specification technique should be powerful enough
to express nontrivial system behavior with a m i n i m u m
of complexity.
• It should separate what the system does (function) from
how it does it (implementation). The technique should
make it possible to describe the behavior of a user interface, without constraining the w a y in which it will be
implemented.
• It should be possible to construct a prototype of the
system directly from the specification of the user interface.
• The structure of the specification should be closely related to the user's mental model of the system itself.
That is, its principal constructs should represent concepts that will be meaningful to users (such as answering a message or examining a file), rather than internal
constructs required by the specification language. Alternatively, the specification should directly yield a reasonable table of contents for a user manual, but not
necessarily the material in the manual.
SURVEY OF SPECIFICATION TECHNIQUES
Much of the w o r k applicable to techniques for specifying
h u m a n - c o m p u t e r interfaces has been concerned with
static rather than interactive languages. In a static language, an entire text in the input language is conceptuall.y
present before a n y processing begins or a n y outputs are
produced; all of the outputs are then produced together,
usually after a fairly long input text, such as a program,
has been processed. Processing of an input text is affected
little, if at all, by the previous inputs. In an interactive
language, the input can be described as a series of brief
texts, where the processing of each input generally depends on previous inputs, or, equivalently, as one long
text, in which the computer takes actions and produces
outputs at various points during the input, resulting in a
dialogue. Hence, a specification for such a language" must
capture not only the system actions and outputs but also
their sequence with respect to portions of the input.
Most specifications for both static and interactive languages have been based on one of two formal models:
Backus-Naur Form (BNF) [15] and state transition diagrams [14]. Each of these methods provides a s y n t a x for
describing legal streams of user inputs. In order to be
used to specify interactive languages, the techniques must
be modified to d e s c r i b e - - i n addition to user i n p u t s - - t h e
system actions and their sequence with respect to the
input.
BNF
For BNF, the necessary modification consists of associating an action with each g r a m m a r rule. W h e n e v e r that rule
applies to the input language stream (received thus far),
the associated action occurs. (As mentioned, for the M M S
family members, these system actions can be described as
ICL statements issued by the User Agent to the Data
Manager.)
Reisner [15] provides an example of h o w BNF can be
used to describe a user interface. Unlike several other
published specifications, Reisner's specifies a nontrivial,
real-world system. It does leave out the semantics of the
u s e r i n t e r f a c e - - t h e system actions and r e s p o n s e s - - s i n c e
Reisner did not need them for her purposes. That is, it
provides a s t a n d a r d BNF description of the input language, but no specification of a n y outputs. Reisner uses
formal properties of the BNF specifications of two syso
April 1983 Volume 26 Number 4
RESEARCHCONTRIBUTIONS
terns to predict differences in the performance of their
users. More complex or less consistent BNF rules lead to
predictions of user errors. Several such predictions are
then verified experimentally.
Shneiderman [16] also examines the use of BNF for
describing interactive user interfaces and proposes a modified form of BNF in which each nonterminal symbol m a y
be associated with either the computer or the user. W i t h
the exception of one unusual nondeterministic case, this
type of g r a m m a r can be m a p p e d into a state transition
diagram similar to Singer's [17].
A BNF specification can also be used as input to a
compiler-compiler, such as YACC [11]. Such a program
can be given a specification in which an executable action
(rather than a routine to generate object code) is associated with each BNF rule; then it can automatically construct a prototype of the specified system. While the input
syntax is described in BNF, the actions must generally be
given in a conventional programming language.
One general problem that arises with BNF-based techniques is that it is sometimes difficult to determine exactly when something will occur, that is, after exactly
what input tokens have been recognized. This makes it
a w k w a r d to specify interactive prompting, help messages,
and error handling, which must occur at particular points
in a dialogue. Often, it requires the introduction of a collection of otherwise irrelevant nonterminal symbols into
the specification.
STATE TRANSITION DIAGRAMS
To represent interactive languages, state transition diagrams are modified in a w a y similar to that for BNFbased techniques. Each transition is associated with an
action; whenever the transition occurs, the system performs the associated action. Since the concept of sequence is explicit in a state diagram (while it is implicit in
BNF), the former is more suited to specifying the points in
a dialogue at which events occur.
C o n w a y [1] presents an early use of a notation based
on state transition diagrams in which an action is associated with each transition. His goal, however, was to specify and construct a compiler for a static language, so he
did not address the problems of interactive user interfaces.
W o o d s [19] also describes a notation, "Augmented
Transition Networks," based on state transition diagrams
for analyzing a static language. His notation includes an
extension to conventional state transition diagrams: a
(global) data structure. The actions associated with each
transition manipulate this structure, and the conditions
for making a state transition can include arbitrary Boolean expressions that d e p e n d on the data structure.
C o n w a y and W o o d s both introduce into their state diagrams a feature analogous to BNF nonterminal symbols.
With this feature, instead of labeling a state transition
with a single input token, the transition m a y be labeled
with the name of a nonterminal symbol. That symbol is,
in turn, defined in a separate state transition diagram.
The labeled path in the main diagram is then taken if the
entire separate diagram can be traversed at the current
position in the input stream. This makes it possible to
divide complex diagrams into more manageable pieces. It
also makes it easier to introduce nondeterminism into the
specification. I If recursive calls to these separate diagrams
are permitted, the notation is equivalent in p o w e r to BNF
[9]. Adding the actions and conditions (and the ability to
April 1983
Volume 26
Number 4
create new variables dynamically) either to these state
transition diagram notations or to the BNF notations
makes the resulting notation equivalent in p o w e r to a
Turing Machine.
Parnas [14] proposes the use of state diagrams to describe user interfaces for interactive languages. He differentiates "terminal state" from "complete state" in a w a y
analogous to the separation of syntax from semantics in
other specifications. Parnas' paper contains some very
simple examples but does not address h o w the scheme
would be extended for more complex real-world systems.
Foley and Wallace [4] also advocate the use of a state
diagram to represent the user interface of an interactive
system. While their notation is clear and easy to understand, they, too, do not examine the problem of specifying
real-world systems.
The standard for the MUMPS interactive computer language [12] provides an example of a specification of a
complex system that uses a notation based on state diagrams. The specification uses nonterminal symbols extensively and gives a precise deterministic procedure for interpreting diagrams containing them (since their use can,
in the general case, require a nondeterministic
automaton). The specification is n o t e w o r t h y in that the
actions associated with its transitions comprise a complete specification of the semantics of the MUMPS language.
Singer [17] presents a state diagram-based specification
of a nontrivial system. His notation is more precise and
more general than most other versions of state diagrams,
but it is also more complex and difficult to understand. It
uses separate diagrams for nonterminal symbols and a
global data structure, which can be set by arbitrary semantic-domain actions. Transitions can only be selected
by examining values in this data structure, rather than the
input tokens directly. Hence a transition involving receipt
of a particular token is described by two transitions in
Singer's n o t a t i o n - - o n e to read it into the data structure
and one to test the value just stored. While the two notations a p p e a r quite different, most aspects of Singer's notation can be m a p p e d into that of the MUMPS specification.
Moran [13] provides a notation for describing the user's
view of a computer system at several levels, from the
overall tasks performed to individual key presses. This
notation results in an unusually long and detailed specification. At the "Interaction Level," Moran's specification
can be m a p p e d onto a state diagram. His notation does
not contain a state diagram representation of the Interaction Level of the user interface, but it does record a number of properties such a diagram would have. These properties are sufficient to generate a state diagram specification or (in a specification where only a few properties are
specified) a set of diagrams.
EXAMPLES OF SPECIFICATIONS
To illustrate the use of some specification techniques, two
commands from an hypothetical military message system
are specified here. The Login c o m m a n d prompts the user
to enter his or her name. If it does not recognize that
name, it asks the user to reenter it, until he enters a valid
name. Then, the system requests a password; if the password entered is incorrect, the user gets one more try to
l This must be done w i t h care in an interactive system. Even though a
deterministic automaton with backtracking can execute a nonrecursive
nondeterministic diagram, in an interactive system it is not possible to b a c k t ra c k
over a path that has already generated output to the user.
Communications of the ACM
261
RESEARCH CONTRIBUTIONS
Each state is represented by a circle. The start and end
states are so named inside the circles. Each transition
between two states is shown as a directed arc. It is labeled with the name of an input token, in capital letters,
plus, in some cases, a footnote containing Boolean conditions, system responses, and actions. A given state transition will occur if the input token is received and the
condition is satisfied; w h e n the transition occurs, the system displays the response and performs the action.
Instead of an input token, a transition m a y be labeled
with the name of another diagram (in lower case). Such a
transition will be made if the n a m e d diagram is traversed
successfully at this point in the input. This notation permits breaking the specification up for clarity; otherwise,
the text of the called diagram could simply have been
inserted at this point in the calling diagram (provided no
recursive calls are made).
In the actions, procedure names in upper case denote
ICL statements, but their specific meaning is not material
to this discussion. Some simple programming languagelike
facilities, such as assignment and comparison, are assumed here, although the corresponding tasks could have
been handled by defining some additional ICL statements.
A token name preceded by a dollar sign stands for the
LOGIN
5ECLE'JF_L (8)
(i)
r e s p : "Enter n a m e "
(2) eond: not EXISTS_USER(SUSER)
rasp: "Incorrect user name--reenter it"
(3)
(4)
c o n d : EXISTS_USER($USER)
resp: "Enter password"
c o n d : $PASSWORD=GETPASSWD_USER(SUSER)
resp: "Enter security l e v e l "
(5) cond: $PASSWORD~GETPASSWD_USER($USER)
rasp: "Incorrect password--reenter it"
(6) cond: SPASSWORD=GEVPASSWD_USER(SUSER)
resp: "Enter security level"
REPLY
(7) cond: $PASSWORD~GETPASSWD_USER(SUSER)
resp: "Incorrect password--start again"
.a~o=
(8) cond: $SECLEVEL>GETCLEARANCE_USER($USER)
rasp: "Security level too high-reenter it"
(9) cond: $SECLEVEL~GETCLEARANCE_USER(SUSER)
act: CREATE~SESSION( $U SER, $PASSWORD,$SECLEVEL)
(10) rasp: '~(our security level is Unclassified"
act: CREATE_.SESSION(SUSER,SPASSWORD,Unclas
EXTRATOS
sified)
FIGURE 2. State Diagram Specification of the "Login': Command.
enter a correct one and proceed; otherwise, he must begin
the whole c o m m a n d again. 2 Next, the system requests a
security level for the session, which must be no higher
than the user's security clearance. If he enters a level that
is too high, he is prompted to reenter it, until he enters an
appropriate level. If he does not enter an appropriate security level, he is given the default level, Unclassified.
The Reply c o m m a n d permits a user to send a reply to a
message he has received. The user can give an optional
input indicating to which message he wants to reply;
otherwise, the default is CurrentMsg. He then enters the
text of his reply. Following this, he can enter some optional lists containing additional addressees to which he
wants this reply to be sent (in addition to those on the
distribution list of the message to which he is replying).
Each of these lists consists of the word "To" or "Cc"
(depending on how the reply should be addressed to these
people) followed by one or more addressees.
In Figure 2, the Login c o m m a n d is specified using state
transition diagrams; the Reply c o m m a n d is specified in
Figure 3. The notation follows widely used conventions.
2 In the specifications of this c o m m a n d given below, this counting is peformed
using an extra state or an extra BNF rule. This approach is clear f o r the simple
c o m m a n d here, but it would obviously be inconvenient if the system allowed
the user a m a x i m u m of 10o tries to enter his p a s s w o r d or if the limit were
dependent on s o m e other stored data. In s u c h a case, the action and condition
features of either notation, described below, would be used. The state transition
or BNF rule corresponding to entry of an incorrect password would have an
action that increments a counter variable, and that counter would then be tested
in a condition associated with a subsequent state transition or BNF rule.
262
Communications
of the ACM
~
(2)
EXTRACES
st•
CE
R~nIv
(~) resp: "Enter text field"
act: replyid:=REPLY..-MSG(SMSGID):
replybuf: = OPENFOREDIT._M SG(r eptyid)
(2) resp: "Enter text field"
act: replyid:=REPLY.._MSG(CurrentMsg);
replybuf: = OPENFOREDIT__MSG (r eplyid)
(a) act: sEYrEXT._MSG (STEXT, replybuf)
(4) act: UPDA~SG(replyid,replybuf);
CLOSEEDIT_MSG(repIyid)
~Ytratn~
(i) act: SEITO_MSG(replybuf,GEITO_MSG(replybuf)+SADDRESSEE)
(2) act: SEITO_.MSG(repIybuf,G~_MSG(repIybtff)+SADDRESSEE)
p~rarr~
(1)
a c t : SETCC__MSG(replybuf,GETCC--MSG(replybut)+$ADDRESSEE)
(2)
a c t : SETCC_.MSG(replybuf,GETCC--MSG(replybuf)+SADDRESSEE)
FIGURE 3.
State Diagram Specification of the "Reply" Command.
A p r i l 1983
V o l u m e 26
Number 4
RESEARCHCONTRIBUTIONS
lx~cTin
start:
LOGIN resp: "Enter name" -*getu
getu:
USER cond: not EXISTS_USER(SUSER)
rasp: "Incorrect user name--reenter it" ~getu
USER cond: E)flSTS_USER(SUSER)
resp: "Enter password" ~getpw
getu:
getpw:
PASSWORD con& $PASSWORD=GETPASSWD_USER(SUSER)
rasp: "Enter security level" -*getsl
PASSWORD cond: SPASSWORD~GETPASSWD_USER(SUSER)
rasp: "Incorrect password--reenter it" ~badpw
getpw:
badpw:
PASSWORD cond: SPASSWORD=GETPASSWD_USER(SUSER)
rasp: "Enter security level" ~getsl
PASSWORD cond: $PASSWORD~GETPASSWD_USER(SUSER)
rasp: "Incorrect password-start again" ~start
badpw:
getsl:
getsl:
getsl:
SECLEVEL cond: $SECLEVEL>GETCLEARANCE_USER(SUSER)
rasp: "Security level too high-reenter it" -*getsl
SECLEVEL cond: $SECLEVEL~GETCLEARANCE_USER(SUSER)
act: CREATE--SESSION(SUSER,SPASSWORD,SSECLEVEL)~end
ANY resp: '"four security level is Unclassified"
act: EREATE--SESSION(SUSER,SPASSWORD,Unclassified) -*end
FIGURE 4. Text Representation of Figure 2.
value most recently read in for that input token. For example, $USER stands for the actual name the user typed.
The special token ANY is defined such that if no other
transition can be made, the transition labeled with ANY
is made, and the current input token is scanned again
when the new state is reached. If the system reaches a
state from which no transition can be made, given the
current input, then there is an error in the input, and a
transition would be made to an error-handling procedure.
For clarity, such procedures have not been included in
these examples. (Clearly, this cannot arise in a state from
which there is a transition with the token ANY.)
The tokens themselves can be defined in a separate
specification, which captures lower-level details of the
user-computer interaction. For example, the token LOGIN
start:
gelid:
getid:
REPLY
could represent the typed string "Login," a function key,
or a hit of a graphic input device on a menu display,
without affecting the specification shown here. Similarly,
the definition of TEXT would include a specification of
the delimiter used to indicate the end of an input string.
Figures 4 and 5 s h o w h o w the specifications can be
represented in text form. This is often more convenient
for computer input and output than the graphical diagrams. The text representation consists of a list of the
transitions that comprise the diagram, each represented
by a line of the form
sl: INP resp: "Hello" -->s2
denoting a transition from state s l to state s2, which expects input token INP and displays response "Hello."
Conditions or actions are specified in a w a y similar to the
response. Instead of an input token, the name of another
diagram could be given (in lower case), meaning that that
diagram would be traversed, and, upon exit from it, a
transition to state s2 would be made. Other features of
this notation are the same as for the state diagrams above.
This notation is directly translatable into that of the
graphic state diagrams. In fact, Figures 4 and 5 were the
input to a program that produced Figures 2 and 3 automatically.
badpw* goodpw [rasp: "Enter security level"I getseelevel
badpw ::=
loguser onetry PASSWORD
[cond: SPASSWORD~GETPASSWD_USER(SUSER)
rasp: "Incorrect password-start again"I
goodpw ::=
loguser PASSWORD
[cond: SPASSWORD= GETPASSWD_USER(SUSER) I
loguser onetry PASSWORD
[cond: SPASSWORD=GETPASSWD_USER(SUSER)~
Ioguser:::
LOGIN [rasp: "Enter name"]
getuser }resp: "Enter password"]
getuser::=
baduser* USER ~cond: EXISTS_USER(SUSER)I
baduser ::=
USER ~cond: not EXISTS_USER($USER)
onetry ::=
PASSWORD
{eond: $PASSWORD~ GETPASSWD_USER(SUSER)
resp: "Incorrect password-reenter it"I
getseelevel ::=
badsl* [resp: '~Yoursecurity level is Unclassified"
act: CREATE--SESSION(SUSER,SPASSWORD,Unclassifled)I
badsl* SECLEVEL
}cond: $SECLEVEL~-GETCLKARANCE_USER (SU SER)
act: CREATE--SESSION(SUSER,SPASSWORD,SSECLEVEL)I
rasp: "Incorrect user name--reenter it"]
-*gelid
M S G I D resp: "Enter text field"
act: replyid:=REPLY...MSG(SYISGID);
replybuf: =OPENFOREDIT....MSG( r eplyid) -*gettext
A N Y resp: "Enter text field"
act: replyid: =REPLY-.MSG(CurrentMsg);
replybuf: = OPENFOREDIT._MSG(replyid) -~gettext
gettext:
TEXT act: SETrEXT_MSG(STEXT,replybuf)
getextras:
getextras:
getextras:
extratos -*getextras
extraccs -*getextras
A N Y act: UPDATF~MSG(replyid,replybuf);
CLOSEEDIT_MSG(replyid) -*end
[
-*getextras
badsl::=
FIGURE 6.
SECLEVEL
}cond: $SECLEVEL>GETCLEARANCE_USER (SUSER)
resp: "Security level too high-reenter it"I
BNF Specification of the "Login" Command.
~vtratf~
start:
tl:
t2:
t2:
start:
el:
e2:
c2:
TO -*tl
A D D R E S S E E act: SETTO_MSG(replybuf,
GETTO--MSG(replybuf) + SADDRESSEE)
A D D R E S S E E act: SETrO--MSG(replybuf,
GETTO_MSG(replybuf) + SADDRESSEE)
A N Y -*end
April 1983
Volume 26
Number 4
R E P L Y getid {rasp: "Enter text field"
act: replybuf: = OPENFOREDIT..-MSG(r eplyid) ~
TEXT ~aet: SETTEXT_MSG(STEXT,repIybuf)I
extras* ~aet: UPDATE--MSG(replyid, replybuf);
CLOSEEDIT_MSG(repIyid) ~
getid ::=
[
MSGID ~act: replyId:---REPLY..-MSG($MSGID)~
NULL [act: replyid:=REPLY_MSG(CurrentMsg)~
extras ::=
extratos [ extrraccs
extratos ::=
t o a d d r e s s e e ::=
TO toaddressee toaddressee*
ADDRESSEE ~act: SETrO_MSG(replybuf,
-*t2
-*t2
CC -*el
ADDRESSEE act: SETCC_MSG(replybuI,
GETCC--MSG(replybuf) + SADDRESSEE) -*e2
ADDRESSEE act: SETCC_MSG(replybuI,
GETCC--MSG(replybuf) + $ADDRESSEE) -~.e2
ANY -*end
FIGURE 5. Text Representation of Figure 3.
R~ply ::=
GETTO_MSG(replybuf) +SADDRESSEE) I
extraccs ::=
C C ccaddressee ecaddressee*
ccaddressee ::= A D D R E S S E E ~act: SETCC_MSG(replybuf,
GETCC.-MSG(replybuf) + SADDRESSEE) I
FIGURE 7.
BNF Specification of the "Reply" Command.
Communications of the ACM
263
RESEARCHCONTRIBUTIONS
F i g u r e s 6 a n d 7 s h o w t h e s a m e c o m m a n d s in BNF n o t a tion. L o w e r c a s e n a m e s d e n o t e n o n t e r m i n a l s y m b o l s ,
w h i c h are s u b s e q u e n t l y d e f i n e d in t e r m s of t e r m i n a l s y m bols. U p p e r c a s e n a m e s are t e r m i n a l s y m b o l s , w h i c h
w o u l d b e d e f i n e d in a s e p a r a t e , l o w e r - l e v e l s p e c i f i c a t i o n .
S o m e d e f i n i t i o n r u l e s are a n n o t a t e d w i t h B o o l e a n c o n d i tions, s y s t e m r e s p o n s e s , or a c t i o n s , all p l a c e d in b r a c e s . If
a rule c o n t a i n s a c o n d i t i o n , t h a t c o n d i t i o n m u s t b e t r u e at
t h e p o i n t in t h e i n p u t s t r e a m c o r r e s p o n d i n g to its p o s i t i o n
in t h e rule f o r t h e rule to b e m a t c h e d . W h e n a rule is
m a t c h e d , t h e s y s t e m will d i s p l a y t h e r e s p o n s e a n d perf o r m t h e a c t i o n , if a n y are given.
The special token NULL represents no input. A token
or n o n t e r m i n a l n a m e f o l l o w e d b y a n a s t e r i s k s t a n d s f o r
" z e r o or m o r e i n s t a n c e s of" t h a t s y m b o l . T h e o t h e r c o n v e n t i o n s u s e d in t h e a c t i o n s a r e t h e s a m e as t h o s e for t h e
state diagrams above.
T h e s p e c i f i c a t i o n s in t h i s n o t a t i o n c o u l d h a v e b e e n produced automatically from those above, but the resulting
s p e c i f i c a t i o n s w o u l d b e d i f f i c u l t to read, as d i s c u s s e d below. F i g u r e s 2 a n d 3 w e r e t r a n s l a t e d b y h a n d to p r o d u c e
F i g u r e s 6 a n d 7, a n d s e v e r a l n o n t e r m i n a l s t h o u g h t to b e
h e l p f u l in u n d e r s t a n d i n g t h e s p e c i f i c a t i o n w e r e i n t r o d u c e d in t h e p r o c e s s .
CONCLUSIONS
F r o m e x a m i n i n g t h e s e a n d o t h e r e x a m p l e s , o n e c a n observe that, while the techniques based on BNF and those
based on state transition diagrams are formally equivalent, t h e i r s u r f a c e d i f f e r e n c e s h a v e a n i m p o r t a n t e f f e ~ o n
t h e c o m p r e h e n s i b i l i t y of t h e s p e c i f i c a t i o n s . In p a r t i c u l a r ,
notations based on state transition diagrams explicitly
c o n t a i n t h e c o n c e p t of a s t a t e a n d t h e t r a n s i t i o n r u l e s
a s s o c i a t e d w i t h it, w h i l e t h i s is i m p l i c i t in B N F - b a s e d
n o t a t i o n s . S i n c e t h e c o n c e p t of s t a t e is i m p o r t a n t i n r e p r e s e n t i n g s e q u e n c e in t h e b e h a v i o r of a n i n t e r a c t i v e s y s t e m ,
s t a t e d i a g r a m s are p r e f e r a b l e to B N F i n t h i s regard.
Existing techniques based on state diagrams vary cons i d e r a b l y in t h e i r s y n t a x a n d e x p r e s s i v e ability, a l t h o u g h
it is p o s s i b l e to c o m b i n e t h e d e s i r a b l e f e a t u r e s of s e v e r a l
such notations into a new technique. The state diagrams
shown above represent such a synthesis.
W h i l e t h e t e x t r e p r e s e n t a t i o n s of t h e s t a t e d i a g r a m s a r e
s o m e w h a t m o r e d i f f i c u l t to r e a d t h a n t h e g r a p h i c a l o n e s ,
t h e y are a m o r e c o n v e n i e n t f o r m of c o m p u t e r i n p u t . T h e y
d o c o n t a i n s u f f i c i e n t i n f o r m a t i o n to g e n e r a t e t h e g r a p h i c
d i a g r a m s a u t o m a t i c a l l y (as w a s d o n e h e r e ) a n d to d r i v e a
s i m u l a t o r of t h e u s e r i n t e r f a c e ( w h i c h h a s r e c e n t l y b e e n
built).
In e i t h e r s t a t e d i a g r a m or B N F n o t a t i o n , t h e j u d i c i o u s
use a n d c h o i c e of m e a n i n g f u l n o n t e r m i n a l s y m b o l s is imp o r t a n t to t h e o v e r a l l c l a r i t y of t h e s p e c i f i c a t i o n , s o m e t i m e s m o r e so t h a n t h e c h o i c e of n o t a t i o n . T h e p r i n c i p a l
d i f f e r e n c e b e t w e e n t h e t w o t y p e s of n o t a t i o n s in t h i s reg a r d is t h a t a B N F - b a s e d s p e c i f i c a t i o n w i t h v e r y f e w n o n t e r m i n a l s ( w i t h r e s p e c t to t h e c o m p l e x i t y of t h e s y s t e m ) is
g e n e r a l l y m o r e d i f f i c u l t to u n d e r s t a n d t h a n t h e c o r r e s p o n d i n g s t a t e d i a g r a m . T h u s a d i r e c t t r a n s l a t i o n of a
t y p i c a l B N F s p e c i f i c a t i o n i n t o s t a t e d i a g r a m n o t a t i o n is
likely to c o n t a i n m a n y v e r y s i m p l e d i a g r a m s ; w h i l e a t y p i cal s t a t e d i a g r a m t r a n s l a t e d into BNF will c o n t a i n o n l y a
few, v e r y c o m p l i c a t e d rules. BNF, t h e n , r e q u i r e s m o r e
n o n t e r m i n a l s to m a k e it r e a d a b l e .
A s y n t h e s i s of t h e f e a t u r e s of s e v e r a l s t a t e d i a g r a m b a s e d n o t a t i o n s w a s t h u s s e l e c t e d to s p e c i f y t h e u s e r int e r f a c e for a p r o t o t y p e m i l i t a r y m e s s a g e s y s t e m . T h e ex-
266,
Communications o f t h e A C M
plicit d e s c r i p t i o n of s t a t e s in t h i s n o t a t i o n m a k e s t h e seq u e n c e of a c t i o n s c l e a r e r t h a n in BNF. In a d d i t i o n , s o m e
of t h e s t a t e s c o r r e s p o n d to u s e r s ' o w n n o t i o n s of w h a t a
s y s t e m d o e s ( " t e x t e n t r y " state, " l o g g e d - o u t " state). T h e
s t a t e d i a g r a m e x a m p l e s s h o w h o w a p o r t i o n of t h e U s e r
A g e n t c a n b e s p e c i f i e d in t h i s m a n n e r . A n i n t e r p r e t e r h a s
b e e n d e v e l o p e d to t a k e s u c h a s p e c i f i c a t i o n d i r e c t l y a n d
e x e c u t e t h e s p e c i f i e d u s e r i n t e r f a c e , i s s u i n g ICL c o m m a n d s to t h e r e s t of t h e m e s s a g e s y s t e m .
Acknowledgments
This work has benefited from discussions with my colleagues on the Military Message System
project: M. C o r n w e l l , C. H e i t m e y e r , a n d C. L a n d w e h r ,
a n d w i t h L. C h m u r a .
REFERENCES
1. Conway, M.E. Design of a separable transition-diagram compiler.
Comm. ACM S, 7 (July 1963), 396-408.
2. Dijkstra, E.W. A Discipline of Programming. Prentice-Hall, Englewood
Cliffs, N.J., 1976, pp. 209-217.
3. Embley, D.W. Empirical and formal language design applied to a
unified control construct for interactive computing. Int. I. ManMachine Studies 10, 2 (March 1978), 197-218.
4. Foley, J.D. and Wallace, V.L. The art of graphic man-machine
conversation. Proceedings of the IEEE 62, 4 (April 1974), 462-471.
5. Hanau, P.R. and Lenorovitz, D.R. Prototyping and simulation tools for
user/computer dialogue design. Computer Graphics 14, 3 (July 1980),
271-278.
6. Heitmeyer, C.L. and Wilson, S.H. Military message systems: Current
status and future directions. IEEE Transactions on Communications
COM-2S, 9 (Sept. 1980), 1645-1854.
7. Heitmeyer, C.L. An intermediate command language (ICL) for the
family of military message systems. Technical Memorandum 7590450:CH:ch, Naval Research Laboratory, Washington, D.C., 13 Nov.
1981.
8. Heitmeyer, C.L., Landwehr, C.E., and Cornwell, M.R. The use of quick
prototypes in the military message system project ACM SIGSOFT.
Software Engineering Notes 7, 5 (Dec. 1982).
9. Hueras, J.F. A forrhalization of syntax diagrams as k-deterministic
language recognizers. M.S. thesis, Computer Science Dept., Univ.
California, Irvine, 1978.
10. Jacob, R.J.K. Survey and examples of specification techniques for user
interfaces. NRL Report, Naval Research Laboratory, Washington, D.C.,
(To appear).
11. Johnson, S.C. Language development tools on the Unix system. IEEE
Computer 13, 8 (Aug. 1980), 16-21.
12. MUMPS Development Committee. MUMPS language standard.
American National Standards Institute, New York, 1977.
13. Moran, T.P. The command language grammar: A representation for the
user interface of interactive computer systems. Int. 1. Man-Machine
Studies 15, 1 (July 1981), 3-50.
14. Parnas, D.L. On the use of transition diagrams in the design of a user
interface for an interactive computer system. Proc. 24th Nat'l ACM
Conference (1989), 379-385.
15. Reisner, P. Formal grammar and human factors design of an
interactive graphics system. IEEE Trans. Software Eng. SE-7, 2 (March
1981), 229-240.
16. Shneiderman, B. Multi-party grammars and related features for
defining interactive systems. IEEE Trans. Systems, Man, and
Cybernetics SMC-12, 2 (March 1981), 148-154.
17. Singer, A. Formal methods and human factors in the design of
interactive languages. Ph.D. dissertation, Computer and Information
Science Dept., Univ. Massachusetts, 1979.
18. Wilson, S.H,, Kallander, J.W., Thomas, N.M, III, Klitzkie, L.C., and
Bunch, J.R, Jr. MME quick look report. Memorandum Report 3992,
Naval Research Laboratory, Washington, D.C., 1979.
19. Woods, W.A. Transition network grammars for natural language
analysis. Comm. ACM 13, 10 (Oct. 1970), 591-606.
CR Categories and Subject Descriptors: D.2.2 [Software Engineering]:
Tools and Techniques--user interfaces; H.1.2 [Models and Principles]:
User/Machine Systems--human factors: F.3.1 [Logics and Meanings of
Programs]: Specifying and Verifying and Reasoning about Programs-specification techniques
General Terms: Human Factors, Languages, Design
Additional Key Words and Phrases: interactive languages, specification
languages, state transition diagrams, BNF, user agent
Received 3/82; revised and accepted 12/82
April 1983
Volume 26
Number 4