lrosalesc

Vista previa del material en texto

TREBALL FINAL DE GRAU 
 
 
 
 
 
Resumen
En estos días, donde todo el mundo intenta encontrar la manera de obtener beneficios ofreciendo
un servicio, las entidades bancarias son una pieza importante de la rueda.
Estas necesitan herramientas para que sus gestores puedan ofrecer el producto o la contratación
adecuada al cliente, gracias a un perfilado y a un conocimiento previo de sus finanzas.
Se ha tenido la suerte de poder trabajar con una plataforma SPA (Single Page Application)
orientada a widgets a nivel profesional basada en AngularJS 1.2 y se ha podido comprobar de
primera mano como funcionan los portales web en las entidades bancarias.
Aunque el framework utilizado sea una potente herramienta de trabajo, ya hace más de seis años
que salio al mercado y tras la constante evolución de las tecnologías web, este framework ya co-
mienza a quedarse obsoleto.
Dada la actual situación de esta plataforma, este proyecto se enfocará en actualizar el portal a la
última versión de los frameworks SPA más conocidos, en concreto, se utilizará la última versión
de Angular para ver como ha evolucionado el framework ya que aunque su nombre sea el mismo,
este framework ha sido reescrito de cero en Typescript y gracias a su nuevo sistema de inyección
de dependencias jerárquico y su modelo orientado a objetos hace que su rendimiento sea superior
a AngularJS.
Tras la implementación de la nueva SPA, se observa que Angular en su última version se adapta
totalmente a las necesidades de una plataforma de estas características, logrando así una inter-
faz mucho más ágil, con una comunicación entre los widgets casi instantánea y de fácil acceso al
usuario.
Agradecimientos
Una de las partes más importantes de para la realización de este proyecto reside en el apoyo que
he ido recibiendo a lo largo de mis estudios en la Universidad de Lleida.
Para empezar, he de agradecer a mi familia y amigos el apoyo tanto económico como emocio-
nal que me han dado desde el primer momento en el que me embarqué en este desafio en el cual
depositaron en mí esa confianza necesaria para saber que todo iría bien. Otra persona a la que me
gustaría agradecer es a mi novia Denise que siempre ha sabido sacarme sonrisas en los momentos
más difíciles de la carrera.
También me gustaría agradecer a mis compañeros de clase Radu y Lluis por las innumerables
horas riéndonos y construyendo código juntos. Gracias a ello he descubierto la pasión por esta
profesión.
Por último y no menos importante, me gustaría agradecer a Roberto ya que ha sabido ayudarme y
encaminarme cuando he tenido cualquier duda en el transcurso de este proyecto y sin él no habría
sido posible la realización de este trabajo.
Índice
1. Introducción 1
1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Estado del arte 4
2.1. Conocimientos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Tecnología Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Tecnología Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Metodología 9
3.1. SCRUM Hands-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Requisitos 12
4.1. Widget framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Elección del Widget Framework . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Diseño 16
5.1. Diseño del Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Métodos HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Diseño del Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. Prototipo Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.2. Diseño Portal X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.3. Diseño Portal MyBank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.4. Adaptación de los Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.5. Otras consideraciones del diseño . . . . . . . . . . . . . . . . . . . . . . . . 26
6. Implementación 28
6.1. Desarrollo Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1.1. Consideraciones Técnicas Back-end . . . . . . . . . . . . . . . . . . . . . . . 28
6.1.2. Aspectos importantes del Back-end . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Desarrollo Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2.1. Consideraciones Técnicas Front-end . . . . . . . . . . . . . . . . . . . . . . 32
6.2.2. Esquema General del Portal MyBank . . . . . . . . . . . . . . . . . . . . . 34
6.2.3. Construcción de Framework propio para la creación de Widgets . . . . . . . 34
6.2.4. Estados del Widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.5. Generación del Gráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.6. Construcción de la Autenticación . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.7. Guards, protección de las rutas internas . . . . . . . . . . . . . . . . . . . . 41
6.2.8. Interceptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.9. Despliegue del Portal MyBank . . . . . . . . . . . . . . . . . . . . . . . . . 44
7. Instalación 46
7.1. Requisitos técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2. Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8. Conclusiones generales 48
8.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9. Referencias 50
9.1. Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Lista de Imágenes
2.1. Backbase portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Liferay Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Metodología SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Prototipos Iniciales del Portal Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Widget Portal real para la gestión de clientes . . . . . . . . . . . . . . . . . . . . . 20
5.3. Widget Portal MyBank para la gestión de clientes . . . . . . . . . . . . . . . . . . 21
5.4. Widget Informacion del Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5. Widget Gráfico de Gastos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.6. Widget Relaciones con MyBank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.7. Widget Información Comercial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.8. Widget Posición Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.9. Diseño del Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.10. Diseño de Gestión de Gestores y Administradores . . . . . . . . . . . . . . . . . . . 26
5.11. Diseño de Gestión de Clientes . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . 27
6.1. Arquitectura de Portales web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Estructura API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3. Contenedor del Widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4. Construcción de los contenedores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.5. Construcción del Widget, Maquetación. . . . . . . . . . . . . . . . . . . . . . . . . 35
6.6. Fases del Widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.7. Widget de Movimientos, Look and Feel . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.8. Conexión con la API con JWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.9. Heroku, automatización del despliegue gracias a Github . . . . . . . . . . . . . . . 44
6.10. Estructura Portal MyBank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Diferente gestión de los widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Lista de Tablas
1.1. Planificación de Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Tiempo estimado con la plataforma Backbase . . . . . . . . . . . . . . . . . . . . . 3
1.3. Presupuesto estimado del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Ventajas e Inconvenientes de ReactJS . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Ventajas e Inconvenientes de VueJS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Ventajas e Inconvenientes de Angular . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Scheme Usuario Autenticado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Scheme Oficina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Scheme Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Métodos HTTP Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Capítulo 1
Introducción
¿Nunca os ha pasado que vuestro banco os llama para ofreceros un préstamo o algún producto de
inversión?
Esto es posible gracias a que las entidades bancarias tienen una plataforma encargada de registrar
y perfilar cada cliente a medida, de tal manera que sus gestores puedan conocer en todo momento
cuando sus clientes puedan necesitar desde un préstamo hasta un producto de inversión.
El proyecto consiste primeramente en explorar la actualización de la plataforma con tecnologías
más actuales, una vez escogida dicha tecnología, nos centraremos en el diseño e implementación
de la plataforma. Para empezar, realizaremos una primera búsqueda para analizar el estado del
arte actual y las tecnologías actuales en cuanto a portales SPA y el diseño Front-end que conlleva,
seguidamente, se seleccionará la opción que más se adapta a nuestra necesitad y a continuación se
empezará con la construcción.
Dicha construcción presentará una interfaz de fácil acceso para el gestor, con una autenticación
de los usuarios basada en web Token y securización de los accesos basada en roles, adaptable a
cualquier navegador con soporte ES5 y capacidad de recuperación de datos gracias a herramientas
de gestión en la nube.
1.1. Objetivos
Los objetivos principales de este trabajo son conseguir diseñar y desarrollar una aplicación web
encargada de mostrar el proceso que se sigue en las entidades bancarias para ofrecer contrataciones
y productos de interés a sus clientes.
A partir de su perfil financiero, el gestor podrá ofrecerle productos que se acercaran más o menos
a sus necesidades, toda esta plataforma vendrá enriquecida en un entorno familiar para el usuario
como son los Widgets, hoy en día, han ganado bastante terreno en el mundo de las aplicaciones
web y los podemos observar en prácticamente cualquier página web o aplicación móvil.
Para conseguir esto, investigaremos los principales frameworks y librerías que tenemos al abas-
to ya sean propietarios o de libre distribución y así poder observar cual es la que más se adapta a
nuestras necesidades.
Una vez la plataforma web sea funcional gracias a una sencilla API (Application Programming
Interface), esta será desplegada en la nube.
1.2. Motivación
La principal motivación de este trabajo de fin de grado nace el día en el que comencé a trabajar en
un proyecto Front-end en la empresa GFT, sin tener previa experiencia antes en el sector laboral,
fui a parar al mundo de los portales bancarios, en concreto, en una herramienta personalizada de
1
soporte para que los gestores puedan conocer el detalle financiero de sus clientes, tras los primeros
meses de aprendizaje, descubrí que había poca o nula documentación referente al core del portal,
llamado Backbase, un potente framework para la creación de portales basados en widgets, ya que,
esta información siempre te venia heredada por otros miembros del equipo de desarrolladores más
veteranos, que a la vez, ellos también habían heredado estos conocimientos.
Entonces pensé, "¿Habría la posibilidad de implementar un portal Single-page Widget-based con
un framework o librerías con más documentación?, quizás, en un entorno más fácil de empezar.
Comenté esta idea con los integrantes del equipo de desarrolladores y ellos me comentaron que ya
que voy a comenzar este proyecto, pueda establecer un primer contacto con los nuevos frameworks
y librerías de Javascript (Ya que en el proyecto actualmente se utiliza AngularJS y MustacheJS
para definir la lógica de cada Widget), así poder estudiar una posible actualización del portal, sacar
conclusiones y ver cual es la opción que más se adapta a nuestro portal y en caso de plantear una
migración a otro framework, estudiar este proyecto y así poder comenzar desde un punto de vista.
1.3. Planificación
En la tabla 1.1 podemos observar la planificación final del proyecto.
Como podemos observar, el mayor coste viene del diseño y desarrollo de la plataforma, se podría
haber reducido el coste de horas si en la etapa de Decisiones de Tecnologías se hubiese invertido
más tiempo en buscar la tecnología más eficiente para manipular los eventos entre widgets, ya
que este paso, supuso un agujero de horas que se podrían haber ahorrado de detectarse a tiempo.
También cabe recalcar que al escoger todos los frameworks sin un previo conocimiento, esto ha
generado una curva de aprendizaje al principio mayor de la esperada.
Tabla 1.1: Planificación de Tareas
Al principio se decidió explorar un poco el framework propietario Backbase ya que me había pre-
viamente informado gracias a mis compañeros que existía una demo que utilizaba como motor
TypeScript y capaz de adaptarse a las necesidades de este proyecto.
Poco después de instalar la demo, se necesitaba solicitar unas credenciales de acceso a los re-
positorios privados de Maven de la compañía, para así tener las dependencias cubiertas.
2
Tras intercambiar un par de correos con la compañía, esta demo estaba únicamente estaba dis-
ponible para empresas, por lo que decidí cortar aquí mi experiencia con Backbase y continuar
investigando cual sería la tecnología a escoger.
En la tabla 1.2 podemos ver el time-box invertido en intentar configurar dicha demo.
Tabla 1.2: Tiempo estimado con la plataforma Backbase
1.4. Presupuesto
El presupuesto a continuación contempla los gastos desde el día cero que se comenzó la plataforma,
se ha considerado la cuantía de veinte euros base como el sueldo básico de un desarrollador por
hora trabajada y a esto se han aplicado las horas que se especifican en la tabla 1.2.
También se han valorado económicamente software, despliegue, hosting y los gastos del entorno de
trabajo.En la tabla 1.3 podemos observar el presupuesto resultante del proyecto.
Tabla 1.3: Presupuesto estimado del proyecto
3
Capítulo 2
Estado del arte
Actualmente, en el mundo de los portales web basados en widgets, existen dos opciones a la hora
de construirlos, nos podemos decantar o bien por sistemas ya construidos y adaptarlos a nuestras
necesidades como vendrían a ser Backbase, Liferay, nCino, etc; el primero de ellos como ya recor-
damos propietario.
Muchos de estos sistemas tienen un problema, al ser PaaS (Platform as a Service) el desarro-
llo es bastante limitado y el desarrollador únicamente se encarga a renombrar widgets o ubicarlos
y dotarlos de un mínimo de comportamiento y quizás no es lo que se busca, ya que al pretender
una actualización de la plataforma, necesitamos una solución más adaptable para el cliente y no
una simple parametrización de los widgets, por lo que se ha comenzado a estudiar los frameworks
actuales y lo que ofrece cada uno de ellos.
En las siguientes imágenes 5.3, 2.2 se pueden apreciar las PaaS dedicadas a la construcción de
widgets.
Imagen 2.1: Backbase portal
Imagen 2.2: Liferay Portal
4
Por otro lado tenemos una infinidad de librerías y frameworks de Javascript que seria la opción
más recomendable para construir la plataforma, ya que, no tenemos restricciones para implementar
cualquier tecnología web basada en MVC(Model View Controller).
La principal necesidad a cubrir a la hora de seleccionar el framework, es tener en mente el ni-
vel de adaptabilidad que se necesita en un portal de estas características, ya que pueden haber
situaciones en las que se requiera alguna librería especifica y con una PaaS esta necesidad quizás
no se pueda cubrir.
Sin embargo, también se tiene en cuenta que al no tener previo contacto con estas tecnologías,
la curva de aprendizaje al principio será más empinada y dificil de superar.
Para este proyecto, se ha propuesto comenzar de cero, es decir, no utilizar ninguna plataforma
ya creada como punto de partida y en vez de esto estudiar los distintos frameworks y librerías más
actuales del mercado Client-side y así poder elegir la que más se adapte a nuestras necesidades.
Entre las más novedosas y escuchadas del mercado podemos encontrar:
1. Angular v7.4
2. Vue JS v2.6
3. React JS v16
2.1. Conocimientos previos
Como conocimientos previos cabe recalcar el amplio abanico de tecnologías utilizadas en el Grado
de Ingeniería Informática y gracias a esto no supondrá dificultad a la hora de adaptarse nuevamente
a un nuevo lenguaje.
En el ámbito de Front-end, se ha estado trabajando profesionalmente este último año con Javas-
cript y su framework AngularJS 1.2, que aunque es la primera versión de este potente framework,
es suficiente para comprender los entresijos del MVC, por lo que la elección de core de nuestra
plataforma vendrá en esta dirección.
2.2. Tecnología Frontend
En esta sección, enumeraremos las principales librerías así como el principal framework de JavaSs-
cript, estos tres son orientados a componentes y cualquiera de ellos nos servirá como core de la
plataforma.
React: Es una librería en JavaScript de código abierto
desarrollada y mantenida principalmente por Facebook, la
única función de React es encargarse de la interfaz de usua-
rio dinámica de la página. Para ello proporciona un API
sencilla y estable orientada a la creación de pequeños com-
ponentes con un alto grado de reusabilidad. React puede
ser completamente independiente del resto de tecnologías
que use el proyecto.
5
Vue: Es un framework en JavaScript de código abierto. Al
igual que en React, el core de Vue está centrado únicamen-
te en solucionar el pilar de la interfaz de usuario dinámica,
aunque como framework también tiene componentes para
resolver problemas como el enrutado, renderizado en servi-
dor, etc.
Angular: Es un framework de código abierto desarrollado
en TypeScript, creado y mantenido por Google. El objetivo
principal de Angular es el desarrollo de SPAs, por lo que tie-
ne un ecosistema completo de librerías para su construcción
que incluye el sistema de enrutado, como solución plantea
una arquitectura MVC y está orientado a componentes.
Tras informarnos un poco más en detalle acerca de estas tres grandes tecnologías se ha recopilado
la información necesaria para hacer una comparativa entre sus ventajas e inconvenientes.
En la tabla 2.1, podemos observar las ventajas e inconvenientes de ReactJS, este a primera vista
también parece otra apuesta segura ya que posee un rendimiento superior a Angular gracias a su
virtual DOM y parece que tiene una gran acogida por los desarrolladores ya que en poco tiempo
ha dado mucho que hablar, también gracias a su extensa documentación y que está escrito en
Javascript parece que su curva de aprendizaje es menos empinada que la de Angular.
Por otro lado, parece que no dispone de tantos recursos como Angular, ya que para aplicar di-
ferentes funcionalidades, como únicamente posee una fuerte capa de vista, se tiene que recurrir a
librerías de terceros.
Tabla 2.1: Ventajas e Inconvenientes de ReactJS
6
En la tabla 2.2, se observa al siguiente candidato de formar parte del stack de desarrollo de este
portal, a simple vista, parece que VueJS destaca por su modularización y es un buen candidato
para el desarrollo de aplicaciones SPA, aunque parece ser que al ser el más joven de los tres aún
falta un poco más de soporte y documentación para adaptarlo en grandes proyectos.
Sin duda es un gran framework que dará muchísimo que hablar en los años venideros ya que
su comunidad de desarrolladores apuesta fuerte por él, pero hoy en día no es quizás el más ade-
cuado para utilizar en grandes entornos de trabajo y más considerando que vendríamos de un gran
proyecto SPA basado en AngularJS
Tabla 2.2: Ventajas e Inconvenientes de VueJS
Al observar la tabla 2.3, en las ventajas de Angular podemos ver que tiene bastante reconocimiento
en el mercado y que es un buen candidato para nuestra plataforma ya que posee una gran esca
labilidad en entornos de desarrollos grandes, como vendría a ser el caso en una SPA y posee un
gran abanico de herramientas al ser un framework y no una librería, todo esto se apoya firmemente
en la cantidad de documentación que tiene esta tecnología por lo que parece una apuesta segura.
Por otro lado tiene la mayor curva de aprendizaje ya que al estar escrito en TypeScript, exige
aprender un lenguaje nuevo por lo que la utilización de esta tecnología al principio no será fácil.
Tras la siguiente comparativa, se ha optado por decantarse por Angular, ya que al venir de un
Tabla 2.3: Ventajas e Inconvenientes de Angular
entorno en AngularJS se ha decidido que la migración puede ser menos costosa por la innumerable
cantidad de blogs y foros de información donde se habla de los pasos para realizar migraciones
entre estas dos plataformas.
También, se ha decidido aceptar el reto de aprender un nuevo lenguaje de programación como
7
es TypeScript, al ser este orientado a objetos y gracias al buen background que se adquirió en el
Grado de Ingeniería Informática, no supondría mayor reto aprender esta tecnología.
Y en el ámbito personal, al haber estado en contacto con AngularJS en el pasado, podré ave-
riguar de primera mano que ha sido con el proyecto Angular en el presente y observar hacia donde
avanza esta tecnología.
2.3. Tecnología Backend
Para hacer la plataforma funcional, se ha decidido implementar una API Rest sencilla que atienda
a todas las peticiones del portal.
Para ello se han barajado las siguientes tecnologías:
Node: Nace del paradigma JavaScript-Everywhere destina-
do a la tecnología Back-end basado en el motor V8 de Ja-
vaScript del navegador Google Chrome y orientado a even-
tos, no bloqueante, lo que lo hace muy rápido a la hora de
crear servidores web y emplear tiempo real.
Firebase: Se trata de una plataforma móvil creada por
Google, cuya principal función es desarrollar y facilitar la
creación de apps, encargada del Back-end y con herramien-
tras automáticaspara la creación de bases de datos orien-
tadas a documentos, completamente adaptable a cualquier
entorno (iOS, Android y web).
Al contemplar estas dos posibilidades para implementar nuestro sencillo Back-end. Se ha opta-
do por NodeJS, por dos principales motivos:
El primero viene a ser por que se utilizará la PaaS de Firebase en el cuarto curso del Grado de
Ingeniería Informática, por lo que seguramente conoceremos los entresijos de esta plataforma y se
adquirirán los conocimientos suficientes para tener un dominio intermedio de la plataforma y por
este motivo se ha decidido escoger una herramienta que nos proporcione nuevos conocimientos tras
su implementación que de seguro nos servirá en el futuro.
Y el otro motivo viene a ser para comprobar de primera mano como es el desarrollo con Javascript
en un entorno diferente al Front-end, puesto que hace relativamente pocos años, Javascript era
famoso por ser una tecnología client-side, así se podrá descubrir personalmente si esta tecnología
tiene futuro en el Back-end, comprobar si su desarrollo es tan fácil como dicen los desarrolladores
y especular acerca de la evolución de Javascript en próximos años.
8
Capítulo 3
Metodología
La metodología que se utilizará dadas las características del proyecto será SCRUM.
SCRUM es una de las técnicas ágiles de desarrollo más conocidas en la actualidad. Se ha escogido
utilizar esta metodología debido a que personalmente he estado trabajando en más de diez sprints
en un equipo de siete desarrolladores sobre SCRUM. Ha sido una experiencia muy satisfactoria el
hecho de poder brindar esa flexibilidad al cliente y que en todo momento haya un feedback cons-
tante por parte de los Product Owners ya que produce un software de alta calidad y casi siempre
cumple con las expectativas del cliente.
A continuación podemos encontrar una serie de ventajas que ofrece trabajar con la metodología
ágil SCRUM:
1. Gestión regular de las expectativas del cliente basada en resultados tangibles.
2. Resultados anticipados (time to market).
3. Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado, etc.
4. Gestión sistemática del Retorno de Inversión (ROI: Métrica usada para saber cuánto ganó la
empresa a través de sus inversiones).
5. Mitigación sistemática de los riesgos del proyecto. Productividad y calidad.
6. Alineamiento entre el cliente y el equipo de desarrollo.
7. Equipo motivado al estar constantemente implementando nuevos Features lo que hace un
cambio de perspectiva y evita el estancamiento.
El proyecto se dividirá en subtareas las cuales las categorizaremos en tres niveles de prioridad
(Bajo, Medio y Alto). Se intentará resolver las tareas en el tiempo estipulado (para este proyecto
cada tarea puede durar un máximo de tres días).
Imagen 3.1: Metodología SCRUM
Dado que este proyecto se desarrollará en medio del cuarto curso de carrera, se intentará seguir el
plan estipulado a excepción de semanas de exámenes, prácticas y compaginándolo con mi actual
trabajo como desarrollador. Supone un gran reto tanto personal como profesional y se abordará
gestionar el tiempo eficientemente para evitar solapamientos.
9
3.1. SCRUM Hands-on
No queda claro de donde salen estas features. Mejor después de los requerimientos y aclarando
que son para realizar una aplicación que pruebe las posibilidades de los frameworks seleccionados.
Además, se supone que en gran medida se intentarán satisfacer los requerimientos funcionales del
portal para gestores existentes.
A continuación, en la tabla 3.1 se describen las principales tareas a realizar en el proyecto. Así
como su prioridad en el Backlog, el siguiente Taskout se centra en la estrategia tomada para llevar
a cabo la actualización de la plataforma SPA de mi actual entorno laboral. Como podemos obser-
var, las primeras tareas son de investigación de las herramientas y frameworks disponibles para el
desarrollo que ha tomado prácticamente un mes entero.
Nos centramos ahora en la fase de diseño ya que investigamos los frameworks que se van a encargar
del lookfeel de la aplicación, así como la previa definición de la Api encargada de la persistencia
de datos de los clientes.
Mas adelante nos enfocamos en la implementación de la plataforma que, como podemos ver, es la
parte más extensa del trabajo, debido a que invertimos aproximadamente 3 - 4 meses.
Por último, dejamos los features adicionales así como los últimos matices gráficos de la plata-
forma.
Este backlog es orientativo y se intentará seguir en medida de lo posible para cumplir con los
requisitos de actualización de esta plataforma.
10
Tabla 3.1: Backlog
11
Capítulo 4
Requisitos
En este capítulo, recorreremos punto a punto la fase de recopilación de requisitos así como las
decisiones tomadas en todo momento antes de ponerse manos a la obra.
4.1. Widget framework
Para llevar a cabo esta actualización del portal existente a las nuevas tecnologías, se ha escogido
Angular como motor de nuestra capa de presentación. Para continuar es necesario introducirnos
en el mundo de los portales web SPA.
Un portal web, y en concreto los portales SPA son aplicaciones web que interactuan con el usuario
de manera dinámica sobre la misma página en lugar de dar la sensación de que se está accediendo
a otra página web. Gracias a ello, al usuario se le da la sensación de que tiene toda la información
disponible y le brinda esta sensación de facilidad que hoy en día es difícil de conseguir.
Tras tener claro lo que es un portal SPA, es muy importante introducir la definición de wid-
get.
La Wikipedia define widget como una pequeña aplicación o programa, usualmente presentado
en contenedores pequeños que son ejecutados por un motor de widgets o Widget Engine. Entre sus
objetivos están dar fácil acceso a funciones frecuentemente usadas y proveer de información visual.
Aunque no es condición indispensable, los widgets suelen ser utilizados para ser .empotrados.en otra
página web.
Esta definición se adapta completamente a la herramienta que necesitamos ya que brinda una
interfaz de fácil acceso para cualquier usuario sin un perfil técnico. Hoy en día, cualquier usuario
es capaz de relacionar el concepto de widget con el de herramienta útil y de fácil acceso. Por este
motivo los portales SPA y en concreto el portal de este proyecto utilizan los widgets como principal
herramienta de acceso a la información.
Tras tener estos conceptos claros, vamos a estudiar las diferentes opciones para modelarlos.
Gracias al soporte de Roberto y a una investigación profunda en el ámbito de portales SPA,
se han encontrado las siguientes librerías y frameworks para modelar widgets en este entorno.
12
jQWidgets: Es un framework creado en jQuery para crear
aplicaciones basadas en web que se ejecutan en PC, dis-
positivos táctiles y móviles. jQWidgets incluye más de 60
widgets de interfaz de usuario. Todos los widgets están dise-
ñados desde cero y se basan en un potente núcleo común. El
núcleo del marco proporciona capacidades fundamentales
como soporte para extensiones y herencia de widgets, con-
figuración de widgets, manejo y enrutamiento de eventos
internos, notificaciones de cambio de propiedad, detección
y ajustes de compatibilidad de dispositivos y navegadores.
Angular Material: También es un Framework que inte-
gra unos componentes de UI siguiendo las especificaciones
de diseño de Google (Material-Design). Este proyecto pro-
porciona un conjunto de componentes de UI reutilizables,
totalmente personalizables y listos para producción.
Bootstrap: Bootstrap es una biblioteca multiplataforma o
conjunto de herramientas de código abierto para diseño de
sitios y aplicaciones web. Contiene plantillas de diseño con
elementos de diseño basado en HTML y CSS, así como ex-
tensiones de JavaScript adicionales. A diferencia de muchos
frameworks web, solo se ocupa del desarrollo front-end.
4.1.1. Elección del Widget Framework
Tras comenzar con las primeras implementaciones con estos dos primeros frameworks y con unaexperiencia previa en Bootstrap gracias a mi entorno laboral, se ha observado que para estas tres
bibliotecas la documentación es extensa por lo que a primera vista no tendremos ningún inconve-
niente en poder utilizar cualquiera de estas tres potentes herramientas.
Se ha comprobado que jQWidgets está más adaptado para el flujo de datos mediante eventos
entre distintos widgets por lo que puede ser una buena opción si lo que buscamos es un framework
robusto y no empezar de cero con la infraestructura del widget. Cabe recalcar que una vez empiezas
a desarrollar con esta herramienta, si no eres un usuario experimentado en TypeScript, al principio
la curva de aprendizaje es más larga.
En cambio, Angular Material tiene una dificultad prácticamente nula si has trabajado anterior-
mente con librerías Front-end como Bootstrap. Este framework nos proporciona una cantidad
considerable de componentes (Form Controls, Layouts, Navigation, Indicators) y todos ellos adap-
tables a cualquier propósito.
Tras comprobar de primera mano el funcionamiento de estos frameworks, se ha decidido utili-
zar Angular Material.
Ya que se ha utilizado previamente en pasados desarrollos como librería en proyectos Android y
en proyectos web con AngularJS, no supondrá mayor reto debido a que en el primer contacto con
13
esta herramienta, se ha detectado un potente componente de Angular Material capaz de modelar
el contenedor de un widget y no supondrá excesivo trabajo la representación de ellos.
Tras una investigación previa para la implementación de los eventos entre widgets, se ha concluido
que se podría utilizar los Observables de Angular RXJS para modelar dicha comunicación de datos.
Más adelante entraremos en detalle de estas potentes herramientas.
4.2. Análisis de requisitos
Se detallarán mediante tablas todos los servicios que debe aportar el portal web. Estos servicios y
restricciones vienen categorizados en requisitos funcionales y requisitos no funcionales.
4.2.1. Requisitos funcionales
Los requisitos funcionales de un sistema son aquellos que describen cualquier actividad que éste
deba de realizar. En otras palabras, el comportamiento o función particular de un sistema o soft-
ware cuando se cumplen ciertas condiciones.
A continuación, en la tabla 4.1 observaremos los requisitos funcionales del portal web MyBank
Tabla 4.1: Requisitos Funcionales
R1.- El sistema debe permitir la inserción de usuarios administradores que tengan un control total
de la plataforma.
R2.- El sistema debe permitir la inserción de usuarios gestores que tengan un control parcial de
la administración del portal. Éstos únicamente deben tener acceso a sus propios clientes.
R3.- El sistema debe permitir la gestión de clientes desde los roles Administrador o Gestor.
R4.- La plataforma debe estar alojada en un servicio cloud para permitir una disponibilidad total.
R5.- El sistema debe permitir una interfaz gráfica para el perfilado del cliente desde la vista gestor
(si el cliente pertenece al gestor en cuestión) o desde la vista administrador.
R6.- El sistema ha de gestionar mecanismos de seguridad de información para que usuarios no
autorizados no tengan acceso a la información.
14
R7.- Debe quedar en todo momento constancia en un único repositorio de la creación del portal
web desde el día uno.
R8.- El sistema debe de poseer dos entornos para trabajar (Local y Producción).
R9.- El sistema debe imitar la funcionalidad del portal existente para poder comprobar los cambios
realizados más facilmente.
R10.- El sistema debe imitar la aspecto del portal existente para poder comprobar los cambios
realizados más facilmente.
4.2.2. Requisitos no funcionales
Los requisitos no funcionales son los que especifican criterios para evaluar la operación de un
servicio que ofrece el portal, en contraste con los requisitos funcionales que especifican comporta-
mientos especificos.
A continuación, en la tabla 4.2 observaremos los requisitos no funcionales del portal web MyBank
Tabla 4.2: Requisitos no funcionales
RN1.- El sistema debe estar blindado contra usuarios no autorizados. Únicamente tendrán acceso
al sistema usuarios Gestores y Administradores.
RN2.- El sistema ha de gestionar la posibilidad de evitar la entrada accidental de datos incorrectos.
RN3.- El sistema ha de gestionar mecanismos de recuperación de accesibilidad en caso de caída del
sistema.
RN4.- La plataforma debe diferenciar entre los dos roles del sistema ya que solo el usuario adminis-
trador tendrá acceso exclusivo a crear usuarios Gestores y Administradores.
RN5.- El sistema Back-end tendrá un mecanismo de seguridad de contraseñas basado en JSON Web
Tokens (JWT).
RN6.- La UI del portal web vendrá dotada de widgets para conseguir una presentación intuitiva,
simple y de fácil acceso para el usuario común.
RN7.- El sistema será capaz de ser ejecutado con sus máximas prestaciones en navegadores (Safari,
Google Chrome, Mozilla Firefox y Microsoft Edge).
RN8.- La persistencia de los datos vendrá implementada mediante una BBDD orientada a docu-
mentos.
15
Capítulo 5
Diseño
En esta sección describiremos el diseño final que se presentará de la plataforma desde el Back-end
hasta el Front-end.
5.1. Diseño del Backend
En este apartado se describirá el diseño del Back-end así como las decisiones tomadas para construir
una API REST.
Primero, vamos a mencionar una serie de características de las API REST que se adaptan total-
mente a nuestras necesidades:
1. Sin estado: Cada petición HTTP que realizamos a nuestra API contiene toda la información
necesaria para ejecutarla, lo que permite que ni cliente ni servidor necesiten recordar ningún
estado previo.
2. XML/JSON: Otra ventaja de las API REST es que se adaptan totalmente a los consumidores
que prefieren la representación de datos en formato XML o JSON.
3. Documentación: Existe innumerables artículos y blogs que tratan sobre la creación y mani-
pulación de APIs REST; desde tutoriales de creación de API en diez minutos hasta complejas
guías que ponen en marcha la arquitectura REST en un entorno corporativo.
Una vez repasadas las principales características de una API REST, nos centramos en el modelo
de datos puesto que utilizaremos NodeJS y MongoDB como core de nuestro sistema Back-end. No
se ha podido pensar otro sistema de representación de datos que no sea Mongoose.
Este framework tiene como principal ventaja la abstracción a objetos desde MongoDB, utilizan-
do entidades llamadas Schemes Gracias a estas entidades podemos implementar la validación y
otras muchas características para asegurarnos de que nuestro scheme sea consistente a la hora de
gestionar documentos dentro de las colecciones.
Mongoose: Permite definir objetos en un esquema fuerte-
mente tipado y ser asignados a un documento MongoDB.
Este framework de Javascript tiene una increíble cantidad
de funcionalidades para la gestion de esquemas (Schemes).
Al definir esta abstracción del modelo, facilita la gestión de
los datos, por lo que parece que se está trabajando única-
mente con objetos.
A continuación se ha definido con Mongoose los siguientes schemes para representar las estructuras
de datos de nuestra aplicación.
16
5.1.1. Schemes
En las siguientes tablas 5.1 5.2 5.3 se muestra la definición sencilla de nuestros modelos en la base
de datos.
Con estos modelos tendremos suficiente para dotar a la plataforma de persistencia de datos.
Tabla 5.1: Scheme Usuario Autenticado
Tabla 5.2: Scheme Oficina
Tabla 5.3: Scheme Cliente
17
5.1.2. Métodos HTTP
Una vez establecidos los esquemas, se presentarán los métodos HTTP accesibles desde client-side.
Como se puede observar en la tabla 5.4 encontramos los diferentes tipos de rutas relacionados
con los Schemes pertinentes.
Vemos que existen rutas dedicadas exclusivamente a la autenticación en el portal (register, lo-
gin, profile). La gestión de estas rutas viene centralizada desde un controlador específico dentro del
dominio del esquema User de la tabla 5.1. Gracias a estas rutas podemos completarlos requisitos
funcionales R1, R2 y R4 de la tabla 4.1
Todos los métodos que implican únicamente el perfilado y la gestión con los clientes apuntan
directamente al controlador del esquema Cliente de la tabla 5.3. De esta manera podemos cum-
plir los requisitos funcionales R3 y R5 de la tabla 4.1
Por último, se observan las rutas dedicadas a los gestores dentro de la plataforma. Al no tener
relación con los clientes, tienen un controlador en el cual está escrita la lógica de gestión.
Estos métodos, aunque sencillos, son los únicos que necesitamos para dotar al portal de una mínima
gestión de usuarios y poder demostrar la funcionalidad completa del portal.
Tabla 5.4: Métodos HTTP Back-end
18
5.2. Diseño del Front-end
En esta sección vamos a repasar los puntos que se han seguido para diseñar la plataforma.
5.2.1. Prototipo Inicial
En la fase inicial, se han construido tres prototipos que ayudarán a guiarnos en la creación. Cabe
recalcar que nos hemos inspirado en el diseño real de una entidad bancaria para el prototipo 5.1(b).
Éste ayudará a hacerse una idea de como funciona la gestión de los clientes en las oficinas y cual
es el aspecto real que tiene la plataforma puesta en producción.
Al imitar el portal real, se podrá facilitar la comparación y así poder ganar experiencia de ca-
ra a actualizar el existente en un futuro, por lo que se cumplirán los requisitos funcionales R9 y
R10 de la tabla 4.1
A partir de este momento, al portal de la entidad bancaria inspiradora le llamaremos Portal
X, ya que será mencionado más de una vez en este documento.
Para poder hacer este portal funcional, se ha requerido implementar UI dedicada especialmente a
la gestión de los usuarios. Por este motivo también se añadirá en el portal funcionalidad dedicada
a la gestión de usuarios autorizados 5.1(a), como también la gestión de nuevos clientes 5.1(c).
Para llevar a cabo este diseño, se seguirán los siguientes prototipos iniciales.
(a) Prototipo del Login (b) Prototipo del Home Page (c) Prototipo de Gestión de Clientes
Imagen 5.1: Prototipos Iniciales del Portal Web
Para el diseño de estos sencillos pero útiles prototipos se ha utilizado la herramienta online de
diseño Draw.io
19
http://www.draw.io
5.2.2. Diseño Portal X
El diseño Front-end que seguiremos será una aproximación de lo que es un portal de ventas real
de un banco.
Como se ha comentado previamente, al tener la suerte de trabajar en este entorno profesional, se
podrá presentar una aproximación bastante acotada del mundo de portales real utilizados en las
entidades bancarias.
A continuación, en la imagen 5.2 podemos apreciar un portal real, el cual será tomado como
inspiración en el proceso de diseño.
Imagen 5.2: Widget Portal real para la gestión de clientes
20
5.2.3. Diseño Portal MyBank
Primero vamos a dar un vistazo general al portal para ver si se han conseguido los objetivos en
cuanto a diseño.
Imagen 5.3: Widget Portal MyBank para la gestión de clientes
Se ha intentado seguir tanto la representación gráfica del portal como la funcional, manteniendo
la funcionalidad de cada widget lo más cercana al portal existente.
Para dar un poco más de contexto, vamos a repasar cada uno de los widgets, tanto su funcio-
nalidad como su adaptación en Portal X.
21
5.2.4. Adaptación de los Widgets
Información del Cliente
Para comenzar, en la imagen 5.4 se observa la representación del widget ’Información del cliente’
de Portal X a Portal MyBank.
El widget de la subimagen 5.4(a) corresponde al portal existente y el de la subimagen 5.5(b)
al desarrollado con las nuevas tecnologías.
(a) Información del cliente en Portal X
(b) Información del cliente en Portal MyBank
Imagen 5.4: Widget Informacion del Cliente
Este sencillo Widget únicamente nos informa de manera muy visual los datos personales del cliente.
Estos datos son recuperados gracias al buscador que se ha implementado en el mismo widget.
A continuación se comentarán los tres widgets centrales:
Gráfico de Gastos
En la imagen 5.5 se observa la representación del widget ’Evolución’ de Portal X a Portal MyBank.
El widget de la subimagen 5.5(a) corresponde al portal existente y el de la subimagen 5.5(b)
al desarrollado con las nuevas tecnologías.
(a) Evolución de carteras en Portal X (b) Gráfico de gastos en Portal MyBank
Imagen 5.5: Widget Gráfico de Gastos
Este sencillo widget nos informa de la situación económica del cliente, en concreto, los gastos que
ha realizado el mes actual agrupado por cuentas corrientes.
22
Relaciones con MyBank
El segundo de los tres widgets en la imagen 5.6 nos muestra la representación del widget ’Relacio-
nes’ de Portal X a Portal MyBank.
El widget de la subimagen 5.6(a) corresponde al portal existente y el de la subimagen 5.6(b)
al desarrollado con las nuevas tecnologías.
(a) Relaciones con Banco en Portal X (b) Relaciones con MyBank en Portal MyBank
Imagen 5.6: Widget Relaciones con MyBank
En este widget se informan una serie de cosas: en la parte superior; el gestor encargado de la gestión
del cliente, y en la parte central-inferior se informa de las relaciones del cliente.
El cliente puede tener relaciones de dos tipos:
1. Grupo Familiar: Familiares directos del cliente.
2. Grupo Económico: Personas relacionadas con el cliente en un entorno profesional (Trabajo,
Inversiones, Empresas)
Gracias a este widget 5.6 el gestor puede cerciorarse si hay algun miembro de estos dos grupos
que tiene gestiones pendientes con el banco ya sean tareas, campañas por finalizar o documentos
pendientes de firmar. Gracias a esto, el gestor podrá tomar acción y recordar a sus relacionados
las gestiones pendientes.
Ademas, este widget cuenta con un botón para crear gestiones tanto para el grupo económico o
familiar. Éste botón únicamente será accesible si se ha iniciado sesión como el gestor encargado de
su gestión o como administrador del portal.
23
Información Comercial
El tercero de los tres widgets en la imagen 5.7 nos muestra la representación del widget ’Informa-
ción comercial’ de Portal X a Portal MyBank.
El widget de la subimagen 5.7(a) corresponde al portal existente y el de la subimagen 5.7(b)
al desarrollado con las nuevas tecnologías.
(a) Información Comercial en Portal X (b) Información Comercial en Portal MyBank
Imagen 5.7: Widget Información Comercial
Este widget es el encargado de informar al gestor la oportunidad de venta con este cliente.
En la parte superior podemos observar la oficina a la que pertenece el cliente. Más abajo, en la
parte central, observamos dos indicadores:
1. Nivel de exposición a riesgo de blanqueo: Este indicador nos avisa de la probabilidad
que tiene el cliente de estar relacionado con el blanqueo de capitales. Viene informado con
tres niveles posibles:
a) Low: El cliente no tiene riesgo de blanquear dinero. (e.g. Personas de edad avanzada)
b) Medium: El cliente tiene un riesgo medio de blanquear dinero. (e.g. Estudiantes)
c) High: El cliente tiene un potencial riesgo de blanquear dinero. (e.g. Informático)
2. Revisión: Es un timestamp que indica última fecha en la que se reviso el nivel de riesgo de
blanqueo.
Para terminar con este widget en la parte inferior podemos observar un apartado denominado:
Perfil de Conveniencia: Conocimiento y Experiencia . Y, nuevamente, viene acompañado
de dos indicadores:
1. Estado Perfil: Este estado indica si el cliente ha tenido una perfilación previa y conocemos
al cliente a nivel financiero. Es decir, si éste ha trabajado previamente con productos de
inversión o derivados, si ha solicitado un prestamo anteriormente, etc. Este estado tiene tres
indicadores posibles:
a) No Empezado: No se ha perfilado nunca al cliente.
b) No Completado: Se ha perfilado parcialmente al cliente.
c) Completado: Se ha perfilado completamente al cliente.
2. Productos: Este indicador nos informa de un total de cinco productos que ofrece el banco,
y la cantidad de los cuales estaría potencialmente interesado.
24
Tras finalizar con los tres widgets centrales pasamos al widgetinferior.
Posición Global
El widget en la imagen 5.7 nos muestra la representación del widget ’Posicion Global’ de Portal X
a Portal MyBank.
El widget de la subimagen 5.8(b) corresponde al portal existente y el de la subimagen 5.8(b)
al desarrollado con las nuevas tecnologías.
(a) Posición Global en Portal X
(b) Posición Global en Portal MyBank
Imagen 5.8: Widget Posición Global
En este widget, se puede observar de manera sencilla las cuentas corrientes que tiene el cliente en
el banco, así como una pequeña descripción de sus gastos.
Como podemos ver, en la parte superior hay dos botones (Add movement, Add account). De esta
manera el gestor del cliente o el administrador podrán interactuar con las cuentas del usuario, ya
sea añadiendo nuevas cuentas corrientes o nuevos movimientos desde sus cuentas.
25
5.2.5. Otras consideraciones del diseño
En este apartado se dará una breve pincelada a la parte de la plataforma encargada de la creación
de gestores, gestión de clientes y autenticación.
Estas pantallas irán acompañadas de su prototipo inicial y una pequeña descripción de la funcio-
nalidad principal.
Inicio de Sesión
En la imagen 5.9 podemos ver como ha evolucionado el prototipo de Login; en esta página se
podrán registrar únicamente Gestores y Administradores. Como se puede apreciar no hay una
opción de ’Crear una cuenta’ debido a que únicamente el usuario de tipo Administrador puede
crear gestores y nuevos administradores.
(a) Prototipo del Login (b) Diseño Final del Login
Imagen 5.9: Diseño del Login
Gestión de Usuarios Gestores y Administradores
Dentro la imagen 5.10 podemos encontrar en la subimagen 5.10(a) el prototipo de un único widget
centrado para la gestión de usuarios y en la subimagen 5.10(b) el resultado final; un widget capaz
de crear cuentas de Gestores y Administradores.
Este widget únicamente sera visible para usuarios Administradores.
(a) Prototipo Gestión de Gestores y Adminis-
tradores
(b) Diseño Final Gestión de Gestores y Administradores
Imagen 5.10: Diseño de Gestión de Gestores y Administradores
26
Gestión de clientes
En la imagen 5.11 podemos ver como ha evolucionado el prototipo de Gestión de clientes. En esta
pantalla, tanto usuarios gestores como administradores podrán realizar las gestiones más comunes
con el usuario (añadir, eliminar y modificar).
Cabe recalcar que los clientes que se creen, pertenecerán al gestor que esté en ese momento regis-
trado, en caso de ser añadidos por un usuario administrador, éste podrá seleccionar el
gestor gracias a un ComboBox que recupera la lista de gestores directamente de la BBDD.
(a) Prototipo de la Gestión de Clientes
(b) Diseño Final de la Gestión de Clientes (Vista Administrador
Imagen 5.11: Diseño de Gestión de Clientes
27
Capítulo 6
Implementación
En esta sección describiremos como ha sido el camino para desarrollar la plataforma, tanto Back-
end como Front-end, así como las decisiones tomadas y las adversidades encontradas.
Tanto para el cliente como para el servidor se ha decidido separarlos en dos repositorios para tener
una mejor perspectiva a la hora de acudir a los recursos.
Ésta decisión viene tomada a causa de la arquitectura de portales web, ya que éstos pueden
consumir decenas de microservicios haciendo estos portales mucho más escalables. Así como hoy
en día se ha construido una única API, en un futuro dejamos la puerta abierta a poder escribir
diferentes microservicios; uno para cada necesidad.
Imagen 6.1: Arquitectura de Portales web
6.1. Desarrollo Back-end
Antes de comenzar a describir Task-out de lo que ha sido desarrollar el servicio encargado de dotar
al portal de persistencia, se debe conocer los siguientes frameworks y herramientas encargadas de
la securización y puesta en el cloud del portal.
6.1.1. Consideraciones Técnicas Back-end
1. Json Web Token permite la distinción de privilegios de acceso en nuestro portal. Gracias
a él vamos a poder diferenciar usuarios autenticados de los usuarios no autenticados.
2. Passport es el módulo encargado de simplificar el proceso del tratamiento de la autenticación
en Express. Está dotado de diferentes estrategias que permiten el acceso de forma fácil. Para
esta implementación se usará la estrategia local; utilizaremos el email almacenado en nuestra
BBDD para la verificación de las credenciales.
3. Express-JWT es la última herramienta que utilizaremos. Ésta se encarga de securizar cada
una de nuestras rutas y así protegerlas de peticiones desde el cliente no autenticadas.
28
4. mLab MongoDB Para dotar Portal MyBank de un servicio 24/7 se ha decidido posicionarlo
en la nube gracias a la PaaS conocida como Heroku. mLab es un servicio de BBDD en la
nube, la cual nos brinda la posibilidad de escalamiento, servicio de backups y recuperación
inmediata, además de un servicio de monitorización y alertas.
5. CORS Es un mecanismo que permite exponer los recursos de la API a consumidores que
se encuentran fuera del dominio. Es importante habilitar este mecanismo ya que como co-
mentamos anteriormente, nuestra API es externa al Portal y necesitamos permitir tráfico
proveniente de diferentes dominios.
Al elegir NodeJS como motor Back-end nos reduce considerablemente el desarrollo de una API
sencilla. De esta manera se ha definido la API REST en los siguientes sencillos pasos:
6.1.2. Aspectos importantes del Back-end
1. Instalación NodeJS y MongoDB
2. Primera configuración del fichero ’server.js’
a) Añadir puerto local
3. Creación de Modelos
4. Creación de Rutas
5. Creación de Controladores
6. Segunda configuración del fichero ’server.js’:
a) Conectar la BBDD añadiendo la URL a la instancia de Mongoose
b) Cargar los Modelos creados
c) Crear BodyParser en el Middleware para controlar las inconsistencias en la BBDD
(Error handler)
d) Registrar nuestras nuevas rutas.
7. Arrancar el servidor
1 $ node server.js
8. Test de la API con Postman
9. Instalación y configuración Json Web Token (JWT)
a) Instalación del módulo JWT
1 $ npm install jsonwebtoken --save
b) Creación del método generateJWT que se encargará de generar un token de acceso para
cada usuario que utilize la plataforma.
1 UserSchema.methods.generateJwt = function () {
2 let expiry = new Date();
3 expiry.setDate(expiry.getDate () + 7);
4
5 return jwt.sign({
6 _id: this._id ,
7 email: this.email ,
8 name: this.name ,
9 role: this.role ,
10 exp: parseInt(expiry.getTime () / 1000),
11 }, config.secret);
12 };
10. Instalación y configuración Passport
29
a) Instalación del modulo Passport
1 $ npm install passport --save
2 $ npm install passport -local --save
b) Configuración de Passport utilizando la estrategia local. Gracias al email, únicamente
necesitaremos escribir una query Mongoose; si ésta encuentra el usuario por el email,
verifica que su hash coincida y por consiguiente autentica el usuario.
1 passport.use(new LocalStrategy ({
2 usernameField: ’email ’
3 },
4 function(username , password , done) {
5 User.findOne ({ email: username }, function (err , user) {
6 if (err) { return done(err); }
7 // Return if user not found in database
8 if (!user) {
9 return done(null , false , {
10 message: ’User not found’
11 });
12 }
13 // Return if password is wrong
14 if (!user.validPassword(password)) {
15 return done(null , false , {
16 message: ’Password is wrong’
17 });
18 }
19 // If credentials are correct , return the user object
20 return done(null , user);
21 });
22 }
23 ));
c) Para finalizar con Passport, éste debe ser inicializado en el fichero ’server.js’ justo delante
de las rutas para que éstas puedan utilizarlo.
1 app.use(passport.initialize ());
2 app.use(’/api’, routesApi);
11. Instalación y configuración de Express-JWT
a) Instalación del modulo Express-JWT
1 npm install express -jwt --save
b) Declaración de JWT y securización de rutas.
1 var jwt = require(’express -jwt’);
2
3 var auth = jwt({
4 secret: config.secret ,
5 userProperty: ’payload ’
6 });
7 ...
8 //e.g. Bank account route securization
9 app.route(’/account /: customerId ’)10 .put(auth , customerOperations.insert_new_account)
11 .get(auth , customerOperations.get_accounts);
12. Subida al cloud Heroku
a) Create App en Heroku CLI
1 $ heroku create
2 Creating app... done , enigmatic -mountain -27495
3 Created http://enigmatic -mountain -27495. herokuapp.com/ | git@heroku.
com:enigmatic -mountain -27495. git
b) Añadir mLab a nuestro Heroku App
1 $ heroku addons:create mongolab
2 $ heroku addons:create mongolab:shared -cluster -1
30
c) Conseguir URI de mLab
1 $ heroku config:get MONGODB_URI
2 MONGODB_URI => mongodb:// heroku_l7t0z2hl:
rpihc5nokv98besvm18vh82sdh@ds211625.mlab.com :11625/ heroku_l7t0z2hl
d) Nueva configuración del fichero ’server.js’
1) Se añade el endpoint remoto para apuntar a esta nueva conexión de mLab en el
cloud.
1 var mongoose = require ("mongoose");
2 var theport = process.env.PORT || 5000;
3 ...
4 let uristring =
5 process.env.MONGOLAB_URI ||
6 process.env.MONGOHQ_URL ||
7 ’mongodb :// heroku_l7t0z2hl:rpihc5nokv98besvm18vh82sdh@ds211625.
mlab.com :11625/ heroku_l7t0z2hl ’;
8
9 mongoose.Promise = global.Promise;
10
11 mongoose.connect(uristring , function (err , res) {
12 if (err) {
13 console.log (’ERROR connecting to: ’ + uristring + ’. ’ + err);
14 } else {
15 console.log (’Succeeded connected to: ’ + uristring);
16 }
17 });
2) Para evitar problemas de CORS es necesario habilitar la recepción de peticiones
fuera del dominio.
1 app.use(cors());
2
3 // Add headers
4 app.use(function (req , res , next) {
5
6 // Website you wish to allow to connect
7 res.setHeader(’Access -Control -Allow -Origin ’, ’*’);
8
9 // Request methods you wish to allow
10 res.setHeader(’Access -Control -Allow -Methods ’, ’GET , POST , OPTIONS ,
PUT , PATCH , DELETE ’);
11
12 // Request headers you wish to allow
13 res.setHeader(’Access -Control -Allow -Headers ’, ’X-Requested -With ,
content -type’);
14
15 // Set to true if you need the website to include cookies in the
requests sent
16 // to the API (e.g. in case you use sessions)
17 res.setHeader(’Access -Control -Allow -Credentials ’, true);
18
19 // Pass to next layer of middleware
20 next();
21 });
Tras la finalización de estos pasos, conseguimos una API funcional, lista para proveer al portal
MyBank de una mínima securización, operatividad en la nube y los recursos suficientes para llevar
este proyecto a cabo.
31
En la imagen 6.3 podemos observar la estructura resultante de la API:
Imagen 6.2: Estructura API
6.2. Desarrollo Front-end
6.2.1. Consideraciones Técnicas Front-end
Antes de comenzar a describir el desarrollo del Front-end se deben aclarar los siguientes conceptos,
tanto internos como externos a Angular, así como la utilización de ellos en el proyecto.
1. Component; Angular integra los componentes para facilitar la construcción de bloques de
la UI. Las aplicaciones hechas con Angular se organizan en una estructura de árbol.
2. Router-Outlet; Directiva de Angular que es utilizada en la plantilla del controlador principal
como placeholder que marca dónde se mostrarán componentes dinámicamente.
3. Guards; pertenecen a la colección de Angular y son utilizados para proteger a nivel de Front
el acceso a rutas internas de Angular (e.g. los gestores no pueden acceder a la ruta de creación
de los mismos)
4. Observable; van de la mano de la programación reactiva, muy importante su presencia en
este proyecto ya que son utilizados como listeners de eventos entre widgets (más adelante
entraremos en detalle con este tema).
5. Programación Reactiva; Angular se apoya en RxJS para implementar la programación
reactiva. Hoy en día indispensable para aplicaciones Front-end. Gracias a este tipo de pro-
gramación, podemos tener una gestión óptima del flujo de datos asíncronos en la aplicación.
6. Async pipe; Es utilizado a nivel de plantilla junto con una variable. Cuando se necesita una
subscripción a un Observable o Promise, éste devuelve el último valor de la variable. Cuando
el valor no coincide con el último devuelto, notifica al componente que lo instancia de que su
fuente de datos ha cambiado.
7. Interceptor; utilizados en el proyecto para incrustar el JWT en cada petición desde el portal
a la API.
32
8. Service; también dentro de la colección interna de Angular. Utilizados como una buena
práctica para compartir información entre componentes o bien centralizar las llamadas a la
API en un único componente.
9. D3.js; Framework para la representación de datos de forma gráfica, ya que se necesitaba
implementar un diagrama de barras en el widget de Movimientos. Fue la primera elección
tras consultar informes existentes sobre herramientas para gráficas web. En la referencia 4t
podemos encontrar dichos informes.
Para el desarrollo del Front-end se ha comenzado analizando todos los elementos del framework An-
gular Material. De todos sus componentes se ha llegado a utilizar hasta el 70% de ellos en el Portal.
Uno de los mas importantes que ha jugado un papel fundamental en el desarrollo de este proyecto
ha sido los Cards.
Gracias a este componente se han podido modelar los contenedores de los widgets. Al ser un com-
ponente super adaptable y flexible, no se ha tenido problema en modelar las estructuras de widgets
que ya hemos visto en la Etapa de Diseño Front-end 5.2
Imagen 6.3: Contenedor del Widget
Para describir la implementación, se han obviado pasos recurrentes entre la creación de los widgets,
ya que todos siguen el mismo patrón.
Tampoco se mencionarán lógicas sencillas del procesamiento de los datos; únicamente haremos
hincapié en las decisiones de desarrollo desde el punto de vista de la implementación de un nuevo
framework para la creación de widgets además de los procesos interesantes que se han seguido para
la evolución del portal.
33
A continuación, vamos a definir los pasos necesarios para la creación del Portal MyBank, se inten-
tará enfatizar más los puntos clave de este desarrollo.
6.2.2. Esquema General del Portal MyBank
1. Gracias a los selectores de Angular podemos observar a grandes rasgos el esquema general
del portal.
1 //Top Navigation bar
2 <app -nav ></app -nav >
3 <section >
4 // Internal routes
5 <router -outlet ></router -outlet >
6 </section >
7 // Portal Footer
8 <app -footer ></app -footer >
2. Dentro de la directiva <router-outlet> pueden hacer instancia los siguientes componentes:
a) Home: Punto clave del portal; aquí es donde los gestores llevarán a cabo las tareas de
perfilamiento de los clientes a través de cada uno de los widgets descritos en la Etapa
de Diseño Front-end 5.2
b) Login: Encargado de gestionar el acceso mediante la autenticación del usuario.
c) Customer: Encargado de gestionar las cuentas de los clientes en la plataforma.
d) User: Componente desde donde se podrán crear las cuentas de Gestores y Administra-
dores.
6.2.3. Construcción de Framework propio para la creación de Widgets
1. Como primer punto, se empieza la maquetación de los contenedores.
Contenedor: Ubicación precisa en la UI donde el widget será alojado.
2. Dentro del componente Home se han construido los contenedores desde donde se irán ins-
tanciando cada uno de los widgets.
En el siguiente código se puede observar lo que sería la construcción de los contenedores para
los tres widgets centrales de Home:
1 [...]
2 <mat -card -content >
3 <mat -grid -list cols="3" rowHeight="120px">
4 // Graphic movements container
5 <mat -grid -tile class="mat -elevation -z4" [colspan ]="1" [rowspan ]="2"/>
6 // Relations with MyBank container
7 <mat -grid -tile class="mat -elevation -z4" [colspan ]="1" [rowspan ]="2"/>
8 // Commercial information container
9 <mat -grid -tile class="mat -elevation -z4" [colspan ]="1" [rowspan ]="2"/>
10 </mat -grid -list >
11 </mat -card -content >
12 [...]
La clase mat-elevation-z4 de Angular Material le da a cada contenedor la apariencia de
superposición en el plano; la comúnmente denominada overlapping.
34
3. Después de la creación de los contenedores, tendríamos una estructura de contenedores similar
a la siguiente:
Imagen 6.4:Construcción de los contenedores.
4. A continuación, una vez creados los contenedores, se seguirán los siguientes pasos para la
implementación de cada uno de los widgets:
Para la demostración se ha decidido seguir la implementación del widget de Información
Comercial.
a) Creación del componente que tendrá la logica del widget.
1 // e.g.
2 $ ng g c CommercialInformation -m app
b) Construcción de la plantilla personalizada para cada widget. Gracias al UI component
mat-list y mat-divider de Angular Material, nos será muy sencillo modelar pequeñas
listas para construir la siguiente estructura:
Imagen 6.5: Construcción del Widget, Maquetación.
c) Una vez tenemos construida la maqueta, tenemos que definir la estructura de datos de
entrada al Widget. Para cumplir con ello, se ha definido la siguiente Interface .
1 export interface CommercialInformationDataModel {
2 dni: string;
3 advisor: string;
4 customerRevisionDate: string;
5 customerRiskLaundering: string;
6 customerOffice: string;
7 derivatives: any;
8 }
d) Después de definir la Interface de datos, se tiene que definir el listener de los eventos
para este widget.
35
Para realizar parte de este trabajo, se ha decidido implementar una Interface de Angular
capaz de escuchar eventos desde otros componentes.
Gracias a la implementación OnChange de Angular podremos detectar cuándo en el
componente padre (HomeComponent) se produce una acción que implica un refresh del
widget.
Tras la implementación de la Interface, utilizamos la anotación @Input() de Angular.
En esta anotación es donde especificamos la variable que mapeará con la información
nueva proveniente del componente padre. Tras la detección de nueva información, ésta
acción es tratada en el método ngOnChanges().
1 class CommercialInformationComponent implements OnChanges {
2 @Input ()
3 data: CommercialInformationDataModel;
4
5 ngOnChanges(changes: SimpleChanges) {
6 this.initWidget ();
7 this.showWidget ();
8 }
9 }
e) Tras implementar la interface, en el componente contenedor (HomeComponent) se han
de realizar un par de acciones.
Primeramente se define un Observable de la Interface CommercialInformationDataMo-
del antes creada, que utilizaremos como conector de datos entre los dos componentes.
1 CIWidgetData: Observable <CommercialInformationDataModel >;
Por último, dentro del contenedor del Widget de Información Comercial, dentro de
la plantilla de HomeComponent, hemos de instanciar el selector del componente que
contendrá la lógica del widget.
1 [...]
2 <mat -grid -tile class="mat -elevation -z4" [colspan ]="1" [rowspan ]="2">
3 <app -commercial -information [CIWidgetData ]="CIWidgetData | async" ></
app -commercial -information >
4 </mat -grid -tile >
5 </mat -grid -list >
6 </mat -card -content >
Como podemos observar, dentro del selector hay un pipe que llama la atención. Eel
async pipe es utilizado ya que necesitamos que la vista se refresque cuando los datos del
Observable cambien.
f ) En el Portal, hay dos maneras de nutrir a estos widgets de nueva información, por
llamada asíncrona a la API y utilizando la función .subscribe
1 private refreshWidget (){
2 this.customerService.getCustomer(this.DRWidgetData.dni).subscribe ((
result: any) => {
3 if (result) {
4 // DRWidgetData is an Observable
5 this.DRWidgetData.familiar_group = result.investment_products.
familiar_group;
6 this.DRWidgetData.economical_group = result.
investment_products.economical_group;
7 this.showWidget ();
8 }
9 });
10 }
O bien construyendo un nuevo Observable a partir de la información recuperada en local.
1 private renderCommercialInformationWidget(result: any) {
2 this.CIWidgetData = new Observable(observer => {
36
3 observer.next(this.dataRefreshed(result));
4 observer.complete ();
5 });
6 }
6.2.4. Estados del Widget
1. De esta manera tendríamos un pequeño acercamiento a la gestión de Eventos en un entorno
de widgets, ya que como se han implementado Observables en las fuentes de datos, cada
widget podrá estar en tres estados diferentes.
a) Fase Inicial: El widget no tiene datos de los cuales nutrirse.
b) Fase de Carga: El widget esta subscrito a un evento asíncrono. Mientras éste se resuelve
se muestra un loading-spinner
c) Fase Final: El widget ha terminado de cargar. El subscribe del Observable ha detectado
cambios y por consiguiente la UI se ha actualizado.
(a) Fase Inicial del Widget (b) Fase de Carga del Widget (c) Fase Final del Widget
Imagen 6.6: Fases del Widget
6.2.5. Generación del Gráfico
Como se ha comentado previamente, para generar el gráfico se ha utilizado la herramienta D3.js
y se ha seguido la siguiente implementación:
1. Instalamos el framework D3.js
1 $ npm install d3
2. Tras haber especificado previamente que el motor de los widgets son los Observables de
Angular, nos colocaremos en el punto del desarrollo en el que la maqueta del widget ya ha
sido creada y está lista para ser rellenada de datos provenientes de un Observable.
1 export interface BarChartDataModel {
2 account_name: string;
3 total_movements: number;
4 }
5 [...]
6 CMWidgetData: Observable <BarChartDataModel >;
3. Una vez aquí, redefinimos el metodo onChange del widget Movimientos.
1 ngOnChanges (): void {
2 if (!this.CMWidgetData || !this.hasMovements(this.CMWidgetData)) {
3 this.showBarChart = false;
4 return;
5 }
6 this.getDates ();
7 this.createChart ();
8 }
37
En la definición anterior podemos observar que si los datos vienen vacíos (es decir que no hay
cuentas o bien estas cuentas no tienen movimientos) el widget no es mostrado. Posteriormente,
si pasa este control se ejecutan los dos métodos encargados de la UI del widget.
4. getDates(), es un sencillo método encargado de mostrar la fecha completa en el widget
mientras que el método createChart() es más complejo, así que dividiremos su estructura
para explicarlo con más detenimiento.
Primeramente este método en la línea (2) elimina el antiguo gráfico si éste existe, después
verificamos que la referencia al gráfico no sea nula y continuamos con la creación del gráfico.
De la línea (9-14) creamos un nuevo elemento ’svg’ y definimos la altura y la anchura del
contenedor del gráfico, más abajo definimos tambien la altura y anchura del gráfico.
1 private createChart (): void {
2 d3.select(’svg’).remove ();
3 const data = this.CMWidgetData;
4
5 if (this.chartContainer) {
6 const element = this.chartContainer.nativeElement;
7
8 const svg = d3.select(element).append(’svg’)
9 .attr(’width ’, element.offsetWidth)
10 .attr(’height ’, element.offsetHeight);
11
12 const contentWidth = element.offsetWidth - this.margin.left - this.margin.
right;
13 const contentHeight = element.offsetHeight - this.margin.top - this.margin
.bottom;
14
15 [...]
16 }
A continuación, se definen las propiedades gráficas para las dos axis del gráfico. Se puede
observar que el dominio de estas axis se adaptan a la cantidad de cuentas y movimientos del
modelo recibido BarChartDataModel.
De esta manera tenemos construidas cada una de las columnas (Cuentas) para su posterior
manipulación dentro del gráfico.
1 private createChart (): void {
2 [...]
3 const x = d3
4 .scaleBand ()
5 .rangeRound ([0, contentWidth ])
6 .padding (0.1)
7 .domain(data.map(d => d.account_name));
8
9 const y = d3
10 .scaleLinear ()
11 .rangeRound ([ contentHeight ,0])
12 .domain ([0,d3.max(data ,d => d.total_movements)]);
13 [...]
14 }
En el siguiente fragmento de código, se aplica al gráfico la distribución visual de las columnas.
El elemento ’g’ de D3.js es usado para agrupar todas las columnas que tenemos en el gráfico
y adicionalmente les proporciona estilo gracias a las clases definidas por D3.js.
1 private createChart (): void {
2 [...]
3 const g = svg.append(’g’)
4 .attr(’transform ’,’translate(’ + this.margin.left + ’,’ + this.margin.
top + ’)’);
5
6 g.append(’g’)
7 .attr(’class ’,’axis axis --x’)
8 .attr(’transform ’,’translate (0,’ + contentHeight + ’)’)
9 .call(d3.axisBottom(x));
10
11 g.append(’g’)
12 .attr(’class ’,’axis axis --y’)
38
13 .call(d3.axisLeft(y).ticks(4))
14 .append(’text’)
15 .attr(’transform ’,’rotate (-90)’)
16 .attr(’y’ ,6)
17 .attr(’dy’,’0.71em’)
18 .attr(’text -anchor ’,’end’)
19 .text(’Total ’);
20 [...]
21 }
Para finalizar, para cada una de las columnas ya preparadas se aplican los atributos fun-
cionales y se incrusta un tooltip encargado de informarnos de la cantidad de dinero gastado
agrupado por cuenta.
1 private createChart (): void {
2 [...]
3 g.selectAll(’.bar’)
4 .data(data)
5 .enter().append(’rect’)
6 .attr(’class ’,’bar’)
7 .attr(’x’,d => x(d.account_name))
8 .attr(’y’,d => y(d.total_movements))
9 .attr(’width ’,x.bandwidth ())
10 .attr(’height ’,d => contentHeight - y(d.total_movements))
11 .on(’mouseover ’,function(d) {
12 return tooltip.style(’visibility ’,’visible ’).text(d.total_movements
+ ’[U+FFFD]’);
13 })
14 .on(’mousemove ’,function(d) {
15 return tooltip.style(’top’,
16 (d3.event.pageY - 10) + ’px’).style(’left’,‘${d3.event.pageX + 10}
px ‘).text(d.total_movements + ’[U+FFFD]’);
17 })
18 .on(’mouseout ’,function () {
19 return tooltip.style(’visibility ’,’hidden ’);
20 });
21 }
39
Como podemos ver en las subimagenes de la imagen 6.7 tenemos los diferentes aspectos que pue-
den generar el widget de Movimientos. Al utilizar D3js permite ajustar muy bien el aspecto de las
columnas en un espacio tan reducido.
Cabe añadir que como identificadores de estas cuentas se ha utilizado las iniciales de cada cuenta,
ya que al tener un espacio corto y físicamente no escribir el nombre completo, se ha optado por un
identificador alfanumérico del estilo que podéis observar a continuación.
(a) Cliente sin movimientos el mes actual (b) Cliente con una cuenta con movimientos el
mes actual
(c) Cliente con cinco cuentas con movimientos
el mes actual
(d) Cliente con siete cuentas con movimientos
el mes actual
Imagen 6.7: Widget de Movimientos, Look and Feel
6.2.6. Construcción de la Autenticación
1. Generación los Componentes necesarios para construir el proceso de autenticación.
1 // e.g.
2 $ ng g c Login -m app
3 $ ng g c Register -m app
2. Generación de el Servicio de autenticación, encargado de gestionar las peticiones de auten-
ticación y enviarlas directamente contra la API.
1 // e.g.
2 $ ng g s Authentication -m app
3. A continuación, se expondrá la definición del servicio.
1 // Authentication operations
2 public register(user: TokenPayload): Observable <any >;
3 public login(user: TokenPayload): Observable <any >;
40
4 public logout (): void;
5
6 // User statuses operations
7 public isLoggedIn (): boolean;
8 public isAdmin (): boolean;
9 public getUserDetails (): UserDetails;
10
11 // Token handler operations
12 private getToken (): string;
13 private setToken(token: string): void;
14 private removeToken (): void
4. El último método de éste servicio lo vamos a ver con un poco más de detalle ya que con
éste método se centraliza la parte del login y del registro en una única operación. Si es una
operación de Login y el servicio responde con el Token que valida el acceso, se guarda el Token
para su uso en futuras peticiones al servicio y como resultado de la operación se devuelve un
Observable para controlar en todo momento la asincronía del método.
1 // Manage our requests to endpoint authentication routes
2 private request(type: ’login’ | ’register ’, user?: TokenPayload): Observable <
any > {
3 let base;
4 base = this.http.post(Environment.endPoint + ‘${type}‘,user);
5 return base.pipe(
6 map((data: TokenResponse) => {
7 if (data.token) {
8 if (type === ’login’) {
9 this.setToken(data.token);
10 }
11 }
12 return data;
13 })
14 );
15 }
5. Gracias a este servicio, únicamente desde los componentes involucrados en la gestión de la
sesión se harán las peticiones pertinentes para Iniciar/Cerrar la sesión.
Podemos ver un ejemplo de estas peticiones en LoginComponent.
1 public login (): void {
2 this.loggingInProgress = true;
3 this.authenticationService.login(this.credentials).subscribe (() => {
4 this.loggingInProgress = false;
5 this.router.navigateByUrl(’/’);
6 }, (err) => {
7 this.loggingInProgress = false;
8 this.openSnackBar(’Sorry , account not found :(’);
9 this.router.navigateByUrl(’/login’);
10 });
11 }
6.2.7. Guards, protección de las rutas internas
1. Como primer punto, comenzamos generando el Guard nuevamente gracias a la herramienta
Angular Cli
1 $ ng g g AuthGuard -m app
2. Después declaramos una instancia del AuthenticationService antes creado en el construc-
tor del Guard.
3. A continuación, escribimos un método sencillo que se encargará de decirnos si la ruta a la
que se intenta acceder esta permitida o no.
1 public canActivate ():boolean {
2 if (!this.authenticationService.isLoggedIn ()) {
3 this.router.navigateByUrl(’/login’);
4 return false;
5 }
6 return true;
7 }
41
4. Ahora nos dirigimos al enrutador interno de angular, situado en el src/app/app-routing-
module.ts y protegemos cada una de las rutas que no deban estar visibles para los usuarios
no autorizados.
1 import { AuthGuardService } from ’./ guards/auth -guard.service ’;
2
3 const routes: Routes = [
4 { path: ’’, component: HomeComponent , canActivate :[ AuthGuardService] },
[...]
5. De esta manera tenemos un sencillo control de acceso en el Portal para usuarios no autori-
zados.
6.2.8. Interceptor
1. Para realizar una conexión segura con la API se ha implementado un Interceptor. En cada
petición a la API, éste se encargará de añadir el JWT extraído de la API en la fase de Login.
De esta manera el servicio sabrá que es una conexión segura y así podrá exponer sus recursos
sin riesgo al filtrado de la información.
2. El primer paso ha sido generar un service
1 $ ng g s AuthInterceptor -m app
3. Este service implementará la Interface HTTPInterceptor y a su vez el método intercept con
la siguiente definición
1 intercept(req: HttpRequest <any >, next: HttpHandler): Observable <HttpEvent <any
>>;
4. Dentro de este método escribiremos la lógica capaz de añadir el JWT en los headers de cada
petición saliente desde el Portal a la API
1 let token = ‘Bearer ${this.auth.getToken ()}‘;
2 let newreq = req;
3 if (token) {
4 newreq = req.clone({
5 headers: req
6 .headers
7 .set(’Authorization ’, token)
8 });
9 }
10
11 return next.handle(newreq).do((event: HttpEvent <any >) => {
12 if (event instanceof HttpResponse) {
13 localStorage.setItem(’current_user ’, event.headers.get(’user’));
14 }
15 }, (err: any) => {
16 if (err instanceof HttpErrorResponse) {
17 if (err.status === 401) {
18 this.router.navigate ([’login ’]);
19 }
20 }
21 });
22 }
De esta manera podemos desautenticar al usuario si su token sufre alteraciones o ha caducado.
42
(a) Petición a la API con JWT añadido
(b) Respuesta de la API
Imagen 6.8: Conexión con la API con JWT
43
6.2.9. Despliegue del Portal MyBank
En éste punto del desarrollo tenemos el Portal completamente funcional y listo para gestionar
cliente pero lo tenemos en local y todavía falta un último paso por seguir. Como comentamos en
la planificación, el portal también debe estar operativo en la Nube por lo que a continuación se
explicará como se ha llevado el Portal a la PaaS Heroku.
1. Primeramente creamos una nueva aplicación en Heroku como creamos previamente para la
API.
1 $ heroku create clientside -appbank
2 Creating app... done , clientside -appbank
3 Created http://clientside -appbank.herokuapp.com/ | git@heroku.com:
clientside -appbank.git
2. Una vez creada la App, nos vamos a la plataforma heroku https://dashboard.heroku.
com/apps/. Una vez allí entramos en nuestra App y configuramos el repositorio de Github
por defecto que va a utilizar heroku para hacer los builds que se encargarán de ejecutar el
despliegue.
En la imagen 6.9 podemos observar como querdaría la configuración.
Imagen 6.9: Heroku, automatización del despliegue gracias a Github
3. Una vez tenemos la App creada en Heroku y configurado el repositorio donde se van a hacer
los deploys automáticos, seguimos una serie de instrucciones que nos ayudarán a tener nues-
tro portal en Heroku.
Añadimos en el package.json