SUPPORTING REUSABILITY IN FIXED AND MOBILE GROUPWARE APPLICATIONS

Abstract

In this paper we present COCHI, a pattern system that supports reusability in the development of groupware applications for fixed and mobile computers at different levels of abstraction: architecture, design and implementation. COCHI has two properties: ease of use and flexibility. In contrast with other groupware tools, COCHI maintains equilibrium between both goals. COCHI provides a class framework that allows a developer to implement groupware applications that can be executed on fixed and mobile computers, reducing the implementation effort. COCHI also provides a set of architectural and design patterns that add flexibility to the platform and permits its extension with new features not originally present. COCHI is particularly useful for research in the CSCW (Computer Supported Cooperative Works) field. We show how the flexibility property of COCHI was used to extend the architectural and design patterns to support features like Quality of Service (QoS), Emotional Awareness, and mobility. [PUBLICATION ABSTRACT]

Headnote

Abstract

In this paper we present COCHI, a pattern system that supports reusability in the development of groupware applications for fixed and mobile computers at different levels of abstraction: architecture, design and implementation. COCHI has two properties: ease of use and flexibility. In contrast with other groupware tools, COCHI maintains equilibrium between both goals. COCHI provides a class framework that allows a developer to implement groupware applications that can be executed on fixed and mobile computers, reducing the implementation effort. COCHI also provides a set of architectural and design patterns that add flexibility to the platform and permits its extension with new features not originally present. COCHI is particularly useful for research in the CSCW (Computer Supported Cooperative Works) field. We show how the flexibility property of COCHI was used to extend the architectural and design patterns to support features like Quality of Service (QoS), Emotional Awareness, and mobility.

Key Words

Reusability, pattern system, groupware application

1. Introduction

Reusability has been one of the main topics in the software engineering discipline and one of its primary goals. The 1968 NATO Software Engineering conference is considered the birthplace of the software engineering field. In this conference Mcllroy presented the paper [I], "Mass Produced Software Components". This paper can be considered as the seminal work on software reusability. Reusability is defined by the IEEE as "the degree to which a software module or other work product can be used in more than one computing program or software system" [2].

The basic idea behind software reuse is very simple: "Using existing software artifacts during the construction of a new software system" [3]. Normally, we think of software artifacts as pieces of code. The next step consists in extending the concept of "Software artifact" beyond the implementation or coding phase to analysis, design, etc. This is because reusability can help developers in every phase of the development process thereby reducing the redundant work that would enhance the reliability of the system, considering that each reused piece reused has already been tested.

Reusability can be achieved at three levels of abstraction: architecture, design, and code, which correspond to high level design, detailed design, and implementation phases of the software development process.

The architecture of a software system defines the structure, interfaces, and interaction between the parts (components, subsystems, etc.) of the architecture. As defined by Jacobson [4], architecture reuse can be achieved when "in an object-oriented system where implementation classes are organized in subsystems, the software architecture defines the static organization of software into subsystems interconnected through interfaces and defines at a significant level how nodes executing those software subsystems interact with each other" .

Reuse at the design level involves the use of a predefined skeleton for modelling some particular feature, normally related to a subsystem of an application's architecture. The best known technique for reusing design components or packages is the use of design patterns. Design patterns are documents that include the context, problem description, restrictions, and a good solution to a problem. Normally this solution is given in the form of a set of diagrams.

When we combine design patterns with software components we generate an application framework [5], which is defined as "a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact".

Software reuse has traditionally been achieved at the level of code. The most common technique to code reuse consists in the development of software based on libraries of functions, procedures, or classes. Other techniques for code reuse consist in the use of visual programming environments for specific domains such as user interfaces and data bases among others. These environments provide an application skeleton for a well defined design space.

As we have seen in this section, there are several techniques and tools that allow us to reuse at any of the three different levels of abstraction. In this paper we present COCHI, a groupware pattern system which includes reusable components at the three levels. Groupware is defined as a computer-based system that helps a group of persons achieve a common task using a shared interface [6]. Groupware applications include features related to collaboration, coordination, and communication that make them complex to design and implement.

As was documented in [7], there are several groupware development tools, some of them are easy to use, but not flexible, while others are very flexible, but hard to use. COCHI, as a pattern system, combines and maintains equilibrium between these two important features of development tools, ease of use and flexibility.

In section 2 of this paper we present the state of the art of groupware development tools. In section 3 we discuss about the object-oriented reuse technique known as pattern systems to understand the ideas behind COCHI. In section 4 we show the details of the structure of the COCHI pattern system. In section 5 we illustrate the tradeoff between ease of use and flexibility that makes COCHI an extensible groupware development tool. And finally, in section 6 we show the conclusions and future work.

2. State of the Art of Groupware Development Tools

Groupware tools have been documented since the appearance of the Computer Supported Cooperative Work discipline. Some of the most representative ones appeared in the 1990's and the first years of this century.

MMConf [8] was developed by Crowley et al. to support the implementation of replicated real-time applications. Rendezvous [9] was developed by Hill and Patterson. This is a tool for implementing synchronous multiuser applications. Rendezvous consists of an architecture based on a user interface management system and an architecture to support connectivity. Conference toolkit [10] was developed by Bonifiglio. This tool extends client-server model form X/Motif applications. Suite [11] was developed by Dewan as a flexible high level platform to support the implementation of multiuser interfaces. ShareLib [12], was developed by Winnett et al. This tool is a library that intends to make some technical groupware issues transparent to the programmers. Groupkit [13] was developed by Greenberg and Roseman to help programmers in the implementation of synchronous groupware. COAST [14] was developed by Schuckmann et al. This tool is a class framework that supports the implementation of platform independent synchronous groupware. Habanero [15] was developed by Chabert et al. This tool, like COAST, is a class framework written in Java. Habanero allows the modification of existing Java applications. Java Shared Data Toolkit (JSDT) [16] was developed by Burridge. This tool is a Java class library that supports the implementation of highly interactive groupware applications. The work by Banavar et al. [17] consists of a set of visual components written as JavaBeans. These components contain the infrastructure for synchronous cooperation. CCF [18] is a structured software system that consists of a network protocol and three layers: application-sharing desktop, communication tools, and interfaces for data management and computation sharing. The methodology defined by Guareis et al. [19] supports the development of groupware applications using a set of composable software components. Grundy et al. [20] developed a set of server-side software components that provide thin-client groupware solutions. Clover [21], developed by Laurillau and Nigay, is an architectural model for groupware. Clover defines three classes of services: production, communication, and coordination. Jazz [22], developed by Clark et al., extends a Java development environment to capture features of a collaborative open office environment. ANTS [23], developed by García López and Gómez Skarmeta, is a component framework that refines groupware development approaches, proposing new solutions at the conceptual, architectural, and technological levels.

The different groupware development tools can be classified according to their approach. The various approaches include tools that provide a run-time infrastructure for converting a single user application to a collaborative one, consist of libraries of functions or classes for supporting the basic characteristics of a groupware application, consist of class frameworks, or provide visual development environments.

Most of these tools were implemented for Unix workstations. Groupkit also runs in MS Windows. Habanero, JSDT, the work by Banavar, Jazz, and ANTS were implemented in Java, which makes them portable to different operating systems.

As we can see, there are many tools that support the development of groupware applications. Their purpose is to facilitate the detailed design and implementation of software. However, it has recently been acknowledged that reusability can be of greater value if incorporated during design rather than waiting for implementation [4].

When we reuse code (using a library, for example), we must restrict our implementation to the design options given by the classes, functions, or packages we choose to reuse. But when reusing at the design level, we can take the design packages (subsystems, modules, etc.) and extend them in order to incorporate the specific features of the system we want to implement. In other words, we can extend the design space defined by these packages.

In section 3 we describe patterns, a software reuse technique which is the basis of the groupware development tool we present in this paper.

3. What is a Pattern System?

Christopher Alexander [24] states, "Each pattern describes a problem that occurs many times in our environment and then describes the most important part of the solution to this problem, so we can use this solution many times". Alexander was talking about buildings, but what he said applies to software.

A pattern system is composed of a set of software patterns, including architectural patterns, design patterns, and idioms. A pattern system describes how its constituent patterns are related with other patterns, how these patterns can be implemented, and how software development can be supported using the patterns.

An architectural pattern defines the structure and organization of a particular type of system. It shows the big picture of the system including the subsystems and the relationships between them in the defined architecture. A design pattern shows the details of a subsystem, documents a framework, and contains the design rationale behind a framework that makes it easier to extend or modify. An idiom is a low-level pattern that describes how to implement particular aspects of components using a specific programming language. We can say that a framework is generated by the classes implemented by idioms and documented by design patterns.

Fig. 1 illustrates the relationships between the elements of a pattern system and it shows how a class framework can be benefited with the use of architectural and design patterns to generate a pattern system.

Software patterns are based on the experience of software developers and can be generated from abstractions of the generic characteristics of representative systems in a specific area. Software patterns provide a systematic approach for the reusability of code or design packages (classes, modules, etc.). There are several specialized catalogues of design patterns [25-27], pattern languages [28-30], pattern systems [31, 32], and related work that shows the importance and success of patterns in software development.

In the next section we present COCHI, a pattern system, which was created to support reuse during the development process of group ware applications.

4. COCHI, a Pattern System for Fixed and Mobile Groupware

Favela et al. [33] proposed a design space for groupware with seven dimensions obtained from the analysis of eleven groupware applications found in the CSCW literature. The dimensions are: interaction, participation, visualization, notification, coordination, distribution, and support.

Considering the design elements of each dimension of the groupware design space, we found that these can be classified in six groups that will be explained in the next section as the subsystems of the COCHI architecture: session management, floor control management, collaboration awareness, communication media, objects management, and collaborative interface.

The COCHI pattern system consists of a set of software patterns and Java classes that can be used to design and implement synchronous groupware applications for fixed and mobile computers, in which the participants interact with each other at the same time. Next we present the three components of the COCHI pattern system: the architecture with all its subsystems, the description of each subsystem, and the implementation of the classes included in the subsystems.

4.1 COCHI's Architectural Pattern

One well-known approach to define a software architecture is to organize it in several layers, because layers reduce software dependencies and promote reusability. A layered architecture allows us to organize software from its most general to its most specific. In a layered architecture, subsystems are organized in layers, where each layer is supported by a more general layer [34].

COCHI's architectural pattern (architecture) is based on layers that include several subsystems that can be described as design patterns. Fig. 2 illustrates the architecture of the COCHI pattern system.

The base of the architecture is the Client-Server design pattern that allows a client application to communicate with others through a server using a defined protocol.

Three layers compose the server. The configuration layer allows participants to configure the characteristics of the session. The collaboration layer of the server includes five subsystems that extend the Client-Server design pattern included in the server layer.

Four layers compose the client. The application layer is the groupware application itself. The collaborative interface layer represents the interface between the developer and the collaboration layer, its features, and services. This layer includes the elements needed for developing groupware applications based on the COCHI platform, including fixed and mobile computers. The collaboration layer of a client has the same five subsystems included in the collaboration layer of the server, so each subsystem of the client interacts with the corresponding subsystem of the server. The client layer contains the Client-Server design pattern.

4.2 COCHI's Design Patterns

We describe briefly the design patterns (subsystems) included in the server, client, and collaboration layers of both server and client. For a more detailed description consult Licea and Favela [7]. We begin with the description of the Client-server design pattern and then we present the five subsystems included in the collaboration layer.

4-2.1 The Client-Server Design Pattern

This design pattern includes the classes needed for handling the connection and event passing between groupware applications through a server. Fig. 3 shows the structure of the classes included in the design pattern.

The Server class is a thread that defines a generic server that listens through some port and receives connection requests from clients. The server creates an instance of Connection handler for each connection requested and uses this instance to receive/send events from/to a particular client.

The Server subsystem is a specialization of server that receives and processes events sent by the clients connected to the server and distributes the events to some or all of the connected clients.

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

The Client subsystem is a specialization of client that receives the events sent by the server and processes them according to the functionality of the collaborative feature it implements. Client subsystem can also send any type of event defined for the application to the server to be distributed to other connected clients.

4-2.2 The Session Manager Design Pattern

The session manager design pattern provides functionality that allows clients to join and exit from a particular session. This subsystem also registers the session name and information from each client (identification, name, and role). This design pattern is a specialization of the Client-Server design pattern. Fig. 4 presents the classes included in this subsystem and the design patterns associated with it.

In Fig. 4 we use the name Collaborative design pattern to indicate any of the design patterns included in the collaboration layer that will be explained in the next subsections. Collaborative interface refers to the subsystem contained in the collaborative interface layer of the client.

4-2.3 The Communication Media Design Pattern

The communication media design pattern allows clients to communicate with other clients in the session using one or more media: text, audio, or video. This design pattern is a specialization of the Client-Server design pattern. Fig. 5 shows the classes included in this subsystem and the design patterns associated with it.

4.2.4 The Collaboration Awareness Design Pattern

The collaboration awareness design pattern defines a subsystem that allows clients to be aware of the presence of other clients in the session. Clients are represented using a list, labelled pointers, icons, or a status line. This design pattern is a specialization of the Client-Server design pattern. Fig. 6 shows the classes included in this subsystem and the design patterns associated with it.

4-2.5 The Object Manager Design Pattern

The object manager design pattern defines functionality for clients to save objects, or groups of objects in a repository included in the server and to retrieve these objects in a later session. This design pattern is a specialization of the Client-Server design pattern. Fig. 7 shows the classes included in this subsystem and the design patterns associated with it.

4-2.6 The Floor Control Design Pattern

The floor control design pattern defines a subsystem to coordinate tasks between session clients through a defined floor control policy using one or more floor control mechanisms. The pre-defined mechanisms are: free, random, pre-emptive, FIFO, central moderator, pause detection, and round robin. Fig. 8 shows the classes included in this subsystem and the design patterns associated with it.

4-2.7 The Collaborative Interface Design Pattern

This design pattern is included in the collaborative interface layer of the client, and is composed of different types of windows and collaborative components. The purpose of this subsystem is to support the developer in the design of the user interface of a groupware application.

There are two groups of elements contained in the collaborative interface subsystem: specialized windows and collaborative user interface components (or widgets). Collaborative, private and secondary windows are specializations of Window, a generic window associated with the session manager subsystem.

Collaborative window is the main window of a groupware application. It is a public window that automatically sends to the server all the events generated in it. This window also receives all the events generated by other clients in the session. A secondary window is a public window that can be used by a collaborative window to perform specific tasks. The Private window stores all the events generated inside it until the user decides to send them.

Fig. 9 shows the classes included in this subsystem and the way in which they relate to the design patterns shown previously.

As a complement, COCHI includes GAVI (Groupware Applications by Visual Interaction), a visual programming interface [35] that helps groupware developers to design and generate the collaborative user interface of the application in an easier way. Using this programming interface, the developer can specify, by direct manipulation, the type and quantity of windows included in the groupware application and the collaborative widgets that will be added to the windows. Fig. 10 shows a snapshot of the visual programming interface.

4.3 COCHI's Class Framework

COCHFs class framework implements Java classes that represent those included in the design patterns, adding some useful classes that facilitate the implementation of groupware applications.

Following the architecture, the framework is divided in a client and a server class hierarchy. Programmers do not need to modify or extend any class in the server part of the framework. The framework contains a class to configure the server before its execution.

To implement a groupware application or convert an existing single user application using COCHFs class framework, a programmer needs to specialize the methods defined in a few classes, the ones included in the collaborative interface design pattern contained in the client.

COCHFs class framework has been used to implement more than ten groupware applications such as: collaborative painting, CRC cards generation [36], house of quality method [37], and gesture recognition for collaborative systems [38], among others.

In Table 1 we briefly describe the characteristics of some of the applications implemented with COCHFs class framework. Skills refer to the experience using the Java programming language and the COCHFs class framework. Novice has no experience with Java or COCHI, medium has some experience with Java, but not with COCHI, and expert has experience with Java and COCHI. Time represents the number of hours dedicated to the application, and LOG (lines of code) refers to the code written by the developers, not including the code provided by COCHFs class framework.

Most of these applications have been implemented as a proof of concept in collaborative systems graduate courses and we found that students using COCHFs class framework were able to focus on the application's functionality rather than low-level issues like how to send/receive information to/from clients or what kind of floor control policy and mechanism must be used. It was remarkable that the complexity of the applications developed using COCHI was much higher than those developed without it.

5. Extending COCHI's Design Space

We have classified different types of software development environments according to ease of use (to what extent they simplify application development) and flexibility (the facility with which new functionality, not originally considered, can be incorporated). A programming language, for instance, provides a great deal of flexibility, but is not particularly easy to use. At the other extreme, an application provides little flexibility to support functionality not originally considered, but requires no development effort.

The ideal development environment will be one that provides maximum flexibility and ease of use. Fig. 11 shows that a pattern system comes close to this ideal, since it provides ease of use without compromising flexibility. It reduces implementation effort since "the patterns provide steps and guidelines that specify their implementation" [31]. In addition, patterns can be extended for specific applications or families of applications.

A pattern system is not as easy to use as a final application, a run-time support platform, or a visual environment, but clearly a pattern system is easier to use than a class framework because design patterns document the class framework and can be extended for specific applications or families of applications, thus reducing the impiementation effort. Design patterns can be considered as the micro-architectural elements of a framework [6, 39].

As we saw in section 2, there are many tools that support the development of groupware applications for different operating systems and devices such as class, libraries, run-time support or application sharing, and visual environments, but they were built to support the implementation of groupware applications under some design space and they lack the flexibility needed to be extended to support new features.

In contrast with other solutions, the structure of COCHI based on software patterns and a tool for supporting the construction of the collaborative user interface allows designers of groupware to customize the platform according to their particular needs. The architecture, documented through an architectural pattern, can be extended with new design patterns (subsystems), each of which can be extended with different features, in addition to those already supported.

In the previous section, we saw that the class framework of the COCHI pattern system provides ease of use to implement groupware applications and we described briefly some of the groupware applications implemented. In this section, we present three extensions made to the COCHI pattern system: adaptive Quality of Service, Emotional Awareness and mobility in groupware applications. In these extensions it was necessary to work in the three levels of abstraction supported by COCHI. The COCHI architecture was modified to add new subsystems, each subsystem was specified as a design pattern using the already defined design patterns, and finally, were implemented as Java classes to extend the COCHI framework with the new features.

5.1 Adaptive Quality of Service in Groupware Applications

Quality of Service (QoS) is used in network applications to address performance guaranties, so that applications can specify their requirements and the network will try to satisfy them. Writing applications to take advantage of the QoS concept is not a trivial task. Developers have to pay attention to details such as building the appropriate data structures to make a QoS specification, passing the right arguments to the right functions, selecting the right API, and learning all its idiosyncrasies.

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

The QoS extension adds three QoS subsystems to COCHI. The subsystems include features such as QoS management, QoS specification, and QoS-aware communication media.

QoS management involves a QoS manager (based on the Client-Server design pattern) for three collaborative scenarios: casual interaction, brainstorm session, and virtual classroom. QoS specification is associated with the QoS manager and considers different types of network infrastructures such as ATM, and RSVP, among others. Fig. 12 shows the classes and relations between them and the session manager subsystem.

QoS-aware communication media adds some classes to the Communication media design subsystem included in COCHI to support QoS-aware video and audio (Fig. 13).

Fig. 14 shows a casual interaction scenario using QoS-aware video as communication media. With this application a virtual lab environment could be created where two clients in different locations have a video camera to feed a video reflector. When a client connects to the reflector, it will take the video feed from the other location and display it in the video window, so there will be awareness of what is going on at the counterpart. In this awareness mode the QoS level for the video window will be set to high.

5.2 Emotional Awareness for Groupware Applications

Affective computing is a computer science research field that relates to, arises from or deliberately influences human emotions [41].

This extension to COCHI allows the development of applications that provide awareness of the emotional state of participants [42]. This knowledge can help improve decision making in collaborative activities. For example, participants could notice the level of understanding, stress, frustration, or satisfaction of other participants and act accordingly. Fig. 15 shows the new classes integrated to COCHI to support emotional awareness and their relationship to other components.

EA-icon (Emotional Awareness icon) is an extension of the Icons class used to represent user participants through icons. EA-icon represents the emotional state of each participant in a collaborative session. The EA-graph is a window displaying a graph that uses a three-dimensional space used to describe and measure emotional states. Affective engine is a concurrent object that detects user emotions using different kind of devices.

Fig. 16 shows an enhanced version of the Use Cases drawing tool application, developed before, with an emotional awareness widget. We used this tool to apply a test to a set of students in order to measure their practical knowledge in Use case diagramming. In this case, the affective awareness facility serves as a communication media where students look for clues to acknowledge their performance. In this application we use the EA-graph to represent the affective state of each participant collaborating. In the Figure we can see: a) Chat window, b) Sketching window, c) Video conferencing window, and d) Emotion awareness chart.

5.3 Mobility in Groupware Applications

Mobility is one of the most interesting topics for groupware applications at this moment. Taking advantage of the multiplatform property of the Java programming language, we redesign COCHI's class framework to allow mobile clients. For this purpose we decided to use handheld computers running the Windows CE operating system. The result is a less complex set of classes that support the development of synchronous collaborative applications for mobile devices like Pocket PCs.

We redesign the communication media, collaborative interface, and collaboration awareness design patterns to include only the basic classes of these subsystems. In Figs. 17 and 18 we can see a group ware application running on both a desktop and a handheld computer. Fig. 17 shows a snapshot of the Use cases drawing tool running in a desktop (fixed) computer.

Fig. 18 shows snapshots of the collaboration options available for the same application running on a handheld (mobile) computer. In this case, due to the size of the screen, the user needs to swap between the collaborative window, the communication media, and the collaboration awareness.

Most groupware development tools do not support groupware application development for mobile computers. The extension described here gives COCHI an added value, supporting the development of groupware applications for fixed and mobile computers.

6. Conclusion and Future Work

One of the main topics and primary goals of the software engineering discipline has been reusability. It can be achieved at different levels of abstraction: analysis, design, and implementation. However, reusability at higher levels during the software development process could bring more benefits than the ones offered by reusability during coding or implementation only. At the code level, we can reuse, for instance, the functions or classes provided by a library, but these functions or classes were implemented in the context of a design space defined by this library, so we are restricted to this space. When we reuse at the design level, we can add new features to the design space and they will be reflected in the code, thus facilitating the extension of the design space they define.

Some authors have proposed software patterns for the development of different kinds of systems, including distributed and network systems [32, 43], but these patterns do not deal specifically with groupware. On the other hand, class frameworks, libraries, and toolkits have been developed specifically for groupware, but they were built to support the implementation of groupware applications and define a design space that, as we mentioned, lack flexibility to extend the design space with new functionality.

We show how the reusability technique named pattern systems can be applied for reuse at architecture and design levels, in addition to programming. We illustrate this through the use of COCHI, a pattern system that facilitates the development of groupware applications. COCHI includes an architectural pattern that provides a general structure for the fundamental features of a groupware application represented as subsystems in the architecture. COCHI also provides a set of design patterns that document each subsystem, and at the lower level of abstraction COCHI defines a Java class framework that implements all the classes included in the design patterns. Finally, as a complement for the design and implementation of the collaborative user interface, COCHI provides a visual environment.

Concluding, we can say that the COCHI pattern system provides a good basis for reusability at the three levels of abstraction due to its ease of use and extensibility. We have shown that COCHI's class framework provides an easy to use platform to implement groupware and COCHI's architectural and design patterns provide extensibility for new functionality such as Quality of Service, Emotional Awareness, and mobility features mentioned in section 4 that can be easily extended to all applications developed in COCHI.

For future work we are proposing the automatic generation of fixed and mobile groupware application templates. We are building a toolkit that allows developers to select from the options given in the design space and then generate a groupware application template according to the requirements of the system and design decisions taken. Once the template is generated, the developer should complete the application according with the functionality required.

We expect COCHI to evolve with new extensions to the architectural and design patterns such as new kind of collaboration awareness, support to multiple sessions, and new subsystems to support useful features like mobile agents that participate during a groupware session.

Finally, we are currently porting COCHI's class frameworks to support the implementation of groupware applications running over the WWW (World Wide Web), the ubiquitous, largest communication platform.

References

References

[1] M.D. Mcllroy, Mass produced software components, NATO Software Engineering Conference, Garmisch, Germany, 1968, 138-155.

[2] IEEE, IEEE standard computer dictionary: A compilation of IEEE standard computer glossaries (New York, NY: IEEE, 1990).

[3] C.W. Krueger, Software reuse, ACM Computing Surveys, 24(2), 1992, 131-183.

[4] I. Jacobson, M. Griss, & P. Jonsson, Software reuse: Architecture, process and organization for business success (Reading, MA: Addison-Wesley, 1997).

[5] R.E. Johnson, Frameworks = Components + patterns, Communications of the ACM, 40(10), 1997, 39-42.

[6] C.A. Ellis, S.J. Gibbs, & G.L. Rein, Groupware: Some issues and experiences, Communications of the ACM, 34(1), 1991, 38-58.

[7] G. Licea & J. Favela, An extensible platform for the development of synchronous groupware, Information and Software technology, 42(6), 2000, 389-406.

[8] T. Crowley, E. Baker, H. Forsdick, P. Milazzo, & R. Tomlinson, MMConf: An infrastructure for building shared applications, Proc. CSCW '90, Los Angeles, CA, 1990, 329-342.

[9] J. Patterson, R. Hill, S. Rohall, & W. Meeks, Rendezvous: An architecture for synchronous multi-user applications, Proc. CSCW '90, Los Angeles, CA, 1990, 317-328.

[10] A. Bonifiglio, G. Malatesta, F. Tisato, Conference toolkit: A framework for real-time conferencing, Studies in CSCW: Theory, Practice, and Design (Amsterdam, The Netherlands: North-Holland, 1990).

[11] P. Dewan & R. Choudhary, A flexible and high-level framework for implementing multi-user Interfaces, ACM Trans. on Information Systems, 10(4), 1992, 345-380.

[12] M. Winnett, R. Malyan, & P. Barnwell, ShareLib: A toolkit for CSCW applications programming using X windows, in Design Issues in CSCW (London, England: Springer-Verlag, 1994), 240-250.

[13] M. Roseman & S. Greenberg, Building real time groupware with GroupKit, a groupware toolkit, ACM Trans. on Computer Human Interaction, 3(1), 1996, 66-106.

[14] C. Schuckmann, L. Krichner, J. Schummer, & J. Haake, Designing object-oriented synchronous groupware with Coast, Proc. CSCW '96, 1996, 30-38.

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

[16] R. Burridge, Java shared data toolkit user guide (Mountain View, CA: Sun Microsystems, Inc., 1998).

[17] G. Banavar, S. Doddapaneni, K. Miller, & B. Mukherjee, Rapidly building synchronous collaborative applications by direct manipulation, Proc. CSCW '98, Seattle, WA., 1998, 139-148.

[18] CCF Project Team, CCF: A framework for collaborative computing, IEEE Internet Computing, 4(1), 2000, 16-24.

[19] C.R. Guareis de farias, L. Ferreira Pires, & M. van Sinderen, A component-based groupware development methodology, Proc. 4th Int. Enterprise Distributed Object Computing Conf., Makuhari, Japan, 2000, 204-213.

[20] J. Grundy, X. Wang, & J. Hosking, Building multi-device, component-based, thin-client groupware: Issues and experiences, Proc. 3rd Australian user Interfaces Conf., Melbourne, Australia, 2001, 71-80.

[21] Y. Laurillau & L. Nigay, Clover architecture for groupware, Proc. CSCW '02, New Orleans, Louisiana, 2002, 236-245.

[22] B. Clark & C. de Souza, Jazz: A collaborative application development environment, Proc. OPSLA '03, Anaheim, California, 2003, 102-103.

[23] P. García López & A.F. Gómez Skarmeta, ANTS framework for cooperative work environments, IEEE Computer, 36(3), 2003, 56-62.

[24] C. Alexander, S. Ishikawa, M. Silverestein, M. Jacobson, I. Fiksdahal-King, & S. Angel, A pattern language (Oxford, UK: Oxford University Press, 1977).

[25] P. Goad, D. North, & M. Mayfield, Object models: Strategies, patterns, & applications (Englewood Cliffs, NJ: Prentice Hall, 1995).

[26] M. Fowler, Analysis patterns: Reusable object models (Menlo Park, CA: Addison-Wesley, 1997).

[27] E. Gamma, R. Helm, R. Johnson, & J. Vlissides, Design patterns: Elements of reusable object-oriented software (Reading, MA: Addison-Wesley, 1995).

[28] J.O. Coplien & D.C. Schmidt, Pattern languages of program design (Reading, MA: Addison-Wesley Software Patterns Series, 1995).

[29] R.C. Martin, D. Riehle, & F. Buschmann, Pattern languages of program design 3 (Reading, MA: Addison-Wesley, 1997).

[30] J.M. Vlissides, J.O. Coplien, & N.L. Kerth, Pattern languages of program design 2 (Reading, MA: Addison-Wesley, 1996).

[31] F. Buschmann, R Meunier, H. Rohnert, P. Sommerlad, & S. Stal, Pattern-oriented software architecture: A system of patterns (New York, NY: Wiley, 1996).

[32] R.K. Keller, J. Tessier, & G. Bochmann, A pattern system for network management interfaces, Communications of the ACM, 41(9), 1998, 86-93.

[33] J. Favela, M.T. Soriano, & M.A. Zapata, A design space and development process for collaborative systems, Proc. CYTED-RITOS Int. Workshop on Groupware 97, Madrid, Spain, 1997, 33-42.

[34] M. Shaw & D. Garlan, Software architecture (Englewood Cliffs, NJ: Prentice-Hall, 1996).

[35] G. Licea, L.O. Escobedo, & R.G. Sarmienta, Developing groupware applications using a visual interface, Proc. ENC 01, Aguascalientes, Mexico, 2001, 913-918.

[36] R.F. Navarro, A. Ayala, G. Licea & J. Favela, C^sup 3^TO: A collaborative case for the analysis of scenarios applying the CRC technique (in Spanish), Proc. Software Engineering Workshop, ENC 97, Querétaro, México, 1997, 55-58.

[37] C.A. Ortiz, J. Favela & G. Licea, HQ: A collaborative system to improve software quality (in Spanish), Proc. Software Engineering Workshop, ENC 97, Querétaro, México, 1997, 68-71.

[38] J.J. Contreras, J.F. Garcilazo, J. Favela, & G. Licea, Gesture recognition in a collaborative system for document review (in Spanish), Proc. User Interfaces Workshop, ENC 97, Querétaro, México, 1997, 25-30.

[39] K. Beck & R. Johnson, Patterns Generate Architectures, Proc. ECOOP '94, 1994, 139-149.

[40] G. Licea, J. Favela, J.A. Garcia-Macias, & J.A. Aguilar, A pattern system supporting QoS for synchronous collaborative systems, Proc. IEEE Int. Conf. on Protocols for Multimedia Systems and Multimedia Networking 97, Santiago, Chile, 1997, 234-238.

[41] R.W. Picard, Affective computing (Cambridge, MA: M.I.T. Press, 1997).

[42] O. Garcia, J. Favela, G. Licea, & R. Machorro, Extending a collaborative architecture to support emotional awareness, Proc. Emotion-Based Agent Architectures '99, Seattle, WA., 1999, 46-52.

[43] J.A. Van den Broecke & J.O. Coplien, Using design patterns to build a framework for multimedia networking, Bell Labs Technical Journal, 2(1), 1997, 166-187.