Shared data modeling withUML-G

Jessica Rubart and Peter DawabiFraunhofer Institute Integrated Publication and Information Systems (IPSI),Dolivostrasse 15, 64293 Darmstadt, GermanyE-mail: {rubart, dawabi}@ipsi.fhg.de

Abstract: Groupware is explicitly designed to support the cooperation among groupmembers. The implementation of cooperation-aware groupware is supported by severalobject-oriented toolkits and frameworks, but there is no uni®ed way to model applicationsbuilt on top of these. We have proposed UML-G as an extensible UML pro®le formodeling groupware and are in the process of turning it into a community e�ort. In thisarticle, we identify modeling needs speci®c to shared data modeling. Shared data is aprerequisite to supporting cooperating users. We present UML extensions to address theidenti®ed needs as a part of UML-G. Usage scenarios demonstrate how UML-G can beused to assist shared data modeling. UML-G provides explicit modeling of shared datarelated aspects. In addition, it supports a shared understanding between developers, whichis independent of, and thus abstracts from, the latter implementation. CASE tool supportfor UML-G strengthens its practical relevance.

Keywords: groupware, shared data modeling, UML, UML-G.

Reference to this article should be made as follows: Rubart, J. and Dawabi, P. (2004)`Shared data modeling with UML-G', Int. J. of Computer Applications in Technology, Vol.19, Nos. 3/4, pp. 231±243.

1 INTRODUCTION

Groupware is explicitly designed to support the co-operation among group members [1]. This can be in adistributed or co-located setting. In addition, it can besynchronous or asynchronous. Synchronous coopera-tion means cooperation happening at the same time withtypically ®ne-grained noti®cations giving immediatefeedback about the activities of other users, whereasasynchronous cooperation can happen at di�erent timeswith usually no noti®cations of other users' actions [2].

The implementation of cooperation-aware group-ware is supported by several object-oriented toolkits andframeworks, but there is no uni®ed way to modelapplications built on top of these. The Uni®ed ModelingLanguage (UML) [3, 4] is the standard notation formodeling object-oriented software. A UML Pro®lespecializes the UML for a speci®c domain. We haveproposed such a pro®le for groupware (UML-G) [5] inorder to assist developers in explicit modeling ofgroupware related needs, such as shared data.

There are several groupware tools available, such ase-mail systems, shared repositories, shared workspacesystems, e.g., BSCW (Basic Support for Cooperative

Work) [6], audio/video-conferencing, shared white-boards or sharing support for single user applications.Sometimes it is su�cient for groupware developers toselect a single-user tool, such as an o�ce suite's wordprocessor, and combine it with a shared repository inorder to support asynchronous editing of documents.To support synchronous editing, sometimes it issu�cient to combine the word processor and the sharedrepository with an application-sharing tool, such asMicrosoft's NetMeeting [7]. But there are also obviousrestrictions, e.g., by using an application-sharing toolonly strict WYSIWIS (What You See Is What I See)functionality can be supported. Moreover, no work-space awareness (if there is any workspace) can begivenÐ in the sense of an up-to-the-moment under-standing of another person's interaction [8]. That's whyapplication-sharing tools belong to the cooperation-transparent class of groupware. To develop newcooperation-aware applications, object-oriented toolkitsand frameworks, such as DistView [9], GroupKit [10],COAST [11], JSDT [12], Habanero [13] and DyCE [14]have become available. All these toolkits and frame-works have their special way of using them. There is nouni®ed way to model applications built on top of these.

In this paper, we identify modeling needs speci®c to

International Journal of Computer Applications in Technology, Volume 19, Nos. 3/4, 2004 231

Copyright # 2004 Inderscience Enterprises Ltd.

shared data modeling. Shared data is a prerequisite tosupport cooperating users. We present UML extensionsto address the identi®ed needs as a part of UML-G. Themodeling language UML-G is designed as an extensibleUML pro®le. With this language, groupware developersare supported in modeling their cooperative applicationsindependent from the latter implementation. Thissupports

* explicit modeling of groupware related needs; and* a shared understanding between developers, which is

independent of and thus abstracts from the latterimplementation.

The remainder of this paper is organized as follows:The next section deals with a problem descriptionrelated to shared data modeling, which leads to a listof requirements UML-G has to ful®ll. Then, UMLextensions are de®ned for UML-G, which address theidenti®ed requirements. Afterwards, usage scenarios arepresented that utilize UML-G's current shared datamodeling part. They talk about Computer-SupportedCooperative Work (CSCW) and Learning (CSCL)applications. Next, we talk about CASE (ComputerAided Software Engineering) tool support for UML-Gin order to strengthen its practical relevance. After-wards, related work is presented. The paper ends withconclusions and plans for future work.

2 SHARED DATA MODELING

This section identi®es modeling needs speci®c to shareddata modeling. These are core requirements for model-ing groupware because shared data is a prerequisite tosupporting cooperating users. First of all, we need amodeling element marking shared data. This is impor-tant for asynchronous and synchronous cooperation. Inboth settings shared data is accessed and manipulated.Therefore, this is our ®rst requirement:

R1. A modeling element marking shared data is needed.

Asynchronous cooperation requires persistent data;otherwise di�erent persons at di�erent points in timecan`t continue work. In addition, if synchronous workneeds to be continued later or at least the results need tostay available, persistence is also required for synchro-nous cooperation:

R2. Shared data requires the option to be modeled as

persistent.

In some scenarios the data persistence is limited to aspeci®c time. Once created, (data-) objects used in suchscenarios are supposed to exist only for a prede®nedperiod of time. This can be relevant for work¯ow-management systems, embedded systems or simulationsin natural sciences, to name only a few. Thus, we alsoneed to support:

R3. Time-dependent persistent shared data.

Synchronous cooperation requires noti®cations ofother users' interactions since it is explicitly designed tosupport simultaneous work. These noti®cations are alsoimportant for the provision of awareness. Hence,changes of shared data need to be propagated:

R4. Noti®cations on shared data need to be supported.

Since several users access shared data, access controlcan be necessary. Therefore, there is a need for modelingaccess-controllable shared data:

R5. Shared data requires the option to be marked asaccess-controllable.

Groupware toolkits and frameworks usually provideconcurrency control mechanisms so that shared data iskept consistent though multiple users access it simulta-neously. But it might be necessary due to somesemantics of the cooperative application that sharedinformation should be explicitly locked, e.g., when using¯oor control mechanisms. Floor control can be used tomoderate the cooperation. Only one person at one pointin time is in charge of the ¯oor and hence able to changesome shared data. Locking is independent of the userswho access the shared data so that it di�ers from accesscontrol (note that this requirement does not address theusage of concurrency control techniques, such asoptimistic and pessimistic concurrency control):

R6. Shared data requires the option to be marked as

lockable.

Di�erent cooperative applications can have di�erentneeds related to the distribution of shared data [15].Even one and the same cooperative application canmake use of di�erent distribution schemes for its shareddata objects. Thus, for shared data modeling we needthe option of specifying the distribution scheme:

R7. Optional speci®cation of the distribution scheme for

shared data.

Users of cooperative applications need a model ofthemselves so that, for instance, access control mechan-isms can be applied to them. In addition, users may beinterested in information about other users, or aware-ness regarding users may be necessary. In general, weare talking about actors, such as users, teams or evensystem parts, which are designed as user representatives.Actors need a model of themselves. Moreover, actorscan ®ll roles:

R8. Shared models of groupware actors and roles need

to exist.

The concept of an `activity' is important as a basicabstraction to model all aspects of CSCW [16]. Work-¯ows, conversations, or conferences can basically beexpressed as structured or unstructured activities.

232 J. RUBART AND P. DAWABI

Several actors can participate in a shared or cooperativeactivity by taking roles and manipulating potentiallyshared data through cooperative tools. Thus, theactivity itself is shared data as several actors can beinvolved and need to interact. This leads to our last corerequirement we have identi®ed:

R9. We need a modeling element for shared activities.

Table 1 below summarizes the identi®ed requirements.

3 UML-G AND SHARED DATA MODELING

Based on the identi®ed requirements we have designed ashared data modeling part of UML-G by using theextension mechanisms of UML. The shared datamodeling part itself is also designed in an extensiblemanner.

3.1 Extension mechanisms of UML

UML provides three mechanisms for extension: stereo-types, tagged values and constraints. Stereotypes classifyother UML elements and thus represent variations ofthem with the same structure, but a di�erent intent,respectively. In general, a stereotype represents a usagedistinction. Tagged values are (Tag, Value) pairsattaching information to a model element and thusrepresenting properties. Constraints allow the speci®ca-tion of new semantics (a condition or restriction) for amodel element linguistically in some textual language.For details see [3]. A UML pro®le is a prede®ned set ofstereotypes, tagged values, constraints, and notationicons, which tailor the UML for a speci®c domain. Sucha pro®le does not extend the metamodel of the UML(that de®nes classes, attributes, stereotypes etc.), but itprovides modeling elements for specializing standardUML to a particular domain. This has the advantagethat CASE tools supporting the UML extensionmechanisms can be con®gured to support modelingwith the pro®le (see Section 5).

Since the UML speci®cation does not provide aformal approach for de®ning the semantics of newstereotypes, tagged values and constraints, we describethe semantics of UML-G informally.

3.2 Syntax and semantics of UML-G's current shared

data modeling part

According to the requirements we have one basic modelelement that is shared data (R1). This model element canbe further speci®ed by e.g., lockable or persistence.Therefore, we have introduced the stereotype�shared� and decided to de®ne constraints or taggedvalues on it to extend its semantics. The stereotype�shared� applies to the UML baseclass Element,which is the class in the UML metamodel at the very topof the inheritance tree. Thus, the stereotype �shared�can be applied to any UML model element. Instances ofelements marked as�shared� are potentially accessiblefrom all users. This marking is completely independentfrom the latter implementationÐwhether it will berealized by e.g., using replicated architecture, one-to-many communication channels or remote objects. Ashared element can be further speci®ed by the Booleantagged value {lockable} in case it is used in a scenariowhere, for example, ¯oor control needs to be supported(R6). We have chosen a Boolean tagged value in orderto indicate whether locking needs to be supported ornot. If the cooperative application developer wants tospecify the locking in more detail, she can use standardUML model elements, such as associations and OCL(Object Constraint Language) constraints [17]. Wehaven't yet identi®ed speci®c OCL constraints, whichneed to be prede®ned in the pro®le. Note that you canleave out the value of a Boolean tag, if it is set to TRUE.

Similarly, we have designed the extensions {access-controllable} and {observable} (R5, R4). A shared modelelement can be marked as {access-controllable}, whichmeans that during runtime access control mechanismscan be applied. It can be marked as {observable} toexpress that noti®cations about changes are possible.This is important to support synchronous cooperation,which usually needs ®ne-grained noti®cations. We havechosen the term observable in order to use a more activeterm. And again, by using e.g., associations and OCLconstraints from standard UML more details on thesemantics can be expressed by the groupware developer.A persistence tagged value (R2) is already available instandard UML and is de®ned on the model elementsassociation, attribute and classi®er (which is a supertypeof e.g., class). Hence, it can easily be combined withUML-G. If we need this tag on other UML modelelements as well, we need to de®ne it. For now, theexisting tag is su�cient. However, in order to addressR3 we have introduced a tag called time-persistence,which can be used to specify time-dependent persistentshared data. It can be set to a String value, whichspeci®es the period of time a shared data-object issupposed to be kept persistent.

In order to specify the distribution scheme for shareddata (R7) we have de®ned the tag {distribution={cen-tral, asymmetric, semi-replicated, replicated}} based onthe proposed distribution schemes in [15]. For any

Table 1 Summary of requirements for shared data modeling.

R1 Shared dataR2 Persistent shared dataR3 Time-dependent persistent shared dataR4 Notifications on shared dataR5 Access control on shared dataR6 Lockable shared dataR7 Distribution scheme for shared dataR8 Shared models of groupware actors and rolesR9 Shared activities

233SHARED DATA MODELING WITH UML-G

shared data its distribution scheme can be speci®ed tocentral, asymmetric, semi-replicated, or replicated.

In order to model roles and actors of cooperativeapplications (R8), we have introduced the stereotypes�sharedRole� and�sharedActor�. We have de®nedthem as subtypes of �shared� (see Figure 1) so thatthe tags de®ned on �shared� can also be applied tothem. This is important since according to the require-ments, models of groupware users are also shared data,on which e.g., noti®cations regarding changes need to bepossible. For example, it needs to be noti®ed whether auser is online or o�ine.

In addition, �sharedRole� and �sharedActor�are separate stereotypes in order to mark their specialmeaning. With �sharedRole� roles in cooperativesessions are indicated and with �sharedActor� actorsin cooperative sessions are marked that can take severalroles. Similarly, we have designed a shared activityaccording to R9. Adding new sub-stereotypes in orderto make explicit special shared data can extend this`stereotype-framework'. These sub-stereotypes inheritthe possibility of applying the Boolean tags {access-controllable}, {lockable} and {observable} as well as thetags {time-persistence={. . .}} and {distribution={cen-tral, asymmetric, semi-replicated, replicated}} to them.Moreover, additional tagged values or special con-straints can be de®ned on the general stereotype�shared� or on special sub-stereotypes. Furthermore,a sub-stereotype can specialize the baseclass to which itapplies by naming a subclass of the parent-stereotype'sbaseclass. We de®ned for instance that the stereotypes�sharedRole� and �sharedActor� apply to classes,rather than to any model element. We de®ned thestereotype �sharedActivity� on Class, ActionState,and SubactivityState. This stereotype on classes isimportant to include shared activities in domain datamodels of cooperative applications. ActionState andSubactivityState are the basic metamodel elements ofUML 1.4 that represent activities in activity diagrams[3]. Activity diagrams can be used to detail use cases.Thus, it is important to make explicit shared activities.In the context of UML 2.0 activity diagrams are nolonger special state diagrams anymore, which makesthem original. As soon as UML 2.0 is adopted we needto adapt the baseclass de®nition for �sharedActivity�to include activities represented in activity diagrams ofUML 2.0 properly.

For the super-stereotype �shared� it is alsoimportant to apply it to other model elements thanclasses. In the following, some examples are given: The

stereotype �shared� applied to attributes is needed inorder to support high granularity. It can be that agroupware developer wants to model some attributes asshared, but not the whole class. If the whole class ismarked as �shared�, this is synonymous with mark-ing each attribute as�shared�. In addition, if a sharedclass is marked with tags, these tags apply to eachattribute since all of them are shared. The stereotype�shared� applied to events is important for state andactivity diagrams in order to express shared events, e.g.,if a user does something special on the user interface,then for other users having the same view this is doneautomatically. A shared event can be locked for examplein order to disallow a special activity on the userinterface until a special constraint is ful®lled. Thestereotype �shared� applied to messages is importantfor sequence and collaboration diagrams to expressshared messages. If a user sends a shared message to anobject, then for other users accessing the same objectthis message should also be sent. A shared message canbe observable for example in order to express explicitlythat other users are noti®ed about sending this message.The stereotype �shared� on associations expressespotentially accessible associations for all users so that allusers can e.g., navigate via this association to relatedobject(s) in case the association is not hidden due to forexample access control mechanisms. Table 2 summarizesthe de®ned UML-G elements and brie¯y describes theirsemantics (we do not include icons for the di�erentstereotypes yet).

3.3 Telepointer example

A telepointer appears at exactly the same position onevery participant's screen. Often it is visualized as anarrow. Users can move telepointers to point to somepart of a shared document. An example telepointer classis detailed in the class-diagram of Figure 2. It isassociated with the roles Tutor and Learner, instancesof which represent roles participating in cooperativesessions. That's why both classesÐTutor and Lear-nerÐare marked with the stereotype �sharedRole�.Both associations are named move because the actors®lling the roles are allowed to move the telepointer, i.e.,to change the Xpos and Ypos attributes. For thisreason, the Telepointer class is marked as �shared�.The semantics of the stereotype is extended by theBoolean tagged value {lockable} because in this examplea tutor needs to have the functionality to lock the accessto the Telepointer, i.e., by using it exclusively. Addi-tional constraints assigned to the association(s) can beused to detail the locking (e.g., by using OCL).

The tag {observable}, applied to the whole class,indicates that noti®cations on changes regarding allattributes need to be supported. This is because learnersand tutors are able to observe the movements of atelepointer visualization. The tag {access-controllable}indicates access control to the telepointer. In this

Figure 1 Stereotype-framework.

234 J. RUBART AND P. DAWABI

example, tutors need to be able to control the access. Anadditional constraint assigned to the association be-tween Tutor and Telepointer details the access control.Both associations are marked as �shared� since it isvisible who, at one point in time, is accessing thetelepointer. Note that a coupling degree, i.e., how manyusers use the same telepointer, can be speci®ed bycardinalities of the associations. The distribution schemefor the Telepointer class is speci®ed to replicated sincehigh responsiveness is crucial here.

3.4 Relations to design patterns

To simplify Figure 2, the class diagram presentedfocuses on data modeling and not on the visualization.Note that also visualization classes or only attributes ofthem can be marked as �shared�. UML-G does notenforce any design pattern. A pattern names a designstructure as a solution to a problem in a particularcontext and thus increases our vocabulary [18]. It's like atemplate that one can apply in di�erent situations.UML-G can help writing down object-oriented designpatterns for groupware in a framework-independentway, e.g., specifying shared data appropriately. Inaddition, UML-G can be extended to include anygroupware pattern explicitly, i.e., UML extensions can

be speci®ed to express patterns [5]. Moreover, a CASEtool can be tailored to perform an automatic transfor-mation to the pattern. The pattern in turn can be takeninto account by the CASE tool in order to generate codefor a special framework or toolkit (see Section 5).

4 USAGE SCENARIOS

This section presents two usage scenarios in order toillustrate the applicability of UML-G in two of ourprojects. It demonstrates the practical relevance ofUML-G for modeling groupware. The ®rst example isrelated to a cooperative laboratory environment andfocuses on group members and access to sharedartifacts. The second scenario is concerned withcooperative hypermedia and complements the ®rst oneby combining UML-G with the persistence Boolean tagfrom standard UML, a UML constraint as well asobject and state diagrams.

4.1 CoopLab

The following usage scenario origins from an internalproject named CoopLab. In CoopLab we develop aJava-based virtual learning environment for biotech and

Table 2 Summary of UML-G's current shared data modeling part.

Name Type Applies to Description

�shared� Stereotype Element Instances are potentially accessible from all users

�sharedRole� Stereotype Class Subtype of �shared�; marks roles in cooperative sessions

�sharedActor� Stereotype Class Subtype of�shared�; marks actors in cooperative sessions

�sharedActivity� Stereotype Class, ActionState,SubactivityState

Subtype of �shared�; marks cooperative activities

{time-persistence = {. . .}} String tag Stereotype �shared� Specifies time-dependent persistence

{access-controllable} Boolean tag Stereotype �shared� Access control mechanisms can be applied to instances

{lockable} Boolean tag Stereotype �shared� It is possible to lock instances

{observable} Boolean tag Stereotype �shared� Notifications about changes of instances are possible

{distribution = {central,asymmetric, semi-replicated, replicated}}

Enumerationtag

Stereotype �shared� Specifies the data distribution scheme

Figure 2 Telepointer example.

235SHARED DATA MODELING WITH UML-G

other kind of experiments [19, 20]. One project goal ofCoopLab is the development of a software frameworkwith the aim of supporting the implementation ofcooperative virtual laboratories. The framework iscalled CoopLab because an important aspect of theframework is to allow cooperative learning in virtuallabs. Each virtual scenario consists of several work-benches, whereby each one provides a scenario for aspecial part of an experiment (see Figure 3).

The framework itself is designed according to theModel-View-Controller approach. A model, a view anda corresponding controller class implement each labdevice or tool. While the controller and the view classesare responsible for user interaction and visualization,the model class implements the internal behavior andfunctionality of a virtual device or tool.

An ice pot in a biotech lab for example has thefunction of keeping devices like reaction tubes cooleddown. The ice pot, which is part of our virtual lab, canaccommodate up to three tubes (see Figure 3).

As a small usage scenario we model the classesIcePot, Tube and Substance from the frameworkapplication and the classes Tutor and Student in oneclass diagram by using some of our shared datamodeling extensions of UML-G (see Figure 4). Theclasses Tutor and Student model the di�erent roles aperson can adopt in a virtual lab scenario. The classTutor implements the role of a tutor in the virtual lab.Analogous to the real world a tutor has the task ofsupervising and assisting the students during theexecution of a virtual experiment.

Dealing with an ice pot in a cooperative lab scenario,

Figure 3 An ice pot with inserted tubes in a virtual biotech lab.

Figure 4 The class IcePot and some of its associated classes.

236 J. RUBART AND P. DAWABI

we need a tutor who directs one or more students withinserting one or more reaction tubes into the ice pot inorder to keep them cooled down in the virtual scenario,when the experiment protocol requires it. Doing that thetutor of such a shared experiment uses the ice pot in thevirtual lab mainly as a demonstration platform and lessfor the purpose of ful®lling the next step of theexperiment. Regarding cooperation in a virtual lab itis important for the participating students to be able toobserve the actions of the tutor. Vice versa, the systemshould provide the functionality that the students can beobserved by the tutor while they are doing a workingstep in the virtual lab.

A typical cooperative situation could be that a tutordemonstrates a task (for example: `Insert tube x into theice pot') and the students are supposed to watch andrepeat it. In analogy to real world experiments the tutorneeds to be able to observe the actions of the students,whenever he or she wants to do it. But in contrast, thestudents may only watch the tutor, when they havepermission to do so.

In Figure 4 you see the class diagram of the classIcePot and the corresponding classes Student and Tutor,which are marked with the stereotype �sharedRole�.The associations between Tutor and IcePot as well asStudent and IcePot are named uses. Furthermore, bothassociations are stereotyped�shared�. This stereotypefor associations means that the associations are sharedwith respect to visibility and changeability. A tutorshould ideally be able to recognize at any time, whichobjects a student is dealing with at the moment. Besides,he needs to be able to restrict the visibility of his ownassociationsÐ in this case his interactionsÐwith ob-jects of the virtual lab. For this reason the associationbetween Tutor and IcePot is marked additionally as{access-controllable}. The association named directsbetween the classes Tutor and Student shows theconnection between the roles, in this case, that the tutorsupervises the student. This association is not stereo-typed �shared� because this relation is not supposedto be visible for other users.

The class Tube, which is aggregated by IcePot isstereotyped �shared� in order to indicate here that itshould be visible for all users, how many tubes areaggregated by an instance of IcePot. The associationsbetween the class Tutor and Tube as well as Student andTube are also stereotyped �shared� in the sense thatthey are shared with respect to visibility and changeability.In addition, the association between Tutor and Tube isaccess controlled (compare associations to IcePot).

The class Substance is aggregated by Tube and alsostereotyped as �shared� in order to indicate that it isvisible for all users as the content of a tube. Here the tag{time-persistence=3 hours} is used to indicate that ashared instance of Substance is only persistent for alimited amount of time (here 3 hours), even if it is in atube which is placed in an ice pot. After this time thesubstance is not longer usable.

Both, the IcePot and the Tube, are marked as{lockable}. This is due to the fact that a tutor can lockthe usage of a virtual tube. This is needed when the tutordemonstrates something and does not want to beinterrupted by a student who wants to handle the sameshared tube in the virtual lab synchronously.

Another tagged value {observable} is attached to theclasses Icepot and Tube to indicate that all elements ofthe classes are observable by all other classes. As aprecondition the classes themselves are stereotyped as�shared�.

In Figure 4 you can see that the tagged value {access-controllable} is also applied to special attributes. Itindicates that these attributes are access controlled. Inthis case, an instance of the class Tutor is able to restrictthe usage. This can be further speci®ed by e.g., OCLconstraints.

4.2 XCHIPS

This usage scenario is related to the European projectEXTERNAL (`EXTended Enterprise Resources, Net-work Architectures and Learning') [21]. There, we haveused shared hypermedia workspaces for supportingdynamic networked organizations in developing andperforming joint business processes.

For this we have developed the cooperative toolXCHIPS (`eXtensible Cooperative Hypermedia Integ-rated with Process Support') [22, 23]. With XCHIPS,users can cooperatively model and execute businessprocesses. Figure 5 shows three users working in anXCHIPS session. They have modeled a process with thesteps XML import/export and Work Management,surrounded by Start and Finish. In addition, they haveassigned responsibilities to the di�erent tasks. XCHIPSshows awareness information regarding who has cur-rently opened which tasks. The XML import/export taskfor example is currently being worked on by dawabi andrubart. Moreover, telecursors are presented, such as theone from wwang.

The underlying data model of XCHIPS is a sharedhypermedia model. Figure 6 gives a basic overview overthis model and makes use of UML-G. A basic hyper-media model is characterized by a node-link paradigm[24]. Nodes are connected by links. Composites allownested hypermedia structures. In XCHIPS, we have aspecial composite Task and a special link Flow to modelwork¯ow. A process is represented as a set of sharedhypermedia tasks connected by shared hypermedia¯ows. Such a hypermedia-based process representationcan contain associated materials because the sharedhypermedia structure is not limited to tasks and ¯ows.In this way, process support is combined with informa-tion management. All instances of these types areshared. That's why the general hypermedia class(HMObject) is marked as �shared�.

The subclasses inherit the �shared� stereotype. Inaddition, all instances of HMObject stay persistent. This

237SHARED DATA MODELING WITH UML-G

is important because all processes and related informa-tion serve as experiences, which need to be accessiblefrom members of later joint projects so that they canlearn from and reuse the experiences. They could, forexample, clone a successful business process and adapt itto the requirements of the new project. In standardUML, a persistence tag is already de®ned, which alsoapplies to classes so that it can easily be combined withthe UML-G extensions in Figure 6. In addition to thepersistence tag, we have used the observable Boolean tagon order to express the fact that all changes on instancesof HMObject need to be propagated. The specialcomposite class Task has an additional, more speci®cstereotype assignedÐ it is marked as a shared activity.The reason for this is that an XCHIPS task is supposedto express a task, in the context of which several usersneed to cooperate. Executing such a task means that

users interact with each other and manipulate shareddata. Since UML 1.4 any model element can have morethan one stereotype [3]; but in this case one stereotype isactually su�cient as �sharedActivity� is a sub-stereotype of �shared�.

4.2.1 Detailing {observable} by a constraint

Figure 5 shows awareness information on the task XMLimport/export, which means that the referring users havecurrently opened the task to model its details. Figure 7shows our Task class, instances of which may beassociated with a number of rectangles (boxes) visualiz-ing tasks in XCHIPS browsers.

Each task has an attribute isOpenedBy indicatingwho has currently opened the task. The {observable} tagmodels explicitly that changes need to be noti®ed. Thisincludes the information on who has opened the task.To detail this, Figure 7 uses a constraint, expressingthat the bottom text of a task rectangle needs to equalthe names of the users who have currently opened thetask.

4.2.2 Object and state diagrams using UML-G

An object or interaction diagram is a collaborationdiagram or a sequence diagram. Both focus on messagesbetween objects in special contexts. A sequence diagrampoints out the temporal order of messages (a messageasks an object to execute an operation. Operations are

Figure 5 XCHIPS browser.

Figure 6 Cooperative hypermedia model with UML-G.

Figure 7 The tagged value {observable} detailed by a constraint.

238 J. RUBART AND P. DAWABI

implemented by methods). A collaboration diagramexplicitly shows the object relationships. In order toexpress that opening and closing an XCHIPS task isshared, messages in sequence and collaboration dia-grams can be marked as shared.

A state diagram shows a sequence of states, which anobject can take in its life. In addition, it presents statechanges, events that trigger state changes and activities.An activity diagram is a special state diagram thatfocuses on activities. Figure 8 shows a state diagramusing UML-G. It presents that an XCHIPS task objectcan be in a state closed and in a state opened during acooperative session.

The open and close events are marked as �shared�in order to express that all users participating in theXCHIPS session share opening a task. This means that,if one user opens the task, it gets opened for the others,too. Note that Figure 8 only presents an excerpt of thestates an XCHIPS task can take. Such an object cantake several states in parallel, e.g., also one thatrepresents whether the task has been started or ®nished.Here, we are focusing on the opened and closed states.The {observable} tag makes explicit that the other sitesare noti®ed about the events.

5 CASE TOOL SUPPORT

UML-G allows high level, implementation-indepen-dent modeling of groupware-speci®c elements andempowers CASE tools to partially automate thedevelopment activities. For this, existing CASE tools,supporting the UML extension mechanisms, can becon®gured to support modeling with UML-G. If theyprovide suitable con®guration mechanisms or APIs,they can be adapted to generate special code. Forgroupware development, usually a groupware toolkitor framework is used. After integrating a selected oneinto an appropriate CASE tool and using the CASEtool's con®guration mechanisms or APIs to adapt thecode generation accordingly, the code for the usedtoolkit or framework can be generated from the UML-G models.

Commercially available UML CASE tools, such as

Rational Rose1, Together2, ojectiF3, Objecteering4 orVisual UML5 (to mention a few), usually providesupport for the extension mechanisms of UML.Di�erences can be found regarding the completenessof this support and with reference to semantic support,whether it is for example possible to de®ne a stereotypehierarchy, a reusable set of extensions or whether OCLconstraint expressions are veri®ed against the model.

For our purposes we have chosen ArgoUML6 since itis an open source UML CASE tool written in Java. Thisenables us promising future work because we can adaptand extend it in any direction. It also has support foradding to-do comments at certain points in models.Figure 9 shows the telepointer example from Section 3.3modeled with ArgoUML. On the top left part you cansee a hierarchical view of our Examples tree. On theupper right part you can see the telepointer classdiagram. The constraint is written in a note using thevariables of the association. The bottom right partshows the details of the selected object in the classdiagram. Currently, the telepointer class is selected andits tagged values are shown in the `details' part.

5.1 Code generation

UML CASE tools usually provide code generationsupport for di�erent object-oriented programminglanguages. In addition, some CASE tools allow theadaptation of generating code by providing suitablecon®guration mechanisms, e.g., by providing scriptinglanguages or APIs. This allows special handling ofparticular UML extensions.

For generating code we have selected the Java-basedgroupware framework DyCE (Dynamic CollaborationEnvironment) [14] since it is used in our institute. SinceDyCE o�ers an object-oriented interface to modelingshared information, the code generation is quitestraightforward. We have adapted and extended theresponsible code generation classes of ArgoUML.Figure 10 shows the generated code for the telepointerclass.

The telepointer class is generated as a subclass ofDyCE's shared object model. Its shared attributes aregenerated as DyCE's shared attributes with get- and set-methods. Note that the way shared attributes aregenerated and thus the get- and set-methods for themare speci®c DyCE-code.

For the tagged value {lockable} a shared attributeLockedBy is generated that can point to the user whohas currently locked the telepointer. Regarding thetagged value {access-controllable} a shared attributeAccess is generated pointing to an AccessRight object

1Rational Software, http://www.rational.com/products/rose/2 TogetherSoft, http://www.togethersoft.com/3microTOOL, http://www.microtool.de/4 Softeam, http://www.softeam.fr/us/produits.htm5Visual Object Modelers, http://www.visualobject.com/6 Tigris.org community, http://www.argouml.org/

Figure 8 State diagram modeled with UML-G.

239SHARED DATA MODELING WITH UML-G

that encapsulates respective information. And again get-and set- methods are created. With reference to{observable} nothing special is generated for thetelepointer class since it is intended to use the observermechanisms already provided by DyCE's shared objectmodel.

Please note that this is only one way of generatingcode for one speci®c underlying framework andprogramming language. UML-G does not enforce aspecial implementation.

6 RELATED WORK

Basically, there are two areas of research related to workpresented in this paper: CSCW and UML extensions.

6.1 CSCW

Toolkits and frameworks for building groupware, suchas in [9±14], do not provide support for modelinggroupware in a manner, which is independent of thetoolkit or framework. Typically, some usage examplesare provided. However, these examples are implementa-tion related and focus on programming rather thanmodeling. Sometimes users' guides include modelinghints, but they are written using the language of the

Figure 9 The telepointer example modeled with ArgoUML.

Figure 10 Example code.

240 J. RUBART AND P. DAWABI

framework or toolkit. Hence, only very low levelmodeling support is provided there.

Modeling support for groupware developers, such asin [25], applies a design pattern from the area of single-user application development [26] to groupware. Thisdesign pattern focuses on the separation of an applica-tion and a domain model, whereby the applicationmodel is related to user interface elements. UML-G incontrast does not enforce any special design patterns. Itprovides groupware-speci®c modeling elements, whichcan be used in any UML diagram. Moreover, UML-Gcan help writing down design patterns for groupware ina way that is independent of any framework and toolkit.In addition, it can be extended to include any groupwarepattern explicitly (see Section 3.4).

In [27] a modeling approach is taken for sharedinformation spaces in order to ease their managementand support knowledge sharing within the enterprise. Ametamodel is proposed that de®nes the conceptualbuilding blocks of an information space. This modelingapproach focuses on organizing information spacesrather than on developing groupware.

6.2 UML extensions

With UML-F [28], working with object-oriented frame-works is supported. It allows the explicit representationof framework variation points. Hence, it is very usefulfor documenting a concrete framework. By using UML-F, framework developers can make explicit which partsof the system need to be adapted in order to create avalid framework instance. Therefore, application devel-opers (users of a framework) are assisted in frameworkimplementation and instantiation. In contrast to UML-F, UML-G does not model framework variation points.It is not intended to support framework developers indocumenting their framework so that it is easier to usefor application developers. It directly supports applica-tion developers in modeling cooperative applications,independent of any framework.

Synchronous groupware is related to real-timesystems in the sense of fast propagation of other users'interactions in order to provide workspace awareness[8]. A real-time system must respond to events in realtime. The architectural design usually involves organiz-ing the system as a set of interacting, concurrentprocesses [29]. There are UML extensions supportingreal-time systems, part of UML-RT [30, 31]. Such anextension is useful for modeling a toolkit or frameworksupporting groupware development, such as in [9±14].These usually care for concurrency control, networklatency and so forth. UML-G in contrast is not intendedto support modeling of real-time systems. It is intendedto support application developers in modeling theircooperative applications on a semantically high level.Typically, application developers use a toolkit orframework supporting groupware development, but donot build one.

UML extensions for agent-based systems, which areaddressed by Agent UML (AUML), as described in e.g.,[32] mainly support di�erent ways of modeling thecommunication protocols between agents. In contrast,UML-G does not aim at such protocols, but atgroupware-speci®c modeling elements.

UMLi [33] is a UML extension for modeling inter-active applications (in the sense of human±computerinteraction). It explicitly addresses interaction issues inactivity and use-case diagrams. In addition, a userinterface diagram is introduced for modeling abstractuser interface presentations. These presentations can berelated to domain objects in UMLi activity diagrams.Since cooperative applications are usually interactiveUMLi is nicely combinable with UML-G.

Note that you are free to combine di�erent UMLextensions in your UML models, if this is meaningful.

7 CONCLUSIONS AND FUTURE WORK

We have identi®ed core requirements for modelingshared data. Our proposed UML extensions address theidenti®ed requirements by explicitly representing shareddata, roles and actors in cooperative sessions, andshared activities as well as providing further semanticson shared data with the Boolean tagged values {access-controllable}, {lockable}, and {observable} and the tagstime-persistence and distribution. These UML extensionsare part of UML-GÐa UML pro®le for modelinggroupware.

UML-G supports groupware developers in modelingtheir cooperative applications by making groupwaredesign explicit and therefore, easier to understand. Thedescribed usage scenarios, in which we have used UML-G for shared data modeling, validate its applicability.Our experience shows that UML-G allows one to modelgroupware independently from any concrete architec-ture of a framework or toolkit. A shared understandingbetween developers is supported, which abstracts fromthe latter implementation. Moreover, UML-G can helpin the writing down of object-oriented design patternsfor groupware in a way that is independent of anytoolkit or framework. In turn, UML-G can be extendedto include any groupware pattern explicitly. UML-Gallows high level, implementation-independent modelingof groupware-speci®c elements and enables CASE toolsto partially automate the development activities forspecial groupware toolkits and frameworks.

In our future work, we will complement UML-G. Asan example, a new part of UML-G addressing the usageof concurrency control can include tagged values, suchas {optimistic} and {pessimistic}. For this, we want thecommunity to contribute to it. In order to make thise�cient we have set up and host community support(http://www.uml-g.org/).

Moreover, we will build cooperative tools providingsynchronous as well as asynchronous modeling support

241SHARED DATA MODELING WITH UML-G

for UML-G. For this, we will either continue usingArgoUML and create suitable shared data models withDyCE or extend the cooperative modeling tool XCHIPSto support a UML-G template. In addition, we willimprove the code generation support.

ACKNOWLEDGEMENTS

We would like to thank the CRIWG community forvaluable feedback and discussions on UML-G. Thanksto Stephan Lukosch for discussing data distribution.

REFERENCES

1 Greenberg, S. (1991) Computer-Supported CooperativeWork and Groupware, Academic Press.

2 Edwards, K. and Mynatt, E.D. (1997) `Timewarp:techniques for autonomous collaboration', Proceedings ofCHI '97, ACM Press.

3 OMG: OMG Uni®ed Modeling Language Speci®cationVersion 1.4 and following, http://www.uml.org/ (2001±2003).

4 Rumbaugh, J., Jacobson, I. and Booch, G. (1999) TheUni®ed Modeling Language Reference Manual, Addison-Wesley.

5 Rubart, J. and Dawabi, P. (2002) `Towards UML-G: aUML pro®le for modeling groupware', Proceedings ofCRIWG '02, Springer-Verlag, pp. 93±113.

6 Bentley, R., Horstmann, T., Sikkel, K. and Trevor J.(1995) `Supporting collaborative information sharing withthe world wide web: the BSCW shared workspace system',The World Wide Web Journal: Proceedings of the 4thInternational WWW Conference, Issue 1, O'Reilly, pp. 63±74.

7 Summers, R. (1998) O�cial Microsoft# NetMeeting2

Book, Microsoft Press.8 Gutwin, C. and Greenberg, S. (1996) `Workspace aware-

ness for groupware', Proceedings of CHI '96, pp. 208±209.9 Prakash, A. and Shim, H.S. (1994) `DistView: support for

building e�cient collaborative applications using repli-cated objects', Proceedings of CSCW '94.

10 Roseman, M. and Greenberg, S. (1996) `Building real-timegroupware with GroupKit, a groupware toolkit', Transac-tions on Human-Computer Interaction, Vol. 3, No. 1,pp. 66±106.

11 Schuckmann, C., Kirchner, L., SchuÈ mmer, J., and Haake,J.M. (1996) `Designing object-oriented synchronousgroupware with COAST', Proceedings of CSCW '96,ACM Press, pp. 30±38.

12 Burridge, R. (1998) Java Shared Data Toolkit User Guide.User Guide, Sun Microsystems Inc.

13 Chabert, A., Grossmann, E., Jackson, L., Pietrowicz, S.and Seguin, C. (1998) `Java object-sharing in Habanero',Communications of the ACM, Vol. 41, No. 6, pp. 69±76.

14 Tietze, D.A. (2001) `A framework for developing compo-nent-based co-operative applications', GMD ResearchSeries No. 7/2001, ISBN: 3-88457-390-X.

15 Lukosch, S. (2002) `Adaptive and transparent data

distribution support for synchronous groupware', Proceed-ings of CRIWG '02, Springer-Verlag, pp. 255±274.

16 Teege, G. (1996) `Object-oriented activity support: a modelfor integrated CSCW systems', Computer SupportedCooperative WorkÐAn International Journal, Vol. 5,No. 1, pp. 93±124.

17 Warmer, J.B. and Kleppe, A.G. (1999) The objectconstraint language: precise modeling with UML, Reading,MA: Addison-Wesley.

18 Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995)Design Patterns: Elements of Reusable Object-OrientedSoftware, Addison-Wesley.

19 Dawabi, P. and Rubart, J. (2000) `CoopLab: A frameworkfor web-based virtual labs', Proceedings of the WorkshopMultimedia Computing on the WWW, VL2000.

20 Dawabi, P. and Wessner, M. (2001) `Combining instruc-tionist and constructionist learning in a virtual biotechlab', Proceedings of ED-Media 2001.

21 EXTERNALÐextended enterprise resources, networkarchitectures and learning, EU Project, IST-1999-10091,New Methods of Work and Electronic Commerce,Dynamic Networked Organisations, http://www.external-ist.org/ (2000±2002).

22 Rubart, J., Haake, J.M., Tietze, D.A. and Wang, W.(2001) `Organizing shared enterprise workspaces usingcomponent-based cooperative hypermedia', Proceedings ofHypertext '01, ACM Press, pp. 73±82.

23 Wang, W., Haake, J.M., Rubart, J. and Tietze, D.A.(2000) `Hypermedia-based support for cooperative learn-ing of process knowledge', Journal of Network andComputer Applications, Vol. 23, pp. 357±379, AcademicPress.

24 Nielsen, J. (1990) Hypertext and Hypermedia. AcademicPress, Inc.

25 Schuckmann, C., SchuÈ mmer, J. and Seitz, P. (1999)`Modeling collaboration using shared objects', Proceedingsof Group '99, ACM Press.

26 Szekely, P., Luo, P. and Neches, R. (1992) `Facilitatingthe exploration of interface design alternatives: theHUMANOID model of interface design', Proceedings ofCHI '92, pp. 507±515.

27 Natvig, M.K. and Ohren, O. (1999) `Modeling sharedinformation spaces (SIS)'. Proceedings of Group '99, ACMPress, pp. 199±208.

28 Fontoura, M., Pree, W. and Rumpe, B. (2000) `UML-F: amodeling language for object-oriented frameworks', Pro-ceedings of ECOOP '00.

29 Sommerville, I. (2001) Software Engineering, 6th Edition,Addison-Wesley.

30 Herzberg, D. (1999) `UML-RT as a candidate formodeling embedded real-time systems in the telecommu-nication domain', Proceedings of �UML '99�.

31 Selic, B. and Rumbaugh, J. (1998) `Using UML formodeling complex real-time systems', White paper avail-able at http://www.objectime.com/otl/technical/umlrt.html

32 Bauer, B., MuÈ ller, J.P., and Odell, J. (2001) `Agent UML:a formalism for specifying multiagent interaction', Agent-Oriented Software Engineering, Springer-Verlag (held atISCE '00, 2000), pp. 91±103.

33 Pinheiro da Silva, P. and Paton, N.W. (2000) `UMLi: theuni®ed modeling language for interactive applications',Proceedings of UML 2000, LNCS, Vol. 1939, pp. 117±132.

242 J. RUBART AND P. DAWABI

BIOGRAPHY

Jessica Rubart is a research scientist at Fraunhofer IPSIin Darmstadt, Germany. She received her degree incomputer science (Dipl. Inform.) at the University ofPaderborn, Germany. Since 1998 she has been carryingout research in the areas of distributed cooperativeworking and learning environments, component-or-iented software engineering, cooperative hypermedia,and knowledge management.

Peter Dawabi is a research scientist at Fraunhofer IPSIin Darmstadt, Germany. He received his degree incomputer science (Dipl. Inform.) at Bielefeld University,Germany. Since 1997 he has been participating inresearch projects in the ®elds of e-learning andcomputer-supported cooperative learning and working.He is also engaged in research on virtual reality as wellas in developing wireless and mobile learning solutions.

243SHARED DATA MODELING WITH UML-G