00001.tif

PDF

Download

Open document

Transcript (if available)

Content SPECIFICATION AND RAPID PROTOTYPING OF USER INTERFACES by C h r is to p h e r Andrew R ouff A D i s s e r t a t i o n P r e se n te d to th e FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In P a r t i a l F u l f i l l m e n t o f th e R equirem ents fo r th e Degree DOCTOR OF PHILOSOPHY (Computer S c ie n c e ) A ugust 1991 C op yrigh t 1991 C h r is to p h e r Andrew R ouff UMI Number: DP22832 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. Dissertation Publishing UMI DP22832 Published by ProQuest LLC (2014). Copyright in the Dissertation held by the Author. Microform Edition © ProQuest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106- 1346 UNIVERSITY OF SOUTHERN CALIFORNIA p J L „t>. THE GRADUATE SCHOOL 1 UNIVERSITY PARK C p S LOS ANGELES, CALIFORNIA 90089-4015 . ' 9 1 R BS* c A H ' This dissertation, written by Christopher Andrew Rouff under the direction of h is Dissertation Committee, and approved by all its members, has been presented to and accepted by The Graduate School, in partial fulfillment of re quirements for the degree of DOCTOR OF PHILOSOPHY Dean of Graduate Studies D a te.......June, 12.,,. 12 21. DISSERTATION COMMITTEE Chairperson C o n ten ts L ist o f F igu res vii L ist o f T ables x A b stra ct xi 1 S u rv ey o f R eq u irem en ts A n a ly sis 1 1.1 Introduction . . . .............................................................................................. 1 1.1.1 Requirem ents Analysis . ............................................................... 2 1.1.2 Problem D e fin itio n ............................................................................. 3 1.1.3 Software Specification ....................................................................... 4 1.2 C urrent M ethods for Specifying User I n te r f a c e s ................................... 5 1.2.1 Transition Diagrams ...................................... 5 1.2.2 D ata A bstraction M e th o d s ........................................................ 7 1.2.3 T e m p la te s ................................ 9 1.2.4 Formal Gram m ars ............................................................................. 11 1.2.5 P r o to ty p in g ..................... 13 1.2.6 Advantages and Disadvantages of Current M e th o d s ............... 23 1.3 Research D ir e c tio n ........................................................................................... 25 2 A Form al M o d el for S p ecify in g U ser Interfaces 28 2.1 Previous Models Used for Specifying User In te rfa c es............................ 28 2.1.1 Overview of Transition Diagrams ................................... 28 2.1.2 Overview of S ta t e c h a r t s .................................................................. 30 2.2 Interface Representation G ra p h s .................... 36 ii 2.2.1 Interface Components ....................................................................... 37 2.2.2 Flow of C o n tr o l..................................................................................... 42 2.2.3 D ata in an I R G ..................................................................................... 44 2.3 Formal Definition of Transition Diagrams, Statecharts, and IRGs . . 46 2.3.1 Formal Definition of Transition D iag ram s..................................... 46 2.3.2 Formal Definition of S ta te c h a rts ..................................................... 47 2.3.3 Formal Definition of I R G s ............................................................... 50 2.4 M apping User Interfaces onto I R G s ........................................................... 53 2.4.1 Definition of a User Interface ......................................................... 53 2.4.2 User Interface C om ponents................................................................ 55 2.4.3 User Interface Flow of C o n tro l......................................................... 58 2.5 Advantages of IRGs for Modeling User I n te r f a c e s ............................... 61 2.5.1 Node S t r u c t u r e .................................................................................... 62 2.5.2 Event D r i v e n ........................................................................................ 63 2.5.3 D ata F lo w ............................................................................................... 63 2.5.4 Constraints on D ata and Control F l o w ....................................... 64 2.5.5 D iv e rsio n s............................................................................................... 64 2.5.6 Separation of Interface and A p p licatio n ....................................... 66 2.6 Examples of User Interfaces and their IRGs ......................................... 67 2.6.1 Form Example .................................................................................... 67 2.6.2 M ultiple Window E x a m p le ................................................................ 74 2.6.3 M ultiple Window Concurrency E x a m p le .................................... 81 3 A n E n v iro n m e n t fo r S p ec ify in g U se r In te rfa c e s 88 3.1 Direct M anipulation L a n g u a g e s .................................................................. 88 3.1.1 Definition of Direct M anipulation L an g u ag es............................. 89 3.1.2 Examples of Direct M anipulation L a n g u a g e s............................. 91 3.1.3 Previous Uses of Direct M anipulation Languages in Specify ing User I n te r f a c e s ............................................................................ 93 3.2 An Environm ent for Specifying User In te rfa ce s..................................... 94 3.2.1 Specifying Windows .......................................................................... 96 3.2.2 Specifying F ra m e s....................................................................................100 iii 3.2.3 Arrays of O b je c ts ...................................................................................104 3.2.4 History F r a m e s ...................................................................................... 104 3.2.5 S e q u e n c e s.................................................................................................108 3.2.6 Specifying Window S e q u e n c e s.......................................................... I l l 3.2.7 R untim e Defined S e q u e n c e s ..............................................................113 3.2.8 Indexed S e q u e n c e s ............................................................................... 113 3.2.9 Specifying I n p u t s ...................................................................................113 3.2.10 Specifying E v e n ts ............................................................................ . 116 3.2.11 Event C o n d itio n s ...................................................................................121 3.2.12 Actions ....................................................................................................122 3.2.13 Specifying C oncurrency........................................................................ 125 3.2.14 Specifying a Divergence .....................................................................127 3.2.15 U tility F u n c tio n s ...................................................................................130 3.2.16 D ata D ictio n ary ......................................................................................132 3.3 M apping the Specified Interface onto IR D ’s ...........................................136 3.3.1 W indow s....................................................................................................136 3.3.2 F ra m e s....................................................................................................... 136 3.3.3 S e q u e n c e s ................................................................................................ 137 3.3.4 History F r a m e s ...................................................................................... 139 3.3.5 E v e n ts ....................................................................................................... 139 3.3.6 C o n d itio n s.................................................................................................141 3.3.7 Actions ....................................................................................................142 3.3.8 C oncurrency............................................................................................. 142 3.3.9 Divergent F ra m e s ...................................................................................142 3.4 Three Examples R e v is ite d ...............................................................................143 3.4.1 Form Example ...................................................................................... 143 3.4.2 Multiwindow E x a m p le ........................................................................ 152 3.4.3 Concurrency Between Windows E x a m p le ..................................... 158 4 C o n sisten cy and C o m p leten ess o f IR G s 162 4.1 C o n s iste n c y ............................................................. 162 4.1.1 M ultiple D estinations of S e q u e n c e s ................................................163 iv 4.1.2 Sequences W ith the Same Events and C o n d itio n s ...................... 163 4.1.3 M ultiple Starting N o d e s ..................................................................... 167 4.1.4 M ultiple Item s W ith the Same Nam e . . ........................................ 167 4.1.5 Intersecting Groups W ith the Same E v e n ts .................................. 168 4.1.6 Incom patible Types on D ata Constraints and Shared D ata . 168 4.1.7 Inherited N o d e s ...................................................................................... 170 4.2 C o m p le te n e ss..........................................................................................................170 4.2.1 Nodes W ith No Interaction .............................................................. 171 4.2.2 No S tart Node in a Parent N o d e ....................................................... 172 4.2.3 Incom plete T ra n s itio n s .........................................................................173 4.2.4 Incom plete Internal B r o a d c a s ts ....................................................... 174 4.2.5 Indexed Transitions Missing In d ic e s ................................................ 177 4.2.6 R untim e Nodes Missing Program S ta te m e n ts...............................177 4.3 Checking for Consistency and Completeness of an I R G ..........................177 4.3.1 Interactive Checking for Inconsistencies.........................................178 4.3.2 Static C h e c k in g ...................................................................................... 180 4.3.3 R untim e C h e c k in g ............................................................................... 183 5 C on clu sion 184 5.1 Interface Representation Graphs for Modeling User Interfaces . . . 184 5.1.1 Hierarchical S t r u c t u r e ........................................................................ 185 5.1.2 Grouping of O b j e c t s ............................................................................185 5.1.3 I n h e r ita n c e .............................................................................................185 5.1.4 Flow of C o n tr o l......................................................................................185 5.1.5 D ata F lo w ................................................................................................ 186 5.1.6 C onclusion................................................................................................ 186 5.2 Reduced Program m ing Prototyper ............................................................... 186 5.2.1 Flow of C o n tr o l......................................................................................187 5.2.2 Interface-A pplication Interface .......................................................187 5.2.3 Formal Model of In te ra c tio n ............................................................. 188 5.2.4 Sharing of S p ecificatio n s.....................................................................188 5.2.5 C o n s tr a in ts .............................................................................................188 v 5.2.6 Consistency and C om pleteness........................................................... 188 5.2.7 Removal of Designer From F o rm alism ............................................. 189 5.3 Further R e s e a r c h ................................................................................................. 189 5.3.1 R estricting D ev elo p m en t..................................................................... 189 5.3.2 M u ltis c re e n ..............................................................................................190 5.3.3 Temporal S p ecificatio n .........................................................................190 A p p en d ix 190 A R eq u irem en ts D efin itio n F orm ats 191 A .l M ilitary S ta n d a rd ................................................................................................. 191 A.2 English L a n g u a g e ................................................................................................. 194 B R eq u irem en ts S p ecifica tio n F orm ats 196 B .l M ilitary S ta n d a rd ................................................................................................. 196 B.2 IEEE S t a n d a r d .................... 198 C E x a m p les o f U ser In terface S p ecification s 201 C .l Transition Diagram Specification ..................................................................201 C.2 D ata A b s tra c tio n .................................................................................................204 C.3 T e m p la te s ...............................................................................................................208 B ib lio g ra p h y 213 VI L ist o f F igu res 1.1 Software Requirem ents Analysis in Software Lifecycle.......................... 2 1.2 Relationship of the three parts of a UIM S................................................. 15 1.3 Exam ple Slang code for calculator................................................................ 16 1.4 Exam ple of saddle code for a calculator..................................................... 17 1.5 Exam ple of C code for calculator.................................................................. 17 1.6 Calculator defined w ith Serpent.................................................................... 18 1.7 Exam ple of W interp source code................................................................... 21 2.1 Transition diagram of bookstore query system ......................................... 30 2.2 Statechart w ith transitions.............................................................................. 33 2.3 Two orthogonal nodes....................................................................................... 37 2.4 Exam ple of an IRG. . ................................................................................... 41 2.5 Interface described by above IR G ................................................................. 41 2.6 Transition diagram w ith transitions and nodes for help and error messages................................................................................................................. 65 2.7 The way diversions are handled in statecharts......................................... 66 2.8 D atabase operation fram e............................................................................... 69 2.9 T itle search fram e.............................................................................................. 70 2.10 Fram e for successful title query..................................................................... 71 2.11 Fram e when title query fails........................................................................... 72 2.12 Screen for FIG graphics editor....................................................................... 76 2.13 IRG for multiwindow user interface............................................................. 77 2.14 IRG for com m and window of multiwindow user interface.................... 78 2.15 IRG drawing window of multiwindow user interface.............................. 80 vii 2.16 Typing tu to r user interface.............................................................................. 82 2.17 IRG for concurrent window user interface.................................................. 83 2.18 IRG for typing window..................................................................................... 84 2.19 IRG for statistics window................................................................................. 85 3.1 Com ponents and structure of R P P ............................................................... 94 3.2 M ain window of the prototyping system ..................................................... 95 3.3 M ain window, window icons, and initial window..................................... 97 3.4 A ttributes window of the prototyping system ..............................................102 3.5 Exam ple of a history fram e................................................................................ 106 3.6 Exam ple of a global history fram e................................................................... 107 3.7 A sequence of fram es............................................................................................ 109 3.8 Exam ple of events th at can be selected for a sequence.............................I l l 3.9 Exam ple of actions th a t can be selected for a sequence........................... 112 3.10 An exam ple of a divergence used for a help window.................................... 129 3.11 An exam ple of a divergence used w ith a “hot key.” ................................. 131 3.12 Exam ple of fram e and window sequences as they are m apped into a statech art.................................................................................................................. 138 3.13 Exam ple of a statechart of a local history fram e w ith divergences. . 140 3.14 The statechart of a set of windows which using the range history fram es.........................................................................................................................141 3.15 Exam ple of m ultiple intersecting divergencies............................................. 144 4.1 Consistent frame sequence with m ultiple destination nodes in or thogonal com ponents.............................................................................................164 4.2 Inconsistent IRG w ith m ultiple destination nodes in non-orthogonal com ponents...............................................................................................................164 4.3 Inconsistent IRG w ith identical events...........................................................167 4.4 Two intersecting groups with identical events.............................................169 4.5 Incom plete IRG where a parent node does not specify a child as a start node..................................................................................................................173 C .l Top-level USE transition diagram of data dictionary................................202 C.2 Exam ple of a report generated w ith KSBASS............................................. 210 C.3 Tem plate for rep o rt............................................................................................... 211 C.4 Successor functions for report definition........................................................ 212 ix L ist o f T ables 1.1 Exam ple m ultiparty gram m ar of book query system ............................... 12 2.1 How window types are m apped onto the X Toolkit................................. 55 2.2 How interface components are m apped onto the X toolkit.................... 57 2.3 How flow of control of a user interface is m apped onto statecharts. . 58 2.4 Table of popup window item s and corresponding actions...................... 81 3.1 Values stored in file to be read in for search resu lt......................................148 3.2 Contents of file holding query results................................................................150 3.3 Specification of a popup window for the Fig graphics editor....................157 x Abstract This thesis presents a model for specifying and a system for rapidly prototyping user interfaces. The model represents the components, flow of control, constraints, and sem antic feedback of an interface while the system allows an interface to be prototyped w ith little or no programming. As a user interface is prototyped, a model of the interface is built th a t represents its structure and functionality. This model can then be compiled into a stand alone program w ith calls to the X windows and M otif libraries. The generated program is compiled and linked to application functions to produce an executable program. The model, IRGs (Interface Representation Graphs) differs from previous user interfaces models in th at it is designed for asynchronous m ultiwindow user inter faces. O ther models force an explicit flow of control between states of the interface and do not take into the account the im plicit flow of control th a t occurs between windows and objects in asynchronous user interfaces. IRGs provides for this im plicit flow of control as well as three other types of flow of control, a representation for the hierarchical structure of components, constraints between com ponents, and interaction with an underlying application. The system, R P P (Reduced Program m ing Prototyper), differs from other user interface builder or UIMS systems in th at it is based on a form al graph model, IRGs, while the others are based on program m ing languages. R P P also differs from other systems in th a t it allows complex sequencing, constraints, and the application interface to be defined interactively. O ther systems restrict interactive definitions to layout only and specify the dialogue in a program m ing language, thus requiring a program m er to learn yet another language. C h a p ter 1 S u rv ey o f R eq u irem en ts A n a ly sis 1.1 Introduction W hen developing a hardw are and software system the custom er and developers be gin by writing a docum ent th at describes the hardware and software components th a t will make up the system called a system specification [9] [11] [19] [44] [45] [56]. The system specification describes w hat is to be accomplished by th e system as a whole. This includes a cost analysis, a feasibility study, a prelim inary schedule, and an allocation of system functions to software and hardware. T he description of functions th a t are allocated to the software are called the software requirem ents definition and the hardw are function descriptions are called the hardw are require m ents definition. The hardw are and software definitions are then further analyzed to produce a detailed description of w hat is to be designed called the hardw are and software requirem ents specifications, respectfully. The process by which the specifications are generated from the requirem ents definition is called requirem ents analysis. This thesis will focus on the process of developing the software requirem ents specification of user interfaces from the software definition, called software require m ents analysis. In the rem ainder of this thesis all references m ade to requirem ents definition, requirem ents analysis or requirem ents specification refer to software re quirem ents definition, software requirem ents analysis and software requirem ents 1 Software Problem Definition System Concept Software Specification Systems Requirements Analysis_____ Software Design Software Requirements Analysis Figure 1.1: Software Requirem ents Analysis in Software Lifecycle. specification. T he rem ainder of this chapter will give an overview of software re quirem ents analysis, the current m ethods used in the requirem ents analysis of user interfaces and an outline of my research in this area. 1.1.1 R eq u irem en ts A n a ly sis Software requirem ents analysis is the step in software engineering th a t occurs be tween the systems requirem ents analysis and the software design [2] [8] [9] [17] [60] [73]. Requirem ents analysis takes as input the software problem definition and ultim ately produces as output the software specification, as illustrated in figure 1.1. This specification is then used as a contract between the developer and the custom er as to w hat is to be developed. Requirem ents analysis examines the prob lem definition of a software system so th a t the problem can be b etter understood and be rew ritten in a precise m anner suitable for the start of the software design phase. Requirem ents analysis’ m ain objective is to describe the external behavior of the proposed system [17]. It does this by decomposing the problem definition to determ ine the input data, the prim ary functions th at operate on the input data, the output d ata and defining any restrictions on the design. There are many m ethods for decomposing the problem definition into its constituent parts. W hat all requirem ents m ethods try to accomplish is to break a problem into its functional and nonfunctional requirem ents [58] [75]. The functional requirem ents explain what a function is to do w ithout describing how it is to be im plem ented. Functional decom position entails identifying the high order functions of the system and the 2 transform ations th a t the d ata goes through as it passes through the functions. The high order functions give the custom er and designer w hat the analyst thinks th e problem is. D ata decomposition accomplishes the same thing as functional decomposition except it uses the breakdown of the input d ata into the output d ata to ultim ately identify the functions th a t are perform ed on th e data. Nonfunctional requirem ents are those requirem ents th a t restrict the set of pos sible im plem entations. They consist of system interfaces, perform ance criteria, and th e use of such things as program m ing languages and design methodologies. Sys tem interfaces are interfaces to other pieces of d ata or hardw are th at the software has to com m unicate with. The perform ance criteria specifies how fast the software is to produce a quantity or how fast it needs to react in a real tim e situation. 1.1.2 P ro b lem D efin itio n The problem definition for a software system is the input to the requirem ents anal ysis. It gives a description of w hat is to be developed from the user’s point of view. The statem ent can be as simple as a natural language description of what is desired for a small system or it can be p art of a detailed system specification of which the software system is only one p art of a larger total system. The M ilitary Standard for Specification Practices refers to the problem definition as an A-spec[46]. It states th a t an A-spec: should state the technical and mission requirem ents for a system /segm ent as an entity, allocates requirem ents to functional areas, docum ents de sign constraints, and defines the interfaces between or among the func tional areas. As is stated in the above definition, the problem definition identifies the system com ponents, the interfaces between these components and any constraints th at will be m ade on the system (e.g., all software will be program m ed in Ada). An outline of the m ilitary standard A-spec is shown in Section A .l and an English language problem definition of a book store check out system is shown in Section A.2. The book store specification is used in m any of the examples in this paper to help illustrate the use of various requirem ents analysis notations and methodologies. 3 1.1.3 S oftw are S p ecifica tio n T he software specification is the result of the requirem ents analysis. T he specifi cation is a docum ent describing the function of the proposed software system . It should describe what is to be developed, not how it is to be im plem ented. The specification is the contract between the developer and the custom er on w hat is to be developed, how it is to perform and the output it is to generate. Good attributes of a software specification have been given by m any people, [2] [3] [4] [16] [58] [72] [73] are a few. The following are some of these attributes: C o n s is te n t - A specification should not contradict itself in different parts of the docum ent. T e s ta b le - It should be possible to determ ine the results of th e software test from the specification. C o m p le te - The specification m ust contain all the pertinent inform ation needed to im plem ent the system. F u n c tio n a l - The specification should describe only w hat needs to be imple m ented and not m ention how. M o d ifia b le - The specification should be w ritten in a structured m anner so th at it can be easily modified as the requirem ents change during the lifetim e of the project. U n d e r s ta n d a b le - The notation used in the specification should be clear to the custom er as well as the im plem entors of the system. The IEE E Standard num ber 830-1984 [3] and the M ilitary S tandard num ber DI-MCCR-80025 [43] are two standards for the form at of a software specification. Section B .l gives an outline and a description of the M ilitary Specification (B5- spec) th a t is required for all software developed for the D epartm ent of Defense and Section B.2 gives the outline of the software specification suggested by th e IEEE standard. 4 1.2 Current Methods for Specifying User Interfaces For m any program s th e user interface is an essential com ponent. W ith th e move towards bitm ap displays w ith mice for pointing, creating a user interface has be come a com plicated process. The following are five forms th a t have been used for specifying user interfaces: transition diagram s, d ata abstraction, tem plates/form s, formal gram m ars and prototyping. The following sections discuss and give exam ples of each of these. 1.2.1 T ra n sitio n D iagram s T he use of transition diagram s for the. specification of user interfaces has been proposed by several people [32] [31] [30] [54] [68] [69] [71]. The nodes of transition diagram s represent points where th e system will accept input from the user and th e transitions specify w hat input is needed to go from one node to another. The | j diagram s are augm ented to show sem antic actions th a t are to be perform ed at [ various tim es during th e interface by associating the actions w ith transitions of the diagram . Levels of abstraction are im plem ented by defining th e transition diagram s in a hierarchical fashion. The rem ainder of this subsection discusses the USE (User Software Engineering) user interface specification system developed by A nthony W asserm an which is based on the transition diagram model. T he USE user interface specification system is a m ethodology for th e speci fication of interactive inform ation systems using a hierarchical set of transition diagram s [72] [70]. Nodes represent waiting states for user input and contain the nam e of a message to be printed when the node is reached. The transitions are m arked w ith tokens th a t specify w hat input is needed to traverse it. Sem antic actions represented by num bered squares m ay also be associated w ith a transition which are executed when th e arc is traversed. The output message associated with the nodes are described in a textual notation in a supplem ent to th e diagram. The actual message to be displayed is listed in quotes w ith positioning inform ation th a t states the row and column of the screen it is to be printed on. For example, 5 a specification of a m enu for an autom ated bank teller m ight be given as: cs, r5, c5, ’Enter the number of the transaction to be performed: r + 4 , clO, ’ 1) Balance of checking’ r + 2 , clO, ’2) Balance of savin gs’ r + 2 , clO, ’3) Deposit to checking’ r+ 2 , clO, ’4) Deposit to savin gs’ r+ 2 , clO, ’5) Withdraw from checking’ r+ 2, clO, ’6) Withdraw from savings' The “cs” stands for clear screen, “r5” stands for row 5, “r+ 4 ” stands for the current row num ber plus four and “clO” stands for column ten. O ther cursor and screen form atting commands include reverse video, go to home position, new line, clear to end of line, clear to end of screen, scroll down, tab settings and m arking positions of the screen for later reference. Naming of messages is perm itted so messages can be reused in other parts of the specification by simply referencing the variable name. Input specified on a transition can be declared as buffered or unbuffered in put. Buffered input is term inated by a carriage retu rn (or other term inator) and is shown in quotes on the transition. Unbuffered inputs can take the form of a single character or control/escape characters which are prepended by an exclam a tion m ark. Special keys can also be defined th at in terru p t the current processing and restart the processing at a different predefined node. This saves the specifier from having to add transitions from every node to the special node to handle the interrupt. USE transition diagram s also contain a mechanism called a subconversation which is sim ilar to a subroutine call in conventional program m ing languages. A sub conversation is specified using a rectangle instead of a circle. W hen a rectangle is encountered during a traversal, the traversal of the current diagram stops and traversal of the subconversation is started. W hen a sub conversation reaches a final state it returns to th e node after the node th a t called it. A sub conversation can 6 also retu rn a value to the calling diagram to indicate exit inform ation (such as error inform ation). Subconversations are used when the description of the input string is complex and its syntax is not im portant to the understanding of th e current diagram . USE also contains a rapid prototyping facility th a t consists of a transition diagram interpreter (TD I) and an Action linker. The TD I accepts a tex tu al version of a transition diagram and transform s it into state tables. The input for the TD I can be obtained from the transition diagram editor or can be encoded by hand. The Action linker is used to associate program segments w ith the sem antic actions listed in the transition diagrams. W ith these two tools prototypes of the user interface can be m ade for evaluation purposes or for making presentations to customers. 1.2.2 D a ta A b str a c tio n M e th o d s There have been several attem pts at the specification of user interfaces using data abstractions. Two such attem pts have been Chi [13] in the specification of the Tandy PC Line E ditor and M allgren [33] [34] specifying graphic d ata abstractions. T ex tu a l S p ecifica tio n s Chi specifies the Tandy PC Line Editor using an algebraic approach as shown in appendix C.2. The algebraic approach describes the user interface by specifying th e operations on an underlying d ata type, which in this case is a line of text. All th e editor functions in the exam ple are defined as to how they affect a line of text. One of the problems w ith th e algebraic approach is th a t it is difficult to express lim its (e.g. buffer size). To help over come this problem G uttag and Hornig [22] have proposed an extension of the algebraic approach to include routines based on predicate transform s which use preconditions to test for lim its. T he specification of a d ata abstraction is first done using the algebraic approach w ith no regard for boundary conditions and then routines are w ritten which “call” the operations defined in the algebraic specification after first checking for lim its on variables and param eters. An example by Chi of a predicate transfer routine for th e move left routine given in the exam ple in appendix C.2 is as follows: 7 PR O C ED U R E Moveleft(VAR line) SUCH TH AT W P(M oveleft(L),Q ) = [ curpos(l) > 1 = = »■ Q[record(moveleft(L), move)/L] AND curpos(L) = 1 =$■ Q[record(L,move/L] ] w ith the new moveleft operation being defined as: curpos(m oveleft(L)) = curpos(L)-l w instart(m oveleft(L)) = IF curpos(L) > 1 TH EN w instart(L) - 1 ELSE w instart(L) The routine “Moveleft” asserts th at if th e cursor position is greater than 1 then the cursor is moved to the left one position, otherwise nothing is done. T he “record(m oveleft(L), move)” specifies th a t the end of line character for the new line will be th e one which was specified to be displayed after a move operation and “record(L,m ove)” specifies th a t the end of line character for the old line will be th a t which was also specified for a move operation (there are three different end of line characters for the Tandy PC line editor). The “moveleft” operation specifies th a t when the operation is perform ed th at th e cursor position on the line is decrem ented by one and the start of the window is decrem ented by one if it isn’t already one. As you can see the algebraic specification does not check if the cursor position is in th e first column or not, but simply decrem ents it, while the routine takes care of th e case where the cursor is in the first column. G ra p h ic S p e c ific a tio n s M allgren in [33] [34] uses an algebraic notation for th e specification of graphic d ata types. The d ata types th a t he uses are: P o in t - a cartesian or polar coordinate. R e g io n - an area in two dimensions or a volume in three dimensions. G e o m e tric F u n c tio n - a function th a t m aps points to points. G ra p h ic T ra n s fo rm a tio n - a function th a t maps pictures to pictures. 8 T ree-S tru ctu red P ic tu r e - a hierarchical picture defined as each node contain ing a picture and each arc a graphic transform ation. C on tin u ou s P ic tu r e - a picture th a t takes up an entire plane or all of three- space. A point has the usual operations such as sum, angle, radius, ordinate, and ab scissa. A region has such operations as intersect, union and difference. Geometric and graphic transform ations are defined as objects because they are often used as objects in other functions themselves. Functions on geom etric transform ations are defined as compose, inverse and transform . Functions on graphic transfor m ations are compose, graphic transform ation and restricted transform ation. The tree-structured picture was defined because so m any pictures are hierarchical in nature w ith a set of operations th a t can be used to combine the parts into the total picture. O perations defined on the tree-structure are append, insert, delete, set color, move to, and draw line to. Finally th e operations defined on the con tinuous picture are get region, get color, sum, geom etric transform ation and color transform ation. 1.2.3 T em p la tes Specifying user interfaces w ith tem plates involves identifying a set of areas th at will contain text and other areas th at will contain data. The textual areas are defined at specification tim e while the d ata areas are defined as variables th at are filled in during runtim e w ith the appropriate values. There have been several system s th a t have used this approach to specifying user interfaces. Some of them are the A C T /I system [37], KSBASS [7], FLA IR II [74], and Excelerator [28]. The following subsection discusses the KSBASS tem plate methodology as an example. K S B A S S KSBASS (K arlsruhe Screen Based Application Support System) was designed for specifying textual user interfaces through the use of tem plates [7]. Templates are defined in a hierarchical m anner which reflects the form at of m ost com puter 9 generated reports. An example from [7] of a report and the tem plate th a t generated it is shown in appendix C.3. Tem plates in KSBASS are defined by specifying th e textual inform ation in groups called elements. Each elem ent contains tex t w ith variable nam es where d ata item s are to be filled in, such as: Elem ent PHD: N um ber of USC Ph.D . students (TO TA L.PH D ) Elem ent D E PT .PH D : (PHD_STUDENTS) Ph.D students in departm ent (D EPA RTM EN T) where “Elem ent PH D ” and “Elem ent D EPT_PH D ” are elem ent declarations, “(T 0 - TA LJPH D ),” “(PH D .ST U D EN T S),” and “(D EPA R TM EN T)” are variable names defining d ata item s to be printed, and “N um ber of USC Ph.D . students” and “Ph.D students in departm ent” are th e tex t to be printed th a t describe th e the d ata ob jects represented by the above variable nam es. T he hierarchical inform ation of the docum ent is described using a set of successor functions. Conditional inform ation in the successor functions can also be add th a t contain tests on variables defined in the elements. This then can be used to specify th a t the decision to display an elem ent can be shown to depend on the value of the d ata being displayed. An exam ple of a successor function is: T he successor of PHD is DEPT_PHD if PH D -STU D ENTS > 0 and PHD groups over D E PT .PH D which states th a t each departm ent to tal is printed only if the num ber of Ph.D students in the departm ent is greater than zero and th at th e D E P T .P H D element is a successor of the PHD elem ent. 10 1.2.4 F orm al G ram m ars Specifying a user interface w ith formal gram m ars involves giving a set of rules th at describes the syntax of the interface and the actions th a t will be taken when th a t syntax is satisfied. Examples of formal gram m ars th at have been used for specifying user interfaces can be found in [57] where Reisner uses a modified BN F and in [61] where Shneiderm an shows how a form al gram m ar can be used to describe the actions of both the com puter and the user through the use of a m ultiparty gram m ar. The rem ainder of this section will describe Shneiderm an’s m ultiparty gram m er as an exam ple of a formal gram m ar. M ultiparty gram m ars are used to describe th e actions between several parties which can consist of people an d /o r machines [61]. It works by listing possible statem ents by one party followed by the responses of another. In describing user interfaces it gives the possible inputs by the user and the responses the com puter will give to the inputs. The nonterm inals th a t describe hum an inputs are preceded w ith a H and th e com puter responses are proceeded w ith a C. The term inals are either the user inputs necessary to com plete the rule or the com puter actions th a t are a result of the rule. An exam ple of p art of a m ultiparty gram m ar for a book store search system is shown in table 1.1. The first line is the nam e of the system being described w ith the m ain com ponents of th e system on the right. The m ain com ponents consist of a start up phase th a t is executed by the com puter followed by com m ands and an ending phase executed by the com puter. W hen a nonterm inal does not include a C : or H : prefix this indicates th at the nonterm inal is m ade up of a com bination of hum an and com puter interactions and will be specified in a later production. All nonterm inals are either hum an inputs or com puter results and are specified as so on the left side of the term inals production in front of the nonterm inal name. T he startu p is executed by the com puter and consists of clearing the screen and then printing the command menu. The C O M M A N D nonterm inal lists the commands th at can be selected as well as the C O M M A N D nonterm inal again. Listing it on the left side adds recursion to th e definition and allows m ultiple com m ands to be entered. The T IT L E production describes the inputs from the 11 < BOOK SEARCH >::=< START >< COMMAND >< QUIT > < START >::=< H : NAME >< C : > < H : NAME >::= “booksearch" < C : IN IT >::=< C : CLEAR SCREEN >< C : PRINT MENU > < COMMAND >::=< COMMAND >< TJTZ£ >< AUTHOR > < PUBLISHER >< HELP >< iVZJLZ, > < TITLE >::=< TITLE SELECT >< H : TITLE NAME > (< r / n , £ FA7X > I < TITLE SUCCESS >) < TITLE SELECT >::=< 5 : ONE >< C : TITLE SCREEN > < TITLE NAME >::=< IT : ENTER TITLE >< C : CLEAR SCRREN > < H : ENTER TITLE >::=< : ENTER TITLE >< : LETTER > < QtfiT >::=< : FIVE >< C : END > < C : END C : CLEARSCREEN > exit < TITLEFAIL >::=< C : FAIL MESSAGE >< : ANY K E Y >< C : INIT > < TITLESUCCESS >::=< C : SEARCH RESULTS >< H : ANY K E Y > < C : INIT > < H : AN YKEY >::=< LETTER > \ < NUMBER > < LETTER >::= A|£|C ... (Z < NUMBER >::= 1|2| ...|0 < H : OiViJ >::= 1 < iT : FIVE >::= 5 Table 1.1: Exam ple m ultiparty gram m ar of book query system. 12 user and th e responses by the com puter when a title search is done. This is specified by th e T IT L E nonterm inal which indicates th a t the title com m and is selected, th e nam e of the title is gotten, and then either a search failure or search success is indicated. T he title com m and is selected (production T IT L E S E L E C T ) by the user typing the num ber “1” (production H :O N E ) and then th e title query screen is printed (production C :T IT L E S C R E E N ). The T IT L E N A M E production indicates th a t the nam e of the title to search for is entered by th e user and then the screen is cleared by th e com puter. Depending on the outcom e of th e search, either production T IT L E F A IL is used or production T IT L E S U C C E S S is used. If th e search for the title fails, then a failure message is printed, T he user presses any key and th e initialization routine is rerun. If the search is successful then the results of the search are displayed, the user presses any key and th e initialization is rerun. The author and publisher search com m ands as well as th e help com m and are sim ilar to the title search commands and are not included. To exit th e book search program th e Q U IT production is followed. This consists of the user typing the num ber “5” on the keyboard which causes the screen to be cleared and the program to be exited. 1.2.5 P r o to ty p in g Prototyping is used to analyze the requirem ents of systems wen the users are not initially sure of w hat they want [10] [37] [56]. It involves developing an exam ple of p art of the system for the user to see before the development is started . T he types of things th a t are prototyped are user interfaces, system functions and tim e/m em ory requirem ents [24]. In prototyping user interfaces, only the part of th e system th a t is seen by the user is developed. T he user then evaluates the prototype and makes suggestions for change. These changes are then incorporated into the prototype and the process is repeated until the user is satisfied and gives th e go ahead for the production version to be w ritten. User interface prototyping tools can be divided into three types: 1. User Interface M anagem ent Systems 13 2. Interactive Design Tools 3. Language based tools Prototypes can also be developed using only conventional program m ing languages and toolkits, th e tools listed above provide an interactive environm ent for designers and provide an increase in productivity over conventional program m ing languages. The following sections discusses each of the above three types of tools. U ser In terfa ce M a n a g em en t S y stem s A user interface m anagem ent system (UIMS) provides a separation between the user interface and the application code. A UIMS can be defined as a system th at provides a com ponent for the presentation of the visual p art of the interface, a com ponent for the definition of the dialogue between th e user and application and a com ponent for defining the connection between the interface and application program [21]. Figure 1.2 shows the relationship of these three parts. The presen tation portion of the UIMS handles the display of inform ation on the screen and converts user inputs into a non-device dependent representation. T he dialogue por tion then exam ines the input and calls the appropriate application function using the dialogue-application interface to pass d ata between the two. A fter the appli cation is through w ith its com putations it then returns control to the dialogue and using th e dialogue-application interface to retu rn any data. Based on th e last user input, th e state the user interface is in and the d ata returned by the application, the dialogue then instructs the presentation system w hat to display. By separating the user interface from the application the developers can change how d ata is dis played w ithout modifying the application and also modify the application w ithout fear of accidentally changing the user interface. Two current UIM S’s are Serpent [5] and TeleUse [67] by TeleSoft corporation. B oth Serpent and TeleUse provide a dialogue language for describing the flow of control of the interface (Slang for Serpent and D for TeleUse), a d ata specification language for describing the interface between the dialogue and application (Saddle for Serpent) and an interactive design tool (ID T) for laying out th e visual part 14 U ser Dialogue Presentation A p p lic a tio n Figure 1.2: Relationship of the three parts of a UIMS. of the user interface. B oth systems also use the X windowing system for the presentation portion of th e UIMS. An exam ple of some dialogue code and interface to an application using the Serpent dialogue language Slang and d ata interface language Saddle is shown in figure 1.3 and figure 1.4 respectively. Application code w ritten in C is shown in fig ure 1.5. Figure 1.6 shows the application being defined w ith Serpent, a calculator. T he Slang code defines th e interface objects th at are to appear in the calculator and th e functions to execute when particular events occur. S tarting at the top of figure 1.3, the E X T E R N A L S definition defines th e application functions th a t will be referenced. The O B J E C T definitions define the interface objects th a t are to appear in the application. The A T T R IB U T E S definitions define initial values th a t each of the objects will have. The M E T H O D S definition defines w hat is processing is done when a particular event occurs. Figure 1.4 defines the variables th a t are to be shared between th e application and the dialogue. In this case the only values are an integer indicating which calculator operation is to be perform ed and a variable th a t sets the value in the display object th a t is the output window for the calculator. Figure 1.5 shows the application code th a t would be executed when one of the num erical buttons on the calculator is pressed. It m ultiplies the current value by ten, adds the value of the current b u tto n pressed and then con verts it to a string and sets th e shared variable d isp la y to the new value so the calculator output will be updated. 15 /* Slang code for calculator example */ E X T E R N A L S : void num ber(integer) /* name of C functions */ void operation(char) O B JE C T S : /* m ain container widget for calculator * / main.window : form.widget { A T T R IB U T E S : height: 400; width: 300; } /* Display window of calculator */ display: labeLwidget { A T T R IB U T E S : parent: main.window; x: 50; y: 20; height: 40; width: 200; label_text: display; } /* Number 4 button on calculator */ digit4: command_widget { A T T R IB U T E S : parent: main.window; x:20; y:170; width: 50; height: 50; label.text: 4; M E T H O D S : notify:{ number(4) } } F igure 1.3: E xam ple Slang code for calculator. 16 «<)}) app: shared data command: record operation: integer; /* operation to perform */ display[20]: string; /* value to display */ end record; end shared data; Figure 1.4: Exam ple of saddle code for a calculator. ^include “slang.h” /* shared variables */ static int.display; /* integer value of display variable */ void number(value) int value; /* number just pressed */ { int.display = int_display*10-fvalue; /* new value to display */ display = itoa(int_display); } Figure 1.5: Exam ple of C code for calculator. 17 Figure 1.6: Calculator defined w ith Serpent. 18 ! In te ra ctiv e D esig n T ools i j j ; Interactive Design Tools (ID T) allow the user to interactively place interface com- j ] ponents on the screen, sim ilar to a graphics editor, except instead of placing lines, j | circles and other figures, the user is placing buttons, lists, m enus, icons and other j ! interface objects on the screen. M any ID Ts also allow th e designer to specify ap- J j plication functions to be executed when a particular event occurs (e.g., a button i press). Most ID T ’s also enforce a particular look and feel th a t is consistent w ith the environm ent they are w ritten for. Once the layout is done, they produce source j code definitions in a program m ing language or layout description language th a t j represents the layout of the screen. The dialogue portion of th e interface is then ! w ritten in a program m ing language, or if p art of a UIMS, in a dialogue language j .1 th a t uses the generated screen definitions. A large num ber of ID Ts have been writ- J ten. Some of these systems are: Dialog E ditor by Cardelli [12], Interface Builder | by N ext [36], P rototyper by Sm etherBarnes [63], X Build by N ixdorf [15], Xcessary ! by Integrated Com puter Solutions [29] and UIMX by HP [27] and Dev Guide by | l Sun Micro Systems. j A nother system , H yperCard [20], also allows interface objects to be interac tively laid out on the screen but differs in the above systems in th a t the designer defines a series of cards with common backgrounds and differing foregrounds. These foregrounds and backgrounds can contain tex t, buttons, lists, m enus and graph ics. T he cards are linked together by events, such as butto n presses, which causes a new card to appear. In this way, simple flow of control between cards can be defined w ithout the need for any program m ing. Only simple sequencing between interaction objects is possible though [6], and if a more advanced scheme is needed a scripting language, HyperTalk [20], needs to be used. Peridot [49] helps the user w ith the layout of interface objects by guessing w hat type of object the user is trying to draw and fills in some of the detail and helps w ith alignm ent and other visual attributes. These objects can then be modified at runtim e through function calls or d ata in the object can be retrieved through shared variables. Peridot also differs from th e above system s in th a t constraints can be defined between interface l objects. t i I i I 19 I ____ j L a n g u a g e B a se d ! Language based prototyping systems are centered around a high level program m ing language th a t has specific constructs for displaying and m anipulating user interface j objects. T he language hides the low level details of th e windowing environm ent and 1 allows the program m er to spend m ore tim e w ith th e logic of th program instead of th e intricacies of defining the appearance of the interface th a t is necessary when i using a graphical user interface toolkit like the Apple M acintosh toolbox [59] or j the X windows toolkit [41]. These languages usually come w ith a program m ing , environm ent th a t lets the designer view interface objects as they are defined and j I to test segments of code th a t operate on an object. j ] Exam ples of language based systems are W interp [39], G arnet [48] and ToolTool j ! [47]. W interp is based on XLISP and the M otif widget set. XLISP has been modified to allow M otif widget attributes and callbacks to be defined. Figure 1.7 is th e source code th a t produces a calculator as shown in figure 1.6 above. The “let *” at th e beginning of the program defines the start of the interface layout. The to p _ w is the nam e given to the top level shell widget which is also given a title of W in te r p C a lc u la to r. The m ain window is a form widget w ith a height of 400 and w idth of 300. A label widget is located at (50,30) of the form widget and has a height of 40 and w idth of 200 and label of “0.” The definition for th e b u tto n “4” of th e calculator is defined as a push bu tto n appearing at (20,170) w ith height and w idth of 50 and a label of “4.” The last segment of code registers a callback to b u tto n “4” w ith an action of modifying th e label in the display widget to reflect a 4 entering the least significant digit. F o rm B a s e d S y ste m s There are several prototyping facilities for developing form based system s. These types of system s contain screens which contain areas for input and tex t areas th at describe the input areas. These systems are often used for database system s or for d ata entry type systems and are m ade to prototype a lim ited type of user interface. T he following are two exam ple systems: Excelerator and A C T /I. Excelerator is a PC based CASE tool th a t allows the specification of “screens” 20 (let* ((top_w /* Define top level shell */ (send TOP_LEVEL_SHELL_WIDGET_CLASS :new :XMN_TITLE “Winterp Calculator” )) /* Define form window widget */ (form.w (send XM_FORM_WIDGET_CLASS mew :managed top_w :XMN_HEIGHT 400 :XMN_WIDTH 300 )) /* Define label widget to be used as calculator display */ (display_w (send XM_LABEL_WIDGET_CLASS mew :managed form.w :XMN_X 50 :XMN_Y 20 :XMN_HEIGHT 40 :XMN_WIDTH 200 :XMN_LABEL “0” )) /* Define the number “4” button of the calculator */ (digit4_w (send XM_PUSH_BUTTON_WIDGET_CLASS mew :managed form.w :XMN_X 20 :XMN_Y 170 :XMN_HEIGHT 50 :XMN_WIDTH 50 :XMN_LABEL “4” )) /* Define callback for the number “4” button of calculator */ (send digit4_w :add_callback :XMN_ACTTVATE_CALLBACK ’() ’((send display.w rset.values :XMN_LABEL = XMN.LABEL *10 + 4 )) ) )) Figure 1.7: Exam ple of W interp source code. 21 and “reports” [28]. A screen is a single form consisting of areas of tex t and input areas where d ata is to be typed in. Reports are sim ilar to screens except th at instead of input areas they have output areas. Usually th e areas of tex t describe w hat is either to be typed in or outputted. The screen and report forms can not be linked together to form a series of screens or reports. Each screen/report is a separate entity from the other screens and reports. T he reports and screens are specified by the user in a report/screen editor. The user indicates where the tex t of the form is to appear by moving the cursor to the { start of where the tex t is to appear and clicking a mouse b u tto n and typing in the | tex t th a t is to be displayed at th a t point. The in p u t/o u tp u t areas are specified j in a sim ilar way w ith the user indicating w ith the cursor th e location of the area, j T he user then specifies the size and the type of d ata to appear in th e area by filling I out a form displayed at the bottom of th e screen. W hen a screen or report is finished, the user can test it through a sim ulation. Screens are tested to see if th e input areas are wide enough and if the edit rules for th e types specified work correctly. The sim ulation consists of starting the user in th e upper left hand input area and moving the user to the next input area after d ata value is entered. T he sim ulation of reports helps th e user decide if the output areas are of the proper size and consists of reading d ata in from a file into the | | outp u t areas of the report. j A C T/1 is an IBM based system th a t allows the specification of form types j of user interfaces for interactive inform ation systems (IIS) [37] [38]. As with Ex- ! celerator above, the designer types in text th a t is to appear on th e form in the appropriate places and indicates where text is to be printed or typed in by the user. T he user then types in a description of the types of input the user will make in each of the user input areas by m eans of a regular expression. Unlike Excelerator, A C T/1 lets the designer specify sequences of forms. This is done by the user typing in th e nam e of the next form to print based on possible inputs from the user. The designer can also specify certain functions to be executed at different periods of the user interface and values th a t these functions are to return. This allows the designer to give sim ulations of the interface. The interfaces th a t can be specified consist only of text and the inputs recognized are only keys 22 I j typed by the keyboard. i ! 1.2.6 A d v a n ta g es and D isa d v a n ta g es o f C u rren t M e th o d s f The following are some of the strengths and weakness of the current m ethods i described above: [ ! T ra n s itio n D ia g ra m s - Like d ata abstractions and tem plates the transition di- j agram m ethod gives a form al specification of the interface and like the tem - ; plates a sim ulation of the user interface is possible. Unlike tem plates though ! the transition diagram m ethod can be used to specify anything based on a j finite state m achine. Disadvantages are th e same as th e tem plate m ethod in j th a t the sim ulation of the user interface is an afterthought of the specification i and does not give an interactive environm ent for th e design of the interface. D a ta A b s tra c tio n s - Advantages of d ata abstractions is th a t the requirem ents are stated in a precise m anner th a t indicate only the external behavior w ith out giving im plem entation details. Im plem entation tends to follow easily form th e specification and certain properties of the specification can be proven to be true. Disadvantages are th a t it takes a trained person to read th e spec ification, an even m ore highly trained person to w rite it, visualization of the interface is difficult and the user has to wait for the im plem entation to see the interface when modifications are the m ost costly to make. T e m p la te s - Advantages of this m ethod is th a t a formal specification of the interface is given and a sim ulation of the user interface can be show the custom er. If the custom er is unhappy w ith the interface the specification can be modified and a new sim ulation done. Disadvantages are th a t only certain types of user interfaces can be specified and th a t the sim ulation of th e user interface is an afterthought of the specification and does not give an interactive environm ent for the design of the interface. F o rm a l G r a m m a rs - Also like d ata abstractions, form al gram m ars have the advantage th a t th e requirem ents are stated in a precise and form al m an ner th a t only give the external behavior of the interface w ithout giving any 23 \ im plem entation details. W ith th e form al gram m ar the im plem entation of a syntax checker for th e interface can be done autom aticly through a lexical | analyzer (like Lex) and a compiler compiler (like YACC). Also w ith a formal J gram m ar, certain hum an factors of th e interface can be checked. Disadvan- | tages are th a t it takes a trained person to read and w rite th e specification ' and visualization of the interface is difficult. i P r o to ty p in g - Advantages of prototyping are th a t the custom er is given a chance ■ to see the user interface before it is im plem ented and in a form th a t is un- | derstandable and modifiable. This allows th e custom er to m ake changes to i the interface during the requirem ents phase of the software im plem entation j when it is the least costly to do so. Disadvantages of this m ethod are th a t i ! th e prototype becomes th e specification of the user interface which does not | | give a precise definition of the problem in th a t there is no functional decom- j position or form al notation of the problem for th e designer to follow. Since j the code is usually modified m any tim es before th e custom er accepts it, the code can become difficult to understand and if it is used in th e production ' version it is difficult to m aintain. 1 j j T he ideal situation when specifying a user interface is to produce a prototype j and a form al specification of the user interface w ith the prototype being produced ! first [10] [69]. The prototype gives th e user som ething concrete to evaluate and j m odify while the formal specification gives the software designer a precise definition j t of w hat is to be im plem ented. Producing th e prototype first allows changes to be j m ade to the interface w ithout having to first m odify or understand a complex spec ification. The quickness in which the prototype can be developed is also dependent on the am ount of code th a t needs to be w ritten. Reducing th e am ount of coding needed also lessens the dependency of a designer on a program m er. The prototype should also be easily modifiable allowing the designer to specify th e interface in an iterative m anner to aid in elim inating early design flaws [18] [35]. M aking the J prototype easily modifiable also helps to involve th e custom er at the specification j ! stage in the software lifecycle when m odifications are th e least expensive to make j ! [9] [24] [50] and help to produce a user centered design [51]. [ 1.3 Research Direction Chignell and Hancock in [14] state: In com parison to developm ents in hardw are technology, m ethods of in terface design are fairly prim itive, largely because there are few models to guide the interface designer. In order to m ake interfaces intelligent, we will need to develop sophisticated models of how interfaces function, along w ith tools th a t can im plem ent these models in software system s. In this thesis I develop a m odel of interaction, a m ethodology and system which will allow a custom er and interface designer to specify the com ponents and dialogue of an interface interactively. The m ethodology will support th e specification by providing a model of th e com ponents and dialogue of the interface while the system will support th e m ethodology through the use of graphics, sim ulation and a d ata dictionary. T he interface specified by the designer is represented by a form al model based on a hierarchical statechart. Algorithm s for checking th e com pleteness and consistency of the user interface are given and analyzed. T he com ponents of a user interface consist of th e graphical objects, user inputs, o utputs and rules. T he graphical objects are m ade up of m enus, icons, windows, tex t and pictures. Though th e above are not all graphical in nature, they can all be treated as such from the system ’s point of view. User inputs take th e form of mouse clicks, mouse m ovem ents, keyboard inputs, touch screen and joystick types of devices. O utputs consist of anything th a t modifies th e user’s screen, such as displaying, erasing or moving an object. Lastly, the rules are descriptions of how th e state of the program will change given the set of possible inputs either from the user or from the result of a program ’s com putation. The m ethodology for specifying a user interface will be concerned w ith how the interface designer goes about creating th e interface. T he following are th e steps th a t will be involved in specifying an interface and the effects they will have on the underlying representation: 1. T he designer starts by defining th e windows th a t are to be used, giving them an initial size, initial depth, and assigning them to an area of the screen. As each window is defined, a node of the m odel is created to represent the 25 window. 2. The designer next specifies a sequence of tex t and graphics (called fram es) th a t are to appear in each window. This is done by either defining the frames or specifying how one fram e will be transform ed into another by graphical operations. A fter drawing each fram e, its nam e and im age are entered in the d ata dictionary for reference in subsequent steps. As these frames are m ade, nodes are allocated to the representation th a t represent the frames. 3. A fter the fram es/windows have been specified, th e designer defines th e in puts necessary to go from one fram e/w indow to the next and th e graphic operations to represent the next fram e/w indow (if not already done in the , previous step). W ith these values, transitions are defined in th e representa- i tion between the nodes th a t represent the fram es/window s. j 4. A fter all th e inputs have been defined, th e designer will run a consistency j and com pleteness checker to test for any possible errors or omissions in the j design. 5. A fter th e errors in th e above step have been fixed, th e designer will compile the representation of the interface into X Toolkit source code. From here the code can be compiled by the designer and run to test the operation of th e interface. Each of these steps can be repeated so th at the interface can be developed in an iterative m anner. T he system th a t will support the m ethodology will contain the following func tions: G ra p h ic s E d ito r - for drawing graphics, tex t, X Toolkit widgets and defining window positions and sizes. D a ta D ic tio n a r y - for storing names and inform ation on windows, fram es and graphical objects, transitions and m aintaining consistency. C o m p le te n e s s C h e c k e r - for checking the representation for unfinished nodes and transitions. 26 C o m p ile r - a compiler to translate the underlying representation into executable X Toolkit code. R u n tim e S y s te m - a runtim e system to m anage th e forms, th e transitions and object appearance tim es during execution. | These tools will be used to autom ate th e m ethodology giving th e designer a com p uter aided environm ent in which to work and create the interface. | T he methodology and supporting system are different from previous systems ! in th a t the user interface is specified by drawing the screens directly and the spec ification of th e underlying state diagram is done indirectly while the underlying ! representation is powerful enough to support a wide range of user interfaces. O ther I | system s based on a state diagram approach concentrate on th e specification of the diagram first and then indirectly specify the appearance of the graphical objects through a high level program m ing language. T he m ethodology th a t I am propos- ; ing is m ore n atural from th e custom er and designer’s point of view since they can ! see exactly w hat is being specified as it is being created. They are not distracted j by having to understand an underlying representation or learn a program m ing lan- \ guage and it allows the interface to be specified in an iterative m anner. O ther m ethodologies have concentrated on specifying only a single type of user inter face while the proposed m ethodology is m ore general in n atu re and will allow the specification of a broad range of interfaces. 27 i C h a p ter 2 i i j I i A F orm al M o d e l for S p ecify in g I U se r In terfa ces i This chapter defines Interface R epresentation G raphs (IRGs), a formal m odel based ! I on transition diagram s and statecharts for specifying user interfaces. In this chapter i 1 an overview of transition diagram s, statecharts, th en IRGs are given, th e use of j IRGs in modeling user interfaces is shown, the advantages of IRGs for m odeling J user interfaces is given and examples of IRGs shown. ! 2.1 Previous Models Used for Specifying User | Interfaces This section describes two previous models for specifying user interfaces: transition diagram s and statecharts. Both models have been used in the past and had an influence in th e developm ent of the interface representation graphs. 2 .1.1 O v erv iew o f T ra n sitio n D ia g ra m s A transition diagram is a directed graph consisting of nodes called states and arcs connecting th e states called transitions [26] [68] [72]. The states represents places in the program where inputs to th e system are accepted. T he state th a t is w aiting for input is called the current or active state. One node of th e diagram is 28 designated as th e sta rt state where execution begins and one or m ore other nodes are designated as final states where execution ends. S tart states are represented by a double circle w ith a “S” in the m iddle and final states by a double circle w ith a “X” in th e m iddle. The other interm ediary states are drawn as a single circle w ith a nam e inside (usually describing its action). The following are exam ples of sta rt, interm ediate, and final state: P rin t M enu, T he leftm ost circle is the start state, the m iddle circle an interm ediate sta te where a m enu is printed and the rightm ost circle is th e final state where a transition diagram would be term inated. Transitions link the nodes of transition diagram s together. Each transition links a source state to a destination state and contains an input value. W hen an input is received by a transition diagram , th e values on th e transitions leaving the current state are checked against th e input received. If there is a m atch, the destination state th a t the transition points to becomes th e new current state and the process repeats itself. Actions can also be associated w ith transitions, which are executed w henever the transition is traversed and listed on transitions after th e input. Figure 2.1 is an exam ple of a transition diagram representing a bookstore query system th a t allows patrons to search for a book either by title or author. Execution of th e diagram begins at the start state where a transition is taken on a null input, has an action of printing a m enu listing the two types of searches available and a help m enu and transfers control to the node labeled “M ain M enu.” At this node th e user can type in a “T ” to perform a title search, an “A” to perform an author search, an “H ” to get some instructions, or a “Q” to end the program . Any other input from th e user is ignored. If a “T ” or “A” is input from the “M ain M enu” node, the appropriate transition is taken and an input screen is displayed asking the user for a title or author. On entering the search string the results of th e search is displayed, and the next node waits for the user to “press any key to continue.” W hen th e user presses a key the only transition is taken, the m ain m enu printed and control returned to the the m ain m enu node. If “H” is selected from the m ain 29 P r in t M en u B / P r i n t B e g in n e r B e g in n er H elp H elp M en u H elp M en u P r in t M en u E x p e r t H elp E / P r i n t E x p e r t N u ll/ p rin t m e n u A ny K e y / P r in t M en u Q / P r i n t S earch R e s u lt T i tle S earch R e s u lts T itle Q u ery M ain M en u A ny K e y / P r in t M en u Q / F r i n t S earch R e s u lt S earch A u th o r A u th o r S earch R e s u lts A u th o r Q u ery Figure 2.1: Transition diagram of bookstore query system . m enu, a second m enu is printed asking the level of help the user would like and control transferred to node “Help M enu.” If a “B ” is typed at th e “Help M enu” node a beginner help message is printed and if an “E” is typed an expert help message is printed. W hen the user is done reading th e instructions an input of “Q ” will retu rn the user from the help m enu back to th e m ain menu. 2 .1 .2 O v erv iew o f S ta tec h a r ts S tatecharts are based upon transition diagram s w ith the following extensions: 1. A node can contain subnodes. 2. Events can include a condition th a t can m ake a test on a global state. 3. Actions can occur on both transitions and at nodes. 4. Concurrency between subdiagram s can exist. 30 T he rem ainder of this section gives a brief discussion of the extensions, nodes, transitions, and concurrency of statecharts. I | N o d e s Nodes in statecharts represent points in a program where actions are executed , followed by the w aiting of an event to occur to indicate th e next node to go to. ; Nodes are drawn as rectangles w ith rounded edges (called blobs or boxes) w ith the . nam e of th e node inside. Subnodes are drawn inside their parent node. Subnodes ■ are often not drawn so as to b etter focus on one or two levels of a m ultilevel i | statechart. i Actions are executed when control reaches a node. Actions can take the form i I of an external output statem ent (e.g., a print statem ent), an internal broadcast event, a com putation, or a call to a user supplied function. T he internal broadcast event is for synchronizing parallel events and is discussed below. There are five types of nodes in statecharts: P a r e n t N o d e s - nodes which contain subnodes. L e a f N o d e s - nodes th a t are at the bottom of the hierarchy of nodes. D e fa u lt N o d e s - a node th a t indicates where execution should start am ong a set of subnodes. H is to r y N o d e s - a node when executed goes to the last node reached th e last tim e th e parent was executed. Each of the above types are further described below. P arent nodes are used to group nodes which have a common function. There is always an outer m ost node th a t contains all other nodes called th e root node. If control is transferred to a node th a t contains a subnode, execution of th e parent node consists of giving control to one of its subnodes. T he execution of the state chart begins w ith the root node, which then transfers control to one of its subnodes to start th e execution of. j P arent nodes can be one of two possible types: I 31 X O R - w here only one subnode is active at a given tim e. A N D - where all of its subnodes are active at once. An X O R node is a sequential node where control is transferred betw een subnodes : one at a tim e w ith events being applied to the currently active subnode, ju st like a ; transition diagram . An A N D node is a parallel node where control is given to each ' of the subnodes (which in tu rn are parent nodes) w ith events applied to each of , the subnodes. T he A N D parent subnodes are said to be orthogonal to each other j and are discussed below. Unless a parent node is explicitly expressed as being an A N D parent or a set of subnodes being orthogonal, parent nodes can be assum ed | . I to be X O R w ith sequential subnodes. ! j An exam ple of hierarchical nodes in a statechart is shown in Figure 2.2. The ! outer node A is th e root node which contains subnodes B and C , one of which J will be given control by node A when execution begins. Node B also contains two subnodes, E and D . As w ith node A , one of them will be given control when B is given control. Control is transferred down th e hierarchy until a leaf node is reached, at which point th e node is executed. Leaf nodes are nodes which do not contain subnodes. They are at the b o tto m of the hierarchy of nodes and are interpreted in th e same way nodes are in a transition diagram . W hen control reaches a leaf node, execution of th e graph halts until an input occurs th a t m atches one of the events listed on an outgoing transition from the node. If an event occurs and does not m atch any of the events listed on the transitions leaving the node, then the event is passed up to the node’s parent where th a t node’s outgoing transitions are exam ined for the event. If there still is no m atch, the event is passed up the hierarchy of nodes until the event m atches one of the values listed on a transition of the original node’s ancestors or until the root node is reached where it is discarded. If an input is ever discarded, the original leaf node regains control and the process is repeated on the next input. A parent node can designate one of its subnodes as a default node. A default node is where execution starts if control is transferred to its parent w ithout indi cating a subnode where execution is to start. Default nodes are designated by an arrow th a t begins w ith a dot and ends at one of the nodes. 32 w j Figure 2.2: S tatechart w ith transitions. i i i Exam ples of default nodes are nodes C and E in Figure 2.2. If control is in node C and transition u is taken to node B then execution of node B will begin w ith E. If instead of transition u being taken from C, transition w is taken, then execution of node B will begin w ith node D since a subnode was specifically specified. Instead of or in addition to a default node, a history node can also be used to I indicate the starting node. T he history node rem em bers which sibling node was last ! executed when control left its parent. Later when control returns to the parent, I execution is restarted at the subnode th a t was last reached. This m echanism can be used in conjunction w ith th e default transitions where a default transition indicates which node to execute the first tim e control is transferred to th e parent. On subsequent invocations control will be transferred via the history mechanism, j A history m echanism is indicated by an arrow entering a parent node and ending j at a circle w ith an “H” in it as indicated in the lower left corner of Figure 2.2. In i ! this exam ple the first tim e node A is entered execution will sta rt at node C. If j event y should occur while control is at node D then execution of A is term inated. If at a later tim e control returns to A via the history node, execution will resum e j at node B. Since node B does not contain a history node, upon reentering B the ! t default node would be always used and execution would resum e at node E. I j A second type of history node is also available. In the above history m echanism , ! only the last executed node of the history node’s sibling nodes is considered for { j execution even though a subnode of th e sibling m ay have actually been the last node executed. For example, if node D was the last node executed in Figure 2.2 before event y occurred, the history m echanism would only give node B control i since it only looks at the nodes at the sam e level th a t it is at. T he second type of history node is indicated by superscripting the H in the history node w ith a star (e.g., H *) and gives control to the lowest subnode of the starred history node’s parent node control. In the above scenario, if the history node in node A was superscripted w ith a star, node D would have been given control instead of B. T ra n sitio n s j i Transitions are used to show flow of control between nodes and can lead from any j node at any level in th e hierarchy to any other node at any level in th e hierarchy, i Figure 2.2 shows some examples of possible transitions between nodes. Transition u indicates th a t control goes to node B from C where either node D or node E is j executed next. Transition vindicates th a t the transition is the equivalent of coming from all subnodes of B . This m eans th a t while in either node D or E transition v can be taken. Similarly transition y indicates th a t it can be taken from any node contained in A (i.e., C, D , E). Transitions can also pass up through or across m ultiple levels of hierarchies as indicated by z. A transition is taken if an event occurs and a transition th a t is attached to the current node is labeled w ith th a t event. Events are inputs to th e program in the form of user input, function results or internal broadcasts. In addition to an event, a condition can be specified which guards a transition. T he guard indicates th a t th e transition can only be taken when the condition is tru e and th e event occurs. A condition attached to an event is w ritten £(C) on a transition where £ is the event and (C) is the condition. Actions can also be attached to transitions as well as nodes and are executed whenever th e transition is taken. An action A is shown on a transition by listing it after the event and condition, as in £{C)/A. 34 An exam ple of a transition is: H E L P ( n o v i c e ) / D isplay v erb o se h elp which indicates th a t if the system is in node A when the H E L P key is pressed and th e user is a novice, then the verbose help window should be displayed. i i j C o n c u rre n c y T he specification of concurrency in statecharts is done by: 1. Defining separate sets of sequential nodes th a t are to ultim ately act in par allel. J I j 2. Giving each sequential set of nodes a X O R parent node. i 3. Collecting each of the new parent nodes into an A N D parent node. T he sets of sequential nodes running concurrently w ith each other are said to be orthogonal to one another. In sequentially executing nodes (nodes th at have an X O R parent), when an event occurs it is com pared to the transitions leaving th e 1 active node and if one is labeled w ith th e event th en th a t transition is taken. In i i orthogonal nodes there is one active node for each orthogonal com ponent. W hen I an event occurs it is applied to each active node in each orthogonal com ponents. In th e extrem e case all nodes will have a transition they can take and the active nodes in all orthogonal com ponents will change. W hen a transition leads to a set of orthogonal nodes, all orthogonal com ponents begin execution at their start node. W hen a transition in one of the orthogonal com ponents exits th a t orthogonal node, then execution term inates in all orthog onal com ponents and sequential control is returned via th e exiting transition to a new node. History states for orthogonal nodes can exist so th at on subsequent invocations, p art or all of the subnodes can resum e where they left off. An exam ple of an A N D node is node A in Figure 2.3. W hen control is tran s ferred to A , both subnodes B and C become active. Since nodes B and C are both ! I 35 X O R nodes, they would both in tu rn activate one of th eir subnodes. Execution starts w ith subnode d of node B and subnode g of node C (the default nodes). If we applied the event list of (w, x,w , z) to the statechart, the progression of nodes would be: (d,g), (e,g ), ( /, h ), (e, h), (d , j ). Execution begins in node d and g when th e event w occurs. Since node d has an outgoing transition labeled w and node g doesn’t, only th e (d — > e) transition is taken and the statech art ends up in nodes e and g. The next event is x which causes both the (e — * f ) and (g — » h) transition to be taken leaving th e statech art in nodes / and h. A fter events w and z are executed, th e statechart ends up in nodes (d ,j ). If at any tim e node h is active and event u occurs, then b o th orthogonal nodes would be exited, and if event t occurred while in any of th e nodes they both would be exited. | As stated earlier, an internal broadcast event can be listed as an action on a transition in the form of a variable nam e. W hen a broadcast is encountered in the action list of a transition it is sent out as an event to all orthogonal nodes. This event is then treated like any other event by the orthogonal nodes and can cause them to execute a transition if it is labeled w ith th a t event. T he prim ary use of broadcast events is for synchronization purposes. In particular instances, it may i be necessary to reset the other orthogonal nodes to a known state. 2.2 Interface Representation Graphs IRGs are a representation of the interaction between th e user and interface. They m odel the structure, flow of control, constraints, and sem antic feedback of the interface. IRGs differ from statecharts in the following ways: • Nodes not onl}r represent a state of th e interface, b u t also a physical or logical com ponent. • Dataflow as well as control flow can be specified. • Inheritance of the following objects is supported: — Interface objects — D ata flow 36 w w w I I Figure 2.3: Two orthogonal nodes. — Control flow — A ttributes of interface objects I ! j • C onstraints on dataflow and control flow exists. 1 • Sem antic feedback notation exists I An exam ple of an IRG and the interface it represents is shown in Figure 2.2.1 and j Figure 2.2.1, respectfully. T he following sections discuss each of p art of the IRGs j in m ore detail. < I I ! 2.2.1 In terfa ce C o m p o n en ts i i Like statecharts, IRGs consist of a hierarchy of states. IRGs differ from statecharts j in this hierarchy in th a t there are five types of nodes: j 1. Groupings of nodes j 2. G raphical objects I ! 3. Frames 4. Inherited nodes 5. Shared d ata nodes I ! 6. A rray nodes. I G ro u p in g s o f N o d e s j IRGs, which are based on statecharts [6] [13], can be defined as hierarchical tra n sition diagram s where nodes either stand for them selves or contain subdiagram s. It is this hierarchy of nodes th a t is used to represent th e levels of windows, fram es and graphical objects of an interface. An interface is m apped onto th e node struc tu re by first representing the entire interface as a root node of an IRG , th e top level windows as children of th e root node, subwindows as child nodes of the win dow’s parent, frames as children of the window nodes and graphics as children of the fram e nodes. Like statecharts each IRG has a root node th at contains all other nodes in the IRG. T he root node and other grouping nodes are all draw n as rectangles w ith rounded edges, ju st as nodes in a statechart. G rouping nodes are used to combine other nodes th a t share a common attrib u te, flow of control, d ata flow or dependency. Groups are treated like any other node. They can have transitions, sem antic feedback, constraints, or other attrib u tes which apply to all the nodes inside the group. Since a grouping node contains other nodes, it can never be represented as a leaf node of an IRG. A n exam ple of an IRG which con tains some grouping nodes is shown in Figure 2.2.1. Each graphical object of an interface is represented by a rectangular state in an IRG. G raphical states are also hierarchical. They can represent windows th a t contain other graphical objects or com posite graphical objects th a t are m ade up of m ultiple objects. All leaf nodes of the IRGs are graphical objects. G rap h ical O b jects i ! T he graphical objects consist of the buttons, m enus, dialog boxes, tex t, and other item s th a t are directly visible to the user. These objects can be divided into two groups: those th a t contain other objects and those th a t are atom ic. T he container 38 objects are th e windows and th e atom ic objects are objects like buttons, labels, lists, and m enus which do not contain any other objects. All graphical objects are represented by a square state to distinguish them from the grouping states which have rounded edges. Examples of graphical objects are shown in figure 2.2.1. Exam ples of windows are th e squares labeled Browser and Help windows. Exam ples of atom ic objects are the Author, Title, and Subject b uttons in the query frame. F ram es T he graphics are grouped together into frames inside each of the windows. A fram e is a set of graphics th a t appear sim ultaneously in a window. W hen control 1 is transferred from one fram e to another, the content of th e window is cleared and a com pletely new set of graphics is drawn. An exam ple of a series of frames is a transaction based system , such as a database browser, in which query fields are filled, and query results are displayed by erasing th e contents of the window and displaying a list. Since m odifications to a fram e som etim es needs to be m ade | i w ithout erasing the entire fram e, we define a second type of fram e called a subfram e j where m odifications can consist of (but are not lim ited to) display of dialog boxes, addition of m enus, lists, error messages or help. Some user interfaces are a series of frames, others are a single fram e w ith subfram es th a t continually modify the original fram e and others are a m ix of these. An exam ple of a fram e oriented user interface is a transaction based system where d a ta in fields of a form are filled, w ith new frames and fields appearing depending on the item s selected or the values entered. An exam ple of a single-frame oriented interface is a graphics editor, in which a single fram e is displayed and changes are continually m ade to it. Most systems contain both types of fram es. There m ay be several fram es th a t make up th e interface but are modified w ith dialog boxes, error and help messages th a t continually update or m odify th e original frame. 39 In h er ited N o d e s Inherited nodes represent graphical objects or other types of states th a t are com m on to a group of states. Inheritance allows graphical objects th a t are to appear often in an interface (e.g., a help butto n ) to be defined once and then used in a group of windows or to be persistent over a period of tim e. This allows th e inter face designer to only define the object and its operations once for all its uses. By defining an object once th a t is to appear in m any places helps to insure consistency of the object across the interface and to ease th e task of modifying th e object since J it is only defined once for the entire interface. Inherited objects are drawn w ith a double edge. The H elp state in Figure 2.2.1 is an exam ple of an inherited state. S h ared D a ta N o d e s Shared d ata are values th a t can be accessed by both the user interface and th e { i application. This is th e m echanism through which th e interface can pass inputs j from th e user or attrib u tes of interface objects to the application and th e applica tion can pass values back. Exam ples of attrib u tes th a t the application m ight want to m odify are labels of objects, their position, or their dimensions. Also stippling (m aking inactive) of m enu item s m ight be done depending on a value calculated by the application or an internal state. Shared d ata nodes are draw n as parallelo gram s and are connected to a node of the user interface by a d a ta transition. The node connection is w hat defines th e object(s) to which the d ata is associated. A rray N o d e s Sometimes m ultiple instances of an object are needed, b u t it is not known how m any instances will be needed until runtim e. In these cases array nodes are used. Instances of an object (and its children) are in stan tiate by a system action. In stances can be given nam es at this tim e or they can be referenced by num ber (the J default). A rray nodes are represented by th e following: 40 J /^Bookstore Query System Browser Window /Ouery Fram e\ /" Author Frame /^Result Framed Help Window Dialog Help ) N e* W Help Frame I ^ "" I Frame 1 J Prev Heading Name Result Quit Button J A u th o i/ /B o o k s J Help Button Heading Author Subject Title Figure 2.4: Exam ple of an IRG. Browser Book Query Click on one: Query by Autho • Query by Title (Query by Subject _____________C T O Browser Author Name: OK Cancel C T O Help This is the top level of help . . . Figure 2.5: Interface described by above IRG. M isc ella n eo u s N o d e s O ther types of nodes th a t are used are start nodes, history nodes, diversions and term ination nodes. Default nodes identify a subnode as th e startin g point in a window or group. A history node is a predefined node th a t rem em bers th e last J subnode executed which can be used when the flow of control is tem porarily in terru p ted and m ust resum ed at a later tim e. A diversion is a group of nodes th at are executed as an aside to the current flow of execution and a term ination node stops execution of the application. 41 2 .2 .2 F lo w o f C o n tro l T he flow of control in an IRG is ju st like the transitions in a statech art. It represents how th e interface will change when inputs from th e user or application are received. I Flow of control can be one of three types: 1. R egular flow of control 2. Constrained flow of control 3. Indexed flow of control ) The following discusses and gives exam ples of each of the above and describes the sem antics of flow of control between different user interface com ponents. | i R eg u la r F low o f C on trol T he regular flow of control is ju st like the transitions in statech arts and are called sequences. They m ust have a source state and th e destination state can be any other state in th e IRG. Like all sequences in an IRG, they m ust have an event indicating when they will be taken and can have optional actions and conditionals. C o n stra in ed F low o f C on trol j Constrained flow of control is used to represent the fact th a t several things need to be done before execution can continue. An exam ple of a constraint on the flow of control is when a user m ust pick an item from several different lists before continuing. C onstraints on flow of control are represented by places, m uch like p etri nets [55], where the transitions all enter and only one exits.A n exam ple of a constrained flow of control is shown below. It has transitions from all nodes th at m ust be executed before th e constraint can continue (a, b, c) coming into a vertical line, out of which is a single transition going to th e destination node (d). 42 In d e x e d F lo w o f C on trol Indexed flow of control is for transferring flow of control to an array node. Since there can be m ultiple instantiations of an array node, the array item th a t control is to be given to m ust be determ ined by the application. T he array node desired is indicated either by a nam e given to it at creation tim e, or it can be referenced by its index in the array. The nam e or index m ust be passed from the application as a shared d ata value. Below is an exam ple of the parts of an index sequence. There is an event, the index indicating which array item it is attached to, a condition, and an action to execute if th e sequence is taken. E vent findexl (condition.) /a c tio y T ran sferrin g C on trol B e tw ee n C o m p o n en ts T he circum stance for a transition to be taken, the semantics associated w ith a transfer of control from one node to another and th e actions executed when th e destination node is reached is all dependent upon the types of nodes involved. If a window is the source of a transition, then whenever control is in th e window and the value listed on its transition occurs, then the transition is taken and control given to th e destination node. If a fram e is th e source of a transition, the transition is taken whenever th e listed input occurs among the fram e’s graphics. If a graphic is th e source of a transition, then whenever the listed input occurs inside th e graphic then control is transferred. If a node is th e destination of a transition, th en depending on th e type of 43 j the destination node, different results occur when th a t node is reached. If the ; destination node is a window node, then from th a t point in tim e until control I leaves th e window all input th a t occur are applied to th e nodes in th a t window, i T he window m ust then transfer control to its start state: either a group, fram e , or graphic. If a destination of a transition is a group then, like a window, its ! sta rt state is given control. If a fram e is th e destination node of a transition then th e graphics in th a t fram e are displayed in the window if it is a new fram e or the i i graphics are modified if it is a modified fram e. Finally, if a graphic, such as a dialog | box, is the destination of a transition, then only th a t graphic can receive input. , j This forces th e user to acknowledge a message or input a value before continuing j j w ith any other p art of the interface. Unlike transition diagram s or statecharts, in an IRG it is not necessary for nodes to have transitions entering and leaving them . This is due to th e fact th a t not all objects change the state of the interface or do not receiving any input. An exam ple of th e form er are radio buttons, which when selected simply set a variable and an exam ple of th e latter would be a label which does not receive any input. 2 .2 .3 D a ta in an IR G In addition to flow of control being represented in an IRG there is also d ata repre sentation. IRGs also show how d ata flows betw een certain parts of a user interface, how constraints on d ata in one p art of the interface m ay have on d ata in another p art of th e interface, and how d ata is passed back and forth betw een the in ter face and application. The following sections describe these d a ta representations in IRGs. D a ta F low D ata flow shows th e direction and inform ation th a t is to be transferred between com ponents of the interface and application or betw een interface objects. T he first type of d a ta flow is used w ith shared d ata while th e second type is used w ith constraints, which are discussed further below. D ata flow arrows are drawn w ith I a square in th e m iddle of them w ith either a “D” or “C” in the square indicating [ 44 either shared d ata flow or a constraint flow. An exam ple of transitions for both control flow and d ata flow is shown in Figure 2.2.1. C o n stra in ts C onstraints define a restriction on a graphical object and are used to indicate j th a t an a ttrib u te of one objects is defined in term s of another. Exam ples of when , constraints are needed is when one object is to be displayed relative to another j object, such as a shadow, or when one object is to display the value of another, I such as a label displaying th e value of a slider. C onstraints betw een widgets are | represented by a special transition, an interface constraint transition (ict). The | source of the node represents the widget th at is to be constrained and has as a ! destination a node representing the object to which th e source is being constrained. I I An equation is associated w ith the transition th a t represents th e transform ation j of th e source w idget’s value to th e destinations w idget’s value. C onstraints can be used when two or m ore widgets are to m aintain relative positions to each other or J display an a ttrib u te of another widget. I S em a n tic F eed back i I ! Sem antic feedback involves th e interface sending or receiving d ata from the ap- J plication. Sem antic feedback betw een the interface and application is represented I l ; through special transitions called d ata feedback transitions (D F T ) and application } feedback transition (A FT ). A D FT transfers d ata from th e user interface to the ! application and has as its source th e object supplying th e value and as a desti- j nation a rectangle representing a variable containing a shared d ata value between j th e interface and application. An A FT has as its source a shared d a ta value and as a destination a node representing the widget th a t is to be affected by th e data. T he d ata values th a t flow between th e interface and application can be attached to any attrib u te of a widget, such as its position, size, label or w hether th e widget will accept user input. 45 2.3 Formal Definition of Transition Diagrams, Statecharts, and IRGs T he following are form al definitions of transition diagram s, statecharts, and inter- j face representation graphs as how they are to be used for specifying user interfaces. t f j 2 .3 .1 F orm al D e fin itio n o f T ra n sitio n D ia g ra m s j Transition diagram s are defined as a graph T = (5, E, T, s0, T ) w here J 1. S' is a finite set of states. 2. E is th e set of valid input symbols. 3. T = { ti,t2, ... ,tn} where t,- = ((sj, s*), E{, Ai) | 1 < i ,j , k < n where (a) (Sj,Sk) £ {S x S |0 < j , k < |S |} are th e source and destination states of the transition. (b) Ei £ E, is the event needed for the transition to be taken. (c) Ai is an ordered list of actions (ai,..., am) th a t are executed when the transition is taken. 4. So is th e start state of th e transition diagram . 5. T is the set of final states = 1,... ,p} which when reached term inate the program . A tran sitio n diagram is defined to be a graph th a t contains a finite set of states (S'), a set of transitions (T ), a start state (s0), and a set of final states (E). The set of states consist of those states th a t can be reached during execution of the transition diagram and the valid inputs are m ade up of the values listed on all the transitions. Each transitions contains a pair of source and destination states, an ; event th a t indicates when the transition is to be taken and an action th a t is to j be executed when th e transition is taken. The start state is w here th e program represented by the diagram will always begin and the set of final states are those states which when reached term inate the execution of the diagram . 46 2.3 .2 F orm al D e fin itio n o f S ta te c h a r ts S tatecharts are defined as a graph T0 = (S0, T0, So, D) where r 0 is defined to be the root node of th e statech art and 1. So is equal to the set of nodes {s0} U {s, |* = 1... n} U T U 7i which appears in the root node where (a) So = {A0, r 0} is the default node for a group of nodes. Ao and To are defined as: i. Ao is an ordered list of actions (ai,..., ap) where ai £ G a U Ua U Ib U A a where Ga is th e set of possible graphic operations, Ua is th e set of user defined functions, Ib is the set of variables available for internal broadcast and A a is a null action. ii. r 0 is defined as a subgraph defined recursively to be (S,„T,i,'Z.i,T,T)uA. (b) Si = { A Si, } are the set of interior nodes for th e current level of the statechart. A S i and are defined as in (a) above for Ao and To. (c) T is th e set of final nodes = 1 . . . n} which m ark th e term ination of th e current window. If th e final node’s parent is th e root node then th e entire program is term inated. (d) TL is th e history node which is defined to be 7i = hU A , e.g., there either exists a history node for the current node or it is em pty. M ultiple history nodes appearing in th e same im m ediate parent node are redundant and are equivalent to a single history node. 2. T0 is equal to the set of transitions {tj\j = 1 ... p} where each tj is equal to the 5-tuple (S8,Sd,E tj,C ti,At.) where (a) S s C So is th e set of source nodes of the transition w ith Ss — 5 • • • 5 Ssn } > & Si £ So and | Ss | ^ 1. (b) Sd E So is the set of destination nodes of the transition w ith Sd = {Sd! ■ ■ - Sdk} where G S0 and | Sd |> 1- 47 (c) E tj is a set of events {ei,..., ep) where each e, £ 8, the set of valid events. The following is the definition of 8: The set of basic events (those events such as key press, m ouse m ovem ent, mouse b u tto n click, etc.) is denoted by 8b and the set of valid events is denoted as 8. 8 is defined inductively as: i. A £ 8, where A is th e null event. ii. If e £ 8b th en e 6 8 iii. If ei, e2 € 8 then ei V e2 € 8 iv. If ex, e2 € 8 then ei A e2 £ 8 (d) Ctj is a set of conditions {ci,..., cpj for transition tj and each C { is i defined as: The set of valid conditions is denoted C and th e set of variables is denoted as V. T he set C is defined inductively as: i. True, False £ C ii. If u, v £ V and R £ {= , > , < , < > , < = , > = } th en uRv £ C iii. If ci, c2 £ C then cx V e2 £ C iv. If Ci, c2 £ C then cx A e2 £ C (e) Atj is an ordered list of actions (ax, ... ,aP) as defined in Si above. 3. £ = UjEti |ti £ To which is the set of valid events th a t appears on th e tran si tions for th e current level of the statechart. 4. D = {X O R , A N D ) which is th e decom position of node r 0 (.i.e, w hether all or only one of its subnodes are executed). T he top level of th e graph, T0, represents th e root node of th e statech art, a set of transitions, an input alphabet, and a decom position. S q is th e set of nodes th at appear in the root node of the statechart. There are four types of nodes th a t can appear at any level of a statechart: 1. An optional “default” node, s0, where execution begins when no o ther node has been indicated. L 48 2. Interior nodes, Si, which represent th e control flow of th e program . 3. A set of final nodes, F , th a t m ark the term ination of th e current window and the program if in the root node. 4. A history node, which either exists or is em pty. T he interior nodes, s, consist of an ordered list of actions, A Si, and an optional subgraph TSi. T he ordered list of actions can consist of graphical (G a) or user defined (Ua ) actions, an internal broadcast (Ib) or a null action (A). If TS [ is defined as null, it indicates th a t th e node is a leaf node otherw ise it is a parent node and is defined recursively as a graph TS | w here s* is th e parent node of th e i subgraph. j Transitions are defined to be a five-tuple consisting of a source node (Ss), a j destination node(5'd), a list of events(i£tj), a set of conditions(CtJ), and a list of : actions (Atj). There can be m ultiple destination nodes to a transition, as long as J \ each of th e destination nodes is orthogonal to th e others (otherw ise it would be j nondeterm inistic). T he event, E tj, can be a single keyboard input, m ouse click, j m ouse m ovem ent, function result or an internal broadcast variable. Events can also be logically A N D ’ed (A) and O R ’ed (V) together w ith other events to form expressions. A set of conditions can also be given on transitions which m ust be satisfied before th e event is tested. These conditions are m ade up of variables and function results which contain or retu rn a tru e or false value. Finally, a list of actions, A*-, can be given th a t are executed if th e conditions for the transition is tru e and th e event equation m atches th e actual events th a t have ju st occurred. E is the set of valid events th a t can occur in th e current parent node. T he valid events are m ade up of all the events listed on th e transitions coming from their child states. If an event occurs and is not in this list, then th e event is passed up to the next level in th e hierarchy where it is checked against the valid events there. T he node decom position, D , for a parent node indicates w hether th e parent is of type A N D or X O R . T he A N D indicates its children are orthogonal and the X O R type indicates its children are sequential. 49 2 .3 .3 F orm al D e fin itio n o f IR G s j IRGs are defined as a graph: IR G = (N , S, C, P ) where N is a set of nodes, S is a J set of sequences, C is a set of constraints, and P is a list of properties defined as: l | 1. N = {G U O U / U A U E U D U f f U X } is a set of nodes, where i ' (a) G = {go, g\ ,..., gn } where each gi is a group of nodes th a t contains other I nodes and w ith go being th e optional starting node and gi C N. Each gi = {Gi, Wi) where Gi C G and W ,- is a window equal to {Fm U Fm ] where i. Fm = {/n,i, • • •, f n , p } is a set of new fram es th a t com pletely clear th e screen before displaying their contents ii. Fm = {/m,i, • • •, f m , q } is a set of m odify fram es (subfram es) th a t define m odifications to a new frame. j Each f U ji and f mj is equal to a set of interaction objects {io\,... ,eor } | th a t are displayed when the fram e is active. (b) O is a set of objects such as th e buttons of an interface. Each object also has a set of attrib u tes, A = {ai,..., a t) which define how an object acts (e.g., stippled) and appears (e.g., color). T he set of possible attrib u tes is defined by each interactive object. (c) / is a set of inherited nodes where \/i € I and \/gj 6 S{i)Rightarrowi 6 gi, where S(i) is th e set of siblings of i. T h at is, each inherited node is contained in each of its sibling nodes which are also group nodes. (d) A is a set of array nodes {ai,...,aM } where each a 4 - C 0. Each a * - can be replicated an arb itrary num ber of tim es at runtim e. Each then referenced by its index. (e) R = {ri,..., r y} where each r 8 - is a runtim e node and has an application function A f assigned to it th a t returns the nam e of a node g € G th at will receive control. 50 (f) D = {d\, .. . ,dz} is a set of shared d ata nodes. These nodes represent d a ta th a t can be exchanged betw een the user interface and the under lying application. (g) H is th e history node which is defined t o b e / 7 = { h U A } , e.g., there either exists a history node for th e current node or it is em pty. M ul tiple history nodes appearing in th e same im m ediate parent node are redundant and are equivalent to a single history node. (h) X is a set of final nodes {xi,..., Xj,..., x n\i = 1... «} which m ark the term ination of the current window. If the final node’s parent is th e root node then th e entire program is term inated. S is equal to th e set of sequences {St U S c U 57} betw een nodes w here (a) St = { ti, • • •, tj, • • •, tP\\j = 1... p} and each tj is equal to th e 5-tuple (Ns,N d, E Sj, CSj, A Sj) where i. N s = (nSix,..., ns> i, ..., n S)n}, is a set of source nodes of th e se quence, such th a t n sj £ N and | N s |> 1. ii. N d £ N is the destination node of the transition. iii. ESj is a set of events {ej,..., ev} where each et - £ S, th e set of valid events. T he following is th e definition of S: T he set of basic events (those events such as key press, m ouse m ovem ent, mouse b u tto n click, etc.) is denoted by S\, and the set of valid events is denoted as £. £ is defined inductively as: A. A £ £, where A is the null event. B. If e £ £b then e £ £ C. If ei, e2 € £ then e\ V e2 £ £ D. If ex, e2 € £ then e\ A e? £ £ iv. CSj is a set of conditions {ci,..., cp} for sequence Sj w ith each C i defined as: T he set of valid conditions is denoted C and th e set of vari ables is denoted as V. T he set C is defined inductively as: 51 A. True, False £ C B. If u, v € V and R 6 {= , > , < , < > , < = , > = } th en uRv € C C. If Ci, c2 € C th en cx V e2 € C D. If ci, c2 G C then cx A e2 € C v. is an ordered list of actions (ax, , ap) as defined in Si above. (b) Sc = (N s, Nd, E Sj, CSj, A Sj) is a constrained sequence. T he differences between S and Sc are the sem antics. For S, only one of th e Ssi 6 N s has to have a sequence taken for Nd to be given control, while for Sc, all Sdf G Nd m ust take their sequences taken for Nd to be given control. (c) Si is an indexed array and is equal to th e 6-tuple (Ns, N d, E Sj, CSj, A Sj,I Sj) where Nd G I (an indexed node) and 1 < h j ^ I Nd | when Is is th e index of a node in I. 3. C = (Ci, C d ) is the set of constraints between objects of th e interface and shared d a ta w ith th e application. (a) Ci is a constraint between interface objects and is equal to {c0)1, . . . , c0jn} j w ith each c0ii = (os, Od, f c(as,i, • • •, a s,n), e) where i. os is a set of source objects of the constraint ii. O d is th e dependent object of th e constraint iii. f c() is a transform ation function th a t takes one or m ore attrib u tes of the source objects and converts them into a value for an a ttrib u te of th e dependent object. iv. at> i are th e attrib u tes involved in com puting th e destination o bject’s attrib u te. v. e is th e event (as defined above) when the constraint is re-evaluated. (b) Cd is a constraint between attrib u tes of an object and an application function which is equal to { q ,i, ..., Q,m} w ith each Cd,i = (od, fa(at,i> ■ ■ ■ ■ > « 5 . n ) , e) where i. O d is th e dependent object. 52 ii. / a is the application function. iii. a t)t- are attrib u tes of th e dependent object th a t are to be passed to th e application function w here they are used in calculations to determ ine the new values of attrib u tes for th e dependent object. iv. e is th e event when th e constraint is evaluated. (c) P = {p i,... ,pt] which are global properties of objects th a t are con- i tained in the graph or subgraph they are defined for. T he properties j define global attrib u tes for all objects contained inside the node. 2.4 Mapping User Interfaces onto IRGs I t ! This section describes w hat a user interface is and how the graphical objects and j control of a user interface are m odeled by a IRG. T he first section defines th e p arts j i of a user interface, th e second section discusses the com ponents of a user interface and how th eir corresponding X Toolkit widgets [40] [66] of the X W indow System [53] are m apped onto IRGs and the th ird p art discusses th e flow of control of user interfaces and how this flow of control is represented in IRGs. 2.4.1 D e fin itio n o f a U se r In terfa ce A user interface can be represented as the tuple: U I = (Graphical Objects, Control) where the graphical objects are the p art of the user interface the user sees and th e control is th e dynam ic behavior of th e interface. T he following sections discuss t each of these item s. | I I ' G rap h ical O b je c ts ! T he graphical objects, GO = {W, 10}. W is defined to be a set of windows, W = {«?!,.. •, wn | n > 1} and I is defined to be a set of interaction objects, IO = { * i , . . . ,im | m > 1 ) . A window is a rectangular area of a screen th a t acts j i 53 as a virtu al term inal. Different types of windows are available and consist of the window widgets from the X Toolkit (see section 2.4.2). T he interaction objects are th e parts of th e user interface th a t th e user interacts w ith and consist of the non-window widgets of th e X toolkit. Each window, wj consists of a set of fram es, Fj = ..., fj,k, • • •, fj,P} where fjtk is a fram e th a t appears in window Wj. Each fram e f j tk = {*i,... ,in} where each ik G I. Frames represent points in tim e where in p u t is needed from the program to continue and consists of a set of interaction objects th a t appear at th at tim e. Frames can also be divided into frames and subfram es. A subfram e is a i | m odification to a fram e while a fram e is a com pletely new set of objects. | C on trol 1 T he control portion of the user interface, can be described by the formula: | C — Inputs + Semantic Actions -f Sequence I | where Inputs = {User Inputs , System Inputs , Data Constraints}. T he user j inputs are values th a t can be input by th e user and consist of characters typed on I a keyboard, th e pressing of a mouse button, m ovem ents of th e m ouse, sound or I any other input supported by the system . The system inputs are values th a t are j returned by an application or system program . These values can be used by the I interface as if they were entered by the user. These inputs m ake it possible for the interface to be driven by the application sometimes instead of always by the user. T he d ata constraints are an indirect form of input. D ata constraints cause one object to be tied to the value of another object. Thus w hen one object is modified, it acts as an input to another object, ju st as if th e value was input by the user or returned by th e application. Inputs are used to determ ine the flow of control of the interface, such as which fram e of the application to display or w hether to switch to a different window. Sem antic actions are the actions executed by the underlying application pro gram . Its th e sem antic actions th a t do the actual processing required by the application. T he sem antic actions are called by th e interface w hen transitions are traversed or when a node of th e IRG is reached. T he results of sem antic actions 54 W in d o w C o m p o n e n t X T o o lk it W id g e t Scrolled W indow A uto M anaged W indow Vertically M anaged W indow User M anaged W indow Prim ary W indow Scrolled W indow W idget B ulletin B oard W idget Paned W idget Form W idget M ain W indow Table 2.1: How window types are m apped onto th e X Toolkit. can be returned as system inputs and effect the appearance or execution of the user interface. T he th ird p art describes th e sequence of the frames and windows. These se quences are defined to be * 5 ' C (W u ! 2 Fi) x (W u ! 3 Fi) j which states th a t S is equal to a set of tuples where each tuple consists of either j two fram es, two windows, a fram e and a window or a window and a fram e. T he first m em ber of each tuple of S is the source fram e or window and th e second item ! the destination fram e or window. A sequence is labeled by a user in p u t or program action which defines th e input needed to for the sequence to be taken, an optional condition, and an optional program action. 2 .4 .2 U se r In terfa ce C o m p o n en ts As noted in section 2.4.1 above, th e graphical objects of a user interface can be divided into sets of windows and interface objects. Each window and interface object is described by a widget of th e X M otif Toolkit [52]. T he following two sections describe the available widgets for describing windows and graphics. W in d o w W id g e ts Table 2.1 lists th e different types of windows and window attrib u tes th a t are rep resented by M otif widgets. T he following are descriptions of each of these item s. 55 S c ro lle d W in d o w W id g e t - A view port widget is a type of window th a t allows the user to view p art of a large d a ta area through a sm aller window. Hori zontal and vertical scrollbars are added when th e d ata being viewed is larger either horizontally or vertically th an th e window. I i B u lle tin B o a rd W id g e t - A box widget is a type of window th a t m anages the I | positing of other widgets. It always tries to pack its children widgets as i closely as possible. W hen one on its children widgets is resized, deleted or j i a new widget is added, th e box widget will try to rearrange th e children so | they are packed as closely together as possible. P a n e d W id g e t - A paned widget is a type of window w here th e widgets th a t appear inside are placed in a vertical fashion. A grip appears on th e border betw een each child widget th a t lets the user resize each of the children. E n larging one child widget decreases th e size of another widget and vice versa. F o rm W id g e t - Form widgets are used for m anaging subwidgets. If a window or area of a window will contain m ultiple widgets then a form widget can be used. T he form widget does not try to put any predefined positioning constraints on the widgets it m anages b u t lets the user define th eir position. M a in W in d o w - A m ain window provides a standard layout for prim ary win dows. T he layout consists of a m enu bar at the top, a com m and window underneath, and a work area at the bottom . G r a p h ic W id g e ts As w ith th e windows above, th e interactive com ponents th a t appear in fram es are represented by M otif widgets. T he following is a list of th e available widgets and a description of each. P u s h B u t t o n W id g e t - A push b u tto n widget is a rectangular box th a t contains a te x t string or a pixel m ap (bit m ap). If the cursor is moved into th e box and a m ouse b u tto n is pressed an event occurs. T he push b u tto n widget would be the same as having a transition leaving a node w ith the event of a 56 I n te rf a c e C o m p o n e n ts T o o lk it W id g e t B utton P ush B u tto n W idget Text and Graphics Label Text E n try Text W idget Dialog Boxes Dialog W idget List of Item s List W idget M enu M enu W idget Table 2.2: How interface com ponents are m apped onto the X toolkit. m ouse b u tto n press w ith a condition th a t th e cursor be in th e button. Since the widget w aits for an input from th e user, a transition will leave the leaf node associated w ith th e widget w ith an event of a m ouse click. j i L a b e l W id g e t - A label widget is a nonm odifiable tex t string th a t is p art of a I fram e of th e user interface. It accepts no inputs and can not contain any subwidgets. It is represented as an a ttrib u te to the leaf node th a t represents th e fram e the widget appears in. i I j T e x t W id g e t - A tex t widget is a window th a t displays strings in rows. Strings i in the window can be selected and an action perform ed. This type of widget can be used for pop up windows or menus. D ia lo g W id g e t - A dialog widget is sim ilar to a com m and widget except th a t accepts tex t from the user instead of a m ouse click. T he dialog widget can have a description of the input w anted and a place w here th e input is typed in by the user. Since it has a display portion and waits for input, it is classified as an a ttrib u te to a fram e and a transition. L is t W id g e t - A list widget displays several rows of tex t which can be selected by the user. This is again a variation of the label and dialog widget since it has a display p art and w aits for input. Because of this it is also represented as an a ttrib u te of a leaf state and has a transition w ith each item th a t can be selected coming from the node th a t represents th e frame. 57 F lo w o f C o n tro l S ta te c h a r t C o m p o n e n t S tart D efault Nodes W ait for Input Leaf Nodes Resum e H istory Nodes Branching Selection Nodes Change Frames Transitions Change W indows Transitions Help and Error Actions Diversions Q uit W indows Stop Nodes H alt Program Stop Nodes Concurrency O rthogonal Nodes Synchronization Internal B roadcasts Table 2.3: How flow of control of a user interface is m apped onto statecharts. M e n u W id g e t - Allows for list of buttons to appear when a p aren t b u tto n is selected. Hierarchies of buttons are possible by allowing child b uttons to also be parent buttons. 2 .4 .3 U se r In terfa ce F lo w o f C o n tro l Table 2.3 shows how the flow of control of user interfaces are m apped onto s ta t echarts. T he following discusses each of the different type of flow of control and their corresponding representation in a statechart. S t a r t S tarting points of a user interface are represented by sta rt nodes of a statecharts. S tarting points can be used to indicate th e starting fram e of an application. They can also be used to indicate th e starting window of an application (if th ere is m ore th an one), the first fram e of a window th a t is to appear or th e first fram e of a help or error sequence of fram es (diversion). 58 W a it fo r I n p u t W hen an input from th e user is needed for th e application to continue and the direction th a t the application will go depends on th e value of th a t input then a set of leaf nodes of a statechart is used. Leaf nodes, which represent interactive com ponents, wait for an input and check th eir outgoing transitions for a m atch to th e input and then gives control to th e node th a t is pointed to by the transition. R esu m e j Resum ing a p art of an application th a t was previously in terru p ted is done w ith 1 ■ ' the history state. The m ost common use of this m echanism is for resum ing th e : ! application after a help or error fram e has been executed in response to an incorrect I • , input by th e user. C o n tro l F lo w B e tw e e n F ra m e s Control flow between fram es is done w ith transitions between a leaf node to a fram e node. T he events represent the input th a t needs to occur in th e interactive com ponent represented by th e leaf node to go to the fram e pointed to by the transition. Conditions can be used to restrict the transition, and th e actions can be used to executed user defined functions w ritten in C , perform graphic operations or set variables for future reference. C o n tro l F lo w B e tw e e n W in d o w s Control flow betw een windows of an interface are m odeled w ith transitions th a t have destinations which are parent nodes of a statech art which represent th e win dows. T he source of the transitions can either be other windows or fram es in other or th e sam e window. As noted earlier, transitions are p erm itted to cross hierarchies | of a statech art so there is no problem in a fram e in one window passing control to j another window or to th e default state in th e current window. 59 C o n tro l F lo w B e tw e en H elp an d E rrors Control flow betw een help and error fram es are accom plished w ith diversions. T he diversions are applied to m ultiple fram es of the user interface and if the given event occurs while control is at any of the fram es, the diversion gains control, perform s its operations (can be m ore th an one fram e) and usually returns control to the original fram e via a history node. O nce a diversion is activated, control does not have to retu rn to its caller. Control can be returned to another predefined p art of th e interface to sim ulate a hot key or other jum p com m and. I ! . I ; C o n stra in ed F low o f C o n tro l ! I I C onstrained flow of control is w here m ore than one event m ust take place before j a transition can be taken. An exam ple is when a user has to select an item from each of m ultiple m enus before th e next fram e is displayed. T he next fram e will not be displayed until everything has been done. There can be constrained and also unconstrained flow of control in the sam e fram e. This allows for th e user to get help, quit, or skip the input w ith out having to first do all th e d a ta entry. Q u ittin g W in d o w s and H a ltin g p rogram s W indows in a statech art can be term inated by executing a h alt sta te in th e parent state th a t represents the window. T he halt state causes th e current window and all subwindows to be closed. If the h alt node is executed in th e root node of the statech art, th e entire application is stopped. C o n cu rren cy Concurrency can exist either between objects appearing in the sam e window or betw een separate windows. Concurrency w ithin windows is specified by first defin ing th e set of objects th a t are to all accept the sam e inputs at th e sam e tim e. Sequential states for each of these objects are defined by th e user which m odel the objects. These states define w hat actions are to be taken on a given input. A fter each of the o b ject’s states have been defined, they are all collected into a parent node and are defined to be orthogonal to each other. W hen control reaches the 60 parent node, th e orthogonal subnodes th a t m ake up th e parent are started . Each orthogonal subnode has defined a sta rt node w here execution will begin. All events th a t occur while control is in the parent node are applied to all orthogonal com po nents. C ontrol can leave th e parent node either by a transition th a t is connected directly to th e parent node or by a transition connected to any node/subnode in one of th e orthogonal com ponents leaving th e parent node. C oncurrency betw een separate windows is specified in a sim ilar way to concur rency w ithin a window, except th a t nodes representing th e concurrent windows | are specified as being orthogonal. This causes th e inputs in one window to be applied to th e statecharts of all th e other orthogonal windows. Any two or m ore windows can be defined as being orthogonal to each other, even though they do not necessarily share th e same parent window. S y n ch ro n iza tio n Synchronization of concurrent parts of a user interface are done through the internal broadcast. T he broadcast is tested for in the orthogonal nodes th a t do not execute th e broadcast. Synchronization is needed w hen one orthogonal com ponent m ust restart and m ust inform th e other parts to do th e same thing or w hen one p art is in a state th a t needs to be com m unicated to th e other p arts so they can take I appropriate action. 1.5 Advantages of IRGs for M odeling User Interfaces T he use of tran sitio n diagram s for th e specification of user interfaces has been suggested by P arnas [?], Jacob [?], W artik and P y ster [?], and W asserm an [?] [?] and statech arts by H arel [?] and W ellner. IRG s have th e following advantages over tran sitio n diagram s and statecharts: • H ierarchical heterogeneous nodes. • Event driven. 61 • D ata flow. • D ata and control flow constraints. • Sem antic feedback. • Diversions. • Separation of th e interface from the application. T he prim ary difference betw een IRGs and statecharts or transition diagram s is th a t the statecharts and transition diagram s only show flow of control, there is no indication of w hether the nodes represent an object or ju st a grouping, no m eans of indicating inheritance, flow of d ata betw een the different objects and the application, constraints on th e control or d a ta flow, or the definition of the interface betw een th e user interface and application. In addition, statech arts and transition diagram s always assum e th a t the interface is in a given sta te at a given tim e, which is contrary to th e im plem entation of graphical user interfaces such as the M acintosh and X windows based user interfaces. T he following gives a discussion of each of the above advantages. 2.5.1 N o d e S tru ctu re T he hierarchical nodes of IRGs lend them selves well to th e representation of th e n atu ral hierarchies found in user interfaces. T he different types of nodes represent- ing different types of constructs aids in the description of an interface. T he hierarchy of IRGs also helps to supports top down design. T he designer of an interface starts w ith th e definition of th e windows, which correspond to th e outer m ost nodes of the statechart. Each of the frames for the windows are then defined which give th e leaf nodes inside the window nodes and then th e diversions are defined th a t group th e leaf nodes into subnodes. At each of th e levels, hierarchies of transitions are also defined th a t move the user up and down through th e levels of the IRG and from one fram e to another. T he grouping of nodes th a t perform sim ilar functions is also a powerful m ech anism in statecharts. In Figure 2.2 it can be seen th a t nodes D and E perform ! a subtask and th a t subtask is term inated by an input of either z, v or y. The i j hierarchy of statecharts also provides m odularity of design, ease of m odification, j and encourages reuse of the design. I j Inheritance of objects into a node allows th e single definition of an item ’s ap pearance and operation once. This centralizes th e place of definition to allow easy future m odifications and to insure consistency of operation of th e object every tim e it is used. W ith transition diagram s or statecharts, th e item would have to i be defined each tim e th a t it was needed, thus m aking it necessary to rem em ber all th e places where th e object is being used and opens the door to inconsistencies as th e object is modified over tim e. i 2 .5 .2 E v en t D riv e n G raphical user interfaces ten d to be event based system s. In event based system s one of m any inputs can occur from several interface objects th a t are displayed in possibly several windows. This m eans th a t the interface can change state depend ing on the active window and the active interface object. Because of this, the m odel of interaction has to be able to change states in an im plicit m anner w ithout th e designer having to explicitly note all the possible details. S tatecharts and tran- ■ 1 sition diagram s m ust always be in a specific state at all tim es and execution m ust 1 continue from there. In IRGs, there is no explicit flow of control from a fram e to any of its children. All children are capable of receiving control if an event occurs in them . This is also tru e of th e windows in th e interface. A ny window can be given control depending on w hether the user gives it control. 2 .5 .3 D a ta F lo w A m ajor p art of any interface specification is th e definition of th e interface between th e user interface and the application. This second interface defines how d ata will be passed betw een the user interface and application. D ata needs to flow between th e user interface and application so th e application can perform calculations based on th e user input and d ata needs to be passed back to the interface to be displayed. 1 i D ata flow allows values to be passed betw een the interface and application as well as 63 betw een interface objects. This is som ething th a t neither statecharts or transition diagram s addresses. i 2 .5 .4 C o n stra in ts on D a ta an d C o n tro l F lo w I { T he appearance or placem ent of an interface object is often dependent on the I i appearance and placem ent of other objects. By constraining d a ta of one object 1 to be defined in term s of another object, th e dependencies betw een objects can j be specified. This type of d ata dependencies is not available in either transition diagram s or statecharts. The reason why is th a t th e transition diagram s and statecharts are only concerned w ith the flow of control of the system being m odeled | and not th e d ata th a t define th e objects which are causing th e flow of control. j C onstraints on control flow are useful in specifying user interfaces because it is j often th e case th a t several things need to be done before execution can continue. It j i is possible to specify these constraints w ith transition diagram s or statech arts, b u t all possibilities of th e order of these events have to be defined or a specific order in which th e tasks are to be done have to be defined. W ith IRGs, it is im plicit th a t there is no ordering on the activities. All th a t has to be defined is th e activities them selves w ith no regard for ordering or sequencing. 2 .5 .5 D iv e r sio n s W artik and P yster [68] point out a problem in specifying user interfaces called diversions. It was noticed th a t each node of a transition diagram has to have its own help and error nodes since transition diagram s have no m emory. Each node of th e interface had to have transitions going back and forth from these nodes even though th e help and error nodes m ay have been shared am ong several different nodes. This essentially doubled or trip led th e num ber of nodes of th e user interface. An exam ple of a transition diagram where each node had to indicate help messages and error messages in shown in Figures 2.6. All theses ex tra transitions for every node of th e user interface clutters up th e rest of the transition diagram J which m ake it m ore difficult to read. W artik and P y ste r’s solution to the problem I ! was to im plicitly associate these transitions and nodes w ith each node. W hile their ! 64 Figure 2.6: T ransition diagram w ith transitions and nodes for help and error m es sages. solution cleaned up transition diagram s of the ex tra transitions and m ade them easier to read, it also hid the fact th a t these help and error messages existed. It still required th e designer to explicitly indicate each node and its corresponding help and error nodes and also did not show th a t a group of nodes share the same help or error messages. S tatecharts solve the diversion problem by having transitions for help and errors occurring at th e level of the parent node. T here is one transition leading from th e parent node for the help node and one for the error node to these nodes outside th e parent. This high level transition applies to all nodes in th e parent and elim inates having to have transitions from each one of them . C ontrol is returned to th e node th a t goes to th e help or error node by using a history node. An exam ple is shown in Figure 2.7 w here there are transitions leading from node A to nodes h e lp and e r ro r . These transitions apply to all inputs while inside of A. This m eans th a t w henever an ‘H ’ is typed while in node A , control will be taken to h e lp and then returned again to th e originating node via the history node. In this way the 65 £ Help W indow 1 Help W indow 2 W indow 1 W indow 2 Figure 2.7: T he way diversions are handled in statecharts. ex tra transitions going back and forth from each node to help and error nodes is elim inated while still displaying the history and error nodes them selves. 2 .5 .6 S ep a ra tio n o f In terfa ce an d A p p lic a tio n Separating th e user interface from the com putational p a rt of an application is a desirable attrib u te of an application. By separating these two p arts, one p art can be modified while not affecting the other. If they are interw oven, m odification of th e com putational p art can effect the user interface and vice versa [25]. W hen a separation of the user interface and th e underlying application is m ade, th e application is one of: I n te rf a c e d riv e n - th e interface determ ines w hat com putation is to be executed 66 next. C o m p u ta tio n d riv e n - th e com putations of the application determ ines w hat p art of the interface will be executed. B a la n c e d - both the interface and th e com putational p a rt can determ ine the direction th a t th e application will go. W ith IRGs all three of the above approaches are possible. A n interface driven application is accom plished by allowing the IRG to m ake function calls from tra n sitions and nodes. Allowing events to be defined as function results allows the com putations m ade by the application to drive th e interface. A m ixture of the above two allows a balanced approach. In any of the three cases, th e com putation p art of th e interface does not contain any interface code while th e com putations of j th e applications are m ade in separate functions w ritten by th e designer enforcing I separation of interface and com putation. I | 2.6 Examples of User Interfaces and their IRGs 1 i | T he following section contains four exam ples of user interfaces and w hat their cor responding IRGs would look like. T he first exam ple is a form oriented user interface th a t lets a user search for a book in a database system . T he second exam ple is a m ultiw indow user interface th a t is a subset of the FIG graphics editor th a t runs on the SUN M icrosystem s w orkstation. T he th ird exam ple is a gam e sim ilar to P ac M an th a t contains concurrency w ithin a window. T he fourth exam ple which illustrates parallelism between windows is a typing tu to r w here th e user types into one window and statistics on the user’s typing is displayed in a second window. 2.6.1 F orm E x a m p le T he form exam ple is a single window interface th a t displays a sequence of predraw n fram es where th e user answers a question which determ ines th e next fram e to be displayed (see Figures 2.8-2.11). Function results are used to determ ine w hether 67 a search for a book is successful and then uses this value to select th e transition to be taken. I n te r f a c e C o m p o n e n ts T he first fram e of the interface shown in Figure 2.8, consists of a form widget window w ith the tex t inside of th e window m ade up of label and push b u tto n widgets. The T itle and th e instructions are b o th label widgets since th e user does not need to select or m odify these values and th e m enu item s are all push b u tto n I widgets since they need to be selected by th e user. | T he second fram e of th e interface is shown in Figure 2.9. T he title and instruc- ! i tions are again label widgets w ith the user input area defined to be a tex t w idget I i which accepts input from th e user. | In th e th ird fram e in Figure 2.10 th e title, labels and note at th e b o tto m of th e page are represented as label widgets since they do not need to be m odified or selected w ith the areas directly to the right defined as label widgets whose values are not supplied until execution tim e. Since an in p u t from th e user is needed for th e application to continue back to the first fram e, a push b u tto n w idget is used at th e b o tto m of the fram e which the user can select and has an action of going back to th e m ain m enu, j T he fifth and last fram e shown in Figure 2.11 contains all label widgets since none of th e fields in th e fram e need to be selected. As in the previous fram e, an in p u t from the user is needed to retu rn control to th e m ain m enu of th e application. As in th e above fram e, a b u tto n widget is provided b u t not displayed where the in p u t from th e user is accepted. I R G R e p r e s e n ta tio n T he IRD for th e form user interface is shown in Figure 2.2.1. T he root node is called B o o k S e a rc h . This is where th e interface begins and has associated w ith it any application initialization actions (such as opening the database). T he child node of B o o k S e a rc h is square and represents the window in which the application will appear. Inside th e window are th e different fram es th a t will be appearing in th e 68 W e lc o m e to th e B o o k S to re D a ta b a se Please select one of the below operations by placing the cursor over the item and clicking a mouse button. Search for a title Search for an author Search for a publisher Help Quit Figure 2.8: D atabase operation fram e. 69 B o o k S to re D a ta b a se T itle Q uery Please type in th e title of th e book you are looking for or press the Escape key to retu rn to th e m ain m enu. Figure 2.9: T itle search fram e. 70 B o o k S to re D a ta b a se T itle Q uery Results T IT L E : A U T H O R : P U B L IS H E R : B O O K N U M B E R : P R IC E : N U M B E R IN S T O C K : Click Here to C ontinue Figure 2.10: Fram e for successful title query. 71 B o o k S to re D a ta b a se T itle Q uery Results T he book store does not carry the queried book. Click Here to Continue. Figure 2.11: Fram e when title query fails. 72 window. T he leftm ost fram e, M a in M e n u F ra m e has a default arrow pointing at it and will be th e first fram e to be displayed. Inside the M a in M e n u F ra m e are nodes representing th e label and push b u tto n widgets th a t will appear in th e frame. The push b u tto n widgets have transitions leaving th em to indicate th a t when th e buttons are pushed a new fram e will be displayed. For exam ple, the title b u tto n has a tran sitio n leafing it going to the T itle fram e and the author b u tto n has a transition leaving it going to th e A uthor fram e. The title and author fram e nodes also have nodes in them representing labels th a t are th e headings of the fram es and a tex t widget where th e user types in a string. T here are no transitions leaving th e label widgets but th e te x t widget has two transition leaving it. In this case th e transition taken is not dependent on th e input from th e user, but w hether the database query was a success or failure. D epending on w hether the query is a success or failure th e next fram e displayed is either T itle S u c ce ss or T itle F a ilu re . The success fram es contain widgets representing label widgets th a t contain th e headers, label widgets th a t represent the retu rn ed values, and a push b u tto n widget th a t returns the user to th e m ain m enu. T he failure nodes are sim ilar, except th a t there is a label nodes representing J th e header labels, a label node representing th e value th a t th e system was not able ; to find, and a push b u tto n th a t returns the user back to the m ain m enu, j and appears in the upper left hand corner of the root node. T he startin g node of th e IRG is indicated by the start transition at node Welcome, where an instructional fram e is shown and any initialization actions are done, such as opening the database. From the Welcome node, a default transition is taken to th e parent node S e a rc h C h o ic e . Since S e a rc h C h o ic e is a parent node, one of its children m ust be given control. Since the transition from node W e lc o m e does not indicate a startin g node and th e node M a in M e n u has a starting tran sitio n going to it, th e node M a in M e n u is given control next. T he M a in M e n u node displays a screen giving search options and instructions on th e use of th e program (see Figure 2.8). T he next node to be reached from this node depends on th e user input. If a num ber betw een 1 and 3 is typed a fram e is displayed to search for either a book title, an author or book num ber. A £ 4’ prints a help m essage and a ‘5’ exits the 73 program . At this fram e, anything besides a num ber betw een one and five or an ‘H ’ will prin t an error message. A global help com m and is also available th a t can be called from anyw here in th e user interface by pressing the help key. T he node is labeled H e lp M sg and has a transition leading to it from the B o o k W in d o w node. T he transition leading from the S o u rc e D iv e rg e n c e node indicates th a t if th e H E L P key is pressed while in any of th e child nodes of B o o k S e a rc h th e transition will be taken. W hen th e H e lp M sg node is reached a m essage is p rinted describing how to use th e system . W hen the user presses a key, control is transferred to th e history node in th e S o u rc e D iv e rg e n c e node where the last node executed is resum ed. If the global help had been specified as a transition diagram , a help node and two transitions would have had to been added to each node where th e help function could be called from. This would have required one transition coming from th e calling node and one transition going back to th e calling node. This would have added a to tal of six nodes and twelve transitions, while in th e IRG version it only cost two nodes (the help and history) and two transitions. A definite reduction in graph clu tter and a corresponding increase in readability of the graph is m ade by th e diversions. 2 .6 .2 M u ltip le W in d o w E x a m p le T he m ultiple window exam ple is a subset of the FIG graphics editor which runs on a SUN w orkstation under Suntools [65]. T here are three windows in th e editor: a m ain window, a com m and window and a pop-up window (see Figure 2.6.2). T he m ain window is where the draw ing of objects is done. O bjects are draw n or m odified by the user clicking a m ouse b u tto n at the place w here an object is to be draw n or over the object th a t is to be modified. T he com m and window is used to select the type of object to be drawn or th e type of m odification to be m ade. Only one com m and can be selected at a tim e and when it is, its icon is displayed in reverse video. A popup window contains a set of file com m ands th a t can be selected when th e cursor is in the drawing window by pulling down th e cursor while th e th ird m ouse b u tto n is pressed. 74 I n te rf a c e C o m p o n e n ts T he user interface of th e Fig graphics editor is shown in Figure 2.6.2. T he en tire interface as shown appears in a form window th a t contains th e draw ing and com m and windows. T he com m and window is also a form window which contains push b u tto n widgets w ith pixm aps. T he draw ing window is a graphics window th a t allows graphics to be draw n and tex t to be w ritten on it. T he pop up window th a t appears in th e drawing window is defined as a m enu th a t appears when the right m ost b u tto n of the m ouse is pressed. R o o t L ev el I R G T he m ain IRG for F IG is shown in Figure 2.13. This IRG represents the flow of control betw een the draw ing window and the com m and window. T he popup I window is not represented in the root window because it is a subwindow of the 1 drawing window and is represented there. Execution of th e graphics editor begins in the com m and window which is indicated by the startin g transition in Figure 2.13 going to node c o m m a n d . Execution of the com m and or drawing window is | im plicit and is perform ed by th e user moving the mouse cursor out of one window | and into th e other. As th e cursor is moved from one window to the next, control | is transferred from one window node to the other. W hen control is transferred j to either th e com m and or drawing window their IRG (in Figures 2.15 and 2.14) ! are executed u n til the cursor is m oved out of th e window, w here upon the other subnode is executed. C o m m a n d W in d o w IR G T he IRG in Figure 2.14 describes the flow of control for th e com m and window j j which is a child of the root node in Figure 2.13. This IRG sim ply states th a t J w henever th e m ouse b u tto n is clicked, th e icon under the cursor is highlighted and th e previously highlighted icon is inverted back to norm al m ode and a shared d ata value is set which can be accessed by the application. T he com m and window is drawn when th e application is initially brought up. Control starts at th e c o m m a n d node where an in p u t of a left b u tto n m ouse click 75 FACILITY FOR INTERACTIVE GENERATION OF FIGURES V. 2.0 Protocol V. 2.' 0 o o ® S S S >£ > P i io 1 ; > § s piJ § / ? \ ? K 0 - 0 % 0 - 0 & 4 V n-r-, . . i * A ^r- l « t e xl « t e x j J V j B ------ I t t H -*s— - * ■ + ■M m m i « In I 2 3 4 T im es-R om an | READY | SAVE a n a Q.UIT QUIT. SAVE || READ I EDIT | c d ir ] PDIR ■STSel. Specifn 9 Figure 2.12: Screen for FIG graphics editor. 76 r FIG Command Draw 1 V _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ J * I Figure 2.13: IRG for m ulti window user interface. j is aw aited. T here is one d ata flow transition coming from this node for each icon in th e com m and window. Each transition is labeled w ith the event of L e ft B u tto n . T he difference betw een each of the transitions is th e d a ta value stored in th e shared variable. D ra w in g W in d o w IR G W hile th e cursor is in the drawing window A transition is taken when either the right or left b u tto n is pushed. If th e right b u tto n is pushed, control is transferred to th e popup node which is a parent node for a pop up window described in table 2.4. If the left b u tto n is pushed the current object selected in th e com m and window is positioned at the current cursor position. If the size of the object can be selected, m oving th e m ouse changes the size of th e object while clicking th e m iddle b u tto n sets th e size of th e object and restarts th e drawing IRGs at the beginning. If th e object being draw n is instead a m ultiple point object (e.g., a polygon) then each click of th e left b u tto n defines a new point for the object while th e m iddle b u tto n signifies th e end of th e points to be inputed. j T he IRG in Figure 2.15 describes the flow of control of th e draw ing window and i I Command Window Square Button Circle Button Commani v T y p e , Text Button Figure 2.14: IRG for com m and window of m ultiw indow user interface. 78 is th e child of node draw in Figure 2.13. As in the com m and window, the drawing i window is draw n when th e application is started. Control sta rts at th e default node i where an event of a left m ouse b u tto n is aw aited. T here is one transition for each of th e com m ands leading from th e default node, each labeled w ith le ft b u tto n and a condition w ith th e nam e of a com m and on it. T he condition is actually th e result of a test of a user defined variable th a t evaluates to either T R U E or F A L S E . T he transition w ith th e current com m and listed in its condition is the one taken when the left b u tto n of th e mouse is pressed. If the rectangle com m and is currently in effect when th e left b u tto n of the m ouse is pressed, th e top transition coming from th e default node to th e rectangle node is taken. T he current cursor position at this point is defined as the center of th e rectangle. T here are only two transitions coming from the rectangle node: one for when the m ouse is moved and one for when th e left b u tto n is released. W hen th e mouse is m oved the M o v e M o u se transition is taken. T he transition leads back to the node w here it originated (the source node is the sam e as the destination node) w here the action D ra w D o tte d R e c ta n g le is executed, which erases th e j previous rectangle and draws a new rectangle w ith th e center at the point where th e cursor was when the left b u tto n was pressed and a diam eter dependent on how far th e cursor is currently from th e center. T he second tran sitio n leading from the * rectangle node, R e le a s e L e ft B u tto n , is taken when th e left b u tto n on th e mouse is let up. This transition then returns control to the default node w here another rectangle can be drawn. P o p u p W in d o w S ta te c h a r t T he popup window is brought up when th e right b u tto n of th e m ouse is pressed while the cursor is in the draw ing window. T he popup window consists of a vertical list of com m ands th a t are selected by p u ttin g th e cursor on top of th e com m and desired and letting go of the right button. T he com m and th a t th e cursor is over is highlighted, and if th e cursor is moved out of th e window, th en none of the com m ands are highlighted. If th e right b u tto n is released while th e cursor is outside of th e window then none of the com m ands are executed. In any case, when the 79 D raw W in d o w M ove M o u se P ress L e ft B u tt o n ( re c ta n g le ) R elease Left B u t t o n R ig h t B u tt o n R elease R ig h t B u tt o n P re s s D ra w in g Solid C ircle D ra w in g D o tte d C ircle In D ra w in g W in d o w D ra w D o tte d R e c ta n g le P o p u p W in d o w Figure 2.15: IRG drawing window of m ultiw indow user interface. 80 W indow Item A ction Nam e Save W rite File Read R ead File Q uit H alt Table 2.4: Table of popup window item s and corresponding actions. right b u tto n is released control is returned to the parent statech art after executing th e selected com m and. All popup windows work in th e above way. W h at is supplied is a list of com m and nam es th a t are to be displayed when the popup window is brought up and a list of actions to be executed if a com m and is chosen. Table 2.4 shows th e nam e of th e com m ands and th e actions th a t are to be executed for the popup window in this exam ple. 2 .6 .3 M u ltip le W in d o w C o n cu rre n c y E x a m p le This exam ple shows how concurrency betw een windows is m odeled using IRGs. Concurrency betw een windows consists of events in one window producing actions in another window. This is specified by th e user giving the actions of each window separately and then defining the two windows to act in parallel. W hat this does is produce independent sub-nodes for the concurrent windows and then m akes them orthogonal to each other. T he following exam ple uses m ultiw indow concurrency. It is a typing tu to r th a t utilizes two separate windows, as shown if Figure 2.16. T he first window is used to display characters th a t th e user is to type and th e actual keys under them th a t were pressed by the user. T he second window is used for giving a running display of the to ta l num ber of words typed, the current num ber of m isspelled words and th e num ber of words per m inute being typed. A t any tim e th e user can ty p e a Control Q to quit or a Control P to pause th e program . I 81 T y p in g T u to r P r e s s A n y K e y t o S t a r t L e s s o n a d s f j l kh q e w r u i o y z c x v b n m . T y p i n g S t a t i s t i c s WPM Figure 2.16: Typing tu to r user interface. 82 I 1 Figure 2.17: IRG for concurrent window user interface. . In terfa ce C o m p o n e n ts ’ T he window where th e typing is displayed is defined as a form window w ith each ; line th a t is to be typed in by th e user is defined as a dialog widget. Each dialog I widget is m ade so th a t th e top line is w hat is to be typed by the user and the second I line is w hat is to be typed in. T he num ber of dialog widgets is dependent on th e i am ount of tex t th e user is to type. T he statistics window is defined as a form i widget window which contains label widgets. For each statistic being displayed I there are two label widgets, one th a t displays th e nam e of the widget and a second j one whose values are updated. * I I ! R o o t N o d e J I j T he characters ty p ed by th e user are used as inputs to both windows. Since each window needs th e keys typed as its inputs, the nodes th a t m odel each window will be declared as orthogonal to each other. Figure 2.17 shows th e root node for [ th e application w ith its two orthogonal subnodes for the two windows. T he typing I window is where characters th a t th e user is to type are displayed and is represented j by the left hand p art of th e root node w ith th e statistics window being represented i by th e right hand node of th e root window. Execution of the IRG begins by the typing and th e statistics nodes both becom ing active at th e sam e tim e. T y p in g T u t o r T y p in g S ta ts W in d o w W in d o w Ap d e fa u lt T y p in g W in d o w E N D AQ d e fa u lt ch a rs = m a x d e f a u l t / b r o a d c a s t ( b e g in ) d e f a u lt E S C d e fa u lt P r in t C h a r tfove C urso i P r in t In s tr u c tio n s P r in t S ta r t in g F r a m e P r in t H a lt F ram e ; H a lt Pause P r in t Q u it o r C o n ti n u e F r a m e P r in t N ew F r a m e Figure 2.18: IRG for typing window. 84 d e fa u lt AP S ta ts d e fa u lt V t i m e r ( l ) AQ beg in E S C I n itia l S ta ts (zero s) P r in t C u r r e n t S ta ts H a lt P r in t F in a l S ta ts Pause Figure 2.19: IRG for statistics window. , T y p in g W in d o w I T he typing window starts by displaying directions on how to use the program and explains the positioning of th e hands on th e “hom e position” of th e keyboard. W hen the user has finished reading the tex t th e user types a key and the typing fram e is displayed which contains th e first set of characters for the user to type. W hen th e user presses th e space key the lesson starts. C haracters are displayed j which th e user is to type w ith th e actual characters being typed are p rinted un- j derneath th e corresponding letter th a t should have been typed. | T he first node of th e IRG , P r in t I n s tr u c tio n s is th e initialization node where the instruction fram e is printed. There is only one tran sitio n leading from this node which has an event of d e f a u lt, which is traversed on any in p u t from th e keyboard. T he next node has an action of displaying th e startin g fram e which contains the first lesson to be displayed. There is only one tran sitio n leading from this node which represents a keystroke from the user to signify th e sta rt of th e lesson. T he ' next node has an action of displaying the character typed under th e first character and m oving th e cursor under the next character. Each of th e next characters typed by the user returns execution to this node via the default arrow w here th e character typed is displayed and the cursor moved under the next character. If at any tim e the user presses th e escape key, the transition labeled “ESC ” is taken to th e next node where th e user is asked w hether he wants to sta rt over or quit. If a ‘c’ is typed a transition is taken back to the P r in t I n s tr u c tio n s N o d e and if he types a £ q ’ th e transition to th e final node is taken where an ending fram e is displayed and th e application is halted. T he above nodes are all enclosed in a parent node th a t has two transitions coming from it for the quit and pause com m ands. T he pause transition is labeled C o n tro l P and goes to a node where a help window is displayed explaining the * tu to r and how the hands are to be placed on th e keyboard. A transition from this node leading back to a history node in th e parent node is taken when the user presses any key and returns the user back to th e node w here th e interruption occurred. T he stop transition is label C o n tro l Q and goes to a final node (doubled edged) and signifies the end of the window. S ta tis tic s W in d o w T he statistics window starts by displaying the initial fram e w hich lists all of the statistics to be displayed w ith values of zero. It then w aits for an in tern al broadcast of “Begin” from th e typing window which signals th a t th e typing has started and th e next set of inputs coming from the user are to be used as statistics. New statis tics are p rinted either every second or whenever a key is pressed. T he gathering of statistics continues u n til it receives another broadcast th a t signals th e end of the typing. T he above statistic nodes are also enclosed in a parent node th a t has two transitions coming from it. T he left hand transition represents th e quit com m and (C o n tro l Q ) which leads to a stop node th a t closes th e statistics window. T he second transition represents th e pause com m and and when it reaches th e p a u s e node, stops th e tim er counting the words per m inute of the typing and displays a P A U S E m essage on the statistics window until another key is typed which returns control back to where it was before th e C o n tr o l P key was typed via a history node. 87 C h a p te r 3 A n E n v ir o n m e n t for S p e c ify in g U se r In terfa ces This chapter describes an environm ent for specifying a user interface. This en vironm ent gives th e designer of the interface a m echanism to precisely describe the layout and flow of control of th e interface to th e custom er as well as to th e software designers of th e proposed application. T he environm ent will be based on a direct m anipulation language which uses th e X Toolkit to define the interface and statecharts to represent th e flow of control of the interface. T he first section of this chapter gives a brief introduction to direct m anipulation languages: a def inition of w hat they are, attrib u tes of one, and how they have been used in other applications. T he second section describes the specification environm ent and how a designer would use it to specify an interface. T he th ird section tells how th e specification is m apped onto th e statecharts described in th e previous chapter and th e fourth section gives three exam ple specifications of the applications given in chapter 2. 3.1 Direct M anipulation Languages T he environm ent th a t will be used to specify th e user interface will use a direct m anipulation language. This language will allow an interface designer to specify the interface by draw ing it directly. T he following sections describe w hat a direct 88 m anipulation language is, gives some exam ples of direct m anipulation languages, and discusses how previous direct m anipulation languages have been used to specify user interfaces. 3 .1 .1 D e fin itio n o f D ir e c t M a n ip u la tio n L a n g u a g es D irect m anipulation languages have been called “w hat you see is w hat you get” program m ing [62]. T he prim ary purpose of a direct m anipulation language is to allow th e continuous viewing and m odification of objects of interest (in our case user interface objects). N on-direct m anipulation languages force a program m er (or specifier) to give descriptions of objects. T he creation and m odifications of an object are done by indirectly describing th e object or m odifications to be m ade and then executing th e descriptions by m eans of an in terp reter or compiler. A ttr ib u te s o f D ir e c t M a n ip u la tio n L an gu ages Shneiderm an in [62] gives the following list of attrib u tes found in direct m anipula tion languages: • Continuous representation of th e object of interest. • Physical actions instead of a com plex syntax. • T he im pact of operations are im m ediately visible. • A spiral approach to learning. T he continuous representation of th e object of interest is w hat enables th e object to be seen and m anipulated and allows the user to view th e current state of the object at all tim es. T he actions used to m anipulate the object are physical in n atu re in th e since th a t th e object is modified by th e user referring to th e object itself and showing how to m odify it, as opposed to other types of languages th at describe how the m odification is to be done. Because th e object is being modified by direct reference, the result of the m odification is im m ediately seen. If the wrong m odification is m ade, th e results of this can be easily seen and corrected. The spiral approach to learning a language allows a user to sta rt using th e language 89 _ w ith a sm all subset of th e available com m ands and as th e user becom es m ore sophisticated m ore powerful com m ands can be used. This allows a person to begin using a language quickly and get im m ediate results w ithout having to first go through large am ounts of training. B e n e fits o f D ir e c t M a n ip u la tio n L an gu ages Shneiderm an also lists th e benefits of direct m anipulation languages as: • Novices can learn the basic functionality quickly. • E xperts can work extrem ely rapidly. • In te rm itten t users can rem em ber basic concepts of th e system . • Error messages are rarely needed. • Users can im m ediately see the results of th eir actions. • Users experience less anxiety because th e system is easy to understand and actions are easily reversed. • Users feel confident because they in itiate an action, feel in control and can predict system responses. D ue to th e spiral approach, novices learn the basics of th e language quickly and can sta rt working w ith little instruction while picking up m ore advanced com m ands as they use it more. Also due to the spiral approach, experts are able to use advance com m ands th a t allow them to perform m ore com plex operations. Due to th e absence of a com plex syntax, in term itten t users can use the system w ith the basic com m ands and get by w ithout spending a lot of tim e relearning th e system each tim e they use it. Since the object of interest is being m anipulated directly and th e lack of com plex syntax in the language, error messages are rarely needed because errors m ade in m anipulating the object are im m ediately seen and there is no com plex syntax to th e language th a t the user can get wrong. Since th e users can see w hat they are m odifying, they are m ore at ease w ith w hat they are doing which in tu rn gives them m ore confidence in using the language. 90 3 .1 .2 E x a m p les o f D ir e c t M a n ip u la tio n L a n g u a g es D irect m anipulation languages have been used in several areas of com puter science I and are not program m ing languages. T he following are some exam ples of direct J m anipulation languages. i I Full S creen E d ito rs * 1 J Full screen editors are classic exam ples of direct m anipulation languages. T he j object of interest is a tex t file and th e editor allows viewing lines of the tex t file j i at all tim es. T he actions used to m odify a file are physical in n atu re and the i results of th e com m and are im m ediately visible to th e user. For instance, to delete a character on a line the user would page down until th e line to be modified is I displayed on th e screen, th e user would next move the cursor up or down until it [ i is on th e line, move the cursor over to the character to be deleted and th en give | the delete character com m and which would cause th e character to be im m ediately j rem oved from th e line. If th e user issued one too m any up/dow n line com m ands j i and passed th e line to be edited, the results would be seen im m ediately and easily j corrected. Finally, a novice user can learn ju st a few com m ands (e.g., up/dow n | page, forw ard/back character and delete line/character) to get sta rted and then j build up their repertoire of com m ands as they gain m ore experience. I I Com paring a full screen editor to a line editor, the difference betw een a direct j m anipulation language and indirect m anipulation language can be seen. W ith a line editor, the contents of the file are not continuously displayed. If the current line needs to be displayed, a com m and m ust be given to show it. T he actions needed to perform an operation on th e file are not physical in n atu re, but are given in a series of indirect com m ands. For exam ple, to delete a character of a tex t file w ith a line editor, the user would have to know which line th e character is on or do a search for the character to m ake th a t line th e current editing line. In either case, th e new current line is not displayed or any p a rt of th e rest of the file is displayed in route to th e line of interest. Because of this, one of th e things people are constantly doing while using a line editor is displaying th e current line and several lines above and below th e current line to get a feel for th eir location in the tex t file; som ething th a t’s obviously in a full screen editor. If th e w hereabouts of th e line in th e file is not known, th en a series of print line com m ands m ust be J given to list sections of th e file until the defined line is found. To m odify a line in a line editor the line m ust be either retyped, a character su bstitution m ust be given, or th e character num ber in th e line m ust be known. As in finding th e line, th e user is not shown the results of th e m odification unless the user explicitly asks for the new line to be printed. As can be seen, th e line editor modifies th e file in an indirect m anner by having th e user give a series of w ritten j com m ands to m odify or move about a te x t file, the results of which are not seen unless explicitly given com m ands to p rin t th e results of a m odification. S p read S h e e ts i Spread sheets allow th e direct m anipulation of rows and columns of data. T he j object of interest in spreadsheets are d a ta values displayed in a table. T he d a ta is ; m anipulated by form ulas th a t express how th e d ata in th e rows and colum ns are , to be treated . T he results of th e form ulas on th e d a ta are shown at th e end of ' l each row or th e bottom of each column. If the form ula or a d ata value is changed, • I th e result for th a t row /colum n is im m ediately changed to reflect th e new values or j form ulas. ! I A t all tim es, the user can see the d a ta being m anipulated and the form ulas th a t j do the m anipulating. If th e user w ants to change a value or a form ula, th e user moves the cursor to th e square th a t is to be m odified and types in th e new value I or form ula. T he squares th a t hold th e results are im m ediately u p d ated to reflect , i the change in the spreadsheet. : I I V id e o G a m es , D irect m anipulation languages do not have to be program m ing system . Video ! games are also a form of direct m anipulation languages th a t often consist of only , a joy stick and b u tto n inputs w ith th e objects being m anipulated are th e graphics j on the screen. T he actions used to modify the screen in a video gam e have all th e j characteristics of a direct m anipulation language: 92 • T he graphics are displayed continuously on th e screen w ith th e object of interest being th e user’s player and th e environm ent is w here the user’s player operates in. • T he actions are physical in n atu re consisting of direct inputs from a joy stick a n d /o r buttons. • T he im pact of th e operations are im m ediately seen in term s of th e actions of th e graphics being m anipulated. • Novice users often learn a gam e in a spiral m anner w here th ey interact w ith only a subset of th e gam e and as they become b e tte r they use m ore features. An exam ple of this is in th e P ac M an game. A novice user m ight at first concentrate only on eating all th e dots and energizer and not try to catch ! th e ghost or eat the fruit until they becom e m ore fam iliar w ith th e game. 1 i As can be seen from th e above, video games are also a form of direct m anipulation j i languages. ! i s i 3 .1 .3 P r e v io u s U se s o f D ir e c t M a n ip u la tio n L a n g u a g es in I S p e c ify in g U se r In terfa ces ! D irect m anipulation has been used in prototyping and specifying user interface for j some tim e. W asserm an [71] used direct m anipulation where th e designer would j interactively draw state transition diagram s and specify actions to be perform ed. D an ’s demo program [64] allowed PC based interfaces to be interactively laid out ! and sim ulated by repaining th e screen to show w hat changes would take place w ith 1 w hat inputs. O ther system s, like ID t’s, (discussed in C hapter 1.2.5) allow designers to layout th e com ponents of a user interface as they are to appear on th e screen and th en save th e screen definitions in source code. 93 Generate Command Commands Executable Code Source Designer Display Errors Display Objects X and Motif Libraries Application Functions IRG IRG Compiler Interface Compiler Interface Editor IRG Database Consistency/ Completeness Checker Figure 3.1: Com ponents and stru ctu re of R PP. 3.2 An Environment for Specifying User Interfaces T he rem ainder of this chapter describes an environm ent called R P P (R educed I Program m ing P rototyper) for specifying and rapidly prototyping user interfaces. Figure 3.2 shows th e stru ctu re and com ponents of R PP. A n interface designer in ter acts w ith R P P through an interface editor. As th e designer draws the com ponents and defines relationships betw een them , the definition of th e interface is saved onto a form al m odel representing th e com ponents, flow of control, and sem antic actions of th e interface. T he designer produces an executable version of th e interface code by issuing a generate com m and causing the interface com piler to com pile th e in ter face m odel into C code w ith calls to the M otif toolkit and X library. A t this point th e source code is com piled and linked w ith user w ritten functions and libraries which can th en be executed. Figure 3.2 shows th e m ain m enu of R PP. T he File pulldown contains com m ands for reading and w riting prototypes, th e W idgets pulldow n contains a list of avail able widgets th a t can be used in th e interface, th e Frames pulldow n is used for defining fram es, subfram es, startin g fram es, halting fram es, and history fram es. T he System pulldow n contains com m ands for generating an executable user in terface from th e specification, com piling th e generated user interface, and other 94 File Widgets Frames System Options Current Frame Current SubFrame proto current_frame current_subframe Figure 3.2: M ain window of th e prototyping system . m iscellaneous com m ands, such as directory listings and editing files. T he options pulldown allows th e designer to tu rn on and off snapping, a visible grid and other | options. ' • A designer specifies a user interface starts by doing th e following: ! i 1. T he windows of th e interface are drawn. I I 2. T he fram es th a t are to appear in th e windows are draw n. j I 3. Fram e sequences are defined. ! t 4. Events and actions are assigned to sequences. 5. C onstraints betw een com ponents are defined. j I ! 6. Sem antic feedback betw een th e interface, th e application, and th e constraints | are defined: 7. T he specification is converted to C and X windows code. j 1 All interface objects are draw n in an interactive editor th a t allows th e designer to j place objects on th e screen exactly how they will be seen at execution tim e. A t j any point in th e above steps th e designer can repeat or redo previous steps. This 1 allows m istakes to be corrected, enhancem ents to be m ade, or different techniques i 1 I I I i 95 ! i to be tried, thus supporting iterativ e design. The following sections describe each of these steps in m ore detail. T he following sections fu rth er describes each of th e above steps, com m ands of R P P , and gives exam ples of how interfaces would be specified. 3 .2 .1 S p e c ify in g W in d o w s T he specification of an application begins w ith the initial windows the application is ! i to appear in and th e definition of any special features of those windows. Specifying 1 a window consists of: • Selecting a type for the initial windows, • Positioning and sizing the window, and • Defining optional attrib u tes. j T he initial windows are those windows th a t appear when the application is started . , T he window widget defines th e type of window to use and th e optional a ttrib u tes are things like border thickness, background color, and window title. All attrib u tes have default values defined for them . Figure 3.2.1 shows th e m ain m enu of R P P in the top right hand corner, icons i representing the different types of windows th e designer can choose from , and in th e j m iddle a bulletin board window th a t was selected. S tarting from top to bottom th e ! icons represent: m ain windows, vpaned windows, row /colum n windows, scrolled windows, bulletin boards, and form windows. In itia l W in d o w s | The windows th a t appear when th e application is started are called th e initial j windows. These windows are the children of th e root window which is represented j by th e entire physical screen. There m ust be at least one initial window defined | for each application. W ithout one, there would be no place for th e flow of control j I to start. F i l s t i i d b e t a F r a m e s S y s t * * O p t i c r a B u l b r c M l r t d o w Figure 3.3: M ain window, window icons, and initial window. 97 I S u b w in d o w s Subwindows are defined the sam e way as the initial windows. A window type is selected from th e displayed window icons and th e new window is positioned I I and sized. T he parent com m and is then selected from th e window ’s option m enu | (described below) and th e window’s new parent is clicked on and the subw indow ’s ! new coordinates are calculated from th e new p a re n t’s origin. Subwindows also have to be defined as to w hether they are to appear th e sam e tim e th eir parent window appears or w hether they appear the first tim e an event giving control to th e window. i M o v e m e n t B e tw e e n W in d o w s M ovement betw een windows indicate the inputs necessary for control to move from ! one window to another. A window can gain control in one of th e two ways: I i 1. Through th e window m anager predefined events. i 2. By an event th a t happens in one window causing control to be transferred to another window. An exam ple of th e first way is when th e cursor is m oved from one window to another using a m ouse or through keyboard m eta characters. An exam ple of the second way m ight be in an application when an event occurs which causes another ■ window to appear and control to transfer to it. ! To specify m ovem ent betw een windows, th e T R A N S F E R option under the , W I N D O W com m and is chosen. T he user is th en prom pted to chose th e window i th a t will gain control, any necessary cursor positioning, and th e event th a t will | I cause th e transfer to take place. P o p u p W in d o w s a n d D ia lo g B o x es Popup windows and dialog boxes are treated slightly different from other windows because they are short lived and contain a set of com m ands th a t can be executed, j T he popup window is brought up by th e designer selecting th e popup m enu widget 98 from th e W idget pulldown in th e m ain m enu. W hen this happens, a selection box appears and the designer inputs which m ouse b u tto n will display the popup m enu and also th e item s th a t will appear in the m enu and th e corresponding actions or j sequences to be executed. | 1 All com m ands th a t appear in the popup window m ust have corresponding ac- ! tions associated w ith th em th a t im plem ent the com m and. T he actions can consist of: • A sub-popup window. • User defined functions i • G raphical operations or i • An internal broadcast i T he sub-popup window is identified in its parent window by an arrow to the right of th e com m ands nam e. W hen this com m and is selected, th e sub-popup window is ; opened (just like its p aren t) and th e user can then pick one of th e com m ands listed j in it. T he user defined functions, graphical operations, and internal broadcasts are I specified as w ith actions on sequences. j Dialog boxes operate in a sim ilar m anner to popup m enus, except th a t there j is usually only one com m and associated w ith them and th ere can be places where th e user can in p u t inform ation. R P P makes available th e predefined M otif dialog boxes. T he num ber of b uttons, user input areas, and messages are dependent on the ty p e of dialog box, b u t every b u tto n of a dialog box can be associated w ith an action to execute. A fter a b u tto n has been pressed, th e dialog box is rem oved ! (except if th e help b u tto n is pressed). 1 W id g e t O p tio n s j Each w idget has a set of com m ands in an options m enu th a t can be executed. [ These com m ands include: ! P r o p e r tie s - when selected brings up an attrib u tes window for th e current wid- , get. I 99 j C allb ack s - allows actions to be associated w ith an object. S e q u e n ce s - defines a sequence from th e current object to another object (e.g., a fram e, group, or window). M o v e - is used for m oving an object. S ize - allows objects to be resized. C u t - deletes an object and puts it on th e clipboard. P a ste - copies an object from the clipboard. P a ren t - gives a widget a new parent. , i C a n cel C o m m a n d - any com m and at any stage can be canceled by clicking the right m ouse b u tto n or pressing th e E S C key. | j 3 .2 .2 S p e c ify in g F ram es | i T he specification of frames is th e second step in specifying th e user interface and consists of the following steps: ( • Specifying th e contents of the fram e by either: ; 1. draw ing th e fram e directly i 2. specifying it as a series of m odifications to another fram e. • Giving a nam e for the fram e (optional). j • Identifying th e window th e fram e is to appear in. | ! • Indicating w hether th e fram e is to be A N D , O R , X O R ’ed or N O T ’ed w ith th e previous fram e or if the previous fram e should be cleared before the new l fram e is displayed (optional). Fram es can be specified by drawing th e com ponents th a t m ake up th e fram e directly and th en printing them when needed or by using graphical operations to describe how a fram e is to be changed from th e preceding fram e (subfram es). The following two sections discuss each of these m ethods. ■ I 100 | F ra m e s Predraw ing fram es involves on th e screen. Fram es th a t are predraw n can be dis played by one of th ree ways: j • By erasing w hat was previously being displayed in th e window. j j • O verw riting it w ith w hat was drawn. j • By overlaying it w ith the pre-existing frame. T he fram es th a t are draw n can consist of tex t a n d /o r graphics. To specify a fram e by drawing it directly, the fram e com m and under create interface is selected and the D raw F ram e option is chosen. At this point th e user is prom pted for a nam e to give th e fram e and to select th e window th a t th e fram e is to be draw n in by m oving th e cursor to th e window and clicking th e left m ouse bu tto n . T he user is th en p u t into a graphics editor th e size of th e window indicated l where th e fram e can be drawn. A ttributes of graphical objects can be set using ] l th e attrib u tes dialog, as show in figure 3.2.2. Exam ples of attrib u tes th a t can be j set are: j I F oregrou n d C olor - th e color of tex t and the border of th e object. 1 i B a ck g ro u n d C olor - th e color of th e m ain p art of th e object. ; i B o rd er C olor - th e color of the edge of th e object. j L a b el - th e tex t string th a t appears in an object (if applicable). j I Font T y p e - T he kind of font to be used (i.e., bold, italics or norm al). J i i Font S ize - th e size of the tex t to be draw n. j i S u b fra m es Specifying a fram e by listing m odifications to an existing fram e is th e alternative to draw ing a com plete fram e by hand. T he m odifications to a fram e are specified 101 proto iv n v iw fm v m w wi‘ O'iWvri-riroviWi‘iV i'i'rt‘iYorr<vrivrwi-i'rriv«Yivvv.wv\voVvY«'i'iVi\wr^V!Wiv>v,iY%visv>vr<<>vv.vwi'0^rov^vw^rro^'<yvV!WrtYrjy-'riV^yl' P roperties J Foreground Color : fB L A C K Background Color nWHITE Border Color t B L A C K iLabel Nam e y» y J k lJgW W W W U M K W . » l 'W J U W O ^ B q P W r a W W J k lW U W U « W Bu J & . . ure 3.4: A ttrib u tes window of the prototyping system . by drawing the m odifications directly in th e window, selecting th em from a pre defined list, or specifying th em as re tu rn values from the application. T h e fram e to be m odified can be displayed in th e window first if desired to help visualize th e | m odifications. As th e designer draws th e m odifications to the window, th e m odi- ! fications are recorded in th e same order as they are entered. A dditional graphics com m ands are available in addition to th e ones in th e graphics editor given above, they include: ! i To specify a fram e through direct m odification, th e F ra m e com m and under j create interface is selected and the M o d ify F ra m e option is selected. A t this point th e designer places the cursor in th e window w here the fram e m odification ; are to appear and click th e left m ouse b u tto n . A t which point th e graphics editor is * run on th e window selected and th e user draws th e m odification th a t is to be m ade , to th e fram e. These m odifications are stored and listed as graphical actions to b e 1 executed when control is transferred from the original fram e to th e new m odified ; l fram e. , I D e fa u lt F ra m e s One fram e from each window can be defined as a startin g fram e. T his fram e is j where execution starts th e first tim e control is transferred to th e window. W hen i control reaches the default fram e, th e window is opened (if not already) and th e initial fram e of the window is displayed. I l R u n tim e M a n ip u la tio n I Som etim es it is not know w hat th e m odifications to an object will be until runtim e. | Interface com ponents can be given nam es and th en referenced and m anipulated individually by the application. T he a ttrib u tes th a t are to be m anipulated at runtim e are specified as param eters to user w ritten routines. A stru ctu re containing only those values are passed to the application and on retu rn , th e values th a t have ' been m odified are u pdated in the object. I i 103 I n te rf a c e C o m p o n e n t O b je c ts To specify a graphical object, th e object m ust first be draw n in th e window it is to be associated w ith. N ext, the G ra p h ic a l O b je c t com m and under the F ra m e com m and. T he designer is th en prom pted to place a rectangle around th e object and then give it a nam e. 3 .2 .3 A rrays o f O b je c ts ! A rrays of objects are defined by setting an a ttrib u te of an object. M ultiple copies of th e object are m ade by the application m aking a function call at runtim e to th e function new_object() w ith a param eter of th e nam e of the array object. If th e object is a user interface com ponent, th en it can be duplicated at runtim e no m a tter how it is defined. O ther objects need to be defined as array objects so th a t sequences th a t have th e object as a destination will be forced to use indexed sequences. ! i i I I 3 .2 .4 H isto r y F ram es j Som etim es it is necessary for the flow of control to leave a window (or a group) i th a t is executing and at a later tim e retu rn to th em and pick up the execution ] where they left off. To do this a history fram e is specified. T his fram e is a logical ■ fram e, it is never displayed and is used solely as a link to another unknow n fram e ! to be determ ined at execution tim e. A history fram e is used w hen it is possible for a group of fram es appearing in a window (usually all th e fram es appearing in the ; window) to lose control to another group of fram es, b u t w hen the original group ! regains control at a later tim e execution of this group needs to be restarted w here : they left off. If control should be given to a history fram e when none of its siblings j have ever been executed before, th en th e history fram e will give control to a default i fram e. If a default fram e does not exist, then an error occurs. j T here are three types of history fram es th a t can be specified: j i 1. T he local history fram e which applies only to th e current window. J f S i i 104 2. T he global history fram e th a t applies to all sub windows of th e current win dow. 3. Range history fram es which fill in th e specified levels of windows th e history is to apply. L o c a l H is to r y F ra m e s T he local history fram e gives control to th e fram e in th e c u r r e n t window th a t j was lasted reached. T he fram e th a t was last executed is not displayed since th a t j fram e could have been th e result of m any m odifications of an initial fram e and j determ ining w hat it looked like right before it was in terru p ted m ay be im possible 1 to determ ine. The designer should be careful when using th e history m echanism : to m ake sure th a t a fram e will not be modified betw een th e tim e th e window loses I control and the tim e th e history fram e is called. If a subwindow of th e current , i window was being executed th e last tim e th e current window was active, then j th a t subwindow is given control again. Execution of th a t subwindow will N O T continue w here it left off, b u t will begin w ith its sta rt state. Figure 3.5 gives an exam ple of a local history fram e. In th e exam ple, there are a group of fram es on th e left and another group of fram es on th e right (you can think of th e two groups of fram es as being in two separate windows). T he group j of fram es shown on the right have their execution stopped by an event th a t gives control to th e group of fram es on th e left. I G lo b a l H is to r y F ra m e s j T he second type of history fram e is th e global history fram e. If a global history j fram e is specified for a p articular window, all subwindows and divergences (see ■ section 3.2.14) of th a t window are also given history fram es. This is necessary I because it is possible for th e flow of control to leave a window and go directly to another window w ith out going through th e first window ’s parent. T he last fram e executed for th a t window was in its subwindow, so control m ust be given to the I subwindow and a history fram e m ust exist for th a t window so it can determ ine | which of its fram es was th e last to execute. ! F r a m e 2 F r a m e 1 F r a m e 3 F r a m e 1 F r a m e 2 W in d o w F W indow A Figure 3.5: Exam ple of a history fram e. j Figure 3.6 shows an exam ple of th e above scenario. In this exam ple th e window : labeled A is th e parent of th e windows labeled B and and C , and th e window I labeled D is separate from A , B and C . In this exam ple either window B or C can transfer control to window D . T he only way for window D to retu rn control to its originator is to know which window transferred control to it. If a local history state j is used inside of window A , control will be given back to th e last active window of j either B or C , b u t not to th e last active state of th a t subwindow. Instead, control j will be given to the starting state of the last active subwindow since a local history , state only keeps track of which child of th e current parent was last active and does not keep track of any of its grandchildren. For th e last executed state of one of th e 1 subwindows to regain control, a global history state m ust be used inside of window J A . This way when window D returns control to the global history state in window A , the last executed state of th e last executed subwindow will be found. i F ra m e F ra m e F ra m e G lo b a l H is to r y F r a m e W in d o w B Divergence W in d o w D Window A Figure 3.6: Exam ple of a global history fram e. i S p e c ify in g a H is to r y F ra m e ' T he history fram e is treated like any other fram e. T he only difference, is th a t it can ; J not be specified as a source fram e in a fram e sequence (since the destination fram e j is not known until execution tim e) and it can not be specified as a destination j fram e from a fram e appearing in th e same window (only from a fram e in another j window). Actions can be associated w ith th e fram e or fram e sequence leading to it I ju st like other fram es (the actions can even include graphical actions). If a history fram e is used, a default fram e should also be used in case it is given control and j the window has never been executed before. This gives th e history fram e some ' place to transfer execution to, otherw ise the sim ulation will h alt w ith an error. i A history fram e is specified like any other fram e, except th ere is no draw ing or ! fram e m odifications associated w ith it. T he user selects th e H is to r y option under th e fra m e com m and and selects either th e local, global or th e autom atic type of | | history fram e. If the local or global history fram e is chosen, th e user is asked to j select th e window th a t the history fram e is to be associated w ith and th a t is all. If ! th e autom atic history fram e option is chosen, the designer is prom pted to select at which window th e history m echanism is to sta rt and at which subwindow it is to end. H istory fram es are also the only fram es th a t can be associated w ith the root j window, so it is legal for the designer to select th e root window as th e recipient of ! a history fram e. If m ore th an one history fram e is needed (due to different actions j being associated w ith them ) subsequent ones will be num bered autom aticly for ' identification purposes. ' 3 .2 .5 S eq u e n c es j i Sequences of fram es define the order in which the fram es will appear in th e appli cation. Each fram e can have m ultiple fram es appearing after it, as shown in figure 3.7. The determ ination of which fram e sequence will be taken is specified below in th e events section. Sequences of fram es are also allowed to contain loops, as shown in figure 3.7 w ith fram e F returning to th e beginning of th e fram e sequence | I at fram e A. Specifying a fram e as th e destination fram e th a t occurs earlier in a j fram e sequence is how iteration in an application is specified. j T he following are th e steps th e interface designer takes when specifying a fram e j i sequence: ■ l 1. Selecting an object th a t will be the source of th e sequence. I 2. Selecting a destination fram e, subfram e, or group. ; 3. Select one or m ore events th a t will cause the sequence to b e taken. j I 4. Select an action th a t will be executed when the sequence is taken: j l T he following sections discuss each of the above steps. I S o u rc e i T he source and destination fram es have to be defined as fram es (either predraw n I or as a m odification) before they can be specified as part of a sequence. A fram e sequence can also have m ultiple source and m ultiple destination fram es. M ultiple 108 Frame 3 Frame 4 Frame 2 Frame 5 Frame 1 Figure 3.7: A sequence of fram es. source fram es are possible w hen several different fram es will go to th e sam e desti nation fram e(s) on th e sam e event. W hen an event is specified for this sequence, th e event will be defined for each of th e source fram es in th e sequence. W hen a sequence is attached to a specific object, th e source fram e defaults to the fram e or subfram e th e object is defined w ithin. D e s tin a tio n F ram e T he destination fram e can be in th e sam e window as th e source fram e or it can be in a different window. If a fram e sequence specifies a destination fram e in a different window th an w hat th e source fram e appears in, th en when th e sequence is taken, th e source fram e’s window is deactivated and th e destination fram e’s win dow is activated. A fram e sequence can only have m ultiple destination fram es if j each of the destination fram es is in a separate orthogonal com ponent (see below i in section 3.2.13 for specifying orthogonal com ponents). These destination fram es , m ust be in orthogonal com ponents relative to each other. T h at is, the orthogonal ; com ponents th a t contain each of the destination fram es m ust have th e sam e or thogonal parent. For a fu rth er discussion of specifying m ultiple destination fram es in orthogonal com ponents, see section 4.1.1. In m ost cases, only a single source 1 and single destination fram e will be used. 1 i E v en ts T he events th a t are to cause th e sequence to be taken are defined after th e desti nation state is defined. Figure 3.2.5 shows a list of events th a t can be used for a push b u tto n . These events correspond to th e callbacks defined by X windows. In I I th e future other events defined by X windows will also be available to choose from. I Events are discussed below in section 3.2.9 in m ore detail. : I A c tio n s ! A ctions to be executed after the sequence is taken are defined after th e events. J Figure 3.2.5 shows the action selection m echanism in R PP. A ctions can be divided j into th e following: | CallBack Select (mNact i vateCa11back foNarmCallback (mNcreateCallback imNdestroyCallback <mNdisarmCallback 'mNhelpCallback Figure 3.8: Exam ple of events th a t can be selected for a sequence. 1. Do nothing. 2. Call user defined function. j 3. Call system function. j If “Do N othing” is chosen, then no actions are executed when th e sequence is taken. ' I If a user defined function is defined, th e user is prom pted for a function nam e and I is allowed to pass param eters to th e function th a t consists of any attrib u te s of th e : interface com ponents. If a system function is specified, then th e user can execute i an external program when th e sequence is taken. A designer specifies a fram e sequence by selecting th e options popup m enu on ; th e interface object where th e sequence will have its source. From th e options m enu the Sequence item is selected and the Frame subm enu is also selected. T he < j designer is th en given a list of possible destination fram es, followed by a list of i events th a t can occur in this object. A fter an event is selected a list of actions is ; displayed th a t the user can choose from. i I 3 .2 .6 S p e c ify in g W in d o w S eq u e n c es j ! A window sequence defines how control will move betw een windows of th e user I interface. Transfer of control betw een windows can always be done by issuing the 111 callback definition rnvrrtvnvftTi^Ym'i,»v«wn*w.-rtv»ViW»¥iYri-<wiV^Aw»vwiVft^wMv»wr^mwrtv^w.virtfiYAY«wwftw»wiviV»wnv^wiYfftv«¥^ # Do Nothing O ' Function F ile Name Function Name Parameter O Program Program Name ca llb a ck _ d e f_ la b e l Widget Type : C all Back Name : PUSHBUTTON XmNactivateCallback S et(s> M f ttiO W wrm aa M QUIT Figure 3.9: Exam ple of actions th a t can be selected for a sequence. 112 com m and supported by the window m anager (e.g., m oving th e cursor into a window or placing th e m ouse cursor in th e window title and clicking a m ouse b u tto n ), but also by giving com m ands from the keyboard. T he com m ands to move between windows are specified in the same way as fram e sequences are specified and are called window sequences. T he designer specifies a window sequence by picking a source window and a destination window, ju st as in a fram e sequence a source and destination fram e is specified. Once th e window sequence has been defined, events, conditions and actions can be associated w ith th e sequence. i i i 3 .2 .7 R u n tim e D efin e d S eq u e n c es Som etim es it is not known until runtim e th e destination of a sequence. In these j I cases th e application m ust retu rn the nam e of a fram e or window w here control will be given control. This is done through a shared d a ta value betw een the ap plication and th e ru n tim e system of R PP. W hen a ru n tim e sequence is defined a function m ust also be defined th a t will set this shared d a ta value. A fter th e func tion executes, th e nam e of the item is read from th e shared value and th a t fram e ; or window is given control. j 3 .2 .8 In d e x e d S eq u e n c es ; I I Indexed sequences differ from other sequences in th a t th e nam e or num ber of an array object m ust be given to indicate which of several identical objects will be given control. T he nam e or num ber is supplied by an application function th a t when called returns the nam e/num ber of th e array object th a t will be the destination. 3 .2 .9 S p e c ify in g In p u ts Inputs are th e values which drive the user interface. T here are two types of inputs possible to a user interface: j l 1. Values th a t come from th e user. j | 2. Values th a t come from th e application. ; | 113 i B oth types of inputs are th e sam e to R PD . They both can be listed as events, the only difference is th a t they come from different places. i U se r In p u ts User inputs consist of those values coming from th e keyboard and m ouse and are m ade up of: | 1 1 • A SCII characters 1 i • Function keys j i • C ontrol/E scape keys j • M ouse m ovem ents [ I | • M ouse b u tto n press/releases ; I O ther types of inputs, such as sound, can also be used as long as they are supported 1 by th e underlying windowing system . , ! In p u ts From th e A p p lic a tio n ( l A pplication returned values consist of results of user w ritten functions or values ' read in from a file. T he results of the function or values read from th e file are ! used as the next event ju st as if th e event had been read from th e keyboard or J mouse. T he user supplied function is executed or th e file is read from each tim e th e fram e is reached. T he results of which are tre ated as if they w here entered from th e keyboard. Functions used to specify an event are supplied by the user and are w ritten in the C program m ing language value retu rn ed are stored in an internal variable to com pare against subsequent event values. T he functions are linked to the runtim e system of R PP. User defined events can be defined as being read from a d a ta file instead of th e | i result of a function w ritten in C. T his type of event is done th e sam e as th e type i above, except instead of executing code to get the value, a line of a d a ta file is read j in. As w ith th e function result, the file is read into an internal variable each tim e ! i I 114 , th e state is reached. If an end of file condition is found or th e file does not exist, th e read will retu rn a null string. To specify th a t a function result is to be used as an event, th e user selects th e I F u n c tio n R e s u lt option under th e e v e n t com m and. The user is then prom pted j for th e nam e of th e function and th e result needed for th e event to be true. T he | ty p e of th e result also needs to be known. i j To specify a read event, th e user selects th e R e a d option under th e E v e n t com m and. T he user is then prom pted for th e nam e of a d a ta file th a t is to be read from. A fter the file nam e is supplied, the user is prom pted for th e value of the result th a t is to be used to indicate a tru e event. All values are read in from th e file as strings and each read from th e file gets an entire line and com pares th a t line to th e specified event. I O r d e r o f E v e n t P ro c e s s in g It is possible for m ultiple inputs to come from th e system or from th e user defined functions at th e sam e tim e. Because of this there are three queues w here th e inputs to th e user interface can be p u t into as they arrive: ! 1. System in p u t queue. I 2. User defined input queue. 3. Internal broadcast queue. j T he system inputs are retrieved from the in p u t queue in th e order th a t they w here j entered by th e keyboard or mouse. T he user defined inputs coming from functions ; or files are placed in th e user defined in p u t queue in the order th ey w here executed j or read. T he internal broadcast queues is w here th e internal broadcast are when a j broadcast action is executed. j W henever a state is reached, before evaluating th e events (see below) the user j I defined inputs are obtained by either executing th e functions or reading from th e J files supplied by th e user. These results are th en p u t in th e user defined input j queue in th e order in which th e functions/files w here defined by th e designer. j W henever an event is needed by th e application, th e internal broadcast queue is , 115 ' I checked for any values first, followed by th e user defined in p u t queue followed last by th e system in p u t queue. T he reason for looking in the internal broadcast queue first is th a t internal broadcasts act as synchronizers or as interrupts. Because of th eir statu s th ey m ust be executed as soon as th ey becom e available. T he reason for checking th e user defined input queue second before checking the system input queue is th a t th e values from th e functions apply specificly to the current state I and are m ore urgent in nature. Since these values only apply to th e current state, after each state is through executing, th e user defined in p u t queue is cleared of all values. W hen all the queues are em pty, th e system w aits for an input com ing from th e system or an internal broadcast. In this case, whichever input arrives first is j used next. j 3 .2 .1 0 S p e c ify in g E v e n ts j Events indicate w hat input is needed to go from one fram e to another. Events : can consist of user inputs, function results, values read from a file or a variable ; indicating an internal broadcast. ! An event is specified by selecting th e e v e n t com m and under th e create interface ; section and then supplying th e nam e of th e fram e sequence th a t the event will be | attached to. A fter th e nam e of th e fram e sequence is given, th e user then indicates j the ty p e of event th a t will be used. This type depends on th e type of interface object being used. • Function results • File read results • Internal broadcasts • D efault and null events • R egular expressions • Variables I T he above events can also be com bined to form com pound events. T he following sections describe each of th e above events and how they are specified. 116 I C u r s o r P o s itio n An event can be triggered by th e position of th e cursor in a window. User input given by th e position of th e cursor is used to indicate: 1 • T he current window of a m ultiwindow interface. • Positional inform ation for drawing graphics. • Positional inform ation for pointing to a graphical object. T he position of th e cursor can trigger an event if th e cursor falls w ithin a predefined rectangular area of a window. A C ursor position is specified by selecting the C u r s o r P o s itio n option under th e E v e n t com m and. T he user is th en prom pted to draw a spline around th e area w here th e cursor is to be in for th e event to take place. C u r s o r M o v e m e n t A cursor m ovem ent event is tru e when th e cursor is moved. It is used in cases ! I like graphics editors where th e size of an object is dependent on th e current cursor j position. Once it has been detected th a t th e cursor has been m oved, an action can j then be used to query th e position of th e cursor. | To specify a cursor m ovem ent event th e user selects th e C u r s o r M o v e m e n t option under th e E v e n t com m and. T he event will be tru e w henever th e cursor is moved from its current location. I F u n c tio n /R e a d R e s u lts as E v e n ts j > Function results and values read from files are user defined inputs (see section 3.2.9) whose retu rn values can be defined as events ju st like system inputs. An event based on a user defined in p u t is specified ju st like th e system defined inputs. T he value is specified as a character string and as either a buffered or unbuffered I event (see above). T he function m ust be m ade to retu rn a character string. i To specify an event as a function result or as a value read from a file th e designer ! selects th e U s e r D e fin e d I n p u t option under the E v e n t com m and. T he user then selects w hether a function result is to be th e event or a value read from a file will be th e event. If a function result is chosen, th e nam e of th e function is entered by th e user w ith th e param eters to be passed to it. If it is a file, th e nam e of th e file th a t th e d a ta is to be read from is given. I i j In tern a l B r o a d ca sts { Internal broadcasts are used prim arily for synchronizing orthogonal states. T he broadcasts are in the form of variable nam es which are used as events in other j p arts of th e interface. In essence, an internal broadcast is an internally generated event. D e fa u lt an d N u ll E v en ts » A default event can be specified for cases in which th e current event does not m atch any of th e listed events for the fram e. If this should happen, th e default event is taken. T he default event is useful for error situations where th e user did not enter j one of th e listed com m ands. In these cases, control can be transferred to another j state to handle th e error w ithout th e designer having to list every possible error th e user could make. A nother situation is w here on any in p u t th e designer w ants I the one and only fram e sequence to be taken. Such situations arise when help ■ windows are displayed and th e user is asked to press any key to continue. It m ay 1 appear th a t th e default event is th e same as th e regular expression. They b o th ! m atch any in p u t found, b u t unlike the regular expression, th e default event is j always guarantied to be taken only if none of the other events evaluate to true. i T he null event represents an event th a t does not require any in p u t or function | result for it to be true. A null event can be specified when a certain condition is being w aited for instead of a particular event to happen. An exam ple of such a I situation is when a user w ants to p u t a tim e lim it on the response for a fram e. T he i designer would specify a null event followed by a conditional w ith a tim er value j desired (see conditionals below). Even though the null event is true, th e fram e ; sequence will not be tru e as a whole until the tim er is tru e (indicating a certain ! am ount of tim e has passed). This m eans th a t the fram e sequence will not be taken : unless no other listed event occurs before the tim er conditional becom es true. S p e c ify in g E v en ts U sin g V ariab les * T he values of variables can be used as events. T he variables can be set to a character string containing buffered or unbuffered events (i.e., they do not have to end w ith a carriage retu rn ). T he variables are set during actions as described below in section 3.2.12. W hen th e variable is encountered during an event, th e variable is dereferenced and its value used as th e event. This allows th e designer the ability to change events on fram e sequences during th e ru n tim e of th e application. S p e c ify in g E v e n ts U sin g R eg u la r E x p ressio n s Som etim es th e input representing an event can be one of several different forms ! and listing all those forms is not practical. In such cases a regular expression can I be given describing th e set of inputs th a t are valid. R egular expressions can consist 1 of any character string w ith the characters “?” representing any single character, ; representing zero or m ore characters, any string betw een th e brackets “[” and ; “]” represent an optional substring inside the m ain string and th e brackets “{” J and “}” representing a repeated substring. If any of th e characters “?,” % ” | w ])” K {?” or w }” nee<l to be used in the string itself th ey can be prepended by a 1 back slash, “\ . ” If a back slash itself needs to be used, then two back slashes in a j row are used. R egular expressions can be used to describe system and user defined inputs alike. Exam ples of some regular expressions are: > i ab c? - any four letter string th a t begins w ith “ab c.” j ab c* - any three or m ore lettered string w ith th e prefix “ab c.” ® i ab c[ab c] - the string “abc” or “abcabc.” j i a b c (a b c ) - the set of strings “abc,” “abcabc,” “abcabc,” .... O ther useful regular expressions would be “?” which represents th e user typing any single character. I A m axim um length of a string in a regular expression can also b e defined. This keeps th e user from typing in an extrem ely long response w hen a regular expression like is used. W hen th e character lim it for a regular expression is reached, th e expression is excepted. To indicate a character and line lim it on a regular expression, th e designer appends the form ula w ith a p air of num bers in parenthesis, i.e., (20,3). T he first num ber indicates th e m axim um num ber of characters in a line and th e second num ber indicates th e m axim um num ber of t I lines. T he default is one line and 256 characters. W hether a regular expression is term in ated by a carriage retu rn or not, or w hether it is m ore th an one line long, depends on w hether th e regular expression is defined as buffered, unbuffered or block tex t, respectfully. C o m p o u n d E v e n ts T here are tim es when m ore th an one event can be used to move from one fram e j I to another or tim es when m ore th an one event needs to occur to move to th e next ! fram e. These types of events are called com pound events. T he first type, w here ! only one of several events need to occur to move to a new fram e, are called O R events because it only takes one of th e events for th e sequence to be taken. The second type of event, where each one of th e events specified needs to occur for the next fram e to be displayed, are called A N D events because they all have to occur for th e sequence to be taken. M ultiple O R and A N D events can be com bined I together to m ake a single com pound event specification. i An exam ple where an O R event m ight be used is when m ore th an one input j from the user will do th e sam e thing. This is the case in m ost applications where certain com m ands have several alias, such as a help com m and th a t can be initiated by th e user typing a “h ,” or “help.” A .case w here an A N D event m ight be used is w hen a m ouse b u tto n needs to be pushed and released before th e event will occur. In this case th e event would be specified as: Button 1 push A N D Button 1 release. This com pound event will then not becom e tru e until b o th p arts of the event occur. To specify a com pound event, an initial event is specified using any of the j I I 120 above single events. This single event becom es th e current event and additional events specified are added. If a com pound event consisting of two O R events is desired, after the first event is specified a second event is specified and th e user I will be notified th a t other events have been specified for this fram e sequence and j then be prom pted as to w hether th e new event is to be added as an O R or A N D ' connective. Each successive addition of an event is p u t at the beginning of the events w ith th e previous operations grouped together. For exam ple, if an event of e l is specified and then followed by an A N D event e2, an O R event e3, another O R event e4 and lastly by an A N D event e5 in th a t order, the resulting form ula j would be: | i e5 A (e4 V (e3 V (e2 A e l))) = e5 A (e4 V e3 V (e2 A e l) ) where th e left hand p art of th e equation is how it is entered into the system b u t is also equal to th e right hand side. If an event is edited at a later tim e, th e adding of events is assum ed to be continued w here th e previous one specification left off. 3 .2 .1 1 E v en t C o n d itio n s Event conditions are used to restrict when an event can be taken. They are used j when an event m ay occur b u t only under the correct circum stances or w hen th e i sam e event can m ean different things depending on a previous action. T here are two types of conditions th a t can be specified: S im p le c o n d itio n s - a single conditional statem ent. C o m p o u n d c o n d itio n s - a com bination of sim ple conditions connected by log ical A N D s or O R s. T he following are discussions of the two types of conditions and how they are specified by th e user. S im p le C o n d itio n s Sim ple conditions are single expressions indicating a condition th a t m ust be tru e before th e event can be taken. Simple conditions consist of: 121 T im e r (ss) - a tim er is a condition th a t becomes tru e only after an indicated num ber of seconds(ss) has elapsed. T he tim e on th e tim er is in reference to th e am ount of tim e since th e current fram e was displayed. C o n d itio n a l E x p ressio n s - conditional expressions consisting of variables and constants are possible. T he conditional connectors can consist of < , > , = , < = , > = and are used to com pare variables, constants and function results. I s T o u c h in g ( o b je c tl,o b je c t2 ) - returns tru e if two graphical objects are touch- I ing each other. j I C o m p o u n d C o n d itio n s j Com pound conditions are m ade up of simple conditions in th e sam e way th a t 1 com pound events are m ade up of sim ple events. Simple conditions can be added j I to previously defined conditions by stringing them together using conjunctions of A N D or O R . I Com pound conditions are specified in th e sam e way th a t the sim ple conditions ; are specified. W hen a second (or m ore) sim ple condition is specified for th e same | event, th e user is inform ed of the previous condition specified for the event and j will be asked w hether th e new condition should be added w ith an O R or an A N D j condition. j 3 .2 .1 2 A c tio n s j Actions can take th e form of graphical operations, user defined actions, or internal I broadcast. Actions can be associated w ith a particular fram e, a fram e sequence, j or an event th a t occurs in an interface object. If they are associated w ith a fram e, ' they are executed after th e fram e has been displayed and before the next event j is checked. If they are associated w ith a sequence, they are executed after the ! sequence occurs b u t before th e fram e is displayed. If they are associated w ith an I object, th en they are executed when th e event occurs. j 122 In tern a l B ro a d ca st Internal broadcasts are used to synchronize concurrency (described below). They are specified by listing a variable nam e on an action. W hen th e action is executed the variable nam e is used as an event in any orthogonal states. S e ttin g V ariab les i ! Variables are available for storing values for later use in th e application. These j J values can be read from a file (see below), set to th e value of an event (e.g., the last , keyboard input) or a discreet value such as a num ber or character string. Variables ! take on an im plicit type, depending on th e context in which they are used (sim ilar j to awk [1]). If a variable is assigned a character string, such as A = “Variable A", J th e variable is given an im plicit type of character string. If a variable is assigned ' a num eric value, such as B = 10, then th e variable is given an im plicit type of I integer (real is also available). A variable can also be used as an array. T he length of the array does not have to be predefined, b u t additional elem ents are added as needed. An exam ple of the use of an array value is: A[2] = B 3. In this case th e j array is used as an integer array, b u t they also can be used as character and real j too. | T he types of variables can also change during th e course of execution. If a j variable given is assigned a character string, it can later be given an integer or real i value. A rithm etic operators are also available for m anipulating the values of the variables, they are: + : addition, for integers and reals. — : subtraction, for integers and reals. * : m ultiplication, for integers and reals. / : division, for integers and reals. % : m odulo, for integers. j substr(V ar, N u m ) : function substring, returns th e N um 'th character of the strin g i Var. | I 123 j / / : concatenate two strings together. T he substr function in addition to operating on characters strings can also operate | on num eric values. W hen an integer or real value is used as an argum ent, the substring function returns th e N um ,th digit from the left. All th e operators above j also work on array elem ents. i I I U se r D efin e d F u n ctio n s j i I Actions can be specified by th e user th a t execute functions th a t need to be pre- | I form ed during th e execution of th e user interface. These functions are w ritten in th e program m ing language C and are executed as subprocesses. These func tions can be used to retrieve inform ation from another file, to fu rth er im ple m ent a p art of th e application or to m ake complex calculations. These user defined functions are defined as actions and are called through th e system call U ser(function..nam e(pi,. . . ,p 8, . . . ,p n) where / unction -nam e is th e nam e of the C program to be executed and p, is th e ith param eter of th e function. T he function is exec’ed as a separate process and th e application th en w aits for it to term inate. A t tim es values from these functions m ay need to be retu rn ed to th e sim ulator, j This can be done be done by assigning a user defined variable to the result of the i function, as in: result = U ser(functionjnam e) w here result is th e nam e of the user defined variable. T he function m ust retu rn a pointer to a character string representation of th e function result. If a num ber needs to be returned, it m ust be converted to a character string and th en retu rn a pointer to it. T he user specifies a coded action by selecting the C o d e option under th e action j ) com m and. T he user is then prom pted for the nam e of th e process to be executed. | i 1 R e a d in g /W r itin g V a lu es F r o m /T o F iles J Instead of spending tim e w riting a function th a t will retu rn a value, sets of prede- ! term ined values can be stored in files th a t can be read in and set to variables. As | stated previously, one line of th e file is read at a tim e and assigned to a variable j i 124 j as a string. Files can also be w ritten to in a sim ilar way. Values w ritten to a file or appended to it and each w rite is appended by a carriage return. To set a variable to a line in a file, th e designer uses th e function V ar = R e a d F ile (f ilejnam e) w here file^name is th e nam e of th e file to be read and V ar is the nam e of the variable to receive th e string read from th e file. T he function reads one whole line of the file in and sets th e variable to it. To w rite a variable to a file, th e designer uses th e function j W rite F ile (file jn a m e ,V a r ) j i w here file jn a m e is th e nam e of th e file to w rite to and V a r is the nam e of the : variable whose contents are to be w ritten. ! i i I S to p p in g th e A p p lic a tio n j An action is available for halting the execution of th e application during sim ulation, i W hen this action is executed, th e application is stopped and control retu rn ed to J the system . T he screen containing th e last fram es of th e interface are left in tact so th e designer can view th e tex t/g rap h ics for debugging purposes. This action can \ be used to stop the sim ulation at th e logical end of the application or for debugging j i purposes. C lo sin g th e C u rren t W in d o w An action is available for closing th e current window. This causes th e window to disappear and control to be retu rn to its parent window w here it resum es executing w here it left off. If th e parent to th e current window is th e root window, th en the application is halted. 3 .2 .1 3 S p e c ify in g C o n cu rren cy As stated in chapter 2, there are two types of concurrency in a user interface th a t can by specified: i 125 1. Concurrency w ithin a window. 2. Concurrency betw een windows. Concurrency w ithin a window occurs when several objects defined w ithin a window act independently to the sam e inputs while concurrency betw een windows is when two or m ore windows share the sam e inputs entered into any of th e windows. W hen execution of a user interface reaches a set of concurrent fram es, control is given to each of the startin g fram es of each of the sequential groups and started at th e sam e tim e. T he following describes how to specify th e two types of concurrency, j I I C o n c u r r e n c y W ith in a W in d o w Specifying concurrency w ithin a window involves identifying each of th e item s th a t are to act in parallel. Once these item s have been identified, th e sequential frames I for each of these item s are described as if each where th e only item s in th e window, j I as was done above. This establishes a separate statech art for each of th e item s, [ th en each of th e windows th a t w here described for the sequential item s are O R ’ed ! together to form a single window and each of th e statech arts defined for these j windows are m ade orthogonal to each other. W hen the previously defined windows J are O R ’ed together, all events th a t occur in the window are th en applied to each j of the statecharts. O f th e windows com bined, one of th e windows is indicated as th e prim ary window which defines such things as the window border, window title and any popup windows. All graphics are done in reference to th e origin of the j original window th a t each object was specified in. To specify concurrency w ithin a window, the user selects the c o n c u r re n c y * com m and and then selects th e W ith in a W in d o w option. T he system then j | prom pts th e user for th e nam es of the windows th a t are to act in parallel w ith j each other. As each of th e windows are nam ed, th e fram es of th e window is drawn. ! T he first window nam ed in the group of concurrent window is used as th e window j specification (its initial position, header and other window a ttrib u te s are used). T he subsequent windows nam ed in th e concurrency have th eir fram e draw n and I th e designer then places th eir outline in how they are to appear in relation to th e J 1 i i 126 1 I first window (only the portions th a t overlap w ith the first window will be displayed, the rest will be clipped). C o n cu rren cy B e tw e e n W in d o w s ' C oncurrent windows are specified by specifying each window th a t is to operate J in parallel separately first and then indicating th a t they are to ru n concurrently afterw ards. This then defines th e windows to be orthogonal to each other and inputs generated in any one of th e windows will th en be applied to all th e other windows. W henever control leaves one of th e windows though, then execution of th e other windows also cease due to th e lack of events. W hen one of th e windows becomes active, all th e windows will becom e active. \ I » 3 .2 .1 4 S p e c ify in g a D iv e r g e n c e 1 i In m ost applications a m om entary divergence from th e m ain flow of control is ! som etim es necessary to do unpredicted processing and then retu rn to th e point o f ; interruption and continue. Divergencies are necessary to process help requests or ' 1 error conditions. In such cases, the user asks for help, a help message is displayed . and w hen th e user is through viewing th e help fram e(s) control is retu rn ed to th e ; point of interruption w here the application continues. Help and error fram es are not th e only types of divergences possible. In m any gam es an “escape” key is j provided th a t stops th e gam e until the key is pressed again. T his allows users to stop to answer a phone or until their boss is out of sight. j In m ost applications th e displaying of help screens and error messages are a j I possibility a t any place where input is possible. T he sam e help and error messages | are often displayed from m any different points of the interface. These messages are j displayed w henever needed and after th e user reads the m essage control returns j to th e previous point of input. Because of th e possibility th a t m ultiple fram es in \ a window m ay need to call help and error m essages, there is a need to associate I fram es sharing th e sam e help and error fram es (as little as one or as m any as a l l ; of them ). T he divergent fram e sequences are treated ju st like a window (and even • can be a separate window) and need to have startin g fram es defined for them if j i 1 2 7 ; there is m ore th an one fram e th a t will be displayed. S p e c ify in g th e D iv e r g e n t F ram es To specify a set of divergent fram es, th e fram es are specified in th e sam e way as described in section 3.2.2 above. T he fram es can be specified in th e current window ju st like th e other fram es in th e norm al flow of control or th e fram es can be specified ; in a separate window which is opened when the divergence is executed. Once th e ; fram es have been specified, if there is m ore th an one fram e to be displayed, th e ; i fram e sequences are defined w ith one of th e fram es defined as th e default (starting) ! fram e. I S p e c ify in g a C a llin g D iv e r g e n c e S eq u en ce N ext, th e norm al application fram es th a t will use th e h elp /erro r fram e(s) are se lected by listing them by nam e (the default is all fram es w ithin th e window). Finally, th e event(s) th a t cause th e divergent fram es to be called are specified in j th e same way as regular events. Usually, th e event will be a default event for error ! conditions and a p articular key (e.g., ”H ”) will be defined for th e help frames. 1 S p e c ify in g a R e tu r n in g D iv e r g e n c e S eq u en ce O nce th e divergent fram e sequence has been specified, the retu rn from th e divergent , fram es needs to be specified. There are two different ways for th e divergence to j retu rn to th e m ain stream of th e interface: i * • R etu rn to the state th a t was in terru p ted by the divergence. ( j • R etu rn to another predefined state. [ I In m ost help and error conditions th e first type of retu rn will probably be used. J These are th e cases w here a user gives a bad input or requests help. In either case a m essage will be displayed offering help. A fter th e user has finished w ith the help, the user needs to be retu rn ed to th e exact state w here he left off. To do this, j th e retu rn sta te from th e divergence m ust b e defined to retu rn to a history fram e j of th e window. T he second case occurs when an error is m ade. A divergence is ' 128 M a in W in d o w H e l p W i n d o w F r a m e 1 F r a m e 2 Help H is to r y F r a m e F r a m e 3 F r a m e 4 Figure 3.10: An exam ple of a divergence used for a help window. i called and th e user is returned to a predefined state (like the beginning) after th e j divergence. To define a retu rn back to a specific state, th e designer sim ply defines j a fram e sequence from th e divergence back to th e nam ed state. ! | D iv e r g e n c e E x a m p le s Two exam ples of divergences are shown in figures 3.10 and 3.11. T he first exam ple shows how a divergence would be used in a norm al help fram e type situation. T he fram es th a t are to have access to the help fram e are all defined as source fram es for I th e divergence, which groups them together. A single sequence is defined from these j source fram es to th e help fram e in the divergence w ith a retu rn fram e sequence j returning to a history fram e in the original group of frames. T he history fram e j then returns control to the fram e from where the divergence was called and th e j interface continues as if nothing occurred. ! G rou p s Divergences can also be used to define “hot keys” w hich re tu rn the user to a predefined place in th e user interface w ith a single keystroke. H ot keys are often j i used in applications th a t have deep tree structures of m enus. T he hot key lets th e ; user go to a predefined place in th e m enu hierarchy w ith a single keystroke. To j i specify this th e designer defines th e predefined fram e th a t th e hot key is associated J w ith as th e fram e appearing in th e divergence. T he fram es th a t are to be covered \ i under the hot key are specified as source frames for th e divergence, th e predefined fram e as th e default fram e of the divergence and th e hot key as th e event th a t triggers th e divergence for these fram es. T he difference betw een this divergence and earlier divergences described above is th a t there is no retu rn divergence fram e sequence. T he application sim ply continues as if it reached this fram e in th e norm al j sequence of control flow of th e application. i T he second exam ple shows how a hot key would be defined using a divergence. T he fram es th a t are to be w ithin th e hot key’s definition are all defined as source fram es which groups them together. A single sequence from this group to the ; predefined fram e is defined using th e hot key F I as the event from the source fram es j to th e destination. Once control reaches this destination control is to continue from j th e new fram e and not retu rn to th e original group, so a retu rn sequence is not j defined. 3 .2 .1 5 U t ilit y F u n ctio n s U tility functions are system defined functions th a t retu rn values th a t can be used to set variables or used in conditions for com paring th eir results against some predefined values. C u rsor P o sitio n i T he cursor position function returns a tuple consisting of th e x and y coordinates of : th e cursors current position in th e window. If for some reason th e window executing th e function does not contain th e cursor in its area then th e function retu rn s -1,-1 : (such a condition m ight arise if th e cursor is in an orthogonal window). T he value 130 ! W in d o w Frame 1 H o t K e y Source D iv erg en ce Frame 3 Frame 2 Frame 4 Figure 3.11: An exam ple of a divergence used w ith a “hot key.” retu rn ed can be used as a param eter to a graphics operation. T im e a n d D a te T he tim e and d ate function, tdate() returns a character string representation of th e tim e and d ate in th e form: ddmmyyhhmmss w here dd is th e day of the m onth, i m m is th e num ber of th e m onth, yy is the last two digits of th e year, hh is the 24-clock hour of th e day, m m is the m inute of th e hour and ss is the second of the m inute. R e s e t F ile P o in te r 1 The reset file pointer function resets th e file pointer of a file th a t is being read from for an event or action. This causes the next read from th e file to be from the first i line of the file. T he form of the function is reset(filejn a m e ) where file jn a m e is a character string containing the nam e of the file to reset. ; W r i te /R e a d F ra m e j T he w rite fram e function w rites the current fram e in the nam ed window to a nam ed j file while the read fram e function reads a previously w ritten fram e from a file and I displays it in th e nam ed window. T he form of th e read and w rite functions are 1 read(F ileN am e, W indow ) and w rite(F ileN a m e, W indow ). i 3 .2 .1 6 D a ta D ic tio n a r y All elem ents nam ed by th e designer while specifying th e user interface are stored in a d a ta dictionary along w ith any attrib u tes of the elem ent th a t are also specified. ! T he following are th e elem ents th a t can be specified and th e a ttrib u tes th a t are saved w ith them . W in d o w s W indows are stored in th e d ata dictionary as elem ents w ith th e following attributes: N a m e - th e nam e of th e window given to it by th e designer. 132 T y p e - type of M otif window widget to use. P a r e n t - the nam e of th e window’s parent. i A t tr ib u te s - the coordinates of the window, dim ensions, border w idth, and other item s describing its appearance. S u b w in d o w s - pointer to list of sub windows. F ra m e L is t - pointer to list of fram es appearing in th e window. S e q u e n c e s - list of sequences coming ; One thing th a t can be deduced by a window’s parent is th a t if th e parent is the root window, then the window is an initial window of th e application and needs to be brought up on start up of th e application. i | F ra m e s ( i i Fram es are stored in the d a ta dictionary as elem ents w ith th e following attributes: N a m e - the nam e of the fram e given to it by th e designer. j I i W id g e ts - list of widgets th a t appear in th e fram e. j S u b fra m e s - list of subfram es th a t m ay m odify this fram e. S e q u e n c e s - list of fram e and subfram e sequences. F ra m e T y p e - lists w hether th e fram e is a default fram e, history fram e or ju st ] I a norm al fram e. ; In th e case of th e bitm ap and th e m odifications, if the window was predraw n by th e designer then there should exist a bitm ap nam e b u t th e m odifications should be null. Likewise, if th e fram e was specified by suppling a series of graphical operations to be perform ed on the previous fram e, th en th e b itm ap nam e should j be null. j Fram e Sequ en ces Fram e sequences are also stored as elem ents in th e d ata dictionary. T he a ttrib u tes stored for th e sequences are: N a m e - th e nam e of th e sequence given to it by th e designer. ; ♦ I T y p e - w hether it is a window, fram e, or subfram e sequence. (S o u rc e F ra m e , W in d o w ) - a list of tuples giving th e nam es of th e source fram e/w idget and th e nam es of the windows the source fram es appear in. ( D e s tin a tio n F ra m e , W in d o w ) - a list of tuples giving th e nam es of th e des tin atio n fram es and th e nam es of th e windows th e destination fram es appear ! in. E v e n t L is t - a list of th e events and conjunctions necessary for this sequence to be taken. C o n d itio n L is t - a list of the conditions and conjunctions necessary for this f sequence to be taken. G r a p h ic A c tio n L is t - a list of graphic actions to be executed to convert the source fram e into th e destination fram e. A c tio n L is t - a list of actions to be executed when th e fram e sequence is taken. Since there can be m ore th an one source/destination fram e, a list of fram es are given. Also, since the sam e fram e nam es in different windows can be th e sam e, th e window nam e in addition to th e fram e nam e in th e tuples are needed to uniquely define each of the frames. G ro u p s Divergences are also stored as elem ents in th e d ata dictionary. T h e a ttrib u tes stored for each divergence is: N a m e - the nam e of th e divergence given to it by the designer. 134 S o u rce F ram e S eq u en ce - th e nam e of a fram e sequence th a t describes th e fram es th a t have access to th e divergence. R e tu r n F ram e S eq u en ce - th e nam e of a fram e sequence th a t describes th e fram es th a t will gain control after th e divergence finishes executing. W in d o w N a m e - th e nam e of th e window the divergence fram es are to appear in. S ta r tin g F ram e - th e nam e of th e fram e in th e divergence where execution will begin. I T he calling fram e sequence has as source fram es all fram es th a t have access to j th e divergence. T he fram e sequence also lists th e events and conditions th a t m ust ' occur for any of the fram es to get to the divergence (all fram es call th e divergence w ith th e sam e events and conditions). T he retu rn fram e sequence has as source ( fram es the list of fram es of th e divergent where it is possible for control to retu rn ' to th e m ain flow of control of th e application. T he destination fram e can be a i history fram e in a window or any other ty p e of fram e. j j G rap h ical O b je c ts j \ G raphical objects are stored as elem ents in th e d a ta dictionary. T he attrib u tes j stored for each of th e object is: j ! N a m e - th e nam e of th e graphical object. j I S eq u e n c e L ist - a list of sequences th a t contain this object as a source. j I i P a r en t - th e nam e of the o b ject’s parent. All th a t is needed is th e nam e of th e object. T he object does not have a default window th a t it appears in, has no default location and has a predefined size. T he j nam e of the file th a t the object bitm ap is saved in is determ ined by th e nam e of | th e object. 135 3.3 Mapping the Specified Interface onto IR D ’s T he IR D ’s by th e direct m anipulation language is m apped into a statech art which represents th e stru ctu re and flow of control of th e interface. Each p a rt of th e specified interface is m apped into a p art of a statech art. T he statech art is built up increm entally as th e user specifies th e interface and at all tim es defines th e current state of th e specification. T he following sections describe how th e different parts of an interface are m apped into a statechart. 3 .3 .1 W in d o w s T he root state of the underlying statech art contains one su b state for each of the prim ary windows of the user interface. Each of these states are m ade a parent state » so th a t th e flow of control for each of th e prim ary windows can be described by j substates. If any of these prim ary windows contain subwindows or pop up windows, j th en a substate is allocated in th e parent state which represents th e subwindow, j T he borders, scroll bars and window nam es are attrib u tes of the window and have no flow of control associated w ith them . They are not m apped into th e statech art ; but are listed as attrib u tes of th e window. 3 .3 .2 F ram es Fram es of the application are represented by the leaf states of th e statech art. T here j are two ways th a t fram es can be specified: ! I 1. By drawing th em directly in th e graphics editor (predraw n). j 2. By specifying a sequence of m odifications to be m ade to the previous fram e, i Each tim e a fram e is specified a leaf state in th e statech art is allocated in th e current parent state. These leaf states are w hat represent each of th e fram es specified by th e user. i 136 F ra m e s Predraw n fram es are those fram es th a t the user explicitly draws. T he bitm aps rep resenting these fram es are associated w ith a leaf state of the underlying statechart. A n action is autom aticly attached to th e state which will read in th e bitm ap and ! displays it inside th e window when th e state is reached. S u b fra m es Fram es can also be specified by giving a list of m odifications to be m ade to a previous fram e. T he list of m odifications given are associated w ith th e leaf state representing th e fram e and are executed when th e state is reached during sim ulation j of th e interface. This list of m odifications th a t define the fram e are stored as a list j of actions consisting of the graphics com m ands given by the user when draw ing th e fram e. T he actions are listed in th e sam e order as given by th e user. j I I 3 .3 .3 S eq u e n c es j 1 1 Sequences of fram es correspond to th e transitions connecting leaf states of th e statech art. T he source fram e of the sequence corresponds to th e source sta te of th e transition and th e destination fram e corresponds to th e destination sta te of the transition. T he states representing the fram es are all descendents of th e window , in w hich they appear. Due to divergences, they m ay not be direct children of the window state, b u t m ay be grandchildren. j W indow sequences are sim ilar to fram e sequences, except th a t they tie windows together instead of fram es. T he only difference betw een th e two is th a t fram e: sequences connect leaf states of th e statech art while th e window sequences connect j parent states th a t represent windows. T he window sequence is represented as a high-level transition between th e parent states representing th e windows and are identical to th e ones used for fram e sequences. An exam ple of a statec h art w ith fram e sequences and window sequences is shown in figure 3.12. 137 In terfa ce F I F I F r a m e 1 F r a m e 2 F r a m e 1 F r a m e 2 W in d o w 2 W in d o w 1 i ! Figure 3.12: Exam ple of fram e and window sequences as they are m apped into a j statech art. f 138 I ____1 3 .3 .4 H isto r y F ram es H istory fram es tran slate directly into history states of the statech art. W henever control reaches one of these states, control transfers directly to th e state in the : parent state th a t was executed last. ! i L ocal H isto r y F ram es Local history fram es are tran slated into regular history states of statecharts. Due to th e possibilities of divergences existing in a window th a t cover only a subsect of th e fram es in th e window, it is necessary to also give th e divergence a history state ju st in case th e last fram e executed was a child of a source divergence. This is j necessary since divergence are also tran slated into substates of th e window state in ■ which they occur. Figure 3.13 shows the statech art for a window w ith a divergence which covers only some of th e fram e states. It is also given a history state. G lo b a l H isto r y F ram es Global history fram es are tran slated into starred history states. Global history states find th e last leaf state executed of all th e descendents of th e current state. [ It acts as if all descendent states of th e current state also have local history states. ; R a n g e H isto r y F ram es j i Range history fram es are tran slated into a series of local history states. All parent \ states through the topm ost window of th e range through th e b o tto m m ost state ■ are all given local history states. Figure 3.14 gives an exam ple of a set of windows ! given a range history and its corresponding statech art representation. ! 3 .3 .5 E v e n ts j i As discussed previously, the events specified in th e language are used to indicate j when a fram e sequence can be taken. All events are m apped onto their corre- ; sponding events for the transitions th a t represent th e ev en t’s fram e sequences. At j execution tim e, com pound events are checked one at a tim e. T he first event found j I I 139! F r a m e C F r a m e A D iv e rs io n W in d o w 1 F r a m e B Source Divergence © * ■ F r a m e D Figure 3.13: Exam ple of a statech art of a local history fram e w ith divergences. 140' W in rinw— 1- WmdowT W in d o w 3 W in d o w 1 W in d o w 2 - < § ) W in d o w 3 Figure 3.14: T he statechart of a set of windows which using th e range history frames. th a t m akes th e com ponent a sim ple event not tru e halts th e evaluation of the events for th e transition they are specified for. 3 .3 .6 C o n d itio n s j Conditions specified by th e interface designer are associated w ith th e transition | I representing the fram e sequence they w here specified for. C onditions are checked , only if the events for the transition are all true. If all th e events are tru e and ! a condition is found to be false, th e tran sitio n is not taken. T he evaluation of 1 com pound conditions is th e sam e as for events. As soon as one p a rt of th e condition j m akes th e entire condition false, the evaluation stops and th e next tran sitio n is J tried. I 3 .3 .7 A c tio n s As discussed previously, actions can be associated w ith states or transitions of a statech art. T he states th a t user defined actions are associated w ith can either be I leaf states, which correspond to frames of th e user interface, or they can be parent states, which correspond to a window. If th e state is a leaf state, then the action is executed before the next event is checked b u t after th e actions th a t draw the window. If th e state is a parent state, then th e action is executed before a substate is given control. t 3 .3 .8 C o n cu rren cy C oncurrent p arts of user interfaces are m apped into orthogonal states which use a com m on parent. Concurrency can be one of two types: w ithin a window and betw een windows. O rthogonal states have an a ttrib u te associated w ith them th a t indicate w hether th e state represents concurrency betw een two separate windows ! or betw een several objects all appearing in the sam e window. ' 3 .3 .9 D iv e r g e n t F ram es T he divergent frames th a t are used for help and error messages are represented by sets of states ju st like th e states th a t represent th e fram es of a window. These J divergent states are contained in a parent state separate from th e window they are j defined for. This divergent parent state is defined as a sibling to th e parent state ' th a t represents th e control flow of th e window. If less th an all the fram es in the window w here defined as source states to the divergent, then the source fram es are group together in a substate of the parent state. T he fram e sequences th a t lead I from the source states to th e divergence are represented as transitions, ju st like 1 norm al fram es. T he transitions have as a source sta te th e substate th a t groups I together the states th a t go to the divergence. T he destination state is defined as ; th e parent sta te for th e divergence. T he set of divergent states then has a default j state defined th a t indicates the first fram e of th e divergence. Divergences th a t are defined for m ultiple windows are m apped into statecharts th e same way th a t they are for fram es in a state w ith th e windows tre ated ju st like norm al states of th e statechart. T he windows th a t share a divergent are grouped together in a substate and have a transition going from this substate to th e divergent. H istory states can also be defined for the source windows of the divergence th a t returns control back to th e window th a t called th e divergent, ju st like w ith th e fram es. M ultiple divergences can be defined for fram es or windows of the interface. Each divergent can also have intersecting sets of fram es inside th e window. In this case, it is possible for a fram e or window to go to m ultiple divergences on different events (if intersecting divergences have th e same events going to them , then this { is a case for an inconsistency and is discussed in chapter 4). An exam ple of how j this would look like in th e underlying statech art is shown in figure 3.15. \ I 3.4 Three Examples Revisited The following four exam ples are th e same th a t w here used in chapter 2 to illustrate th e use of statecharts for representing a user interface specification. For each of , th e exam ples, th e steps necessary to produce the interface using the specification j language is given. T he resultant statecharts and their explanation can be found in ■ section 2.6, figures 2.8 - 2.19. | 3.4.1 F orm E x a m p le j T he form exam ple is th e book store query system which prom pts th e user for a ; query com m and and search inform ation and then displays th e result of th e query. : T he designer specifies the interface by: i f i 1. Defining th e initial (and only) window the form s are to appear in. j | 2. Drawing th e fram es to appear or giving m odifications to be m ade to predraw n i I fram es. 1 I i 3. Specifying th e sequence in which th e fram es are to appear in. | W in d o w W in d o w 2 W in d o w 1 Source Divergence F r a m e 2.1 F r a m e 1.1 F r a m e 2 .2 F r a m e 1.2 D iv e rg e n c e 3 D iv e r g e n c e 2 D iv e r g e n c e 1 Figure 3.15: Exam ple of m ultiple intersecting divergencies. 4. Specifying th e events for which each of th e fram e sequences are to be taken. 5. Defining any actions th a t need to be executed after a fram e is displayed. i 6. Specifying th e help and error frames. 7. Defining divergences for the help and error fram es. this exam ple will only describe th e fram es running along th e th read of control of th e Title Query com m and. T he fram es for this exam ple can be found in section 1.3 in figures 2.8 through 2.11. the following sections describe each of th e above seven steps in specifying the interface in detail. D e fin in g t h e W in d o w As w ith specifying all interfaces using the above specification language, the designer ■ starts by entering th e specification system and drawing th e initial windows th a t ! th e interface is to appear in. In this exam ple th e application will run in only one window. To specify th e initial window, th e designer selects th e define window com m and and using th e mouse indicates the window’s initial position and size. \ th e D e fin e W in d o w option. T he cursor then changes from an arrow to a wedge I indicating th e upper left corner of th e window. T he designer th en places the edge J of th e window in th e location where th e window is to appear on th e initialization j of th e application. T he designer clicks th e left b u tto n when th e wedge is in the i i propper location. A t this point, the cursor is changed to indicate the lower right ; corner of th e window so the designer can specify th e horizontal and vertical size : of th e window. By moving the cursor, th e size and shape of th e window can be ; changed. W hen th e proper size and shape is determ ined, th e left b u tto n is again : clicked which causes th e outline of th e window to b e drawn. Once the window ’s j size, shape and initial location has been specified other aspects of th e window j such as the nam e and border size can be defined. To specify the nam e of the 1 window, select th e w in d o w n a m e option under the w in d o w com m and and se le c t! i th e window th a t is to receive th e window header by placing th e cursor over th e ; window, clicking th e left b u tto n of th e m ouse and th en typing the nam e of th e i application “Book Search” when th e cursor appears. To center the tex t, blanks j I 145 | can be added to th e front of th e nam e. To specify the border w idth of th e window, select the b o r d e r option under the w in d o w com m and, place th e cursor over the window whose border is to be defined, click the left m ouse b u tto n , move th e cursor out to indicate th e desired thickness and then click th e left m ouse b u tto n again to indicate the end of th e com m and. To alter th e border w idth or change th e window nam e after they have already been modified ju st re-execute th e com m and and the border can be redefined or the window nam e retyped. A fter the window has been specified, the window com m and i can be exited by selecting th e exit option which will pop th e user back to th e create j interface menu. D e fin in g th e F ra m e s I All of th e fram es in this exam ple are defined by drawing them or by specifying some i graphical m odifications to be m ade to previous fram es. T he first fram e is draw n in ; th e window specified above and consists of a title and a m ain m enu listing the five i I available com m ands. T he nam e given the fram e is main. T he second fram e in the j title query series contains instructions to type in th e nam e of the title to search j for along w ith a space for the title to be typed. This fram es is nam eded the title ' fram e. T he th ird and fourth fram es in the series are fram es which are displayed , depending on w hether th e search for the title was a success or failure. T he title ; i success fram e gives headers for the title, author and publisher nam es, th e book j num ber, price, and th e num ber of books in stock. T he failure fram e states th a t the j book is not carried by the book store. Sim ilar fram es for th e search string, failure i j and success fram es are draw n for th e other search com m ands. T he help and error | fram es are discussed below under divergences. | i i i D e fin in g I n p u t A re a s Input areas are only needed for the inputs of the search item s. T he input defining which com m and to execute in the m ain m enu and th e default keystroke for the help, error and search result frames are also not p rinted and therefore do not need an input area defined for them . To define an input area for each of the search I 146 | i fram es, each of the respectful fram es are called up in tu rn and the I n p u t A r e a option under th e C r e a te F ra m e com m and is chosen. A rectangle is th en drawn by the designer representing th e size of th e input area in th e location where the typing is to appear. D e fin in g O u tp u t A re a s i O u tp u t areas are needed for each of the successful query result fram es the title : success fram e for th e title com m and). Each of th e o u tp u t areas should be big enough to display each piece of inform ation for a single book, this includes the title, author, publisher, book num ber, price and the num ber left in stock. Since it is possible th a t m ore th an one book can be found on some of the searchs (e.g., j author) a “stop scroll” o u tp u t area should be defined. T he specification of the j o u tp u t area is done by the designer selecting the O u tp u t A r e a option under the J C r e a te F ra m e com m and after the appropriate fram e is brought up. T he designer ! then choses the S to p S c ro ll type of scrolling area and draws a rectangle in the i size of the area to receive the tex t. i U s e r D e fin e d I n p u ts ! I T he user defined inputs in this case are th e function results of a database search. ■ 1 If a search finds the item , then a su c c e ss result is retu rn and if th e item is not i found, then a fa ilu re result is returned. In this case, since th e book store database : system has not been developed yet, we will instead read in th e function results from a file. T he contents of the file consists of one retu rn value per line of th e file (since a ! whole line is read each tim e), the file will contain a series of “success” and “failure” j strings, depending on how th e designer w ants th e sim ulation to run. This type o f ! a specification is called a m ockup. T he file th a t th e function results are to be read from is specified by th e designer w hen selecting the I n p u ts com m and and selecting th e R e a d F ro m F ile option. T he user is then prom pted to give a nam e of a fram e th a t th e input is to be associated w ith and the nam e of th e file th a t th e values will be read from. Table 3.1 gives an exam ple of w hat the file m ight contain. It should be noted th a t no; i 1 4 7 ! s u c c e ss s u c c e ss f a il u r e s u c c e ss Table 3.1: Values stored in file to be read in for search result. m a tter w hat is entered for a search, the search results will always yield success, success, failure and success no m atte r w hat the user inputs. i i D e fin in g th e S eq u en ce o f F ram es I defining the sequence in which the fram es are to appear in is th e next step of th e specification. As w ith defining the fram es, only th e fram e sequences for th e title search com m and will be given. This is done by specifying th e events necessary to move from one fram e to th e next, th e first sequence of fram es is the welcome fram e listing th e available com m ands which goes to th e search for title fram e asking th e ! user for the title of a book to search for. To specify this sequence th e designer . selects th e fram e sequence com m and under the C rea te In terfa ce com m and. T he ; designer is and is then prom pted for a nam e of th e sequence (title), th e source fram e (main) and the destination fram e (title). T here is no inconsistency in giving - both a fram e and a fram e sequence th e sam e nam e since they refer to d ifferen t! objects. T he second sequence of frames depends on a user defined input from th e query com m and consisting of a success or failure retu rn value (specified above). T he success sequence is specified w ith th e source fram e title and the destination fram e success. T he failure sequence also uses th e source fram e title but uses th e destina tion fram e failure. T he th ird fram e sequence returns the user back to th e first fram e when the user types any keystroke. This sequence can be specified by using all the success/failurej i fram es as th e source fram es and the destination fram e of main (it’s given a nam e o f 1 return) . T he rest of th e search com m and fram e sequences are defined in a sim ila r; t m anner. ; i 148 i D e fin in g t h e E v e n ts a n d C o n d itio n s T he events and conditions th a t define w hen each of th e above fram e sequences are ! to be taken are specified after the fram e sequences have been done. All th e events ; for this application are composed of user inputs in th e form if ty p ed characters j I or values read from files. As w ith th e fram e sequence, only th e search for author operation will be covered here. The other event definitions are sim ilar. T he first fram e sequence is when th e user presses th e num ber “1” to indicate th e search for title query. This event is an unbuffered input, th e value typed in by j the user will not be echoed, so no input area needs to be associated w ith it. T he j user specifies the event by selecting the event com m and under c r e a te in te rfa c e , i and giving th e nam e of the sequence the event is to be associated w ith title) and typing th e num ber “1” as th e event. ! the second fram e sequence depends on a user defined input from th e query com m and consisting of a success or failure retu rn value, the values specified for the events are exactly th e possible values read from th e file: ”success” and ’’failure” . The ’’success” event is given to the success sequence and the ’’failure” event is given ; to th e failure sequence in the sam e m anner as above. the th ird fram e sequence is taken when th e user types in any character to q u it< reviewing th e query result. T he event to use in this case is the default event ' ■ (although th e regular expression will also work) and the sequence th a t th e j event will apply to is return. I D e fin in g th e A c tio n s | I Defining th e actions th a t are to be associated w ith th e fram es and fram e sequences ! are specified next. T he only action th a t needs to be specified is: th e print string actions to display th e title, author, publisher, num ber, price and num ber in stock ^ of th e book when the search is a success, i.e., when control reaches a success fram e), j No other actions are needed for th e other fram e sequences since all th a t is necessary j for them is to ju st display th e next fram e, which is defined as an im plicit action 1 I autom aticly when th e fram e sequence is specified. Like th e events above, since th e database system is not available, the results will be predefined in a file. ! 149 The Art o f Computer Programming, Vol I Knuth 111 , $ 5 9 .9 5 1 Table 3.2: C ontents of file holding query results. T he actions needed to be executed for th e title success fram e sequence will I consist of reading one line from the file for each of th e values to be p rin ted and assigning th em to a variable. These variables will th en be p rin ted in th e outp u t areas assigned for each item . Again, one should note th a t w hen using this m ethod of reading th e results from a file, w hat is displayed does not necessarily correspond i to w hat was typed in by th e user as a search item . T he actions to read the query results from a file are specified by assigning a variable to the result of th e function R eadF ile{Q ueryR esults) for each if th e j values to be printed. Table 3.2 shows th e first five lines of th e file to be read in which consists of a book title, its author, book num ber, price and q u an tity in stock. Variables for each of th e item s to be printed are on separate lines of the file and m ust be assigned separate variable nam es. Giving each of th e values a \ I separate variable nam e allows m ore flexibility in the form at in which the values j will be printed. T he assignm ents defined th a t will read in th e values in th e file are: i I T itle = ReadFile(Q uery Results) \ A uthor = ReadFile{Q uery R esults) N um ber = ReadFile(Q uery Results) Price = ReadFile(Q uery Results) Q uantity = Read File{Q uery Results) T he above equations will each read one of the lines of the file shown in table 3.2 into each of th e five variables. ( O nce the variables are set w ith th e query results, th e actions to p rin t the values ! to th eir respected o u tp u t areas can be specified. Each of th e query result variables ' are p rin ted one at a tim e, so there will be one print action for each or th e variables. T he title of th e book is printed by th e designer selecting th e p rin t action, specifying I an o u tp u t area w here th e title is to appear by pointing to th e o u tp u t area of the j title success fram e and listing th e T itle variable in th e action window provided as ! th e string to be printed. T his is done for each of th e five variables. D e fin in g t h e H e lp a n d E r r o r F ra m e s Help and error fram es can be called from any place in th e user interface by the user either pressing th e “F l ” key for help or pressing a nonsensical key for an appropriate error message. Defining th e help and error fram es consists of specifying a divergence for each of them . The help window consists of a single fram e th a t is p rinted in th e application window. To specify th e help window, the designer selects the predraw option on the fram e com m and and draws th e help fram e directly and gives it th e nam e “help.” The designer th en selects the divergence com m and and selects the “help” fram e as th e fram e sequences for th e divergent, selects th e “help” fram e as th e default fram e for th e divergence and selects the entire window as the source fram es (i.e., all fram es appearing in th e window are source fram es). T he last thing th e designer does is to specify a history fram e as the destination fram e for th e J divergence so th a t control will retu rn to th e fram e w here control was interrupted. ^ T here are actually two different error fram es th a t can appear: one error fram e j for th e m ain window (fram e “erro rl” ) and one error fram e for all the search fram es j (fram e “error2” ). T he help fram e and th e fram es th a t print the results of the | queries do not need error fram es since all they require is for th e user to ’’Press | any key to continue” . Specifying th e error fram es is sim ilar to specifying th e help j fram es. To specify th e second error divergence, th e designer selects the d iv erg en t! com m and, specifies th e “error2” fram e to be th e fram e appearing in the divergence ' and the default fram e for th e divergence and selects th e “search title ,” “se a rc h ! I au th o r,” and “search num ber” frames as th e source frames. Since th e “e rro rl” ; fram e only applies to th e m ain m enu of th e application, a divergence is not re a lly , necessary. T he designer instead can define a default fram e sequence from th e “m ain m enu” fram e to th e “e rro rl” fram e and back again to the “m ain m enu” fram e. This * 151 will in essence give the sam e result as a divergence. T here is one last divergence th a t needs to be specified for this application. T here is an escape key, “ESC ,” th a t allows the user to retu rn to th e m ain m enu fram e j from anyw here in th e application whenever it is pressed. This is also specified I by th e designer defining a divergence for all fram es in th e window. T he fram e appearing in the divergence is th e m ain m enu. This divergence is specified in the sam e way as th e help divergence except th a t there is no destination fram e specified for th e divergence since th e m ain m enu already has fram e sequences leaving it for the three search frames. I 3 .4 .2 M u ltiw in d o w E x a m p le j T he m ultiwindow exam ple is a graphics editor th a t is a subset of Fig. This interface ! consists of two separate windows (a com m and and draw ing window) and a pop up window. T he com m and window consists of a collection of icons representing the j different editor com m ands and th e drawing window is w here graphics are drawn. T he pop up window is a subwindow to the draw ing window and is bound to the I right key of th e mouse. T he pop up window contains com m ands to save a drawing, read in a previously saved drawing and a quit com m and. T he interface is specified by the the designer drawing the initial windows first, draw ing th e fram es second j followed by th e association of events and actions w ith th e fram e sequences. The pop up window can be specified at any tim e after th e draw ing window is specified. I D ra w in g th e W in d o w s ! Once th e designer enters th e specification system , th e initial windows th a t appear . w hen the application is in itiated m ust be drawn. This includes the com m and j window and th e draw ing window. T he popup window does not appear on th e initial j sta rtu p of the application, so it is defined later. To specify the initial windows, th e designer selects a position for the window, adjusts the size,and gives it a nam e. N ext, th e border sizes for each of th e windows are specified by p u ttin g th e m ouse j over th e window to be specified, clicking th e b u tto n , adjusting the border size by m oving th e m ouse out and saving th e border. If any m istakes were m ade they can 152 be fixed by either deleting th e item w here the m istake was m ade and redraw ing it or in th e case of th e window title and border reissuing th e com m and. t T h e C o m m a n d W in d o w i I I T he com m and window consists of a collection of icons representing com m ands for I draw ing or m anipulating graphics in the drawing window. T he designer starts the specification of th e com m and window by drawing its in itial fram e. This fram e is actually th e only fram e th a t needs to be specified since subsequent fram es are m odification of this fram e consisting of highlighting of different icons. A fter th e com m and fram e is draw n, the fram e sequences are defined. There t will be one sequence th a t will represent th e highlighting of each icon, th a t will | consist of fram e sequences for highlighting each of th e icons. To do this, fram e j m odifications m ust be specified for each of th e icons in th e window. This m eans [ th a t a fram e sequence will have to be defined for each of th e icons so th e actions . have som ething to be attached too. One fram e sequence for each of th e icons needs ! to be defined w ith th e fram e main listed as both the source and destination fram e j for each of the sequences. Defining a fram e sequence for th e rectangle icon would I consist of: j j • Selecting the fram e sequence com m and. • Selecting the com m and window as th e destination window. j • Giving th e sequence a nam e (e.g., “rectangle” ). • N am ing th e fram e main as th e source fram e. • Nam ing th e fram e main as the destination fram e. I T he fram e sequences for th e other com m ands would be defined in exactly th e same j way. j T he events th a t indicate when each of the fram e sequences are to be taken | are defined after the fram e sequences have been specified. T he events consist of' i clicking the left m ouse b u tto n inside an icon to specify which com m and is being j selected. T his m eans th a t each of th e fram e sequences from the com m and fram e | 153 will all have a left b u tto n as their event. To distinguish one sequence from another, a condition needs to be added to th e event to indicate th a t th e sequence should only be taken if the cursor is over th e respected icon. T he events for each of the sequences consists of a b u tto n press and release of th e left b u tto n w ith a second A N D ’ed event testing if th e cursor is in the appropriate icon area. To specify the second event of the cursor being over a particular icon, th e designer selects th e cursor position event and draws a box around the appropriate icon. This event will then becom e tru e whenever th e cursor is in th a t box. T he m ouse click event is specified by the designer and th en defines it for the left b u tto n for a push and release of th e bu tto n . These events are specified for each of the fram e sequences defined above. | i Lastly, the actions th a t are to be executed when each of th e fram e sequences are I taken are specified. These actions consist of setting the com m and variable to the appropriate value indicating which icon was chosen, inverting th e icon chosen and inverting th e previously selected icon. T he actions to indicate th e inverting of th e j icon would be done by the designer selecting th e invert graphic action and pointing i to th e appropriate icon. T he previous icon is inverted to norm al m ode by th e action ; invert(C urrentC om m and), w here C urren tC o m m a n d is a variable nam e) and the ( new com m and nam e saved by th e action: C u rren tC o m m n a d = “rectangle”. J A different way to specify th e com m and window would be to define each of th e , icons as orthogonal subwindows. Each of these icon subwindows would then have two fram e sequences: 1. O ne to check if th e left m ouse b u tto n was pressed. 2. One to check if an internal broadcast was m ade. T he first item would only be tru e if th e cursor was over the window (icon) when the b u tto n was pressed and the second sequence is to un-highlight the an icon when it is un-selected as a com m and. T he first fram e sequence would have actions of m aking the icon inverse video and sending out a broadcast th a t a new com m and was selected and th a t the old com m and should un-highlight itself. T he second fram e sequence would check for the internal broadcast and would have a condition th a t tested if the previous com m and was the com m and represented by this icon. If 154 it is, then it would un-highlight its icon. This m ethod is actually sim pler in m any ways and would save the designer from having to m ake a fram e sequence for each of th e icons and doing test for cursor positions inside th e icons. D e fin in g th e D ra w in g W in d o w As w ith the specification of the com m and window, th e specification of the drawing window begins w ith drawing its initial fram e. T he only thing th a t needs to be ; draw n are th e rulers on the top, b o tto m and left side of th e window w ith the rest i of th e window blank. Also like the com m and window, this will be the only fram e , th a t needs to be draw n since subsequent fram es will be m odifications of th e initial j fram e. T he rest of the fram es are defined as m odification of th e previous fram e. | As w ith th e com m and window, th e rest of th e specification will be given only for th e rectangle com m and. T he frames th a t need to be defined for th e rectangle com m and are: • A fram e th a t draws a dashed rectangle at the current cursor position. I i • A fram e th a t draws a solid rectangle. ' T he fram e sequence going from the initial drawing window fram e can save th e value | I of the first cursor click to be used for the location of th e m iddle of th e rectangle, i M oving the cursor then causes an event to occur th a t redraw s th e rectangle using th e new current cursor position as th e lower left hand com er of th e rectangle. j A fter the initial (and only) fram e is draw n the fram e sequences are defined. J There will be a separate set of fram e sequences for each of the drawing com m ands. , The rectangle’s first fram e sequence would consist of a source fram e coming from , th e initial fram e and going to the initial dashed rectangle fram e (rectangle fra m e ; 1). A second fram e sequence m ust be defined for when th e cursor is moved, so a! fram e sequence is defined from fram e 1 back to itself. This is done since the cursor j can be m oved several tim es. A th ird fram e sequence is defined to th e second j fram e m odification which draws the fram e as a solid line. A fourth and final fra m e ; l sequence is draw n from this fram e m odification back to th e windows initial fra m e .! T he events and conditions th a t specify when each of th e above fram e sequences i will be taken are defined next. Since m ost of th e com m ands are started using the j i 155 left m ouse b u tto n , th e only way to know which of several identical events should be taken is to specify conditions stating th a t th e startin g fram e sequence should only be taken when th a t com m and is in effect. T he com m and in effect is specified through a variable, Command, so each of th e conditions will be of th e form: j i I 1 C om m nad = “rectangle where th e nam e in quotes is th e nam e of th e com m and for th e following fram e sequences. T he event for th e second fram e sequence consists of a m ovem ent of the cursor from its current spot. W hen this happens, a fram e sequence from the first fram e back to its self is executed so the rectangle can be redraw n w ith its new j i size. T he fram e sequence betw een th e first and second fram e is taken when the left i m ouse b u tto n is clicked again indicating the correct size of th e rectangle has been found. T he last fram e sequence going from th e second fram e back to the predraw n window fram e has a null event defined for it. No input is necessary for control to j go from th e second fram e back to the initial fram e. ' Lastly, th e actions th a t are to be executed whenever a fram e sequence is taken j are given. T he actions to be executed for th e fram e sequences defined above for the rectangle com m and would sta rt w ith the mouse click sequence th a t indicates : the m iddle of th e rectangle. Any m ovem ent of the cursor th en causes the “Cursor i M ovem ent” event to be triggered and the action erasing th e old d o tted rectangle j and redraw ing th e new d o tted rectangle. T he last action occurs when the second m ouse click event occurs. This sim ply causes the current rectangle to be redraw n w ith a solid line. I D e fin in g th e P o p u p W in d o w | T he popup window is specified by the user selecting th e draw ing window as th e j pop up window’s parent and indicating th e left mouse b u tto n for to be defined for \ it. A two colum n window then appears for the user to type th e popup windowj item s and their corresponding actions. T he user then types in th e com m ands t h a t , are to appear in the popup window and th e associated functions th a t are to b e , executed. Table 3.3 shows th a t the popup window specification would look like; after it was specified. T he nam es in the first colum n are w hat will appear in t h e , 156 i Ite m N a m e I te m A ctio n Save write(file) Read read(file) Q uit halt Table 3.3: Specification of a popup window for th e Fig graphics editor. window when th e pop up window is brought up and th e right colum n are the actions to be executed when th a t item is selected. D e fin in g th e H elp W in d o w ! A help window can be defined th a t appears whenever th e user presses the “h ” or , “H ” keys. Using global key definitions, a help window can be m ade to appear w ith a predefined message explaining how to use Fig. T he help window is then erased on the next user input. ! To specify th e help window, a new window is draw n and inside this window j a description of how Fig works is w ritten. T he help window is specified as a j divergence. Since the sam e help window will be displayed no m atte r which window j th e user is in, the divergence will be specified at the window level. This m eans ! th a t all the fram es in th e drawing and com m and window are included as th e source j of th e divergence. To do this, draw the window th a t th e help fram e is to appear j in specifying it to appear when control reaches th e window and draw the help fram e inside th e newly defined window. N ext, the divergence com m and is specified under th e create interface environm ent, th e window is selected as th e divergence, j th e com m and and drawing windows are specified as th e source fram es, and a global j history fram e is specified as the retu rn fram e. [ T here are no error messages necessary for Fig. If an input is given by th e user th a t doesn’t m ake sense, Fig sim ple ignores it. This can be seen by exam ining the statech art for th e application. In this case if an input is given in either the com m and or drawing window th a t is not defined in th a t window, it is passed up to th e root state for evaluation. Since the only events th a t th e root window looks for is th e m ovem ent of th e cursor betw een th e two windows, any other in p u t passed up to it is sim ply disregarded. 3 .4 .3 C o n cu rre n c y B e tw e e n W in d o w s E x a m p le T he exam ple of concurrency betw een windows is th e typing tu to r program where th e user types in one window and statistics on how th e user is doing are displayed in a second window. Before th e windows can be defined to be orthogonal to each other, each of th e windows has to be specified separately. T he following outlines th e specification of each of the windows. t D ra w in g th e In itia l W in d o w s ! T he interface designer would again sta rt th e specification by defining th e two initial window sizes and locations as well as giving th e windows nam es and border sizes. Since no scroll bars, subwindows or popup windows are needed, th e specification of th e windows is done. J f D e fin in g th e T y p in g F ram es I T he initial fram e of th e typing window containing the instructions on how to use th e program and introductory m aterial on typing is draw n first. T he next fram e to be draw n is th e typing window which has an area for characters to be draw n ; and space underneath them w here the characters th e user types are to be printed, j * T he space underneath th e characters is defined as an input area which allows the i characters typed by the user to be echoed. One in p u t area for each of th e lines o f ; characters is needed. A th ird fram e is needed to ask th e user if he w ants to quit or I have another fram e to type on and a fourth fram e th a t consists of a halt com m and is needed to close th e window. T he fram e sequences are defined after th e fram es are drawn. These sequences will be a com bination of sequences of predraw n fram es and frames defined as m odi fications to previous ones. T he first fram e sequence is from th e instruction fram e to th e typing fram e. T he second fram e sequence is from the second fram e and is taken when the user types in a character. This causes th e character to be p rinted in th e ! n ext spot under th e one th a t was supposed to be typed. T he th ird fram e sequence ^ goes from th e typing fram e to th e fram e th a t asks th e user if he w ants to continue w ith another typing fram e or to quit. T he fourth and fifth fram e sequences go from the co n tin u e/q u it fram e to th e halt fram e and from th e continue/quit fram e ! back to the fram e displaying the characters to type. T he events and conditions th a t specify when each of the fram e sequences are to be taken are given next. T he first sequence from th e instruction fram e to the typing fram e is taken when th e user gives any in p u t, so a default event is defined for th e event. T he event for th e typing fram e sequence th a t is taken when the user i types a character. This sequence needs to be taken whenever a non Ap, Aq or E S C 1 is typed, so a default event is used. Events for th e pause (Ap) and quit (Aq or ESC) are also added to their respective fram e sequences. No actions need to be specified for th e above fram e sequences. T he characters typed in are defined to be echoed in th e proper input area and the displaying of th e proper fram es is done autom aticly when a new fram e is reached in a fram e ' I sequence. D e fin in g th e S ta ts W in d o w T he specification of th e statistics window begins by th e user draw ing th e initial ' fram e of th e window showing the various typing statistics w ith zero as their initial values. Subsequent fram es are specified as a m odification to the initial values in , this first fram e. T here are two ways th a t th e statistics window m odifications could be specified: 1. Redrawing all th e statistics whenever one of th em have changed. I ! 2. Redraw ing only the statistics whose values have changed. j T he first m ethod is th e sim plest m ethod and consists of a single event checking for when any of th e statistics values have changed. It is also the m ost inefficient i m ethod because all the statistics have to be redraw n even though only one of them j m ight have changed. T he second m ethod is m ore efficient in term s of w hat is redraw n on th e screen, b u t is m ore com plicated since a fram e sequence will h a v e , I to be defined for each of th e statistics. In this case we will use th e m ore efficient j second m ethod. 159 T he fram e sequences for th e stats fram es will be m odifications of previous fram es in th e form of printing th e new statistics values over th e old ones. A fram e sequences for each of th e statistics being displayed will have to be defined. T he source fram e for each of th e sequences will be the initial statistics fram e and the destination fram e will again be th e initial fram e. T he events for th e statistics window consist of checking predefined variables for a change in their values. W hen a change occurs, then a change in th e statistics j has occurred and the corresponding value in the stats windows m ust be updated, j For exam ple, the num ber of m istyped characters is kept track of to be displayed i as one of th e statistics. A null event is used for th e fram e sequence th a t updates j this statistic w ith a condition th a t checks th e old value of th e statistic w ith the j I new value, e.g., “oldjmissedl = current -m issed.” W hen this condition becomes j true, th e sequence is taken and the new value is p rinted to its o u tp u t area and the j variable “old-m issed” is set to “cu rre n t-m isse d ” D e fin in g th e W in d o w s to b e O rth o g o n a l : The windows are defined to be orthogonal to each other after th e typing and stats I windows have been fully defined separately. A t this point, th e designer is prom pted 1 I to select th e windows th a t are to be orthogonal to each other and th e designer clicks i th e m ouse b u tto n on each of the two windows. I I H elp W in d o w ' A help window is defined for th e stats window th a t appears w henever th e F l ! function key is pressed. W hen the help window appears, the execution of th e * 1 typing window is suspended, th e window th e help m essage is to appear in is opened j and th e help message is p rinted in th e window. W hen th e user is through reading th e help window, th e user presses th e F l key again, the window is closed and the typing tu to r is restarted where it left off. T he above help window is im plem ented using a divergent fram e sequence. A window is opened and specified as being opened only when executed, th e help fram e is draw n and indicated as the default fram e for the window. T he divergence I 160 is defined as consisting of all th e fram es in th e help window. T he source fram es of th e divergence consist of all th e fram es in th e typing and statistics windows and th e destination fram e will be a global history fram e defined to be in the root window. T he global history fram e is needed so th a t both windows can resum e w here they left off before th e divergence was executed. C h a p te r 4 C o n siste n c y a n d C o m p le te n e ss o f IR G s I Consistency and com pleteness of any specification needs to be checked. D uring th e ! process of specifying th e user interface it is inevitable th a t the specification will go through incom plete and inconsistent states due to m odifications and uncom pleted work. T he inconsistent and incom plete states are of interest to designers because it lets th em know w hat p arts of the interface are unfinished, have been effected by previous changes, or im properly done. In this chapter th e causes of inconsistencies in an IRG are discussed, under w hat circum stances an IRG would be incom plete, , and how inconsistencies and incom pletenesses can be found. 4.1 Consistency For a specification to be consistent no p art of th e specification should conflict w ith ; any other p art. T he following are the ways an IRG can be inconsistent: • M ultiple destinations of sequences. • Sequences w ith th e sam e events and conditions. j • M ultiple startin g nodes. j • M ultiple objects w ith th e same nam e. • Intersecting groups w ith th e sam e events. • Incom patible types on d ata constraints and shared data. I T he following sections describe each of the above inconsistencies and th e type of j situations th a t can cause them . | I I 4 .1 .1 M u ltip le D e s tin a tio n s o f S eq u e n c es A transition can have m ultiple destination nodes as long as each one of th e destina tions is in a separate concurrently executing (orthogonal) com ponent. A transition j is inconsistent when it has m ultiple destination nodes th a t are in th e sam e orthog- j onal com ponent. Since each orthogonal com ponent is sequential, only one node at ; a tim e can be executed. If m ultiple destination nodes exist in th e sam e com ponent, th en th e specification is nondeterm inistic. If this should happen, either th e designer listed the wrong destination fram e for j one (or m ore) of the orthogonal com ponents or the designer forgot to list the parent node as orthogonal. In th e first case, it would m ake the specification inconsistent since it is am biguous as to which node is to receive control next. In th e second j case, th e IRG is incom plete due to the unspecified orthogonal com ponents. Since j we cannot read th e designer’s m ind to determ ine if the designer forgot to specify j an orthogonal com ponent, we will have to classify this situation for w hat it appears ' to be: an inconsistency due to the inability to determ ine which node of m u ltip le ! nodes specified is to gain control next in sequence. ! Figures 4.1 and 4.2 give exam ples of good and bad m ultiple destination nodes ! in orthogonal com ponents. In figure 4.1 node A on event x gives control to th e two * orthogonal nodes C and D . Node A has explicitly indicated startin g nodes inside \ nodes C and D . In figure 4.2, node A also indicates two sta rt nodes, b u t the nodes are in the sam e orthogonal com ponent, thus causing an inconsistency. 4 .1 .2 S eq u e n c es W ith th e S a m e E v e n ts an d C o n d itio n s If a node has m ultiple transitions leaving it, only one of those transitions can be j taken w hen an event occurs. If m ultiple transitions were allowed to be taken, then 163 m E d G H Figure 4.1: C onsistent fram e sequence w ith m ultiple destination nodes in orthog- 1 onal com ponents. Figure 4.2: Inconsistent IRG w ith m ultiple destination nodes in non-orthogonal com ponents. I 164 j ____i a nondeterm inistic function would result. It m ight be thought th a t an easy way to solve this problem would be to disallow identical events on transitions leaving the sam e node. U nfortunately, identical events coming from th e sam e node are som etim es necessary. Such a situation was illu strated in th e Fig graphics editor exam ple in th e previous two chapters w here th e left b u tto n of the m ouse could indicate one of several figures to draw depending on the value of a variable in each of the tran sitio n ’s condition. T he following are th e types of situations th a t could cause m ultiple transitions j to be taken on a single event: • M ultiple transitions w ith identical events and no conditions. • M ultiple transitions w ith identical events and identical conditions. i t • M ultiple transitions w ith identical events w ith different b u t equiv alent conditions. | • M ultiple transitions w ith different variables w ith equivalent values j for either events or conditions. j i T he first item is actually a special case of th e second item where both conditions j are null (and therefore identical). T he following discusses each of the above possi- ! bilities. f Id e n tic a l E v e n ts and C o n d itio n s ■ I It is easy to identify a node th a t has m ultiple transitions w ith exactly th e sam e i events and conditions. U nfortunately, two different transitions can have th e fol- j lowing two events: j e l = Right Button V Return \ i and ; e2 = Return V Right Button , In th e above case events el and e2 are the same event but th e events Right Button and Return are in different order m aking detection m ore difficult. Figure 4.3 shows j an exam ple of this type of inconsistency at node C . T he tran sitio n going from node | 165 C out of node A and the transition going from node C to node F both have th e sam e event (u) and condition (a = b). Id e n tica l E v en ts w ith D ifferen t b u t E q u iv a len t C o n d itio n s Two conditions do not have to be identical for them to be tru e at th e sam e tim e. i An exam ple is when one condition is algebraicly equivalent to another as in: Ci = (a A b) V c and c2 = (a V c) A (a V b) W henever c2 is true, Ci will also be tru e (D eM organ’s Law). A nother exam ple ! I of two different conditional statem ents being tru e a t th e sam e tim e is when one j condition is a subset of another or m ultiple conditions have identical subparts which causes th e conditions to be tru e sim ultaneously only some of th e tim e. An j exam ple of such a situation would be th e following: j I I c l = a A b A c and c2 = a A b j i In this case th e tru th of condition c2 implies th a t th e tru th of condition cl. W hen- j ever cl is tru e c2 is tru e but not the converse. A nother case would be if condition ! I cl and c2 were th e following: j ci = a A b A c ! and ! I c2 = a A b A d In this case th e conditions cl and c2 would only be tru e at th e sam e tim e if variables c and d w here also tru e at th e same tim e. To cause additional uncertainty when | trying to detect inconsistencies a situation could exist w here c is always equal to i d m aking cl and c2 equivalent, or c could be equal to th e negation of d whereby j cl and c2 are never equal, or c and d are ju st som etim es equal. j 166! i a — b a = b Figure 4.3: Inconsistent IRG w ith identical events. 4 .1 .3 M u ltip le S ta r tin g N o d e s A parent node th a t contains m ore th an one starting node is also inconsistent. W hen 1 m ultiple starting nodes are specified for a node then it is im possible to determ ine i at which node execution is to begin. Figure 4.3 shows an inconsistent IRG whose : l parent has m ultiple starting nodes (B and D). One other problem th a t can arise is when a designer specifies a node as a 1 startin g node and th a t node is defined inside a group and a window. W hen this j happens th e designer has to be explicitly asked w hether th e startin g node should be applied to the group or window. 4 .1 .4 M u ltip le Ite m s W ith th e S a m e N a m e N am ed item s can also be a source of inconsistencies. Item s appearing in the same window can not be given the sam e nam e or th e two item s will becom e confused w ith each other. An exam ple of this problem is when defining a series of fram es and the designer gives th e sam e nam e to two different frames. If this should happen, the system would not be able to differentiate between the two fram es and would not know which to use in th e definition of sequences and other item s. D uplicate nam es of item s can occur as long as they occur in th e context of separate windows. This helps w hen copying windows (and th eir contents) for such purposes as defining j m ultiple concurrent identical objects w ith out having to change all nam es of the objects involved. If conflicts do arise, the nam es will have to be fully qualified, giving th e list of windows and subwindows th e item appears in, m uch like giving the full p ath nam e of a file in a hierarchical file system . T he way one can tell if a duplication of nam es will result is by checking if b o th item s have the sam e fully qualified nam es. Only nodes need to have unique nam es. Sequences are attached j I to nodes so there are no conflicts since th e node has to be identified before the sequence can be. ! 4 .1 .5 In te r se c tin g G rou p s W ith th e S a m e E v en ts If two groups intersect each other then there can not be transitions w ith identical events coming from the two groups. If there is, then when control is in th e inter- 1 section of the group and th e identical event occurs, it can not be determ ined which group is th e source. This is sim ilar in n atu re to a node having m ultiple transitions i w ith identical events. An exam ple IRG having this problem is shown in figure 4.4. , In this exam ple, group B contains node F, G and H while group C contains nodes , F, I and J. If the interface should ever be in node F when event help occurred, it j could not be determ ined w hether to give control to node J or I. I 4 .1 .6 In c o m p a tib le T y p e s on D a ta C o n stra in ts a n d Sharedj D a ta J D ata constraints betw een attrib u tes of two interface objects or shared d a ta betw een j an interface object and application m ust be of sim ilar types. In th e case of d ata { constraints it doesn’t m ake m uch sense for th e position of one object to be d ire c tly' dependent on th e color of another object. If there exists a dependency betw een I incom patible d a ta types, then a transform ation equation or function m ust be sup plied by th e designer. W ith shared data, th e application m ust be re ad in g /w ritin g : 168 A help help Figure 4.4: Two intersecting groups w ith identical events. 1691 _ _ _ i values th a t are com patible w ith th e a ttrib u te of th e object th a t is reading/w riting th e data. 4 .1 .7 In h e r ite d N o d e s Nodes th a t are defined to be inherited m ust be defined in a context in which there is some object to inherited them . For exam ple, if an inherited object, such as a b u tto n , is defined inside a fram e, there is nothing to inherit it. Instead it m ust be . defined to be inherited to a group of fram es or inside a window w here th e object : is inherited by all th e fram es appearing in th e group/w indow . 4.2 Completeness For a specification to be com plete no p art of it can be left unfinished. T he differ- ■ ence between an inconsistent and incom plete specification is th a t in an inconsistent j specification one p a rt disagrees w ith another while if it is incom plete then a d d i-; tional inform ation is needed for it to be understood. A specification is usually in an incom plete form u ntil th e entire interface and underlying functions have been specified. Inform ation on w hat p a rt of th e specification is incom plete is im portant to designers so th a t they know w hat is left to finish. An IRG can be incom plete in th e following ways: j • Nodes defined w ith no interaction. j • No start node in a parent node. • Transitions m issing events. • Internal broadcasts m issing counterparts. i • Transitions m issing either a source or destination. • Indexed transitions m issing an index. • R untim e nodes m issing a program statem ent. ! These item s are all results of th e designer leaving th e specification w ith in co m p lete; inform ation to be understood. 1701 I 4*2.1 N o d e s W ith N o In te r a c tio n W ith a few exceptions, m ost nodes should be a t least a source or a destination of a transition. Being a source or destination of a transition indicates th a t the object is involved w ith some type of interaction. A node w ith no transitions entering or leaving it m eans the node is never given control and th e node cannot transfer I control or m odify th e interface. W ith th e exception of a few nodes, all nodes should I l have some ty p e of interaction defined for them . If they do not, chances are th a t | they have been incom pletely defined. T he following subsections describe object, fram e, group, and window nodes and how they can be incom plete. I O b je c t N o d e s | O bject nodes, which represent interaction objects such as buttons, should have : a transition leaving them (source) representing an action to take w hen th e user interacts w ith the object. An exam ple is when a b u tto n is pressed a help window ! m ay need to appear. O bject nodes are not th e destination of transitions since | objects are grouped into fram es and th e fram es are the destinations of transitions, i Exceptions to this rule are objects like labels and read only tex t which by their J definition do not accept user inputs. In these cases there cannot be any transitions ' leaving them since they cannot accept inputs. F ram e N o d e s ! All fram es m ust be the destination of a transition. If a fram e does not have > i any transitions going to it then th e fram e will never be displayed. Therefore any j fram e node th a t is not th e destination of a transition is an orphan and incom plete, j In addition to being the destination of a transition, fram es also need to contain interface com ponents. W ith out any interface objects, there is no way th a t control i can be transferred out of the fram e. In th e case of subfram es, an em pty su b fram e! causes no m odifications to an existing fram e, so it also m ust be incom plete. j G rou p N o d e s T he reason for th e existence of groups is to either m ake th e group th e source of a divergence, define a common attrib u te, or define an inherited node. If none of these are defined for a group node then there is no reason for its existence, and therefore is incom plete. I W in d o w N o d e s ' W indows can be defined to be either initially visible or invisible. If it is defined to be invisible, then control can not be transferred to it im plicitly by m oving the cursor to it. Because of this, windows th a t are defined to be initially invisible m ust be destinations of transitions so th a t they can gain control and be m ade visible. ! Any windows th a t are defined as being initially invisible and are not th e destination of a transition and are incom pletely defined. W indows are also incom plete if they j I do not contain at least one fram e. If they do not, then there is no interaction possible in the window. I 4 .2 .2 N o S ta rt N o d e in a P a ren t N o d e j i If a parent node is nam ed as a destination of a transition, then one of the parent ( node’s subnodes m ust be defined as a start node, otherw ise there is no way to determ ine th e next node to receive control. If this occurs to a node th a t is a window, then the next fram e of the user interface cannot be determ ined. This type of incom pleteness can occur when: • Control is defined to transfer to a window, b u t a sta rt node is not specified. • Control is transferred to a group b u t a sta rt node is not defined. j An exam ple of this type of incom pleteness is shown in figure 4.5 where transition | x has the parent node A as a destination node, b u t non of th e nodes, B , C or D ; i are defined as startin g nodes. W hen executing th e user interface, if control ever i reached node A th e next node could not be determ ined and execution would have j i to stop. I 1 72 ! Figure 4.5: Incom plete IRG where a parent node does not specify a child as a start j node. [ f 4 .2 .3 In c o m p le te T ra n sitio n s For a transition to exist, a t least a source node, destination node, and event m ust j be specified. At a m inim um , a transition will contain these th ree parts, if any are j missing, then the IRG is incom plete. M issin g E v en ts i i If an event is m issing from a transition then it is im possible to determ ine when : th a t transition can be taken. This is a form of incom pleteness because it does not j create an am biguity since there is no conflict, and is probably an oversight on the p art of th e designer. T he other possibility for a m issing events is if it is specified j as a retu rn value from a user w ritten function and th e function is never w ritten, thus causing th e specification will also be incom plete. I i M issin g S o u rce or D e stin a tio n N o d e s R P P forces sequences to be defined w ith sources and destinations at definition tim e. However, a sequence can lose a source or destination if either is deleted at a later tim e. This would then cause th e sequence to becom e incom plete due to a missing node. 173 C h eck in g for In c o m p le te T ra n sitio n s Checking for incom plete transitions consists of checking if sufficient inform ation has been given so th a t at execution tim e it can be determ ined w hether th e transition should be taken given an event. T he inform ation th a t could be m issing from a transition are: • A source node. • A destination node. • An event. • An action. Conditions are not essential because th e transition could have been specified to be taken under any condition given a specific event (the null condition). If a transition is m issing a source or destination node it will be evident from an inspection of the transition definition in the d ata dictionary. Every transition in th e d a ta dictionary ! j has a reference to th eir source and destination node and this entry will be NULL j if one of these item s is missing. W hile each of th e transitions are being checked j for source and destination nodes they can also be checked for th e existence of an I event and action th a t is associated w ith them . If either th e event or action value ! i in the dictionary is em pty, the transition should be flagged as incom plete. j i 4 .2 .4 In c o m p le te In tern a l B ro a d ca sts I Internal broadcasts are incom plete if: j I • A broadcast is specified in an action and a corresponding broadcast variable | is not defined as an event somewhere else. • A broadcast variable is defined as an event in one place and not broadcast during an action someplace else. T he following discusses each of these cases further and describes how such co n d i-: tions can be detected. 174! In tern a l B r o a d c a sts A s A ctio n s W ith o u t C o rresp o n d in g E v en ts i If an internal broadcast is listed as an action on a transition b u t there does not exist a corresponding event w ith the nam e of th e broadcast, then th e broadcast i has no effect on the interface. In this case, either: • T he specification has been over specified by adding useless actions. • T he specification has been underspecified by the designer leaving I th e broadcast out on a transition. Chances are th a t the second case is tru e and th e designer forgot to add th e broad cast as an event. ( I In tern a l B ro a d ca sts A s E v en ts W ith o u t C o rresp o n d in g A c tio n s j An internal broadcast is specified as an event w ithout ever specifying th a t particu- j lar broadcast as an action then the transition will never be taken, which is a form of ; 1 incom pleteness. As above, either the broadcast is a result of an over specification \ i th a t includes a useless event or, m ore likely, it is an under specification w here th e ' designer sim ply forgot to add the broadcast {action someplace. ' C h eck in g for In c o m p le te In tern a l B ro a d ca sts i There are two cases where an internal broadcast can be incom plete. T he first type | is where an action makes an internal broadcast and there is not a corresponding j internal broadcast listed as an event of a transition. T he second type is w here an internal broadcast is listed as an event on a transition, b u t is not broadcasted at any action. i To check for th e first type of broadcast incom pleteness (action has no event), all actions have to be searched for internal broadcasts and then all th e events have j to be searched for th e existence of th e broadcast. In all cases, all actions havel to be checked followed by the checking of all events. In m ost instances, not a ll' of the events will have to be searched though. If all th e internal broadcasts are j I found before the last event is searched then th e search can be halted early. In t h e ; worst case all th e events will have to be searched because th e last event checked 175 I will contain one of th e broadcasts. In the best case, th ere will be a search for only one internal broadcast and it will be found in th e first transition checked. In th e average case though, all the actions will have to be checked and only half the events. To check for th e second type of incom pleteness of internal broadcasts th e reverse j I of the above procedure is perform ed. All events m ust be checked for internal I broadcasts, then all actions need to be checked for th e existence of broadcasts listed as events. T his is th e reverse of the first type of incom pleteness and has a worst case where all events have to be searched (to find all broadcasts) and then all actions have to be searched before finding every broadcast. T he worst case is the ; I sam e as the above w here all events and actions have to be checked, and the average j J case is the converse of th e above case, where all the events have to be checked and , j I half of th e actions have to be checked. W hen checking for th e two types of incom pleteness, if th e above routines where executed separately, we would on the average have to check all th e events one and a half tim es and all th e actions one and a half tim es (th e sum m ation of each of th e > above average cases). This tim e can be cut by a th ird by checking for b o th cases ; at th e same tim e. This is done by: 1. Searching th e events and keeping a list of all th e broadcasts found. 2. W hen the actions are checked, all broadcasts are p u t on separate lists. 3. W hen all th e actions have been checked, th e lists are com pared. If the event and action lists are th e same, then there are no incom plete broadcasts j since all broadcasts found in th e events have a broadcast appearing in an action | as well as th e converse. If th e actions list is a subset of th e events list, then a ! broadcast was listed as an event th a t was not listed in a broadcast. If the events j list is a subset of th e actions list, then a broadcast was listed on an action th a t is j not listed as an event. T he tim e for checking both types of incom pleteness is th e j tim e to check all actions and all events, which is th e best case for sum m ation ofj th e best cases for checking both types of incom pletenesses separately. 176 | 4 .2 .5 In d e x e d T ra n sitio n s M issin g In d ice s Indexed sequences m ust contain a m ethod for calculating which node of an array of nodes will be given control. If there is no form ula, or function returning this value, then it is incom plete. This value can be checked at definition tim e for com pleteness, j If no index is given, then R P P does not allow th e definition. i 4 .2 .6 R u n tim e N o d e s M issin g P ro g ra m S ta te m e n ts R untim e nodes which call a user w ritten program to determ ine w hich fram e, win dow, or group will be given control next is incom plete when th e user w ritten pro gram is never provided. This value can be checked at definition tim e. If th e nam e J of a function is not given th en the definition is not m ade and an error given to th e ; designer. Existence and proper typing of the function can also be insured through j th e linker when th e generated code is linked w ith th e user defined functions. If j th e routine does not exist or is of the wrong type then th e linker will give an error J when linking the runtim e R P P system w ith the application routines. j 4.3 Checking for Consistency and Completeness of an IR G ! A designer can invoke th e consistency and com pleteness checker at any tim e while in , R P P and get a list of inconsistency and incom pleteness th a t exist in th e prototype. ; T he checker determ ines these errors and omissions by exam ining th e IRG th a t ■ represents th e prototype and looks for the inconsistencies and incom pletenesses ] described in th e preceding sections. ! T here are three tim es when inconsistencies and incom pletenesses can be checked: • As th e inform ation is entered by the designer. • A t any tim e during the specification. • A t runtim e. 177 T he rem ainder of this section describes the algorithm s th a t are used in th e checker at th e above tim es during the specification and the tim e com plexity of each of the algorithm s. 4 .3 .1 In te r a c tiv e C h eck in g for In c o n siste n c ie s ! M any inconsistencies can be determ ined at the tim e the designer enters th e infor m ation interactively. Even though these inconsistencies can be determ ined im m e diately at design tim e, th e designer m ay decide to th e inform ation at a later tim e. This m eans th a t th e inform ation m ay have to be checked outside th e context in which it was entered. Incom pletenesses are not checked interactively because an ; incom plete interface is th e norm as it is being prototyped. T he following describes j how each of the inconsistencies can be checked interactively. j I M u ltip le D e stin a tio n s T here are tim es when a designer needs to indicate destinations of a sequence in | separate orthogonal com ponents (parts of th e interface th a t are to run in paral- 1 lei). To interactively check for m ultiple destinations of a sequence in th e sam e ; orthogonal com ponent, the system only needs to do checks when the m ultiple des- ; tinations are entered. To check if th e designer gave m ultiple destinations in th e ! sam e com ponent the system does a depth first search (0 (n )) for each of th e nodes selected until each node is found. As th e depth first search is done the nam e of th e orthogonal com ponent is stored for each destination node as it is found. W hen all destination nodes are found their orthogonal com ponents are com pare to check for any com ponents th a t are the same, which is essentially a sorting problem th a t j takes 0 (m lo g m ) where m is the num ber of destination nodes and is bounded by n. [ \ T he entire search tim e then is 0(m lo g m ) + O (n) for a worst case tim e com plexity j of 0(nlogn). j Id e n tic a l E v en ts and C o n d itio n s ' AS noted above in section 4.1.2, m ost cases of identical events and conditions : m ust be checked at runtim e due to variable nam es being used to define events and i conditions. To check at design tim e for this inconsistency each tim e an event and condition is defined, the system com pares th e new event/condition to existing other event/conditions on sequences coming from the current node. If a lexical com pare is positive, then th e designer is notified of the problem . This also is a sorting problem and can be done in 0 ( s nlogsn), where sn is the num ber of sequences coming from node n. M u ltip le S ta r tin g N o d e s If a transition is a startin g node, this inform ation is stored in the nodes parent so when th e parent is given control, the starting node is easily found. Each tim e a starting node is defined, its parent is checked to see if a startin g node has already been defined. If there already exists a startin g node th en th e designer is informed. This takes a single com parison, or constant tim e , 0 (1 ), to do. M u ltip le Ite m s W ith th e S a m e N a m e M ultiple item s w ith th e sam e nam e only apply to item s in the sam e window. Item s in separate windows can be qualified by their window nam e. To check for this problem a binary search can be done on th e nam es of nodes in each window, j To search for a num ber would take O(logn) tim e, where n is th e num ber of nodes in an IRG. In te r se c tin g G rou p s W ith th e S a m e E v en t W hen a sequence is defined w ith a group of nodes as its source, it m ust be de term ined if th e group intersects another group and w hether th e two groups have identical events and conditions. To check for this a dep th first search is perform ed on the IRG and for each node contained in a group another depth first search is done to determ ine if th e node is contained in any other groups. If it is found th a t th e node is contained in at least one other group, th en th e node is contained in in tersecting groups. T he tim e to find all intersecting groups takes O (n), the num ber of nodes in an IRG. Once it has been determ ined th a t a node is in intersecting groups, th e events 179 and conditions of th e sequences coming from the group can be sorted. If there are any identical events/conditions it will be found during th e sort. T he sort will take O(slogs) where s is th e num ber of sequences in an IRG. T he to ta l tim e to check if a single node is in intersecting groups w ith identical events/conditions is 0 ( n + slogs)). T he tim e to check for all nodes is 0 ( n 2 + nslogs). In c o m p a tib le T y p es on D a ta C o n stra in ts an d S h ared D a ta W hen a d ata constraint or shared d a ta value is defined, th e types betw een the objects or o b je c t/d a ta m ust be com patible. An exam ple of an inconsistent d ata constraint would be if th e x coordinate of an object was dependent on th e back- I ground color of another object. If there is a dependency betw een an attrib u te of one object and an a ttrib u te of another object w ith a different type, th en a tran s form ation function m ust be supplied. This type m ism atch can be determ ined as soon as the constraint or shared d ata is defined by checking th e types of each ob ject involved. Conversions of some types (like integer to float) can be m ade, but others are inconsistent unless th e designer supplies a conversion function which gets com piled into C code. This check can be done in constant tim e, 0 (1 ). In h er ite d N o d e s W hen an inherited node is defined it m ust be defined as a sibling to nodes th a t j are legal to inherit it. Legal siblings are windows and fram es. To interactively check for this condition th e types of th e siblings on th e tree are com pared for com patibility. T he tim e to check a node’s siblings for com patible types would be 0(m ax(\W \, |F |) ), th e m axim um of th e num ber of windows and frames. 4 .3 .2 S ta tic C h eck in g As a designer enters th e specification for an interface, inconsistencies m ay occur b u t the designer m ay choose not to fix them at th a t tim e, b u t w ait and fix them at a later tim e. Due to this there m ust be algorithm s to check all inconsistencies and incom pletenesses at any tim e. T he following describes an algorithm to check an entire IRG for consistency and com pleteness at a single tim e. 180 C o n siste n c y T he consistency of an IRG can be checked during a depth first traversal, which takes 0 (n ) tim e, where each of the item s in section 4.3.1 are checked as follows: ' I 1 • during th e depth first traversal a t each node th a t has a sequence w ith m ultiple destination nodes, the nodes are checked to m ake sure they are in separate orthogonal com ponents, taking 0 ( n ) tim e a t each node. • for each sequence leaving a node th e events/conditions of each sequence are com pared w ith each of th e other sequences of th e node for a m atch which j takes O(slogs) at each node, where s is th e num ber of sequences coming from th e node. j • at each parent node m ultiple startin g nodes are check, which takes constant tim e, 0 (1 ). ] • if a sequence coming from a node has a destination of a group node, then j intersecting groups w ith the sam e events are checked, which takes 0 ( n + | slogs) tim e where s is th e num ber of sequences coming from a node. i • if a node is defined as an inherited node then th e tim e to check if its siblings : are of legal types is 0 ( m a z ( \W \, 1^1)). I • T he tim e to check for item s w ith th e sam e nam e is O (n), w here n is the I I num ber of nam es in the database, since duplicate nam es are flagged when j they are entered and are not unflagged until the duplicate nam e is deleted, j T he to tal tim e to check for consistency is 0 ( n 2 + nslogs). I C o m p le te n e ss j i To check for com pleteness of an IRG the nodes and sequences have to be checked ■ separately due to the fact th a t there m ay be orphaned nodes or sequences. S tarting J w ith th e nodes, a depth first search is done w here each node is checked for: 181; • If it is an object, it is checked for sequences leaving it. If it does not have any sequences then there is no interaction defined for th e object, a possible j incom pleteness (depending on th e type of the object). The to tal tim e to check each object is two com parisons, or constant tim e, 0 (1 ). • If it is a runtim e node, a program nam e m ust be associated w ith it. T im e to check is 0 (1 ), constant tim e. Total tim e to check for each of the above node incom pletenesses for each node is 0 (n ) tim e. Each sequence of th e IRG is checked for: j j • An Event defined for each of the sequence, taking 0 (1 ) tim e. , I • Source and destination nodes existing for each sequence, taking 0 (1 ) tim e. < • For each internal broadcast listed as an event, there exists a corresponding j event listed as an action. As internal broadcasts are found, either as events j i or actions, they are p u t on a list and m arked as events or actions. W hen a j corresponding event or action is found, the broadcast is m arked as com plete. At th e end of the completeness check, each of th e broadcasts on the list is check to be incom plete. To build and then check th e list takes 0(|&c|) tim e, w here |6C | is the num ber of broadcasts. • If a sequence is an indexed sequence, th en an index m ust be associated w ith it. T im e to check takes constant tim e, 0 (1 ). • To check for orphan frames or windows, as the sequences are checked, if the destination is a fram e or window, th en it is m arked as being a destination j (or a sta rt state). At the end, if there exists a fram e or window th a t is not th e destination of a sequence, then it is an orphan. For a window to be an orphan, it m ust not be a destination and it m ust have an initial definition of being invisible. T he tim e com plexity at each sequence is constant tim e, 0 ( 1). 182 The tim e com plexity to check consistency is 0 (n + s), th e tim e it takes to exam ine each of the nodes and sequences. T he tim e it would take to check both com pleteness and consistency would take 0 ( n 2 + nslogs). j 4 .3 .3 R u n tim e C h eck in g j Some inconsistencies dealing w ith identical events/conditions coming from the same node can only be checked at runtim e due to the use of variable nam es which are not bound till runtim e. These inconsistencies are checked by intercepting each event and checking each of th e sequences leaving a node to determ ine if it m atches m ore th an one. If it does, th e first sequence of th e list is taken and an error mes sage is printed. T he tim e to check for these inconsistencies at each step of the program is 0 { s ) tim e, where s is the num ber of sequences. T he to tal tim e spent | checking over the course of the program would be the sum m ation of the num ber of sequences of each of th e nodes visited, Yl(ni * l5i|) w here € N e w ith N e the set of nodes executed and ni is th e num ber of tim es th e node was executed. j C h a p te r 5 C o n c lu sio n In this thesis a m odel for specifying and a system for prototyping user interfaces was presented. T he m odel provides a m eans for representing a wide range of user interfaces and th e system provides a m eans for easily prototyping th e interfaces. T he following sections discuss th e contributions of th e interface m odel and the prototyping system presented here. 5.1 Interface Representation Graphs for M odeling User Interfaces Previous m odels for representing user interfaces have used tran sitio n diagram s, statech arts, algebraic m ethods, BN F, and high level languages. In m ost cases these system s worked well for com m and languages or sim ple m enu interface but did not work well for m ultiw indow graphical user interfaces. IRGs differ from these o th er m odels by providing: • a hierarchical stru ctu re for representing com ponents • a m echanism to group objects sharing common attrib u tes • a variety of flow of control m echanism s • a dataflow m echanism 184 • an inheritance m echanism T he following discusses each of these contributions. i J 5.1.1 H iera rch ica l S tru ctu re T he hierarchical stru ctu re of IRGs reflect th e n atu re of graphical user interfaces and provides a distinction betw een nodes th a t group item s together and nodes th a t represent objects of th e interface. Previous graph models have not typed nodes of th e interface b u t used them only to represent sta te inform ation. By providing type I inform ation in the nodes. A rray nodes provide th e ability to duplicate in terface; objects an arb itrary num ber of tim es during execution and runtim e nodes provide j ■ the ability to delay the definition of flow of control till execution. O ther special nodes, such as orthogonal nodes and history support some of the special needs of user interfaces like concurrency and diversions. I ! 5 .1 .2 G ro u p in g o f O b je c ts ! Groupings of objects into fram es and subfram es allows easy definition of sequencing I in th e interface. User defined groupings also allow objects w ith common attrib u tes, I flow of control, or common objects of a group to be defined once for th e entire group, thus supporting consistency across the interface. Grouping also allows diversions from th e m ain flow of control for help and error processing to be easily defined. ; ! 5 .1 .3 In h e r ita n c e j Inheritance allows th e visual and flow of control aspects of a persistent object (like a I | help butto n ) to be defined once for all parts of th e interface w here it appears. This also provides a centralized location for th e object definition so th a t m odifications only have to be m ade once instead of once for each occurrence of the object. 5 .1 .4 F lo w o f C o n tro l t Different types of flow of control between user interface objects is also available. T he m ajor difference betw een other state based system s is th e im plicit flow ofl I 1851 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : _i control betw een objects of th e interface. In addition, th e constrained flow of control allows order independent tasks to be perform ed before execution continues, and indexed sequences allow accessing m ultiple identical objects. If th e item is also an interface object, im plicit flow of control applies to all objects in th e array. 5 .1 .5 D a ta F lo w T he availability of a d ata flow indicator allows constraints betw een objects and shared d ata to be defined. T he constraints allowing p arts of one object to be dependent on another allows runtim e interaction betw een object to be defined w ithout having to interface w ith the application. T he shared d a ta provides a m echanism for specifying interaction betw een the interface and application which other state based models do not address. 5 .1 .6 C o n clu sio n Interface R epresentation Diagram s provide a richness in expressibility beyond pre vious m ethods. The im plicit flow of control betw een objects of th e interface reflects th e event driven n atu re of m any user interfaces, nodes are given types to reflect th e objects they represent, special nodes such as array and runtim e nodes reflect, dynam ic behavior of interfaces, interaction w ith the application can be defined,' constraints on th e flow of control allow complex sequencing to be defined, and constraints on d ata allow interaction betw een interface objects to be defined. 5.2 Reduced Programming Prototyper T he com plexity of m ost user interfaces today are such th a t a form al specification is very complex and should not have to be done by th e designer. R P P allows designers to interactively place objects on the screen in th e sam e m anner th at they will appear at execution tim e, define dialogue, and define th e interface to the application. As the designer prototypes the interface, a form al specification is also produced in th e form of an Interface R epresentation D iagram . This representation i can th en be compiled into executable code or printed to produce a specification; docum ent. T he prim ary objective of R P P is to reduce to a m inim um th e am ount of program m ing needed to produce a prototype and to also allow nonprogram m ers to | produce a functional prototype of an interface w ith out th e help of a program m er. ! R P P differs from other prototyping and specification system s in th e following ways: • Flow of control is specified interactively w ith out using a program m ing lan guage. • T he interface-application interface is defined interactive instead of through j th e application language or schem a language. j • A form al specification in th e form of an IRG is produced as th e interface j t specification. j I I I • A ttrib u tes shared betw een m any objects only need to be defined once. • P ersistent objects only need to be defined once. • C onstraints betw een objects are interactively defined. • Consistency and com pleteness of th e interface can be checked a t any tim e. • Removal of designer from formalism. i t 5 .2 .1 F lo w o f C on tro l Flow of control of the interface is based on th e fram es and subfram es of IRGS. I This allows th e designer to interactively define a series of screens, m odifications to j f those screens, and an ordering on the screens. O ther system s use a program m ing ! language to define th e sequencing. This prevents nonprogram m ers from specifying i th e dialogue and causes program m ers to learn another program m ing language. ; I 5 .2 .2 In terfa ce— A p p lic a tio n In terfa ce ! i T he interface between the application and user interface is defined by th e designer ' selecting th e d a ta they wish to send or receive. In this m anner th e designer does 187; not have to know w hat type th e d ata is or th a t how to stru ctu re it. A nd only the d a ta th a t is needed is passed to th e application, thereby providing protection from accidental m odification of other data. The applications program m er receives the d ata as a param eter to a function, but does not directly m odify it. I 5 .2 .3 F orm al M o d e l o f In te r a c tio n In other system s, either there is no form al specification defined at all or if there is one, th e designer works directly w ith the form al specification. R P P is driven by i i the IRDs b u t th e designer does not directly specify it. Instead, the designer works w ith th e interaction objects and R P P builds th e IRG for the designer. 5 .2 .4 S h arin g o f S p e c ific a tio n s I t O bjects th a t are to appear over a range of tim e can be defined once and then the designer interactively indicates the frames and windows th a t they are to appear in. M odifications only have to be done once to the single object to change all instances where it appears. | ! 5 .2 .5 C o n stra in ts ! Dependencies betw een objects of an interface are interactively defined by selecting attrib u tes of one object and defining a second o b ject’s a ttrib u te to be dependent on i th e first. T he system then produces as p art of its runtim e system code to m onitor th e values of th e dependent objects. No application code has to be w ritten to define these constraints, and since the inform ation is all obtained interactively, no j knowledge of th e underlying system needs to be known, and there is no need for a 1 program m er. ( 5 .2 .6 C o n siste n c y an d C o m p le te n e ss 1 Since th e interface is represented as a form al m odel (IR G ), consistency and com- j pleteness of th e m odel can be checked. This allows designers to determ ine when I I i 188 : i th eir specification does not m ake sense (inconsistent) and w hat p arts of th e inter face are not com pletely specified (incom plete). It was also shown th a t determ ina- j tion of com pleteness and consistency can be done in polynom ial tim e. 5 .2 .7 R em o v a l o f D e sig n e r From F orm alism Interface designers rarely have the background to understand com plex models of specification. W hat they know is w hat user interfaces should look like. Instead of th e designer having to concentrate on an abstract representation of th e interface, the direct m anipulation language allows them to concentrate on w hat they are the j m ost com fortable with: th e interface. 1 | i 5.3 Further Research A dditional research relating to Interface R epresentation D iagram s and the Reduced Program m ing P rototyper include: • restricting the types of user interfaces th a t can be developed • addition of m ultiscreen user interfaces | i • allowing the specification of actions to be dependent on tem poral inform ation. : T he rem ainder of this section will discuss each of these areas. , 5 .3 .1 R e str ic tin g D e v e lo p m e n t ' i R estricting the types of user interfaces to develop involves im posing a stan d ard on j th e appearance of the interface. These restrictions m ight include colors, positioning I of item s, display of dialog boxes, or enforcing certain configuration of com ponents J will always be used together (such as, there will always be a m enu b ar at the top of each window). In th e case of colors or positioning, adding these restrictions involves defining global values for certain attrib u tes. In the case of enforcing certain configuration of com ponents, a sam ple window (or other com ponent) needs to be 189 defined w ith th e optional item s attached. This definition of th e object is then displayed w henever the original item is asked chosen to be displayed. 5 .3 .2 M u ltisc r e e n W ith distrib u ted com puting, th e need for m ultiperson operation, and the imple- j m entation of com puter supported cooperative work, the capability to im plem ent m ultiscreen user interfaces arises. This capability could be added by treatin g a screen sim ilar to a window, b u t one level higher in the hierarchy of objects. Each of the screens would have to be defined separately (if using a single screen), caus ing th e definition of constraints and sequencing betw een screens to be defined by , toggling from one screen to another during definition. j 5.3.3 T em p o ra l S p e cifica tio n l I Tem poral constraints allow th e displaying of objects to be dependent on how fast | som ething was done. Such things are critical to games, air traffic control system s, j and com m and and control system s. T he tim e it takes for an object to move from ! one point to another or the tim e it takes for an operator to respond m ay effect how j som ething is displayed. These tim ings need to be added to th e specification and to the prototype. j l ! i I i 190 A p p e n d ix A R e q u ir e m e n ts D e fin itio n F o rm a ts T he following are two exam ples of requirem ents definition form ats. T he first is an outline of th e m ilitary standard system specification [42] and the second is an exam ple of a requirem ents definition of a fictitious book store check out system . A .l Military Standard 1. S co p e 1.1. Identification 1.2. Purpose 1.3. Introduction 2. A p p lica b le D o c u m e n ts 2.1. Governm ent Docum ents 2.2. Non-G overnm ent Docum ents 3. R eq u irem en ts 3.1. System Definition 3.1.1. Missions 3.1.2. T hreat 191 3.1.3. System Modes and States 3.1.4. System Functions 3.1.5. System Functional Relationships 3.1.6. Configuration A llocation 3.1.6.1. Functional and Perform ance Requirem ents 3.1.6.2. Requirem ents Cross Reference 3.1.7. Interface Requirem ents 3.1.7.1. E xternal Interfaces 3.1.7.2. Internal Interfaces 3.1.8. Governm ent Furnished P roperty List 3.2. System Characteristics 3.2.1. Physical Requirem ents 3.2.2. Environm ental Conditions 3.2.3. Nuclear Control Requirem ents 3.2.4. M aterials, Processes and P arts 3.2.5. Electrom agnetic R adiation 3.2.6. W orkm anship 3.2.7. Interchangeability 3.2.8. Safety 3.2.9. H um an Perform ance/H um an Engineering 3.2.10. Deploym ent R equirem ents 3.2.11. System Effectiveness Models 3.3. Processing Resources 3.3.1. C om puter H ardw are R equirem ents 3.3.2. Program m ing Requirem ents 3.3.2.1. Program m ing Language(s) 3.3.2.2. Com piler/A ssem bler 3.3.3. Design and Coding C onstraints 3.3.4. C om puter Processor U tilization 3.4. Q uality Factors 3.4.1. Reliability 3.4.2. M odifiability 3.4.2.1. M aintainability 3.4.2.2. Flexibility and Expansion 3.4.2.3. Availability 3.4.2.4. P ortability 3.4.2.5. A dditional Q uality Factors 3.5. Logistics 3.5.1. Support Concept 3.5.2. Support Facilities 3.5.2.1. H ardw are Support 3.5.2.2. CSCI Support 3.5.3. Supply 3.5.4. Personnel 3.5.5. Training 3.6. Precedence 4. Q u a lifica tio n R eq u irem en ts 4.1. General 4.1.1. Philosophy of Testing 4.1.2. Location of Testing 4.1.3. Responsibility for Tests 4.1.4. Qualification M ethods 4.1.5. Test Levels 4.2. Formal Tests 4.3. Formal Test Constraints 193 4.4. Qualification Cross Reference 5. P r e p a r a tio n For D e liv e r y T he scope section contains the identification num ber and th e nam e of th e sys tem , why th e system is being built and a brief overview of w hat th e system is to do. T he requirem ents section is the m ain p art of the system specification docu m ent. It first defines w hat mission it will be a p art of and w hat th re at it will guard I against. It then lists the different parts of th e system to be developed, th e states th a t each p art can be in, perform ance requirem ents and interfaces betw een parts and to the outside environm ent. C haracteristics of the system are th en specified indicating physical properties, w hat environm ent it will operate in (e.g., b a ttle field or com puting center), m aterials, m anufacturing processes, radiation requirem ents, and how effective it will be at its task. T he next section states th e processing requirem ent of th e system which includes th e com puting hardw are and software requirem ents. This is th en followed by reliability and m odifiability requirem ents, training th at will be needed for users, support, and personnel. T he system /segm ent specification ends w ith how the system is to be delivered. A .2 English Language A book store is installing an autom ated cashier system . T he new system will use bar code readers to read the code off of th e books and query a database of books in stock. T he database system will retu rn a book inform ation table th a t contains the book nam e, price, quantity in stock, stock level threshold and a reorder flag. The stock level threshold indicates the m inim um num ber of books in stock before they should be reordered. The reorder flag indicates th a t the book has been ordered. A fter th e product table has been retrieve from the database, th e product nam e and price are printed on th e cash register receipt, th e stock quantity is decrem ented and if th e in stock quantity is less th an or equal to the threshold value th e ordered flag is set. To to tal a custom er’s purchase th e to tal b u tto n is pressed which prints the sales to tal on th e receipt and a sta rt b u tto n clears th e register for th e next 194 custom er. Finally, on the last day of each m onth a report is generated from the sales inform ation th a t lists the num ber of each book sold and the total am ount of sales. 195 A p p e n d ix B R e q u ir e m e n ts S p ecifica tio n F o rm a ts T he following are outlines of the software requirem ents specification as stated in the m ilitary standard DI-MCCR-80025 [43] and the IE E E S tandard num ber 830-1984 [3]. B .l Military Standard 1. S c o p e 1.1. Identification 1.2. Purpose 1.3. Introduction 2. A p p lic a b le D o c u m e n ts 2.1. Governm ent D ocum ents 2.2. Non-Governm ent D ocum ents 3. R e q u ir e m e n ts 3.1. Program m ing Requirem ents 196 3.2. Design Requirem ents 3.3. Interface Requirem ents 3.4. D etailed Functional and Perform ance R equirem ents 3.5. A daptation Requirem ents 3.6. Q uality Factors 3.7. Software Support 3.8. Traceability 4. Q u a lifica tio n R eq u irem en ts 4.1. G eneral Qualification R equirem ents \ 4.2. Special Qualification Requirem ents 5. P r ep a r a tio n For D e liv e r y i The section on scope of the software specification covers th e software identifi-1 i cation num ber, the m ajor functions th a t the software is to perform and the role of the software in th e to tal system . The specification then covers relevant govern m ent and non-governm ent docum ents th a t are needed in im plem enting the system . I These can include m anuals, regulations, other specifications and drawings , N ext, the specification covers the requirem ents of th e software. T he program m ing requirem ents cover th e languages, com pilers/assem blers and standards th a t are to be adhered to. T he design requirem ents cover the any sizing constraints, tim ing betw een software, design standards to be followed and any other constraints on th e software design. The interface requirem ents refer to th e interface relation ships to other software or hardw are, the identification num bers of the interfaces, and exactly w hat how the com ponents are to interface. T he detailed functional and perform ance requirem ents lists all the functions of th e software and w hat th eir inputs, o utputs and algorithm s to accomplish th e function. T he ad aptation requirem ents list th e global variables th a t are used to set the current m ode, system param eters, and variables th a t set the lim its of operation. 197 The quality factors describe how close the im plem entation has to be to th e re quirem ents, how reliable it has to be, its efficiency, integrity, th e difficulty to learn th e user interface, m aintain, test, enhance, and port, and if th e software is to be reused. T he software support subsection specify th e equipm ent, software, person nel and training th a t are needed for the developm ent, operation and support of the software. T he qualification requirem ents specify how the software is to be checked to make sure th a t th e software requirem ents have been adhered to. Finally, th e preparation for delivery specifies on w hat m edia th e software is to be delivered on, and the labeling, packaging and handling directions th a t are to be followed during delivery. B.2 IEEE Standard 1. In tro d u c tio n 1.1. Purpose 1.2. Scope 1.3. Definitions, Acronyms, and A bbreviations 1.4. References 1.5. Overview 2. G eneral D escription 2.1. P roduct Perspective 2.2. P roduct Functions 2.3. User C haracteristics 2.4. General C onstraints 2.5. A ssum ptions and Dependencies 3. Specific Requirem ents 3.1. Functional R equirem ents 198 3.1.1. Functional Requirem ent 1 3.1.1.1. Introduction 3.1.1.2. Inputs 3.1.1.3. Processing 3.1.1.4. O utputs 3.1.2. Functional Requirem ent 2 3.1.3. Functional Requirem ent n 3.2. E xternal Interface Requirem ents 3.2.1. User Interfaces 3.2.2. H ardw are Interfaces 3.2.3. Software Interfaces 3.2.4. Com m unications Interfaces 3.3. Perform ance Requirem ents 3.4. Design C onstraints 3.4.1. Standards Compliance 3.4.2. H ardw are Lim itations 3.5. A ttributes 3.5.1. Security 3.5.2. M aintainability 3.6. O ther Requirem ents 3.6.1. D ata Base 3.6.2. O perations 3.6.3. Site A daptation 199 T he introduction p art of th e IE E E standard identifies th e intended audience of the specification, explain w hat the product will do, give pertinent definitions and the goals of the proposed system . In th e general description section an inform al description of the product, other products it interfaces w ith, its com ponents, func tions th a t the com ponents perform , the users of the system (if there are any), and any general constraints such as protocols or program m ing languages th a t are to be used. T he th ird section describes th e specific requirem ents of th e system . Due to th e size and com plexity of the specific requirem ents the IE E E standard gives four i different possible variations of this section. The variation used would depend on w hat best suited th e type of software being developed. T he Specific R equirem ents section starts out by giving each of the functional requirem ents. T he functional requirem ents are stated by giving the inputs, the processing of the inputs to be done and the outputs to be m ade. This is done for each of the functional units defined during requirem ents analysis. A fter all the functional requirem ents have been given, all the external interfaces are described. T he external interfaces include user interfaces, hardw are interfaces, software interfaces and com m unications interface (e.g., to a network). The perform ance requirem ents state such things as how m any users the system is to support, th e average response tim e, the average tu rn around tim e, size of databases. Design constraints cover the standards to be adhered to during th e developm ent, hardw are lim itations, and form ats of reports, to nam e a few. The attrib u tes section contains inform ation on the security of the system , m ean tim e betw een failure and m aintainability. The final section called “O ther R equirem ents” covers anything th a t has not already been covered in th e previous sections. Some of the things th a t m ay want to be covered here such as th e different m odes the system should operate in (e.g., novice and expert) or requirem ents of any database th a t needs to be generated or developed in conjunction w ith the system to be developed. 200 A p p e n d ix C E x a m p les o f U se r In terfa ce S p ecifica tio n s T he following are exam ples of user interface specifications using three different techniques. T he first technique transition diagram s, the second d a ta abstraction and th e th ird a tem plate technique. C .l Transition Diagram Specification An exam ple transition diagram of the user interface for a d ata dictionary system given by W asserm an in [69] is shown in figure C .l and the tex t th a t describes the messages to be printed are th e following: Actions 1 call startup 2 call shutdown diagram main entry setup exit x 201 help error J L <add> <modify> .select] start <delete> ca nodb <query> Figure C .l: Top-level USE transition diagram of d ata dictionary. tab t_0 15 tab t_l 20 message header cs,r2,cO,c_’USE Data Dictionary’ message lastline r$,cO,’Hit any character to continue.’ node setup node select tomark_A,ce,r-f3,t_0,’Please choose:’, r+ 2,t_l,’l: Add a dictionary entry.’, 202 r+ 2 ,t_ l,’2: Modify a dictionary entry.’ r+ 2 ,t_ l,’3: Delete a dictionary entry.’ r+ 2 ,t_ l,’4: Query d ata dictionary.’ r+ 2 ,t_ l,’help: Inform ation on use of program ’ r+ 2 ,t_ l,’quit: Exit U S E /D ata D ictionary’, r+2,t_0,’Your Choice:’ node help cs,r$-3,cO,’For more inform ation about a command, enter’, r$-2,c0,’the command num ber, press return and then type ’’help” or r$,cO,’Hit any key to continue’ node nodb cs,r$,cO,’Could not open database directory’ node start header ,mark_A node x cs node error 1 r$-l,cO,rv,bell,’Please type a num ber form 1 to 4 .’,sv, lastline The diagram starts at the “setup” node which does not display anything and the plus sign indicates th a t no input is needed to do th e next transition. T he arc leading out of the node “setup” executes sem antic action num ber two and if the results of it or “ok” it goes to the start node otherwise it goes to th e “nodb” node, displays an error message and then goes to th e exit node “x” w here th e screen is cleared. At the “s ta rt” node the message header is displayed and a m ark is set for future reference. From here we transition directly to the “select” node w ithout input w here a m enu is displayed. From th e “select” node th e next node we go to depends on the input from th e user. If “help” or “?” is typed then control is transferred to the help node where a message is printed and control is returned to 203 the “select” node as soon as th e user presses a key. If “q u it” or “q” is typed then th e sem antic action shutdow n is executed and control is again transferred to node “x” . If th e num bers ’1’, ’2’, ’3’ or ’4’ are pressed then th e functions add, modify, delete or query are done. These functions are shown in subdiagram s. Finally, if none of th e above com m ands are typed, then control goes to th e error node where the bell is rung and an error message is printed. C.2 Data Abstraction The following is an exam ple of an algebraic specification as given by Chi in [13] of th e Tandy PC-1 Tandy com puter line editor. Generator Functions 1. clear — » line 2. moveleft: line — > line 3. moveright: line — » line 4. insert: line — * line 5. delete: line — ► line 6. type: line x character — > line Inquiry Operations 1. curpos: line — > positiveJnteger 2. size: line — » ■ nonnegative_integer 3. eolchr: line — > character 4. content: line x positiveJnteger — > character 5. display: line x positiveJnteger — » character 6. blink: line — * ■ positiveJnteger U {NONE} A xiom s 204 1. curpos(clear) = lsize(clear)= 0 eolchr(clear)= “> ” content(clear,i)= IF i= l TH EN eolchr(clear) ELSE 2. curpos (moveleft(L)) = IF curpos(L )> 1 then curpos(L)-l ELSE curpos(L) content(m oveleft(L),i) = IF i < size(m oveleft(P)) TH EN content(L,i) ELSE IF i= size(m oveleft(L ))+l AND i=curpos(m oveleft(L)) TH EN eolchr(m oveleft(L)) ELSE 3. curpos (m overight(L)) = IF curpos(L) < size(L) TH EN curpos(L) + 1 ELSE curpos(L) content(m overight(L),i) = IF i < size(m overight(L)) TH EN content(L,i) ELSE IF i = curpos(m overight(L)) + 1 AND i = curpos(m overight(l)) TH EN eolchr(m overight(L)) ELSE 4. size (insert(L )) = IF curpos(L) < size(L) TH EN size(L) + 1 ELSE size(L) eolchr(insert(L)) = IF eolchr(L) = “> ” TH EN ELSE eolchr(L) content (insert(L),i) = 205 IF i < size(insert(L)) TH EN CASE i < curpos(L): content(L,i) i = curpos(L): “[]” i > curpos(L): content(L,i-1) ELSE IF i= size(insert(L ))+ l AND i= curpos(insert(L )) TH EN eolchr(insert(L)) ELSE 5. size (delete(L)) = IF size(L) > 0 AND curpos(L) < size(L) TH EN size(L) - 1 ELSE size(L) eolchr(delete(L)) = IF eolchr(L) = “> ” TH EN ELSE eolchr(L) content(delete(L ),i) = IF i < size(delete(L)) TH EN CASE i < curpos(L): content(L,i) i >curpos(L ): co n ten t(L ,i+ l) i > curpos(L): content(L,i+1) ELSE IF i = size(delete(L ))+ l AND i=curpos(delete(L )) TH EN eolchr(delete(L)) ELSE 6. curpos(type(L,c)) = curpos(L) -f- 1 size(type(L,c)) = IF curpos(L) < size(L) TH EN size(L) ELSE size(L )+ l eolchr(type(L,c)) = content(type(L ,c),i) = IF i <size(type(L ,c)) TH EN CASE IF i < size(type(L,c)) TH EN CASE 206 i < curpos(L): content(L,i) i = curpos(L): c i > curpos(L): content(L,i) ELSE IF i = size(type(L ,c))+ l AND i = curpos(type(L,c)) TH EN eolchr(type(L,c)) ELSE 7. display(L,i) = content(L,i) 8. blink (L) = IF curpos(L) < size(L) TH EN curpos(L) ELSE NONE T he first two sets of definitions (generator functions and inquiry functions) define w hat the inputs and outputs of the com m ands are. For exam ple, the moveleft function takes as input a line and returns a line as a result. T he axioms define the sem antics of th e functions which intern describes th e d ata abstraction (a line). Axiom 1 describes the behavior of th e function “clear” . It states th a t when the clear function is perform ed th e size of the line is zero, the current cursor position is 1, the end of line character is “> ” and th e line consists of th e end of line character in the first column and the rest of the line is blank. T he second axiom describes the “moveleft” function. It says th a t the cursor position is moved left one position unless it is in th e first colum n in which case it stays in the left column. It also states th a t the content of th e ith position of the line after th e move left function is just the same as th e content of the line before th e function was perform ed. T he m overight com m and is sim ilar to the move left com m and except th e cursor position is increm ented instead of decrem ented and th e cursor position is not allowed to move past th e end of line character. Axiom num ber four describes the insert function. It states th a t if th e cursor is to th e left of the end of line character then the size of the line is increased by one, 207 else if the cursor is under the end of line character then the insert is not done. It also states th a t if the end of line character is a “> ” before the insert function then it gets changed to Axiom four then goes on to to say th a t a place is opened up in the line at th e cursor position before the function was perform ed and th a t th e characters to th e left of the insert are the same characters to the left of the cursor position before th e insert and th e characters to the right of th e insert are th e characters th a t where under or to the right of th e cursor before the insert. The delete function is sim ilar to the insert com m and except th a t th e character under th e cursor is removed from the line and th e size of the line is decrem ented by one (again, if th e cursor is under the end of line character then nothing is done). Axiom five describes th e “type” function. This is the function th a t describes w hat happens to the the current line when the user types a character on the keyboard. It says th a t the current cursor position is increased by one, th e size of th e line is in increased by one if th e cursor is under the end of line character, the line size rem ains the same if the cursor is to th e left of the end of line (i.e., the character under th e cursor is overw ritten by th e typed character), the end of line character is changed to a the content of the line after th e function is perform ed is the same before it is perform ed except th a t the typed character has replaced the character th a t was under the cursor before the function was perform ed. j i Axioms seven and eight p ertain to the screen of th e display device. Axiom seven states th a t the line being displayed is th e same as the line being edited and axiom eight states th a t if the cursor is to the left of the end of line character then the character is to blink. C.3 Templates T he following is an exam ple of a tem plate specification of a report using th e KS- BASS m ethod [7]. The report th a t was generated using th e system is shown in figure C.3. Tem plates are produced by defining the tem plate headers and the d ata values th a t are to appear in the tem plate. T he tem plate headers th a t were used to define the report in figure C.3 is shown in figure C.3. In this exam ple th e text th a t is to appear in the tem plate is on the left and the d ata values th a t are to 208 be printed are shown on th e right in parenthesis. T he tem plates are defined in a hierarchical m anner using successor functions (see figure C.3). The successor functions defines how the tem plate hierarchy is broken down. In this exam ple it is shown th a t a division tem plate (DV) is m ade up of departm ent tem plate (D P) and th e division header always comes before the departm ent headers. It then goes on to give the break down of the departm ent tem plates into employees, ect. Logic can also be incorporated into th e tem plate hierarchy. For exam ple the successor of th e employee ID tem plate is dependent on th e value of th e m artial status of the employee. If th e employee is m arried then th e successor is th e DM tem plate, if he/sh e is divorced then the successor is the DD tem plate and if th e employee is single then there is no successor. 209 Division: Information science Division travel allotment 12000 Division travel used 5050 Travel money remaining 6950 * * *********************** * ****** **** ******* * * Department: Systems Departmental travel allotment 8000 Departmental travel used 3550 Travel money remaining 4450 % % $ 4 : sf: + * jjc afc sje % jf : $ * $ * sfc * * * $ sfc: % * * * * a|c * * % sf: * % * jf : * * * * $ sfc Name: Joe Smith Title: Programmer Status: single Travel allotment: 2000 Travel used: 2000 Name: Jack Jones Title: Department head Status: married Travel allotment: 4000 Travel used: 50 Date Married: June 5, 1977 Child: Jack Jr. Child: Jill * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * H e*** Department: Applications Departmental travel allotment 4000 Departmental travel used 1500 Travel money remaining 2500 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Name: Judy Smythe Title: Department head Status: divorced Travel allotment: 4000 Travel Used: 1500 Date Divorced: October 20, 1976 Child: Roger Figure C.2: Exam ple of a report generated w ith KSBASS. Element DV: Division: (DIV) Division travel allotment (TRAVALLOC) Division travel used (TRAVUSED) Travel money remaining (TRAVALLOC-TRAVUSED) Element DP: Department: (DEPT) Departmental travel allotment (TRAVALLOC) Departmental travel used (TRAVUSED) Travel money remaining (TRAVALLOC-TRAVUSED) Element ID: Name: (NAME) Title: (TITLE) Status: (MARSTAT) Travel allotment: (TRAVALLOC) Travel used (TRAVUSED) Element DM: Date Maried: (MARDATE) Element DD: Date Divorced: (DIVDATE) Element CH: Child: (CHILDNAME) Figure C.3: Tem plate for report. 211 SUCCESSOR FUNCTIONS AND GROUPING The successor of DV is always DP and DV groups over DP The successor of DP is always ID and DP groups over ID The successor of ID is DM if MARSTAT = ’married’ DD if MARSTAT = ’divorced’ and no successor if MARSTAT = ’single’ and ID groups over CH The successor of DM is CH if CHILDNAME is defined and no successor if CHILDNAME is undefined. DM groups over CH The successor of DD is CH if CHILDNAME is defined and no successor if CHILDNAME is undefined. DD groups over CH CH has no successor. Figure C.4: Successor functions for report definition. B ib lio g ra p h y [1] Alfred V. Aho, B rian W . Kernighan, and P eter J. W einberger. The A W K Programming Language. Addison-Wesley, 1988. [2] Mack W . Alford, R. P. Loshbough, and L. R. M arker. T he software require m ents engineering m ethodology: An overview. Software Series TRW-SS-80- 03, TRW Defense and Space Systems G roup, M ay 1980. [3] A N S I/IE E E S tandard 830-1984. IE E E Guide to Software Requirements Spec- j ification. A N S I/IE E E , 1984. [4] R. Balzer and N.. Goldm an. Principles of good software specification and im plem entation. In Conference on Specifications o f Reliable Software, pages 58-67. IEEE, 1979. [5] L. Bass, E .J. Hardy, K. Hoyt, R. L ittle, and R.C. Seacord. Introduction to th e serpent user interface m anagem ent system . Technical R eport C M E/SE I- j 88-TR-5, Carnegie Mellon University, Software Engineering In stitu te, M arch 1988. [6] Len Bass and Joelle Coutaz. Developing Software fo r the User Interface. SEI Series in Software Engineering. Addison-Wesley, Reading, M ass., 1991. [7] Leonard J. Bass. An approach to user specification of interactive display interfaces. IE E E Transactions on Software Engineering, SE-ll(8):686-698, AUGUST 1985. i [8] Thom as E. Bell and Thom as A. Thayer. Software requirem ents: Are they 213 really a problem ? Software Series TRW-SS-76-04, TRW Defense and Space Systems Group, July 1976. [9] B arry W . Boehm. Software engineering. Software Series TRW-SS-7-08, TRW Defense and Space Systems G roup, O ctober 1976. [10] B arry W . Boehm. P rototyping versus specifying: A m ultiproject experim ent. IE E E Transactions on Software Engineering, SE-10(3):290-302, M ay 1984. [11] Phillip Bruce and Sam M. Pederson. The Software Development Project. John W iley and Sons, 1982. [12] Luca Cardelli. Building user interfaces by direct m anipulation. In Proceedings o f the A C M S IG G R A P H Sym posium on User Interface Software, pages 152- 166. ACM, O ctober 1988. [13] Uli H. Chi. Formal specification of user interfaces: A com parison and evalua tion of four axiom atic approaches. IE E E Transactions on Software Engineer ing, SE -ll(8):671-685, August 1985. [14] M. H. Chignell and P. A. Hancock. An introduction to intelligent interfaces. In P. A. Hancock and M .H. Chignell, editors, Intelligent Interfaces: Theory, Research and Design, H um an Factors in Inform ation Technology, pages 1-22. N orth-H olland, 1989. [15] N ixdorf C om puter Engineering Corporation. X B uild User Guide. Nixdorf Corporation, 1990. [16] A lan M. Davis. A utom ating th e requirem ents phase: Benefits to later phases of th e software life-cycle. In C O M P SAC Proceedings, pages 42-48. IEEE, 1980. [17] Alan M. Davis. A com parison of techniques for the specification of external system behavior. Com m unications of the ACM , 31(9):1098-1115, Septem ber 1988. 214 [18] Stephen W . D raper and Donald A. Norm an. Software engineering for user interfaces. IE E E Transactions on Software Engineering, SE-ll(3):252-258, M arch 1985. [19] P eter Freem an. A perspective on requirem ents analysis and specification. In IB M Design ’79 Symposium. IBM , 1979. [20] D anny G oodm an. The Complete HyperCard handbook. B antam Books, 1987. [21] M. Green. R eport on dialogue specification tools. In G unther E. Pfaff, editor, User Interface M anagement System s, pages 9-20. Springer-Verlag, 1985. [22] John V. G uttag and J. J. Horning. Form al specification as a design tool. In Proceedings o f the Seventh Sym posium o f Programming Languages, pages 251-261. ACM, 1980. [23] David Harel. On visual formalisms. Com m unications o f the AC M , 31(5):514- 530, MAY 1988. [24] R alph Harrision. Prototyping and the system s developm ent life cycle. Journal o f System s M anagement, 36(8):22-25, A ugust 1985. [25] H. Rex H artson and D eborah Hix. H um an-com puter interface developm ent: Concepts and system s for its m anagem ent. A C M Computing Surveys, 21(1), M arch 1989. [26] John E. Hopcroft and Jeffrey D. Ullm an. Introduction to Autom ata Theory, Languages and Com putation. C om puter Science. Addison-W esley Publishing Company, 1979. [27] HP. U IM X User Guide, 1990. [28] Index Technology Corporation. Excelerator Reference Manual, 1987. [29] Inc. Integrated C om puter Solutions. The Builder Xcessory. Integrated Com p u ter Solutions, Inc., 1990. 215 [30] R obert J. K. Jacob. Using form al specifications in th e design of a hum an- com puter interface. Com m unications o f the A C M , 26(4):259-264, A pril 1983. , i [31] R obert J. K. Jacob. A state transition diagram language for visual program ming. IE E E Com puter, pages 51-59, August 1985. [32] R obert J. K. Jacob. A specification language for direct-m anipulation user interfaces. A C M Transactions on Graphics, 5(4):283-317, O ctober 1986. [33] W illiam R. M allgren. Formal specification of graphic d ata types. A C M Trans actions on Programming Languages and System s, 4(4), O ctober 1982. [34] W illiam R. M allgren. Formal Specification o f Interactive Graphics Program ming Languages. ACM Distinguished D issertations. T he M IT Press, 1982. j [35] M arilyn M. M antei and Toby J. Teorey. C ost/benefit analysis for incorpo- | rating hum an factors in the software lifecycle. Com m unications o f the A C M , 31(4):428-439, April 1988. [36] NeXT Systems Reference M anual. Interface Builder. NeXT Corporation, 1989. [37] R. E. A. Mason and T. T. Carey. Prototyping interactive inform ation systems. Com m unications o f the ACM , 26(5):347-354, May 1983. [38] R. E. A. Mason, T. T. Carey, and A. Benjam in. A ct/1: A tool for inform ation system s prototyping. A C M S IG SO F T Software Engineering Notes, 7(5):120— 126, December 1982. [39] Niels M ayer, Allan Shepherd, and Allan Kuchinsky. W interp: An object- oriented, rapid prototyping, developm ent environm ent for building extensible applications w ith the osf/m otif ui toolkit. In Xhibition ’ 90 Conference Pro ceedings, pages 49-64, May 1990. [40] Joel M cCormack, Paul Asente, and Ralph R. Swich. X Toolkit Intrinsics - C Language Interface. M assachusetts In stitu te of Technology and Digital Equipm ent Corporation, 1988. 216 [41] Joel M cCormack, Paul Asente, and R alph R. Swick. X Toolkit Intrinsics - C Language Interface. M IT Project A thena, 1988. [42] M ilitary S tandard DI-CMAN-8008. System /Segm ent Specification. D epart m ent of Defense, June 1985. [43] M ilitary S tandard DI-MCCR-80025. Software Requirements Specification. D epartm ent of Defense, February 1985. [44] M ilitary S tandard DOD-STD-216T. Defense System Software Development. D epartm ent of Defense, June 1984. [45] M ilitary Standard MIL-STD-483A. M ilitary Standard Configuration Manage m ent Practices fo r System s, Equipment, M unitions, and Com puter Programs. D epartm ent of Defense, December 1970. [46] M ilitary Standard MIL-STD-490A. M ilitary Standard Specification Practices. D epartm ent of Defense, O ctober 1968. [47] Chuch M usciano. Tooltool Reference M anual, 1988. [48] B. M yers, D. Giuse, R. D annenberg, B. V ander Zanden, , D. Kosbie, P. Mar- chal, E. Pervin, and J. Kolojejchick. The garnet toolkit reference manuals: Support for highly-interactive, graphical user interfaces in lisp. Technical R eport CMU-CS-89-196, Carnegie Mellon University, C om puter Science De p artm ent, November 1989. [49] B rad Myers. Creating User Interfaces by Demonstration. Academ ic Press, 1988. [50] John M. Nicholas. User involvement: W hat kind, how much, and when? Journal o f System s M anagement, 36(3):23-27, M arch 1985. [51] Norm an. User Centered Design. [52] Open Software Foundation, Eleven Cam bridge Center; Cam bridge, MA 02142. O S F /M O T IF Program m er’ s Guide, 1989. 217 [53] T im O ’Reilly, Varerie Quercia, and Linda Lamb. X W indow System User’ s Guide. O ’Reilly & Associates, Inc., 1988. [54] David L. Parnas. On the use of transition diagrams in the design of a user in- J terfacefor an interactive com puter system. In Proceedings o f the 24th National A C M Conference, pages 379-385, 1969. [55] Jam es L. Peterson. P etri nets. A C M Computing Surveys, 9(3):223-252, Septem ber 1977. [56] Roger S. Pressm an. Software Engineering: A P ractitioner’ s Approach. Soft ware Engineering and Technology Series. McGraw-Hill Book Company, 1987. [57] Phyllis Reisner. Formal gram m ar and hum an factors design of an interactive graphics system. IE E E Transactions on Software Engineering, SE-7(2):229- 240, M arch 1981. [58] G ruia-C atalin Roman. A taxonom y of current issues in requirem ents engi neering. Com puter, pages 14-21, April 1985. [59] C. Rose and K. L. Schoman. Inside Macintosh. Addison-Wesley, Reading, M ass., 1986. [60] W inston W . Royce. Software requirem ents analysis: Sizing and costing. In Ellis Horowitz, editor, Practical Strategies fo r Developing Large Software Sys tems, chapter 2, pages 57-71. Addison-Wesley Publishing Company, 1975. [61] Ben Shneiderm an. M ultiparty gram m ars and related features for defining interactive systems. IE E E Transactions on System s, M an, and Cybernetics, SMC-12(2):148-154, M arch/A pril 1982. [62] Ben Shneiderm an. Direct m anipulation: A step beyond program m ing lan guages. Computer, 16(7):57-69, July 1983. [63] Sm etherBarnes Incorporated. Prototyper Reference Manual, 1987. [64] Software G arden, Inc, Newton Highlands, M assachusetts. Dan Bricklin’ s Demo I I Program User Manual, 1987. 218 [65] Supoj Sutanthavibul. F IG - Facility fo r Interactive Generation o f Figures. U niversity of Texas at A ustin, M arch 1988. [66] R alph R. Swich and Terry W eissman. X Toolkit Athena Widgets - C Language Interface. M assachusetts In stitu te of Technology and Digital Equipm ent Cor poration, 1988. [67] TeleSoft, Inc. TeleUse User’ s Guid, 1989. [68] Steven W artik and A rthur Pyster. The “diversion” concept in interactive com puter systems specifications. In CO M PS A C Proceedings, pages 281-286, 1983. [69] A nthony I. W asserman. Extending state transition diaram s for th e specifi cation of hum an-com puter interaction. IE E E Transactions o f Software Engi neering, SE-11(8):699-713, August 1985. [70] A nthony I. W asserman, P eter A. Pircher, and David T. Shewmake. Build ing reliable interactive inform ation systems. IE E E Transactions o f Software Engineering, SE-12(1):147-156, January 1986. [71] A nthony I. W asserm an and David T. Shewmake. R apid prototyping of in teractive inform ation systems. A C M S IG S O F T Sortware Engineering Notes, pages 1-18, December 1982. [72] A nthony I. W asserm an and Susan K. Stinson. A specification m ethod for in teractive inform ation systems. In Proceedings, Specifications o f Reliable Soft ware, pages 68-79, April 1979. [73] Jam es W inchester. Requirements Definition and Its Interface to the SA R A Design Methodology fo r Computer-Based System s. PhD thesis, University of California, Los Angeles, February 1981. [74] P.C.S. Wong and E. R. Reid. User interface dialog design tool. Com puter Graphics, 16(3):87-98, July 1982. 219 [75] Raym ond T. Yeh. Requirem ents analysis - a m anagem ent perspective. In CO M PS A C Proceedings, pages 410-416. IEEE, 1982. 220

Abstract (if available)

Linked assets