Rapid Development of Non-Monolithic CSCL-Applications About the Benefits of Using a Prescribed Terminology in Web Programming Thorsten Hampel1 , Alexander Roth2 1 2
Heinz-Nixdorf-Institut, University of Paderborn, Germany
Decision Support & OR-Lab, University of Paderborn, Germany {hampel,roth}@upb.de
Abstract: Development and maintenance of CSCL-applications continuously face the environmental infrastructure’s high heterogeneity, as well as new or altered requirements during their lifetime. This paper presents a terminology based development approach, which proved very successful in practice. Compared to the conventional way in which conception and implementation stages are accomplished, the consistent use of a prescribed terminology in different modules and technologies saves time and money. The following paper describes the terminology and its technical realization, and clarifies its utilization in web programming considering PHP as showcase technology.
1. Introduction The requirements in the electronic learning and working field have changed within the last years. Today, the main challenge of modern e-learning-concepts and -infrastructures is to provide different infrastructures and systems that are adjusted to the specific needs of the users and the diverse contexts of application. To achieve this, the idea of using a unitary learning environment for different contexts of application has to be abandoned in the medium-term. The boundary between collaborative learning and working environment is increasingly melting, which makes the development of these systems even more complicated: Next to technological solutions for the interface-problem, there is the need for new development concepts to produce modular learning environments in a cost-efficient way and to achieve the higher requirements in modularity and integrity. The conventional procedure concerning the development of web based learning and working environment is especially affected by the implementation details. Many things have to be taken into consideration, which go beyond the plain technical view and take up time and money. An object-orientated analysis is required to deduce classstructures and a conceptual data-schema. Both, the class-structure as well as the data-schema have to be transformed into a programming language and a structured query language respectively. The coupling between application and persistence-layer (database or similar) has to be designed and implemented, and the consistency and integrity of the data model have to be assured for runtime. Thus, the utilization of an object-orientated programming language does not free software-architects and programmers from dealing with details of implementation. On the contrary: The language influences them in thinking about the problems and how they express the problems. According to one single language, certain solutions are obvious, others are latent respectively. In the paper at hand, we will show how a metaphor, serving the needs of a collaborative knowledgeorganization, can appropriately be used when transferred into a technological terminology, to support a wide range of e-learning-contexts. Thereby, the focus is at a persistent object structure of rooms, objects of content and incidents. These attributes form our central model of virtual knowledge-rooms. In the gained object structure, different services and protocols can be integrated in a flexible way. Therefore, the utilization of these technologised terminology for developing CSCL/W- applications has several advantages: o The programming on a higher level of abstraction allows the concentration on the professional realization of individual learning- and working scenarios. Unimportant details of implementation can be ignored during this process (see [Hunt and Thomas, 2005], p.56).
o A conceptual data-scheme is not part of the application, since the conceptual design of the scenarios is carried out through the technical terminology. Therefore, the usual effort concerning application’s development and maintenance is reduced to a great extend1 . Especially systems which form learning- and working environments have to be created very flexible and adaptive regarding communication, interaction and cooperation, so that the individual, as well as the collective dynamic evolution of the users can be supported (see [Wenger, 1998]). o The utilization of the terminology can be realized through various technologies. Therefore, the application modules developed are independent from one another, but also highly compatible with each other. Thus, an optimal flexibility and extensibility can be accomplished to fulfill the demands of dynamic and growing applications in heterogeneous IT-environments (see [Hampel et al., 2005]). After introducing our terminology’s fundemantal object model and its technical realization in the next section, section 3 demonstrates its cost and time saving utilization in web programming on the basis of some examples. As technology, the programming language PHP is exemplarily used.
2. Merging Terminology with Technology 2.1. The Metaphor of Virtual Knowledge Rooms One of the most important fields of intervention of knowledge organizations is the arrangement of areas: The area canalizes communication and permits or limits the structuring, allocation and the medium of information. As a central metaphor, virtual knowledge rooms offer (see [Hampel, 2002]) space to work with knowledge objects as well as the space to store them. They can be connected freely and in different ways, e.g. through hallways, doors or with the help of links between materials located in different rooms. Since there is the possibility of advanced structures through folders or sub-rooms within one room, it is also possible to display amounts of objects, persons and structural relationships in a semantic, logic and chronologic way. The concept of the media-functions identifies medial support, which provide technical systems to create, change and arrange knowledge-objects and their structures.
Figure 1. The object-model works as generic kernel (1). Functions for media and communication are build on it, and available through standardized internet protocols (2). This enables an integration into heterogeneous infrastructures (3), and adapted views on rooms and knowledge objects.
1
The conceptual data-schema is fully integrated in conventionally developed applications, and can only be hold consistent with the system, since it has to be adjusted to altered or new requirements during its lifecycle.
2.2. An Object-Model for the Metaphor of Knowledge-Rooms For the architectural-technical realization of the above mentioned basic-metaphors, a class/-or object-model realized in the Paderborn sTeam-System emerged. This system basically depends on the idea, to treat collaborative (CSCW-) environments as connected room-structures, where several documents and nested object-structures can be filed and where users are able to stay, move, and be aware. The basic object-model is characteristic for the structure of the collaboration-server sTeam. It is limited to the attributes object, room, link, document, connection, container, user and group and describes a terminology for learning and working-scenarios (compare to figure 1). The central element of the model is the object. Mainly, it has functions to set and select attributes, but also to set and review authorizations. Further classes inherit the basic characteristics of objects. A document adds the feature of administering the content of a document to the object. With the help of links, documents (objects) can be connected arbitrarily. The main function of a container is to encapsulate documents. Essentially, methods are provided to add objects and to ask for the content of containers and its environments. Therefore, the room is a special feature of the container, where users can stay. Rooms can be connected through gateways, which are a specialization of links. In that way, a corridor develops, where users can move along the set access rights. A user-object inherits all characteristics of the basic type object and of a container, and is therefore (just like a rucksack) able to carry all kinds of objects (see listing 5). It can also be featured with arbitrary attributes and authorities. Groups are directly derived from objects and allow the administration of different participants of one user group. Via access rights, various interactions and contexts of use can be controlled, and users move in virtual rooms and have the right to deal with different objects. Herewith different levels of self-organization of groups and users are realized. 2.3. Integration through Adjusted Views In order that the presented concepts can serve as a basis within a heterogeneous environment, the Paderborn collaboration server sTeam obtains the actual communication- and infrastructure protocols from the internet through protocol adaptors on the elements of the knowledge-room metaphor (compare to figure 1). Different clients can therefore produce various, adapted views on the virtual space. Thus, objects of annotations can be retrieved through mail-protocols, or documents can be rearranged and edited in collaboration in one room with the help of a shared whiteboard-client. Also the PHP programming interface, which is presented in the next chapter, produces adapted views on the knowledge-room metaphor and the objects structures administered in the persistency layer of the collaboration server.
3. Rapid Development with PHPsTeam The following section demonstrates the terminology-based development of CSCL-systems considering the widelyused PHP technology2 as an example, due to its high learning curve and its low requirements regarding a runtime environment. For this, running listings are presented, next to listings which are stripped-down for better readability and comprehension. Because our own practices with the terminology-based approach have shown, that compliance with a structured proceeding model is important to realize more complex CSCL-applications, we want to present the examples in such a manner, that their affiliation to this model becomes clear. Figure 2 describes the layered structure of a typical CSCL-system, which determines the implementation procedure owing to the dependencies of an upper to its underlying layer. But before becoming specific regarding terminology and our proceeding model, the subsections 3.1 and 3.2 deal with the setup and the user management of the PHPsTeam runtime environment, so that you can try out the given examples on your own accord.
2
See http://www.php.net for more information.
Comm u
nicatio
n Laye
Conte
r
nt Lay
Conte
er
xt Lay
er
Figure 2. The layered structure of CSCL-applications determines the order of implementation steps owing to the dependencies of an upper to its underlying layer. 3.1. First Steps: How to Connect to the Virtual Space The sTeam application programming interface (API) for PHP is called PHPsTeam3 . It is implemented on top of the COAL-protocol to communicate with the server (see figure 1). Before you can step into the virtual space, you need to setup the sTeam-server at first. Since it is developed under the GNU GPL licence4 , you have the options to download it for free5 or install sTeam through the internal package manager, if you use Debian GNU/Linux6 . In addition to the sTeam-server, you need a runtime environment for PHP5. When you have the required components running, the connection between PHP5 and sTeam can be made by instantiating the class steam connector, which comes with PHPsTeam. In order to be able to treat every term of the metaphor as stand-alone object whilst programming, it needs to retain a reference to an instance of this connector. The dispensation is made automatically by the class steam factory, which bundles all factory services for creating and instantiating terms’ objects. Listing 1 describes the fundamental frame for every following programming example: a connection is built up, the login status is checked and the user object is retrieved from the connection. Beside the functionality of adding a new user, in listing 2, one can recognize that every factory service demands that connection; that is, because the steam factory passes it over to new instances. 3.2. User Management Implementation of personalized learning and working environments always have to deal with conceptual and programming details of user management in one way or another. On the basis of PHPsTeam, one can use simple designed functions for managing users, groups and access rights. Listing 2 demonstrates how easy it is to register and activate a new user; it takes the programmer only three commands. If one needs to maintain a larger user profile, various attributes can be attached to the user object with the command set attributes (see listing 4 for an example of dynamic attributing). The registration process provides a key (line 1), which is necessary for later profile activation. In practice, other than activating the profile in the same script as exemplarily shown (line 10), we automatically mail this key to the registered e-mail-address to verify the given data. After receiving the key, the user can activate the profile on its own, supported by a second script. 3
A download option and a detailed documentation to PHPsTean can be found at http://www.PHPsTeam.org. The GNU General Public Licence, see http://www.gnu.org/copyleft/gpl.html. 5 See http://www.open-steam.org for more details. 6 Since the last stable release Debian/GNU Linux 3.1 (Sarge), the sTeam server is part of the distribution. An installation can be invoked with the single command apt−get install steam. 4
Listing 1. The sTeam-Connector 2 4 6 8 10
<?php r e q u i r e o n c e ( ” s t e a m c o n n e c t o r . c l a s s . php ” ) ; $ s t e a m c o n = new s t e a m c o n n e c t o r ( ” your . s t e a m s e r v e r . org ” , 1900 , ” r o o t ” , ” steam ” ); i f ( ! $ s t e a m c o n −>g e t l o g i n s t a t u s ( ) ) d i e ( ” Not c o n n e c t e d ” ) ; $ u s e r = $ s t e a m c o n −>g e t l o g i n u s e r ( ) ; ... $ s t e a m c o n −>d i s c o n n e c t ( ) ; ?>
As arguments, IP-address or hostname respectively, the port, username and password are necessary to establish a connection to sTeam (line 4). At the end of the script, this connection is closed and resources are set free (line 10).
Listing 2. Adding New User Accounts All types of objects in the metaphor of virtual knowledge rooms need a connection to the sTeam-server, which provides the persistence tier. Therefore, all PHPsTeam-objects need to retain a reference to an instance of steam connector (listing 1). The steam factory is responsible for this dispension.
1 3 5 7 9
$activation code = steam factory : : create user ( / / steam connector $steam con , ” roth ” , / / login ” secret ” , / / password ” roth@upb . de ” , / / e−m a i l ” A l e x a n d e r ” , ” Roth ” / / r e a l name ); $user = steam factory : : username to object ( $steam con , ” r o t h ” ) ; $ u s e r −>a c t i v a t e ( $ a c t i v a t i o n c o d e ) ;
3.3. The Context Layer Context binds messages and information. Due to this fact, it is very important for knowledge management. In CSCLsystems, various contexts can be in an objective manner, i.e. they constitute semantic structures of a subject area. But they can represent organizational and operational structures also, e.g. an organization chart or a curriculum as well as structured workflows and business processes, which can be learning environments too. For analyzing the problem area which should be supported by the later application, in the first step those contexts must be determined and implemented by means of the terminology. For this purpose, one can flexibly interconnect rooms through doors and gateways as described in subsection 2.2, and hierarchic structures can be mapped to subspaces, i.e. rooms or container available inside other containers. Then, those complexes of interconnected rooms and containers have to be implemented as objective classes (see listing 3 for a stripped-down example for modelling scenarios with the metaphors’ terms). An objective class adequately describes a place, an organizational unit, a professional or organizational concept, or a (learning) tool. More important than detailing single classes or the question, which attributes and methods those classes feature, is, at this time, the definition of fundamental structural relationships. Furthermore, actors and their various roles in different usage contexts have to be identified, and mapped inside the system by means of user groups. But actors can not only be associated to contexts, they can be related to one another too. Beside communicational relationships, which are primary considered in the communication layer (see 3.5), actors can have generalization and specification relationships, to outline a hierarchical structure or abstraction between them. In analogy to user roles, these kinds of relationships can be mapped by means of groups and subgroups also. The implementation of structural relationships between the objective classes can be realized dynamically. As already mentioned in the introduction, that, contrarily to conventional implementation concepts, a conceptual data schema is no longer needed. Here, data, metadata and relationships of an object can be managed by means of attributes flexibly attached to it. In case of changing requirements of an application during its lifecycle, those attributes’ get- and set routines have to be solely adjusted. Other operating expenses are not necessary.
Listing 3. Modelling a Course Szenario 2 4 6 8 10 12 14
$ a l l l e s s o n s = steam factory : : create room ( $steam con , ” l e s s o n s ” , $course room ) ; $ c o u r s e r o o m−>i n s e r t ( s t e a m f a c t o r y : : c r e a t e g r o u p ( $ s t e a m c o n , $ c o u r s e r o o m−>get name ( ) . ” p a r t i c i p a n t s ” , ” students ” ) ); $ p r o t e c t e d a r e a = steam factory : : create room ( $steam con , ” p r o t e c t e d a r e a ” , $course room ) ; $ p r o t e c t e d a r e a −>i n s e r t ( s t e a m f a c t o r y : : c r e a t e g r o u p ( $ s t e a m c o n , $ c o u r s e r o o m−>get name ( ) . ” t u t o r s ” , ” tutors ” ) ); ... $ l e s s o n = steam factory : : create room ( $steam con , $ l e s s o n t i t l e , $ a l l l e s s o n s ) ) ; $ n e w l e s s o n −>i n s e r t ( a r r a y ( $ s l i d e s h o w , $ c a s e s t u d y , $homework ) , AS LINK ) ;
In this example, a rudimental course room is modelled by means of the terminology. Thereby, a subroom is created inside the courseroom to act as a container for the course lessons, and also a protected area for tutors (line 1 and 6). Both roles, participants and tutors, are mapped to groups (line 3 and 8). In line 12 and 14 is described, how one can create a new lesson, and assign materials to it.
Listing 4. Dynamic Object Attributes 1 3 5 7 9
$ a t t r i b u t e = a r r a y ( ”LOM. L i f e C y c l e . P u b l i s h . D a t e ” => now ( ) ) ; foreach ( $ l e a r n i n g o b j e c t s as $ s i n g l e o b j e c t ) $ s i n g l e o b j e c t −>s e t a t t r i b u t e s ( $ a t t r i b u t e ) ; $ l e s s o n −>i n s e r t ( $ l e a r n i n g o b j e c t s ) ; ... $ s t u d e n t s o n l i n e = $ l e s s o n −>g e t v i s i t o r s ( ) ; $ a t t r i b u t e = a r r a y ( $ l e s s o n −>g e t i d ( ) , ” was p r e s e n t ” ) ; foreach ( $ s t u d e n t s o n l i n e as $ s i n g l e s t u d e n t ) $ s i n g l e s t u d e n t −>s e t a t t r i b u t e s ( $ a t t r i b u t e ) ;
As object repository, sTeam manages object attributes in a dynamical way. Attributes can be attached to, read or deleted from objects at any time. This way, metadata can be stored (line 1), as well as data or relations between objects through their unique object IDs (line 7).
3.4. The Content Layer The content layer defines, how documents, and content in general, can be used by certain user groups (roles or communities) in the contexts specified by the underlying context layer. Therefore, a flexible management of access rights is necessary, which can be configured in an uncomplicated way. Due to reasons of better maintenance and ease of integration, rights management should be designed as consistently as possible in all components of a CSCL-system. Thus, functions for rights administration of information carriers are attached directly with the carriers themselves in sTeam; i.e. beside the information itself, any kind of information carrier provides additional functions for reading and setting access rights. As described in the object model, the treatment of information carriers in sTeam is based on a conceptual and technological generalization, whereby an equal functional treatment is given, irrespective of their medium or their context7 . Every information carrier inherits general functions from the base class steam object. On the one hand, this consistency provides an immense assistance for software architects and programmers. On the other hand, this generalization step is an elementary precondition for a component spanning compatibility and reusability of information, and therefore, for a continuous availability during the whole learning process without struggling with differences in media format. As a matter of principle, information can be detached from external learning environments’ semantic contexts and hierarchies, and semantically restructured in other contexts. That gives the widely used term Reusable Learning Object (RLO) a new dimension: multimedia content for learning and communication can be combined system spanning by tutors and learners without effort (see [Roth et al., 2005]).
7
Zack describes in [Zack, 1999] a similar concept, and looks upon a knowledge unit ”as formally defined, atomic packet of knowledge that can be labeled, indexed, stored, retrieved, and manipulated. The format, size, and content of knowledge units may vary, depending on the type of explicit knowledge being stored and the context of its use.”
Furthermore, a successful knowledge management requires information redundancy and knowledge existence in various semantic and didactic contexts respectively. For this, sTeam offers options to copy objects (listing 5 line 3), and to generate hyperlinks to them (see figure 1, also listing 3 line 15). The latter permits the manifold logical presence of information, despite a physical singleness; an information update of the source object is directly present in other contexts through hyperlinks. A rucksack concept, as described in listing 5, offers a convenient option for programmers to implement a flexible content management. Listing 5. The Rucksack Concept 1 3 5
$workroom = $ u s e r −>get workroom ( ) ; $ o b j e c t s t o t a k e a w a y = $workroom−>g e t i n v e n t o r y ( ) ; $ u s e r −>r u c k s a c k i n s e r t ( $ o b j e c t s t o t a k e a w a y , AS COPY ) ; $ u s e r −>move ( $ n e w l o c a t i o n ) ; $ u s e r −>r u c k s a c k d r o p o b j e c t s ( $ n e w l o c a t i o n ) ;
As shown in figure 1, the user class inherits functions for filing and dealing with documents from the container class. This has enabled the rucksack concept, which allows an easy implementation of a very flexible content management for any type of documents.
The implementation of the content layer can be simply and nearly intuitively done by means of PHPsTeam. Next to the mentioned functions for access control, others are being at the programmers’ command, for deleting, arranging, annotating, and interlinking. New documents can be internally generated through sTeam, as well as being derived from external systems through FTP- or WebDAV-Clients (see figure 1). As a matter of course, an upload option via PHP is available, too. Listing 6 presents a fully functional script for this; thereby, the actual PHP-code for uploading the document is confined to one single function (line 7), since the target container is defined (line 6). Listing 6. Uploading New Documents As result of the first request (HTTPGET), this script delivers a HTML form for determining local files to upload. If the form is posted (HTTPPOST), the choosen file is transferred to the web-server, to be imported into sTeam via the COAL-protocol and assigned to a container object. Except the script’s workflow control and the form’s HTML-code, only two lines of code are necessary to specify the target and file the document (line 6-7).
1 3 5 7 9 11 13
<?php r e q u i r e o n c e ( ” s t e a m c o n n e c t o r . c l a s s . php ” ) ; $ s t e a m c o n = new s t e a m c o n n e c t o r ( ” y o u r . s t e a m s e r v e r . o r g ” , 1 9 0 0 , ” hampel ” , ” s e c r e t ” ) ; i f ( $ SERVER [ ”REQUEST METHOD” ] == ”POST” ) { $workroom = $ s t e a m c o n −>g e t l o g i n u s e r ()−>get workroom ( ) ; $workroom−>upload ( ” f i l e t o u p l o a d ” ) ; } e l s e { ?> <html><body><form method =”POST” e n c t y p e =” m u l t i p a r t / form−d a t a ”> <i n p u t t y p e =” f i l e ” name =” f i l e t o u p l o a d ”> <i n p u t t y p e =” s u b m i t ” name =” go”> </form ></body ></html> <?php } ?>
3.5. The Communication Layer The main focus while developing CSCL-systems is on the support of communication and collaborative problem solving. In addition to an awareness component, sTeam supports asynchronous and synchronous communication as basis functionality. As described in 2.3, current internet protocols for communication are brought together inside a room, whereby room-based messages and actions are transformed into protocol-specific information (and vice versa). An event controller ensures the forwarding of one adaptor’s incoming information to other protocol adaptors, so that, for example, one IRC-message can be brought to all other members being aware in the working room by means of the shared whiteboard or connected Jabber-clients (see figure 1). In case of PHPsTeam, one has to consider the fact that data exchange between web-server and browser normally proceeds on top of HTTP, which is stateless; an event-driven notification is hardly feasible, since every connection via this protocol is a single, autonomous transaction. Therefore, PHPsTeam is limited to the support of asynchronous communication, like blackboards, discussion boards, document annotations and internal and external mailing. The class steam messageboard, as part of PHPsTeam, is implemented by the usage of sTeam’s annotation functionality, simply because an annotation is an annotatable document, too; one can easily implement each imaginable form of communication board with it.
Listing 7. Communication Support PHPsTeam supports asynchronous com- 2 munication such as exchanging messages 4 between users and user groups (line 1), different forms of discussion boards (line 6 3-5), and shared document annotations 8 (line 6-8).
$ t u t o r −>s e n d m e s s a g e ( $ s u b j e c t , $ m e s s a g e b o d y , $ p a r t i c i p a n t s ) ; ... $ q u e s t i o n = $ m e s s a g e b o a r d −>a d d t h r e a d ( $ s u b j e c t , $ m e s s a g e ) ; $answer = $ m e s s a g e b o a r d −>a d d a r t i c l e ( $ q u e s t i o n , $ s u b j e c t , $message ) ; ... $ b u l l e t i n = steam factory : : create textdoc ( $steam con , $filename , $ c o n t e n t ) ; $document−>a d d a n n o t a t i o n ( $ b u l l e t i n ) ;
4. Conclusion and Outlook On account of the mentioned reasons we started with, CSCL-applications often have to meet changing and new requirements during their lifetime. Here, we exemplified, how CSCL-applications can be developed rapidly by the continous usage of our terminology during conception and implementation stage. This approach is not reliant on an integrated conceptual data schema, and therefore, it prevents the implementation on a low level of abstraction for better adaptability and reactivity. Our experiences with the presented architecture and the terminology-based implementation of CSCLcomponents have shown that the well known drawbacks of the conventional object-oriented approach do not occur herein: On the one hand, there was an improvement of productivity during concept development and implementation. On the other hand, with each application development we recognized an improved reactivity concerning dynamic processes and the following altered requirements, what has simplified the maintenance of these systems to a great extend. For the time being, we are developing standardized modules via this concept, which are dynamically combinable to cover blended learning szenarious seamless in the metapher of a workbench. This work takes place in the context of the project Locomotion - Low-Cost Multimedia Organisation and Production8 , funded by the German Ministry of Education and Research, and the University of Paderborn. During the next three years, workflows of such processes as module-planning and -examination, as well as knowledge organization, should be supported through both, a university-wide technological framework, and organizational service-units.
References Hampel, T. (2002). Virtuelle Wissensr¨aume - Ein Ansatz f¨ur die kooperative Wissensorganisation. PhD thesis, University of Paderborn, Paderborn. Hampel, T., Roth, A., Kahnwald, N., and K¨ohler, T. (2005). An Adaptable Platform for Evolving Communities of Practice. In Mambrey, P. and Gr¨ather, W., editors, Proceedings of the Workshop Design for Large-Scale Digital Communities, 2nd International Conference on Communities and Technologies, 13.-16.06.05, Milano, Italy. Hunt, A. and Thomas, D. (2005). The Pragmatic Programmer. Addison-Wesley, 14th edition. Roth, A., Hampel, T., and Suhl, L. (2005). Platform Spanning Cooperative Learning - An Integration of Distributed Environments based on Virtual Knowledge Spaces. In Kommers, P. and Richards, G., editors, Proceedings of Ed-Media 2005, 27.06.-02.-07.05, Montreal, Canada, pages 1620–1625. AACE. Wenger, T. (1998). Communities of Practice. Learning, Meaning, and Identity. Cambridge Univ. Press, Cambridge. Zack, M. (1999). Managing Codified Knowledge. In Sloan Management Review, volume 40, pages 44–58, Cambridge.
8
Please visit http://locomotion.upb.de for more details.