tional Science Foundation Industry/University Cooperative Research Center ..... It opens a connection to the budget object using an object open call, which is ...
A Tour of the Suite User Interface Software PRASUN DEWAN Purdue University 3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 Suite offers high-level abstractions for developing both single-user and multi-user interfaces. An interactive application in Suite displays data structures to one or more users and asynchronously responds to user modifications to these data structures. Between each application and user is a dialogue manager, which offers the user an interface for manipulating displayed data. Dialogue managers and applications execute in separate address spaces, residing possibly on different computers, such as local workstations and remote hosts. Users and applications can customize several aspects of the user interface including how data are displayed, the kind of feedback given in response to user input, and how changes made by multiple users to a data structure are synchronized. An inheritance model offering both structural and type inheritance is provided for easing the task of customizing user interfaces. Typing is considered orthogonal to persistence, communication, and input/output, that is, a value of any type can be made persistent, communicated among applications, and input from and output to users. In this paper, we take the reader on a tour of the software, highlighting its distinguishing features. Categories and Subject Descriptors: C.2.4 [Computer-Communication Networks]: Distributed Systems—distributed applications, distributed databases; D.2.2 [Software Engineering]: Tools and Techniques—user interfaces; D.2.6 [Software Engineering]: Programming Environments—interactive; D.3.3 [Programming Languages]: Language Constructs—input/output; D.4.7 [Operating Systems]: Organization and Design—distributed systems; H.1.2 [Models and Principles]: User/Machine Systems—human factors; H.4.1 [Information Systems Applications]: Office Automation; I.7.2 [Text Processing]: Text Editing General Terms: Design, Human Factors, Languages Additional Key Words and Phrases: groupware, inheritance, distributed objects, persistence, structure editors, user interface management systems
3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333
1. INTRODUCTION Suite offers high-level abstractions for developing both single-user and multi-user interfaces. It is the successor of Dost [7], which was developed by the author at UW-Madison as part of his Ph.D. dissertation. Like Dost, Suite:
d
offers the abstraction of an ‘‘active value’’ or ‘‘active variable’’ —a program data structure displayed to the user whose display can be updated by the program to show results and the user to input values,
3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 Author’s address: P. Dewan, Department of Computer Sciences, Purdue University, W. Lafayette, IN 47907. This research was supported in part by National Science Foundation grant IRI-9015442 and in part by a grant from the Software Engineering Research Center at Purdue University, a National Science Foundation Industry/University Cooperative Research Center (NSF Grant No. ECD-8913133).
P. Dewan
d
Tour of Suite d 2
supports active variables of both predefined and programmer-defined types including enumerations, records, unions, pointers, arrays, and sequences (variable length arrays),
d
places between each application and user a dialogue manager, which displays the active variables of the application, provides a generic user interface to edit active variables, and invokes asynchronous procedures in the application to inform it of user changes to its active variables,
d
associates each active variable with a large number of predefined I/O properties called attributes,
d
provides an inheritance model based on IS-A inheritance to reduce the effort required to specify values of attributes.
In addition, it supports:
d
loose physical coupling between an application and its dialogue manager, that is, execution of these components in different address spaces, residing possibly on different hosts,
d
a language-independent dialogue manager,
d
graphical presentations of data structures,
d
a flexible input model that allows users to choose when their changes to active variables are checked for syntax and semantic errors and transmitted to the application,
d
IS-PART-OF inheritance in the inheritance model,
d
shared active variables, that is, active variables that multiple users, interacting possibly from different workstations, can view and modify,
d
a new architecture for handling multi-user input/output that combines useful properties of both the centralized and replicated architectures proposed by other researchers.
Suite has been implemented on a network of workstations executing UNIX, TCP/IP, X [25], and NFS [24] It uses X for displaying windows, and TCP/IP and NFS for communication among and naming of applications and dialogue managers. In other papers, we describe in detail some of the individual aspects of Suite and compare them with related work [8, 10, 11]. In this paper, we take the reader on a tour of the Suite software, emphasizing how its various components work together and how they can be used to build user interfaces. We use the example of a project management tool we have built for managing some of the activities of the Purdue-Florida Software Engineering Research Center (SERC). The tool consists of three applications: a project manager, which allows addition of new projects; an affiliate manager, which allows addition of new affiliates; and a budget manager, which maintains budgetary information including the contribution of each affiliate and the money allocated to each project. These applications communicate with each other and their dialogue managers to keep their data and displays consistent. We first describe an example session with the tool, illustrating the system from the point of view of end-users. Next we explain how the tool is implemented, illustrating the system from the point of view of application-programmers. Finally, we illustrate facilities provided by Suite for specifying properties of the user interface. These can be used by application-
Tour of Suite d 3
P. Dewan programmers to define an initial user interface and end-users to customize it. 1.1. User Interface Creating Suite Applications
A user creates a Suite application by using the UNIX command interpreter to execute a Suite application program. Suite applications communicate with each other using messages—therefore we refer to them as objects [28]. Unlike objects supported by several other object-based systems including Smalltalk and Dost, these objects execute in separate address spaces, residing possibly on different hosts. Each object is associated with an ASCII name, which is used by other objects to communicate with it. This name is a file name in a hierarchical network file system [9] and is given at object creation time as an argument to the application program executed by the object. Thus, a user can execute the commands cd /u13/rxc/proj/demo/serctool budget -name my_budget & projects -name my_projects -budget my_budget & affiliates -name my_affiliates -budget my_budget & to create in the directory /u13/rxc/proj/demo/serctool, budget, project, and affiliate objects named my_budget, my_projects, and my_affiliates, respectively. The -budget argument is specific to the project and affiliate objects and tells them the name of the budget object. This name is used by the two objects to open connections to the budget object. Coupling Dialogue Managers and Applications In Suite, creating interactive applications does not automatically create user interfaces for them. User interfaces of interactive applications are created by objects called dialogue managers, which must be explicitly coupled to these applications. For instance, to interact with the budget object, we must create a dialogue manager for it: dm -name dm_budget & The dialogue manager displays a startup window, which can be used to connect it to an interactive object. Let us enter the name of the budget object in the Object field of the startup window and execute the Load command (Figure 1). In response, the dialogue manager loads the active variables of the budget object in the object window and provides a menu window for manipulating these values (Figure 2). Similarly, to interact with the project object, we create another dialogue manager and connect it to the object (Figure 3). Like other objects, a dialogue manager executes in its own address space, which may reside on a host that is remote to the application to which it is connected. For instance, in the example above, the budget object and its
Figure 1. Coupling a Dialogue Manager to an Application
Tour of Suite d 4
P. Dewan
Figure 2. The Budget Object
Figure 3. The Project Object dialogue manager reside on the hosts medusa.cs.purdue.edu and arthur.cs.purdue.edu, respectively. Thus, Suite supports loose physical coupling between applications and dialogue managers, which is a generalization of the widely-accepted practice of logically separating these components [15, 29]. It is in the spirit of network window systems such as X [25], which support loose physical coupling between an application and its window server. It allows users to access remote applications, since the dialogue manager and the application can execute on the local workstation and remote host, respectively. This separation may not seem useful in a system built on top of a network window system such as X, which allows the window server and application to execute on the local workstation and remote host, respectively. However, in comparison to a window server, a dialogue manager provides higher-level user interface abstractions, thereby allowing a greater amount of processing at the local workstation. As shown by Lantz and Nowicki [17], a high-level partitioning of services between the local workstation and the remote host is important when the two are separated by a slow network such as a wide-area network. As we shall see later, loose physical coupling between applications and dialogue managers can also be used to build a new kind of multi-user architecture.
Tour of Suite d 5
P. Dewan Input/Output Model
The object windows of Figures 2 and 3 show the active variables of the budget and project objects, respectively. The budget object window displays a budget record with fields that store information about the amounts allocated to projects and contributed by affiliates. Currently, no projects or affiliates have been assigned to the center, therefore the fields affiliate_contributions and project_allocations in Figure 2 are empty. The project object window displays a project template and an empty list of current projects. In Suite, the display of an active variable is ‘‘live’’ [14] and can be edited to input data. Like Dost, Suite provides a structure-editing interface to edit displays of data structures. For instance, it provides the Insert After command to insert elements into a list. Figure 4 shows the use of this command to add items into the personnel field of the first milestone of the new project. We now execute the Accept command to ‘‘commit’’ the template. In response, the dialogue manager reports syntax errors in the error window (Figure 5(a)). A user can click on an error message in the error window to ask the dialogue manager to highlight the error value. Figure 5(a) shows the result of clicking on the second error message. Let us correct the errors and execute Accept again. This time, the dialogue manager reports semantic errors, since the names of the persons entered by the user do not match the names of the principal investigator and student assigned to the project (Figure 5(b)). Let us enter correct names and execute Accept one more time. At this point, several changes to the display occur (Figure 6). The error message disappears from the error window of the project object. Moreover, in the object window of the project object, the new project is added to the list of current projects. Furthermore, the ‘‘dependent’’ fields of the project have been automatically computed for the user. For instance, the person_months_planned field has been computed based on the information in the personnel field. Similarly, the allocated, spent, and balance fields have been computed for the user. Finally, in the object window of the budget object, a new entry is made in the list of current project allocations, and the total allocated amount is recomputed.
Figure 4. Modifying the Project Template
Tour of Suite d 6
P. Dewan
(a) Figure 5. Syntax and Semantic Errors
(b)
In general, a dialogue manager does the following when the user executes the Accept command. It first begins a syntax phase, when, for each value whose presentation has been changed, it checks the presentation for syntax errors based on the type of the value, parses the value if it finds no syntax error, and marks the value as parsed. If it finds no error in the syntax phase, it begins a validate phase, when it checks each of the parsed values for semantic errors by invoking the validate procedure associated with the value, and if it finds no error, marks the value as validated. Finally, if it finds no error in the validate phase, it begins the update phase, when it commits each of the validated values by invoking the update procedure associated with the value, which can take (possibly irreversible) semantic actions such as updating the display of data structures and sending messages to other objects. A value is considered changed if it has been directly edited by the user or it is a parent of a changed value. Values are visited in postorder in each of these phases, that is, the children of a structure value are visited before their parent is visited. We refer to the feedback given by the syntax, validate, and update phases as syntactic, semantic, and update feedback, respectively. By executing the Accept command, we received the highest ‘‘degree’’ of feedback, since the system went through all three phases: syntax, validate, and update. It is possible to receive lower degrees of feedback. The Validate command goes through only the syntax and validate phases, while the Syntax commands goes through only the syntax phase. A user does not always have to explicitly execute a special command to receive feedback in response to a change to a value. Suite associates each active variable with the attribute, IncFeedbackScheme, which determines the kind of feedback implicitly given on each incremental change to the display of the variable. We can set this attribute to InputUpdate, InputValidate, InputSyntax, or InputDelay, to receive update, semantic, syntactic, or no feedback, respectively, on every incremental change. Suite also lets a user postpone feedback until the value has been completely edited. It associates each active variable with the attribute, CompletionFeedbackScheme, which determines the kind of feedback implicitly given on each completed change to the display of the variable.
Like
IncFeedbackScheme, this attribute takes the values
InputUpdate,
Tour of Suite d 7
P. Dewan
Figure 6. Commitment of Project Template InputValidate, InputSyntax, and InputDelay. In Suite, an incremental change to a data structure is made by executing the Increment operation and a series of incremental changes to the data structure are completed by executing the Complete operation. These two operations are abstract operations and must be bound to concrete commands provided by the editor used to modify the display of the data structure. The text and ‘‘bar’’ editors provided by Suite illustrate how this binding can be made. In the case of the text editor, insertion or deletion of a character in the presentation of a data structure is considered invocation of the Increment operation and movement of the insertion point away from the presentation of the data structure is considered execution of the Complete abstract operation. In the case of the bar editor, ‘‘dragging’’ the bar is considered execution of the Increment operation and ‘‘releasing’’ the bar is considered execution of the Complete operation. Our input model provides a flexible answer to an important question in user interface design: When should feedback be given in response to user input? Different systems/applications address this issue in different ways. For instance, a traditional application that reads input from a file gives all (syntactic, semantic and update) feedback after all input has been completely specified, while a structure-editor gives all feedback as soon as an individual change is
P. Dewan
Tour of Suite d 8
made. These two examples represent two extremes in the approaches to feedback taken by contemporary user interfaces: one gives batch feedback while the other gives incremental feedback. Both approaches are useful. Incremental feedback allows users to detect errors and compute results early, and is therefore increasingly being supported by recent ‘‘direct-manipulation’’ user interfaces [26]. On the other hand, the traditional approach of delaying feedback also offers benefits. It eliminates the overhead of incremental processing, thereby providing better incremental response time. Moreover, it prevents spurious (possibly irreversible) feedback when a user needs to make multiple changes to transform a value from one consistent state to another. Suite supports both feedback schemes. Returning to the example of the project object, we can set the feedback attributes of the active variables of the object to InputDelay to receive batch feedback and to IncUpdate to receive incremental feedback. Moreover, Suite extends the two feedback schemes in two ways: First, it allows feedback to be tailored to the data structure being modified. For instance, we can receive batch feedback while editing the project template (so that we do not commit the template on every change to it) and incremental feedback while editing the project list, by setting the values of the feedback attributes of the fields of the two data structures to InputUpdate and InputDelay, respectively. Second, it allows different kinds of feedback to be given at different times. For instance, we can choose to get syntactic feedback on incremental changes to the fields of the project template, semantic feedback on completed changes to them, and update feedback only on explicit execution of the Accept command, by setting their IncFeedbackScheme attribute to InputSyntax and the CompletionFeedbackScheme attribute to InputValidate. Multi-User Interaction It is possible for the dialogue managers of the different objects of our example tool to be created by different users, interacting possibly from different workstations connected by a (local or wide-area) network. For instance, the dialogue managers of the project and budget objects can be created by different users interacting from different workstations. The input of a new project template causes dialogue managers of both users to display new output (Figure 6). Thus, the example tool provides a multi-user interface, that is, a user interface that receives input from and display output to multiple users. Such interfaces are important since they allow automation of group activities, which are a large fraction of the activities carried out by professionals [6]. It is also possible for a particular object to interact with multiple users via multiple dialogue managers. To illustrate this feature, consider the affiliate object. Assume that two different users, user A and user B, have connected the dialogue mangers, dm_aff_A and dm_aff_B, respectively, to the object (Figure 7). Both users can edit the affiliate template to add a new affiliate and each sees every incremental change made by the other (Figure 8). Figure 9 shows what happens when user B commits the change made by A by executing the Accept command. The list of current affiliates displayed to both users is updated. Moreover, the list of affiliate contributions displayed to the user of the budget object is also updated. In this example, users A and B were tightly coupled while editing the template—each user saw every incremental change made by the other user. Suite also allows them to be completely uncoupled while editing the template. The two users can set the ValueCoupled attributes of their copies of the template to False if they wish to
Tour of Suite d 9
P. Dewan
Figure 7. Multiple Users Interacting with the Affiliate Object
Figure 8. User A Changes Template independently add affiliates (Figure 10). In addition, Suite supports several intermediate levels of coupling. It allows users to select when changes to values are broadcast and received, how correct a value must be before it is broadcast or received, which users see the same view of a value, and whether a user can specify coupling attributes for other users [11]. Multi-user interaction is also supported by other systems such as NLS [12] and VConf [18]. Suite differs from these systems in two important ways: First, the entities shared in Suite are active variables rather than screen images [12] or window images [18]. As a result, it is possible to use semantic properties of a value to determine how the
Tour of Suite d 10
P. Dewan
Figure 9. User B Commits the Change
Figure 10. Users A and B are Uncoupled copies of it displayed to different users are coupled. For instance, it is possible for a user viewing a variable to see only committed changes made by other users to the value of the variable. Moreover, it is possible to associate different coupling properties with different active variables displayed in a window. For instance, it is possible for users to share changes to the affiliate list but not the affiliate template (Figure 10), thereby allowing them to independently add affiliates to a single affiliate list. Finally, it is possible to associate different formatting, access, and other I/O properties with different copies of an active variable displayed to different users. For instance, it is possible to allow an affiliate representative interacting with the affiliate object to modify the entry for only his/her company. Second, Suite supports a multi-user architecture that offers benefits of both the centralized and replicated multi-user architectures supported by other works [18]. Under the centralized architecture, a single replication of a multi-user application communicates with its users. The input from each user is transmitted to the application, and the output of the application is broadcast to all the users. Under the replicated architecture, the application is replicated on all the workstations used by its users. The input from a user is is broadcast to all replications of the applications, but a replication produces output for only its workstation. The replicated architecture is expected to give better
P. Dewan
Tour of Suite d 11
response time, since, typically, the size of the input of an application is much smaller than its output, and thus broadcasting input in the replicated case is more efficient than broadcasting output in the centralized case [18]. On the other hand, it is not always possible to replicate applications. For instance, it is not possible to replicate the budget object if it prints cheques for project investigators when their projects are committed, since each replication of the object would print a copy of the cheque. The Suite multi-user architecture offers benefits of both architectures. It keeps the object centralized but replicates the dialogue managers of the object, which are responsible for displaying results to their users. The object is responsible for broadcasting the values of new results but not their (typically much larger) displays. For instance, when the budget object calculates a new value of the total_allocation field, it broadcasts only the value of this field to its dialogue managers. Each dialogue manager locally converts the value to its graphical representation. Like most of the other systems supporting multi-user interaction, Suite currently provides no concurrency control. We currently coordinate our activities using a multi-user ‘‘talk program’’ created using Suite and/or the telephone. Ending Interactive Sessions A user can stop interacting with an object by executing the Close or Quit command provided by the startup window of the dialogue manager (Figure 1). The former destroys the coupling between the dialogue manager and the object while the latter also destroys the dialogue manager. The object remains active if other users are still interacting with it. When all dialogue managers and other objects have closed their connections to it, the system passivates it, saving its persistent data on disk. Later, when a dialogue manager or another object tries again to connect to it, the system automatically activates it, restoring its persistent data from disk. Continuing with our example, if both users of the affiliate object execute the Close command, the object is passivated and the list of affiliates is saved on disk. Later, if user A executes the Load command to interact with one of these objects, the system automatically activates the object, restores its persistent state, and couples it with the dialogue manager. The user can resume interaction with the object without being aware of the fact that the object was passivated since the last time he or she interacted with it. There is, however, an extra delay in connecting to the object, which depends on the size of its persistent data. Our experience shows that this delay is imperceptible when the size of the persistent data is small [9]. 2. Programming Primitives Each one of the objects of the example tool executes a separate application program. Figure 11 shows an outline of the application program executed by the affiliate object. It is a C program containing special comments beginning with the words oc and dmc, called object and dialogue annotations, respectively, which are processed by the Suite object and dialogue compilers, respectively. Managing Session State
Tour of Suite d 12
P. Dewan
2222222222222222222222222222222222222222222222222222222222222222222 1 /*oc 1 1 1 Initiate with AffInitiate 1 1 Eternal affiliate, affiliates, budget_name 1 1 Activate with AffActivate 1 1 1 Passivate with AffPassivate 1 1 */ 1 1 /*dmc 1 1 1 Editable Affiliate, Affiliates 1 1 Load with AffLoad 1 1 1 */ 1 1 /* Declarations */ 1 1 1 ... 1 1 1 typedef struct { 1 char *name; 1 1 1 int planned, actual, balance; 1 1 1 Strings projects; 1 1 } Affiliate; 1 1 1 typedef struct { 1 unsigned num_affiliates; 1 1 1 Affiliate *affiliate_arr; 1 1 } Affiliates; 1 1
1
1 Affiliate new_affiliate; 1 Affiliates affiliates; 1 char *budget_name; 1 OBJECT *budget_obj; 1
1
1 1 1 1
1 1
1 1
1 void AffInitiate (argc, argv) 1 int argc; char *argv[]; 1 1 1 { 1 1 new_affiliate.name = "Super Research Company"; 1 1 1 new_affiliate.planned = 30000; 1 1 ... 1 1 budget_name = GetBudgetName(argc, argv); 1 1 1 AffActivate (); 1 1 1 } 1 void AffActivate () 1 1 1 { budget_obj = OpenObject(budget_name); } 1 1 1 void AffPassivate () 1 1 { CloseObject(budget_name); } 1 1 char *ValidateAffiliate(path, aff_ptr ) 1 1 1 char *path; Affiliate *aff_ptr; 1 1 { ... } 1 1 1 void UpdateNewAffiliate(path, aff_ptr ) 1 1 char *path; Affiliate *aff_ptr; 1 1 1 { ... } 1 AffLoad() 1 1 1 { ... } 12222222222222222222222222222222222222222222222222222222222222222222 1 Figure 11. The Affiliate Application Program The program does not have a main procedure. Instead, it has object handlers, which are specified by object annotations. The object annotation
P. Dewan
Tour of Suite d 13
Activate with AffActivate tells Suite that AffActivate is the activation handler. This handler is invoked whenever the object is activated. It opens a connection to the budget object using an object open call, which is like a file open call except that it returns an object descriptor instead of a file descriptor [8]. This descriptor is used to invoke procedures in the budget object. The annotation Passivate with AffPassivate tells Suite that AffPassivate is the passivation handler. This handler is invoked whenever the object is passivated and closes its connection to the budget object. The annotation Initiate with AffInitiate tells Suite that AffInitiate is the initialization handler. This handler is invoked when the object is first created and receives arguments supplied by its creator. It initializes the data structures of the object and opens a connection to the budget object. Finally, the annotation Eternal affiliate, affiliates, budget_name tells Suite that affiliate, affiliates, and budget_name are persistent data structures. These handlers give the application programmers high-level but flexible primitives for saving, restoring, and initializing the state of an interactive session. The programmer specifies only the names its persistent data structures— the task of saving/restoring them is automatically carried out by the system. It is not meaningful to save and restore data structures such as file and object descriptors that are valid only during a particular activation of the object. The passivate and activate handlers can be used to destroy and recreate such data structures. Finally, the initiate handler can be used to establish an initial session state. Defining Active Variables In Figure 11, the dialogue annotation Editable Affiliate, Affiliates tells Suite that variables of types Affiliate and Affiliates will be created as active variables. Suite uses this information to build tables that describe the structure of these types, which are used by a dialogue manager to display and parse values of these types. The annotation Load with AffLoad tells Suite the name of the load handler. This procedure is called whenever a dialogue manager is coupled to the object. An outline of the procedure follows:
Tour of Suite d 14
P. Dewan AffLoad() { Dm_Submit(&new_affiliate, "new_affiliate", "Affiliate"); Dm_Submit(&affiliates, "affiliates", "Affiliates");
Dm_SetAttr("Type: Affiliate", AttrValidateProc, ValidateAffiliate); Dm_SetAttr("Value: new_affiliate", AttrUpdateProc, UpdateNewAffiliate); ... Dm_Engage("new_affiliate"); Dm_Engage("affiliates"); }
The load handler invokes several procedures in the dialogue manager. It invokes Dm_Submit create the active variables, new_affiliate and affiliates, which store information about the affiliate template and affiliate list, respectively. The arguments of Dm_Submit specify the location, name, and type, respectively, of the active variable. It invokes Dm_SetAttr to define attributes of displayed variables. The first call defines the validate procedure for all variables of type Affiliate, while the second call defines the update procedure for the specific active variable new_affiliate. It also makes several other attribute definitions not shown here. Finally, it invokes Dm_Engage to ask the dialogue manager to ‘‘engage’’ the two active variables, that is, display them to the user. In this example, active variables were defines by the load handler. In general, any application procedure can dynamically create them, set their attributes, and engage them. For instance, the update procedure invoked in response to the addition of a new affiliate can set the ReadOnly attribute of the active variable to True and engage another active variable for adding a new affiliate, thereby allowing users to see the history of interaction. Suite Types The record type Affiliates simulates a sequence (variable length array) of type Affiliate. The first field of Affiliates keeps the size of the sequence and the second field points to an array that stores the elements of the sequence. When transmitting a sequence-simulating record as an argument to a remote procedure or saving it in persistent storage, Suite sends or saves, respectively, only as many elements of the array as are specified by the first field. Moreover, when displaying the record, it regards the record as a list and allows elements to be inserted into and deleted from the array field, updating the length field appropriately. In general, the system associates each value with a Suite type, which is the type that determines how the value is communicated to other objects, saved on backing store, and input from and output to the user. Suite types allow definition of a large set of data structures including integers, reals, characters, strings, enumerations, reals, records, discriminated unions, arrays, and sequences. The C type for the value is automatically mapped to a corresponding Suite type by the object compiler [8]. Thus, the C record type Affiliates is automatically mapped to a Suite sequence type with the same name. The distinction between Suite types and the types provided by the language used to code the program serves two purposes. First, it can allow the programmer to work with a richer set of types. For instance, it allows a C
P. Dewan
Tour of Suite d 15
programmer to work with sequences, which are used extensively in all the sample applications built by us, including the budget, project, and affiliate objects. Second, it provides a certain amount of language independence in the system. We can add a new language in the system by simply writing a new translator that maps types of the language to Suite types. We do not have to change, for instance, the dialogue manager, which works in terms of Suite types. Suite takes the approach of making typing orthogonal to persistence, communication, and input/output, that is, allows a value of any Suite type to made persistent, communicated to other users, and input from and output to the user. Traditionally, programming languages have not supported this facility, thereby requiring programmers to use special database management systems, communication packages, and user interface management systems for managing data structures that are persistent, communicated among applications, and input/output, respectively. These systems, typically, offer type systems that are different from the type system offered by programming languages and require the programmer to create multiple representations of data. Our approach is a generalization of the approach taken by recent database programming languages of making typing orthogonal to persistence [1]. It relieves a programmer from the ‘‘impedance mismatch’’ problem of converting among multiple representations of a data structure. Input/Output Here is the definition of validate procedure defined to validate values of type Affiliate: char *ValidateAffiliate( path, aff_ptr ) char *path; Affiliate *aff_ptr; { if (aff_ptr->planned < 30000) return ("Planned amount must be at least $30000."); if (aff_ptr->planned < aff_ptr->actual) return ("Planned amount less than actual."); return ((char *) 0); } It takes two arguments, the first is the path name of the active variable that was modified and the second is a pointer to its new value entered by the user. (The path name of a value is an ASCII name that uniquely identifies the value and can be used both by the application and its users.) The procedure checks the new value for semantic consistency and returns an error message if it finds an error. Here is the definition of the update procedure, UpdateNewAffiliate, which is called when the new template is committed by a user:
Tour of Suite d 16
P. Dewan
void UpdateNewAffiliate(path, aff_ptr ) char *path; Affiliate *aff_ptr; { int cur_aff_no; if (affiliates.num_affiliates++ < MAX_AFFILIATES) { cur_aff_no = affiliates.num_affiliates - 1; affiliates.affiliate_arr[cur_aff_no] = *aff_ptr; Dm_Update( "affiliates", "Affiliates", &affiliates); AddAffiliate ( budget_obj, *aff_ptr ); } } Like a validate procedure, it takes arguments specifying the path name and new value of the data structure modified by the user. It inserts the new affiliate in the affiliate list, calls the dialogue procedure Dm_Update with the new value of the affiliate list, and finally, calls AddAffiliate in the budget object to inform it of the new affiliate. A dialogue manager responds to Dm_Update by updating the value of the new variable. The validate procedure above is invoked when any user validates a new value of type Affiliate. Similarly, the update procedure is invoked when any user commits a new value of the affiliate. Finally, the Dm_Update procedure is invoked in the dialogue managers of all users interacting with the application. Thus, the application is unaware of the number and identity of the users interacting with it and can be used, for instance, both in the singleuser and multi-user mode. Composing Objects Figure 12 shows how the different objects of the Suite application communicate with each other. The affiliate and project objects invoke the AddAffiliate and AddProject procedures in the budget object to inform it of new affiliates and projects, respectively. The budget object updates its data structures appropriately and invokes
AddProject projects
AddAffiliate budget
affiliates
ValidateAffiliate
UpdateNewAffiliate
Dm_Update Dialogue Manager
Dialogue Manager
Dialogue Manager
Figure 12. Composing Objects
Dialogue Manager
Tour of Suite d 17
P. Dewan
Dm_Update to update the displays of its users. The project application program is like the affiliate application program except that it creates active variables for the project template and project list. The budget application program is structured a little differently and is outlined in Figure 13. Like the affiliate application program, it contains an initiate handler, which initializes the budget; and a load handler, which creates an active variable for the budget. It does not define activate or passivate handlers since it does not open files or objects, or validate or update procedures since the value of budget is read only by its users. It defines two external procedures, AddAffiliate and AddProject. The object annotation Method AddAffiliate, AddProject tell Suite that these two procedures can be called from other objects. The Suite activation/passivation scheme [8] allows a set of cooperating objects to be activated and passivated together. To illustrate this feature, consider the sequence of actions that takes place when the dialogue managers of the three objects close their connections to the these objects. The system passivates them since all references to them have been destroyed. Before passivating them, it calls their passivation handlers, which close their connections to the budget object, thereby causing its passivation. Now assume that a dialogue connects to the affiliate object. The system activates the object and invokes its activation handler, which causes activation of the passive budget object by opening a connection to it.
22222222222222222222222222222222222222222222 1 /*oc 1 1 1 Initiate with BudgetInitiate 1 1 Eternal budget 1 1 Method AddAffiliate, AddProject 1 1 1 */ 1 1 /*dmc 1 1 1 Editable Budget 1 1 Load with BudgetLoad 1 1 1 */ 1 1 /* Declarations */ 1 1 1 ... 1 Budget budget; 1 1
1
1
1
1 void AddAffiliate ( aff ) 1 1 Affiliate aff; 1 1 1 { ... } 1 int AddProject ( proj ) 1 1 1 Project proj; 1 1 { ... } 1 1 1 void BudgetInitiate () 1 1 1 { ... } 1 BudgetLoad() 1 1 1 { ... } 122222222222222222222222222222222222222222222 1 Figure 13. The Budget Application Program
Tour of Suite d 18
P. Dewan 3. Customization
In Suite, the user interface available to interact with an object has three main components: (1) a generic component shared by all user interfaces, which includes object-independent commands such as DeleteCharacter, names of object-dependent commands such as Insert After, and facilities such as buttons in the menu window for invoking (object-dependent/independent) commands, (2) a default object-specific component, which includes the default implementation of object-dependent commands and is ‘‘driven’’ by the type declarations in the program describing the object, and finally, (3) a customized component, which is customized by attributes of active variables. We have so far seen mainly the first two components. We have seen some examples of Suite attributes including the IncFeedbackScheme, ValueCoupled, and UpdateProc attributes. These attributes can be defined either by the object or its users. An object defines attributes using the SetAttr procedure and a user defines them using the attribute window (Figure 14(a)). Let us change an attribute of an active variable of the budget object. We enter the path of the active variable, the name of the attribute, and the value of the attribute in the Path, Attr, and Value fields, respectively, of the attribute window, and execute the Set command (Figure 14 (a)). The dialogue manager responds by using the ‘‘dialog widget’’ to display the variable (Figure 14(b)). Let us try the same process with some other attributes. Let us now change the BackgroundColor attribute of the variable budget.affiliate_contributions. The background shades of all the ‘‘bars’’ used to display descendents of this data structure change (Figure 15). This is because the Suite inheritance model allows a field to inherit attributes from its parent data structure. We can view the definition made directly for or inherited by a data structure by executing the Load or Inherit command, respectively. For instance, we can view the definition of the GraphicLength attribute made
(a)
(b) Figure 14: Changing an Attribute Definition
Tour of Suite d 19
P. Dewan
Figure 15: Structure Inheritance of Background Color for the total_allocation field by specifying the path of the field and the name of the attribute, and executing the Load command. The dialogue manager responds with the message that no attribute definition was directly made for the field (Figure 16(a)). We can now execute the Inherit command to find the definition for this attribute inherited by the field (Figure 16(b)). The inheritance model also lets a variable inherit attribute values from its type, as illustrated by Figure 17, which shows the result of changing the definition of the GraphicLength attribute of the type integer. In general, the inheritance model classifies data structures into several groups based on their types, contexts, siblings, ancestors, and other properties and allows an attribute to be defined once for all members of a group. It arranges these groups in multiple intersecting hierarchies and allows a subgroup inherit attributes from its supergroup(s). It defines several alternate rules for resolving multiple inheritance and allows users to choose among these rules [10]. The inheritance model relieves applications/users from specifying and the system from storing a large number of attribute definitions for each active variable. Currently, Suite supports about 50 predefined attributes, which are divided into several categories:
(a) (b) Figure 16: Finding an Attribute Definition
Tour of Suite d 20
P. Dewan
Figure 17: Type Inheritance of Graphic Length
d
Constraint Attributes: These attributes, together with the type of the variable, put constraints on its values. Examples of these attributes include the MinVal and MaxVal attributes, which determine the lower and upper bounds of a scalar value, and the MaxChar attribute, which determines the maximum number of characters in a string.
d
State Attributes: These attributes, together with the value of the variable, define its state. Suite defines two state attributes, Uninitialized and Erroneous, which determine whether the variable is uninitialized and erroneous, respectively.
d
Feedback Attributes: These attributes determine the kind of feedback given in response to changes to the variable and include the IncFeedbackScheme and CompletionFeedbackScheme attributes discussed before.
d
Access Attributes: These attributes determine the set of commands a user can execute on a variable and include the Selectable and Readonly attributes.
d
Callback Attributes: These attributes determine callback procedures, such as validate and update procedures, invoked in the application in response to invocation of editor commands on the variable.
d
View Attributes: These attributes determine parts of the value of the variable that are displayed. Currently, Suite supports only one view attribute, Elided, which determines if the components of the value are displayed or hidden. In the future, we plan to support view attributes that determine which components of a value are displayed.
d
Display Procedure: The GraphicWidget attribute determines the display procedure used to display the active variable. Currently, Suite supports a procedure that displays textual representations of arbitrary data structures and graphical procedures that display scalars as ‘‘bars’’ and ‘‘scales’’.
P. Dewan
d
Tour of Suite d 21
Formatting Attributes: These attributes determine the parameters of the display procedure used to display the variable. Examples of these attributes include the GraphicLength and BackgroundColor attributes. A formatting attribute may be used by more than one display procedure. For instance, the GraphicLength attribute determines the length of both the bar and scale used to display a scalar variable.
d
Coupling Attributes: These attributes determine which of the attributes of the copies of the variable displayed to different users are shared. An example of a coupling attribute is the the FormatCoupling attribute, which determines whether the format attributes of these copies are shared. Coupling attributes are described in detail in [11]. The notion of associating displayed data structures with customizable formatting attributes is supported in
several earlier systems including Xerox’s Star [27]. Suite generalizes this idea by associating a large variety of attributes with displayed data structures and allowing both users and applications to define values of attributes. As a result, it gives both users and applications great flexibility in specifying properties of the user interface. 4. CONCLUSIONS AND FUTURE WORK Suite has been used so far by 15 programmers at Purdue and Minnesota to create several prototype interactive applications including tools that allow users to edit system data structures such as line printers and process lists, a multi-user talk program, a multi-user debugging interface, a multi-user appointment service, a ‘‘visitor’’ scheduler that allows members of an organization to schedule meetings with visitors and view and manipulate information about them, an ‘‘expense service’’ that keeps the common expenditures of a group of users, a tool that allows multiple users to vote on issues, and a multi-user code inspector. Our initial experience with Suite has been mostly positive [9]. Programmers have benefited from almost all facilities provided by Suite, which is illustrated by the project management tool. The tool uses the facility of structured shared active values, attributes, type and structure inheritance, interobject communication, and so on. In the absence of system support for these facilities, programmers would be responsible for implementing them manually. Programmers have also benefited from a single language for describing both the internal data of applications and data that are saved on backing store, communicated among applications, and input from and output to users, since they have not been forced to use different languages, create multiple declarations of the same data structure, or convert among different representations of it. Moreover, since programs are written in a familiar programming language, they have been able to learn the system in a matter of days and use a mature programming environment. We have found it difficult to precisely characterize the class of applications that can benefit from a Suite-like system. The examples above show that Suite has applications in the areas of operating systems, office automation, accounting, and project management. It also has applications in software engineering since it can be used, for instance, to create multi-user structure-editors for programs, design documents, and requirements specifications. It can be used to create user interfaces for both data-intensive and computation-intensive applications, since it can display complex data structures, and trigger complex computations, possibly on remote sites, in response to changes to them. Suite is part of a response to a general need for reducing the effort required to implement interactive applications. It represents one approach to user interface software. While it offers several benefits such as high-level user
P. Dewan
Tour of Suite d 22
interface abstractions and integration with conventional programming languages, it does not support some attractive facilities offered by alternate approaches. For instance, unlike ThingLab [3], the Synthesizer Generator [23], and Pan [2], it does not support declarative specification of the semantics user interfaces; unlike the recent extension to ThingLab [4] and Perdiot [21], it does not offer interactive specification of the semantics of user interfaces; unlike UIDE [13], it does not support evaluation of the user interface or automatic help generation; unlike Chiron [29], GELO [20], and StarLite [5], it does not support programmer-defined display procedures; and finally, unlike toolkits such as the Smalltalk Model-View-Controller [16], Interviews [19], and the Brown Workstation Environment [22], it does not give programmers the flexibility to customize low-level user interface abstractions such as scrollbars and menus. We plan to extend our work in several ways. We intend to address issues in concurrency control, access control, and undo/redo raised by multi-user interfaces. We also intend to explore how the goals and designs of other approaches can be integrated with the goals and design of Suite. In particular, we plan to determine how I/O interfaces to lower-level software such as toolkits can be integrated with a Suite-like high-level I/O interface. Finally, we plan to do performance experiments to measure the effect of executing the dialogue manager and applications on different machines. Acknowledgments Eric Vasilik and Rajiv Choudhary implemented most of the current version of the Suite prototype. REFERENCES
[1]
Malcolm P. Atkinson and O. Peter Buneman, ‘‘Types and Persistence in Database Programming Languages,’’ ACM Computer Surveys 19:2 (June 1987).
[2]
Robert A. Ballance, Susan L. Graham, and Michael L. Van De Vanter, ‘‘The Pan Language-Based Editing System for Integrated Development Environments,’’ Proc. of 4th ACM Symp. on Software Development Environments, December 1990, pp. 77-93.
[3]
Alan H. Borning, ‘‘The Programming Language Aspects of ThingLab, A Constraint-Oriented Simulation Laboratory,’’ ACM Transactions on Programming Languages and Systems 3:4 (October 1981), pp. 353-387.
[4]
Alan H. Borning, ‘‘Defining Constraints Graphically,’’ CHI ’86 Proceedings, April 1986, pp. 137-143.
[5]
Robert P. Cook and Richard J. Auletta, ‘‘StarLite, A Visual Simulation Package for Software Prototyping,’’ Proc. of 2nd ACM Symp. on Practical Software Development Environments, December 1986, pp. 102-110.
[6]
T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams, Dorset House Publishing Co., New York, 1987.
[7]
Prasun Dewan and Marvin Solomon, ‘‘An Approach to Support Automatic Generation of User Interfaces,’’ ACM Transactions on Programming Languages and Systems 12:4 (October 1990), pp. 566-609.
[8]
Prasun Dewan and Eric Vasilik, ‘‘An Object Model for Conventional Operating Systems,’’ Usenix Computing Systems 3:4 (Dec 1990), pp. 517-549.
P. Dewan
Tour of Suite d 23
[9]
Prasun Dewan and Rajiv Choudhary, ‘‘Experience with the Suite Distributed Object Model,’’ Proceedings of IEEE Workshop on Experimental Distributed Systems, October 1990, pp. 57-63.
[10]
Prasun Dewan, ‘‘An Inheritance Model for Supporting Flexible Displays of Data Structures,’’ Software— Practice and Experience 21:7 (July 1991), pp. 719-738 .
[11]
Prasun Dewan and Rajiv Choudhary, ‘‘Flexible User Interface Coupling in Collaborative Systems,’’ Proceedings of the ACM CHI’91 Conference, April 1991, pp. 41-49.
[12]
D.C. Engelbart, ‘‘NLS Teleconferencing Features,’’ Proceedings of Fall COMPCON, September 1975, pp. 173-176.
[13]
James Foley, Won Chul Kim, and Srdjan Kovacevic, ‘‘A Knowledge-Based User Interface Management System,’’ CHI’88 Proceedings, May 1988, pp. 67-72.
[14]
Christopher W. Fraser and Balachander Krishnamurthy, ‘‘Live Text,’’ Software—Practice and Experience 20:8 (August 1990).
[15]
H. Rex Hartson and Deborah Hix, ‘‘Human-Computer Interface Development: Concepts and Systems,’’ ACM Computing Surveys, March 1989, pp. 5-92.
[16]
Glenn E. Krasner and Stephen T. Pope, ‘‘A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80,’’ Journal of Object-Oriented Programming 1:3 (August/September 1988 ), pp. 26-49.
[17]
Keith A. Lantz and William I. Nowicki, ‘‘Structured Graphics for Distributed Systems,’’ ACM Transactions on Graphics 3:1 (January 1984), pp. 23-51.
[18]
Keith A. Lantz, ‘‘An Experiment in Integrated Multimedia Conferencing,’’ Proceedings of Conference on Computer-Supported Cooperative Work, December 1986, pp. 267-275.
[19]
Mark A. Linton, John M. Vlissides, and Paul R. Calder, ‘‘Composing User Interfaces with InterViews,’’ IEEE Computer, February 1989, pp. 8-24.
[20]
Scott Meyers, Steven P. Reiss, and Carolyn Duby, ‘‘Using GELO to Visualize Software Systems,’’ Proceedings of the 2nd ACM Symposium on User Interface Software and Technology, November 1989.
[21]
Brad A. Myers, ‘‘Creating User Interfaces Using Programming by Example, Visual Programming, and Constraints,’’ ACM Transactions on Programming Languages and Systems 12:2 (April 1990), pp. 143-177.
[22]
Steven P. Reiss and John T. Stasko, ‘‘The Brown Workstation Environment: A User Interface Design Toolkit,’’ Proceedings of IFIP TC2/WG 2.7 Working Conference on Engineering for Human-Computer Interaction, Napa Valley, August 1989, North-Holland, 1990, pp. 215-232.
[23]
Thomas Reps and Tim Teitelbaum, ‘‘The Synthesizer Generator,’’ Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments, April 1984, pp. 42-48.
[24]
R. Sandberg, ‘‘The Sun Network File System: Implementation and Experience,’’ Proceedings of the Florence Spring ’86 EUUG Conference, 1986.
[25]
R.W. Scheifler and J. Gettys, ‘‘The X Window System,’’ ACM Transactions on Graphics 16:8 (Aug. 1983), pp. 57-69.
P. Dewan
Tour of Suite d 24
[26]
Ben Shneiderman, ‘‘Direct Manipulation: A Step Beyond Programming Languages,’’ IEEE Computer 16:8 (Aug 1983), pp. 57-69.
[27]
David Canfield Smith, Charles Irby, Ralph Kimball, Bill Verplank, and Eric Halsem, ‘‘Designing the Star User Interface,’’ BYTE 7:4 (April 1982).
[28]
Peter Wegner, ‘‘Dimensions of Object-Based Language Design,’’ OOPSLA ’87 Proceedings, October 1987, pp. 168-182.
[29]
Michal Young, Richard N. Taylor, and Dennis B. Troup, ‘‘Software Environment Architectures and User Interface Facilities,’’ IEEE Transactions on Software Engineering 14:6 (June 1988), pp. 697-708.
