1

Organización de actividades de aprendizaje colaborativo basado en problemas en el sistema

DomoSim-TPC Miguel A. Redondo, Crescencio Bravo, José Bravo, Manuel Ortega

Abstract— Las experiencias de aprendizaje colaborativo sobre

entornos telemáticos promueven el desarrollo de conocimiento compartido por los participantes. En estos entornos la tecnología puede proporcionar mecanismos tanto para el acceso y gestión del conocimiento generado como para la propia organización, estructuración y seguimiento de dichas experiencias. En este artículo describimos las decisiones de diseño que se han tomado y el soporte que se ha incluido en el sistema DomoSim-TPC para organizar y gestionar actividades de aprendizaje colaborativo de técnicas de diseño mediante resolución de problemas.

Index Terms—Aprendizaje colaborativo; concepción, desarrollo y evaluación de software educativo; sistemas distribuidos en tele-educación.

I. INTRODUCCIÓN Los entornos de aprendizaje colaborativo comprometen a

los aprendices en la realización de actividades cognitivas y metacognitivas que promueven el desarrollo de conocimiento compartido por todos los miembros de un grupo. En estos entornos la tecnología proporciona mecanismos para la utilización de información hipermedia, acceso remoto a la información y realización de actividades a distancia, organización y estructuración de dichas actividades, etc. Los sistemas CSILE [1] y Notebook [2] son ejemplos pioneros que

materializan el planteamiento anterior.

Este trabajo ha sido realizado gracias al apoyo prestado por la Junta de

Comunidades de Castilla-La Mancha y por Ministerio de Ciencia y Tecnología en el marco de los proyectos PBI-02-026 y TIC2002-01387 respectivamente.

M. A. Redondo es Profesor Asociado del Departamento de Informática de la Universidad de Castilla – La Mancha y adscrito a la Escuela Superior de Informática de Ciudad Real. Paseo de la Universidad, 4. 13071 – Ciudad Real. (Tfno.: +34 926295300 ext. 3717, email: Miguel.Redondo@uclm.es).

C. Bravo es Profesor Asociado del Departamento de Informática de la Universidad de Castilla – La Mancha y adscrito a la Escuela Superior de Informática de Ciudad Real. Paseo de la Universidad, 4. 13071 – Ciudad Real. (Tfno.: +34 926295300 ext. 3717, email: Crescencio.Bravo@uclm.es).

J. Bravo es Profesor Titular de Escuela Universitaria del Departamento de Informática de la Universidad de Castilla – La Mancha y adscrito a la Escuela Superior de Informática de Ciudad Real. Paseo de la Universidad, 4. 13071 – Ciudad Real. (Tfno.: +34 926295300 ext. 3713, email: Jose.Bravo@uclm.es).

M. Ortega es Catedrático de Escuela Universitaria del Departamento de Informática de la Universidad de Castilla – La Mancha y adscrito a la Escuela Superior de Informática de Ciudad Real. Paseo de la Universidad, 4. 13071 – Ciudad Real. (Tfno.: +34 926295300 ext. 3723, email: Manuel.Ortega@uclm.es).

Cuando el aprendizaje se orienta hacia materias altamente experimentales, modelos instruccionales como el Aprendizaje Basado en Problemas [3] o el Aprendizaje Basado en Proyectos [4] refuerzan el compromiso entre el aprendiz y la actividad que realiza. En este sentido, Koschmann [5] propuso una aproximación que relacionaba las ventajas del Aprendizaje Basado en Problemas y las de la utilización de la tecnología al servicio de la enseñanza. En la actualidad, otros investigadores como Jonnassen [6] se plantean, como primera aproximación, identificar y modelar diferentes tipos de problemas para posteriormente tratar de sistematizar la actividad cognitiva de su resolución y determinar la forma en la que la tecnología puede ayudar en estas actividades.

Por ejemplo, en [7] se destaca que una de las características importantes que debe proporcionar la tecnología es la de facilitar la estructuración, representación, almacenamiento y recuperación de actividades de aprendizaje colaborativo para su análisis y reutilización.

En este artículo describimos el soporte que se ha incluido en el sistema DomoSim-TPC [8] para organizar actividades de aprendizaje colaborativo de técnicas de diseño mediante la resolución de problemas. Principalmente nos centraremos en presentar las decisiones que se han tomado para organizar los grupos de trabajo, para estructurar las actividades de aprendizaje y, sobre todo, para monitorizar la resolución de los problemas que se plantean a los alumnos, ya que el dominio donde se aplica nos permite explotar esta característica.

En la siguiente sección presentamos las características más destacadas del sistema DomoSim-PTC. A continuación describimos el modelo adoptado para organizar y gestionar las actividades de aprendizaje. Finalmente, apuntamos algunas conclusiones de nuestro trabajo.

II. EL ENTORNO DOMOSIM-TPC Utilizamos el marco conceptual proporcionado por el

paradigma CSCL [9] para situar los aspectos sociales y tecnológicos relacionados con esta investigación. Interpretamos el aprendizaje como un proceso social y distribuido, donde se considera de forma especial el diálogo producido de forma cooperativa entre los participantes que tratan de construir conjuntamente la solución a un problema.

2

Así, desarrollamos DomoSim-TPC, un entorno distribuido con soporte para aprendizaje a distancia del diseño domótico. Éste incluye facilidades para configuración, realización, seguimiento, análisis y almacenamiento de actividades de aprendizaje.

El término Domótica está asociado al conjunto de elementos que instalados en viviendas y edificios, interconectados y controlados automáticamente, liberan al usuario de acciones rutinarias y al mismo tiempo optimizan el control y el confort, el consumo energético, la seguridad y las comunicaciones.

Para la realización de las actividades de aprendizaje se utiliza el concepto de espacio de trabajo, entendido como un espacio virtual y estructurado con recursos y herramientas para resolver tareas (en nuestro caso problemas de diseño).

En particular, una actividad de aprendizaje del diseño domótico quedará definida, además de por las herramientas disponibles en los espacios de trabajo, por:

• El enunciado debidamente estructurado del problema a resolver.

• Las restricciones y posibilidades de intercambio de información con los miembros del grupo de trabajo y con los profesores.

• La definición y asignación de roles. • El establecimiento de restricciones generales. • La definición de un nivel de ayuda que marcará el

grado de apoyo que ofrecerá el sistema durante la actividad.

Figura 1. Etapas de una experiencia de aprendizaje

Como se muestra en la figura 1, las actividades de

aprendizaje se estructuran en tres etapas claramente diferenciadas:

1. Especificación de modelos y planificación de su estrategia de diseño. En esta etapa los aprendices, de forma individual, reflexionan y definen los pasos que determinan la estrategia a seguir para construir el modelo que según su criterio satisface los requisitos propuestos en el enunciado del problema. Es decir, definen la solución y la forma de alcanzarla. En este proceso la actuación del usuario puede ser conducida por el sistema. Para tal fin se dispone de una herramienta denominada PlanEdit [10], que utilizando una representación intermedia y abstracta para especificar el diseño y utilizando conocimiento experto representado en forma de planes óptimos de diseño, se adapta a la actuación del aprendiz y le aconseja sobre cuales serían las mejores acciones a abordar en cada momento.

2. Discusión, argumentación y búsqueda de consenso en las

características del modelo que se plantea. En esta etapa se desarrollan dos ejercicios cognitivos: diseñar y colaborar. Los participantes discuten de forma argumentada sobre la solución, su forma y los pasos que hay que realizar para obtenerla. Así, de este proceso se obtendrá una propuesta que refleja el punto de vista de cada uno de los participantes.

3. Diseño detallado y simulación en grupo. Antes de probar la validez de la solución propuesta los aprendices deben detallar y organizar los atributos asociados a los objetos que constituyen el modelo. Esto se realiza mediante una herramienta, también colaborativa, basada en manipulación directa de objetos del dominio [11]. Posteriormente, se plantean hipótesis y casos de estudio que se deben contrastar mediante la simulación del comportamiento de dicho modelo. En esta simulación todos los participantes pueden interactuar en tiempo real contribuyendo a la detección de errores de funcionamiento y al descubrimiento de inconsistencias en el planteamiento.

III. ORGANIZACIÓN DE ACTIVIDADES Situamos la definición de las actividades en torno al modelo

estructural que Engeström [12] propuso para modelar actividades utilizando la Teoría de la Actividad. Del análisis y estudio de este modelo, junto con los usuarios finales encargados de organizar y planificar la realización de actividades, se observó la necesidad de disponer de herramientas para definir los componentes de una actividad. A continuación se describen los fundamentos y detalles de estas herramientas.

A. Gestión de usuarios y de grupos de trabajo Los usuarios de DomoSim-TPC se clasifican en dos

categorías generales: profesores y alumnos. Esta clasificación da lugar a un primer nivel de gestión de roles en el que se establecen derechos de acceso en el contexto del sistema en general. Otras especificaciones de sistemas consideran otras categorías de usuarios [13], pero en el dominio en el que se aplica el nuestro se ha observado que sólo son necesarias estas dos.

El entorno incorpora una herramienta destinada al mantenimiento de la información relativa a los usuarios y sus características. Dicho mantenimiento solo puede ser realizado por participantes con derechos de acceso a la misma (generalmente profesores). La figura 2 muestra el interfaz de dicha herramienta. Se puede observar que se recogen datos generales y de identificación de cada usuario, incluso se registra la URL de su fotografía. Ésta se utiliza en diversas etapas y utilidades como las de discusión y de simulación.

3

Figura 2. Interfaz de usuario para la gestión de usuarios de tipo profesor.

Mediante la funcionalidad ofrecida por la interfaz se pueden

realizar búsquedas de usuarios atendiendo a varios criterios (mediante los botones de búsqueda situados junto a los campos destinados al DNI y al login). Además, la selección de usuarios se simplifica mediante la incorporación de listas de registros que facilitan el acceso directo a sus datos.

Para la realización de las actividades de diseño los usuarios se organizan en grupos de trabajo. Estos grupos estarán formados por uno o más alumnos y pueden ser coordinados por uno o más profesores, aunque generalmente será uno sólo.

La figura 3 describe, utilizando UML, el modelo seguido para esta organización. Existe una clase abstracta que denominamos Usuario y que contiene la información común para todas las categorías de usuarios permitidas en el sistema. Ésta clase se especializa en otras dos para los usuarios de tipo Profesor y de tipo Alumno, donde se definen las particularidades de cada uno de estos tipos. Los usuarios se organizan en grupos formados por uno o más alumnos y coordinados por uno o más profesores.

Figura 3. Modelo conceptual para la organización y clasificación de usuarios.

B. Problemas de diseño Las actividades de aprendizaje consisten en la resolución de

problemas de diseño. El objetivo de un problema de diseño es el de fomentar situaciones en las que los aprendices se enfrenten a las tareas propias del dominio a estudio, con el propósito de satisfacer un conjunto de requerimientos y necesidades contando con una serie de recursos. En este sentido destacamos algunos elementos que caracterizan la especificación de un problema de diseño de instalaciones domóticas:

• Identificación y enunciado resumido del problema

• Características de la vivienda para la que se plantea el problema.

• Información del entorno o contexto en el que se sitúa la vivienda.

• Requisitos y necesidades definidos, como los servicios y las áreas de gestión a automatizar así como sus características generales.

• Tareas que hay que abordar y por lo tanto en las que se puede estructurar el problema. Para cada una de estas tareas se contará con un mecanismo o estrategia general de resolución.

• Hipótesis y casos de estudio de cara a una verificación del modelo propuesto. Esta verificación podrá realizarse mediante la simulación de su comportamiento, una vez definidas correctamente sus propiedades.

DomoSim-TPC ofrece la funcionalidad necesaria para que expertos o profesores puedan definir nuevos problemas y casos de estudio. Estos problemas quedarán almacenados en una memoria organizativa mantenida por el sistema. Así, se persigue la reutilización de información en situaciones y contextos diferentes. Del mismo modo, se hace recaer la responsabilidad de la definición de problemas y de sus objetivos docentes del lado de los profesionales en la docencia de la materia, tratando de fomentar un proceso de aprendizaje realista y efectivo.

Se han desarrollado una serie de utilidades dentro de un proceso iterativo en el que se ha contado con la participación activa de usuarios finales. De esta forma, se ha conseguido un método flexible para la especificación de problemas mediante la definición de los elementos que se han considerado como característicos.

El método estructura la resolución de los problemas en diversas tareas. Para cada una de estas tareas los expertos expresan una estrategia general de resolución que el sistema registra y utiliza para guiar a los aprendices en su trabajo.

Destacamos la posibilidad de definir diferentes niveles de ayuda que el sistema podrá ofrecer, tanto a los usuarios como al grupo, durante la resolución de las tareas asociadas a la actividad. Mediante esta posibilidad pretendemos ofrecer la suficiente funcionalidad para que los profesores puedan emplear técnicas de scaffolding [14, 15]. De esta forma, se puede considerar la resolución de problemas con diferentes niveles de ayuda de refuerzo, dependiendo de los conocimientos previos de los participantes y dentro de un proceso de integración sucesiva del conocimiento. Por ejemplo, en etapas iniciales se pueden plantear problemas sencillos con alto nivel de ayuda, mientras que según se va avanzando en el conocimiento del dominio se pueden abordar problemas más complejos y con menor ayuda.

En particular, se han considerado tres categorías o niveles de ayuda: Alto, Medio y Bajo. Asociado a cada uno de estos niveles el sistema efectuará ciertas verificaciones contrastando el modelo y estrategia que plantean los aprendices con conocimiento obtenido de expertos en la materia y asociado a la tarea que resuelven mediante lo que hemos denominado Plan General de Diseño y Plan Óptimo de Diseño (más

4

adelante se explican estos conceptos). A continuación se describen los desarrollos realizados con

el objetivo de mantener la memoria organizativa de problemas y sus estructuras generales de resolución.

1) Identificación del problema

La identificación del problema dentro del sistema se realiza mediante un único código alfanumérico que se acompaña con algunos datos más que constituyen información de carácter general sobre dicho problema. A continuación resumimos este tipo de información que se puede observar en la figura 4:

• Nivel de complejidad. Esta información proviene de la opinión de los expertos y docentes en la materia y se utiliza para clasificar los problemas en tres categorías: alto, medio y bajo. Además, esta información se puede emplear para articular mecanismos de scaffolding.

• Enunciado del problema. Texto resumen del objetivo a cumplir en la solución que se proponga.

• Plano. Plano de la vivienda que constituye una representación del escenario sobre el que se demandan las especificaciones del problema.

• Diseño en la solución. Este dato se utiliza para indicar si el problema es de tipo experimental y se plantea con el objetivo de que los aprendices puedan practicar libremente. Es decir, permite a los participantes diseñar y efectuar simulaciones para observar el funcionamiento de los elementos pero no se les obliga a proponer una solución que satisfaga las especificaciones del problema.

• Observaciones. Espacio adicional para anotar otro tipo de reseñas.

Figura 4. Interfaz para gestión de la identificación de un problema.

2) Características de la vivienda sobre la que se trabaja

Bajo este calificativo se agrupan características relativas a la vivienda. Se considera su propio plano y aquellos datos que describen aspectos físicos de la misma que tienen especial repercusión en el problema que se va a estudiar.

La definición y gestión de planos de las viviendas se realiza mediante una herramienta de autor desarrollada a tal efecto. Aunque el plano se define como si de un objeto en dos dimensiones se tratase, se incluye información relativa a la altura de cada una de las habitaciones, de esta forma se pueden realizar cálculos relativos a la vivienda considerada como un volumen. En este sentido, también se considera el

coeficiente de pérdida de temperatura que presentan los hipotéticos materiales de construcción empleados para levantar las paredes de la misma. Este coeficiente podrá ser empleado en procesos de simulación del comportamiento y evolución de la temperatura.

El resto de información que se considera describe valores de potencia energética, distribución de la energía en líneas de carga, calorías de los elementos de radiación de aire caliente, lúmenes de los puntos de luz, etc. (para más detalles ver figura 5). La información relativa a cada uno de los parámetros considerados para la vivienda puede quedar definida de diferentes formas no necesariamente excluyentes:

• Indefinida (la casilla Def. de la interfaz no está activada). Se debe definir como parte de la solución al problema.

• Definida (la casilla Def. está activada). El profesor establece unos valores por defecto.

• Modificable (la casilla Modificable está activada). Los usuarios pueden modificar los valores como parte de la solución al problema.

• No modificable (la casilla Modificable no está activada). Los usuarios deben trabajar únicamente con los valores por defecto que propuso el profesor, considerándolos como parte de la especificación del problema.

Figura 5. Interfaz para la definición de las características que modelan la vivienda.

3) Contexto en el que se sitúa la vivienda

En esta categoría se agrupan aquellas características relativas al entorno medioambiental en el que se sitúa la vivienda objeto de estudio. Como ejemplo, podemos citar parámetros sobre cómo evoluciona la temperatura exterior o la iluminación a lo largo del día, cóo incide la temperatura en el interior de la vivienda, la estación del año para la que se pretende optimizar el diseño, etc.

La figura 6 muestra la interfaz desarrollada para el mantenimiento de este tipo de información. Destacamos que como en el caso de la definición de características de la vivienda, existen parámetros para los que se puede establecer un valor por defecto o por el contrario estos valores deben obtenerse como parte de la solución. En caso de que los valores se fijen inicialmente, estos pueden ser modificables o no. Todo esto dependerá del estado de los campos Modificable y Def. asociado a cada parámetro.

5

Figura 6. Definición de las características del contexto en el que se sitúa la vivienda.

4) Parámetros, restricciones y necesidades del problema

Los objetivos a conseguir con el modelo cuyo diseño se propone se definen mediante parámetros que organizamos en varias categorías:

- relativos al confort térmico - relativos al confort luminoso - relativos a la seguridad

Los parámetros pertenecientes a estas categorías pueden presentar valores que se considerarán como punto de partida cuando se inicia algún proceso de simulación del modelo.

Para la consecución de los objetivos se pueden establecer algunas restricciones entre las que por ejemplo, para el caso del confort térmico, se han considerado aquellas relativas al número de radiadores y al número de equipos de aire acondicionado.

Las necesidades a satisfacer por el problema se completan mediante la especificación de otros requisitos que hacen referencia a la obligatoriedad de la inclusión de elementos u operadores concretos.

La figura 7 muestra la herramienta de autor mediante la que se especifican parámetros, restricciones y necesidades que completan la definición del propósito del problema. La interfaz de esta herramienta se ha diseñado en base a la presentación de casillas de verificación mediante las que confirmar o descartar opciones referentes a los objetivos del problema. En función de estas opciones se generará de forma automática un enunciado detallado en el que se describe la situación cuya resolución se plantea.

Toda esta información se organiza y clasifica en torno al concepto de área de gestión como grupo de servicios que pueden ser automatizados y controlados en una vivienda. Así, el problema que se propone tendrá que abordar la automatización de servicios relativos a una o varias de estas áreas. En la parte superior izquierda de la interfaz se muestran las áreas junto con una casilla de verificación para cada una de ellas. Aquellas que tengan marcada esta casilla serán objeto de estudio en el problema.

Figura 7. Definición de parámetros, restricciones y necesidades de un problema.

5) Casos de estudio e hipótesis de trabajo Para la simulación de los modelos que los alumnos

construyen como solución a los problemas planteados se asocia a cada uno de ellos diferentes casos de simulación e hipótesis de trabajo.

Como caso de estudio entendemos aquellas situaciones en las que se debe verificar el comportamiento del diseño. En la utilidad desarrollada es posible definir hasta tres casos diferentes para los que el modelo debe satisfacer los requisitos propuestos en apartados anteriores (ver parte superior de la figura 8).

Figura 8. Definición de casos de estudio e hipótesis de trabajo.

En el proceso de simulación los usuarios podrán reflexionar

y discutir sobre el comportamiento del sistema. El mecanismo de establecimiento de hipótesis ayuda a centrar el tema de la discusión, ya que la simulación se orientará a determinar si se cumple o no lo apuntado en dicha hipótesis. En la definición del problema, el profesor puede fijar hasta dos hipótesis de ejemplo como guía a la discusión entre los alumnos (ver parte central de la figura 8).

C. Estructuración en tareas y esquemas generales de resolución En función de los datos anteriormente descritos la

resolución del problema se estructura en diversas tareas o apartados. En un primer enfoque podríamos considerar que cada tarea podría recoger las acciones necesarias para resolver

6

las cuestiones planteadas para un área de gestión. Sin embargo, las tareas que se generarían serían de gran envergadura y la granularidad de las mismas complicaría la discusión en torno a las acciones que las caracterizan, sobre todo en viviendas compuestas por un gran número de habitaciones. Creemos que es una mejor aproximación considerar como tareas individuales la resolución de la automatización de los servicios de cada área de gestión sobre cada sección definida (habitación) en el plano de la vivienda. Este planteamiento es el que hemos adoptado. Así, la generación automática de las tareas en que se estructura el problema se resuelve siguiendo un sencillo algoritmo que se muestra en la figura 9.

Figura 9. Algoritmo para generación de tareas en que se estructura la resolución de un problema de diseño en Domótica.

Figura 10. Relación entre áreas de gestión, tipos de habitaciones y Plan General de Diseño.

Cada tarea de las que se han definido cuenta con la

suficiente generalidad como para abstraer unas pautas o guías a seguir para su resolución. Por ejemplo, la automatización de los servicios relativos al confort térmico mantiene un esquema general para todos los dormitorios, aunque será directamente dependiente de las restricciones, necesidades y contexto específico en el que se sitúa el problema.

La figura 10 muestra la tabla de doble entrada mediante la que se determina el identificador correspondiente al tipo de estrategia o Plan General de Diseño (PGD) que hemos asociado a cada par formado por una habitación y un área de gestión. Este plan representa información proporcionada por expertos en la docencia de la Domótica y se compone de aspectos relativos a las siguientes categorías:

• Elementos. Hace referencia a los operadores que formarán parte del modelo o solución al problema. La presencia de éstos en la solución se puede considerar como obligatoria, aconsejable o admisible. Definimos estos términos como:

- La presencia de un elemento en una propuesta de solución es obligatoria si es imprescindible para resolver el problema planteado.

- La presencia de un elemento es aconsejable en una propuesta de solución si no es obligatoria pero mejora las características del modelo planteado para resolver el problema.

- La presencia de un elemento es admisible en una propuesta de solución si no es obligatoria pero es posible, aunque no mejorará sensiblemente las características del modelo planteado.

• Relaciones. Hace referencia a los enlaces que se establecen entre pares de operadores. La presencia de cada uno de estos enlaces, como en el caso anterior, puede ser obligatoria, aconsejable o admisible. Para definir estos términos se aplican las mismas definiciones apuntadas para los elementos.

• Restricciones. Aportan información relativa al orden de la secuencia de acciones que constituyen la estrategia a seguir para construir una buena solución. Es decir, establecen un orden entre las acciones a seguir para definir los elementos y relaciones que deben formar parte del modelo.

• Alteraciones. Definen la influencia que tienen o presentan los parámetros, restricciones y necesidades específicas del problema sobre la estrategia de resolución. Éstas se traducen en:

- Modificaciones del carácter de obligatoriedad de uno o varios elementos.

- Modificaciones del carácter de obligatoriedad de una o varias relaciones.

- Modificación de una o varias restricciones. Podemos formalizar la información que forma parte de un

Plan General de Diseño como se indica a continuación. Sea D el conjunto que representa el dominio de la domótica. Sea A el conjunto de todas las acciones de diseño posibles en D. Sea T la tarea consistente en construir el modelo de diseño domótico apropiado para automatizar los servicios de un área de gestión en una habitación. Definimos como el conjunto de las acciones de diseño que constituyen el modelo propuesto como solución a la tarea T del problema.

AM T ⊂

Sea Op el conjunto de todos los operadores domóticos. Sea Tip = {obligatorio, aconsejable, admisible}. Definimos el Plan General de Diseño para una tarea T de un problema de diseño (PGDT) como PGDT = {ET, RT, CT, NT}, donde:

• ET es el conjunto de todos los elementos que forman parte de PGDT. Los elementos de ET son pares de la forma (e, t), tales que e y t . Op∈ Tip∈

• RT es el conjunto de todas las relaciones que forman parte de PGDT. Los elementos de ET son pares de la forma (r, t), tales que r es una relación establecida entre dos elementos e y t . Ope ∈21, Tip∈

• CT es el conjunto de todas las restricciones que forman parte de PGDT. Los elementos de CT son pares de la forma (c, a), tales que c y )( TT RE U∈ Aa ∈ ,

• NT es el conjunto de todas las alteraciones contempladas para PGDT.

Definimos el Plan Óptimo de Diseño para una tarea ( ) de un problema en base a los parámetros, requisitos y necesidades que se han establecido y que han sido contemplados como modificaciones en N

TPOD

TPODT. De forma que

. TT NPGD U=

7

Con los conceptos anteriormente definidos, podemos considerar algunas operaciones como la de obtener el conjunto de los elementos (operadores) que forman el modelo mínimo que soluciona una tarea de un problema. A este conjunto lo notamos como y se define como:

minME

)(),(/ eoobligatoriPODteEeME TTmin ∧∈∃∈= Las relaciones que forman parte del modelo mínimo que

soluciona una tarea se nota como MR y se define como: min

)(),(/min roobligatoriPODtrRrMR TT ∧∈∃∈= Para que sea admisible afrontar la realización de una acción

, las acciones de diseño trazadas como parte de un modelo M

Aa ∈T deben verificar que:

TTT MeAaEeCae ∈⇒∈∈∈∀ ,,),(

Considerando la formalización anterior podemos construir un algoritmo para la generación de las tareas en que se estructura la resolución de un problema y para la inferencia del Plan Óptimo de Diseño asociado a cada una de ellas, siempre partiendo del correspondiente Plan General de Diseño. El algoritmo queda definido como se muestra en la figura 11.

Figura 11. Algoritmo para generación de tareas en que se estructura la resolución de un problema de diseño en domótica y obtención de los Planes Óptimos de Diseño asociados a cada una de ellas.

D. Colaboración Teniendo presente el modelo de referencia que empleamos,

necesitamos mecanismos para establecer normas relativas al trabajo en grupo. Estas normas, principalmente, hacen referencia a las alternativas de comunicación y discusión, a los criterios de reparto del trabajo, a la forma en la que éste se hace efectivo y a la definición de sesiones de trabajo online para verificar las propiedades de los modelos construidos mediante simulación. Describimos a continuación los mecanismos y herramientas para establecer dichas normas.

1) Restricciones de comunicación para la discusión y argumentación

Entre las normas que se definen para los usuarios participantes en una actividad y la comunidad involucrada destacamos aquellas que afectan a las estructuras conversacionales que se podrán emplear durante el proceso de negociación para la justificación y argumentación de las propuestas de diseño que plantean los aprendices como solución a cada una de las tareas en que se estructura un problema. En dicho proceso de negociación aparecen diferentes tipos de contribuciones sobre las que se puede

actuar de diferentes formas: respondiendo, preguntando, etc. Estos elementos se han clasificado atendiendo a un modelo objeto-acción. Los tipos de contribuciones constituyen los objetos del modelo mientras que los tipos de actuaciones que se realizan se consideran como acciones.

El objetivo que se persigue con la definición de este modelo es el de poder fijar qué tipo de acción (respuesta) se puede iniciar a partir de un objeto (contribución). Por ejemplo, podemos restringir las posibilidades de comunicación indicando que el tipo de respuesta a una contribución de comentario solo puede ser una acción que genere una contribución de tipo aclaración.

Para representar este tipo de restricciones se construye una tabla de doble entrada en la que se fijan tipos de objetos y tipos de acciones en cada sus dimensiones. Cada una de las celdas, T(c, a), de esta tabla contiene un valor lógico que indica si a la contribución c se puede emitir una respuesta de tipo a (ver figura 12). Así, la forma de discutir, argumentar y justificar las posturas individuales dependerá muy especialmente de la configuración que se realice mediante esta tabla. Esta funcionalidad ofrece, desde el punto de vista de los profesores, importantes posibilidades para definir las características cognitivas de las tareas a realizar. Es decir, además de variar el tipo de problema a realizar permite establecer cómo debe ser la comunicación entre los miembros del grupo para resolver dicho problema.

Figura 12. Tabla de configuración de restricciones de comunicación para la discusión y argumentación.

2) Asignación y reparto del trabajo

Respecto a la estrategia de reparto de trabajo que se puede establecer entre los miembros del grupo se han considerado dos posibilidades:

• Asignación de responsables o especialistas en la realización de cada tarea.

• Definición de roles que habilitan para realizar unas tareas y restringen la realización de otras.

La asignación de la responsabilidad de la realización de una tarea a un miembro del grupo repercute en el hecho de que este usuario tendrá encomendada la función de realizar las propuestas de diseño que resuelven la problemática planteada por la tarea. El resto de los participantes solo podrán pedir información, realizar críticas o manifestar su acuerdo o desacuerdo con referencia a los planteamientos que realiza el

8

responsable. Las restricciones respecto a la comunicación que establece

la asignación de responsabilidades prevalecen frente a lo definido en la tabla descrita anteriormente.

La configuración de estas responsabilidades se realiza mediante la herramienta cuya interfaz se muestra en la figura 13. En la zona de la izquierda aparecen las tareas de la actividad que todavía no tienen asignado responsable, en la zona de la derecha aparecen los participantes en la actividad y candidatos a ser responsables de alguna tarea y en la parte inferior se muestran los pares (tarea, alumno) corres-pondientes a asignaciones ya establecidas. No es obligatorio que toda tarea cuente con un responsable del mismo modo que no todo usuario tiene que tener asignada una responsabilidad.

Figura 13. Asignación de responsables o especialistas por tareas.

Las responsabilidades asignadas a cada usuario se muestran

en la interfaz de sus herramientas cuando acceden a los subespacios de trabajo donde éstas surten efecto.

Desde el punto de vista del análisis del comportamiento de los grupos de trabajo durante la realización de diferentes actividades de aprendizaje, se ha considerado interesante y beneficioso disponer de la flexibilidad suficiente para poder refinar los roles que los usuarios desempeñan respecto del sistema en general.

Como punto de partida se han definido tres tipos de roles: Espectador, Diseñador y Crítico. Cada uno de estos tipos lleva asociadas restricciones en cuanto a su comportamiento ante el grupo. Por ejemplo, un participante de tipo Espectador será un mero observador del proceso que realiza el resto y no se le permitirá ni plantear propuestas ni realizar críticas del trabajo de los demás. Un participante de tipo Diseñador será el encargado de plantear los diseños iniciales y argumentarlos como respuesta a las críticas del resto. Un participante de tipo Crítico será aquel que se encarga de pedir explicaciones con referencia a lo que los demás plantean, y del mismo modo, tratar de determinar posibles errores en dichos planteamientos.

Tanto el tipo de roles que soporta el sistema como las funciones que se les atribuyen son totalmente flexibles y configurables para adaptarse a otras situaciones y experimentos con fines diferentes.

Como en el caso anterior, las restricciones respecto a la

comunicación que establece la definición de roles prevalecen frente a lo definido en la tabla descrita en el apartado anterior y también frente a lo fijado a nivel de responsabilidades y de especialistas.

Las restricciones que establecen los distintos roles se aplican a diferentes herramientas disponibles en el sistema. En la interfaz de estas herramientas se presenta, de forma personalizada para cada usuario, las características del rol con el que se ha accedido a las mismas.

La definición de los roles se realiza mediante una herramienta con una interfaz similar a la empleada para definir responsables por tareas (ver figura 13).

3) Sesiones de simulación

Para realizar la simulación colaborativa en tiempo real es preciso definir sesiones de trabajo. Definimos una sesión como el periodo de tiempo en el que se pueden efectuar actividades de diseño y simulación en un espacio de información compartido. Durante la simulación los usuarios pueden alterar el comportamiento automático del modelo mediante acciones elementales (encender y apagar, abrir y cerrar, provocar accidentes...). El usuario con el rol de profesor puede además controlar la sesión deteniéndola temporalmente para, por ejemplo, proponer una pregunta o provocar una reflexión.

La tarea de simulación se realiza en un proceso en tres fases: (1) diseño detallado, (2) tratamiento de casos e hipótesis y (3) simulación. Durante el diseño es preciso establecer una distribución o reparto de las acciones que debe realizar cada usuario. Una vez efectuado este reparto existen dos posibilidades: que el trabajo de cada individuo sea visible para el grupo o que sea privado y no se muestre hasta que sea explícitamente integrado por el usuario. Como parte del diseño también debe darse valor a ciertos parámetros generales correspondientes a las características de la vivienda y al entorno medioambiental. Para este proceso de parametrización se han considerado dos modelos:

• Democrático: Los alumnos proponen diferentes valores y como decisión final se toma el valor dado por la mayoría.

• Basado en propuestas: Los alumnos deben mostrar su acuerdo o desacuerdo con las propuestas de los demás, tomándose como decisión el valor que ha alcanzado el consenso.

En la fase de tratamiento de casos e hipótesis se siguen procesos de proposición que hemos modelado de acuerdo a la Perspectiva del Lenguaje/Acción [16]. Las acciones comunicativas se efectúan mediante botones que representan actos del habla. Las hipótesis y los casos que se discuten proceden de la definición del problema, aunque los estudiantes pueden introducir nuevos elementos.

Tanto las sesiones de simulación en tiempo real como el tipo de visibilidad del trabajo individual y el modelo de parametrización constituyen aspectos de la colaboración que se definen para cada actividad de aprendizaje.

9

IV. CONCLUSIONES En este trabajo hemos tratado de aprovechar las

posibilidades que ofrece la tecnología para estructurar, representar, almacenar y recuperar actividades de aprendizaje colaborativo. Así, hemos diseñado la organización de experiencias de aprendizaje del diseño en grupo en base a la Teoría de la Actividad y la estructura del modelo propuesto por Engeström que de ella se deriva. Considerando las necesidades impuestas por el dominio en el que aplicamos las experiencias, se ha construido un modelo conceptual en el que se definen las relaciones entre los elementos particulares que se ponen en juego para la representación de actividades de aprendizaje en DomoSim-TPC. En este modelo los usuarios se organizan en grupos constituidos por alumnos y coordinadores o profesores. Se dispone de una memoria organizativa de problemas de diseño diseñados por profesionales en la docencia de la materia. Se ha recogido la experiencia de estos profesionales para determinar las estrategias típicas y generales que se deben seguir para resolver estos problemas. Organizando y estructurando los problemas en diferentes categorías o tipos hemos podido asociar, para cada categoría, una estrategia de resolución general que hemos denominado Plan General de Diseño. Estas estrategias se ven modificadas en función de los objetivos y requerimientos específicos que se marquen en un problema particular. Como consecuencia de esta alteración se generará un Plan Óptimo de Diseño para cada una de las tareas en las que se puede descomponer un problema de diseño. Esto nos permite plantear la búsqueda de la solución a un problema y el mecanismo para la construcción de la misma como objetivo de las actividades de aprendizaje.

Las actividades asocian grupos de trabajo y problemas organizados en tareas que deben resolver o realizar dichos grupos. Como consecuencia de la realización de estas tareas se obtienen resultados que están constituidos por:

• La solución en forma de modelo de diseño que recoge los puntos de vista de todos los participantes.

• La estrategia propuesta para construir dicha solución, también diseñada en grupo y formada por una secuencia de acciones de diseño.

• El proceso de discusión originado y desarrollado para justificar y argumentar las decisiones tomadas sobre la solución construida y sobre la forma de hacerlo.

• El proceso de simulación en grupo y verificación de las propiedades del modelo construido.

• Información referente a la interacción entre los usuarios del sistema, inferida tras el análisis y estudio de los diversos eventos significativos que se han registrado.

Toda esta información podría facilitar la realización de un exhaustivo análisis de la actividad, en términos de la solución obtenida, el proceso seguido para construirla y sus relaciones. Incluso, éste análisis podría abordarse de forma sistemática se buscan y articulan los métodos apropiados. Éste es un aspecto sobre el que nos plantemos profundizar en futuros trabajos.

En la actualidad el sistema se utiliza experimentalmente en algunos centros de Formación Profesional de la provincia de

Ciudad Real (España). En su memoria organizativa almacena información relativa a la resolución en grupo de unos 70 problemas de diseño, cada uno de ellos con características diferentes, tanto en lo relativo a su especificación como en lo relacionado con las normas establecidas para su resolución. Parte de esta información se puede consultar en la Web1.

REFERENCIAS [1] M. Scardamalia, C. Bereiter, “Computer support for Knowledge-

Building Communities”. Journal of the Learning Sciences, 3 (3), pp. 265-283, 1994.

[2] D.C. Edelson, R.D. Pea, L.M.Gómez, “The collaboratory Notebook”. Communication of the ACM 39 (4), pp. 32-33, 1996.

[3] H.S. Barrows, R. Tamblyn, (Eds.), Problem-based learning: An approach to medical education. New York: Srpinger, 1980.

[4] P. Blumenfeld, E. Soloway, R. Marx, J. Krajcik, M. Guzdial, A. Palincsar, “Motivating project-based learning: Sustaining the doing, supporting the learning”, Educational Psychologist, 26, pp. 369-398, 1980.

[5] T. Koschmann, A.C. Kelson, P.J. Feltovich, H.S. Barrows, “Computer-Supported Problem-Based Learning: A principled approach to the use of computers in collaborative learning”, in T. Koschmann (Ed.), CSCL: Theory and Practice of an Emerging Paradigm, NJ: Lawrence Erlbaum, Assoc. pp. 83-124, 1996.

[6] D.H. Jonassen, “Toward a Meta-Theory of Problem Solving”. Educational Technology: Research & Development, 48 (4), pp. 63-85, 2000.

[7] M.F. Verdejo, B. Barros, “Creating an organisational learning memory for collaborative experiences in distance education”, Proceedings of XV IFIP World Compueter Congress, pp. 1035-1045, 1998.

[8] C. Bravo, M.A. Redondo, J. Bravo, M. Ortega, “DOMOSIM-COL: A Simulation Collaborative Environment for the Learning of Domotic Desgin”, Reviewed paper in Inroads The SIGCSE Bulletin of ACM, 32 (2), pp.65-67, (2000).

[9] T. Koschmann, “Paradigm shifts and instructional technology”. In T. Koschmann (Ed.), CSCL: Theory and Practice of an Emerging Paradigm, NJ: Lawrence Erlbaum, Assoc. pp. 1-24, 1996.

[10] M.A. Redondo, C. Bravo, M. Ortega, M.F. Verdejo, “PlanEdit: An adaptive tool for design learning by problem solving”. In P. De Bra, P. Brusilovsky y R. Conejo (Eds.), Adaptive Hypermedia and Adaptive Web Based-Systems, 2nd International Conference of Adaptive Hypermedia and Adaptive Web-Based Systems (AH2002). LNCS 2347, pp. 560-563. Springer-Verlag, 2002.

[11] C. Bravo, M.A. Redondo, M. Ortega, M.F. Verdejo, M.F., “Collaborative Discovery Learning of Model Design”, In S. A. Cerri, G. Gourdères y F Paraguaçu (Eds.), Intelligent Tutoring Systems, 6th International Conference on Intelligent Tutoring Systems Conference (ITS’2002). LNCS 2363, pp. 671-680. Springer-Verlag, 2002.

[12] Y. Engeström, “Learning by Expanding: An activity-Theoretical Approach to Developmental Research”. Helsinki: Orienta-Konsultit Oy, 1987.

[13] L. Anido, “Contribución a la definición de arquitecturas distribuidas para sistemas de aprendizaje basados en ordenador utilizando CORBA”. Tesis Doctoral: Departamento de Inteligencia Telemática. Universidad de Vigo, 2001.

[14] M.B. Rosson, J.M. Carroll, J.M., Scaffolded “Examples for Learning Object-Oriented Design”, Communications of ACM, 39 (4), 1996.

[15] M. Ortega, J. Bravo, C. Bravo, J.J. Muñoz, M.A. Redondo, “Scaffolding and Planning Techniques in Distance Education: A case Study in Statistics”, Proceeding of 4th International Conference on Technology Supported Learning. Online Educa. Berlin, pp. 164-168, 1998.

[16] Winograd, T., “A Language/Action Perspective on the Design of Cooperative Work”, in Greif, E. (Ed.), CSCW: A Book of Readings. Morgan-Kaufmann, 1988.

1 http://chico.inf-cr.uclm.es/mredondo