ESTUDIO Y DESARROLLO DE UN PROTOTIPO DE APLICACIÓN …tauja.ujaen.es/bitstream/10953.1/8439/1/TFG... · Se realizará con el Framework Ionic que está basado en Angular JS y el servidor

Universidad de Jaén

Escuela Politécnica Superior de Jaén

Trabajo Fin de Grado

ESTUDIO Y DESARROLLO DE

UN PROTOTIPO DE

APLICACIÓN WEB PARA LA

GESTIÓN DE COMANDAS EN

UN ESTABLECIMIENTO DE

HOSTELERÍA

Alumno: José Jiménez De la Paz

Tutor: Prof. D. José Ramón Balsas Almagro Dpto: Informática

Junio, 2018

Escu

ela

Polit

écn

ica S

up

eri

or

de J

aé

n

José Jiménez De la Paz Gestión de comandas en un establecimiento de hostelería

Escuela Politécnica Superior de Jaén 2

Universidad de Jaén

ESCUELA POLITÉCNICA SUPERIOR DE JAÉN

DEPARTAMENTO DE INFORMÁTICA

Don JOSÉ RAMÓN BALSAS ALMAGRO, tutor del Trabajo Fin de Grado titulado: ESTUDIO Y DESARROLLO DE UN PROTOTIPO WEB PARA LA GESTIÓN DE COMANDAS EN UN ESTABLECIMIENTO DE HOSTELERÍA, que presenta JOSÉ JIMÉNEZ DE LA PAZ, autoriza su presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.

Jaén, junio de 2018

El alumno: Los tutores:

José Jiménez De la Paz José Ramón Balsas Almagro



Escuela Politécnica Superior de Jaén ............................................................................ 1

Grado en Ingeniería Informática .......................................................................................... 1

1. INTRODUCCIÓN. ................................................................................................. 9

1.1. Introducción al proyecto. ................................................................................ 9

1.2. Motivación ................................................................................................... 10

1.3. Objetivo ....................................................................................................... 11

Objetivos específicos ............................................................................................ 11

1.4. Metodologías ................................................................................................ 11

Diferencias entre metodología tradicional y metodología ágil. ................................... 13

SCRUM .............................................................................................................. 14

1.5. Estructura del documento ............................................................................ 16

2. ANÁLISIS. .......................................................................................................... 18

2.1. Análisis preliminar .......................................................................................... 18

Estado del arte ...................................................................................................... 21

2.2. Propuesta de solución....................................................................................... 23

2.3. Historias de usuario ......................................................................................... 24

2.4. Criterios de satisfacción ................................................................................... 26

2.5. Planificación temporal ..................................................................................... 29

Estimación de las historias de usuario y definición de las tareas. ................................ 29

Priorización de las historias de usuario .................................................................... 32

Estimación de velocidad ........................................................................................ 34

Evolución de las estimaciones ................................................................................ 36

2.6. Estudio de viabilidad........................................................................................ 38

2.7. Modelo de dominio........................................................................................... 40

3. DISEÑO .............................................................................................................. 41

3.1. Diagrama de Entidad-Relación ..................................................................... 41

3.2. Diagrama de clases ....................................................................................... 43

Aplicación Cliente ................................................................................................ 43

Aplicación Servidor .............................................................................................. 47

3.3. Diagramas de secuencia ................................................................................ 48

3.4. Diseño de la interfaz ..................................................................................... 56

4. IMPLEMENTACIÓN ........................................................................................... 67

4.1. Arquitectura de la aplicación ........................................................................ 67

4.2. Detalles sobre la implementación .................................................................. 69

Aplicación Cliente ................................................................................................ 69

Aplicación Servidor .............................................................................................. 74

5. PRUEBAS .......................................................................................................... 81

6. CONCLUSIONES ................................................................................................ 82

6.1. Trabajos futuros .......................................................................................... 83



7. BIBLIOGRAFÍA .................................................................................................. 85

APÉNDICE I: MANUAL DE INSTALACIÓN DEL SISTEMA ...................................... 88

APÉNDICE II: MANUAL DE USUARIO .................................................................... 89

APÉNDICE III: MANUAL DE CONTENIDOS SUMINISTRADOS ............................ 101



Índice de ilustraciones

Ilustración 1 Proceso tradicional ............................................................................... 13

Ilustración 2 Proceso ágil.......................................................................................... 13

Ilustración 4 Enfoque ágil ......................................................................................... 13

Ilustración 3 Enfoque tradicional ............................................................................... 13

Ilustración 5 Costo del cambio .................................................................................. 14

Ilustración 6 Ciclo de trabajo SCRUM ...................................................................... 15

Ilustración 7 Sistema actual de anotación de comandas .......................................... 18

Ilustración 8 Aplicación nativa, híbrida o web ........................................................... 19

Ilustración 9 Capturas de MyOrder https://goo.gl/qAJiQd ......................................... 21

Ilustración 10 Captura de Mr Noow https://goo.gl/j2HEQG....................................... 22

Ilustración 11 Historias de usuario ............................................................................ 26

Ilustración 12 Criterios de satisfacción ..................................................................... 28

Ilustración 13 Tareas y estimación de las historias .................................................. 32

Ilustración 14 Prioridad Must .................................................................................... 33

Ilustración 15 Prioridad Should ................................................................................. 33

Ilustración 16 Prioridad Could ................................................................................... 34

Ilustración 17 Prioridad Would not ............................................................................ 34

Ilustración 18 Planificación 1 de los Sprints ............................................................. 35

Ilustración 19 Planificación 2 de los Sprints ............................................................. 37

Ilustración 20 Gráfico Burn Down ............................................................................. 37

Ilustración 21 Coste Herramientas Software ............................................................ 38

Ilustración 22 Coste Herramientas Hardware ........................................................... 38

Ilustración 23 Modelo del dominio ............................................................................ 40

Ilustración 24 Esquema comunicación con BD ......................................................... 41

Ilustración 25 Diagrama de BD ................................................................................. 42

Ilustración 26 Tablas creadas por JPA ..................................................................... 43



Ilustración 27 Esquema MVVM https://goo.gl/C2nRiC ............................................. 44

Ilustración 28 Diagrama de clases Cliente ............................................................... 45

Ilustración 29 Diagrama de clases lado del cliente, rol de camarero y cocinero....... 46

Ilustración 30 Diagrama de clases servidor .............................................................. 47

Ilustración 31 Diagrama de secuencia seguridad ..................................................... 48

Ilustración 32 Diagrama de secuencia login ............................................................. 49

Ilustración 33 Diagrama de secuencia login servidor ............................................... 50

Ilustración 34 Diagrama de secuencia registro cliente ............................................. 51

Ilustración 35 Diagrama de secuencia registro servidor ........................................... 52

Ilustración 36 Diagrama de secuencia realizar pedido ............................................. 53

Ilustración 37 Diagrama de secuencia realizar pedido en servidor ........................... 54

Ilustración 38 Diagrama de secuencia pagar cliente cliente ..................................... 55

Ilustración 39 Diagrama de secuencia pagar la cuenta servidor .............................. 55

Ilustración 40 Diagrama de estados del cliente ........................................................ 57

Ilustración 41 Interfaz de identificación ..................................................................... 58

Ilustración 42 Interfaz cuenta .................................................................................... 59

Ilustración 43 Interfaz categoría ............................................................................... 60

Ilustración 44 Interfaz producto ................................................................................ 61

Ilustración 45 Interfaz historial .................................................................................. 62

Ilustración 46 Interfaz buscar .................................................................................... 63

Ilustración 47 Interfaz carrito .................................................................................... 64

Ilustración 48 Interfaces enlazar y cobrar ................................................................. 65

Ilustración 49 Interfaz cocinero ................................................................................. 66

Ilustración 50 Diagrama cliente-servidor .................................................................. 67

Ilustración 51 Diagrama arquitectónico del sistema ................................................. 68

Ilustración 52 Ionic Workflow https://goo.gl/JoR6aE ................................................. 69

Ilustración 52 Estructura ionic ................................................................................... 70



Ilustración 54 Vista enlazar.html ............................................................................... 71

Ilustración 55 Controlador enlazar.ts ........................................................................ 71

Ilustración 56 Generar app en distintas plataformas ................................................ 72

Ilustración 57 Ejemplo petición get ........................................................................... 73

Ilustración 58 Local Storage ..................................................................................... 74

Ilustración 59 GIT servidor........................................................................................ 75

Ilustración 60 Etiquetas JPA ..................................................................................... 76

Ilustración 61 Pedido DAO ....................................................................................... 76

Ilustración 62 Tabla end-points ................................................................................. 78

Ilustración 63 Creación de token .............................................................................. 79

Ilustración 64 Comprobación token en cada petición ............................................... 80

Ilustración 65 Server Side Events ............................................................................. 80

Ilustración 63 Vista registro ...................................................................................... 89

Ilustración 67 Vista login ........................................................................................... 89

Ilustración 69 Vista categorías .................................................................................. 90

Ilustración 65 Vista productos ................................................................................... 90

Ilustración 67 Vista producto 2 ................................................................................. 91

Ilustración 71 Vista producto .................................................................................... 91

Ilustración 69 Vista carrito ........................................................................................ 92

Ilustración 73 Vista categorías con carrito ................................................................ 92

Ilustración 71 Pedido con éxito ................................................................................. 93

Ilustración 75 Confirmación pedido .......................................................................... 93

Ilustración 73 Confirmación pagar ............................................................................ 94

Ilustración 77 Vista de cuenta ................................................................................... 94

Ilustración 78 Vista buscador .................................................................................... 95

Ilustración 79 Vista historial de pedidos ................................................................... 96

Ilustración 77 Vista enlazar éxito .............................................................................. 97



Ilustración 81 Vista enlazar 1 .................................................................................... 97

Ilustración 79 Vista servir eliminar ............................................................................ 98

Ilustración 83 Vista servir 1....................................................................................... 98

Ilustración 84 Vista cobrar ........................................................................................ 99

Ilustración 85 Vista cocinero ................................................................................... 100



1.1. Introducción al proyecto.

Para finalizar la carrera de ingeniería informática he decidido basar mi trabajo fin de

grado en la realización de una aplicación móvil para pedir la comanda en un restaurante.

Este tipo de aplicación va a automatizar la forma de dar servicio a los clientes del

restaurante añadiendo una mejor comunicación con la cocina y los camareros. A través de

ella estarán "conectados" los clientes, camareros y cocineros para que la relación cliente-

restaurante sea automática y reduciendo tiempos de espera.

La idea es que el cliente desde su mesa y con su móvil, ya sea con un sistema operativo

Android o Apple iOS, se conectará con su cuenta a la aplicación y podrá acceder a los

distintos menús.

El cliente puede consultar la carta de productos, ordenada por categoría (ensaladas,

carnes, bebidas, etc.) ir añadiendo al carrito los productos que desee tomar y, finalmente,

hacer el pedido. También desde el móvil puede ver la cuenta total hasta el momento de

pagar, los pedidos que ha realizado en ese momento, un historial de pedidos y un

buscador de productos.

El camarero también tendría un dispositivo móvil donde puede ver el estado de los

pedidos de las mesas para avisarle si tiene que llevar algún pedido o cobrarles.

Por otra parte, el cocinero tendrá acceso a la aplicación desde la cocina para ver el estado

de los pedidos, ordenados por orden de entrada. El cocinero una vez que haya preparado

el pedido lo marcará como preparado para que el camarero lo entregue a los clientes.

Con esta aplicación los camareros del restaurante seguirían en sus puestos de trabajo,

aunque cambiando un poco sus tareas a desempeñar. Además, los clientes que sean más

reacios al uso de tecnología, el método tradicional de que el camarero apunte las

comandas en la libreta podrá convivir con la aplicación.

Esta digitalización de la comunicación cliente-restaurante facilita al restaurante la

promoción de sus productos, ofertas e incluso hacer un sistema de puntos para premiar a



sus mejores clientes, que en definitiva contribuirá a mejorar la experiencia de usuario del

cliente.

1.2. Motivación

Pedir la comanda en un restaurante desde el teléfono móvil, en la actualidad, no sería

algo extraño. Según una noticia, España es el 5º país del mundo que más tiempo pasa con

el teléfono. [1].

Además, supondría una serie de ventajas como automatizar los pedidos aportando un

toque moderno y agilizando los tiempos de comunicación cliente-camarero-cocina, o la

novedad para los clientes de usar su propio móvil para pedir su comanda.

En el año 2017 por primera vez los móviles superaron a los ordenadores como medio más

habitual de acceso a internet [1], esto conlleva un gran aumento en la industria del móvil,

además de que en los últimos 5 años ha aumenta el uso de "smartphones" en España,

siendo el porcentaje de españoles con móvil de 81% según una noticia de cadena ser [2].

Por otro lado, existe un gran mercado de teléfonos móviles con sus respectivos sistemas

operativos, entre lo que destacan: Android e iOS, entre otros. Esta diversidad de sistemas

operativos provoca desarrollos específicos dedicados para cada uno, y esto hay que

tenerlo en cuenta si se quiere hace una aplicación para ser compatible con el mayor

número de SO.

Una aplicación móvil híbrida multiplataforma, tiene como ventaja realizar un solo

desarrollo de la aplicación y generar la aplicación con compatibilidad con distintos

sistemas operativos. Por ello se decidió basar la aplicación en un framework que nos

permitiera esto.

A partir de estas ideas, se contactó con un Restaurante que pudiera servir como cliente y

permitiera obtener de primera mano los requisitos reales de la aplicación. En la reunión

con la dueña del restaurante se explicaron estas noticias y las ventajas de usar esta

aplicación en su restaurante. Finalmente, su confirmación, me permitió basar mi trabajo

fin de grado en el desarrollo de dicha aplicación. El nombre que se decidió para la

aplicación fue "TuComanda".



La realización de este proyecto me permite poner en práctica los conocimientos

aprendidos en las asignaturas de la carrera. De cómo asignaturas que aparentemente no

tenían relación como: Desarrollo ágil, Desarrollo de aplicaciones web, Desarrollo de

aplicaciones empresariales, Estructura de datos, Base de datos… etc componen entre

todas la aplicación. Cada una desde su ámbito, pero con la misma importancia que las

demás, formando así la aplicación y metodologías a seguir. Además de dar la oportunidad

de aplicar los conocimientos a un caso real y que verdaderamente ayuda a las personas o

al negocio.

1.3. Objetivo

El objetivo principal del proyecto es realizar una app móvil que sea compatible para los 2

sistemas operativos de móvil más usados en la actualidad, Android o Apple iOS, y sea

capaz de pedir la comanda en un restaurante. Se realizará con el Framework Ionic que

está basado en Angular JS y el servidor con Spring Boot. El uso de estos lenguajes

punteros me permitirá en el futuro tener experiencia y poder acceder con más

conocimientos en el mundo laboral.

El proyecto implicará un estudio previo de soluciones existentes, además de análisis,

diseño e implementación del proyecto.

Objetivos específicos

De forma detallada, para la realización del presente TFG se establecieron los siguientes

objetivos, cuyo alcance y consecución se presenta a lo largo de esta memoria:

Realizar un estudio de necesidades y soluciones existentes en el contexto

seleccionado.

Diseñar un sistema informático especialmente orientado a la utilización de

arquitecturas, principios de diseño y metodologías de desarrollo web.

Seleccionar un entorno de desarrollo web e implementar un prototipo de

aplicación web que satisfaga las necesidades que se hayan determinado.

1.4. Metodologías

Para el desarrollo del trabajo, se decidió seguir una metodología ágil para dar un papel

importante al cliente durante las estepas del proceso, ir entregando el producto en



intervalos para que el producto final sea una suma de entregables que nos proporcione un

mejor seguimiento, y conocer realmente cuales son las tareas innecesarias para poder

centralizar los esfuerzos en las verdaderamente importantes. Se comentan a continuación

algunas ideas sobre este tipo de metodologías.

Kent Beck y otros expertos en la industria del software se reunieron Utah, EEUU en 2001

[3]. Firmaron el 'Manifiesto por el desarrollo ágil del software' [4], en el que destacaron

los siguientes principios:

Individuos e interacciones sobre procesos y herramientas.

Software funcionando sobre documentación extensiva.

Colaboración con el cliente sobre negociación contractual.

Respuesta ante el cambio, mejor que acogerse a un plan.

Dando importancia a los elementos de la derecha, aunque con más importancia aún a los

de la izquierda, surgió un nuevo paradigma.

Principios derivados del manifiesto [5]:

Satisfacción del cliente como prioridad, mediante entregas frecuentes y en etapas

tempranas.

Los cambios son bienvenidos, aun en una etapa avanzada del desarrollo.

Entrega frecuente de software que funcione, de 2 semanas a un par de meses lo

más pronto que se pueda.

El personal de la empresa y los desarrolladores deben trabajar juntos y mejorar la

comunicación.

Motivación del equipo, con los trabajadores motivados se aumentará la

productividad.

Comunicación cara a cara como método de comunicación con los integrantes del

equipo principal.

El software que funciona es la mejor medida de progreso.

Ritmo de desarrollo sostenible, máximo 40 horas semanales.

Atención continua a la calidad técnica y al buen diseño.

Maximizar el trabajo no hecho, no desarrollar más de lo acordado.



Equipos auto-organizados, mantener los equipos de un proyecto a otro.

Autoevaluación, el equipo se reúne regularmente para hacer autocrítica y plantear

posibles mejoras.

Diferencias entre metodología tradicional y metodología ágil.

El proceso ágil sigue haciendo las mismas actividades del proceso de desarrollo de

software, aunque difiere en la forma de hacerlo. [6]

Como se observa en las ilustraciones 1 y 2 se puede observar que las fases de desarrollo

en el proceso ágil son las mismas, pero varía en la forma de hacerlo.

Ilustración 2 Proceso ágil

Pero, aunque tengan las mismas actividades tiene una consecuencia importante a la hora

de realizar el proyecto. En el enfoque tradicional se fijan los requisitos y a partir de ellos

se estiman el tiempo y coste para poder cumplir los requisitos. Sin embargo, con el

enfoque ágil se fijan el tiempo y el coste y a partir de estos dos valores se estima los

requisitos [5]. Como se observa en las ilustraciones 3 y 4.

Tiempo

Coste

Requisitos

Estimado

Fijo

Estimado

Tiempo

Coste

Requisitos

Fijo

Ilustración 4 Enfoque tradicional

Ilustración 1 Proceso tradicional

Ilustración 3 Enfoque ágil



El enfoque ágil "suaviza" el costo de cambio (véase la Ilustración 6) consiguiendo la

satisfacción de los clientes. El proceso ágil contempla la entrega incremental además de

pruebas unitarias continuas, disminuyendo el coste de cambios.

Ilustración 5 Costo del cambio

Finalmente debido a que el proyecto tiene una alta probabilidad de que tenga requisitos

cambiantes, predispuestos al cambio y modificaciones, y con un desarrollo que se adapte

a las necesidades del cliente he decidido usar una metodología ágil. Además de que el

cliente obtenga regularmente pequeñas versiones del proyecto es uno de los motivos que

me ha hecho decidirme a este tipo de metodología. Concretamente la metodología elegida

es SCRUM.

SCRUM

SCRUM es un proceso ágil adaptable, iterativo, rápido, flexible y eficaz que está

diseñado para entregar valor al cliente durante el desarrollo del proyecto. [7]

SCRUM usa patrones de desarrollo que son eficaces para proyecto con plazos de entrega

cortos y requisitos cambiantes. Con intervalos de 2 o 4 semanas se puede ver el software

funcionando y decidir si seguir mejorándolo o entregarlo.

El objetivo principal es satisfacer las necesidades del cliente, favoreciendo la

comunicación con el cliente y el equipo de desarrolladores.



Ciclo de trabajo en SCRUM:

Ilustración 6 Ciclo de trabajo SCRUM

1. Toma de requisitos al cliente, para cada requisito principal se crea una historia

de usuario.

2. El cliente ordena la lista priorizada del producto (backlog), que contiene la lista

de los requisitos en orden de prioridad para el negocio en forma de historias de

usuario.

3. El equipo de trabajo toma un grupo de historias del backlog y las incluyen en la

planificación del Sprint divididas en sub tareas más sencillas. El equipo trabaja

en la realización de los entregables durante 2-6 semanas. En el Sprint no se

admiten cambios para que el equipo trabaje de forma estable y a corto plazo.

4. Durante el Sprint se realizan reuniones diarias y se debe responder a 3 preguntas

clave:

a. ¿Qué hiciste ayer?

b. ¿Qué harás hoy?

c. ¿Hay obstáculos en tu camino?

Al final de cada Spring se realiza una reunión de retrospectiva del Spring donde se

analizan los aspectos que mejorar y los problemas ocurridos durante el mismo.

Una vez finalizado el Spring se entrega al cliente el resultado del trabajo y se vuelve al

punto 2 hasta acabar con las historias.



Adaptación de SCRUM al proyecto:

En mi caso, para adaptar esta metodología ágil he tenido que adaptar algunos roles y uso

de reuniones:

Product Owner: sí se mantiene, es el responsable del producto. Define las

funcionalidades principales del producto, estima fechas, prioriza las

funcionalidades, además de evaluar los entregables. Este rol lo adoptaría la

dueña del restaurante.

Scrum Master y Team: El responsable del funcionamiento de SCRUM y

equipo de desarrollo (analista y programador) lo haría individualmente.

Reuniones de equipo: Puesto que yo adoptaré el perfil de equipo, no tiene

sentido hacer las reuniones, aunque sí es útil hacer un seguimiento del

trabajo realizado, anotando los problemas, lo que se hará en el futuro y lo

que hice el día anterior.

1.5. Estructura del documento

El documento se ha organizado de la siguiente forma: en el apartado 2 llamado "Análisis"

se describirá el sistema del que se parte y se verán sus desventajas además de ver otras

aplicaciones similares y la propuesta de solución, incluyendo historias de usuario,

planificación y viabilidad.

En el apartado 3 de diseño se mostrarán los detalles que se han tenido en cuenta a la hora

de organizar la información que gestionará la aplicación, así como la estructura y

funcionamiento del software a desarrollar, para los que se incluyen: el diagrama entidad

relación de la base de datos, el diagrama de clases de la aplicación, diagramas de

secuencia de los aspectos más relevantes y diseño de la interfaz mediante un programa

informático.

En apartado 4 de implementación se detallará la arquitectura de la aplicación y la relación

entre los elementos, además de los detalles sobre la implementación donde se menciona

técnicas y tecnologías empleadas.



Después en el apartado 5 llamado “Pruebas”, se mostrará cómo se ha comprobado el

correcto funcionamiento de la aplicación y si se ha obtenido los resultados esperados.

En el apartado 6 se explica las conclusiones del proyecto y trabajos futuros para ampliar

o mejorar el proyecto.

Finalmente se añaden tres anexos: manual de instalación del sistema, manual de usuario y

manual de contenidos suministrados.



La etapa de análisis debe estar completa antes de pasar al diseño. El análisis proporciona

al diseño toda la información necesaria para crear los modelos del diseño [1].

2.1. Análisis preliminar

Se parte de un sistema para atender las comandas tradicional, que en gran medida cumple

su propósito: trasladar a la cocina los pedidos del cliente, pero se observan grandes

deficiencias.

El proceso tradicional consiste en que los camareros

están atentos a las mesas para ver si alguien nuevo se

sienta.

El cliente se sienta a la mesa y mira la carta, que está

impresa y plastificada en la mesa para ver las cosas

que ofertan. En esta aparece los productos agrupados

en categorías y con el precio de cada producto.

A continuación, el cliente llama al camarero y le

dicta las cosas que desea tomar. Éste apunta en su

libreta, que tiene la estructura tal y como se observa

en la Ilustración 7, anotando: nombre del camarero, la

mesa donde está sentado el cliente, la fecha, la

cantidad del producto, el producto y el precio de cada producto.

Después, el camarero lleva la nota a la cocina y la pega en una pared por orden de

llegada. Se fija en las bebidas y acude a la barra a prepararlas y servirlas.

El cocinero recoge la nota de la pared y comienza a realizar las comandas. Conforme va

finalizando una comanda la deja en una mesa grande a la espera de que el camarero acuda

a la cocina y recoja la comanda. La nota no puede perderse porque ahí está apuntada la

mesa del pedido. De hecho, el camarero cada vez que acude a la cocina y quiere llevarse

una comanda debe mirarla.

Ilustración 7 Sistema actual de anotación de comandas



Finalmente, cuando el cliente quiere finalizar y pagar su cuenta, debe llamar la atención

al camarero y pedirle la cuenta para que le cobre.

Inconvenientes del proceso tradicional:

Si se quisiera editar la información de un producto se deberían reimprimir todas

las cartas.

Las cartas se deterioran con el paso del tiempo y se deben volver a imprimir.

El camarero debe anotar su nombre, la fecha y la mesa cada vez que atiende a un

cliente, siendo un proceso lento.

A veces no se entiende la caligrafía del camarero.

Es posible que se pierda la nota y no se sepa los productos que había apuntados o

la mesa.

El camarero continuamente debe entrar a la cocina y mirar si hay algún plato

cocinado.

El cliente debe llamar la atención al camarero cada vez que quiera pedir algo.

Como hemos visto anteriormente son numerosos los inconvenientes, sin embargo, con el

nuevo sistema que se propone se solventarían todos ellos.

Hay varias alternativas [8] para hacer una aplicación web para el móvil: aplicación

nativa, aplicación híbrida o una web.

Ilustración 8 Aplicación nativa, híbrida o web



La principal desventaja de hacer una aplicación nativa es que no sería multiplataforma y

solo nos serviría para el sistema operativo en que se base. Una aplicación nativa sería un

inconveniente para el proyecto.

Basar la aplicación en una web, tendría inconvenientes, como que no nos proporcionaría

una interfaz fluida e intuitiva, no se podría subir a las tiendas de aplicaciones móviles y

tendría poco rendimiento.

Una aplicación híbrida es una combinación de HTML, CSS y JavaScript, que se ejecuta

dentro de un contenedor nativo. Permite usar funcionalidades del dispositivo como el

GPS o la cámara entre otras.

Además, una aplicación híbrida proporciona una interfaz fluida e intuitiva,

multiplataforma, posibilidad de subir la aplicación a las tiendas de aplicaciones móviles

entre otras ventajas.

Una vez realizada la comparación con las tres opciones, nos hemos decantado por realizar

una aplicación híbrida. Puesto que sus características son ideales para el proyecto.



Estado del arte

A continuación, se comentarán algunas aplicaciones similares a la que vamos a

desarrollar para pedir la comanda desde el móvil. Esto servirá para coger ideas para

nuestra aplicación y evitar los posibles fallos.

My Order1

Ilustración 9 Capturas de MyOrder https://goo.gl/qAJiQd

Esta es una aplicación para pedir la comanda desde el móvil, puedes navegar en la carta y

pedir los productos que desees, además puedes añadir notas en los productos.

Ventajas:

Se puede añadir notas a los productos.

Disponible en Android y Apple iOS.

Tiene el sistema de carrito para pedir los productos.

Dispone de buscador.

Inconvenientes:

Interfaz poco llamativa.

Actualmente en desuso.

1 https://goo.gl/kPwQoQ



No tiene sistema de bonificar a los usuarios.

MR. Noow2

Es una aplicación similar a la anterior, pero con más funcionalidades y optimizada. Está

desarrollada por españoles y en Madrid actualmente existen comercios que la utilizan.

Ilustración 10 Captura de Mr Noow https://goo.gl/j2HEQG

Ventajas:

Interfaz muy intuitiva y llamativa.

Dispone de pago virtual.

Encontrar por geolocalización restaurantes cercanos.

Disponible en Android y Apple iOS.

Son pocos los inconvenientes que he podido encontrar, pero por ejemplo añadir notas al

producto a pedir es uno de ellos, creo que es algo muy importante para adaptarte a las

necesidades del cliente.

2 https://www.mrnoow.com/



2.2. Propuesta de solución

Con este análisis previo, se ha quedado más claro el sistema que se quiere realizar. El

objetivo es hacer un prototipo de una aplicación web móvil híbrida instalable y

multiplataforma.

El sistema estará dividido en dos aplicaciones, la del cliente y la del servidor.

Cliente

El framework elegido para hacer la aplicación web híbrida es Ionic3 que es un SDK

(software development kit) que provee servicios y herramientas para desarrollar

aplicaciones híbridas. Está basado en AngularJS 4 y Apache Cordova5, el objetivo es

simplificar el front-end. Ionic es gratuito, con foro para dudas y un gran manual online

donde explica con ejemplos todo su potencial.

Servidor

El servidor deberá proporcionar una API RESTFUL para la comunicación el cliente

mediante peticiones POST y GET, además de proporcionar un sistema de identificación

por token y acceso cómodo a la base de datos. La mejor opción es utilizar el estándar

JAX-RS de java utilizando Spring Boot6 .

Spring boot es un framework basado en Java, nos permite hacer Servidores de

aplicaciones embebidos (Tomcat, Jetty, Undertow), POMs con dependencias y plug-ins

para Maven, uso extensivo de anotaciones que realizan funciones de configuración,

inyección, etc.

Utilizaremos JPA para mapear las clases de persistencia (que queramos guardar en la

base de datos) haciendo uso de DAOs para acceder a la base de datos. Como base de

datos se utilizará MySQL.

3 https://ionicframework.com/ 4 https://angularjs.org/ 5 https://cordova.apache.org/ 6 https://es.wikipedia.org/wiki/Spring_Framework



La combinación de Ionic y Spring Boot nos dará una interfaz atractiva para el cliente y

fluida y un servidor estable que proporciona todo lo necesario para el cliente.

2.3. Historias de usuario

Puesto que se ha decidido usar una metodología ágil, concretamente

SCRUM, detallaremos más adelante las historias de usuario, estas se centran en el valor

del cliente con una fuerte intención de fomentar la comunicación. Y obtendremos así los

requisitos.

Las historias de usuario son una forma de obtener los requisitos a partir de la información

obtenida del cliente, mezclando la forma oral y escrita. [9]

Cada historia de usuario es enumerada con un número entero que sirve de identificador,

además tiene criterios de satisfacción. Los criterios de satisfacción describen las acciones

que hay que realizar una vez acabada la historia de usuario para que se válida. Más

adelante se mostrará una tabla con esta información.

Con la ayuda del Product Owner, en este caso es el cliente, he realizado las siguientes

historias de usuario que recoge las funcionalidades principales de la aplicación.

Haré una aclaración de los roles que se usan en las historias de usuario:

Propietario: dueño del restaurante.

Usuarios: clientes del restaurante.

Camarero: camareros contratados del restaurante.

Cocinero: cocinero del restaurante.



ID Título Descripción

1 Registro en el sistema Como propietario del restaurante quiero que los usuarios puedan registrarse en el sistema de forma gratuita introduciendo todos los datos requeridos por el sistema para poder acceder a las funcionalidades del sistema.

2 Identificación en el sistema Como cliente quiero que los usuarios puedan acceder al sistema una vez hayan sido registrados en este.

3 Carta del restaurante Como cliente quiero que los usuarios puedan acceder a la carta del restaurante organizada en categorías, y al seleccionar un producto, podrá ver la información detallada del producto.

4 Añadir producto al carrito Como cliente quiero que los usuarios puedan añadir en el carrito el producto que desee seleccionando la cantidad y dando la opción de añadir notas al producto.

5 Ver carrito Como cliente quiero que los usuarios puedan acceder al carrito y ver los productos seleccionados y finalmente realizar el pedido.

6 Eliminar productos del carrito Como cliente quiero que los usuarios puedan eliminar productos del carrito.

7 Buscador de productos. Como cliente quiero que los usuarios puedan acceder a un buscador de productos y seleccionar la vista del producto detallada.

8 Histórico de pedidos. Como cliente quiero que los usuarios puedan visualizar el histórico de pedidos realizados en el restaurante.

9 Estado de la cuenta Como cliente quiero que los usuarios puedan ver el estado de sus pedidos realizados que están pendientes de pago y una opción para poder llamar al camarero para que le cobre dichos pedidos.

10 Lista del cocinero Como cliente quiero que el cocinero pueda ver la lista de los pedidos en estado de 'pedido', cada producto se detallará la cantidad que introdujo el cliente y el apartado de notas.

11 Producto cocinado Como cliente quiero que el cocinero cuando haya cocinado el producto pueda eliminarlo de su vista para notificar al camarero de que está listo para servir.



12 Enlazar cliente Como cliente quiero que el camarero pueda enlazar al cliente a la mesa en la que está sentado.

13 Servir producto Como cliente quiero que el camarero pueda ver la lista de pedidos listos para servir, que los emite el cocinero y eliminar el pedido una vez servido.

14 Cobrar cliente Como cliente quiero que el camarero pueda seleccionar una mesa y ver los pedidos en estado 'pendiente de pago' para cobrar al cliente y cambiar el estado del pedido a 'pagado'

15 Bonificar con puntos Como cliente quiero que el usuario obtenga puntos para premiarle por sus pedidos. Con estos puntos podrá obtener descuento del precio a pagar.

16 Sistema de gestión Como cliente quiero que el administrador pueda gestionar la carta, cuentas de usuarios, camareros y cocineros.

17 Capturar productos con código Bidi

Como cliente quiero que los usuarios puedan capturar desde su móvil el código Bidi de cada producto desde la carta impresa del restaurante.

Ilustración 11 Historias de usuario

2.4. Criterios de satisfacción

En la siguiente tabla podemos ver los criterios de satisfacción que tiene cada historia de

usuario. Éstos nos indican las acciones a realizar para dar como válida una historia de

usuario. [10]

ID Nombre Criterios de satisfacción

1 Registro en el sistema Introducir datos de registro

incompletos de un nuevo usuario y

comprobar que se indica error.

Introducir todos los datos correctos y

comprobar que ha habido un registro

de un nuevo usuario.

2 Identificación en el sistema Introducir datos de usuario erróneos y comprobar que se da error

Introducir datos de usuario correctos y comprobar que este accede correctamente al sistema.

3 Carta del restaurante Comprobar la correcta navegación entre



categorías.

4 Añadir producto al carrito Comprobar que el producto con su

cantidad y notas es efectivamente lo

que seleccionamos.

5 Ver carrito Comprobar que se puede acceder al

carrito.

Comprobar que los productos que

tiene el carrito son los añadidos

previamente.

Comprobar que se ha realizado el

pedido del carrito correctamente.

6 Eliminar productos del carrito Comprobar que se pueda eliminar productos del carrito correctamente.

7 Buscador de productos. Comprobar que el buscador muestra productos que contengan en su nombre parte del texto introducido en el buscador.

8 Histórico de pedidos. Comprobar que los pedidos

mostrados en el histórico fueron

realizados por dichos usuarios.

Comprobar que los pedidos

mostrados en el histórico muestren

los productos que se pidieron.

9 Estado de la cuenta Comprobar que los pedidos

mostrados tengan el estado pendiente

de pago.

Comprobar que se envié la

notificación al camarero

correctamente.

10 Lista del cocinero Comprobar que los pedidos mostrados equivalgan con los pedidos por el cliente.

11 Producto cocinado Comprobar que se elimina el producto

de su lista.

Comprobar que se notifica al

camarero que atendió el pedido

correctamente.

12 Enlazar cliente Comprobar que se muestra la lista de

mesas del restaurante.

Comprobar que se pueda buscar al

cliente por su nick.

Comprobar que se produce el enlace



correctamente mesa-nick.

13 Servir producto Comprobar que se añade en la lista

de productos a servir justo cuando el

cocinero lo marca como listo para

servir.

Comprobar que se pueda eliminar de

la lista.

14 Cobrar cliente Comprobar se muestra la lista de

mesas del restaurante para

seleccionar una.

Comprobar que muestre

correctamente los pedidos de la mesa

seleccionada.

Comprobar que se produce los

cambios de estado del pedido

correctamente.

15 Bonificar con puntos Comprobar que cuando el cliente

paga el pedido, se le da los puntos.

Comprobar que el cliente puede

canjear los puntos por reducir el

precio del pedido.

16 Sistema de gestión Comprobar que el administrador pueda hacer alta/baja/modificación de la carta y las cuentas de usuarios.

17 Capturar productos con código Bidi

Comprobar que al capturar el código Bidi le muestre la ventana del detalle del producto capturado correctamente.

Ilustración 12 Criterios de satisfacción



2.5. Planificación temporal

En este apartado se hará la planificación temporal para realizar las historias de usuario,

esto conlleva a la estimación, priorización y cálculo de la velocidad.

Estimación de las historias de usuario y definición de las tareas.

A continuación, se estiman las historias de usuario para hacer una idea de la dificultad

que llevaría hacer cada una, he utilizado la serie de Fibonacci: 1,2,3,5,8 cuanto mayor sea

la nota mayor dificultad conlleva realizarla.

En primer lugar, he buscado una historia para que sirva como referencia en la estimación

de las demás, esta historia no es ni la más fácil ni la más difícil: “Estado de la cuenta” con

5 puntos asignados.

En base a esta historia hemos estimado las demás, siendo la más difícil “Producto

cocinado” con 8 puntos, porque se debe reducir en 1 la cantidad del pedido

correspondiente al que pertenece y notificar al camarero que atendió el pedido

inmediatamente.

Cabe destacar que en la tabla siguiente se descompone cada historia de usuario en tareas.

Esta descomposición se debería realizar al sacar la historia de usuario del Backlog.

Además de reflejar las horas de trabajo realizadas con cada perfil.

ID Historia de usuario-Tareas Asignado a

1 Registro en el sistema 3 puntos de historia

1.1 Análisis y diseño de los requisitos Analista- 5 horas

1.2 Implementación en el controlador REST Programador- 5 horas

1.3 Diseño de la vista Programador - 2 hora

1.4 Implementación de la vista Programador- 2 horas

1.4 Pruebas Programador- 3 horas

2 Identificación en el sistema 5 puntos de historia

2.1 Análisis y diseño de los requisitos Analista - 3 horas

2.2 Estudio de Spring Security y token JWT Analista - 5 horas

2.3 Implementación en el controlador REST Programador - 6 horas

2.4 Diseño de la vista Programador - 3 horas

2.5 Implementación de la vista Programador - 2 horas



2.6 Pruebas Programador - 1 horas

3 Carta del restaurante 3 puntos de historia



3.3 Diseño de la vista Programador - 3 hora

3.4 Implementación de la vista Programador - 3 horas


4 Añadir producto al carrito 5 puntos de historia

4.1 Análisis y diseño de los requisitos Analista – 4 horas

4.2 Estudio de almacenamiento en Storage Analista – 3 horas

4.3 Diseño e implementación de la vista Programador – 10 horas

4.4 Pruebas Programador – 8 horas

5 Ver carrito 3 puntos de historia




6 Eliminar productos del carrito 1 punto de historia




7 Buscador de productos 5 puntos de historia


7.2 Implementación en el controlador REST Programador – 9 horas

7.3 Diseño de la vista Programador – 3 horas

7.4 Implementación de la vista Programador – 3 horas


8 Histórico de pedidos 2 puntos de historia






9 Estado de la cuenta 5 puntos de historia








10 Lista del cocinero 5 puntos de historia

10.1 Análisis y diseño de los requisitos Analista -5 horas

10.2 Estudio de Server Side Events Analista -5 horas

10.3 Implementación en el controlador REST Programador -10 horas

10.4 Diseño de la vista Programador -6 horas

10.5 Implementación de la vista Programador -4 horas

10.6 Pruebas Programador -11 horas

11 Producto cocinado 8 puntos de historia






12 Enlazar cliente 2 puntos de historia



12.3 Diseño de la vista Programador - 3 horas



13 Servir producto 5 puntos de historia






14 Cobrar cliente 3 puntos de historia






15 Bonificar con puntos 5 puntos de historia



15.1 Análisis y diseño de los requisitos Analista

15.2 Implementación en el controlador REST Programador

15.3 Diseño de la vista Programador

15.4 Implementación de la vista Programador

15.5 Pruebas Programador

16 Sistema de gestión 5 puntos de historia






17 Capturar productos Bidi 5 puntos de historia






Ilustración 13 Tareas y estimación de las historias

Priorización de las historias de usuario

La priorización proporciona una ordenación de las historias de usuario según su

importancia en la aplicación. Esto nos ayudará para determinar qué funcionalidades

podrán desarrollarse con los recursos y tiempo con los que se dispongan.

Para priorizar las historias de usuario hemos utilizado el sistema de priorización MoSCow

[11]. Se basa en agrupar las historias de usuarios en grupos llamados: Must, Should,

Should y Would Not. A continuación, se detallará cada grupo y las historias de usuario

que los forman.

En la siguiente tabla se agrupan las historias de usuario del grupo Must, que son los

requisitos que deben tener la solución, son los requisitos mínimos.



Must

ID Nombre Puntos de

historia

1 Registro en el sistema 3

2 Identificación en el

sistema

5

3 Carta del restaurante 3

4 Añadir producto al

carrito

5

9 Estado de la cuenta 5

10 Lista del cocinero 5

11 Producto cocinado 8

12 Enlazar cliente 2

13 Servir producto 5

14 Cobrar cliente 3

Ilustración 14 Prioridad Must

A continuación, se agrupan las historias de usuario del grupo Should, que son los

requisitos que se deberían implementar, pero no son obligatorios necesarios.

Should

I

D

Nombre Puntos de historia

5 Ver carrito 3

6 Eliminar productos del

carrito

1

8 Histórico de pedidos 2

Ilustración 15 Prioridad Should



Los del grupo Could son requisitos que podrían incluir la solución.

Could

ID Nombre Puntos de historia

7 Buscador de

productos

5

Ilustración 16 Prioridad Could

Finalmente, los del grupo Would not son requisitos son requisitos que en un futuro

podrían hacerse.

Would not

ID Nombre Puntos de

historia

15 Bonificar con puntos 5

16 Capturar productos con

código Bidi

5

17 Sistema de gestión 5

Ilustración 17 Prioridad Would not

Estimación de velocidad

Para calcular la duración de la planificación desde los puntos de historia, se utiliza el

concepto de velocidad, la velocidad es una medida para estimar el avance del equipo de

desarrollo.

Inicialmente se tiene en cuenta las historias de usuario del grupo Would Not a pesar de

que técnicamente los requisitos de este grupo no se tendrían en cuenta.

Por lo tanto, la suma de todos los puntos de historia es: 70 puntos de historia.

La fecha de comienzo del proyecto será el 29 de enero de 2018 y como fecha de

finalización el 3 de junio. En semanas de trabajo son 17 semanas.



La 1º semana del 29 de enero al 4 de febrero será dedicada para la instalación,

configuración y búsqueda de información de Spring Boot, MySql y ionic.

La 2º semana del 5 de febrero al 11 será dedicada para el análisis y diseño de la interfaz

de usuario, arquitectura de la aplicación y diseño de la base de datos.

Por último, las 2 últimas semanas del 21 de mayo al 3 de junio se usará para terminar la

memoria del TFG relacionada con guía de usuario y conclusiones.

Por lo cual de las 17 semanas iniciales estimadas ahora nos quedarían 14 semanas para

desarrollar las historias de usuario.

He estimado que la duración de cada Sprint es de 2 semanas. Por lo cual realizando la

división 14 semanas / 2 semanas por sprint tenemos 7 Sprints.

Velocidad: 70 / 7 = 10 puntos de historia por sprint.

Con los datos anteriores hice la siguiente planificación, ajustando la semana previa a

realizar las historias de usuario, Sprint 0. Además de reflejar las 2 últimas semanas para

dedicarlas a la memoria del TFG, Sprint 8.

Nº de

Sprint

Fecha Inicio Fecha Fin Puntos de

historia

Velocidad Historias de

usuario

0 29 de enero 4 de febrero Instalación SW

1 12 de febrero 25 de febrero 10 100% 1,2,12

2 26 de febrero 11 de marzo 10 100% 4,9

3 12 de marzo 25 de marzo 8 80% 3,10

4 26 de marzo 8 de abril 11 110% 11,14

5 9 de abril 22 de abril 9 90% 13,5,6

6 23 de abril 6 de mayo 12 120% 8,7,15

7 7 de mayo 20 de mayo 10 100% 16,17

8 21 de mayo 3 de junio Memoria TFG Ilustración 18 Planificación 1 de los Sprints



Como se aprecia en la tabla anterior, la primera historia de usuario se empieza a hacer el

12 de febrero y la última el 3 de junio. También se asocia una velocidad a cada Sprint,

concretamente hay varias superiores al 100%, el Sprint 4 y 6. Esto quiere decir que en

esas semanas hay que trabajar más horas que las planificadas para poder alcanzar el

objetivo planificado de terminar esas historias de usuario.

Evolución de las estimaciones

El Sprint 3 y 5, como sus velocidades son por debajo del 100% reflejan que habrá más

tiempo para terminar las historias de usuario asignadas.

Sin embargo, al finalizar el Sprint 2 el 11 de marzo, en la reunión con el cliente y

enseñarles los avances no se terminó completamente la historia de usuario con el id 9

“estado de la cuenta” y esto hizo que se replantearan las tareas a realizar en el proyecto.

Para ajustar el trabajo restante, se acordó con el cliente adaptar el alcance del proyecto, lo

que permitió reducir la velocidad de trabajo a un nivel razonable, por ello se analizó la

velocidad del 1er Sprint que fue de 10 y la velocidad del 2º Sprint que fue 7, con estas dos

velocidades la media es 8. Por tanto, la nueva velocidad es 8.

Adoptando esta velocidad de 8, las historias de usuario de la prioridad Would not no se

realizarían, es decir, no se incluirían en la siguiente planificación.

Historias de usuario de la categoría Would Not descartadas:

ID 15: Bonificar con puntos con 5 puntos de historia.

ID 16: Capturar productos con código Bidi con 5 puntos de historia.

ID 17: Sistema de gestión con 5 puntos de historia.



Quedando finalmente la siguiente tabla de planificación:

Nº de

Sprint

Fecha Inicio Fecha Fin Puntos de

historia

Velocidad Historias de

usuario

0 29 de enero 4 de febrero Instalación SW

1 12 de febrero 25 de febrero 10 100% 1,2,12

2 26 de febrero 11 de marzo 10 100% 4,9

3 12 de marzo 25 de marzo 8 100% 9,10

4 26 de marzo 8 de abril 8 100% 11

5 9 de abril 22 de abril 8 100% 3,13

6 23 de abril 6 de mayo 7 75% 14,5,6,

7 7 de mayo 20 de mayo 7 88% 7,8

8 21 de mayo 3 de junio Memoria TFG Ilustración 19 Planificación 2 de los Sprints

Adoptando estos cambios en la planificación inicial antes descrita, en el Sprint 3 se

realiza 3 puntos de historia que faltaban de la historia con el id 9 además de la historia

con el id 10.

Con velocidades menores de 100% se proporciona un tiempo de trabajo más adecuado,

permitiendo así continuar con esta planificación.

Ilustración 20 Gráfico Burn Down

0

10

20

30

40

50

60

70

80

1 2 3 4 5 6 7 8

Planificación 2 Planificación 1

Punto

s de h

istoria

Iteraciones



Como vemos en el gráfico anterior con la planificación 1 la inclinación es más abrupta

que en la planificación 2 que es más suave, menos inclinada. Esto es debido a la

diferencia del porcentaje de la velocidad, siendo en la planificación 1 más estable y no

pasando nunca del 100%.

2.6. Estudio de viabilidad

En este apartado se calculará el coste económico de llevar a cabo el proyecto. Este

cálculo se obtendrá en base del coste relacionado con el software necesario, el hardware y

el coste económico del personal. El coste total será incrementado un 15% para tener un

margen de beneficio.

A continuación, se muestra el coste de software requerido para el proyecto, la mayoría es

gratuito y con un tiempo de uso de 5 meses.

Programas Precio Tiempo de uso Precio de uso

Netbeans 8.2 0€ 5 meses 0€

Microsoft Office 365

Personal

7€/mes 5 meses 35€

Visual Studio Code 1.23 0€ 5 meses 0€

Postman 5.5.2 0€ 5 meses 0€

Visual Paradigm

Community Edition

0€ 5 meses 0€

MAMP 0€ 5 meses 0€

TOTAL: 35€ Ilustración 21 Coste Herramientas Software

Seguidamente se muestra el coste del hardware, el cálculo se ha realizado estimando la

vida útil del componente y estimando el tiempo de uso. A partir de estas estimaciones se

ha concluido un precio de uso.

Ilustración 22 Coste Herramientas Hardware

Hardware Precio Vida estimada Precio de uso

MacBook Pro

Retina 13"

1400€ 10 años 80€

Huawei p8 lite 200€ 4 años 70€

TOTAL: 150€



El tercer coste referente al cálculo del salario, se ha llevado a cabo tomando como

referencia el salario junior como programador y analista según tablas salariales del grupo

Ilunion [12].

El total de horas de trabajo ha sido calculado de la siguiente forma, los días de trabajo

realizados con el rol correspondiente en este caso Analista y programador multiplicado

por las horas al día de trabajo en este caso 5 horas.

Y finalmente las horas de trabajo multiplicadas por el salario por hora de cada rol nos da

como resultado el coste total por cada uno.

Tabla 1 Cálculo del salario

Ya calculados los tres costes anteriores, se procede a la suma de ellos que nos da como

resultado 4130,00€. Este resultado se incrementa un 15% de beneficio obteniendo el

precio total de llevar a cabo la aplicación.

Costes Precio

Coste hardware 150,00€

Coste software 35,00€

Coste personal 2773,14€

Coste total 2958,14€

Beneficio- 15% del total 443,7€

Total: 3401,8€

Tabla 2 Coste del proyecto

Cargo Salario

Mensual

Salario

por hora

Horas

al día

Total

de

horas

Precio

Programador 1200,08€ 7,60€ 5 269 2044,4€

Analista 1406,90€ 8,78€ 5 83 728,74€

Total 2773,14€



2.7. Modelo de dominio

A continuación, a partir de los conceptos anteriores de análisis se intenta hacer una

aproximación a la solución, donde podemos intuir las clases conceptuales que se crearán

en el proyecto.

La clase Usuario hace referencia tanto a clientes, camarero y cocineros. La clase usuario

tendrá un atributo que identifique qué rol de los tres tiene en el sistema.

La relación de Pedido_detalle a Producto es de 1 a 1, porque cada Pedido tiene una

referencia a un Pedido_detalle que en éste tendría como atributo la cantidad y notas del

producto, además de tener como atributo una lista de Producto.

A partir de este modelo se centrará el estudio del diseño donde posiblemente habrá

cambio con respecto a esta estructura.

Ilustración 23 Modelo del dominio



Como dice Taylor el diseño es "... proceso de aplicar distintas técnicas y principios para

definir un dispositivo, proceso o sistema con suficientes detalles como para permitir su

realización física" [13] además el diseño construye el sistema desde el punto de vista del

dominio de la solución, es por ello que previamente se ha realizado el modelo del

dominio.

3.1. Diagrama de Entidad-Relación

La base de datos relacional para la aplicación es MySql7, usando Hibernate 8 y JPA 9para

el mapeado objeto-relacional. En la siguiente imagen se muestra más detalladamente.

Son muchas las ventajas de usar mapeado objeto-relacional una de ellas es no encontrar

código SQL empotrado o el mapeado automático de estructuras de datos complejas,

podemos encontrar más información en [14].

Cuando la aplicación de Spring compile y se ejecute, las clases con las anotaciones

respectivas que requieran persistencia, se crearán automáticamente en la base de datos.

7 https://www.mysql.com/ 8 http://hibernate.org/ 9 https://es.wikipedia.org/wiki/Java_Persistence_API

BD relacional

Aplicación Java

ORM

JPA

Hibernate

JDBC

MySql

Ilustración 24 Esquema comunicación con BD



Además, cuando se realice inserciones, modificaciones y borrados se realizará sin usar

código SQL.

Ilustración 25 Diagrama de BD

En la siguiente imagen se puede observar también las tablas desde la web de mysql, que

ha creado automáticamente JPA.

Como podemos observar las tablas están en 3ª forma normal, porque están en 2FN (los

atributos no clave depende de toda la clave principal) y no existe ninguna dependencia

transitiva entre los atributos que no son clave.



Ilustración 26 Tablas creadas por JPA

3.2. Diagrama de clases

A continuación, se estudiará el diagrama de clases de la aplicación, donde se podrá ver la

estructura del sistema compuesta en paquetes y clases, con sus atributos, operaciones o

métodos y las relaciones.

Cabe destacar que se estudiará el diagrama de clases del cliente y el diagrama de clases

del servidor por separado. Debido a que son aplicaciones que se ejecutan en equipos

distintos y con lenguajes diferentes.

Aplicación Cliente

En el lado del cliente dado que hemos usado el Framework Ionic que está basado en

AngularJS es importante explicar el flujo que va a realizar la aplicación.

AngularJS usa el patrón de diseño MVVM (Modelo-Vista-Vista-Modelo) que es un

refinamiento del patrón MVC. La vista está totalmente aislada del modelo, sin embargo,

mediante eventos se comunica con el ViewModel que este si se comunica con el modelo.

Por tanto, si se modifica un dato en la vista, éste se modifica en el ViewModel y

viceversa. [15]



Ilustración 27 Esquema MVVM https://goo.gl/C2nRiC

Cabe destacar que se ha separado en 2 los diagramas de clases de la aplicación

atendiendo a la funcionalidad de los diferentes roles implicados: por un lado, está el

cliente y por otro está el diagrama del personal que incluye al camarero y al cocinero.

Esta separación se ha hecho para facilitar la claridad de los diagramas.

En los diagramas se ha usado nomenclatura de colores, relacionando la vista y el

controlador del mismo color, indicando también qué servicio usa cada controlador.



Ilustración 28 Diagrama de clases Cliente



A continuación, se muestra el diagrama de clases referente al rol de cocinero y camarero.

Tienen un servicio denominado Servicio, que proporciona métodos para llevar a cabo la

comunicación con cocina-camarero-cliente.

El servicio Auth está relacionado con la mayoría de los controladores porque utiliza

funciones como Logout() que permite al cliente cerrar la sesión.

Además, Servicio, se comunica con el servidor y los resultados los guarda en listas, para

proporcionar esa información a los controladores. Los controladores suministran la

información a las vistas para mostrar los datos.

Ilustración 29 Diagrama de clases lado del cliente, rol de camarero y cocinero



Aplicación Servidor

La estructura del servidor sigue el esquema que nos proporciona Spring Boot, se han

utilizado paquetes para agrupar las diferentes clases.

El paquete servidor contiene la clase que inicializa la aplicación, y ejecuta el paquete de

recurso.

El paquete de recursos contiene las clases que llevan a cabo la aplicación RESTFUL que

a su vez hacen uso de los DAOs 10 para el acceso a la base de datos.

El paquete de DAOs hace uso del paquete de excepciones para controlar si hay algún

error.

Cuando es necesario devolver al cliente información encapsulada en DTOs 11 se hace uso

del paquete de dicho nombre.

Finalmente, el paquete Security proporciona seguridad a la API, restringiendo urls a

usuarios con autorización.

Ilustración 30 Diagrama de clases servidor

10 https://es.wikipedia.org/wiki/Data_Access_Objects 11 https://es.wikipedia.org/wiki/Objeto_de_transferencia_de_datos



3.3. Diagramas de secuencia

A continuación, se muestra los diagramas de secuencia [16] más representativos del

sistema, mediante ellos se puede observar la interacción de objetos a través del tiempo.

Debido a que realmente tenemos dos aplicaciones, la del cliente y el servidor que

proporciona la API, tenemos que hacer dos diagramas por cada historia de usuario.

Seguridad

Cada petición a la API REST va acompañada del token del usuario. Este token es enviado

en el encabezado http Authorization cada vez que la aplicación hace una solicitud HTTP.

Inicialmente JWTFilter intercepta la petición y capta el token, solicitando a

TokenProvider si es válido el token. Este extrae la información de nick del token y

mediante UsuarioDAO se accede a la BD y se comprueba si el usuario existe en el

sistema.

Finalmente, si es válido se permite acceder a la petición del controlador de recurso o si es

inválido se devuelve un código de error.

Ilustración 31 Diagrama de secuencia seguridad



Identificación del usuario (Login)

Inicialmente es imprescindible hacer un login válido para poder acceder a las

funcionalidades del sistema.

El usuario solicita al controlador de login la vista y este se la proporciona. Una vez que el

usuario rellene los datos, los envía al controlador de login y este se los manda al servicio

que se encarga de la autentificación.

El servicio envía los datos a la API a la espera de una respuesta. Si la respuesta es válida,

se devuelve el token [17] al usuario y se redirige a la ventana de home.

El token es una secuencia de cadena de caracteres, que en nuestra aplicación tiene un

significado coherente. Está basado en el estándar JWT, compuesto en tres partes:

encabezado, carga útil y firma.

El token se enviará al servidor para cada petición que requiera validación, para

comprobar si el cliente está identificado en el sistema y tiene los permisos requeridos.

Ilustración 32 Diagrama de secuencia login



En el servidor, se recibe los datos de login en el controlador de la API, y este hace uso del

DAO de usuarios para que este acceda a la base de datos para comprobar que el usuario

es válido.

Finalmente, si el usuario es válido se devuelve el token como hemos visto anteriormente,

y si no se devuelve un error.

Ilustración 33 Diagrama de secuencia login servidor



Registro de usuario

Inicialmente, el usuario solicita al controlador de login que le muestre la vista de login y

este la recibe. Seguidamente, cuando pulse en el botón de registro, el controlador de login

recibe la solicitud y le muestra al usuario el formulario de registro. Una vez que el

usuario rellene los datos lo envía al controlador de (Signup) y este los envía al servicio

llamado auth.ts que se comunica con la API.

El servidor devuelve una respuesta de éxito o fracaso y se muestra al cliente la respectiva

vista.

Ilustración 34 Diagrama de secuencia registro cliente

El registro por parte del servidor comienza recibiendo del cliente los datos mediante la

API, seguidamente utiliza el DAO de usuarios para comprobar que no existe ningún

usuario con dicho nick, y devuelve el token si es válido y vacío si no lo es.



Ilustración 35 Diagrama de secuencia registro servidor

Realizar Pedido

El usuario solicita ver los productos de una categoría al controlador de por_categoria y

este le devuelve la lista de productos. Cuando el usuario selecciona un producto, se le

proporciona la vista detallada del producto.

Una vez que el usuario selecciona agregar al carrito se envía el producto al controlador de

producto para añadirlo a la lista. Este proceso de ir añadiendo productos al carrito se

repite hasta que finalice la compra.

Cuando el usuario pulsa en ver carrito se envía la solicitud al controlador de

productosCarrito para mostrarle la vista, a continuación, cuando pulse en realizar pedido,

el controlador envía al servicio los productos a pedir.



El servicio es el encargado de comunicarse con la API y enviarle el pedido a la espera de

una respuesta.

Ilustración 36 Diagrama de secuencia realizar pedido

El servidor recibe del cliente el pedido, después utiliza el DAO de pedidos para insertarlo

en la base de datos y envía una respuesta al cliente según si hubo o no éxito.



Ilustración 37 Diagrama de secuencia realizar pedido en servidor

Pagar la cuenta

El camarero solicita al controlador de cobrar la vista y este se la devuelve. Después envía

la mesa y el cliente al servicio para que se comunique con la API y le envía los datos.

Según la respuesta de la API se muestra un mensaje de éxito o error.



Ilustración 38 Diagrama de secuencia pagar cliente cliente

En el servidor se recibe los datos y usa el DAO de pedido para insertar en la base de datos el

nuevo pedido y se devuelve un mensaje según si hubo éxito o no.

Ilustración 39 Diagrama de secuencia pagar la cuenta servidor



3.4. Diseño de la interfaz

En este apartado mostraremos en primer lugar un diagrama de estados de la aplicación

cliente, para observar los distintos estados y transiciones de la aplicación cliente [18].

Después se mostrará los bocetos de las interfaces cliente, cocinero y camarero.

Diagrama de estados de la aplicación cliente

El siguiente diagrama muestra el flujo de ejecución del cliente para facilitar su

comprensión. Cada estado tiene un identificador, para ser usado en el siguiente apartado

y ver que vista corresponde con cada estado.

Inicialmente el usuario se le muestra la ventana de login, si el login es incorrecto se le

vuelve a mostrar. También si no tiene cuenta, accede a la ventana de registro para

registrarse y después hacer el login.

Cuando el login es válido se redirige al menú de navegación, donde tiene acceso a varias

opciones.

Cuando accede a carta se le muestra las categorías de los productos, al seleccionar un

producto accede al detalle del producto seleccionado y lo puede agregar al carrito y

vuelve a la carta para poder seguir añadiendo más productos.

Además, puede hacer uso del buscador para acceder a la ficha del producto directamente.

Cuando acceda al carrito puede realizar el pedido. Finalmente, cuando acceda a cuenta

puede solicitar que le cobre la comanda para terminar la estancia en el restaurante.



Ilustración 40 Diagrama de estados del cliente

Interfaces de identificación

A continuación, se muestra la interfaz de identificación y crear cuenta en el sistema, que

corresponden con el diagrama de estados anterior: ID1, ID2, ID3.



Ilustración 41 Interfaz de identificación

Este primer boceto, representa las ventanas de identificación y registro de la cuenta de

usuario. Lo primero que encontraría el usuario sería la venta de identificación, con dos

campos de texto para introducir su nick y su contraseña. Si los datos introducidos son

válidos, se accede al sistema con el rol correspondiente a la cuenta (cliente, camarero o

cocinero) y se mostrará el menú de navegación, correspondiente al ID 3 del diagrama de

estados.

La interfaz de registro contiene varios campos a rellenar por el usuario, estos son:

nombre, correo, nick y contraseña. Si el usuario pulsa sobre el botón de registro y estos

campos no son válidos el texto erróneo se marca en rojo y aparece un símbolo de error

como se indica en el boceto.



Interfaces del cliente

El cliente es el rol de usuario con más tipo de interfaces, hace uso de navegar entre los

productos, ver los pedidos que ha realizado o hacer uso del buscador. A continuación, se

detalla cada una de las interfaces.

Cuenta del cliente, ID 4

Ilustración 42 Interfaz cuenta

En esta primera interfaz del cliente, se muestra la estructura a seguir en las demás

interfaces de cliente.

Todas ellas estarán compuestas de dos botones con sus respectivos iconos en la parte

superior derecha para desconectar de la aplicación y acceder al carrito de productos.

En la parte inferior se ha pensado en hacer una barra de navegación entre las

funcionalidades principales que puede hacer el cliente que son Cuenta, Carta, Historial y

Buscar.



La idea de esta interfaz es mostrar los pedidos que está realizando el cliente que están

pendientes de pago. Cada pedido mostrará la hora en la que se pidió y los productos que

compone el pedido. Además de mostrar el total a pagar que lleva hasta ese momento con

esos pedidos.

Finalmente, un botón Pedir Cuenta que llamará al camarero para que se acerque a la mesa

y le cobre esos pedidos.

Carta de productos, ID 10, ID 12

Ilustración 43 Interfaz categoría

Dado que los productos están agrupados en categorías, la interfaz de Carta mostrará una

lista de todas las categorías permitiendo la navegabilidad entre ellas.

Una vez accedido a una categoría, la interfaz de productos por categoría mostrará todos

los productos de esa categoría en forma de lista. Cada elemento de esta lista contiene una

imagen del producto, el título y su precio.



Una vez que acceda al producto se mostrará la interfaz de producto que detalla toda su

información. Contiene el título del producto, una imagen, descripción, precio,

ingredientes, seleccionar la cantidad y añadir notas introduciendo un texto. Finalmente,

un botón para añadirlo al carrito.

Ilustración 44 Interfaz producto



Historial de pedidos, ID 8

Ilustración 45 Interfaz historial

Esta interfaz es muy sencilla, mostrará una lista de los pedidos realizados por el cliente

que estén en estado de pagado.

Cada elemento de la lista contendrá la fecha en que se realizó y una descripción,

conteniendo los productos que se pidieron. Es meramente informativa.



Buscar producto, ID 6

Ilustración 46 Interfaz buscar

Esta es la interfaz del buscador, en la parte superior se deberá introducir el texto a buscar,

y en la lista de abajo se mostrará los productos que coincidan en su nombre con el texto

introducido. Pudiendo pulsar en uno de ellos para redirigirle a la interfaz de detalle del

producto.



Detalle del pedido, ID 7

Ilustración 47 Interfaz carrito

Esta interfaz se mostraría cuando el usuario pulse sobre el icono de arriba a la derecha

llamado carrito. Este icono estaría en todas las interfaces de cliente como se ha

comentado anteriormente.

El objetivo sería mostrar los productos en forma de lista, mostrando su nombre, notas y

precio. Cada producto tendría un botón para eliminarlo del carrito. En la parte de abajo

un botón para realizar el pedido.



Aplicación cliente: vista de camarero

El camarero cuando hace login con éxito en la aplicación, accede al sistema.

El camarero no tiene el botón de carrito como le cliente porque carece de sentido, si tiene

el botón de cerrar sesión en la parte superior derecha.

Ilustración 48 Interfaces enlazar y cobrar

En la interfaz de enlazar, aparecería un buscador para buscar al cliente por su

identificador ("nick"), también aparecería las mesas del restaurante y seleccionas la mesa

en la que está sentado el cliente.

Finalmente, un botón para realizar el enlace del cliente con la mesa.

En la interfaz de cobrar, el camarero seleccionaría la mesa del cliente al que quiere

cobrar, y se muestra en forma de lista el detalle de todos los pedidos que están en



pendiente de pago por parte del cliente. Una vez realizado el pago en metálico por parte

del cliente al camarero, éste pulsaría el botón “Cobrar”, y los pedidos se ponen en estado

de cobrado.

Aplicación cliente: vista de cocinero

El cocinero tiene una interfaz muy sencilla, no tiene menús de navegación, solo la tabla

con los pedidos entrantes y el botón de cerrar sesión.

Ilustración 49 Interfaz cocinero

La tabla muestra los productos que componen el pedido, el orden es con prioridad al más

antiguo.

Cada producto es un botón que muestra el nombre del producto, la cantidad y las notas.

Por cada click que haga el cocinero en el producto la cantidad se decrementará en uno

hasta llegar a cero y desaparecerá el producto.



En este punto se explicará la arquitectura de la aplicación y los componentes más

relevantes que se han usado para llevar a cabo la aplicación ayudándonos de fragmentos

de código.

4.1. Arquitectura de la aplicación

Nuestra aplicación usa una arquitectura cliente-servidor, el servidor proporciona recursos

y estos son solicitados por el cliente. Es decir, el cliente realiza peticiones y estas son

respondidas por el servidor.

Ilustración 50 Diagrama cliente-servidor

Nuestro servidor para atender las peticiones del cliente, proporciona una API [19].

Una API REST se puede definir como una interfaz entre sistemas que utilizan el

protocolo HTTP [20] para obtener datos o generar operaciones sobre esos datos en

distintos formatos como JSON [21] o XML [22].

Por lo tanto, siguiendo esta arquitectura, la siguiente imagen muestra cómo estaría

organizada la aplicación en base a los frameworks y tecnologías usados.



Ilustración 51 Diagrama arquitectónico del sistema

En el lado del cliente, se muestra como angular proporciona a Ionic está basado en

Angular y como Ionic hace uso de HTML, CSS y JS. Después Ionic hace uso de Apache

Cordova para generar las aplicaciones móviles. Éstas pueden ser Android, iOS o

Windows Phone.

Con la aplicación móvil generada previamente con Apache Cordova12, mediante

peticiones POST/GET se comunica con la REST API proporcionada por el servidor.

Las peticiones recibidas en el servidor, hacen uso de clases de Java, que son del modelo

de negocio, y éstas a su vez si necesitan acceder a la base de datos lo hacen mediante

JPA.

12 https://cordova.apache.org/



4.2. Detalles sobre la implementación

A continuación, se describirá una lista de las tecnologías empleadas durante la

implementación:

Ionic v3.2

AngularJS v1.6.8

HTML 5

CSS 3

Apache Cordova

GIT 2.6.2

Spring Boot 2.0

Postman 5.5.2

Aplicación Cliente

Git Workflow

Usando Ionic se ha empleado el sistema control de versiones que proporciona, para ir

guardando los avances del proyecto. Está basado en Git, sobre todo se ha usado commits,

push y pull. [23]

En la siguiente imagen se muestra un histórico de commits.

Ilustración 52 Ionic Workflow https://goo.gl/JoR6aE



Estructura Ionic

Al crear un proyecto con Ionic se crea una carpeta con el nombre del proyecto y dentro

de ella una estructura de archivos y carpetas. Ahora veremos los aspectos más relevantes

que tiene el proyecto en base a su estructura.

En la carpeta src están todos los archivos con el contenido de

nuestra aplicación. Src contiene la carpeta de app que es el

módulo principal, assets, pages donde se encontrarán nuestras

páginas y su respectivo controlador, pipes para procesar

información, provider que contiene nuestros servicios y theme

que suministra estilos. [24]

En las siguientes imágenes se muestra un ejemplo de una página concretamente la de

Enlazar, está formada por el controlador Enlazar.ts y la vista Enlazar.html. Se puede

observar la declaración y uso de funciones y cómo por ejemplo cuando una variable es

modificada en la vista, simultáneamente se modifica en el controlador.

Ilustración 53 Estructura ionic



Ilustración 54 Vista enlazar.html

Ilustración 55 Controlador enlazar.ts



Generar aplicación para varias plataformas

En este apartado veremos cómo se genera la aplicación [25] para Android o IOS.

Mediante el CLI 13de IONIC, escribimos los siguientes comandos para agregar la

plataforma Android o IOS al proyecto:

ionic cordova platform add android

ionic cordova platform add ios

Ahora para generar el archivo apk se escribe los siguientes comandos:

ionic build android --release

ionic build ios --release

El archivo apk14 se encuentra en Plataformas \ Android \ Build \ Outputs \ apk

Ilustración 56 Generar app en distintas plataformas

13 https://ionicframework.com/docs/cli/ 14 https://es.wikipedia.org/wiki/APK_(formato)



Finalmente, para instalar el archivo .apk hay que seguir una serie de pasos [26]:

Dar permiso al dispositivo móvil para poder instalar aplicaciones que no

provengan de App Store. Se debe acceder Ajustes-Seguridad y habilitar la opción

de “Orígenes desconocidos”.

Conectar el dispositivo móvil mediante USB al ordenador y elegir en el

dispositivo móvil la opción de “Transferir archivos”.

Copiar el archivo desde el ordenador al dispositivo móvil.

Finalmente extraer de forma segura el móvil y acceder desde el móvil a la carpeta

donde ha sido copiada la aplicación y ejecutarla para instalarla.

Ejemplo de un servicio

Los servicios de la aplicación cliente se encargan de comunicarse con el servidor

mediante peticiones asíncronas. Además, estos guardan estructuras de datos para guardar

información necesaria. Como estructura de datos se ha usado listas debido al uso que se

le han dado.

En la siguiente función se puede observar una petición GET y el resultado se guarda en

una lista llamada pedidos_cocina. Todo ello dentro de una promesa, para indicar que el

objeto promesa contendrá un valor en el futuro que nos interesa y no podemos dejar que

bloqueen la función.

Ilustración 57 Ejemplo petición get



Local Storage

Local Storage [27] nos permite almacenar información en el navegador, aunque se cierre

el navegador, la información permanece. Unas de las características destacadas es que

permite almacenar entre 5MB y 10MB, la información está almacenada en el dispositivo

del cliente y no es enviada en cada petición al servidor.

Se ha empleado Local Storage para guardar en la memoria del dispositivo el carrito del

cliente, guardando en formato JSON el detalle de todos los productos, cantidad, notas etc.

Ilustración 58 Local Storage

En la imagen anterior se puede observar que, con la aplicación del cliente en ejecución en

localhost y abierta sobre el navegador Chrome, se usa la memoria para guardar en

formato (llave,valor) la información. En este caso la llave es 'items' y el valor es la

información en formato JSON que contiene la información del carrito.

Aplicación Servidor

Sistema gestor de versiones GIT

También se ha utilizado el sistema gestor de versiones GIT para ir guardando el proyecto

y sea más fácil recuperar versiones anteriores.



Ilustración 59 GIT servidor

Mapeo ORM de clases con anotaciones JPA

Dado que el mapeado de una clase a una tabla no es automático, tenemos que

proporcionar a JPA una mínima información, mediante anotaciones en código Java. [28]

En la siguiente imagen se puede observar un ejemplo del uso de anotaciones en la clase

Categoría.

Con la anotación @Entity indicamos que la clase Categoría es una clase persistente, que

en JPA se denomina entidad.

Con la anotación @Id marcamos el atributo que hace de clave primaria de la tabla, en

este caso es autogenerado, marcado con la etiqueta @GeneratedValue.



Ilustración 60 Etiquetas JPA

Acceso a la base de datos con DAOs

Cuando la capa de lógica de negocio quiera interactuar con la base de datos, lo hará a

través del DAO de su clase respectiva.

Ilustración 61 Pedido DAO

En cada DAO está inyectado el EntityManager. El EntityManager está asociado con el

contexto de persistencia, el cual será utilizado para administrarlas entidades y las

transacciones. [29]

Con EntityManager podemos hacer operaciones como:

Búsquedas: find()

Insertar: persist()



Actualizar: merge()

Borrar: remove()

Recursos API

El servidor proporciona una API REST con distintos servicios para atender las peticiones

del cliente.

Por ejemplo, en la siguiente imagen se puede ver el servicio de tipo GET para realizar las

búsquedas de productos.

En caso de no encontrar resultado se devuelve el objeto vacío.



Tabla de end-points REST

A continuación, se observa la información relevante de los end-points REST 15de la

aplicación:

Tipo Detalle URL RequestBody Devuelve Devuelve

en caso de

error

GET Suscribir

camarero al

emitter

/tucomanda/avisoscomanda/{nickc} null Emitter null

POST Realizar

pedido

/tucomanda/pedidos/ List<ProductoInfo> Cod: 200 Cod:404

GET Comprueba

enlace

tucomanda/enlace/{nick} null 200 404

GET Pedidos a

cobrar

/tucomanda/pedidos/cobro/{mesa} null Pedido null

POST Cobrar

pedidos

/tucomanda/pedidos/cobro Pedidos 200 404

GET Pedidos a

cocinar

/tucomanda/pedidos Null 200 404

POST Producto

cocinado

/tucomanda/producto Producto 200 404

GET Pedidos a

pagar cliente

/tucomanda/pedidos/actuales Null 200 404

GET Historial /tucomanda/pedidos/historial Null 200 404

GET Solicita

cobro

/tucomanda/pedidos/aviso Null 200 404

GET Buscar

producto

/tucomanda/productos/buscar/{patron} null 200 404

POST Buscar

usuario

/tucomanda/usuarios/buscar/{patron} null Usuario null

GET Cargar mesas /tucomanda/mesas Null Mesas null

POST Crear enlace /tucomanda/enlace Enlace 200 404

POST Identificarse /login Usuario Token null

POST Crear cuenta /signup Usuario Token Null

GET Productos

por tipo

/productos/por_tipo/{categoria} Null Productos null

GET Cargar

categorías

/categorias Null Categorías null

Ilustración 62 Tabla end-points

15 https://smartbear.com/learn/performance-monitoring/api-endpoints/



Seguridad token JWT

Con la utilización del token en forma jwt, podemos extraer del token el Nick del cliente.

Esto nos proporciona en cada petición la posibilidad de comprobar si tiene permiso de

acceso, proporcionando seguridad a la aplicación.

JWT (Json Web Token) es un estándar para crear tokens de acceso. [30]. El JWT está

formado por 3 partes, encabezado, carga útil y una firma. Para crear el token, los datos

necesarios para crear el token son: la palabra secreta proporcionada desde el archivo

applycation.yml, el tiempo que va a ser válido el token y para la firma el algoritmo

(HMAC con SHA-512)16.

Ilustración 63 Creación de token

Además, se filtran las solicitudes entrantes usando el token creado y Spring security. En

la siguiente imagen se puede observar cómo se comprueba la validación del token y si el

usuario existe en la base de datos, además se devuelve una serie de excepciones cuando

falla la validación.

16 https://es.wikipedia.org/wiki/HMAC



Ilustración 64 Comprobación token en cada petición

Server Side Events (SSEs)

Consiste en que el cliente se suscribe a una 'transmisión' desde el servidor y el servidor

enviará mensajes 'eventos' al cliente, hasta que se cierre la conexión.

SSEs se envían a través de HTTP tradicional. Significa que no requieren un protocolo

especial o implementación de servidor para funcionar [31].

El uso de enviar eventos del servidor al cliente se ha usado para las notificaciones al

camarero de servir un producto o para notificarle de cobrar una mesa.

Ilustración 65 Server Side Events



Se ha comprobado el correcto funcionamiento de las historias de usuario, después de cada

sprint. Las historias de usuario fueron validadas con el usuario utilizando los criterios de

aceptación expuestos en la tabla del apartado 2.4.

Surgió un problema a la finalización del Sprint 2, la historia de usuario con el id 9

“estado de la cuenta” no fue realizada completamente. Este hecho se solventó con la

reducción de la velocidad de scrum, de manera que en el siguiente sprint se finalizó.

Además, para comprobar el funcionamiento de la interfaz REST se ha utilizado un

software llamado “Postman”17. Enviando peticiones GET o POST al servidor con los

datos requeridos analizando los resultados y comprobando si la respuesta del servidor era

correcta.

Finalmente, surgieron ideas nuevas en las que se añadirían en futuras ampliaciones como

que el cliente pueda pagar desde la aplicación con la tarjeta de crédito directamente. Estas

ideas son expuestas en el apartado 6.1 llamado “Trabajos futuros”.

17 https://www.getpostman.com/



En la actualidad podemos observar que uno de los motivos del desarrollo tecnológico es

el de dar servicios a la sociedad. Automatizar procesos o realizar cálculos proporciona a

la persona ahorro de tiempo, eficiencia y fiabilidad.

Además, año tras año, el uso de la tecnología para realizar tareas habituales es más

común y esto abre la posibilidad de un avance tecnológico y nuevas aplicaciones

orientadas a dar servicio a las personas.

Es por ello que esta aplicación proporciona una automatización del servicio que da un

restaurante a sus clientes aumentando mucho la eficiencia en el servicio.

Esta aplicación hace un tiempo hubiera sido inviable, debido a que las personas carecían

de un dispositivo móvil con conexión a internet, pero hoy en día la mayoría de las

personas dispone de móvil, y es extraño que no tenga tarifa de datos en el mismo por lo

que la idea de ir a un restaurante y pedir la carta desde tu propio dispositivo no resultaría

tan extraño.

En lo referente al desarrollo del proyecto, podemos concluir que se han alcanzado con

éxito los objetivos inicialmente propuestos:

Se ha desarrollado un estudio en el contexto donde se quiere instalar la aplicación,

analizando su funcionamiento y extrayendo sus ventajas e inconvenientes.

Además de una reunión con el cliente para estudiar sus necesidades y proponerle

las soluciones más adaptadas a las mismas.

Se ha diseñado un sistema informático, definiendo la funcionalidad del sistema

mediante historias de usuario y se ha estudiado la viabilidad temporal y

económica del desarrollo. Siguiendo una metodología ágil, SCRUM.

Se han realizado implementaciones utilizando tecnologías actuales como Angular

JS, CSS, HTML5 (Ionic) en la aplicación del cliente; y Spring para la aplicación

del servidor.

Y, por último, se han probado los resultados obtenidos siguiendo los criterios de

satisfacción junto con el cliente, adaptándose la planificación a los imprevistos

surgidos.



Desde un punto de vista personal, al realizar este proyecto he podido ser consciente de la

importancia del trabajo al que me dedicaré, debido a que muchos negocios o empresas se

basan en software y sus beneficios económicos pueden variar mucho dependiendo de la

calidad de dicho software.

Al inicio del desarrollo del proyecto me enfrenté a una tecnología nueva para mí como es

Ionic, no obstante, a las dificultades que encontré fui resolviéndolas a través de foros

especializados en esta tecnología. Después, con el conocimiento adquirido pude avanzar

con mayor eficacia en el proyecto.

Desde un punto de vista técnico, el uso de JPA para crear las tablas en la base de datos de

forma automática me ha servido para conocer mejor su funcionamiento y las utilidades en

lo que lo puedo emplear. Otro de los aspectos que he aprendido es el de los beneficios

que tiene las aplicaciones híbridas porque proporciona una aplicación multiplataforma,

que puede usar funcionalidades nativas del móvil y con una interfaz muy conseguida.

También he valorado mucho el uso de sistema control de versiones GIT porque hubo

veces que tuve que regresar a una versión del proyecto anterior para solventar errores y el

empleo de esta tecnología me facilitó mucho la tarea.

Creo que este trabajo me servirá en el futuro porque sigue una arquitectura muy común

en muchos proyectos y he usado tecnologías muy punteras en el mercado, aparte de que

me ayudará en mi currículum profesional.

6.1. Trabajos futuros

En este apartado voy a comentar brevemente las historias de usuario que se descartaron

en la planificación inicial y serian unas buenas candidatas para incluirlas en una futura

planificación. Así como otras nuevas o mejoras de las existentes que han ido surgiendo a

lo largo de la realización del proyecto.

Principalmente si se quisiera ampliar el proyecto, las historias de usuario esenciales son:

Bonificar con puntos.

Capturar productos con código Bidi.



Sistema de gestión.

Por otro lado, las mejoras y nuevas funcionalidades podrían ser:

Un sistema de estadísticas e informes de ventas, para ver qué productos compran

más los clientes, en qué franja horaria, etc.

El uso de estadísticas daría al empresario una buena visión de pasado y de futuro

de su negocio, como por ejemplo para contratar más personal u ofertar más

productos relacionados con los gustos de sus clientes.

Incluir ofertas temporales para llamar la atención a los clientes.

Valoración de los productos por parte de los clientes.

En un futuro si se implementara la aplicación en varios restaurantes, se podría añadir un

sistema de geolocalización de restaurantes más cercanos que usen el sistema. Esto

serviría también como promoción del restaurante. La idea sería crear una red de

restaurantes que usen esta tecnología.

Otra propuesta sería en la ficha específica del producto, aparte de mostrarse el nombre,

precio e ingredientes, incluir un vídeo mostrando la elaboración del producto.

Con todas estas ideas podría desarrollarse una aplicación muy completa y con mucha

probabilidad de éxito en el mercado.

Con el diseño, arquitectura y tecnologías utilizadas en el proyecto, no sería difícil integrar

estas mejoras, porque en los elementos de la aplicación se ha intentado que tengan alta

cohesión y bajo acoplamiento; además de estar basada en una arquitectura modelo-vista-

controlador.



[1] «Expansion,»[Enlínea].Available:

http://www.expansion.com/economiadigital/innovacion/2017/03/10/58c19825e5fdea6f

688b456b.html.

[2] «Cadenaser,»[Enlínea].Available:

http://cadenaser.com/ser/2017/02/28/ciencia/1488281552_888684.html.

[3] «Wikipedia,»[Enlínea]. Available:

https://es.wikipedia.org/wiki/Manifiesto_%C3%A1gil.

[4] A. Á. G. R. d. l. H. d. D. Carmen Lasa Gómez, Métodos Ágiles. Scrum, Kanban, Lean,

Anaya, 2017.

[5] P. González, Apuntes de la asignatura Desarrollo Ágil, 2017.

[6] «Equipo Altran,» [En línea]. Available: http://equipo.altran.es/metodologias-agiles-vs-

metodologias-tradicionales/.

[7] J. Sutherland, Scrum: El nuevo y revolucionario modelo organizativo que cambiará tu

vida, 2015.

[8] «Auth0,» [En línea]. Available: https://auth0.com/blog/alternatives-to-native-mobile-

app-development/.

[9] M. Cohn, User stories applied: For Agile Software Development, Addison Wesley,

2004.

[10] R. d. l. H. C. L. Alonso Álvarez, Métodos ágiles y Scrum, Anaya, 2012.

[11] «EllaboratoriodelasTI,»[Enlínea].Available:

http://www.laboratorioti.com/2016/09/26/tecnica-priorizacion-moscow/.

[12] «Tablas salariales grupo Ilunion,» 2017. [En línea]. Available: https://www.ccoo-

servicios.es/archivos/ilunioncontactcenter/TablasSalariales2017.pdf.

[13] S. M. y. R. F. S. Bennett, Análisis y diseno orientado a objetos de sistemas, 3a edición,

McGraw-Hill, 2006.

[14] V. Mihalcea, High-Performance Java Persistence, 2016.



[15] «Adictos al trabajo,» [En línea]. Available:

https://www.adictosaltrabajo.com/tutoriales/zk-mvc-mvvm/.

[16] «Wikipedia,» [En línea]. Available:

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

[17] «Esacademic,» [En línea]. Available:

http://www.esacademic.com/dic.nsf/eswiki/1155905.

[18] «WikiUml,» [En línea]. Available:

https://wikiuml.wikispaces.com/Diagrama+de+Estados.

[19] E. Amodeo, Principios de Diseño de APIs REST.

[20] «Wikipedia,» [En línea]. Available:

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

[21] «W3schools,» [En línea]. Available: https://www.w3schools.com/js/js_json_intro.asp.

[22] «W3schools,» [En línea]. Available: https://www.w3schools.com/xml/.

[23] «Ionicframework,» [En línea]. Available:

https://dashboard.ionicframework.com/app/c2229688/code/builds.

[24] E. Revilla, Desarrollo de aplicaciones móviles multiplataforma con Ionic desde cero,

2017.

[25] «Ionic Framework,» [En línea]. Available:

https://ionicframework.com/docs/cli/commands.html.

[26] «El android libre,» [En línea]. Available:

https://elandroidelibre.elespanol.com/2016/04/como-instalar-aplicaciones-apk-

android.html.

[27] «ASDSDSADSDSDdictos al trabajo,» [En línea]. Available:

https://www.adictosaltrabajo.com/tutoriales/html-5-almacenamiento-local/#04.

[28] A. Rueda, Apuntes de la asignatura Desarrollo de aplicaciones empresariales, 2017.

[29] «Arquitectura Java,» [En línea]. Available: https://www.arquitecturajava.com/ejemplo-

de-jpa/.

[30] «IETF-related tools, standalone or hosted on tools.ietf.org,» [En línea]. Available:

https://tools.ietf.org/html/rfc7519.



[31] «Stream data,» [En línea]. Available: https://streamdata.io/blog/server-sent-events/.

[32] S. M. y. R. F. S. Bennett, Análisis y diseno orientado a objetos de sistemas, 3a edición,

McGraw-Hill, 2006.

[33] «El confidencial,» [En línea]. Available:

https://www.elconfidencial.com/tecnologia/2017-05-26/movil-uso-exceso-espana-

salud-enganchados-smartphone_1389117/.



Aplicación del servidor

Inicialmente se requiere tener instalado MAMP e iniciar la aplicación, para que se inicie

de MYSQL Server. Los parámetros de la BD son:

spring.datasource.url: jdbc:mysql://localhost:8889/tucomanda_db

spring.datasource.username: tienda_user

spring.datasource.password: 123456

Es necesario tener instalado Netbeans. El siguiente paso es pulsar sobre “Archivo”-

“Importar proyecto” y abrir la carpeta llamada “tucomandaspring” que contiene la

aplicación del servidor que está en el USB entregado.

Después pulsar sobre “Ejecutar proyecto”.

Aplicación móvil

Primero acceder con consola de comandos a la carpeta suministrada en el USB llamada

“tucomanda”, después ejecutar: Ionic serve. Este comando abrirá el navegador con la

aplicación.

Además, se incluye en la carpeta Platforms el proyecto compilado para Android o IOS.



En este apartado vamos a presentar una guía de uso de la aplicación, con una cuenta con

el perfil de cliente. Donde se podrá observar el flujo de ejecución y las distintas opciones

de cada vista.

Aplicación cliente: vista de clientes

Al ejecutar la aplicación se muestra una vista para la identificación del usuario, se debe

insertar el nick y la contraseña. También se puede registrar en la plataforma en caso de no

tener cuenta, rellenando los datos que solicita el formulario de alta. Estos formularios

validan los datos y muestran mensajes de errores.

Ilustración 67 Vista login

Una vez se realice el “login” correctamente, se tiene acceso a la aplicación, en la parte

inferior de la pantalla se muestra las distintas funcionalidades donde se puede acceder

como: Cuenta, Carta, Pedidos o Buscar.

En la sección de Carta se muestra una lista de todas las categorías de productos, si se

accede a una categoría se muestra los productos de dicha categoría.

Ilustración 66 Vista registro



Ilustración 69 Vista categorías

Por ejemplo, si se accede a la categoría de ensaladas, se muestra una lista de ensaladas y

cada producto con su imagen, nombre, precio y un botón a la derecha llamado 'VER

MÁS' para acceder a la ficha del producto.

Cuando se accede a la ficha del producto, se muestra una pantalla con toda su

información. El nombre, una foto del producto, el precio, un seleccionador de cantidad y

un apartado para introducir notas, donde se puede poner por ejemplo tus preferencias para

la carne si muy hecho o poco hecho o algún ingrediente que no quieras que tenga la

ensalada.

Ilustración 68 Vista productos



Ilustración 71 Vista producto

Una vez configuradas tus preferencias, solo faltaría pulsar el botón que pone 'AGREGAR

AL CARRITO' y se actualizará el icono de carrito de arriba a la derecha con el número

de productos que tengas en tu carrito.

Si haces “click” en el botón de carrito se muestra una lista de los productos que tienes

listos para hacer el pedido, por cada producto se muestra una foto, el nombre, precio y

cantidad.

Ilustración 70 Vista producto 2



Ilustración 73 Vista categorías con carrito

Finalmente, si hace “click” en el botón de 'REALIZAR PEDIDO' se mostrará un mensaje

de confirmación para asegurar la decisión.

Ilustración 72 Vista carrito



Ilustración 75 Confirmación pedido

Ahora si se accede al menú de 'Cuenta' se muestra el estado actual de nuestra cuenta, y

una lista de los pedidos realizados hasta ese momento. Si se quiere dar por finalizada la

estancia y pagar, solo habría que hacer “click” en el botón de 'PEDIR CUENTA' y

confirmar el mensaje de confirmación. Ahora solo habría que esperar a que el camarero

acuda a cobrarnos.

Ilustración 74 Pedido con éxito



Ilustración 77 Vista de cuenta

También se dispone de buscador, si accedemos a la opción 'Buscar' del menú y

escribimos la palabra 'ensalada', aparecerán todas las ensaladas que se ofertan. Ahora

pulsando sobre una de ellas accedes a la ficha de la ensalada seleccionada.

Ilustración 76 Confirmación pagar



Ilustración 78 Vista buscador

Finalmente, si accedemos a 'Pedidos' podremos ver el historial de pedidos que hemos

hecho en el restaurante, es meramente informativo.



Ilustración 79 Vista historial de pedidos

CAMARERO

Inicialmente con una cuenta con el rol de camarero se debe iniciar sesión en la aplicación

para acceder al sistema. Una vez dentro hay 2 opciones en el menú de navegación

'Enlazar' ,'Servir' y 'Cobrar'. A continuación, se detallarán estas opciones.



Ilustración 81 Vista enlazar 1

En la opción 'Enlazar' se enlaza el cliente con la mesa en la que está sentado para saber el

destino de sus pedidos.

En la parte superior aparece un buscador, donde hay que introducir el nick del cliente y

pulsar sobre el botón con el símbolo de más. A continuación, aparece un seleccionador

donde se elige la mesa del cliente. Por último, se pulsa sobre el botón enlazar para

realizar la acción.

En la opción de 'Servir' aparecerán los productos del pedido listos para servir, en forma

de lista donde aparece la cantidad, nombre, mesa destinataria y notas del producto.

Cuando se sirve el plato se tiene que eliminar de la lista desplazando el ítem hacia la

izquierda y pulsando el botón de 'Servido'.

Ilustración 80 Vista enlazar éxito



Ilustración 83 Vista servir 1

Por último, la opción de 'Cobrar', muestra una lista de todos los pedidos que ha realizado

la mesa seleccionada en el seleccionador de mesas. Una vez cobrado se debe pulsar en el

botón 'COBRAR' para que se marquen esos pedidos como cobrados.

Ilustración 82 Vista servir eliminar



Ilustración 84 Vista cobrar

Cocinero

Lo primero que hay que hacer es acceder al panel de login y identificarse

satisfactoriamente con una cuenta de cocinero. Una vez dentro del sistema se muestra la

lista de pedidos pendientes por servir, estos pedidos están ordenados por orden de

llegada.

Una vez preparado el producto se tiene que hacer click sobre el botón del producto para

notificar al camarero que lo recoja y lo sirva a la mesa determinada.



Ilustración 85 Vista cocinero



Se suministra un USB que contiene los siguientes archivos comprimidos:

Aplicación del servidor llamada tucomandasrping.zip

Aplicación del cliente llamada tucomanda.zip

Documents

ESTUDIO Y DESARROLLO DE UN PROTOTIPO DE APLICACIÓN …tauja.ujaen.es/bitstream/10953.1/8439/1/TFG... · Se realizará con el Framework Ionic que está basado en Angular JS y el servidor