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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
3 Escuela Politécnica Superior de Jaén
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
4 Escuela Politécnica Superior de Jaén
Anexo I: Manual de despliegue ............................................................................................71
Atom .................................................................................................................................71
Node.js, LoopBack, Angular..............................................................................................71
Docker y MySQL ...............................................................................................................71
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
5 Escuela Politécnica Superior de Jaén
Í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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
6 Escuela Politécnica Superior de Jaén
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
7 Escuela Politécnica Superior de Jaén
Í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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
8 Escuela Politécnica Superior de Jaén
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
9 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
10 Escuela Politécnica Superior de Jaén
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
11 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
12 Escuela Politécnica Superior de Jaén
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:
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
13 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
14 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
15 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
16 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
17 Escuela Politécnica Superior de Jaén
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
Sprint 2 3 (18 diciembre)
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)
Validación del desarrollo actual
Selección de las actividades a
desarrollar
Toma de contacto con las herramientas
Sprint 4 8 (19 febrero)
9 (26 febrero)
10 (5 marzo)
11 (12 marzo)
Validación del desarrollo actual
Selección de las actividades a
desarrollar
Implementación servidor
Sprint 5 12 (19 marzo) Validación del desarrollo actual
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
18 Escuela Politécnica Superior de Jaén
13 (2 abril)
14 (9 abril)
15 (16 abril)
Selección de las actividades a
desarrollar
Implementación cliente
Sprint 6 16 (23 abril)
17 (30 abril)
Validación del desarrollo actual
Selección de las actividades a
desarrollar
Despliegue en servidor de pruebas
Sprint 7 18 (7 mayo)
19 (14 mayo)
Validación del desarrollo actual
Selección de las actividades a
desarrollar
Fase de pruebas
Corrección de errores
Despliegue en servidor de producción
Sprint 8 - Validación del desarrollo actual
Selección de las actividades a
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
19 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
20 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
21 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
22 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
23 Escuela Politécnica Superior de Jaén
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
24 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
25 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
26 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
27 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
28 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
29 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
30 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
31 Escuela Politécnica Superior de Jaén
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:
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
32 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
33 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
34 Escuela Politécnica Superior de Jaén
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).
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
35 Escuela Politécnica Superior de Jaén
“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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
36 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
37 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
38 Escuela Politécnica Superior de Jaén
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).
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
39 Escuela Politécnica Superior de Jaén
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”
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
40 Escuela Politécnica Superior de Jaén
Modelo Elemento Nombre Descripción
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.
ACLs admin El administrador tiene permiso sobre todos los
métodos del modelo
everyone Todo el mundo tiene acceso al método “find” de
este modelo
Tabla 5 - Definición del modelo “room”
Modelo Elemento Nombre Descripción
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
41 Escuela Politécnica Superior de Jaén
(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
ACLs admin El administrador tiene permiso sobre todos los
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”
Modelo Elemento Nombre Descripción
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
42 Escuela Politécnica Superior de Jaén
(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”
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
43 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
44 Escuela Politécnica Superior de Jaén
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).
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
45 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
46 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
47 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
48 Escuela Politécnica Superior de Jaén
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
49 Escuela Politécnica Superior de Jaén
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
implica una persistencia de datos en la base de datos. Puntos importantes que se
encuentran en este modelo:
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
50 Escuela Politécnica Superior de Jaén
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
implica una persistencia de datos en la base de datos. Puntos importantes que se
encuentran en este modelo:
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”.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
51 Escuela Politécnica Superior de Jaén
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
52 Escuela Politécnica Superior de Jaén
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).
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
53 Escuela Politécnica Superior de Jaén
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:
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
54 Escuela Politécnica Superior de Jaén
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
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:
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
55 Escuela Politécnica Superior de Jaén
Método Petición HTTP
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:
Método Petición HTTP
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:
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
56 Escuela Politécnica Superior de Jaén
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
socket, actualiza la lista de objetos de ese tipo
onConfigEvent() No Cuando recibe un mensaje de tipo “config” a través del
socket, actualiza la lista de objetos de ese tipo
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).
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
57 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
58 Escuela Politécnica Superior de Jaén
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”.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
59 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
60 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
61 Escuela Politécnica Superior de Jaén
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
Sprint 1 1 (4 diciembre)
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)
Sprint 2 3 (18 diciembre)
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
62 Escuela Politécnica Superior de Jaén
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
63 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
64 Escuela Politécnica Superior de Jaén
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
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
65 Escuela Politécnica Superior de Jaé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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
66 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
67 Escuela Politécnica Superior de Jaén
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:
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
68 Escuela Politécnica Superior de Jaén
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).
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
69 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
70 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
71 Escuela Politécnica Superior de Jaén
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.
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
72 Escuela Politécnica Superior de Jaén
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:
Sebastián Collado Montañez Sistema de reservas de espacios a través de la web
73 Escuela Politécnica Superior de Jaén
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.