The check box labeled 'coupled' allows control over scroll- ing and selection ... If the box is checked, the user ..... qucis.queensu.ca/home/graham/reference.html.
Modeling
Collaboration
Christian
Schuckmann,
using Shared Objects Jan Schiimmer,
Peter Seitz
GMD - German National Research Center for Information Technology Integrated Publication and Information Systems Institute- IPSI Dolivostr. 15, D - 64293 Darmstadt, Germany , { Christian.Schuckmann, Jan.Schuemmer, Peter.Seitz} @gmd.de jects. Among other possibilities to realize synchronous document-based groupware, shared object spaces (sometimes called shared environments) are the most promising for the development of large and complex applications [7]. As a consequence, many existing toolkits or frameworks provide shared objects as a basic service.
ABSTRACT
Many object-oriented toolkits and frameworks for groupware development provide shared objects as a basic service. This relieves developers of a lot of problems originating from the field of distributed systems. However, there is little support on how to use shared objects to actually build collaborative applications. In this paper we propose an objectoriented model for applications using shared objects. The model is discussed with respect to object-oriented reusability aspects and its applicability is tested against CSCWspecific aspects like the provision of group-awareness and coupling control. Furthermore, concrete model examples derived from an example application are shown for illustration.
To maintain a consistent and flexible visualization of shared objects, concepts like Model- View-Controller (MVC) [121 have already been extended for the use in groupware applications [7]. Examples are Patterson’s Abstraction-LinkView [lo] or the Clock language [6]. All of these approaches operate on the micro level of modeling like MVC does. This means, they propose a way how shared model objects can be attached to multiple views and controllers at different sites, but do not include an overall application model that describes how the application as a whole is composed. However, with shared object spaces and associated visualization concepts solving fundamental issues, it is possible to define a uniform application model for multi-user applications on a more abstract level. Such a model has to consider groupware-specific aspects like group awareness or floor control as well as object-oriented software engineeringspecific aspectslike usability and reusability.
Keywords
Object-oriented groupware design, shared objects, synchronous groupware, groupware framewoTks INTRODUCTION
The object-oriented design of single-user applications now has a long history. Several methodologies, design patterns, frameworks, etc. are at hand to guide developers of singleuser applications. However, these concepts are not fully applicable to synchronous, collaborative applications where additional aspects have to be considered. The step from single-user application development towards groupware development requires more than just sharing common artifacts or connecting a set of distributed user interfaces. These additional aspects can be seen from a conceptual or from a technical point of view. Technical issues include e.g. distributed architectures, concurrency control, view updating, etc. Much research has been done on solving such technical problems, which provides a good basis for groupware design on a higher abstraction level. Therefore, it is now time to concentrate on object-oriented groupware design from a more abstract, conceptual point of view.
In the design of single-user applications the separation of application model and domain model has proven successful 113, 191. In our approach, we try to transfer this concept to collaborative applications. We claim that this separation, if it is based on a shared object space and adapted to the specific needs of the multi-user case, is helpful for the development of multi-user applications as well. This paper is organized as follows. The next section describes requirements for an object-oriented model for groupware applications. Then, an example application is introduced that will be used throughout the paper to further illustrate our approach. Afterwards, the proposed model is presented. The main part of the paper then discusses this model with respect to the identified requirements. The paper finishes with a short excursion on implementation aspects, a comparison to related work, conclusions, and our plans for future work.
This paper addressesdevelopers of synchronous groupware applications. To them we would like to present an objectoriented groupware application model based on shared obPermission to make digital or hard copies of all or part of this work fol personal or classroom use is granrcd without fee provided that copies arc not ma& or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists. requires prior specific permission an&or a fee. GROUP Copyright
99 Phoenix Arizona USA ACM 1999 I-581 13-065-l/99/1
REQUIREMENTS
In this section we list the design issues that our model has to cover. These well-known and accepted requirements origi-
1...$5.00
189
nate from the fields of CSCW and object-oriented programming.
APPLICATION
EXAMPLE: TASK ASSIGNMENT TOOL
In the example described in this section we want to model a simple collaborative task assignment tool that members of a project team can use to assign themselves to tasks.
One of the most prominent groupware-specific aspects is the provision of group awareness to help users coordinate their work [8]. To provide such information the model has to capture the relationships between users and the tools or artifacts they currently use, i.e. the current collaborative situation.
Figure 1 shows the domain model used for our application. It is a simple model for projects that consist of tasks and human resources. People working in projects have a name and a set of assignments that specify how long they will work on which task. Finally, tasks have a description, duration, and a set of assignments.
Furthermore, collaboration has to be structured according to the collaborative situation at hand (see e.g. [9]). For example, working groups are established as users join the same session. Parallel sessions, on the other hand, allow work to be divided between independent groups.
Person
Project descriptton
Members of a session may want to switch collaboration mode between tight (WYSIWIS: ‘What You See Is What I See”) and loose collaboration according to the current task, i.e. some kind of coupling control is needed [3]. Groupware developers have to deal with collaboration structuring in a flexible way, where applications even have to change the collaboration structure on the fly.
resources
name
>
A person
assignments
tasks v Task description duration
Compared to single-user applications, groupware designers do not always want to give all users full control over the application. Floor control, for example, may be necessary to coordinate who is allowed work when. Again, flexible solutions are required to allow fine-grained control over parts of the application and switching of control between different modes according to the task at hand.
Figure I:
(
v Assignment
task >
workload
assignments
Domain model for the application example. (The UML notation is used for all class and object diagrams in this paper)
The user interface for the tool is shown in figure 2. In the upper left part the user interface contains a list of tasks with information about task duration, workload already assigned (the sum of the assignment durations), and assignment details. Right of the scrollbar information about other user’s scrollbars is provided.
To summarize, the following design issues apply to groupware development (in addition to those of single-user application development): . group awareness l coupling control . session management l floor control From the object-oriented programming point of view, additional requirements can be identified. Perhaps the most ambitious, but also most general among these is the ease-of-use requirement, To be more specific, the proposed model has to be on the right level of abstraction, i.e. it has to explicitly include the concepts from the problem domain (in our case: the domain of collaborative applications). Furthermore, it should be a consistent solution that uses one uniform model to capture all concepts from the problem domain equally.
/ Chrii ti?): 1 rI
Tee@ (j,;Teek3 (31. fee#r (5). Teekl4 (6) Tacks (3). nukl 1 0) a&5 (1). Tsek3 (a), Taekl l(2)
Finally, application designers of object-oriented groupware do not want to build applications from scratch, but want to reuse components already at hand (according to the promises of object-orientation). As a consequence, the questions arise where the potentially reusable parts of an objectoriented groupware application can be found and how a groupware application can be designed to offer reusable components for other applications with focus on multi-user specific parts.
Figure 2: User interface of the example application
Users can select a task in the list and then use the ‘add’ or ‘remove’ button to increase or decrease their workload in the selected task. The check box labeled ‘coupled’ allows control over scrolling and selection behavior. If the box is checked, the user will have his or her scroll position and selection coupled with all other users who work in this mode. Otherwise the user can browse the task list individually. The next check
190
box labeled ‘exclusive’ can be used to grab the control over the task assignment activity. Only the floor holder can scroll the task list, select tasks, change assignments, and uncheck the ‘exclusive’ box. In the lower left part another list gives an overview of people and their assigned tasks. This list is read-only and can always be scrolled individually.
sub-components could well be composed of generic classes from an application framework or library. During run-time, application models are set into relation with the domain models they currently edit or show. In our example, Project is the domain model for the task assignment application model. Furthermore, the list of all Tasks within the project is the domain model of the task list application model and the list of all Persons is the domain model of the person list application model.
Finally, in the right part of the window there is a user list indicating which users are currently working with the application. A MODEL FOR COLLABORATIVE
perscnLisl
APPLICATIONS
exclusiveFlag
This section introduces an object-oriented model for collaborative applications. Shared object spaces as the basis of the model and the distinction between application and domain model are summarized first, followed by the unique and groupware specific aspectsthat form our contribution to the model. Domain Model and Application
tasklist
Tas8chslgnmentApp coupledFlag
Figure 3: Example of a simple application
model.
During run-time, application models are set into relation with the domain models they currently edit or show. In our example, Project is the domain model for the task assignment application model. Furthermore, the list of all Tasks within the project is the domain model of the task list application model and the list of all Persons is the domain model of the person list application model.
Model
When modeling applications, the separation between user interface objects and domain objects (sometimes also called “business domain objects” or just “model objects”) is a wellknown technique. User interface objects are responsible for visualizing model objects, interpretation of user input, and modification of model objects. Domain objects represent entities of the domain world. They implement domainspecific behavior and contain state that, in contrast to user interface object’s state, may be stored persistently. An example of a domain model is shown in figure 1.
On the user interface side additional components (e.g. views and controllers) are needed to actually present application data on the screen and interpret user input. Concepts such as MVC [12] or Abstraction Link View [IO] help application developers on this side of the application model.
It is further suggested that object-oriented application designers distinguish between domain-specific and application-specific model objects [ 13, 191. Seen from another point of view, this approach separates user interface state (e.g. the position of a scrollbar) and behavior (e.g. application code executed when a button is pressed) from the pure visualization and simple input processing functionality.*
Sharing the Application
Model
Single-user applications normally do not store their application model persistently, as the application model can be reinstantiated at application start-up. Likewise, it is uncommon for groupware applications to share more than the domain model among application instances. The application model, which is tightly coupled to the user interface, seems to be a natural candidate for a local object structure. Instead, we propose to use shared objects not only for the domain model but also for the application model. This allows applications running at different sites to share a common application model and thus establish synchronized, tightly coupled user interfaces at all sites in an easy way without the inflexibility of shared view. Of course, such WYSIWIS interaction among users is not always appropriate. In this case parts of the application model have to differ for individual users or groups of users. Thus, a loosely coupled collaboration can be established with relaxed WYSIWIS or even completely different user interfaces at each user’s site. One could argue that parts of the application model that are used by only one individual user do not have to be shared with all other users. There are two objections against this:
Application models are used to model all application aspects such as presentation and manipulation of domain objects. Usually, a whole hierarchy of application models composed of generic, reusable parts (e.g. list boxes or other widgets) and custom parts constitutes an application. The usage of application models for single-user applications is discussed in detail in literature about model based user interfaces [13, 191.For our approach these concepts form an essential basis to which we will add groupware-specific aspects. Figure 3 shows an example application model that could be used for our task assignment tool. In this example we have one custom application model (TaskAssignmentApp) that has to be provided by the application programmer, whereas its * We are aware of the possible confusion with respect to the different kinds of model objects. Unfortunately, publications about object-oriented modeling have never consistently used these terms in the past.
First, when group awareness is needed, individual parts of the application model may be of interest to other users as
191
view/
View/ Controller
Controller local
V
v Application Model
Application Modet
shared
subscriptions ( ,
Application User
subscribers $ Domain Model
* -
Domain User
Domain Model
-
Domain User
local
Figure 4: Comparison between a conventional modelfor single-user applications and our modelfor groupware applications (on the right).
well. For example, a user X of our task assignment tool may work individually somewhere at the end of the task list. The scroll position part in the application model is individualized for her. If this individualized scroll position is accessible from other users’ sites the information can be used to display the remote scroll position of user X as shown in figure 2.
application. In our example, the team members are using the task assignment tool - therefore they are represented by an instance of an application user model on the application level of the software. Furthermore, they assign themselves to tasks (which are part of the domain model) - thus an instance of the domain user model is set into relationship with the other domain models. In this case, it might be helpful to establish an association between domain user model and application user model. Thereby the application user model is enabled to share attributes with the domain user model (e.g. the user name).
Second, keeping parts of the application model local means only a small performance gain compared to the loss of simplicity and flexibility that a completely shared model offers. Performance optimizations ensuring that only those objects are shared that are really in-use by an application instance can be easily implemented at the shared object service layer. Application
(on the IefI,)
Proiect A
C-
TaskAsdanmentAoD 1 C-
L&$.X
User Model
Unlike single-user applications, groupware applications involve more than one user. As a consequence, it makes sense to represent users in the application model so that we can express the relationship between user and application with our model. For each user of a groupware application an instance of an application user model is created. During application run-time these application user objects are set into relation with the application models the corresponding user currently uses. We call this the subscription relationship. The set of subscribers together with the shared application model logically forms a session. The object structure in figure 5 shows our task assignment tool used by three users (X, Y, Z). User Y and user Z are cooperatively using the tool? user X works individually.
Figure 5:
Object structure representing two running task assignment sessions, one with one user, the other one with two users.
Summary
Let us shortly sum up the important points of our objectoriented model for groupware applications: . Using shared model objects, these objects are divided into two main categories: domain. and application model. . In contrast to single-user applications, the application model is not considered local but shared among application instances. This allows coupling of user interfaces and the provision of group awareness. . A representation of the user is introduced to the application model. The subscription relationship expresses which user currently uses which application model. Thereby sessionsand their participants are defined.
It is important to distinguish between the application user model and a domain user model which might be necessary depending on the actual domain. Domain user models are special domain models that represent users of the application domain. For example, in the project management domain these could be employees of a company. Domain user models may be set into relation with other domain models to represent owner- or member- or any other relationship in the specific application domain. It is, however, possible that application users will have a representation in the domain ‘world’ and at the same time a representation in the application ‘world’ while using the
192
.
will be impossible. During the time a user needs between selecting a task and pressing the ‘add’ or ‘remove’ button, another user might have unintentionally changed the selection to another value. For this usage scenario, a relaxed form of WYSIWIS is appropriate. This is called ‘loosely-coupled mode’. The third usage scenario provides an alternative view of the domain model. Even though the underlying domain model is the same for users of the assignment tool and users of the executive summary view, the visual presentation is totally different. We call this ‘independent work’.
The application user model and the domain user model should be handled separately. Nevertheless there should be an association between the two in case the groupware system has a representation of the user as part of its domain model. Figure 4 further illustrates the comparison of our model and the conventional single-user application model. DISCUSSION OF THE MODEL
In the following sections we will show how our model can solve the critical issues in groupware design we listed in the requirements section. In doing so, some parts of the example and design alternatives are presented in more detail.
Collaboration between users is achieved by sharing a common application model between these users. As all user interface states are included in the application model, the sharing of this model will result in a strong WYSIWIS application as needed in the discussion scenario. Figure 7 shows an object diagram for the task assignment example with a set of users working with the application in tightlycoupled mode. As refinement compared to figure 3, the ScrollableListModel class is replaced with a generic list with scrolling functionality provided by a scrolling wrapper. For an in depth discussion of the decorator pattern refer to [4].
Coupling control As there are many usage scenarios for a groupware application, it is not possible to decide a priori whether a concrete attribute of the user interface - such as the position of a scrollbar - has to be coupled or not. Even for our small example application different usage scenarios can be found: The tool might be useful for individuals assigning themselves to tasks as well as to a group of users when discussing an overall project schedule. Additionally, there might be the demand for an ‘executive summary’ view showing people and their assigned workload in a graphical presentation. Figure 6 shows an example screenshot of such an executive summary view.
/ i t i i i i
Figure 6:
The loosely-coupled mode can he realized in two ways. One possibility is to use different instances of the application model for each user. These applications are then independent of each other, even though they accessthe same domain models. Figure 8 shows an object diagram for our task assignment application using this design.
18
The second design alternative allows a liner gradation towards tightly-coupled mode. In this design, users still subscribe to one shared application model, but within this application model, certain attributes show personalized values for each user. The decision whether an attribute of the user interface should be coupled or not can be made dynamically, on a per-attribute base, and independently for each user interface widget. To realize this partial split we replaced the wrappers that hold for example the scrollbar position with a more sophisticated structure we call ‘personalized wrapper’. Figure 9 shows such a structure. A personalized wrapper does not refer to its value attribute directly. Instead, an index structure is used that allows storing different values for each user.
16
:“, 10 8 6 4
Executive summary view of the task assignment application.
Figure 10 shows the task assignment example again with personalized scroll position and selection attributes. The transition from tightly to loosely-coupled mode is done by replacing the standard wrappers with their personalized counterpart. This is exactly what the application would do when the ‘coupled’ check box is unchecked.
In this discussion scenario, it is important for the participants to have a common view with strong WYSIWIS. In this situation, the scrollbars of the task list and the user list should be coupled, and the selections made within these lists should be the same for each user thus providing a common point of reference in the discussion. This setting is known as ‘tightly-coupled mode’ [9].
The independent work mode is accomplished by a structure similar to the one shown in figure 8. The alternative application is modeled by a separate application model class. Between these two applications there is no shared interface state. Figure 11 shows the object structure of this scenario.
On the other hand, when used individually by members of a group of users, the coupling of scrollbars could make the tool awkward to use. By supporting only one selected element in the task list for the entire application, using the tool
193
anApplication User
subscribers ,,.
-
coupled, exclusive
aTaskAssiqnmentApp
. taskList
personList w aScrollWrapper
A aCheckBoxModel
f
scrolllndex
checked
Figure 7: Object diagram for the task assignment application
anAoolication User
