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

VI

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

VIII

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

X

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

1 Introducción

4

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

2 Estado del arte

8

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 Resultados

Figura 5.1: Web de auto-gestión: Página principal

28

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

6 Conclusiones

52

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

7 Lineas Futuras

54

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)