Sincronización del sistema de información de la ULPGC con Moodle

Proyecto Fin de Carrera Ingeniería en Informática Sincronización del Sistema de Información de la ULPGC con Moodle Autor: Víctor Déniz Falcón Tutor: Alexis Quesada Arencibia Escuela de Ingeniería Informática Universidad de Las Palmas de Gran Canaria Febrero de 2015 A Jenni, llenas mi vida y me haces desear que llegue la noche para recogerme en tus brazos, sin importar como haya ido el día; no dejo de aprender contigo y quiero seguir haciéndolo el resto de mi vida. A Bianca y Aarón, me habéis enseñado otra forma de amar, otra forma de sentir. Habéis dado un revolcón a mi vida y ya no puedo imaginarla sin vosotros. A Mawi, tu sacrificio y esfuerzo me permitió realizar unos estudios universitarios, aun cuando no respondía como te merecías. Has dado parte de tu vida para que yo tenga la mía. Nunca podré agradecerte lo suficiente su entrega. A Papá, Mamé y Lali, sin ustedes no sería quién soy. No me hace falta preguntar, sé que siempre están ahí. Los quiero… Agradecimientos Durante los años que me ha llevado realizar el proyecto final de carrera, por diferentes motivos de índole personal y profesional he empleado muchos más de los necesarios, son demasiadas las personas a las que tengo que agradecer en mayor o menor medida su aportación. A todos los tutores que en algún momento he perturbado, más bien poco, con mi intención de hacer el proyecto. En especial a Alexis Quesada, cuya cercanía y atención, a pesar de mi irregularidad, me ha marcado el camino a seguir. A mis compañeros del Servicio de Informática de la ULPGC, especialmente a Luci, que entre café y queque siempre han puesto a mi disposición los recursos necesarios y han facilitado mi trabajo. A todos mis profesores, desde la guardería hasta el último curso de carrera, por el conocimiento transmitido y vuestra aportación en mi persona. No puedo dejar de mencionar a Don Manuel, su convicción y metodología me marcó profundamente. iii Resumen Se ha desarrollado un conjunto de extensiones para el LMS (Learning Management System) Moodle que permiten sincronizar su contenido con la información académica de la ULPGC, almacenada en una base de datos institucional. De esta forma se minimiza la intervención humana, garantizando que el Campus Virtual de la ULPGC sea un reflejo de su estructura presencial, incluyendo titulaciones, asignaturas, profesores y alumnos. Para ello se han seguido las directrices marcadas por los desarrolladores de Moodle, respetando la arquitectura de este software y utilizando la API que incorpora. Asimismo, las extensiones se han desarrollado con la vista puesta en su uso por terceros, por lo que, con pequeños cambios de configuración, se pueden utilizar en cualquier instalación de Moodle con características similares a las de la ULPGC. v Palabras Clave Moodle, Desarrollo de extensiones de Moodle, Sincronización de sistemas, Campus Virtual de la ULPGC, Learning Management System, Extensión de identificación, Extensión de matriculación, Sincronización de bases de datos vii Índice de Figuras Figura 1-1 Fases de la metodología en Cascada ................................................................. 4 Figura 1-2 Planificación ........................................................................................................ 8 Figura 2-1 Principales hitos e-learning en la ULPGC ........................................................ 17 Figura 3-1 Estructura de Moodle ....................................................................................... 20 Figura 3-2 Jerarquía de categorías y cursos ...................................................................... 21 Figura 3-3 Diferencias entre identificación y matriculación ............................................ 22 Figura 4-1 Esquema ULPnet ............................................................................................... 28 Figura 4-2 Infraestructura de las plataformas del Campus Virtual ................................. 29 Figura 4-3 Arquitectura de sistemas de la ULPGC ............................................................ 30 Figura 6-1 Entorno de ejecución ....................................................................................... 35 Figura 8-1 Sistemas involucrados ...................................................................................... 77 Figura 8-2 Tabla de centros ................................................................................................ 82 Figura 8-3 Tablas de Moodle implicadas en la sincronización ........................................ 83 Figura 8-4 Diagrama de flujo de datos general scripts extensión local .......................... 84 Figura 8-5 Diagrama de flujo de datos Insertar Centro ................................................... 85 Figura 8-6 Diagrama de flujo de datos Eliminar Centro ................................................... 85 Figura 8-7 Diagrama de flujo de datos Insertar Categoría ............................................... 86 Figura 8-8 Diagrama de flujo de datos Eliminar Categoría .............................................. 86 Figura 8-9 Diagrama de flujo de datos Insertar Curso ..................................................... 86 Figura 8-10 Diagrama de flujo de datos Eliminar Curso .................................................. 87 Figura 8-11 Diagrama de flujo de datos Insertar Grupo .................................................. 87 Figura 8-12 Diagrama de flujo de datos Eliminar Grupo ................................................. 87 Figura 8-13 Diagrama de flujo de datos Asignación Grupos ........................................... 88 Figura 8-14 Diagrama de flujo de datos Asignar Grupo ................................................... 89 Figura 8-15 Diagrama de flujo de datos Desasignar Grupo ............................................. 89 Figura 8-16 Diagrama de secuencia del proceso de identificación ................................. 90 Figura 8-17 Diagrama de clases extensión Identificación ................................................ 91 Figura 8-18 Tabla de usuarios de Moodle ......................................................................... 94 Figura 8-19 Diagrama de clases extensión de matriculación .......................................... 95 Figura 8-20 Tablas relacionadas con la matriculación ..................................................... 95 Figura 8-21 Secuencia de ejecución de los scripts de sincronización ............................. 96 Figura 9-1 Entorno de desarrollo ..................................................................................... 102 Figura 9-2 Conexión a base de datos externa................................................................. 103 Figura 9-3 Estructura de archivos de extensión local .................................................... 105 Figura 9-4 Estructura de archivos extensión identificación ........................................... 110 Figura 9-5 Estructura de archivos extensión matriculación .......................................... 115 Figura VII-1 Activación de extensión de identificación .................................................. 170 Figura VII-2 Configuración de la extensión de identificación ........................................ 171 Figura VII-3 Activación de la extensión de matriculación .............................................. 172 Índice de Tablas Tabla 1 Planificación ............................................................................................................. 7 Tabla 2 Plataformas del Campus Virtual de la ULPGC ..................................................... 18 Tabla 3 Organización del código fuente ............................................................................ 36 Tabla 4 Organización del directorio de datos ................................................................... 37 Tabla 5 Ejemplos de extensiones ...................................................................................... 39 1 INTRODUCCIÓN 1.1 JUSTIFICACIÓN DEL PROYECTO La enseñanza a distancia (e-learning) dota de libertad para escoger cuándo y dónde estudiar, adaptándose al estilo de vida del alumno, permitiéndole compatibilizar su trabajo y tareas cotidianas con el aprendizaje de estudios universitarios. Moodle es una plataforma de e-learning de distribución libre, con más de 45000 organizaciones y 20 millones de usuarios que hacen de este sistema uno de los más usados y con mayor crecimiento. La Universidad de Las Palmas de Gran Canaria (ULPGC), desde el curso académico 2005/06, ofrece titulaciones de grado en modalidad no presencial sobre Moodle. La docencia en línea, además, se ha extendido al resto de niveles formativos: enseñanza presencial, cursos de másteres, expertos universitarios, extensión universitaria, etc. El Campus Virtual de la ULPGC ofrece a muchos estudiantes la posibilidad de cursar una titulación totalmente a distancia y a otros complementar su formación presencial, con la participación de los profesores que cada vez se involucran más en fomentar la participación en los cursos virtuales. Para facilitar su manejo, la estructura idónea y natural para cada una de las plataformas que conforman este campus es aquella que más se asemeja a la estructura tradicional de la Universidad, utilizando las mismas entidades y nomenclatura. La información en las plataformas de enseñanza a distancia tiene que estar actualizada a diario y de manera automática, de tal forma que sea un fiel reflejo de la información académica real, permitiendo a alumnos y profesores interactuar con la plataforma en el menor lapso de tiempo posible desde que se matriculen o asignen. El sistema de información que maneja los datos de titulaciones, cursos, grupos, alumnos y profesores de la ULPGC es muy complejo y Moodle no puede trabajar directamente con él. Por tanto, es necesario desarrollar los procedimientos necesarios para realizar esta sincronización de forma sistemática y, automáticamente, transferir la información de la base de datos corporativa de la ULPGC a la base de datos de cada plataforma virtual. 1 Introducción Facilitar y colaborar en la mejora de este servicio, permitiendo que todos los usuarios puedan acceder de forma automática a los cursos en los que están matriculados, es esencial para la institución y, como profesional de las TIC, ofrece un alto grado de satisfacción personal. 1.2 ESTADO ACTUAL En el momento de iniciar el proyecto, la sincronización se realiza enviando unos ficheros de texto desde los servidores de la base de datos institucional a los servidores del Campus Virtual. En el Campus Virtual se procesan todos los registros diariamente, es decir, en cada ejecución se intenta crear cada titulación, curso y usuario, implicando un tiempo de procesamiento elevado, que, en caso de ejecutarse durante las horas de mayor uso de las plataformas, ralentizaría notablemente el rendimiento de las mismas. Además, los ficheros de texto deben generarse íntegramente antes de cada actualización, incrementando el número de pasos y el tiempo necesarios. El problema más crítico, desde el punto de vista operativo del Campus Virtual, radica en la mala generación o transmisión de los ficheros de texto, que podría provocar efectos indeseados como la eliminación de un usuario en una asignatura o incluso la desactivación de cuentas de usuario, sucesos ocurridos en varias ocasiones y que se han solventado utilizando copias de seguridad de días anteriores. 1.3 OBJETIVOS DEL PROYECTO El objetivo principal del proyecto es desarrollar las extensiones de Moodle que garanticen que la información académica de la ULPGC relativa a titulaciones, asignaturas, grupos, profesores y alumnos se traslada al Campus Virtual, teniendo en cuenta las siguientes premisas: • Automatización del proceso de sincronización: diariamente se deben sincronizar los datos de la base de datos corporativa con la base de datos del Campus Virtual sin intervención humana. Se desarrollarán los procesos necesarios para que, a diario, se sincronicen ambas bases de datos. • No perder información: Es de vital importancia que no se pierda información accidentalmente en la plataforma virtual. • Actualización: la información debe estar actualizada en la mayor brevedad posible. Como máximo, un día. 2 Introducción • Integridad y coherencia: la información en ambas bases de datos debe coincidir; la información en el Campus Virtual tiene que coincidir con la realidad académica de la ULPGC. • La información que se debe sincronizar comprende: titulaciones, asignaturas, profesores, estudiantes, grupos y asignación de profesores y estudiantes a sus asignaturas y grupos. • Unidireccional: las modificaciones realizadas en el Campus Virtual, nunca se transmitirán a la base de datos institucional. • Eficiencia: el proceso de sincronización debe consumir la menor cantidad de recursos posibles, no afectando al rendimiento del Campus Virtual. En la medida de lo posible, es deseable que se pueda realizar manualmente si no se quiere esperar a la sincronización programada. 1.4 METODOLOGÍA Este proyecto se desarrollará siguiendo el desarrollo en cascada, principalmente por dos razones: • es la metodología empleada en el Servicio de Informática, responsable final del correcto funcionamiento de este proyecto que se desarrollará al amparo del mismo; • se trata de un proyecto estable, donde es poco probable que surjan cambios durante el desarrollo del mismo, puesto que los requisitos están claramente definidos, y en base al estado actual se puede producir un diseño correcto, corrigiendo los problemas actuales, antes de empezar la implementación. 1.4.1 Metodología en Cascada Es un modelo lineal de desarrollo, siguiendo un proceso secuencial, donde cada fase (análisis, diseño, implementación, pruebas, implantación y mantenimiento) se finaliza antes de pasar a la siguiente. 3 Introducción Figura 1-1 Fases de la metodología en Cascada La planificación del proyecto es el elemento central de esta metodología, por lo que requiere un análisis muy detallado desde el inicio, permitiendo estimar plazos y costes con mayor precisión que otras metodologías. Por el contrario, es poco flexible. Modificar los requisitos u objetivos del proyecto en cualquier fase del proyecto es muy complicado, de ahí la importancia del análisis inicial. Además, las pruebas y la retroalimentación tienen lugar en las últimas fases del proyecto, por lo que la capacidad de reacción es muy limitada y requiere una importante cantidad de recursos (tiempo, esfuerzo y dinero). Brevemente, las fases de la metodología en cascada son: 1. Análisis: evaluación de los requisitos de los usuarios finales para determinar los objetivos del proyecto y disponer de una especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. Señalar que todo lo que se requiere del sistema se debe definir en esta fase, no pudiéndose añadir nuevos requerimientos una vez finalizada esta fase. 2. Diseño: a partir de los requisitos, se obtiene un diseño lógico de la aplicación independiente del hardware y software a utilizar, para posteriormente transformarlo en un diseño físico en función de los sistemas hardware y software donde se implantará el producto. 4 Introducción 3. Implementación: desarrollo del código de la aplicación en base a los requisitos y especificaciones de las fases anteriores, siendo de gran utilidad el uso de prototipos. 4. Pruebas: verificar que la aplicación funciona correctamente y cumple con las expectativas de los usuarios. El usuario final debe verificar y validar el correcto funcionamiento. Existen varios tipos de prueba, que se describirán con más detalle en el apartado correspondiente: • Pruebas de unidad • Pruebas de integración • Pruebas de sistema • Pruebas de aceptación 5. Implantación: la solución se pone en producción o se integra en otra aplicación de mayor envergadura ya en producción. 6. Mantenimiento: seguimiento de la solución en producción. El objetivo es detectar errores y solucionarlos. Las causas de estos errores pueden ser requisitos mal definidos, un diseño incorrecto o cambios en los requisitos de usuario. 1.5 PLANIFICACIÓN A continuación se definen las fases en las que se desglosa este proyecto, incluyendo una tabla con la estimación temporal para cada una de ellas. • Análisis de requisitos: análisis de los requisitos de los usuarios y los sistemas. • Base de datos institucional: conocimiento básico de la base de datos desde la que se va a obtener la información a sincronizar. A groso modo, conocer dónde y cómo se almacena y cómo se puede acceder a la misma desde un sistema externo. • Moodle: adquirir las nociones fundamentales de desarrollo en Moodle, arquitectura, convenciones, APIs disponibles, etc. • Herramientas de desarrollo: familiarizarse con el software que se empleará durante el desarrollo de las extensiones. • Diseño: diseñar las extensiones en base al análisis elaborado en la primera fase. 5 E-learning internet. Incluye un ahorro de costes y reducción en el impacto medioambiental que genera el uso de vehículos. • Facilita la comunicación y la interactividad: hay muchas herramientas que facilitan la comunicación tanto horizontal (entre compañeros) como vertical (con los profesores). Foros, chats, mensajería, son ya parte de cualquier entorno colaborativo y cada vez es más frecuente el uso de videoconferencia como instrumento para comunicarse con uno o varios participantes de un curso. • Flexibilidad: los estudiantes pueden marcar su propio ritmo. Idealmente se podría acceder a los recursos las 24 horas del día los 7 días de la semana (24x7x365). • Combinación de materiales educativos: las limitaciones en el uso de las pizarras o transparencias se eliminan con un amplio abanico de herramientas multimedia que posibilitan crear contenido que enriquecen la experiencia del usuario, combinando audio, vídeo e imágenes, potenciando la interacción del usuario. Además de las ventajas mencionadas, hay otras serie de características relevantes asociadas al e-learning online : • Vivo: contenidos y actividades actualizados, con variedad de fuentes y facilidad para acceder y modificar los mismos. • Personalizado: cada usuario debe poder obtener formación y/o material acorde a sus necesidades, estando disponible cuando el usuario puede o quiere acceder. • Colaborativo: la colaboración facilita e impulsa el aprendizaje. Son esenciales los mecanismos que permiten interactuar a los usuarios. • Individualizado: cada usuario debe poder elegir cómo adquirir los conocimientos, utilizar los recursos que mejor se adapten a su metodología de estudio. El e-learning on-line se fundamenta, tecnológicamente, en los Sistemas de Gestión de Aprendizaje (LMS), entornos web desde los que se ofrecen, administran y gestionan tanto los contenidos formativos como la actividad de los estudiantes. 2.2 SISTEMAS GESTIÓN DE APRENDIZAJE (LMS) Los Sistemas de Gestión de Aprendizaje (Learning Management Systems, LMS) o plataformas de aprendizaje, son un software instalado generalmente en un servidor web, que se emplea para 12 E-learning crear, aprobar, administrar, almacenar, distribuir y gestionar las actividades de formación virtual. Puede utilizarse como complemento a la enseñanza presencial o a la enseñanza a distancia tradicional. Para simplificar, utilizaremos las siglas LMS para referirnos a este tipo de software. Los LMS se centran en gestionar los contenidos y la interacción de los usuarios. La creación de los contenidos se realiza utilizando Sistemas de Gestión de Contenidos para el Aprendizaje (LCMS, siglas de Learning Content Management Systems) o herramientas de autor, generalmente externas al LMS. Cada vez es más frecuente que los LMS incluyan herramientas para generar los propios contenidos. 2.2.1 Usuarios En un LMS podemos encontrar diferentes tipos de usuarios: • Administradores: instalan, configuran y gestionan el buen funcionamiento del LMS. No intervienen en la formación. • Diseñadores instruccionales: comúnmente conocidos como creadores o diseñadores de cursos, que definen la estructura de los cursos y utilizan los contenidos para estructurar los mismos. En muchos casos son los propios profesores. • Profesores: utilizan los contenidos del curso para formar a los alumnos o complementar la docencia presencial. Adicionalmente, en muchos LMS disponen de funcionalidades para evaluar y hacer un seguimiento del aprendizaje de los alumnos. • Alumnos: acceden al LMS para adquirir conocimientos, interactuar con otros usuarios y desarrollar y/o entregar diferentes actividades propuestas por los profesores de los cursos. 2.2.2 Características Según Clarenc (Clarenc, 2013), las características que debería cumplir un LMS son: • Interactividad: los LMS deben disponer de las herramientas necesarias para ofrecer suficiente interactividad, de tal forma que los usuarios puedan comunicarse e intercambiar conocimientos, sin dejar de ser los protagonistas de su propio aprendizaje. • Flexibilidad: las plataformas no deben ser rígidas a la hora de implementar un plan de estudio o diseñar un curso. Deben permitir modificar la estructura general o la 13 E-learning configuración de un curso, adaptándose a la organización de un centro o al método pedagógico que decidan emplear los profesores. • Escalabilidad: un LMS debe ofrecer un rendimiento aceptable a los usuarios, independientemente del número de usuarios registrados y/o activos. • Estandarización: tiene dos vertientes. Por un lado que su uso sea acorde a las convenciones con las que están familiarizados los usuarios al utilizar otras aplicaciones. Por otro lado, que permita integrar con facilidad materiales que hayan sido elaborados con otras herramientas. • Usabilidad: rapidez y facilidad con la que los usuarios pueden realizar sus tareas dentro del LMS. Contempla aspectos de efectividad, eficiencia y accesibilidad, que generan el grado de satisfacción del usuario. • Funcionalidad: debe cumplir con los requerimientos y necesidades de los diferentes usuarios, permitiéndoles desempeñar su labor. En el siguiente apartado se describen las principales funciones que debe cumplir. • Ubicuidad: es la capacidad de una plataforma de hacer sentir al usuario presente en todo momento, independientemente de dónde esté o cómo se conecte, y de que encontrará en ella todo aquello que necesite para avanzar en sus estudios. • La integración y articulación de otras cuatro características, funcionalidad, usabilidad, ubicuidad e interactividad. Es la capacidad que tiene una plataforma de fidelizar a un usuario a través de uso, ofreciéndole una experiencia satisfactoria que le motive a continuar utilizándola. 2.2.3 Funciones Las principales funciones que debe ofrecer un LMS moderno son: • Gestión de usuarios: permitir la creación de usuarios, modificación de sus datos y asignación a cursos con diferentes roles (profesor, alumno, etc.). • Gestión de contenidos: facilitar la adición de contenido (material didáctico) y creación de actividades a realizar por los alumnos. • Evaluaciones: mecanismos para valorar la adquisición de conocimiento por parte de los alumnos. 14 E-learning • Seguimiento del proceso de aprendizaje: mecanismos para determinar dónde se encuentra un estudiante en cada momento y ofrecerle un aprendizaje a medida. Útil para identificar dificultades durante el aprendizaje. • Elaborar informes: los informes son una poderosa herramienta para evaluar el desempeño tanto a nivel individual como colectivo de los usuarios, limitándose a un curso o a toda una plataforma. • Ofrecer herramientas de comunicación: la interacción entre profesores y alumnos es imprescindible; la colaboración entre alumnos mejora exponencialmente el aprendizaje. Son necesarias herramientas de comunicación uno a uno, uno a muchos y muchos a muchos (foros, chats, mensajería privada, etc.). Observar que no se contempla la elaboración de contenidos entre las funcionalidades que debe ofrecer un LMS, sino la gestión de los mismos. Los entornos destinados a la creación de contenidos se conocen como Sistemas de Gestión de Contenido para Aprendizaje (LCMS , siglas de Learning Content Management Systems). La información de cursos y usuarios normalmente se almacena en los sistemas de información de las organizaciones, siendo la integración de éstos con el LMS un factor determinante a la hora de implantar una plataforma de enseñanza on-line. 2.3 E-LEARNING EN LA ULPGC En el año 1994, el CICEI (Centro Informático y de Comunicaciones del Edificio de Ingeniería) asume la implantación e integración de las Tecnologías de la Información en el ámbito de la ULPGC. En 1997 en el CICEI se comienza a trabajar con la versión beta de WebCT. Este mismo año se inicia un proyecto de innovación docente, denominado Proyecto INNOVA, en el que participaron más de 30 profesores de diferentes departamentos de la Universidad. La plataforma utilizada, IVA (Interfaz Virtual de Aula), fue un entorno desarrollado por el CICEI sobre la primera versión de WebCT. La primera titulación en línea de la ULPGC, Psicopedagogía en línea, se ofrece en febrero del año 2002, utilizando IVA. Esta primera edición se impartió en modalidad semipresencial, contando con sesiones presenciales, material impreso, tutorías y consultas en línea. En esta edición se matricularon 90 estudiantes residentes en cuatro de las islas. En el curso 2003/04 el 15 E-learning número de matriculados aumenta a 185, con presencia de alumnos no residentes en las Islas Canarias, y en el curso 2004/05 ya superan los 200. En el curso 2003-04 se desarrolló en la propia ULPGC una aplicación como soporte a la enseñanza presencial, no relacionada ni con IVA ni con WebCT. Se bautizó como EVA o LPE (La Plataforma Educativa). Aunque resultó excesivamente no funcional, fue la insatisfacción con la misma la que causó la búsqueda de otra plataforma mejor y descartar desarrollos a medida. A partir de los resultados obtenidos en el uso de LPE, se definieron una serie de criterios básicos para la evaluación de un LMS como alternativa a la misma: • Basado en web y multiplataforma • Gestión de acceso unificada y permiso basado en roles • Flexibilidad en el uso de actividades y módulos docentes • Fácil diseño y creación de cursos • Trabajo colaborativo • Seguimiento de la actividad del alumno • Características técnicas: o Seguridad o Facilidad para añadir/desarrollar nuevas funcionalidades o Escalabilidad frente al aumento en el número de usuarios o Integración con otros sistemas Se realizó una comparativa entre más de 50 plataformas de e-learning de libre distribución, dado que el presupuesto era nulo. En función de los criterios anteriormente expuestos y otra serie de características deseables en este tipo de entornos, se concluyó que Moodle destacaba claramente por su interfaz amigable, siendo la herramienta más fácil de manejar, su extensa interoperabilidad, el gran número de módulos de actividades, sus características avanzadas de trabajo colaborativo, siendo enormemente potente y flexible. En el año 2004 se toma la decisión de adoptar Moodle como plataforma de e-learning, desarrollado como software libre por un equipo liderado por Martin Dougiamas, antiguo 16 E-learning desarrollador de WebCT. Se inicia la docencia de Másteres y Expertos, programas de Doctorado, cursos de Extensión Universitaria y de Formación Continua. Bajo el proyecto de desarrollo del Campus Virtual de la ULPGC, se pone en marcha la plataforma Apoyo a la Enseñanza Universitaria Presencial, en la que se aprovecha la experiencia obtenida en la formación no presencial para mejorar la calidad de la modalidad de enseñanza tradicional, y la plataforma Espacios Virtuales de Trabajo, en la que se ofrece toda la potencia de Moodle para la estructuración de todo tipo de grupos de trabajo a distancia en docencia, investigación y gestión. Fruto de la estrecha colaboración de la ULPGC con la comunidad mundial de Moodle, en 2005 se organiza en la ULPGC un congreso de desarrolladores de Moodle (MoodleMoot’05). En el curso académico 2005/06 se inician dos nuevas titulaciones de grado online: Maestro en Educación Primaria y Diplomatura en Turismo. En el curso siguiente, 2006/07, se añaden dos nuevas titulaciones: Diplomatura en Trabajo Social y Diplomatura de Relaciones Laborales. Paralelamente, en la plataforma Apoyo a la Enseñanza Presencial, son cada vez más los profesores y estudiantes que participan, de tal forma que todas las titulaciones y asignaturas en modalidad presencial tienen su espacio virtual. Figura 2-1 Principales hitos e-learning en la ULPGC La ULPGC, en el curso académico 2014-15, vigente durante la realización del proyecto, mantiene una plataforma de e-learning destinada a la enseñanza presencial, en la que todas las titulaciones y asignaturas están presentes, así como una plataforma destinada exclusivamente a las titulaciones en línea. En el siguiente apartado se detalla la organización del Campus Virtual de la ULPGC. 17 E-learning 2.4 ORGANIZACIÓN DEL CAMPUS VIRTUAL DE LA ULPGC Un Campus Virtual, análogamente a los campus universitarios, es el espacio físico, virtual, administrativo, tecnológico y educativo donde se desarrolla toda la experiencia institucional, y se ha consolidado como el pilar del e-learning en las universidades. Uno de los principales elementos de un Campus Virtual es el LMS. El Campus Virtual de la ULPGC lo componen varias instancias de Moodle independientes, cada una con su propia instalación y base de datos: • Teleformación: se encarga de las titulaciones impartidas exclusivamente en línea, a distancia, por la Estructura de Teleformación. • Grado y Posgrado: da servicio a titulaciones oficiales de grado y másteres y doctorados de posgrado (1er, 2º y 3er ciclo), ya sean impartidas en régimen presencial, semipresencial o a distancia. • Trabajo colaborativo: ofrece espacios genéricos de colaboración para grupos de trabajo o de investigación de la ULPGC o externos. • Campus social: ofrece espacio a cursos de biblioteca, centros, foro de calidad y evaluación, punto de encuentro y sala de profesores. • Otras Enseñanzas: destinada a estudios de másteres y expertos, cursos de Extensión Universitaria, programas formativos especiales (Diploma de Estudios Canarios, Diplomas de Estudios Europeos, Peritia et Doctrina). También aloja cursos externos a la ULPGC, mediante convenios de colaboración. Plataforma Teleformación Grado y Posgrado Trabajo colaborativo Campus social Otras Enseñanzas Cursos 504 4822 465 63 1225 Usuarios 2338 21920 4269 50994 7747 Tabla 2 Plataformas del Campus Virtual de la ULPGC 18 3 MOODLE La palabra Moodle es el acrónimo, en inglés, de Modular Object-Oriented Dynamic Learning Environment, cuya traducción es Entorno de Aprendizaje Dinámico Modular Orientado a Objetos. Es una aplicación que se puede categorizar como un gestor de contenidos educativos (LMS, Learning Management System), subcategoría a su vez de los gestores de contenidos (CMS, Content Management System). En pocas palabras, ofrece un espacio donde un centro educativo o una organización gestionan recursos educativos proporcionados por unos docentes y organiza el acceso a los mismos por parte de los alumnos, facilitando la comunicación entre ambos grupos. La primera versión de Moodle apareció el 20 de agosto de 2002; desde entonces han aparecido nuevas versiones de forma regular que han ido incorporando nuevos recursos, actividades y mejoras demandadas por la comunidad de usuarios. Moodle es un software de código abierto, bajo licencia GPL, escrito en PHP. A la redacción de esta memoria, Moodle es la plataforma LMS más popular del mundo y está traducido a 75 idiomas e incluye más de 27.000 sitios registrados. La estructura de Moodle gira en torno a los cursos, usuarios y roles, tres conceptos interrelacionados y dependientes entre sí (Büchner, 2011). Definiremos estos tres conceptos y como se relacionan, así como otros de menor importancia pero igualmente relevantes para la comprensión de este proyecto. 3.1 ORGANIZACIÓN INTERNA DE MOODLE Para tener una visión de conjunto de la importancia de los cursos, usuarios y roles, se utilizará este diagrama donde se resalta la importancia de los tres conceptos y como se relacionan con otros elementos. 19 Moodle Figura 3-1 Estructura de Moodle Haciendo un recorrido siguiendo el sentido de las agujas del reloj y partiendo de la esquina inferior izquierda: • Los usuarios tienen que superar un proceso de Identificación para obtener acceso a Moodle. • Luego tienen que disponer de Matrícula en aquellos Cursos en los que quieran participar, estando los cursos organizados en Categorías. • Los Grupos y Cohortes permiten agrupar usuarios a nivel de curso o de sitio respectivamente. • Los usuarios obtienen Roles en diferentes Contextos, dependiendo qué puede hacer cada rol únicamente por los Permisos que se le han asignado al mismo. Actividades y recursos Una actividad es un elemento que permite a los usuarios interactuar con otros usuarios o con el profesor. Ejemplos de actividades es un foro, enviar un documento respondiendo a un enunciado o responder un cuestionario. Un recurso es un elemento que un profesor añade a un curso como apoyo al aprendizaje, como puede ser un archivo, un vídeo o un enlace a una página web. La principal diferencia con las Categorías Matrículas (Enrolments) Cursos Grupos Identificación Usuarios Contextos Roles Permisos 20 Moodle actividades es que los recursos son estáticos. Los estudiantes solo pueden verlo o leerlo, pero no interactuar con el mismo. Cursos Los cursos son el elemento central de Moodle ya que son los contenedores donde el proceso de enseñanza tiene lugar. Es el espacio donde los profesores añaden el material docente, en forma de recursos, crean actividades, resuelven dudas y evalúan el trabajo de los alumnos. Por su parte, los alumnos leen, escucha o visualizan los materiales docentes, participan en actividades, envían sus trabajos y colaboran con otros. La organización interna puede variar, pero normalmente incluyen una serie de secciones donde se muestra el material y bloques laterales ofreciendo características o información adicionales. Categorías Los cursos se organizan jerárquicamente en categorías, que son únicamente contenedores de cursos, de forma similar a como se organizan los ficheros en un sistema operativo. Pueden contener subcategorías, que a su vez pueden tener otras subcategorías y así sucesivamente. La organización de los ficheros en un disco duro es un símil: las categorías serían como carpetas y lo cursos los ficheros. La estructura jerárquica de los elementos hasta ahora mencionados: Figura 3-2 Jerarquía de categorías y cursos Un curso siempre pertenece a una única categoría. Ni puede pertenecer a más ni no pertenecer a ninguna. La única excepción es la página principal, que internamente se considera un curso que no pertenece a ninguna categoría y que no puede eliminarse. 21 Sistema de información de la ULPGC Figura 4-1 Esquema ULPnet 4.4.2 Servidores El Campus Virtual está montado en una serie de servidores virtuales, duplicados y dotados de balanceadores de carga para garantizar la alta disponibilidad, que se ejecutan sobre un clúster VmWare y se almacenan los datos en un clúster de base de datos MySQL Los servidores están protegidos por cortafuegos redundantes, se realiza copia de seguridad diaria mediante el software Networker y se mantiene una monitorización constante del rendimiento y de la disponibilidad mediante la herramienta Zabbix. 28 Sistema de información de la ULPGC Además, utiliza varios recursos IT adicionales del Servicio de Informática. Así, el acceso se realiza a través de la página Web institucional y el registro y autentificación de los usuarios de todas las plataformas está centralizado en un servidor LDAP. Los estudiantes disponen para su uso en Moodle de una cuenta de correo en un servidor IMAP. Los cuatro servidores físicos tienen las siguientes características: HP Proliant DL580 G5, con 4 procesadores Intel Xeon E7310 @ 1.60Ghz quad-core, con 32 Gb RAM Cada una de las instalaciones mencionadas anteriormente dispone de dos frontales web, con la excepción de la plataforma de apoyo a la enseñanza presencial (con 12 servidores virtuales) y teleformación (4 servidores). En cuanto al backend de bases de datos, es proporcionado por dos servidores en los que hay instalado un clúster MySQL versión 5. Por último, Moodle requiere un espacio de almacenamiento, conocido como directorio de datos, donde almacena físicamente los ficheros utilizados en la plataforma: imágenes, manuales subidos por profesores, tareas realizadas por alumnos, etc. Figura 4-2 Infraestructura de las plataformas del Campus Virtual 29 Sistema de información de la ULPGC 4.4.3 Arquitectura de sistemas del Campus Virtual Paralelamente e interoperando con el Campus Virtual hay otros sistemas en la ULPGC. La siguiente figura muestra los más importantes. Figura 4-3 Arquitectura de sistemas de la ULPGC • El servicio de identificación centralizado controla el acceso al resto de sistemas. • El sistema de información académico comprende las aplicaciones y la base de datos donde se registran las titulaciones que se ofertan, las asignaturas que se imparten, las matrículas de los alumnos, etc. • Mahara es un ePortfolio, donde los estudiantes y profesores pueden reunir sus logros y trabajos realizados, haciéndolos públicos a quien consideren oportuno, pudiendo elaborar su curriculum vitae o mostrar evidencias de conocimientos adquiridos. Campus Virtual (Moodle) Servicio de identificación (CAS) Sistema de información académico (Oracle) ePortfolio (Mahara) 30 5 HERRAMIENTAS Y TECNOLOGÍAS 5.1 SUBVERSION La ULPGC utiliza Subversion como sistema de control de versiones. El código fuente de Moodle se gestiona en Subversion, por lo que su uso es condición indispensable para realizar este proyecto, puesto que las modificaciones se han de realizar siempre sobre la última versión del código de Moodle que esté usando la ULPGC y, al finalizar el proyecto, las extensiones desarrolladas deben estar integradas en Subversion. 5.1.1 Repositorio El repositorio es el núcleo de Subversion, el almacén central de información en forma de árbol jerárquico de directorios y archivos. Los clientes se conectan al repositorio para obtener las distintas versiones del código e información sobre las mismas, así como para hacer públicos los cambios que han realizado. Siguiendo la recomendación de la comunidad Subversion, que se puede considerar un estándar, cada proyecto cuenta con un directorio, y, dentro del mismo, tres subdirectorios: • trunk: línea de desarrollo base, donde tiene lugar el desarrollo principal del proyecto • tags: versiones del proyecto finales, se crean o se destruyen, pero no se modifican • branches: líneas de desarrollo alternativas. Para el desarrollo del proyecto se utilizará la rama branches/moodlepfc, dentro del repositorio destinado al código del Campus Virtual. En el Anexo II se define el protocolo de trabajo a seguir con Subversion. 5.2 ECLIPSE El uso de un entorno de desarrollo integrado, IDE por sus siglas en inglés (Integrated Developmet Environment), aumenta considerablemente la productividad de un desarrollador, principalmente facilitando la edición de código, gestionando el acceso al servidor y mejorando la organización del código. 31 Herramientas y tecnologías Eclipse es, probablemente, el IDE de código abierto más potente y con más usuarios del mercado. Cuenta con numerosas características y es altamente configurable. Hay disponibles una gran cantidad de plugins que amplían su funcionalidad, uno de los cuales, PHP Development Tools (PDT), convierte Eclipse en un formidable IDE para desarrollo PHP. El Anexo III detalla la configuración de Eclipse utilizada para desarrollar este proyecto. 5.3 ENTORNO DE DESARROLLO Para el desarrollo y prueba de las nuevas extensiones de Moodle se utiliza un entorno de desarrollo similar a las instalaciones de Moodle que se encuentran en producción: un entorno LAMP (Linux + Apache + MySQL + PHP) con una instalación de Moodle. La infraestructura física la facilita para el desarrollo de este proyecto el Servicio de Informática (SI) de la ULPGC, habilitando una máquina al efecto y un usuario con permisos de administración con el que podemos instalar una versión de Moodle similar a las que se ofrecen a los usuarios del Campus Virtual de la ULPGC. 5.3.1 PHP PHP es un lenguaje de código abierto del lado del servidor muy potente que se puede utilizar independientemente desde línea de comandos o integrado en un servidor web, permitiendo crear sitios con contenido dinámico. Es un lenguaje interpretado, una ventaja para los programadores, pues evita la necesidad de compilar antes de ejecutar el código; la edición y ejecución del código es mucho más rápida. Para ejecutar Moodle 2.6, versión de Moodle instalada en el Campus Virtual de la ULPGC durante la realización del proyecto, se necesita como mínimo la versión de PHP 5.3.3. La instalación y configuración de PHP corre a cargo del Área de Sistemas del Servicio de Informática de la ULPGC. Como referencia, consultar la documentación oficial de Moodle en el siguiente enlace https://docs.moodle.org/26/en/PHP_settings_by_Moodle_version. 5.3.2 MySQL y SQL MySQL es un sistema de gestión de base de datos relacional (RDBMS). Básicamente, MySQL permite a los usuarios almacenar información en una estructura en forma de tabla, usando filas y columnas para organizar diferentes datos. Hay otros muchos RDBMS, pero esta es la escogida por la ULPGC tanto para sus aplicaciones corporativas como para el Campus Virtual. 32 Herramientas y tecnologías PHP dispone de librerías para interactuar con MySQL, siendo necesario un conocimiento básico de SQL (Structured Query Language) para acceder y/o modificar los datos en MySQL. SQL es un pequeño lenguaje de fácil aprendizaje y uso, que permite: • crear bases de datos • crear tablas en una base de datos • insertar datos en las tablas • obtener datos de las tablas • actualizar datos en las tablas 33 6 DESARROLLO EN MOODLE Moodle ofrece una serie de directrices y guías para el desarrollo de código que se pueden encontrar en la documentación oficial (Moodle, 2014), completando esa información para redactar este capítulo con (Hunt, 2012). En este apartado solo se incluye una pequeña introducción para facilitar la comprensión de las particularidades del desarrollo en Moodle, añadiéndose al final de esta memoria un anexo profundizando en cada aspecto relevante. 6.1 ARQUITECTURA DE MOODLE 6.1.1 Entorno de ejecución El entorno escogido por la ULPGC para dar soporte a su Campus Virtual, siendo a su vez el más extendido, es el conocido como LAMP, framework de código abierto compuesto por Linux (sistema operativo), Apache (servidor web), MySQL (base de datos) y PHP (lenguaje de programación). Este último es el único indispensable, puesto que hay varias alternativas al sistema operativo, el servidor web y la base de datos sobre las que es operativo Moodle. 34 Desarrollo en Moodle Figura 6-1 Entorno de ejecución 6.1.2 Capas de Moodle Moodle se organiza en dos capas para ofrecer su funcionalidad: el código fuente (PHP, HTML, CSS y JavaScript) y los datos, repartidos en la base de datos y los ficheros de datos. Estos componentes pueden estar en un solo servidor, pero en grandes instalaciones, se opta por un entorno con redundancia y balanceo de carga, con varios servidores web con una copia del código y una o varias instancias tanto de la base de datos como de los ficheros de datos. La configuración global de Moodle, donde se especifica donde se encuentran los elementos mencionados, se almacena en un fichero llamado config.php, en el directorio raíz del código fuente. Código fuente El código fuente lo componen las librerías de uso general, los módulos, bloques, plugins y otras entidades. Se almacena en el sistema de ficheros en un directorio conocido como dirroot, que se especifica durante la instalación de Moodle. A continuación se muestra la organización de este directorio: 35 Desarrollo en Moodle Carpeta Funcionalidad admin Administración de Moodle auth Extensiones de autenticación backup Operaciones de copia y restauración blocks Bloques que se pueden colocar en los cursos y en la página principal blog Funcionalidad del blog calendar Gestión del calendario y de eventos cohort Manejo de grupos a nivel de sitio comment Comentarios utilizados en los cursos course Gestión de categorías, cursos y formatos de curso enrol Extensiones de matriculación error Manejo de errores files Gestión de ficheros filter Filtros aplicados a texto creado en el editor integrado grade Gestión de las calificaciones y del libro de calificaciones group Gestión de grupos y agrupamientos install Instalación y actualización de Moodle iplookup Búsqueda de direcciones IP lang Cadenas de idioma; hay una carpeta por cada uno lib Librerías del núcleo de Moodle local Directorio destinado a modificaciones locales login Gestión de acceso y creación de cuentas message Herramienta de mensajería que soporta varios canales mnet Conexión con otras instalaciones de Moodle mod Módulos incluidos por defecto en Moodle my Escritorio personal del usuario, conocido como myMoodle notes Gestión de notas en los perfiles de usuario pix Gráficos genéricos del sitio plagiarism Extensiones de detección de plagio portfolio Extensiones de portfolio que permiten a los usuarios exportar datos question Gestión del banco de preguntas, preguntas y categorías de pregunta rating Puntuaciones utilizadas en foros, glosarios y bases de datos repository Extensiones de repositorio: permiten importar y exportar datos rss Feeds RSS search Búsqueda local de cursos y global del sitio sso Operationes Sigle sign-on tag Etiquetado theme Temas para cambiar la apariencia del sitio user Gestión de usuarios webservice Funcionalidad de Servicios Web Tabla 3 Organización del código fuente Datos En la base de datos se guarda toda la información relacionada con los cursos, usuarios, roles, calificaciones, recursos añadidos por los profesores y la configuración del sistema. Por otro lado, 36 Desarrollo en Moodle los ficheros tales como imágenes, documentos de texto u hojas de cálculo se almacenan en otro directorio de Moodle, conocido como dataroot. Moodle gestiona internamente los ficheros, almacenando su ubicación física e información adicional (como el nombre, licencia, fecha de última modificación, etc.) en una tabla de la base de datos. Manipular ficheros directamente en el sistema de ficheros puede provocar comportamientos inesperados e incluso el mal funcionamiento de Moodle. El directorio de datos, dataroot, donde se almacenan físicamente los archivos subidos a Moodle se organiza en las siguientes carpetas: Carpeta Archivos almacenados filedir Contenido de los usuarios, ficheros subidos por los mismos. repository Ubicación externa accesible desde Moodle search Ficheros temporales creados durante la realización de búsquedas temp Archivos temporales trashdir Ficheros eliminados Tabla 4 Organización del directorio de datos 6.1.3 Moodle como sistema modular Moodle cuenta con un núcleo de aplicación y numerosas extensiones (plugins) que ofrecen funcionalidad adicional. Está diseñado para ser personalizable y añadir capacidades sin modificar las librerías del núcleo, evitando problemas cuando se actualiza la aplicación a una nueva versión. De esta forma, cuando se quiere personalizar o extender una instalación de Moodle, siempre debe hacerse utilizando la arquitectura de extensiones. Este modelo, común a muchos proyectos de código abierto, permite a los usuarios personalizar el sistema ajustándolo a sus necesidades. Moodle cuenta con un núcleo pesado, incluye mucha funcionalidad, y extensiones fuertemente tipadas, dependiendo de la funcionalidad a implementar, es necesario escribir un tipo determinado de extensión. Por ejemplo, un módulo de Actividad será muy diferente de una nueva extensión de Autenticación o un nuevo tipo de pregunta. 37 Desarrollo en Moodle Moodle ofrece una serie de recomendaciones orientadas a la generación de páginas solicitadas por los usuarios. En el caso de los scripts a ejecutar desde consola, habrá que tener en cuenta: • Limitar la cantidad de RAM que consumen, para no saturar el servidor web y finalizar anormalmente la ejecución del script. • Realizar el menor número de consultas necesario a la base de datos. • Minimizar el impacto en el uso cotidiano por parte de los usuarios. 44 7 ANÁLISIS Este apartado contiene la especificación de requisitos y toda la documentación del análisis, a partir de la cual se elaborará posteriormente el diseño. 7.1 DEFINICIÓN DEL SISTEMA El sistema al completo comprende la creación y carga del Data Mart intermedio, con los datos a sincronizar ya procesados, y los scripts de Moodle que realizan la sincronización. Aunque he desarrollado ambos, cada uno de ellos tiene entidad para ser un proyecto por sí mismo y, de hecho, se realizaron como proyectos independientes que luego se integraron. 7.1.1 Determinación del Alcance del Sistema El propósito de este proyecto es el desarrollo de las extensiones necesarias en Moodle para que, a partir de la información contenida en el sistema de información de la ULPGC, el Campus Virtual de la ULPGC sea un reflejo de la realidad académica. En un sistema de información tan complejo son muchas las particularidades a tener en cuenta, escapando muchas de ellas al propósito general de este proyecto, relegándose a desarrollos posteriores. El énfasis de este proyecto recae en el análisis de la información necesaria para cargar correctamente el Campus Virtual y el desarrollo de las extensiones acorde a las directrices de desarrollo de Moodle, de tal forma que su utilidad no se reduzca al ámbito de la ULPGC, sino que puedan ser reutilizados en condiciones similares en otros ámbitos. El proceso de sincronización entre la información de la ULPGC y el Campus Virtual será completamente automático y desatendido, por lo que no se contemplan interfaces de usuario ni la interacción bilateral entre ambos sistemas. Asimismo, nos centraremos en solo una de las plataformas del Campus Virtual, considerando que la aplicación al resto de ellas es similar. Escogemos la plataforma de Grado y Posgrado por ser la más compleja, ya que comprende el mayor número de cursos y usuarios. La información que se sincronizará abarca centros, titulaciones, asignaturas, grupos, profesores, alumnos y matrículas. 45 Análisis 7.2 REQUISITOS DEL SISTEMA 7.2.1 Centros Los centros se encargan de la organización de las enseñanzas y de los procesos académicos, administrativos y de gestión conducentes a la obtención de los títulos. Pueden ser Facultades o Escuelas, estando dirigidas por un decano o director. El primer nivel de organización dentro del Campus Virtual serán los centros. Debe existir una categoría por cada Facultad, Escuela o Instituto que imparta alguna titulación. Identificador F01 Nombre CrearCentro Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Crear una categoría representando un centro en el Campus Virtual Identificador F02 Nombre EliminarCentro Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Eliminar una categoría que represente a un centro del Campus Virtual, eliminando las titulaciones correspondientes 7.2.2 Titulaciones Las titulaciones, articuladas en planes de estudio, son el conjunto de enseñanzas organizadas por una Universidad cuya superación da derecho a la obtención de un título. Son los centros los que ofertan las distintas titulaciones, por lo que cada una de ellas estará asociada a un centro. 46 Análisis Las titulaciones conformarán el segundo nivel en la categorización de los cursos en el Campus Virtual. Deben estar asociadas al centro que las oferta. Cada curso estará en la titulación en la que se imparte la asignatura a la que representa. Existirá una categoría por cada titulación, dentro de la categoría correspondiente al centro que oferta la titulación. Identificador F03 Nombre CrearTitulación Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Crear una categoría que represente una titulación en el Campus Virtual, dentro de la categoría del centro que la oferta Identificador F04 Nombre EliminarTitulación Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Eliminar la categoría que representa la titulación del Campus Virtual, eliminando las asignaturas asociadas 7.2.3 Asignaturas Corresponde a los centros proponer las asignaturas que componen un plan de estudio, estando orientadas al cumplimiento de los objetivos del mismo. Hay que tener presente la existencia de asignaturas vinculadas. Son aquellas que están asociadas a otra asignatura, definida como maestra, que es la que realmente se imparte. Las asignaturas se asignan a los departamentos que se consideren competentes para impartirla. 47 Análisis Todas las asignaturas que se imparten en la ULPGC deben tener presencia en el Campus Virtual, en la forma de cursos. Es importante conocer la relación con el departamento responsable. Para las asignaturas vinculadas no se creará un curso. Identificador F05 Nombre CrearAsignatura Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Añadir un curso que represente una asignatura en el Campus Virtual, asociada la titulación en la que se imparte Identificador F06 Nombre EliminarAsignatura Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Elimina un curso del Campus Virtual 7.2.4 Grupos Los alumnos dentro de cada asignatura se organizan en grupos. Existen dos tipos de grupos: • docencia: útiles para estructurar la impartición de las clases. Divide a los alumnos en varios grupos de teoría y prácticas. Cada grupo de docencia tiene un profesor asignado, encargado de impartir la docencia en el mismo; • actas: orientados a la calificación final de los alumnos por parte de los profesores. No es necesario que tengan un profesor asignado. En cada curso dentro del Campus Virtual deben estar definidos los grupos de las asignaturas. 48 Análisis Identificador F07 Nombre CrearGrupo Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Crea un grupo dentro del curso que representa la asignatura a la que pertenece el grupo, identificándolo como grupo académico Identificador F08 Nombre EliminarGrupo Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Elimina un grupo del curso que representa la asignatura a la que pertenece A cada grupo hay que asignar tanto a los profesores como a los alumnos que correspondan. Identificador F09 Nombre AsignarGrupo Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Asignar los usuarios al grupo 49 Análisis Identificador F10 Nombre DesasignarGrupo Tipo Funcional Fecha 20/03/2013 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Desasignar los usuarios que dejen de pertenecer a un grupo 7.2.5 Usuarios Debe tener acceso al Campus Virtual todo docente y alumno de la ULPGC, autenticándose previamente en el Servicio de Identificación Centralizada. No pueden identificarse ni crear una cuenta directamente en el Campus Virtual. Por el contrario, un alumno que anula matrícula o un profesor que deja de impartir docencia pierde el derecho a acceder al Campus Virtual. No pueden anular su cuenta motu proprio. La sincronización de cuentas se realizará diariamente, de tal forma que un usuario pueda acceder al campus al día siguiente de haber formalizado la matrícula. El proceso se realizará en el horario de menor uso, para reducir el impacto en el rendimiento de la plataforma. Identificador F11 Nombre AltaUsuario Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Creación de cuenta de usuario en el Campus Virtual, con sus datos personales actualizados. Los usuarios no pueden crear cuentas por sí mismos. Si el usuario fue creado manualmente, identificarlo como usuario sincronizado. 50 Análisis Identificador F12 Nombre BajaUsuario Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Eliminar cuenta de usuario en el Campus Virtual. Los usuarios no pueden eliminar su cuenta por sí mismos. Identificador F13 Nombre IdentificaciónUsuario Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Los usuarios se debe identificar en el Servicio de Identificación Centralizada de la ULPGC, no directamente en el Campus Virtual 7.2.6 Matrículas Cada profesor debe poder acceder y modificar aquellos cursos en el Campus Virtual correspondiente a las asignaturas que imparte en la ULPGC. Asimismo, cada alumno debe poder acceder y participar en aquellos cursos que representan a las asignaturas en las que está matriculado. Igualmente, si un alumno causa baja en una asignatura o un profesor deja de tener docencia en una asignatura, se desmatricula del curso correspondiente en el Campus Virtual. 51 Análisis Identificador F14 Nombre MatricularUsuario Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Se matricula el usuario en el curso en el que participa con el rol correspondiente. Si se hubiese matriculado previamente de forma manual, identificar la matrícula como procedente de la sincronización. Identificador F15 Nombre DesmatricularUsuario Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Se desmatricula un usuario de un curso 7.2.7 Global La sincronización de la información se realizará diariamente, de tal forma que los cambios en el sistema de información de la ULPGC se reflejen, como máximo, al día siguiente. El proceso de sincronización se realizará en el horario de menor uso, para reducir el impacto en el rendimiento del Campus Virtual. 52 Análisis Identificador F16 Nombre SincronizaciónDiaria Tipo Funcional Fecha 20/03/2014 Prioridad Alta Necesidad Sí Estabilidad Normal Verificable Sí Descripción Sincronización diaria, en el horario que menos afecte el rendimiento del Campus Virtual 7.3 IDENTIFICACIÓN Y DESCRIPCIÓN DE LOS SUBSISTEMAS Hay dos subsistemas bien diferenciados: • El sistema de información de la ULPGC, en adelante SI de la ULPGC, que proporciona la información académica de la universidad; su gestión queda fuera del ámbito de este proyecto. • Moodle, donde se deben implementar los mecanismos necesarios para cargar la información facilitada por el SI de la ULPGC. 7.3.1 Sistema de Información de la ULPGC Como se mencionó en el apartado 4.3, el SGBD Oracle es la base del sistema de información de la ULPGC. De él habrá que extraer toda la información necesaria para montar la estructura del Campus Virtual. La información académica que requiere el Campus Virtual no se puede obtener directamente de la base de datos institucional, sino que requiere su extracción y transformación antes de poder procesarla. Para realizar esta tarea, será necesario crear un sistema intermedio (Data Mart), donde se almacenará la información procesada para ser directamente integrada en el Campus Virtual. En base a este criterio, diferenciaremos: • Esquemas, tablas y vistas de las que se extrae la información académica que debe reflejarse en el Campus Virtual (cursos, profesores, alumnos matriculados, etc.); • Esquema intermedio con las tablas, vistas y procedimientos utilizados para adecuar la información al formato que requiere el Campus Virtual. 53 Análisis con un script que se puede ejecutar regularmente para crear las nuevas cuentas, concordando con el requisito R05. Además, permite mapear campos de la base de datos externa con valores del perfil del usuario, almacenado en la base de datos de Moodle. De esta forma, se puede identificar qué campos se desea mantener actualizados. Esta extensión cumple con los requisitos R01, R02 y R03. Sin embargo, la autenticación se realiza directamente en Moodle, utilizando la contraseña que el usuario tiene en su perfil o, en caso de tratarse de un usuario nuevo, la contraseña almacenada en la base de datos externa, por lo que no satisface el requisito R04. Conclusión De la evaluación anterior, teniendo en cuenta que la información de los usuarios se almacena en la base de datos institucional pero que la autenticación pasa por utilizar el Servicio de Identificación Centralizada, podemos modificar ligeramente la extensión para usar una base de datos externa, cambiando el proceso de autenticación para utilizar el Servicio de Identificación Centralizada de la ULPGC, tal como implementa la extensión basada en CAS. A esta nueva extensión la denominaremos CASulpgc. 7.3.2.2 Extensiones de matriculación (enrolment) Habilitar la participación de usuarios en cursos se conoce en Moodle como enrol o matriculación. Es, a todos los efectos, el equivalente a la matrícula de un alumno en una asignatura o la asignación de un profesor a un asignatura. En Moodle, la diferencia entre un profesor y un alumno radica en los permisos que tiene el usuario dentro del curso, representados por los roles. Los roles determinan que puede hacer un usuario dentro de un curso. Las extensiones de matriculación controlan qué usuarios están matriculados en qué cursos y con qué roles. Como en el caso anterior, se puede sincronizar con otro sistema, como un sistema de información de estudiantes, o puede ser gestionado internamente por Moodle. Las extensiones de matriculación se encuentran en el directorio enrol. Estado actual Al igual que sucedía con la creación de cuentas de usuario, la matriculación de usuarios en cursos se realiza mediante un proceso de sincronización utilizando una extensión desarrollada a medida, que a partir de un fichero de texto asigna y desasigna roles a los usuarios dentro de un curso. 60 Análisis Este fichero de texto se genera en la base de datos corporativa e incluye la relación de matrículas de alumnos en asignaturas así como la asignación de profesores a las asignaturas. Hay varios problemas asociados a este procedimiento: • todos los días se traspasa la información relativa a matrículas de alumnos y asignación de profesores, lo que implica un procesado considerable; • aunque el proceso está automatizado, implica la creación del fichero de texto en la base de datos corporativa, importarlo al servidor del Campus Virtual y luego procesarlo. En ocasiones este proceso hay que realizarlo manualmente, resultando engorroso; • la extensión está desarrollada para Moodle 1.9.x, por lo que es necesario adaptarla a la nueva versión de Moodle. Extensiones nativas Moodle ofrece varias formas de gestionar la matriculación, utilizando distintas extensiones de matriculación (plugins). Por defecto están disponibles las siguientes: • Matriculación manual - el administrador o gestor del curso añade a los usuarios manualmente • Auto-matriculación - el usuario puede matricularse en un curso • Sincronización de cohorte - los usuarios de una cohorte se matriculan en el curso (las cohortes son un concepto fuera del ámbito de este proyecto) • Metaenlace de curso - matricula automáticamente participantes en un curso en otro • Acceso de invitados - los usuarios pueden acceder al curso sin ser participantes • Categoría de matrícula - los usuarios se matriculan en todos los cursos de una categoría • Base de datos externa - los usuarios se matriculan según la información almacenada en una base de datos externa • Archivo plano (CSV) - los usuarios se matriculan según la información almacenada en un fichero de texto plano • Archivo IMS Enterprise - los usuarios se matriculan según la información almacenada en un fichero con este formato XML estándar 61 Análisis • Matriculaciones LDAP - los usuarios se matriculan según la información almacenada en un directorio LDAP • Matriculaciones remotas MNet - los usuarios se matriculan en base a un sitio Moodle enlazado • Paypal - los usuarios se matriculan tras pagar su inscripción con Paypal. La instalación de Moodle puede tener activas todas las extensiones de matriculación que se precisen, y cada cuenta de usuario debe estar asociada a una de ellas. Además de las extensiones incluidas por defecto, se pueden añadir extensiones de terceros o desarrollarlas a medida. Evaluación de las extensiones nativas Matriculación manual La matriculación de usuarios corre a cargo de un administrador, profesor o gestor del curso. Es una tarea inviable mantener actualizadas todas las matriculaciones de los alumnos y profesores en cada curso, ya que el número de usuarios supera con creces los 20.000 usuarios y el de asignaturas los 4.000. Auto-matriculación Los usuarios pueden matricularse por sí mismos en los cursos. Esto va en contra de los requisitos R01 - R04, que especifican que los usuarios sólo pueden estar en aquellos cursos en los que estén matriculados como alumnos o asignados como profesores. Sincronización de cohorte Las cohortes son grupos de usuarios a nivel de sitio Moodle. Con esta extensión, todos los usuarios pertenecientes a una cohorte se matriculan en un curso. No es aplicable en este modelo. Metaenlace de curso Los usuarios ya matriculados en un curso, se pueden matricular en otro. No es aplicable en este modelo. 62 Análisis Acceso de invitados Cualquier usuario, sin matricularse en un curso, puede acceder al mismo. No cumple con los requisitos R01 - R04. Categoría de matrícula Una categoría engloba un conjunto de cursos. Utilizando esta extensión, los usuarios seleccionados se matriculan en todos los cursos de una categoría. No es aplicable en este modelo. Base de datos externa Esta extensión utiliza una base de datos externa para determinar qué usuarios deben participar en un curso y con qué rol. Este proceso realiza las matriculaciones cuando el usuario se autentica. Si se desea que la actualización de matrículas sea un proceso automático, esta extensión cuenta con un script que se puede ejecutar regularmente para crear las nuevas cuentas, concordando con el requisito R05. Esta extensión cumple con los requisitos especificados. Se estudiará con detenimiento para determinar si es válida sin realizar ninguna modificación. Archivo plano (CSV) La información de las matrículas de los usuarios se obtiene de un fichero de texto plano. Actualmente se utiliza una extensión basada en ésta, como se describe en el apartado Estado actual. Solucionar los problemas que surgen de su uso es una de las motivaciones de este proyecto. Archivo IMS Enterprise Se trata de un fichero de texto con un formato XML reconocido. Incurre en la misma problemática que acarrea el uso de un fichero de texto plano, añadiendo dificultad en su generación y proceso. Matriculaciones LDAP El servidor LDAP de la ULPGC se utiliza únicamente a efectos de identificación, no conteniendo información relativa a las asignaturas en las que está matriculado un usuario, por lo que no se puede utilizar esta extensión, que se basa en la información almacenada en LDAP. 63 Análisis Matriculaciones remotas Mnet Mnet define la conexión entre diferentes instalaciones de Moodle. Este mecanismo no se está utilizando en la ULPGC, por lo que se descarta el uso de ésta extensión. Paypal Este medio de pago no se utiliza en la ULPGC, descartando el uso de esta extensión, que efectúa la matrícula tras realizar un pago en Paypal. Conclusión De la evaluación anterior, teniendo en cuenta que la información de los usuarios se almacena en la base de datos institucional, procedemos a evaluar a fondo el funcionamiento de la extensión Base de datos externa. En el caso de que necesite alguna modificación, se desarrollará una nueva extensión. Extensión de matriculación Base de datos a fondo Son varias las bases de datos que se pueden utilizar con esta extensión, pero nos centraremos exclusivamente en Oracle, utilizada por la ULPGC como sistema gestor de base de datos. Asume la existencia de una tabla que contiene los siguientes campos: • identificador de curso • identificador de usuario • rol del usuario Matriculación y desmatriculación La matriculación de un usuario tiene lugar cuando éste se autentica en Moodle. La extensión intenta automáticamente matricularlo en todos los cursos presentes en la base de datos externa y, opcionalmente, crear los cursos si no existen. Este proceso también desmatricula a los usuarios de los cursos que ya no aparecen en la base de datos externa. Los registros de usuario se etiquetan con la extensión de matriculación utilizada. Por ello, la extensión sólo procederá a desmatricular a aquellos usuarios que hayan sido matriculados utilizando esta extensión en primer lugar. Realizar el proceso de actualización de matrículas cada vez que accede un usuario supone un aumento significativo del tiempo de acceso a la plataforma. Como se mencionó anteriormente, 64 Análisis esta extensión dispone de un script para sincronizar automáticamente las matrículas. Utilizando éste, se evitará el uso de la extensión durante la autenticación. Matriculación y roles Aunque es posible especificar un rol por defecto en la página de configuración de la extensión, se utilizará un campo en la tabla de la base de datos externa para especificar el rol de cada usuario, dado que se van a matricular tanto estudiantes como profesores. Creación de cursos Opcionalmente, los cursos que no existen en Moodle se pueden crear, configurando adecuadamente la extensión, indicando incluso qué formato aplicar al curso y en qué categoría incluirlo. Sin embargo, es una de los requisitos, no de esta extensión sino del sistema en general, que los cursos sean creados con independencia de los usuarios que participen en ellos. Script de sincronización La extensión incluye un script que permite sincronizar todas las matrículas simultáneamente, tanto añadiendo como eliminando matrículas de usuarios. El script se llama sync.php y se encuentra en la carpeta enrol/database/cli. Este script está pensado para ejecutarse desde el cronjob del sistema. Los usuarios deben existir previamente en la plataforma, por lo que es necesario utilizar el script de sincronización similar de la extensión de autenticación utilizada. Una entrada de ejemplo en el cron: # 5 minutes past 4am 5 4 * * * /usr/bin/php -c /path/to/php.ini /path/to/moodle/enrol/database/cli/sync.php Notas: • Si el número de matrículas es muy grande, es conveniente elevar el límite de memoria con el argumento -d memory_limit=256M • Para depurar y mantener un log, se recomienda añadir a la línea de comando -d log_errors=1 -d error_reporting=E_ALL -d display_errors=0 -d html_errors=0 65 Análisis Configurar la sincronización de usuarios En primer lugar es necesaria una tabla en la base de datos externa que contenga un registro por cada matrícula de alumno o asignación de un profesor en una asignatura, con el rol del mismo. Los campos necesarios son: • Un identificador de curso único que coincida con uno de los siguientes campos en la tabla course de la base de datos de Moodle: o idnumber (varchar 100), correspondiente al Número ID del curso o shortname (varchar 255), nombre corto del curso o id (int 10), identificador autonumérico generado cuando se crea el curso • Un identificador de usuario único, que debe coincidir con uno de los siguientes campos en la tabla user en la base de datos de Moodle: o idnumber (varchar 100), correspondiente al Número ID de usuario o username (varchar 100), nombre del usuario en Moodle o email (varchar 100), dirección de correo del usuario o id (int 10), identificador autonumérico generado cuando se crea el usuario • Un identificador de rol único, que debe coincidir con uno de los siguientes campos en la tabla role en la base de datos de Moodle: o shortname (varchar 100), nombre corto del rol o name (varchar 255), nombre real del rol o id, identificador autonumérico generado cuando se crea el rol En Moodle, activar la extensión en Administración del sitio - Extensiones - Matriculaciones - Gestionar plugins de matriculación y a continuación pulsar Configuración. En la página de configuración hay que introducir los datos de conexión con la base de datos externa, así como la tabla en la misma con los datos de las matrículas y la correspondencia entre los campos de la base de datos externa y la base de datos de Moodle. Hay varias opciones para configurar los roles por defecto en caso de que no se especifiquen en la base de datos externa, como gestionar la desmatriculación de usuarios y el manejo de los 66 Análisis cursos ocultos. En principio no son relevantes, salvo la desmatriculación, que trataremos más adelante. Por último se puede configurar la creación automática de cursos. Problemas potenciales • La integridad de la base de datos externa es fundamental. Si los datos se pierden o no se generan correctamente en la base de datos externa, esta extensión por defecto desmatricula a usuarios de los cursos que no están en la tabla, eliminándolos de los grupos en los que estén asignados y borrando su actividad de los módulos que así lo especifiquen. • Relacionado directamente con el apartado anterior, el hecho de que la anulación de matrículas se base en la ausencia de registros, fuerza a comprobar siempre la existencia de los mismos, perjudicando el rendimiento dado el alto número de matrículas gestionadas. • Hay que tener en cuenta que los campos equivalentes entre ambas bases de datos no deben poder ser modificados en Moodle por los usuarios, puesto que podrían generar problemas de seguridad o incurrir en errores durante la sincronización. Por ejemplo, un usuario que modifica el valor de alguno de sus campos al valor del mismo campo de otro usuario válido, podría obtener acceso a cursos en los que está matriculado el usuario suplantado. 7.3.2.3 Resto de entidades a sincronizar Para la gestión de centros, categorías, cursos y grupos no existe un esquema de extensiones, por lo que se desarrollarán extensiones a medida para sincronizar cada uno de estos ítems. La creación de cursos y grupos de forma automática está integrada en la extensión de matriculación, pero en el ámbito de la solución actual es necesario que dispongan de una gestión independiente, puesto que la creación de cursos y grupos se realiza antes de matricular a los usuarios. 7.3.3 Descripción de los Interfaces entre Subsistemas Para la comunicación entre ambos subsistemas se valoraron varias aproximaciones. A continuación explicamos brevemente los principales y, por último, nos centramos en el mecanismo escogido. 67 Análisis Ficheros de texto plano Los ficheros de texto permiten exportar toda la información ya procesada desde la base de datos institucional. El tratamiento de la información se realiza en el SGBD, mucho más potente y rápido que posteriormente en el propio Moodle. En este solo sería necesario crear unas extensiones de identificación y matriculación que integrasen la información contenida en los ficheros de texto. Para acelerar el proceso se utilizan ficheros planos en lugar de otras alternativas más potentes como podría ser XML. Las principales ventajas de este sistema: - la extracción y transformación de la información se realiza en el SGBD, no ralentizando el Campus Virtual y empleando un tiempo menor; - sencillo de implementar; - tanto las extensiones como los scripts utilizan un mecanismo similar para leer los ficheros y gestionar los datos; - independencia en el tratamiento de la información y la carga de la misma. Sin embargo, como se describió al inicio de esta sección, existen algunas desventajas que se consideran suficientes para descartar este mecanismo. Conexión al LDAP institucional La información de los usuarios se encuentra en un servidor LDAP externo. La ULPGC cuenta con un servidor LDAP contra el que se validan los usuarios vía el Servicio de Identificación Centralizada. Sin embargo, no contiene toda la información necesaria para crear una cuenta de usuario ni tampoco indica en qué titulaciones o asignaturas está matriculado un estudiante. Uso de Servicios Web La forma más elegante, directa y en tiempo real de sincronizar ambos sistemas. La versión 2 de Moodle incorpora una capa de Servicios Web muy potente que permite crear cursos, usuarios, realizar matrículas y otras muchas acciones. Sin embargo, las llamadas a estos Servicios Web deberían integrarse en las aplicaciones de gestión de los servicios de Gestión Académica y Ordenación Académica. Es un proyecto que requiere un estudio de viabilidad y una planificación e implantación minuciosas, a realizar paulatinamente, puesto que no se disponen ni de los recursos ni del tiempo suficiente para acometerlo en plazo. 68 Análisis Conexión directa a la base de datos corporativa Estas extensiones consideran que los detalles de las cuentas de usuario y de su relación con las asignaturas están en una base de datos externa a Moodle, de la cual los obtiene y los inserta en la base de datos propia. Los principales inconvenientes: • los procesos para obtener la información y procesarla son muy complejos, puesto que no hay una correspondencia directa entre ambas bases de datos; este problema es resuelto con el uso de vistas o tablas intermedias que faciliten la correspondencia directa. • dada la gran cantidad de usuarios y cursos que se maneja, los recursos necesarios para obtener toda la información de una vez son insuficientes; si por el contrario se realizan varias conexiones, el riesgo de que fallen y el tiempo empleado aumentan considerablemente. Para solventar esta tara, se plantea la carga sistemática de la información diariamete, reduciendo considerablemente la cantidad de información a tratar. Las principales ventajas de usar este mecanismo: • sencillo de implementar: basta con instalar el cliente de la base de datos correspondiente para poder acceder directamente a su información; • altamente configurable: la modificación de las consultas que obtienen la información de la base de datos externa es sencilla, pudiéndose parametrizar en el grado deseado. • ejecución inmediata: no son necesarios pasos intermedios. Directamente se obtiene la información y se procesa. 7.4 ESPECIFICACIÓN DEL PLAN DE PRUEBAS Para validar la adecuación del proyecto a los objetivos perseguidos, diseñamos un plan de pruebas de las extensiones y sus funciones, así como todos los mecanismos que utilizaremos para detectar errores y corregirlos ya en la fase de implementación. Las pruebas contemplarán aspectos tanto de funcionalidad, ya que al ser un proceso automatizado no intervienen usuarios. Se contemplarán tres tipos de pruebas: 69 8 DISEÑO DEL SISTEMA 8.1 ARQUITECTURA DE SISTEMAS Como se describió en el apartado 4.4.3 Arquitectura de sistemas del Campus Virtual, hay tres sistemas involucrados en el proceso de sincronización: Figura 8-1 Sistemas involucrados Realmente la sincronización se realiza con la información almacenada en el Sistema de información académico, pero la extensión de identificación tiene que comunicarse con el Servicio de identificación de la ULPGC para autenticar a los usuarios (requisito F13). 8.1.1 Comunicación con el Sistema de información académico Como se estableció durante la fase de análisis, 7.3.3 Descripción de las interfaces entre subsistemas, la conexión directa a la base de datos institucional es el mecanismo mejor valorado. Moodle incorpora y utiliza la librería de abstracción de base de datos ADOdb. Se empleará la misma para conectarse con la base de datos institucional de la ULPGC. Campus Virtual (Moodle) Servicio de identificación (CAS) Sistema de información académico (Oracle) 77 Diseño del Sistema Rendimiento. Se realizarán el menor número de consultas, a ser posible solo una, para reducir el tiempo de ejecución de cada script de sincronización. Seguridad. La conexión entre ambos sistemas se realiza íntegramente en una red privada a la que no tiene acceso usuarios ajenos al Servicio de Informática. 8.1.2 Comunicación con el Sistema de identificación (CAS) Moodle ya dispone de una extensión de identificación que utiliza CAS como servicio de identificación externo, haciendo uso del cliente oficial de CAS escrito en PHP, phpCAS. Se hará uso del mismo para implementar la nueva extensión de identificación. Figura 8-1 Comunicación entre sistemas 8.2 COMPONENTES DEL SISTEMA DE SINCRONIZACIÓN Dada la estructura de Moodle y las entidades a sincronizar, este servicio se va a ofrecer empleando dos extensiones y cuatro scripts, en total 6 elementos para las 6 entidades a sincronizar. Las entidades a sincronizar son: centros, titulaciones, asignaturas, grupos, usuarios (profesores y alumnos) y matrículas. Los usuarios y las matrículas se pueden sincronizar utilizando tipos de extensiones existentes en Moodle. Para el resto no hay definido ningún tipo de extensión, por lo que se utilizarán scripts en PHP, utilizando la API de Moodle. Tanto los scripts como las extensiones son independientes entre sí, tanto por solicitud de los usuarios como por la propia arquitectura de Moodle: no existe ninguna relación ni interoperabilidad entre ellos. De hecho podrían utilizarse independientemente en diferentes instalaciones. Sin embargo, es necesario matizar que sí existe una fuerte relación entre las diferentes entidades 78 Diseño del Sistema En las últimas versiones de Moodle se tiende a que toda funcionalidad añadida tenga la forma de extensiones. En esta línea, los scripts de sincronización que no tienen un tipo de extensión equivalente se agruparán en una extensión de tipo Local. En la siguiente figura se estable la correlación entre las entidades a sincronizar y el medio propuesto a tal fin. Figura 8-2 Relación de entidades a sincronizar y componentes del sistema 8.2.1 Elementos comunes a todas las extensiones Configuración Los valores de configuración del sistema de sincronización no se introducirán utilizando la interfaz de usuario, por motivos de seguridad. En las distintas instalaciones de Moodle del Campus Virtual de la ULPGC hay varios administradores, con acceso global a todo el sistema. No es recomendable que puedan acceder y modificar esta extensión, ya que obtendrían información ajena a Moodle que podría facilitar el acceso al sistema de información de la ULPGC y podrían configurar incorrectamente el sistema de sincronización, con el siguiente malfuncionamiento del mismo. Todo el código se versiona en Subversion salvo el fichero de configuración (config.php), por lo que si se añadiese un fichero de configuración local se podría acceder al mismo desde Subversion. Las dos opciones son añadir un fichero local y cambiar la política de uso de Subversion o añadir las variables de configuración al fichero config.php, utilizando la variable global $CFG. Dado que esta última práctica ya se utiliza con otros fines, y solo las personas con 79 Diseño del Sistema acceso físico a la máquina podrían ver este fichero, se opta por incluir los valores de configuración del sistema de sincronización en el fichero config.php. Versión de la extensión Para asegurar la compatibilidad de una extensión con la instalación de Moodle, así como para detectar cuándo es necesaria una actualización, se incluye un fichero en la carpeta de la extensión llamado version.php, un fichero estándar PHP, que empieza con la etiqueta <?PHP, no se cierra con la correspondiente etiqueta (?>), y define las siguientes variables: • $plugin->version o Obligatorio. Número de versión de la extensión con el formato YYYYMMDDxx, donde xx es el número de versión de ese día en concreto. • $plugin->requires o Opcional. Versión mínima de Moodle que requiere la extensión. Consultar la página http://docs.moodle.org/dev/Releases para identificar los números de versión de Moodle. • $plugin->cron o Opcional. Intervalo de tiempo entre las llamadas a la función cron de la extensión. Definido a 0 desactiva la ejecución de la misma. • $plugin->component o Opcional. Nombre frankenstyle de la extensión, muy recomendado (ver http://docs.moodle.org/dev/Frankenstyle). Utilizado para diagnósis de instalación y actualización. • $plugin->maturity o Opcional. Estabilidad de la extensión: MATURITY_ALPHA, MATURITY_BETA, MATURITY_RC, MATURITY_STABLE • $plugin->release o Opcional. Número de versión en un formato simplificado, más sencillo de manejar. • $plugin->dependencies 80 Diseño del Sistema o Opcional. Lista de otras extensiones que requiere este plugin para trabajar. Ejemplo: array(‘mod_forum’=>ANY_VERSION, ‘mod_data’ => 2010020300). Base de datos Si la extensión utiliza nuevas tablas o modificar tablas en la base de datos, incluirá los ficheros db/install.xml y db/upgrade.php respectivamente: • db/install.xml: fichero en formato xml describiendo las tablas y campos que requiere la extensión. • db/upgrade.php: código para modificar las tablas de la extensión. Idioma Los paquetes de idiomas se incluyen en la carpeta lang. El paquete de idioma de un módulo es una carpeta con el nombre xx_utf8, incluyendo en el mismo una carpeta llamada help (contiene los ficheros de ayuda del módulo) y un archivo con el mismo nombre del módulo. xx es el código de dos caracteres del idioma, por ejemplo, en (inglés), es (español), fr (francés). Scripts de línea de comandos Los scripts que se ejecutan desde línea de comandos se almacenan en la carpeta cli dentro de la carpeta principal de la extensión. 8.2.2 Extensión local: sincronización de centros, titulaciones, asignaturas, grupos, asignación de grupos Para la sincronización de los centros, titulaciones, asignaturas y grupos no existen extensiones propiamente definidas en Moodle. Hay algunas aproximaciones que permiten, por ejemplo, crear categorías y cursos (equivalente en Moodle a las titulaciones y asignaturas respectivamente) a partir de un archivo Excel, de poco utilidad en este caso. Para estos scripts crearemos una extensión local, aquellas que no coinciden con ningún tipo de extensión definido. Siguiendo la nomenclatura Frankenstyle, se llamará local_sinculpgc (al no coincidir con los tipos de extensión existentes se incluye en el directorio local de Moodle) y se almacenará en local/sinculpgc. 81 Diseño del Sistema Diseño de la base de datos Los centros no existen en Moodle. Para poder almacenarlos es necesario crear una nueva tabla. El uso de esta tabla en el entorno del Campus Virtual no compete a este proyecto, por lo que durante la realización del mismo no fue necesario establecer ninguna relación con el resto de tablas. centres PK id code name director secretary Figura 8-2 Tabla de centros Las tablas para el resto de entidades ya existen: • course_categories: tabla de categorías. Las titulaciones en Moodle se crearán como categorías. • course: tabla de cursos. Las asignaturas en Moodle se crearán como cursos. • groups: tabla de grupos, donde se crearán los grupos de las asignaturas. • groups_members: relación de alumnos asignados a los grupos de asignaturas. 82 Diseño del Sistema Figura 8-3 Tablas de Moodle implicadas en la sincronización Utilizando la API de Moodle, en la mayoría de las ocasiones, la estructura de la base de datos es transparente para el desarrollador. Diagrama de flujo Los scripts para la creación de centros, titulaciones, asignaturas y grupos siguen un esquema similar al que se muestra en el siguiente diagrama de flujo. Los registros en la base de datos institucional indican si el registro se debe insertar, actualizar o eliminar, por lo que la acción a realizar ya está determinada antes de comenzar el proceso de sincronización. 83 Diseño del Sistema Dado que en las plataformas del Campus Virtual se pueden realizar acciones sin que la base de datos institucional tenga constancia, por ejemplo, desmatricular a un alumno de un curso, siempre es necesario comparar la información en el Campus Virtual con la información en la base de datos institucional. Figura 8-4 Diagrama de flujo de datos general scripts extensión local Los procesos de insertar y eliminar no son similares, por lo que se desgranan en diferentes flujos de datos para cada entidad. 84 Diseño del Sistema Figura 8-5 Diagrama de flujo de datos Insertar Centro Figura 8-6 Diagrama de flujo de datos Eliminar Centro Las entidades existentes en el Campus Virtual no se eliminan cuando no están en la base de datos institucional, sino que se ocultan para evitar pérdida de información en caso de tratarse de un error o volver a estar presentes en la base de datos institucional. Por ejemplo, si una titulación se elimina en las aplicaciones corporativas por error, se eliminaría también del Campus Virtual junto con todas sus asignaturas. En lugar de esto, se oculta la categoría y los cursos que contiene, solo siendo visible a los administradores. De esta forma, al detectar el error y corregirlo en las aplicaciones de gestión, en el Campus Virtual solo es necesario volver a poner visible la categoría correspondiente a la titulación, así como los cursos, y no habría pérdida de información. 85 Diseño del Sistema 4. Para configurar la extensión utilizando la interfaz de usuario, hay que implementar los métodos config_form() y process_config(). A los ajustes de configuración se podrá acceder desde la página (Administración del sitio - Extensiones - Identificación - CASULPGC), siendo los valores de configuración almacenados en la tabla config_plugins. La página de configuración es un fichero en formato html que se debe incluir en el directorio de la extensión, con el nombre config.html. Básicamente será un formulario con las opciones de configuración de la extensión. Base de datos La información de los usuarios, conteniendo tanto lo datos personales como la extensión de identificación que utilizan, se almacena en la tabla user. La interacción con esta tabla se realiza íntegramente utilizan la API de Moodle. 92 Diseño del Sistema 93 Diseño del Sistema Figura 8-18 Tabla de usuarios de Moodle Localización de la extensión Por defecto, nuestro plugin aparecerá como [[auth_casulpgc]]. La asignación de nombres a las identificaciones se realiza creando un fichero de idioma para la extensión. Creamos el directorio /auth/casulpgc/lang/ y dentro de éste un directorio por cada idioma que se precise, por ejemplo, /auth/casulpgc/lang/es. Dentro de estos directorios se crea un archivo auth_casulpgc.php, en el que se asigna la cadena que queramos se muestre en el menú anterior a la variable $string[‘pluginname’]. La descripción de la extensión se asigna a $string[‘auth_casulpgcdescription’]. Hay definidas otra serie de variables a las que se puede asignar la cadena de texto en el idioma adecuado. 8.2.4 Extensión de matriculación Para corregir los problemas descritos en el análisis detallado de la extensión Base de datos, cuya funcionalidad cubre en buena medida los requisitos especificados, desarrollamos una nueva extensión. No se realizan las modificaciones sobre la misma para evitar problemas cuando se realicen actualizaciones de código o cambios de versión. La matrícula da a los usuarios los siguientes privilegios: • Un usuario con matrícula activa puede acceder a un curso. Los usuarios que no tienen, requieren acceso de invitado o el permiso moodle/course:view. • La página “Mis cursos” muestra una lista de todas las matrículas activas del usuario. • Participación en el curso - algunas actividades restringen la participación a usuarios matriculados exclusivamente. • Solo los usuarios matriculados pueden ser miembros de grupos. • El libro de calificaciones contempla a los alumnos matriculados, controlándose por el rol de los usuarios la visibilidad de las calificaciones. Las matrículas y la asignación de roles son conceptos separados. Es posible estar matriculado en un curso y no tener ningún rol asignado y viceversa. Los roles a nivel de curso y por debajo se pueden controlar por las extensiones de matriculación. 94 Diseño del Sistema Estructura de la extensión Todas las extensiones de matriculación deben extender la clase enrol_plugin, definida en lib/enrollib.php, que contiene todos los métodos estándar. Figura 8-19 Diagrama de clases extensión de matriculación Base de datos La información de las matrículas de los cursos se almacena en las tablas enrol y user_enrolments, estando el rol asociado en la tabla role_assignments. Opcionalmente se utilizan otras tablas definidas por diferentes extensiones de matriculación. Cada extensión controla todos sus registros y las matrículas de los usuarios; por defecto, las matrículas de usuario están protegidas y no pueden ser modificadas manualmente por los profesores. Figura 8-20 Tablas relacionadas con la matriculación Suspensión y expiración de una matrícula Una matrícula se considerará activa si cumple todas las condiciones siguientes: 95 Diseño del Sistema - existe un registro para el usuario en la tabla user_enrolments, - la matrícula está vigente, es decir, entre las fechas enrolstartdate y enrolenddate, - la matrícula del usuario está activa (status) - el tipo de matrícula está activa en la tabla enrol (campo status) - la extensión de matriculación está activada 8.2.5 Secuencia de ejecución Existe una clara dependencia entre las diferentes entidades, por lo que es forzoso seguir un orden en el proceso de sincronización. No sería lógico intentar matricular alumnos en un curso que todavía no se ha creado o intentar asignar un grupo en una asignatura a un alumno que no se ha matriculado. El script que automatice el proceso debe tener en cuenta esta restricción. Hay que matizar que la ejecución de los scripts o el uso de las extensiones si es autónomo, su funcionamiento será totalmente correcto aunque se ejecuten de forma independiente. Pero los resultados pueden no ser los esperados sin no existen los elementos correspondientes. Para crear un grupo tiene que existir el curso, para asignar un usuario a un grupo tiene que existir previamente, etc. Figura 8-21 Secuencia de ejecución de los scripts de sincronización centros categorías cursos grupos usuarios matrículas asignación grupos 96 Diseño del Sistema 8.3 ESPECIFICACIÓN TÉCNICA DEL PLAN DE PRUEBAS El proceso de pruebas se extiende durante todo el proceso de construcción del software. En esta sección se describe cómo se van a aplicar las pruebas diseñadas. El entorno en el que se ha realizado el desarrollo es similar en prestaciones al entorno de producción. La principal diferencia es que no hay balanceo de carga, pero en este caso no es significativo porque el proceso de sincronización se ejecutará en un solo nodo, no existiendo en ningún caso balanceo de carga. 8.3.1 Pruebas Unitarias Para la realización de las pruebas descritas en el apartado 7.4.1 Casos de prueba, se crearán los registros pertinentes en la base de datos desde la que se extrae la información. Al ser una base de datos dedicada a la sincronización del Campus Virtual, es posible insertar, eliminar y modificar registros con total libertad. Hay un mecanismo que generará la información real a sincronizar en un corto periodo de tiempo, acción que se llevará a cabo una vez finalizadas las pruebas y verificado el correcto funcionamiento del proyecto. Una vez implementado cada uno de los scripts y extensiones, se realizarán las pruebas correspondientes a cada uno de ellos. Para reutilizar los mismos casos de prueba, se reseteará el estado de Moodle al estado inicial. El proceso de realización de las pruebas se resume en los siguientes pasos: 1. Implementación del script o extensión. 2. Preparar base de datos institucional con los registros necesarios. 3. Ejecutar el script o extensión. 4. Verificar en la plataforma que los resultados son los esperados. 5. Pasar al siguiente script o extensión. Notar que, como se indicó en el apartado 8.2.5 Secuencia de ejecución, la ejecución de los scripts y/o extensiones durante el proceso de pruebas tiene que seguir el orden establecido, debido a la dependencia existente entre los diferentes elementos que se crean en la plataforma (un usuario debe existir antes de poder matricularse). Centros Se necesitan los siguientes registros en la vista de centros (VMOCENTROS): 97 Diseño del Sistema - varios registros de inserción de centros que no existen en Moodle; - un registro de inserción de un centro que ya existe en Moodle, para verificar que no se inserta dos veces; - un registro de eliminación de un centro que no existe, transparente para el sistema; - un registro de eliminación de un centro previamente creado en Moodle. Categorías Se necesitan los siguientes registros en la tabla de titulaciones (TMOCATEGORIAS): - varios registros de inserción de titulaciones que no existen en Moodle; - un registro de inserción de una titulación que ya existe en Moodle, para verificar que no se inserta dos veces; - un registro de eliminación de una titulación que no existe en Moodle, transparente para el sistema; - un registro de eliminación de una titulación previamente creada en Moodle. Cursos Se necesitan los siguientes registros en la tabla de asignaturas (TMOCURSOS): - varios registros de inserción de asignaturas que no existen en Moodle; - un registro de inserción de una asignatura que ya existe en Moodle , para verificar que no se inserta dos veces; - un registro de eliminación de una asignatura que no existe, transparente para el sistema; - un registro de eliminación de una asignatura previamente creada en Moodle. Grupos Se necesitan los siguientes registros en la tabla de grupos (TMOGRUPOS): - varios registros de inserción de grupos que no existen en Moodle; - un registro de inserción de un grupo que ya existe en Moodle, para verificar que no se inserta dos veces; - un registro de inserción de un grupo creado en Moodle manualmente, para verificar que se convierte en grupo académico; 98 Diseño del Sistema - un registro de eliminación de un grupo que no existe, transparente para el sistema; - un registro de eliminación de un centro previamente creado en Moodle. Asignaciones de grupo Se necesitan los siguientes registros en la tabla de asignación de grupos (TMOGRUPOSUSUARIOS): - varios registros de inserción de asignaciones no realizadas en Moodle; - un registro de eliminación de una asignación previamente creada en Moodle; - un registro de inserción de asignación en un grupo que no existe en un grupo, transparente para el sistema. Extensión de identificación Se necesitan los siguientes registros en la tabla de usuarios (TMOUSUARIOS): - varios registros de inserción de usuarios que no existen en Moodle; - un registro de inserción de un usuario que ya existe en Moodle, procedente de sincronización; - un registro de inserción de un usuario que ya existe en Moodle, creado manualmente; - un registro de eliminación de un usuario que existe en Moodle, procedente de sincronización; - un registro de eliminación de un usuario que existe en Moodle, creado manualmente. Extensión de matriculación Se necesitan los siguientes registros en la tabla de matrículas (TMOMATRICULAS): - varios registros de inserción de matrículas que no existen en Moodle; - un registro de inserción de una matrícula que ya existe en Moodle, procedente de sincronización; - un registro de inserción de una matrícula que ya existe en Moodle, creada manualmente; - un registro de eliminación de una matrícula que existe en Moodle, procedente de sincronización; - un registro de eliminación de una matrícula que existe en Moodle, creada manualmente. 99 Diseño del Sistema 8.3.2 Pruebas de Integración y del Sistema La ejecución de todos los escenarios anteriores conjuntamente, no uno a uno, sino en bloque, ya supone una prueba de integración y de sistema, puesto que los scripts se integran en Moodle desde el inicio, para poder utilizar el esquema de extensiones y la API, y la dependencia entre los diferentes elementos fuerza que no se puedan probar de forma totalmente independiente, aunque, como se mencionó anteriormente, se pueden ejecutar por separado con éxito. 100 9 IMPLEMENTACIÓN DEL SISTEMA En este capítulo se recoge información relevante sobre la implementación del sistema, detalles que pueden facilitar la compresión de la solución desarrollada. En el soporte digital que acompaña esta memoria está disponible todo el código fuente correspondientemente comentado. 9.1 PREPARACIÓN DEL ENTORNO El Servicio de Informática de la ULPGC facilita un entorno similar al de producción del Campus Virtual. Se solicita la instalación del cliente Oracle y habilitar conexión directa desde servidor donde se encuentra instalado el código fuente de Moodle a la base de datos institucional. En el entorno de producción solo se utilizará un frontal para la sincronización, por lo que no es necesario disponer de un sistema redundante con balanceo de carga. Como ya se describió con detalle en los apartados 4.4 Arquitectura física del Campus Virtual de la ULPGC y 6.1 Arquitectura de Moodle, Moodle precisa de un servidor web, una base de datos y un directorio de datos, que pueden estar en una sola máquina o en diferentes servidores, como es el caso, para mejorar el rendimiento. En el caso de la ULPGC, para la identificación de los usuarios hay que habilitar la conexión con un servidor CAS y, para la sincronización, con la base de datos institucional. 101 Implementación del Sistema })), $categoriascv); $categoriasdel = array_intersect(array_keys(array_filter($categoriasulpgc, function ($obj) { if ($obj->estado == 'D') return true; })), $categoriascv); $categoriaskeys = array_merge($categoriasadd, $categoriasdel); $categorias = array_intersect_key($categoriasulpgc, array_flip($categoriaskeys)); // TRATAMIENTO DE CADA REGISTRO foreach ($categorias as $categoria) { // Categoría a añadir if ($categoria->estado == 'I') { … } if ($categoria->estado == 'D') { … } Cabecera En primer lugar hay que definir la constante CLI_SCRIPT, que indica a Moodle que se trata de un script de consola. En caso contrario fallará la ejecución del mismo. Seguidamente se incluye siempre el fichero config.php, que carga las librerías del núcleo y carga las variables globales. A continuación se cargan las librerías necesarias para cada script. 108 Implementación del Sistema Contadores Definición de los contadores que se utilizarán para registrar las modificaciones realizadas por el script. Gestión de registros En estas líneas se obtienen los registros de la base de datos externa, los registros en el Campus Virtual y se comparan: • los categorizados para insertar en la base de datos externa y no existen en el Campus Virtual, se insertan en el Campus Virtual. • los categorizados para eliminar en la base de datos externa y que existen en el Campus Virtual, se eliminan en el Campus Virtual. Con el fin de optimizar el rendimiento, se realiza una única consulta a la base de datos externa y se utilizan las potentes funciones de arrays de PHP, ganando en velocidad y facilidad de manejo. Se comparan los identificadores únicos de cada registro, que coinciden tanto en la base de datos externa como en Moodle. Tratamiento de cada registro Cada registro se trata individualmente, ya sea una nueva inserción o una eliminación. En el caso de que se intente crear una entidad que ya existe o eliminar una que no existe, se pasa al siguiente registro. Antes de insertar o eliminar cada entidad puede ser necesario realizar algunas comprobaciones y definir algunos valores que no provienen de la base de datos externa. De la misma forma, una inserción o eliminación en ocasiones acarrea operaciones adicionales. En el código fuente se comentan todas estas situaciones. 9.5 EXTENSIÓN DE IDENTIFICACIÓN Las extensiones de identificación son extensiones de la clase auth_plugin_base. La clase, siguiendo la convención de Moodle, se llamará auth_plugin_casulpgc y se define en el archivo /auth/casulpgc/auth.php. A continuación se detallan los detalles de la implementación más relevantes. 109 Implementación del Sistema Figura 9-4 Estructura de archivos extensión identificación 9.5.1 Configuración de la extensión config.html Página ubicada en /auth/casulpgc/ con las opciones de configuración de la extensión. Esta página se muestra cuando el usuario accede a Administración del sitio - Extensiones - Identificación – Gestionar identificación – CAS ULPGC (SSO). Contiene un formulario web, mayormente escrito en HTML, donde el administrador introducirá los parámetros de conexión al servidor CAS. 110 Implementación del Sistema process_config Es un método de la clase que procesa y almacena los valores de configuración introducidos en la página de configuración de la extensión. … if (! isset ( $config->removeuser )) { $config->removeuser = 0; } if (!isset($config->logout_return_url)) { $config->logout_return_url = ''; } … 9.5.2 Autenticación El proceso de autenticación, descrito en 8.2.3 Extensión de identificación, es independiente de la base de datos externa. Verifica que el usuario existe en Moodle y que ha iniciado sesión en el servidor CAS. loginpage_hook Este es el método de cada extensión que invoca la página /login/index.php, donde se puede modificar el comportamiento del proceso de identificación. Para cumplir con el requisito F13, solo se permite el acceso previa autenticación en el servidor CAS, por lo que se chequea tal condición y, si no se cumple, se envía al usuario a la página del Servicio de identificación centralizada de la ULPGC. En caso de que el usuario esté autenticado en el CAS, pero no tenga cuenta en la instancia de Moodle, se le reenvía a una página indicándole esta condición. if (phpCAS::checkAuthentication ()) { $frm = new stdClass (); $frm->username = phpCAS::getUser (); $user = get_complete_user_data ( 'username', $frm->username); 111 Implementación del Sistema if ((! $user) || (($user->auth != 'casulpgc') && ($user->auth != 'manual'))) { redirect ( $CFG->wwwroot . '/auth/casulpgc/noexiste.php' ); } return; user_login Este método devuelve verdadero si el usuario se identifica correctamente. De acuerdo al requisito F13, esta autenticación se realiza en el servidor CAS, por lo que se redirige al mismo al usuario no autenticado. Una vez autenticado, el propio servidor CAS devuelve el control a Moodle. Se apoya en el método connectCAS, que crea un cliente y establece la conexión con el servidor CAS. function user_login($username, $password) { $this->connectCAS (); return phpCAS::isAuthenticated () && (trim ( core_text::strtolower ( phpCAS::getUser () ) ) == $username); } function connectCAS() { … if (! $connected) { if ($this->config->proxycas) { phpCAS::proxy ( $this->config->casversion, $this->config- >hostname, ( int ) $this->config->port, $this->config->baseuri, false ); } else { phpCAS::client ( $this->config->casversion, $this->config- >hostname, ( int ) $this->config->port, $this->config->baseuri, false ); } $connected = true; 112 Implementación del Sistema } … } logoutpage_hook Esta función modifica el comportamiento al finalizar la sesión. En concreto, se cierra la sesión también en el servidor CAS al cerrar la sesión en el Campus Virtual. Se utiliza la API de CAS para PHP, especificando la página a la que se reenvía al usuario tras las desconexión: … $this->connectCAS (); $redirect = phpCAS::getServerLogoutURL () . '?service=' . urlencode ( $this- >config->logout_return_url ); … 9.5.3 Sincronización con la base de datos externa Es necesario crear las cuentas de los usuarios de la plataforma, tanto estudiantes como profesores, a partir de la información en la base de datos corporativa. Éste procedimiento se ejecutará de forma automática diariamente, en un horario que no afecte al rendimiento de los sistemas implicados, o manualmente. sync_users.php Este es el script que se invoca desde línea de comandos para iniciar la sincronización de usuarios. Al tratarse de un script de línea de comandos, se ubica en la carpeta auth/casulpgc/cli. En última instancia, invoca al método sync_users. sync_users Gestiona la conexión a la base de datos externa y la creación/eliminación de cuentas. Tiene una estructura similar a los scripts de la extensión local, pero, por convención, la sincronización de usuarios es un método de la clase de identificación. 113 Implementación del Sistema La extensión se puede configurar para que elimine las cuentas definitivamente o solamente que las suspenda. Dada esta posibilidad, siempre se verificará, antes de realizar ninguna acción, si la cuenta del usuario ya existe en Moodle. ... // Verificar existencia de la cuenta del usuario $existing_user = $DB->get_record ( 'user', array ( 'username' => strtolower ( $user- >username )) ); ... Cuando la cuenta del usuario ya existe, hay dos posibilidades: • Si no utiliza esta extensión de identificación, se le asigna. De esta forma se controla a los usuarios que provienen de la base de datos externa. • Si la cuenta está suspendida, se reactiva. Si la cuenta del usuario no existe, se crea, con la información personal de la base de datos externa y una serie de valores por defecto. Al eliminar una cuenta solo hay que tener en cuenta la configuración al respecto, eliminándose la cuenta definitivamente o suspendiéndola, según corresponda. 9.6 EXTENSIÓN DE MATRICULACIÓN Se duplica la carpeta de la extensión Base de datos externa, llamándola sinculpgc, y, para que Moodle lo reconozca como una nueva extensión de matriculación, modificamos el nombre de la clase en el fichero enrol/sinculpgc/lib.php, denominándola enrol_sinculpgc_plugin. 114 Implementación del Sistema Figura 9-5 Estructura de archivos extensión matriculación 9.6.1 Sincronización con la base de datos externa Esta es el principal objetivo de la extensión. Al igual que la extensión de identificación, hay un script que se ejecuta desde línea de comandos que invoca el método de la clase que realizar la sincronización. sync.php Al ejecutarse desde línea de comandos, se ubica en enrol/sinculpgc/cli. sync_enrolment Sigue el esquema del resto de scripts. Utilizando arrays se determinan los registros a tratar, para lo cual se emplea la API de enrol de Moodle. Adicionalmente es necesario definir tres métodos de la clase para facilitar su administración: • instance_deleteable($instance): indica si se permite eliminar este método de matriculación de un curso; 115 Implementación del Sistema • allow_unenrol_user(stdClass $instance, stdClass $ue): para desmatricular usuarios desde la interfaz de la aplicación; • get_user_enrolment_actions(course_enrolment_manager $manager, $ue): devuelve las acciones que puede realizar un usuario sobre una matriculación de esta extensión. access.php En este archivo se define un array con las nuevas capacidades inherentes a esta extensión. Las capacidades se asignan a los roles para permitir realizar determinadas acciones a los mismos: - enrol/sinculpgc:config: configuración de la extensión; - enrol/sinculpgc:manage: gestión de las instancias de la extensión; - enrol/sinculpgc:enrol: matricular usuario; - enrol/sinculpgc:unenrol: desmatricular usuario. 9.7 EJECUCIÓN COMPLETA DE LA SINCRONIZACIÓN Los scripts de sincronización deben ejecutarse secuencialmente, siguiendo el orden establecido en 8.2.5 Secuencia de ejecución. En la extensión local se ubica el archivo local/sinculpgc/cli/sincro.php, responsable de esta tarea. En función de la plataforma en la que se realice la sincronización, determina que entidades (scripts) deben sincronizarse y cuáles no. Este script debe ejecutarse desde el cron del sistema de uno de los servidores de cada plataforma a sincronizar. 116 10 EJECUCIÓN DE LAS PRUEBAS Para facilitar la realización de las pruebas se ha desarrollado un script (local/sinculpgc/cli/restoremoodlepfc.sh) que permite reiniciar la plataforma al estado inicial, de tal forma que cada prueba sea independiente de la anterior. El procedimiento a seguir es el siguiente: - realizar una instalación limpia de Moodle; - hacer una copia de la base de datos y del directorio de datos; - ubicar ambas copias en la misma carpeta que esté el script de restauración; - realizar la prueba; - verificar resultado en la plataforma; - ejecutar el script de restauración. El script se ha desarrollado a medida para el entorno de la ULPGC, por lo que solo contempla MySQL como SGBD. La ejecución del mismo elimina la base de datos y el directorio de datos, creándolos de nuevo a partir de las copias realizadas tras la instalación de la plataforma. Como se detalló anteriormente, existe dependencia entre las diferentes entidades que se sincronizan. Por esta razón las pruebas se realizaron de forma incremental, añadiendo paulatinamente la sincronización de nuevos elementos. De esta forma, la secuencia de ejecución de las tandas de pruebas fue la siguiente: - sincronización de centros; - sincronización de centros y titulaciones; - sincronización de centros, titulaciones y asignaturas; - sincronización de centros, titulaciones, asignaturas y grupos; - sincronización de centros, titulaciones, asignaturas, grupos y usuarios; - sincronización de centros, titulaciones, asignaturas, grupos, usuarios y matrículas; 117 Ejecución de las pruebas Verificar restricción acceso El usuario, sin estar autenticado en CAS , fue redirigido a la página de identificación. Tras aut enticarse se redirige al Campus Virtual. Caso de Prueba: CP5.6 Entrada Resultado Obtenido Matricular usuario en curso El usuario está matriculado en el curso y pudo acceder. Caso de Prueba: CP5.7 Entrada Resultado Obtenido Desmatricular usuario de curso El usuario dejó de estar matriculado y no puede acceder al curso. 124 11 CONCLUSIONES Y LÍNEAS DE TRABAJO FUTURAS 11.1 CONCLUSIONES Este proyecto se realizó como parte de un proyecto de mayor tamaño que abarcaba la puesta en marcha del Campus Virtual de la ULPGC 2014/15. A mediados de julio del 2014 ya estaban instaladas las nuevas plataformas, y se utilizó este proceso de sincronización para cargar la información académica en las mismas. En ese momento se cargaron los centros, titulaciones, asignaturas, grupos y se dieron de alta y asignaron a sus titulaciones y grupos los profesores. En septiembre, poco antes del inicio de las clases, se dieron de alta y asignaron a titulaciones y grupos también los alumnos. Desde entonces está en funcionamiento el proceso de sincronización, ejecutándose a diario en las plataformas siguientes: • Grado y Posgrado • Teleformación • Otras enseñanzas • Social El número de incidencias relacionadas con la sincronización se han reducido en un 100% con respecto al curso académico 2013/14. Todas las incidencias hasta el momento han tenido causa académica o en las especificaciones de cómo determinar la información a sincronizar. Además, se han solventado otros problemas recurrentes en cursos anteriores: • notable reducción en el tiempo de ejecución, facilitando su ejecución manual en caso de querer sincronizar una plataforma antes de la hora programada; • un fallo en la sincronización (caída de base de datos local, error en acceso a base de datos externa, etc.) no implica trabajo adicional. Basta con relanzar el proceso. 125 Conclusiones y líneas de trabajo futuras Un beneficio adicional es el ahorro de recursos en la resolución de incidencias. Los problemas de sincronización en cursos anteriores demandan la atención del personal y la consiguiente inversión de tiempo, que ralentizaba o impedía la realización de otros proyectos. La validez de la información académica en las plataformas del Campus Virtual incluso está creando la tendencia entre los usuarios de utilizarlo como referencia en lugar de otras herramientas disponibles: listados de alumnos, calificaciones, pertenencia a grupos, etc. A su vez, esta misma tendencia obliga a garantizar que el proceso de sincronización se mantiene a este nivel y, en la medida de lo posible, mejore. 11.2 LÍNEAS DE TRABAJO FUTURAS Actualmente se sigue mejorando el proceso de sincronización, añadiendo más información o nuevas características. Las principales líneas de trabajo son las siguientes: • Nueva información: se añade información a las entidades que ya se sincronizan, como por ejemplo identificar alumnos morosos o añadir carga docente de los profesores, y nuevas entidades, como los departamentos. • Sincronización desde interfaz de usuario: de esta forma los administradores de cada plataforma podrían lanzar el proceso de sincronización manualmente, sin requerir la intervención de los administradores de sistemas. • Opciones de configuración: las opciones de configuración en este versión son bastante limitadas. Los valores por defecto de las entidades que se sincronizan están definidos en el código fuente, mientras que si existiese una interfaz en la plataforma, los administradores tendrían la posibilidad de modificarlos. • Granular el proceso de sincronización: apoyándose en dos de las líneas anteriores, disponer de una interfaz y más opciones de configuración, sería posible sincronizar solo aquellas entidades que se precisen en un momento determinado o seleccionar subconjuntos de información de las mismas. Por ejemplo, sincronizar solo la asignación de grupos de una asignatura o dar de alta a los profesores antes del inicio del curso. • Actualización de registros: en esta versión del proceso de sincronización no se actualizan las entidades ya creadas en el Campus Virtual. Si un usuario cambia de nombre o una titulación de cuatrimestre no se refleja en el Campus Virtual. Se ha hecho 126 Conclusiones y líneas de trabajo futuras ya alguna aproximación utilizando Servicios Web con buenos resultados, pero habría que extenderlo a toda la información susceptible de actualización. • Acceso al log de sincronización desde interfaz web: el log del proceso de sincronización no fue una solicitud de los usuarios, por lo que se implementó su uso únicamente con el propósito de facilitar la depuración de posibles errores por parte de los administradores de sistemas o los desarrolladores, quienes deben acceder directamente a la tabla de la base de datos para obtener esta información. En ocasiones los administradores de la plataforma o incluso usuarios con otros roles, profesores y estudiantes, han solicitado información relativa a la sincronización, peticiones que justifican que se facilite el acceso a esta información por sí mismos empleando el mismo mecanismo que emplean para acceder a otras áreas del log de Moodle, denominado Informes o Registros en el bloque Administración. • Sincronización en tiempo real: este sería el proyecto más ambicioso y dejaría el proceso de sincronización en un segundo plano o incluso lo relevaría. La idea base es modificar las aplicaciones de gestión tradicionales para que cada vez que se añada información académica ésta se añada en la plataforma del Campus Virtual que corresponda. Moodle dispone de una capa de Servicios Web y una API para desarrollar cuántos sean precisos que facilitaría esta labor. Ejemplos: o cuando un alumno formaliza la matrícula en la administración, automáticamente se matricula en los cursos correspondientes en el Campus Virtual; o si en Ordenación Académica se asigna docencia a un profesor, al finalizar el trámite se traspasa esta información al Campus Virtual. 127 12 BIBLIOGRAFÍA Büchner, A. (2011). Moodle Administration. Packt Publishing. Clarenc, C. A. (2013). Instrumento de evaluación y selección de sistemas de gestión de aprendizaje y otros materiales digitales. Congreso Virtual Mundial de e-Learning 2013. Hunt, T. (2012). The Architecture of Open Source Applications Volume II. (A. Brown, & G. Wilson, Edits.) Moodle. (15 de Agosto de 2014). Data manipulation API. Recuperado el 2014, de Moodle: https://docs.moodle.org/dev/Data_manipulation_API Moodle. (12 de 08 de 2014). Developer documentation. Obtenido de Moodle: http://docs.moodle.org/dev/Developer_documentation Moodle. (19 de Junio de 2014). PHPUnit. Recuperado el 2014, de Moodle: http://docs.moodle.org/dev/PHPUnit Moodle. (26 de Diciembre de 2014). Seguridad. Recuperado el 2014, de Moodle: http://docs.moodle.org/dev/Security Moodle. (s.f.). Moodle architecture. Recuperado el 17 de 12 de 2014, de http://docs.moodle.org/dev/Moodle_architecture#Moodle_as_a_modular_system 129 ANEXO I: INSTALACIÓN DE MOODLE La complejidad de la instalación de Moodle varía notablemente en función de la infraestructura implicada y la personalización de la plataforma. Para este proyecto se cuenta con la colaboración del Servicio de Informática de la ULPGC, que facilita la instalación y configuración del entorno LAMP (Linux, Apache, MySQL y PHP) necesario para la ejecución de Moodle. Disponiendo de un entorno que cumple con los requisitos a nivel de servidores, podemos realizar una instalación rápida de Moodle siguiendo las instrucciones https://docs.moodle.org/27/en/Installation_Quickstart. En el anexo XX se incluyen las características del entorno así como los requisitos mínimos de Moodle. En esta instalación no se considerarán aspectos de seguridad o rendimiento, sino disponer de una instalación funcional que permita desarrollar las extensiones necesarias. CÓDIGO DE MOODLE Hay varias alternativas para disponer del código de Moodle. En el servidor donde es va a instalar disponemos de un cliente Git, por lo que se puede obtener desde el repositorio Git oficial: git clone -b MOODLE_27_STABLE git://git.moodle.org/moodle.git Con esta instrucción desde línea de comandos se crea la carpeta moodle y se obtiene una copia completa del repositorio de Moodle y se cambia a la rama estable 2., versión actual en el momento de realizar este proyecto. Verificar que el servidor web no tiene permiso para escribir en ningún fichero de Moodle. CREAR UNA BASE DE DATOS Se dispone de las credenciales de administrador en la base de datos MySQL destinada al proyecto. Para crear una base de datos: 130 mysql> CREATE DATABASE basedatos DEFAULT CHARACTER SET UTF8 COLLATE utf8_unicode_ci; Se crea un usuario y se le asignan todos los permisos sobre la base de datos recién creada: mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,CREATE TEMPORARY TABLES,DROP,INDEX,ALTER ON basedatos.* TO moodleuser@localhost IDENTIFIED BY 'yourpassword'; CREAR DIRECTORIO DE DATOS Es necesario un directorio vacío para almacenar los ficheros de Moodle. Por motivos de seguridad, no debe estar en el área pública del servidor web, pero si debe tener permisos para que el usuario del servidor web pueda escribir en él. Basta con que el usuario del servidor web sea el propietario o dar permiso de escritura a todos en el directorio. Se opta por crear el directorio en la raíz de la máquina donde se ubica el servidor web y asignar el grupo apache, al que pertenece el usuario del servidor web, al directorio. mkdir /directoriodatos chown usuario:apache /directoriodatos chmod 775 /directoriodatos INSTALACIÓN Se puede instalar desde el navegador o desde línea de comandos. En este caso, hay que ejecutar el script install.php y seguir las instrucciones que se muestran en consola: php /path/to/moodle/admin/cli/install.php Este script crea el fichero de configuración config.php. Durante el proceso de instalación se habrán generado credenciales para un usuario con permisos de administración, por defecto admin. Con esas credenciales se puede acceder desde el navegador. 131 ANEXO II: SUBVERSION Cada usuario dispone de un directorio de trabajo propio en el entorno de desarrollo. Se crea una instalación de Moodle y un usuario para cada desarrollador en la máquina de desarrollo. CREACIÓN DEL DIRECTORIO DE TRABAJO Para crear un nuevo directorio de trabajo, es decir, una copia del código fuente, en /var/www/html lanzamos el comando # svn checkout file:///var/svn/repos/moodle/trunk moodle_user donde user será el usuario con el que se accede al sistema el desarrollador; por ejemplo, moodle_vdeniz. FLUJO DE TRABAJO GENERAL Actualizar la copia de trabajo Para actualizar la copia de trabajo con la última versión de los ficheros del proyecto, con las posibles modificaciones que hayan realizado otros miembros del equipo de desarrollo, hay que ejecutar el siguiente comando desde el directorio de trabajo: # svn update Hacer cambios en la copia de trabajo Modificar el contenido de ficheros no requiere ninguna acción especial. Los comandos de Subversion solo tienen efecto sobre el repositorio del mismo, no copian, mueven ni borran ficheros de la copia de trabajo. Es preciso señalar que las modificaciones no se efectúan en el sistema de control de versiones hasta que se efectúa un commit. Añadir o eliminar ficheros Si se añade o elimina un fichero o directorio a la copia de trabajo (físicamente), se notifica al sistema de control de versiones con: 132 # svn add foo # svn delete foo El fichero o directorio foo se eliminará o añadirá al control de versiones en el próximo commit. Copiar o mover ficheros Es posible copiar o mover ficheros junto con su historial de modificaciones, sin necesidad de hacerlo físicamente, con los comandos: # svn copy foo bar # svn move foo bar Examinar los cambios Para examinar los cambios que se van a efectuar en el repositorio antes de hacerlos efectivos: # svn status Es posible ver las diferencias existentes entre los ficheros del repositorio y los modificados en la copia local: # svn diff Deshacer cambios Es posible cancelar las modificaciones realizadas en los ficheros o directorios de trabajo y volver al estado anterior: # svn revert foo Confirmar los cambios Una vez realizado los cambios necesarios, hay que hacerlos efectivos en el repositorio, añadiendo algún mensaje significativo: # svn commit –message “Añadida la actualización automática de los departamentos” Resolver conflictos Cuando intentamos actualizar en el repositorio un fichero que ya ha modificado otro desarrollador, se producen conflictos que, en ocasiones, tenemos que resolver manualmente, bien descartando algunas modificaciones o combinando dos ficheros. Consultar el manual para resolver estas situaciones. 133