diseÑo y desarrollo de una aplicaciÓn mÓvil de pago …
TRANSCRIPT
DISEÑO Y DESARROLLO DE UNA APLICACIÓN
MÓVIL DE PAGO PARA BARES Y RESTAURANTES
MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN
MATÍAS ANDRÉS MENICH MÉNDEZ
PROFESORA GUÍA:
MARÍA CECILIA BASTARRICA PIÑEYRO
MIEMBROS DE LA COMISIÓN:
JOCELYN SIMMONDS WAGEMANN
PATRICIO POBLETE OLIVARES
SANTIAGO DE CHILE
2017
UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN
i
RESUMEN DE LA MEMORIA PARA OPTAR AL
TÍTULO DE: Ingeniero Civil en Computación
Por: Matías Andrés Menich Méndez
Fecha: 17 de marzo de 2017
Profesora guía: María Cecilia Bastarrica Piñeyro
DISEÑO Y DESARROLLO DE UNA APLICACIÓN MÓVIL DE
PAGO PARA BARES Y RESTAURANTES
En los tiempos actuales, de alta competitividad, uno de los procesos que ha adquirido
cada vez mayor relevancia en las organizaciones es el de atención a clientes. Para el caso de las
empresas del sector gastronómico, como son los restaurantes o bares, se trata de un proceso
clave. El proceso de pago es determinante en este aspecto y es un factor que está directamente
relacionado con el tiempo de atención.
El proceso de pago es un problema en los restaurantes y bares que afecta de manera transversal a
varios actores, no sólo a los clientes finales (los comensales) sino que también a “restauranteros”
(dueños de restaurant y administradores) y meseros por igual. Para los clientes es lento, no existe
control sobre la cuenta, existe dificultad al momento de dividir la cuenta y hay poca seguridad en
la transacción. Para restauranteros resulta potencialmente en menores ingresos, experiencia pobre
de los consumidores, existe poco conocimiento sobre la demografía y hábito de consumo de sus
clientes y existen clientes que se van sin pagar.
La tecnología de pagos móviles permite proveer una mejor experiencia de pago de cara al
consumidor, haciendo del pago algo fácil, rápido y seguro. Existe un crecimiento importante de
esta tecnología en los últimos años, pronosticando 450 millones de usuarios de pagos móviles a
nivel mundial para 2017, lo que manifiesta una confianza en esta tecnología por parte del
consumidor que antes no existía.
En vista de lo anterior se busca desarrollar una aplicación móvil de pago para bares y
restaurantes, y evaluar su velocidad, influencia en el flujo, escalabilidad y disponibilidad a partir
de los datos obtenidos durante la implementación de un prototipo en un restaurant.
Particularmente las labores que se desarrollaron en esta memoria son: Diseño del sistema y su
arquitectura, diseño de la interfaz de usuario (GUI) y desarrollo frontend y backend.
Se describió el desarrollo de la solución en detalle y su implementación en un contexto real
donde tuvo un impacto positivo y un buen desempeño.
ii
“There is nothing noble in being superior to
your fellow man; true nobility is being superior
to your former self.”
- ERNEST HEMINGWAY
iii
Agradecimientos
A mi familia, sin su apoyo y cariño incondicional no estaría acá ni sería la persona que soy.
A Josefa, mi eterna compañera y apoyo. Gracias por empujarme, te amo.
A mis amigos, que me han ayudado más de lo que creen.
A mis socios, por creer en mí y mis proyectos.
A mis profesores, todos han aportado a mi formación de una u otra manera.
Sin cada uno de ustedes hubiese sido imposible realizar este trabajo. Gracias.
iv
Tabla de Contenido
RESUMEN ..................................................................................................................................................... I
AGRADECIMIENTOS ............................................................................................................................. III
ÍNDICE DE TABLAS ................................................................................................................................ VI
ÍNDICE DE FIGURAS .............................................................................................................................. VI
1 INTRODUCCIÓN ............................................................................................................................... 1 1.1 OBJETIVOS .................................................................................................................................... 3
1.1.1 Objetivo General ...................................................................................................................... 3 1.1.2 Objetivos Específicos ............................................................................................................... 3
1.2 ESTRUCTURA ................................................................................................................................ 3
2 MARCO CONCEPTUAL .................................................................................................................. 4 2.1 WEBSOCKET ................................................................................................................................. 4 2.2 REST (REPRESENTATIONAL STATE TRANSFER) .......................................................................... 5 2.3 APACHE CORDOVA ....................................................................................................................... 6 2.4 NODE.JS ........................................................................................................................................ 7 2.5 NOSQL ......................................................................................................................................... 8 2.6 JSON WEB TOKEN (JWT) ............................................................................................................ 9
3 DISEÑO.............................................................................................................................................. 11 3.1 PROPUESTA ................................................................................................................................. 11 3.2 PRINCIPALES FUNCIONALIDADES ............................................................................................... 12
3.2.1 Despliegue de la información de la cuenta ............................................................................ 12 3.2.2 Compartir de manera simple ................................................................................................. 12 3.2.3 Pagar la cuenta ...................................................................................................................... 12
3.3 SELECCIÓN DE TECNOLOGÍAS ..................................................................................................... 12 3.3.1 Aplicación Móvil (Frontend) .................................................................................................. 12
3.3.1.1 Aplicaciones nativas v/s aplicaciones hibridas ............................................................................................. 13 3.3.2 Procesamiento de pagos ........................................................................................................ 14 3.3.3 División de la cuenta .............................................................................................................. 16 3.3.4 API (Backend) ........................................................................................................................ 16 3.3.5 Arquitectura ........................................................................................................................... 17
4 DESARROLLO ................................................................................................................................. 19 4.1 COMPONENTES COMPARTIDAS ................................................................................................... 19
4.1.1 Modelo de Datos .................................................................................................................... 19 4.1.2 Seguridad ............................................................................................................................... 20
4.1.2.1 Autenticación ................................................................................................................................................ 20 4.1.3 Interfaz principal de la aplicación móvil ............................................................................... 21
4.1.3.1 Directrices de diseño entre plataformas. ....................................................................................................... 21 4.1.3.2 Registro y Log-in .......................................................................................................................................... 22 4.1.3.3 Despliegue de establecimientos soportados .................................................................................................. 23 4.1.3.4 Menú lateral .................................................................................................................................................. 24
4.2 DESPLIEGUE DE LA INFORMACIÓN DE LA CUENTA. .................................................................... 25 4.2.1 Módulo de Integración con Puntos de Venta ......................................................................... 25
4.2.1.1 Servicio de POS ............................................................................................................................................ 26 4.2.1.2 POS-API ....................................................................................................................................................... 28 4.2.1.3 Canal de comunicación con el POS .............................................................................................................. 29
4.2.2 Interfaz aplicación móvil ........................................................................................................ 30 4.3 DIVISIÓN DE LA CUENTA ............................................................................................................. 31
4.3.1 Caso 1: División Equitativa ................................................................................................... 32 4.3.2 Caso 2: División por ítem ...................................................................................................... 35
v
4.4 PAGAR LA CUENTA ..................................................................................................................... 41 4.4.1 Gateway service ..................................................................................................................... 41 4.4.2 Inscripción de tarjetas ............................................................................................................ 41 4.4.3 Pago ....................................................................................................................................... 45
5 IMPLEMENTACIÓN Y ANÁLISIS ............................................................................................... 49 5.1 CONTEXTO DE IMPLEMENTACIÓN ............................................................................................... 49 5.2 USABILIDAD ................................................................................................................................ 50 5.3 FLUJO .......................................................................................................................................... 54 5.4 DESEMPEÑO TECNOLÓGICO ........................................................................................................ 57
5.4.1 Uso normal ............................................................................................................................. 57 5.4.2 Pruebas de stress .................................................................................................................... 59
6 CONCLUSIONES ............................................................................................................................. 62
7 GLOSARIO ....................................................................................................................................... 64
8 BIBLIOGRAFÍA ............................................................................................................................... 67
ANEXO ......................................................................................................................................................... 1 ANEXO A: LLAMADAS INTEGRACIÓN POS-API ........................................................................................ 1
Obtener ticket específico ....................................................................................................................... 1 Obtener tickets....................................................................................................................................... 3 Registrar pago ....................................................................................................................................... 4
ANEXO B: EVALUACIÓN CUALITATIVA DE LA APLICACIÓN ...................................................................... 1
vi
Índice de Tablas
Tabla 1: Comparativa medios de pago online chilenos ................................................................. 15 Tabla 2: Comparativa entre frameworks de desarrollo web .......................................................... 17 Tabla 3: División por ítem - Primer escenario .............................................................................. 35 Tabla 4: División por ítem - Segundo escenario ........................................................................... 35 Tabla 5: División por ítem - Tercer escenario ............................................................................... 36
Índice de Figuras
Figura 1: Diagrama funcionamiento Websocket ............................................................................. 5 Figura 2: Diagrama funcionamiento Apache Cordova .................................................................... 7 Figura 3: Diagrama comparativo aplicaciones nativas v/s aplicaciones híbridas ......................... 13 Figura 4: Diagrama de la arquitectura final de la aplicación ......................................................... 18 Figura 5: Modelo de datos ............................................................................................................. 19 Figura 6: Interacción proceso de autenticación ............................................................................. 21 Figura 7: Comparativa barra de título entre plataformas ............................................................... 22 Figura 8: Comparativa botón entre plataformas ............................................................................ 22 Figura 9: Flujo de log-in y registro ................................................................................................ 23 Figura 10: Vista establecimientos.................................................................................................. 23 Figura 11: Menú lateral ................................................................................................................. 24 Figura 12: Secciones menú lateral ................................................................................................. 25 Figura 13: Diagrama de patrón strategy en adaptadores de POS-Service ..................................... 26 Figura 14: Ejemplos de interfaces de POS de restaurantes ........................................................... 28 Figura 15: Flujo de despliegue de información de la cuenta - 1 .................................................... 30 Figura 16: Flujo de despliegue de información de la cuenta - 2 .................................................... 31 Figura 17: Interfaz división equitativa........................................................................................... 33 Figura 18: División equitativa - Ejemplo primer escenario .......................................................... 34 Figura 19: División equitativa - Ejemplo segundo escenario ........................................................ 34 Figura 20: División por ítem – Representación de flujo websockets ............................................ 38 Figura 21: División por ítem – Primer escenario .......................................................................... 39 Figura 22: División por ítem - Segundo escenario ........................................................................ 40 Figura 23: División por ítem - Tercer escenario............................................................................ 40 Figura 24: Diagrama de secuencia de inscripción de tarjetas Webpay Oneclick .......................... 42 Figura 25: Pantallas de inicio de inscripción de tarjeta ................................................................. 43 Figura 26: Flujo inscripción webview ........................................................................................... 44 Figura 27: Diagrama de interacción de pago con Webpay Oneclick ............................................ 46 Figura 28: Vista de resumen y propina .......................................................................................... 47 Figura 29: Vista comprobante ....................................................................................................... 47 Figura 30: Email de comprobante de pago .................................................................................... 48 Figura 31: Foto de lanzamiento de Slice en el restaurant Pad Thai .............................................. 49
1
1 Introducción
En los tiempos actuales, de alta competitividad, uno de los procesos que ha adquirido
cada vez mayor relevancia en las organizaciones es el de atención a clientes. Para el caso de las
empresas del sector gastronómico, como son los restaurantes o bares, se trata de un proceso
clave. Según [1], [2] y [3], los atributos que más valoran los clientes de un restaurante, son: el
precio, el tiempo de atención, la localización, el ambiente y la calidad de la comida. Dentro de
ellos, el proceso de pago es un factor determinante ya que está directamente relacionado con el
tiempo de atención total.
El proceso de pago es un problema en los restaurantes y bares que afecta de manera transversal a
varios actores, no sólo a los clientes finales (los comensales) sino que también a “restauranteros”
(dueños de restaurant y administradores) y meseros por igual.
Existen varios puntos en los cuales este proceso puede no ser el ideal:
- Para clientes (del restaurant o bar):
o Es lento: El proceso de pago en un restaurant o bar es en promedio 12 minutos desde
que el cliente pide la cuenta hasta que se retira del local. Esto se ve acrecentado en
periodos de alta demanda, debido a que el personal tiene que atender a mayor cantidad
de solicitudes y a la existencia de grupos grandes.
o No existe control sobre la cuenta: Si existe un error en la cuenta, hoy el cliente sólo
se puede percatar al momento de pedir la cuenta. Es fácil no percatarse de ellos
cuando la cuenta aumenta en pedidos en un número considerable.
o Dificultad al momento de dividir la cuenta: Sobre todo en cuentas de más de 6
personas y con consumo asimétrico, los cálculos crecen en dificultad para el usuario
promedio. Es usual también que existan clientes que “delegan” la responsabilidad de
la cuenta a los demás comensales, al irse sin aviso o pagar menor cantidad (con o sin
intención).
o Poca seguridad: Ya que al pagar con tarjeta (el medio de mayor uso al momento de
esta memoria), ya sea con crédito o débito, los usuarios son susceptibles a las ya
habituales clonaciones de datos.
- Para restauranteros:
o Menores ingresos: Dado a que pueden atender menos personas por unidad de tiempo
en horario punta (menor rotación de mesas).
o Experiencia pobre de los consumidores: Al ser ineficiente en el proceso del pago, se
traslada la espera a los consumidores, los cuales valoran su tiempo.
o Poco conocimiento sobre la demografía y los hábitos de consumo de sus clientes:
Ya que los puntos de ventas tradicionales tienen sólo alcance local y no tienen un
registro (en general) de los datos de los clientes como edad o sexo.
o Poca eficiencia de sus recursos: Sobre todo de los humanos (los meseros) debido a
que podrían estar atendiendo más mesas. Los meseros pasan a tomar labores de
2
cajeros en horas punta, teniendo que calcular cuentas (lo que ya es difícil), cobrar y
recontar el dinero en múltiples ocasiones.
o Clientes que se van sin pagar: Sobre todo en bares, donde los clientes les disminuye
la percepción moral y cometen este crimen.
Según datos de [4], 20% de los chilenos visita un restaurant al menos una vez al mes, porcentaje
que se pronostica aumentará, por lo que cada vez los problemas mencionados se harán más
recurrentes. Cabe mencionar que solo en Santiago, existe un restaurante por cada 825 habitantes
[5], razón que se ve multiplicada en varias otras partes de Latinoamérica y el mundo, por lo que
es un problema de alcance global.
Por otro lado, la alta cantidad de smartphones en el mundo, los que se pronostican llegarán a 1.84
billones para el año 2020 [6], junto a el crecimiento de la tecnología con respecto a los pagos,
hacen que hoy el pago móvil sea prácticamente una realidad. Tecnologías como Apple Pay,
Samsung Pay, PayPal, y Square han impulsado esta tendencia, brindando como ventajas
seguridad, rapidez y simplicidad. Según [7], se pronostican 450 millones de usuarios de pagos
móviles a nivel mundial para 2017, lo que manifiesta una confianza en esta tecnología por parte
del consumidor que antes no existía, por lo que esta tecnología es cada vez menos ajena al
público general, por lo que existe una costumbre ya instaurada entorno a pagar mediante un
smartphone para los usuarios.
En vista de lo anterior, es lógico asumir que las ventajas provistas por las tecnologías de pago
móviles podrían beneficiar directamente el proceso de pago en bares y restaurantes. En Chile, a la
fecha de escribir este documento, no existe una aplicación que resuelva este problema a
cabalidad.
Esta memoria busca desarrollar una aplicación móvil de pago para bares y restaurantes, y evaluar
su funcionamiento a partir de los datos obtenidos durante la implementación de un prototipo en
un restaurant.
Cabe mencionar que el pago es un proceso altamente interactivo entre los usuarios, por lo que se
necesita una aplicación que permita realizar este proceso de manera simple, por lo que su
usabilidad (facilidad de uso y de aprendizaje) debe ser alta. A su vez, el sistema debe poder
adaptarse a las necesidades cambiantes del problema y del usuario, y a un crecimiento potencial
acelerado de su uso.
Particularmente las labores que se desarrollaron en esta memoria son: Diseño del sistema y su
arquitectura, diseño de la interfaz de usuario (GUI) y desarrollo frontend y backend.
3
1.1 Objetivos
1.1.1 Objetivo General
Diseñar y desarrollar una aplicación móvil para pagar la cuenta en bares y restaurantes.
1.1.2 Objetivos Específicos
• Diseñar un sistema que sea escalable, mantenible y que permita agilidad en el desarrollo.
• Analizar y determinar las características necesarias para diseñar un sistema de alta
usabilidad.
• Desarrollar e implementar un prototipo funcional de la aplicación móvil que permita
llevar a cabo la solución propuesta.
• Evaluar el impacto de la aplicación móvil en el proceso de pago de restaurantes y bares.
1.2 Estructura
El trabajo de memoria se llevó a cabo siguiendo la siguiente estructura:
• Diseño: Para comenzar, se describió la propuesta tecnológica de manera general,
describiendo la idea general y realizando una justificación con respecto al contexto. Se
analizó cuáles son las características principales que deben ser integradas en la solución. Cada
característica de la aplicación fue argumentada a partir de los requerimientos y de las
posibilidades tecnológicas de las que se disponen en la actualidad. Luego, se eligieron las
tecnologías sobre las cuales se hizo el desarrollo, exponiendo las alternativas existentes
acompañadas de sus respectivas ventajas y desventajas.
• Desarrollo de la aplicación: En esta etapa se construyó el software que permite satisfacer los
requisitos de la propuesta de solución. Se describió en detalle el proceso de desarrollo junto
con las decisiones tomadas desde el punto de vista técnico para cumplir el objetivo.
• Implementación y análisis: La implementación, consiste en la prueba del funcionamiento de
la aplicación. Se obtuvieron datos e información de los usuarios, a partir de los cuales se hizo
un análisis con el objetivo de verificar si el desarrollo tecnológico satisface los objetivos con
respecto a la solución del problema. También se evaluó el desempeño de la solución
tecnológica en torno a los requerimientos.
4
2 Marco Conceptual
En este capítulo se describirán las tecnologías y conceptos que fueron relevantes para el
desarrollo de la solución.
De manera breve, estos conceptos y tecnologías son:
• Websocket: Tecnología de canal de comunicación bidireccional y full-duplex sobre un
único socket TCP. Se utilizó para proveer un canal de comunicación en tiempo real para
una mejor respuesta con respecto a la interacción entre los usuarios, la obtención de
información y la comunicación de los componentes del sistema.
• REST: Estilo de arquitectura que provee una manera de interoperabilidad entre sistemas
computacionales en internet, utilizando un conjunto predefinido de operaciones
“stateless” o sin estado. Se utilizó para el diseño del backend, y como protocolo de
comunicación de todos los componentes de la arquitectura del sistema.
• Apache Cordova: Framework de desarrollo móvil que permite construir aplicaciones
móviles utilizando tecnologías web. Se utilizó para el desarrollo de la aplicación móvil.
• Node.js: Entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa
del servidor basado en JavaScript, asíncrono, con I/O de datos en una arquitectura
orientada a eventos y basado en el motor V8 de Google. Fue utilizado para distintas
componentes del sistema, haciendo uso extensivo de él en el backend.
• NoSQL: Bases de datos distribuidas no relacionales que proveen ganancias en
escalabilidad y rendimiento con respecto a bases de datos SQL con respecto a ciertas
aplicaciones debido a su estructura. Se utilizó para implementar el modelo de datos
mediante MongoDB, la cual es una base de datos documental.
• JWT: Estándar abierto que define una forma compacta y auto contenida de transmitir
información de manera segura entre pares a través de un objeto JSON. Se utilizó como
protocolo de seguridad para la transmisión de información para todos los componentes del
sistema.
A continuación, se describirá en detalle cada uno de los conceptos.
2.1 Websocket
Consiste en una tecnología que proporciona un canal de comunicación bidireccional y
full-duplex sobre un único socket TCP. Está diseñada para ser implementada en navegadores y
servidores web, pero puede utilizarse por cualquier aplicación cliente/servidor. La API de
WebSocket está siendo normalizada por el W3C, mientras que el protocolo Websocket ya fue
normalizado por la IETF como el RFC 6455 [8].
Para establecer una conexión Websocket, el cliente manda una petición de negociación
Websocket, y el servidor manda una respuesta de negociación Websocket. Esta negociación
puede parecerse a la negociación HTTP, pero no es así. Permite al servidor interpretar parte de la
petición de negociación como HTTP y entonces cambiar a Websocket. Una vez establecida, las
tramas Websocket de datos pueden empezar a enviarse en ambos sentidos entre el cliente y el
servidor en modo full-duplex.
5
La especificación del protocolo WebSocket define dos nuevos esquemas de URI, ws: y wss: para
conexiones no cifradas y cifradas respectivamente. Además del nombre del esquema, el resto de
componentes del URI se definen con la sintaxis genérica de URI.
Figura 1: Diagrama funcionamiento Websocket
Debido a que las conexiones TCP comunes sobre puertos diferentes al 80 son habitualmente
bloqueadas por los administradores de redes, el uso de esta tecnología proporcionaría una
solución a este tipo de limitaciones proveyendo una funcionalidad similar a la apertura de varias
conexiones en distintos puertos, pero multiplexando diferentes servicios WebSocket sobre un
único puerto TCP (a costa de una pequeña sobrecarga del protocolo).
2.2 REST (Representational State Transfer)
La Transferencia de Estado Representacional (Representational State Transfer) o REST es
un estilo de arquitectura de software para sistemas hipermedia distribuidos como la World Wide
Web.
Si bien el término REST se refería originalmente a un conjunto de principios de arquitectura, en
la actualidad se usa en el sentido más amplio para describir cualquier interfaz entre sistemas que
utilice directamente HTTP para obtener datos o indicar la ejecución de operaciones sobre los
datos, en cualquier formato (XML, JSON, etc.) sin las abstracciones adicionales de los protocolos
basados en patrones de intercambio de mensajes, como por ejemplo SOAP.
6
Los sistemas que siguen los principios REST se llaman con frecuencia RESTful.
REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseños
fundamentales clave:
• Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la
información necesaria para comprender la petición. Como resultado, ni el cliente ni el
servidor necesitan recordar ningún estado de las comunicaciones entre mensajes. Sin
embargo, en la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros
mecanismos para mantener el estado de la sesión (algunas de estas prácticas, como la
reescritura de URLs, no son permitidas por REST).
• Un conjunto de operaciones bien definidas que se aplican a todos los recursos de
información: HTTP en sí define un conjunto pequeño de operaciones, las más
importantes son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se
equiparan a las operaciones CRUD en bases de datos (ABMC en español: crear, leer,
actualizar, borrar) que se requieren para la persistencia de datos, aunque POST no encaja
exactamente en este esquema.
• Una sintaxis universal para identificar los recursos: En un sistema REST, cada recurso
es direccionable únicamente a través de su URI.
• El uso de hipermedios, tanto para la información de la aplicación como para las
transiciones de estado de la aplicación: la representación de este estado en un sistema
REST son típicamente HTML o XML. Como resultado de esto, es posible navegar de un
recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de
registros u otra infraestructura adicional.
2.3 Apache Cordova
Apache Cordova (conocido anteriormente como PhoneGap) es un popular framework de
desarrollo móvil. Permite a programadores de software construir aplicaciones utilizando CSS3,
HTML5 y Javascript, en vez de apoyarse en las APIs específicas de cada plataforma, como
Android, iOS o Windows Phone. Permite extender las características de HTML y Javascript para
trabajar en el dispositivo.
7
Figura 2: Diagrama funcionamiento Apache Cordova
Las aplicaciones resultantes resultan ser híbridas, esto significa que no es una aplicación
realmente nativa (ya que el render se hace mediante webviews en vez del framework UI de la
plataforma) y tampoco puramente basada en Web (dado a que no sólo son aplicaciones Web, si
no que están empaquetadas como aplicaciones para distribución y tienes acceso APIs nativas del
dispositivo).
2.4 Node.js
Node.js es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la
capa del servidor (pero no limitándose a ello) basado en el lenguaje de programación
ECMAScript (comúnmente conocido como JavaScript), asíncrono, con I/O de datos en una
arquitectura orientada a eventos y basado en el motor V8 de Google. Fue creado con el enfoque
de ser útil en la creación de programas de red altamente escalables, como, por ejemplo,
servidores web [9].
Al contrario que la mayoría del código JavaScript, no se ejecuta en un navegador, sino en el
servidor.
Sus características principales son:
8
• Concurrencia: Node.js funciona con un modelo de evaluación de un único hilo de ejecución,
usando entradas y salidas asíncronas las cuales pueden ejecutarse concurrentemente en un
número de hasta cientos de miles sin incurrir en costos asociados al cambio de contexto. Este
diseño de compartir un único hilo de ejecución entre todas las solicitudes atiende a
necesidades de aplicaciones altamente concurrentes, en el que toda operación que realice
entradas y salidas debe tener una función callback. Un inconveniente de este enfoque de
único hilo de ejecución es que Node.js requiere de módulos adicionales como cluster7 para
escalar la aplicación con el número de núcleos de procesamiento de la máquina en la que se
ejecuta.
• Módulos: Node.js incorpora varios "módulos básicos" compilados en el propio binario, como
por ejemplo el módulo de red, que proporciona una capa para programación de red asíncrona
y otros módulos fundamentales, como por ejemplo Path, FileSystem, Buffer, Timers y el de
propósito más general Stream. Es posible utilizar módulos desarrollados por terceros, ya sea
como archivos ".node" precompilados, o como archivos en Javascript plano.
Los módulos de terceros pueden extender Node.js o añadir un nivel de abstracción,
implementando varias utilidades middleware para utilizar en aplicaciones web, como por
ejemplo los frameworks connect y express. Pese a que los módulos pueden instalarse como
archivos simples, normalmente se instalan utilizando el Node Package Manager (npm) que
nos facilitará la compilación, instalación y actualización de módulos, así como la gestión de
las dependencias. Además, los módulos que no se instalen el directorio por defecto de
módulos de Node necesitarán la utilización de una ruta relativa para poder encontrarlos. El
wiki de Node.js proporciona una lista de varios de los módulos de terceros disponibles.
• API Unificada: Node.js puede ser combinado con una base de datos documental (por
ejemplo, MongoDB o CouchDB) y JSON lo que permite desarrollar en un entorno de
desarrollo JavaScript unificado. Con la adaptación de los patrones para desarrollo del lado del
servidor tales como MVC y sus variantes MVP, MVVM, etc., Node.js facilita la reutilización
de código del mismo modelo de interfaz entre el lado del cliente y el lado del servidor.
• Loop de eventos: Node.js se registra con el sistema operativo y cada vez que un cliente
establece una conexión se ejecuta un callback. Dentro del entorno de ejecución de Node.js,
cada conexión recibe una pequeña asignación de espacio de memoria dinámico, sin tener que
generar un hilo de trabajo. A diferencia de otros servidores dirigidos por eventos, el lazo de
manejo de eventos de Node.js no es llamado explícitamente, sino que se activa al final de
cada ejecución de una función de callback. El lazo de manejo de eventos se termina cuando
ya no quedan eventos por atender.
2.5 NoSQL
Es una amplia clase de sistemas de gestión de bases de datos que difieren del modelo
clásico del sistema de gestión de bases de datos relacionales (RDBMS) en aspectos importantes,
el más destacado es que no usan SQL como el principal lenguaje de consultas. Los datos
almacenados no requieren estructuras fijas como tablas, normalmente no soportan operaciones
JOIN, ni garantizan completamente ACID (atomicidad, consistencia, aislamiento y durabilidad),
y habitualmente escalan bien horizontalmente. Los sistemas NoSQL se denominan a veces "no
9
sólo SQL" para subrayar el hecho de que también pueden soportar lenguajes de consulta de tipo
SQL.
Por lo general, los investigadores académicos se refieren a este tipo de bases de datos como
almacenamiento estructurado, término que abarca también las bases de datos relacionales
clásicas. A menudo, las bases de datos NoSQL se clasifican según su forma de almacenar los
datos, y comprenden categorías como clave-valor, las implementaciones de BigTable, bases de
datos documentales, y Bases de datos orientadas a grafos.
Los sistemas de bases de datos NoSQL crecieron con las compañías de Internet, como Google,
Amazon, Twitter y Facebook. Estas tenían que enfrentarse a desafíos con el tratamiento de datos
que las tradicionales RDBMS no solucionaban [10]. Con el crecimiento de la web en tiempo real
existía una necesidad de proporcionar información procesada a partir de grandes volúmenes de
datos que tenían unas estructuras horizontales más o menos similares. Estas compañías se dieron
cuenta de que el rendimiento y sus propiedades de tiempo real eran más importantes que la
coherencia, en la que las bases de datos relacionales tradicionales dedicaban una gran cantidad de
tiempo de proceso.
En ese sentido, a menudo, las bases de datos NoSQL están altamente optimizadas para las
operaciones recuperar y agregar, y normalmente no ofrecen mucho más que la funcionalidad de
almacenar los registros (p.ej. almacenamiento clave-valor). La pérdida de flexibilidad en tiempo
de ejecución, comparado con los sistemas SQL clásicos, se ve compensada por ganancias
significativas en escalabilidad y rendimiento cuando se trata con ciertos modelos de datos.
2.6 JSON Web Token (JWT)
JSON Web Token es un estándar abierto (RFC 7519 [11]) que define una forma compacta y auto
contenida de transmitir información de manera segura entre pares a través de un objeto JSON.
Esta información es confiable y verificable debido a que se encuentra firmada digitalmente. JWT
puede ser firmado usando un secreto (utilizando el algoritmo HMAC [12]) o un par de llaves
pública/privada usando RSA.
Su estructura consiste en tres partes separadas por puntos (xxxxx.yyyyy.zzzzz), las cuales son:
• Header (Cabecera): Es un JSON que consiste en dos partes: el tipo de token, el cual es
JWT, y el algoritmo de hashing que se utiliza, como HMAC, SHA256 o RSA. Luego este
JSON se codifica en Base64Url para formar la primera parte del JWT.
• Payload (Carga útil): Es un JSON que contiene las reclamaciones o claims. Los claims
son declaraciones sobre una entidad (típicamente, el usuario) y metadata adicional. Luego
este JSON se codifica en Base64Url para formar la segunda parte del JWT. Existen tres
tipos de claims:
o Reservadas: iss (issuer o emisor), exp (expiration time o tiempo de expiración),
sub (subject o sujeto), aud (audience o audiencia), y otros.
o Públicas: Estas puedes ser definidas a conveniencia por los que ocupen las JWTs.
o Privadas: Estas son claims personalizadas creadas para compartir información
entre las partes que accedieron a utilzarlas.
10
• Signature (Firma): Consiste en el conjunto firmado del header codificado, el payload
codificado, un secreto y el algoritmo especificado en el header. Esta se utiliza para
verificar que el emisor del JWT es quien dice ser y para garantizar que el mensaje no fue
modificado en el camino.
El output consiste en tres strings Base64 separados por puntos que pueden ser fácilmente
distribuidos por en ambientes HTML y HTTP, siendo más compacto al compararlo con
estándares basados en XML como SAML.
11
3 Diseño
En el siguiente capítulo se hará un análisis de la propuesta y se propondrá el diseño de la
solución. Se evaluarán los requisitos, seleccionando las características principales de la aplicación
móvil para luego elegir las tecnologías necesarias para satisfacer los requisitos de cada una.
3.1 Propuesta
La propuesta principal que se desea desarrollar es la siguiente: Una aplicación móvil para poder
pagar y compartir la cuenta de forma rápida, segura y sencilla en bares y restaurantes.
Los siguientes son los factores que hacen posible construir la solución buscada:
• la alta y creciente cantidad de smartphones en el mundo, los que se pronostican llegarán a
1.84 billones para el año 2020 [6], por lo que tienen un gran alcance y penetración en la
población;
• las diferentes características que entregan los dispositivos a sus usuarios y la cercana
relación que se establece entre las personas y sus aparatos móviles;
• el bajo costo de desarrollo del producto y escalabilidad, en relación a los mercados
tradicionales;
• la fácil distribución a través de las tiendas de aplicaciones, lo que significa mayor
accesibilidad para los usuarios;
• la tendencia mundial en torno a los pagos móviles [7] acrecentada por el creciente uso de
aplicaciones como Uber y apariciones de medios de pago móviles como Apple Pay,
Android Pay y Samsung Pay entre otros.
La idea general, es que el usuario pueda usar su smartphone para ver el estado de su cuenta,
repartirla de manera fácil e intuitiva y pagar cuando estime conveniente, evitando así los
problemas asociados mencionados en el capítulo 1.2.1. Esto apunta a hacer más eficiente el
proceso del pago y proporcionar la mejor experiencia posible al consumidor final.
Para esto, tanto el cliente como el restaurant o bar deben estar registrados en el sistema, de
manera de poder contar con la información necesaria para realizar una transacción.
El flujo de la propuesta es el siguiente:
1. El usuario solicita un código al mesero para poder ver su cuenta en cualquier momento.
2. El mesero le devuelve un código correspondiente a su pedido.
3. El usuario ve reflejado el estado de su cuenta en el smartphone (viendo todo lo que
ordenó y se ordenará en un futuro).
4. El usuario podrá elegir entre dividir el consumo de manera fácil o pagar el total, incluida
la propina.
5. El usuario podrá pagar mediante su smartphone y podrá retirarse del establecimiento, sin
necesidad de pedir la cuenta.
6. El staff del local recibirá una notificación cuando exista un pago.
12
Es muy importante señalar que el objetivo original de la aplicación apunta a mejorar la
experiencia del pago, y no solo a ser un medio de pago, de manera que pagar y compartir la
cuenta no sea un problema.
3.2 Principales Funcionalidades
En esta etapa se realizó un análisis cualitativo para determinar las funcionalidades
principales de la aplicación móvil. Se seleccionaron tres: Despliegue de la información de la
cuenta, compartirla de manera simple y pagarla.
3.2.1 Despliegue de la información de la cuenta
Una funcionalidad que debe entregar la aplicación móvil al usuario, es la posibilidad de
ver el estado de su cuenta en todo momento. Esta funcionalidad emula el funcionamiento de la
pre-cuenta del restaurant, donde se ve reflejado todo el consumo del usuario hasta ese momento.
De esta manera, el usuario podrá tener control sobre su consumo, observando cuánto ha gastado y
detectando posibles errores de digitación del personal.
3.2.2 Compartir de manera simple
Esta funcionalidad permite a un usuario poder compartir de manera simple la cuenta entre
más usuarios. Debe permitir la interacción de múltiples actores, con y sin la aplicación; y facilitar
el proceso de división, haciéndolo rápido mediante una interfaz simple.
3.2.3 Pagar la cuenta
Como se declara en la propuesta, la aplicación móvil tendrá como objetivo el pago en bares y
restaurantes, por lo que este punto es crucial y deberá permitir al usuario pagar la cuenta de un
bar o restaurant. Cabe mencionar el pago debe ser seguro y debe simplificar y no complicar el
flujo de pago actual existente.
3.3 Selección de tecnologías
Actualmente existen diferentes opciones tecnológicas para el desarrollo de aplicaciones
móviles. La selección de la plataforma es una decisión importante ya que cambiarse
posteriormente implica retraso y altos costos de desarrollo. Es por esto que la elección
tecnológica debe ser realizada considerando diferentes aspectos como la complejidad de la
aplicación, el mercado al cual apunta, el tiempo de aprendizaje y desarrollo asociado a cada
plataforma, entre otros.
3.3.1 Aplicación Móvil (Frontend)
Para desarrollar la aplicación móvil, se necesita de tecnologías que permitan un desarrollo
rápido, constante iteración, máxima eficiencia, rapidez y robustez. Para esto es necesario elegir
13
una tecnología que permita tener agilidad en el desarrollo manteniendo un alto estándar en torno
a la experiencia del usuario.
3.3.1.1 Aplicaciones nativas v/s aplicaciones hibridas
Un punto importante al momento de desarrollar una aplicación móvil es decidir si realizar
una aplicación nativa o una aplicación híbrida. Cada una tiene ventajas y desventajas, los cuáles
serán evaluados a continuación en torno al contexto del proyecto.
Las aplicaciones nativas se desarrollan exclusivamente para un sistema operativo móvil, como
puede ser Android o iOS, por lo que por cada plataforma que se quiera agregar, se debe agregar
un stack de un nuevo lenguaje al proyecto, junto con su base de código, lo que aumenta el tiempo
de desarrollo y costo del proyecto. Las aplicaciones híbridas permiten escribir en una misma base
de código y poder ejecutarlo en múltiples plataformas, pudiendo acceder a las mismas APIs
nativas de cada una mediante adaptadores o plugins.
Con respecto al rendimiento, según [13] existe un mayor rendimiento en torno a tiempos de
respuesta y uso de recursos en aplicaciones nativas versus aplicaciones hibridas. Esto debido a
que las aplicaciones nativas se ejecutan a un nivel más bajo que las híbridas y pueden acceder a
recursos del hardware y APIs directamente.
Figura 3: Diagrama comparativo aplicaciones nativas v/s aplicaciones híbridas
A pesar de lo anterior, la ganancia en costo y tiempo que se obtiene mediante el desarrollo de
aplicaciones hibridas es inmejorable, sobre todo cuando dado el contexto prima el tiempo y la
capacidad de iterar bastante rápido, debido a que los requerimientos son cambiantes. A pesar de
que el rendimiento pueda resultar perjudicado, no es un factor determinante debido al avance
14
constante en el hardware de los teléfonos móviles de la mano de la unificación de estándares en
los motores web de los dispositivos y el avance de los frameworks híbridos, hacen que el
rendimiento de las aplicaciones híbridas este un camino de constante mejora. Por otro lado, la
solución a construir no necesita de un alto poder de cómputo, por lo que el acceso directo a los
recursos del smartphone no se justifica. En vista de esto, se decide optar por desarrollar una
aplicación móvil híbrida, utilizando Apache Córdova como base para construir la aplicación
móvil, dado que permite utilizar fácilmente tecnologías web para desarrollar aplicaciones. En
vista de esto y de ofrecer una experiencia similar a la nativa, se opta por utilizar Ionic1 como
framework web para desarrollar el frontend de la aplicación móvil.
3.3.2 Procesamiento de pagos
Para procesar pagos online en Chile existen distintas alternativas, cada una con distintas
características. Se evaluaron distintas alternativas para poder integrar en la aplicación móvil:
• Khipu: Medio de pago chileno basado en la simplificación de transferencias bancarias. Es
básicamente una interfaz simplificada y unificada del proceso de transferencia de varios
bancos nacionales. El usuario para pagar debe tener una cuenta en el sistema y debe
utilizar las credenciales de su banco cada vez para realizar transferencias entre personas y
al comercio utilizando una aplicación terminal nativa para cada sistema. La integración
para el comercio consiste en proveer una cuenta corriente donde se depositará el dinero y
utilizar un API REST provisto para crear cobros y recibir pagos. La comisión por
transacción es del 1% con tope de $300 pesos más IVA.
• Webpay Plus: Medio de pago chileno provisto por Transbank. Provee una interfaz donde
el usuario puede pagar mediante tarjetas de débito o crédito. El usuario por cada
transacción debe validar sus credenciales con su banco, ingresando su usuario y clave y la
tarjeta clave/digipass/multiclave dependiendo de la entidad bancaria. Para la integración
la empresa desarrolladora debe ser cliente de Transbank para luego implementar en el
servidor un Kit de conexión de comercio (KCC) provisto por Transbank, el cual consiste
en una serie de CGIs para validar el proceso de pago. La comisión por transacción varía
desde un 1,79% (Débito) y un 2,95% (Crédito) más IVA.
• Webpay Oneclick: Medio de pago chileno provisto por Transbank. Provee una interfaz
en donde el usuario puede inscribir un medio de pago (tarjeta de crédito) en un comercio,
validando previamente sus credenciales con el banco, para luego poder realizar pagos
recurrentes sin autorización previa. Para la integración, al igual que Webpay Plus, se debe
ser cliente de Transabank, pero a diferencia de este, OneClick expone un webservice
SOAP con endpoints para efectuar y validar el proceso de pago. La comisión por
transacción es del 2,95% más IVA.
• Flow: Es una plataforma de pagos chilena que provee una manera de cobrar mediante
Webpay plus, Servipag o Multicaja. Facilita la integración proveyendo una interfaz
unificada para estos servicios. La comisión va desde un 4,29% hasta un 4,99% más IVA
dependiendo del servicio a utilizar por el usuario final.
1 Ionic Framework: http://ionicframework.com
15
Haciendo una comparativa entre estos medios de pago en vista de los requerimientos, un punto
muy importante es la experiencia de uso y la facilidad. De las evaluadas, la que destaca es
Webpay Oneclick, ya que en contraste a sus alternativas en las cuales el usuario debe ingresar sus
datos cada vez que desee realizar un pago, esta permite realizar pagos simplificados, sin solicitar
la autorización del usuario. Esto es especialmente útil en el contexto móvil donde el usuario en
muchas ocasiones no lleva consigo multipass/tarjeta clave/digipass. Esto sumado a que las
interfaces del proceso de pago de las alternativas al momento de la elaboración esta memoria, no
están optimizadas para el uso en dispositivos móviles, hace que la experiencia del usuario no sea
la ideal. Khipu posee una aplicación nativa móvil, mejorando la experiencia del usuario, pero a
pesar de esto, la experiencia general no es ideal ya que el usuario necesita de sus credenciales
bancarias sumado a que posea no sólo una sino dos aplicaciones instaladas (la desarrollada más la
de Khipu) en su dispositivo para poder pagar. Webpay Oneclick a pesar de que la interfaz de
inscripción es igual o similar a la de transacciones de Webpay Plus, el usuario debe interactuar
con ella sólo una vez por tarjeta que desee inscribir, para luego poder realizar pagos mediante
sólo un click.
Khipu Webpay Plus Webpay Oneclick Flow
Tipo de pago Débito
(Transferencia) Débito/Crédito Crédito Débito/Crédito
Comisión (+ IVA) 1% (con tope
$300) 1,79% a 2,95% 2,95% 4,29% a 4,99%
Mantención $0 0,48UF + IVA /
mensual $0 $0
Velocidad de
integración Rápida Mediana Rápida Rápida
Uso de
Multipass/Tarjeta
clave/Digipass
En cada
transacción
En cada
transacción En la inscripción En cada transacción
Experiencia Móvil Mediana Baja Mediana Alta Baja
Requisitos en Móvil
Aplicación +
Credencial
bancaria
Credencial
bancaria
Credencial
bancaria por
tarjeta
Credencial bancaria
Tabla 1: Comparativa medios de pago online chilenos
De esta manera, para poder generar un flujo sencillo y rápido de pago, se opta por integrar
Webpay Oneclick en la aplicación.
16
3.3.3 División de la cuenta
La división de la cuenta es un punto crítico de la propuesta de solución, ya que implica
una interacción constante entre los usuarios. Esta presenta un desafío debido a que la interacción
se produce en múltiples dispositivos a través de internet y para que la interacción sea fluida,
cualquier retraso existente para conciliar el estado de la división resulta desfavorable para la
experiencia del usuario. Se debe tomar en cuenta el uso de datos en los dispositivos móviles, ya
que se trabaja con conexiones de menor velocidad y de tarifa variable, por lo que muchos
usuarios se verán perjudicados si la solución utiliza de manera abundante sus datos.
Para esto se propone utilizar una tecnología que permita la comunicación en tiempo real de los
datos. Las estrategias habituales para resolver este problema consisten en hacer “Long polling” o
constantes llamadas AJAX al servidor, pero esto no es lo ideal ya que al escalar significa
sobrecargar el servidor con múltiples llamadas por usuario, sin mencionar el constante uso de los
datos celulares. Websockets proveen un canal de comunicación en tiempo real, bi-direccional por
lo que resuelve este problema a cabalidad. No sólo eso, si no que el uso de datos se ve reducido,
debido a que el handshake TCP inicial se realiza sólo una vez, por lo que no existe el overhead
causado por el header para cada mensaje, limitándose sólo a llamadas de keep-alive periódicas y
a los datos de los mensajes entre clientes.
3.3.4 API (Backend)
En vista del análisis anterior, se debe elegir un framework que permita la integración de
los distintos componentes junto con brindar agilidad en el desarrollo. Fueron evaluados 3
populares frameworks que cumplían con los requerimientos de la propuesta de solución:
• Ruby on Rails (v4.2.1): Es un framework de código abierto escrito en Ruby, siguiendo el
paradigma MVC. Trata de combinar la simplicidad con la posibilidad de desarrollar la
aplicación escribiendo menos código que con otros frameworks y con un mínimo de
configuración, siguiendo el patrón de convención sobre configuración (CoC), el cual
busca minimizar el número de decisiones que un desarrollador necesita hacer, ganando así
en simplicidad, pero no perdiendo flexibilidad por ello.
• Sails.js (v0.11.4): Es un framework código abierto basado en Node.js y el framework
Express. Está diseñado para emular el familiar patrón MVC y CoC de frameworks como
Ruby on Rails, pero con soporte para los requerimientos de aplicaciones modernas: APIs
orientadas a los datos con una arquitectura escalable y orientada a servicios.
• Django: Es un framework de código abierto escrito en Python, siguiendo del paradigma
MVC. Facilita la creación de sitios web complejos, poniendo énfasis en el re-uso, la
conectividad y extensibilidad de componentes, el desarrollo rápido y el principio DRY
(De las siglas en inglés “dont repeat yourself” o no te repitas).
Los frameworks evaluados son bastantes similares entre sí: Están basados en el paradigma MVC,
poseen scaffolding, el cual es una técnica que permite especificar cómo será usada la base de
datos de una aplicación mediante el uso de comandos específicos, acelerando de esta manera el
desarrollo; un ORM (Object-Relational mapping) el cual permite utilizar una base de datos
orientada a objetos virtual, sobre la base de datos relacional, permitiendo el uso de características
propias de este tipo de programación; y siguen el paradigma de convención sobre configuración.
17
Los 3 poseen una comunidad bastante activa y documentación y paquetes para manejar múltiples
circunstancias. Con cualquiera de ellos es posible desarrollar una aplicación de manera rápida,
que sea escalable, rápida y robusta.
Ruby on Rails Sails.js Django
Lenguaje Ruby Node.js (JavaScript) Python
Paradigma MVC MVC MVC
Scaffolding Sí Sí Sí
ORM ActiveRecord Waterline QuerySets
Soporte Websockets Mediante módulos
externos al framwork Incorporado
Mediante módulos
externos al framework
Tabla 2: Comparativa entre frameworks de desarrollo web
Con respecto al soporte de websockets, destaca entre ellos Sails.js, ya que posee esta tecnología
incorporada (mediante socket.io) a su scaffold. En los demás no existe una manera simplificada
de abarcar eventos asíncronos derivados de las interacciones con Websockets, esto debido en
parte a que la “asincronicidad” no es parte del paradigma principal del diseño para ellos, como lo
es para Sails.js y Node.js.
Gracias a esto, es muy fácil generar aplicaciones con soporte en tiempo real con sólo unos pocos
comandos. Además, todas las rutas REST generadas poseen soporte de websockets, por lo que
facilita el desarrollo de aplicaciones de este tipo, ya que no es necesario definir canales, mensajes
y sus protocolos, debido a que existen previamente configurados.
Cabe mencionar que como además la lógica de la aplicación móvil también será desarrollada
utilizando tecnologías web, mediante Apache Cordova e Ionic, por lo tanto, utilizando Javascript,
al utilizar Sails.js es posible manejar un stack unificado en torno a este lenguaje, pudiendo
reutilizar código entre ambos y conocimientos de los desarrolladores de manera transversal.
Por las razones anteriores, se decide utilizar Sails.js como framework para desarrollar el backend.
3.3.5 Arquitectura
Para montar el backend se levantó una instancia EC2 M3.Large en Amazon AWS, la cual
consiste en una máquina virtual compuesta por 2 CPU virtuales 7,5 GiB de memoria y 32GB de
almacenamiento SSD. Esta corre sobre Ubuntu 14.04 LTS de 64 bits. Se montó en ella Dokku2
v.0.4.1, una plataforma PaaS basada en Docker, la cual permite montar la arquitectura completa,
permitiendo pasar a producción los distintos componentes como contenedores en la plataforma
mediante simples comandos git, automatizando las labores necesarias para hacer deploy de las
2 Dokku - https://github.com/dokku/dokku
18
tecnologías. Provee además plugins que permiten manejar bases de datos y otros componentes,
como autorización, certificados SSL, entre otros. De esta manera se gana en agilidad en el
desarrollo, permitiendo realizar una integración continua de los componentes.
Como base de datos se utilizó MongoDB y Redis para el almacenamiento de la información de
sesión de los websockets.
Figura 4: Diagrama de la arquitectura final de la aplicación
19
4 Desarrollo
En este capítulo, se describirá el desarrollo de las componentes compartidas y las
características principales de la propuesta de solución.
4.1 Componentes compartidas
Estas consisten en módulos o sistemas que son transversales en torno a las características
de la aplicación.
4.1.1 Modelo de Datos
En base a los requerimientos se diseñó un modelo de datos que pudiera representar de
manera apropiada la información del sistema. Se identificaron 6 entidades principales: Location,
Party, User, Card, Review y Payment.
Figura 5: Modelo de datos
Location posee los datos de contacto de los locales, junto a las coordenadas geográficas y los
datos de conexión al punto de venta.
Party representa una cuenta en la cual interactúan los usuarios, la cual posee el identificador del
ticket y su información en un objeto, lo cual es provisto por NoSQL, por lo que no se necesita de
20
serializarlo. También posee un objeto que representa las apropiaciones de ítems de usuarios (se
verá esto en detalle más adelante).
Un User puede tener múltiples Cards, estar asociado a múltiples Partys y realizar múltiples
Reviews y Payments.
En torno a la escalabilidad, se tomó en cuenta que en un futuro es probable que sea necesario
implementar más medios de procesamiento de pagos, por lo que se definió un objeto Gateway y
Gateway_data en Card y Payment respectivamente, los cuales definen los parámetros específicos
que pudieran ser requeridos por cada medio de procesamiento de tarjetas.
4.1.2 Seguridad
En torno a este apartado, se utilizó SSL/TLS para encriptar todas las comunicaciones
(incluyendo websockets a través de wss:) y utilizar JSON Web Tokens como forma de
autenticación entre las partes.
Cabe mencionar que a pesar de que se procesen pagos, no se maneja información sensible de
ellos, debido a que se utiliza un tercero que provee este servicio. Los pagos se encuentran
“tokenizados” y el token en sí mismo no sirve sin los certificados adecuados. Se verá esto en la
sección 4.4.
4.1.2.1 Autenticación
Cuando el usuario inicia sesión de manera exitosa con sus credenciales (usuario y
contraseña, Facebook OAuth o Google OAuth), se le devuelve su información más un JWT. Este
es almacenado por la aplicación de manera local en el dispositivo. Cuando el usuario desea
acceder a una ruta protegida o recurso, la aplicación envía de manera automática el JWT
almacenado (de existir uno), utilizando el header Authorization, utilizando el schema Bearer. El
contenido del header es el siguiente:
Código 1: Contenido header JWT
Esto es un mecanismo de autenticación “stateless” (sin estado), ya que el estado del usuario
nunca es almacenado en la memoria del servidor. Las rutas protegidas del servidor verificarán si
existe un JWT válido en el header Authorization, y si se encuentra presente, el usuario podrá
acceder al recurso protegido. Como los JWT son auto-contenidos, toda la información necesaria
ya se encuentra en ellos, reduciendo la necesidad de realizar consultas a la base de datos
múltiples veces. El payload del JWT contiene lo siguiente:
Código 2: Payload JWT
Authorization: Bearer <token>
{ id: <user_id>, jti: <unique_token_id>, scopes: [<resource_1>, <resource_2>, …] }
21
Donde el id representa al id asociada al usuario, jti representa a un id único del token, el cual se
puede utilizar para revocación y scopes a un arreglo de permisos asociados a él. La expiración del
token se configuró en 30 días a contar de la fecha de emisión.
Figura 6: Interacción proceso de autenticación
4.1.3 Interfaz principal de la aplicación móvil
A continuación, se describirán los componentes compartidos de la interfaz por las
características principales.
4.1.3.1 Directrices de diseño entre plataformas.
Para el diseño la interfaz, se tomaron en cuenta las directrices de diseño existentes para
cada plataforma, tanto para Android como para iOS (Material Design 3 y Human Interface 4
respectivamente), de manera de utilizar convenciones a las que el usuario ya está acostumbrado,
entregando una experiencia consistente en su plataforma.
Por ejemplo, en la barra de título en iOS los títulos se encuentran centrados y el botón de regreso
de la navegación posee texto (siendo el nombre de la vista anterior, o atrás), en cambio en
Android, la barra tiene una altura mayor y posee sombreado, el título se encuentra justificado a la
izquierda y el botón de regreso es simplemente el ícono de la plataforma que indica atrás.
3 Material Design - https://material.google.com/ 4 Human Interface Guidelines - https://developer.apple.com/ios/human-interface-guidelines/
22
Figura 7: Comparativa barra de título entre plataformas
Los botones en Android también poseen un sombrado (o elevación según las directrices de la
plataforma) y se despliega su texto en mayúscula, al contrario que con iOS, donde los botones
son “planos”.
Figura 8: Comparativa botón entre plataformas
El objetivo de estas directrices es proveer un estándar de calidad al usuario para lograr una mayor
usabilidad.
4.1.3.2 Registro y Log-in
Para el registro y log-in de la aplicación, se intentó realizar un flujo sencillo, de manera
que el usuario pueda empezar a utilizar rápidamente la aplicación. Para ello se optó por utilizar
un ingreso mediante credenciales de cuentas que posea el usuario, en particular Google y
Facebook proveen métodos OAuth para realizar log-in del usuario. De esta manera, se agiliza el
proceso de ingresar datos, ya que como se encuentra previamente con la sesión iniciada en el
servicio seleccionado en el dispositivo, no es necesario volver a ingresar las credenciales.
Como se puede observar en el flujo descrito por la Figura 9: Flujo de log-in y registro, también se
provee al usuario de un proceso de registro tradicional, compuesto por el ingreso de su correo y
contraseña, seguido por el ingreso de sus datos personales: nombre, apellido, fecha de nacimiento
(opcional) y género (opcional). Independientemente del método de registro, al usuario se le
consultará por el ingreso de un medio de pago (el cual se explicará en detalle más adelante), el
cual puede completar en otra ocasión.
23
Figura 9: Flujo de log-in y registro
4.1.3.3 Despliegue de establecimientos soportados
Para que el usuario pueda usar la aplicación en un establecimiento, es necesario listar los
establecimientos soportados para el usuario y proveer información sobre ellos, como por ejemplo
su dirección. Para ello se ideó una vista en la cual se listan los establecimientos disponibles junto
con una vista de detalle para cada uno la cual se puede observar en la Figura 10: Vista
establecimientos.
24
Figura 10: Vista establecimientos
Esta lista además se encuentra ordenada con respecto a su ubicación geográfica, con respecto a la
ubicación del usuario, utilizando el posicionamiento provisto por el GPS del dispositivo. De esta
manera, el lugar más cercano se encontrará primero y el más lejano al último. También el usuario
puede realizar una búsqueda de texto con respecto a ellos.
4.1.3.4 Menú lateral
El resto de las opciones se ubicó en un menú lateral ubicado al costado izquierdo de la
pantalla, accesible al hacer “swipe” desde el costado izquierdo de la pantalla o al presionar el
botón de menú ubicado en el extremo superior izquierdo de la vista de establecimientos. Se puede
observar en la Figura 11: Menú lateral.
25
Figura 11: Menú lateral
Se ideó su diseño pensando también en las directrices de diseño de las plataformas y permite
navegar hacia las siguientes secciones:
• Perfil: Permite al usuario editar su información de perfil, desde los datos básicos como
nombre o fecha de nacimiento, hasta la fotografía de perfil y contraseña.
• Billetera: Permite al usuario manejar los medios de pago inscritos. Podrá agregar o
eliminar tarjetas, así como también definir una como su favorita.
• Historial: vista que permite al usuario ver un registro de sus transacciones pasadas. Podrá
ver el detalle de consumo de cada una, así como también con quien compartió la cuenta.
• Cuenta de prueba: Permite al usuario ver e interactuar con la interfaz principal de cuenta
y de pago (que se describirán en detalle más adelante) y realizar un pago de prueba, es
decir, sin costo.
• Configuración: Permite al usuario cambiar sus ajustes, como la propina por defecto. Se
encuentra ubicado también aquí los términos y condiciones de uso y la opción de cerrar
sesión.
Las interfaces de cada una de estas secciones se pueden observar en la Figura 12: Secciones
menú lateral.
26
Figura 12: Secciones menú lateral
4.2 Despliegue de la información de la cuenta.
Para el desarrollo de esta característica se tenían los siguientes requisitos:
• Extracción de la información de la cuenta del usuario de los puntos de venta.
• Desplegar la información de en una interfaz de fácil aprendizaje y uso.
A continuación, se describirá las distintas componentes que fueron necesarias para cumplir estos
requisitos.
4.2.1 Módulo de Integración con Puntos de Venta
Este módulo corresponde a la integración con el POS (Point of Sale o punto de venta) del
restaurant o bar. Se separó en tres partes: 4.2.1.1 Servicio de POS o POS-Service (Backend),
4.2.1.2 POS-API (Cliente) y 4.2.1.3 Canal de comunicación con el POS (Cliente).
4.2.1.1 Servicio de POS
Corresponde a un módulo escrito en Node.js que se encuentra ubicado en el backend y
provee un canal de comunicación entre el API y la integración con el POS del restaurant o bar.
Lo llamaremos POS-Service. En vista de que existen diversos tipos de POS (dada la naturaleza
del problema) se diseñó este módulo con miras unificar la interfaz con la cual se extrae y envía
información a los POS mediante el uso de adaptadores. De esta manera, cada adaptador
representa la estrategia necesaria para la interacción con cada tipo de POS soportado.
Se realizó un estudio de la estructura de 3 sistemas puntos de venta comerciales distintos:
Methodo 5 , Restó 6 y Gour-net 7 . De esta manera reconocer patrones y estructuras de datos
5 Methodo POS: http://www.methodo.cl
27
compartidas por cada uno de ellos. Se identificó que las comandas o tickets, las cuales
representan el pedido del cliente, poseen un identificador numérico asociado, el cual es siempre
visible por el personal. Por lo tanto, para rescatar la información del pedido del cliente, basta
realizar una búsqueda sobre los tickets abiertos en el sistema mediante 4 dígitos que representan
los últimos números de la comanda. Es fácil ver que es bastante poco probable que exista un
conflicto ya que tendrían que existir 10.000 tickets abiertos en un solo restaurant o bar. De esta
manera, se simplifica enormemente la comunicación entre el cliente y el restaurant y por lo tanto
la conexión del cliente con su pedido en la aplicación móvil.
Figura 13: Diagrama de patrón strategy en adaptadores de POS-Service
Como se puede observar en el diagrama en la Figura 13, este módulo expone 4 funciones:
• getTicketById(id: string): Obtiene un ticket del POS mediante su id.
• getTicketByNumber(number: string): Obtiene un ticket abierto del POS mediante un
código, representado por los últimos cuatro del número de comanda. Si el ticket posee
menos de 4 dígitos, se agregarán 0’s a la izquierda hasta completar 4 dígitos. Por ejemplo,
“23” se convierte en “0023”.
• getTicketByTable(table: string): Obtiene un ticket abierto del POS mediante el número
o código de mesa.
• payTicket(id: string, amount: float, tip: float): Realiza un pago por “amount” y “tip”
en el POS en el ticket correspondiente al id especificado.
Cabe mencionar, que cada adaptador está encargado de realizar el parsing de la respuesta del
POS, basándose en la siguiente estructura representada en Código 3. De esta manera, se unifica la
respuesta de las funciones y se normaliza la información obtenida de los puntos de venta.
6 Restó POS: http://www.resto.cl 7 Gour-net POS: http://gour-net.cl/web
28
4.2.1.2 POS-API
Cada punto de venta en un bar o restaurant es un software distinto, implementado en
distintos lenguajes, con distintas interfaces, flujos y características. Esto presenta una dificultad a
la hora de modelar el acceso a variables que sean transversales y al tratar de conciliar la
experiencia para el restaurant.
{ id: '1234', // id único de ticket open: true, // Estado del ticket items: [ // Arreglo de ítems agregados al ticket { id: '5678', // id único de ítem name: 'Pie de Limón', // Nombre del ítem price: 2450.00, // Precio del ítem quantity: 1, // Cantidad del ítem discount: 0, // Descuento en % modifiers: [ // Variables Modificadoras del ítem { name: 'Sin Merengue', // Nombre del modificador price: 0, // Precio del modificador quantity: 1 // Cantidad del modificador } ] }, ], payments: [ // Arreglo de pagos en el ticket { id: 'asd123', // id único de pago amount: 1000.00, // Monto del pago tip: 100.00 // Propina asociada al pago } ], totals: { // Totales del ticket due: 1450.00, // Restante total: 2450.00, // Total }, table: { // Mesa del ticket number: '43' // Número de mesa seats: 5 // Asientos en la mesa }, employee: { // Empleado o mozo que atiende ticket id: '123', // Id único del mozo name: 'María Pérez', // Nombre del mozo },
Código 3: Estructura de ticket JSON
29
Figura 14: Ejemplos de interfaces de POS de restaurantes
En base al estudio realizado sobre los POS, a nivel primordial todos permiten al staff ingresar los
pedidos de los clientes y registrar pagos. Debido a esto, se propone realizar un servicio web
REST que se integre de manera adhoc a los POS y que permita rescatar información exponiendo
3 endpoints de manera unificada:
• Obtener tickets: Retorna un arreglo JSON con información de los tickets del sistema.
• Obtener ticket específico mediante su id: Retorna un JSON con información de un
ticket específico correspondiente a un id.
• Registrar pago: Permite registrar un pago en el punto de venta (monto y propina
mediante un objeto JSON)
Así, independientemente de cómo esté implementado el punto de venta, la estrategia para
manipular la información será consistente entre ellos. De esta manera, el backend podrá realizar
llamadas http a los POS para extraer e insertar información. Se verá esto a continuación.
4.2.1.3 Canal de comunicación con el POS
Ya que los puntos de venta están instalados de manera local en el establecimiento de bares
y restaurantes, para acceder a ellos requiere que la máquina esté disponible en internet, eso quiere
30
decir, que exista una manera para que el servidor pueda realizar llamadas al servicio web provisto
por la integración con el POS. El enfoque general es exponer el servidor local a internet, pero
esto es en general es difícil de realizar, ya que implica conocer la arquitectura de red del
establecimiento y adaptarla o configurarla (sin tomar en cuenta las implicancias de seguridad de
esta acción), sumado a que la mayoría de las conexiones poseen una IP dinámica, por lo que se le
debe asignar un host dinámico. Claramente este enfoque no es el indicado si se pretende escalar e
instalar en múltiples restaurantes, ya que el sobrecosto asociado a la configuración y mantención
de la conexión no son menores.
En vista de lo anterior, se propuso una solución basada en websockets que permite la
comunicación bidireccional entre el backend y el POS con el sólo requisito de que el computador
local esté conectado a internet, sin tener que configurar la red para exponerlo. Esto funciona de la
siguiente manera:
Existe un cliente escrito en Node.js corriendo como servicio en la máquina local del
establecimiento. Este se conecta mediante websockets al módulo de POS-Service ubicado en el
backend, el cual es visible públicamente en una URL. Al establecer una conexión, el cliente envía
sus credenciales, enviando el id del POS al cual sirve. El POS-Service asocia la conexión de este
socket al id del POS provisto. Este, al momento de que existe una llamada por parte de la API,
busca el socket de conexión mediante el pos_id provisto en la llamada y envía un mensaje al
cliente con los datos de la llamada del al servicio REST del POS.
Como se puede observar en el Código 4: Ejemplo de cuerpo de llamada JSON a cliente, el cuerpo
consiste con los datos necesarios para realizar una llamada http de manera local. El cliente con
estos datos realiza una llamada al servicio REST de la integración con el punto de venta y retorna
la respuesta con un mensaje de webservice al POS-Service.
4.2.2 Interfaz aplicación móvil
El flujo de la propuesta de solución para este apartado fue modelado de la siguiente
manera en la interfaz:
1. El usuario elige el establecimiento en donde se encuentra en la vista de locaciones.
2. Se le dirige a la vista de check-in, donde debe ingresar un código correspondiente a los
últimos 4 dígitos de la comanda. (El cual se lo dará el mesero).
{ method: 'GET', url: 'http://localhost:8080/tickets/2311, headers: { 'Authorization': 'Basic ' + opts.pos_key }, data: null }
Código 4: Ejemplo de cuerpo de llamada JSON a cliente
31
3. El usuario ingresa el código, de ser correcto, se le muestra un mensaje de éxito y se le
dirige a la vista de cuenta. De ser erróneo se le muestra un mensaje de error y se le
devuelve a la misma vista.
4. El usuario se le dirige a la vista de cuenta donde podrá ver el estado de su cuenta.
5. Si el usuario ordena más cosas, podrá realizar un gesto de “Pull to refresh” para actualizar
los datos de la cuenta.
Figura 15: Flujo de despliegue de información de la cuenta - 1
32
Figura 16: Flujo de despliegue de información de la cuenta - 2
4.3 División de la cuenta
Para evaluar los requisitos de esta característica, debido a su naturaleza interactiva es
necesario realizar un análisis de los tipos de interacción que ocurren al momento de división de la
cuenta por parte de los usuarios.
Se describirán los tipos de interacción en base a 3 actores y su interacción en distintos casos de
división en base a una cuenta predeterminada a modo de ejemplo.
La cuenta está compuesta por lo siguiente:
Ítem Precio Cantidad Total
Bebida $1.500 2 $3.000
Jugo de Pera $1.000 1 $1.000
Mega hamburguesa $4.000 2 $8.000
Papas fritas $6.000 1 $6.000
Copa de Helado $2.000 3 $6.000
Total $24.000
Llamaremos a los actores Josefa, Sebastián y Cristian para mayor conveniencia y legibilidad de
los ejemplos.
33
4.3.1 Caso 1: División Equitativa
Se describirá este caso como en el cual la división se realiza sobre el total de la cuenta.
Para este caso existen dos escenarios:
En el primero, Josefa, Sebastián y Cristian desean pagar de manera equitativa por el total de lo
consumido, por lo que cada uno desea pagar un tercio del importe, es decir, $8.000.
Gráfico 1: División equitativa - Pago equitativo
En el segundo escenario, Cristian desea pagar un tercio del importe ($8.000) pero Sebastián desea
“invitar” (pagar por lo consumido) a Josefa. Por lo que Sebastián pagaría dos tercios del importe
($16.000).
Gráfico 2: División equitativa - Invitación
Josefa34%
Sebastián33%
Cristian33%
Divisisión equitativa: Pago equitativo
Josefa Sebastián Cristian
Josefa0%
Sebastián67%
Cristian33%
División equitativa: Invitación
Josefa Sebastián Cristian
34
Para abarcar estos dos escenarios, se diseñó una interfaz que permitiera a los actores de manera
fácil definir el pago de una fracción del total de la cuenta utilizando el lenguaje natural. Esta
abstracción consiste en que los usuarios deben armar una frase mediante dos selectores de la
siguiente manera:
“Dividir entre 𝑥, pagar por 𝑦”
Donde 𝑥 es el selector equivalente al número de personas que consumieron (entre los que se
desea dividir la cuenta). 𝑦 corresponde al selector de número de personas por la que se desea
pagar. Se realiza la siguiente operación:
𝑡𝑢 = 𝑡𝑐 ∗𝑦
𝑥
Donde 𝑡𝑢 es el total del usuario y 𝑡𝑐 es el total de la cuenta. Al mover los selectores, se actualiza
el total automáticamente en pantalla. Se puede observar el resultado en la Figura 17.
Figura 17: Interfaz división equitativa
Ahora volviendo a los escenarios descritos anteriormente para este caso, para satisfacer el
primero basta que cada uno de los actores se dirija a la pantalla de división equitativa y
seleccione: “Dividir entre 3, pagar por 1”, como podemos observar en la Figura 18.
35
Figura 18: División equitativa - Ejemplo primer escenario
Para el segundo escenario, basta que Cristian seleccione: “Dividir entre 3, pagar por 1” y
Sebastián seleccione: “Dividir entre 3, pagar por 2” ya que efectivamente estará pagando por él
y Josefa.
Figura 19: División equitativa - Ejemplo segundo escenario
36
4.3.2 Caso 2: División por ítem
Se describirá este caso como en el cual la división se realiza sobre lo consumido, es decir,
sobre la cantidad de elementos de la cuenta que consumió cada uno. Para este caso existen tres
escenarios:
En el primero, cada uno de los actores consumió ítems excluyentes entre ellos.
Actor Consumió Total
Josefa
1 x Jugo de Pera - $1.000
1 x Mega Hamburguesa - $4.000
1 x Copa de Helado - $2.000
$7.000
Sebastián
1 x Bebida - $1.500
1 x Mega Hamburguesa - $4.000
1 x Copa de Helado - $2.000
$7.500
Cristian
1 x Bebida - $1.500
1 x Papas Fritas - $6.000
1 x Copa de Helado - $2.000
$9.500
Tabla 3: División por ítem - Primer escenario
En el segundo escenario, Josefa, Sebastián y Cristian compartieron ítems, es decir, consumieron
de manera compartida uno más ítems de la cuenta. De esta manera, desean pagar por los ítems
que fueron compartidos de manera equitativa.
Actor Consumió Total
Josefa
1 x Jugo de Pera - $1.000
1/3 x Papas Fritas - $2.000
1 x Copa de Helado - $2.000
$5.000
Sebastián
1 x Bebida - $1.500
1 x Mega Hamburguesa - $4.000
1/3 x Papas Fritas - $2.000
1 x Copa de Helado - $2.000
$9.500
Cristian
1 x Bebida - $1.500
1 x Mega Hamburguesa - $4.000
1/3 x Papas Fritas - $2.000
1 x Copa de Helado - $2.000
$9.500
Tabla 4: División por ítem - Segundo escenario
37
En el tercer escenario, Josefa, Sebastián y Cristian compartieron un ítem, pero Cristian desea
pagar a Sebastián su parte. De esta manera, Josefa desea pagar $2.000 y Cristian debiera pagar
$4.000 equivalente a dos tercios del ítem compartido (Papas fritas).
Actor Consumió Total
Josefa
1 x Jugo de Pera - $1.000
1/3 x Papas Fritas - $2.000
1 x Copa de Helado - $2.000
$5.000
Sebastián
1 x Bebida - $1.500
1 x Mega Hamburguesa - $4.000
1 x Copa de Helado - $2.000
$7.500
Cristian
1 x Bebida - $1.500
1 x Mega Hamburguesa - $4.000
2/3 x Papas Fritas - $4.000
1 x Copa de Helado - $2.000
$11.500
Tabla 5: División por ítem - Tercer escenario
Como se puede observar del análisis de estos escenarios, este caso comprende una gran cantidad
de colaboración e interacción por parte de los usuarios, los que deben conciliar las divisiones
correspondientes a cada ítem. Para facilitar la tarea de los usuarios y emplear una interfaz lo más
intuitiva posible, se optó por la siguiente abstracción:
Los usuarios poseen una lista de “casillas” correspondientes a los ítems. Cada casilla posee un
valor el cual está determinado por el precio y cantidad de cada ítem. Cada usuario posee un
arreglo infinito de “fichas” sin valor. Si un usuario coloca “ficha” en una casilla, lo que equivale
a haber consumido algo de esa casilla, esta pasa a tener el valor de la casilla. Cada usuario paga
por el valor de todas sus fichas. Si otro usuario coloca su ficha en esa casilla, como existen 2
fichas en esa casilla, se divide el total de la casilla entre las dos fichas, por lo que cada usuario
paga la mitad del total de la casilla. La ecuación para calcular el total por usuario 𝑡𝑢 sería la
siguiente:
𝑡𝑢 =
{
𝑓𝑢 > 0, ∑
𝑓𝑢𝑖𝑓𝑡𝑖𝐶𝑉𝑖
𝑛
𝑖=1
𝑓𝑢 = 0 ∧ 𝑓𝑡 > 0, ∑𝐶𝑉𝑖
𝑛
𝑖=1
− ∑𝑒𝑓𝑖𝐶𝑉𝑖
𝑛
𝑖=1
Donde 𝑛 es el número de casillas, 𝑓𝑢 es el número de fichas del usuario en la casilla, 𝑓𝑡 es el
número de fichas totales en la casilla, 𝑒𝑓𝑖 corresponde a la existencia de fichas en la casilla; si
existe, entonces 𝑒𝑓𝑖 = 1, si no, 𝑒𝑓𝑖 = 0. 𝐶𝑉 representa el valor de la casilla, el cual está definido
por:
38
𝐶𝑉 = 𝑃𝑖 ∗ 𝑄𝑖
Donde 𝑃𝑖 corresponde al precio del ítem y 𝑄𝑖 corresponde a la cantidad del ítem.
Por ejemplo, si existen 2 casillas 𝐴 y 𝐵 , con 𝐶𝑉𝐴 = 20 y 𝐶𝑉𝐵 = 10, si 𝑢1 consumió 𝐴 y 𝐵, 𝑢2
consumió 𝐴, entonces:
𝑡𝑢1 =1
2∗ 20 +
1
1∗ 10 = 20
𝑡𝑢2 = 1
2∗ 20 +
0
1∗ 10 = 10
Ahora, si existen las mismas casillas 𝐴 y 𝐵, con los mismos valores, pero 𝑢1 consumió 𝐵 y 𝑢2
quiere pagar lo restante:
𝑡𝑢1 =0
1∗ 20 +
1
1∗ 10 = 10
𝑡𝑢2 = 20 + 10 − 0 ∗ 20 – 1 ∗ 10 = 20
Luego, para trasladar esta abstracción a una interfaz amigable, se requiere de una sincronización
permanente de los estados de los distintos usuarios, ya que para calcular el total se necesita el
total de las fichas existentes en cada casilla en todo momento. De otra manera podría resultar en
errores en el cálculo de la cuenta de algún usuario, lo que es inaceptable. Se evaluaron tres
estrategias para realizar esto: polling, notificaciones push y websockets.
La estrategia de polling consiste en realizar una operación de consulta constante al servidor en
intervalos, de manera de actualizar el estado. El problema de esta estrategia es que es muy
costosa en torno a uso de los recursos del servidor (sobre todo CPU) y en torno al uso de la red,
debido a que debe realizar una conexión TCP por cada consulta, la cual ya en sí es costosa
(pensando en escalar también), independientemente de que se haya o no actualizado realmente el
estado.
Las notificaciones push permiten utilizar mejor los recursos del servido y desligar al cliente de
estar constantemente consultando al servidor, ya que debe simplemente escuchar a un evento de
la notificación (lo que es provisto por el sistema operativo) cuando se necesite actualizarlo. Esto
en la teoría debiera funcionar, pero los servicios provistos por iOS y Android, APNS y GCN
respectivamente, no son confiables o fehacientes ya que estos no garantizan la entrega del
mensaje al cliente, sumado a que existe un cierto retraso con respecto a la entrega de la
notificación (que en algunos casos puede llegar a los varios segundos) lo que es bastante
perjudicial para la experiencia del usuario.
Por último, utilizar websockets permite realizar una conexión TCP una vez para luego escuchar
eventos desde el servidor de manera bidireccional. De esta manera se logra lo mismo que con
notificaciones push, sumado a que es un canal bidireccional lo que lo hace más eficiente en torno
39
al uso de la red. Además, permite una comunicación con muy poco retraso, casi en tiempo real.
Es por esto que se eligió utilizar websockets como la estrategia para desarrollar esta interacción.
Aplicándolo a la abstracción, una vez que un usuario pone una ficha en una casilla, notifica al
servidor y este realiza un broadcast del evento a todos los usuarios suscritos a esa cuenta,
actualizando los estados de todos.
Figura 20: División por ítem – Representación de flujo websockets
Cada cliente al recibir un mensaje del servidor, actualiza el cálculo del total y despliega el estado
actual de las fichas en las casillas. La interfaz se diseñó y desarrolló en torno a esto.
Para la interfaz, se utilizó la vista de la información de la cuenta, pero si cualquier usuario
selecciona algún ítem de la lista, presionando en él, esta automáticamente se convierte en la vista
de división por ítem, mostrando las fichas actuales y el nuevo total para el usuario, desplegándolo
en el botón de pagar. Para deseleccionar el ítem, basta con presionar nuevamente el ítem
previamente seleccionado.
40
Como se puede observar en Figura 21, Figura 22 y Figura 23, el estado de la cuenta se despliega
para todos los usuarios, permitiendo a cada usuario ver sus fichas y la de los demás. Desaparece
el botón de la división equitativa, quedando sólo el botón de pago, el cual actualiza el total de
manera inmediata al producirse un cambio en el estado de las fichas de la cuenta.
Cabe mencionar que cada ítem seleccionado por el propio usuario se “oscurece”, permitiendo
verificar a simple vista qué ítems son los que pagará. Por ejemplo, en la Figura 21 Josefa
seleccionó el jugo de pera, la mega hamburguesa y la copa de helado, por lo que cada uno de esos
ítems se encuentra más oscuro que los demás. Los ítems seleccionados por otros usuarios en los
cuales el usuario no participa, mantienen su color, pero sí muestran la ficha del usuario el cual se
adjudicó el ítem.
Existe también un botón al costado de cada ítem seleccionado por el usuario, representado por un
signo de suma (+), que permite ingresar fichas adicionales a la casilla o ítem, de manera pagar
por otra persona. Si se selecciona, se agrega un indicador a la ficha del usuario, el cual representa
la cantidad de fichas que posee el usuario en aquella casilla o ítem. Se puede observar esto en la
Figura 23, la cual representa el tercer escenario, donde Cristian paga por Sebastián las papas
fritas. Para restar fichas de la casilla, basta simplemente presionarla.
Figura 21: División por ítem – Primer escenario
41
Figura 22: División por ítem - Segundo escenario
Figura 23: División por ítem - Tercer escenario
42
4.4 Pagar la cuenta
Para el desarrollo de esta característica se tenían los siguientes requisitos:
• Integración con el medio de pago (en este caso Webpay Oneclick).
• Inscripción de múltiples tarjetas por parte de los usuarios.
• Registrar el pago en el punto de venta.
• Interfaz amigable que permita un pago rápido y sencillo.
A continuación, se describirán las distintas componentes que fueron necesarias para cumplir estos
requisitos.
4.4.1 Gateway service
En vista de que en el futuro podrían existir otros medios de pago, se desarrolló un módulo
que actúa como wrapper de las funciones de las integraciones de los medios de pago. En el caso
de la aplicación, en un principio estará asociado a las funciones que permiten la operación
completa del procesador de Webpay Oneclick. Se exponen 5 endpoints:
• Iniciar inscripción de tarjeta: Permite iniciar el proceso de inscripción de tarjeta.
Retorna la URL a la cual se redirige el usuario.
• Finalizar inscripción de tarjeta: Permite finalizar el proceso de inscripción de tarjeta,
mediante la respuesta obtenida en la primera parte del proceso. Retorna los datos del
usuario si este fue exitoso o error en el caso contrario.
• Desinscribir tarjeta: Permite desinscribir una tarjeta del usuario en el sistema.
• Autorizar pago: Permite autorizar un pago para una tarjeta inscrita, por un monto
establecido. Retornará los datos del pago en caso de éxito o error en el caso contrario.
• Reversar pago: Permite realizar una reversa de un pago realizado previamente con éxito,
en el caso de un cobro erróneo, especificando el id de la operación.
En este módulo se encuentran también los certificados correspondientes a la validación de las
llamadas del API SOAP provista por Oneclick. Esta validación es parte del proceso de
certificación de Transbank y permite asegurar que las respuestas provienen de una entidad
confiable.
4.4.2 Inscripción de tarjetas
El flujo de inscripción de tarjetas de Webpay Oneclick, se puede observar en el diagrama
de secuencia representado por la Figura 24: Diagrama de secuencia de inscripción de tarjetas
Webpay Oneclick.
El usuario puede iniciar el proceso a través de dos interfaces: Una ubicada al momento del
registro y otra en la vista billetera, la cual puede ser observada en la Figura 12.
43
Figura 24: Diagrama de secuencia de inscripción de tarjetas Webpay Oneclick
44
Figura 25: Pantallas de inicio de inscripción de tarjeta
Una vez iniciado el flujo, se dirige al usuario a un webview en el cual realiza la inscripción
mediante la interfaz web provista por Oneclick, representadas en la Figura 25: Pantallas de inicio
de inscripción de tarjeta. La particularidad de este tipo de inscripción, es que los datos
relacionados a la tarjeta los maneja Webpay, retornando sólo al final de la inscripción un token
que identifica al usuario, junto con el tipo de tarjeta y los últimos 4 dígitos, para que el usuario
pueda identificarla. De esta manera, se desliga al integrador de la responsabilidad de salvaguardar
los datos bancarios, ya que, ante una eventual brecha de seguridad, no es posible extraer los datos
de tarjeta de los usuarios, ya que simplemente no existen en el sistema.
Cabe mencionar que cada banco posee una interfaz distinta, pudiendo requerir distintos datos
entre ellas. Una vez terminado el flujo de inscripción, se muestra una pantalla de éxito o fracaso y
se retorna al usuario a la aplicación, viendo reflejado el estado de sus tarjetas inscritas. Desde ese
punto en adelante, está habilitado para hacer pagos en la aplicación.
45
Figura 26: Flujo inscripción webview
Con respecto a la inscripción de múltiples tarjetas por usuario, existe una limitación técnica de
Webpay Oneclick, ya que existe un límite impuesto de una tarjeta por username en el comercio,
en este caso la solución. Para resolver esto, se optó por realizar la inscripción concatenando la
fecha actual con el email del usuario, generando así un email válido para el sistema. Luego, en el
callback del pago, se inserta una variable en la URL que corresponde al usuario para asociar
aquel username a los datos de la tarjeta, para luego poder realizar operaciones como autorizar un
pago, anular un pago o desinscribir la tarjeta. Se desconoce la razón detrás de este límite por parte
de Transbank.
46
4.4.3 Pago
El flujo de pago de Webpay Oneclick, como se puede observar en el diagrama de
interacción representado por la Figura 27, consiste en autorizar un pago para el medio de pago del
usuario y luego registrarlo en el punto de venta. El pago se realiza mediante el Gateway Service y
el registro mediante la integración de con el punto de venta descrita previamente en la sección
4.2.1.
Al inicio del flujo, la aplicación solicita el pago al backend, el cual primero verifica que este está
disponible para interactuar y actualiza a la última versión del ticket en el sistema. Una vez que se
obtienen los datos, se realiza una llamada de autorización de pago a Webpay Oneclick (mediante
el Gateway service descrito en el capítulo 5.3.1). De ser exitoso el pago, se notifica a la
aplicación la cual despliega los datos del pago al usuario, notificando a su vez al backend. El
backend entonces registra el pago en el POS, mediante el POS-Service.
Si un pago no es notificado, es decir, el usuario no pudo ver los datos del pago en la aplicación
por cualquier motivo (por ejemplo, se cayó el acceso a internet en ese mismo instante), no podrá
ver la confirmación de la transacción por lo que el pago no será registrado en el POS y se debe
reversar, a pesar de que este fue exitoso. Se mostrará un error al usuario y se le pedirá que intente
nuevamente. Existe una tarea cron ejecutándose cada minuto, que verifica los pagos pendientes, o
sea, que no han sido notificados. Si detecta que un pago lleva en estado pendiente más de 1
minuto, realiza la reversa automática del pago mediante el Gateway Service. No existen mayores
implicaciones de cara al usuario ya que podrá efectuar el pago con normalidad a continuación.
La interfaz del pago en la aplicación móvil, que observa en la Figura 28, comienza al ingresar a la
pantalla de resumen. En ella se puede ver el total a pagar y se ofrece la opción de ingresar la
propina por el servicio, seleccionada la opción de 10% por defecto. El sistema calcula la propina
automáticamente con respecto al porcentaje que elija el usuario. Una vez que desee pagar,
presiona el botón inferior para ir al popup de confirmación. En este popup puede elegir pagar con
su medio de pago predeterminado o favorito o elegir otro medio de pago previamente ingresado.
Una vez que el usuario presiona pagar, se realiza el flujo en el backend descrito en la Figura 27.
En el caso de existir un error, se le notifica mediante un “toast” (mensaje flotante) en la parte
inferior de la pantalla.
En el caso contrario se lleva al usuario a la vista de comprobante descrita en la Figura 29. En ella
se despliega el monto total pagado por el usuario junto a los datos de la transacción, incluyendo
el código de transacción y los datos relacionados a la tarjeta. El usuario también puede ver un
detalle del consumo presionando el botón de mayor información.
Para poder continuar, el usuario debe ingresar una valoración por el servicio desde 1 a 5
“estrellas” y un comentario opcional.
El sistema le envía automáticamente un comprobante de pago al email, con el detalle del
consumo y los datos de la transacción, el cual se puede observar en la Figura 30.
47
Figura 27: Diagrama de interacción de pago con Webpay Oneclick
48
Figura 28: Vista de resumen y propina
Figura 29: Vista comprobante
49
Figura 30: Email de comprobante de pago
50
5 Implementación y Análisis
En este capítulo se describen las prueba de funcionamiento de la aplicación. Se obtendrán
datos e información del uso y de los usuarios, a partir de los cuales se hará un análisis con el
objetivo de verificar si el desarrollo satisface los objetivos con respecto a la solución del
problema. También se evaluará el desempeño tecnológico en torno a los requerimientos.
5.1 Contexto de implementación
La aplicación se liberó para su descarga de manera gratuita en las tiendas de aplicaciones
para las plataformas iOS y Android a finales de diciembre de 2015. Luego se realizó un
lanzamiento en un restaurant llamado Pad Thai ubicado en Av. Manuel Montt 231, Providencia,
Santiago; donde posteriormente se realizaron las pruebas y evaluaciones del funcionamiento.
Figura 31: Foto de lanzamiento de Slice en el restaurant Pad Thai
De esta manera, se obtuvieron resultados y conclusiones de un ambiente real, por lo que se puede
llegar a un mejor análisis con respecto a los objetivos. Se incentivó el uso de la aplicación
primero a usuarios seleccionados y luego al público general. Los usuarios fueron jóvenes de 20 a
30 años.
Se realizaron diversos experimentos donde se pusieron a prueba distintos aspectos del uso de la
aplicación y el desempeño de la solución tecnológica. Esto tuvo una duración de 4 semanas,
desde diciembre 2015, hasta enero 2016.
51
5.2 Usabilidad
En esta sección, se describirá las pruebas realizadas en torno a la interacción del usuario y
la aplicación, evaluando distintas componentes de manera de verificar si esta permite al usuario
realizar las distintas tareas y lograr objetivos de una manera sencilla y simple. El estándar
ISO/IEC 9126-1 define usabilidad como
“Las capacidades del software de ser entendido, aprendido, usado y atractivo para el usuario,
cuando es utilizado bajo condiciones específicas.”
Se realizó una evaluación en la cual se le entregaba a los usuarios una lista de objetivos con
respecto a distintos escenarios que debían lograr mediante el uso de la aplicación. Las métricas
medidas fueron las siguientes:
• Completitud de la tarea: Cuando se completa un escenario de manera exitosa, es cuando
el participante indica que encontró la solución o cuando completa el objetivo de la tarea.
• Errores críticos: Son los errores que provocan desviaciones en la terminación de los
objetivos del escenario. Esencialmente el participante no puede completar la tarea. El
participante puede o no estar al tanto de que el objetivo de la tarea es incorrecto o
incompleto.
• Errores no críticos: Son los errores que son recuperados por el participante y no
perjudican su habilidad de completar el objetivo de la tarea. Estos errores hacen que la
tarea se complete de manera menos eficiente.
• Tasa de completitud sin errores: Es el porcentaje de los participantes de la prueba que
completan la tarea sin ningún error (críticos o no críticos).
• Tiempo en la tarea: La cantidad de tiempo que le toma al participante completar la
tarea.
• Medidas subjetivas: Estas evaluaciones son reportadas por los mismos participantes a
través de un cuestionario, donde los participantes miden en una escala de Likert del 1 al 7
distintos conceptos. Se midió: facilidad de aprendizaje, satisfacción y facilidad de uso.
20 usuarios sin experiencia previa en el sistema evaluaron las siguientes tareas: registro,
inscripción de medio de pago, pago total, pago equitativo, pago por ítem y pagar por alguien más.
Los resultados fueron los siguientes:
52
Gráfico 3: Tasa de completitud por tarea
Gráfico 4: Promedio de número de errores por tarea
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Registro Inscripción demedio de pago
Pago total Pago equitativo Pago por ítem Pagar por alguien
Tasa de completitud por tarea
Tasa de completitud
0.25 0.25
0.75
1.9
3.3
6.85
00.25
0 0 0 0.1
0
1
2
3
4
5
6
7
Registro Inscripción depago
Pago total Pago equitativo Pago por ítem Pagar por alguien
Nú
mer
o d
e er
rore
s
Promedio de número de errores por tarea
No críticos Críticos
53
Gráfico 5: Tasa de completitud sin errores por tarea
Gráfico 6: Tiempo promedio por tarea
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Registro Inscripción depago
Pago total Pago equitativo Pago por ítem Pagar por alguien
Tasa de completitud sin errores por tarea
Tasa de completitud sin errores
0
10
20
30
40
50
60
70
80
90
100
Registro Inscripción depago
Pago total Pago equitativo Pago por ítem Pagar por alguien
Tiempo promedio por tarea
Tiempo en segundos
54
Gráfico 7: Valoración promedio por tarea
Como se ve en el Gráfico 3, se obtuvo en general una alta tasa de completitud de las tareas, donde
la mayoría de los evaluados pudo completar el objetivo de cada una sin mayores problemas. La
solución posee una alta efectividad, con una tasa de completitud general del 94.2%.
Según el Gráfico 4, la inscripción del pago fue la que presentó la mayor concentración de errores
críticos, donde 25% de los usuarios no pudieron completar la tarea. Esto debido a que se utiliza la
interfaz de Webpay Oneclick y la de los bancos, la mayoría de los cuales no posee optimización
para móviles para su interfaz y otros simplemente fallan. Esto escapa del alcance del diseño de la
interfaz de la aplicación debido a que la interfaz de inscripción es provista por un tercero.
En base al número de errores no críticos, se llegó a la conclusión que es perfectamente normal
para los usuarios cometer errores, sobre todo en las tareas relacionadas con pagar, a pesar de ser
no críticos. Según el Gráfico 5, sólo el 18,75% de las tareas de pago fueron completadas sin
errores. Se puede concluir que la interfaz permite la recuperación de errores y posee un
importante componente explorativo.
Pagar por alguien más, fue la tarea que obtuvo la mayor cantidad de errores no críticos y mirando
el Gráfico 7, una valoración baja en torno a la facilidad aprendizaje y uso con respecto a las
relacionadas con el pago, lo que indica que el diseño en este apartado es deficiente ya que los
usuarios no logran entender su funcionamiento en primera instancia. A pesar de que pagar por
ítem es la segunda en este apartado, con 3.3 errores no críticos en promedio, los usuarios la
valoraron bastante alto en torno a la facilidad de uso y aprendizaje, por lo que se asume que son
errores relacionados a la exploración de la interfaz y no a un diseño deficiente de ella.
1
2
3
4
5
6
7
Registro Inscripción depago
Pago total Pago equitativo Pago por ítem Pagar por alguien
Valoración promedio por tarea
Facilidad de uso Facilidad de aprendizaje Satisfacción
55
El tiempo empleado en las tareas mostrado por el Gráfico 6, fue bastante bajo: todas bajo los 2
minutos. La eficiencia en torno al tiempo de las tareas las podemos calcular como:
𝐸 =
∑ ∑𝑛𝑖𝑗𝑡𝑖𝑗
𝑁𝑖=1
𝑅𝑗=1
𝑁𝑅
Donde 𝑁 es el número total de tareas, 𝑅 el número de usuarios, 𝑛𝑖𝑗 es el resultado de la tarea 𝑖
para el usuario 𝑗; si el usuario completa la tarea entonces 𝑛𝑖𝑗 = 1, si no, entonces 𝑛𝑖𝑗 = 0, y 𝑡𝑖𝑗 es
el tiempo utilizado por el usuario 𝑗 en completar la tarea 𝑖. Si la tarea no se completa de manera
satisfactoria, el tiempo es medido hasta que el usuario abandona la tarea. Aplicando a los
resultados, obtenemos una eficiencia general en torno al tiempo aproximada de 0.85 tareas por
minuto.
Con respecto a las valoraciones representadas en el Gráfico 7, es fácil ver dado el análisis anterior
por qué la inscripción tuvo tan bajos resultados en los 3 apartados. Las tareas relacionadas al
pago fueron bien evaluadas, sobre todo en el ámbito de satisfacción, donde todas obtuvieron
puntaje sobre 6. La facilidad de aprendizaje y de uso fueron también valoradas en gran manera,
sobre todos para las tareas de pago total, pago equitativo y pago por ítem; y se obtuvo un
promedio general de 5.61 y 5.58 para la facilidad de aprendizaje y de uso respectivamente. A
pesar de que la tarea de inscripción del medio de pago impacta fuertemente en las valoraciones,
permite que el pago suba en su valoración debido a la experiencia simple que provee.
5.3 Flujo
En este aparatado, se describirá y analizará las pruebas realizadas en torno a la influencia
de la solución en el flujo del restaurant y sus resultados.
Se realizaron mediciones mediante observación en torno al tiempo empleado para pagar en base a
la cantidad de comensales por mesa. Las variables a medir fueron:
• Tiempo total: Es la duración total de una cuenta. Desde que se toma el pedido hasta que
paga la cuenta.
• Tiempo de pago total: Es el tiempo entre que se termina de consumir hasta que se paga
la cuenta en su completitud.
• Promedio de tiempo de pago por persona: Es el tiempo promedio que demora una
persona en pagar la cuenta desde que termina de consumir.
• Número de comensales: Representa el número de comensales de la cuenta.
Los resultados fueron los siguientes:
56
Gráfico 8: Tiempo total y tiempo de pago total por persona
Gráfico 9: Promedio de tiempo de pago por persona
En base a los resultados, se puede observar que existe una clara ganancia en el tiempo utilizando
la aplicación. Analizando los datos del Gráfico 8 y el Gráfico 9, desde los 6 comensales el tiempo
de pago sube de manera abrupta, mientras que, mediante el uso de la solución la tasa de
0
20
40
60
80
100
120
140
1 2 3 4 5 6 7 8 9 10 11 12
Pro
med
io e
n m
inu
tos
Número de comensales
Tiempo total y tiempo de pago total por persona
Tiempo de pago (sin Slice) Tiempo total (sin Slice)
Tiempo de pago (con Slice) Tiempo total (con Slice)
0
5
10
15
20
25
1 2 3 4 5 6 7 8 9 10 11 12
Pro
med
io e
n m
inu
tos
Número de comensales
Promedio de pago por persona
Sin Slice Con Slice
57
crecimiento es mucho menor, manteniéndose bajo la marca de los 12 minutos con 12 comensales.
Se observó una mejora en el tiempo de pago total promedio del 69.95%, lo que representa una
mejora inmediata en la rapidez flujo general.
Se puede ver en el Gráfico 8, que existe una estricta correlación entre el tiempo total y el tiempo
de pago total, el cual influye directamente en la tasa de crecimiento del primero, sobre todo
cuando el número de comensales supera los 6. En vista de esto, se puede decir que la solución
influye directamente en disminuir el tiempo total de la cuenta, haciendo que se comporte de
manera más lineal con respecto al número de comensales.
En el Gráfico 9 se puede observar que existe una mejora sustancial en los promedios de tiempo
de pago por persona, esto debido no sólo al tiempo incurrido por los comensales para dividir la
cuenta, sino que también se observó que en la mayoría de los casos los comensales deseaban
pagar con tarjeta, ya sea crédito o débito, lo que generaba un cuello de botella en torno a la
operación con el POS de tarjetas del restaurant (el que muchas veces también fallaba con una tasa
no despreciable). Se produce la situación descrita a modo de ejemplo por el Gráfico 10: Situación
ejemplo de pago con tarjeta vs Slice – Tiempo de pago por persona, donde los tiempos de pago se
ven perjudicados por la espera y se van acumulando con respecto a la cantidad de usuarios,
haciendo que la experiencia diste de la ideal. La aplicación provee una solución a esta
problemática, debido a que permite realizar los pagos de manera asincrónica, por lo que el
comensal no debe esperar su turno para poder realizar la transacción, manteniéndose de manera
casi constante el promedio de tiempo de pago por persona, a medida que crece el número de
comensales.
Gráfico 10: Situación ejemplo de pago con tarjeta vs Slice – Tiempo de pago por persona
0
5
10
15
20
25
Comensal 1 Comensal 2 Comensal 3 Comensal 4 Comensal 5 Comensal 6
Min
uto
s
Situación ejemplo de pago con tarjeta vs Slice – Tiempo de pago por persona
Tarjeta
Slice
58
5.4 Desempeño tecnológico
En esta sección se describirá el desempeño de las tecnologías con respecto al uso de la
solución en el contexto descrito. También, se realizarán pruebas de stress para verificar la
escalabilidad y estabilidad de la solución.
5.4.1 Uso normal
A continuación, se analizará el desempeño en el uso normal de la aplicación durante el
periodo de pruebas descrito en el contexto. Para esto se expondrán métricas en torno al
desempeño de las llamadas y del servidor, así como también los componentes asociados.
Con respecto al backend, la utilización de la CPU promedió un 1.12%, utilizando un 30% de la
memoria disponible, por lo que el uso de recursos del servidor fue razonable, considerando un
bajo número de transacciones simultáneas y a pesar de ejecutar múltiples instancias de la API
junto a sus bases de datos y store de sesión asociados. Se tuvo una disponibilidad del API de
99.95% ya que existieron algunos errores en un comienzo relacionados a la puesta en producción
del sistema que debieron ser reparados sobre la marcha.
Se realizaron mediciones del tiempo de respuesta durante el periodo.
Gráfico 11: Tiempos de respuesta de llamadas totales
4578
1811
327
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
< 300[ms]
300 - 800[ms]
> 800[ms]
Tiempos de respuesta de llamadas totales
Llamadas
59
Gráfico 12: Tiempos de respuesta de llamadas por endpoint con interacción con POS
Observando el Gráfico 11, el tiempo de respuesta promedio rondó los 260[ms], considerando una
latencia del servidor de 200[ms] en promedio, por lo que se comportó acorde a lo esperado.
Según el Gráfico 12, las llamadas entre los 300 y los 800 milisegundos correspondieron en su
mayoría a los endpoints que necesitan de interacción con el punto de venta del restaurant. Este
aumento se debe a que se rescata la información desde el servidor local mediante los módulos de
POS. A pesar de que el aumento en el tiempo de respuesta para este tipo de llamadas se mantiene
dentro de márgenes aceptables, la forma en que se ejecuta causó que existieran peaks de demora
en ocasiones, llegando inclusive a los miles de milisegundos, debido a que el tiempo de respuesta
de las llamadas al POS depende en gran medida de las condiciones de la red del restaurant. A
pesar de que ocurrió de manera esporádica, existieron periodos en los cuales la experiencia del
usuario no fue la ideal. Cabe mencionar que el endpoint de rescatar información de una comanda
o ticket representa el 95% de este grupo. Analizando el problema se propone realizar un caché de
la comanda con duración de 1 minuto con respecto a la última llamada. De esta manera si existe
demora en la llamada, esta afectará (en intervalos mayores) a 1 usuario a la vez y no afectará a
los demás, ayudando también a disminuir la saturación de la red local.
La dependencia del endpoint de pago de los tiempos de repuesta del sistema Oneclick sumado a
los del POS, significó que fuera el que obtuvo el mayor tiempo de respuesta en promedio, con
sólo 2 de sus llamadas bajo la marca de los 800[ms], pero fue uno de los menos solicitados, ya
que el usuario sólo debe realizar esta acción una sola vez. A pesar de que es un punto crítico de la
solución, no representó mayor inconveniencia para el usuario, el cual acostumbra a que este
proceso tome un poco más. Aun así, vale la pena en el futuro optimizar este apartado, con miras
de la escalabilidad del sistema.
Cabe mencionar que existió una tasa de error de transacción con Webpay Oneclick para el
periodo evaluado del 8%, en gran parte debido a problemas en el lanzamiento con los topes de
transacción, los cuales por defecto son configurados en $15.000 pesos, por lo que cualquier
0 200 400 600 800 1000 1200 1400
GET /locations/:id/find_ticket/:query
GET /locations/:id/tickets/:ticket_id
POST /locations/:id/tickets/:ticket_id/pay
TIempos de respuesta de llamadas por endpoint con interacción con POS
Llamadas > 800[ms] Llamadas < 800[ms]
60
transacción por arriba del monto era rechazada. Una vez que se acordó con Transbank subir el
monto, la situación se normalizó.
El desempeño de la aplicación móvil, a pesar de no ser desarrollada de manera nativa, fue
bastante bueno (sobre todo en iOS), ya que no se produjeron bugs de importancia y la interfaz se
desplegó con la velocidad y tiempos de respuesta adecuados. Existieron problemas con la
velocidad de las animaciones en teléfonos con Android antiguos o de gama baja, por lo que
debieron ser desactivados para estos dispositivos.
5.4.2 Pruebas de stress
Se realizaron pruebas para analizar el rendimiento de la API bajo stress simulando el
tráfico y demanda asociado a una carga pesada. Todas las pruebas se ejecutaron en un equipo
Macbook Pro con un procesador Intel Core i5 5287U y 16gb RAM LPDDR3 a 1866 MHz, con
respecto al sistema en producción.
Para evaluar la carga máxima que soporta la API, se utilizó como herramienta wrk 8 como
herramienta de punto de referencia. Se utilizaron 4 threads variando el número de conexiones
abiertas por 30 segundos cada una, apuntando a la dirección de producción de la API:
https://api.slicepayments.com/.
Los resultados fueron los siguientes:
Gráfico 13: Prueba de estrés API
8 wrk: https://github.com/wg/wrk
0
200
400
600
800
1000
1200
0
100
200
300
400
500
600
50 100 500 1000 2000 3000 4000 5000 7500 10000
Lat
enci
a [m
s]
Lla
mad
as /
seg
un
do
Conexiones abiertas
Prueba de estrés API
Llamadas / segundo Latencia[ms]
61
Los resultados son bastante alentadores, ya que se puede observar que, hasta las 2.000 conexiones
abiertas, el API alcanza una tasa de casi 500 llamadas por segundo. Se puede notar también que
luego de las 500 conexiones abiertas, la latencia sube casi al segundo y se mantiene de esa
manera hasta las 10.000 conexiones, lo que se mantiene también dentro de muy buenos
márgenes.
Cabe mencionar que el API, debido a la naturaleza de Node.js, se ejecuta en un solo thread, por
lo que consume una sola cola de eventos. Cuando la latencia sube o las llamadas por segundo
disminuyen, significa que la cola recibe tareas más rápido de lo que las puede procesar. En base a
los resultados, la cola se empieza a “atorar” a las 500 conexiones y es sobrepasada sobre las
2.000 conexiones concurrentes abiertas, lo cual ya es bastante, pero si se llega a esa tasa, se debe
escalar el servidor. No es necesario escalar de manera vertical ya que Node permite crear un
cluster que permite utilizar cada uno de los threads del procesador, por lo que simplemente se
necesitaría lanzar varias instancias iguales bajo un balanceador de carga, el cual ya se encuentra
disponible en el stack. Esto hace que el API tenga grandes capacidades para escalar de manera
horizontal en base a los requerimientos sin la necesidad de lanzar otro servidor o actualizar las
componentes del actual antes de las 2.000 y 8.000 conexiones abiertas concurrentes.
Ahora, en torno al desempeño de websockets, se realizaron pruebas en torno al número de
mensajes que se pueden enviar con respecto a la cantidad de subscriptores concurrentes. Se
utilizó artillery9 como herramienta de punto de referencia, la cual soporta socket.io. Se utilizaron
4 threads variando el número de clientes y la tasa de mensajes por segundo. Los resultados fueron
los siguientes:
Gráfico 14: Promedio de re tiempo de respuesta de mensajes por segundo con respecto al número de subscriptores
concurrentes
9 Artillery: https://artillery.io/
0
500
1000
1500
2000
2500
500 1000 2000 4000 5000 8000 9000 10000 12000 14000
Pro
med
io d
e ti
emp
o d
e re
spu
esta
en
m
ilis
egu
nd
os
Mensajes enviados por segundo
Promedio de tiempo de respuesta de mensajes por segundo con respecto al número de subscriptores concurrentes
25 50 75 100 200 300 400 500 750 1000
62
En base a los resultados obtenidos, se puede concluir que los tiempos de respuesta son
básicamente los mismos, independientemente de la tasa de mensajes por segundo y sólo
dependen del nivel de concurrencia. Sin embargo, la diferencia no es dramática. Incluso con
1.000 clientes simultáneos, el tiempo promedio de respuesta está en el orden de los 200[ms].
Mientras que no es un resultado espectacular, es sin duda manejable y se mantiene prácticamente
constante hasta los 8.000 mensajes por segundo.
En esta prueba ocurre lo mismo que con la anterior, donde el umbral de “atasco” se alcanza a la
tasa de 8.000 mensajes por segundo. Sin embargo, el desempeño en las situaciones que no existe
atasco es alto, ya que se puede enviar incluso una relativamente gran cantidad de mensajes a una
gran velocidad, esencialmente sin costo en la latencia. Con respecto a la capacidad de escalar, es
básicamente la misma situación que en el caso anterior.
Este resultado supera con creces los de la prueba anterior con respecto a la cantidad de
información que puede ser enviada, pero a menor grado de concurrencia.
63
6 Conclusiones
La aplicación logró un gran impacto en torno a la optimización del flujo de pago en el
restaurant, lo que se tradujo en una mejor experiencia para el usuario y una mejor rotación para el
restaurant o bar. En base a los resultados obtenidos, y al desempeño de la aplicación, se puede
concluir que los objetivos de esta memoria fueron satisfechos a cabalidad, ya que se pudo
desarrollar un sistema seguro, escalable que permite pagar la cuenta de manera fácil y rápida a los
usuarios. Esto también se vio reflejado en el restaurant, donde el staff y la administración
quedaron muy satisfechos con la solución, cumpliendo sus expectativas con respecto a la
optimización de su trabajo. Sin embargo, a pesar que se realizó la prueba en sólo uno, se intuye
que estos resultados podrían ser replicados con facilidad en otros restaurantes o bares.
En base a los resultados obtenidos, es fácil ver porqué existe una clara tendencia en torno a los
pagos móviles, ya que ofrecen una experiencia de pago más rápida en general en el proceso que
se implemente debido a que cada usuario posee un terminal de pagos en su mano, lo que hace que
este pueda realizarse de manera asíncrona y concurrente. Aun así, la optimización de los procesos
en base al desempeño, usabilidad y seguridad mediante tecnologías no deja de ser importante,
sobre todo al momento de la adopción de este medio por parte del usuario.
El uso de un framework híbrido para desarrollar la aplicación móvil fue de gran ayuda, ya que
efectivamente aportó agilidad en el desarrollo y permitió generar una interfaz rápida y estable,
que fue alabada en general por los usuarios. El desempeño fue igual o muy parecido a una
aplicación nativa, por lo que se recomienda su uso, sobre todo con el acelerado aumento en el
rendimiento de estos dispositivos.
La elección de Webpay Oneclick como medio de pago fue un acierto con respecto a permitir la
experiencia de pago sin complicaciones de cara al usuario, pero a pesar de esto, la inscripción de
la tarjeta significa uno de los puntos de complejidad de la interfaz de usuario más importantes
que existen hoy en Slice, sobre todo para conseguir nuevos usuarios. La tasa de errores en la
inscripción es bastante alta, la interfaz es excesivamente simple (básica) y distinta para cada
usuario, todo sumado a que los usuarios en su mayoría no traen consigo su
multiclave/digipass/multipass de su banco. Hoy, existen soluciones como Stripe Atlas que
permiten realizar el proceso de registrar una empresa en territorio estadounidense para procesar
tarjetas utilizando su sistema, el cual provee de una experiencia superior en la inscripción de
tarjetas. Sin embargo, esto trae consigo un mayor costo por transacción el cual debe ser
considerado.
A pesar de los problemas que existieron en la implementación, el sistema se comportó de manera
bastante robusta, con una tasa de errores bastante baja. Los tiempos de respuesta se mantuvieron
bastante bajos, pero no ideales, por lo que se evaluará utilizar un servidor en Latinoamérica o en
Chile para reducir las latencias promedio.
Una parte importante en el éxito de la aplicación con los usuarios, fue la interfaz, la experiencia
de usuario y la usabilidad, lo que se puede atribuir a la elección de tecnologías de tiempo real,
sobre todo con respecto al proceso de división de la cuenta. La inmediatez en el acceso de la
información y la retroalimentación instantánea es hoy en día primordial, donde cada vez existe
una mayor competencia por la atención del usuario, el cual a su vez es más y más exigente.
64
Como trabajo futuro se propone desarrollar un módulo de pre compra, ya que de esta manera se
ataca otra parte del flujo que afecta en el tiempo total de la cuenta, convirtiendo a la aplicación en
una solución más integral. También, el desarrollo de un punto de venta propio de cara el
restaurant o bar sería muy útil, ya que muchos de los restaurantes interesados no poseen un
sistema POS o poseen sistemas de punto de venta no compatibles. Esto representa un problema,
debido a que el desarrollo ad-hoc no permite un crecimiento acelerado, no sólo por el tiempo y
recursos necesarios, sino también por la relación comercial y técnica que debe existir por cada
uno de las empresas que proveen este software.
Cabe mencionar, que este proyecto originalmente surge dentro del curso “Taller de Metodologías
Ágiles de Desarrollo de Software”, el semestre de otoño 2014. Bajo el nombre de “ScanEat”, el
cual tenía como motivación principal utilizar las herramientas tecnológicas disponibles para
agilizar el proceso de pedido en restaurantes. En agosto de 2015, al alero del ingreso al programa
Start-Up Chile 10 , el equipo decide tomar un cambio de rumbo y abandonar el pedido para
enfocarse en el pago y la experiencia en torno a ello, debido a que se identifica que es un
problema aún mayor. Se contrata a 2 diseñadores y un desarrollador como apoyo de manera de
agilizar el proceso. Durante el mismo periodo, se opta por cambiar la antigua imagen del
proyecto y utilizar un nuevo nombre, Slice, del inglés “tajada” o “corte”, haciendo alusión al acto
de dividir una cuenta.
A la fecha de entrega de esta memoria, Slice se encuentra en 12 locales, cuenta con más de 800
descargas, más de 18 millones de pesos procesados, con 11.05 transacciones promedio a la
semana. Esto no sólo son indicadores de que la aplicación soluciona el problema planteado, sino
que también es uno que afecta a una gran cantidad de personas.
10 Start-Up Chile: http://startupchile.org/
65
7 Glosario
Startup: es un término utilizado actualmente en el mundo empresarial el cual busca arrancar,
emprender o montar un nuevo negocio y hace referencia a ideas de negocios que están
empezando o están en construcción, es decir son empresas emergentes apoyadas en la tecnología.
Son ideas que innovan el mercado y buscan hacer de los procesos complicados más fáciles de
realizar, estas van enfocadas a diferentes temas y usos. Generalmente son empresas asociadas a la
innovación, al desarrollo de tecnologías, al diseño web o desarrollo web; son empresas de capital-
riesgo.
Framework: Es una estructura conceptual y tecnológica de soporte definido, normalmente con
artefactos o módulos concretos de software, que puede servir de base para la organización y
desarrollo de software. Típicamente, puede incluir soporte de programas, bibliotecas, y un
lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes
componentes de un proyecto. Representa una arquitectura de software que modela las relaciones
generales de las entidades del dominio, y provee una estructura y una especial metodología de
trabajo, la cual extiende o utiliza las aplicaciones del dominio.
MVC: Es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de
una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las
comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son
el modelo, la vista y el controlador, es decir, por un lado, define componentes para la
representación de la información, y por otro lado para la interacción del usuario. Este patrón de
arquitectura de software se basa en las ideas de reutilización de código y la separación de
conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior
mantenimiento.
JSON: (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato ligero de
intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas
es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación
JavaScript, Standard ECMA-262 3rd Edition - diciembre 1999. JSON es un formato de texto que
es completamente independiente del lenguaje, pero utiliza convenciones que son ampliamente
conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java,
JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que JSON sea un lenguaje
ideal para el intercambio de datos.
JSON está constituido por dos estructuras:
• Una colección de pares de nombre/valor. En varios lenguajes esto es conocido como un
objeto, registro, estructura, diccionario, tabla hash, lista de claves o un arreglo asociativo.
• Una lista ordenada de valores. En la mayoría de los lenguajes, esto se implementa como
arreglos, vectores, listas o sequencias.
Estas son estructuras universales; virtualmente todos los lenguajes de programación las soportan
de una forma u otra. Es razonable que un formato de intercambio de datos que es independiente
del lenguaje de programación se base en estas estructuras.
66
Frontend y backend: En diseño de software el frontend es la parte del software que interactúa
con el o los usuarios y el backend es la parte que procesa la entrada desde el frontend. La
separación del sistema en frontends y backends es un tipo de abstracción que ayuda a mantener
las diferentes partes del sistema separadas. La idea general es que el frontend sea el responsable
de recolectar los datos de entrada del usuario, que pueden ser de muchas y variadas formas, y los
transforma ajustándolos a las especificaciones que demanda el backend para poder procesarlos,
devolviendo generalmente una respuesta que el frontend recibe y expone al usuario de una forma
entendible para este. La conexión del frontend y el backend es un tipo de interfaz.
CRUD: En computación CRUD es el acrónimo de Crear, Leer, Actualizar y Borrar (del original
en inglés: Create, Read, Update and Delete). Se usa para referirse a las funciones básicas en bases
de datos o la capa de persistencia en un software.
ORM: El mapeo objeto-relacional (más conocido por su nombre en inglés, Object-Relational
mapping, o sus siglas O/RM, ORM, y O/R mapping) es una técnica de programación para
convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a
objetos y la utilización de una base de datos relacional como motor de persistencia. En la práctica
esto crea una base de datos orientada a objetos virtual, sobre la base de datos relacional. Esto
posibilita el uso de las características propias de la orientación a objetos (básicamente herencia y
polimorfismo).
OAuth: OAuth (Open Authorization) es un protocolo que permite flujos simples de autorización
para sitios web o aplicaciones informáticas. Se trata de un protocolo que permite autorización
segura de una API de modo estándar y simple para aplicaciones de escritorio, móviles y web.
OAuth permite a un usuario del sitio A compartir su información en el sitio A (proveedor de
servicio) con el sitio B (llamado consumidor) sin compartir toda su identidad. Para
desarrolladores de consumidores, OAuth es un método de interactuar con datos protegidos y
publicarlos. Para desarrolladores de proveedores de servicio, OAuth proporciona a los usuarios
un acceso a sus datos al mismo tiempo que protege las credenciales de su cuenta.
PaaS: La plataforma como servicio (en inglés platform as a service, PaaS), es la encapsulación
de una abstracción de un ambiente de desarrollo y el empaquetamiento de una serie de módulos o
complementos que proporcionan, normalmente, una funcionalidad horizontal (persistencia de
datos, autenticación, mensajería, etc.). De esta forma, un arquetipo de plataforma como servicio
podría consistir en un entorno conteniendo una pila básica de sistemas, componentes o APIs
preconfiguradas y listas para integrarse sobre una tecnología concreta de desarrollo (por ejemplo,
un sistema Linux, un servidor web, y un ambiente de programación como Perl o Ruby). Las
ofertas de PaaS pueden dar servicio a todas las fases del ciclo de desarrollo y pruebas del
software, o pueden estar especializadas en cualquier área en particular, tal como la administración
del contenido.
Scaffold: O Scaffolding, es una técnica soportada por algunos frameworks MVC, en la cual el
programador puede especificar como la base de datos de la aplicación pueda ser utilizada. El
compilador o framework usa esta especificación, junto con plantillas de código predifinido, para
generar el código final que la aplicación utilizará para realizar operaciones CRUD.
Integración Continua: La integración continua (continuous integration en inglés) es un modelo
informático propuesto inicialmente por Martin Fowler que consiste en hacer integraciones
67
automáticas de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes.
Se entiende por integración, la compilación y ejecución de pruebas de todo un proyecto.
CGI: Interfaz de entrada común (en inglés Common Gateway Interface, abreviado CGI) es una
tecnología que permite a un cliente (navegador web) solicitar datos de un programa ejecutado en
un servidor web. CGI especifica un estándar para transferir datos entre el cliente y el programa.
Es un mecanismo de comunicación entre el servidor web y una aplicación externa cuyo resultado
final de la ejecución son objetos MIME. Las aplicaciones que se ejecutan en el servidor reciben el
nombre de CGIs.
68
8 Bibliografía
[1] R. Johnston y S. Michel, «Three outcomes of service recovery: Customer recovery, process
recovery and employee recovery,» International Journal of Operations & Production
Management, vol. 28, nº 1, pp. 79-99, 2008.
[2] A. Gad y A. Federgruen, «Competition in Service Industries,» Operation Research, vol. 55,
nº 1, pp. 37-55, 2007.
[3] M. K. Hui, M. V. Thakor y R. Gill, «The Effect of Delay Type and Service Stage on
Consumers' Reactions to Waiting,» Journal of Consumer Research, vol. 24, nº 4, pp. 469-
479, 1998.
[4] GFK Adimark, «Los chilenos y la alimentación,» 16/10/2015. [En línea]. Available:
http://www.adimark.cl/es/estudios/documentos/gfk%20adimark_chilenos%20y%20alimentac
i%C3%B3n.pdf. [Último acceso: 6/9/2016].
[5] D. Villegas, «Los resultados del primer “censo” de restaurantes en Santiago,» La Tercera, p.
18, 4 8 2014.
[6] International Data Corporation (IDC), «Worldwide Smartphone Growth Forecast to Slow to
3.1% in 2016 as Focus Shifts to Device Lifecycles, According to IDC,» [En línea].
Available: http://www.idc.com/getdoc.jsp?containerId=prUS41425416. [Último acceso: 6 9
2016].
[7] K. McDermott, «The mobile payments revolution,» 2015. [En línea]. Available:
http://www.aic-sf.com/download/media/296. [Último acceso: 6 9 2016].
[8] I. Fette y A. Melnikov, The WebSocket Protocol, Internet Engineering Task Force (IETF),
2011.
[9] K. Finley, «Wait, What’s Node.js Good for Again?,» 25/1/2011. [En línea]. Available:
http://readwrite.com/2011/01/25/wait-whats-nodejs-good-for-aga/. [Último acceso: 29 9
2016].
[10] N. Leavitt, «Will NoSQL Databases Live Up to Their Promise?,» IEEE Computer, 26 1
2010. [En línea]. Available: http://www.leavcom.com/pdf/NoSQL.pdf. [Último acceso: 6 9
2016].
[11] J. B. N. S. M. Jones, JSON Web Token (JWT), Internet Engineering Task Force (IETF), 2015.
[12] M. B. R. C. H. Krawczyk, HMAC: Keyed-Hashing for Message Authentication, Network
Working Group, 1997.
[13] R. A. Dan Brinkheden, «A Performance Study of Hybrid Mobile Applications Compared to
Native Applications,» 2015.
Anexo A
Anexo
Anexo A: Llamadas Integración POS-API
Obtener ticket específico
URL: /tickets/:id Método: GET
Parámetros URL:
Requeridos: id=[integer] Parámetros Data: Ninguno
Respuesta Exitosa:
Código: 200 OK Contenido (ejemplo):
{ "id" : 25, //id_mesa "table_number" : 7, "guests" : 4, "created_at": { "time" : "hh:mm:ss", "date" : "yyyy-mm-dd" }, "employee": { //Opcional "id" : 3, "name" : "Juan Perez" }, "items": [ { "id": 66, "name": "Cous Cous", "price_per_unit": 1200, // Round "quantity": 2, // Puede ser float "discount": 10, // Entero que representa al porcentaje "modifiers": [], "created_at": { "time" : "hh:mm:ss", "date" : "yyyy-mm-dd" } }, { "id": 67, "name": "Papas Fritas", "price_per_unit": 1500, "quantity": 3, "discount": 0, "modifiers" : [ //Modificadores { "id": 13, "name": "Con Ketchup", "price_per_unit": 0,
Anexo A
"quantity": 1 }, { "id": 10, "name": "Ultra saladas", "price_per_unit": 0, "quantity": 1 } ] "created_at": { "time" : "hh:mm:ss", "date" : "yyyy-mm-dd" } }, { "id": 68, "name": "Te Verde Akbar, Sabores", "price_per_unit": 1200, "quantity": 2, "discount": 0, "modifiers": [], "created_at": { "time" : "hh:mm:ss", "date" : "yyyy-mm-dd" } } ], "payments": [ // Lista de pagos parciales { "id": 21 "amount": 2400, "tip": 240, "type": "Crédito", "created_at": { "time" : "hh:mm:ss", "date" : "yyyy-mm-dd" } }, { "id": 22 "amount": 1200, "tip": 120, "type": "Slice", "created_at": { "time" : "hh:mm:ss", "date" : "yyyy-mm-dd" } } ], "totals": { "total": 9300, //Total de la cuenta "due": 5700 //Total por pagar } }
Respuesta Errónea:
Anexo A
Código: 404 NOT FOUND Contenido:
{ "error": "Ticket no encontrado." }
Código: 401 UNAUTHORIZED
Contenido:
{ "error": "No tienes autorización para hacer esta llamada." }
Obtener tickets
URL: /tickets
Método: GET
Parámetros de URL:
Requerido: Ninguno
Opcional: init_date=[date], finish_date=[date] Parámetros Data: Ninguno
Respuesta Exitosa:
Código: 200 OK
Contenido: Array de tickets (ver ticket específico)
Respuesta errónea:
Código: 401 UNAUTHORIZED
Contenido:
{ "error": "No tienes autorización para hacer esta llamada." }
Código: 400 BAD REQUEST
Contenido:
{ "error": "Formato de fecha inválido." }
Código: 422 UNPROCESSABLE ENTITY
Contenido:
{ "error": "Rango de fechas inválido." }
Anexo A
Registrar pago
URL: /tickets/:id/pay Método: POST
Parámetros de URL
Requerido: id=[integer]
Parámetros data:
Requerido: amount=[integer], tip=[integer] Ejemplo:
{ "amount" : 1200, // Monto pagado por el cliente "tip" : 120, // Propina dejada por el cliente }
Respuesta exitosa:
Código: 201 CREATED
Contenido:
{ ... ,//Resto del ticket "payments": [ ... // Resto de pagos parciales ,{ "id": 22 "amount": 1200, "tip": 120, "type": "Slice", "created_at": { "time" : "hh:mm:ss", "date" : "yyyy-mm-dd" } ] }
Respuesta errónea:
Código: 404 NOT FOUND
Contenido:
{ "error": "Ticket no encontrado." }
Código: 422 UNPROCESSABLE ENTITY Contenido:
{ "error": "Pago excede el monto a pagar." }
Código: 401 UNAUTHORIZED
Anexo A
Contenido:
{ "error": "No tienes autorización para hacer esta llamada." }
Anexo B
Anexo B: Evaluación cualitativa de la aplicación
Para cada una de las preguntas a continuación, indique la respuesta que mejor caracterice como
se siente acerca de la afirmación con respecto a la tarea en una escala del 1 al 7, donde 1 = muy
en desacuerdo y 7 = muy de acuerdo.
1. La tarea fue fácil de aprender.
1 2 3 4 5 6 7
2. La interfaz/interacción fue fácil de utilizar.
1 2 3 4 5 6 7
3. Realizar/cumplir la tarea fue satisfactorio.
1 2 3 4 5 6 7