Aprendizaje en grupo de la programación mediante técnicas

Aprendizaje en grupo de la programación mediante
técnicas de colaboración distribuida en tiempo real
Crescencio Bravo
Miguel Á. Redondo
Manuel Ortega
Profesor Asociado
Paseo de la Universidad, 4
13071 Ciudad Real
34 926295300 ext. 3717
Profesor Asociado
Paseo de la Universidad,4
13071 Ciudad Real
34 926295300 ext. 3717
Catedrático de Universidad
Paseo de la Universidad,4
13071 Ciudad Real
34 926295481
[email protected]
[email protected]
[email protected]
cada grupo los alumnos colaboran entre sí cara a cara al modelar
el problema mediante diferentes representaciones, al editar el
código fuente, al compilar, al depurar errores y al ejecutar el
programa. Esta organización en parejas viene principalmente
motivada por las limitaciones que existen en el número de
ordenadores en los laboratorios de prácticas o para dar
oportunidades a los alumnos de trabajar en equipo de cara a
facilitar en el futuro su integración en los equipos de
desarrolladores de las empresas.
ABSTRACT
En la realización de ejercicios prácticos de programación en los
primeros cursos de enseñanza universitaria de informática suele
producirse una situación de trabajo en parejas frente a un
ordenador: un estudiante maneja el teclado y el otro revisa su
trabajo. En esta configuración cabe plantearse el empleo de
estrategias y soporte colaborativos para mejorar el proceso de
enseñanza-aprendizaje, posibilitando un trabajo en grupo y a
distancia. En este trabajo modelamos una propuesta de sistema
colaborativo síncrono para el aprendizaje de la programación que
pueda ser utilizado tanto en los laboratorios de prácticas como
desde otros espacios (en casa, bibliotecas...). De acuerdo con este
modelo hemos construido un sistema que soporta la edición,
compilación y ejecución de programas en grupo por parte de los
alumnos, y la revisión del trabajo efectuado por los estudiantes
por parte del profesor para extraer conclusiones sobre el proceso
de programación en grupo.
Este enfoque de Programación en Parejas (Pair Programming) es
popular en el ámbito empresarial, principalmente en las
organizaciones que utilizan la Programación Extrema (eXtreme
Programming, XP). En este tipo de tarea dos programadores
diseñan software juntos en un mismo ordenador, trabajando
colaborativamente en el mismo algoritmo, diseño o tarea de
programación. La situación es idéntica al caso de enseñanza
práctica anterior. El modelo de Programación en Parejas se ha
mostrado beneficioso en estudiantes de programación. Estudios
cuantitativos y cualitativos demuestran que el uso de esta
aproximación en las clases de introducción a la programación
mejora el aprendizaje del alumno, aumenta su satisfacción, reduce
la frustración compartida de los estudiantes y disminuye el
número de defectos de los programas [10].
Keywords
CSCW/CSCL, Programación en Parejas, Programación
Colaborativa, Aprendizaje a Distancia
1. INTRODUCCIÓN
El área de los Sistemas Colaborativos se ha desarrollado
rápidamente en los 90 y está alcanzando plena madurez. Estos
sistemas se vienen aplicando con éxito tanto en diferentes
situaciones de trabajo (CSCW, Computer-Supported Cooperative
Work) como para el aprendizaje (CSCL, Computer-Supported
Collaborative Work). Uno de los dominios en los que tiene
aplicación el paradigma de colaboración es la construcción de
programas de ordenador o programación. En las asignaturas de
Introducción a la Programación de las diferentes enseñanzas
universitarias españolas se imparten clases prácticas en las que se
emplean lenguajes como Java, Pascal o C. Inicialmente se
plantean unos problemas que los alumnos tienen que resolver en
grupos de dos. Estos ejercicios suelen ser de mediana dificultad y
permiten practicar los diferentes aspectos de la programación. En
Pero cuando no es posible que los dos alumnos estén presentes,
puede utilizarse la tecnología informática para soportar
colaboración a distancia. Surge, por tanto, el concepto de
Programación Colaborativa por ordenador como la aplicación de
estrategias colaborativas y soporte informático a la Programación
en Parejas. Esto permitiría no sólo a dos alumnos, sino a tres o
cuatro, trabajar en grupo. Estudios previos [7, 11] indican que la
Programación Colaborativa no sólo acelera los procesos de
resolución de problemas, sino que mejora la calidad de los
productos software. Según Johnson [5], el proceso de analizar y
criticar artefactos de software producidos por otras personas es un
potente método para aprender lenguajes de programación,
técnicas de diseño y dominios de aplicación. Un sistema que
permite a programadores distribuidos geográficamente participar
concurrentemente en el diseño, codificación, prueba, depuración y
documentación de un mismo programa es RECIPE (REal-time
Collaborative Interactive Programming Environment) [8]. Esta
herramienta permite que los compiladores y depuradores
monousuario pueden convertirse fácilmente en aplicaciones
colaborativas sin modificar los ejecutables (transparencia) y que
los editores colaborativos existentes puedan integrarse en el
sistema. Sin embargo, no registra el trabajo de los programadores
Se concede el permiso para la reproducción digital o impreso total o
parcial de este trabajo sin contraprestación económica únicamente para
la utilización personal o en clase. En ningún caso se podrán hacer o
distribuir copias de para su explotación comercial. Todas las copias
deben de llevar esta nota y la información completa de la primera
página. Para cualquier otro uso, publicación, publicación en servidores,
o listas de distribución de esta información necesitara de un permiso
específico y/o el pago correspondiente.
Interacción '04 – 3-7 Mayo, 2004, Lleida, España.
351
para obtener conclusiones sobre su trabajo, ni ofrece herramientas
especializadas de comunicación y awareness.
Un protocolo de colaboración describe los espacios de trabajo
compartidos disponibles y cómo el grupo de estudiantes puede
navegar a lo largo de estos espacios. Un espacio de trabajo es una
zona de elaboración e intercambio de información, independiente
pero interrelacionada con las otras del sistema. Los espacios
propuestos por este sistema son cinco:
Aunque el laboratorio es el espacio natural para la realización de
estos trabajos, los alumnos no siempre los concluyen en el tiempo
previsto, teniendo que terminarlos en horario extraescolar, en sus
casas o en aulas de libre uso. Además, en muchas ocasiones se
proponen tareas de autoestudio que también pueden ser abordadas
en grupo. Con nuestra propuesta se permite y favorece el trabajo a
distancia, optimizando el tiempo de dedicación de los alumnos a
la asignatura que, a veces, tienen que desplazarse a casa del
compañero o al centro de estudios para terminar los ejercicios. Un
factor a tener en cuenta como beneficio adicional es el aspecto
motivante de la colaboración a distancia, que ofrece herramientas
cercanas a los jóvenes como el chat y el correo electrónico. Con
este nuevo enfoque el escenario que se produce consiste en que
los alumnos (dos o tres), desde casa o desde su centro educativo,
editen conjuntamente un programa que supone una solución a un
problema
previamente
planteado,
que
lo
compilen
simultáneamente, que lo depuren y que finalmente lo ejecuten.
Para que esto sea factible se requieren conexiones de alta
velocidad que posibiliten la interacción síncrona, pero no
debemos olvidar que actualmente hay una alta disponibilidad de
conexiones ADSL en los hogares y que los centros universitarios
cuentan con redes de alta velocidad.
1. Diseño: Donde se construye el modelo que supone una
solución al problema.
2. Organización del Trabajo: Donde los alumnos distribuyen su
trabajo definiendo un reparto de acciones.
3. Definición de Parámetros: Donde se definen las variables
generales del problema.
4. Casos e Hipótesis: Donde los alumnos definen casos e
hipótesis de simulación.
5. Simulación: Donde se simula el modelo y se experimenta con
él.
Estos espacios de trabajo integran diferentes mecanismos que
soportan el proceso de diseño y simulación en grupo [2]:
ƒ Mecanismos de manipulación directa: Los alumnos diseñan y
simulan los modelos mediante acciones elementales de
manipulación directa, siguiendo la metáfora de la pizarra
electrónica colaborativa basada en el modelo objeto-acción.
En este trabajo nos planteamos la exploración de estas
posibilidades y el modelado de este tipo de sistemas para la
realización de ejercicios prácticos de programación, en Java o en
cualquier otro lenguaje. De esta manera se tendría un sistema de
Programación Colaborativa que podría utilizarse tanto como
sistema de CSCW/Groupware en las empresas, como sistema de
CSCL para el aprendizaje en centros de enseñanza. El artículo se
organiza de la siguiente manera: en el siguiente apartado se
presenta brevemente DomoSim-TPC, un entorno de CSCL que
servirá para aplicar sus planteamientos y parte de su
infraestructura al tipo de sistemas que abordamos; en el apartado
3 se modela el proceso de programación colaborativa y se
describen los componentes que formarían este tipo de sistemas; en
el apartado 4 se tratan aspectos del soporte pedagógico; el
siguiente apartado muestra un primer prototipo de sistema; y,
finalmente, en el apartado 6 se muestran las conclusiones del
trabajo y las líneas de trabajo futuro.
ƒ Soporte para la comunicación y la coordinación: Al ir
diseñando y simulando la solución a un problema los alumnos
pueden hacer uso de un Chat Estructurado y de una
Herramienta de Toma de Decisiones. Esta última se invoca
mediante un botón disponible en el Chat Estructurado.
ƒ Técnicas de awareness: Para facilitar la colaboración en
tiempo real se ha dado una gran importancia al awareness [4],
entendido como la percepción y conocimiento de la
interacción que efectúan otras personas dentro de un espacio
de trabajo compartido. Para ello se utilizan telepunteros, listas
de participantes y listas que recogen las interacciones
efectuadas.
En la figura 1 se muestra la principal herramienta de DomoSimTPC: la herramienta que soporta el Diseño Colaborativo. A la
izquierda se muestran las barras de herramientas de operadores
(1) y de enlaces (2), y a la derecha las barras de herramientas de
dibujo (3). Los operadores y los enlaces, que los relacionan, son
los componentes de los modelos. Pueden verse también el Panel
de Sesión (4) y el Chat Estructurado (5), y a la izquierda de éste la
zona de mensajes de interacción y de error (6). La superficie de
trabajo (7) contiene el plano de la vivienda sobre el que se
construye el modelo. El modelo de datos que constituye la
solución y el proceso de construcción que da lugar a él son
persistentes, quedando almacenados y estando disponibles tanto
para la consulta del profesor como para la continuación del
trabajo en otra sesión. Esta característica diferencia a los sistemas
de CSCL de los sistemas de CSCW; para los primeros es tan
interesante el producto como el propio proceso que permite
construirlo.
2. DOMOSIM-TPC: UN SISTEMA
COLABORATIVO DE DISEÑO
DomoSim-TPC1 [1] es un entorno de aprendizaje colaborativo del
diseño domótico mediante la resolución de problemas complejos,
con el que los alumnos discuten, diseñan y simulan en superficies
de trabajo compartidas. El sistema soporta todo el proceso de
enseñanza-aprendizaje, incluyendo herramientas para la
organización y análisis de actividades por parte del profesor.
Este sistema propone un modelo semiestructurado de interacción
para la resolución colaborativa síncrona de problemas de diseño,
que se basa en técnicas como los Protocolos de Colaboración [9]
para estructurar el proceso de aprendizaje, el Lenguaje/Acción
[12] para instrumentar la ejecución de ciertas tareas y la
Estructuración Flexible [6] para construir herramientas efectivas
de comunicación y coordinación.
1
http://chico.inf-cr.uclm.es/domosim
352
Figura 2. Protocolo de Colaboración para Programación.
En la Programación en Parejas se identifican usuarios con dos
tipos de roles diferentes [10]: realizador y observador. Durante la
edición, el realizador tiene el control de la interacción
(teclado/ratón) y realiza el diseño o codificación, y el observador
revisa el trabajo del compañero buscando defectos, considerando
alternativas y planteando preguntas. Mientras el realizador
reflexiona sobre su trabajo el observador solicita aclaraciones y
explicaciones según evoluciona la solución. Para los sistemas de
Programación Colaborativa modelamos también una tarea de
edición monousuario tal y como propone este método, soslayando
así las dificultades de implementación de un editor colaborativo
síncrono y dando más importancia al cambio en el turno de
edición que tendrán que gestionar los alumnos.
Figura 1. Espacio de Trabajo de Diseño.
3. MODELADO DEL PROCESO DE
PROGRAMACIÓN COLABORATIVA
Vamos a aplicar el modelo de estructuración y los mecanismos de
soporte a la colaboración del sistema DomoSim-TPC a los
sistemas de Programación Colaborativa. En el proceso de
programación distinguimos varias etapas (edición del código
fuente, compilación y ejecución de los programas objeto) que se
describirán con un protocolo de colaboración. Al utilizar el
sistema los estudiantes realizan tareas del dominio y tareas de
comunicación y coordinación. Las tareas del dominio son las
relacionadas con la programación. Las tareas de comunicación y
coordinación permiten intercambiar información relativa al
dominio, coordinar acciones y alcanzar acuerdos.
La navegación entre espacios de trabajo se instrumenta mediante
mecanismos de proposición (figura 3). Un primer alumno hace
una propuesta de desplazamiento y los compañeros (o el
compañero) le contestarán con un acuerdo o desacuerdo. Las
propuestas y reacciones a éstas se expresan mediante botones.
Cuando todos los alumnos están de acuerdo o se abstienen se
produce el desplazamiento al nuevo espacio. La abstención se
produce automáticamente por el sistema cuando no se ha
respondido durante un tiempo de 10 segundos, aunque este tiempo
es configurable. Si no se produce ningún acuerdo o no hay
propuestas, el grupo no puede trabajar, de manera que la
responsabilidad de avanzar en el trabajo recae en el grupo y en
sus participantes. Este mismo mecanismo será el utilizado para
dar el turno de edición, para realizar la compilación y para
comenzar la ejecución del programa.
3.1 Protocolo de Colaboración
Identificamos un protocolo de colaboración de tres etapas que se
describe con el grafo de la figura 2. Cada etapa o nodo se
corresponde con un espacio de trabajo donde realizar cada una de
las tres tareas específicas del dominio. El espacio principal es el
de Edición/Revisión, en el que un único usuario edita el código
fuente. Este espacio también puede utilizarse para revisar el
código sin realizar cambios en él. Desde este espacio puede
realizarse la compilación o directamente pasar a la ejecución, en
este último caso cuando ya se dispone del programa objeto. El
espacio de Compilación es de corta permanencia para el grupo: el
sistema invocará al compilador correspondiente y mostrará su
salida en el espacio de trabajo. Los alumnos pueden entonces
observar los resultados de la compilación (mensajes de error,
números de línea...), discutirlos y realizar la depuración en el caso
de que hubiese errores, trasladándose para ello al espacio de
Edición/Revisión. Si no hay errores pueden acceder al espacio de
Ejecución. La ejecución del programa se realiza en una consola
específica. Al finalizar la ejecución el grupo siempre se situará en
el espacio de Edición/Revisión, para comenzar el proceso
nuevamente, rectificando el programa si no se obtienen los
resultados esperados.
Figura 3. Grafo conversacional para una propuesta.
353
-
3.2 Soporte para las Tareas del Dominio
Las tareas del dominio se materializan siguiendo el paradigma de
manipulación directa basado en el modelo objeto-acción. En la
edición, los objetos son las partículas del lenguaje (variables,
métodos, clases...) o, a un nivel de granularidad menor, los
caracteres que se insertan o eliminan en el código fuente. Las
acciones son las de insertar, eliminar, seleccionar, guardar, cortar,
pegar, etc. En los espacios de compilación y ejecución no hay
objetos ni acciones destacados.
ƒ Mensajes libres: Para ofrecer una posibilidad adicional de
comunicación a los usuarios que aporte más libertad pueden
utilizarse mensajes con texto libre, pero siempre instruyendo a
los alumnos a la hora de preparar las experiencias en el uso
preferente de los mensajes estructurados, que estructuran la
comunicación
con
unas
formas
semánticamente
comprensibles y adecuadas para la tarea del dominio y
facilitan el posterior análisis de la comunicación. Por este
motivo, el chat registra los cinco últimos mensajes de texto
libre introducidos, lo que ahorra tiempo de tecleo y centra la
atención de los alumnos en un pequeño conjunto de mensajes.
En determinadas experiencias o en diferentes momentos este
tipo de mensajes podría no estar disponible para forzar a los
alumnos a utilizar los otros dos tipos de mensajes.
La manipulación directa también se emplea para las tareas de
coordinación. Los objetos son las abstracciones que modelan los
procesos de proposición y comunicación: turno de edición,
propuesta de compilación y propuesta de ejecución; y las acciones
son las de proponer, estar de acuerdo, estar en desacuerdo y
abstenerse, que se disparará en ausencia de las otras.
3.3 Soporte para la Comunicación y la
Coordinación
Aunque existe la posibilidad de utilizar canales de audio y vídeo
durante cualquier actividad colaborativa, incluida la
programación, la comunicación estructurada textual tiene una
ventaja frente al audio y el vídeo: permite registrar los actos de
comunicación de manera que puedan analizarse con posterioridad.
De un flujo de audio o vídeo es difícil extraer información sobre
la comunicación con significado. En cambio, si cada mensaje del
chat se almacena, este registro puede analizarse mediante diversas
técnicas. Este enfoque ha sido explorado en el Subsistema de
Monitorización y Análisis de DomoSim-TPC [1].
Los instrumentos de comunicación y coordinación son utilizados
desde todos los espacios. La comunicación queda materializada
mediante un Chat Estructurado, basado en la Estructuración
Flexible para la comunicación propuesta por Lund et al [6], que
permite la comunicación textual entre los aprendices. Este chat es
estructurado porque ofrece un conjunto preestablecido de actos de
comunicación. Los mensajes que pueden enviarse se clasifican de
acuerdo a tres criterios:
El soporte de coordinación queda reflejado por los tres procesos
de proposición descritos y específicos a cada una de las tareas o
espacios del dominio, que, como la navegación entre espacios de
trabajo, siguen el grafo conversacional de la figura 3. La
utilización de acciones (botones) para representar actos del habla
como proponer, estar de acuerdo, etc. se inspira en la Perspectiva
del Lenguaje como Acción [12].
ƒ Tipo de mensaje: Según el tipo los mensajes pueden ser
aserciones, preguntas y respuestas.
ƒ Lugar en el diálogo: De acuerdo al lugar que ocupa el texto
del mensaje en el diálogo se tienen mensajes iniciales y
reactivos.
ƒ Tipo de adaptación: En función del tipo de adaptación del
mensaje al contexto se tendrían mensajes no adaptables y
mensajes adaptables. Los mensajes adaptables recogen
información de las tareas del dominio y generan mensajes
particulares para estas situaciones. Por ejemplo, en función de
las clases, métodos y variables existentes en el código fuente
se pueden enviar mensajes que incluyan a estos elementos.
3.4 Técnicas de Awareness
En la realización de las tareas del dominio y las de coordinación y
comunicación se dispone de funciones de awareness. Este soporte
se ofrece mediante los siguientes elementos:
ƒ Panel de Sesión: Es el principal elemento de awareness.
Muestra una lista de participantes en la sesión. Junto al
nombre de cada participante se acompaña la foto para reducir
la barrera que supone la colaboración remota. El propio
usuario queda resaltado en el panel con un recuadro para que
éste conozca su propia identificación. Cada usuario se muestra
con un color particular que se utiliza para identificar sus
interacciones, que se reflejarán con el mismo color. De
manera adicional este panel muestra el estado en que se
encuentra cada usuario. Proponemos los siguientes estados:
editando, comunicando, observando, compilando y
ejecutando.
ƒ Telepunteros: Aunque no es necesario tener telepunteros de
dibujo por cada usuario ya que no existe una pizarra
colaborativa, sí es interesante mostrar el puntero de edición
del usuario que tiene el turno. Por tanto, sólo hay que mostrar
un único telepuntero, que será un cursor de edición textual,
que muestre la zona en la que se está editando o el carácter
que se está manipulando.
Proponemos los siguientes mensajes específicos para los sistemas
de Programación Colaborativa:
ƒ Mensajes de discusión/argumentación:
-
“Pienso que...”: aserción, inicial y no adaptable.
-
“Pienso lo mismo”: aserción, reactivo y no adaptable.
-
“No pienso así”: aserción, reactivo y no adaptable.
-
“¿Por qué ...?”: pregunta, inicial y no adaptable.
-
“No sé”: respuesta, reactivo y no adaptable.
-
“Porque ...”: respuesta, reactivo y no adaptable.
ƒ Mensajes relativos a objetos del dominio: Tendrán una
conexión con los diferentes elementos del dominio,
contenidos fundamentalmente en el espacio de Edición, tales
como clases, métodos, atributos, etc. Se proponen dos tipos de
mensajes:
-
“Veo un fallo en el/la (clase | método | atributo | palabra
reservada | variable) <objeto>”: aserción, inicial y
adaptable.
“Falta el/la (clase | método | atributo | palabra reservada
|variable) <objeto>”: aserción, inicial y adaptable.
354
ƒ Listas de interacción: Existen tres áreas de coordinación:
cambio de turno, propuesta de compilación y propuesta de
ejecución. Cada una de ellas incorpora una lista de mensajes
que muestra tanto las propuestas iniciales como los mensajes
de acuerdo/desacuerdo, incluyendo en todos los casos el
emisor del mensaje.
ƒ Awareness en la comunicación: El Chat Estructurado incluye
una lista que refleja los mensajes enviados junto con su autor.
1. Que el alumno relacioné qué cambio en la edición se
corresponde con qué error de compilación. Esto facilita el
registro pero da más trabajo al alumno. Para ello se podría
habilitar una lista de mensajes de error; el alumno primero
selecciona el error a corregir y modifica el código fuente.
2. Que el sistema relacione cada error con su corrección. Este
mecanismo tiene como ventaja que el registro es transparente
al usuario, pero es complejo de llevar a la práctica. Una
primera aproximación se basaría en los números de línea en
los que se ha producido el error y en los números de línea en
los que se realizan cambios. Pero hay que tener en cuenta que
como consecuencia de corregir un error el número de línea
puede cambiar (si se ha eliminado o insertado alguna), que
pueden hacerse otras correcciones o mejoras que no procedan
de ningún error y que ciertos errores producidos en una línea
pueden corregirse en otras diferentes.
4. INTERVENCIONES DEL SISTEMA Y
MONITORIZACIÓN DEL PROCESO
Para el éxito de la tarea del aprendizaje de la programación
mediante la elaboración de programas es necesaria una adecuada
gestión del turno de edición. En el sistema modelado, esta gestión
es responsabilidad de los alumnos. Uno de los objetivos de la
investigación consiste en explorar cuáles de los mecanismos de
cambio de turno es más adecuado en estas situaciones. Es cierto
que la asignación de turno permite que las carencias de un alumno
puedan completarse con los conocimientos del otro. Pero una
libertad tan grande abre la puerta a que un alumno nunca
participe, asumiendo el otro todo el protagonismo. Una ventaja de
la Programación Colaborativa por ordenador frente a la
Programación en Parejas es que el cambio de turno puede ser
responsabilidad del sistema, de manera que el tiempo se reparta
por igual entre los participantes obligando a que participen todos.
O pueden establecerse otros mecanismos de negociación que
aseguren la participación y maximicen el beneficio pedagógico.
Para facilitar esta segunda posibilidad y registrar correctamente
los errores producidos es preciso definir cómo se muestran las
líneas de error y los tipos de error en el compilador concreto que
se esté utilizando, ya que, no olvidemos, el sistema es
independiente del lenguaje utilizado, simplemente éste debe
disponer de un compilador y de un intérprete o máquina virtual, o
debe generarse directamente un ejecutable. Esta definición se
realizará utilizando una función de configuración.
5. EL SISTEMA COLLEGE
COLLEGE (COLLaborative Edition, compilinG, and Execution
of programs) es un sistema desarrollado para soportar la tarea de
la programación en grupo, tal y como se ha descrito
anteriormente. En la figura 4 se muestra la interfaz que permite
acceder al sistema. Tras una primera conexión al servidor, el
usuario dispone de una herramienta para gestionar sesiones. En
este caso, a diferencia de DomoSim-TPC, no es el profesor el que
se encarga de definir las sesiones de trabajo, sino que se encargan
los propios alumnos. Una sesión se define mediante un nombre,
un tipo, un fichero y un horario en el que se puede realizar. El
fichero contiene un enunciado del problema a resolver que podrá
consultarse desde COLLEGE. Dada una sesión, los alumnos
podrán consultar los participantes que se encuentran actualmente
conectados a ella.
Además de la estructuración del cambio de turno existen muchas
otras posibilidades pedagógicas de guía al proceso, basadas en las
ideas de los Sistemas Tutores Inteligentes, pero esto será un
objetivo futuro del sistema. Sí consideramos adecuado incorporar
una función que permita consultar la estadística de errores para
que los propios alumnos puedan comprobar cuáles suelen
cometer, para prestar más atención a los aspectos relacionados
con esos errores y poder discutir al respecto.
La labor de análisis del trabajo efectuado por los alumnos, durante
las experiencias o al concluir éstas, es especialmente interesante
en este dominio. Si pensamos en un grupo de alumnos trabajando,
en cada una de las tareas los alumnos tienen un comportamiento
diferente. En la edición todos contribuyen con ideas o con
acciones de edición. Durante la compilación se mantienen a la
expectativa para observar el resultado; finalizada la compilación
hay una labor de reflexión, sobre todo cuando ha habido errores,
que da lugar a la corrección de los mismos. Finalmente, durante la
ejecución, hay una labor común de definición de los datos de
entrada y de interpretación de los datos de salida, buscando
funcionamientos inadecuados o errores de ejecución. Estos
comportamientos, que pueden contribuir a diseñar un sistema más
efectivo, pueden estudiarse con diferentes técnicas de Inteligencia
Artificial, como la Lógica Difusa (Fuzzy Logic), las Redes
Neuronales o los Algoritmos Genéticos.
Todo el desplazamiento del grupo a través de los espacios, la
comunicación escrita y los procesos de proposición quedan
convenientemente registrados en el sistema. Pero el registro de las
acciones en el editor, sobre todo las relativas a la corrección de un
error de programación, no es una cuestión trivial porque hay que
relacionar cada acción con el error correspondiente. Surgen dos
posibilidades:
Figura 4. Conexión y gestión de sesiones en COLLEGE.
La figura 5 muestra una sesión de trabajo con COLLEGE. Pueden
verse las áreas para las tareas de Edición/Revisión (1) y
355
Compilación (2), así como las tres áreas para los procesos de
proposición (3, 4, 5), el Panel de Sesión (6) y el Chat Estructurado
(7). En la figura los alumnos están elaborando un programa que
permita resolver ecuaciones de segundo grado. Al compilar el
código se producen algunos errores, y los alumnos discuten con el
fin de resolverlos. Cuando el programa está finalizado y los
alumnos están de acuerdo en su ejecución, se abrirá una consola
de ejecución como la que se muestra en la figura 6. Durante la
ejecución en esta consola está disponible el Chat Estructurado.
Nótese que el lenguaje utilizado en este ejemplo es Java.
6. CONCLUSIONES Y TRABAJO FUTURO
El sistema COLLEGE pretende ser un medio para investigar
aspectos de comportamiento en el trabajo de edición, compilación
y ejecución en grupo de programas, así como un sistema de
soporte al aprendizaje de la programación, de manera que se
puedan introducir mejoras en la enseñanza/aprendizaje de esta
disciplina. En su desarrollo hemos aplicado los modelos y
arquitecturas que propone el subsistema de Diseño y Simulación
de DomoSim-TPC y aprovechado la infraestructura tecnológica
construida en dicho proyecto. COLLEGE estructura la tarea de la
programación mediante Protocolos de Colaboración, y combina la
realización de tareas del dominio mediante manipulación directa
con un soporte colaborativo para la comunicación y la
coordinación basado en la Estructuración Flexible y la
Perspectiva del Lenguaje como Acción.
Este sistema está siendo evaluado actualmente. Antes de ser
utilizado para la enseñanza de la programación en Java, va a ser
empleado en la construcción de programas para practicar aspectos
relacionados con la protección y seguridad de la información,
como el cifrado de datos (en lenguaje C) y los protocolos de
seguridad (en lenguaje Java). Una vez procesados los primeros
resultados, que permitirán mejorar el sistema, el sistema se
utilizará en las clases prácticas de la asignatura de Metodología y
Tecnología de la Programación.
En cuanto al trabajo futuro, estamos colaborando con la
Universidad de Coimbra para conectar COLLEGE con el sistema
OOP-ANIM [3], que permite visualizar una representación
animada de la ejecución de un programa en Java. OOP-ANIM es
una herramienta monousuario, y será convertida en herramienta
colaborativa de manera sencilla utilizando la ISSC.
Figura 5. Un sesión de Programación Colaborativa en
COLLEGE.
A un nivel más general, nos planteamos el objetivo de abordar
tareas propias de la ingeniería del software, como el modelado
estructural o dinámico, aprovechando las ideas y resultados
obtenidos de la presente investigación (COLLEGE) y del sistema
DomoSim-TPC. Se utilizarán técnicas de especificación que
permitan flexibilizar los componentes desarrollados para que
permitan abordar diferentes dominios, tareas y situaciones.
7. AGRADECIMIENTOS
Este trabajo de investigación ha sido parcialmente financiado por
la Red Iberoamericana de Informática Educativa (RIBIE) y la
Universidad de Castilla - La Mancha (España).
Figura 6. Consola de ejecución de programas (lenguaje Java).
8. REFERENCIAS
[1] Bravo, C. (2002) Un Sistema de Soporte al
Aprendizaje Colaborativo del Diseño Domótico
Mediante Herramientas de Modelado y Simulación.
Tesis Doctoral. Dpto. de Informática, Universidad de
Castilla - La Mancha.
El sistema está desarrollado en Java, y opera siguiendo un modelo
cliente/servidor sobre redes TCP/IP para facilitar su utilización
sobre Internet/intranet. El subsistema de sincronización opera
sobre la Infraestructura de Sincronización para Sistemas
Colaborativos (ISSC), desarrollada por nuestro grupo a partir del
Java Shared Data Toolkit2 (JSDT)©, que presenta una
arquitectura de comunicaciones centralizada.
2
[2] Bravo, C., Redondo, M.A., Ortega, M. & Verdejo,
M.F. (2002) Collaborative Discovery Learning of
Model Design. Cerri, S.A., Gourdères, G. &
Paraguaçu, F. (Eds.) Intelligent Tutoring Systems, 6ª
Conferencia Internacional, ITS’2002, pp. 671-680,
LNCS, Springer.
http://java.sun.com/products/java-media/jsdt/
356
[8] Shen, H. & Sun, C. (2000) RECIPE: a prototype for
Internet-based real-time collaborative programming.
Proceedings of the 2nd Annual International
Workshop on Collaborative Editing Systems in
conjunction with ACM CSCW Conference, December
2-6, Philadelphia, Pennsylvania, USA.
[3] Esteves, M. & Mendes, A.J. (2003) OOP-Anim, a
system to support learning of basic object oriented
programming concepts. Proceedings of CompSysTech'
2003 - International Conference on Computer Systems
and Technologies. Sofia, Bulgaria.
[4] Gutwin, C. & Greenberg, S. (1997) Workspace
Awareness. CHI’97 Workshop on Awareness in
Collaborative Systems. Atlanta, Georgia, March 22-27.
[9] Wessner, M., Hans-Rüdiger, P. & Miao, Y. (1999)
Using Learning Protocols to Structure ComputerSupported Cooperative Learning. Proceedings of the
ED-MEDIA’99. World Conference on Educational
Multimedia, Hypermedia & Telecommunications, pp.
471-476, Seattle, Washington, June 19-24.
[5] Johnson, P.M. (1998) Reengineering Inspection: The
Future of Formal Technical Review. Communications
of the ACM, vol. 41, pp. 49-52.
[6] Lund, K., Baker, M.J. & Baron, M. (1996) Modelling
dialogue and beliefs as a basis for generating guidance
in a CSCL environment. Proceedings of the
International Conference on Intelligent Tutoring
Systems, pp. 206-214. Montreal.
[10] Williams, L. & Upchurch, R.L. (2001) In Support of
Student Pair-Programming. ACM SIGCSE Conference
for Computer Science Educators, February.
[11] Williams, L.A. & Kessler, R.R. (2000) All I really
need to know about pair programming learned in
kindergarten. Communications of the ACM, Vol. 43,
No. 5 (2000).
[7] Nosek, J.T. (1998) The Case for Collaborative
Programming. Communications of the ACM, Vol. 41,
No. 3 (March), pp. 105-108.
[12] Winograd, T. (1988) A Language/Action Perspective
on the Design of Cooperative Work. Greif, E. (Ed.)
CSCW: A Book of Readings. Morgan-Kaufmann.
357