Group Learning of Programming by means of Real Time ... - CiteSeerX

Group Learning of Programming by means of Real Time Distributed Collaboration Techniques Crescencio Bravo1, Miguel Á. Redondo1, Antonio J. Mendes2, Manuel Ortega1 1

Departamento de Informática, Universidad de Castilla-La Mancha Departamento de Engenharia Informática, Universidade de Coimbra

2

1 Introduction The Collaborative Systems area has developed quickly in the nineties and it is reaching full maturity. These systems are being successfully applied in different work activities (CSCW, Computer-Supported Cooperative Work) as well as for learning (CSCL, Computer-Supported Collaborative Work). One of the domains in which this collaboration paradigm can be applied is in the construction of computer programs or programming. In the subject area of Programming Fundamentals in the different Spanish universities, practical classes are taught with languages like Java, Pascal or C. Initially, some problems that the students have to solve in pairs are outlined. These exercises are usually of intermediate difficulty and allow practicing the different aspects of programming. In each pair the students collaborate face to face when modelling the problem by means of different representations, when editing the source code, when compiling, when debugging errors and when executing the program. This organization in pairs is mainly due to the limitations in the number of computers available in laboratories. On the other hand, this situation also happens to give the students the opportunity to get accustomed to team work in order to facilitate their integration in the development teams of companies in the future. This approach of Pair Programming is popular in the business sphere, mainly in organizations using eXtreme Programming (XP). In this kind of task, two programmers design software together in the same computer, working collaboratively in the same algorithm, design or programming task. The situation is identical to the aforementioned case of teaching practical programming. The Pair Programming model has demonstrated to be beneficial in students of programming. Quantitative and qualitative

Bravo, C., Redondo, M.A., Mendes, A.J., Ortega, M.

studies show that the use of this approach in the lessons of Programming Fundamentals improves the students' learning, increases their satisfaction, reduces their shared frustration and decreases the number of bugs in the programs developed [10]. But when it is not possible for two students to be physically together, computer technology can support collaboration at distance. Thus, the concept of computer Collaborative Programming arises. Collaborative Programming is the application of collaborative strategies and computer support to Pair Programming. This allows, not only two, but three or four users to work in group. Previous studies [7, 11] indicate that Collaborative Programming does not only accelerate the problem solving processes, but rather it improves the quality of the software products. According to Johnson [5], the process of analysing and criticising software artefacts produced by other people is a powerful method to learn programming languages, design techniques and application domains. A system that allows geographically distributed programmers to participate concurrently in the design, coding, test and debugging and documentation of a program is RECIPE (REal-time Collaborative Interactive Programming Environment) [8]. This tool allows the easy conversion of single-user compilers and debuggers in collaborative applications without modifying the executable elements (transparency) and the integration of existent collaborative editors in the system. However, it does not register the programmers’ work in order to draw conclusions on their work, neither does it offer specialized tools for communication and awareness. In spite that the computer laboratory is the natural place to carry out these works, the students not always finish them in the time scheduled, so they have to complete them in out-of-school time in their homes or in free computer classrooms. Moreover, on many occasions self-study tasks are proposed that can also be done in group. With our proposal, work at distance is allowed and motivated, optimising the time the students can spend on the subject, since sometimes they have to move to their partner’s home or to the study centre to finish the exercises. A factor to take into account as an additional benefit is the motivating aspect of collaboration at distance, which offers tools to which young people are accustomed, such as chat or electronic mail. With this new approach the scenario that takes place consists in the students (two or three), at home or in their educational centre, editing together a program that solves a previously outlined problem, compiling it simultaneously, debugging it and finally making it run. To make this feasible, high speed connections facilitating synchronous interaction are required. Currently, there are a great number of DSL connections available in homes and university centres have high speed networks.

Group Learning of Programming by means of Real Time Distributed Collaboration Techniques

In this work we outline the exploration of these possibilities and the modelling of this kind of systems for the realization of practical exercises in programming, in Java or in any other language. This way, a Collaborative Programming system would be available, which could be used as a CSCW/Groupware system for companies as well as a CSCL system for learning in teaching centres. The paper is organized as follows: the next section is a short presentation of DomoSim-TPC, a CSCL environment used to apply its positions and part of its technological infrastructure to the kind of systems we approach; in section 3, the collaborative programming process is modelled and the components that make up these systems are described; in section 4, some aspects of the pedagogical support are considered; the next section shows a first prototype of the system; and finally, in section 6, the conclusions are drawn and future work lines are shown.

2 DomoSim-TPC: A Design Collaborative System DomoSim-TPC [1] is an environment of collaborative learning of design in Domotics by means of complex problem solving, with which the students discuss, design and simulate in shared work areas. The system supports the whole teaching-learning process, including tools for the organization and analysis of activities on the part of the teacher. This system proposes a semi-structured interaction model for the synchronous collaborative resolution of design problems, following techniques such as Collaboration Protocols [9] to structure the learning process, the Language/Action Perspective [12] to arrange the execution of certain tasks, and the Flexible Structuring [6] to build effective tools of communication and coordination. A collaboration protocol describes the shared workspaces available and how the group of students can navigate along these spaces. A workspace is an area of development and exchange of information, which is independent but related to others in the system. The workspaces proposed by this system are five: 1. Design: Where the model representing a solution to the problem is built. 2. Work Distribution: Where the students distribute and organize their work defining an allocation of actions. 3. Parameter Definition: Where the general variables of the problem are defined. 4. Cases and Hypotheses: Where the students define cases and hypotheses of simulation.


5. Simulation: Where the model is simulated and the students experiment with it. These workspaces integrate different mechanisms that support the process of design and simulation in group [2]: − Direct manipulation mechanisms: The students design and simulate the models by means of elementary actions of direct manipulation, following the collaborative electronic whiteboard based on the objectaction model. − Communication and coordination support: While designing and simulating the solution to a problem, the students can use a Structured Chat and a Decision-Making Tool. The latter is activated by means of a button available in the Structured Chat. − Awareness techniques: To facilitate real time collaboration, we have given great importance to awareness [4], which is the perception and knowledge of the interaction that other people carry out in a shared workspace. For that reason, tele-pointers, lists of participants and lists showing the interactions carried out are used.

Fig. 1. Design Workspace.

In Fig. 1 the main DomoSim-TPC tool is shown: the tool supporting Collaborative Design. On the left, the operator (1) and links (2) toolbars, and on the right, the draw toolbar (3), are shown. The operators and the links relating them are the model components. The Session Panel (4), the Structure Chat (5) and the area (6) for interaction messages and errors (6) on the left of the chat can be seen. The work surface (7) contains the house plan on which the model is built. The data model that makes up the solution and the construction process that produces that model are


persistent, being stored and available for the teacher’s query as well as for the continuation of the work in other session. This feature differentiates CSCL systems from CSCW systems; in the former the product is as interesting as the process itself that allows building it.

3 Modelling of the Collaborative Programming Process We will apply the structuring model of the DomoSim-TPC system and its collaboration-support mechanisms to the Collaborative Programming systems. In the programming process we distinguish several stages (source code edition, compilation and execution of object program) that will be described with a collaboration protocol. When the students use the system they carry out domain tasks, and communication and coordination tasks. The domain tasks are those related with programming. The communication and coordination tasks allow users to exchange information about the domain, to coordinate actions and to reach agreements. 3.1 Collaboration Protocol We identify a 3-stage collaboration protocol. It is described in the graph in Fig. 2. Each stage or node corresponds to a workspace where to carry out one of the three domain-specific tasks. The main workspace is Edition/Revision, in which one user edits the source code. This workspace can also be used to revise the source code without carrying out changes in it. From this workspace, the compilation can be carried out or the execution can be directly started when the object program is available. The group’s stay will be short at the Compilation workspace: the system will call the corresponding compiler and will show the compilation messages in a workspace area. Then, the students can observe the compilation results (errors messages, line numbers...), discuss on them and carry out the debugging (if there are errors) moving to the Edition/Revision workspace. If there are no errors they can access the Execution workspace. The program execution is carried out in a specific console. When finishing any of these two tasks, the group will always be located in the Edition/Revision workspace to start the process again, correcting the program if the expected results are not obtained. In Pair Programming users with two different kinds of roles are identified [10]: driver and observer. During the edition, the driver has the control of the interaction (keyboard/mouse) and carries out the design or cod-


ing, and the observer revises the work of the fellow pair member looking for bugs, considering alternatives and outlining questions. While the driver reflects upon his/her work, the observer asks for clarifications and explanations as the resolution process evolves. For the computer-supported Collaborative Programming systems we model a one-user edition task as this traditional method proposes, overcoming in this way the implementation difficulties of a synchronous collaborative editor and giving more importance to the negotiation for the turn shift in the edition role, which the students have to manage.

Fig. 2. Collaboration Protocol for Programming.

Fig. 3. Conversational graph for a proposal.

The navigation along the workspaces is organized by means of proposition mechanisms (Fig. 3). A first student makes a proposal of navigation and the fellow students (or the partner) will answer him/her in agreement or disagreement. The proposals and the reactions to them are expressed by means of buttons. When all the students agree or they abstain, the navigation to the new workspace takes place. A abstention is produced automatically by the system when a student does not answer in ten seconds, although this time setting is configurable. If no agreement is reached or no proposals are made, the group cannot work. Thus, the responsibility of moving forwards falls on the group and their participants. This same mechanism is used to manage the edition role turn shift, to carry out the compilation and to run the program execution.


3.2 Support for Domain Tasks The domain tasks are materialized following the paradigm of interaction by means of direct manipulation based on the object-action model. In the edition, the objects are the language particles (variables, methods, classes...) or, at a smaller granularity level, the characters that are inserted or deleted in the source code. The actions are inserting, deleting, selecting, saving, cutting, pasting, etc. In the compilation and execution workspaces there are neither significant objects nor actions. The direct manipulation is also used for the coordination tasks. The objects are the abstractions that model the proposition and communication processes: edition turn, compilation proposal and execution proposal; and the actions are those of proposing, being in agreement, being in disagreement and being absent, which will be generated if no other action is carried out. 3.3 Support for Communication and Coordination The communication and coordination instruments are used from all the workspaces. Communication is materialised by means of a Structured Chat, which is based on the Flexible Structuring for communication proposed by Lund et al [6], which allows the exchange of text messages among the learners. This chat is structured because it offers a preestablished set of communication acts. The messages that can be sent are classified according to three criteria: − Type of message: According to the type, the messages can be assertions, questions and answers. − Position in the dialogue: In relation with the position the text message takes in the dialogue, there are initial and reactive messages. − Type of adaptation: According to the type of adaptation of the message to the context, the messages can be adaptive or non-adaptive. The adaptive messages collect data from the domain tasks and generate particular messages for these situations. For example, depending on the classes, methods and variables existing in the source code, messages including these elements can be sent. We propose the following specific messages for Collaborative Programming systems: − Discussion messages: • "I think that...": assertion, initial and non-adaptive. • "I think so": assertion, reactive and non-adaptive.


• "I don’t think so”: assertion, reactive and non-adaptive. • "Why...?": question, initial and non-adaptive. • "I don’t know": answer, reactive and non-adaptive. • "Because..." : answer, reactive and non-adaptive. − Messages related to domain objects: These messages have a link with the different domain objects, which are classes, methods, attributes, etc. and are manipulated mainly in the Edition workspace. Two kinds of messages are proposed: • “The (class | method | attribute | reserved word | variable) is missed”: assertion, initial and adaptive. • “A mistake in the (class | method | attribute | reserved word | variable) can be seen”: assertion, initial and adaptive. − Free messages: To offer an additional communication functionality to the users giving them more freedom, messages with free text can be used. However, the students will be always guided during the system training in the preferential use of the structured messages, which structure the communication with semantically understandable forms suitable for the domain task and also facilitate the later communication analysis. For that reason, the chat registers the last five free-text messages sent, which saves keying time and focuses the students’ attention in a small set of messages. In certain experiences or in different moments this kind of messages could not be available in order to enforce the students to use the other two kinds of messages: structured and object-related. Although it is possible to use audio and video channels during any collaborative activity, including programming, the textual structured communication has an advantage with respect to audio and video: it allows registering the communication acts so that they can be analyzed afterwards. From an audio or video stream it is difficult to extract meaningful information about the communication. However, if each chat message is stored, this log can be analyzed by means of diverse techniques. This approach has been explored in the Monitoring and Analysis Subsystem of DomoSim-TPC [1]. The coordination support is shown in the three proposition processes described which are specific to each one of the tasks or domain workspaces, which, as the navigation along the workspaces, follows the conversational graph of Fig. 3. The utilization of actions (buttons) to represent speech acts such as to propose, to agree, etc. is inspired on the Perspective of Language as Action [12].


3.4 Awareness Techniques In the execution of domain tasks as well as of coordination and communication tasks awareness functions are available. This support is offered by means of the following elements: − Session Panel: This is the main awareness element. It shows a list of participants in the session. Besides the name of each participant the photo of the user is also shown in order to reduce the barrier that implies remote collaboration. Each user’s name is shown in a particular color used to identify his/her interactions. These interactions will be reflected in the same color. In addition, this panel shows the state in which each user is. We propose the following states: editing, communicating, observing, compiling and running. − Tele-pointers: Although it is not necessary to have drawing tele-pointers since there is not a collaborative whiteboard, it is really interesting to show the edition pointer of the user whose turn it is. Therefore, only a tele-pointer has to be shown. It is a text-edit cursor, which shows the area in which the user is editing or the character that is being manipulated. − Interaction lists: There are three coordination areas: turn shift, compilation proposal and execution proposal. Each one incorporates a message list that shows the initial proposals as well as the agreement/disagreement messages, always including the sender. − Awareness in the communication: The Structured Chat shows a list of the messages and their author.

4 System Interventions and Process Monitoring For the success of the programming learning task by means of program construction a suitable management of the edition turn is required. In the system modelled, the students are responsible of this management. One of the aims of this research consists in exploring which turn shift mechanisms are more productive in these situations. When the turn assignment is the users’ responsibility, the limitations of a student can be overcome with the knowledge or skills of another. But so much freedom makes it possible that a student never participates, the other carrying out all the actions. An advantage of computer-supported Collaborative Programming versus Pair Programming is that the turn shift could be the responsibility of the system, so that the time would be distributed equally among all the participants enforcing them all to participate. Other negotiation


mechanisms that assure participation and maximize the pedagogic benefit can be established. Besides the structuring of the turn shift there are many other pedagogic possibilities to guide the process, based on the ideas of the Intelligent Tutoring Systems. But this is a future objective of the system. However, we consider appropriate to incorporate a function that allows the students to consult the error statistics and detect which errors they usually make in order to focus their attention in the aspects in relation to these errors and facilitate discussion on this. The analysis of the work carried out by the students, during the experiences or when they conclude, is specially interesting in this domain. If we pay attention to a group of students at work, we can see that in each task they have a different behavior. In the Edition all of them contribute with ideas or edition actions. During the compilation they stay expectant to observe the result. When the compilation ends, above all when there have been errors, there is a reflection process which leads to their correction. Finally, in the execution, there is a common work of definition of input data and of interpretation of the output data, looking for incorrect functioning or execution errors. The behavior and work of the group, if registered in an appropriate way, can be studied with different techniques of Artificial Intelligence, such as Fuzzy Logic, Neural Networks or Genetic Algorithms, which can contribute to design a more effective system. The group’s navigation along the workspaces, the communication and the proposition processes are registered in the system. But the storage of the actions in the editor, mainly the ones relative to the correction of a programming error, is not a trivial aspect because it is convenient to associate each action with the related error. In order to do so there are two possibilities: 1. The student relates which changes in the edition correspond with which compilation errors. This makes the registration possible but makes the students work more. For this purpose a list of error messages could be made available, so that the student first selects the error to correct and then modifies the source code. 2. The system relates each error with its correction. This mechanism has an advantage: the registration is transparent to the user. However, it is complex to put it into practice. A first approach is based on the line numbers in which errors occur and on the line numbers in which the changes are carried out. But in this case, it is necessary to take into account that the line number of a error can change when other error has been corrected (if lines are deleted or inserted), that other corrections or improvements not coming from any error can be made, and that certain errors produced in a line can be corrected in other different lines.


To facilitate this second possibility and to register the produced errors correctly it is necessary to define how the error lines and the error types are shown in the specific compiler used. This is necessary since the system is independent of the language used. The language should simply have a compiler and an interpreter or virtual machine. This definition will be carried out using a configuration function.

5 The COLLEGE System COLLEGE (COLLaborative Edition, compilinG and Execution of programs) is a system developed to support the task of group programming, as previously described. In Fig. 4 the user interface of the tool that allows users to access the system is shown. When the user is connected to the server, a tool to manage sessions is available. In this case, contrary to DomoSim-TPC, the teacher is not the one that takes charge of defining the work sessions, but rather it is the role of the students themselves. A session is defined by means of a name, a type, a file and a schedule in which the session can be carried out. The file contains a formulation of the problem to be solved that will be available to consult from COLLEGE. The students can see the participants connected to a session by clicking on the session in the list.

Fig. 4. Login and session management in COLLEGE.

Fig. 5 shows a work session with COLLEGE. The areas for Edition/Revision task (1), and Compilation and Execution tasks (2), as well as the three areas for the proposition processes (3, 4, 5), the Session Panel (6) and the Structured Chat (7) can be seen. In the figure the students are elaborating a program to solve second degree equations. When the code has been compiled and some errors have occurred, the students start dis-


cussing with the aim of solving them. Once the program has been finished and the students have agreed on running it, the execution console is activated in the way shown in Fig. 6 (1). The compilation and execution tasks use the same console. During the execution an area for entering data is available (2) and the Structured Chat can also be used.

Fig. 5. A Collaborative Programming session in COLLEGE.

Fig. 6. Console for program execution.

The system is developed in Java, and operates following a client/server model on TCP/IP networks to facilitate its use on the Internet/intranet. The synchronization subsystem operates on the Synchronization Infrastructure for Collaborative Systems (ISSC), developed by our research group starting from the Java Shared Data Toolkit (JSDT)©, which presents a centralized communication architecture.

6 Conclusions and Future Work The COLLEGE system aims to be a means to investigate behavioural aspects in the work of edition, compilation and execution of programs in


group, as well as a support system to the programming learning, so that improvements in the teacher/learning of this discipline can be introduced. In its development we have applied the models and architectures that proposes DomoSim-TPC and taking advantage of the technological infrastructure built in this project. COLLEGE structures the programming task by means of Collaboration Protocols, and combines the realization of domain tasks by means of direct manipulation with collaborative support for communication and coordination based on the Flexible Structuring and the Perspective of the Language as Action. This system is currently being evaluated. Before being used for the teaching of programming in Java, it is being used in the construction of programs to practise aspects related with the subject area of protection and security of information (as a groupware system). Once the first results have been processed, which will allow us to improve the system, COLLEGE will be used in the practical classes of the subject of Programming Foundations. To do so, we are defining experiences with students from the Universities of Castilla – La Mancha (Spain) and Coimbra (Portugal). We have randomly arranged two sub-groups of students and we have defined a library of problems with increasing complexity. The first sub-group will solve the problems in a traditional way, following the Pair Programming approach. The second sub-group will solve the same problems both individually and in pairs using the COLLEGE system. Then, in the first stage, the solutions and the work carried out by the students in the sub-groups will be studied using statistical calculations. With this data we expect to confirm the hypothesis of improvement of the programming learning process. With respect to future work, we are collaborating with the University of Coimbra to link COLLEGE with the OOP-ANIM system [3], which allows learners to visualize an animated representation of the execution of a Java program. OOP-ANIM is a single-user tool, and it will be transformed into a collaborative tool in a simple way using the ISSC. At a more general level, we are outlining the aim of approaching tasks characteristic of software engineering, as structural or dynamic modelling, taking advantage of the ideas and results obtained in the present investigation and in the DomoSim-TPC system. Specification techniques allowing users to make the developed components more flexible applicable to different domains, tasks and situations will be used.


Acknowledgements This research work has been supported in part by the Red Iberoamericana de Informática Educativa (RIBIE) and the Universidad de Castilla - La Mancha (Spain).

References 1. Bravo C (2002) Un Sistema de Soporte al Aprendizaje Colaborativo del Diseño Domótico Mediante Herramientas de Modelado y Simulación. Ph.D. thesis, Universidad de Castilla - La Mancha 2. Bravo C, Redondo MA, Ortega M, Verdejo MF (2002) Collaborative Discovery Learning of Model Design. In: Cerri SA, Gourdères G, Paraguaçu F (eds) Intelligent Tutoring Systems. LNCS, Springer, Berlin, pp 671-680 3. Esteves M, Mendes AJ (2003) OOP-Anim, a system to support learning of basic object oriented programming concepts. In: Proceedings of CompSysTech' 2003 - International Conference on Computer Systems and Technologies. Sofia, Bulgaria 4. Gutwin C, Greenberg S (1997) Workspace Awareness. In: CHI’97 Workshop on Awareness in Collaborative Systems. Atlanta, Georgia, USA 5. Johnson PM (1998) Reengineering Inspection: The Future of Formal Technical Review. Communications of the ACM 41:49-52 6. Lund K, Baker MJ, Baron M (1996) Modelling dialogue and beliefs as a basis for generating guidance in a CSCL environment. In: Proceedings of the International Conference on Intelligent Tutoring Systems. Montreal, Canada, pp 206-214 7. Nosek JT (1998) The Case for Collaborative Programming. Communications of the ACM 41(3):105-108 8. Shen H, Sun C (2000) RECIPE: a prototype for Internet-based real-time collaborative programming. In: Proceedings of the 2nd Annual International Workshop on Collaborative Editing Systems. Philadelphia, Pennsylvania, USA 9. Wessner M, Hans-Rüdiger P, Miao Y (1999) Using Learning Protocols to Structure Computer-Supported Cooperative Learning. In: Proceedings of the ED-MEDIA’99 World Conference on Educational Multimedia, Hypermedia, Telecommunications. Seattle, Washington, Usa, pp 471-476 10. Williams L, Upchurch RL (2001) In Support of Student Pair-Programming. In: ACM SIGCSE Conference for Computer Science Educators 11. Williams LA, Kessler RR (2000) All I really need to know about pair programming learned in kindergarten. Communications of the ACM 43(5) 12. Winograd T (1988) A Language/Action Perspective on the Design of Cooperative Work. In: Greif E (ed) CSCW: A Book of Readings. MorganKaufmann