sistema de reservas de espacios a travÉs de la webtauja.ujaen.es/bitstream/10953.1/8833/1/tfg...

Escu

ela

Polit

écn

ica S

up

eri

or

de J

aé

n

UNIVERSIDAD DE JAÉN Escuela Politécnica Superior de Jaén

Trabajo Fin de Grado

SISTEMA DE RESERVAS DE

ESPACIOS A TRAVÉS DE LA

WEB

Alumno: Sebastián Collado Montañez Tutor: Prof. D. Arturo Montejo Ráez Dpto: Departamento de Informática

Octubre, 2018

Universidad de Jaén

Escuela Politécnica Superior de Jaén

Departamento de Informática

Don Arturo Montejo Ráez, tutor del Trabajo Fin de Grado titulado: Sistema de

reservas de espacios a través de la web, que presenta Sebastián Collado

Montañez, autoriza su presentación para defensa y evaluación en la Escuela

Politécnica Superior de Jaén.

Jaén, octubre de 2018

El alumno: El tutor:

Sebastián Collado Montañez Arturo Montejo Ráez

Sebastián Collado Montañez Sistema de reservas de espacios a través de la web

2 Escuela Politécnica Superior de Jaén

Índice Índice de ilustraciones ........................................................................................................... 5

1. INTRODUCCIÓN ........................................................................................................... 8

1.1. Motivación ............................................................................................................... 8

1.2. Objetivos ................................................................................................................. 8

1.3. Metodología ............................................................................................................ 9

1.4. Estructura de la memoria .......................................................................................10

2. ANÁLISIS DEL PROBLEMA .........................................................................................12

2.1. Análisis de casos de uso ........................................................................................12

2.2. Análisis de requisitos ..............................................................................................12

2.3. Solución propuesta ................................................................................................14

2.4. Análisis de seguridad .............................................................................................15

2.5. Estimación de recursos ..........................................................................................16

2.5.1. Estimación temporal ........................................................................................16

2.5.2. Estimación económica ....................................................................................18

3. ESTADO DEL ARTE .....................................................................................................20

3.1. Situación actual de la tecnología ............................................................................20

3.1.1. Google Calendar .............................................................................................20

3.1.2. SuperSaas ......................................................................................................21

3.1.3. Timify ..............................................................................................................22

3.2. Crítica al estado del arte ........................................................................................22

3.3. Propuesta ...............................................................................................................23

4. DISEÑO ........................................................................................................................25

4.1. Diseño de la interfaz...............................................................................................25

4.1.1. Mockup ...........................................................................................................26

4.2. Análisis de las herramientas ...................................................................................28

4.2.1. Herramienta para el diseño de la interfaz ........................................................28

4.2.2. Herramienta para el desarrollo de aplicación cliente .......................................29

4.2.3. Entorno de desarrollo en el lado del servidor ..................................................32

4.2.4. Herramienta para el desarrollo de la API REST ..............................................33

4.2.5. Herramienta para la persistencia de datos en el lado del servidor ...................35

4.2.6. Otras herramientas utilizadas ..........................................................................35

4.3. Arquitectura software .............................................................................................36

4.3.1. Estructura de directorios .................................................................................36

4.3.2. Arquitectura del conjunto de tecnologías .........................................................37

4.3.3. Diseño del modelo de datos ............................................................................37



5. IMPLEMENTACIÓN ......................................................................................................43

5.1. Preparación del entorno de desarrollo local ...........................................................43

5.2. Implementación de la interfaz visual desde mockup ...............................................43

5.2.1. Vista general ...................................................................................................43

5.2.2. Elementos de interfaz para reservas ...............................................................44

5.2.3. Elementos de interfaz para dependencias .......................................................45

5.2.4. Elementos de interfaz para la gestión de usuarios ..........................................47

5.2.5. Elementos de interfaz para la configuración del calendario .............................48

5.2.6. Elementos de interfaz para mostrar estadísticas de uso .................................48

5.3. Definición de modelos en LoopBack ......................................................................49

5.4. Migración de modelos de LoopBack a esquema MySQL .......................................50

5.5. Definición de clases en Angular .............................................................................51

5.6. Implementación del sistema de autenticación en Angular y LoopBack ...................51

5.7. Implementación de servicios en Angular ................................................................53

5.7.1. Servicio “Client” ...............................................................................................53

5.7.2. Servicio “Room” ..............................................................................................54

5.7.3. Servicio “Book” ................................................................................................54

5.7.4. Servicio “Calendar” .........................................................................................55

5.7.5. Servicio “Socket” .............................................................................................55

5.8. Implementación de componentes en Angular .........................................................56

5.9. Implementación de filtros o funciones (pipes) en Angular .......................................57

5.10. Implementación de tecnología websocket...........................................................57

5.11. Definición y uso de múltiples entornos (environments) en Angular .....................57

5.12. Trabajo realizado sobre servidor de pruebas y producción .................................59

5.12.1. Lanzamiento del servicio .............................................................................59

5.12.2. Salida al exterior y HTTPS ...........................................................................59

5.12.3. Mecanismo de copia de seguridad ..............................................................60

6. RESULTADOS ..............................................................................................................61

7. CONCLUSIONES..........................................................................................................66

8. TRABAJOS FUTUROS .................................................................................................67

8.1. Distribución ............................................................................................................67

8.2. Implantación física .................................................................................................67

8.3. Mejora en copias de seguridad ..............................................................................67

8.4. Nuevas funcionalidades .........................................................................................67

9. REFLEXIONES FINALES .............................................................................................69

Bibliografía ...........................................................................................................................70



Anexo I: Manual de despliegue ............................................................................................71

Atom .................................................................................................................................71

Node.js, LoopBack, Angular..............................................................................................71

Docker y MySQL ...............................................................................................................71



Índice de ilustraciones Ilustración 1 - Flujo de trabajo con Scrum.............................................................................10

Ilustración 2 - Diagrama de casos de uso .............................................................................12

Ilustración 3 - Esquema de la solución posible .....................................................................15

Ilustración 4 - Google Calendar ............................................................................................21

Ilustración 5 - SuperSaas .....................................................................................................21

Ilustración 6 - Timify .............................................................................................................22

Ilustración 7 - Modelo de funcionamiento del conjunto de aplicaciones encontradas ............23

Ilustración 8 - Modelo de funcionamiento de la propuesta ....................................................23

Ilustración 9 - Aspecto de la aplicación para usuarios sin estar autenticados .......................26

Ilustración 10 - Aspecto de la aplicación para usuarios autenticados ...................................26

Ilustración 11 - Aspecto de la aplicación para el administrador .............................................27

Ilustración 12 - Búsquedas en Google para los principales framework para “front-end”........28

Ilustración 13 - Interacciones y contribuciones a Bootstrap en GitHub .................................29

Ilustración 14 - Interacciones y contribuciones a Foundation en GitHub ...............................29

Ilustración 15 - Búsquedas en Google para los principales framework de “front-end” ...........30

Ilustración 16 - Interacciones y contribuciones a Angular en GitHub ....................................30

Ilustración 17 - Interacciones y contribuciones a React en GitHub .......................................30

Ilustración 18 - Logotipo de Angular .....................................................................................30

Ilustración 19 - Patrón de arquitectura de software PAC ......................................................31

Ilustración 20 - Búsquedas en Google para los principales sistemas de desarrollo web en

servidor ................................................................................................................................32

Ilustración 21 - Logotipo de LoopBack ..................................................................................33

Ilustración 22 - Arquitectura de módulos de LoopBack .........................................................34

Ilustración 23 - Logotipo de MySQL......................................................................................35

Ilustración 24 - Logotipo de Docker ......................................................................................35

Ilustración 25 - Logotipo de Atom .........................................................................................35

Ilustración 26 - Logotipo de GitLab .......................................................................................36

Ilustración 27 - Estructura de directorios del proyecto ..........................................................37

Ilustración 28 - Pila de tecnologías .......................................................................................37

Ilustración 29 - Diagrama Entidad-Relación ..........................................................................38

Ilustración 30 - Vista general de la aplicación .......................................................................44

Ilustración 31 - Menú principal del administrador ..................................................................44

Ilustración 32 - Modales utilizados para las reservas ............................................................45

Ilustración 33 - Lista de dependencias para el administrador (izquierda), lista de

dependencias para el resto de usuarios (derecha) ...............................................................46



Ilustración 34 - Editar dependencia ......................................................................................46

Ilustración 35 - Selector de color para dependencia .............................................................47

Ilustración 36 - Panel de gestión de usuarios .......................................................................47

Ilustración 37 - Panel de configuración del calendario ..........................................................48

Ilustración 38 - Panel de estadísticas de uso ........................................................................48

Ilustración 39 - Uso de la función “automigrate” de LoopBack ..............................................51

Ilustración 40 - Definición de clases en Angular ...................................................................51

Ilustración 41 - Diagrama de secuencia del sistema de autenticación ..................................52

Ilustración 42 - Vista general de la aplicación en producción durante una semana de julio ..64

Ilustración 43 - Número de reservas en el servidor de producción .......................................64

Ilustración 44 - Número de clientes en el servidor de producción .........................................64

Ilustración 45 - Número de dependencias en el servidor de producción ...............................65



Índice de tablas

Tabla 1 - Planificación temporal inicial del proyecto .............................................................18

Tabla 2 - Gastos derivados de personal ...............................................................................19

Tabla 3 - Gastos derivados de material ................................................................................19

Tabla 4 - Diseño del modelo “Client” ....................................................................................39

Tabla 5 - Definición del modelo “room” .................................................................................40

Tabla 6 - Definición del modelo “book” .................................................................................41

Tabla 7 - Definición del modelo “config” ...............................................................................42

Tabla 8 - Métodos del servicio “client” en Angular ................................................................54

Tabla 9 - Métodos del servicio “Room” en Angular ...............................................................54

Tabla 10 - Métodos del servicio “Book” en Angular ..............................................................55

Tabla 11 - Métodos del servicio “Calendar” en Angular ........................................................55

Tabla 12 - Métodos del servicio “Socket” en Angular ............................................................56

Tabla 13 - Valores de Angular para entorno local .................................................................58

Tabla 14 - Valores de Angular para entorno de pruebas/producción ....................................59

Tabla 15 - Planificación temporal final del proyecto ..............................................................62

Tabla 16 - Errores en la aplicación desde despliegue en servidor de pruebas .....................63



1. INTRODUCCIÓN

El propósito de este proyecto es el desarrollo de un sistema para la gestión de

dependencias del Departamento de Psicología de la Universidad de Jaén. A

continuación se definen los conceptos y tareas básicas a realizar.

Este proyecto, desde sus inicios, ha sido orientado al aprendizaje y estudio de

nuevas tecnologías sobre las cuales no ha sido posible profundizar durante el grado.

Estas tecnologías son hoy en día referencia en el mercado laboral y su comprensión

permite llevar un paso más allá los conceptos y habilidades adquiridas durante estos

años de estudio.

Durante el desarrollo del proyecto se ha mantenido una comunicación continua

con el cliente, desarrollando de modo incremental un software que a día de hoy se

encuentra en fase de producción, con más de 90 usuarios activos.

1.1. Motivación

Este proyecto surge como una necesidad del propio Departamento de

Psicología de la Universidad de Jaén, donde la planificación y reserva de

dependencias dependía de un conjunto de personas que debían gestionar dichos

recursos, entre otras muchas tareas, lo que conllevaba una sobrecarga de trabajo

ante un problema que podría ser solucionado de forma informática.

1.2. Objetivos

El principal objetivo que abarca este proyecto, tal y como se ha comentado

anteriormente, es el de desarrollar una solución para el problema de la gestión de

dependencias. Para ello, se implementará una aplicación web que permitirá a los

usuarios interactuar sobre las dependencias existentes según su disponibilidad,

tramos horarios y otros factores que se detallarán posteriormente en esta memoria.

La plataforma desarrollada debe resultar intuitiva y sencilla de utilizar para el

usuario, buscando interacciones conocidas o familiares para el mismo. Además, es



importante facilitar la visualización de la aplicación desde múltiples dispositivos con

distintos tamaños de pantalla.

Al ser una aplicación utilizada por PDI/PAS de la Universidad de Jaén, se

deberá integrar el sistema de autenticación a través de las propias cuentas UJA.

Como objetivo adicional, se pretende indagar en tecnologías y herramientas

extendidas en el mercado laboral pero que durante el grado no se han podido

estudiar de forma profunda.

1.3. Metodología

Dada la necesidad de estructurar, planear y controlar el proceso de desarrollo

del proyecto, se busca un marco de desarrollo ágil que sea rápido, flexible y con una

alta integración del cliente en el proyecto: Scrum.

Scrum (Schawaber & Sutherland, 2018) es un marco de trabajo que permite

abordar problemas complejos, a la vez que entregar productos del máximo valor

posible. Se basa en las siguientes características:

Desarrollo iterativo e incremental, en lugar de la planificación y ejecución

completa del producto, lo que optimiza la predictibilidad y el control de

riesgo.

Solapamiento de las diferentes fases de desarrollo.

Gestión regular de las expectativas del cliente, lo que promueve:

resultados anticipados, flexibilidad y adaptación, mitigación de riesgos,

aumento de la productividad y calidad, alineamiento entre cliente y

equipo.



Ilustración 1 - Flujo de trabajo con Scrum

A continuación se detalla el flujo de trabajo con esta metodología:

Product Backlog: Conjunto de requisitos de la aplicación.

Sprint: Periodo de tiempo en el cual se lleva a cabo el trabajo en sí. La

duración debería ser constante y definida por la experiencia del equipo

de trabajo. Al finalizar el sprint el equipo debe presentar el resultado

obtenido, que debe ser un producto potencialmente entregable al cliente.

Planificación de Sprint: Al comienzo de un sprint, el equipo tiene una

reunión en la que se seleccionan los requisitos a cubrir del “Product

Backlog” y se generan las tareas para la nueva iteración (“Sprint

Backlog”).

Sprint Backlog: Conjunto de tareas seleccionadas que serán

completadas durante un sprint.

Reunión diaria de sincronización: Cada miembro del equipo muestra

su progreso, sus objetivos próximos e impedimentos en un máximo de

15 minutos. El objetivo de esta reunión es la transferencia de

información y comunicación entre los miembros del equipo para

aumentar su productividad.

1.4. Estructura de la memoria

En primera instancia se realiza un estudio del estado del arte, que permitirá

conocer de forma próxima la situación actual de las herramientas relacionadas con



el problema a solucionar. Este estudio permitirá tomar nota de buenas y malas ideas

para la consecución del proyecto, llegando a una propuesta de solución.

Posteriormente se realiza un análisis detallado del problema, con el objetivo de

conocer las necesidades del cliente sobre el software y poder así plantear una

buena solución.

Se continúa con el planteamiento del diseño de la aplicación, donde se definen

elementos clave en la funcionalidad y usabilidad del producto, permitiendo un

desarrollo donde todos los factores han sido valorados y tenidos en cuenta.

La implementación será el siguiente elemento importante que se encontrará en

la memoria. En este se encuentran todos los pasos seguidos para la consecución

del producto final desde que se realizó el diseño del mismo.



2. ANÁLISIS DEL PROBLEMA

Para reunir la información requerida en este punto, se realizó una reunión con

la dirección del Departamento de Psicología de la Universidad de Jaén a principios

de diciembre de 2017. Fruto de esta, se obtuvo información suficiente para realizar

los análisis que se plantean a continuación, dando lugar al “Sprint 1”.

2.1. Análisis de casos de uso

Con el análisis de casos de uso se pretende descomponer el funcionamiento

del sistema en partes más pequeñas. Cada parte de dicha descomposición se

centrará en una funcionalidad concreta y se denomina caso de uso. Los casos de

uso serán relacionados con diversos actores, que surgen de los roles de usuario

implicados en el uso del sistema.

Ilustración 2 - Diagrama de casos de uso

2.2. Análisis de requisitos

En este apartado se desarrolla el análisis de requisitos (Pressman, 2010) del

sistema.

Requisitos funcionales:



Relativos a los usuarios: autenticación institucional, añadir usuario,

añadir múltiples usuarios, filtrar usuarios, borrar usuario, borrar todos los

usuarios.

o El administrador debe poder gestionar el acceso a los usuarios de

forma individual o múltiple.

o El administrador debe poder filtrar la lista de usuarios según su

correo.

o Los usuarios válidos deben poder acceder a la aplicación

mediante su cuenta institucional de la Universidad de Jaén.

Relativos a las dependencias: Crear, visualizar, modificar, eliminar,

asignar supervisor de reservas.

o El administrador debe poder crear, visualizar, modificar y eliminar

dependencias.

o El administrador debe poder asignar a cualquier dependencia un

supervisor de reservas si así lo estima conveniente.

o Un supervisor de reservas asignado a una dependencia podrá

validar o rechazar reservas que sean realizadas sobre dicha

dependencia.

o Los usuarios deben poder visualizar las dependencias (nombre,

descripción, etc).

o Cuando un usuario intente reservar una dependencia con

supervisor, el supervisor recibirá un correo con enlaces de

confirmación/rechazo. Tras la acción del supervisor, el usuario

recibirá un correo con el resultado de dicha acción.

o Un visitante no usuario debe poder ver la lista de dependencias,

pero no conocer más información que el nombre de las mismas.

Relativos a las reservas: Crear, visualizar, eliminar.

o El administrador debe poder crear y visualizar reservas.

o El administrador debe poder eliminar cualquier reserva.

o Los usuarios deben poder crear y visualizar reservas.

o Los usuarios deben poder eliminar reservas que ellos mismos

hayan creado previamente.



o Un visitante no usuario debe poder ver las reservas en el

calendario, pero sólo verá el nombre de la reserva, la hora y la

dependencia a la que está asignada.

Relativos al calendario: Días de la semana habilitados, horario hábil,

días de antelación máximos para reserva.

o El administrador debe poder modificar los días de la semana

habilitados, el horario hábil y los días de antelación máximos para

las reservas.

Requisitos no funcionales:

Debe presentar una interfaz intuitiva y simple.

Debe poder ser operativa desde múltiples dispositivos en tiempo real,

permitiendo la concurrencia de acciones.

Cualquier usuario desde cualquier dispositivo debe poder trabajar de

forma sencilla con la aplicación.

La aplicación debe de ser accesible sin instalación previa en dispositivos

cliente.

La información deberá ser tratada de forma segura, siendo necesaria la

autenticación de los usuarios para el acceso a la misma.

La aplicación debe garantizar la seguridad en el acceso a la misma,

permitiendo sólo visualizar la información realizar las acciones según el

rol del usuario en cada momento.

2.3. Solución propuesta

A modo de resumen, la aplicación a desarrollar puede ser descrita como una

herramienta para la gestión de reservas sobre dependencias, realizadas por un

grupo limitado de personas que serán validadas por la dirección del departamento.

Dicha aplicación será utilizada por múltiples usuarios y dispositivos de forma

simultánea, por lo que la información que visualice debe estar actualizada en todo

momento. Los requisitos anteriores reflejan que una aplicación basada en la Web

sería una solución bien orientada a la solución del problema.



Es importante destacar que la información transmitida desde los dispositivos de

los usuarios debe ser tratada de forma segura.

El funcionamiento de la solución propuesta se basa en el modelo cliente-

servidor, donde el cliente será una aplicación web a la que el usuario accede a

través de su navegador web y que le permite tanto hacer reservas como conocer el

estado de las dependencias a lo largo del tiempo. Este cliente realizará de forma

transparente al usuario una serie de peticiones API hacia el servidor, enviando y

recibiendo la información que el usuario necesite en cada momento. Además el

servidor deberá notificar a la aplicación cliente sobre cambios realizados por otros

usuarios con el fin de mantener la información mostrada por la interfaz actualizada

en tiempo real.

Ilustración 3 - Esquema de la solución posible

2.4. Análisis de seguridad

En la solución posible quedan a la vista varios puntos donde la seguridad de la

información es crítica por lo que a continuación se detallarán y se indicarán las

acciones a realizar para mantener la aplicación segura.

El núcleo de información de la aplicación, al ser un sistema centralizado,

radica en el servidor, es decir, en la API REST. Es importante que la información que

allí se encuentre sea debidamente protegida mediante mecanismos de autenticación

y autorización para acceder a la misma. Para ello se definirán dentro de la API REST

una serie de roles que permitirán a cada usuario acceder a la información que le

corresponde.



Otro de los mecanismos a emplear para garantizar la seguridad de la

información del servidor será la autenticación de usuario mediante token de acceso

para el cliente. Un usuario que solicite cierta información necesitará un token que le

autentique como usuario lícito para dicha información.

En el apartado de la comunicación entre el cliente y el servidor, será necesario

establecer la comunicación mediante un protocolo seguro, como es HTTPS,

haciendo que todo el paso de mensajes desde un punto hasta el otro se encuentre

cifrado ante la posibilidad de atacantes que puedan situarse en puntos intermedios

de la comunicación.

Los datos que se generen con el uso de la aplicación deben ser persistentes en

el tiempo y se debe asegurar su recuperación en caso de anomalía en el servicio.

Por esto, se deben crear copias de seguridad de forma periódica de toda la

información almacenada en la base de datos de la aplicación.

Para terminar, es importante destacar que, tanto el sistema operativo que

ejecute el software, como las aplicaciones de base de datos necesarias, deben

encontrarse bajo la protección de contraseñas robustas.

2.5. Estimación de recursos

2.5.1. Estimación temporal

A continuación se detallan algunos puntos a tener en cuenta en la estimación

temporal:

El proyecto comienza con una reunión el día 4 de diciembre de 2017, en

la cual se obtienen los requisitos del sistema y se toma la idea general

del mismo.

El cliente indica que la fecha de finalización del proyecto debe situarse

sobre principios de junio de 2018, quedando un plazo de 26 semanas

para su realización.

En promedio, se dedicarán 5 horas diarias a la realización del proyecto.

Se debe tener en cuenta que la última semana de diciembre y primera

de enero es periodo vacacional.



Del 15 al 27 de enero (2 semanas) y del 21 al 31 de mayo (2 semanas)

serán periodos de exámenes para enseñanzas de grado, por lo que la

dedicación al proyecto se verá disminuida.

La semana del 26 al 30 de marzo es periodo vacacional.

Partiendo de los puntos anteriores, se establecerá la planificación en

base a 19 semanas de trabajo.

En la siguiente tabla se detalla la planificación semanal del proyecto:

Sprint Semana Actividades previstas

Sprint 1 1 (4 diciembre)

2 (11 diciembre)

Fase de análisis


4 (8 enero)

Validación del desarrollo actual

Selección de las actividades a

desarrollar

Estudio del estado del arte

Fase de diseño

Sprint 3 5 (29 enero)

6 (5 febrero)

7 (12 febrero)



desarrollar

Toma de contacto con las herramientas

Sprint 4 8 (19 febrero)

9 (26 febrero)

10 (5 marzo)

11 (12 marzo)



desarrollar

Implementación servidor

Sprint 5 12 (19 marzo) Validación del desarrollo actual



13 (2 abril)

14 (9 abril)

15 (16 abril)


desarrollar

Implementación cliente

Sprint 6 16 (23 abril)

17 (30 abril)



desarrollar

Despliegue en servidor de pruebas

Sprint 7 18 (7 mayo)

19 (14 mayo)



desarrollar

Fase de pruebas

Corrección de errores

Despliegue en servidor de producción

Sprint 8 - Validación del desarrollo actual


desarrollar

Correcciones y mejoras sugeridas por el

cliente

Tabla 1 - Planificación temporal inicial del proyecto

2.5.2. Estimación económica

Respecto a personal, el gasto se basará en el trabajo de un

analista/programador en prácticas, a tiempo parcial, que supondrá unos gastos de

aproximadamente 1000€ al mes.



Concepto Meses Importe unitario Total

Salario, impuestos, seguro y

otros gastos derivados

5 1000€ 5000€

Tabla 2 - Gastos derivados de personal

Los cálculos de costes para material aquí reflejados serán amortizados a 5

meses de duración del proyecto, teniendo como referencia 4 años (48 meses) de

vida útil para dispositivos electrónicos.

Concepto Descripción Coste

Ordenador portátil MacBook Pro 13” 2016 156,25€

Tabla 3 - Gastos derivados de material

Tras analizar los diferentes gastos del proyecto, tendremos una cifra total de

5156,25€.

Hay que tener en cuenta que los gastos del proyecto pueden variar ligeramente

durante su realización, por lo tanto, sería conveniente aplicar un porcentaje extra

como margen de seguridad. En el caso de este proyecto se aplicará un margen

amplio, del 10%, quedando en un total de 5671,88€.

Es importante destacar que esta cifra representa los costes estimados del

proyecto y no un presupuesto para el cliente, el cual debería incluir otros datos como

el margen de beneficio, impuestos y otros gastos periódicos como alojamiento y

dominio.



3. ESTADO DEL ARTE

En este apartado se analizará la situación actual de la tecnología, hablando de

aplicaciones que existen actualmente con funciones cercanas a los objetivos

buscados. Tras una valoración de dichas aplicaciones se expondrá la propuesta del

proyecto.

3.1. Situación actual de la tecnología

Existe una gran cantidad de aplicaciones online para tratar el problema

expuesto. Generalmente se trata de aplicaciones para gestionar recursos en

múltiples entornos como calendarios, aulas, clases, citas, inventarios, etc.

Las aplicaciones encontradas dentro de este ámbito suelen aparecer con un

modelo de distribución “Software como servicio”1 (del inglés: Software as a Service,

SaaS). Por lo general ofrecen una versión gratuita con anuncios y limitaciones en la

aplicación, junto a otras versiones de pago que integran distintas funcionalidades y

evitan los anuncios. A continuación se presentan algunos de estos sistemas.

3.1.1. Google Calendar2

Una herramienta con reconocimiento mundial, utilizada para la gestión de

agenda y horarios. Permite crear una serie de calendarios, los cuales pueden ser

compartidos con diferentes personas y donde se pueden añadir eventos. Su uso es

gratuito y sólo se necesita una cuenta de Google para poder utilizarlo.

1 Software como servicio. (Sin fecha). En Wikipedia. Recuperado de

https://es.wikipedia.org/wiki/Software_como_servicio el 12/07/2018. 2 Google Calendar. (Sin fecha). En Wikipedia. Recuperado de

https://es.wikipedia.org/wiki/Google_Calendar el 15/07/2018.

https://es.wikipedia.org/wiki/Software_como_servicio

https://es.wikipedia.org/wiki/Google_Calendar



Ilustración 4 - Google Calendar

3.1.2. SuperSaas3

Aplicación para la gestión de citas/reservas online. Dispone de una versión

gratuita para uso no comercial, con publicidad, restricciones de uso y un límite de 50

usuarios registrados. Para eliminar las restricciones de uso y aumentar la cantidad

de usuarios ofrece una serie de paquetes de diferentes precios. Dispone de

diferentes tipos de roles para los usuarios, los cuales deberán ser registrados de

forma individual, creando una cuenta por usuario dentro de la aplicación.

Ilustración 5 - SuperSaas

3 SuperSaaS. (2018). Sistema de reservas online. Recuperado de https://www.supersaas.es/ el 15 de

julio de 2018.

https://www.supersaas.es/



3.1.3. Timify4

Sistema de cita previa online y aplicaciones de calendario. Ofrece una variante

para el sector educativo que permite la gestión y planificación de clases, eventos,

recursos humanos y técnicos. Dispone de una versión gratuita para pocos usuarios y

otros planes de pago para mayor cantidad de usuarios y funciones.

Ilustración 6 - Timify

3.2. Crítica al estado del arte

El nicho de aplicaciones que incluyen las funcionalidades requeridas para

cumplir los objetivos del proyecto suelen orientarse a los sistemas de citas o

reservas para clientes de negocios concretos, añadiendo gran cantidad de

funcionalidad en ese apartado. Esto provoca una gran cantidad de funcionalidades

que son irrelevantes para el cliente del proyecto que se trata de poner en marcha,

pues el objetivo es gestionar recursos (dependencias), lo que sería únicamente el

primer paso a realizar en estas aplicaciones mencionadas.

Un ejemplo de lo anteriormente expuesto sería: un gimnasio establece un

horario de clases para sus clientes, los cuales se apuntarán al horario que deseen.

En este caso, los usuarios finales de la aplicación realizan la acción de inscribirse a

un horario ya creado por el administrador. En el caso de la aplicación que se

4 Timify. (2018). Sistema de citas previas y apps de calendario. Recuperado de

https://www.timify.com/es-es/ el 15/07/2018.

https://www.timify.com/es-es/



pretende desarrollar, los usuarios finales serán los encargados de crear ese horario,

el propio personal del departamento.

Ilustración 7 - Modelo de funcionamiento del conjunto de aplicaciones encontradas

Otro de los inconvenientes encontrados corresponde al objetivo de permitir a

los usuarios (PDI/PAS del Departamento de Psicología de la UJA) acceder a los

sistemas con sus cuentas institucionales de forma transparente, lo cual no está

implementado en ninguna de las soluciones encontradas.

Los sistemas generalistas encontrados disponen de ciertas funciones que

ayudarían a solucionar el problema expuesto, pero conllevan una complicada curva

de aprendizaje y generan dependencia de un software que puede cambiar a lo largo

del tiempo en sus funciones. Además carecen de ciertas funcionalidades que son

requeridas por el cliente de forma explícita, como son la autenticación institucional,

la validación de usuarios según los criterios de la dirección del departamento y otros

requisitos que se analizarán en apartados posteriores.

3.3. Propuesta

Partiendo de un esquema visual bien conocido como es Google Calendar, la

aplicación permitirá a los usuarios gestionar la planificación horaria de un conjunto

de dependencias con diferentes características. Dichos usuarios tendrán acceso

directo a la aplicación gracias a la autenticación a través de sus cuentas

institucionales (UJA), previa validación de la dirección del departamento.

Ilustración 8 - Modelo de funcionamiento de la propuesta



En cuanto a la interacción persona-ordenador5 (IPO) se priorizará una

metodología de diseño centrado en el usuario (en inglés UCD, user-centred design),

con el objetivo de hacer lo más sencilla y productiva posible la tarea a solucionar y

con el mínimo tiempo de adaptación al sistema.

Se registrarán y mostrarán una serie de estadísticas, tales como el porcentaje

de ocupación, número de reservas por dependencia y número de horas, que

permitirán a la dirección del departamento tomar decisiones acerca de las

dependencias en periodos posteriores.

5 Interacción persona-ordenador. (Sin fecha). En Wikipedia. Recuperado de

https://es.wikipedia.org/wiki/Interacci%C3%B3n_persona-computadora el 18/07/2018.

https://es.wikipedia.org/wiki/Interacci%C3%B3n_persona-computadora



4. DISEÑO

El diseño de software es una etapa fundamental que debe ser desarrollada de

forma previa a la implementación de la solución. El objetivo de esta es conseguir una

representación de calidad de la solución planteada, basada en las especificaciones

extraídas del análisis previo. Dicha representación permitirá abstraer la solución para

facilitar y mejorar el entendimiento del modo de proceder de cara al equipo de

desarrollo.

Durante este apartado se hará uso de diversas herramientas que permitirán

acometer la fase de implementación de software de forma más eficiente.

4.1. Diseño de la interfaz

La interfaz de usuario se basará en las siguientes características: facilidad de

uso, facilidad de aprendizaje, intuitividad, consistencia, eficiencia, libre de errores y

funcional.

El diseño se plantea con una arquitectura “single-page application”6 (SPA), con

la cual se tiene acceso a toda la información en una sola página, sin necesidad de

recargar, acercándose a lo que tradicionalmente se ha conocido como aplicaciones

de escritorio. Todo el uso de la aplicación se centra en una página y una serie de

elementos con los que interactuar, lo que simplifica el uso y aprendizaje.

En este apartado y dado que los estudios cursados no se centran en el diseño

gráfico, se hará uso de un framework7 que depure el aspecto visual relativo a los

elementos de interfaz que serán utilizados. Gracias a esto, se ahorrará un tiempo

considerable que será invertido en la consecución de los objetivos funcionales. No

obstante, el uso del framework elegido no exime de realizar un diseño general de la

disposición de los diversos elementos de la interfaz que formarán el aspecto general

de la aplicación. Para ello se plantean una serie de mockups o maquetas que

representarán de forma fiel el estado final que se buscará en la etapa de

implementación.

6 Single-page application. (Sin fecha). En Wikipedia. Recuperado de

https://es.wikipedia.org/wiki/Single-page_application el 14/10/2018. 7 Framework. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/Framework el

20/09/2018.

https://es.wikipedia.org/wiki/Single-page_application

https://es.wikipedia.org/wiki/Framework



4.1.1. Mockup

Tras la primera reunión con el cliente, la cual se enmarca en la fase de análisis,

se prepara el diseño de la interfaz. Se presentó el día 18 de diciembre de 2017 en

una segunda reunión con el cliente mediante los documentos gráficos que se

muestran a continuación.

En primer lugar se muestra el diseño creado para la aplicación orientado a

visitantes que no hayan realizado el proceso de autenticación institucional, por lo

que sólo tendrán acceso a información básica sobre las reservas.

Ilustración 9 - Aspecto de la aplicación para usuarios sin estar autenticados

Tras realizar el proceso de autenticación, los usuarios pueden crear nuevas

reservas y eliminar las propias.

Ilustración 10 - Aspecto de la aplicación para usuarios autenticados

Si el usuario es administrador, tendrá la siguiente visualización de la aplicación,

con permiso para eliminar y añadir reservas, añadir y eliminar dependencias, y

gestionar el calendario.



Ilustración 11 - Aspecto de la aplicación para el administrador

Es importante añadir que el aspecto final de la aplicación se basará en el

mockup, pero con alteraciones en el diseño de los elementos utilizados en el

planteamiento del mismo. El motivo de esto es la guía de estilos seguida durante la

creación del mockup, que fue Material Design8 y durante la implementación, debido

a la elección de Bootstrap (Getbootstrap, 2018) como framework, fue la propia guía

de estilos de este.

Gracias a la presentación del mockup en la segunda reunión, el cliente es

capaz de definir mejor algunas ideas del proyecto, requisitos que ya se encuentran

en la lista del presente documento. El conjunto de funcionalidades será más estable

a partir de este momento. Las funcionalidades añadidas son:

El administrador debe poder gestionar el acceso a los usuarios de forma

individual o múltiple.

Funcionalidades relativas al supervisor de reservas sobre dependencias.

8 Material Design. (Sin fecha). En Wikipedia. Recuperado de

https://es.wikipedia.org/wiki/Material_design el 14/10/2018.

https://es.wikipedia.org/wiki/Material_design



4.2. Análisis de las herramientas

4.2.1. Herramienta para el diseño de la interfaz

El “front-end” es la parte del trabajo durante el desarrollo web que se encarga

de la interfaz y hace que los usuarios puedan visualizar e interactuar con el sistema.

El conjunto de tecnologías que agrupa son ejecutadas directamente en el equipo

cliente, más concretamente sobre su navegador web, y son servidas a través de

servidores web.

Para tomar una decisión, se analiza el impacto de los principales frameworks

orientados a “front-end” en el mercado actualmente. Para ello se toman como

referencia datos como las búsquedas de los usuarios en Google, además de la

actividad y colaboración de la comunidad en los respectivos proyectos de GitHub9,

para asegurar la mayor estabilidad del producto final.

Ilustración 12 - Búsquedas en Google para los principales framework para “front-end”

Como se puede observar en Google Trends10, el framework con mayor número

de búsquedas en España sería Bootstrap11, seguido de Foundation12. A continuación

se muestra la información de GitHub de ambos proyectos para determinar la vida de

los mismos y su continuidad.

9 GitHub. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/GitHub el 14/10/2018.

10 Google. (2018). Google Trends. Recuperado de https://trends.google.es/trends/ el 15/08/2018.

11 Bootstrap. (Sin fecha). En Wikipedia. Recuperado de

https://es.wikipedia.org/wiki/Bootstrap_(framework) el 14/10/2018. 12

Foundation. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/Foundation_(framework) el 14/10/2018.

https://es.wikipedia.org/wiki/GitHub

https://trends.google.es/trends/

https://es.wikipedia.org/wiki/Bootstrap_(framework)

https://es.wikipedia.org/wiki/Foundation_(framework)



Ilustración 13 - Interacciones y contribuciones a Bootstrap en GitHub

Ilustración 14 - Interacciones y contribuciones a Foundation en GitHub

Tal y como se observa, ambos proyectos tienen una gran comunidad a sus

espaldas, lo que hace pensar que ambos serán una opción factible de cara a ser

utilizados dentro del proyecto desarrollado.

Finalmente se opta por Bootstrap 4 por varios factores: tener una gran

comunidad que lo respalda, ser un proyecto en constante evolución y mejora, ser

uno de los principales frameworks relativos a la interfaz de usuario en el mercado

actual, y por último, la experiencia previa del equipo de desarrollo con dicha

herramienta, lo que agilizará la implementación y asegurará un mejor resultado final

en menos tiempo.

4.2.2. Herramienta para el desarrollo de aplicación cliente

Del mismo modo que se desarrollan aplicaciones nativas para los diversos

sistemas operativos (Linux, Android, macOS, Windows, etc), existe la posibilidad de

desarrollar aplicaciones web que se ejecutarán directamente sobre el navegador del

cliente, pero con toda la funcionalidad que podríamos esperar de una aplicación

nativa. Esto es así gracias a tecnologías como HTML513 y JavaScript14.

Para crear este tipo de aplicaciones de una forma robusta, eficiente y escalable

es recomendable hacer uso de alguno de los múltiples frameworks que existen en el

mercado para dicho fin.

A continuación se presentan los datos que han sido tenidos en cuenta para la

elección en este proyecto:

13

HTML5. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/HTML5 el 14/10/2018. 14

JavaScript. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/JavaScript el 14/10/2018.

https://es.wikipedia.org/wiki/HTML5

https://es.wikipedia.org/wiki/JavaScript



Ilustración 15 - Búsquedas en Google para los principales framework de “front-end”

Ilustración 16 - Interacciones y contribuciones a Angular en GitHub

Ilustración 17 - Interacciones y contribuciones a React en GitHub

Un factor determinante en la elección es la inquietud por aprender Angular15

(Google, 2018), pues en experiencias previas se ha trabajado con AngularJS16, la

versión anterior de este. El por qué de esta inquietud también viene justificado por

los datos de uso y la búsqueda en diversas fuentes como Google Trends y GitHub.

Ilustración 18 - Logotipo de Angular

Angular (comúnmente llamado Angular 2) es un framework para aplicaciones

web desarrollado en TypeScript17, de código abierto y mantenido por Google que

15

Angular. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/Angular_(framework) el 14/10/2018. 16

AngularJS. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/AngularJS el 14/10/2018. 17

TypeScript. 2018. Typescriptlang. Recuperado de https://www.typescriptlang.org/index.html el 14/10/2018.

https://es.wikipedia.org/wiki/Angular_(framework)

https://es.wikipedia.org/wiki/AngularJS

https://www.typescriptlang.org/index.html



permite desarrollar aplicaciones basadas en una arquitectura SPA (“single-page

application”).

TypeScript es un lenguaje de programación que compila en JavaScript. Es un

superconjunto de JavaScript, de código abierto y mantenido por Microsoft.

Principalmente añade tipado estático y objetos basados en clases. Una de sus

principales ventajas utilizándolo en Angular es que permite al equipo de desarrollo

detectar errores en tiempo de compilación, lo cual simplifica el proceso de depurado

de código en muchas ocasiones.

Angular puede ser definido mediante una aproximación al patrón de

arquitectura de software Presentación-abstracción-control (PAC) (Coutaz, 1987).

Este patrón define una estructura jerárquica de componentes que contienen a su vez

tres elementos:

Presentación: Presenta las vistas o elementos de interfaz de la aplicación.

Abstracción: Recupera y procesa los datos.

Control: Conecta la capa de presentación y la abstracción, añadiendo una

capa de funcionalidad. Define la lógica de la aplicación.

Ilustración 19 - Patrón de arquitectura de software PAC

En Angular, cada componente contiene de forma empaquetada los siguientes

elementos:



Plantilla: Capa de presentación. Se define principalmente con lenguajes de

marcado (HTML, CSS).

Una clase donde se define la lógica del componente (control).

Una pequeña parte de abstracción de datos correspondiente a los datos del

componente exclusivamente.

La parte importante de abstracción se mantiene en unos elementos llamados

servicios, donde se define toda la comunicación necesaria para la recuperación y

procesamiento de datos de la aplicación. Los componentes se nutrirán a partir de su

comunicación con los servicios.

4.2.3. Entorno de desarrollo en el lado del servidor

La elección de esta herramienta viene principalmente motivada por el interés

de aprender una tecnología en constante crecimiento y cada vez más solicitada en el

mercado laboral: Node.js18.

A continuación se muestra el crecimiento de Node.js respecto a las principales

tecnologías del lado de servidor históricamente.

Ilustración 20 - Búsquedas en Google para los principales sistemas de desarrollo web en servidor

Node.js es un entorno de ejecución, multiplataforma y de código abierto,

principalmente utilizado en la parte servidor. Está basado en el lenguaje de

programación ECMAScript, asíncrono y con una arquitectura orientada a eventos

18

Node.js. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/Node.js el 20/08/2018.

https://es.wikipedia.org/wiki/Node.js



para la gestión de las peticiones de entrada/salida, lo que permite crear programas

en red altamente escalables, como por ejemplo servidores web.

4.2.4. Herramienta para el desarrollo de la API REST

REST19 (Representational State Transfer) es un estilo de arquitectura software

para sistemas hipermedia distribuidos (Fielding, 2000) que permite obtener u operar

sobre datos de forma sencilla. Dentro de REST, existe un principio llamado

HATEOAS20 (Hypermedia As The Engine Of Application State) que define que cada

vez que se hace una petición al servidor, éste devuelve una respuesta (en el caso de

este proyecto, en formato JSON).

Para realizar las comunicaciones entre cliente y servidor, se busca poner en

marcha una API REST. Tras comenzar a investigar Node.js se decide utilizar un

framework para simplificar y agilizar la creación de la API REST. LoopBack

(StrongLoop, 2018) es la herramienta escogida por cumplir con las siguientes

características:

Curva de aprendizaje asequible.

Documentación detallada y actualizada.

Proyecto open-source, con el respaldo de IBM.

Comunidad grande y activa.

Pone a disposición del desarrollador de un explorador de endpoints.

Permite generar el esquema de la base de datos a partir de los modelos.

Simplicidad para la definición de métodos, ACLs, restricciones y otros

elementos clave.

Ilustración 21 - Logotipo de LoopBack

19

Transferencia de estado representacional. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional el 20/09/2018. 20

HATEOAS. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/Hateoas el 20/09/2018.

https://es.wikipedia.org/wiki/Transferencia_de_Estado_Representacional

https://es.wikipedia.org/wiki/Hateoas



LoopBack se compone de un conjunto de módulos Node.js que pueden ser

utilizados individual o conjuntamente para construir APIs REST de forma rápida. El

siguiente diagrama ilustra los módulos clave de este framework.

Ilustración 22 - Arquitectura de módulos de LoopBack

Fuente: LoopBack 3.x Documentation. Recuperado de https://loopback.io/doc/en/lb3/index.html

El patrón de diseño de arquitectura de software Modelo-vista-controlador

(MVC) separa los datos y la lógica de negocio de su presentación. En LoopBack,

podemos encontrar la siguiente correspondencia de módulos respecto a las partes

de MVC:

“Models”: Definición de modelos y su comportamiento lógico (Controladores).

“Abstraction”: Abstracción de datos para su persistencia física (Modelos).

https://loopback.io/doc/en/lb3/index.html



“API Endpoints”: Capa de presentación de datos (Vistas).

4.2.5. Herramienta para la persistencia de datos en el lado del servidor

En el caso de la persistencia de datos, se opta por una solución más

tradicional, escogiendo MySQL21 como servidor de bases de datos. El motivo es la

seguridad del equipo de desarrollo para trabajar sobre dicha tecnología, aunque

podrían ser válidas otras como MariaDB22.

Ilustración 23 - Logotipo de MySQL

Por otro lado, y buscando la facilidad a la hora del despliegue e independencia

de la aplicación, la instalación del servicio MySQL se llevará a cabo mediante

Docker (Docker, 2018), un sistema de virtualización ligera.

Ilustración 24 - Logotipo de Docker

4.2.6. Otras herramientas utilizadas

Para el desarrollo del código de la aplicación, se ha optado por Atom23, un

editor de textos simple, pero con integración total con JavaScript, TypeScript,

HTML5 y CSS, puesto que serán los principales lenguajes utilizados.

Ilustración 25 - Logotipo de Atom

21

MySQL. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/MySQL el 14/10/2018. 22

MariaDB. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/MariaDB el 14/10/2018. 23

Atom. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/Atom_(software) el 14/10/2018.

https://es.wikipedia.org/wiki/MySQL

https://es.wikipedia.org/wiki/MariaDB

https://es.wikipedia.org/wiki/Atom_(software)



Como herramienta para la planificación de tareas, gestión documental y gestión

del código de la aplicación se ha optado por el servicio de GitLab24 ofrecido por la

Universidad de Jaén.

Ilustración 26 - Logotipo de GitLab

Otras herramientas relevantes son los diversos módulos y componentes de

Angular que permiten una implementación más rápida del proyecto. Entre ellos se

encuentran:

@ng-bootstrap/ng-bootstrap: Integración de múltiples elementos de Bootstrap

con Angular.

ap-angular2-fullcalendar: Adaptación para Angular de la librería de

calendarios JavaScript FullCalendar.

angularx-social-login: Simplifica la autenticación con proveedores externos

como Google o Facebook desde la perspectiva de Angular.

ngx-toastr: Permite mostrar notificaciones emergentes para informar de

acciones correctas, erróneas u otros estados de la aplicación.

4.3. Arquitectura software

4.3.1. Estructura de directorios

A continuación se muestra la estructura de directorios de la aplicación junto a

una breve nota que indica su finalidad en cada caso.

24

GitLab. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/GitLab el 14/10/2018.

https://es.wikipedia.org/wiki/GitLab



Ilustración 27 - Estructura de directorios del proyecto

4.3.2. Arquitectura del conjunto de tecnologías

A continuación se muestra el esquema planteado en el que se establece la

relación entre las tecnologías escogidas.

Ilustración 28 - Pila de tecnologías

4.3.3. Diseño del modelo de datos

En primer lugar se presenta un diagrama entidad-relación que permitirá tener

una visión general de los objetos existentes y sus relaciones.



Ilustración 29 - Diagrama Entidad-Relación

A partir del diagrama entidad-relación, se obtiene la estructura de las tablas

necesaria para la base de datos.

Listado de tablas para la base de datos:

client(id, email, username, isActive)

room(id, name, description, color, id_sup)

book(id, ,title, observation, start, end, status, id_client, id_room)

config(id, days, hours, maxBookTime)

Descripción de columnas específicas:

isActive: Indica si el usuario está activo o inactivo.

id_sup: Indica el usuario que tiene que autorizar la reserva.

status: 'RESERVED' | 'PENDING' | 'DENIED':

o Las reservas libres y las autorizadas toman el valor 'RESERVED'.

o Las reservas que necesitan autorización toman el valor 'PENDING'.

o Las reservas denegadas toman el valor 'DENIED'.

En las tablas que se muestran a continuación, se plantea el diseño para el

modelo de datos planteado para la solución del problema. Se incluyen propiedades,

métodos, relaciones y control de acceso para cada modelo (ACLs).



Modelo Elemento Nombre Descripción

Client Propiedades id (number) Identificador principal

email (string) Email del usuario

username

(string)

Nombre del usuario

isActive

(boolean)

Usuario activo o inactivo (borrado lógico)

Relaciones roles Relación del tipo “hasMany” con el modelo

“Role”. Puede tener cero o más roles de usuario.

Métodos CRUD Operaciones por defecto: Crear, Leer, Actualizar

y Borrar.

socialLogin Recibe las credenciales de usuario de Google y

devuelve el token de Loopback

socialRegister Crea usuarios a partir de su email o los reactiva

si ya existían

disableClient Deshabilita un cliente

disableAllClients Deshabilita todos los clientes que no son

administradores

ACLs admin El administrador tiene permiso sobre todos los

métodos del modelo

authenticated Los usuarios autenticados tienen acceso al

método “find” de este modelo

everyone Todo el mundo tiene acceso al método

“socialLogin” de este modelo

Tabla 4 - Diseño del modelo “Client”




room Propiedades id (number) Identificador principal

name (string) Nombre de la dependencia

description

(string)

Descripción de la dependencia

color (string) Color de la dependencia

id_sup

(number)

Identificador del supervisor asociado a la

dependencia

Relaciones supervisor Relación del tipo “belongsTo” con el modelo

“Client”. Puede tener cero o un supervisor.

Métodos CRUD Operaciones por defecto: Crear, Leer, Actualizar y

Borrar.


métodos del modelo

everyone Todo el mundo tiene acceso al método “find” de

este modelo

Tabla 5 - Definición del modelo “room”


book Propiedades id (number) Identificador principal

title (string) Título de la reserva

observation

(string)

Observaciones sobre la reserva

id_client

(number)

Identificador del usuario de la reserva

id_room Identificador de la dependencia reservada



(number)

start (date) Fecha y hora inicial de la reserva

end (date) Fecha y hora final de la reserva

status (string) Estado de la reserva: RESERVED | PENDING |

DENIED

Relaciones client Relación del tipo “belongsTo” con el modelo

“Client”. Puede tener cero o un cliente vinculado.

room Relación del tipo “belongsTo” con el modelo

“room”. Puede tener cero o una dependencia

vinculada.

Métodos CRUD Operaciones por defecto: Crear, Leer, Actualizar y

Borrar.

validate Un supervisor acepta o rechaza una reserva


métodos del modelo

authenticated Los usuarios autenticados pueden utilizar los

métodos “create” y “deleteById” de este modelo

everyone Todo el mundo puede utilizar los métodos “find” y

“validate” de este modelo

Tabla 6 - Definición del modelo “book”


config Propiedades days (object) Objeto que contiene los días de la semana a

mostrar en el calendario

hours (object) Objeto que contiene las horas hábiles del

calendario

maxBookTime Días de antelación máximos para reservar



(number) dependencias

Relaciones - -

Métodos CRUD Operaciones por defecto: Crear, Leer,

Actualizar y Borrar.

ACLs admin El administrador tiene permiso sobre todos

los métodos del modelo

everyone Todo el mundo puede utilizar el método

“findOne” de este modelo

Tabla 7 - Definición del modelo “config”



5. IMPLEMENTACIÓN

La etapa de implementación es el proceso mediante el cual se pasa a código la

propuesta generada a partir de las etapas de análisis y diseño. En el caso del

presente proyecto, al ser un producto que será puesto en producción, incluye una

fase de refinamiento del software, que vendrá dada por la interacción constante con

el cliente.

5.1. Preparación del entorno de desarrollo local

El proceso de preparación del entorno de desarrollo se puede encontrar en el

Anexo I: Manual de despliegue.

5.2. Implementación de la interfaz visual desde mockup

5.2.1. Vista general

Para comenzar se muestra una vista general de la aplicación. Se han utilizado

tanto elementos de Bootstrap 4 (botones, colores, barra de navegación, etc) como

propios (lista de dependencias con seleccionables, selector de colores, etc).

Como se puede observar a continuación, hay dos calendarios. El pequeño

servirá como acceso rápido al día, mes y año mostrado. El grande muestra la

información de las reservas realizadas sobre cada dependencia y será el principal

elemento de interacción para los usuarios, pudiendo consultar, reservar y cancelar

reservas desde este.

https://docs.google.com/document/d/1O5USTOcKiSCgvJf37aRRoooN1cLiVVxaiiHMMFThFGI/edit#heading=h.t7grtmokarxh



Ilustración 30 - Vista general de la aplicación

A continuación se muestra el menú principal de la aplicación, visible por el

administrador y le permitirá gestionar la aplicación. Los usuarios regulares solo

tendrán acceso a cerrar sesión desde este.

Ilustración 31 - Menú principal del administrador

5.2.2. Elementos de interfaz para reservas

A continuación se muestran dos modales (paneles que se muestran sobre la

pantalla) diseñados para la gestión de las reservas. A la izquierda se puede ver el

proceso de creación de una nueva reserva. A la derecha, la información visible de

una reserva tras su creación (elementos de solo lectura).



Ilustración 32 - Modales utilizados para las reservas

5.2.3. Elementos de interfaz para dependencias

En la parte izquierda de la vista general se puede ver la lista de dependencias

disponibles en la aplicación. El elemento de marcado (checkbox) permitirá que las

reservas relativas a dichas dependencias aparezcan o no en el calendario, de modo

que el usuario pueda filtrar las reservas que puede ver.

Los nombres de dependencias que superen el ancho del elemento, serán

cortados y se mostrará en su lugar puntos suspensivos. No obstante, si el puntero se

sitúa sobre dicho nombre, mostrará el nombre completo en un elemento emergente.



Ilustración 33 - Lista de dependencias para el administrador (izquierda), lista de dependencias para el resto de usuarios (derecha)

Un usuario autenticado presione sobre el nombre de una dependencia podrá

ver la información de la misma. El usuario administrador tendrá disponible un botón

para editar la información de las dependencias, tal y como se puede ver en el área

izquierda de la ilustración anterior. Una vez pulsado este botón de edición, le llevará

al modal de edición correspondiente, visible en la siguiente ilustración.

Ilustración 34 - Editar dependencia

En el panel de edición de dependencia, se encuentra un apartado para asignar

el color de la misma, el cual se despliega al hacer click sobre el color que aparece.



Ilustración 35 - Selector de color para dependencia

5.2.4. Elementos de interfaz para la gestión de usuarios

El administrador podrá acceder desde el menú superior a diversos elementos

de la aplicación, entre los cuales se encuentra el panel de gestión de usuarios.

Ilustración 36 - Panel de gestión de usuarios

Este panel permitirá, desde el área izquierda del mismo, filtrar de forma

dinámica la lista de usuarios, identificar sus roles y eliminarlos de forma individual o

múltiple. Desde el área izquierda se podrán añadir usuarios línea a línea, de forma

que el administrador puede simplemente copiar una columna de usuarios desde una

hoja de cálculo y pegarla en el área de texto correspondiente para añadirlos.



5.2.5. Elementos de interfaz para la configuración del calendario

El administrador debe poder modificar ciertas configuraciones del calendario,

las cuales se aplicarán a todos los usuarios que accedan a la aplicación.

Ilustración 37 - Panel de configuración del calendario

5.2.6. Elementos de interfaz para mostrar estadísticas de uso

El administrador dispone de un panel de estadísticas, donde se mostrará una

serie de datos relacionados con la ocupación de las dependencias:

Ilustración 38 - Panel de estadísticas de uso



5.3. Definición de modelos en LoopBack

Una de las ventajas de LoopBack es que permite obtener automáticamente el

esquema de la base de datos desde la definición de modelos del propio framework

mediante el uso de los métodos “auto-migrate” (destruye todo el esquema previo en

su ejecución) o “auto-update” (respeta el esquema anterior y se adapta al mismo).

Esta utilidad evita tener que definir por un lado el esquema en MySQL y por otro en

el modelo de la API REST.

Otra razón para crear el esquema de la base de datos a partir de los modelos

es la existencia de ciertos modelos básicos de LoopBack que se utilizarán, por

ejemplo, la definición del modelo “Client” heredará del modelo base “User”. A causa

de ello parece más coherente realizar la definición de modelos en el propio

LoopBack y posteriormente generar el esquema de MySQL a partir de estos.

A continuación se detallan los factores tenidos en cuenta para la

implementación de modelos en LoopBack:

El modelo “Client” hereda desde el modelo base “User” existente en

LoopBack, como una especialización del mismo. Esto permite utilizar funcionalidad

ya implementada, como asignación de roles y tokens de usuario.

El modelo “room” hereda del modelo “PersistedModel” de LoopBack, lo que

implica una persistencia de datos en la base de datos. Puntos importantes que se

encuentran en este modelo:

Se valida la unicidad del nombre a la hora de crear o editar la dependencia.

El borrado de una dependencia implica un borrado en cascada de todas las

reservas asociadas a la misma. Para conseguirlo se hace uso de “Operation

hooks”, unos disparadores a nivel de API. En este caso, se hará mediante un

disparador “before delete”, borrando las reservas asociadas y posteriormente

la dependencia.

El modelo “book” hereda del modelo “PersistedModel” de LoopBack, lo que





En el momento de anterior a la creación de una reserva se ejecuta un método

“beforeRemote” en el cual se comprueba que el usuario incluido en la reserva

es quien dice ser, si la reserva está dentro de los plazos permitidos y si existe

disponibilidad en la dependencia para dicho tramo horario. Tras esto, se

comprueba si la dependencia tiene supervisor para las reservas, en cuyo

caso se enviará un correo de validación a este.

El correo de validación contiene dos enlaces, uno para aceptar y otro para

rechazar una reserva. Estos enlaces son generados a partir del objeto “book”,

el cual se pasa a cadena de texto. La cadena de texto es hasheada mediante

“bcrypt”, de modo que no se podrá recuperar información de la misma por

terceros. Para terminar, el hash se pasa por una función “URL encode”, en la

cual los caracteres que no son aptos para URL son sustituidos por otros

válidos. La cadena resultante de este proceso será el identificador de reserva

que se enviará como parte de la URL para la validación.

El método “validate” revierte y valida todas las operaciones aplicadas en el

punto anterior. Si se quiere aceptar la reserva y todavía hay disponibilidad se

aceptará la reserva, se enviará un correo al usuario que hizo la solicitud y otro

al supervisor como confirmación. Si se quiere rechazar, igualmente se envía

un correo al usuario y otro al supervisor con la notificación.

El modelo “config” hereda del modelo “PersistedModel” de LoopBack, lo que



Antes de actualizar el modelo “config”, se comprueba la integridad del mismo

(identificador, número de días, días de antelación) mediante un “Operation

hook” llamado “before save”.

5.4. Migración de modelos de LoopBack a esquema MySQL

El paso de generación del esquema para MySQL resulta muy sencillo. En

primer lugar se referencia la base de datos a utilizar dentro de las que existan

declaradas en el proyecto (en este caso sólo una, MySQL). Se listan los modelos

que se quieren migrar y se pasan a la función “automigrate”.



Ilustración 39 - Uso de la función “automigrate” de LoopBack

5.5. Definición de clases en Angular

Angular trabaja con TypeScript, un lenguaje tipado que compila en JavaScript,

lo cual permite definir las clases en el lado cliente. El uso de las clases es totalmente

opcional, pero puede resultar útil en el caso de clases muy utilizadas, definiendo

desde un primer momento sus atributos y tipos.

Se valora que definir las clases “Client”, “Book” y “Room” puede ser muy

beneficioso a la hora de implementar el resto de la aplicación Angular, pues la API

REST devolverá objetos con los mismos atributos, consiguiendo una aplicación más

robusta y homogénea.

Ilustración 40 - Definición de clases en Angular

5.6. Implementación del sistema de autenticación en Angular y

LoopBack

Uno de los principales requisitos de la aplicación se centra en la autenticación

institucional, cuya implementación se comentará en este punto.

La primera opción a valorar fue operar directamente con el sistema propio de

la Universidad de Jaén (SIDUJA), lo que resultó ser inviable por razones

institucionales y organizativas. Tras este intento, se opta por trabajar directamente

con el servicio de autenticación de Google,, pues todas las cuentas UJA son a su



vez cuentas de este servicio. Como contacto inicial se enumeran una serie de

elementos a tener en cuenta:

Las cuentas con dominio “@red.ujaen.es” son de estudiantes, por lo que

directamente se rechazará su conexión.

Las cuentas con dominio “@ujaen.es” son cuentas de personal (PDI/PAS),

por lo que podrán autenticarse con la aplicación siempre y cuando el

administrador de la misma las incluya en la lista de control de acceso.

El resto de dominios vinculados con Google serán automáticamente

descartados para conectarse a la aplicación.

A continuación se muestra un diagrama de secuencia para reflejar el sistema

de autenticación implementado.

Ilustración 41 - Diagrama de secuencia del sistema de autenticación

El diagrama anterior muestra cómo un usuario desde su aplicación cliente

consigue un token para hacer peticiones a la API REST, el cual guardará en una

cookie del navegador durante 24 horas. Para ello:

El usuario debe introducir su cuenta institucional en el sistema habitual de

autenticación con Google, el cual devuelve un token, junto información acerca

de la cuenta de usuario de Google, tal como el nombre y foto.

El token de Google se envía a la API REST (LoopBack).



La API, por motivos de seguridad, debe preguntar a Google si el token es

válido para dicho usuario.

En caso de validación por parte de Google, la API comprobará si ese usuario

está dentro de la lista de usuarios admitidos por el administrador.

Si el usuario es validado por Google y por la lista de acceso, se le devuelve

un token que le permite hacer peticiones a la API.

Si el usuario no es validado por Google o por la lista de acceso, se deniega el

token a la aplicación cliente.

5.7. Implementación de servicios en Angular

El propósito de los servicios en Angular es contener lógica de negocio, clases

para acceso a datos o utilidades de infraestructura. Los componentes delegan las

tareas de recuperación de datos del servidor y validación de datos sobre estos.

Los servicios implementados tienen como tarea principal hacer de bus de

comunicaciones entre el cliente y servidor, siendo los encargados de hacer las

peticiones necesarias a la API REST y a su vez comunicar las respuestas a los

componentes.

Otra tarea importante que realizan los servicios es mantener los objetos

existentes en los distintos componentes de la aplicación comunicados entre sí.

Se definen a continuación los servicios junto a sus métodos más importantes

para la comprensión del sistema.

5.7.1. Servicio “Client”

Este servicio es una clase utilizada para gestionar los objetos

correspondientes al usuario actual, acceso, creación de usuarios, lista de usuarios y

eliminar usuarios. Se compone de los siguientes métodos:



Método Petición

HTTP API

Descripción

setClient No Establece el objeto correspondiente al usuario

autenticado en todos los componentes de la aplicación

registerClients() Si Crea/activa múltiples clientes

disableClient() Si Borrado lógico de un cliente

disableAllClients() Si Borrado lógico de todos los clientes no administradores

getClients() Si Obtiene todos los usuarios

loginAPI() Si Obtiene un token de LoopBack a partir de un token de

Google

Tabla 8 - Métodos del servicio “client” en Angular

5.7.2. Servicio “Room”

Este servicio es una clase utilizada para la gestión de los objetos

correspondientes a las dependencias. Se encarga de los siguientes métodos:

Método Petición HTTP

API

Descripción

setRooms() No Establece la lista de dependencias para todos los

componentes de la aplicación

getRooms() Si Obtiene la lista de dependencias

createRoom() Si Crea una nueva dependencia

updateRoom() Si Actualiza una dependencia

deleteRoom() Si Elimina una dependencia

Tabla 9 - Métodos del servicio “Room” en Angular

5.7.3. Servicio “Book”

Es el servicio encargado para la gestión de objetos de tipo “Book”. Está

formado por los siguientes métodos:




API

Descripción

setBooks() No Establece la lista de reservas para todos los componentes

de la aplicación

getBooks() Si Obtiene la lista de reservas

createBook() Si Crea una nueva reserva

deleteBook() Si Elimina una reserva

Tabla 10 - Métodos del servicio “Book” en Angular

5.7.4. Servicio “Calendar”

El servicio “Calendar” permite sincronizar el día mostrado entre el calendario

de acceso rápido y el calendario principal. Además, gestiona la configuración del

calendario. A continuación se muestran los métodos que lo conforman:


API

Descripción

changeSelectedDate() No Mantiene la fecha entre ambos calendarios

sincronizada

getConfig() Si Obtiene la configuración del calendario

updateConfig Si Actualiza la información del calendario

Tabla 11 - Métodos del servicio “Calendar” en Angular

5.7.5. Servicio “Socket”

El servicio encargado de la comunicación socket gestiona todo el paso de

mensajes necesario para mantener la información de la aplicación actualizada en

tiempo real. Hace uso de la librería “socket.io-client” que se comunicará con

“socket.io-server” la cual se encuentra en el servidor. Dispone de los siguientes

métodos:



Método Petición

HTTP API

Descripción

sendMessage() Si Notifica a todos los clientes suscritos al socket que hay un

nuevo mensaje a través del servidor

onBookEvent() No Cuando recibe un mensaje de tipo “book” a través del

socket, actualiza la lista de objetos de ese tipo

onRoomEvent() No Cuando recibe un mensaje de tipo “room” a través del


onConfigEvent() No Cuando recibe un mensaje de tipo “config” a través del


Tabla 12 - Métodos del servicio “Socket” en Angular

5.8. Implementación de componentes en Angular

Los componentes son bloques básicos de construcción para una aplicación

Angular. Establece un mecanismo de definición de etiquetas HTML propias para la

aplicación, que permiten compactar y reutilizar código. Se pueden crear tantos

componentes como se requiera para la aplicación, que contendrán código HTML,

CSS y JavaScript, formando un bloque compacto y ordenado.

Angular provee un componente base para la aplicación, dentro del cual se

añadirán los sucesivos componentes creados por el equipo de desarrollo.

Para el proyecto se definen 7 nuevos componentes:

Calendario principal (custom-calendar).

Calendario secundario (sidebar-datepicker).

Lista de dependencias (sidebar-checkboxes).

Menú superior (sign-in).

Modal para gestión de usuarios (modal-users).

Modal para configuración de la aplicación (modal-config).

Modal para mostrar estadísticas (modal-statistics).



5.9. Implementación de filtros o funciones (pipes) en Angular

En ocasiones es necesario transformar los datos dentro de objetos o

colecciones de objetos. Por ejemplo, en la lista de usuarios queremos añadir la

funcionalidad de filtrar por email, dejando visibles únicamente los que coincidan con

la cadena introducida de forma parcial. Esto se consigue por medio de “pipes” en

Angular.

Durante el desarrollo del proyecto han sido necesarios dos filtros o “pipes”:

El del ejemplo mostrado anteriormente recibe una lista de clientes y una

cadena de texto, devolviendo la lista de clientes que concuerda con la cadena de

texto aportada.

Por otro lado, encontramos un mecanismo de ordenación, el cual dado una lista

de clientes, los ordena por orden alfabético.

5.10. Implementación de tecnología websocket

Websocket25 es una tecnología que hace posible abrir una sesión de

comunicación interactiva entre el cliente y el servidor. Este mecanismo permite en la

aplicación cubrir las siguientes situaciones (tal y como se indica en el apartado

“5.7.5. Servicio Socket”):

Un usuario añade una nueva reserva o dependencia. Todos los usuarios

visualizan esa reserva en sus calendarios sin necesidad de recargar la

página.

Un administrador modifica la configuración. Todos los usuarios reciben la

nueva configuración y se aplica sin recargar la página.

5.11. Definición y uso de múltiples entornos (environments) en

Angular

Angular es un framework que ofrece la posibilidad de definir conjuntos de

variables a los que llamaremos entornos. Cada entorno contendrá información

relativa al servidor donde se ejecuta con el fin de adaptarse a la situación del mismo.

25

WebSocket. (Sin fecha). En Wikipedia. Recuperado de https://es.wikipedia.org/wiki/WebSocket el 14/10/2018.

https://es.wikipedia.org/wiki/WebSocket



Tras definir los entornos, el código no necesitará ser modificado en función de dónde

se ejecute, sino que se añadirá un parámetro de compilación que hará que la

aplicación tome unas variables u otras.

En un estado avanzado de la implementación, y preparada la aplicación para

su fase de pruebas, se realiza una tarea de definición de varios entornos para la

aplicación cliente.

Hasta ahora se ha trabajado en la implementación y pruebas sobre el

ordenador del equipo de desarrollo, desplegando el software de forma local. Ahora,

se pretende dar acceso a múltiples usuarios a la plataforma con la finalidad de

comenzar una fase de pruebas. Para ello, se establecen dos entornos en Angular:

Default: Entorno por defecto con un conjunto de variables que serán utilizadas

cuando se compile en el servidor local. Para utilizar este conjunto de variables

es necesario lanzar el comando de construcción “ng serve” o “ng build”.

Variable Valor Descripción

production false La compilación se hará de forma rápida. La

aplicación de esta forma es más pesada y lenta.

serverUrl http://localhost:3000/ Dirección del servidor local

wssUrl http://localhost:3000/ Dirección del servidor de websocket local

apiUrl http://localhost:3000/api/ Dirección de la API REST local

Tabla 13 - Valores de Angular para entorno local

Prod: Entorno con un conjunto de variables que serán utilizadas cuando se

compile en un servidor remoto (pruebas o producción). Para utilizar este

conjunto de variables es necesario lanzar el comando de construcción “ng

build --prod”.



Variable Valor Descripción

production true La compilación se hará de forma lenta,

minimizando el código generado. La

aplicación funciona mucho más fluida.

serverUrl https://psicol.yottacode.com/ Dirección del servidor de pruebas/producción

wssUrl wss://psicol.yottacode.com/ Dirección del servidor de websocket de

pruebas/producción

apiUrl https://psicol.yottacode.com/api/ Dirección de la API REST de

pruebas/producción

Tabla 14 - Valores de Angular para entorno de pruebas/producción

5.12. Trabajo realizado sobre servidor de pruebas y producción

5.12.1. Lanzamiento del servicio

Una vez creados los entornos de Angular, la puesta en marcha del servidor de

pruebas se haría con los siguientes pasos:

Instalar los paquetes de software indicados en el Anexo I: Manual de

despliegue.

Descargar el proyecto desde GitLab.

Compilar la aplicación Angular para entornos de producción.

Lanzar el servidor con Node.js.

5.12.2. Salida al exterior y HTTPS

El servidor de producción es una máquina que ofrece más de un servicio, por

lo que se hace uso de “Apache HTTP Server26” para poder hacer accesible el

proyecto.

A través del servicio “Let’s Encrypt”27 se generan los dos ficheros necesarios,

el certificado y la clave, que son almacenados en el servidor. También es necesario

activar el módulo de Apache para SSL (“mod_ssl”).

26

Apache HTTP Server. (2018). The Apache HTTP Server Project. Recuperado de https://httpd.apache.org/ el 14/10/2018. 27

Let’s Encrypt. (2018). Let’s Encrypt. Recuperado de https://letsencrypt.org/ el 14/10/2018.




https://httpd.apache.org/

https://letsencrypt.org/



Se prepara un fichero “Virtual Host”28 de Apache para conseguir que las

peticiones que lleguen al servidor desde “psicol.yottacode.com:80” sean pasadas a

través de una regla de reescritura hacia “psicol.yottacode.com:443”, forzando la

entrada a la página a través de HTTPS.

Una vez que las peticiones están entrando por el puerto correspondiente a

HTTPS, son dirigidas a través de proxy internamente hasta el puerto 3000, en el cual

trabaja LoopBack por defecto.

Gracias al sistema implementado, un cliente que accediese a

“psicol.yottacode.com” sin indicar puerto alguno estaría entrando vía HTTPS y

además, de manera transparente, estaría consultando un servicio que realmente se

ofrece en el puerto 3000.

5.12.3. Mecanismo de copia de seguridad

Se crea una tarea cron29, definida en el archivo “daily” de Ubuntu, la cual se

ejecutará diariamente sobre el servidor, copiando el contenido del esquema y los

datos de MySQL sobre un fichero nombrado como el día de la semana que sea en

ese momento. Esto asegura una copia de seguridad para cada día durante la última

semana completa. Estos ficheros son almacenados en el sistema de ficheros del

sistema operativo.

28

Apache Virtual Host documentation. (2018). Apache HTTP Server Project. Recuperado de https://httpd.apache.org/docs/2.4/vhosts/index.html el 11/10/2018. 29

Cron es el programa que permite a usuarios de entornos Linux ejecutar automáticamente conjuntos de órdenes a una fecha u hora específica. Permite periodicidad en la ejecución de las mismas.

https://httpd.apache.org/docs/2.4/vhosts/index.html



6. RESULTADOS

En el presente apartado se procede a valorar los resultados obtenidos a lo

largo de todo el proyecto, recopilando las pruebas que justifiquen la buena

resolución del problema.

Como primer elemento importante en la presentación de resultados, se muestra

la planificación final resultante del proyecto, pues a lo largo del tiempo ha sufrido

alteraciones propias de un proyecto de desarrollo de software, pero siempre dentro

de los plazos y respetando el esquema original del proyecto.

Sprint Semana Actividades realizadas


2 (11 diciembre)

Estimación de recursos

Estudio del estado del arte

Análisis de requisitos

Análisis de seguridad

Diseño de la interfaz (mockup)


4 (8 enero)

5 (29 enero)

6 (5 febrero)

Análisis de las herramientas

Preparación del entorno de desarrollo local

Implementación de la interfaz visual desde mockup

Sprint 3 7 (12 febrero)

8 (19 febrero)

9 (26 febrero)

10 (5 marzo)

Definición de modelos en LoopBack

Migración de modelos de LoopBack a esquema MySQL



11 (12 marzo)

Sprint 4 12 (19 marzo)

13 (2 abril)

14 (9 abril)

15 (16 abril)

Definición de clases en Angular

Implementación del sistema de autenticación institucional

(Angular + LoopBack)

Sprint 5 16 (23 abril)

17 (30 abril)

18 (7 mayo)

19 (14 mayo)

Implementación de servicios en Angular

Implementación de componentes en Angular

Implementación de filtros o funciones (pipes) en Angular

Implementación de tecnología websocket

Sprint 6 20 (21 mayo) Definición y uso de múltiples entornos (environments) en

Angular

Puesta en marcha del servidor de pruebas

Sprint 7 21 (28 mayo)

22 (4 junio)

Fase de pruebas

Corrección de errores

Sprint 8 23 (11 junio) Puesta en marcha del servidor de producción

Implantación de mecanismo de copia de seguridad

Implementación HTTPS

Sprint 9 18 junio en

adelante

Servidor en producción con clientes operando con datos

reales

Correcciones/mejoras sugeridas por el cliente

Tabla 15 - Planificación temporal final del proyecto



Durante la fase de pruebas (Sprint 7 y 8) se seleccionó un pequeño conjunto

de personas para hacer pruebas. Fruto de las mismas, la aplicación presentó una

serie de fallos que la dirección del departamento fue notificando en varias ocasiones

para su subsanación. Estos fallos se describen a continuación:

Error Prioridad Fecha

notificación

Fecha

solución

Renombrar una cadena de texto Baja 8 junio 2018 11 junio

2018

Los usuarios autenticados no pueden ver

información sobre las dependencias

Media 8 junio 2018 11 junio

2018

Error al dar de alta usuarios Crítica 11 junio 2018 11 junio

2018

Renombrar una cadena de texto Baja 13 junio 2018 21 junio

2018

Error en selector de hora Baja 13 junio 2018 21 junio

2018

Tabla 16 - Errores en la aplicación desde despliegue en servidor de pruebas

Como prueba del resultado final de la aplicación se muestra una captura de la

aplicación de la semana del 16-21 de julio de 2018, en la cual se pueden observar

múltiples reservas sobre diversas dependencias.



Ilustración 42 - Vista general de la aplicación en producción durante una semana de julio

Se muestran a continuación algunos datos obtenidos del uso de la aplicación

durante los meses de junio, julio, agosto y septiembre:

Número de usuarios: 96

Número de reservas: 154

Número de dependencias: 11

Ilustración 43 - Número de reservas en el servidor de producción

Ilustración 44 - Número de clientes en el servidor de producción



Ilustración 45 - Número de dependencias en el servidor de producción

Al ser una aplicación en producción, la opinión de los usuarios es la mayor de

las pruebas sobre la buena o mala realización de un trabajo, por lo que se muestra a

continuación un fragmento de correo electrónico que justifica la llegada del proyecto

a buen puerto.

“Aprovecho para transmitiros el sentir mío y de mis compañeros en relación con

la satisfacción con la aplicación de reservas, sobre todo los que la hacían

manualmente. Felicitaciones por vuestro magnífico trabajo y muchas gracias.”

(Usuario anónimo. Junio de 2018)

A día de la entrega de esta memoria, 6 de septiembre de 2018, los usuarios no

han reportado nuevos errores o sugerencias de mejora y han vuelto a comenzar las

reservas tras el periodo vacacional de verano.



7. CONCLUSIONES

El problema de la gestión de dependencias de manera manual ha sido

solucionado con una implementación tecnológica de forma exitosa, lo cual era el

principal objetivo de este proyecto.

Pasando a valorar el apartado de eficiencia en la solución generada, parece

que cubre todos los requisitos de forma correcta y sencilla, pues no hay usuarios

que reporten problemas sobre la aplicación, ni siquiera propuestas de mejora sobre

la misma.

La solución implementada para la autenticación con cuentas institucionales ha

resultado en un sistema bastante sencillo de utilizar, que me ha permitido

profundizar en los sistemas de autenticación de terceros, lo cual se encuentra

actualmente a la orden del día y seguro que utilizaré en futuros proyectos.

Las herramientas seleccionadas para el proyecto han permitido conseguir los

objetivos planteados de forma correcta y rápida aún sin conocerlas en su mayoría al

principio del proyecto.

El desarrollo del proyecto ha supuesto un punto de inflexión en mis

conocimientos sobre las tecnologías utilizadas, permitiendo que pueda decidir entre

un mayor número de posibilidades en cada proyecto que acometa en un futuro.



8. TRABAJOS FUTUROS

8.1. Distribución

El proyecto tiene una clara línea de futuro en la Universidad de Jaén, dados los

siguientes factores:

Hay múltiples departamentos, facultades y otras unidades organizativas en la

universidad cuya gestión de las dependencias carece de automatización o es

muy rudimentaria.

El sistema desarrollado posee una alta integración con los sistemas de

autenticación de la universidad, por lo que su adaptación para otro colectivo

dentro de esta sería muy sencilla.

8.2. Implantación física

Otra de las líneas de futuro, expresada en una de las reuniones con la

dirección del Departamento de Psicología, es la implantación del sistema sobre

dispositivos como tablets/pantallas situadas físicamente en las proximidades de las

dependencias a reservar, permitiendo consultar directamente desde la puerta el

estado de la dependencia. También se baraja la posibilidad de hacer las reservas

directamente desde dichos dispositivos.

8.3. Mejora en copias de seguridad

Actualmente las copias de seguridad de toda una semana se almacenan en el

mismo sistema de archivos del servidor de trabajo. Esto puede ocasionar problemas

si hubiese conflictos en el disco duro o la máquina tuviese problemas. Podría

solucionarse haciendo una copia extra de los archivos a un directorio remoto de

forma regular.

8.4. Nuevas funcionalidades

Se detectan dos funcionalidades que posiblemente serían interesantes de

añadir, aunque nunca han sido mencionadas como requisito por parte del cliente a

fecha de presentación de este proyecto. A continuación se comentan brevemente:



Mostrar/ocultar todas las dependencias: Sería interesante disponer de un

botón para mostrar y ocultar todas las dependencias al mismo tiempo. Esto

permitiría una mayor productividad a la hora de trabajar con la aplicación

cuando se tienen muchas dependencias.

Reservas periódicas: En ciertos casos podría ser interesante poder realizar

reservas periódicas, de modo que reuniones o clases que se extienden a lo

largo de un periodo de tiempo se añadirían de forma automática marcando la

periodicidad necesaria (diaria, semanal, mensual, etc).



9. REFLEXIONES FINALES

El grado que he cursado y que finaliza con este proyecto me ha permitido

adquirir una serie de conocimientos, habilidades y aptitudes que entiendo

imprescindibles para mi desarrollo académico, profesional y personal.

Considero los conocimientos y técnicas adquiridos como una base

fundamental, aunque me gustaría resaltar la habilidad para abstraer problemas

complejos y ser capaz de generar una solución que simplifique y mejore la calidad

de vida de las personas como una de las capacidades más satisfactorias que

considero haber adquirido. En el presente proyecto puede verse como un problema

que en un principio ocupaba el tiempo de personas, que además tenían otras

muchas ocupaciones a lo largo de su jornada laboral (y una fuente de problemas

constante), ha sido reducido a una aplicación web intuitiva y sin necesidad de

supervisión personal.

Otro de los puntos que considero destacable es la habilidad para trabajar en un

equipo que además integra al cliente con un flujo de comunicación constante, con el

fin de alcanzar la mejor solución posible para el problema presentado.

En conclusión, se cierra una provechosa etapa y a su vez se abre la posibilidad

de continuar mis estudios con un máster que permita seguir ampliando

conocimientos y experiencias.



Bibliografía

(Schawaber & Sutherland, 2018) Ken Schwaber and Jeff Sutherland. (2018). The Scrum Guide. Recuperado de https://www.scrumguides.org/scrum-guide.html el 03/09/2018.

(Pressman, 2010) Pressman, Roger S. (2010). Ingeniería del software. Un enfoque práctico. Séptima edición. México DF, México. McGraw-Hill Interamericana Editores.

(Fielding, 2000) Fielding, Roy Thomas. (2000). Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.

(Coutaz, 1987) Coutaz, Joëlle. (1987). "PAC: an Implementation Model for Dialog Design". In Bullinger, H.-J.; Shackel, B. Proceedings of the Interact'87 conference, September 1–4, 1987, Stuttgart, DE. North-Holland. pp. 431–436.

(Google, 2018) Google. (2018). Angular Documentation. Recuperado de https://angular.io/docs el 03/09/2018.

(Docker, 2018) Docker Inc. (2018). Docker Documentation. Recuperado de https://docs.docker.com/ el 03/09/2018.

(StrongLoop, 2018) IBM/StrongLoop. (2018). LoopBack Documentation. Recuperado de https://loopback.io/doc/ el 03/09/2018.

(Getbootstrap, 2018) Getbootstrap. (2018). Bootstrap Documentation. Recuperado

de https://getbootstrap.com/docs/4.1/ el 03/09/2018.

https://www.scrumguides.org/scrum-guide.html

https://angular.io/docs

https://docs.docker.com/

https://loopback.io/doc/

https://getbootstrap.com/docs/4.1/



Anexo I: Manual de despliegue

Antes de comenzar con el desarrollo, es imprescindible preparar el equipo de

trabajo con el conjunto de herramientas a utilizar. Para ello, se instalará el siguiente

software:

Atom

Descargado desde su página oficial “https://atom.io/”. Se encuentra disponible

para Ubuntu, macOS, Windows, entre otros.

Node.js, LoopBack, Angular

Paquetes de software instalados desde la terminal de Ubuntu 16.04:

Ilustración I.1 - Instalación de Node.js, LoopBack y Angular

Docker y MySQL

Docker es un sistema de automatización para el despliegue de servicios dentro

de contenedores de software, por medio de virtualización. Cada contenedor de

software se encuentra aislado del sistema operativo en el que se ejecute,

permitiendo la comunicación mediante la configuración del mismo contenedor.

Para el desarrollo del proyecto se ha utilizado Docker como soporte para el

servicio MySQL, con la finalidad de mantener el servicio aislado de otros posibles

servicios iguales instalados en las máquinas y para simplificar el despliegue del

conjunto de tecnologías.

https://atom.io/



El primer paso necesario es instalar Docker, mediante la terminal de Ubuntu

16.04:

Ilustración I.2 - Instalación de Docker en Ubuntu 16.04

Una vez preparado Docker en el sistema, es necesario crear un nuevo

contenedor a partir de la imagen de MySQL correspondiente. Si la imagen no se

encuentra disponible en el equipo, Docker se encargará de buscarla en su

repositorio automáticamente:

Ilustración I.3 - Creación del nuevo contenedor a partir de la imagen de MySQL

En la orden anterior, se indica la siguiente información a Docker:

El puerto 3306 del contenedor se redirecciona al puerto 3310 para evitar

colisiones con otros posibles servicios locales.

El nombre del contenedor es “mysql-rd”

La contraseña del usuario “root” será “contraseña” (solo como demostración).

La imagen a partir de la cual se genera el contenedor es de MySQL en su

versión 5.7.21.

Para acceder al servicio primero hay que lanzar el contenedor:

Ilustración I.4 - Lanzar el contenedor Docker

Ya será posible acceder al servicio MySQL mediante:

Ilustración I.5 - Acceder al servicio MySQL de Docker

Para terminar, sería necesario añadir el origen de datos a LoopBack para que

la persistencia de datos de la API quede vinculada al servicio. Para ello, se añade un

objeto dentro del fichero “datasources.js” de LoopBack con el siguiente aspecto:



Ilustración I.6 - Definición del servicio MySQL en los orígenes de datos de LoopBack

Siguiendo los pasos anteriormente mencionados se tendría el software

necesario para comenzar el desarrollo de la aplicación con el conjunto de

tecnologías seleccionado.

sistema de reservas de espacios a travÉs de la webtauja.ujaen.es/bitstream/10953.1/8833/1/tfg...

Documents