an extensible platform for the development of synchronous groupware

18

Click here to load reader

Upload: g-licea

Post on 05-Jul-2016

216 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: An extensible platform for the development of synchronous groupware

An extensible platform for the development of synchronous groupware

G. Liceaa,b,* , J. Favelaa

aDepartment of Computer Science, CICESE Research Center, Ensenada, Baja California, MexicobComputer Engineering, University of Baja California, Tijuana, Baja California, Mexico

Received 13 May 1999; received in revised form 3 September 1999; accepted 25 October 1999

Abstract

The development of groupware is a complex endeavor due to several inherent features not present in single-user applications. To addressthis complexity many authors have presented useful platforms that permit the reutilization of code to facilitate the implementation ofgroupware applications. However, design reusability could be of greater value than code reusability and facilitate the use and extension ofgroupware features. This paper describes COCHI (Collaborative Objects for Communication and Human Interaction), an extensible patternsystem for groupware applications that aims to provide reusability and extensibility of design patterns represented as COCHI subsystems andimplemented as a class framework.

This pattern system has proved to be useful for the rapid development of groupware applications, while being flexible enough toincorporate important extensions to the original framework. Overall, it provides a good balance between ease of use and flexibility.q 2000 Elsevier Science B.V. All rights reserved.

Keywords: Groupware; Software pattern; Framework; Design reusability

1. Introduction

Groupware applications include features related tocollaboration, coordination, and communication that arenot present in single-user systems [1]. These featuresmake groupware complex to design and implement.

There are many platforms that support the developmentof groupware applications and their purpose is to facilitatethe detailed design and implementation of software. Theseplatforms provide different types of support (run-time,libraries, etc.) to help the developer while implementinggroupware applications. However, it has recently beenacknowledged that reusability can be of greater value, ifincorporated during design rather than waiting forimplementation [2]. When we reuse code (using a library,for example), we must restrict our implementation to thedesign options given by the classes, functions, or packageswe choose to reuse. But when reusing at the design level, wecan take the design packages (subsystems, modules, etc.)and extend them in order to incorporate the specific featuresof the system we want to implement. In other words, we canextend the design space defined by these packages.

The platforms proposed to facilitate groupware develop-ment include: MMConf [3], Rendezvous [4], Suite [5],

Conference Toolkit [6], ShareLib [7], Groupkit [8], Coast[9], Habanero [10], Java Shared Data Toolkit (JSDT) [11],and the work by Banavar et al. [12].

Some of these platforms provide a run-time infrastructurefor converting a single user application to a collaborativeone, others consist of libraries of functions or classes forsupporting the basic characteristics of a groupware appli-cation.

Almost all of these platforms were implemented for Unixworkstations. Groupkit also runs in MS Windows. Habanero,JSDT, and the work by Banavar were implemented in Java,which makes them portable to different operating systems.

Fig. 1 illustrates the level of reusability of the platformsmentioned above including the COCHI pattern system, thesystem we are presenting in this paper. We can see that ahigher level of reusability can be achieved with COCHI,given that it is based on design patterns.

A decade ago programmers dedicated a considerableamount of effort to the implementation of the GraphicalUser Interface (GUI) of a system, since they lacked thetools to facilitate this task. Many tools appeared sincethen, that facilitate the design and implementation of agraphical user interface. In addition, developers can now useguidelines that define the typical elements and configurationsof an effective GUI. These guidelines were developed basedon experience, usability tests, and opinions from experts.

Information and Software Technology 42 (2000) 389–406

0950-5849/00/$ - see front matterq 2000 Elsevier Science B.V. All rights reserved.PII: S0950-5849(99)00098-1

www.elsevier.nl/locate/infsof

* Corresponding author.

Page 2: An extensible platform for the development of synchronous groupware

CSCW (Computer-Supported Cooperative Work) is insimilar position to the one in which HCI was some yearsago. In the next few years architectures, platforms, frame-works, and tools will appear to facilitate the development ofgroupware. But, most important, during this period, guide-lines for the development of groupware will be developed.

In this paper we present a flexible platform, namedCOCHI (Collaborative Objects for Communication andHuman Interaction), that help in the coding phase, but

also during the design of a groupware application. COCHIis a pattern system composed of an architectural pattern thatincludes subsystems for the most common features found ingroupware, a set of design patterns that show how to buildany of the specific subsystems included in the architecture,and a class framework for supporting the rapid implemen-tation of groupware applications.

Software patterns are based on the experience of softwaredevelopers and can be generated from abstractions of thegeneral characteristics of representative systems in aspecific area. Patterns provide a systematic approach forreusability of code or design packages (classes, modules,etc.). There are several specialized catalogs of designpatterns [13–15], pattern languages [16–18], patternsystems [19,20], and related work that shows the importanceand success of patterns in software development.

In the next section (Section 2) we describe a design spacefor groupware that helped us determine issues to be con-sidered in the architectural pattern. In Section 3 we describethe architecture, the design patterns associated to eachsubsystem, and the framework that supports the implemen-tation of groupware applications, including some of themost interesting ones developed using this framework. InSection 4, to illustrate the flexibility of the COCHI patternsystem at the design level, we present two extensions thatreuse COCHI to support adaptive Quality of Service [21]and emotional awareness in groupware applications [22].Finally, in Section 5, we present our conclusions.

2. A design space for groupware

A design space identifies the functional requirements anddesign related to a specific field. Each functionalrequirement or design decision is represented as adimension of the design space [23]. A design space helpsin the characterization of a system and provides guidelinesfor selection between the design elements of the space,according to the particular application, in order to simplifythe development process.

In Ref. [24], we proposed a design space for groupwarewith seven dimensions obtained from the analysis of elevengroupware applications found in the CSCW literature. The

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406390

Table 1Features present in each subsystem of COCHI’s architecture

Subsystem Features

Session management Interaction: localization of participants,synchronous interaction, informalcommunication, social status ofparticipants based on rolesParticipation: support for joining andleaving a session, late comers, small orlarge groupsDistribution: client-server processarchitecture

Floor control Interaction:alternate access to publicareaCoordination:floor control policydimensions, several floor controlmechanisms, explicit request/release forfloor control, visual representation of thefloor control owner

Collaborationawareness

Participation: list of participants

Notification:visualization of location,graphic representation of sessionparticipants

Communicationmedia

Participation: several mechanism forcommunication, annotationsSupport:communication channels

Object management Participation: persistent objectsCoordination:concurrency controlDistribution: centralized dataarchitecture

Collaborativeinterface

Visualization:three types of windows(public, private, and secondary),WYSIWIS views by default (easymodification), data transmission tomaintain simultaneous views, cursorsdisplay, menu items selection, visualcues to identify types of windows

Fig. 1. Level of reusability of existing platforms.

Page 3: An extensible platform for the development of synchronous groupware

dimensions are: interaction, participation, visualization,notification, coordination, distribution, and support.

The functional requirements and design decisions of thedesign space were used to identify the design patterns andconsequently associate them using a common architecture(architectural pattern). Each design pattern includes specificissues in several dimensions.

In this section, we present the characteristics of eachdimension of the design space and the possible values rep-resented by design decisions.

2.1. Interaction

Refers to all those characteristics that involve the par-ticipants of a session and the way in which they interact.This dimension includes: localization of the participants,time (same or different), type of communication (formalor informal), social structure of the session (democratic orstratified), social status of the participants (same or hierarch-ical), invocation to participate in the session (scheduled orspontaneous), interaction flow of session, authorship ofideas, styles of accomplishing a larger task (joint orsubgroups), access to a public area (simultaneous or takingturns), and type of contribution (independent, reflective, orby consensus).

2.2. Participation

Refers to the way in which participants in a session inter-act with the groupware application. This dimensionincludes: method to establish session participation (plannedor dynamic), joining a session (on time, late comers, or in

intervals), leaving a session (until finish, before conclusion),policy to give access to late comers (consensus, moderator,vote, or criteria), group size (small or large), list of attendees(unspecified, specified, or conditioned), accomplishment ofactivities (jointly or parallel), communication mechanisms(textual, sketching, audio, or video), annotations (static ordynamic), endurance of data elements (persistent or non-persistent), period of interaction, data representation (differ-ent or the same for the participants), actions and functions(listing, drawing, gesturing, storing information, expressingideas, or mediating the interaction of other participants).

2.3. Visualization

Refers to the way in which the elements of a session aredisplayed. This dimension includes: multi-user interface(WYSIWIS strict or relaxed), type of windows (public,private, or shared), visual cues to identify types of windows,screen workspace management, data transmission to main-tain simultaneous views, maintaining user displays (updateor non-update), change in window representation whenactivated, cursors used, cursors display, and selection ofmenu items.

2.4. Notification

Refers to collaboration awareness of others participantsand their actions. This dimension includes: collaborationawareness (transparent or aware), visualization of spatiallocation, graphic representation of participants (namedcursors, video images, list of users, status line, or icons),and availability of participants (accessible or interrupted).

2.5. Coordination

Refers to the mechanisms and rules established forsharing resources. This dimension includes: pre-meetingprocess (goal setting, participant signing, and materialcollection), meeting registration, registration style for appli-cations (same or different), registration scheme (open door,controlled by a facilitator, based on rooms or communities),dimensions for floor control policies (number of floors,number of participants with the floor control, and how thefloor is passed), floor control mechanism (free, round robin,moderator, random, FIFO, preemptive, and pause detec-tion), floor control policy to request the floor and how it isgranted (implicit/implicit, explicit/implicit, or explicit/explicit), visual representation of current floor holder,concurrency control mechanism (locking, serialization, orother), and concurrency control based on selected dataarchitecture (centralized or duplicated).

2.6. Distribution

Refers to the design strategy used for the implementationof the application and the way in which shared resources areused. This dimension includes: data and application archi-tecture (centralized or replicated).

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406 391

Fig. 2. Ease of use vs. flexibility provided by software developmentenvironments.

Fig. 3. Relationships between architectural pattern, design pattern and classframework.

Page 4: An extensible platform for the development of synchronous groupware

2.7. Support

Refers to the technical infrastructure required to attendthe functional requirements and the use of tools for group-ware applications development. This dimension includes:communication channels (the application uses a separateaudio/video communication channel) and programmingtoolkits (the application could be developed using a group-ware toolkit).

Considering the design elements of each dimension of thegroupware design space, we found that these can be classi-fied in six groups that will be explained in the next section asthe subsystems of the COCHI architecture: session manage-ment, floor control management, collaboration awareness,communication media, objects management, and collab-orative interface (see Table 1).

3. The COCHI pattern system

In Fig. 2 we have classified different types of softwaredevelopment environments according to ease of use (to whatextent they simplify application development) and flexi-bility (the facility with which new functionality, not origin-ally considered, can be added). A programming languagefor instance, provides a great deal of flexibility, but is notparticularly easy to use. At the other extreme an applicationprovides little flexibility for supporting functionality notoriginally considered, but requires no development effort.

The ideal development environment will be one thatprovides maximum flexibility and ease of use. We cannote in Fig. 2 that a pattern system comes closer to thisideal when compared to other software environmentssince it provides ease of use without compromising

flexibility. A pattern system is not as easy to use as a finalapplication or a run-time support platform, but clearly apattern system is easier to use than a class frameworkbecause design patterns document the class frameworkand permit to extend them for specific applications orfamilies of applications, reducing the implementation effort.Design patterns can be considered as the micro-architecturalelements of a framework [25,26].

A pattern system is composed of architectural patterns,design patterns, and class frameworks. An architecturalpattern defines the structure and organization of a particulartype of system. It shows the big picture of the system,including the subsystems and the relationships betweenthem in the defined architecture. A design pattern showsthe details of a subsystem and documents the class frame-work. A design pattern contains the design rationale behinda class framework, what makes it easier to extend or modify.The class framework is the implementation of all the classesincluded in the design patternsusing a programming language.

Fig. 3 illustrates the relationships between the elements ofa pattern system and it shows how a class framework can be

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406392

Fig. 5. General structure of the Client–Server design pattern.

Fig. 4. Architecture of COCHI.

Page 5: An extensible platform for the development of synchronous groupware

benefited with the use of architectural and design patterns togenerate a pattern system.

The COCHI pattern system includes the three com-plementary elements of a pattern system: an architecturalpattern that includes the most important features in acollaborative environment such as session management,collaboration awareness, floor control, among others; a setof design patterns for each of the features, and groupwareclass frameworks that have been used to implement severalgroupware applications.

The main goal of COCHI is not just to support theimplementation phase of the software development cycle,but the design phase as well, by providing a set of extensibleand reusable patterns that documents the class framework.To build a platform that give us these features it was neces-sary to take design decisions according to our needs.

We began with a study of several of the most popular andwell known groupware applications and groupware plat-forms in order to determine the subsystems that should beincluded in the architecture, as well as the features includedin each subsystem.

First, we selected the architectural structure of the

platform. We choose a Client–Server architecture due toits popularity and simplicity for implementation. In fact,this type of architecture is most commonly used in group-ware, these days. Then, we proposed six subsystems thatform the core of COCHI: session management, floorcontrol, collaboration awareness (user representation),communication media, and object management. Also acollaborative user interface was included to facilitate theuse of the platform.

Once we defined the subsystems, we reviewed the differ-ent features included in the design space for groupware andwe choose the features according with the study previouslydone [24]. Finally, we classified each feature in one of thesix subsystems and arranged the subsystems in an integratedstructure (based on the Client–Server model).

Surely, the most complete platform should be the one thatincludes subsystems for dealing with all the featuresillustrated in the design space for groupware, but this isnot possible because many features are mutually exclusive,and other features are rarely used, and should be an over-head for the platform. We tried to select the features mostcommonly found in groupware applications, providing

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406 393

Fig. 6. Structure of the Client–Server design pattern.

Fig. 7. A participant connects to the server.

Page 6: An extensible platform for the development of synchronous groupware

facilities to add new features, and subsystems according tothe specific needs of the application.

In the next subsections we will describe the architecture,subsystems, and class frameworks of COCHI.

3.1. The COCHI architecture

The first element of the COCHI pattern system is alayered architecture composed of several subsystems thatcan be described as design patterns. We use layers becausethey reduce software dependencies and promote reusability[2]. Table 1 describes the features of each subsystem basedon the design space presented in Section 2 and Fig. 4 illus-trates the architecture of the COCHI pattern system.

The architecture itself is based on a design pattern(Client–Server design pattern) that allows the participant’sapplications to communicate with each other through aserver with a defined protocol.

Theserveris composed of three layers. The configurationlayer allows participants to configure the characteristics ofthe session. The collaboration layer of the server includesfive subsystems that extend the Client–Server designpattern included in the server layer. The Client–Serverdesign pattern will be explained in the next section. Briefly,we can say that this design pattern is composed of all thenecessary elements that allow communication between aserver and applications connected to it.

The participant is composed of four layers. The appli-cation layer is the groupware application itself. The collab-orative interface layer represents the interface between thedeveloper and the collaboration layer, its features andservices. This layer includes the necessary elements fordeveloping groupware applications, based on the COCHIplatform. The collaboration layer of a session participanthas the same five subsystems included in the collaborationlayer of the server, so each subsystem of the participantinteracts with the corresponding subsystem of the server.The participant layer contains the Client–Server designpattern.

3.2. The COCHI subsystems

In this section, we describe the subsystems included in theserver, client and collaboration layers of both server andsession participant. We begin with the description of theClient–Server design pattern and then we present the fivesubsystems included in the collaboration layer.

3.2.1. The Client–Server design patternThe Client–Server design pattern includes the classes

needed for handling the connection and event passingbetween groupware applications through a server. Next,we present the detailed description of the design patternusing the format defined by Buschmann [19].

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406394

Fig. 8. A participant sends an event to the server.

Fig. 9. The session manager design pattern.

Page 7: An extensible platform for the development of synchronous groupware

Pattern: Client–Server design pattern.Context: Groupware is software developed to help a

group of people to accomplish some task using networkedcomputers. Groupware is more complex than single-userapplications because groupware requires, in addition tothe typical features of a single-user application, somefeatures related to communication between participants,coordination of activities and collaboration issues that arepresent only in groupware applications.

Problem: The development of groupware is a complexendeavor due to several inherent features not present insingle-user applications. It is not obvious which featuresmust be considered as the most important. Groupwareinvolves technical and social issues as well. The developerof groupware applications and platforms could be benefitedby the use of a toolkit to support him in order to completesuccessfully his task. There are several possible approachesfor a toolkit. A good support could be a run-time architec-ture that provides the basic features found in most group-ware applications, in addition to transforming single-userexecutable applications into groupware. This helps when

the system has been already developed. Another (morecomplete solution) would be a set of libraries that supportthe developer by providing special constructs to design andimplement the application.

Solution: Design a set of related classes that allows agroup of participants to connect to a collaborative sessionand send messages, events, and any kind of objects througha server under a predefined protocol to process them accord-ing to the specific groupware application or subsystem. Fig.5 shows the general structure of this approach.

Structure:The Client–Server design pattern is a set ofclasses that support connection and event handling. Fig. 6shows the classes included in the design pattern and howthey are related.

TheServerclass is thread (concurrent object) that definesa generic server that listens through some port and receivesconnection requests from participants. The server creates aninstance of Connection handler for each connectionrequested and uses this instance to receive/send eventsfrom/to a particular participant.

The Server subsystemis a specialization ofserver that

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406 395

Fig. 10. The communication media design pattern.

Fig. 11. The collaboration awareness design pattern.

Page 8: An extensible platform for the development of synchronous groupware

receives and processes events sent by the participantsconnected to the server and distributes the events to someor all the participants connected.

The Client class is a thread that defines a generic clientthat requests connection to the server and it receives/sendsevents from/to the server once the connection is established.

The Client subsystemis a specialization of participantthat receives that events sent by the server and processesthem according to the functionality of the collaborativefeature it implements. Client subsystem can also send anytype of event defined for the application to the server to bedistributed to other participants connected.

Behavior: Two scenarios illustrate the behavior of theClient–Server design pattern. They show how the differentclasses interact in order to interchange information(messages, events, and objects) between the participantsusing a common server.

Figs. 7 and 8 illustrate the behavior of the design pattern.Fig. 7 shows the behavior of the system when a participantconnects to the server.

Fig. 8 shows how a participant sends an event, message,or object and how the server processes this event or notifiesother participants.

3.2.2. The session manager design patternThe session manager design pattern is a specialization of

the Client–Server design pattern. The subsystem providesfunctionality that allows participants to join and exit from aparticular session. This subsystem also registers the sessionname and information from each participant (identification,name and role). Fig. 9 presents the classes included in thissubsystem and the design patterns associated with it.

In Fig. 9 we use the nameCollaborative design patterntoindicate any of the design patterns included in the collabor-ation layer that will be explained in Sections 3.2.3–3.2.6and Collaborative interface refers to the subsystemcontained in the collaborative interface layer of the sessionparticipant. This subsystem is explained in Section 3.2.7.

3.2.3. The communication media design patternThe communication media design pattern is a specializ-

ation of the Client–Server design pattern. The subsystemallows participants to communicate with other participantsin the session using one or more media: text, audio, or video.Fig. 10 shows the classes included in this subsystem and thedesign patterns associated with it.

3.2.4. The collaboration awareness design patternThe collaboration awareness design pattern is a special-

ization of the Client–Server design pattern. It defines asubsystem that allows participants to be aware of thepresence of other participants in the session. Participants

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406396

Fig. 12. The object manager design pattern.

Fig. 13. The floor control design pattern.

Page 9: An extensible platform for the development of synchronous groupware

are represented using a list, labeled pointers, icons or, astatus line. Fig. 11 shows the classes included in this subsys-tem and the design patterns associated with it.

3.2.5. The object manager design patternThe object manager design pattern is a specialization of

the Client–Server design pattern. It defines functionality forparticipants to save objects, or groups of objects in a repo-sitory included in the server and to retrieve these objects in alatter session. Fig. 12 shows the classes included in thissubsystem and the design patterns associated with it.

3.2.6. The floor control design patternThe floor control design pattern defines a subsystem to

coordinate tasks between session participants through a

defined floor control policy using one or more floor controlmechanisms. The pre-defined mechanisms are: free,random, pre-emptive, FIFO, central moderator, pausedetection and round robin. Fig. 13 shows the classesincluded in this subsystem and the design patterns asso-ciated with it.

3.2.7. The collaborative interface subsystemThe collaborative interface subsystem is included in the

collaborative interface layer of the participant, it iscomposed of different types of windows and collaborativecomponents. The purpose of this subsystem is to support thedeveloper in the design of the user interface of a groupwareapplication.

There are two groups of elements contained in the

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406 397

Fig. 14. The collaborative interface subsystem.

Fig. 15. Class framework for the server of COCHI.

Page 10: An extensible platform for the development of synchronous groupware

collaborative interface subsystem, specialized windows andcollaborative user interface components or widgets.

Collaborative, private and secondary windows arespecialization ofWindow, a generic window associatedwith the session manager subsystem.

Collaborative windowis the main window of a group-ware application. It is a public window that automaticallysends to the server all the events generated in it. Thiswindow also receives all the events generated by other par-ticipants in the session. ASecondary windowis a publicwindow that can be used by a collaborative window toperform specific tasks. ThePrivate windowstores all theevents generated inside it until the user decides to sendthem.

Fig. 14 shows the classes included in the subsystem andthe way in which they relate to the design patterns shown inthe previous sections.

3.3. The class framework

In the previous sections we described the architecturaland design patterns of the COCHI pattern system. In thissection we describe the lower level of the pattern system, theclass framework.

The class framework of COCHI implements in the Javaprogramming language all the classes included in the designpatterns and subsystems adding some useful classes thatfacilitate the implementation of groupware.

3.3.1. The serverFollowing the architecture, the framework is divided in a

client and a server class hierarchy. Programmers do not needto modify or extend any class in the server part of the frame-work. The framework contains a class to configure theserver before its execution. Fig. 15 shows a diagramcontaining all the classes defined in the server and Fig. 16shows the server configuration dialog.

3.3.2. The participantsTo implement a groupware application or convert an

existing single user application using the framework definedin COCHI, a programmer needs to specialize the methodsdefined in a few classes, the ones included in the collabor-ative interface subsystem. Fig. 17 shows the class hierarchyused to implement a client.

When a user requests admission to a collaborative sessionof a groupware application implemented with the COCHIclass framework he will be presented with the configurationdialog shown in Fig. 18.

3.3.3. Groupware applications developed with COCHI’sclass framework

The main purpose of the COCHI platform is to facilitatethe development of groupware applications through design

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406398

Fig. 16. The server configuration dialog.

Fig. 17. Class framework for the participant of COCHI.

Page 11: An extensible platform for the development of synchronous groupware

and code reuse. For that, we have focused on two maindimensions of reusability: flexibility and ease of use. But,we consider also important to support the rapid prototypingof applications.

In this section we show some of the several groupwareapplications implemented using COCHI’s class frame-works. These applications have been implemented mostlyas final projects in a graduate course on collaborativesystems. Through by its use, we found that students usingCOCHI’s class frameworks were able to focus on the appli-cation’s functionality rather than low-level issues of group-ware such as: how to send/receive information to/fromsession participants? or how to implement the particularfloor control policy and mechanism selected?, amongothers. By using COCHI the applications developed weremore complex and interesting than those developed withoutit, using only a programming language and its providedlibraries or specialized network applications class frame-works.

The experience gained through the development of thesegroupware applications, influenced the evolution ofCOCHI. Table 2 presents some of the applicationsimplemented with COCHI’s class frameworks and some

estimations of the effort required to implement them. Inthis table we can observe four columns. The first columncontains the name and a brief description of each appli-cation. The second column refers to the skills of the devel-oper, where we can distinguish between three levels: novice(which indicates no knowledge about groupware or the Javaprogramming language), medium (which indicates someknowledge about groupware or the Java programminglanguage), and expert (which indicates experience in theuse of Java and knowledge about groupware). Finally, thelast column represents the number of lines written toimplement the application, without including the codeprovided by COCHI’s class frameworks which is trans-parent to the developer. In the next part of this subsectionwe describe three (the most interesting) applications thatappear in Table 2.

3.3.3.1. C3TO (Collaborative CRC CASE TOol).Classidentification is one of the main problems presentedduring requirement specification in the object-orientedanalysis phase of the software development process.Several methods have been proposed for this purpose andthe Class Collaborator Responsibility Cards (CRC Cards)

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406 399

Fig. 18. The participant configuration dialog.

Table 2Characteristics of some groupware applications implemented with COCHI’s frameworks

Name/description Developer’ skills Time (h) Lines of code

Hello WorldA simple application to “say hello” to otherparticipants in the session

Medium 0.5 25

Collaborative Simple PaintA simple free hand drawing application

Medium 1 41

Collaborative paintAn application for drawing figures such aslines, circles, etc. using a set of colors

Expert 16 239

C3TOAn application for the creation of CRCCards that describe classes during object-oriented analysis

Medium 70 1481

Coarsy/TVPAn application for the creation and review/annotation of HTML documents

Novice 90 678

AcmeA system for brainstorming and takingdecision support

Novice 80 485

HQ A system for generating product designattributes based on the clients needs

Novice 24 222

Use Cases drawing toolA system for drawing use cases diagrams

Expert 40 580

Page 12: An extensible platform for the development of synchronous groupware

method, introduced by Beck and Cunningham [27] is one ofthe most popular. C3TO allows us to write CRC Cards in acollaborative environment. Each card represents a class in thesystem that is being modeled, the cards include the name,responsibilities (methods) and collaborators (associations) ofa class. Fig. 19 shows the structure of the CRC Cards and theway they are represented in C3TO.

In Fig. 20 we can see three windows of the application.On top appears the main window, which includes menuswith different options for the collaboration features (sessionmanager, floor control, collaboration awareness, andcommunication). In addition, this window presents menusfor dealing with the creation, display, storage, andretrieval of CRC Cards. The window at the rightshows a list with the available CRC Cards for thissession, and the left window shows the information ofa particular CRC Card.

C3TO was implemented as a final project in a graduatecourse of collaborative systems. The developer of this appli-cation had some knowledge about groupware and the Javaprogramming language.

3.3.3.2. Coarsy/TVP. Coarsy is an asynchronouscollaborative editor and review tool for HTML(HyperText Markup Language) documents [28] developedusing only the support of the Java’s standard libraries. Thisgroupware application allows a group of session participantsto edit an HTML document and to make annotations aboutsome parts of the document (section, subsection,paragraph, or the whole document), these annotationsare saved in a discussion thread that contains thehistory of the document. Coarsy/TVP is an extensionto Coarsy that uses COCHI to add location awarenessand synchronous interaction.

Fig. 21 shows two windows of the Coarsy/TVP appli-cation. The main window (at the right) contains an areafor the edition of the HTML document, icons for selectingdifferent options for the documents (fonts, alignment, cutand paste, etc.), and menu options for session management.The other window (at the left) shows a global view of thedocument, in which the position of each session participantover the HTML document is indicated.

Coarsy/TVP was implemented as a final project in a

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406400

Fig. 19. CRC Cards and their representation in C3TO.

Fig. 20. The C3TO application.

Page 13: An extensible platform for the development of synchronous groupware

graduate course of collaborative systems. The developerof this application had some knowledge about group-ware, but no knowledge about the Java programminglanguage.

3.3.3.3. Use Cases drawing tool.Use Cases are diagramsused to show the typical scenarios in an informationprocessing system. These diagrams help us to obtainthe requirements of a software system. Use Casesdiagrams are part of the UML (Unified MethodLanguage) [29].

The Use Cases drawing tool is a groupware applicationfor drawing use diagrams. Fig. 22 shows the main windowsof this application. The window to the left is the mainwindow, in which the use cases diagrams are drawn, thiswindow contains options for drawing an connecting differ-ent type of elements, and it also allows the user to save andretrieve diagrams. The upper right window shows the list of

participants in the session, and the bottom right windowshows the collaboration options.

This application was implemented, to support a distribu-ted software engineering graduate course. The developer ofthis application had experience in groupware and the Javaprogramming language.

4. Extensions to the COCHI architecture and designpatterns

In contrast with libraries or other solutions, the COCHIstructure based on software patterns allow designers ofgroupware to customize the platform according to theirparticular needs. The architecture, documented through anarchitectural pattern, can be extended adding more sub-systems and each subsystem (design pattern) can beextended with different features, in addition to those alreadysupported.

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406 401

Fig. 21. The Coarsy/TVP application.

Fig. 22. The Use Cases Drawing Tool application.

Page 14: An extensible platform for the development of synchronous groupware

The main difference between a library and a class frame-work is that the class framework includes classes that (as anintegrated set) provide support for problem solutions in aspecific domain. A library is just a collection of classes withsome relation. In addition, a class framework includes somedocumentation about the way in which the classes and theirassociations were implemented.

A pattern system includes a set of design patterns thatdescribe the design rational of the class frameworks, andit also includes one or more architectural patterns thatpresent a general architecture that explains the relationsbetween the design patterns and the class frameworks.

To illustrate the flexibility of the COCHI pattern systemwe present two extensions made to the COCHI to supportadaptive Quality of Service and Emotional Awareness ingroupware applications, these extensions were made aspart of academic research projects in the field of CSCW.In both extensions it was necessary to work at the threelevels of abstraction of the pattern system. The COCHIarchitecture was modified to add new subsystems, eachsubsystem was specified as a design pattern using thealready defined design patterns, and finally, were implemen-ted as Java classes to extend the COCHI framework with thenew features.

4.1. Adaptive quality of service in groupware applications

Quality of Service (QoS) is a concept used in networkapplications to addresses performance guaranties, so thatapplications can specify their requirements and the networkwill try to satisfy them. Writing applications to take advan-tage of the QoS concept is not a trivial task. Developershave to pay attention to details such as building the appro-priate data structures to make a QoS specification, passingthe right arguments to the right functions, selecting the rightAPI and learning all its idiosyncrasies.

The extension made to COCHI allows groupware appli-cation developers to work at a higher level of abstraction,overcoming unnecessary complexity and avoiding commonpitfalls that arise when using low-level native OS APIs [21].In this section we describe the subsystems included in theCOCHI extension.

The QoS extension adds three QoS subsystems toCOCHI. The subsystems include features such as QoSmanagement, QoS specification, and QoS-aware communi-cation media.

QoS managementinvolves a QoS manager (based on theClient–Server design pattern) for three collaborativescenarios: casual interaction, brainstorm session, and virtualclassroom.QoS specificationis associated with the QoSmanager and considers different types of network infrastruc-tures such as ATM, RSVP, among others. Fig. 23 shows theclasses and relations between them and the session managersubsystem.

QoS-aware communication mediaadds some classes tothe Communication media design subsystem included inCOCHI to support QoS-aware video and audio (Fig. 24).

Fig. 25 shows a casual interaction scenario using QoS-aware video as communication media. With this applicationa virtual lab environment could be created where two par-ticipants in different locations have a video camera to feed avideo reflector. When a participant connects to the reflector,it will take the video feed from the other location anddisplay it in the video window, so there will be aware-ness of what is going on at the counterpart. In thisawareness mode the QoS level for the video windowwill be set to high.

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406402

Fig. 23. QoS manager and QoS specification.

Fig. 24. QoS-aware communication media.

Page 15: An extensible platform for the development of synchronous groupware

4.2. Emotional awareness for groupware applications

Affective computing, is a computer science research fieldthat relates to, arise from, or deliberately influence, humanemotions [30].

This extension to COCHI allows the development ofapplications that provide awareness of the emotional stateof participants. This knowledge can help improve decisionmaking in collaborative activities. For example, participantscould notice the level of understanding, stress, frustration,or satisfaction of other participants and act accordingly.

Fig. 26 shows the new classes integrated to COCHI tosupport emotional awareness and their relationship to othercomponents.

EA-icon (Emotional Awareness icon) is an extension ofthe Iconsclass used to represent user participants throughicons.EA-icon represents the emotional state of each par-ticipant in a collaborative session. TheEA-graph is awindow displaying a graph that uses a three-dimensionalspace used to describe and measure emotional states.Affec-tive engineis a concurrent object that detects user emotionsusing different kind of devices.

Fig. 27 shows an enhanced version of the Use Casesdrawing tool application, developed before, with anemotional awareness widget. We used this tool to apply atest to a set of students in order to measure their practicalknowledge in Use Case diagramming. In this case, the affec-tive awareness facility serves as a communication mediumwhere students look for clues to acknowledge their per-formance.

In this application we use the EA-graph to represent theaffective state of each participant collaborating. In the Fig.27 we can see a drawing window for the use case diagrams,a text chat window, and the EA-Graph window.

5. Conclusions

Reusability is one of the main topics in the softwareengineering discipline and one of its primary goals. Reus-ability can be achieved at different levels of abstraction and,the highest the level of reusability at which one works thegreater the benefits.

The software development process distinguishes three,

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406 403

Fig. 25. A casual interaction session using QoS-aware video.

Fig. 26. Emotional awareness.

Page 16: An extensible platform for the development of synchronous groupware

well delimited phases: analysis, design, and implemen-tation. During analysis, we define the requirements of thesystem that we want to develop. In the design phase, wedefine an architecture for the system, including the sub-systems that, together, will define the structure of thesystem. During implementation, we transform the architec-tural and design decisions to code.

Reusability can be achieved at implementation level. Inthis level, we can reuse the functions or classes provided bylibraries, but these libraries do not necessarily include all thefeatures we identified and defined during analysis anddesign. Thus, we need to go back to redesign the systemor modify the existing libraries to support the defined designspace. This is because there is no direct connection betweenthe libraries and the design elements.

If we reuse at the design level, we can take the architec-tural and design elements and modify them according to therequirements of the system. For instance, if we use a set ofarchitectural and design elements that document classframeworks, we have software elements of different levelsof abstraction in direct correspondence. In this way, if thedesign space defined does not include some of the featuresthat we require, then we can add them at the design level,and these features can be easily reflected in the code (classframeworks), facilitating the extension of the design spacedefined. Once we extended the design space, it could beused for the development of other systems taking advantageof the new features added.

Software patterns are a reusability technique that allowsthe reuse at different levels: architectural (architecturalpatterns), design (design patterns), and implementation

(implementation patterns or idioms). A pattern system is acollection of software patterns of the three types mentioned:architectural, design, and implementation.

Software patterns have been proposed for the develop-ment of several kinds of systems, including distributedand network systems [20,31], but none of these patternsdeal specifically with groupware. On the other hand, classframeworks, libraries, and toolkits have been developedspecifically for groupware [3,5–12], but they were built tosupport the implementation of groupware applications anddefine a design space that, as we mentioned, lack flexibilityto extend the design space with new functionality.

5.1. Strengths and weaknesses of COCHI

In this paper, we illustrated how the reusability techniquenamed pattern systems can be applied for the reuse atarchitectural, design, and implementation levels. We illu-strated this through the use of COCHI, a pattern system thatfacilitates the development of groupware applications.COCHI includes an architectural pattern that provides ageneral structure for the fundamental features of a group-ware application represented as subsystems in the architec-ture. COCHI also provides a set of design patterns thatdocument each subsystem, and at the lower level of abstrac-tion COCHI defines a Java class framework that implementsall the classes included in the design patterns.

We presented several groupware applications developedin a few weeks by software engineers who in most caseswere developing their first groupware application. We foundthat people using the COCHI class frameworks focused on

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406404

Fig. 27. A use cases session detecting user emotional state.

Page 17: An extensible platform for the development of synchronous groupware

the application’s functionality instead of low-level issueslike: how to send/receive information to/from session parti-cipants? or how to implement the particular floor controlpolicy and mechanism selected?, among others.

The aim of COCHI is the extension of its architecture andsubsystems for special purposes or specific functionality.We have shown two examples of such extensions made toCOCHI’s architecture: adaptive Quality of Service andaffective awareness in groupware applications. ThusCOCHI can be used as a platform to propose and test newgroupware features and functionalities.

COCHI has several advantages (as we have mentioned),but it also has some limitations. First, it is a platform for thedevelopment of synchronous groupware, thus it lacksfeatures for the development of asynchronous systems.Second, COCHI’s architecture is based on the client-servermodel (even though most platforms today use this kind ofmodel), which has some disadvantages such as the central-ization of data and processes, and the dependence on theserver for good performance and reliability of the appli-cations.

In conclusion, we can say that the COCHI pattern systemprovides a good basis for the design and implementation ofgroupware applications due to its good balance betweenease of use and flexibility.

5.2. Future work

We are proposing the automatic generation of groupwareapplication templates. We are building a toolkit that allowsdevelopers to select from the options given in the designspace and then generate a groupware application templateaccording to the requirements of the system and designdecisions taken. Once the template is generated, the devel-oper should complete the application according with thefunctionality required. As part of this project, a visualenvironment will support the implementation of the multi-user interface of the groupware application.

We expect COCHI to evolve with new extensions to thearchitectural and design patterns such as new kind of collab-oration awareness, support to multiple sessions, and newsubsystems to support useful features like mobile agentsthat participate during a groupware session and nomadiccomputing to allow the use of different kind of computingdevices such as PDA’s (Personal Digital Assistant), palm-tops, laptops, etc. during a session.

Finally, we are currently porting COCHI’s class frame-works to support the implementation of groupware appli-cations running over the WWW (World Wide Web), theubiquitous, largest communication platform.

Acknowledgements

This work was partially supportd by CONACyT scholar-ship No. 117161 provided to the first author.

References

[1] C.A. Ellis, S.J. Gibbs, G.L. Reln, Groupware Some issues and experi-ences, Communications of the ACM 34 (1) (1991) 38–58.

[2] I. Jacobson, M. Griss, P. Jonsson, Software Reuse: Architecture,Process and Organization for Business Success, Addison-Wesley,Reading, MA, 1997.

[3] T. Crowley, E. Baker, H. Forsdick, P. Milazzo, R. Tomlinson,MMConf: An infrastructure for building shared applications,Proceedings of CSCW’ 901990, pp. 329–342.

[4] J. Patterson, R. Hill, S. Rohall, W. Meeks, Rendezvous: an architec-ture for synchronous multi-user applications, Proceedings of CSCW’901990, pp. 317–328.

[5] P. Dewan, R.A. Choudhary, Flexible and High-Level FrameworkImplementing Multi-User Interfaces, ACM Transactions on Informa-tion Systems 10 (4) (1992) 345–380.

[6] A. Bonifiglio, Conference toolkit: a framework for real-time confer-encing, Studies in CSCW: Theory, Practice, and Design, Elsevier,Amsterdam, 1991.

[7] M. Winnett, R. Malyan, P. Barnwell, ShareLib: A Toolkit for CSCWApplications Programming Using X Windows in Design Issues inCSCW, Springer, Berlin, 1994, pp. 240–250.

[8] M. Roseman, S. Greenberg, Building real time groupware with group-kit, a groupware toolkit, ACM Transactions on Computer HumanInteractions 3 (1) (1996) 66–106.

[9] C. Schuckmann, L. Krichner, J. Schummer, J. Haake, Designingobject-oriented synchronous groupware with coast, Proceedings ofCSCW’ 961996, pp. 30–38.

[10] A. Chabert, E. Grossman, L. Jackson, S. Pietrowicz, C. Seguin, Javaobject-sharing in Habanero, Communications of the ACM 41 (6)(1998) 69–76.

[11] R. Burridge, Java Shared Data Toolkit User Guide, Sun Microsys-tems, Inc., 1998.

[12] G. Banavar, S. Doddapaneni, K. Miller, B. Mukherjee, Rapidly build-ing synchronous collaborative applications by direct manipulation,Proceedings of CSCW’ 981998, pp. 139–148.

[13] P. Coad, D. North, M. Mayfield, Object Models: Strategies, Patterns,& Applications, Prentice Hall, Englewood Cliffs, NJ, 1995.

[14] M. Fowler, Analysis Patterns: Reusable Object Models, Addison-Wesley, Reading, MA, 1997.

[15] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns,Elements of Reusable Object-Oriented Software, Addison-Wesley,Reading, MA, 1995.

[16] J.O. Coplien, D.C. Schmidt, Pattern Languages of Program Design,Software Patterns Series, Addison-Wesley, Reading, MA, 1995.

[17] R.C. Martin, D. Riehle, F. Buschmann, Pattern Languages of ProgramDesign 3, Addison-Wesley, Reading, MA, 1997.

[18] J.M. Vlissides, J.O. Coplien, N.L. Kerth, Pattern Languages ofProgram Design 2, Addison-Wesley, Reading, MA, 1996.

[19] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, S. Stal,Pattern-Oriented Software Architecture: A System of Patterns,Wiley, New York, 1996.

[20] R.K. Keller, J. Tessier, G. Bochmann, A pattern system for networkmanagement interfaces, Communications of the ACM 41 (9) (1998)86–93.

[21] G. Licea, J. Favela, J.A. Garcia-Macı´as, J.A. Aguilar, A patternsystem supporting QoS for synchronous collaborative systems,Proceedings of IEEE International Conference on Protocols for Multi-media Systems and Multimedia Networking, Santiago, Chile,November 1997, pp. 234–238.

[22] O. Garcia, J. Favela, G. Licea, R. Machorro, Extending a collabora-tive architecture to support emotional awareness, Proceedings ofEmotion-Based Agent Architectures’99 1999, pp. 46–52.

[23] T.G. Lane, Studying software architecture through design spaces andrules, Technical report CMU/SEI-90-TR-18, SEI, CMU, November1990.

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406 405

Page 18: An extensible platform for the development of synchronous groupware

[24] J. Favela, M.T. Soriano, M.A. Zapata, A design space and develop-ment process for collaborative systems, Proceedings of CYTED-RITOS International Workshop on Groupware, 97, 1997, pp. 33–42.

[25] K. Beck, R. Johnson, Patterns Generate Architectures, Proceedings ofECOOP’94 1994, pp. 139–149.

[26] R. Johnson, Frameworks� (Components1 Patterns), Communica-tions of the ACM 40 (10) (1997) 39–42.

[27] K. Beck, W.A. Cunningham, Laboratory for teaching object-orientedthinking, Special Issue of SIGPLAN Notices 24 (10) (1989) 1–6.

[28] D. Ruiz, J. Favela, Collaborative review and edition of HTML docu-

ments, Proceedings of CYTED-RITOS International Workshop onGroupware 98, Rio de Janeiro, Brazil, 1998, pp. 113–128.

[29] M. Fowler, K. Scott, I. Jacobson, UML Distilled, Addison-Wesley,Reading, MA, 1997.

[30] R.W. Picard, Affective Computing, MIT Press, Cambridge, MA,1997.

[31] J.A. Van den Broecke, J.O. Coplien, Using design patterns to build aframework for multimedia networking, Bell Labs Technical Journal 2(1) (1997) 166–187.

G. Licea, J. Favela / Information and Software Technology 42 (2000) 389–406406