Anexo 9. Plataformas MV3D y LMS integradas

Transcripción

1 1 Anexo 9. Plataformas MV3D y LMS integradas El desarrollo de componentes, como se plantea en la arquitectura propuesta, comprende tres niveles identificados por la plataforma: servidor de recursos, LMS y MV3D. Desarrollos en el servidor de recursos El servidor de recursos utilizado corresponde a Restos, un servidor tipo REST desarrollado por Bernal (2010). En este servidor se implementaron los recursos necesarios para la integración, bajo un esquema modular. Restos fue utilizado como servidor principal de recursos, pero también como interfaz, para proveer recursos desde el LMS y desde el MV3D. El servidor principal de recursos, encargado de la publicación y descubrimiento, maneja de manera centralizada a los usuarios y es el encargado de definir las plataformas LMS y MV3D que participan en la comunicación. Por facilidad en el proyecto, la base de datos utilizada para almacenar los usuarios corresponde a la base de datos de la plataforma LMS; esa reutilización es posible debido a que el servidor Restos abstrae la comunicación y la presenta de manera transparente a los demás sistemas involucrados. Una de las principales razones para elegir manejar los usuarios desde el LMS es el ahorro de tiempos, que significa no tener que crear interfaces web para operaciones como edición del perfil, cambio de clave, gestión de cuentas, entre otras, pues dichas interfaces ya se encuentran implementadas en el LMS.

2 2 Desarrollos en la plataforma LMS Las actividades en la plataforma LMS se definieron como un Módulo de tipo actividad propio de Moodle. El módulo fue desarrollado siguiendo el esquema propuesto por los desarrolladores de Moodle (2010), haciendo una tipificación dentro del módulo para permitir crear los tres tipos de actividades definidos. En la Figura 1 Error! No se encuentra el origen de la referencia. se puede ver el menú, que muestra los tres tipos de actividades que pueden ser insertadas en Moodle. Figura 1. Menú para insertar actividades Cuando una actividad es creada, se genera la puerta que enlaza el LMS con el MV3D. En la Figura 2 puede verse la página que da acceso al mundo virtual después de haber creado una actividad. La imagen corresponde a la vista del docente y presenta tres pestañas en la parte superior. La primera pestaña es la página genérica, que muestra la información básica de la actividad y que, mediante el enlace Ir al mundo virtual, permite abrir el visor instalado y acceder directamente al MV3D en la zona que se preconfigura. La pestaña Relacionar recursos que se observa en la Figura 3 es

3 3 la que permite comunicar el LMS con el MV3D mediante la configuración de los mensajeros. La pestaña Ver informes que se observa en la Figura 4 es la que muestra los datos recogidos en la comunicación con los mensajeros y los presenta en tres tipos o vistas de informes, los cuales presentan la información dependiendo del tipo de actividad. Figura 2. Página que permite el acceso al MV3D desde LMS Figura 3. Página de configuración de los mensajeros

4 4 Figura 4. Página de informes. Vista Log de usuario Desarrollos en la plataforma MV3D OpenSim En el MV3D se contemplan dos tipos de desarrollo. El primero corresponde a las librerías de comunicación creadas para OpenSim, que implementan el modelo de comunicación definido, y el segundo corresponde a los componentes implementados dentro de OpenSim para la interacción con los usuarios. Las librerías de comunicación se implementaron como adición al lenguaje scripting de la plataforma OpenSim, y se les asignó el nombre clave de EntreDos. Dentro de la librería se encuentran completamente implementadas las funcionalidades edosisenabled, edosregistermessenger, edoslogvisit, edoslogaction, edosgettracking, edossavetracking, edosgetfeedback, edosgetquiz, edossavequizresult y edoslasterror. Con dichas funcionalidades se implementa el 100% de la comunicación y registro de los mensajeros, además de los componentes de seguimiento. Dado que OpenSim define un modelo de desarrollo de nuevas librerías, el desarrollo no se hizo de

5 5 manera invasiva; por el contrario, se desarrolló como un módulo adicional a la librería scripting de OpenSim. Los componentes implementados dentro de OpenSim son: enlace a documentos, reproductor de diapositivas, puerta de teletransportación entre zonas, infográfico, folleto, tablero de cuestionario, dos tipos de demarcador. Los diferentes componentes le permiten al avatar interactuar con los mensajeros de tipo retroalimentación y cuestionario, además de estar conectados mediante los mensajeros de tipo interacción. Los mensajeros de tipo visita se integran a objetos arquitectónicos del MV3D, por lo cual no requieren la construcción de componentes especiales; sin embargo, se desarrolló un subprograma integral que se vincula fácilmente con las construcciones para el registro de las visitas. En la Figura 5 puede verse una sala con algunos de los componentes construidos. La presentación gráfica de estos componentes es susceptible a cambios. Figura 5. Sala con contenidos en el MV3D del caso de estudio

6 6 Además de los componentes predeterminados, las funcionalidades del API están diseñadas para ser utilizadas en la construcción de actividades personalizadas. Para el caso de estudio, se utilizaron en la construcción de las dos actividades propuestas: Preparándose para salvar la reserva y Salvando la reserva. Mediante las funcionalidades del API se registran las acciones que realizan los avatares, el progreso que van teniendo en cada actividad, las respuestas en los cuestionarios, y las calificaciones parciales y totales obtenidas. Además, se utilizan las funcionalidades de consulta para retroalimentar al avatar frente a determinadas acciones, según el avance que ha conseguido, y para presentar ayudas o instrucciones que son configuradas desde el LMS. En la Figura 6 puede verse el fragmento de uno de los script que controla un paso de la actividad Preparándose para salvar la reserva. En dicho script, mediante la función edosisenabled, se valida si la actividad se encuentra activa; de ser así, se obtienen los datos de seguimiento del avatar mediante la función edosgettracking para saber el estado de la actividad, se registra la acción touch:info (tocar un objeto y recibir información), mediante la función edoslogaction, y utilizando los datos de seguimiento previamente obtenidos, se valida si la estación que el avatar está visitando es la siguiente. Si es así, se despliega un cuestionario correspondiente a la estación actual. De no ser la estación siguiente, se muestra un mensaje informando cuál es la estación que debería buscar.

7 Figura 6. Script en OpenSim utilizando mensajeros 7

8 8 Referencias Bernal, David H. (2010), Mundos virtuales 3D como herramientas en un LMS para apoyar procesos de enseñanza-aprendizaje [Proyecto de investigación para título de Maestría en Ingeniería], Medellín, Universidad de Antioquia. Moodle (2010), Development: Modules - Activity Modules [en línea], disponible en recuperado: diciembre de 2010.