Executable Specifications for a Human-Computer Interface (1983)
| Venue: | Proc. ACM CHI'83 Human Factors in Computing Systems Conf |
| Citations: | 10 - 2 self |
BibTeX
@INPROCEEDINGS{Jacob83executablespecifications,
author = {Robert J. K. Jacob},
title = {Executable Specifications for a Human-Computer Interface},
booktitle = {Proc. ACM CHI'83 Human Factors in Computing Systems Conf},
year = {1983},
pages = {28--34},
publisher = {ACM Press}
}
OpenURL
Abstract
It is useful to be able to specify a proposed human-computer interface formally before building it, particularly if a mockup 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 sys-tem application. An interpreter that executes the resulting specification ~s then described. Some 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 non-deterministic model, constraints necessary to realize the system with a deterministic interpreter are given. Writing a formal specification of the user interface of a computer system before building it permits the interface designer to consider a variety of possible user interfaces and describe them precisely and compactly without actually having to code them. It also permits the appli-cation of human performance models to the specifications to obtain information about the user interfaces they describe before building them [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 pro-totype or mockup of the user interface of the proposed system can be constructed directly from the specification. Problems with the pro-posed user interface can then be identified early in the design process, when they are easier to fix. While many prcspective users will f_nd a for-mal specification of a proposed system difficult to understand, they will have much less trouble evaluating a mockup system and identifying deficiencies in its user interface, both through informal demonstrations and formal experi-







