Integración de herramientas de gamificación en plataformas de enseñanza virtual

e s El texto presentado no puede ocupar más de una línea Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Integración de herramientas de gamificación en plataformas de Enseñanza Virtual Autor: Pedro García Frutos Tutor: Francisco José Fernández Jiménez Dpto. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2018 Trabajo Fin de Grado Ingeniería de Telecomunicación Integración de herramientas de gamificación en plataformas de Enseñanza Virtual Autor: Pedro García Frutos Tutor: Francisco José Fernández Jiménez Profesor colaborador Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2018 Trabajo Fin de Grado: Integración de herramientas de gamificación en plataformas de Enseñanza Virtual El tribunal nombrado para juzgar el Trabajo arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2018 El Secretario del Tribunal Autor: Pedro García Frutos Tutor: Francisco José Fernández Jiménez A mi familia A mis amigos A mis maestros Agradecimientos Este trabajo no podría haberse realizado sin la ayuda de mi tutor Francisco José Fernández Jiménez, que ha colaborado en el proyecto y resuelto todas mis dudas. También merecen una mención especial Jesus Muñoz Calle -autor de los juegosy Francisco Javier Muñoz que accedieron a reunirse conmigo para cada duda o problema surgido con la implementación de los mismos e hicieron posible que todo funcionara correctamente. Por último, pero no menos importante, me gustaría agradecer a mis padres y amigos el apoyo brindado a lo largo de todos estos años y a los profesores que me han ido formando a lo largo de la carrera, sin los cuales tampoco podría estar finalizando en estos momentos. Pedro García Frutos Sevilla, 2018 3.3 Arquitectura y funcionamiento básico de la aplicación 37 3.3.1 Estructura de la base de datos 39 3.3.2 Comunicación entre los juegos y la aplicación web 41 4 Implementación 43 4.1. Código 43 4.1.1 Documentación 46 4.1.2 Clases 46 4.1.3 Librerías 48 4.1.4 Ficheros JSP 50 4.1.5 Fichero de configuración: config.properties 59 4.1.6 Descriptor de despliegue 60 4.1.7 Ficheros JavaScript 60 4.1.7.1 Ficheros usados para la creación de partidas 60 4.1.7.2 Ficheros usados para comunicación entre la herramienta y el juego 61 4.1.8 Archivos de error 61 4.1.9 Ficheros CSS 62 4.2 Otras funcionalidades 62 4.2.1 Eliminar usuarios 62 4.2.2 Borrado de notas 62 4.2.3 Control horario 62 4.2.4 Terminar partida 62 5 Prueba de ejecución 63 5.1 LMS utilizados 63 5.1.1 CourseSites 63 5.1.2 Moodle 63 5.2 Pruebas de funcionamiento y otros datos de interés 64 5.3 Pruebas de rendimiento 67 5.4 Pruebas de seguridad 67 6 Conclusiones, líneas de futuro y planificación 68 6.1 Conclusiones 68 6.2 Líneas de futuro 68 6.3 Planificación 69 Referencias 70 7 Anexos 73 Anexo A. Manual de instalación 73 7.1. Preparación del entorno 73 7.2 Fichero de configuraciób "config.properties" 73 7.3 Configuración para poder realizar pruebas o modificaciones 74 Anexo B. Manual de usuario 75 7.4 Instrucciones de uso 75 7.4.1 Aplicación Web 75 7.4.1.1 Creación de un usario 76 7.4.1.2 Subida de juegos y creación de una partida 78 7.4.1.3 Eliminación de una partida 81 7.4.1.4 Gestión de juegos 83 7.4.1.5 Eliminación de un usuario 86 7.4.1.6 Información de una partida y consulta de calificaciones 88 7.4.2 Integración de herramienta en LMS 89 7.4.2.1 CourseSites 89 7.4.2.2 Moodle 90 7.4.3 Acceso a la herramienta desde el TC 91 ÍNDICE DE TABLAS Tabla 1 Características de diferentes vesiones LTI………………………………………..….……..7 Tabla 2 Envío de mensaje al TC para escribir una nota en el cuaderno de calificaciones….….……..9 Tabla 3 Caracterización de los requisitos del sistema…………………………………..…….…….14 Tabla 4 Requisito general 01 “Sistema de creación y gestión de herramientras LTI……...…………14 Tabla 5 Requisito general 02 “Inicio de sesión”……………………………………………..……..15 Tabla 6 Requisito general 03 “Existencia de superusuario”………………………………..……….15 Tabla 7 Requisito general 04 “Creación de credenciales LTI”…………………………..………….15 Tabla 8 Requisito general 05 “Juego”………………………………………………….………...…15 Tabla 9 Requisito general 06 “Calificar usuario”……………………………………….…………..16 Tabla 10 Requisito general 07 “Versión LTI 1.1”…………………………………….…………….16 Tabla 11 Requisito general 08 “Mensajes informativos”…………………………….…………..….16 Tabla 12 Requisito general 09 “Arranque de la aplicación”………………………………………...17 Tabla 13 Requisito general 10 “Configuración de partidas”…………………………………………17 Tabla 14 Requisito general 11 “Sistema operativo”…………………………………………..…….18 Tabla 15 Caso de uso 01 “Iniciar sesión”……………………………………..…………………….18 Tabla 16 Caso de uso 02 “Crear usuarios”………………………………………………..…………19 Tabla 17 Caso de uso 03 “Eliminar usuarios”………………………………………………………19 Tabla 18 Caso de uso 04 “Elegir zona horaria”………………………………………………..……19 Tabla 19 Caso de uso 05 “Cambiar contraseña”……………………………………………………..19 Tabla 20 Caso de uso 06 “Subir juego”…………………………………………………………..…19 Tabla 21 Caso de uso 07 “Eliminar juegos”………………………………………………...……….20 Tabla 22 Caso de uso 08 “Habilitar/Deshabilitar juegos”………………………………….……….20 Tabla 23 Caso de uso 09 “Cerrar sesión”………………………………..………………………….20 Tabla 24 Caso de uso 10 “Detectar parámetros de forma automática”……………………………….21 Tabla 25 Caso de uso 11 “Crear partidas”……………………………………………………..……21 Tabla 26 Caso de uso 12 “Establecer fecha y hora”………………………………………………….21 Tabla 27 Caso de uso 13 “Establecimiento de parámetros LTI”……………………………………..21 Tabla 28 Caso de uso 14 “Número de repeticiones”…………………………………………………22 Tabla 29 Caso de uso 15 “Clave de acceso”……………………………..………………………….22 Tabla 30 Caso de uso 16 “Subir fichero de preguntas”……………………………………..……….22 Tabla 31 Caso de uso 17 “Borrar notas”………………………………………..…………………...23 Tabla 32 Caso de uso 18 “Editar partidas”……………………………………………………..…...23 Tabla 33 Caso de uso 19 “Información de la partida”………………………………………………..23 Tabla 34 Caso de uso 20 “Modo Test”…………………………………………..…………...……..24 Tabla 35 Caso de uso 21 “Borrar partida”…………………………………………..…………...….24 Tabla 36 Caso de uso 22 “Terminar partida”……………………………………………..…………24 Tabla 37 Caso de uso 23 “Acceso a herramienta LTI desde LMS”……………………...…………..24 Tabla 38 Regla de negocio 01 “Roles de usuario”………………………………………...…………26 Tabla 39 Regla de negocio 02 “Profesores creadores de partida”………………………..……….….27 Tabla 40 Requisitos de conducta 01 “Creación de tablas para comunicación LTI”……………….…27 Tabla 41 Requisitos de información 01 “Almacenamiento de usuarios y partidas”…………………..27 Tabla 42 Requisitos de información 02 “Parámetros de configuración LTI”………………..………28 Tabla 43 Requisitos de información 03 “Fichero de configuración”………………………..………29 Tabla 44 Requisitos de fiabilidad 01.......................................................................................................29 Tabla 45 Requisitos de fiabilidad 02 “Verificación de campos”……………………………………..30 Tabla 46 Requisitos de fiabilidad 03 “Nombre de partidas y/o juegos”……………………..………30 Tabla 47 Requisitos de fiabilidad 04 “Selección correcta de fecha y hora”…………………………..30 Tabla 48 Requisitos de fiabilidad 05 “Reinicio de partidas por recarga de contexto”………..……...30 Tabla 49 Requisitos de usabilidad 01 “Manual de instalación”…………………………………...…31 Tabla 50 Requisitos de usabilidad 02 “Manual de usuario”……………………………………..…..31 Tabla 51 Requisitos de usabilidad 03 “Indicaciones de uso”……………………………………..…31 Tabla 52 Requisitos de usabilidad 04 “Fichero de preguntas”……………...………………………..32 Tabla 53 Requisito de Mantenibilidad 01 “Reutilización”………………………………..…………32 Tabla 54 Requisito de portabilidad 01 “Base de datos”……………………………………...………32 Tabla 55 Requisito de portabilidad 02 “Servidor”……………………………………..……………33 Tabla 56 Requisito de seguridad 01 “Control de acceso”……………………………………...…….33 Tabla 57 Requisito de seguridad 02 “Cambio de contraseña”…………………………..…………..33 Tabla 58 Requisito de seguridad 03 “Codificación de contraseña”………………………….……...33 Tabla 59 Requisito de seguridad 04 “Control de sesión”………………………………………..…..34 Tabla 60 Requisito de seguridad 05 “Control de acceso a partida”……………………..…………...34 Tabla 61 Requisito de seguridad 06 “Carga de ficheros de juegos”………………………………....34 Tabla 62 Requisito de seguridad 07 “Filtros”……………………………………………………......34 Tabla 63 Restricción Técnica 01 “Sistema operativo”…………………………………...………….35 Tabla 64 Restricción Técnica 02 “Java Runtime Environment 8”…………………………..………35 Tabla 65 Restricción Técnica 03 “SQLite”…………………………………..……………………..36 Tabla 66 Restricción Técnica 04 “Servidor Tomcat 8.5”………………………………… ………..36 Tabla 67 Restricción Técnica 05 “LMS”…………………………………………… ……………..36 Tabla 68 Restricción Ténica 06 “Conexión TCP”…………………………………..………………36 Tabla 69 fichero config.properties…………………………………..……………………………....59 Tabla 70 Descriptor de despliegue…………………………….…………..………………………...60 Tabla 71 Ejemplo de fichero properties del juego test…………………….…….…………………..76 ÍNDICE DE FIGURAS Figura 1 LMS más populares………………………………….......................................................6 Figura 2 Acceso a herramienta LTI desde enlace .........................................................................10 Figura 3 UML de inicio de sesión.................................................................................................12 Figura 4 UML de creación de partidas..........................................................................................13 Figura 5 UML de fin de partida y envío de calificaciones............................................................13 Figura 6 Principales usos del superusuario....................................................................................25 Figura 7 Principales usos del usuario profesor .............................................................................26 Figura 8 Rol del alumno en herramienta LTI ...............................................................................26 Figura 9 Estructura general del sistema ........................................................................................38 Figura 10 Estructura de base de datos...........................................................................................39 Figura 11 Comunicación entre herramienta LTI y juegos.............................................................42 Figura 12 Estructura de directorios de la aplicación.....................................................................37 Figura 13 Mapa Web de superusuario...........................................................................................44 Figura 14 Mapa Web de usuario profesor.....................................................................................45 Figura 15 Mapa Web de usuario alumno......................................................................................45 Figura 16 Librerías usadas en el proyecto.....................................................................................48 Figura 17 Menú de creación de un usuario....................................................................................50 Figura 18 Listado de los usuarios existentes en la aplicación.......................................................51 Figura 19 Formulario de creación de partidas...............................................................................52 Figura 20 Menú de Información de una partida............................................................................53 Figura 21 Menú de navegación de la aplicación...........................................................................53 Figura 22 Menú para cambiar contraseña......................................................................................54 Figura 23 Menú de gestión de juegos............................................................................................55 Figura 24 Menú principal de la aplicación....................................................................................55 Figura 25 Menú de partidas….......................................................................................................56 Figura 26 Menú del modo Test .....................................................................................................56 Figura 27 Menú de subida de juegos.............................................................................................57 Figura 28 Menú de inicio de sesión a la aplicación.......................................................................57 Figura 29 Credenciales de inicio de sesión inválidas....................................................................58 Figura 30 Interfaz de juego tipo test..............................................................................................58 Figura 31 Mensaje indicando que se han sobrepasado el límite de intentos.................................59 Figura 32 Mensaje indicando que la partida no está disponible en este momento........................59 Figura 33 Gráfico esquemático de la prueba realizada..................................................................66 Figura 34 Fases del proyecto y duración.......................................................................................69 Figura 35 Gráfico de la duración y relaciones entre tareas...........................................................69 Figura 36 Servidores disponibles y estado....................................................................................74 Figura 37 Menú principal con rol de profesor...............................................................................75 Figura 38 Inicio de sesión de superusuario....................................................................................76 Figura 39 Creación de usuario profesor.........................................................................................77 Figura 40 Lista de usuarios............................................................................................................77 Figura 41 Menú de subida de un juego..........................................................................................78 Figura 42 Éxito en la subida..........................................................................................................79 Figura 43 Formulario de creación de una partida..........................................................................80 Figura 44 Lista de partidas............................................................................................................81 Figura 45 Menú de partidas tras pulsar “BORRAR” ....................................................................82 Figura 46 Partida Eliminada .........................................................................................................83 Figura 48 Juego deshabilitado……………...................................................................................84 Figura 49 Eliminación de juego ...................................................................................................85 Figura 50 Juego eliminado ...........................................................................................................86 Figura 51 Eliminación de un usuario.............................................................................................87 Figura 52 Usuario eliminado.........................................................................................................87 Figura 53 Calificaciones antes de finalizar partida…....................................................................88 Figura 54 Calificaciones tras terminar la partida...........................................................................88 Figura 55 Configuración de enlace web en CourseSites...............................................................90 Figura 56 Configuración de Moodle para crear enlace LTI..........................................................90 Figura 57 Partida no disponible por fecha.....................................................................................91 Figura 58 Partida no disponible por sobrepasar el número de intentos.........................................91 Figura 59 Interfaz de juego “Test”................................................................................................91 1 1 INTRODUCCIÓN as nuevas tecnologías han cambiado la visión que tenía el ser humano del mundo. Han permitido fenómenos como la globalización e impulsado multitud de áreas del conocimiento como la ingeniería, la medicina, la arquitectura, la agricultura y por supuesto la educación. Pilar de todas las ciencias. 1.1 Motivación Para que pueda llevarse a cabo el proceso formativo de una persona es fundamental que ésta se encuentre motivada y muestre interés por el área en el que se esté formando. Pero a pesar de ser el principal requisito no es el único. La falta de recursos o la excesiva carga de trabajo de los profesores al contar con un número muy elevado de alumnos pueden dificultar mucho esta tarea. Con este proyecto se pretende facilitar la labor docente mediante el uso de la gamificación. 1.2 Gamificación La gamificación o ludificación es una técnica basada en el uso de juegos y dinámicas relacionadas con el ocio en situaciones no recreativas. Busca incrementar el desarrollo de competencias y habilidades fomentando la motivación y el interés de una persona o grupo de personas por un área determinada. En el caso del proyecto que nos ocupa en el ámbito educativo. Los juegos utilizados pueden basarse en multitud de mecánicas que hagan del proceso de aprendizaje algo más atractivo. Algunas de éstas mecánicas podrían ser la obtención de premios para los alumnos con mayor puntuación, proponer desafíos que al superarse aporten cierto grado de satisfacción personal, apelar al espíritu competitivo del alumnado mediante rankings… Varias de las aplicaciones usadas en la actualidad y que ejemplifican el uso de la gamificación en el aula sería Kahoot [1], Plickers [2] o Quizizz [3]. Para más información visitar [4]. Para poder hacer uso de estas herramientas es necesario que tanto el profesor como los alumnos se registren en una web y que todo el proceso de evaluación se desarrolle en la misma. Este sistema puede llegar a ser muy ineficiente o limitar mucho al profesor si éste requiere del uso de juegos que se encuentren desperdigados entre las diferentes alternativas existentes. La funcionalidad extra que nosotros aportamos a la hora de realizar este proyecto frente a las herramientas de gamificación ya existentes, es el poder integrar los juegos en un gran número de plataformas de enseñanza virtual, haciendo posible que todo esté centralizado e integrado en un solo lugar. L “El futuro de la educación estará profundamente signado por la tecnologia de la información venidera. Pero más aún, por cómo los educadores y estudiantes utilizan las TIC para el aprendizaje continuo” - Stanley Williams – Future of Education: Technology + Teachers- Estado del arte 8 8 modelos mediante herramienta y UML. Servicios REST Sí Sí Servicios REST de nivel 3 para gran variedad de tareas servidor a servidor. En LTI 1.2 sólo se permiten servicios REST implementados en el TC. Tabla 1 Características de diferentes versiones LTI Hay que destacar que desde la versión de LTI 1.1 es posible asignar una calificación desde el TP al cuaderno de calificaciones del TC. Característica importante que se utilizará en el proyecto para evaluar a los alumnos que participen en las partidas creadas por los profesores. En el trabajo realizado anteriormente por mi compañera Lourdes [6] se hace uso de esta característica. La comunicación estaba implementada por la librería “oscelot”. Esta librería fue modificada con el fin de corregir algunos errores por Francisco José Fernández Jiménez y es la usada en este proyecto. La especificación utilizada en este proyecto -LTI Basic Outcomes Service [22]- se basa en el envío de mensaje POX (Plain Old Xml) firmados con el estándar OAuth [23] [24]. Básicamente con el uso de esta especificación nos es posible realizar operaciones de lectura, escritura y borrado del cuaderno de calificaciones. El acceso al mismo será posible gracias a la combinación de los parámetros usuario/recurso, que en el estándar reciben el nombre de user_id y resource_link_id. De esta forma, conociendo el identificador del usuario y el del recurso asignado a dicho usuario, podemos acceder a la fila y columna del cuaderno de calificaciones del TC y realizar cualquiera de las operaciones descritas anteriormente. Cabe destacar en este punto que el estándar nos obliga a la hora de escribir una nota en el cuaderno de calificaciones del TC que ésta se encuentre comprendida entre 0.0 y 1.0. Cualquier otro número que no esté comprendido entre ellos nos reportará un mensaje de operación fallida. En la Tabla 2, se presenta un ejemplo del mensaje que habría que enviarle al TC para escribir una nota en el cuaderno de calificaciones. <?xml version = "1.0" encoding = "UTF-8"?> <imsx_POXEnvelopeRequest xmlns = "http://www.imsglobal.org/services/ltiv1p1/xsd/imsoms_v1p0"> <imsx_POXHeader> <imsx_POXRequestHeaderInfo> <imsx_version>V1.0</imsx_version> <imsx_messageIdentifier>1313355158804</imsx_messageIdentifier> </imsx_POXRequestHeaderInfo> </imsx_POXHeader> <imsx_POXBody> <replaceResultRequest> <resultRecord> 9 Estado del arte 9 Tabla 2 Envío de mensaje al TC para escribir una nota en el cuaderno de calificaciones [25] 2.1.2.2 Arquitectura LTI Antes de establecer la estructura de comunicación básica de LTI (versión 1.0) es necesario que el administrador del TC configure las credenciales de dominio para un TP particular. Estas credenciales se aplican a los enlaces LTI creados directamente en el sistema TC. Por otra parte, el administrador TP crea la combinación clave y secreto para el TC (donde el administrador de TC puede solicitar una clave particular, a menudo el nombre de dominio TC), el par clave/secreto debe ser conocido por ambos y son usados para firmar el contenido de los paquetes con OAuth. Una vez realizado lo anterior el proceso a seguir sería el siguiente: 1. Un usuario pincha en un enlace LTI alojado en el TC lo que desencadena la ejecución de la herramienta. 2. El TC establece una serie de parámetros de lanzamientos (parámetros estándar, opcionales y personalizados) que serán parte del mensaje de lanzamiento. 3. Se firma el contenido con OAuth para asegurar su integridad. 4. El TC envía el mensaje al navegador y un fragmento de código JavaScript se encarga de autoenvíar el mensaje al TP. 5. El TP responde con una representación de la herramienta en el navegador. Este proceso podría resumirse en el diagrama mostrado en la Figura 2. <sourcedGUID> <sourcedId>3124567</sourcedId> </sourcedGUID> <result> <resultScore> <language>en</language> <textString>0.91</textString> </resultScore> </result> </resultRecord> </replaceResultRequest> </imsx_POXBody> </imsx_POXEnvelopeRequest> Estado del arte 10 10 Figura 2 Acceso a herramienta LTI desde enlace. En nuestro caso usamos LTI 1.1. El funcionamiento es el mismo que el descrito para LTI 1.0 pero añadiendo dos parámetros adicionales en el lanzamiento:  lis_outcome_service_url: URL donde está escuchando el servicio del TC que permite la modificación de notas.  lis_result_sourceid: valor que indica la fila y columna del cuaderno de calificaciones del TC donde se insertará, eliminará o editará una nota. El mensaje devuelto por el TP es completamente asíncrono por lo que pueden pasar horas, días, o incluso semanas hasta que se envía la calificación al TP. Esta característica es usada en nuestro proyecto para establecer una hora de cierre de la actividad, en el momento en el que dicha actividad concluye, las notas son enviadas al TC y pueden ser consultadas por los alumnos. 2.1.2.3 Librerías y Ejemplos LTI Desde la propia página de IMS se aporta documentación para el uso del estándar LTI en sus distintas versiones [26]. En el caso de nuestra aplicación para el intercambio de mensajes entre el TC y el TP estamos usando el código del autor Stephen Vickers [27], está programado en java (como la mayoría de nuestro proyecto) soporta las versiones de LTI 1.x y proporciona un código de ejemplo usando el servicio Outcome. 2.1.2.4 Implementación En capítulos posteriores se describirá el proceso de implementación de nuestra herramienta en los LMS en los que se han realizado las pruebas CourseSites y Moodle ambas propiedad de BlackBoard. Navegador •Contiene enlace LTI TC •Preparación de parámetros •Firma OAuth Navegador •Ejecuta código JavaScript TP •Envía representación de la herramienta Navegador •Representa la herramienta click POST POST 11 Estado del arte 11 2.1.3 Herramienta LTI usada en nuestro proyecto El proceso que acabamos de describir es el que nos permite la implementación de los juegos en las plataformas de enseñanza. En el siguiente capítulo hablaremos sobre el diseño de nuestra aplicación -que recordemostiene como objetivo la creación de partidas configurables, con la capacidad de autocorregirse y subir las notas automáticamente al cuaderno de calificaciones del LMS. Diseño 12 12 3 DISEÑO En este apartado se profundizará en el software a implementar y se detallarán los objetivos y funcionalidades del mismo. 3.1 Introducción El objetivo a la hora de diseñar la aplicación es que los profesores puedan autentificarse en la herramienta desde cualquier lugar (ver Figura 3) y crear una partida. Figura 3 UML de inicio de sesión Las partidas podrán ser accedida por los alumnos que el profesor desee y en la fecha fijada por el mismo. Una vez creada la partida (ver Figura 4) el profesor habilitará un enlace LTI en el LMS en el que desarrolle su actividad docente 1 . 1 Más adelante se detallará como crear enlaces LTI en los LMS en los que se han realizado las pruebas. 13 Diseño 13 Figura 4 UML de creación de partidas Los alumnos podrán acceder a la partida en la fecha establecida por el profesor. Cuando la partida concluya (la partida puede estar activa desde minutos hasta días y finalizará cuando expire el temporizador, o antes si el profesor decide darla por finalizada manualmente) las notas de los alumnos serán enviadas al cuaderno de calificaciones del TC (ver Figura 5). Figura 5 UML de fin de partida y envío de calificaciones Diseño 14 14 3.2 Análisis de requisitos y especificaciones En este apartado vamos a realizar un análisis pormenorizado de los requisitos que debe cumplir nuestra aplicación. El formato es el descrito a continuación: IDENTIFICADOR Nombre del requisito Dependencias Descripción Importancia Prioridad Tabla 3 caracterización de los requisitos del Sistema  Dependencias: Nombre de el/los requisitos que son necesarios para la implementación de este requisito o que están íntimamente relacionados.  Descripción: Explicación breve del objetivo a alcanzar con ese requisito.  Importancia: Indica el grado de relevancia que tiene el requisito para el cliente.  Prioridad: Indica el grado de relevancia que tiene el requisite para el desarrollador. Los requisitos de importancia y prioridad atenderán a tres posibles valores o grados:  Alta: Fundamental para el proyecto.  Media: sólo se puede omitir en ocasiones donde suponga la eliminación de otro requisito de más importancia/prioridad.  Baja: Se sugiere pero no es imprescindible. 3.2.1 Requisitos generales RG-01 Sistema de creación y gestión de herramientras LTI Dependencias RT-05 Descripción Será necesaria la existencia de un sistema que nos permita insertar, editar o eliminar herramientas LTI. Importancia Alta Prioridad Alta Tabla 4 Requisito general 01 “Sistema de creación y gestión de herramientras LTI” 15 Diseño 15 RG-02 Inicio de sesión Dependencias RG-03, RCU-01 Descripción Para poder acceder a la aplicación web tendremos que identificarnos con un nombre de usuario y contraseña. Importancia Alta Prioridad Alta Tabla 5 Requisito general 02 “Inicio de sesión” RG-03 Existencia de superusuario Dependencias RG-02 Descripción Existirá desde el momento de inicio de la aplicación un super usuario encargado de la gestión del resto de usuarios (salvo el superusuario el resto tendrán rol de profesor). Importancia Alta Prioridad Alta Tabla 6 Requisito general 03 “Existencia de superusuario” RG-04 Creación de credenciales LTI Dependencias RG-10 Descripción Deben existir los campos utilizados para la correcta comunicación entre la herramienta LTI y el LMS, el par clave/secreto serán necesarios para la creación de una partida además de otros campos relacionados con ésta. Importancia Alta Prioridad Alta Tabla 7 Requisito general 04 “Creación de credenciales LTI” RG-05 Juego Dependencias RG-10 Diseño 16 16 Descripción Toda partida debe tener un juego, dicho juego se elegirá en el momento de creación de la partida, cada juego cuenta con una serie de parámetros, algunos opcionales modificables y otros fijos. El juego en cuestión determinará en gran medida las características de la partida. Importancia Alta Prioridad Alta Tabla 8 Requisito general 05 “Juego” RG-06 Calificar usuario Dependencias RG-07 Descripción La herramienta LTI debe ser capaz de asignar una puntuación a un alumno y escribirlo en el cuaderno de calificaciones del TC. Importancia Alta Prioridad Alta Tabla 9 Requisito general 06 “Calificar usuario” RG-07 Versión LTI 1.1 Dependencias RG-06 Descripción La herramienta LTI debe integrar la version 1.1 ya que es la responsable del envío de calificaciones entre la herramienta y el LMS. Importancia Alta Prioridad Alta Tabla 10 Requisito general 07 “Versión LTI 1.1” RG-08 Mensajes informativos Dependencias RUS-03 Descripción La aplicación debe notificar al usuario en la medida de lo posible el resultado de las operaciones, tanto las que se realizan con éxito como las que provocan error. 17 Diseño 17 Importancia Media Prioridad Media Tabla 11 Requisito general 08 “Mensajes informativos” RG-09 Arranque de la aplicación Dependencias RFIA-05 Descripción Cuando el servidor arranca debe comprobarse si existen en la base de datos las tablas necesarias para el correcto funcionamiento de la aplicación, si no existen se crean, también debe comprobarse si existe alguna partida en marcha y reiniciar los temporizadores o proceder a la subida de notas si es necesario. Importancia Alta Prioridad Alta Tabla 12 Requisito general 09 “Arranque de la aplicación” RG-10 Configuración de partidas Dependencias RG-04, RG-05, RG-07 Descripción Los parámetros que tengan las partidas deberán ser:  Nombre de la partida  Selección de juego  Fichero de preguntas  Clave de entrega  Clave  Parámetros fijos  Parámetros variables  Secreto  Nº de Repeticiones  Habilitar  Envío de calificación  Fecha de inicio Diseño 24 24 RCU-20 Modo Test Dependencias RN-01 Descripción El profesor dispondrá de un modo test que le permitirá comprobar que la partida funciona correctamente antes de habilitarla en el LMS y de que los alumnos puedan acceder a ellas. Importancia Media Prioridad Media Tabla 34 Caso de uso 20 “Modo Test” RCU-21 Borrar partida Dependencias RN-01, RN-02 Descripción El profesor podrá eliminar las partidas creadas por él mismo. Importancia Media Prioridad Media Tabla 35 Caso de uso 21 “Borrar partida” RCU-22 Terminar partida Dependencias RN-01, RN-02 Descripción El profesor podrá dar por finalizada una partida en cualquier momento pulsando un botón. Importancia Baja Prioridad Baja Tabla 36 Caso de uso 22 “Terminar partida” RCU-23 Acceso a herramienta LTI desde LMS Dependencias RCU-13 Descripción Tanto el profesor como el alumno deben poder acceder a las 25 Diseño 25 partidas mediante un enlace LTI desde el LMS. Importancia Alta Prioridad Alta Tabla 37 Caso de uso 23 “Acceso a herramienta LTI desde LMS” El esquema de casos de uso serían los observados en las Figuras 6, 7 y 8. Figura 6 Principales usos del superusuario Superusuario Crear usuarios Cambiar contraseña Administrar juegos Subir juegos Eliminar juegos Habilitar/Desh abilitar Juegos Cerrar sesión Ver partidas Diseño 26 26 Figura 7 Principales usos del usuario profesor Figura 8 Rol del alumno en herramienta LTI 3.2.2.2 Reglas de negocio RN-01 Roles de usuarios Dependencias RN-02, RG-03 Descripción Existirán dos tipos de usuarios, el usuario superusuario y el usuario profesor las acciones que pueden llevar a cabo varían dependiendo del tipo de usuario y vienen descritas en las Figuras 6 y 7 Importancia Alta Prioridad Media Tabla 38 Regla de negocio 01 “Roles de usuarios” Profesor Subir juegos Cambiar contraseña Partidas Crear partida Editar partida Eliminar partida Información de la partida Terminar partida Modo test Cerrar sesión Alumno Accede a partida desde LMS Realiza el Juego Obtiene una calificación Fin de la partida Calificación en el TC 27 Diseño 27 RN-02 Profesores creadores de partidas Dependencias RCU-17, RCU-20, RCU-21, RCU-22 Descripción Sólo el profesor creador de una partida puede realizar modificaciones sobre ésta. Importancia Media Prioridad Media Tabla 39 Regla de negocio 02 “Profesores creadores de partida” 3.2.2.3 Requisitos de conducta RC-01 Creación de tablas para comunicación LTI Dependencias RI-02 Descripción Serán necesarias la creación de tablas en la base de datos que almacenen la información necesaria para la correcta comunicación entre el TC y el TP. Importancia Alta Prioridad Alta Tabla 40 Requisitos de conducta 01 “Creación de tablas para comunicación LTI” 3.2.2.4 Requisitos de información RI-01 Almacenamiento de usuarios y partidas Dependencias RG-10, RI-02 Descripción  La información relativa a los usuarios almacenada en la base de datos es:  Nombre de usuario  Contraseña  Zona horaria  Tipo  En cuanto a la usada para la creación de una partida es: Diseño 28 28  Nombre de la partida  Nombre del juego  Clave de la partida  Fecha de inicio  Fecha de fin  Key  Secreto  Parámetros fijos  Parámetros opcionales  Fichero de preguntas  Habilitación  Subir nota  Número de repeticiones  Estado de la partida  Contador Importancia Alta Prioridad Alta Tabla 41 Requisitos de información 01 “Almacenamiento de usuarios y partidas” RI-02 Parámetros de configuración de LTI Dependencias RI-01, RC-01 Descripción Será necesario almacenar en la base de datos la información de configuración de cada herramienta LTI. Importancia Alta Prioridad Alta Tabla 42 Requisitos de información 02 “Parámetros de configuración de LTI” 29 Diseño 29 RI-03 Fichero de configuración Dependencias RP-02 Descripción Se utilizará un fichero de configuración llamado “config.properties” que almacenará la configuración inicial de la aplicación. En dicho fichero existirán los siguientes campos:  Base de datos (con nombre, usuario y contraseña)  Descritor de despliegue  Nombre de la aplicación (debe coincidir con el nombre del directorio que la contiene)  Directorio donde se alojarán los juegos en el servidor  Directorio temporal donde se almacenará el juego comprimido Importancia - Prioridad Alta Tabla 43 Requisitos de información 03 “Fichero de configuración” 3.2.3 Requisitos no funcionales 3.2.3.1 Fiabilidad RFIA-01 Error durante creación, edición y eliminación de una partida o juego Dependencias RG-08 Descripción En la medida de lo posible se procurará que cuando haya un error de algún tipo se vuelva al estado previo antes del error. Importancia Alta Prioridad Alta Tabla 44 Requisitos de fiabilidad 01 “Error durante creación, edición y eliminación de una partida o juego” RFIA-02 Verificación de campos Dependencias RG-10 Diseño 30 30 Descripción Se obligará al usuario a rellenar los campos considerados como imprescindibles tanto a la hora de crear una partida como a la hora de subir un juego. Importancia Media Prioridad Media Tabla 45 Requisitos de fiabilidad 02 “Verificación de campos” RFIA-03 Nombre de partidas y/o juegos Dependencias RG-08 Descripción Se impedirá la creación de partidas si ya existe una con el mismo nombre, del mismo modo tampoco se podrá subir un juego si ya existe en el servidor. Importancia Alta Prioridad Alta Tabla 46 Requisitos de fiabilidad 03 “Nombre de partidas y/o juegos” RFIA-04 Selección correcta de fecha y hora Dependencias RG-10 Descripción El sistema se asegurará de que la fecha y hora establecidos sean correctos, no permitirá fechas de inicio posteriores a las de cierre ni establecer una fecha de inicio anterior al momento actual. Todo ello se hará teniendo en cuenta la zona horaria del usuario que configura la partida. Importancia Baja Prioridad Baja Tabla 47 Requisitos de fiabilidad 04 “Selección correcta de fecha y hora” RFIA-05 Reinicio de partidas por recarga de contexto Dependencias RG-09 Descripción Si el servidor cae o se produce una recarga en el contexto la 31 Diseño 31 aplicación se encargará de reiniciar las partidas que estuvieran en curso y de subir las notas de las partidas que hubieran finalizado durante la caída del servidor. Importancia Media Prioridad Baja Tabla 48 Requisitos de fiabilidad 05 “Reinicio de partidas por recarga de contexto” 3.2.3.2 Usabilidad RUS-01 Manual de instalación Dependencias - Descripción Se proprocionará un manual de instalación junto con la aplicación. Importancia Alta Prioridad Media Tabla 49 Requisitos de usabilidad 01 “Manual de instalación” RUS-02 Manual de usuario Dependencias - Descripción Se proporcionará un manual de usuario junto con la aplicación. Importancia Alta Prioridad Media Tabla 50 Requisitos de usabilidad 02 “Manual de usuario” RUS-03 Indicaciones de uso Dependencias RG-08 Descripción Se proporcionará información al usuario durante la creación, eliminación o edición de una partida, también se darán pautas a la hora de administrar juegos. Diseño 32 32 Importancia Media Prioridad Baja Tabla 51 Requisitos de usabilidad 03 “Indicaciones de uso” RUS-04 Fichero de preguntas Dependencias RG-10 Descripción El usuario deberá de subir un fichero con las preguntas que serán cargadas por el juego. Importancia Alta Prioridad Media Tabla 52 Requisitos de usabilidad 04 “Fichero de preguntas” 3.2.3.3 Mantenibilidad RM-01 Reutilización Dependencias - Descripción Las partidas deberán poder editarse para realizarse las veces que se quieran cambiando cualquiera de los parámetros disponibles. Antes de reutilizar una partida ya creada es conveniente eliminar las calificaciones vinculadas a esa partida antes de su reutilización. Importancia Media Prioridad Media Tabla 53 Requisito de Mantenibilidad 01 “Reutilización” 3.2.3.4 Portabilidad RP-01 Base de datos Dependencias RI-02, RT-03 Descripción El sistema debe poder soportar MySQL y SQLite.. 33 Diseño 33 Importancia Baja Prioridad Baja Tabla 54 Requisito de Portabilidad 01 “Base de datos” RP-02 Servidor Dependencias RI-03 Descripción Debe poder cambiarse el descriptor de despliegue, de usuario y la ruta donde se almacenarán los juegos. Importancia Alta Prioridad Alta Tabla 55 Requisito de Portabilidad 02 “Servidor” 3.2.3.5 Seguridad RS-01 Control de acceso Dependencias RS-03 Descripción Se entrará a la aplicación mediante una combinación de nombre de usuario y contraseña. Importancia Alta Prioridad Alta Tabla 56 Requisito de Seguridad 01 “Control de acceso” RS-02 Cambio de contraseña Dependencias - Descripción Todos los usuarios pueden cambiar su contraseña. Importancia Alta Prioridad Alta Tabla 57 Requisito de Seguridad 02 “Cambio de contraseña” RS-03 Codificiación de contraseña Diseño 40 40 Todas las tablas de la Figura 10 cuyos nombres comiencen por “lti” (lti_user, lti_context…) contienen información relativa a la comunicación entre nuestro TP y el TC en el que se implementa nuestra herramienta. Los parámetros más importantes para que dicha comunicación pueda llevarse a cabo son:  consumer_key: tras la creación de una partida este parámetro estará formado por los campos “Nombre de la partida” + “_” + “Clave”. Deberá coincidir con el campo “Tecla” 3 de nuestro TC.  lti_resource_id: identificador de la partida en el TC.  user_id: identificador del usuario en el TC.  secret: parámetro configurable del TC que debe coincidir con el campo “secret” de nuestra partida. Los parámetros más importantes de nuestra aplicación web se hallan en la tabla “partidas” de la Figura 10 y son los siguientes:  partidaname: nombre de la partida.  gamename: nombre del juego.  deliveryPassword: clave de acceso a la partida.  fecha_inicio: fecha de inicio de la partida.  fecha_fin: fecha de fin de la partida.  key: clave para comunicación con el TC.  secret: secreto para comunicación con el TC.  fijos: parámetros fijos del juego. No modificables desde el menú de configuración de las partidas.  opcionales: parámetros variables del juego configurados por el creador de la partida.  preguntas: preguntas que usará el juego para la evaluación de los alumnos.  enable: booleano que vale uno cuando la herramienta LTI está habilitada  outcome: booleano que vale uno cuando el envío de calificaciones está habilitado  repeat: número de intentos que tiene un alumno para repetir una partida.  status: informa sobre el estado de la partida (activa o finalizada). Usado en la reactivación de los temporizadores en caso de recarga de contexto o caída del servidor.  count: contador utilizado para saber la última vez que una partida ha sido modificada y desactivar el anterior Timer para activar uno nuevo. 4 Los usuarios registrados en la aplicación se encuentran en la tabla “users” de la Figura 10 y sus 3 Aunque realmente recibe este nombre en el TC, lo más probable es que se trate de un error de traducción. 4 Es importante recordar que cada vez que una partida es editada el temporizador que controla la duración de la misma es reactivado con las nuevas fechas. 41 Diseño 41 campos son los siguientes:  username: nombre del usuario en la aplicación.  pass: contraseña de acceso a la aplicación.  timeZone: zona horaria del usuario.  type: tipo de usuario (profesor o superusuario). La relación entre las partidas y los usuarios creadores de las mismas se almacenan en la tabla “partidas_users” de la Figura 10. Los juegos subidos a la aplicación web se encuentran en la tabla “games” de la Figura 10. Sus campos son:  fijos: parámetros fijos del juego. No modificables desde el menú de configuración de las partidas.  opcionales: parámetros variables del juego configurados por el creador de la partida.  id: identificador del juego.  enable: uno cuando el juego está habilitado, cero en caso contrario. 3.3.2 Comunicación entre los juegos y la aplicación web Como ya se ha mencionado cada partida debe tener un juego. También hemos explicado anteriormente que los juegos deben subirse al servidor en formato zip y que dicho zip debe contener dos archivos:  Archivo HTML “jugar”: contendrá el juego en cuestión. Siempre deberá llamarse “jugar”.  Archivo de texto “properties”: contendrá las propiedades o parámetros de configuración del juego en cuestión (número de preguntas, orden de éstas…). Siempre deberá llamarse “properties”. En el esquema del sistema de la Figura 9 puede observarse que el juego es un iframe insertado en una página JSP. La comunicación entre el juego y la herramienta LTI que lo implementa puede observarse en la Figura 11 y comprende las siguientes etapas: 1. Si el usuario tiene acceso al juego se inicia la carga del mismo. Cuando esté totalmente cargado se lo hará saber a nuestra herramienta. 2. Una vez la herramienta recibe que el juego se ha cargado, manda los parámetros de configuración 5 establecidos por el profesor durante la creación/edición de la partida. Estos parámetros se obtienen de la base de datos. 3. El juego procesa la información suministrada por la herramienta y se configura en consecuencia. Una vez configurado, se autoenvía a nuestra herramienta LTI y el alumno podrá comenzar a jugar. 5 Los parámetros de configuración variarán en función del juego seleccionado Diseño 42 42 4. Cuando el juego finaliza se manda un mensaje a la herramienta de “fin de juego”. Además de indicarnos el final de la partida este mensaje nos dice cual es la máxima puntuación alcanzable y los errores y aciertos que ha tenido el alumno. Esta información es pasada a un Servlet encargado de calcular la puntuación obtenida 6 por el alumno y almacenarla en la base de datos. Figura 11 Comunicación entre herramienta LTI y juegos 6 Para el cálculo de las notas se hace una ponderación sobre diez. 43 Implementación 43 4 IMPLEMENTACIÓN n el apartado anterior se ha descrito de forma resumida el funcionamiento básico de la aplicación. el objetivo de este capítulo es explicar cómo es esto posible. Para ello se mostrará la organización del software y se analizará de forma breve y concisa las partes más importantes del mismo, por último, se mostrará la interfaz de usuario que presenta la aplicación. 4.1 Código Figura 12 Estructura de directorios de la aplicación Siguiendo la estructura de ficheros del proyecto podemos clasificar el código en:  Documentación  Clases E Implementación 44 44  Librerías  Ficheros JavaScript  Ficheros JSP  Ficheros HTML y CSS  Base de datos  Fichero de configuración  Descriptor de despliegue  Juegos Con el objetivo de simplificar la descripción de nuestra aplicación web diseñaremos un mapa de navegación donde se muestran todas las páginas/servlets con enlaces al resto de páginas/servlets que son accesibles desde cada una de ellas. El mapa variará en función del rol del usuario, así si es superusuario, el mapa será el de la Figura 13. Si por el contrario el usuario es de tipo profesor el mapa será el de la Figura 14. Por último, el acceso por parte de un alumno desde el TC se muestra en el mapa de la Figura 15. Figura 13 Mapa Web de superusuario cabecera.jsp - menu.jsp partidas.jsp usuarios.jsp adduser.jsp AddUserServlet.java DeleteUserServlet.java changepass.jsp ChangePasswordServlet.j ava juegos.jsp uploadgame.jsp UploadServlet.java SelectGameServlet login.jsp LoginServlet.java relogin.jsp cabecera.jsp - menu.jsp 45 Implementación 45 Figura 14 Mapa Web de usuario profesor Figura 15 Mapa Web de usuario alumno cabecera.jsp - menu.jsp partidas.jsp crearpartida.jsp EditProjectServlet.j ava partidas.jsp infoproject.jsp DeleteProjectServle t.java editpartida.jsp EditProjectServlet.j ava partidas.jsp testpartida.jsp TestStudent.jsp DeleteNotas.java changepass.jsp ChangePasswordSe rvlet.java juegos.jsp uploadgame.jsp UploadServlet.java login.jsp LoginServlet.java relogin.jsp cabecera.jsp-menu.jsp Launch.java pass.jsp passServlet.java Student.jsp Student.jsp ErrorApp.jsp NotaServlet.java Implementación 46 46 4.1.1 Documentación En el CD/DVD propocionado junto a la memoria se incluye un directorio de nombre “doc” que incluye la documentación del proyecto realizado. En ella se describe brevemente cada uno de los métodos y clases utilizados. 4.1.2 Clases En este apartado se comentarán las clases más relevantes para el funcionamiento de la aplicación, dichas clases se encuentran contenidas en el paquete es.us.dit.lti. Las clases de los paquetes org.oscelot.lti.x.x también son imprescindibles para el funcionamiento de la misma pero pueden ser consultadas desde la API [28], aunque como ya se dijo anteriormente esta librería fue modificada por Francisco José Fernández Jiménez para corregir algunos errores. Puede obtenerse más información de cada una de las clases existentes en la documentación proporcionada. AppLoader Clase que se ejecuta con el arranque de la aplicación en el servidor, creará las tablas necesarias en la base de datos si no existen. Esta clase se usa en el arranque para verificar y establecer los parámetros de inicios necesarios para el correcto funcionamiento de la aplicación. Si el servidor se cae o se produce una recarga del contexto esta clase comprobará el estado de las partidas. Si la partida aún no ha finalizado reactivará el temporizador asociado a dicha partida (llamada a clase Mytimer, descrita más adelante). Si la partida finalizó cuando el servidor estaba caído procederá al envío inmediato de las calificaciones almacenadas en la base de datos al TC. DAO Clase utilizada en cualquiera de los accesos a la base de datos por parte de la aplicación. Entre los métodos más relevantes de los que dispone se encuentran los de gestión y administración de usuarios, partidas y juegos. Db Se encuentran los métodos necesarios para la creación e inicialización de la base de datos, así como los que permiten su conexión con ésta. LoginServlet Servlet utilizado a la hora de iniciar sesión en la aplicación. EditProjectServlet Usado en la creación/edición de partidas. Cada vez que una partida es creada o editada este servlet además de almacenar la nueva información en la base de datos mediante el uso de métodos de la clase DAO, inicia un temporizador, cuando este expira se dará por concluida la partida. MyTimer Es la clase encargada de gestionar la duración de una partida, cuando ésta finaliza se ejecutará un 47 Implementación 47 algoritmo que determinará las calificaciones de qué partida y de qué alumnos han de ser subidas al cuaderno de calificaciones del TC. ProjectBean, UserBean y Games Estas tres clases clases contienen la siguiente información:  ProjectBean: Contiene todas las variables y métodos relativos a una partida.  UserBean: Contiene todas las variables y métodos relativos al usuario.  Games: Contiene todas las variables y métodos relativos a un juego. Filters Todas las clases que tengan el sufijo “Filter” son usadas para que en el momento de hacer una petición con la intención de acceder a una zona considerada como de acceso restringido –y con acceso restringido nos referimos a aquellas zonas no accesibles por cualquier usuariosea interceptada para verificar si el usuario tiene permisos para acceder al recurso solicitado. UploadServlet Se encarga de la subida y descompresión de los juegos al servidor, una vez el juego ha sido descomprimido y almacenado correctamente el archivo comprimido es eliminado. SelectGameServlet Se encarga de gestionar la habilitación de los juegos. Cuando el superusuario desea habilitar/deshabilitar uno o más juegos se llama a este servlet. NotaServlet Encargado de calcular la nota de los alumnos. Recibe como parámetro los puntos totales de una partida y los obtenidos por el alumno. Realiza una ponderación sobre diez y guarda la nota en la base de datos. Launch Cuando el usuario del LMS hace click en el enlace LTI esta clase es invocada mediante un método POST. Lo primero que hace es obtener los datos asociados al proyecto a partir de la clave que ha recibido. A continuación, se generan atributos de sesión asociados a cada uno de los datos que ha obtenido. De esta manera se podrá acceder a las propiedades de la herramienta desde cualquier parte en la aplicación sin necesidad de leer ficheros ni de acceder a la base de datos. Por último, se inicializan las tablas de los datos LTI -creándolas si no existeny se genera un objeto ToolConsumer al que se le asocian una serie de parámetros (clave, secreto, habilitación y nombre) un objeto ToolProvider con los parámetros necesarios y se llama al método execute() del objeto. Implementación 48 48 Test2ExternStaticFolder Los juegos y los ficheros que éste requiere para funcionar se encuentran en una parte del servidor no accesible mediante URL. Si el usuario tiene permiso para acceder a la partida esta clase envía los ficheros para que el juego pueda ejecutarse. De esta forma se impide que cualquier usuario pueda acceder a ellos poniendo una dirección URL en su navegador. 4.1.3 Librerías Las librerías utilizadas en este proyecto son: Figura 16 Librerías usadas en el proyecto commons-cli-1.2.jar Librería utilizada para el análisis de parámetros con los que el usuario inicia la aplicación. commons-codec-1.10.jar Contiene codificacores y decodificacors simples para varios formatos, como Base64 y Hexadecimal. commons-fileupload-1.3.3.jar Usado para cargar archivos a Servlets y aplicaciones web. 49 Implementación 49 commons-io-2.5.jar Entre algunas de sus aplicaciones se encuentran el filtrado y comparación de archivos, tranformación a endian y mucho más. commons-lang3-3.6.jar Usado en las clases de la jerarquía java.lang. commons-logging-1.2.jar Ofrece una interfaz común para crear registros logs. fluent-hc-4.5.3.jar APIs para interfaces HttpClient. gson-2.8.2.jar Permite la serialización y deserialización entre objetos Java y su representación en notación JSON. httpclient-4.5.3.jar Ofrece una API HTTP cliente simplificada para operaciones de tipo XMLHttpRequest usada por los navegadores. httpclient-cache-4.5.3.jar Proporciona una capa de almacenamiento en caché compatible con HTTP/1.1 para ser utilizada con HttpClient. httpclient-win-4.5.3.jar Funcionalidad específica de HttpClient para Windows. httpcore-4.4.8.jar Usado para crear servicios HTTP del lado del cliente y del servidor con un impacto mínimo. jdom-2.0.6.jar Usado para manipulaciones de datos XML optimizados para Java. jna-4.1.0.jar Proporciona un fácil acceso a las bibliotecas de Java nativas compartidas sin usar la interfaz nativa de Java. joda-time-2.9.9.jar Utilizada para la conversión de zona horaria. mysql-connector-java-5.1.40-bin.jar Utilizada para conectar con base de datos MySQL. oauth-20100527.jar Utilizada para firmar los paquetes que se envían desde el TP al TC. Aporta seguridad. servlet-api-3.1.jar Utilizada para la integración de los Servlets de nuestro proyecto. sqlite-jdbc-3.20.1.jar Utilizada para conectar con base de datos SQLite. Implementación 56 56 partidas Página que muestra un listado con todas las partidas que un usuario ha creado. En esta página además los profesores podrán elegir entre ver información de una partida, editarla, borrarla, finalizarla, eliminar las notas asociadas o probarlas mediante el modo test. Ver Figura 25. Figura 25 Menú de partidas testpartida Modo de pruebas solo accesible por profesores para comprobar que la partida funciona correctamente. En este modo el envío de calificaciones está deshabilitado. Ver Figura 26. Figura 26 Menú del modo Test 57 Implementación 57 uploadgame Página desde la que se suben los juegos. Todos los usuarios podrán subir juegos 7 , para ello deberán subirse en formato .zip y elegir un nombre con el que se almacenará en el servidor. Ver Figura 27. Figura 27 Menú de subida de juegos ErrorApp Página mostrada cuando hay algún error en la comunicación entre el TP y el TC. login Página usada para iniciar sesión en la aplicación. Ver Figura 28. Figura 28 Menú de inicio de sesión a la aplicación 7 Cuando un juego se sube al servidor éste estará habilitado por defecto. Implementación 58 58 logout Página usada para cerrar sesión. Pass Página en la que el alumno tendrá que introducir una clave para acceder a una partida, sólo se muestra si la partida requiere de una contraseña para poder acceder a ella. Relogin Página mostrada cuando las credenciales para iniciar sesión introducidas son inválidas. Ver Figura 29. Figura 29 Credenciales de inicio de sesión inválidas Student Página mostrada cuando un alumno accede a la herramienta LTI. Se compone de una página JSP en la que se inserta un iframe, dicho iframe será el juego. El juego será mostrado siempre y cuando el alumno que quiera acceder a él tenga los permisos necesarios. Ver Figura 30. Figura 30 Interfaz de juego tipo test 59 Implementación 59 En caso de no contar con las credenciales necesarias para su acceso esta página mostrará un mensaje indicándole por qué no se le permite entrar al juego. En la Figura 31 el alumno ha sobrepasado el número de intentos establecidos por el profesor. Figura 31 Mensaje indicando que se han sobrepasado el límite de intentos En la Figura 32 el alumno no puede acceder a la partida porque está fuera del plazo de la fecha establecida para esa partida. Figura 32 Mensaje indicando que la partida no está disponible en este momento. TestStudent Esta página es solo accesible por el profesor y es la usada para probar el correcto funcionamiento de una partida. Se muestra siempre el juego seleccionado durante la configuración de la partida sin necesidad de introducir credenciales de ningún tipo. En esta página no se produce la evaluación de la persona que realiza el juego. La interfaz es la misma que la observada en la Figura 30. Nota: Es importante aclarar en este punto que las fechas podrían mostrarse con un formato distinto a los mostrados en las imágenes puesto que son de tipo “datetime-local” y navegadores como Firefox a fecha del 27/07/2018 aún no lo han implementado. Las imágenes han sido capturadas usando el navegador Google Chrome en su versión 67.0.3396.99. 4.1.5 Fichero de configuración: config.properties El fichero de configuración usado en el proyecto es el siguiente: Tabla 69 fichero config.properties  dbHost: Equipo en el que se encuentra el servidor de bases de datos, como puede apreciarse se está utilizando el driver para poder realizar la conexión con SQLite. Implementación 60 60  dbName: Nombre de la base de datos usada en el proyecto.  zipPath: Ruta donde se almacenará el fichero comprimido con el juego. Realmente este fichero es temporal puesto que en el momento en el que el juego sea descomprimido éste será eliminado.  gamePath: directorio del servidor donde se almacenarán los juegos una vez descomprimidos.  dbUsername: usuario con el que se accede a la base de datos.  dbPassword: contraseña del usuario con el que se accede a la base de datos.  rootPath: directorio raíz del proyecto. 4.1.6 Descriptor de despliegue Tabla 70 Descriptor de despliegue 4.1.7 Ficheros JavaScript 4.1.7.1 Ficheros usados para la creación de partidas Se encuentran en la carpeta Resources del proyecto. Son los siguientes: <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"> <listener> <listener-class>es.us.dit.lti.AppLoader</listener-class> </listener> <servlet-name>ExternStaticFolder</servlet-name> <servlet-class>es.us.dit.lti.ExternStaticFolderServlet</servlet-class> <init-param> <description>Path to extern folder to serve</description> <param-name>ExternFolder</param-name> <param-value>/tmp</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>ExternStaticFolder</servlet-name> <url-pattern>/extern/*</url-pattern> </servlet-mapping> <servlet> <servlet-name>Games</servlet-name> <servlet-class>es.us.dit.lti.Launch</servlet-class> </servlet> <servlet-mapping> <servlet-name>Games</servlet-name> <url-pattern>/games</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>404.html</welcome-file> </welcome-file-list> <error-page> <error-code>404</error-code> <location>/404.html</location> </error-page> <error-page> <exception-type>java.lang.Throwable</exception-type> <location>/exception.html</location> </error-page> </web-app> 61 Implementación 61 crearpartida Funciones JavaScript o ECMAScript usadas durante la creación y edición de partidas. Entre sus usos está comprobar que se ha elegido un juego válido, y que, en el caso de haberlo hecho, se haga una petición AJAX al servidor para que se carguen los parámetros de configuración (fijos y opcionales) del juego. También se usa para validar que la fecha y hora en las que se habilitará la partida están permitidas. Un ejemplo de fecha no válida sería aquella en el que el inicio de la partida fuera posterior a la fecha de cierre. formCheck Funciones usadas para la validación de los campos del formulario durante la edición y creación de las partidas.. 4.1.7.2 Ficheros usados para comunicación entre la herramienta y el juego En este apartado describiremos las funciones JavaScript que hacen posible la comunicación entre la herramienta y el juego. Este proceso de comunicación fue descrito anteriormente en el punto 3.3.2. envio-variables.jsp Recoge los parámetros de configuración del juego de la base de datos y se los envía (estos parámetros fueron establecidos por el profesor durante la creación de la partida). Cuando recibe por parte del juego el mensaje de fin, recoge los resultados de la partida y los envía usando AJAX a NotaServlet. Como puede apreciarse “envio-variables” es un jsp puesto que incorpora código java para la obtención de parámetros de la base de datos y hace uso de JavaScript para comunicarse con el juego y enviar información de la partida a un servlet que la procesa y establece una calificación. comunicacion Desarrollado por Jesús Muñoz Calle. Es el encargado de avisarnos cuando el juego está cargado por completo (punto 1 de la Figura 11) y procesa los datos de configuración enviados por nuestra aplicación para que el juego dé comienzo (punto 3 Figura 11). 4.1.8 Archivos de error En esta parte se han reutilizado los mensajes de error desarrollados por Francisco José Fernádez Jiménez, por lo que se hará una breve mención a cada uno de ellos sin entrar mucho en detalles. Cuando se produzcan algunos errores determinados el navegador mostrará los siguientes mensajes:  Si ocurre una excepción no controlada se mostrará el archivo exception.html  Si intentamos acceder a la herramienta desde el TC mediante una petición GET en lugar de POST –el estándar requiere del uso de éstas últimas para su funcionamientose mostrará ErrorGet.html  Cuando se da algún otro tipo de error en la herramienta se muestra un mensaje con el error pertinente. Por ejemplo si una página solicitada no se encuentra en el servidor se devolverá error 404 not found. El fichero es ErrorApp.jsp Implementación 62 62 4.1.9 Ficheros CSS Se han reutilizado los diseñados por Francisco José Fernández Jiménez.  Error: Usado en los mensajes de error arriba expuestos.  Form: Usado para dar formato a los formularios de la aplicación 4.2 Otras funcionalidades Hasta ahora hemos explicado que nuestra aplicación web genera herramientas LTI que pueden ser integradas en diferentes LMS. Estas herramientas son configuradas por usuarios con rol de profesor y reciben el nombre de “partidas”. Cada partida incorporará un juego al que accederán los alumnos. También hemos hablado del carácter autocorrector de las partidas y de la subida automatizada de calificaciones a la plataforma de enseñanza virtual donde se implementan estas herramientas. En este punto hablaremos sobre algunas funcionalidades extras que si bien no son fundamentales, dotan de mayor versatilidad a nuestra aplicación y ofrecen una mejor experiencia de usuario. 4.2.1 Eliminar usuarios Al igual que con los juegos, el superusuario podrá borrar al resto de usuarios. Cuando un usuario es borrado todas las partidas creadas por él son eliminadas. El mismo caso es aplicable a los juegos, si un juego es eliminado cualquier partida que lo contuviera es eliminada. 4.2.2 Borrado de notas Si el profesor lo desea puede borrar todas las calificaciones asociadas a una partida con solo pulsar el botón “BORRAR NOTAS” de la Figura 25. Nota: Las calificaciones serán borradas tanto de la base de datos como de la plataforma de enseñanza virtual en la que esté implementada la partida. 4.2.3 Control horario Durante la creación de un usuario (Figura 17) podrá configurarse la zona horaria a la que pertenece. La aplicación se encargará de la conversion horaria entre las distintas zonas. De esta forma un profesor que resida en Canarias y tenga alumnos en la península al poner que una partida comience a las 14:00 h ésta estará disponible para los alumnos a partir de las 15:00 h horario peninsular. 4.2.4 Terminar partida Aunque las partidas finalizan en un plazo determinado configurado por el profesor, éste puede terminarla en cualquier momento si así lo desea pulsando el botón “TERMINAR PARTIDA” de la Figura 25. 63 Pruebas de ejecución 63 5 PRUEBAS DE EJECUCIÓN as pruebas realizadas han sido numerosas. Si bien es cierto que el proyecto ha ido incorporando funcionalidades y nuevas medidas de seguridad con el paso del tiempo -lo que supone modificar el código en numerosas ocasiones y por tanto mayor posibilidad de fallos y de pasar alguna situación por altose ha procurado que con cada cambio realizado se hicieran pruebas para verificar que todo funcionaba correctamente. En este punto trataremos principalmente algunas de las pruebas realizadas, problemas encontrados, los LMS utilizados en este proyecto y las pruebas de seguridad. Todos los aspectos aquí tratados han sido explicados anteriormente en el apartado de implementación. En este punto confirmaremos mediante pruebas que el programa responde satisfactoriamente a lo descrito y algunos de los problemas que puede mostrar el programa bajo ciertas circunstancias. 5.1 LMS utilizados Este proyecto ha sido probado en CourseSites [12] en su versión 9.1 del cuarto trimestre de 2017 y Moodle [14] en su versión 3.5. 5.1.1 CourseSites Los características más relevantes que nos han hecho decantarnos por este LMS son:  Gratuito.  Permite la creación de cursos.  Permite la integración de enlaces LTI.  Personalizable (diseños, cursos…).  Contiene panel de calificaciones.  Número ilimitado de cursos.  Permite invitar alumnos a cursos mediante un mensaje de correo electrónico de forma gratuita.  No tiene límites de alumnos en los cursos.  Permite incorporar profesores invitados a los cursos.  Muy popular, ampliamente testeado y con soporte técnico. 5.1.2 Moodle Hemos usado un hosting gratuito llamado MoodleCloud, usado por particulares o pequeñas instituciones. Moodle dispone de hostings de pago que ofrecen más servicios.  Gratuito y de código abierto.  Permite la creación de cursos.  Permite la integración de enlaces LTI.  Personalizable (permite personalizar diseños, cursos… de la distribución estándar de Moodle). L Pruebas de ejecución 64 64  Contiene panel de calificaciones.  Número de cursos ilimitados.  Permite invitar alumnos a cursos mediante un mensaje de correo electrónico de forma gratuita.  Máximo cincuenta usuarios en total.  doscientos Mb de espacio en disco.  Cuenta con BigBlueButton, que permite realizar conferencias con hasta seis personas al mismo tiempo. Dispone de una zona donde pueden realizarse encuestas y dispone de una pizarra virtual visible y editable por el resto de usuarios.  Muy popular, ampliamente testeado y con soporte técnico. Aunque la versión usada de Moodle se encuentra algo más limitada que la de CourseSites por el hecho de ser gratuita, nos intereseaba utilizar otro LMS para asegurarnos que el estándar utilizado respondía bien a otros TC. Además, Jesús Muñoz Calle –autor de los juegosutiliza esta plataforma en su día a día como profesional de la docencia y podría usar en un futuro esta herramienta con sus alumnos. Nota: Durante las pruebas se advirtió que con versiones desactualizadas de Moodle (versión 2.9 de 2015) el estándar presentaba problemas y la comunicación entre la herramienta y el LMS no era posible. Para garantizar el funcionamiento de la aplicación en este LMS no se recomienda usar versiones anteriores a la 3.5 (versión con la que se han realizado las pruebas con resultados satisfactorios). 5.2 Pruebas de funcionamiento realizadas y otros datos de interés Las pruebas que se han realizado y han dado resultados satisfactorios han sido:  Creación y eliminación de usuarios. No se permitirá la existencia de dos usuarios con el mismo nombre y se mostrará un mensaje de error.  Creación, Edición y Eliminación de partidas. El sistema impide la creación de dos partidas con el mismo nombre y notifica al usuario del error mediante un mensaje.  Subida, Habilitación/Deshabilitación y eliminación de juegos. El sistema no permite la subida al servidor de dos juegos con el mismo nombre y notificará al usuario con un mensaje de error. Tampoco será posible subir un juego al servidor sin darle nombre.  Modo Test. Se ha comprobado que el profesor puede acceder a la partida configurada antes de publicarla y de que no tiene que pasar por ningún tipo de control de identificación. Las calificaciones están deshabilitadas en este modo.  Si el profesor accede a la herramienta desde el LMS se habilitará el modo Test.  Se ha comprobado que funciona la detección horaria. Cambiando el reloj del sistema la aplicación detecta la nueva zona horaria y se la sugiere automáticamente al usuario, además la fecha de inicio y fin límites de la partida se adaptan a la zona horaria elegida por el usuario.  Se han comprobado cada uno de los campos de los formularios de creación y edición de partidas. Si no se rellenan los campos obligatorios no es posible enviar el formulario. Se impide también el envío si la fecha de inicio es anterior a la actual o posterior a la del cierre de la partida. 65 Pruebas de ejecución 65  Se ha comprobado que si una partida tiene deshabilitado el envío de calificaciones ésta no guarda ni envía al TC las calificaciones de los alumnos. También se ha comprobado que con esta opción habilitada, el envío se hace de forma correcta tanto en CourseSites como en Moodle.  Cuando una partida se crea, arranca un temporizador. En el momento en el que este concluya se terminará la partida. Cuando una partida es editada el temporizador de la partida se recarga con los nuevos valores de fecha introducida.  Cuando una partida es editada se cargan de forma predeterminada los campos de configuración que tiene la partida para facilitar la edición de ésta al usuario.  Se ha comprobado la aperture y cierre de las partidas con horarios de diferentes países (Portugal, Londres, España, Singapur, París, El Chad…).  Se han usado dos juegos para las pruebas “Test” y “Artificieros”, ambos funcionan correctamente y responden satisfactoriamente a los cambios en su configuración (Número de preguntas, orden de las preguntas…).  Se ha comprobado que si ocurre una recarga en el contexto, o el servidor se cae, los temporizadores se reactivan automáticamente tras el arranque de la aplicación. Si una partida hubiera finalizado durante este periodo no se reactivará el temporizador sino que se procederá a la subida de calificaciones directamente.  Se ha comprobado el correcto funcionamiento del menú de información de las partidas. Desde éste podrán cosultarse los parámetros de una partida así como las calificaciones de los alumnos que hayan participado en la misma.  Se ha comprobado que funciona correctamente tanto el borrado de las calificaciones asociadas a una partida como el “TERMINAR PARTIDA” manual activado por el profesor creador de la misma.  En el caso de querer reutilizar una partida se recomienda eliminar las calificaciones asociadas a ésta antes de reiniciarla.  El programa presente problemas si una misma partida se integra con el mismo nombre en dos LMS simultáneamente.  Con los parámetros de configuración correctos, se han podido integrar las partidas en ambas plataformas y han dado resultados positivos. Una de las pruebas más significativas realizadas en ambos LMS se han hecho bajo las siguientes condiciones (ver diagrama de Figura 33): o Se han creado dos profesores y cuatro alumnos. o Uno de los profesores (profesor “1”) tiene zona horaria de Portugal, el otro (profesor “2”) zona horaria Europa/Madrid. o Se han creado tres partidas, la partida “1” y “2” con el juego “Test” la partida “3” con el juego “Artificieros”. Cada una de estas partidas con un horario de apertura diferente. Las partidas “1” y “3” finalizan el mismo día a la misma hora. o La partida “1” pertenece al profesor “1”, la partida “2” y “3” pertenecen al profesor “2”. o El alumno “1” participará en la partida “1” y “3”, el alumno “2” en la “1” y “2”, el alumno “3” en la “1” y el alumno “4” en la “2” y “3”. Con esta prueba se pretende condensar la mayor casuística posible intentando no ser excesivamente Referencias 72 72 [31] Eclipse Foundation, «Descargas,» [En línea]. Available: https://www.eclipse.org/downloads/ [32] Java, «Descargas» [En línea]. Available: https://www.java.com/es/download/ [33] The Apache Software Foundation, «Tomcat documentation,» 3 Marzo 2004. [En línea]. Available: http://tomcat.apache.org/tomcat-3.3-doc/. [34] Db Brower for SQLite [En línea]. Available: https://sqlitebrowser.org/ 73 Anexos 73 7 ANEXOS Anexo A. Manual de instalación. Aunque el proyecto funciona y de hecho ha sido ejecutado con éxito en sistemas Linux (no olvidemos que está basado en trabajos anteriores cuya plataforma de funcionamiento principal eran sistemas operativos Linux) la realización y pruebas se han hecho en Windows 10 por tanto esta guía se centrará en este sistema. Se considera que el lector de este anexo dispone de los ficheros de la aplicación web, así como los archivos comprimidos que contienen los juegos con los que se han realizado las pruebas (test y artificieros) disponibles desde el CD/DVD adjunto a la memoria. 7.1 Preparación del entorno 1. Instalación de Eclipse Para este proyecto se ha usado Eclipse Oxygen.2 en la versión de diciembre de 2017, la descarga de eclipse se realiza desde su web oficial [31]. 2. Instalación de Java Para este proyecto hemos usado la versión 8 de java, esta versión puede descargarse desde su web oficial [32]. 3. Instalación de Apache Tomcat En nuestro proyecto se ha usado la versión 8.5, puede descargarse desde su web oficial [33]. 4. (opcional) Visualizador de base de datos. Para poder ver los datos almacenados en la base de datos y la estructura de ésta he usado db browser for SQLite. Descargable desde aquí [34]. 7.2 Fichero de configuración “config.properties” Antes de arrancar la aplicación es necesario configurar el fichero situado en WEB-INF que recibe el nombre de “config.properties”. Los parámetros son los siguientes:  dbHost: Equipo en el que se encuentra el servidor de bases de datos, como puede apreciarse se está utilizando el driver para poder realizar la conexión con SQLite.  dbName: Nombre de la base de datos usada en el proyecto.  zipPath: Ruta donde se almacenará el fichero comprimido con el juego. Realmente este fichero es temporal puesto que en el momento en el que el juego sea descomprimido éste será eliminado.  gamePath: directorio del servidor donde se almacenarán los juegos una vez descomprimidos. Anexos 74 74  dbUsername: usuario con el que se accede a la base de datos.  dbPassword: contraseña del usuario con el que se accede a la base de datos.  rootPath: directorio raíz del proyecto. 7.3 Configuración para poder realizar pruebas o modificaciones Una vez hayamos descargado Eclipse pulsamos “File > Import > Projects from folder or Archive” y seleccionamos el directorio donde tengamos almacenado el proyecto. Si todo ha ido bien el proyecto importado debe aparecer en la pestaña “package explorer” Ahora que tenemos el proyecto en eclipse debemos instalar el servidor, para ello deberemos ir a “File > new > server” y elegiremos la version que queramos instalar, en nuestro caso hemos usado la versión 8.5. Una vez hayamos hecho todos estos pasos en la pestaña “servers” debería salirnos el servidor que acabamos de instalar. Si hacemos click derecho sobre el servidor y pulsamos en “start” lo arrancaremos y podremos acceder a la aplicación desde un navegador. Figura 36 Servidores disponibles y estado 75 Anexos 75 Anexo B. Manual de usuario. 7.4 Instrucciones de uso En este punto se darán pautas con el funcionamiento de la aplicación y cómo integrar herramientas LTI en el LMS 7.4.1 Aplicación Web En la aplicación existirá como usuario por defecto un superusuario con nombre “super” y contraseña “super”, siempre es recomendable por seguridad cambiar la contraseña tras iniciar sesión por primera vez. Los usuarios según sus roles son:  Superusuario: podrá crear usuarios (que tendrán el rol de profesor) asignándoles un nombre, contraseña y zona horaria. La contraseña podrá ser cambiado posteriormente por el usuario. El superusuario será el único usuario con el poder de crear y eliminar usuarios. Cuando un usuario es eliminado las partidas asociadas a éste serán también eliminadas, por ultimo el superusuario será el único capaz de habilitar, deshabilitar o eliminar juegos.  Profesor: El usuario profesor podrá realizar las siguientes acciones: Figura 37 Menú principal con rol de profesor o Crear partida (+). o Información: ver parámetros y calificaciones de una partida. o Borrar partida. o Editar partida. o Modo Test: probar una partida. o Borrar notas: eliminar notas vinculadas a una partida. o Terminar partida: Finalizar manualmente una partida. Anexos 76 76 o Subir juego: Almacenar un juego en el servidor. El juego debe subirse en formato zip y debe contener un archivo html con el nombre de “jugar” y un fichero de configuración con el nombre “properties”. Tabla 71 Ejemplo del fichero properties del juego test 7.4.1.1 Creación de un usuario Partiendo de un estado inicial en el que no existen usuarios ni juegos ni partidas el procedimiento a seguir sería el siguiente: 1. Superusuario inicia sesión, el nombre por defecto es super y la contraseña super. Figura 38 Inicio de sesión de superusuario 2. Una vez logueados creamos al usuario prof con contraseña prof y zona horaria de España. <static> ALE=1; </static> <dinamic> jug1="Manolillo";CONTIPAR=0; CONTINUARPARTIDA="";NP=5; TIPORESPUESTA=0;TIPOCORRECCION=0; </dinamic> 77 Anexos 77 Figura 39 Creación de usuario profesor 3. Tras esto deberíamos visualizar el nuevo usuario creado. Figura 40 Lista de usuarios Anexos 78 78 7.4.1.2 Subida de juegos y creación de una partida 1. Iniciamos sesión con el nuevo usuario creado y subimos un juego. Para ello pulsaremos el enlace “Subir Juego”. Una vez pulsada la interfaz sería la siguiente: Figura 41 Menú de subida de un juego Seleccionamos el archivo del juego, le damos un nombre y procedemos a la subida del juego. Si todo ha ido bien nos deberá aparecer el siguiente mensaje: 79 Anexos 79 Figura 42 Éxito en la subida 2. Volvemos al menú principal pulsando en el enlace “partidas” y pulsamos en el símbolo “+” que hay a la derecha del rótulo “Lista de partidas”. Tras esto entraremos en el menú de configuración de una partida: Anexos 80 80 Figura 43 Formulario de creación de una partida Tras rellenar los campos de configuración de la partida pulsamos en “ESTABLECER”. Si todo ha ido bien esta acción nos redigirá a la página “partidas” y visualizaremos la nueva partida creada: 81 Anexos 81 Figura 44 Lista de partidas 7.4.1.3 Eliminación de una partida 1. Pulsamos en el botón borrar de la Figura 45. Se nos pedirá confirmación y deberemos aceptar. Anexos 88 88 7.4.1.6 Información de una partida y consulta de calificaciones Para consultar los parámetros de una partida será necesario seleccionarla y pulsar el botón “INFORMACIÓN” Figura 45. Desde esta parte del programa podrá ser consultada las calificiaciones obtenidas por los alumnos en esa partida. Existen tres posibilidades: 1. Que ningún alumno haya participado en la partida, por tanto este apartado esté vacío. 2. Que al menos un alumno haya participado pero la partida aún no haya finalizado. En este caso se mostrarán las calificaciones provisionales de la partida. Figura 53. Figura 53 Calificaciones antes de finalizar partida 3. Que al menos un alumno haya participado en la partida y ésta haya finalizado Figura 54. Figura 54 Calificaciones tras terminar la partida 89 Anexos 89 7.4.2 Integración de herramienta en LMS En este apartado se explicará cómo implementar nuestra herramienta en los dos LMS en los que se han realizado las pruebas. 7.4.2.1 CourseSites El primer paso es tener creado un curso y alumnos registrados en él. Una vez hecho esto deberemos ir al contenido del curso, tras esto pulsaremos en “enlace web”. En este apartado tendremos que establecer una serie de parámetros de configuración que pueden observarse en la Figura 55.  Nombre: Nombre con el que aparecerá el enlace web en CourseSites.  URL: Dirección a la que se hará POST tras hacer click en el enlace LTI. En nuestro caso el descriptor de despliegue está configurado de forma que cuantro pulsamos en el enlace se invoque a la clase Launch.  Tecla: Debe coincidir con el consumer_key de nuestro proyecto, recordemos que éste se forma de la siguiente manera: “Nombre de la partida” + “_” + “Clave” 8 .  Secreto: Debe coincidir con el configurado en la partida.  Parámetros personalizados (opcionales): o debug=true: Muestra mensajes detallados en caso de producirse un error LTI. o uvus=@[email protected]@X@: Se utiliza para identificar al alumno por el nombre con el que se ha registrado en CourseSites en lugar de con el id de usuario. 8 Tanto el nombre de la partida como la clave son configurados durante la creación de la misma. Anexos 90 90 Figura 55 Configuración de enlace web en CourseSites 7.4.2.2 Moodle Proceso muy similar al descrito para CourseSites. Quizás el cambio más significativo sea que en el apartado “Custom parameters” (Parámetros personalizados) la sentencia cambia. En la Figura 56 puede observarse el nuevo formato que adopta. Figura 56 Configuración de Moodle para crear enlace LTI 91 Anexos 91 7.4.3 Acceso a la herramienta desde el TC Una vez la partida se ha configurado e integrado en el TC los alumnos deberán acceder a ella desde el enlace LTI creado por el profesor. En este momento pueden ocurrir tres cosas: 1. Que la partida no haya empezado aún o ya haya finalizado por lo que se mostrará el siguiente mensaje. Figura 57 Partida no disponible por fecha 2. Que el alumno haya excedido el número de intentos, en este caso se mostrará lo siguiente. Figura 58 Partida no disponible por sobrepasar el número de intentos 3. Que todo esté correcto y el alumno pueda acceder al juego. Figura 59 Interfaz de juego “Test” Anexos 92 92 Cuando se alcanza la fecha de finalización de la partida o el profesor dicide terminarla pulsando el botón “TERMINAR PARTIDA” (Figura 44) la nota es enviada al cuaderno de calificaciones del TC. 93 Anexos 93