K*: A FORTRAN-BASEDCODE FOR PROGRAMMING AND EVALUATING INTERACTIVE SOFTWARE D. F. Redmiles Mathematical Analysis Division National Bureau of Standards Washington, D. C.

ABSTRACT of the Communications of the ACM (3). That issue is devoted entirely to the human-computer interface. K* (read kay-star) is an experimental library of The problem of implementing good, error-free code FORTRAN 77 subroutines that simplifies the design and has received even attention (4). Economic (5), implementation of -driven interactive programs. social (6), and mathematical (7) considerations have K* gives program designers a way to evaluate and each been applied to the problem of cost-effectively modify easily the user interface. Also, it relieves delivering working software. programmers of coding many tasks associated with user K* combines the ideas of modern programming prac- interaction. tices and of formally specifying the user interface. The K* library and the programming methodology it Unlike the grammars used in the research cited above, uses are designed with %idn to "largen sized applica- the specification language used by K* is designed to tions in mind. This paper first describes K* and under serve easily several purposes discussed later. circumstances K* is useful; second, it Moreover, the K* subroutines with code imple- presents an example implementation of an interactive mentation by providing FORTRAN subroutines that per- program. form most of the functions needed in the human inter- face and by encouraging a modular code design. KEYWORDS

Command interpreter; data structure; formal DESCRIPTION language; FORTRAN 77; human interface; LISP; ; relational database; software engineering; COMPONENTS structured programming. K* (K: command intepreter; *: generalized) is a package of FORTRAN 77 subroutines that support a gen- INTRODUCTION eral command interpreter. For a particular interac- tive program, the programmer supplies K* with a A common form of interactive computer program is wdescriptiontlfile of the user interface and with the command interpreter. A command interpreter is a application dependent subroutines. The description program that prompts a user for a command, carries out gives K* a map of the available commands and the given command, and returns to the original prompt- other user interactions. When it executes, K* uses ing mode awaiting further instructions. the description file to interpret user commands. K* The command interpreter style occurs in programs calls on the application subroutines to execute the across many disciplines and all levels of computer commands. programming; e.g., CAD/CAM programs, operating sys- The description file is specified in a language tems, and text editors. Builders of interactive pro- called LEMM (Linear Encoding for Multi-Media), origi- grams face a double problem: they must both design a nally developed for representing scientific data (8) good user interface and implement an error-free code. at the suggestion of Don J. Orser. Loosely, LEMM is a The way command interpreters interact with their list encoding of a relational database record (9); human users has long been the focus of research (1). its form is designed to be invariant over various com- Within the past few years, the theory of formal puter storage media; i.e., disk, tape, printout. languages has been used to develop grammars solely for The LEMM description file contains the names of implementing and evaluating the interactions between a commands, their arguments, prompt messages, and help user and a command-driven program (2). messages. Some commands have subcommands with addi- Such research is described in the April 1983 issue tional arguments and messages. Each command has an associated sequence number that K* uses at run- to Finally, the K* subroutines which control the and execute user-supplied subroutines that per- interaction with the user may be enhanced to handle form the specific command. more elaborate styles of interaction. Such modifica- Thus for each command, the applications programmer tions could be made without having to disturb an is expected to supply one or more subroutines. He application% code. must also provide one master subroutine to coordinate all calls. APPLICATION Using the LEMM description file, K* prompts the user for a command, verifies its existence, collects So far, the reader has learned about the com- its arguments on a stack, and passes the command's ponents, usage, and benefits of K*. Seven steps for sequence number and stack of arguments to the master applying K* to a problem are now presented. call subroutine. The master call subroutine then These steps may be thought of as the K* program- passes the arguments to the appropriate command sub- ming methodology. routine. 1. Specify the problem task. USAGE AND BENEFITS 2. If an interactive command interpreter is appropriate, decide on a selection of com- By design, K* is intended for implementing command mands. interpreter programs. Hence, K* is not currently 3. out command names, prompts, and help appropriate for all styles of interactive programs, messages in a LEMM description file. just command-driven ones. 4. Use Kits "dummyw program to walk-through Using the K* package seems at first to incur the proposed interactions. unnecessary trouble. This point is conceded in the 5. Revise the commands and repeat step 4 case of a small, isolated program. However, for large until the command selection and options problems, the benefits of using K* begin to outweigh seem satisfactory. its overhead. 6. Draft a user's guide for the proposed sys- Note the use of the word "problem" as opposed to tem. T'program". The solution to one problem may call for 7. Add FORTRAN code segments as desired, several small programs. K* facilitates the planning debugging each command function as added. and maintenance of a set of programs by imposing a UI.- :arm implementation. Separately specifying the user interactions in the EXAMPLE LEMM description file emphasizes the importance of the user interface. The LEMM description file serves PROBLEM STATEMENT other purposes as well. Since the LEMM description file removes the vari- It was mentioned in the introduction that a ous user interactions from a program's code, changes computer's operating system exemplifies the command to the command names, prompts, and help messages may interpreter programming style. To demonstrate K*, the be made without recompiling the code. Such modifica- implementation of a simplified example operating sys- tions can be made using an ordinary text editor; no tem will be presented. The example operating system programming effort is required. should provide commands for editing, printing, and K* has a facility for allowing program designers enumerating files. The editor should be capable of to walk-through the program interactions before any inserting, printing, and deleting lines. supporting code is written. Thus program designers The programming will be simplified by permitting can evaluate and refine a design before its implemen- files to be limited in size and kept in memory. tation. When coding begins, not all commands have to be COMMAND SET implemented at once. If commands and subcommands are thought of as program modules (lo), the LEMM descrip- The requirements of the example problem can be tion file may be viewed as a map of the programming satisfied with operating system commands "edU, task. The hierarchy of program modules is recorded in "printu, and "dir" for editing, printing, and this map in the command/subcommand hierarchy. Pro- enumerating (getting a directory of) files respec- grammers may implement modules as appropriate. The tively. The editor commands "input", "print", and modular approach lessens the problems of program "delete" will be for inserting, printing, and deleting maintenance and debugging. lines respectively. Since K* knows which applications subroutines to There should also be clean ways of terminating the call for which commands and subcommands, the run-time operating system and editor. Hence the commands relation of modules is "flattened". Specifically, at ftshutdowntqto stop the operating system and "" for execution time, no command's subroutine depends on leaving the editor are added. another command's subroutine being in computer memory The arguments for the operating system commands at the same time. Thus planning of memory linkages or are obvious: "edW and "print" need file names; "dirU even memory map overlays is simplified. and "shutdownw need nothing. Internal to the K* code are many subroutines for However, in the editor, "input", "print", and manipulating list structures (11) that K* calls to "deletev need to know where to input, what lines to read the LEMM encoding and to use it. The basic list print, and what lines to delete. By adding the con- subroutines are patterned after implementations of the cept of a current line pointer, any confusion can be LISP programming language (12, 13). The LEMM subrou- eliminated: vtinputvtcan be assumed to follow the tines use ideas from Minsky's frames (14, 15). K* is current line; "deleten and "print" can work with the built to allow a programmer to call these list subrou- number of lines following the current line. tines directly from his application code. Thus K* becomes especially attractive if an application can LEMM DESCRIPTION FILE benefit from using data structures more flexible than FORTRAN scalars and arrays. The above selection of commands can now be specified in a LEMM description file. Command prompts eos and help messages will also be included along with (name: eos sequence numbers that let K* associate command names sequence: 100 with subroutines. The LEMM description file for the parameter: example operating system is listed in Figure 1. This (prompt-message: " are yout' listing shows two LEMM sentences. The first defines help-message: "Give your user name, & the object "eosn which stands for "example operating e.g. Bilbo.") systemv. The second defines the object nline-editortt. commands: Parentheses group items into lists. Sublists (prompt-message: "yestt (lists within lists) provide greater levels of detail. help-message: "Enter an operating & Words immediately followed by colons are attri- system command; & butes, the properties by which an object is defined. /"HELP/" for the & The remaining words and literals serve as values to selection. these attributes. choice[ll: The reader should now have a rough understanding (name: dir of the way LEMM sentences define commands. sequence: 101) The word "line-editoru in the "eosW object could choiceL21: line-editor be replaced by the actual line-editor sentence. choiceC31: Separating the two objects demonstrates part of LEMM's (name: print flexibility, allows the option of reusing easily the sequence: 102 line editor subcommand in another application, and parameter: emphasizes K*'s use of an identical representation for (prompt-message: ttFilett subcommands and main programs. help-message: ItEnter the name of & This self-similar nature of K* allows it to exe- the file you want to print.")) cute subcommands to any depth. Corresponding LEMM choiceC41: sentences and FORTRAN modules for the commands may be (name: prepared without undue consideration of the level at sequence: 103))) which the program may call them. line-editor WALK-THROUGH (name: sequence: 200 After the LEMM description file is entered into parameter: the computer, a program designer can "walk-throughn (prompt-message: "Filen the proposed commands to evaluate the design from the help-message: "Give the name of the & user's point of view. file you want to edit.") commands: PROGRAM EOS (prompt-message: "don Implicit declarations help-message: "Enter an editor command;& INCLUDE lC-.macforlimplicit.incq / type help for a list & Master call subroutine name of available commands.tt EXTERNAL Kfprog choice[ll: Initialize K* package (name: input CALL MaciniO sequence: 201) CALL KstiniO choiceE21: Read in the LEMM description file (name: go PRINT *,'Tell me the file name of thet sequence: 202 PRINT *,'LEMM encoding of your1 parameter: PRINT *,'operating system.' (prompt-message: "wherem READ *,cfile help-message: "Give the line & number where you & OPEN (UNIT-~,FILE=C~~~~,STATUS=~OLD') want to move.")) ilastu = Mnunt(8) choiceC31: nos = Lreadcicond) (name: print yeffct = Lreadcicond) sequence: 203 ilastu = Mnunt(i1astu) parameter: CLOSE(i1ast.u) (prompt-message: "how manytt activate the K* generalized command help-message: "Give the number of & interpreter, supplying it with a LEMM lines to be printed.")) representation of the interactions and choiceL41: the name of a master call subroutine. (name: delete yeffct = Kstar(nos,Kfprog) sequence: 204 parameter: END (prompt-message: "how manyn help-message: "Give the number of & Figure 2: main program for walking- lines to be deleted.")) through the eos commands. choiceC51: (name: exit A short program, listed in Figure 2, passes the sequence: 205))) LEMM eos object to K* with the name of a master call subroutine. K* uses the master call routine to invoke the functions corresponding to the user's request. Figure 1: LEMM description file for the For a walk-through, K* supplies a dummy master example operating system. call routine which satisfies the FORTRAN compiler but executes no commands (see Figure 3). With almost no and of the editor. Their list representation is sug- programming, a designer can evaluate messages and gested in the included diagram. the adequacy of the proposed command set. $ run walk INTEGER FUNCTION Kfprog(iseq,pargsk, Tell me the file name of the + iccode) LEMM encoding of your * operating system. supposed to call the subroutines that lprogf actually implement the commands. This Who are you? * version of Kfprog simply returns. Its Joe sole use is for walking through the interactions outlined in the LEMM ? representation of the command {user enters a blank line3 interpreter. Enter an operating system command; type "HELP" for the selection. INCLUDE I[-.macforlimplicit.inc' HELP INCLUDE I[-.macforlmacats.incf commands prompt-message help-message INCLUDE f[-.macforlmaccds.inc' dir * ed File Give the na~eof iccode standard condit!on code the file you want iseq sequence number specifying a to edit. command print File Give the name of * pargsk stack of arguments for a command the file you want t to print. shutdown iccode = IOKCC pargsk = NIL yes? Kfprog = NIL dir END yes? Figure 3: Kits dummy master call routine. dir

A walk-through of the example LEMM file is shown yes? in Figure 4. Notice some features of the K* inter- djfkj face: tfhelp'f is built-in, commands may be entered eos doesn't recognize djfkj without format restraints, some error checking is built-in, commands and arguments may be typed on the yes? same line, no argument is requested unless it is ed file-1 required and has not been supplied. do? REVISION input

A revision made after the original walk-through do? was the renaming of the editor's print command. Ori- go print all ginally, this command was called tttypetf but during the walk-through, it became apparent "printw was more con- sistent in view of the operating system print command. do? print USER'S GUIDE how many? 5 A user's guide could have been drafted after deciding on the command set. By waiting until after do? the walk-through, a program designer can take advan- ... tage of any ideas gained from becoming momentarily a user. Figure 4: dummy walk-through The user's guide for the example operating system is Appendix A. The main program passes K* the LEMM file of Fig- This guide was the principal specification fol- ure 1 and the master call routine, "Iosprgn. lowed for programming the example problem. For large When Kf identifies the command requested by the problems, various design strategies are available (16, user and collects its arguments into a stack, it calls 17). Iosprg. Iosprg splits into two subroutines, "Ioscomn for FORTRAN calling operating system commands and "Jedcomn for calling editor commands. These routines invoke a - The example operating system has been implemented ticular command subroutine as indicated by the by taking advantage of the subroutines for manipulat- sequence number. ing list structures. Finally, two command subroutines are listed: Selected sections of the code are listed in Appen- tfIshutn for the operating system command, nshutdownn; dix 9. The "includett statement is the only non- and "Igon for the editor command, t*gon. Ishut illus- standard FORTRAN 77 statement: it inserts text from trates the use of the condition code for signaling K* another file. to finish a command level, in this case, the main pro- The first code segment defines the global vari- gram. Igo illustrates heavy use of the list subrou- ables that maintain the state of the operating system tines and the global variables. An execution of the complete system is listed in National SAMPE Symposium Exhibition, Appendix C. Note how closely the walk-through of Fig- Reno, April 1984, pp. 1450 - 1464. ure 4 simulates the actual session. Ullman, Jeffrey D., Principles of Database Sys- tems, Computer Science Press, Rockville, 1982, p. 19. SUMMARY Shooman, Martin L., Software Engineering, McGraw-Hill Book Company, New York, 1983, p. K* is a library of FORTRAN 77 subroutines for pro- 107. gramming and evaluating command-driven, interactive Standish, Thomas A., Data Structure Techniques, programs. Addison-Wesley Publishing Company, Reading, The K* subroutines support programming by automat- 1980, p. 185. ing the user interface and supplying routines for Meehan, James R., The Neu UCI LISP Manual, manipulating list structures. In addition, K* Lawrence Erlbaum Associates, Hillsdale, prescribes a programming methodology based on modern 1979. programming practices. McCarthy, John, et. al, LISP 1.5 Programmert? K* requires separation of the user interactions Manual, The M.I.T. Press, Cambridge, 1965. from the code. This separation encourages careful Minsky, Marvin, "A Framework for Representing consideration and adjustment of the user interface, Knowledgett, in The Psychology of computer especially with the aid of walk-throughs before coding Vision, edited by Patrick Henry Winston, begins. Also, the interactions file enhances the pro- McGraw Hill Book Company, New York, 1975, p. gramming specifications. 211. The K* user interface subroutines may be modified Winston, Patrick Henry and Berthold Klaus Paul without disturbing an application. Horn, LISP, Addison-Wesley Publishing Com- K* allows applications programmers to implement pany, Reading, 1981, pp. 291 - 314. command-driven programs in a uniform fashion, without Basili, Victor R., "Structured Program Designw, the burden and hazard of writing code for the user reprinted in Tutorial Structured Program- communication. ming: Integrated Practices, edited by Victor R. Basili and F. Terry Baker, IEEE Computer Society, Los Alamitos, 1981, pp. 111 - 120. ACKNOWLEDGEMENTS Griffiths, S. N., "Design Methodologies -- A Com- parison", reprinted in Tutorial: Software I thank Anthony P. Date1 for his help in designing Design Strategies, edited by Glenn D. Berg- and programming K*, and Martin Knapp-Cordes for his land and Ronald D. Gordon, IEEE Computer technical assistance. Society, Long Beach, 1979, pp. 189 - 213.

REFERENCES

Foley, J. D. and V. L. Wallace, "The Art of Natural Graphic Man-Machine Conversation", Proceedings of the IEEE, vol. 62, no. 4, * The names of computer hardware and * April 1974, pp. 462 - 471. software mentioned in this paper are * Moran, T. P., "The Command Language Grammar: A intended only for communication Representation for the User Interface of * purposes. Such mention should not * Interactive Computer Systemsn, International * be construed as endorsement by t Journal of Man-Machine Studies, vol. 15, no. * either the author or his institution. * 1, July 1981, pp. 3 - 50. * Jacob, Robert J. K., "Using Formal Specifications ...... in the Design of a Human-Computer Inter- facett,Communications of the ACM, vol. 26, no. 4, April 1983, pp. 259 - 264. Boehm, B. ., "Seven Basic Principles of Software Engineering", The Journal of Systems Software, vol. 3, no. 1, March 1983, pp. 3 - 24. Boehm, B. W., "Software Engineering Economics", IEEE Transactions on Software Engineering, vol. SE-10, no. 1, January 1984, pp. 4 - 21. Baker, F. T., "Chief programmer team management of ~roduction oronramminntt, reorinted in

~utoiial on ' ~tructured. p;ogramming: Integrated Practices, edited by Victor R. Basili and F. Terrv Baker. IEEE Comouter Society, Los Alamitos, 1981, pp. 255 - 273. Mills, Harlan D., "Mathematical Foundations for Structured Programmingtt, reprinted in Tutorial on Structured Programming: Integrated Practices, edited by Victor R. Basili and F. Terry Baker, IEEE Computer Society, Los Alamitos, 1981, pp. 42 - 107. Bhansali, Kirit J., et. al., "Database Develop- ment under the ASM/NBS Program on Alloy Phase Diagramsu, Proceedings of the 29th