Embed Size (px)
Citation preview
Graduado en Ingeniería Informática Universidad Politécnica de Madrid
Escuela Técnica Superior de Ingenieros Informáticos
TRABAJO FIN DE GRADO
(COMPRA - VENTA DE PRODUCTOS CON
BLOCKCHAIN INTEGRADO)
Autor: Álvaro Picazo Haase Director: Fernando Pérez Costoya
MADRID, JUNIO 2018
i
ii
ÍNDICE
1. RESUMEN ...................................................................................................... 1
2. ABSTRACT ..................................................................................................... 1
3. INTRODUCCIÓN Y OBJETIVOS ................................................................. 3
4. PLANTEAMIENTO DEL PROBLEMA ......................................................... 5 4.1. Tecnología escogida ............................................................................................5 4.2. Trabajos previos .................................................................................................6
5. RESOLUCIÓN DEL PROBLEMA PLANTEADO ......................................... 8 5.1. Organización de desarrollo .................................................................................8 5.2. Red de Blockchain ............................................................................................ 10 5.3. Herramientas utilizadas ................................................................................... 14
5.3.1. Github .................................................................................................................... 14 5.3.2. SourceTree ............................................................................................................. 14 5.3.3. VisualStudio Code ................................................................................................. 14 5.3.4. Google Drive ......................................................................................................... 15
5.4. Desarrollo del back-end .................................................................................... 15 5.5. Desarrollo del front-end ................................................................................... 27
6. ANÁLISIS DE RESULTADOS OBTENIDOS .............................................. 42
7. CONCLUSIONES ......................................................................................... 43
8. LINEAS FUTURAS ....................................................................................... 44
9. BIBLIOGRAFÍA ........................................................................................... 45
iii
1
1. RESUMEN
El TFG1 realizado consiste en el diseño e implementación de una aplicación para móvil para comprar productos sostenida por la tecnología Blockchain. Dicha aplicación móvil, con nombre ZOOM, dará la posibilidad de que tanto un usuario llamado Cliente tenga realice una compra de un producto, un Vendedor aceptar dicha petición y un Transportista realizar la entrega de dicho producto al destinatario. A su vez, los tres participantes del flujo podrán ver el estado de la llamada Order2, y el Cliente tendrá la posibilidad de realizar cambios en su perfil o incluso de ver todos los pedidos que tiene pendientes de entrega. Zoom ofrece la posibilidad de realizar un registro para usuarios nuevos, introduciendo los parámetros necesarios para completar dicho registro. Toda la información de los usuarios, tanto de los clientes como del transportista y vendedor, queda registrada en la Blockchain, así como de la información de los productos y de las Orders creadas cuando se realiza la compra de un producto. Cada vez que un usuario realiza una acción, se actualizan diferentes parámetros en la Blockchain dependiendo de la acción tomada y dependiendo de sobre que producto se haya tomado. Este trabajo ha sido diseñado e implementado de cero, basándome en aplicaciones ya hechas pero con otras tecnologías, y tratando de desarrollar algo similar pero con mas simpleza. Es por esto por lo que se ha decidido utilizar los diferentes lenguajes en función de mi criterio y mis conocimientos, siempre analizando la idea y entendiendo que dichos lenguajes de programación servían para el desarrollo en su plenitud de la aplicación.
2. ABSTRACT
The Final Year Project consists in the design and implementation on a mobile application for buying products based on the Blockchain technology. In this application, named as ZOOM, will let the Client buy a product registered in the Blockchain, sold by a Vendor, that will accept or decline the request and if accepted a Transport participant will deliver the product to its destination. Meanwhile, every participant will be able to see the status of the order and see the tracking of it. The client has the possibility to edit his profile or even see every order
1 Trabajo de Fin de Grado 2 Pedido
2
that is has not been yet delivered. Every new user can sign up for free, introducing the requested parameters as an usual application. Every users’ data will be registered in the Blockchain, as well as the data of the products and the orders’ created when a request is accepted by the Vendor, as it was explained before. When a participant makes an action, every parameters involved are updated in the Blockchain, depending on the action an also the product. This project has been developed and designed from the start, based on famous applications but with different technologies. It has been developed in the programming languages most well-known by myself and also my knowledge.
3
3. INTRODUCCIÓN Y OBJETIVOS
Blockchain es una tecnología de la que últimamente mucha gente habla pero poca conoce realmente. Para conocer realmente no sólo su significado sino hacer un correcto uso de ella, es necesario haber aplicado a casos de uso reales ésta tecnología. Como una introducción al Blockchain, se puede decir que es una Base de Datos distribuida que presenta las siguientes características que hacen que la diferencie de una Base de Datos normal:
Inmutabilidad Algoritmos de consenso Seguridad
“We are on a mission to build a more open, accessible, and fair financial future, one piece of software at a time. Our technology is revolutionizing the financial services
industry by empowering millions across the globe to authenticate and transact immediately and without costly intermediaries”.[1]
Cuando hablamos de inmutabilidad, hablamos también de seguridad y del algoritmo de consenso. La información que hay registrada en la Blockchain no se puede borrar, ni tampoco editar a gusto de un participante. Para que un usuario edite, por ejemplo, un campo de un objeto, es necesario, en primer lugar, que ese usuario disponga de un token de acceso al sistema. Una vez el usuario quiere realizar ese cambio o actualización, es cuando entra el algoritmo de consenso. Todos los participantes han de aprobar dicho cambio y es en ese momento y no antes cuando se produce el cambio en todos los nodos3. Este algoritmo de consenso permite volver a un estado anterior, también llegando a un acuerdo entre todos los participantes. Cada vez que se produce un cambio en la Blockchain, se genera un bloque de datos en el que incluye la información de la transacción realizada. Cuando se realiza un cambio, se genera un nuevo bloque, y siempre ligado al anterior. Es por esto por lo que recibe el nombre de Blockchain (cadena de bloques).
3 Instancia del sistema
4
Ésta es también una de las características del Blockchain que aporta seguridad al sistema. Cuando he hablado anteriormente de los nodos, significa que cada participante de la red tiene una instancia de la Blockchain. En el caso de que un nodo sea hackeado y se produzcan cambios en ese nodo, los demás nodos dispondrán información diferente a la de éste, es por ello por lo que sería fácil identificar cambios no deseados en la Blockchain. Otra faceta del Blockchain relacionada con su seguridad, es que cada transacción va cifrada con un algoritmo de cifrado, o bien con SHA-2564, SHA-5125… Esto hace que no se pueda ver la información de la transacción y sólo aquel que disponga de acceso al sistema puede descifrar la información relacionada con el procesador de transacciones, y de esta manera poder saber que procesos se están llevando a cabo. Los casos de uso de esta tecnología son variados, desde traspaso de fondos entre diferentes entidades, cadenas de soportes, hasta al seguimiento de productos que es de lo que se va a tratar este trabajo. El objetivo principal de este TFG será implementar dicha tecnología, vinculándola a un front-end desarrollado también por el alumno, y conseguir que se pueda realizar un seguimiento del producto desde el momento en el que un cliente decide comprar dicho producto hasta que llega a sus manos entregado por un transportista, habiendo sido supervisado y aceptado el pedido por un vendedor.
4 Tipo de cifrado 5 Tipo de cifrado
5
4. PLANTEAMIENTO DEL PROBLEMA Pese a que Blockchain se relacione a Bitcoin y de ahí no se sepa más, es una tecnología perfecta para el desarrollo de otros casos de uso diferentes, tales como la creación de un Smart Contract, o también muy demandada a la vez que utilizada la llamada Supply Chain o cadena de suministro. Dado que en otras experiencias pasadas se trabajó en un caso de uso que consistía en éste último, se planteó la posibilidad de crear una aplicación basada en un tracking de productos soportada con esta tecnología. Tras hacer un estudio detenido, se llegó a la conclusión de que se podría obtener un buen resultado final y es por ello por lo que se comenzó el desarrollo.
4.1. Tecnología escogida El tracking de productos es perfectamente posible de desarrollar con otro tipo de tecnologías. Un ejemplo es Aliexpress, que utiliza una tecnología basada en RFID6 que permite almacenar los datos del producto en un sistema y de esta manera enviar al cliente el estado del pedido o cualquier información, incluyendo la localización de este. Pero como se ha explicado anteriormente, la idea de este trabajo era ver el resultado final de una aplicación que fuera fácil de manejar por todos los participantes que intervienen en el flujo basada en Blockchain. Dentro de Blockchain, existen varias compañías que han desarrollado su propia tecnología pero siempre siguiendo las normas y conteniendo los pilares fundamentales que forman Blockchain. Se ha decidido escoger el Blockchain de IBM7. Este Blockchain se llama Hyperledger y la razón por la que se ha dedicido implementarlo es porque es con la que más se ha trabajado personalmente y la que mejor se conoce. Esto no quiere decir que no se pueda desarrollar con otras o que den peores resultados en este caso de uso que es el tracking de productos. 6 Identificación por radio frecuencia 7 International Business Machines Corporation
6
Ilustración 1. Logo de Hyperledger de IBM
4.2. Trabajos previos Como se ha dicho anteriormente, la plataforma de Blockchain escogida es la que mejor se conoce y esto es porque se han desarrollado otros casos de usos previos a éste. Dado que para la empresa que trabajo desarrollando Blockchain exige confidencialidad en los proyectos que se desarrollan internamente, se van a exponen simplemente los casos de uso en los que se ha trabajado y una breve descripción de ellos. Son los siguientes:
Trazabilidad de fondos: La aplicación consiste en que dos entidades tienen la opción de agregar cantidades de dinero a fondos de inversión, venderlos o realizar traspasos entre diferentes entidades. Esta aplicación se desarrolló con el Blockchain de Ethereum.
SmartContract entre dos entidades: Un ‘’SmartContract’’ es un contrato
inteligente soportado por la tecnología Blockchain, en este caso de Hyperledger, que contiene una serie de datos, duración del contrato, pagos, facturas mensuales y un acuerdo entre dos entidades. Este es uno de los casos de uso más comunes dentro de Blockchain.
Supply Chain de una farmacéutica: El término ‘’Supply Chain’’ consiste en un
seguimiento de un producto de todas las fases, desde la orden de creación hasta la llegada al cliente. En este caso se realizaba el seguimiento en su plenitud, desde
7
la creación de una orden de compra de la empresa, pasando por los almacenes, farmacia y cliente, distribuida por diferentes transportistas.
El trabajo actual es lo más parecido al último caso, que de manera simplificada se ha querido implementar este caso de uso. Estos trabajos han servido no solo para entender la filosofía de Blockchain y saber como desarrollarla, sino también poder diseñar una aplicación visual para que el cliente o diferentes participantes puedan ver un resultado basado en Blockchain.
8
5. RESOLUCIÓN DEL PROBLEMA PLANTEADO
Para obtener un resultado de ZOOM que satisfaga a los participantes que intervienen en el flujo del tracking de un producto, ha sido necesario llevar a cabo una organización rigurosa, estudiando todos los requisitos y necesidades de usuario. Además, ha sido imprescindible levantar una red organizada, y desarrollar un código sin errores que mantenga una conexión apropiada con la red de Blockchain para la correcta llamada a las operaciones ofrecidas por la API8. Dicho lo cual, a continuación se detallan los pasos seguidos en orden cronológico para llegar al resultado final.
5.1. Organización de desarrollo Uno de los primeros pasos ha sido valorar que era necesario tener definido antes del desarrollo del back-end9 y del front-end10 de la aplicación. Esto eran los requisitos, necesarios para ya saber cómo enfocar el código y el diseño de la aplicación.
ID DESCRIPCIÓN Inicio de sesión y registro R01 El usuario de tipo Cliente introduce los campos necesarios para llevar a
cabo el registro. R02 Da error en el registro si se ha dejado un campo vacío R03 Comprobación de inicio de sesión de un usuario con su correspondiente
contraseña R04 Error si el usuario no existe o la contraseña es incorrecta R05 Error en tipo de usuario si no se ha seleccionado el tipo de usuario Navegación por la aplicación como usuario Cliente
8 Interfaz de programación de aplicaciones 9 Contiene la lógica del resultado final 10 Interfaz gráfica
9
R06 Carga correcta de los productos disponibles
R07 El usuario ha de navegar con fluidez por la pagina inicial R08 Despliegue correcto del menú lateral R10 Correcta carga de los datos correspondiente a cada producto una vez
clickado en uno concreto. R11 Carga correcta de la página de Perfil R12 Posibilidad de editar los datos personales R13 Salir a la página de Login Compra de productos R14 El producto comprado por el usuario debe ser asociado internamente a
éste una vez realizada dicha compra R15 Creación de una nueva Order R16 En la ventana de Mis pedidos, debe aparecer el producto comprado,
incluyendo datos como el estado del pedido Navegación de la aplicación como usuario Vendedor R17 El vendedor deberá ser capaz de visualizar los productos vendidos por
él que se han comprado. R18 Éste deberá confirmar la Order, validándola de éste modo y dando
opción al Transportista a llevar a cabo el proceso de reparto R19 Podrá ver el estado del pedido en cualquier momento R20 Opción de salir a la página de Login Navegación de la aplicación como usuario Transportista R21 El transportista deberá ser capaz de visualizar todos los productos
previamente confirmados por el vendedor, incluyendo la información de éste.
R22 Para cambiar el estado del producto a IN TRANSIT, podrá escanear el código QR asociado al pedido disponible en la página web
R23 Para cambiar el estado del producto a DELIVERED, podrá escanear el código QR asociado al pedido disponible en la página web
R24 Una vez cambiado el estado a DELIVERED, el pedido desaparecerá de la lista de la aplicación móvil
R25 Cuando se realice un escaneo de un QR asociado a un pedido que esté en estado IN TRANSIT, se habrá realizado la entrega, y por ello deberá desaparecer de la misma manera de la lista de la aplicación móvil pero en la aplicación web
R26 Opción de salir a la página de Login
Tabla 1 Requisitos
10
5.2. Red de Blockchain Para poder desplegar el código, generar una API y llevar a cabo las transacciones, es necesario levantar una red para que posteriormente se pueda llamar desde la parte frontal a los servicios e invocar dichas transacciones. Para ello, IBM nos ofrece en su página de Bluemix11 una guía de instalación de diferentes herramientas para llevar a cabo el proceso. Se van a detallar a continuación los pasos seguidos hasta el despliegue completo de la red, incluyendo ilustraciones para su mejor comprensión:
1. Creación de una cuenta en IBM Cloud.
Ilustración 2. Campos a rellenar para crear una cuenta en IBM Cloud
De aquí en adelante toda la instalación se va a llevar a cabo desde la línea de comandos.
2. Descarga e instalación de Hyperledger Composer Cli
11 Servicio de IBM para gestionar datos en la nube
11
Ilustración 3. Comando para instalar Hyperledger Composer Cli
3. Para ciertos comandos va a ser necesaria la descarga de kubernetes, por lo que también se instalarán.
A partir de aquí comienza la configuración del clúster. Este clúster dará una IP pública de donde podremos obtener por diferentes puertos acceso a la Blockchain y a la API.
4. Establecer un punto final de la API. Este punto es muy importante ya que tenemos que establecer como región eu-gb. Esto significa que si iniciamos sesión desde otra zona geográfica que no sea la establecida, no tendremos acceso por términos y condiciones de IBM al clúster.
Ilustración 4. Comando para establecer la región en la que se está.
5. Login. Se realiza para cuando se cree el clúster, se asocie dicho clúster a la cuenta creada anteriormente.
Ilustración 5. Comando para iniciar sesión en Bluemix.
6. IBM permite la creación de un clúster gratuito durante un mes. Cuando pasa el mes, el clúster se borra automáticamente y sería necesario repetir el proceso en su totalidad.
Ilustración 6. Comando para la creación de un clúster gratuito.
7. Para obtener las direcciones IP del clúster(tanto privada como pública) es necesario utilizar el siguiente comando.
12
Ilustración 7. Direcciones IP del clúster de ZOOM
8. El siguiente paso es importante ya que nos permitirá levantar la red ejecutando los scripts12 con kubernetes13. Si no se realiza de manera correcta, dichos scripts darán error y no se podrá continuar.
Ilustración 8. Como exportar las variables de entorno para usar kubernetes Una vez realizado este paso, procederemos a la descarga de los scripts proporcionados por IBM almacenados en un repositorio de Github y a ejecutarlos.
9. Descarga de archivos con el siguiente comando
Ilustración 9. Descarga de scripts para su ejecución
10. Con el comando “./créate_all –with-couchdb” levantaremos la red entera. Es un programa que tarda cierto tiempo en terminar ya que necesita crear una base de datos donde se almacenan las transacciones, llamada couchdb.
12 Programas 13 Sistema que permite desplegar contenedores
13
Ilustración 10. Comando para levantar la red de Blockchain
Ya despegada la red tendremos como resultado la imagen mostrada a continuación. Antes de despegar el Rest Server o API, es necesario desarrollar el código del back-end para que tenga cierta lógica. Por tanto, lo siguiente sería crear una Business Network donde tendremos la posibilidad de desarrollar el modelo y lógica de las transacciones, assets14 y participantes que intervienen en el flujo de la aplicación.
Ilustración 11. Red de Blockchain de Hyperledger
14 Objetos
14
5.3. Herramientas utilizadas En este apartado se comentará las herramientas que se han utilizado para desarrollar el código, almacenarlo y por qué.
5.3.1. Github Para almacenar el código y poder tener diferentes versiones del mismo, se han creado dos repositorios en Github, uno para el código del back-end y otro para el código del front-end. Se ha utilizado esta herramienta y no otra puesto que ya se disponía una cuenta de Github y es la herramienta que más se ha utilizado para este caso.
5.3.2. SourceTree SourceTree es una herramienta que permite de manera visual subir el código a nuestro repositorio, ya sea Github o cualquier otro. Permite crear diferentes ramas destinadas al desarrollo de una parte en concreto del código. Una vez terminada esa tarea, se sube a una rama llamada ‘’development’’ donde se almacena todo el código probado y que funciona correctamente.
5.3.3. VisualStudio Code
15
Herramienta desarrollada por Microsoft. Muy común entre programadores. Se ha utilizado esta herramienta puesto que tiene a mano una ventana de consola para compilar, aunque se podría haber desarrollado en otras como Sublime. Un punto a favor de esta herramienta es que dispone de un plug-in15 del lenguaje propio de Hyperledger, lo que hace que sea una programación más comoda.
5.3.4. Google Drive Dejando a parte el desarrollo del TFG, se ha utilizado la herramienta Drive de Google para clasificar las entregas y documentos que se han ido realizando sobre las versiones de la memoria de dicho trabajo. De esta manera se ha dispuesto de una organización lo que ha permitido acceder a algún punto que se tuviera que revisar de cierta entrega previa.
5.4. Desarrollo del back-end
Una vez llegado al último punto del apartado 4.2, la siguiente tarea es programar un código que permita ejecutar transacciones que modifican datos y almacenarlos en la red, relacionado con el caso de uso que tengamos en mente. Lo primero que tenemos que saber es que hay tres tipos de archivos que van a componer nuestra red:
- Archivo con extensión .cto: En estos ficheros se encuentra lo que vamos a llamar el modelo de nuestro back-end. En él, se van a declarar los campos que contiene un participante, los campos que contiene un asset16 y las transacciones que se van a llevar a cabo. Se desarrolla en un lenguaje diseñado por IBM.
- Archivos con extensión .js: En estos ficheros se van a llevar a cabo la programación de las transacciones. En ellas, se relacionarán los participantes y assets que intervienen en ellas y los cambios o acciones que han de realizarse.
- Archivos con extensión .acl: Toda red de Blockchain ha de tener un
permisionado para los distintos participantes. En el caso de ZOOM, un vendedor no puede ejecutar las mismas transacciones que ejecuta un transportista. En este archivo se contempla esto. Se permite o se restringe la ejecución de
15 Complemento 16 Objeto, en el caso de ZOOM son los productos
16
transacciones. Puesto que cada participante debería tener una card17 y en este caso se va a realizar todo desde la card de administrador, no es necesario desarrollarla ya que no influye en el desarrollo posterior.
Una vez entendido qué es lo que debe contener los archivos que componen la red, se va a realizar una demostración de cómo se ejecutan las transacciones desde la interfaz que nos ofrece IBM y de cómo va cambiando el estado de la red a medida que vamos ejecutando las transacciones. Para empezar, se ha desarrollado el modelo de las transacciones, assets y participantes. El resultado final es el siguiente:
Ilustración 12. Propiedades en un participante
17 Archivo con el que inicias sesión en una determinada red de Blockchain
17
Ilustración 13. Participantes de la red
En la ilustración 12 podemos ver todos los campos que tiene un participante. Muchos de ellos aparecen opcionales ya que solo son para los participantes del tipo Cliente. Desde el front-end obligaríamos al usuario a rellenar esos campos. En la ilustración 13 podemos ver que se declaran los tres tipos de participante heredando los atributos del participante “Business”, que es el genérico. Dando paso a los assets, tenemos dos tipos, los productos y los pedidos.
18
Ilustración 14. Atributos de los assets del flujo
Todo asset se identifica por su id. Dicho id se forma como se muestra en la ilustración 15. Tiene diferentes atributos y tienen asignados algunos participantes. Estas asignaciones se indican con el carácter “ ” , ya que un producto es vendido por un vendedor en concreto y un pedido es creado al realizar una compra por el cliente, confirmado por el vendedor y distribuido por un transportista.
Ilustración 15. Cálculo de un id de un asset a partir de la fecha actual.
Por último, dentro del modelo tenemos las transacciones. Siguen la misma estructura que los assets, quedando de la siguiente manera:
19
Ilustración 16. Transacciones de la red
20
Una vez desarrollado el modelo, se tiene que programar lo que debe realizar cada transacción, y como se ha explicado anteriormente, va en el código de archivos javascript. En las ilustraciones 17, 18 y 19 se muestra cómo está desarrollado el código de las transacciones.
Ilustración 17. Transacción de login
En la transacción de login podemos ver tres variables que son aquellas que se contemplan en el modelo de dicha transacción. A continuación se comprueba el tipo de participante, donde como ya sabemos, puede ser de tres tipos. Si el nombre del participante es del tipo seleccionado, entra en el bucle y comprueba si la contraseña
21
introducida coincide. Si es así, se lleva a cabo la transacción, de lo contrario salta un mensaje de error.
Ilustración 18. Transacción de compra de un producto
En este caso, el cliente compra un producto y al comprarlo se crea un nuevo “Resource” que es el Order o pedido. A este pedido se lee asocia un cliente, vendedor y transportista y se añaden mas datos a los atributos de dicho pedido.
22
Ilustración 19. Transaccion de envío en tránsito
En la ilustración 19 se puede ver una transacción de código bastante corto, pues lo único que hace es actualizar el estado del pedido a en tránsito. Para crear todos los objetos y participantes en la red de Blockchain, se ha diseñado una transacción llamada “SetupDemo” donde crea lo dicho anteriormente con unos datos. Tiene la siguiente apariencia:
Ilustración 20. Parte de la transacción SetupDemo
Una vez desarrollado el código, se van realizando test donde se comprueba que el código desarrollado realiza lo que queremos. En la siguiente ilustración se muestra la interfaz de testing que nos ofrece IBM. Comentar que los datos de los objetos, transacciones y participantes se guardan en formato JSON.
23
Ilustración 21. Interfaz de testing de la red Pinchando en el botón azul nos aparecen todas las transacciones declaradas en el modelo. La manera de probarla es seleccionando una de ellas, introduciendo los datos que te pide y haciendo click en “Submit transaction”. Se muestra un caso de error y un caso de éxito en la transacción de login para comprobar que no se finaliza la ejecución de la transacción al introducir datos incorrectos y que si se finaliza al introducir los datos correctos.
24
Ilustración 22. Caso de error de Credenciales Inválidas dado que la contraseña no es “12” sino “1234”
Cuando una transacción se completa con éxito, se añade al historial de transacciones de la red, donde de manera inmutable quedan registradas desde que se creó la red.
Ilustración 23. Historial de transacciones
25
Ilustración 24. Información sobre la transacción ejecutada Como se explicó anteriormente, IBM ofrece un API REST para poder consumir los servicios desde un frontal. Se despliega en un puerto diferente utilizando la misma IP pública del clúster creado anteriormente.
26
Ilustración 25. API REST de la red de Blockchain
27
5.5. Desarrollo del front-end El desarrollo de un front-end de una aplicación es lo que más puede llevar en cuanto a tiempo se refiere. Se tiene que pensar en aplicaciones similares a tu caso de uso y estudiar como puede encajar. Cuando ya has encontrado varios ejemplos, se trata de realizar un diseño a alto nivel de las distintas páginas que va a encontrarse el usuario según el tipo de participante que es. Hay que analizar detenidamente las experiencias de usuario, si tiene cierta lógica el diseño de la aplicación y la intuición del modelo es también una característica muy importante en la parte visual. A medida que se desarrolla el contenido de la aplicación, los componentes han de llevar estilos (así como colores, tamaños, formatos) y también ha de estar conectado con el back-end que se desarrolló para que todo en conjunto tenga un sentido. Dicho lo cual, el desarrollo del front-end de ZOOM se ha llevado a cabo con el framework18 IONIC3, y lo que debemos saber es que para cada página se van a utilizar tres tipos de archivos:
- Archivos con extensión .html: En él se declaran los componentes de las páginas, así como texto, botones, pastillas, imágenes… Desde estos archivos se hacen llamadas a funciones declaradas en los archivos con extensión .ts. También, se relaciona con los archivos .scss para dar estilos a estas componentes.
- Archivos con extensión .ts: En este tipo de archivos se declaran variables,
funciones, alertas, eventos… El lenguaje es typescript aunque es prácticamente igual a javascript.
- Archivos con extensión .scss: En estos archivos se dan estilos a los componentes
del frontal de la aplicación. A pesar de que se podría meter en el html, se utilizan estos archivos para dejar en el html únicamente componentes y de ésta manera tener un código más clasificado y organizado.
IONIC permite desplegar tu programa en local mediante el comando “ionic serve” e ir desarrollando tu código y al mismo tiempo ver cómo va quedando.
18 Entorno de trabajo
28
Lo primero que se ve nada más arrancar la aplicación es la pantalla de inicio de sesión. Desde aquí podremos iniciar sesión según el tipo de participante que seamos (para ello tenemos un selector) y también disponemos de un registro exclusivo para clientes donde se registran los típicos datos necesarios para contemplar un registro.
Ilustración 26. Pantalla de login
29
Si hacemos click en Regístrate accedemos a la pantalla de registro.
Ilustración 27. Pantalla de registro
Cuando hacemos click en Iniciar Sesión, se hace una llamada al API REST de la transacción login donde se comprueba que los datos de nombre de usuario y contraseña coinciden y el tipo de participante seleccionado es el correcto. De no ser así, se muestra también un mensaje de error. Cuando recibimos un mensaje de tipo 200, salta la siguiente pantalla:
30
Ilustración 28. Pantalla cuando accedes de manera satisfactoria a la aplicación
En este caso hemos iniciado sesión como usuario de tipo cliente. Lo que el cliente va a ver es una lista de productos que hay en la aplicación, indicándose los datos de éstos. Están catalogados como ofertas, populares, recomendaciones… También dispondrá de un menú lateral que permitirá al usuario editar los ajustes de su perfil, ver los pedidos que ha realizado y cerrar sesión. Chrome ofrece la posibilidad como otros navegadores de utilizar el uso del modo Inspeccionar. Este modo ha sido de especial ayuda para el desarrollo del frontal como también de la conexión entre el back-end y el front-end, para ver si recibía de manera correcta los productos registrados en la Blockchain o si se llevaban a cabo de manera correcta las llamadas a los servicios.
31
Ilustración 29. Página principal de ZOOM
Como ya se ha comentado, tenemos un menú lateral donde se puede editar la información del usuario o visualizar los pedidos en curso.
32
Ilustración 30. Menú lateral Accediendo a la sección de mi perfil, obtenemos una visual de los datos del usuario específico. Cabe recordar que todo se recoge de la Blockchain, mediante una petición GET del usuario específico.
33
Ilustración 31. Página de Perfil
Cuando se quiere editar algún campo, se ha de hacer click en el botón de Editar Perfil y de esta manera quedará habilitada la edición. Cuando se hace click en Guardar, se realiza una petición post donde queda registrado en la Blockchain el cambio realizado.
En la página de Mis Pedidos podemos ver todos los pedidos que hemos realizado. Además podremos realizar un seguimiento del estado del pedido, disponer de una imagen para saber el producto que hemos comprado.
34
Ilustración 32. Página de Mis Pedidos Al hacer click en el pedido se muestra un seguimiento del pedido de forma más esquemática, con algunos iconos y colores y con un mensaje aclarando el estado del envío.
35
Ilustración 33. Página del tracking del pedido
Damos paso a la otra parte del flujo de la aplicación en la parte del cliente. Cuando el usuario pincha en un producto desde la página principal, se muestra más información acerca de éste, como una breve descripción del mismo, si se encuentra en stock, el peso… Además, recoge la dirección del usuario para que si se compra dicho producto sea esa la dirección de destino.
36
Ilustración 34. Página de un producto específico
Al hacer click en Comprar, aparece un pequeño recuadro que contiene los términos y condiciones de ZOOM que se han de aceptar para poder confirmar la compra del producto. Además, se dispone de dos métodos de pago para poder llevar a cabo la transación. Es necesario aclarar que el pago se realiza de manera ficticia por lo que no interviene en la operación ningún tipo de dinero real. Tras la compra del producto, se da por finalizado el frontal por parte del cliente.
37
Ilustración 35. Confirmación de compra
Una vez terminada la sección de usuario de tipo cliente, damos paso a la interfaz de usuario de tipo Vendedor. En este caso, se dispone de una única página, donde el usuario confirma el pedido si considera que debe vender el producto, por cualquier motivo. Cuando se confirma el pedido, aparece un pequeño recuadro confirmando que se ha confirmado un pedido específico. Cabe señalar que para esta versión hay únicamente un vendedor, que tiene asociado todos los productos registrados en la Blockchain, pero está programada de tal manera que se puedan registrar más vendedores y más productos.
38
En el momento que se confirma el pedido, es el transportista quien toma el protagonismo en esta parte del flujo del tracking del producto. El vendedor, al igual que el cliente, puede realizar un seguimiento del estado del pedido.
Ilustración 36. Página de pedidos del vendedor
Cuando el vendedor confirma el pedido, a parte de que aparezca un pequeño recuadro, se deshabilita el botón para que no se pueda confirmar de nuevo. Se dispone de un botón de cerrar sesión como en todos los tipos de usuarios. Finalmente damos paso al último tipo de usuario, el transportista. Para este usuario se ha diseñado una parte del flujo en la aplicación móvil y una página web. Desde la aplicación móvil, el transportista hace un escaneo a un código QR19 generado automáticamente desde la web. Cuando el vendedor confirma el pedido, en la sección de pedidos pendientes de envío aparece un QR que contiene el ID del pedido. Al realizar el escaneo, internamente se llama a una función que llama al API REST que
19 Del inglés, Quick Response Code
39
cambia el estado del pedido a “IN TRANSIT”. De la misma manera funciona al escanear de nuevo, esta vez desde la sección de pedidos en tránsito, el QR del pedido específico. Esto se realiza cuando teóricamente el transportista llega al lugar de destino, por lo que internamente al realizar el escaneo QR se llama a una función del API REST que cambia el estado del pedido a “DELIVERED”.
Ilustración 37. Página de pedidos del transportista
40
Ilustración 38. Web donde se visualizan los QR de los pedidos pendientes y en tránsito
Cuando un pedido llega a su estado final, desaparece de la lista en tanto el vendedor como el transportista, ya que por motivos lógicos y visuales, no tiene sentido que siga apareciendo un pedido ya finalizado. Por último, se va a explicar como se ha realizado la conexión entre el front-end y la Blockchain. Se dispone de un archivo typescript llamado “index” donde se declaran todas las funciones que se llaman desde otras páginas. Estas funciones contienen la uri perteneciente a la transacción, cabeceras, parámetros y el tipo de operación, ya sea POST, GET o PUT. En la variable dominio se incluye la dirección a la API, que es la misma que la del clúster, por el puerto 31090. Destacar que se necesitan librerías como “HttpClient” o “HttpResponse”, entre otras, para llevar a cabo las llamadas. Estas librerías son de angular.
41
Ilustración 39. Index.ts . Llamadas al API REST
42
6. ANÁLISIS DE RESULTADOS OBTENIDOS Analizando el resultado final tras haber realizado un estudio de todas las características de la aplicación (esto engloba diseño, experiencia de usuario…) es una versión que cumple con los objetivos propuestos antes de llevar a cabo el desarrollo. Aunque no sea importante para esta versión y no influya en el flujo del tracking de un producto, si queremos cubrir todas las características de la tecnología Blockchain, sería bueno implementar diferentes participantes con restricciones y permisos para ejecutar diferentes transacciones. El problema es que IBM permite hacer esto siempre y cuando se pague una cantidad de dinero exigida por la compañía. Al ser una cifra tan cara y aún no disponer de una versión estable, se decidió utilizar una card de administrador y tener la capacidad de todo tipo de transacciones.
43
7. CONCLUSIONES Realizar un Trabajo de Fin de Grado de estas dimensiones y características requiere una amplia dedicación y un trabajo muy por encima de lo acostumbrado comparado a asignaturas del grado. A pesar de ser un trabajo que requiere unos conocimientos previos de programación en diferentes lenguajes y entendimiento de la filosofía del Blockchain, es necesario dedicar mucho tiempo para que el resultado final no solo cumpla los objetivos, sino que tiene que tener un aspecto que llame la atención y que sea cómodo de usar. Por tanto, los objetivos establecidos al principio del proyecto se han cumplido, por lo que mi opinión el resultado final es satisfactorio. Desde que me introduje en esta tecnología tenía claro que quería enfocar mi Trabajo de Fin de Grado hacia Blockchain. Por tanto, he de agradecer a mi tutor por haberme dado la oportunidad de poder presentar esta tecnología que seguramente esté comenzándose a conocer, al menos de manera hablada, y por lo tanto aporte todavía más curiosidad.
44
8. LINEAS FUTURAS Las líneas futuras de ZOOM engloban principalmente a la parte del front-end. Una de los componentes que sería bueno añadir es un filtro de productos o una búsqueda por nombre. Esto hace de ZOOM una aplicación con más sentido a nivel visual y permite a su vez al usuario de tipo cliente encontrar un producto específico. También, un mejor diseño del tracking del producto en la página de Mis Pedidos aportaría más atracción al cliente y por lo tanto una experiencia de usuario más positiva. Finalmente, sería de gran utilidad añadir la opción de recuperar la contraseña. Se ha diseñado la página pero no se ha implementado un back-end que envíe al correo electrónico una solución para acceder a la cuenta ya que no forma parte de Blockchain y no es el tema principal de este trabajo, aunque si daría más riqueza a la aplicación.
45
9. BIBLIOGRAFÍA Enlaces a repositorios:
- [1] https://github.com/apicazohaase/ZoomFrontend - [2] https://github.com/apicazohaase/ZoomBackend
[3] Red de Blockchain: http://159.122.183.51:31080/ [4] API REST: http://159.122.183.51:31090/explorer/ [5] Términos y condiciones de la compra de un producto: https://www.pronovias.com/es/terminos-y-condiciones-de-compra [6] Framework de Ionic: https://ionicframework.com/ [7] Plataforma de Bluemix de IBM: https://console.bluemix.net/ [8] Repositorio de IBM Hyperledger: https://github.com/hyperledger [9] Guía de instalación seguida para levantar una red de Hyperledger: https://ibm-blockchain.github.io/simple/ [10] “Blockchain” https://www.blockchain.com/ [11] Tracking de un producto: https://www.warehouseanywhere.com/technology/
Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,
C=ES
Fecha/Hora Sun Jun 03 12:38:37 CEST 2018
Emisor delCertificado
[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES
Numero de Serie 630
Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)
