A Guide to Suite - CiteSeerX

A Guide to Suite PRASUN DEWAN Purdue University 33333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 Suite is a software system being designed and implemented at Purdue. It supports remote procedure call, active persistent data, and management of ‘‘direct-manipulation’’ user interfaces— three (related) useful services missing from conventional systems. It is ‘‘integrated’’ with conventional systems in that its components are seamless extensions of corresponding components in conventional operating systems and programming languages. A prototype of the system is implemented on a network of workstations executing UNIX, NFS, and X. We have used the prototype to build several interactive applications and our preliminary experience has been encouraging. This report is meant for researchers interested in learning, using, and modifying the system. It motivates and outlines the main components of Suite, and describes how the prototype implementation may be installed and used. It uses the example of a project management tool to illustrate the various components of the system.

33333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333

1. Introduction The primary goal of Suite is to provide support for building direct-manipulation [11] or editor-based user interfaces in a distributed environment while retaining compatibility with conventional (U NIX-like) operating systems and conventional (Pascal-like) programming languages. Specifically, we intend to provide a system of uniform interactive editors that support editing of data structures described by the types of multiple conventional languages and residing on different nodes of a distributed system. The name of the system expresses this goal, since it is an acronym for ‘‘a System of Uniform Interactive Type-directed Editors’’. In order to build the system, we need the capabilities of remote procedure call [10] and active persistent data [9]. While some research had been done in these areas [1, 3], none of the existing systems are compatible with conventional operating systems supporting multiple conventional programming languages. Therefore, we have (somewhat grudgingly) undertaken the task of designing and implementing a ‘‘software suite’’ that also provides these capabilities. We have designed an initial version of the system that has several novel characteristics including a remote procedure facility that treats servers as files [4], a user interface management system that is integrated with conventional programming languages [7], an inheritance model for displaying data structures [8], and a generic high-level 33333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 Author’s address: P. Dewan, Department of Computer Sciences, Purdue University, W. Lafayette, IN 47907. This research was supported in part by the National Science Foundation sponsored Software Engineering Research Center at Purdue.

P. Dewan

A Guide to Suite d 2

uniform editor-based user interface [5]. We have also implemented a prototype version of the design on a network of workstations executing U NIX, TCP/IP, NFS, and X. We have used the prototype to build a wide range of distributed interactive applications including a calendar service, a project management tool, an editor of process-lists, and an editor of line printer queues. Our preliminary experience with the system has been encouraging and leads us to believe that the underlying concepts can be used to fill several gaps in conventional systems. We have written several reports and papers describing individual aspects of previous versions of Suite [4, 5, 7, 8]. In comparison to these publications, this report gives an overview of the complete current version of the system and describes the relationships among the three layers of the system. It also describes how the prototype implementation may be installed and used. It uses the running example of the project management tool to illustrate the various components of the system. It has been written for researchers interested in learning, using, and modifying the system. The remainder of this report is organized as follows. Section 1 gives an overview of the system, describing and motivating the individual components of the system and showing the relationships among these components. Sections 2, 3, and 4 describe support for RPC, persistence, and user interface management in Suite respectively. Section 5 describes three important programs provided by Suite: the object compiler, dialogue compiler, and object manager. Section 6 illustrates in detail the specific steps a user of the system needs to take to use the Suite prototype. Section 7 contains conclusions and directions for future work. Appendix 1 describes how the software may be installed, and finally, Appendix 2 contains UNIX man pages detailing the options to the various tools provided by Suite. 2. Overview Suite consists of three components: RPC, persistent memory, and user interface management. Suite RPC allows applications executing in different address spaces and possibly on different hosts to name and communicate with each other by calling high-level remote procedures [10]. Suite persistent memory consists of persistent applications whose data structures are saved on persistent storage. Unlike other means for storing persistent data such as persistent files and relations, persistent applications are ‘‘active’’ in that they can trigger actions in response to modifications to data. Finally, Suite user interface management is provided by dialogue managers, which display selected data structures of applications, provide users with a generic editor-based user interface to modify these data structures in a syntactically and semantically correct fashion, and allow the applications to trigger semantic actions (such as displaying results and communicating with other applications) in response to user changes to the data structures. Applications specify the display properties of displayed data structures, and a multiple-inheritance scheme is provided for specifying default values of these properties. Applications and dialogue managers can execute on separate computers on a network. Application programs describing Suite applications are traditional programs extended with constructs supporting remote procedure call, persistent memory, and user interface management. Suite applications can use all resources available to host applications including files and devices. Suite thus represents an evolutionary approach

P. Dewan

A Guide to Suite d 3

to system design, offering users several new facilities without requiring them to abandon ‘‘time-tested’’ components of conventional systems. Suite is also integrated with the host system (operating system and programming languages) in that several of the facilities offered by it are compatible with corresponding facilities offered by the host system. Moreover, the three main components of Suite are integrated with each other. For instance, naming of an application in which a remote procedure is to be executed is similar to naming of a file. Similarly, persistent and temporary data structures are described by the same set of types, thereby eliminating the ‘‘impedance mismatch’’ problem arising in translating between different representations of internal and persistent data structures [2]. Furthermore, displayed and internal data structures are also described by the same type system, thereby eliminating another kind of ‘‘impedance mismatch’’ problem that arises in translating between different representations of internal and displayed data. Not all facilities provided by Suite need to be used by an application executing in Suite. We refer to an application using none of the facilities provided by Suite as a traditional application, allowing remote procedure calls as a server application, whose data structures are saved on persistent storage as a persistent applicaion, and allowing data structures to be edited as an editable application. In Suite, an editable or persistent application must also be a server application. An application can be both editable and persistent. Suite is the successor of Dost [6], which was designed and implemented by the author as part of his dissertation work at the University of Wisconsin. The prototype implementation of Dost executed on the Mesa-based Xerox Development environment (XDE). Suite extends Dost with support for applications written in multiple languages including weakly-typed languages such as C, execution of applications and dialogue managers in separate protected address spaces residing possibly on separate hosts, remote procedure call, a multiple-inheritance sceheme for specifying default presentation of data structures, automatic translation between persistent and internal representation of data, and a user interface allowing user control over the degree of feedback. In this report, we highlight mainly those aspects of Suite that are unique to it. Several systems such as [1, 3] call persistent applications communicating with each other ‘‘objects’’, and the system on the whole ‘‘object-based’’. In other papers on Suite [4] we also have used the ‘‘object-based’’ terminology, but in this paper we do not to highlight the fact that unlike other object-based systems Suite is an extension of a traditional system and Suite applications and application programs are not dramatically different from their traditional counterparts. To illustrate the different components of Suite, consider the prototype project management tool we have built for managing some of the activities of the Purdue 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. This tool uses all three facilities provided by Suite. The affiliate and project managers use RPC to inform the budget manager about new projects and budgets respectively. Selected data structures of the applications such as the budget are persistent and are saved on disk. Finally, selected data structures of the applications such as the

A Guide to Suite d 4

P. Dewan

budget are displayed to the users who interact with these applications by editing visual representations of these data structures and viewing results displayed in response to the editing actions. The internal, persistent, and displayed data structures of an application are all described by a single set of type declarations in the application program. Figure 1 illustrates how the example tool uses the three facilities provided by Suite. 3. Remote Procedure Call Remote procedure call in Suite is supported by server applications. A server application is like a traditional application in that it is described by an application program declaring data and the procedures that manipulate them. However, several important differences distinguish it from a traditional application: It is associated with remote procedures and (optional) initialization and termination handlers instead of a main procedure. Like a UNIX device or directory, it ‘‘is a file’’, that is, it is associated with a file name. A (traditional, server, persistent, or editable) client application may open it to get an object descriptor that refers to it, use the descriptor to invoke a sequence of remote procedures in it, and later close it. It executes the initialization handler when it is created and the termination handler when it is removed from the system. At any time, it may be in the computing, quiescent, or unreferenced state. It is in the computing state when it is executing a remote procedure, the quiescent state when it is waiting for a remote procedure to be invoked, and the unreferenced state when no application has it open for

Project Manager RPC Automatic Budget

Conversion

Manager

Persistent Representation of Budget RPC Automatic Conversion Affiliate Manager Visual Representation of Budget

Figure 1: Organization of the Project Management Tool

A Guide to Suite d 5

P. Dewan communication.

Figure 2 shows an outline of the application program describing a budget server. Like a traditional program, it defines data structures such as budget and procedures such as AddAffiliate which manipulate these data structures. It also contains special comments beginning with the word oc called object annotations, which are processed by the object compiler provided by Suite. The annotation Initiate with Initiate tells Suite that Initiate, which initializes budget, is the initialization handler. The annotations Method AddProject Async Method AddAffiliate tell Suite that AddProject and AddAffiliate are remote procedures that can be called synchronously and asynchronously respectively. The former is invoked by the project application to inform the budget server of

2222222222222222222222222222222222222222222222222222222222222222222 1 #include 1 1 #include 1 1 1 1 #include "proj.h" 1 1 /*oc 1 1 Initiate with Initiate 1 1 1 Method AddProject 1 1 Async Method AddAffiliate 1 1 1 */ 1 1

1

1

1

1 Budget budget; 1

1 ProjectBudget project_budget_arr [MAX_PROJECTS]; 1 1 AffiliateBudget affiliate_budget_arr [MAX_AFFILIATES]; 1 1

1

1

1

1

1

1 void Initiate () 1 { ... }

1 1

1

1

1

1 1

1 int AddProject ( proj ) Project proj; 1 1 { ... }

1

1

1

1

1

1

1 void AddAffiliate ( aff ) 1 Affiliate aff; 1 { ... }

1 1

1

1

1

1

1

1

1

1 /* Other Procedures */ 1 ... 12222222222222222222222222222222222222222222222222222222222222222222 1 Figure 2 A Server Application Program

P. Dewan

A Guide to Suite d 6

information about a new project such as the number of PI’s and students involved. In response, the budget server allocates a new entry in the budget for the project, allocates a default amount of money to the project based on the information it receives from the project application, updates dependent fields such as the current balance, and returns to the project application the money allocated to the new project. The latter is invoked by an affiliate application to inform the budget server of information about a new affiliate such as the name and contribution of the affiliate. In response, the budget server changes the budget accordingly, but does not return a value. The affiliate application does not wait for completion of the procedure since it has been declared to be asynchronous. A server application is created by invoking its program with a special argument describing its file name. Thus the command budget -name my_budget & may be used to create the server application my_budget which executes the object file budget. The name argument may be omitted when the name of a server is the same as the application program it executes. Moreover, a special argument -f indicates that the new server should replace an existing server with the same name. Thus the call budget -f & creates a new server called budget which replaces an existing application with the same name. The following code shows the structure of the remote procedure AddProject declared in the budget application program: int AddProject( proj ) Project proj; { /* local variable declarations */ ... SaveArguments(); /* process new project and allocate money to it */ ... /* return money allocated */ return (project_budget_arr[cur_proj_no].total_cost); } } This declaration is like a local procedure declaration except that it calls the predefined procedure SaveArguments. When a remote procedure is executed, memory is allocated to store the values of its arguments. This memory is released when it finishes execution, unless it calls SaveArguments. In this example, AddProject calls SaveArguments because it stores the value of its argument in a global array. Figure 3 outlining some of the code of the project application program illustrates how an application communicates with a server application. The call to OpenObject returns a descriptor to budget which is used as the first argument in the call to the procedure AddProject. The remaining arguments of the call correspond to the parameters specified in the declaration of AddProject in the budget application program. The memory allocated for storing the result returned by a remote procedure call is saved unless the procedure FreeResults is

A Guide to Suite d 7

P. Dewan

22222222222222222222222222222222222222222222222222222222222222222222222222222 1 #include 1 1 #include 1 1 1 1 #include "proj.h" 1 1 /*oc 1 1 Initiate with Initiate 1 1 */ 1 1

1

1 /* Declarations */ 1 Projects projects; 1 OBJECT *budget_obj; 1 ... 1

1

1 1 1 1

1

1

1

1

1 void Initiate() 1 1 { 1 1 ... 1 1 if ((budget_obj = OpenObject("budget")) == (OBJECT *)NULL){ 1 1 1 printf ( "Can’t open Budgets"); 1 1 return; 1 1 } 1 1 1 } 1 1

1

1

1

1

1 1 void UpdateNewProject(path, proj_ptr ) char *path; 1 1 Project *proj_ptr; 1 { 1 int cur_proj_no; 1 SaveArguments(); 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1

1 }

1 1

if (projects.num_projects++ < MAX_PROJECTS) { ... projects.project_arr[cur_proj_no].allocated = AddProject ( budget_obj, * proj_ptr ); ... }

1 1 1 1 1 1 1 1

1

1

1

1

1 /* Other Procedures */ 1 122222222222222222222222222222222222222222222222222222222222222222222222222222 ... 1 Figure 3 A Client Application Program explicitly called. In order to transmit and receive arguments of remote procedures, Suite needs to know the type of these arguments. This presents a problem in weakly typed languages such as C since the the type of a data structure is often ambiguous. For instance, a variable declared as char *ptr may be a pointer to a character, character array, or string. Suite lets a programmer explicitly specify the type of

P. Dewan

A Guide to Suite d 8

such data. Moreover, it uses several rules to determine the type in the absence of explicit programmer specification [4]. One important rule lets it support sequences— variable length arrays missing from C, Pascal and older languages. Suite lets a sequence be simulated by a record containing a length field and an array pointer. For instance, it lets a sequence of values of type Affiliate be simulated by the record: typedef struct { unsigned num_affiliates; Affiliate *affiliate_arr; } Affiliates; When transmitting such a record as an argument to a remote procedure, Suite sends only as many elements of the array as are specified by the first field. Sequences are used extensively in all the sample applications built by us, including the budget, project, and affiliate applications. It is possible to create communicating applications such as these using lower-level communication layers such as the UNIX socket layer. However, that requires handling several tedious tasks such as establishing connections and coding/decoding the operation name and arguments. These tasks are automatically handled by Suite RPC. 4. Persistence Suite allows persistent data to be kept in persistent applications. A persistent application is like a server application with some important differences. It can declare certain data structures as eternal, which are saved on disk. In addition to the computing, quiescent, and unreferenced state, it can be in the passive state. When it is in a non-passive ( computing, quiescent, or unreferenced) or active state, it is associated with a temporary server called an incarnation which executes the program describing the persistent application. An active persistent application that stays in the unreferenced state for more than a certain period of time is passivated, that is, its eternal data structure written to disk and the incarnation removed from the system. A passive persistent application opened by another (temporary or persistent) application is activated, that is a temporary incarnation created and the eternal data structures loaded from the disk. A persistent application may define handlers to process transitions between its active and passive states. It may also explicitly ask for its data structures to be saved on disk and restored from it at anytime during its execution [4]. Figure 4 illustrates how the server application program of Figure 2 may be extended to describe persistent budget applications. The object annotation Eternal budget tells Suite that the variable budget is to be saved/restored when the application is passivated/activated. A persistent application is named, created, opened, and closed like a server application. Thus the command budget -name newbudget & can also be used to create a new persistent budget application. The application may later be opened and closed. If it stays in the unreferenced state for more than a certain period of time, it is passivated and its eternal data structures saved on disk. Later, when it is opened by some applications such as the project application, it is activated and its eternal data structures restored from disk.

A Guide to Suite d 9

P. Dewan

2222222222222222222222222222222222222222222222222222222222222222222 1 #include 1 1 #include 1 1 1 1 #include "proj.h" 1 1 /*oc 1 1 Initiate with Initiate 1 1 1 Method AddProject 1 1 Async Method AddAffiliate 1 1 Eternal budget 1 1 1 */ 1 1

1

1

1

1 Budget budget;

1

1 ProjectBudget project_budget_arr [MAX_PROJECTS]; 1 1 AffiliateBudget affiliate_budget_arr [MAX_AFFILIATES]; 1 1

1

1

1

1 void Initiate () 1 { ... }

1 1

1

1

1

1

1 void AddAffiliate ( aff ) 1 Affiliate aff; 1 { ... }

1 1 1

1

1

1

1

1 int AddProject ( proj ) Project proj; 1 1 { ... } 1

1 1 1 1

1 /* Other Procedures */ 1 1 1 ... 12222222222222222222222222222222222222222222222222222222222222222222 1 Figure 4 A Persistent Application Program A persistent application can be simulated in a system supporting only server applications. By providing automatic support for persistent applications, we relieve programmers from manually determining when applications should be activated/passivated, activating and passivating them, and saving and restoring their data structures. 5. User Interface Management In Suite, interactive applications are created as editable applications. An editable application is a server application extended with primitives for specifying its user interface. Some of its data structures can be edited by the user to control the behavior of the application. In addition to the computing, quiescent, and unreferenced state, it may be in the loaded state. In the loaded state, it has been opened by a dialogue manager, which can be used to interact with it. It can define load and unload handlers to process transitions to and from the loaded state. A load handler, typically, asks the dialogue manager to display an initial set of data structures, and describes how these data structures are to be displayed. An editable application is created, opened, closed, and destroyed like a server application. A dialogue manager displays a set of windows to interact with the editable application. In the Suite prototype, this set consists of five windows: a startup window, an object window, a menu window, an error window, and

A Guide to Suite d 10

P. Dewan

an attribute window (Figure 5). Not all windows need to be mapped to the screen at all times— special commands are provided to map and unmap them. A startup window lets a user use the dialogue manager to interact with different editable applications in the system. A user wishing to edit with a new application specifies the name of the application and executes the Load command. In response, the presentation of the editable data structures of the application are loaded in the object window of the dialogue manager. This presentation may be edited by invoking the commands in the menu window. Later, a user may execute the Quit command to unload the application and remove the dialogue manager. The error window shows error messages while the attribute window allows users to interactively specify non-procedural attributes of value groups. Figure 6 illustrates how the budget application program of Figure 4 may be extended to describe an editable and persistent budget application. It contains dialogue annotations embedded in a special comment beginning with the keyword dmc which are directives to the Suite-provided dialogue compiler. The annotation Editable Budget telling Suite that variables of type Budget are editable. The annotation Load with Load tells Suite that the procedure Load in the application program is the load handler. The definition of Load follows:

Figure 5: Dialogue Manager Windows

A Guide to Suite d 11

P. Dewan

2222222222222222222222222222222222222222222222222222222222222222222 1 #include 1 1 #include 1 1 1 1 #include "proj.h" 1 1 /*oc 1 1 Initiate with Initiate 1 1 1 Method AddProject 1 1 Async Method AddAffiliate 1 1 Eternal budget 1 1 1 */ 1 1

1

1 /*dmc 1 Editable Budget 1 Load with Load 1 */ 1

1 1 1 1 1

1

1

1 ProjectBudget project_budget_arr [MAX_PROJECTS]; 1 1 AffiliateBudget affiliate_budget_arr [MAX_AFFILIATES]; 1 1

1

1 Budget budget;

1

1 1

1 1

1 void Initiate () 1 { ... }

1 1

1

1

1

1

1 void AddAffiliate ( aff ) 1 Affiliate aff; 1 { ... }

1 1 1

1

1

1

1

1 int AddProject ( proj ) Project proj; 1 1 { ... } 1 1 1

1

1

1 Load() 1 1 { ... }

1 1 1

1

1

1 void UpdateProjectBudget (path, budget_ptr) 1 char *path; 1 ProjectBudget *budget_ptr; 1 { ... } 1 1

1 1 1 1 1 1

1 /* Other Procedures */ 1 112222222222222222222222222222222222222222222222222222222222222222222 11 ... Figure 6 An Editable and Persistent Application Program Load() { Dm_Submit( &budget, "budget", "Budget" ); Dm_SetAttr( "Type: ProjectBudget", AttrUpdateProc, UpdateProjectBudget ); Dm_Engage( "budget" ); } It consists of invocations of three different remote procedures defined by the dialogue manager. The call to Dm_Submit submits the variable (also called a view in Suite) budget for editing to the dialogue manager. The

A Guide to Suite d 12

P. Dewan

first argument specifies the location of the value of the variable, the second argument the name of the variable, and the third argument the name of the type of the variable (which must be one of the types that has been declared to be editable). The call to Dm_SetAttr specifies the value of an attribute of a value group [8] which is either a type or view (variable). The first argument specifies the path name of the value group, the second argument the name of the attribute, and the third argument the new value of the attribute. In this example, the call specifies the value of the AttributeUpdateProc attribute of the type ProjectBudget to be the procedure UpdateProjectBudget. The attribute AttributeUpdateProc of a type specifies the procedure to be called when a value of that type is edited by the user. Finally, the call to Dm_Engage asks the dialogue manager to engage the variable, that is, display it to the user. Here is the callback procedure UpdateProjectBudget, which is invoked when a new value of type ProjectBudget is committed by the user. void UpdateProjectBudget(path, budget_ptr ) char *path; ProjectBudget *budget_ptr; { int change; change = - budget_ptr->total_cost; ComputeNewBudget (budget_ptr); change += budget_ptr->total_cost; budget.allocated += change; budget.balance -= change; Dm_Update( path, "ProjectBudget", budget_ptr); Dm_Update ("budget.allocated", "int", &budget.allocated); Dm_Update ("budget.balance", "int", &budget.balance); } Like other callback routines, it takes two arguments: the first, path, indicates the path of the variable that was edited by the user, while the second, budget_ptr, gives the address of the new value for the variable. The procedure assumes that the user changes only the independent fields of the project budget and calls ComputeNewBudget to calculate the new values of dependent fields such as total_cost. It then calls the remote procedure, Dm_Update, in the dialogue manager to ask it to update the display of the project budget. The first argument of Dm_Update names the variable to be updated while the second argument indicates the new value of the variable. Changing the total cost of a project budget also affects the value of the total amount allocated to the various projects and the balance left. The callback procedure computes new values of these fields and calls Dm_Update to update their displays. In the budget example, the dialogue manager uses default values of formatting attributes in order to display the value of budget. In general, an application can override these values in a structured way. Suite groups values into value groups, based on the type, parent, context, and other properties of values, and allows attributes to be specified once for all values in the group. For instance, an application can specify the TitleString attribute once for all values of type Budget. Similarly, it can specify the UnInitialized attribute once for all descendents of the value budget. The various groups are hierarchically arranged and a more specialized group inherits attributes from a general group. The details of the Suite value groups and the inheritance model are

A Guide to Suite d 13

P. Dewan described in [8].

A dialogue manager is itself a server application executing a Suite-provided application program, and can be created like other servers, as shown below: dm -f & The user interface provided by Suite is more flexible than one that can be created using C or Pascal I/O routines, since it supports full-screen editing of data structures instead of the teletype interaction model. However, it is less flexible than one that can be created using a toolkit such as X, since it cannot currently support, for instance, multiple object windows per application or graphical displays of data structures. Suite is preferable to X if it meets the application’s interface needs since it relieves the application from handling low-level interaction tasks such as creating/destroying windows, handling the mouse, converting between visual and internal representations of data, and a host of other activities. 6. Object and Dialogue Compilers, and Object Manager The object compiler oc, is used to compile server and persistent application programs, but not editable ones. It preprocesses object annotations and calls the C compiler to generate an object file that may be executed to create a server. For instance, assume that the application program describing a server application is in file "server.obj" in the current directory. Then invoking the command oc server.obj creates the executable file "server" in the current directory. This file can later be executed server -f & to start the server. Compiling a server application program generates an interface (".C") file that needs to be linked with clients wishing to communicate with the server. Thus, in the above example, the file "server.C" is generated by oc. Assume that we wish to compile another server program, "client.obj", which is a client of "server.obj". The following command does the job: oc client.obj server.C We may wish to create two server application programs which invoke procedures in each other. The "-c" option to object compiler lets us handle this situation. This option tells the object compiler to generate the interface part but not the executable. The option can be used as follows to compile "server.C" and "client.C" if they execute procedures in each other: oc oc oc oc

-c server.obj -c client.obj server.obj client.C client.obj server.C

The dialogue compiler, dmc, is used to compile editable application programs. It processes the dialogue annotations and then calls oc to do the rest of the processing. Thus, if in the above example, "server.obj" was editable, we would execute the following commands:

P. Dewan

A Guide to Suite d 14

oc -c server.obj oc -c client.obj dmc server.obj client.C oc client.obj server.C Finally, Suite provides an object manager, om, which forks incarnations of persistent applications. It needs to be running on each machine on which incarnations can be created. It should be invoked in the background since it is itself a server application program: om & The man pages for oc, dmc, and om provide more details. 7. An Example Session with Suite In this section, we take the reader through an example session with Suite, illustrating how the prototype may be used. The session uses the project management tool, which is included in the Suite software. We assume that the reader has access to the software and follows the steps given here. Change your directory to proj/demo/serctool where proj is the root directory of the software. A copy of the directory should exist on each machine type on which Suite applications are to be executed. In the Purdue installation, /u17/rxc/proj and /u13/rxc/proj contain software that runs on Sun-3 and Sequent computers, respectively. If you wish to create applications on different hosts, then create a shell on each of these hosts, ensuring that the DISPLAY variable of each of these computers refers to a workstation running X and the host is on the access list for the workstation. Also make sure that the bin directory is in your search path. List the files in the directory. This list should contain Makefile, budget.obj, projects.obj, and affiliates.obj. Compile these files as shown below to generate the corresponding binaries: dmc budget.obj dmc projects.obj budget.C dmc affiliates.obj budget.C The order of the compilation is important since projects.obj and affiliates.obj call remote procedures in budget.obj. The compilation will take time since dmc processes the source file and then calls oc which again processes the file and in turn calls the C compiler. At the end of the compilation phase, the directory should contain the executables budget, projects, and affiliates, which will be executed to create applications managing the SERC budget, projects, and affiliates respectively. Before these applications are executed, run the object manager om in the background on each machine on which you will execute applications. Execute the command budget -f & to create a budget application whose (relative) file name is budget. It is important to give it this file name, since

A Guide to Suite d 15

P. Dewan

it is used by projects.obj and affiliates.obj when they open it.1 At this point you will get the error message Server Library: Access denied in open during create: .../proj/demo/serctool/budget if some other user has already created an object with the same name. Execute rm *.ins to get rid of all ‘‘instance files’’ representing existing objects. The budget application is editable, so you can interact with it using a dialogue manager. Execute dm -f -name dm_budget & to create a dialogue manager (on possibly a different machine from which budget was created on). After a few seconds, you will see the startup window appear on the screen. This window is an X window and you can use the regular X commands to perform window operations such as hide, move and so on. It tells you the full path name of the dialogue manager and the machine on which it was executed. It also prompts you for the name of the editable application (object) with which you wish to interact (Figure 7). Fill in the name budget and execute the Load command by clicking with the left button on the Load button. The dialogue manager will respond by unmapping the startup window and mapping the object and menu windows. The object window shows the display of the initial value of the budget. The menu window allows a user to execute UnSelect, Elide, and other editing commands to edit the contents of the object window. Practice using them. Click the middle mouse button on the organization field to select it (Figure 8). Now execute the Up command to select the parent structure (Figure

Figure 7: The Startup Window

Figure 8: Selecting a Field 333333333333333333 1

A useful extension to the tool would let the projects and affiliates applications get the name of the budget as a command argument.

A Guide to Suite d 16

P. Dewan

9). Clicking on the Elide button will hide the subfields of the budget (Figure 10) while clicking on it one more time will restore the display. (This button toggles between the Expand and Elide commands.) You can now execute the UnSelect command to unselect the budget. Currently, no projects or affiliates have been assigned to SERC, therefore the fields affiliate_budgets and project_budgets are empty. These should not be edited directly to add new projects or affiliates, since they are managed by the project and affiliate applications respectively. To create the project application execute the command: projects -f & Create a new dialogue manager dm -f -name dm_projects & and load projects. You must give a new dialogue manager a name that is different from the names of the dialogue managers that are currently executing. The screen now shows two pairs of startup and object windows and it may be hard to pair up the startup and object windows of a particular application. We shall not be directly interacting with budgets for a while, so position the mouse within the object window for it and press the F2 key on your keyboard. The menu window for budgets will disappear (Figure 11). (The F2 key, like F1, F3, and F4 acts as a toggle, and in this example can be

Figure 9: Selecting the Parent

Figure 10: Hiding Subfields

A Guide to Suite d 17

P. Dewan

pressed one more time to make the menu window reappear. If you have bound any of the keys F1-F4 to other functions, you can use the keys F6-F9 instead.)

Figure 11: Hiding a Menu Window The object window of the project application displays two top-level data structures: a project template, which can be edited to add a new current project, and a list of current projects. Initial values of most of the fields of the project template have been supplied by projects. In this example we will edit the personnel field of the first milestone since no value has been supplied for it. This field is a sequence and can consist of several pairs of name and percent time fields, where the percent time field describes the percentage of full time that the person name will devote to the project. A new pair can be added by selecting the personell field and executing the Insert After command.

A Guide to Suite d 18

P. Dewan

Figure 12: Adding the First Element to a Sequence The display of the new pair indicates that the name field is uninitialized by showing the placeholder (Figure 12). Initialize this field by positioning the cursor (using the left mouse button) on the placeholder and entering the replacement for the placeholder. Use the backspace key to delete characters. Similarly, edit the percent time field. Now add a new pair by selecting the first pair (Figure 13) and executing the Insert After command, and edit this field as shown in Figure 14.

A Guide to Suite d 19

P. Dewan

Figure 13: Executing Insert After

A Guide to Suite d 20

P. Dewan

Figure 14: New Entry in the Sequence

A Guide to Suite d 21

P. Dewan

The template at this point contains most of the information about the new project. We have deliberately not filled certain fields. For instance, we have not edited the person_months_planned field, which is a dependent field and will be automatically computed for us based on the value of other fields. We have also not edited the allocated field. In this example, a user of the project application cannot change this field and it is the responsibility of the budget application to give an appropriate value to it. The template can now be committed by executing the Accept command. At this point all changes since the last execution of this command are communicated to projects which takes several actions in response. It first communicates information about the new project to budget and receives in return a default amount of money allocated to the project based on the status and number of the personnel working on the project. Next, it calculates the dependent fields of the new project such as person_months_planned based on the independent fields. It next inserts the new project in the data structure containing the list of current projects and sends the new value of the data structure to the dialogue manager, which updates its display (Figure 15).

Figure 15: Accepting the Project Template

A Guide to Suite d 22

P. Dewan

In the meantime, the budget application inserts information about the budget of the new project in the data structure describing the list of current project budgets and sends the new value of the data structure to its dialogue manager, which also updates its display. To add new affiliates, create a new affiliate application affiliates -f & and load it in a new dialogue manager. You can edit the affiliate template and execute the Accept command to add a new affiliate. (You must edit the template even if you do not wish to change the information because currently Accept will send the template to the affiliate application only if one or more of its fields has changed.) Both the affiliate and budget applications respond to the command by appropriately modifying their editable data structures and sending the new values to their dialogue managers (Figure 16).

Figure 16: Adding an Affiliate

A Guide to Suite d 23

P. Dewan

It is also possible to modify information that has been accepted by an application. For example, it is possible to edit the summer_salary field in pi_budgets to change the money allocated to a project— the budget application recalculates the budget when the user executes the Accept command (Figure 17). It should also be possible to change the lists of current projects and affiliates but that is not currently supported in this initial version of the tool.

Figure 17: Modifying the Budget The example so far has illustrated several interactive features of Suite including how to create applications and their dialogue managers, load editable applications in windows, map and unmap startup and menu windows, execute menu commands, and edit and commit presentations of data structures. If you are an end-user, these features are almost all you will ever use. Suite also provides interactive features meant for application programmers defining editable applications. We illustrate them in the remainder of this example.

A Guide to Suite d 24

P. Dewan

Hide all windows except the object window for the project application. Now position the mouse in this window and press the F4 key. The dialogue manager will respond by displaying the attribute window, shown in Figure 18. This window displays four fields, Message, which displays a message from the dialogue manager, Path, which names a value group, Attr, which names an attribute, and Value, which contains a value for the attribute. It also provides seven commands, Load, Set, Inherit, Delete, Path, Attr Menu, and Enum Menu. The Load command is used to load the value of an attribute of a value group, while the Set command is used to define the value. The Inherit command is like Load except that it looks for an inherited value if the attribute is not defined in the specified value group. The Delete command deletes the definition of the attribute of the value group. The Path command lets a user select a value group instead of typing its name. It loads the path of the selected data structure in the presentation window in the Path field of the attribute window. The Attr Menu commands displays a menu of attribute values from which a value can be selected to set the Attr field. Finally, the Enum Menu commands shows the set of legal values for an enumeration attribute. Try changing an attribute of a value. Execute the Attr Menu command to display the list of attributes (Figure 18), and select one of them, say ElideString. You need to also specify the path of a value whose attribute you wish to change. Select the value in the object window and execute the Path command to display its name in the path field (Figure 19). You must have exactly one value selected when you execute the Path command—if

Figure 18: Suite Attributes and Attribute Window

A Guide to Suite d 25

P. Dewan

you have zero or multiple selections then an error message will be displayed in the Message field.

Figure 19: Selecting the Path

A Guide to Suite d 26

P. Dewan

Now enter a valid string in the Value field and execute the Set command. Next time you elide the project, the new value of ElideString will be displayed (Figure 20).

Figure 20: The ElideString Attribute

A Guide to Suite d 27

P. Dewan

Try the same process with some other attributes. For instance, change the Titled attribute of the project to False. Notice that the TitleString ‘‘1: ’’ disappears from the display. Notice also that all fields of the data structure (except the milestones field) have become untitled (Figure 21). This is because Suite defines structural inheritance which uses the IS_PART_OF relationship to let a child inherit attribute values from its parent. To restore the titles of the fields of the project (but not the project itself) set the Titled attribute of View Child: ((projects) [0]) to True (Figure 22).

Figure 21: Structural Inheritance

A Guide to Suite d 28

P. Dewan

Figure 22: Children Groups

A Guide to Suite d 29

P. Dewan

Suite also defines type inheritance which uses the IS_A relationship to let a value inherit attribute values from its type. You can change the TitleString attribute of Type: Personell to correct the spelling of the titles of all values of this type (Figure 23). Unfortunately, the titles of the elements of the sequence and name field of the elements (but not the percent time fields) also change because of structural inheritance. This situation can be corrected by explicitly assigning the string "%s: " to the TitleString attribute of Type: Person (Figure 24) %s is a special formatting character that can appear as part of a string attribute of value and stands for the name of the field holding the value.

Figure 23: Type Inheritance

A Guide to Suite d 30

P. Dewan

Figure 24: Type-first Inheritance The structural and inheritance schemes are two independent schemes which can both influence the attributes of a value. Suite resolves the multiple inheritance problem for most attributes by giving the type inheritance higher precedence over structural precedence. This explains why the Titled attribute of the milestones field did not change when the attribute was changed in its parent. In the definition of the project application, the type of the milestone field gives a definition for this attribute, which is used instead of the definition in the parent. For similar reasons, the TitleString attribute of the percent time field did not change in Figure 21. While ‘‘type-first’’ inheritance is suitable for most attributes, other mechanisms for resolving multiple inheritance are more suitable for other attributes. As explained in [8] Suite currently also supports ‘‘structure-first’’, ‘‘type-only’’, ‘‘structure-only’’, and ‘‘no-inheritance’’ search schemes.

Look at the end of the file

‘‘proj/symtab/makeattr.c’’ to determine which attribute inheritance scheme is used for a particular attribute. You may wish to change the default schemes based on your needs and experience.

A Guide to Suite d 31

P. Dewan

Suite extends the notion of type beyond what is supported by programming languages. To illustrate how, consider the name field of a project. Suppose we wished to make all occurrences of this field untitled. One way to achieve that is to set the Titled attribute of its type, String, to the False value. However, that would make all values of that type untitled, including the goal field of a Milestone and the name field of a Person (Figure 25).

Figure 25: Untitling all Strings

A Guide to Suite d 32

P. Dewan

Therefore, Suite defines special ‘‘context types’’ or ‘‘context groups’’ that group together all values of a particular type that appear as a particular component of a structure type. For instance, it defines the context group Project.name which groups together all values of type String that appear as name fields of records of type Project. The Titled attribute of this type can now be changed to achieve our original goal (Figure 26). A context type such as Project.name inherits attributes from the corresponding more general ‘‘pure type’’ such as String, as explained in [8].

Figure 26: Context Groups

A Guide to Suite d 33

P. Dewan

Titled, TitleString, and ElideString are three example of attributes that determine the format of presentations of data structures. Figure 27 illustrates the semantics of other formatting attributes. In this Figure, the PreString, TitleString, Titled, and Postring attributes have been set to the "PreString " , "TitleString ", True and " PostString\n\n" values respectively.

Figure 27: Formatting Attributes

A Guide to Suite d 34

P. Dewan

Not all attributes of a value determine the format of its presentation. For instance, the ReadOnly attribute determines if its presentation can be modified by the user— a dependent field should have this attribute set to True; the VerifyProc attribute determines the procedure that is invoked to check the value for semantic correctness —this attribute cannot be currently modified interactively; the Erroneous attribute determines if the value is semantically invalid; and the ErrorString attribute determines the error message that is displayed when a value is found to be erroneous. Error messages are displayed in the error window. Position the mouse in the object window and press the F3 key to show the error window. Currently, it shows no messages since none of the values displayed in the object window is erroneous. Change the Erroneous attribute of the faculty and student fields of the project template to True. The error window will now show two default error messages which can be customized by modifying the ErrorMessage attribute of these values. In general, it may be hard for the user to determine the correspondence between erroneous values and error messages. Therefore, Suite highlights the corresponding error value in the object window whenever the user selects an error message in the error window (Figure 28). Two important attributes determine how soon users get feedback from dialogue managers and applications in response to changes they make to values. These attributes are best illustrated using the budget application, since it reacts to editing of the budget. Iconize the project windows and display the object and attribute windows of the budget application instead. Change the IncInputScheme attribute of the summer_salary field of the first project budget to the enumeration value InputUpdate (You can use the Enum Menu command to enter the

Figure 28: Error Messages

A Guide to Suite d 35

P. Dewan

enumeration value, as illustrated in Figure 29). When you next change the summer_salary field you will notice that the values of dependent items are recomputed incrementally on every keystroke. This is because the InputUpdate input scheme asks for incremental invocation of the update procedure in the application. If this attribute is set to InputDelay then the updating takes place only when the Accept command is executed. Suite also lets a user postpone feedback until the value has been completely edited without requiring explicit invocation of the Accept command. It uses movement of the insertion point away from the edited field as an implicit indication of completion of the editing of the field. Change the value of the IncInputScheme attribute to InputDelay and the value of the MovementInputScheme to IncUpdate. Since the input scheme is InputDelay, the update procedure is not invoked on every keystroke. However, since the movement scheme is InputUpdate, the update procedure is invoked as soon as the user moves the insertion point away from the edited field (Figure 30). Updating of the data structure in the application is only one of three possible kinds of feedback to a user change to the presentation of a data structure. The two other kinds of feedback are checking of user input for syntax errors and semantic errors. The three kinds of feedback represent three decreasing degrees of feedback. Updating of the data structure occurs only after the new value of the data structure has been checked for syntax and semantic errors. Similarly, checking a new value for semantic errors or validation occurs only after it has been checked for syntax errors. In Suite users can choose when a particular degree of feedback is given. For instance, they can choose to get syntactic feedback on every keystroke, semantic feedback on movement of the cursor point, and

Figure 29: Update on Keystroke

A Guide to Suite d 36

P. Dewan

Figure 30: Update on Movement updating on explicit execution of the Accept command, by setting the

IncInputScheme attribute to

InputSyntax, and MovementInputScheme to InputValidate. If you wish to close a dialogue manager’s connection with a loaded object, you can position the mouse within the object window, press the F1 key to display the startup window, and then execute the Close command. Moreover, you can execute the Quit command to both unload the object and terminate the dialogue manager. Thus, to end this session, execute the Quit command in the startup windows of the dialogue managers for the three objects. You do not have to worry about killing the processes created for executing these objects—they will automatically passivate themselves after a while. Moreover, you can resume this session at a later time by, as before, starting dialogue managers and asking them to load these objects. However, this time you do not have to explicitly start processes for these objects—the objects will be automatically activated by the object manager. This example illustrates several interactive features of the user interface including structure-based commands, triggering of actions in response to user input, user control over the degree of feedback, attributes, and structural and type inheritance. These features are applicable to a variety of applications. Indeed, we have used them in manipulating directories, process lists, calendar lists, and other information. Thus, the Suite user interface is an important step towards a generic automatable high-level user interface. 8. Conclusions and Future Work Suite supports three important features missing from conventional systems: RPC, active persistent data, and user interface management. It is integrated with conventional systems, thereby representing an ‘‘evolutionary’’

P. Dewan

A Guide to Suite d 37

approach to system design. We have implemented a prototype on a network of hosts executing U NIX, NFS, and X. This report illustrates and motivates the main components of Suite through the example of a realistic project management tool. It has been written specifically for researchers wishing to experiment with the prototype. Both the system and the tool are prototypes meant only to demonstrate the usefulness of the concepts behind the system. The functionality, robustness, and efficiency of the system would need to be improved in a production version of it. Currently, a Suite editable application communicates with at most one dialogue manager. It would be useful to allow multiple dialogue managers per application, each interacting with a different user of the application. This idea raises several issues in distributed collaboration including issues in concurrency control, access control, communication, and user interface. We plan to address these issues in the next version of Suite. Acknowledgments Eric Vasilik implemented most of the current version of the Suite prototype. Rajiv Choudhary has been involved in measuring and improving its performance, and writing the man pages. Ronnie Martin found several errors in a draft version of this report. REFERENCES

[1]

G.T. Almes, A.P Black, E.D. Lazowska, and J.D. Noe, ‘‘The Eden System: A Technical Overview,’’ IEEE Transactions on Software Engineering 11:1 (January 1985), pp. 43-59.

[2]

Malcolm P. Atkinson and O. Peter Buneman, ‘‘Types and Persistence in Database Programming Languages,’’ ACM Computer Surveys 19:2 (June 1987).

[3]

P. Dasgupta, R. C. Chen, S. Menon, M. P. Pearson, R. Ananthanarayanan, U. Ramachandran, M. Ahamad, R. J. LeBlanc, W. F. Appelbe, J. M. Bernabeu-Auban, P. W. Hutto, M. Y. A. Khalidi, and C. J. Wilkenloh, ‘‘The Design and Implementation of the Clouds Distributed Operating System ,’’ Usenix Computing Systems 3:1 (Winter 1990), pp. 11-46.

[4]

Prasun Dewan and Eric Vasilik, ‘‘Supporting Objects in a Conventional Operating System,’’ Proceedings of the San Diego Winter ’89 Usenix Conference, February 1989, pp. 273-286.

[5]

Prasun Dewan, ‘‘Integrating User Interfaces,’’ Technical Report SERC-TR-48-P, Software Engineering Research Center, Purdue University, August 1989.

[6]

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.

[7]

Prasun Dewan and Eric Vasilik, ‘‘An Approach to Integrating User Interface Management Systems with Programming Languages,’’ Proceedings of IFIP TC2/WG 2.7 Working Conference on Engineering for Human-Computer Interaction, Napa Valley, August 1989, North-Holland, 1990, pp. 493-514 .

[8]

Prasun Dewan, ‘‘An Inheritance Model for Supporting Flexible Displays of Data Structures,’’ Software— Practice and Experience 21:7 (July 1991), pp. 719-738 .

[9]

M. Morgenstern, ‘‘Active Databases as a Paradigm for Enhanced Computing Environments,’’ Proceedings of the 9th International Conference of Very Large Data Bases , 1983, pp. 34-42.

P. Dewan

A Guide to Suite d 38

[10]

Bruce Jay Nelson, ‘‘Remote Procedure Call,’’ Ph.D. Thesis and Tech Report CMU-CS-81-119, Department of Computer Science, Carnegie-Mellon University, May 1981.

[11]

Ben Shneiderman, ‘‘Direct Manipulation: A Step Beyond Programming Languages,’’ IEEE Computer 16:8 (Aug 1983), pp. 57-69.