Considerations on the Application of Object-Oriented Reuse Technology to the Computer-Supported Cooperative Learning Domain

Karin Becker Ana Paula T.Bacelo Blois Pontijicia Universidade Catdlica do Rio Grande do Sul

{ kbecker, anapaula@inf.pucrs.br)

Abstract

In the sofiware engineering field, reuse is considered the key for achieving quality, reducing costs and increasing productivity. Such expectations motivate the proposition of generic, reusable solutions for the development of applications in various domains. In this paper, we address some initial considerations on the potentials of object-oriented (00) reuse technology, particularly frameworks, in the Computer-supported cooperative learning (CSCL) domain. The paper discusses the striking aspects of such technology, the difficulties for defining expected functionality for CSCL applications, and describes some of the existing customizable solutions for the CSCL domain. Two of them, namely TOP and Habanero, are analyzed in more detail.

1. Introduction

Advances in technology are affecting how people interact, work and learn. Much emphasis has been placed on the potentials of groupware for education and training [17][23], due to the collaborative and interactive nature of the learning process, defining a research area commonly referred to as Computer- Supported Cooperative Learning (CSCL). Among the motivations in this area are learning improvement, wider access to educatiodinformation, as well as costs reduction [23].

Nowadays, a number of generic environments, frameworks and toolkits for developing CSCL environments are available. Some of them can be adapted to educational settings (e.g. [ l I][ 12][10]), whilst others are specifically targeted at this domain (e.g. [6][22][15][21]). The benefits expected from starting the development of a CSCL based on a pre- existing, tailorable solution, are the same ones expected in the software engineering field for software development in general. In that field, reuse is believed to be the key for improving software quality, increasing development productivity and reducing costs [2].

The potentials of the Object-oriented (00)

0-7695-1351-4/01 $10.00 0 2001 IEEE

paradigm for reuse have been stressed over the past decade, with particular focus on two reuse technologies: frameworks and patterns [14]. A framework offers an application skeleton that can be customized by an application developer, based on the refinement of provided classes and connection of objects. Patterns are means to reuse experience (e.g. design, architecture).

Our group is studying alternatives for taking advantage of 00 reuse technology in the development of collaborative learning environments in the WWW. Our long term goals are to gather requirements for different types of web CSCL environments, to verify whether it is possible to define a kernel of basic functional requirements, and to investigate opportunities for 00 reuse technology in the CSCL domain, particularly frameworks and patterns. In this paper, we present some initial considerations towards these goals.

This paper is structured as follows: Section 2 discusses the striking aspects of 00 reuse technology, frameworks and patterns; the difficulties involved in the definition of expected functionality for CSCL applications are addressed in Section 3; Section 4 describes some of the existing customizable solutions for the CSCL domain, and presents a more in-depth analysis of two of these solutions, namely Top and Habanero; Section 5 draws conclusions.

2. Object-oriented Reuse

According to [2], reuse technologies can be roughly classified into two major groups: composition and generation. Composition technologies are characterized by the existence of autonomous, identifiable reuse units, and deriving new software is a matter of applying a set of well-defined composition principles to connect these building blocks. Generation technologies are based on the existence of patterns or transformation rules, which can be systematically applied, possibly by an automated generator, to derive new systems. Three levels of reuse in the 00 paradigm have been addressed with relative success: code (reuse of classes), design (reuse of abstract classes and frameworks [9]) and experience (reuse of patterns). Classes and frameworks represent component-oriented

164

reuse technology, whilst patterns are an example of generation technology.

Reuse-based development is subject to two primal, but contradictory forces: adaptability and reusability. Reusabilily refers to the ability of applying a generic solution to a variety of different contexts, implying that it is possible to customize it according to the characteristics of the situation at hand, possibly through the extension of the proposed solution (ex/ensihili/y). Adtiprtrhilily refers to the easiness for performing such a customization. The easiest i t is to adapt it, the more limited is the reuse, and vice-versa [SI.

A,frirmework is a reusable design of all o r part of a system that is represented by a set of abstract classes and the way their instances interact. A framework offers an application skeleton that can be customized by an application developer, who refines the abstractions provided by the framework, create and initialize objects, and connect them to define the global behavior of the application. Frameworks can be classified according to two dimensions: scope and customization techniques 181. According t o their scope, frameworks are classified as infrrr.s/ruc/ure, middle~~trre-in/egra/ion and en/erpri.se t/pp/icu/iiin, where only the later is targeted at a specific domain (e.g. telecommunications, CSCW). As for the customization process, frameworks are classified us ~ ~ h i l e - h i i x and hltrck-box. White-box frameworks rely on inheritancc and overwriting mechanisms in order to achieve extensibilily, whereas black-box ones are aduptetl by composing objects that conform to pre- defined interfaces. White-box frameworks are considered harder to adapt, since the use of inheritance requires the understanding of internal details. Black-box frameworks are easier to adapt, since one only needs to know the interlace of the expected components. On the other hand, they are harder to design, because one has to carefully foresee all possible reuse situations, and define llcxible interfaces that represent these situations.

Frameworks have a long life-cycle [18]: they should be derived from the experience of building different applications in that domain, of which the common aspects are factored out and abstracted; they tend to start as white-box frameworks and evolve to black-box ones; and part of mature frameworks are the infrastructure for using them, in particular. documcntation, visual configuration, inspection and testing tools. The more mature they are, the easier to adapt, possibly by a person with a less technical profile. Accurate and comprehensible documentation is crucial to the success of framework-based development. Fayad and Schmidt (81 highlight that documentation often focus on low-level, method-oriented documentation, which fails to capture the strategic roles and collaborations. In that sense, the particular role ot pattern languages is studied as an elegant way to

document frameworks [ 131. Though not originally proposed in the context of

the 00 paradigm, patterns have become a popular way to reuse design experience in the 00 community. A pattern describes a problem to be solved, a solution, and the context in which that solution works. Developers who share a set of patterns have a common vocabulary for describing their designs and also a way of making design tradeoffs explicit. Patterns are much more abstract than frameworks, because they are targeted at transmitting experience that cannot be encapsulated into components. Patterns have many applications nowadays. Design patterns [9] focus on transmitting the experience of designs that facilitate reuse (mostly oriented towards the use of black-box customization techniques). Architectural patterns 141 focus on describing reified application architectures (e.g. distributed systems, interactive systems).

3. CSCL Domain Requirements

The devclopment of any generic customizable solution for a given domain implies a deep knowledge of the basic requirements of applications in such domain. Unfortunately, CSCL is a buzz word, for which no consensus exist in determining its scope, goals, role, and functional requirements. Definitions of CSCL ranges from the application of cooperative learning techniques supported by computer [20], to computcr- mediated communication applied to educational settings [23][6]. In this section, we survey the main concepts, taxonomies and requirements found in the literature, in an attempt to convey to a more precise understanding of CSCL applications.

CSCL have a clear intersection with the Computer- Supported Cooperative Work (CSCW) area. Groupware is a term normally employed as the technical infrastructure used to implement a CSCW application [ 5 ] . Various taxonomies contribute to a better definition of the distinct types of groupware, their goal and requirements. Groupware has been classified using dimensions such as lime, .spi/ce, group .size and previ.sibili/y [ 5 ] . Coleman [7] proposed a number of functional categories, among them: a) electronic mail and messaging; b) group calendaring and scheduling; c) electronic meeting systems; d) conferencing systems; e) group document handling; f) decision support systems, g) workflow and h) coordination systems. Mandviwalla and Olfman [16] stress that, to match the work life of organizational groups, groupware must provide: a ) support for multiple group tasks; b) support for multiple work methods; c) support for the development of the group; d) interchangeable interaction methods; e) support for multiple behavioral characteristics; f) accommodation of permeable group boundaries; and g)

165

adjustment to group’s context. Despite the valuable contributions of the aforementioned work, a unified vision of groupware is still lacking, and further work is required to better integrate these various dimensions.

The interactive and collaborative nature of the learning process makes the adoption of group support tools a natural choice for reaching quality in education [6]. Brna 131 argues that computer support for collaboration with learning purposes can be improved only if there is a deeper insight of the collaboration model to be supported, and provides a conceptual framework for understanding the collaboration model: a) task division and control; b) collaboration as a state or process; c) collaboration as a means or end; and d) awareness of a collaboration contract. Wolz et al. [23] propose a taxonomy for computer-mediated communication applied to educational settings, which classifies communication tools according to time, place and peers (interpersonal/group). According to [23], besides support for communication according to the proposed taxonomy, CSCL functionality includes support to: a) various aspects of course organization, b) diversified media, c) follow up and assessment, and d) anonymity. Santoro et al. [20] propose to organize the study of CSCL environments according to 9 dimensions: a) learning theory; b) cooperation model (e.g. information search, problem solving); c) domain (e.g. mathematics); d) interaction technology (i.e. synchronous and asynchronous); e) interaction degree (small to big); f) cooperative work activities (e.g. group memory, coordination); g) platform (e.g. Unix); roles assignment (e.g. teachedstudent); and h) relationship to other areas.

CSCL is evolving fast. From the analysis of existing tools, it becomes clear that it is too soon to conclude about required CSCL core functionality, particularly considering that very little is known about the impact of the features already listed on the learning process. Works such as [23][17] highlight that the potential of CSCL will become more clear as we know more about the impact of CSCL and new designs on the learning process; new roles of teachers and students; new learning theories; interaction between pedagogy and technology; CSCL, students and learning assessment; technology evolution, among others.

4. Generic Solutions for CSCL

A number of generic environments, frameworks and toolkits for developing CSCL environments are already available. As mentioned, reuse is subject to two contradictory forces: adaptability and reusability. Considering the learning context, two roles can be distinguished by the type of competence possessed: the educator (competence on the domain) and the software

developer (technical skills for application development). The former seeks for solutions that can be easily adapted, and the latter is required for providing such solutions, and for extending them when they are not fully adaptable. Roschelle et al. [I91 stress that the collaboration of these two roles is essential to attend the growing demand on educational software.

Tools such as WEBCT [22], AulaNet [6], Learningspace [ 1.51, provide a generic configurable environment for distance learning, which offers diversified tools for communication (e.g. email, chat), coordination (e.g. calendar), course organization (e.g. material, course structure) and assessment (e.g. quiz, exercises), encapsulated as components. The customization of these environments is to be performed by an educator with a minimum amount of training, and it is relatively easy. However, customization options are minimum, basically limited to the selection of components for a customized working space. Also, the addition of new, personalized components is often a problem, if not imposible. Such environments are interesting from an institutional point of view, since they provide a standard environment for distance learning, regardless the subject. Nevertheless, their reusability is minimal out of that context, and prevents a teacher from experimenting different issues in a CSCL, for instance, learning theory, collaboration model, specific interfaces, etc.

Works such as [19][21], consider essential the existence of a dynamic component library in order to increase reusability. An infrastructure to support the development of collaborative project-based learning environments is proposed in [21], composed of an environment and a components repository. Although the infrastructure does not offer explicit support for the development of new components, i t does propose to gather the experience on building such components through domain patterns (e.g. cooperative editing tool). Rochelle et al. [I91 stress the importance of developing such components through the cooperation of developers and educators, and analyze issues for successful educational software components development and reuse, such as component granularity, interoperability, support for educator cognitive style, among others.

TOP [ I l l , Habanero [12], and Groupkit [IO] are examples of 00 frameworks targeted at the development of groupware in general, but which can easily be adapted to educational settings. The development of new applications using these frameworks implies the refinement/extension of provided abstractions, the creation of objects and their initialization, and their connection to define the global behavior of the application. This approach favors reusability instead of adaptability, but i t implies certain technical skills. Indeed, in most cases, the teacher would

166

have to count on someone with technical skills to design and develop a CSCL environment with the desired features. On the other hand, one is able to include in such designs all desired features targeted at obtaining certain results in the learning process. This is particularly interesting, since we are just starting to realize how technology can improve and enhance learning. Frameworks can also be used to support the development of new components for configurable environments. In the remaining of this section, we further describe and evaluate 2 frameworks, namely TOP and Habanero, based on a practical experience (attempt) of use.

4.1. Case Study: TOP and Habanero

This case study involved the comparative development of a very simple collaborative application using two frameworks: Top and Habanero. The application was a WebChat that offers various chat rooms. The choice of these two particular frameworks was motivated by their availability. The following aspects were observed in the experiments: a) the basic facilities offered by each framework for developing a collaborative application; b) the type of skills necessary for reusing the framework; c) the process for instantiating framework classes and connecting objects; d) the process for extending the framework, if necessary; e) support for reuse, particularly documentation and customization tools. This experience also evaluated these frameworks from an 00 point of view, considering adaptability degree and easiness; flexibility for reuse in other contexts and extensibility. Table 1 summarizes our experiences.

TOP [ I l l is a framework developed in Java targeted at the construction of collaborative environments in the Web. It provides 10 pre-defined abstractions, which allow the creation and management of group memory (Box, Boxobject, BoxObjecfType, View), users control (User, Role) and different types of interaction among these (Environment, Session, Floorcontrol, Broadcast). TOP also includes a server (Topserver) and an applet that encapsulates all communication routines between the client and the server. To develop a specific application, one has to have at least a certain amount of knowledge on HTML and JavaScript, besides of TOP platform (available abstractions and their respective methods).

For the analysis of TOP, in addition to WebChat, we considered another application under development in our group, namely W302 [I], a much more complex CSCL. The following aspects can be reported from our experience with T O P

a) Webchat was easily developed, and TOP abstractions were useful and sufficient. As for W302,

many aspects could not be easily in terms of TOP abstractions, such as distinct levels of access to group’s memory and roles, objects representation and retrieval, and objects display (views).

b) TOP applications are accessed through a WWW browser, and therefore, one may concentrate a great deal of the application on its interface, using resources such as HTML and JavaScript, and a minimum interaction with TOP. Additionally, TOP provides a graphical tool for instantiating objects (Adrnin application), but which does not offer facilities for connecting these instances. These two features allow TOP to be used with people trained on simpler techniques, if compared to Java programming. On the other hand, we observed that in practice TOP deals with a minor portion of the collaborative application: adaptation is mostly related to the development of a whole application in HTML/JavaScript, rather than to the extension of framework classes and creatiodconnection of objects. It is possible nevertheless to customize the framework itself, in which case a deeper knowledge is required (e.g. Java, 00 programming, sockets);

c) Extending TOP functionality is not an easy task, due to design problems [9], such as: Topserver concentrates too much intelligence and control; some methods are too big (if distributed in smaller methods, one could vary just specific parts of the behavior); specific and related behavior is not concentrated in a single class;

d) The lack of documentation was certainly the most serious problem. The documentation available consisted of technical papers reporting different versions of TOP, a really brief description of TOP methods, few examples of very simple applications, as well as intensive interactions with TOP’S author. In the context of W302, a lot of additional documentation has been generated by our group, as more experience on its use was acquired. Indeed, WebChat, of which the development started an year after W302, was easily developed due to the documentation produced by our group.

Habanero [I21 provides a framework for creating collaborative Java applications, and an environment containing a set of applications, allowing people to interact on the Internet using a variety of applications that share state and events. The framework provides 29 Java packages containing classes, interfaces and methods targeted at creating or converting existing applications and applets into collaborative applications, called Hablets. The Habanero environment enables to create collaborative work environments and virtual communities. The environment includes a server that hosts sessions and a client that interacts with sessions using a variety of Hablets. Sessions can be recorded,

167

persistent, access restricted and can even be anonymous. The Habanero client provides the interface to define, list, create, join and interact with a session. The client provides functionality from session control (e.g. user identification, notification mechanism). Habanero provides a number of predefined hablets that are useful for CSCL, such as whiteboard, telnet, electronic conference, voting tool, collaborative editor, etc.

Habanero is a powerful framework, and provides a comprehensive set of abstractions for constructing synchronous collaborative applications. However, existing documentation concentrates on the use of the Habanero environment, particularly on the conversion of an applet into a Hablet. One wishing to develop a new tool using Habanero classes is provided with minimum documentation to explore the 29 Java packages, which follows JDK documentation standards, except that no explanations or comments are provided for package elements. Considering the time available for the experiment, we were not able to develop a trivial application as WebChat due to the complexity of the framework, and the total lack of support, particularly documentation. The following conclusions were drawn from our experience with Habanero:

a) It was impossible to evaluate the usefulness, adaptability and reusability of Habanero framework classes, due to the lack of appropriate documentation;

b) To construct a collaborative tool, one has to be particularly skilled on the use of Java, development of collaborative applications and programming concepts in general. On the other hand, the conversion of that tool into a Hablet, its insertion into the environment, as well as the use of the environment for accessing tools, are tasks that require much less skills. However, the customization options for the environment are minimum (basically, tools addition).

c) As already mentioned, the Habanero site provides a number of white papers orienting on the use

Frameworks/ Evaluation criterion

Usefulness of abstractions

customization level

application developer skills

adaptability (complexity) reusability extensibility documentation amount and quality visual customization tools framework scope

of the environment and hablets creation, but help on the use of classes is minimal. Documentation on Habanero packages follows JDK documentation style, and all problems reported on use of such documentation style are faced by Habanero users. Finally, available examples are too simple to guide on the use of classes, even for a simple application as WebChat.

TOP

Good for applications of small/medium complexi ty Novice: application interface Expert: Top classes

Novice: basic notions of HTML, JavaScript and Top objects functionality Expert: skilled in Java and distributed applications

according to application complexity medium

low and complex insufficient

limited to object instantiation Application enterprise

5. Conclusions

In this paper, we presented some initial considerations on the use of 00 frameworks in the CSCL field. Frameworks are subject to intensive research, and there are many open issues that need to be addressed before a wider acceptance of reuse-based application development is achieved, such as framework development, customization process, framework maintenance and integration, potentials of patterns and pattern languages, etc. Expectations in terms of productivity and quality, motivates its exploitation in a number of fields, CSCL among them. However, CSCL is a fast evolving area, and existing systems are not yet representative of its potentials for learning improvement. This difficulty implies problems for developing widely acceptable reusable solutions. Existing solutions, such as configurable learning environments, components or 00 frameworks for specific aspects of CSCL applications, provide important but partial solutions. It is our opinion that it will take long for the CSCL domain to stabilize, as the community experiments new ideas for the use of interaction technology for learning, and new frameworks/components will be proposed in accordance to advances in this field.

The limitations highlighted in Section 4.1 about two out of the few existing frameworks for CSCL field, are representative of the problems involved in developing and using frameworks in general.

meworks

Habanero

Unable to evaluate due to complexity

Novice: environment (including conversion of Hablets) Expert: Habanero classes Novice: skilled in Java and distributed applications Expert: highly skilled in Java, and distributed applications

~~

high and complex insufficient for using classes

distributed system infrastructure

168

Developing frameworks is a hard task and they can only be assessed through practical experiences. The difficulty for extending frameworks can partly be justified by white-box framework designs, given that they are not mature enough, as well as the lack of appropriate customization support. In the CSCL field, there is the additional need of targeting the customization process to people with a less technical profile. This implies the development of the necessary customization infrastructure, definition of the customization options available to each type of profile, as well a clear prioritization between extensibility and adaptability properties. The existence of these two types of application developers profiles is essential in the CSCL field, for they represent the required knowledge on the domain and technical skills, respectively, and support must he provided for developing a shared communication language to discuss application requirements. Future research is oriented towards the supporting infrastructure that enables frameworks to be easily and effectively reused, considering these two profiles. Among the open issues we can mention: a) documentation, orienting both novice and skilled (re)users; b) mature framework designs oriented towards black-box customization; c) configuration tools targeted at novice users, compatible with their cognitive view and skills; d) participatory design for integrating the contributions of both profiles; among others. For documentation, pattern languages can be investigated, given that they are not only a means to structure experience orienting on the (re)use of framework elements, but can be designed to address various profiles. Architectural and design patterns play a major role in the conversion of white-box frameworks into black-box ones, thus enabling a configuration process more focused on the activity of instantiating and connecting objects. The right granularity of framework abstractions is the result of many iterations between design and reuse attempts. Customization tools targeted at novice users must allow the understanding, instantiation and binding of framework abstractions in a way compatible with their cognitive style and skills. The support for the interaction of both technical and educator profiles is necessary for gathering requirements, providing assistance for adapting and extending framework abstractions, assess framework designs, provide feedback for framework (re)design, and collect (un)successful experiences of reuse-based CSCL application developments.

Acknowledgements

This work was partially supported by CNPq-Brazil (grant 520100/96-4).

References

[ I ] Becker, K.; Zanella, A. “A Cooperation Model for TeachingRRarning Modeling Disciplines”. In: 4” CRIWG, Blizios, 1998. Proceedings. p.97-112. [2] Biggerstaff, T, Richter, C. “Reusability framework, assessment, and directions”. IEEE Software, v.4, n.2, p. 41-49, March 1987. [3] Brna, P. “Collaboration Models”. Revisfa Brasileira de Informritica nu Educa@o, v.1, n.3, p.9-15,1998. (in Portuguese) [4] Buschmann, F. et al. Partern-Orienied Sojware Archiieciure. John Willey and Sons, 1996. [5] Chaffey, D. Groupware, Workflow and Intranets. Digital Press, 1998. 264 p. [6] Choren, R.; Fuks, H.; Lucena, R. “Using a Group Support System to Meet Educational Objectives”. In: 6* CRIWG, Madeira, 2000. Proceedings. IEEE Press, 2000. p.86-93. [7] Coleman, D. Groupware - The Changing Environment. Captured at Oct. 2“d 1998. Available at: hlto://www.collaboralz.con7/publications/se~li~n I -2.htm. [SI Fayad, M. “Object-oriented application frameworks”. CACM, v.40. n.10, p.32-38, Oct. 1997. [9] Gamma, E. et al. Design Parierns: Elemenis of Reusable Objeci-Oriented Sojware. Addison-Wesley, 1995. [IO] Groupkit: Available at: hrto://cpsc.ucalp3rv.ca/oroiects/~o~iolab/~o~iukil. [ 1 I ] Guerrero, L.; Fuller, D. “A Web-Based 00 Platform for the Development of Multimedia Collaborative Applications”. Decision Support Sys/ems.v.27,n.3, p.255-268, Dec. 1999. [I21 Habanero. NCSA HabaneroO 2.0 API. Captured at July 20th 2000. Available at: htt~://havsfiin.ncsil .uiuc,~~~i~iabane~o/API/. [ 131 Johnson, R. “Documenting Frameworks using Patterns”. In: OOPSLA92, Vancouver, 1992. Proceedings. ACM

[ 141 Johnson, R. “Frameworks = (Components + Patterns)”. CACM, v.40, n.10, p. 39-43, Oct. 1997. [ 151 Lotus Notes. “Learning Space”. Lotus Development Corporation, 1997. [I61 Mandviwalla, M.; Olfman, L. “What do Groups Need? ACM TCHI. v.1, n.3, p.245-268, Sept. 1994. [I71 Reinhardt, A. “New ways to learn”. Byte, v.20, n. 3., p.

[I81 Roberts. D.; Johnson, R. “Evolving Frameworks: A Pattem Language for Developing Frameworks”. In: Paitern Languages of Program Design 3. Addison-Wesley, 1998.

[ 191 Roschelle, J. et al. “Developing Educational Software Components”. Computer, v.32, n.9. p 50-58. Sept. 1999. [20] Santoro. F, Borges, M.; Santos, N. “Computer-Supported Cooperative Learning Environments: A Framework for Analysis”. In: EDMEDIA ’99, Seattle, 1999. Proceedings. [21] Santoro, F.; Borges, M.; Santos, N. “An Infrastructure to support the development of collaborative Project-Based Learning Environments”. In: 6Ih CRIWG, Madeira , 2000. Proceedings. IEEE Press, 2000. p.78-85. [22] Webct. Webct. “User‘s Manual”, 1997. [23] Wolz, U et al. “Computer-mediated communication in collaborative educational settings”. SIGCSE/SIGCUE

SIGPLAN, 1992. p. 63-76.

50-72. March 1995.

p.47 1-486.

ITlCSE‘97. USA, p.51-69, 1997.

169