Post on 04-Jul-2020
Graduado en Ingeniería Informática
Universidad Politécnica de Madrid
Escuela Técnica Superior deIngenieros Informáticos
TRABAJO FIN DE GRADO
Plataforma Web para la gestión de grupos de prácticas ynotas en la asignatura Bases de Datos
Autor: Diego Fernández Peces-Barba
Director: Alejandro Rodríguez González
MADRID, JULIO DE 2019
Agradecimientos.
A mis padres, hermano y abuelas porque gracias a su incondicional apoyoen los momentos de bajón, han conseguido que no tire la toalla y que complete este grado deinformática. Por los valores que siempre me han transmitido de lucha y de constancia, porsu esfuerzo económico y porque se que han llegado a sufrir por mis estudios en numerosasocasiones más que yo. Por todo eso, estaré siempre agradecido. Gracias.
A Sonia, por apoyarme siempre en todo momento. Por confiar en que puedocon cualquier cosa, por animarme en los días de academia, de exámenes y realmente todoslos días de mi vida. Por escucharme en todo momento y estar siempre ahí al pie del cañón.Por aguantarme en mis peores días y aun así darme todo el cariño que una persona puededar. Por quererme como soy. Gracias cariño por ser tan especial.
A mis grandes amigos: Garri, Pablo, Monty, Rober, Sergio, Emi, Jose,Vane... mi querida «Batmafia», porque sin ellos, este camino hubiese sido mucho más difícil.El aprender juntos, el trabajo en equipo, los proyectos en común, las horas en la 1103 o enCanalobre. Son tantas horas junto a esta gente, que es imposible agradecerles todo el apoyorecibido.
A Alejandro, Ernes, Chelo y todo el grupo MIDAS. A Luis, Johnny, Gerado, César...y a todos los demás que saben quienes son y que me han apoyado ayudándome en todo. Pordarme la oportunidad de trabajar en un entorno perfecto, por la confianza depositada en mi,y por guiarme durante esta etapa de mi vida. Gracias.
Por último, y no menos importante, agradecer a todo el personal de la «FI» por sunaturalidad, por su simpatía, incluso sin saber que siendo como son, ayudaban a mantenerun entorno saludable en cuanto a ánimo. Especial mención al personal de cafetería, que noshacían sentirnos como en casa. Gracias a todos.
Índice general
1. Introducción 1
1.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Estado del arte 5
2.1. Moodle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Sakai Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. ATutor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Chamilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Especificación de requisitos 9
4. Desarrollo 11
4.1. Propuesta de solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Tecnologías y herramientas utilizadas . . . . . . . . . . . . . . . . . 11
4.2.2. Web de auto-gestión de grupos . . . . . . . . . . . . . . . . . . . . . 17
4.2.3. Plataforma UPMScore . . . . . . . . . . . . . . . . . . . . . . . . . 19
I
5. Resultados 27
5.1. Web de auto-gestión de grupos . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Plataforma UPMScore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.1. Panel de administración . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.2. Panel de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6. Conclusiones 51
7. Lineas Futuras 53
Bibliografía 55
II
Índice de figuras
1.1. Esquema de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Logo de Moodle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Logo de Sakai Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Logo de ATutor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Logo de Chamilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Logo de Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Logo de Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. Logo de Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Logo de Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Logo de Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Logo de Thymeleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.7. Logo de JSON Web Token . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Logo de MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. Arquitectura del sistema de auto-gestión de grupos . . . . . . . . . . . . . . 17
4.10. Arquitectura de UPMScore . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.11. API UPM: Ejemplo de datos de la API para la asignatura de Bases de datos. . 22
4.12. GAUSS UPM: Guía resumida de la asignatura de Bases de datos. . . . . . . . 23
4.13. UPMScore: Esquema de la base de datos. . . . . . . . . . . . . . . . . . . . 26
III
5.1. Web de auto-gestión: Página principal . . . . . . . . . . . . . . . . . . . . . 28
5.2. Web de auto-gestión: Ver grupos . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3. Web de auto-gestión: Crear grupo . . . . . . . . . . . . . . . . . . . . . . . 30
5.4. Web de auto-gestión: Función que comprueba la existencia de alumnos o que
pertenezcan a otro grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5. Web de auto-gestión: Modificar grupo . . . . . . . . . . . . . . . . . . . . . 32
5.6. UPMScore - Administración: Inicio de sesión . . . . . . . . . . . . . . . . . 33
5.7. UPMScore - Administración: Listado de asignaturas . . . . . . . . . . . . . 34
5.8. UPMScore - Administración: Buscador en funcionamiento con asignatura
inexistente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.9. UPMScore - Administración: Listado de profesores . . . . . . . . . . . . . . 36
5.10. UPMScore - Administración: Edición de una asignatura (Info) . . . . . . . . 37
5.11. UPMScore - Administración: Edición de una asignatura (Asignatura) . . . . . 38
5.12. UPMScore - Administración: Edición de una asignatura (Profesores) . . . . . 39
5.13. UPMScore - Administración: Edición/creación de un profesor . . . . . . . . 40
5.14. UPMScore - Administración: Creación Asignatura (Paso 1) . . . . . . . . . . 41
5.15. UPMScore - Administración: Creación Asignatura (Paso 3) . . . . . . . . . . 42
5.16. UPMScore - Administración: Selección del centro . . . . . . . . . . . . . . . 43
5.17. UPMScore - Administración: Selección del plan . . . . . . . . . . . . . . . . 43
5.18. UPMScore - Administración: Creación Asignatura (Paso 4) . . . . . . . . . . 44
5.19. UPMScore - Profesor: Inicio de sesión . . . . . . . . . . . . . . . . . . . . . 45
5.20. UPMScore - Profesor: Listado de asignaturas . . . . . . . . . . . . . . . . . 46
5.21. UPMScore - Profesor: Evaluaciones y Tareas de la asignatura . . . . . . . . . 47
5.22. UPMScore - Profesor: Crear nueva evaluación . . . . . . . . . . . . . . . . . 48
5.23. UPMScore - Profesor: Crear nueva tarea evaluación . . . . . . . . . . . . . . 48
5.24. UPMScore - Profesor: Información de la asignatura . . . . . . . . . . . . . . 49
5.25. UPMScore - Profesor: Información de los alumnos . . . . . . . . . . . . . . 50
IV
Índice de tablas
4.1. Descripción de la entidad Estudiante. . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Descripción del CSV de entrada de APOLO. . . . . . . . . . . . . . . . . . . 21
4.3. Descripción del CSV de salida de APOLO. . . . . . . . . . . . . . . . . . . 22
4.4. UPMScore: Descripción de la entidad Estudiante. . . . . . . . . . . . . . . . 24
4.5. UPMScore: Descripción de la entidad Profesor. . . . . . . . . . . . . . . . . 25
4.6. UPMScore: Descripción de la entidad Asignatura. . . . . . . . . . . . . . . . 25
4.7. UPMScore: Descripción de la entidad Asignatura UPM. . . . . . . . . . . . 25
4.8. UPMScore: Descripción de la entidad Evaluación. . . . . . . . . . . . . . . . 25
4.9. UPMScore: Descripción de la entidad Tarea. . . . . . . . . . . . . . . . . . . 26
4.10. UPMScore: Descripción de la entidad Nota. . . . . . . . . . . . . . . . . . . 26
V
Resumen
El incremento del número de personas conectadas a Internet ha supuesto una revolución
en el paradigma del mundo académico. Actualmente, existen un gran número de herramientas
que permiten la gestión de cursos o asignaturas por parte de profesores de un centro educativo.
Estas herramientas tienen normalmente un grado de complejidad elevado.
Hoy en día, los profesores pasan una gran parte del tiempo calculando, con ayuda de hojas
de cálculo las calificaciones obtenidas por sus alumnos. En este proceso primero obtienen un
fichero de calificaciones que fueron puestas en una plataforma de tipo LMS, comprueban
entonces si son las correctas y por último tienen que pasar estas notas al formato adecuado
que acepte la plataforma de calificaciones del centro.
El objetivo de este trabajo ha sido el de desarrollar un conjunto de aplicaciones web o
plataformas que permitan gestionar las diferentes modalidades de evaluación de unas asig-
naturas así como la auto-gestión por parte de los alumnos de los grupos de prácticas de una
asignatura. Otro de los objetivos de esta plataforma es el de facilitar el trabajo al profesor
generando los ficheros de salida necesarios para que el proceso de calificaciones sea de la
forma más rápida posible, y enviar las calificaciones obtenidas al alumno mediante correo
electrónico o mensajería instantánea.
En este documento se describirán las diferentes fases por las que el proyecto ha pasado,
así como el diseño del conjunto de aplicaciones, de herramientas y de tecnologías utilizadas
para el desarrollo del mismo.
VII
Abstract
The increase in the number of people connected to the Internet has brought about a rev-
olution in the paradigm of the academic world. Currently, there are a large number of tools
that allow the management of courses or subjects by teachers of an educational center. These
tools usually have a high degree of complexity.
Currently, teachers spend a large part of their time calculating if the grades obtained by
their students and that were introduced in the current grading systems are correct. Also, they
have to transform these grades to the correct format accepted by the center’s grading platform.
The main objective of this project was to develop a set of web applications and a web
platform that allow the management of different modalities of evaluation of several subjects,
as well as the self-management of the workgroups of a particular subject by the students. An-
other goal of this platform is to facilitate the work of the teacher by generating the necessary
output files to make grade assignments as quick as possible, and sending those grades to the
student via email or instant messaging.
This document describes the different stages of the project, as well as the design of the
set of applications, the tools, and the technologies that were used for its development.
IX
1Introducción
En los últimos años, el paradigma de la educación ha sufrido una evolución en lo que a
métodos de enseñanza se refiere. En esta era todo está conectado a Internet y en España el
85 % de la población está conectada [1] y tiene acceso al contenido publicado en la red.
Esta evolución, en cuanto a conectividad se refiere, permite a la mayoría de la población
acceder a contenidos educativos gratuitos y tener acceso a la información de una manera in-
mediata y de fuentes que son confiables y de gran reputación. Antes de esta revolución en la
conectividad, empresas como Microsoft lanzaban al mercado en marzo de 1993 enciclopedias
digitales como Encarta, con alrededor de 22.000 artículos, pero con un alto coste, aproxima-
damente, de 395 dólares por disco. Cuando la revolución de la conectividad llegó al mundo,
llegó Wikipedia. En enero de 2001, Jimmy Wales y Larry Sanger lanzaron este servicio con
la idea de crear una enciclopedia colaborativa y social, ganando popularidad rápidamente de-
bido al carácter gratuito del mismo. Las universidades dotaron de conectividad a sus centros,
apareciendo servicios de aprendizaje en línea que se servían de datos de enciclopedias on-linepara enseñar a los estudiantes.
A su vez, esto originó una evolución en los sistemas de enseñanza, permitiendo a docen-
tes de todo el mundo, montar su propio sitio web o utilizar recursos on-line para enseñar a sus
alumnos contenido de interés en sus asignaturas. Para poder tener una mejor accesibilidad de
dicho contenido, comenzaron a aparecer un tipo de software denominado Learning Mana-gement Systems (LMS) o en castellano, los Sistemas de Gestión de Aprendizaje (SGA) que
iba enfocado a buscar una solución a esta demanda. Este software permite subir contenido
propio, generar test de evaluación, grupos de evaluación o de trabajo, etc.
1
1 Introducción
1.1 Planteamiento del problema
Los actuales LMS tienen un alto grado de complejidad a la hora de manejar todas sus fun-
cionalidades. Normalmente se dota de cursos de tipo Massive Open Online Course (MOOC) a
aquellas personas que vayan a utilizarlo para que se pueda explotar todo su potencial, algunas
de sus funcionalidades son muy generales. Una de las tareas en las que más tiempo se emplea
por parte del profesorado es en el de la publicación/edición de notas de las asignaturas.
En muchas instituciones, esta tarea requiere de unos formatos específicos en los que el
profesor debe de rellenar un fichero de tipo Comma Separated Value (CSV) u hoja de cálculo
de tipo Microsoft Excel con las notas del alumno. Una ardua y compleja tarea, ya que los
actuales LMS no cuentan con tantas reglas específicas como por ejemplo, establecer dife-
rentes tipos de evaluaciones, excepciones específicas para ciertos alumnos o adaptar dichas
calificaciones al formato específico que la plataforma en la que se insertan las notas requiere.
1.2 Objetivos
Mediante este trabajo se desarrollará una serie de aplicaciones web, las cuales permi-
tirán gestionar lo que en la anterior sección se planteaba como problema. Para ello, se ha
desarrollado un conjunto de aplicaciones web que permiten la auto-gestión de grupos de una
asignatura, así como la gestión del proceso de calificaciones en una asignatura.
La aplicación de auto-gestión de grupos permitirá instanciar una de estas aplicaciones,
configurándola para una asignatura, y permitiendo que los alumnos creen o modifiquen sus
propios grupos para futuras prácticas.
1.3 Esquema
Figura 1.1: Esquema de la aplicación
2
1.3 Esquema
La aplicación estará compuesta por una serie de micro-servicios que compondrán la fun-
cionalidad completa. Esta contará con un servidor web (back-end) una interfaz web (front-end) y una base de datos que mantendrá la persistencia de los datos de los cuales se nutre la
aplicación.
La interacción entre el usuario y el sistema se realizará mediante la interfaz web, mien-
tras que la lógica de toda la aplicación, tanto la transferencia de datos con la ApplicationProgramming Interface (API) de Universidad Politécnica de Madrid (UPM), como el envío
de notificaciones a través del correo electrónico o mensajería instantánea (Telegram [2]) co-
mo operaciones con la base de datos las realizará el servidor web.
El funcionamiento detallado de esta aplicación se comentará más adelante en este docu-
mento.
3
2Estado del arte
En este capítulo se pretende profundizar en las diferentes herramientas existentes de tipo
LMS utilizadas para el fin que plantea este trabajo.
2.1 Moodle
La herramienta Moodle [3] fue desarrollada por Martin Dugiamas, pedagogo e informá-
tico, en el 2001 para ayudar a profesores y educadores a crear comunidades para el aprendi-
zaje en línea. Actualmente es una de las herramientas más utilizadas por personal académico,
aproximadamente 105.600 sitios web cuentan con una instancia de Moodle en línea. El top
de uso de esta herramienta por países es Estados Unidos con aproximadamente 10.000 insta-
laciones, seguido de España con aproximadamente 8.400 instalaciones y México con 5.900
instalaciones.
Moodle se caracteriza por ser diseñado para la enseñanza y el aprendizaje, proporcio-
nando un conjunto de herramientas centradas en el estudiante. A su vez, al tratarse de un
proyecto de Código Abierto, bajo la Licencia Pública General GNU V3 (General Public Li-
cense V3), el desarrollo por parte de la comunidad es extenso, teniendo una gran cantidad
de complementos disponibles en repositorios públicos. Está desarrollado en el lenguaje de
programación web PHP.
5
2 Estado del arte
Figura 2.1: Logo de Moodle
2.2 Sakai Project
La herramienta Sakai [4] fue desarrollada por una comunidad de desarrolladores de Có-
digo Abierto, con origen en la Universidad de Míchigan y en la Universidad de Indiana y
con la Fundación Apereo como líder del proyecto sin ánimo de lucro. Su primera versión fue
liberada en marzo de 2005 como una solución para mejorar las iniciativas anteriores como el
mencionado anteriormente Moodle [3].
No ha sido tan adoptado como esta última, pero también ha cosechado un gran volumen de
instituciones, aproximadamente 350 instituciones usan esta herramienta en todo el mundo. Al
igual que sus competidores, tiene una alta flexibilidad a la hora de incorporar herramientas y
aplicaciones de terceros en una instancia de Sakai. Está desarrollada sobre la máquina virtual
de Java en su versión 7.
Figura 2.2: Logo de Sakai Project
2.3 ATutor
La herramienta ATutor [5] fue desarrollada por la Adaptative Technology Resource Cen-
tre de la Toronto University, actualmente la Inclusive Design Research Centre, lanzando su
primera versión en enero de 2002.
La principal característica de esta herramienta es que fue diseñada desde el principio
con el objetivo de lograr las especificaciones de accesibilidad de W3C WCAG con nivel
AA+. Este nivel garantiza que, usuarios con problemas de acceso que utilizan tecnologías
asistidas, pueden acceder y utilizar la herramienta al 100 %. Al igual que sus competidores,
tiene un sistema de módulos que permite a los usuarios de la plataforma instalar extensiones
o módulos para ampliar la funcionalidad del sistema.
6
2.4 Chamilo
Figura 2.3: Logo de ATutor
2.4 Chamilo
Chamilo [6] es una Plataforma de E-learning de software libre, licenciada bajo la GNU /
GPLv3, de gestión del aprendizaje presencial, semi-presencial ó virtual, desarrollada con el
objetivo de mejorar el acceso a la educación y el conocimiento globalmente. Está respaldada
por la Asociación Chamilo (asociación sin fines de lucro), la cual tiene como objetivo la
promoción del software para la educación (y en particular de Chamilo), el mantenimiento de
un canal de comunicación claro y la construcción de una red de proveedores de servicios y
contribuidores al software.
El proyecto Chamilo intenta asegurar la disponibilidad y la calidad de la educación a un
costo reducido a través de la distribución gratuita y abierta de su software, la adaptación de
su interfaz a dispositivos de países del Tercer mundo y la provisión de un campus e-learning
de acceso libre.
Figura 2.4: Logo de Chamilo
7
3Especificación de requisitos
En este capítulo se especifica los diferentes requisitos obtenidos tras estudiar las necesi-
dades de la plataforma según la descripción del trabajo.
1. Acceso a la plataforma de administración por parte del administrador.
2. Cierre de sesión en la plataforma de administración por parte del administrador.
3. Creación de asignaturas en la plataforma de administración por parte del administrador.
4. Creación de profesores en la plataforma de administración por parte del administrador.
5. Posibilidad de modificar asignaturas en la plataforma de administración por parte del
administrador.
6. Posibilidad de eliminar asignaturas en la plataforma de administración por parte del
administrador.
7. Posibilidad de modificar profesores en la plataforma de administración por parte del
administrador.
8. Posibilidad de eliminar profesores en la plataforma de administración por parte del
administrador.
9
3 Especificación de requisitos
9. Acceso a la plataforma de usuario por parte de un profesor.
10. Cierre de sesión en la plataforma de usuario por parte de un profesor.
11. Posibilidad de crear/modificar/eliminar evaluaciones en la asignatura donde se encuen-
tre el profesor en la plataforma de usuario.
12. Posibilidad de crear/modificar/eliminar tareas para una determinada evaluación por
parte del profesor en la plataforma de usuario.
13. Posibilidad de subir ficheros CSV de APOLO para añadir estudiantes a la plataforma
de usuario por parte del profesor.
14. Posibilidad de asociar/modificar la evaluación para un determinado estudiante por parte
del profesor en la plataforma de usuario.
15. Posibilidad de introducir notas en una tarea para un determinado estudiante por parte
del profesor en la plataforma de usuario.
16. Posibilidad de descargar fichero CSV con formato APOLO para la puesta de califica-
ciones en la plataforma de usuario.
17. Acceso a la plataforma de usuario por parte de un alumno.
18. Cierre de sesión en la plataforma de usuario por parte de un alumno.
19. Consulta de notas en la plataforma de usuario por parte de un alumno.
20. Envío de notificaciones a alumnos por parte del sistema vía correo electrónico o algun
servicio de mensajería isntantánea.
21. Posibilidad de que los alumnos creen/modifiquen sus propios grupos para una asigna-
tura.
10
4Desarrollo
4.1 Propuesta de solución
Tras valorar diferentes tipo de implementaciones, se ha optado por la creación de tres
productos, que juntos satisfacen toda la visión general del problema planteado al inicio del
documento.
Estos productos tienen un fin diferente en cada caso, el cual se explicará de forma deta-
llada en cada uno de los mismos.
4.2 Arquitectura
4.2.1 Tecnologías y herramientas utilizadas
Para el desarrollo de estos tres productos, se han empleado ciertas herramientas y tecno-
logías que serán detalladas por separado a continuación. Los tres productos se basan en una
solución de tipo cliente-servidor, basándose en micro-servicios para facilitar el despliegue y
tener una modularización.
11
4 Desarrollo
Docker
Docker [7] es un proyecto de código abierto que automatiza el despliegue de aplicacio-
nes dentro de contenedores de software, proporcionando una capa adicional de abstracción
y automatización de virtualización de aplicaciones en múltiples sistemas operativos. Docker
utiliza características de aislamiento de recursos del kernel Linux, tales como cgroups y espa-
cios de nombres (namespaces) para permitir que «contenedores» independientes se ejecuten
dentro de una sola instancia de Linux, evitando la sobrecarga de iniciar y mantener máquinas
virtuales.
El uso de la tecnología de Docker en este trabajo se decide gracias a sus múltiples cua-
lidades respecto a desplegar las aplicaciones en el propio sistema operativo de la máquina
anfitriona donde va a ser desplegado. Este nos ofrece estas principales ventajas:
El uso de contenedores aporta seguridad ya que sus procesos se ejecutan en un entorno
de tipo sandbox que aporta encapsulamiento, desacople y aislamiento del contenedor.
Utiliza menos recursos de la máquina anfitriona al no virtualizar el núcleo de la máqui-
na anfitriona y utilizar imágenes optimizadas.
Compatibilidad al ser compatible con multi-plataforma y mantenimiento fácil.
Figura 4.1: Logo de Docker
Java
Java [8] es un lenguaje de programación de propósito general, concurrente, orientado a
objetos, que fue diseñado específicamente para tener tan pocas dependencias de implemen-
tación como fuera posible. Su intención es permitir que los desarrolladores de aplicaciones
escriban el programa una vez y lo ejecuten en cualquier dispositivo «write once, run anywhe-
re (WORA)», lo que quiere decir que el código que es ejecutado en una plataforma no tiene
que ser recompilado para correr en otra. Java es, a partir de 2012, uno de los lenguajes de
programación más populares en uso, particularmente para aplicaciones de cliente-servidor de
web, con unos diez millones de usuarios reportados.
12
4.2 Arquitectura
Figura 4.2: Logo de Java
Maven
Maven [9] es una herramienta de software para la gestión y construcción de proyectos
Java creada por Jason van Zyl, de Sonatype, en 2002.
Utiliza un Project Object Model (POM) para describir el proyecto de software a construir,
sus dependencias de otros módulos y componentes externos, y el orden de construcción de los
elementos. Viene con objetivos predefinidos para realizar ciertas tareas claramente definidas,
como la compilación del código y su empaquetado.
El uso de Maven en este proyecto nos facilita el poder añadir dependencias a nuestro
proyecto Java con una mayor facilidad, ya que posteriormente a la hora de empaquetar el
proyecto se bajarán las dependencias de su repositorio.
Figura 4.3: Logo de Maven
Spring Framework
Spring Framework [10] es una plataforma que nos proporciona una infraestructura que
actúa de soporte para desarrollar aplicaciones Java.
Las características fundamentales de Spring Framework son las múltiples extensiones
para la construcción de aplicaciones web sobre la plataforma Java EE. A pesar de que no im-
pone ningún modelo de programación en particular, este framework se ha vuelto popular en
la comunidad al ser considerado una alternativa, sustituto, e incluso un complemento al mo-
delo «Enterprise JavaBean (EJB)». Spring Framework es un contenedor ligero «lightweightcontainer» en contraposición a un un servidor de aplicaciones J2EE.
13
4 Desarrollo
La ventaja principal por la que se usa Spring Framework es la facilidad para crear una
API REST y su modo de uso, el cual mediante inyección de dependencias y anotaciones, es
capaz de crear los componentes y sus relaciones entre ellos de forma automática.
Figura 4.4: Logo de Spring
Ionic
Ionic es un completo SDK de código abierto para el desarrollo de aplicaciones móviles
híbridas creado por Max Lynch, Ben Sperry y Adam Bradley de Drifty Co. en 2013. La
versión original se lanzó en 2013 y se construyó sobre AngularJS y Apache Cordova.
La ventaja de usar este framework para la parte front-end es que, al ser capaz de desarro-
llar aplicaciones móviles híbridas, también se pueden crear aplicaciones web para escritorio,
otorgando una sencillez que no se podría obtener con otros frameworks. Dependiendo de la
plataforma a la que se desee compilar, este lo hace siguiendo unas guías de estilo para dichas
plataformas, lo que garantiza una perfecta armonía en los diferentes ecositemas.
Figura 4.5: Logo de Ionic
Thymeleaf
Thymeleaf [11] es un motor de plantillas, es decir, es una tecnología que nos va a permitir
definir una plantilla y, conjuntamente con un modelo de datos, obtener un nuevo documento,
práctica muy útil para entornos web sencillos. Es integrable con muchos de los frameworks
más utilizados, como para nuestro caso, Spring Framework, y está basado en el uso de nuevas
etiquetas, de nuevos atributos.
Una de las ventajas de usar Thymeleaf, es que, para web sencillas, permite crear modelos
web cuyo código es casi tan legible como si fuera un documento HTML. Esto nos va a
14
4.2 Arquitectura
dar muchas facilidades, no solamente a la hora de la lectura, sino también a la hora de la
visualización.
Figura 4.6: Logo de Thymeleaf
JSON Web Token
JSON Web Token [12] es un estándar abierto basado en JSON propuesto por IETF (RFC
7519) [13] para la creación de tokens de acceso que permiten la propagación de identidad y
privilegios o claims en inglés. Por ejemplo, un servidor podría generar un token indicando
que el usuario tiene privilegios de administrador y proporcionarlo a un cliente. El cliente
entonces podría utilizar el token para probar que está actuando como un administrador en el
cliente o en otro sistema.
El token está firmado por la clave del servidor, así que el cliente y el servidor son ambos
capaz de verificar que el token es legítimo. Los JSON Web Tokens están diseñados para
ser compactos, poder ser enviados en las URLs -URL-safe- y ser utilizados en escenarios
de Single Sign-On (SSO). Los privilegios de los JSON Web Tokens puede ser utilizados para
propagar la identidad de usuarios como parte del proceso de autenticación entre un proveedor
de identidad y un proveedor de servicio, o cualquiera otro tipo de privilegios requeridos por
procesos empresariales.
En nuestro caso, el uso de los JSON Web Tokens se usan en el escenario anteriormente
especificado SSO.
Figura 4.7: Logo de JSON Web Token
MySQL
MySQL [14] es un sistema de gestión de bases de datos que cuenta con una doble licencia.
Por una parte es de código abierto, pero por otra, cuenta con una versión comercial gestionada
por la compañía Oracle. Actualmente, es la base de datos de código abierto más famosa y
15
4 Desarrollo
utilizada en el mundo entero. Una de las principales características de MySQL es que trabaja
con bases de datos relacionales, es decir, utiliza tablas múltiples que se interconectan entre sí
para almacenar la información y organizarla correctamente.
Los principales motivos por los cuales hemos elegido MySQL:
Es gratuito con licencia GPL
Ofrece muchas funcionalidades para ser un gestor de bases de datos gratuítos
Ofrece gran variedad de interfaces de usuario que se pueden implementar, Spring Fra-
mework es 100 % compatible con este gestor y trae interfaces ya predefinidas out of thebox.
Su gran acogida tanto en proyectos personales como en entornos empresariales durante
los años 2018 y 2019 según la encuesta a desarrolladores de Stack Overflow [15].
Figura 4.8: Logo de MySQL
16
4.2 Arquitectura
4.2.2 Web de auto-gestión de grupos
En esta sección se muestra la arquitectura que se ha seleccionado para la aplicación web
de auto-gestión de grupos. Esta aplicación está pensada desde el comienzo de su diseño en
su modularidad, y en la posibilidad de que cada departamento de una escuela, pueda montar
esta aplicación web para la gestión de sus grupos de asignaturas. En la siguiente figura 4.9 se
muestra un diagrama.
Figura 4.9: Arquitectura del sistema de auto-gestión de grupos
Esta aplicación web se compone de dos micro-servicios que están se encuentran embebi-
dos en contenedores de Docker. El primer contenedor dota de lógica de negocio y una interfaz
de usuario, es concretamente, la aplicación web con la que el usuario interactuará para la ges-
tión de los grupos. Esta aplicación está desarrollada en Java y usa Spring Framework como
herramienta para gestionar la conexión con la base de datos, y exponer un servidor web,
el cual, mostrará una interfaz de usuario que ha sido desarrollada mediante el Framework
Thymeleaf.
A su vez, para notificar mediante correo electrónico a los estudiantes, se ha desarrollado
un servicio que realiza una conexión con el servidor del proveedor de correo electrónico. Para
las pruebas se ha utilizado GMail como proveedor, pero se puede modificar por cualquier
proveedor de correo electrónico que soporte el protocolo SMTP.
17
4 Desarrollo
Base de datos
La versión propuesta para el sistema se caracteriza por tener solamente tres tablas, ya
que estas tres tablas aúnan la información requerida y suficiente, siendo susceptible de ser
incrementada en un futuro. De estas dos tablas, una en la que se almacenan los datos de
los estudiantes (student), otra con la información del grupo (student_group) que actualmente
solo tiene un identificador, pero que podría contener mas información que se considerase
oportuna, y finalmente, una tabla que relaciona los estudiantes con el grupo al cual pertenecen
(student_group_students).
Atributo Tipo Descripción Otros
id Int(11) Identificador único del estudiante (Auto-generado) PKcoordinador bit (1) Identifica si estudiante es coordinador de su grupo.
dni VC(255) Documento Nacional de Identidad del estudiante. Únicoemail VC(255) Correo electrónico del estudiante. Úniconame VC(255) Nombre del estudiante.
surname VC(255) Apellidos del estudiante.
Tabla 4.1: Descripción de la entidad Estudiante.
La tabla 4.1 muestra la entidad Estudiante. Cada fila de dicha tabla contiene toda la infor-
mación necesaria para un estudiante. Cabe recalcar que los atributos «dni» y «email» deben
de ser únicos en la tabla, garantizando que las comunicaciones se realizan solo a una persona
y que su identificador es único.
18
4.2 Arquitectura
4.2.3 Plataforma UPMScore
En esta sección se muestra la arquitectura que se ha seleccionado para la aplicación web
que agrupa el resto de funcionalidades que se espera sobre este proyecto. Esta aplicación
tiene una mayor complejidad que la anterior, ya que reúne una mayor cantidad de requisitos.
Figura 4.10: Arquitectura de UPMScore
Como se puede observar en la figura 4.9 que muestra un diagrama de la arquitectura,
esta aplicación web se compone de cuatro micro-servicios, que se encuentran embebidos en
contenedores de Docker. A continuación se detallan de manera agrupada, cada uno de estos
contenedores.
Interfaz de usuario
Para la interfaz de usuario, se ha decidido crear dos paneles que separan los roles más
restrictivos que existen actualmente en la plataforma. Estos roles son los de «Administra-
dor» y los de «Usuario general». Este último rol también puede ser diferenciado entre rol de
«Profesor» y «Alumno». Ambos paneles se han desarrollado sobre el Framework Ionic 3.
El primer panel es el denominado «Panel de Administración». Las funcionalidades que
este panel ofrece son las de administrar asignaturas y profesores en el sistema. Este panel
trata de solventar los requisitos numerados del 1 al 8 definidos en el Capítulo 3.
El segundo panel es el denominado «Panel de Usuario». Las funcionalidades que este pa-
nel ofrece son las de administrar los alumnos, las evaluaciones y las tareas de una asignatura
por parte del profesor. A su vez, también podrá administrar las notas de los alumnos para
19
4 Desarrollo
dichas tareas. En este panel, el alumno podrá ver sus notas de las diversas tareas de las asig-
naturas que el alumno está cursando. Este panel trata de solventar los requisitos numerados
del 9 al 20 definidos en el Capítulo 3.
A diferencia de la interfaz de usuario en la web de auto-gestión de grupos, el uso del
framework Ionic para la parte gráfica, garantiza que se puedan reutilizar componentes que
otras personas ya han diseñado y que pueden ser encontrados en repositorios de Internet.
Otra de las ventajas que nos ofrece Ionic es que podremos generar aplicaciones web móviles
de una manera sencilla, ya que sería una aplicación que se debería de usar de una manera más
habitual al contrario que la web de auto-gestión de grupos.
Lógica de negocio
La parte de lógica de negocio está desarrollada en Java y usa Spring Framework como
herramienta para gestionar la conexión con la base de datos, y montar un servidor web. Este
servidor web expone una REST API, la cual permite el manejo de todos los recursos de la
plataforma.
Esta lógica de negocio, ha sido dividida en paquetes de Java, organizando el servicio de
la siguiente manera:
configuration: Bajo este paquete se encuentran las clases necesarias para la configu-
ración de ciertos recursos. A su vez, se encuentra la configuración de seguridad de la
API con la que se controla que roles pueden acceder a que recursos de la plataforma.
controllers: Bajo este paquete se encuentran los endpoints de la API. Estos son las
URL que exponen servicios o recursos de la plataforma. Aquí encontramos los recursos
de autenticación en el sistema, el manejo de notificaciones, asignaturas, profesores, o
recursos de la API-UPM.
models: Aquí se encuentran los objetos que suministran una interfaz común entre la
plataforma y el almacenamiento en una base de datos. Se suele referir a estas clases
como Data Access Object (DAO) [16]
repositories: Bajo este paquete se encuentran las interfaces que permiten realizar todas
las operaciones contra la base de datos mediante el uso de los modelos anteriormente
nombrados. Estas operaciones son las de consulta, guardado, edición y borrado de filas
en una base de datos.
services: Bajo este paquete se encuentran los servicios con lógica de negocio creados
a partir de las necesidades del problema. Estos servicios hacen uso normalmente de los
repositorios anteriormente nombrados. Para ello se han creado servicios de Estudiantes,
Profesores, Notas, Tokens, Notificaciones y APOLO [17].
20
4.2 Arquitectura
Una de las partes a destacar en el sistema es el APOLO Service, este servicio es el res-
ponsable de convertir un CSV de APOLO a un objeto manejable en el sistema. Y viceversa.
La plataforma APOLO [17] es un servicio desarrollado por la UPM mediante el cual se
elaboran las actas de las diferentes asignaturas y se permite la consulta de listados de estu-
diantes por grupos. Es por ello, que se desea poder realizar una ingesta de datos de alumnos
desde un fichero elaborado por esta plataforma y la generación de otro que permita elaborar
las actas en el formato de fichero que la paltaforma es capaz de procesar.
Columna CSV DescripciónDNI Documento identificativo del alumno.
Apellidos Apellidos del alumno.
Nombre Nombre del alumno.
E-mail Correo electrónico @alumnos.upm.es del alumno.
Plan Plan de estudios del alumno.
Expediente Número de expediente (matrícula) del alumno.
Exp_centro Número de expediente (matrícula) del alumno.
Grupo matr. Grupo en el que realizó la matricula el alumno.
Nombre_Grupo_matricula Nombre del grupo de matrícula anterior.
Codigo_asignatura Código único de asignatura donde se matriculó el alumno.
Tabla 4.2: Descripción del CSV de entrada de APOLO.
Tal y como se puede observar en la tabla 4.2, el fichero CSV de entrada del sistema
APOLO contiene toda la información necesaria para registrar a un alumno en el sistema. El
servicio realiza la conversión necesaria para crear una nueva instancia de la entidad «Estu-
diante».
Para la puesta final de notas en los sistemas de la UPM, es necesario crear un fichero CSV
a partir de las notas que existan en el sistema para dicho alumno. Este fichero CSV difiere en
alguna de sus cabeceras. La tabla 4.3 refleja las diferencias.
Servicios de terceros
Para lograr una experiencia de usuario más completa, se decidió implementar varios ser-
vicios de terceros. El primero de ellos es la API UPM [18]. Este servicio otorgado por la UPM
permite obtener mediante el consumo de una REST-API datos académicos y personales, tan-
to públicos como privados. En nuestro caso, gracias al uso de este servicio se puede obtener
información de todos los centros que existen, de sus planes, tipo de estudios y asignaturas.
Complementando la API UPM, obtenemos desde el servicio GAUSS UPM [19] las guías
de aprendizaje de las asignaturas que nos devuelve la API UPM, con esto podemos obtener
21
4 Desarrollo
Columna CSV DescripciónDNI Documento identificativo del alumno.
Apellidos Apellidos del alumno.
Nombre Nombre del alumno.
E-mail Correo electrónico @alumnos.upm.es del alumno.Plan Plan de estudios del alumno.
Expediente Número de expediente (matrícula) del alumno.
Exp_centro Número de expediente (matrícula) del alumno.
Grupo matr. Grupo en el que realizó la matricula el alumno.
Nota_total Nota que se le otorga al estudiante.
Tabla 4.3: Descripción del CSV de salida de APOLO.
Figura 4.11: API UPM: Ejemplo de datos de la API para la asignatura de Bases de datos.
información de profesores que imparten la asignatura, sus múltiples evaluaciones, tareas y
demás información sobre una asignatura en concreto. Un ejemplo de esta información se
22
4.2 Arquitectura
puede ver en la figura 4.12.
Figura 4.12: GAUSS UPM: Guía resumida de la asignatura de Bases de datos.
23
4 Desarrollo
Otro servicio de terceros que se usa es el envío de correos electrónicos mediante un pro-
veedor de correo electrónico. Para las pruebas hemos usado GMail, se ha creado un servicio
en la aplicación que genera cuerpos de correos electrónicos y los envía mediante este pro-
veedor. Con esto conseguimos que los alumnos no tengan por que ingresar en la plataforma
para obtener sus calificaciones. El sistema envía automáticamente correos electrónicos que
contienen este tipo de información. A su vez también es el medio para informar a un alumno
de su alta automática en el sistema o la vía para cambiar la contraseña de su usuario.
En conjunto al envío de correo electrónico, se ha planteado el uso de un proveedor de
mensajería instantánea para la comunicación de notificaciones al usuario. Se ha decidido el
uso de Telegram para esta función. Telegram reúne que es un servicio gratuito y que permite
la creación de Telegram Bots [20]. Estos bots permiten al usuario interactuar con el sistema.
Para ello, se creará un servicio el cual mediante una autenticación OAuth [21] en nuestro
sistema, se vinculará un usuario único de Telegram con un usuario único de UPMScore.
Base de datos
La versión propuesta para el sistema se caracteriza por tener siete tablas o entidades. Cada
entidad se corresponde con un objeto Java.
Atributo Tipo Descripción Otrosid VC(255) Identificador único del estudiante (Auto-generado) PKdni VC(255) Documento Nacional de Identidad del estudiante.
email VC(255) Correo electrónico @alumnos.upm.es del estudiante.
enabled bit(1) Identifica si el usuario está activo en el sistema.
name VC(255) Nombre del estudiante.
password VC(255) Contraseña del estudiante.
surname VC(255) Apellidos del estudiante.
telegram_id VC(255) Identificador único de Telegram.
Tabla 4.4: UPMScore: Descripción de la entidad Estudiante.
24
4.2 Arquitectura
Atributo Tipo Descripción Otrosid VC(255) Identificador único del profesor (Auto-generado) PKemail VC(255) Correo electrónico @upm.es del profesor.
enabled Bit(1) Identifica si el usuario está activo en el sistema.
name VC(255) Nombre del profesor.
password VC(255) Contraseña del profesor.
surname VC(255) Apellidos del profesor.
phone_number VC(255) Número de teléfono del profesor.
role VC(255) Rol del profesor (coordinador, en prácticas...)
room VC(255) Despacho del profesor.
Tabla 4.5: UPMScore: Descripción de la entidad Profesor.
Atributo Tipo Descripción Otrosid VC(255) Identificador único de la asignatura (Auto-generado) PKcourse VC(255) Curso de la asignatura.
name VC(255 Nombre de la asignatura.
semester VC(255) Semestre de la asignatura.
year VC(255) Año de la asignatura.
Tabla 4.6: UPMScore: Descripción de la entidad Asignatura.
Atributo Tipo Descripción Otrossubject_id VC(255) Identificador de la asignatura UPM. C-PKsemester VC(255) Semestre de la asignatura UPM. C-PKyear VC(255) Año de la asignatura UPM C-PKapolo_file VC(255) Ruta del fichero de APOLO vinculado.
modified_date BigInt(20) Fecha de última modificación.
name VC(255) Nombre de la asignatura UPM.
Tabla 4.7: UPMScore: Descripción de la entidad Asignatura UPM.
Atributo Tipo Descripción Otrosid VC(255) Identificador único de evaluación (Auto-generado) PKminimum_grade Int(11) Nota mínima de la evaluación.
name VC(255) Nombre de la evaluación.
subject_id VC(255) Identificador de asignatura a la que hace referencia. FK
Tabla 4.8: UPMScore: Descripción de la entidad Evaluación.
25
4 Desarrollo
Atributo Tipo Descripción Otrosid VC(255) Identificador único de la tarea (Auto-generado) PKminimum_grade Int(11) Nota mínima de la tarea.
name VC(255) Nombre de la tarea.
num_of_students VC(255) Número de participantes para la tarea.
evaluation_id VC(255) Identificador de evaluación a la que hace referencia. FK
Tabla 4.9: UPMScore: Descripción de la entidad Tarea.
Atributo Tipo Descripción Otrosid VC(255) Identificador único de la nota (Auto-generado) PKcreated_date BigInt(20) Fecha de creación de la tarea.
modified_date BigInt(20) Fecha de la modificación de la tarea.
assingment_id VC(255) Identificador de la tarea a la que hace referencia. FKstudent_id VC(255) Identificador del alumno al que hace referencia. FKteacher_id VC(255) Identificador del profesor a la que hace referencia. FK
Tabla 4.10: UPMScore: Descripción de la entidad Nota.
Figura 4.13: UPMScore: Esquema de la base de datos.
26
5Resultados
5.1 Web de auto-gestión de grupos
Tal y como se puede observar en la figura 5.1, la página web principal se compone de tres
botones en los que se puede:
Consultar Grupos Existentes
Crear Nuevo Grupo
Modificar Grupo Existente
Cada uno de estos botones, llevará a otra vista creada, con el fin de gestionar los grupos
de una asignatura. Para esta ocasión, se ha probado con la asignatura de Bases de Datos para
el curso 2019.
27
5.1 Web de auto-gestión de grupos
Figura 5.2: Web de auto-gestión: Ver grupos
En la figura 5.2 se muestra el resultado de la página de consulta de grupos existentes. Esta
se compone de una lista de grupos una vez han sido previamente formados. Si se selecciona un
grupo, mediante una animación de tipo «acordeón», aparecen los nombres y apellidos de los
integrantes del grupo seleccionado. El alumno que pertenece al grupo y que es coordinador
de dicho grupo tendrá una etiqueta en la parte de la derecha indicando que tiene dicho rol.
29
5 Resultados
Figura 5.3: Web de auto-gestión: Crear grupo
En la figura 5.3 muestra el resultado de la página de creación de un grupo. Esta se com-
pone dos partes claramente diferenciadas mediante dos columnas. La primera columna es el
formulario que permitirá crear el grupo. Este está compuesto de cuatro campos de texto, en
donde los alumnos deberán de meter el DNI, NIE o pasaporte de todos los integrantes del
grupo. Para este caso en concreto, se decidió que un grupo sólo podría tener 4 alumnos como
máximo, siendo este parámetro configurable en el código. A su vez, uno de los alumnos del
grupo ha de ser obligatoriamente el coordinador del mismo.
La segunda columna es meramente informativa, donde se explican las reglas para poder
formar un grupo válido. Estas reglas han de estar previamente definidas en el modelo de la
página que se completa en el código del programa.
Cuando un alumno rellena el formulario y decide crear el grupo, la primera operación es
comprobar que el alumno se encuentra en nuestra base de datos, o bien, que el alumno no
se encuentre en un grupo. Una vez se comprueba esto, se comprueba que se ha recibido un
coordinador válido y se procede a guardar todos los estudiantes asignándoles un grupo nuevo.
30
5.1 Web de auto-gestión de grupos
Figura 5.4: Web de auto-gestión: Función que comprueba la existencia de alumnos o que
pertenezcan a otro grupo
El servicio de notificaciones enviará entonces tantos correos electrónicos como alumnos
tenga el grupo, diferenciando a su vez, el contenido del mismo, dependiendo de si es única-
mente integrante o coordinador del grupo. Esta diferenciación se hace ya que el coordinador
recibirá un JSONWebToken [12] con el que posteriormente podrá realizar modificaciones con
respecto a su grupo en la vista de modificar grupo. Esto se hace para no tener que mantener
una tabla de usuarios y contraseñas, siendo responsabilidad del coordinador, guardar en un
lugar seguro dicho JSONWebToken.
31
5 Resultados
Figura 5.5: Web de auto-gestión: Modificar grupo
En la figura 5.5 muestra el resultado de la página de modificar un grupo. Esta se compone
de una parte principal en la que se muestra un formulario que permitirá identificar el grupo
que se desea modificar. Este formulario está compuesto por tres campos: El identificador del
grupo (número), el correo electrónico del coordinador del grupo, y el JSONWebToken que
recibió mediante un correo electrónico el coordinador a la hora de crear el grupo.
Si todos los campos son completados correctamente, la vista a la que pasaría el alumno
para modificar el grupo sería la misma que la vista de crear grupo de la figura 5.3. En caso de
que cualquier campo fuese incorrecto, se le notificaría al usuario mediante una alerta de que
alguno de los datos introducidos no son correctos.
32
5.2 Plataforma UPMScore
5.2 Plataforma UPMScore
5.2.1 Panel de administración
Inicio de sesión
Figura 5.6: UPMScore - Administración: Inicio de sesión
En la figura 5.6 se muestra el resultado de la primera página que muestra la plataforma de
administración de asignaturas y profesores. Este pantalla corresponde con el inicio de sesión
33
5 Resultados
en la plataforma, está compuesta de un formulario con dos campos, uno para el correo elec-
trónico (que en este caso tendrá que ser una dirección que esté bajo el dominio «upm.es») y el
otro para la contraseña asociada a dicho usuario. El sistema permitirá única y exclusivamente
el inicio de sesión a aquellos usuarios que tengan activado el rol de «Administración» en el
sistema.
Listado de asignaturas
Figura 5.7: UPMScore - Administración: Listado de asignaturas
34
5.2 Plataforma UPMScore
En la figura 5.7 se muestra el listado de asignaturas que están configuradas en la plata-
forma. Por cada asignatura, aparece una tarjeta que muestra el nombre, el curso, el semestre
y el año que el administrador ha proporcionado en el proceso de creación/modificación de
una asignatura. A su vez, hay un botón que permite entrar a la página de edición de dicha
asignatura.
En esta vista, observamos a su vez el botón de «Añadir», que nos permitiría entrar a la
vista de creación de una nueva asignatura. A su lado, se encuentra un buscador que, de manera
instantánea, te va mostrando los resultados de las asignaturas que contengan las palabras que
se estén buscando.
Figura 5.8: UPMScore - Administración: Buscador en funcionamiento con asignatura inexis-
tente
En la figura 5.8 se proporciona un ejemplo de lo que muestra la web de administra-
ción cuando buscas por una asignatura inexistente en el sistema. La web te recomienda que
busques por otros términos o que crees una asignatura nueva mediante el botón próximo al
buscador.
35
5 Resultados
Listado de profesores
Figura 5.9: UPMScore - Administración: Listado de profesores
En la figura 5.9 se muestra el listado de profesores que han sido registrados en el sistema.
Por cada profesor, aparece una tarjeta que muestra nombre, apellidos, correo electrónico y
despacho del profesor. A su vez, hay un botón que permite entrar a la página de edición de
dicho profesor.
En esta vista, observamos a su vez el botón de «Añadir», que nos permitiría entrar a la
vista de creación de un nuevo profesor. A su lado, se encuentra un buscador que, de manera
instantánea, te va mostrando los resultados de los profesores que contengan en el nombre las
palabras que se estén buscando.
36
5.2 Plataforma UPMScore
Editar una asignatura
Figura 5.10: UPMScore - Administración: Edición de una asignatura (Info)
En la figura 5.10 se muestra la página de edición de una asignatura, esta está compuesta
por tres segmentos en los que se observan «Info», «Asignaturas» y «Profesores». De esta
manera, la información a editar de una asignatura está categorizada y es mas sencillo de
editar.
Esta primera vista «Info» nos muestra la información básica de la asignatura. Esta está
compuesta de un formulario con el nombre, el curso, el semestre y el año académico de
la asignatura. A su vez, se encuentran los botones «Eliminar» para borrar la asignatura por
completo del sistema y «Guardar».
37
5 Resultados
Figura 5.11: UPMScore - Administración: Edición de una asignatura (Asignatura)
La segunda vista «Asignaturas» que se puede observar en la figura 5.11 muestra las asig-
naturas que se encuentran en el sistema «GAUSS» [19] que concuerdan con asignaturas que
se están impartiendo en la UPM.
Cada asignatura de tipo UPM, a su vez tiene un semestre elegido y un año de impartición.
Toda esta información se obtiene a través de la API-UPM [18] y tiene un código único de
asignatura. Se pueden asociar tantas asignaturas UPM a la asignatura del sistema como se
quiera. A su vez, el sistema permite retirar el vínculo de la asignatura UPM.
38
5.2 Plataforma UPMScore
Figura 5.12: UPMScore - Administración: Edición de una asignatura (Profesores)
La tercera y última vista «Profesores» que se puede observar en la figura 5.12 muestra un
listado de profesores asociados a la asignatura. Esto otorgará el poder al profesor de poder
tener en su panel de usuario la asignatura y poder realizar operaciones sobre la misma,
39
5 Resultados
Editar/crear un profesor
Figura 5.13: UPMScore - Administración: Edición/creación de un profesor
La vista que se puede observar en la figura 5.13 la interfaz con la que se puede crear o
modificar un profesor en el sistema. Esta vista se compone de un formulario con los campos
de Nombre, Apellidos, E-Mail, Teléfono, Despacho y una casilla de activación de usuario.
Recalcar el funcionamiento de esta última casilla. Cuando un profesor es creado, este no
está activado en el sistema hasta que no modifica su contraseña. Aún así, el administrador
puede activar/desactivar su usuario cuando asi la situación lo requiera.
40
5.2 Plataforma UPMScore
Crear una asignatura
Figura 5.14: UPMScore - Administración: Creación Asignatura (Paso 1)
Para el proceso de creación de una asignatura, la primera vista que se muestra al usuario
visible en la figura 5.14 muestra un formulario compuesto por cuatro campos que deberán
ser completados por la información de la asignatura. Estos campos son el nombre, el curso,
el semestre y el año. Para continuar con la creación de la asignatura habrá que pulsar sobre el
botón «Siguiente».
41
5 Resultados
Figura 5.15: UPMScore - Administración: Creación Asignatura (Paso 3)
El siguiente paso que muestra la figura 5.15, se observan dos partes diferenciadas en la
interfaz. La primera columna que ocupa la mitad de la pantalla, es el buscador de asignaturas
UPM. La segunda columna que ocupa la otra mitad de la pantalla, muestra las asignaturas
UPM que se han seleccionado finalmente para componer la asignatura del sistema.
42
5.2 Plataforma UPMScore
Figura 5.16: UPMScore - Administración:
Selección del centro
Figura 5.17: UPMScore - Administración:
Selección del plan
Este buscador permite vincular las asignaturas UPM a nuestra asignatura en el sistema.
Primero se deberá cumplimentar, mediante un selector, el centro al cual pertenece la asigna-
tura. Una vez se seleccione dicho centro mediante el selector de la figura 5.16, la web cargará
entonces los planes de dicho centro, y una vez se seleccione el plan mediante el selector de
la figura 5.17, cargará las diferentes asignaturas del plan.
Una vez se haya terminado de elegir las asignaturas, se deberá pulsar sobre el botón
«Siguiente» para continuar con la creación de la asignatura.
43
5 Resultados
Figura 5.18: UPMScore - Administración: Creación Asignatura (Paso 4)
El siguiente, y último paso que muestra la figura 5.18, se observan dos partes diferencia-
das en la interfaz, de manera similar a la anterior. La primera columna que ocupa la mitad de
la pantalla, es el buscador de profesores que impartirán esta asignatura. Esta pantalla muestra
unos «Profesores sugeridos», los cuales son obtenidos mediante la API UPM y los cuales
aún no se encuentran en el sistema. Si se selecciona profesores de esta lista, serán creados
automáticamente y se les enviará un correo electrónico para finalizar el registro del mismo.
A su vez, si alguno de los profesores que la API UPM sugiere se encontrase ya registrado
en el sistema, aparecería en la lista de «Profesores en el sistema». Además, se puede buscar
cualquier profesor que exista en el sistema para vincularle con esta asignatura.
La segunda columna que ocupa la otra mitad de la pantalla, muestra los profesores que
finalmente se han seleccionado para componer la asignatura del sistema.
44
5.2 Plataforma UPMScore
5.2.2 Panel de usuario
En la figura 5.19 que se muestra a continuación se puede observar el resultado de la
primera página que muestra la plataforma de usuario. Esta pantalla corresponde con el inicio
de sesión en la plataforma de usuario, está compuesta de un formulario con dos campos, uno
para el correo electrónico (que en este caso tendrá que ser una dirección que esté bajo el
dominio «upm.es» o «alumnos.upm.es») y otro para la contraseña asociada a dicho usuario.
El sistema permitirá única y exclusivamente el inicio de sesión a aquellos usuarios que tengan
activado el rol de «Profesor» o «Alumno» en el sistema. Dependiendo de si se tiene un rol u
otro, se mostrará una vista diferente tras el inicio de sesión en el sistema
Figura 5.19: UPMScore - Profesor: Inicio de sesión
45
5 Resultados
Panel del Profesor
A continuación se muestra la plataforma que se puede observar si un profesor inicia sesión
en el sistema.
Figura 5.20: UPMScore - Profesor: Listado de asignaturas
En la figura 5.20 se muestra el listado de asignaturas que están disponibles para un de-
terminado profesor. Como se puede observar, la vista es prácticamente la misma a la del
panel del administrador al poder compartir los componentes web. Por cada asignatura, apa-
rece una tarjeta que muestra el nombre, el curso, el semestre y el año que el administrador
proporcionó en el proceso de creación/modificación de una asignatura mediante el panel de
administración. A su vez, hay un botón que permite entrar a la página de edición de dicha
asignatura.
En la figura 5.21 se muestra la vista que se obtiene al seleccionar una asignatura de la
lista anterior. Esta está compuesta por dos segmentos «Evaluaciones» e «Información».
46
5.2 Plataforma UPMScore
Figura 5.21: UPMScore - Profesor: Evaluaciones y Tareas de la asignatura
En el segmento de «Evaluaciones» se nos muestra un desplegable que nos permite elegir
una evaluación previamente creada, o bien, una opción para crear una nueva evaluación. En
esta figura, se muestra una evaluación con sus diferentes tareas. Cada tarea muestra el nombre,
la nota mínima, el peso en la evaluación y si es individual o grupal. Para crear nuevas tareas
o modificar datos de la evaluación, hay un botón con una «varita mágica» que permite estas
operaciones. Cada tarea tiene un botón que permite editar los datos de esta, o bien consultar
o poner las actas de la tarea.
47
5 Resultados
Figura 5.22: UPMScore - Profesor: Crear
nueva evaluación
Figura 5.23: UPMScore - Profesor: Crear
nueva tarea evaluación
Las figuras 5.22 y 5.23 muestran las ventanas emergentes en formato modal que permiten
la creación/edición de una evaluación y de una tarea.
La edición de una evaluación consta de un formulario el cual contiene dos campos. El
primer campo es el del nombre que recibirá la evaluación y el segundo es el de la nota mínima
que un alumno deberá obtener para que se considere aprobado.
La edición de la tarea también consta de un formulario el cual contiene cuatro campos. El
primer campo es el del nombre que recibirá la tarea, el segundo el de la nota mínima que un
alumno deberá obtener para que se considere la tarea aprobada, el tercer campo el peso de la
nota en un rango (1 - 100) para la evaluación en la que se encuentra, y por último, el cuarto
campo define el número de integrantes necesario para esta tarea.
48
5.2 Plataforma UPMScore
Figura 5.24: UPMScore - Profesor: Información de la asignatura
En la figura 5.24 se muestra la vista que se obtiene al seleccionar el segmento de «Infor-
mación». Este a su vez está compuesto por otros dos segmentos, que muestran la información
de manera agrupada. Esta se agrupa en «Asignatura» y en «Alumnos».
En el segmento de «Asignatura» muestra la información acerca de la asignatura de cara al
profesor. Esta información no es modificable por el profesor e informa sobre el identificador
único de la asignatura, el nombre, el semestre y el año. Por otra parte, los profesores que
imparten dicha asignatura y sus correos electrónicos, y por último, las asignaturas UPM que
están vinculadas a esta asignatura.
49
5 Resultados
Figura 5.25: UPMScore - Profesor: Información de los alumnos
En el segmento de «Alumnos» visible en la figura 5.25 se nos muestra una lista de alum-
nos, agrupada por asignaturas UPM. Esta lista de alumnos muestra la información básica del
alumno, una foto de perfil, su nombre y apellidos, su dirección de email, y la evaluación asig-
nada de las disponibles en el sistema. A su vez, tiene un botón con el que se puede modificar
la evaluación del alumno, antes de que haya sido ya evaluado de alguna tarea.
50
6Conclusiones
Este trabajo ha servido para conocer en profundidad el ciclo de análisis, diseño, desarrollo
y despliegue de una aplicación web mediante el uso de diferentes tecnologías y herramientas
de desarrollo.
La implementación en las aplicaciones de servicios que se comunican con APIs de terce-
ros ha sido uno de los puntos claves en este trabajo, ya que requiere de obtener y procesar
documentación y a su vez entender el funcionamiento de las mismas para poder sacarle el
máximo provecho. En concreto, hemos trabajado con la API de la UPM, de GAUSS y de
Telegram.
A su vez, este trabajo ha sido muy útil para aplicar los conocimientos obtenidos en el gra-
do sobre programación, sistemas orientados a servicios, bases de datos, gestión de proyectos
e interacción persona ordenador.
51
7Lineas Futuras
El proyecto deja abiertas muchas posibilidades a la hora de mejorar o ampliar las fun-
cionalidades de las diferentes aplicaciones web. Dado que la duración de este trabajo ha sido
insuficiente para la implementación de todos los requisitos, unas mejoras notables podrían
ser las siguientes:
Implementar un panel para que el alumno pueda consultar sus notas.
Implementar una zona de ajustes, donde el profesor o alumno puedan modificar sus
preferencias.
Implementar funciones protegidas de la API UPM que permitan obtener más informa-
ción del alumno, como su fotografía de perfil, si se encuentra al corriente de pago,
etc.
Implementar más funciones en el bot de Telegram que permita obtener más informa-
ción.
Diseñar un servicio que se comunique directamente con APOLO para enviar/recibir los
ficheros y evitar que sea un proceso manual.
Enriquecer la experiencia del profesor mediante la implementación de estadísticas.
Gracias a la modularidad del código y al uso de micro-servicios, se podrían realizar otras
tareas mediante el uso de otras API-REST.
53
Bibliografía
[1] Expansión. (2018). Las cifras de Internet: En España el 85 % de la población está
conectada, dirección: http://www.expansion.com/economia- digital/innovacion/
2018/02/01/5a72e73a22601db2288b4658.html (visitado 15-03-2019).
[2] Telegram. (2019). Telegram Messenger, dirección: https://telegram.org/ (visitado
12-06-2019).
[3] Moodle. (2019). Moodle - Open-source learning platform | Moodle.org, dirección:
https://moodle.org/?lang=es (visitado 15-03-2019).
[4] Sakai. (2019). Sakai Learning Management System | Higher Education, dirección:
https://www.sakailms.org/ (visitado 15-03-2019).
[5] ATutor. (2019). ATutor Home, dirección: https : / / atutor . github . io/ (visitado
15-03-2019).
[6] Chamilo. (2019). Chamilo.org – Asociación Chamilo, dirección: https://chamilo.
org/es/ (visitado 15-03-2019).
[7] Docker. (2019). Enterprise Container Platform | Docker, dirección: https : / / www .
docker.com/ (visitado 12-06-2019).
[8] Java. (2019). java.com: Java y Tú, dirección: https://www.java.com/es/ (visitado
12-06-2019).
[9] Maven. (2019). Maven – Welcome to Apache Maven, dirección: https : / / maven .
apache.org/ (visitado 12-06-2019).
[10] Spring. (2019). Spring Framework, dirección: https://spring.io/ (visitado 12-06-2019).
[11] Thymeleaf. (2019). Thymeleaf, dirección: https : / / www . thymeleaf . org/ (visitado
12-06-2019).
[12] JWT. (2019). JSON Web Tokens - jwt.io, dirección: https : / / jwt . io/ (visitado
15-06-2019).
55
BIBLIOGRAFÍA
[13] R. 7519. (2015). RFC 7519 - JSON Web Token (JWT), dirección: https://tools.
ietf.org/html/rfc7519 (visitado 15-06-2019).
[14] MySQL. (2019). MySQL, dirección: https://www.mysql.com/ (visitado 12-06-2019).
[15] S. Overflow. (2019). Stack Overflow Developer Survey 2019, dirección: https : / /
insights . stackoverflow . com / survey / 2019 / #technology - _ - databases (visitado
12-06-2019).
[16] ORACLE. (2015). Core J2EE Patterns - Data Access Object, dirección: https://www.
oracle.com/technetwork/java/dataaccessobject-138824.html (visitado 16-06-2019).
[17] U. P. de Madrid. (2019). APOLO - Login, dirección: https://www.upm.es/apolo/
(visitado 19-06-2019).
[18] ——, (2019). apiUPM, dirección: https://www.upm.es/apiupm/index.html (visitado
17-06-2019).
[19] ——, (2019). GAUSS - Login, dirección: https : / / www . upm . es / gauss/ (visitado
17-06-2019).
[20] Telegram. (2019). Bots: An introduction for developers, dirección: https://core.
telegram.org/bots/ (visitado 17-06-2019).
[21] R. 6749. (2019). RFC 6749 - The OAuth 2.0 Authorization Framework, dirección:
https://tools.ietf.org/html/rfc6749 (visitado 17-06-2019).
56
Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,
C=ES
Fecha/Hora Sat Jun 29 17:36:09 CEST 2019
Emisor delCertificado
EMAILADDRESS=camanager@fi.upm.es, CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES
Numero de Serie 630
Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe Signature)