Object-Oriented Activity Support: A Model for Integrated ... - CiteSeerX

Object-Oriented Activity Support: A Model for Integrated CSCW Systems Gunnar Teege

Institut fur Informatik, Technische Universitat 80290 Munchen, Germany Tel: 49-89-450552-31 E-mail: [email protected]

Abstract. This paper proposes a model for integrated CSCW systems, the model of Objectoriented Activity Support OOActSM. In contrast to existing systems for the support of collaborative work, the model aims at the integrated support of all aspects of CSCW in a single frame system. The major properties of our model are the use of \activity" as the basic concept and the use of object-oriented mechanisms for providing solutions of typical CSCW problems. I demonstrate how all major aspects of current CSCW systems can be supported and integrated with each other in our model. Key words: Integrated CSCW, activity support, object-oriented paradigm, work ow support, activity design

1. Introduction Nearly all CSCW systems which have been developed so far concentrate on a more or less narrow sub eld of cooperative work. Examples of these sub elds are work ow speci cation, electronic meetings, or collaborative editing. As a consequence, users are forced to employ several dierent CSCW application systems for dierent forms of collaborative work, although these dierent forms are often used during a single work project. A typical example of a work processes including several forms of collaboration are meetings (Begeman et al., 1986). They consist of a phase for the asynchronous preparation of the meeting including meeting scheduling, the synchronous meeting itself, and an asynchronous or even non-collaborative followup phase. The resulting problems of dierent metaphors and user interfaces and of a bad support of data exchange between dierent applications is one reason for the bad acceptance of CSCW systems in practice. Thus, the need for integrated CSCW applications is apparent (Wilson, 1988, p. 222). Integrated CSCW applications could be built by integrating existing applications. However, it is dicult to do this in a way which achieves a true semantical integration of the various aspects. A better approach is to design the application from the beginning as an integrated system. Existing solutions for speci c aspects can be integrated as subsystems, if they are \open" enough. Otherwise, existing approaches have to be adapted and reimplemented, or new solutions have to be implemented as a part of the integrated system.

2

Gunnar Teege

It is clear that CSCW is too large a eld to allow the development of a fully integrated support system accounting for all aspects of cooperative work. At least at the current state of research this is not possible with a sensible amount of eort. Thus, the important dierence between an integrated CSCW system and existing systems must be its extendibility . The underlying model of the system must be general enough so as not to prevent the integration of additional aspects and mechanisms in an easy way. The model must be open to dierent paradigms, such as \document-based" or \work ow-based", and it must allow for the coexistence of dierent paradigms in the application, since they may be of dierent usefulness in dierent situations. In this paper, I propose a model for integrated CSCW systems, the model of Object-oriented Activity Support OOActSM, developed at our institute. Its major properties are the underlying concept of activity and the massive use of mechanisms of object-oriented programming. Activities have been proposed, e.g., by Kuutti (1991), as a basic concept for CSCW research. They have also been used as the basis for CSCW systems, but not in the broad sense in which we use it in OOActSM. Object-oriented programming systems have been used for the implementation of CSCW systems, however, our intent is to apply typical OO mechanisms as solutions for typical problems in the CSCW domain. The paper is organized as follows: First, I give an overview of existing systems related to our model. In the next section I present the main ideas of OOActSM and give some motivations for them. In the last section I describe for all main aspects of current CSCW systems the manner in which these aspects can be represented in OOActSM and how our approach allows OO mechanisms to be directly applied so as to provide solutions for corresponding problems.

2. Existing Systems I roughly separate the existing systems related to our model into three groups. The rst group includes specialized systems supporting only one or a few speci c aspect of cooperative work. An integrated model must be able to embrace all of these speci c approaches, since most of them have proven to be useful within their domain. The second group includes systems supporting activities. They usually use a broader approach than specialized systems. I will describe the activity models of several systems for activity support and later compare our activity model with them. The third group includes systems for integrated support, which address similar goals to those of OOActSM. 2.1. Systems Supporting Specific Aspects A major class of systems is the class of work ow systems, originating mainly in attempts to support oce procedures. Work ow systems are mainly concerned

13/03/1996

3 with the speci cation of the ow of control and data in complex cooperative work procedures. Additional aspects include determining the persons in charge of single steps and the tools used to perform the steps. Work ow systems typically use a speci c speci cation mechanism for work procedures, e.g., extended petri nets. There are document-based systems, such as ProminanD (Karbe et al., 1990). As their main abstraction they use a folder with documents which is passed from one worker to the next. Other systems are server-based, such as DOMINO (Kreifelts et al., 1991a) or Action Work ow (Medina-Mora et al., 1992). They use a central database server for scheduling the work procedures and delegating steps. Related systems are those for supporting structured communications. They are mainly concerned with the organization of complex communication procedures. They support the use of schemas for determining the possible communication steps, the ltering of information, and the actual communication via electronic media. Examples of this kind of system are The Coordinator (Winograd, 1988), Information Lens (Malone et al., 1987), CHAOS (DeCindio et al., 1986), Strudel (Shepherd et al., 1990), and UTUCS (Bignoli et al., 1991). Another class of systems is the class of collaborative editors and systems for conference support. Both allow the synchronous collaborative editing of a shared workspace. In the case of a collaborative editor the workspace contains, e.g., text or graphics information. The main aspect here is the coordination of changes made to the workspace content. Examples of collaborative editors are Quilt (Fish et al., 1988), MultimETH (Lubich and Plattner, 1994), or IRIS (Borgho and Teege, 1993). In systems for conference support the main aspect is that of communication. The workspace content is mainly used to convey ideas to the other conference members. It typically consists of outlines or sketches. Examples are Cognoter (Foster and Ste k, 1986) and GROVE (Ellis et al., 1991). Both kinds of systems may use additional communication facilities, such as a video link. A speci c class of systems is that of meeting scheduling. It is concerned with determining a time slot and, optionally, a place for a meeting of a group of people. Examples are MPCAL (Greif, 1980), the Eden Shared Calendar System (Holman and Almes, 1985) and the Visual Scheduler (Beard et al., 1990). Object-Oriented Activity Support

2.2. Systems Supporting Activities Systems using the notion of \activity" as a central abstraction usually originate from two speci c domains: that of work ow support and that of support for structured communication. They extend the original approach, but still do not cover the full spectrum of cooperative work. In the ACT model described by Kreifelts et al. (1991b) an activity is a net of causally dependent actions. The system supports the coordination of these actions with the help of a semi-autonomous mediator. The mediator schedules the actions and uses action-speci c schemes of structured communication for communicating with the corresponding actor. The MOBILE model described by Jablonski (1994)

to be published in: Computer Supported Cooperative Work --An International Journal

4 Gunnar Teege separates the speci cation of an activity into a functional, a behavioral, an organizational, and an informational part. In contrast to classical work ow systems both models include support for activities which cannot be scheduled automatically and for an incremental speci cation and revision of running activities. The latter is also the main goal of the Regatta system described by Swenson et al. (1994). The systems COSMOS (Dollimore and Wilbur, 1991), and AMIGO (PankokeBabatz, 1989) have their origin in support for structured communication. They extend this approach mainly by putting the conversation actions into a broader context. They support the speci cation of activity templates which also include non-conversational actions. However, cooperation is still based on message exchange. Thus, these systems only support restricted kinds of activities. 2.3. Systems for Integrated Support There are several approaches to achieve integration with the help of toolkits. The COLA platform described by Trevor et al. (1993) provides collaboration support in a separate level below the application. COLA de nes a \lightweight" model of activities, leaving the semantical interpretation to the application. Thus, COLA provides a technical base for application interoperability, however, it does not force a semantical integration of applications. Other toolkits, such as LIZA (Gibbs, 1989) or GroupKit (Roseman and Greenberg, 1992), provide a frame for application integration. However, they concentrate on a rather narrow eld of collaboration support. LIZA supports centralized synchronous tools, GroupKit supports realtime conferencing. An alternative way of achieving integration uses applications with open-ended tailorability, i.e., systems which \can be changed in ways not foreshadowed by the original developer" (Roseman and Greenberg, 1993). In some respects, Lotus Notes (Marshak, 1993) is of this kind. It provides application programming as a part of the system. However, in many other aspects the system is closed. The collaboration model of shared information with optimistic concurrency control and asynchronous message exchange cannot be modi ed by the user. The same holds true for, e.g, the security mechanism, the form-based interface model for documents, and the table-based interface model for databases. More tailorability is typically provided by object-oriented systems, such as the Linkworks system (Jennison, 1994) with a basic functionality similar to that of Notes. Another example is the system PAGES described by Hammainen (1991b). However, although PAGES integrates synchronous and asynchronous collaboration, it does so mainly for structured activities. Support for unstructured activities has been provided by a separate application in the same project (Hammainen, 1991a). The system which is most similar to our approach is Oval, described by Malone (1992) as \radically tailorable". It supports the speci cation of classes of semistructured objects without restricting their use to a speci c collaboration model.

13/03/1996

5 As a demonstration of Oval's tailorability, the functionalities of Notes, the information ltering system Information Lens, the group decision support system gIBIS, and the Coordinator have been integrated in Oval. Two observations have been that object-oriented speci cation and reuse signi cantly increases the end users' power, and that radically tailorable frame systems facilitate integration. Object-Oriented Activity Support

3. The Model of OO Activity Support Now, I will introduce our model of Object-oriented Activity Support in three steps. First, I describe the main parts of the model independently of object-oriented mechanisms. The model abstracts from typical notions of existing systems and integrates them into a broader framework. In the second step I map the parts of the model onto object-oriented mechanisms. Finally, I describe the realization of the model in our prototype system TACTS. As we have seen in Section 2, existing models of collaborative work support are too restrictive. A model for an integrated support must be exible enough to embrace an open-ended set of collaboration mechanisms. The problem of this approach lies in the danger of the model becoming too vague to be of any practical use. The most exible model would be a general-purpose programming system which allows the programming of all mechanisms which are needed. With our model we try to reach a compromise between these extremes. 3.1. Abstraction and Integration As a rst step to our model we need a central basic abstraction. Basic abstractions used by existing systems are work ows, conversations, documents, groups, or conferences. However, none of these are general enough to be the basis of a model covering all aspects of CSCW. We have chosen the concept of \activity" as a basic abstraction. Even the informal semantics of \activity" embraces the basic abstractions mentioned previously: work ows, conversations, and conferences are structured or unstructured activities performed by several participants; documents are produced and used by activities; groups execute collaborative activities. A similar proposal is made by Kuutti (1991) who uses the concept of activity as de ned by activity theory. Our notion of activity bears some similarities to that one. However, since we are interested in a model for an integrated CSCW system instead of a model for general CSCW research, we emphasize the aspects of activities dierently. We also de ne activities in a broader sense compared to that de ned for all systems described in Section 2.2. In our model an activity is characterized as follows (see Figure 1). An activity

? is structured, i.e., consists of an arbitrarily deep hierarchy of sub-activities;

to be published in: Computer Supported Cooperative Work --An International Journal

6

Gunnar Teege activity subactivity structure

executing actor

context

Fig. 1. The Components of an Activity

? is executed by an actor which may be, e.g., a single person, a group of persons,

or a programmed \autonomous agent" in a computer; ? has a context which contains, e.g., tools or information needed, and objects which are changed or produced. This speci cation of activity covers a large number of activity kinds, in particular the following. ? Single-user activities without cooperation, cooperative activities by a group, and activities executed automatically by programmed systems. ? Activities with synchronous or asynchronous coordination and activities in the same place or in dierent places (i.e., all four regions of the common 2x2 time/place matrix of CSCW applications (Ellis et al., 1991)). ? Activities for which the execution may or may not be supported by a computer. Our model supports two main aspects of activities. These are the means of specifying activity kinds and the means of managing activity instances. An important observation regarding work processes is that they often include a design aspect. The actor does not simply execute an activity, he also invents new ways of performing and organizing activity parts. Thereby he modi es and adapts the activity kind. Hence, our model integrates the support for using activity kind speci cations with support for their design. Supporting activity kind design implies the following requirements. First of all, the speci cation of activity kinds must not be restricted to a single speci cation formalism or a speci c content, such as a speci cation of the control ow. A control ow speci cation may be useful for some activity kinds and it may be useless for other kinds. Next, the model must support a wide spectrum of degree of detail. Activity kind speci cations may be rather general, such as \some activity executed by a single person", if the details are not known in advance and are determined while executing the activity. Activity kind speci cations may include a very detailed description of the context and the

13/03/1996

1

7 individual steps, if they describe a schematic work process with a predetermined structure. Finally, it must be possible to reuse existing speci cations by extending or modifying them. It is typical for work processes in a common environment to share many common aspects and to dier only minimally. Consider the activity of sending a letter with the help of a secretary. The common aspects are the subactivities: formulating the content, writing the letter, optional revision, signature, sending. The activities may dier, e.g., in the medium used for sending (surface mail, fax, electronic mail) or the tool used for writing (typewriter, speci c word processing system). Support of activity design is the main basis of the Oval system (Malone, 1992). However, there are also a number of more specialized systems with design support, which has proven to be an important component. Examples are the conversation support system Strudel (Shepherd et al., 1990) and the activity support systems COSMOS, CHAOS, and AMIGO (see Section 2.2). Another example is the approach of \open protocols" described by Roseman and Greenberg (1993). In contrast to activity kinds, activity instances allow the representation and support of concrete activities. There are three main kinds of support for activity instances provided by the system in our model. Structuring: Maintaining the association between activities, their sub-activities, the executing actor, and objects in the context, such as documents. The structure is used for accessing related parts of the activity and for determining the environment in which the activity is performed. History: Collecting information about the activity which is not part of the activity kind. A typical example is time points of events related to the activity, such as its start or completion. Another example is the addressee and content of a letter. The history is used for determining how to proceed with the activity. After completion of the activity the history is used to perform similar activities or to design activity kinds for similar activities, thus reusing the experience gained while executing the activity. Execution: Executing all or part of the activity, possibly under the control of the user. If possible, the system executes sub-steps or organizes the sequencing of steps or the coordination among dierent actors. It depends on the activity kind, whether the system may support execution. Sub-step execution can only be supported if the sub-step can be performed by the computer, such as sending email. Step sequence organization can only be supported if the activity has an execution scheme (such as in work ow applications) which may be mechanically interpreted. These kinds of support for activity instances imply the following requirements. Rich structuring facilities are required for the representation of all activity parts. A state must be maintained for activity instances and instances must provide storing facilities for history informations and for activity-speci c execution procedures. Object-Oriented Activity Support

to be published in: Computer Supported Cooperative Work --An International Journal

8

Gunnar Teege

Note, that the model does not incorporate any speci c theory of coordination or communication. Several theories, such as activity theory (Kuutti, 1991), coordination theory (Malone and Crowston, 1990), communication for action (Winograd, 1988), or the action work ow approach (Medina-Mora et al., 1992) can coexist in the model, and each one can be used for modeling corresponding speci c activity kinds. 3.2. Mapping the Model onto OO Mechanisms The second step is the mapping of the abstract model onto a speci c modeling paradigm for program systems. We chose the object-oriented paradigm for several reasons. The main reason is the inherent design aspect of the work to be supported (see Section 3.1). Usually, object-oriented technology is applied to cope with the problems of software engineering, i.e., the design of software systems. The design of activity kinds bears several similarities to that. In particular, the requirements of dierent speci cation mechanisms for dierent purposes and of speci cation reuse hold for system design in the same way. Therefore, the main new idea of employing object-oriented technology in our model OOActSM is its use for supporting the design tasks of the end-user of the system. Apart from this new use of object-oriented technology, we also use it in the classical way. As Nierstrasz and Tsichritzis (1989) state it, integrated oce systems are inherently very complex software systems and object-oriented technology promises to cope with that complexity. Finally, there are several aspects of object-oriented technology which are not directly concerned with system design. Many demands of our model can be satis ed by such aspects. An example is the distributedness of the system. Object-oriented technology supports distribution through protocols for communication among distributed objects, such as de ned by the CORBA standard (OMG, 1992). Thus, OOActSM provides a frame which allows the application of object-oriented mechanisms to CSCW problems in a more speci c way than they are usually applied to software systems in general. The central idea of the mapping of the abstract activity model onto the objectoriented paradigm is the representation of the activities, of the actors, and of all components of the context by objects. The association between these objects is implemented by the usual container objects or complex objects with object references. Accordingly, the activity kind speci cations are implemented by class speci cations. The design task for activity kinds thus becomes a design task for classes. This provides a basis for satisfying the requirements, such as speci cation reuse, through object-oriented approaches to analysis and design. The same idea is exploited by Bauer et al. (1994). They give a detailed example of modeling a business process as an object, using the modeling technique OMT (Rumbaugh et al., 1991). Since context components, sub-activities, and their association are also represented by objects, the speci cation of activity structures and contexts is covered by

13/03/1996

9 class speci cations as well. Hence, class speci cations provide a uniform framework for the speci cation of all aspects of activities in our model. In particular, Class speci cations support the incorporation of other systems by de ning them as tools and providing methods for their use. Speci c classes of activities may then use the tool, or it may be used manually via the methods. The degree of integration possible depends on the features of the incorporated system. The management of activity instances is directly implemented by the management of object instances. Object instances have \instance variables" or \attributes" for storing instance-speci c information. These attributes are used to store and retrieve the history information of an activity. A persistent storing of this information is achieved with the help of the usual mechanisms for object persistence. The operations applicable to an object instance are determined by the object's class and are implemented by \methods". These class-speci c operations on object instances provide the support for activity execution. Methods may also be de ned for objects in the context, providing operations on these objects which may be executed as a part of performing the activity. The corresponding system architecture for OOActSM is as follows. It is a distributed system consisting of \method execution engines" (MEE) and repositories. The repositories are simple database servers. They store the objects and class descriptions and provide access to them by the MEEs. Each MEE either runs under direct control of a user or acts as an autonomous agent. MEEs execute or initiate all operations on the objects stored in the repositories. This may include the invocation of other programs, such as editors or communication interfaces, for providing speci c functionalities. All methods are executed in the MEEs. To execute a method, the MEE loads the object and its class from the repository. Object modi cations are synchronized by a locking mechanism in the repository. On a higher level, however, the system would support any type of concurrency control mechanism, also optimistic ones. Since the system also supports single-user activities, we incorporate \private" repositories in OOActSM which can only be accessed by one MEE. Private repositories need only provide the functionality of a simple single-user database system. For cooperative activities, however, there must exist \shared" repositories which may be accessed by several MEEs concurrently. The concurrent access to shared objects provides a base for group awareness. The repository has to coordinate the concurrent accesses. However, shared repositories do not constitute a central \coordination facility", such as in database driven approaches. They are merely a mechanism for sharing objects, e.g., a work group may use a shared repository for managing their group activities and storing shared documents. Other groups may use replication of documents. Figure 2 depicts the system architecture. An alternative approach would be an architecture in which all operations on objects are executed in the repositories. The main advantage of this approach is the potential reliability of repositories. In contrast to an MEE which runs on the user's machine, repositories can be installed in a way that they cannot be manipulated by Object-Oriented Activity Support

to be published in: Computer Supported Cooperative Work --An International Journal

10

Gunnar Teege

user1

user2

MEE

MEE

repository

MEE (autonomous) private repository

repository repository

repository

shared

Fig. 2. Architecture of an OO Activity Support System

the users in arbitrary ways. Such a reliable repository can guarantee the semantics of the operations it executes. This kind of reliable operation, such as supervising access rights, is essential in a system for supporting collaborative work of several users. In our architecture an autonomous MEE with a private repository can be used to implement reliable operations. The critical operations are delegated to the autonomous MEE which performs them on the objects in its private repository. No other MEE may access that repository directly. Delegation of operations between MEEs must be based on a mechanism for remote method invocation, as it is included in most distributed object-oriented systems. The CORBA standard (OMG, 1992) provides the corresponding interface. One advantage of operation execution in the MEE is the direct access to the user interface. In our architecture every object can implement its own user interface in any way supported by the hard- and software of the user's machine. This is an important aspect in a system for integrating all possible ways of supporting activities. As an example, activity kinds are not restricted to using a window-mouse interface; speci c activity kinds may use audio or video hardware for communicating with the user. As another advantage of operation execution in the MEE, the repositories need only provide the functionality of a passive database system. Therefore, the repositories may be implemented by existing database systems or object repositories. We call systems corresponding to the OOActSM model Object-oriented Activity Support Systems. In contrast to most existing CSCW systems, as mentioned in Section 2, they allow the integrated support of all aspects of cooperative and non-cooperative activities.

1

13/03/1996

11

Object-Oriented Activity Support

class instance

aggregate

multiple inheritance

Fig. 3. Two Approaches to Aspect Combination for Instances

3.3. Realization of the Model To further illustrate the model I will describe two design issues of our prototype realization TACTS: the component for classes (ELIOOS) and the component for modeling instance states (HieraStates). As I have already stated, the reuse of activity kind speci cations or parts thereof is an important requirement due to the design aspect of activity support. Reuse is most eective if activity kind speci cations are maximally broken up into single aspects which may then be combined in any way needed by the user. A single aspect of an activity kind may be any part of the speci cation, such as a speci c sub-activity, a possible state, an operation, a coordination scheme, a tool, a speci c part of the history information to be collected, a speci c aspect of an object in the context, etc.. In OOActSM, where activity kind speci cations are class speci cations, this implies technically a ne-grained class hierarchy (Johnson and Rees, 1992). Every class speci es only a single aspect. The classes must be exibly combinable by the user who may thus determine the aspects needed for a speci c activity. This toolkit-like combination of classes supports the simplest form of activity design by the user. The combination of aspects modeled by classes, yielding an instance containing all these aspects, can be done in two ways. In the rst approach, for every class an instance is created. All these instances become a part of the main instance which is represented by the aggregate of the single instances. Each instance handles one aspect. The overall behavior of the main instance emerges from the collaborative behavior of the parts. I call this the \aggregate approach" to aspect combination. It is depicted in the right half of Figure 3.

to be published in: Computer Supported Cooperative Work --An International Journal

1

12

Gunnar Teege

The aggregate approach is quite common in object-oriented systems. A typical example is systems where standard aspects of objects, such as the user interface or persistent storing must be implemented by separate instances. Several development systems based on Smalltalk or other languages without multiple inheritance use this approach. The aggregate approach is also the idea behind the \adapters" in the COLA toolkit (Trevor et al., 1994). Existing instances without collaborative features are enhanced through separate adapter instances which provide collaborative aspects, such as locking or access control. The second way of combining aspects modeled by classes uses multiple inheritance. The classes are combined to yield a new class which inherits from all classes used in the combination. Then the instance is created as an instance of the new class. The instance's behavior is determined by the new class which integrates all aspects from the combined classes. I call this the \multiple inheritance approach" to aspect combination. It is depicted in the left half of Figure 3. One advantage of this approach is the compact representation of entities, such as activities, by single instances instead of by an aggregate of instances for every aspect. In a ne-grained class hierarchy with many single aspects the aggregates become complex and their collective behavior is dicult to manage. On the other hand, most schemes of multiple inheritance in object-oriented languages do not support aspect combination well enough. If several dierent aspects inherited from dierent superclasses concern the same class slot, e.g., a method, usually all but one of the aspects must be neglected (\overridden"). Only few languages, such as CLOS (Lawlers and Miller, 1991), support more complex combination schemes for multiply inherited slots. Another advantage of the aggregate approach is the possibility of dynamically rearranging the aggregate. Instances implementing speci c aspects may be removed, and instances for other aspects may be added. In particular, this allows an incremental construction of the instance during its use. It has been argued by Swenson (1993) and others that incremental instance construction is a vital requirement in the domain of work support. In TACTS we have chosen the multiple inheritance approach for avoiding complex aggregates. Its disadvantages are overcome by the speci c object-oriented system ELIOOS developed as a basis for TACTS. In ELIOOS, a new scheme of multiple inheritance is used which supports the exible combination of inherited slots. The main idea is to inherit functions for constructing and modifying slot values instead of inheriting the slot values themselves. This approach is described in more detail by Teege (1993b). Additionally, ELIOOS supports \transient classes" which may be added to and removed from existing instances dynamically. Based on ELIOOS, TACTS consists mainly of a ne-grained hierarchy of ELIOOS classes. A prototype of a class hierarchy covering single user support for electronic mail, request-answer sequences, and working with TEX documents includes approximately 130 classes and has been described in detail by Teege (1993a). The second component of the implementation to be described here supports a state-dependent behavior of instances. An instance has a state-dependent behav-

13/03/1996

13 ior, if the set of available operations and their implementations is not determined by the instance's class alone, instead, the behavior may change over time and depends on the instance's current state. In the object-oriented domain there are two main approaches to state-dependent behavior. Predicate classes (Chambers, 1993) are automatically used for instances at run-time if an associated predicate is satis ed. Thus, the possible states and state transitions are implicitly determined by the predicates and by the operations changing the instance. On the other hand, there are approaches based on state-transition diagrams, making states and transitions explicit. However, these approaches are mostly used during object-oriented analysis and design (Graham, 1994), e.g. in OMT (Rumbaugh et al., 1991) or OSA (Embley et al., 1992), not at run-time. More elaborate mechanisms extend simple state-transition diagrams by using hierarchical states. Examples are the Statechart mechanism introduced by Harel (1987) and the ROOMcharts mechanism introduced by Selic et al. (1994). In OOActSM, support for state-dependent instance behavior has to satisfy the following two main requirements: providing support for the design and for the use of activities by the user and supporting reuse. Since no such mechanism existed we developed the HieraStates mechanism de ned by Teege (1994) as a part of our prototype TACTS. HieraStates is a diagram-based approach with explicit states and transitions. The diagrams provide a model of the state-dependent instance behavior which can be investigated by the user as a source of information for designing and using the corresponding objects. In approaches with implicit states and transitions it is much more expensive to create such a model, and it may even be impossible. In contrast to most diagram-based approaches, HieraStates diagrams are used at run-time. The user may inquire the current state of an instance, the operations applicable in that state, possible followup states and the transitions or transition sequences leading to those states. The system uses the diagram for identifying operation implementations depending on the current state of the instance. Figure 4 depicts an example of a HieraStates scheme. It describes activities which have the three main states \unstarted", \active", and \ nished". The state \unstarted" has two substates \planned" and \canceled", the state \ nished" has two substates \aborted" and \completed". Initial states are marked by an arrow which starts in a lled dot. HieraStates uses hierarchical states and a corresponding transition model for at least three reasons. Hierarchical states provide a structuring of the diagrams and they help control the explosion in the number of states, as described by Harel (1987). Hierarchical states are useful for providing the means of handling exceptional situations by the user. In HieraStates, if a transition cannot be completed due to an exceptional situation, transitions starting in the next surrounding state are still applicable and may be invoked to handle the situation. An example is the transition abort in Figure 4. It is de ned in the outermost state. Hence, it is applicable in any substate, such as \active". Additionally, it is applicable whenever Object-Oriented Activity Support

to be published in: Computer Supported Cooperative Work --An International Journal

14

Gunnar Teege

abort

unstarted cancel

planned canceled

complete

activate

nished

active reset

restart

aborted completed

Fig. 4. HieraStates Example

a transition, such as complete , blocks in between substates due to an exceptional situation. Finally, hierarchical states are useful for supporting the reuse of diagram parts. HieraStates diagrams are implemented by speci c ELIOOS class slots. The ELIOOS inheritance mechanism thus provides multiple inheritance for diagrams, based on diagram combination. The hierarchical structure of the HieraStates diagrams allows for several useful ways of diagram combinations, including the union and product of state sets. This is described in detail by Teege (1994). An example is depicted in Figure 5. The re nement of the states \unstarted" and \ nished" into substates is done separately. If the two schemes in the lower part of the gure are combined the diagram of Figure 4 results. Matsuoka et al. (1993) have pointed out, that the use of diagram-based approaches for supporting state-dependent behavior at run-time inherently con icts with the use of inheritance. They call this eect \inheritance anomaly". However, the reason for this anomaly is the lack of ne-grained modi cations of inherited methods in all common object-oriented systems. In HieraStates this anomaly disappears, since the inheritance mechanism of ELIOOS supports ne-grained modi cations both for method implementations and for state-transition diagrams.

4. Application of the Model In this section I investigate in more detail the way in which several important aspects of CSCW systems can be represented and integrated with each other in OOActSM. In all cases either ELIOOS and HieraStates or existing OO mechanisms provide the necessary functionality or a basis for it. By mapping CSCW aspects to OO mechanism it becomes possible to use these mechanisms or even corresponding implementations as part of the activity support system. The use of existing

1

13/03/1996

15

Object-Oriented Activity Support activate active reset

unstarted

complete nished restart

abort

activate

unstarted cancel

active reset

restart

reset

complete

planned canceled

complete

active

nished

restart

activate

unstarted

nished aborted completed

Fig. 5. Incremental Scheme Speci cation

mechanisms and standards, such as CORBA (OMG, 1992), or the work ow reference model of the Work ow Management Coalition (Tate, 1995) is particularly important for a frame system such as that in OOActSM. The main goal of this section is to demonstrate that OOActSM allows in fact the integration of all major aspects of the CSCW systems mentioned in Section 2 in a single system. The approaches described here are examples of how this can be achieved. They are not, however, part of OOActSM. 4.1. The User Interface As mentioned previously, the user interface is realized by the MEEs which run under the control of a user on his local machine. Aside from supporting the visualization of the objects and the displaying of the necessary information about them, the user interface should also support the following general operations by the user:

? Con guring the object display, e.g., by sorting or ltering. ? Navigating among the object structures. ? Initiating the execution of methods by object instances.

to be published in: Computer Supported Cooperative Work --An International Journal

1

16

Gunnar Teege

? Generating and destroying object instances. ? Changing the structure of objects. ? Managing transactions, e.g., beginning, committing, or aborting a transaction. ? Selecting the repositories to be used. ? Initiating the migration of objects between repositories. The rst two operations are local to the interface and provide the necessary basis for the user to perform the remaining operations. The last ve operations should be included in order to support exibility. Theoretically they could all be performed implicitly as a part of the method execution of certain objects. However, in the domain of CSCW it is too restrictive to automate everything. There is always the need for manual control in exceptional situations. Generating and destroying object instances allows for manually introducing additional sub-activities in an activity instance or introducing additional objects within the context of an activity. Changing the structure of an object allows for manually rearranging the sub-activities or the context members of an object. Managing transactions allows the manual combination of several single operations into an atomic operation. Selecting repositories and moving objects between repositories provides for the manual control which allows decisions to be made on the use of a private or a shared repository and on the use of speci c repository implementations. Most of these operations are typical features of user interfaces which support the direct manipulation of objects. A common example of this kind of interface is graphical le managers on personal computers. They display the objects of interest ( les and directories) by graphical units (icons). Operations are invoked by mouse gestures, such as clicking or drawing, or by menus. This kind of user interface was the driving force for the development of early object-oriented systems, such as Smalltalk. Another important feature of the user interface is the speci cation of the activity kind for instances upon instance creation. In OOActSM an activity kind is determined by a combination of classes chosen from a toolkit-like ne-grained class hierarchy. The system has to oer mechanisms for the user to visualize this hierarchy and select one or more classes to be assigned to a new instance. This approach and the necessary support by the user interface is described in more detail by Teege (1993b). Since all components in activity contexts are speci ed by classes as well, this approach also applies to the creation of instances of context components. Compared to Oval (Malone, 1992), we do not restrict the interface to a formbased display of objects. A form-based interface is useful for many objects in OOActSM and should be a default for most classes. However, other kinds of objects can pro t from other interface paradigms, such as using the desktop metaphor, e.g., for collections of information, or using the room metaphor, e.g., for meetings. Of

13/03/1996

17 course, new interface paradigms are typically not introduced by the end-user of the system. Nevertheless, the model should not restrict the interface to only one paradigm. In TACTS the user interface is implemented by transient ELIOOS classes. These classes are only used for an instance in speci c situations and may be removed afterwards. Thus, it is possible to access the same object through dierent user interfaces (e.g., on dierent system architectures). At the same time the interface functionality may still depend on the object's class, if a corresponding interface class is provided for each interface. The current TACTS prototype includes one text-based interface implemented in the Emacs editor and one graphical X interface implemented in LISP. An X interface implemented in the script language TCL/TK is in preparation. Object-Oriented Activity Support

4.2. Workflow Specification Work ow support is an important facet of activity support. However, most existing work ow support systems have two disadvantages: they concentrate too much on the work ow aspect alone and they do not support work ow speci cation by the user (Swenson, 1993). On the other hand, several parts of work ow systems, such as the providing of a task context, are applicable in a broader way to activity support. As a consequence, the work ow-speci c parts should be integrated in a general activity support system (Schlichter and Teege, 1994). In this section I describe how to achieve this integration in OOActSM. If a work ow is mapped into OOActSM, it becomes an activity with additional predetermined information about its structure and execution. Sarin et al. (1991) and Abbott and Sarin (1994) list several requirements for work ow support systems. I will explain how these requirements are satis ed in the framework of object-oriented activity support. The requirements of using an explicit representation of the collaborative process, of providing a task context, and of working in a distributed environment are directly satis ed by the model. Activities are represented by object instances which include a context and can be accessed by distributed MEEs. The requirement of \openness", of supporting arbitrary external activities and tools, is satis ed as a consequence of the integrated approach in OOActSM. It does not restrict the kinds of activities in any way. The requirement of process monitoring is satis ed by inspecting the activity history, particularly the activity's current state. The requirement of routing the work to the responsible individual corresponds to determining the executing actor of the activity. This is described in Section 4.6. The requirement of support for authorization and access control becomes a special case of access control for objects in OOActSM. Object-oriented access control models have an established history in operating systems and database management systems. Hence, existing solutions can be applied here.

to be published in: Computer Supported Cooperative Work --An International Journal

18

Gunnar Teege

The remaining requirements mainly concern the most typical part of work ow speci cations: the execution scheme. If work ows are mapped to activities in OOActSM, the work ow execution scheme must be mapped to a component of the class specifying the activity kind. We propose to extend and use the component which speci es the dynamic object behavior. The HieraStates mechanism of our prototype is designed in a way that it can be used for the speci cation of work ow execution schemes. The requirement of supporting the provision of policies is satis ed by the shared class hierarchy. Since an execution scheme is a part of a class speci cation, it may be used for any number of work ow instances. Every policy corresponds to a class which may be instantiated or extended by inheriting from it. The requirement of evolutionary process development is also satis ed by the way in which classes are used in OOActSM. Classes, and particularly their HieraStates slots may be extended and combined. Classes with execution scheme components may be added to existing instances, thus providing delayed speci cation of execution scheme parts. The user interface supports the selection of classes for instances (see Section 4.1) and thus the selection of execution scheme parts. Finally, the history of instances may be used to abstract its speci c way of execution to an execution scheme. A simple way of doing this is to retrieve the class mix which has been accumulated during the existence of an instance and reuse this mix for similar activities. The last requirement concerns the exibility of the scheme speci cation. It must allow for the handling of exceptional situations, for the mixing of schematic and non-schematic parts, and for the use of human judgment in addition to and even instead of the prede ned scheme options. In OOActSM this is achieved by separating the structural aspect and the aspect of execution for work ows in a way similar to the work ow model of Jablonski (1994). The structuring of activities into sub-activities is fully independent of the execution scheme used for organizing the activity's dynamic behavior. The execution scheme may organize a part of the activity's sub-activities, while other parts are organized manually by the user. Execution scheme and structuring are orthogonal mechanisms. As a consequence, this kind of execution scheme can generally not be interpreted automatically by a \work ow engine". The primary use of execution schemes in OOActSM is to provide help to the user. The execution scheme provides suggestions for actions to be taken for an activity instance. The user may decide whether to select a suggested action or to escape from the scheme and perform a manual action. He may even modify the scheme by adding classes to the instance. As a special case, execution schemes may also be executed automatically by autonomous MEEs. The amount of intelligence in the MEE restricts the kind of schemes it can execute. In the simplest case all possible execution paths must be de ned in the scheme and the MEE corresponds to a work ow engine. In this case the Work ow Reference Model (Tate, 1995) of the Work ow Management Coalition can be supported, however, the system is not restricted to it.

13/03/1996

19

Object-Oriented Activity Support Class MainAct execution scheme:

main1 activate

unstarted :::

active

:::

:::

sub1

method implementations: activate: create sub1 of class SubAct; :::

:::

Fig. 6. The Indirect Association of a Sub-activity with a Transition

To illustrate our approach, I conclude this section by a description of the manner in which the execution scheme interacts with the activity structure in our prototype TACTS. In HieraStates, each transition is associated with a method. The method implementation may perform any programmable operation. Additionally, it may cause the transition to stop, resulting in a current state of the instance which lies between the transition's starting state and its destination state. The user may resume the transition at a later time. The method is executed again, continuing from the interrupt point, and it may stop the transition again. As a special case, a transition may be associated with a set of sub-activities of the instance. Upon transition invocation the sub-activities may already exist or they may be newly created by the transition method. Usually, the transition is nished only if all sub-activities are nished. In this is the case the transition method will stop the transition as long as there are un nished sub-activities associated. This indirect connection between a transition and a sub-activity is depicted in Figure 6. The instance sub1 is created in the body of the transition method of transition activate in the execution scheme of the class MainAct. The class MainAct de nes the behavior of the instance main1. This simple mechanism provides an extremely exible integration of activity structure and activity behavior. Sub-activities associated with the same transition may be executed in parallel. Sub-activities may be manually created and associated with a transition, even if the transition has already been invoked. If the sub-activity has its own execution scheme, a hierarchical scheme results, as usual in most work ow models. However, the sub-activity need not be organized by a scheme, thus allowing for non-schematic sub-activities in a schematic activity.

to be published in: Computer Supported Cooperative Work --An International Journal

1

20

Gunnar Teege x subject, determine participants.

arrange time

conference

multicast to answer participants

protocol produce

distribute

Fig. 7. A possible Execution Scheme for a Conference

As an example, Figure 7 depicts a possible scheme of managing a conference. It uses two schematic sub-activities for arranging the time and preparing the protocol and two sub-activities without an execution scheme for xing the subject and determining the participants and for the conference itself. Compared with the work ow applications mentioned in Section 2.1, our approach supports both the server-based and the document-based case. In the server-based case the activity object resides in a single autonomous MEE, in the documentbased case the activity migrates among the user-local MEEs. 4.3. Asynchronous Cooperation The base for implementing forms of asynchronous cooperation are mechanisms for asynchronous communication or noti cation. In OOActSM we may distinguish between three cases of asynchronous communication mechanisms. 1. The use of a tool which is external to the OO system, such as electronic mail, usenet news, surface mail, or fax. 2. The use of object migration as communication medium. 3. The use of shared objects as communication medium. In the rst case the communication is integrated into the OO activity system as follows. The actions of sending and receiving are modeled as activities and are represented by objects. In most cases these activities are non-collaborative, since the sending or receiving actions are executed by single actors. The activity may include a preparation phase (e.g. composing a message before sending) or a succession phase (e.g. storing a message after reception). The context contains at least an object representing the transmitted information and an object representing the communication tool. Additionally, information about the communication partner may be represented by an object, if a partner exists, i.e., the communication does not have the form of broadcasting. Depending on the communication tool, the execution of sending and receiving activities may be supported by the system. For electronic mail, usenet news, or fax,

1

13/03/1996

21 support is possible depending on the connectivity provided by the computer system in use. The sending and receiving of surface mail usually cannot be supported, however, the preparation (composing and printing) of a letter can be supported and the sending itself can be recorded in the activity history. The second case of asynchronous communication uses migrating objects as the communication medium. It is similar to the rst case, however, the execution of sending and receiving can always be supported by the system, since it is implemented by the internal migration mechanism. The message itself is represented by an object migrating to the receiver. Sending may include the migration from the sender's private repository to a shared repository. Receiving may include the migration from the shared repository to the recipient's private repository. In the third case the communication medium is an object in a shared repository. Sending is done by storing the transmitted information at the object, receiving is done by retrieving the information from the object. An example of this kind of shared communication objects is mailboxes. Our approach to asynchronous communication has the following advantages. Since sending and receiving is modeled by activities, these actions may be used as sub-steps in other activities. Thus, the kind of asynchronous coordination can be speci ed as part of the activity speci cation by using corresponding communication activities as sub-steps. It is possible to specify coordination schemas, such as the delegation of sub-steps or request-answer schemas, through corresponding sequences of communication sub-activities. Dierent activity kinds can use dierent coordination schemas. Furthermore, it is possible to specify structured communications by combining communication activities with work ow speci cations. Thus, all cases of structured communication, as mentioned in Section 2.1 can be supported by OOActSM and can be integrated with activities of other kinds. Object-Oriented Activity Support

4.4. Synchronous Cooperation Synchronous cooperation requires the combined action of several users at the same time. This may be modeled by the use of a shared coordination object. The following cases exist for the object's semantics:

? The object may represent the artifact which is manipulated by the coopera-

tive activity, such as a document. The current state of the object is visible to all MEEs. Coordination mechanisms, such as locks or oor passing are implemented by methods of the object. Thus they can be speci cally designed for speci c artifact kinds.

? The object may represent the act of cooperating, such as a conference. In

this case it is used for coordination and communication only. Methods of the object implement communication operations, such as the opening of a video connection.

to be published in: Computer Supported Cooperative Work --An International Journal

22

Gunnar Teege

? The object may represent the group of users which constitutes the activity's

executing actor. In this case the methods on the object implement operations concerning the group, such as joining or leaving. Typically, the operation for joining the group includes access controls. The execution of synchronous cooperative activities may be supported by the system with the help of speci c tools for synchronous collaborative work, such as a collaborative editor or a video connection. These tools are represented by objects and are invoked by the system. In this way OOActSM integrates the cases of collaborative editing and conference support, as mentioned in Section 2.1. The speci cation of states and transitions used for work ow modeling are applicable to synchronous cooperative activities as well. In all three cases of the semantics of the coordinating object, states and transitions may be used to specify the coordination of operations on the object and the coordination of the activity. An example of states in a synchronous activity are the phases of the Drexler/Sibbet group process described by Johansen et al. (1991). The concurrent access by several MEEs to a shared object provides the base for group awareness. The consequences of every operation changing the object's state can potentially be observed by all other users. The user interface determines which changes are displayed and how they are displayed. Since autonomous MEEs change object states in the same way as MEEs under user control, awareness also covers the observation of operations performed by autonomous agents. The three cases of semantics may also be combined. As an example, it is possible to model both the edited document and the group of editing users by a common object. Then the object's state re ects both the state of the group and that of the document and it may take into account dependencies between them. An example of such a dependency is the fact that the document content cannot change when the work group is empty. A systematic approach to this kind of semantic integration has been proposed by Teege and Borgho (1993). 4.5. Activity Context The context of an activity may be represented by a separate object, or it may be a part of the compound activity object. In the rst case the context is associated with the activity via a reference and a speci c context may belong to several activities. These kind of independent contexts are similar to the contexts used in the EuroCoOp activity coordination model (Hennessy et al., 1992). In the second case the context is local to the activity. However, parts of the context may still be implemented by references and thus be shared among several activity contexts. In both cases the context structure is modeled with the help of container objects, such as sets or sequences. The members of a context are objects which may represent ? artifacts manipulated by the activity, such as documents,

13/03/1996

Object-Oriented Activity Support

23

? artifacts used for performing the activity, such as documents or tools, ? persons or other actors, such as organizations, involved in the activity, ? other information items, such as goals or policies. Context components need not be accessible to the activity support system. As an example, a document can only be accessible to the system if it is stored in electronic form; as another example a car engine produced in an activity can only be accessible in a fully integrated CIM environment. Nevertheless, inaccessible components must be represented by objects in the system, in order to allow the support of structuring contexts and the protocoling of the states of the components and the actions performed on them. Sub-activities are represented by objects as well. Therefore, there is technically no implementational dierence between sub-activities and context components. As a consequence, it is possible to integrate the activity structure and the activity context. Together they may be speci ed in a uniform way as a part of the class speci cation. As mentioned previously for work ow speci cations, inheritance among classes can be applied to support incremental speci cations of structure and context. Finally, since all context components are objects, they may have contexts themselves, in the same way in which activities have contexts. As an example, the context of a document may contain all activities performed on it, all the users who contributed to it, and all documents referenced by its content. Thus, OOActSM supports a tight integration of activity-based systems, such as work ow systems, with document-based systems which mainly support the storing, retrieval, versioning, and manipulation of documents. 4.6. Actor Assignment An object in the context of another object is either speci cally produced for its use in that context, or it is selected from existing objects and a reference to it is added to the context. In OOActSM we call the latter process \instance assignment". Instance assignment applies to all kinds of objects in the context of an activity, such as tools or information sources used by the activity. However, many CSCW systems treat the case of assigning \actors" in speci c ways, since it tends to be more complicated than other cases. An actor is an active entity which executes the activity or is involved in the activity in other ways. Examples of actors are humans, groups, organizations, departments, or programmed agents. However, in OOActSM it is not possible to draw an exact border between actors and non-actors. A human may be used in an activity as an information source in the same way as a database. Thus, in our view \actor" is not a property of the object. Instead, the term merely subsumes several methods of instance assignment which are typically applied to active entities. We call this special case \actor assignment".

to be published in: Computer Supported Cooperative Work --An International Journal

24

Gunnar Teege

Instance assignment in general is speci ed by the object's class. The class determines which references are contained in the context and how the instances to be referenced in a speci c context are to be found. An example is the reference to the executing actor which is a part of the context of every activity. In the simplest case an activity instance is executed by the actor who initiates its creation. When the activity instance is created the initialization method of its class determines the actor associated with the MEE process and uses that actor for initializing the reference to the executing actor. In the case of a user MEE the associated actor represents the user. It is determined from the system environment upon starting the MEE process. Since actors are used by many MEEs they must exist in a shared repository. This repository contains available actors and possibly other organizational units, such as departments, or organizational relations, such as \is manager of". Thus, the repository corresponds to the \organizational structure" used in several CSCW systems as a model of the organizational environment. Usual object-oriented mechanisms are employed to represent this environment. If an actor involved in an activity is not yet known upon instance creation, the activity class must de ne operations for actor assignment. This includes de ning when the assignment should occur and how the actor is to be determined. The former can be done with the help of object states, as described in Section 4.2, the latter can be done by de ning a corresponding method. As an example, consider the case of delegation. In a delegated activity the executing actor is not identical to the initiating actor. The initiating actor creates the activity instance and is assigned immediately. Before the activity is performed the initiator must add speci c information, such as the document to be worked on, and assignment of the executing actor must take place. The actor may be assigned manually by the initiator. This is a simple yet frequently used method of delegation. Moreover, manual assignment is a basic operation usually supported by all activity classes. Hence, it can be used for exception handling, if other assignment methods de ned by the class do not work in a speci c case. Manual assignment is possible whenever the activity is manipulated in a user's local MEE. Most work ow support systems use role-based actor assignment, since that can be done automatically. Roles are named. Each actor is associated with the roles he can play. An actor needed for an activity is speci ed by specifying the role. Actor assignment is done by choosing an actor who can play the speci ed role. In OOActSM this is easily implemented by storing the role names an actor can play in an attribute of the actor object. Role-based actor assignment and manual assignment can also be combined, letting the initiator choose among all actors who can play the speci ed role. However, as Jablonski (1994) states it, this role-based approach is too simple for many real-world cases. In addition to the role, actor assignment may depend on speci c properties of the activity instance. One example is the case where

13/03/1996

25 the actor for signing a project contract depends on the project's budget. Another example uses history information and assigns an actor which has executed a speci c other activity instance. This case is typical for sub-activities of a larger activity. Consider the review of a revised paper which should be done by the same actor who reviewed the original paper. It seems that no xed scheme of actor assignment can provide the necessary exibility to handle all cases occurring in the real world. In OOActSM, actor assignment is speci ed by methods. Thus actor assignment can be speci ed with maximal exibility. On the other hand, inheritance and method combination, as described in Section 3.3, can be applied to specify actor assignment policies incrementally and to select the appropriate policy for an activity instance by choosing a corresponding class. Another aspect of actor assignment is actor noti cation. Noti cation is necessary if some action is expected from an assigned actor and the actor does not yet know that he has been assigned to the activity. The typical case is that of delegation. The executing actor must be noti ed after assignment. This noti cation must include all relevant information. Actor noti cation is a case of asynchronous or synchronous cooperation, as described in Sections 4.3 and 4.4. Asynchronous actor noti cation is done by sending the necessary information to the actor. The addressing information must be determined from the actor object. As an example, an actor object representing a user could contain the email address in an attribute. If the actor to be noti ed does not use the activity support system, the information is sent as a text to be read by a human. Thus it is possible to include actors using the system and actors not using the system in the same activity. This aspect is important for an incremental introduction of an activity support system in an organization. If the recipient uses the support system, the noti cation should result in providing access to the activity object or should provide a copy of it for the recipient. The noti cation includes a reference to the activity object or the activity object migrates to the recipient. Alternatively the noti cation only contains the classes and initialization information to create a copy of the activity object at the recipient. Synchronous actor noti cation is possible if the activity is shared by all potential actors. If an actor is assigned this is re ected in the information displayed about the activity and the actor is thus informed. Of course, synchronous noti cation only works if all potential actors watch the activity object and respond to their assignment by performing the corresponding action. In most cases an acknowledgment by the actor is useful. An example is a conference where the chair assigns an actor for writing the protocol. Finally, shared objects provide another way of actor assignment. The actor can assign himself to the activity. Other potential actors are automatically noti ed through their realization of the change in the activity's state. The synchronization mechanism for object access by MEEs guarantees that only one actor can assign himself to the activity. An extension of this scheme allows a shared activity to be Object-Oriented Activity Support

to be published in: Computer Supported Cooperative Work --An International Journal

26 Gunnar Teege selected several times by dierent actors, where each actor executes only a part of the activity or the actors collaborate in executing the activity. 4.7. Activity Design As mentioned in Section 3.1, a major task of an activity support system is supporting activity design. Current systems mainly support the execution of activity schemes. The design of schemes is supported by providing a speci c speci cation language and simple mechanisms for adding new schemes to the system. Special experts are needed who extend the system in this way. The resulting systems are in exible and incapable of supporting all activities performed by the users. This is a major reason for the lack of acceptance of this kind of systems. Systems which address this problem, such as Regatta (Swenson, 1993), usually employ a graphical mechanism for specifying the execution scheme of activities. In OOActSM activity design becomes class design. The simplest case is the selection of appropriate classes from the class hierarchy during instance creation, as described in Section 4.1. In more complex cases activity design is itself an activity which produces a new class. This re ective situation corresponds to the typical re ective situation of meta-objects in OO systems. In many systems, such as in CLOS or in Smalltalk, classes are themselves objects, often called \meta-objects". If classes are objects, their manipulation can be represented in OOActSM as an activity with the class in its context. As a consequence, activity design simply is a kind of activity, where the produced artifact in the context is an activity class speci cation. Thus, in OOActSM activity design is fully integrated among other activities and can pro t from features used for arbitrary activities. Activity design may be done collaboratively, it has a structured context, and it may be done in several sub-steps which are speci ed in an execution scheme. The meta-objects can be implemented as specializations of documents, since they have several aspects in common with documents. They have versions, they can be displayed and edited, they can be transmitted over communication media, and they can be processed (e.g., compiled or analyzed). For the practical application, however, we need to specify in which concrete way a class speci cation is produced. Again, we use the exibility of the objectoriented approach. It is not necessary to restrict the system to one speci c way of producing class speci cations. Design activities, like all other activities, are described by their class. Hence, it is possible to use dierent ways of class design in the system and to de ne additional ways if needed. In particular, a new way of class design can be designed using an existing way. Figure 8 depicts the situation. Just as a normal activity produces a product, a design activity produces an activity kind speci cation. It seems sensible to provide a whole spectrum of class design mechanisms which covers mechanisms from simple restricted ones, such as instantiating parameters

13/03/1996

27

Object-Oriented Activity Support design activity kind

:::

design activity kind meta-objects

produces design activity activity

produces produces

activity kind object

product

Fig. 8. Activity Design: Producing Meta-objects

of an existing class, to fully programming a class in an object-oriented language. A mechanism in the lower part of the spectrum is programming by example, as it is employed in the OTM system (Lochovsky et al., 1988). The user performs an activity manually and the system abstracts it to a class, possibly inquiring additional information about alternatives from the user. The middle part of the spectrum includes graphical programming interfaces. They support the graphical design of certain activity aspects, such as designing the scheme for dynamic behavior with the help of a graphical representation. Of course, for using complex design mechanisms expert knowledge is needed and the corresponding design activities are performed by specialists, like other complex activities. In addition to the complexity, activity design can be dierentiated by the kind of activity which is designed. Dierent classes for activity design may support the design of oce procedures, of teleconferences, or of document development. Finally, since an activity and its context form a system of objects, methods for object-oriented analysis and design, such as OMT (Rumbaugh et al., 1991) or OSA (Embley et al., 1992), can be employed in activity design. The use of these methods may become a part of the design activity, as speci ed by the corresponding classes. The integration of new activity speci cations into the existing system can pro t from methods for schema evolution which have been developed for object-oriented database systems (Banerjee et al., 1987). They allow for the addition of classes to a class hierarchy and for the restructuring of the hierarchy. 4.8. Coordination and Consistency An important aspect of CSCW systems is the technical support for coordination of concurrent processes and for the consistency of the manipulated data. Most of the

to be published in: Computer Supported Cooperative Work --An International Journal

1

28

Gunnar Teege 1

3

4 1

m1

sub1

2

sub2

m2

5

sub3

Fig. 9. Instances Aected by Coordination Issues

existing approaches, such as transactions, originated in the eld of database technology. They have been extended for use in CSCW and other advanced database applications in several ways, such as long-running transactions, compensation transactions, or interdependence between transactions (Dayal et al., 1990). In OOActSM, existing techniques in OODB systems can be used as a basis, providing coordinated access to the objects. More elaborate techniques are built on top as part of the activity support system, by implementing the techniques with the help of methods. We will consider this in more detail for the main aspects of technical coordination in CSCW systems. For every numbered point below, Figure 9 depicts the aected instances in a schematic example of two activities m1, m2 with sub-activities. 1. Data consistency for single activities and between dierent activities. This is implemented by making methods atomic operations, which is supported by most distributed OO systems. 2. Coordination of the sub-activities of a single activity instance. This is organized with the help of HieraStates speci cations (see Section 4.2). 3. Semantic consistency of the context of a single activity instance. This is solved with the help of extended transaction mechanisms. They allow, e.g., the modeling of the activity as a set of interdependent long-running transactions. The extended transaction mechanisms can be implemented inside the activity support system. It is a part of the activity kind speci cation. Dierent speci c mechanisms can thus be used for dierent activity kinds. 4. Exception handling in a single activity instance. The handling of expected exceptions is speci ed in the control ow speci cation by the corresponding HieraStates scheme. Unexpected exceptions are handled manually by the user. The user may, e.g., invoke a speci c method, abort a long-running transaction, or create additional sub-activities. See also Section 4.2.

1

13/03/1996

29 5. Coordination of the sub-activities of dierent activity instances. This must be organized with the help of additional shared coordination objects in the context of all aected activities. An example is the coordination of mutual exclusive sub-activities with the help of a semaphore object. Again, this kind of coordination objects can be easily implemented with the help of atomic methods. Object-Oriented Activity Support

5. Conclusion In this paper I have de ned the model of Object-oriented Activity Support OOActSM. The model provides a general framework for the design of integrated CSCW application systems with the help of object-oriented mechanisms. The basic abstraction of the model is the concept of activity. The model supports both collaborative and non-collaborative activities, it supports synchronous and asynchronous coordination and it supports the representation of activities and activity contexts in a uniform framework. One important consequence of OOActSM is the fact that OO mechanisms become available for the systematic application to CSCW problems. In particular, it helps by providing design facilities for the end-user. I have shown in some detail how all major aspects of current CSCW systems can pro t from existing solutions in the domain of OO systems. As a test for the model and the ideas presented here, we have developed a prototype of an Object-oriented Activity Support System, the TACTS system (Teege, 1993a). It is built on top of the object-oriented system ELIOOS, which has been speci cally developed for this purpose. Implementations of ELIOOS exist in Emacs Lisp and in Common Lisp, an implementation in C is in preparation. TACTS itself is a collection of classes, written in the language TACTS-L. TACTSL is partly interpreted and partly compiled and can be used in any ELIOOS implementation. Until now, TACTS has mainly supported non-collaborative document preparation and asynchronous communication and coordination, in particular via electronic mail and USENET news. Additionally, TACTS already supports the use of HieraStates for the speci cation and management of ow control in simple activities. Activity design is still restricted to programming classes in TACTS-L and to combining classes at run-time with a menu-based mechanism. Future work will include the extension of TACTS for the support of additional activity kinds and additional design mechanism, as described in this paper. At the same time we will try to identify additional cases where object-oriented mechanisms can be usefully applied to CSCW problems and can help to integrate dierent forms of collaborative work.

to be published in: Computer Supported Cooperative Work --An International Journal

30

Gunnar Teege

References

Abbott, K. R. and Sarin, S. K.: 1994, Experiences with Work ow Management: Issues for the Next Generation, in R. Furuta and C. Neuwirth (eds), Proc. of the Conf. on Computer Supported Cooperative Work CSCW'94, ACM Press, New York, pp. 113{120. Banerjee, J., Kim, W., Kim, H.-J. and Korth, H. F.: 1987, Semantics and Implementation of Schema Evolution in Object-Oriented Databases, Proc. of ACM/SIGMOD Annual Conf. on Management of Data, Vol. 16 of SIGMOD Record, ACM Press, pp. 311{322. Bauer, M., Kohl, C. and Mayr, H. C.: 1994, Enterprise Modeling Using OOA Techniques, in G. Chroust and A. Benczur (eds), Work ow Management { Challenges, Paradigms and Prod ucts. Proc. CON'94, Vol. 76 of Schriftenreihe der Osterreichischen Computer Gesellschaft, Oldenbourg, Wien, Munchen, pp. 96{111. Beard, D., Palanappian, M., Humm, A., Banks, D. and Nair, A.: 1990, A visual calendar for scheduling group meetings, Proc. of the Conf. on Computer Supported Cooperative Work CSCW'90, ACM Press, Los Angeles, California. Begeman, M. et al.: 1986, Project NICK: Meetings Augmentation and Analysis, Proc. of the Conf. on Computer Supported Cooperative Work CSCW'86, ACM Press, Austin, Texas, pp. 1{6. Bignoli, C. et al.: 1991, UTUCS: A Support for Synchronous and Asynchronous Communication, in K. Gorling and C. Sattler (eds), International Workshop on CSCW, number 4 in Informatik Informationen Reporte, Institut fur Informatik und Rechentechnik, Berlin, Germany, pp. 74{ 84. Borgho, U. M. and Teege, G.: 1993, Structure Management in the Collaborative Multimedia Editing System IRIS, in T.-S. Chua and T. L. Kunii (eds), Proc. Int. Conf. on Multi-Media Modeling (MMM '93), World Scienti c, Singapore, pp. 159{173. Chambers, C.: 1993, Predicate Classes, in O. M. Nierstrasz (ed.), ECOOP'93 { Object-Oriented Programming, Lecture Notes in Computer Science 707, Springer, Berlin, pp. 268{296. Dayal, U., Hsu, M. and Ladin, R.: 1990, Organizing Long-Running Activities with Triggers and Transactions, in H. Garcia-Molina and H. Jagadish (eds), Proceedings of the 1990 ACM SIGMOD Int. Conference on Management of Data, Vol. 19 of SIGMOD RECORD, ACM press, pp. 204{214. DeCindio, F. et al.: 1986, CHAOS as Coordination Technology, Proc. of the Conf. on Computer Supported Cooperative Work CSCW'86, ACM Press, Austin, Texas, pp. 325{342. Dollimore, J. and Wilbur, S.: 1991, Experiences in Building a Con gurable CSCW System, in J. M. Bowers and S. D. Benford (eds), Studies in Computer Supported Cooperative Work, North-Holland, Amsterdam, pp. 173{181. Ellis, C., Gibbs, S. and Rein, G.: 1991, Groupware { Some Issues and Experiences, Communications of the ACM 34(1), 38{58. Embley, D., Kurtz, B. and Wood eld, S.: 1992, Object-Oriented Systems Analysis: A Model-Driven Approach, Yourdon Press, Englewood Clis, NJ. Fish, R., Kraut, R. and Leland, M.: 1988, Quilt: A Collaborative Tool for Cooperative Writing, in R. Allen (ed.), Proc. of ACM SIGOIS/IEEE TC-OA Conf. on Oce Information Systems, Vol. 9 of ACM SIGOIS Bulletin, pp. 30{37. Foster, G. and Ste k, M.: 1986, Cognoter, Theory and Practice of a Colab-orative Tool, Proc. of the Conf. on Computer Supported Cooperative Work CSCW'86, ACM Press, Austin, Texas, pp. 7{15. Gibbs, S. J.: 1989, LIZA: An Extensible Groupware Toolkit, in K. Bice and C. Lewis (eds), Human Factors in Computing Systems. Proc. of CHI'89, ACM Press, pp. 29{35. Graham, I.: 1994, Object Oriented Methods, 2 edn, Addison-Wesley. Greif, I.: 1980, Programs for Distributed Computing: The Calendar Application, Technical report, MIT Laboratory for Computer Science, Cambridge, MA. Hammainen, H.: 1991a, Form and Room: Metaphors for Groupware, in P. de Jong (ed.), Proc. of the Conf. on Organizational Computing Systems COOCS'91, ACM, ACM Press, pp. 95{105. Hammainen, H.: 1991b, Form-based Approach to Distributed Cooperative Work, Acta Polytechnica Scandinavica, Mathematics and Computer Science Series, Ma 58.

13/03/1996

Object-Oriented Activity Support

31

Harel, D.: 1987, Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming 8, 231{274. Hennessy, P., Kreifelts, T. and Ehrlich, U.: 1992, Distributed Work Management: Activity Coordination within the EuroCoOp Project, Computer Communications 15(8), 477{488. Holman, C. and Almes, G.: 1985, The Eden Shared Calendar System, Technical report, Department of Computer Science, University of Washington, Seattle WA. Jablonski, S.: 1994, MOBILE: A Modular Work ow Model and Architecture, Proc. of Int. Working Conference on Dynamic Modelling of Information Systems. Jennison, L.: 1994, Selected Software for Supporting Co-operative Work, in K. Spurr, P. Layzell and L. Jennison (eds), Computer Support for Co-operative Work, John Wiley & Sons, Chichester, chapter V, pp. 217{246. Johansen, R. et al.: 1991, Leading Business Teams, Addison-Wesley, Reading, MA. Johnson, P. and Rees, C.: 1992, Reusability Through Fine-grain Inheritance, Software { Practice and Experience 22(12), 1049{1068. Karbe, B., Ramsperger, N. and Weiss, P.: 1990, Support of Cooperative Work by Electronic Circulation Folders, in F. Lochovsky et al. (eds), Conference on Oce Information Systems (SIGOIS Bulletin), ACM. Kreifelts, T., Hinrichs, E., Klein, K., Seuert, P. and Woetzel, G.: 1991a, Experiences with the DOMINO oce procedure system, in L. Bannon, M. Robinson and K. Schmidt (eds), Proc. of the European Conf. on Computer Supported Cooperative Work ECSCW'91, Dordrecht, Boston, London: Kluwer Academic Publ., Amsterdam, The Netherlands, pp. 117{130. Kreifelts, T., Pankoke-Babatz, U. and Victor, F.: 1991b, A Model for the Coordination of Cooperative Activities, in K. Gorling and C. Sattler (eds), International Workshop on CSCW, number 4 in Informatik Informationen Reporte, Institut fur Informatik und Rechentechnik, Berlin, Germany, pp. 85{100. Kuutti, K.: 1991, The concept of activity as a basic unit of analysis for CSCW research, Proc. of the European Conf. on Computer Supported Cooperative Work ECSCW'91. Lawlers, J. and Miller, M.: 1991, Understanding CLOS, Digital Press. Lochovsky, F. H., Hogg, J. S., Weiser, S. P. and Mendelzon, A. O.: 1988, OTM: Specifying Oce Tasks, in R. B. Allen (ed.), Proc. Conf. on Oce Information Systems, Vol. 9 of SIGOIS Bulletin, ACM, pp. 46{54. Lubich, H. P. and Plattner, B.: 1994, The MultimETH Conferencing and Joint Editing System, Collaborative Computing 1(2), 147{162. Malone, T. and Crowston, K.: 1990, What is Coordination Theory and how can it help design cooperative work systems?, Proc. of the Conf. on Computer Supported Cooperative Work CSCW'90, ACM Press, Los Angeles, California. Malone, T. W.: 1992, Experiments with Oval: A Radically Tailorable Tool for Cooperative Work, in J. Turner and R. E. Kraut (eds), Proc. of the Conf. on Computer Supported Cooperative Work CSCW'92, ACM Press, New York, pp. 289{297. Malone, T. W., Grant, K. R., Lai, K.-Y., Rao, R. and Rosenblitt, D.: 1987, Semi-structured messages are surprisingly useful for computer-supported coordination, ACM Transactions on Oce Information Systems 5(2), 115{131. Marshak, D. S.: 1993, Understanding and Leveraging Lotus Notes, in-depth research report, Patricia Seybold Group, Boston, MA. Matsuoka, S., Taura, K. and Yonezawa, A.: 1993, Highly Ecient and Encapsulated Re-use of Synchronization Code in Concurrent Object-Oriented Languages, in A. Paepcke (ed.), Proc. OOPSLA'93, Vol. 28 of SIGPLAN Notices, ACM Press, pp. 109{126. Medina-Mora, R. et al.: 1992, The action work ow approach to work ow management technology, Proc. of the Conf. on Computer Supported Cooperative Work CSCW'92. Nierstrasz, O. and Tsichritzis, D.: 1989, Integrated Oce Systems, in W. Kim and F. Lochovsky (eds), Object-Oriented Concepts, Databases and Applications, ACM Press and AddisonWesley, pp. 199{215. OMG: 1992, The Common Object Request Broker: Architecture and Speci cation, OMG Document 91.12.1, Object Management Group, X/Open.

to be published in: Computer Supported Cooperative Work --An International Journal

32

Gunnar Teege

Pankoke-Babatz, U. (ed.): 1989, Computer Based Group Communication: the AMIGO Activity Model, Ellis Horwood, Chichester. Roseman, M. and Greenberg, S.: 1992, GroupKit: A Groupware Toolkit for Building Real-Time Conferencing Applications, in J. Turner and R. E. Kraut (eds), Proc. of the Conf. on Computer Supported Cooperative Work CSCW'92, ACM Press, New York, pp. 43{50. Roseman, M. and Greenberg, S.: 1993, Building Flexible Groupware Through Open Protocols, in S. Kaplan (ed.), Proc. of the Conf. on Organizational Computing Systems COOCS'93, ACM Press, New York, pp. 279{288. Rumbaugh, J. et al.: 1991, Object-Oriented Modelling and Design, Prentice Hall, Englewood Clis, NJ. Sarin, S. K., Abbott, K. R. and McCarthy, D. R.: 1991, A Process Model and System for Supporting Collaborative Work, in P. de Jong (ed.), Proc. of the Conf. on Organizational Computing Systems COOCS'91, ACM, ACM Press, pp. 213{224. Schlichter, J. and Teege, G.: 1994, Managing Tasks in the Oce Environment, Workshop at the 1994 CSCW Conference: Work ow = OIS? Selic, B., Gullekson, G. and Ward, P. T.: 1994, Real-Time Object-Oriented Modeling, John Wiley & Sons, New York. Shepherd, A., Mayer, N. and Kuchinsky, A.: 1990, Strudel: An Extensible Electronic Conversation Toolkit, Proc. of the Conf. on Computer Supported Cooperative Work CSCW'90, New York: SIGCHI/SIGOIS ACM, Los Angeles, CA, pp. 93{104. Swenson, K. D.: 1993, Visual Support for Reegineering Work Processes, in S. Kaplan (ed.), Proc. of the Conf. on Organizational Computing Systems COOCS'93, ACM, ACM Press, pp. 130{ 141. Swenson, K. D. et al.: 1994, A Business Process Environment Supporting Collaborative Planning, Collaborative Computing 1(1), 15{34. Tate, A.: 1995, Work ow Management Coalition Homepage, World Wide Web, URL http://www.aiai.ed.ac.uk/WfMC. Teege, G.: 1993a, The Activity Support System TACTS, Technical Report TUM{I 9306, Inst. fur Informatik, Technische Universitat Munchen, Munich, Germany. also available from URL http://www11.informatik.tu-muenchen.de/. Teege, G.: 1993b, Type Selection at the User Interface, in C. Rathke, J. Kopp, H. Hohl and H. Bretthauer (eds), Object-Oriented Programming in Lisp: Languages and Applications. A Report on the ECOOP'93 Workshop. (Arbeitspapiere der GMD 788), Gesellschaft fur Mathematik und Datenverarbeitung, Sankt Augustin, pp. 39{47. Teege, G.: 1994, HieraStates: Flexible Interaction with Objects, Technical Report TUM{I 9441, Inst. fur Informatik, Technische Universitat Munchen, Munich, Germany. also available from URL http://www11.informatik.tu-muenchen.de/. Teege, G. and Borgho, U. M.: 1993, Combining Asynchronous and Synchronous Collaborative Systems, in M. Smith and G. Salvendy (eds), Proc. 5th Int. Conf. on Human-Computer Interaction, Elsevier Science Publ. B.V., Amsterdam, pp. 516{521. Trevor, J., Rodden, T. and Blair, G.: 1993, COLA: A Lightweight Platform for CSCW, in G. de Michelis, C. Simone and K. Schmidt (eds), Proc. of the European Conf. on Computer Supported Cooperative Work ECSCW 93, Kluwer Academic Publishers, Dordrecht, pp. 15{30. Trevor, J., Rodden, T. and Mariani, J.: 1994, The Use of Adapters to Support Cooperative Sharing, in R. Furuta and C. Neuwirth (eds), Proc. of the Conf. on Computer Supported Cooperative Work CSCW'94, ACM Press, New York, pp. 219{230. Wilson, P.: 1988, Key Research in Computer Supported Cooperative Work, in R. Speth (ed.), Research into Networks and Distributed Applications: Proc. of EUTECO'88, Elsevier, pp. 211{ 226. Winograd, T.: 1988, A Language/Action Perspective on the Design of Cooperative Work, Human Computer Interaction 3(1), 3{30.

13/03/1996