Protocolos de Coordinación y Comunicación Estructurada en Entornos de CSCL Síncronos 345 Crescencio Bravo Escuela Superior de Informática. Departamento de Informática. Universidad de Castilla La Mancha Crescencio.Bravo@uclm.es Resumen El desarrollo de entornos de CSCL síncronos es una tarea compleja. La utilización de componentes y de patrones software puede reducir esta complejidad. En particular, los Protocolos de Colaboración constituyen un patrón de diseño que resuelve la problemática de estructurar los sistemas de aprendizaje colaborativo. En este artículo se presenta una colección de protocolos de colaboración para procesos de coordinación, toma de decisiones y comunicación estructurada y de interfaces de usuario para estos procesos, que constituyen una colección de patrones de diseño y de patrones para Interacción Persona-Ordenador. Palabras Clave CSCL, Estructuración de la Colaboración, Protocolos de Colaboración, Colaboración Distribuida Síncrona. MOTIVACIÓN La Ingeniería del Software estudia los principios y metodologías para el desarrollo y mantenimiento de sistemas software. Los Sistemas Colaborativos (SC) son un tipo de sistema software particularmente complejo de desarrollar, especialmente cuando soportan colaboración distribuida síncrona. Por ejemplo, la prueba exhaustiva es difícil de realizar por las múltiples interacciones de diferentes tipos que pueden producirse entre los usuarios. En esta situación, la utilización de componentes probados facilita el desarrollo y lo dota de calidad. Por otro lado, los patrones software [10] facilitan la recopilación y aplicación de experiencia. Un patrón es una solución común a un problema común en un contexto dado. Componentes y patrones siguen el principio de la reutilización y permiten mejorar el desarrollo de software. El CSCL y el CSCW son las dos áreas científicas que conforman los SC. Collis [5] identifica las principales contribuciones de las investigaciones en CSCL y CSCW y su relación. Por ejemplo, algunas características esenciales y diferenciadoras del CSCL son la influencia del profesor, la importancia de estructurar las actividades de grupo y de establecer objetivos compartidos, y la utilización de marcos teóricos y soporte informático basados en teorías de aprendizaje constructivistas y cognitivas. Algunos de los métodos pedagógicos que suelen adoptarse en CSCL son el Aprendizaje Basado en Problemas, el Aprendizaje Basado en Proyectos o el Aprendizaje Mediante Diseño. Tomando estos métodos como marco, un entorno de CSCL permite a los usuarios realizar una actividad como resolver un problema, desarrollar un proyecto o diseñar un artefacto. En el aprendizaje colaborativo subyacente a estas actividades se dan dos tipos de interacciones: negociación y argumentación [7]. La comunicación, la coordinación y la toma de decisiones son tareas necesarias para materializar los procesos de negociación y argumentación. La aportación de este artículo consiste en la propuesta de una serie de protocolos de colaboración para procesos de coordinación y toma de decisiones y para la comunicación estructurada. Estos protocolos constituyen una colección de patrones de diseño a ser utilizados en el desarrollo de entornos de CSCL síncronos. Se mostrarán ejemplos de procesos de coordinación en diferentes sistemas que ilustran y ejemplifican la utilización de estos protocolos, y que suponen una propuesta a nivel de interfaz de usuario, constituyendo patrones para Interacción Persona-Ordenador (IPO). Diferentes autores han propuesto catálogos de patrones para IPO [9], pero no abordan la interacción colaborativa. En cambio, sí existen patrones para Groupware [1], pero no contienen propuestas para entornos de CSCL. Hernández et al [12] proponen la formalización de patrones de aprendizaje colaborativo mediante IMS Learning Design. Sin embargo, los patrones generales que proponen estos autores no abordan procesos específicos de coordinación y no proponen aspectos relacionados con la interfaz de usuario. No existen, por tanto, colecciones de patrones de diseño y de interacción específicos para entornos de CSCL. En la siguiente sección se presentan métodos estructurados de soporte en CSCL. A continuación, se muestran diferentes protocolos para estructurar procesos de coordinación, incluyendo la toma de decisiones y la comunicación, y se muestran algunas implicaciones en relación con la interfaz de usuario. Finalmente, se concluye con un análisis y se muestran algunas líneas de trabajo futuro. ESTRUCTURACIÓN DEL SOPORTE PARA APRENDIZAJE COLABORATIVO En el Aprendizaje Colaborativo se distinguen dos tipos de métodos de soporte [13, 14]: Métodos globales que estructuran la colaboración a un nivel general. Métodos estructurados o guiados de aprendizaje colaborativo, que proporcionan protocolos estructurando el diálogo y las acciones de los aprendices.
346 Cooperative-task DistribuirTrabajo DistribuciónTrabajo ListaCasosEHipótesis DistribuirTrabajo DistribuirTrabajo GestionarCasosEHipótesis GestionarCasosEHipótesis FinDistribución Diseñar FinGestión DefinirParámetros FinDefinición DefinirParámetrosGenerales FinProblema Simular FinSimulación Caso Simular ParámetrosGenerales ModeloDiseñado FIGURA 1 PROTOCOLO DE DISEÑO Y SIMULACIÓN EN DOMOSIM-TPC. La estructuración que se propone en este trabajo se basa en el Scripting para materializar protocolos de colaboración. Así se da forma a la importancia de estructurar las actividades de aprendizaje como apunta Collis [5]. Los Protocolos de Aprendizaje (o de Colaboración) son un soporte de aprendizaje integrado que describe cómo realizar restricciones, reglas y métodos de estructuración de los procesos en un entorno de CSCL [16]. Los protocolos de colaboración, entendidos como métodos guiados de aprendizaje colaborativo, están fundamentados en las teorías de los scripts psicológicos. En la psicología cognitiva y social el conocimiento general respecto a una secuencia rutinaria de eventos relacionados se conoce comúnmente como script. Desde esta aproximación, los protocolos son un conjunto de scripts útiles para el aprendizaje, exteriorizados como métodos ejecutables, con roles, eventos y acciones explícitas. Los protocolos de colaboración pueden representarse mediante Diagramas de Estados. Cada estado representa la realización de una tarea en un espacio de trabajo compartido. En cada espacio los usuarios pueden efectuar acciones tales como comunicarse o manipular artefactos. La transición a otro espacio se dispara por acciones de los usuarios o al alcanzarse una condición específica, como la superación de un time-out o que el artefacto alcance una situación determinada. La Fig. 1 muestra un protocolo de colaboración para la resolución de problemas mediante diseño y simulación en DomoSim-TPC [4]. La notación empleada es la propuesta por la metodología AMENITIES [11], que es una extensión de los Diagramas de Actividad de UML. El grupo comienza su actividad en el espacio Diseñar, y desde éste puede desplazarse de manera sincronizada al resto de espacios de acuerdo a las transiciones. Cada transición es un proceso de coordinación, ya que los usuarios deben tomar la decisión de realizar la transición y cambiar de tarea. Los datos manipulados en las tareas también se incluyen en el diagrama. Se utilizan flechas con trazo discontinuo (dependencias) para indicar estas manipulaciones. En cada estado se ha indicado también el rol que participa en cada tarea. En este caso el profesor participa de la misma forma que el alumno. Esta característica hace posible que se asignen diferentes tareas a los roles. Así se puede diferenciar el comportamiento del profesor con tareas específicas, de manera que siga un protocolo diferente y pueda influir en el proceso de aprendizaje como señala Collis [5]. PROTOCOLOS DE COORDINACIÓN Y COMUNICACIÓN Para describir protocolos de colaboración se pueden utilizar varios formalismos: los Diagramas de Actividad extendidos de AMENITIES, Diagramas de Estados, etc. Un Grafo Conversacional [2] permite mostrar los tipos de contribuciones que pueden emitir los usuarios y las relaciones entre ellas. Los nodos del grafo son las contribuciones, y los arcos, que son dirigidos, representan las respuestas entre contribuciones, determinando el orden de emisión de éstas. En una conversación hay contribuciones iniciales, finales e intermedias. Por otro lado, se distinguen contribuciones emitidas por los usuarios y contribuciones generadas automáticamente por el sistema. Las primeras se representarán con un rectángulo, y las segundas con un rectángulo con las esquinas redondeadas. Sin embargo, un grafo conversacional sólo muestra los tipos de contribuciones y sus relaciones. Para describir el funcionamiento detallado de los protocolos se utilizarán Diagramas de Estados. A continuación se presentan protocolos para cinco tipos de procesos de coordinación. Al final de la sección se hará una reflexión sobre su relación con la interfaz de usuario. I. Procesos basados en propuestas y acuerdos En estos procesos un primer alumno realiza una propuesta de un valor, de realización de una acción, etc. Ante esa propuesta, los compañeros tienen que manifestarse emitiendo un acuerdo, un desacuerdo o una abstención. Este procedimiento se describe mediante el grafo conversacional de la Fig. 2.
Proponer Acuerdo Desacuerdo Asignar Propuesta FIGURA 2 GRAFO CONVERSACIONAL DEL PROCESO BASADO EN PROPUESTAS. Este esquema representa un único proceso de propuesta. Durante una tarea puede ocurrir que los usuarios realicen propuestas en paralelo. En este caso, para responder a una propuesta hay que señalarla previamente. Para soportar propuestas múltiples se requieren dos estructuras de datos: la lista de propuestas activas con las acciones y valores propuestos y una lista de respuestas (acuerdo, desacuerdo y abstención) para cada propuesta. Un grafo conversacional más elaborado permitiría que a una contribución Proponer le pudiera contestar otra contribución Proponer. Las estructuras conversacionales más complejas y extensas son típicas de procesos colaborativos asíncronos, ya que los usuarios tienen tiempo para pensar y elegir la contribución más adecuada en cada momento. El funcionamiento de este proceso queda descrito por el Diagrama de Estados de la Fig. 3, que representa un esquema de una única propuesta. Cuando sólo hay un usuario en el grupo, al hacer la propuesta se realiza directamente la acción relacionada con los datos de la propuesta (realizaracción). Si hay más usuarios, se almacenan los datos que caracterizan a la propuesta y el flujo de control se sitúa en el estado Propuesta Pendiente de Contestar, en el que se contarán los acuerdos, los desacuerdos y las abstenciones. Cuando todos los usuarios han votado, se generará el evento hayacuerdo si no hay ningún desacuerdo. En cambio, en cuanto se produzca un desacuerdo se genera el evento nohayacuerdo. Si hay acuerdo el sistema evoluciona al estado Propuesta Contestada, en el que se realiza la acción relacionada con la propuesta. La abstención podrá ser un tipo de contribución a seleccionar por los usuarios o podrá ser emitida automáticamente por el sistema cuando se alcance un tiempo límite. 347 A continuación se presentan algunos ejemplos de interfaces de usuario para procesos basados en propuestas. La Fig. 4 muestra un fragmento del espacio de trabajo compartido DefinirParámetrosGenerales de DomoSim-TPC [4]. La interfaz permite asignar valores a diferentes parámetros. Mediante el botón Prop. un usuario puede proponer un valor para un parámetro. Las respuestas se emiten con los botones Ok (acuerdo) y No (desacuerdo). Con estos botones se responde a la propuesta del usuario situado en la columna en la que se encuentra el botón. En la columna Decisión aparece el valor inicial del parámetro y el elegido mediante las propuestas. FIGURA 4 INTERFAZ PARA DEFINIR PARÁMETROS (MODELO BASADO EN PROPUESTAS). La Fig. 5 muestra la interfaz para la manipulación de casos (izquierda) e hipótesis (derecha) de simulación en DomoSim-TPC [3]. Un caso es una ejecución de una simulación. La interfaz permite proponer nuevos casos (botón Proponer) y seleccionar la simulación de un caso previamente seleccionado en la lista correspondiente (botón Simular>). Los botones OK y No OK permiten responder con un acuerdo o desacuerdo tanto a la propuesta de caso como a la propuesta de simulación. Las propuestas y respuestas emitidas aparecen en la lista de la parte inferior. Una hipótesis es el enunciado de algún hecho significativo relativo a la simulación. Las hipótesis pueden tomar el valor verdadero o falso indicando si el enunciado se cumple o no. Los botones Proponer, V y F permiten proponer, respectivamente, la creación de una nueva hipótesis, la asignación del valor verdadero a una hipótesis y la asignación del valor falso. La propuesta de valor para una hipótesis requiere que ésta sea seleccionada en una tabla. FIGURA 5 INTERFAZ PARA MANIPULACIÓN DE CASOS E HIPÓTESIS DE SIMULACIÓN. FIGURA 3 DIAGRAMA DE ESTADOS DE UN PROCESO BASADO EN PROPUESTAS. II. Procesos de toma y liberación de recursos En este esquema los usuarios solicitan recursos, y acceden a ellos si éstos están disponibles. La asignación de recursos se hace por orden de solicitud. Pero hasta que un usuario no libere explícitamente un recurso, éste no podrá pasar a otro usuario. El grafo conversacional que caracteriza este proceso se muestra en la Fig. 6. Una situación típica en la que se produce este proceso es cuando existe un turno de trabajo no regulado por el sistema que debe negociarse entre los usuarios.
Solicitar Recurso Liberar Recurso Asignar Recurso FIGURA 6 GRAFO CONVERSACIONAL DE LA TOMA Y LIBERACIÓN DE RECURSOS. La Fig. 7 muestra la interfaz de COLER [6] y COLAB [15] para gestionar el turno de trabajo. En COLER (panel izquierdo) sólo un alumno puede modificar el espacio de trabajo compartido. Por ello deben negociar quién tendrá el lápiz de trabajo. En COLAB (panel derecho) los alumnos tienen que decidir cuál de ellos dirigirá la interacción, siendo el resto observadores. En la figura se aprecia que en ambos sistemas existe un botón para solicitar el turno de trabajo y un botón para liberarlo. En COLAB existe además un botón que permite cancelar una petición de recurso en espera. FIGURA 7 INTERFACES PARA GESTIONAR EL TURNO DE TRABAJO EN COLER Y COLAB. III. Procesos democráticos Un proceso democrático evita las contribuciones de tipo respuesta. En este caso, el sistema debe calcular el valor a asignar a alguna variable a medida que los usuarios emiten propuestas. Es necesario que el sistema tenga un método, que podrá ser configurable, que defina cómo obtener el valor de la variable a partir de propuestas de valor y del tipo de variable. En el sistema DomoSim-TPC se utiliza un proceso democrático en la tarea DefinirParámetrosGenerales (Fig. 8). Esta herramienta soporta, por tanto, dos modelos para asignación de variables (ver Figs. 4 y 8). El modelo empleado se define a nivel de configuración del sistema. En la herramienta democrática hay variables de dos tipos: numéricas y alfanuméricas. Las variables numéricas se calculan mediante la media aritmética de todos los valores propuestos, mientras que para las alfanuméricas se toma la moda (el valor más votado). Las propuestas se realizan con el botón Prop. 348 decisiones es un proceso más guiado que se instrumenta como una votación (Fig. 9): hay una primera definición de la votación por parte de un usuario, el propio usuario y sus compañeros votan y finalmente se muestran los resultados, contabilizados por el sistema. Los usuarios son entonces responsables de utilizar los resultados para realizar alguna acción posterior. Definición de Votación Voto Resultados FIGURA 9 GRAFO CONVERSACIONAL DE UNA VOTACIÓN. Cada votación consiste en el planteamiento de una pregunta a los usuarios. Se identifican tres tipos de votaciones que se corresponden con tres tipos de preguntas (Tabla I): las que tienen una respuesta afirmativa o negativa, las que tienen como respuesta un valor numérico y las que tienen como respuesta una alternativa entre un conjunto de posibilidades. TABLA I TIPOS DE VOTACIONES E INFORMACIÓN PROCESADA POR UNA HERRAMIENTA DE VOTO. Proceso Tipo de Votación Sí/No Valor Numérico Lista de Valores Definición Texto de la Pregunta Texto de la Pregunta Texto de la Pregunta Lista de Valores Respuesta Resultado Sí No Total Votos Abstenciones Votos Sí Votos No Número Real Total Votos Abstenciones Frecuencias Media Mínimo Máximo Valor (de una lista) Total Votos Abstenciones Frecuencias La Tabla I muestra la información que caracteriza la definición de la votación, la respuesta y el resultado, en función del tipo de votación. Este modelo ha sido implementado en la Herramienta de Voto de DomoSim-TPC. La Fig. 10 es un ejemplo de voto para una votación de tipo lista de valores. La abstención es un tipo de voto que se puede emitir mediante el botón. FIGURA 8 INTERFAZ PARA DEFINIR PARÁMETROS (MODELO DEMOCRÁTICO). IV. Procesos de toma estructurada de decisiones Los procesos anteriores producen una acción directamente como consecuencia de adoptar una propuesta o de ir realizando propuestas. En cambio, la toma estructurada de FIGURA 10 VOTO EN UNA VOTACIÓN DE TIPO LISTA DE VALORES.
V. Comunicación estructurada En numerosos entornos de CSCL síncronos se dispone de funcionalidades de comunicación durante la realización de las tareas. La comunicación es un medio más para la negociación y argumentación. En esta situación, una interfaz de comunicación estructurada puede suponer un excelente complemento, presentando tres ventajas potenciales: Proporciona la representación explícita de ciertos actos de comunicación (por ejemplo el acto por qué?) que alientan la participación de los alumnos. Puede reducir la carga de escritura y facilitar la coordinación, permitiendo centrarse más en la tarea y en la interacción reflexiva. Evita problemas de entendimiento del lenguaje natural. El lenguaje subyacente a una comunicación estructurada presenta la forma que muestra el grafo conversacional de la Fig. 11. Éste contiene mensajes iniciales (i, k) y mensajes que son respuestas a otros (j, l, m), llamados reactivos. Como muestra el esquema general de la figura, hay mensajes que pueden responder a varios mensajes diferentes (mensaje j) y hay mensajes que aceptan varias respuestas (mensaje i). Mensaje i Mensaje k Mensaje j Mensaje l Mensaje m FIGURA 11 GRAFO CONVERSACIONAL DE UNA COMUNICACIÓN ESTRUCTURADA. El chat de DomoSim-TPC es un caso de Chat Estructurado (Fig. 12). En la parte derecha contiene botones para expresar los actos de comunicación. En el ejemplo de la figura se han activado los mensajes Pienso lo mismo y No pienso así, que son las respuestas posibles al mensaje Pienso que, emitido con anterioridad. FIGURA 12 UN CHAT ESTRUCTURADO. VI. Interfaces de usuario para procesos de coordinación, toma de decisiones y comunicación estructurada Las Figs. 4, 5, 7, 8, 10, 12 y 13 son ejemplos de materialización en interfaces de usuario de los diferentes modelos de procesos para coordinación, toma de decisiones y comunicación presentados. En este sentido, dichos ejemplos constituyen una colección de patrones de interacción. Dado un proceso de coordinación, existen varias soluciones para implementar su interfaz de usuario. A 349 continuación se presentan unas indicaciones que analizan los componentes de interfaz (o controles) más adecuados. Propuestas: Se suelen utilizar botones para su emisión. El conjunto de datos que caracterizan la propuesta (variables y valores) debe definirse utilizando otros controles, como casillas de verificación, listas o cajas de texto. Acuerdos, desacuerdos y abstenciones: Un botón es el control más intuitivo y adecuado para manifestar estas contribuciones. Sin embargo, es necesario indicar con otros controles a qué proceso de propuesta se refieren. Votaciones: Para definir votaciones será necesario utilizar controles que recojan sus características. Votos: El valor votado se podrá seleccionar mediante radio-botones o botones o teclearse en una caja de texto. Comunicación estructurada: Típicamente se emplean botones para enviar mensajes. Una alternativa que emplea menos espacio consiste en utilizar una lista desplegable con los mensajes posibles. Los mensajes enviados deben mostrarse en una lista o tabla para permitir su selección y poder realizar respuestas. Para completar los mensajes que requieran texto adicional se utiliza una caja de texto. El awareness facilita la comprensión de las actividades de los otros usuarios, lo que proporciona un contexto para tu propia actividad [8], y reduce el esfuerzo necesario para coordinar tareas y recursos, ayuda a las personas a desplazarse entre actividades individuales y compartidas y permite anticipar las acciones de los demás. Por tanto, la percepción de las propuestas, de las votaciones, etc., es vital para el progreso de los procesos de coordinación. Los principales componentes de awareness incluidos en los propios paneles y herramientas de ejemplo que se han presentado son: Información de contribuciones: Lógicamente, cuando se emite una propuesta o votación, esto debe reflejarse de tal manera que se perciba fácilmente. Las propuestas, acuerdos, votos suelen mostrarse en listas o tablas. Nombre del usuario emisor: La identificación del usuario se suele colocar al lado de sus contribuciones en las listas que las recogen, de manera que se identifique con claridad quién es el emisor. Fotos: La fotografía de los usuarios reduce la distancia entre ellos, y sirve también como medio para identificar las interacciones de los usuarios (ver Fig. 4). Pitidos: Si se asocian sonidos a la emisión de contribuciones se refuerza su percepción. La Fig. 13 muestra una interesante solución para mejorar el awareness en los procesos basados en propuestas. Se trata de utilizar un semáforo (rectángulo en la esquina superior derecha de cada panel) que estará en rojo cuando no haya ninguna propuesta que contestar (panel derecho) y en verde cuando haya alguna propuesta pendiente (panel izquierdo). De esta forma se percibe con rapidez el hecho de que hay propuestas pendientes y no es necesario explorar toda la lista, lo que a veces es lento y no muy intuitivo para los usuarios. Sin embargo, estas listas son necesarias para soportar propuestas múltiples.
REFERENCIAS 350 [1] Patterns for Groupware. Groupware Patterns Map, http://www.groupware-patterns.org/ [2] Barros, B., Aprendizaje Colaborativo en Enseñanza a Distancia: Entorno Genérico para Configurar, Realizar y Analizar Actividades en Grupo, Tesis Doctoral, Departamento de Inteligencia Artificial, Universidad Politécnica de Madrid. FIGURA 13 PANELES DE COORDINACIÓN CON SEMÁFORO. Otros elementos externos a estos procesos, como paneles de participantes en la sesión, telepunteros, utilización del color para identificar los usuarios y sus interacciones, vistas de radar, etc., ayudan a reforzar el awareness en la coordinación. ANÁLISIS, DISCUSIÓN Y LÍNEA DE TRABAJO FUTURO En este artículo se ha presentado una colección de protocolos de colaboración que permiten modelar procesos de coordinación en entornos de CSCL síncronos y se han mostrado ejemplos de interfaces de usuario que materializan la interacción persona-ordenador-persona necesaria para soportar estos procesos. Estos protocolos son en realidad patrones, ya que representan un problema (el de coordinar una tarea o acción colaborativa) y una solución efectiva (un modelo de coordinación) en un contexto determinado. En concreto, se han propuesto patrones para procesos basados en propuestas y acuerdos, procesos de toma y liberación de recursos, procesos democráticos, procesos de toma estructurada de decisiones y comunicación estructurada. De las interfaces de usuario de ejemplo se pueden extraer pautas o líneas guía de las que se derivan patrones para IPO. Cada protocolo y su interfaz pueden implementarse mediante componentes software, de manera que siguiendo un Desarrollo Basado en Componentes se podrían construir entornos CSCL mediante composición de bloques de construcción (componentes). Los protocolos presentados desarrollan el principio de la estructuración. Esta estructuración facilita el almacenamiento de las tareas y acciones de los alumnos y de sus interacciones en la interfaz, lo que permite el posterior estudio y análisis del trabajo de aprendizaje realizado, algo característico en CSCL. En cuanto a las limitaciones de los protocolos presentados, en primer lugar se encuentra la ausencia de mecanismos para evitar la falta de participación y los conflictos de intenciones. Desde el punto de vista del desarrollo de software, existe la necesidad de métodos para el modelado de los procesos de colaboración, de manera que se facilite la Ingeniería Directa. Para alcanzar este objetivo, es necesario utilizar técnicas de descripción formales para representar los protocolos y los patrones sin ambigüedad para facilitar su tratamiento computacional y poder representar y aplicar experiencias previas. En este sentido, sería necesario conectar los elementos de la interfaz de usuario colaborativa (controles) con los tipos de contribuciones, con el funcionamiento del protocolo y con el modelo de tareas de los usuarios. Esta es la línea de trabajo actual. [3] Bravo, C.; A. Redondo, M.; Ortega, M.; Verdejo, M.F., Collaborative distributed environments for learning design tasks by means of modelling and simulation, Journal of Network and Computer Applications (In Press), 2005. [4] Bravo, C.; A. Redondo, M.; Ortega, M.; Verdejo, M.F, Collaborative environments for the learning of design: A model and a case study in Domotics, Computers and Education (In press), 2005. [5] Collis, B., Cooperative Learning and CSCW: Research Perspectives for Internetworked Educational Environments, Paper in IFIP Working Group 3.3. Working Conference, Lessons from Learning, Theme B, Archamps, Francia, 1993. [6] Constantino-González, M.A. & Suthers, D.D., Coaching Collaboration by Comparing Solutions and Tracking Participation, Proceedings of the European Conference on Computer-Supported Collaborative Learning, Maastricht, Netherlands, 2001. [7] Dillenbourg, P., Baker, M., Blaye, A. & O Malley, C., The evolution of research on collaborative learning, Espada, E. & Reiman, P. (Eds.), Learning in Humans and Machine: Towards an interdisciplinary learning science, Oxford: Elsevier, 1996, pp. 189-211. [8] Dourish, P. & Belloti, V., Awareness and coordination in shared workspaces, Proceedings of Computer Supported Cooperative Work, ACM Press, 1992, pp. 107-114. [9] Fincher, S., Patterns for HCI. Pattern gallery, http://www.cs.kent.ac.uk/people/staff/saf/patterns/gallery.html [10] Gamma, E., Helm, R., Johnson, R. & Vlissides, J., Design patterns: Elements of reusable object-oriented software, Reading, MA: Addison Wesley, 1995. [11] Garrido, J.L., Gea, M. & Rodríguez, M.L., Requirements Engineering in Cooperative Systems, Requirements Engineering for Socio- Technical Systems, IDEA GROUP INC. (USA), 2005, pp. 226-244. [12] Hernández, D., Asensio, J.I. & Dimitriadis, IMS Learning Design Support for the Formalization of Collaborative Learning Patterns, Proceedings of 4 th International Conference on Advanced Learning Technologies, Joensuu, Finlandia, 2004, pp. 350-354. [13] Hron, A., Hesse, F.W., Reinhard, P. & Picard, E., Structured cooperation in computer-supported collaborative learning, Unterrichtswissenschaft, 1/97, 1997, pp. 56-69. [14] Mancini, B.M., Hall, R.H., Hall, M.A. & Stewart, B., The individual in the dyad: a qualitative analysis of scripted cooperative learning, Journal of Classroom Interaction, 33 (1), 1998, pp. 14-22. [15] van Joolingen, W. R., de Jong, T., Lazonder, A. W., Savelsbergh, E., & Manlove, S., Co-Lab: Research and development of an on-line learning environment for collaborative scientific discovery learning, Computers in Human Behavior, 21, 2005, pp. 671-688. [16] Wessner, M., Hans-Rüdiger, P. & Miao, Y., Using Learning Protocols to Structure Computer-Supported Cooperative Learning, Proceedings of the ED-MEDIA 99, World Conference on Educational Multimedia, Hypermedia & Telecommunications, Seattle, Washington, 1999, pp. 471-476.