TFG - Repositorio de la Universidad de Jaen: Pàgina de...
Transcript of TFG - Repositorio de la Universidad de Jaen: Pàgina de...
Esc
uela
Pol
itécn
ica
Sup
erio
r de
Jaén
Gra
do e
n In
geni
ería
Inf
orm
átic
a
UNIVERSIDAD DE JAÉN Nombre del Centro
Trabajo Fin de Grado
AGREGADOR DE VENTAS ON-LINE
Alumno: Juan Cazalla Estrella Tutor: Prof. D. Arturo Montejo Ráez Dpto: Nombre Departamento
Septiembre, 2015
Universidad de Jaén
Escuela Politécnica Superior de Jaén Departamento de Informática
Don Arturo Montejo Ráez, tutor del Proyecto Fin de Carrera titulado: Agregador de ventas online, que presenta Juan Cazalla Estrella, autoriza su presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.
Jaén, Septiembre de 2015
El alumno: Los tutores:
Juan Cazalla Estrella Arturo Montejo Ráez
Juan Cazalla Estrella Agregador de ventas online
2 Escuela Politécnica Superior de Jaén Escuela Politécnica Superior de Jaén
Juan Cazalla Estrella Agregador de ventas online
3 Escuela Politécnica Superior de Jaén Escuela Politécnica Superior de Jaén
Agradecimientos
En primer lugar, dar las gracias a mi familia por el apoyo que han sido para mí
durante toda mi vida y por darme la educación más importante. Si hoy estoy
entregando este proyecto es, sin duda, gracias a ellos.
Me gustaría, especialmente, agradecer a mi pareja, Victoria, que siempre ha
estado cuando la he necesitado y que me ha motivado a superarme día a día.
Gracias por tu comprensión, por tu desinteresada e incansable ayuda y por
enseñarme a darle importancia a mi trabajo y a no rendirme cuando las cosas no
han ido como esperaba.
Agradecer también a mis amigos y compañeros de Universidad por la gran
ayuda que han supuesto para mí. Sin duda, lo mejor que me llevo de la Universidad
son estas personas.
Por último, agradecer a todos y cada uno de los profesores y personas
involucradas en mi formación durante mi estancia en la Universidad de Jaén, en
especial a Arturo Montejo Ráez quien, de una u otra manera, ha sido un ejemplo
para mí a la hora de ser perfeccionista y profesional.
A todos ellos, muchas gracias.
Juan Cazalla Estrella Agregador de ventas online
4 Escuela Politécnica Superior de Jaén Escuela Politécnica Superior de Jaén
Juan Cazalla Estrella Agregador de ventas online
5 Escuela Politécnica Superior de Jaén Escuela Politécnica Superior de Jaén
Índice
1. INTRODUCCIÓN ............................................................................................................. 11 1.1. Motivación ................................................................................................................. 11 1.2. Objetivos ................................................................................................................... 12 1.3. Metodología y modelo de desarrollo ......................................................................... 12 1.4. Estructura de la memoria .......................................................................................... 15
2. ANÁLISIS ........................................................................................................................ 17 2.1. Análisis de soluciones anteriores .............................................................................. 17 2.2. Propuesta de solución ............................................................................................... 17 2.3. Análisis de requisitos ................................................................................................. 18
2.3.1. Requisitos Funcionales ....................................................................................... 18 2.3.2. Requisitos No Funcionales ................................................................................. 19
2.4. Casos de uso ............................................................................................................ 20 2.5. Planificación de tareas .............................................................................................. 25
2.5.1. Backlog y sprints ................................................................................................. 26 2.6. Estudio de viabilidad ................................................................................................. 32
2.6.1. Gastos de hardware ............................................................................................ 32 2.6.2. Gastos de licencias de software ......................................................................... 32 2.6.3. Servicios externos ............................................................................................... 33 2.6.4. Gastos de personal ............................................................................................. 33 2.6.5. Gastos totales y de viabilidad ............................................................................. 33
3. DISEÑO DEL SISTEMA .................................................................................................. 35 3.1. Introducción ............................................................................................................... 35 3.2. Diseño de la base de datos ....................................................................................... 36
3.2.1. Modelo Entidad/Relación .................................................................................... 36 3.2.2. Bases de datos actuales ..................................................................................... 37 3.2.3. Estudio de la base de datos a usar ..................................................................... 39 3.2.4. Entidades en base de datos NoSQL ................................................................... 40
3.3. Diseño de la interfaz .................................................................................................. 42 3.3.1. Registro e inicio de sesión .................................................................................. 42 3.3.2. Cerrar sesión ...................................................................................................... 45 3.3.3. Compartir oferta .................................................................................................. 47 3.3.4. Detalle de una oferta ........................................................................................... 49 3.3.5. Marcar oferta como favorita ................................................................................ 50
Juan Cazalla Estrella Agregador de ventas online
6 Escuela Politécnica Superior de Jaén Escuela Politécnica Superior de Jaén
3.3.6. Abrir tienda de oferta .......................................................................................... 51 3.3.7. Ofertas compartidas por el usuario ..................................................................... 52 3.3.8. Ofertas favoritas del usuario ............................................................................... 53
4. IMPLEMENTACIÓN ........................................................................................................ 55 4.1. Selección de tecnologías .......................................................................................... 55
4.1.1. Aplicación cliente ................................................................................................ 55 4.1.1.1. iOS ................................................................................................................... 55 4.1.1.2. Entornos de programación ............................................................................... 56 4.1.1.3. Fabric Crashlytics ............................................................................................. 57 4.1.1.4. CocoaPods ....................................................................................................... 58 4.1.1.5. TyphoonFramework ......................................................................................... 58 4.1.1.6. ReactiveCocoa ................................................................................................. 59 4.1.2. Servidor ............................................................................................................... 59 4.1.2.1. Parse ................................................................................................................ 59
4.2. Arquitectura del sistema ............................................................................................ 60 4.2.1. Arquitectura de la aplicación cliente para iOS .................................................... 63
4.3. Implementación del sistema ...................................................................................... 65 4.3.1. Implementación del servidor en Parse ................................................................ 65 4.3.2. Implementación de aplicación cliente en iOS ..................................................... 67 4.3.2.1. Capa de presentación ...................................................................................... 67 4.3.2.2. Capa de dominio .............................................................................................. 69 4.3.2.3. Capa de datos .................................................................................................. 70 4.3.2.4. Inyección de dependencias con TyphoonFramework ...................................... 71 4.3.2.5. Gestión de las dependencias ........................................................................... 72
4.4. Pruebas y validación ................................................................................................. 73 5. CONCLUSIÓN ................................................................................................................. 75
5.1. Áreas de mejora y trabajos futuros ........................................................................... 76 Bibliografía ............................................................................................................................. 79 ANEXO I ................................................................................................................................. 83 Manual de puesta en marcha del sistema ............................................................................. 83 ANEXO II ................................................................................................................................ 89 Manual de usuario de la aplicación ........................................................................................ 89
Juan Cazalla Estrella Agregador de ventas online
7 Escuela Politécnica Superior de Jaén Escuela Politécnica Superior de Jaén
Índice de ilustraciones
Ilustración 1.1 - Esquema de proceso de desarrollo .............................................................. 15 Ilustración 3.1 - Modelo entidad-relación ............................................................................... 36 Ilustración 3.2 - Escalabilidad NoSQL vs SQL ....................................................................... 37 Ilustración 3.3 - Tiempo de inserción NoSQL vs SQL ............................................................ 38 Ilustración 3.4 - Diagrama de flujo de registro e inicio de sesión ........................................... 43 Ilustración 3.5 - Storyboard de registro e inicio de sesión ..................................................... 44 Ilustración 3.6 - Diagrama de flujo de cierre de sesión .......................................................... 45 Ilustración 3.7 - Storyboard de cierre de sesión ..................................................................... 46 Ilustración 3.8 - Diagrama de flujo de compartir oferta .......................................................... 47 Ilustración 3.9 - Storyboard de compartir oferta ..................................................................... 48 Ilustración 3.10 - Diagrama de flujo de detalle de una oferta ................................................. 49 Ilustración 3.11 - Storyboard de detalle de una oferta ........................................................... 49 Ilustración 3.12 - Diagrama de flujo de marcar una oferta como favorita .............................. 50 Ilustración 3.13 - Storyboard de marcar una oferta como favorita ......................................... 50 Ilustración 3.14 - Diagrama de flujo de abrir tienda de oferta ................................................ 51 Ilustración 3.15 - Storyboard de abrir tienda de oferta ........................................................... 51 Ilustración 3.16 - Diagrama de flujo de ofertas compartidas por el usuario ........................... 52 Ilustración 3.17 - Storyboard de ofertas compartidas por el usuario ...................................... 52 Ilustración 3.18 - Diagrama de flujo de ofertas favoritas del usuario ..................................... 53 Ilustración 3.19 - Storyboard de ofertas favoritas del usuario ................................................ 53 Ilustración 4.1 - Capas del sistema operativo iOS ................................................................. 56 Ilustración 4.2 - Arquitectura del Sistema .............................................................................. 60 Ilustración 4.3 - Diagrama de flujo de un caso de uso ........................................................... 62 Ilustración 4.4 - Arquitectura de la aplicación iOS ................................................................. 65 Ilustración 4.5 - Crear proyecto en Parse .............................................................................. 65 Ilustración 4.6 - Claves de aplicación en Parse ..................................................................... 66 Ilustración 4.7 - Configuración de las claves de Parse en iOS .............................................. 66 Ilustración 4.8 - Añadir tablas en Parse ................................................................................. 67 Ilustración 4.9 - Organización de la capa de presentación .................................................... 69 Ilustración 4.10 - Organización de la capa de dominio .......................................................... 70 Ilustración 4.11 - Organización de la capa de datos .............................................................. 71 Ilustración 4.12 - Ejemplo de inyección de dependencias ..................................................... 71 Ilustración 4.13 - Módulo Assembly ....................................................................................... 72 Ilustración 4.14 - Podfile con las dependencias ..................................................................... 73
Juan Cazalla Estrella Agregador de ventas online
8 Escuela Politécnica Superior de Jaén Escuela Politécnica Superior de Jaén
Juan Cazalla Estrella Agregador de ventas online
9 Escuela Politécnica Superior de Jaén Escuela Politécnica Superior de Jaén
Índice de tablas
Tabla 1.1 - Características de las metodologías .................................................................... 14 Tabla 2.1 - Caso de uso Registrarse ...................................................................................... 20 Tabla 2.2 - Caso de uso Iniciar Sesión .................................................................................. 21 Tabla 2.3 - Caso de uso Cerrar sesión .................................................................................. 21 Tabla 2.4 - Caso de uso Ver lista de las mejores ofertas ...................................................... 22 Tabla 2.5 - Caso de uso Compartir oferta .............................................................................. 22 Tabla 2.6 - Caso de uso Ver detalle de oferta ....................................................................... 23 Tabla 2.7 - Caso de uso Abrir tienda de oferta ...................................................................... 23 Tabla 2.8 - Caso de uso Marcar oferta como favorita ............................................................ 24 Tabla 2.9 - Caso de uso Ver lista de ofertas favoritas ........................................................... 24 Tabla 2.10 - Caso de uso Ver mis ofertas compartidas ......................................................... 25 Tabla 2.11 - Backlog inicial .................................................................................................... 26 Tabla 2.12 - Sprint 1 ............................................................................................................... 27 Tabla 2.13 - Sprint 2 ............................................................................................................... 27 Tabla 2.14 - Sprint 3 ............................................................................................................... 28 Tabla 2.15 - Backlog 2 ........................................................................................................... 29 Tabla 2.16 - Sprint 4 ............................................................................................................... 30 Tabla 2.17 - Sprint 5 ............................................................................................................... 30 Tabla 2.18 - Sprint 6 ............................................................................................................... 30 Tabla 2.19 - Sprint 7 ............................................................................................................... 30 Tabla 2.20 - Sprint 8 ............................................................................................................... 30 Tabla 2.21 - Backlog 3 ........................................................................................................... 31 Tabla 2.22 - Sprint 9 ............................................................................................................... 31 Tabla 2.23 - Gastos de Hardware .......................................................................................... 32 Tabla 2.24 - Gastos de Software ........................................................................................... 32 Tabla 2.25 - Gastos Externos ................................................................................................. 33 Tabla 2.26 - Gastos de Personal ........................................................................................... 33 Tabla 2.27 - Gastos Totales ................................................................................................... 33 Tabla 3.1 - Entidad Usuario .................................................................................................... 40 Tabla 3.2 - Entidad oferta ....................................................................................................... 41
Juan Cazalla Estrella Agregador de ventas online
10 Escuela Politécnica Superior de Jaén
Juan Cazalla Estrella Agregador de ventas online
11 Escuela Politécnica Superior de Jaén
1. INTRODUCCIÓN
Vivimos en un mundo dominado por la tecnología en el que nadie puede vivir
sin un teléfono móvil. Mientras que hace algo más de una década tan sólo se
utilizaban para realizar llamadas telefónicas, con el aumento de potencia en los
procesadores móviles y la llegada de internet, fuera del mundo profesional los
smartphone han sustituido completamente a los ordenadores. Además, la cantidad
de videojuegos y aplicaciones infantiles han provocado que la edad de acceso al uso
de smartphones sea cada vez menor.
Por otra parte, pese a que hace unos años la gente era reacia a ofrecer datos
bancarios en internet, en la actualidad la sociedad está perdiendo este miedo
empujada por la comodidad de pagar online y la imposibilidad de usar otro medio de
pago en una gran cantidad de servicios.
Todo esto ha conducido a que la forma de realizar las compras haya cambiado
totalmente. Ahora, por internet se hace la compra de comida, material mobiliario,
artículos de tecnología, vacaciones o incluso seguros de coches. Sin embargo, la
facilidad con la que puedes consultar el precio de los distintas tiendas online ha
provocado que una gran cantidad de compradores pasen mucho tiempo
comparando los precios y servicios de cada una de las tiendas y revisando las
opiniones de los usuarios.
1.1. Motivación
Mi motivación para realización de este TFG es la idea de diseñar una
aplicación que haga más fácil a los compradores encontrar buenas ofertas para los
productos que desean adquirir.
Pese a que existen comparadores de precios online, suelen ser muy escasos
en la cantidad de tiendas que comparan. Mi propuesta es distinta y se basa en el
funcionamiento del agregador de noticias Meneame.net en el que es el usuario quien
comparte las que le parecen interesantes. De esta forma, se pretende conseguir un
ranking con las mejores ofertas de tiendas online compartidas por usuarios.
Juan Cazalla Estrella Agregador de ventas online
12 Escuela Politécnica Superior de Jaén
Además, quería hacer una aplicación con enfoque social y que se basase en el
consumo de servicios REST, que es el patrón más repetido en las aplicaciones
profesionales actuales.
1.2. Objetivos
Teniendo en mente la idea planteada anteriormente, el objetivo que deseo
satisfacer con el prototipo que voy a desarrollar es el de ofrecer una aplicación
capaz de facilitar a los usuarios la tarea de encontrar las mejores ofertas en distintas
tiendas online, sin menospreciar la oportunidad que pueden tener las tiendas menos
populares de darse a conocer.
Sin embargo, considero que la calidad del software es clave para que una
buena idea se convierta en un buen producto, y como tal, me he centrado en
desarrollar el prototipo prestando la máxima atención a apartados como el diseño o
la arquitectura del software de la aplicación, pues estos apartados son claves para
crear código mantenible, testable y fácil de entender.
Para conseguirlo, los objetivos han sido:
- Aplicar los principios de SOLID.
- Explorar distintas soluciones para las tareas asíncronas como puede ser
una consulta a una API REST.
- Plantear un paradigma de programación reactiva y analizar su eficacia
para aplicaciones del tipo de la que se presenta.
- Analizar la forma más rápida de desarrollar un prototipo de aplicación.
1.3. Metodología y modelo de desarrollo
Para la realización de este proyecto me he basado en un modelo de desarrollo
iterativo y creciente[16]. Este modelo de desarrollo no es más que un conjunto de
tareas agrupadas en pequeñas iteraciones.
Este modelo se ha convertido en uno de los más utilizados en los últimos años,
sobre todo en proyectos donde no se sabe a ciencia cierta si puede haber cambios
de requisitos durante el desarrollo.
Juan Cazalla Estrella Agregador de ventas online
13 Escuela Politécnica Superior de Jaén
La idea principal que persigue este modelo de desarrollo es permitir al
desarrollador sacar ventaja de lo aprendido en la iteración anterior. Los pasos claves
en el proceso son comenzar con una implementación simple de los requerimientos
del sistema, e iterativamente mejorar la solución hasta que el sistema completo esté
implementado.
La base de este modelo reside en el desconocimiento de los usuarios para
encontrar una solución que satisface sus necesidades. Además, tiene en cuenta que
en el desarrollo suelen surgir cambios.
He seleccionado este modelo de desarrollo para afrontar el proyecto porque no
tenía unos requisitos exactos conocidos desde el principio. Además, en primera
instancia, carecía de experiencia en las herramientas utilizadas y el sistema
operativo iOS, por lo que era previsible que se produjesen cambios a medida que iba
avanzando.
Aunque es muy común el uso de una metodología de programación extrema[17]
acompañando a este modelo de desarrollo, en el presente caso se ha seguido una
metodología Scrum[18], aunque con sprints de tan sólo una semana.
Scrum es un esqueleto de proceso que incluye un conjunto de prácticas y roles
predefinidos. Los roles principales en Scrum son el ScrumMaster que mantiene los
procesos y trabaja junto con el jefe de proyecto, el Product Owner que representa a
las personas implicadas en el negocio y el Team que incluye a los desarrolladores.
Lógicamente, puesto que en este proyecto solamente participo yo, me he encargado
de todos los roles.
El funcionamiento se basa en que en cada iteración (en nuestro caso de 1
semana, aunque lo recomendado es entre 2 y 4 semanas), el equipo crea un
incremento de software operativo. El conjunto de características que entra en una
iteración viene del backlog del producto, que es un conjunto priorizado de requisitos
de trabajo de alto nivel que se han de hacer. Los ítem que entran en una iteración se
determinan durante la reunión de planificación de la misma. Durante esta reunión, el
Product Owner informa al equipo de los ítem en el backlog del producto que quiere
que se completen. El equipo determina entonces la cantidad de tareas que puede
Juan Cazalla Estrella Agregador de ventas online
14 Escuela Politécnica Superior de Jaén
comprometerse a completar durante la siguiente iteración. Durante una iteración,
nadie puede cambiar el backlog y una vez completada, el equipo demuestra el uso
del software.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto
los desafíos que no se pueden predecir no se pueden tratar fácilmente de una forma
predictiva o planificada tradicional. Por esto, Scrum adopta un enfoque empírico,
aceptando que el problema no se puede entender o definir completamente. Puesto
que es muy probable que se realicen una gran cantidad de cambios durante el
desarrollo del proyecto a medida que conozca mejor las herramientas y requisitos
deseados, me he decantado por esta metodología en lugar de utilizar programación
extrema. Como vemos en la tabla 1.3, Scrum se adapta mejor a los cambios.
Crystal DSDM LD Scrum XP Resultados 5 4 4 5 5 Simplicidad 4 3 3 5 5 Adaptabilidad 5 3 4 4 3 Excelencia técnica 3 4 4 3 4 Prácticas de colaboración 5 4 3 4 5 Media Total 4.5 3.6 3.9 4.7 4.8 Tabla 1.1 - Características de las metodologías
Por último, una de las mayores ventajas de Scrum es que es muy fácil de
entender y requiere poco esfuerzo para comenzar a usarse. Las reuniones que se
realizan durante cada iteración son de distintos tipos:
- Scrum diario: cada día durante la iteración, tiene lugar una reunión de
estado del proyecto. A esta reunión se le domina daily
- Reunión de planificación de iteración (sprint): se lleva a cabo al principio
del ciclo de la iteración.
- Reunión de revisión de iteración: al final del ciclo de la iteración.
- Iteración retrospectiva: al final del ciclo de la iteración.
Juan Cazalla Estrella Agregador de ventas online
15 Escuela Politécnica Superior de Jaén
Con todo esto, el esquema básico del proceso de desarrollo escogido queda
como en la ilustración 1.1:
Ilustración 1.1 - Esquema de proceso de desarrollo
1.4. Estructura de la memoria
Una vez terminado el capítulo de introducción de esta memoria, en este
apartado haré un pequeño resumen de cada uno de los capítulos restantes.
En el capítulo 2 se realiza un análisis completo del sistema a desarrollar, con
una propuesta de solución, el estudio de los requisitos que se deben satisfacer, la
planificación de tareas y el estudio de la viabilidad del proyecto.
En el capítulo 3 me centro en realizar un estudio del diseño de la base de
datos. Además se realiza el diseño de un storyboard que indica el flujo entre
pantallas de la aplicación.
Durante el cuarto capítulo de esta memoria, se explica como he llevado a cabo
la implementación del sistema completo, especificando cuales han sido las
tecnologías seleccionadas y cómo se han realizado el diseño y arquitectura del
código de la aplicación.
En el quinto y último capítulo se exponen una serie de conclusiones y análisis
de los objetivos cumplidos. Además, se reflejan posibles áreas de mejora o trabajos
futuros que se han considerado interesantes para la aplicación.
Juan Cazalla Estrella Agregador de ventas online
16 Escuela Politécnica Superior de Jaén
Por último, para cerrar la memoria, se incluye la bibliografía y los enlaces a
recursos en los que me he basado para llevar a cabo el desarrollo de este proyecto y
un par de anexos a modo de manual de instalación y un manual de usuario.
Juan Cazalla Estrella Agregador de ventas online
17 Escuela Politécnica Superior de Jaén
2. ANÁLISIS
2.1. Análisis de soluciones anteriores
El principal objetivo de este proyecto es crear una aplicación que pudiera ser
referente a la hora de buscar ofertas por internet. En la actualidad, ya existen gran
multitud de aplicaciones con el mismo fin. Entre ellas destacan Ofertia, Tiendeo y
Shoppydoo en las que se ofrece un catálogo de productos junto con la comparación
de precios en un número limitado de tiendas online. Estas distintas aplicaciones
cuentan con más de 1 millón de descargas Google Play Store, la plataforma de
descarga de aplicaciones del sistema operativo Android, donde es posible tener
acceso a esta información.
Además, existen otra gran cantidad de aplicaciones también orientadas a
encontrar “chollos” online como Groupon donde cada día se comparten una lista de
ofertas interesantes o descuentos. En este caso, Groupon cuenta con más de 10
millones de descargas en la plataforma mencionada anteriormente.
Estos datos dejan claro que tendría sentido el desarrollo de una aplicación de
este estilo, ya que hay una cantidad de clientes potenciales. Aunque en realidad es
un mercado que ya está en gran medida cubierto, el uso de aplicaciones en este
ámbito no es excluyente y los usuarios suelen compaginar el uso de distintas
aplicaciones de ofertas porque con todas puede salir beneficiado.
2.2. Propuesta de solución
El principal objetivo de este proyecto es crear una aplicación que compita en el
mercado comentado en el apartado anterior. Para conseguirlo, como se comentó en
la introducción de esta memoria, se ha seguido un planteamiento donde la
característica diferenciadora es que los usuarios serán los que compartan las ofertas
que consideren atractivas.
La propuesta es una aplicación en la que el usuario pueda encontrar ofertas no
sólo de una lista de tiendas, sino de cualquier tienda que pueda haber en internet.
Además, se podrá usar sin tener que crear una cuenta en la aplicación. En caso de
que se quieran compartir o valorar anuncios, el usuario sí tendrá que crear una
cuenta. Puesto que nos interesa que sea fácil compartir o valorar anuncios, que es la
Juan Cazalla Estrella Agregador de ventas online
18 Escuela Politécnica Superior de Jaén
clave para el funcionamiento del producto, la forma de crear una cuenta para la
aplicación deberá ser lo más simple posible.
Algo a tener en cuenta en esta propuesta es que nuestro objetivo no es
competir con las demás soluciones comentadas anteriormente, sino hacernos con el
mayor número posible de usuarios. Para ello, se podrán compartir ofertas
encontradas en páginas como Groupon, Tiendeo o cualquiera del estilo para así
aprovechar su potencial en beneficio de nuestra aplicación.
Por último, comentar que se realizará un análisis más profundo de esta
solución propuesta en futuros apartados, examinado las tecnologías que se usarán
para construir un prototipo de la aplicación en el sistema operativo iOS. Lo ideal si se
desea tener éxito es tener también una aplicación Web y una aplicación Android,
aunque es algo cuya implementación quedará abierta para posibles extensiones de
este proyecto. Se ha elegido como nombre para el prototipo desarrollado SnipShare.
2.3. Análisis de requisitos
En este apartado, se analiza de una forma más formal qué es lo que el
prototipo que se va a desarrollar debe satisfacer. Para ello se realiza un estudio de
los requisitos funcionales y no funcionales. Si se desea conocer en mayor
profundidad en qué consisten estos requisitos es recomendable revisar las
referencia [19] en la bibliografía.
2.3.1. Requisitos Funcionales
• Se podrán compartir ofertas de cualquier tienda online.
• La aplicación debe mostrar la lista ordenada de los anuncios atendiendo
a la valoración de éstos.
• La aplicación deberá ser totalmente funcional para los usuarios que no
hayan iniciado sesión, a excepción de las funcionalidades de compartir
un anuncio y marcar como favorito.
• Los usuarios que han iniciado sesión podrán compartir las ofertas que
consideren atractivas y añadir éstas a sus favoritas de forma rápida y
sencilla.
Juan Cazalla Estrella Agregador de ventas online
19 Escuela Politécnica Superior de Jaén
• Desde la aplicación, podrá accederse a la tienda online de cada anuncio
para comprar el producto.
• Un usuario que haya iniciado sesión podrá ver sus ofertas compartidas.
• Un usuario que haya iniciado sesión podrá ver sus anuncios favoritos.
• Los anuncios no serán editables para evitar fraudes en las valoraciones.
• El inicio de sesión en la aplicación se deberá hacer con Twitter de la
forma más sencilla posible, sin requerimiento de contraseña y utilizando
la cuenta que esté utilizando en el teléfono.
2.3.2. Requisitos No Funcionales
• Los tiempos de carga en la aplicación deberán ser óptimos.
• La aplicación deberá ser fácilmente extensible.
• Se deberá soportar un cambio en la fuente de datos de la aplicación de
forma fácil.
• En caso de que una petición a la red consuma demasiado tiempo, ésta
deberá ser cancelada para no afectar al consumo de batería.
• La aplicación deberá ser fluida, sin quedar en ningún momento la
interfaz bloqueada.
• El diseño seguirá las guías del sistema operativo en el que se desarrolle
para que los usuarios aprendan a utilizarla sin dificultad.
• Los iconos de la aplicación también seguirán el estándar del sistema
operativo en el que se desarrolle.
Juan Cazalla Estrella Agregador de ventas online
20 Escuela Politécnica Superior de Jaén
2.4. Casos de uso
En este apartado describimos las acciones y reacciones del sistema y los
límites de éste con los siguientes casos de uso:
Caso de Uso Registrarse
Actor primario Usuario sin registrar
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa
1- El usuario no está registrado en el sistema.
2- El usuario posee una cuenta en Twitter
3- El usuario ha iniciado sesión en Twitter en el
smartphone.
Flujo normal 1- El actor pulsa el botón de registro.
2- El sistema realiza la petición de registro al servidor.
3- La vista cambia al perfil del usuario.
Flujo alternativo
2- Si el usuario posee varias cuentas de Twitter en el
smartphone, el sistema preguntará con cuál desea
registrarse antes de realizar la petición de registro.
3- En caso de haber cualquier tipo de error no se registrará
ni iniciará sesión. Quedará en la vista de registro.
Postcondiciones El actor ha quedado registrado en el sistema y con la sesión
iniciada. Tabla 2.1 - Caso de uso Registrarse
Juan Cazalla Estrella Agregador de ventas online
21 Escuela Politécnica Superior de Jaén
Caso de Uso Iniciar sesión
Actor primario Usuario registrado
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa 1- El usuario está registrado.
2- El usuario no ha iniciado sesión.
Flujo normal
1- El actor pulsa el botón de iniciar sesión.
2- El sistema realiza la petición de inicio de sesión al
servidor.
3- La vista cambia al perfil del usuario.
Flujo alternativo
2- Si el usuario posee varias cuentas de Twitter en el
smartphone, el sistema preguntará con cuál desea iniciar
sesión antes de realizar la petición.
3- En caso de haber cualquier tipo de error no iniciará
sesión. Quedará en la vista de inicio de sesión.
Postcondiciones El actor ha quedado identificado en el sistema. Tabla 2.2 - Caso de uso Iniciar Sesión
Caso de Uso Cerrar sesión
Actor primario Usuario identificado
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa El usuario ha iniciado sesión.
Flujo normal 1- El actor pulsa el botón de iniciar sesión.
2- La vista cambia a la pantalla de inicio de sesión.
Postcondiciones La sesión ha quedado cerrada Tabla 2.3 - Caso de uso Cerrar sesión
Juan Cazalla Estrella Agregador de ventas online
22 Escuela Politécnica Superior de Jaén
Caso de Uso Ver lista de las mejores ofertas
Actor primario Usuario
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa Existen ofertas compartidas en la aplicación
Flujo normal
1- El actor pulsa la pestaña de la lista de ofertas.
2- Se envía la petición al servidor para descargar la lista de
ofertas ordenadas por la cantidad de veces que han sido
marcadas como favoritas.
Postcondiciones La lista de las ofertas se muestra en pantalla Tabla 2.4 - Caso de uso Ver lista de las mejores ofertas
Caso de Uso Compartir oferta
Actor primario Usuario identificado
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa El usuario ha iniciado sesión.
Flujo normal
1- El actor pulsa el botón de compartir oferta.
2- Rellena los campos solicitados en la oferta.
3- Pulsa para compartir la oferta.
4- Envía la petición al servidor para añadir la nueva oferta.
5- Vuelve a la lista de ofertas y refresca los datos.
Postcondiciones La oferta ha quedado añadida y ahora aparece en la lista. Tabla 2.5 - Caso de uso Compartir oferta
Juan Cazalla Estrella Agregador de ventas online
23 Escuela Politécnica Superior de Jaén
Caso de Uso Ver detalle de oferta
Actor primario Usuario
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa Estar en la vista de la lista de ofertas
Flujo normal 1- El actor pulsa en una oferta.
2- Se muestra una nueva pantalla con la información de la
oferta.
Postcondiciones El usuario puede ver todos los datos de la oferta. Tabla 2.6 - Caso de uso Ver detalle de oferta
Caso de Uso Abrir tienda de oferta
Actor primario Usuario
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa Estar en la vista de detalle de una oferta
Flujo normal 1- El actor pulsa en la tienda de la oferta.
2- SnipShare lanza el navegador con el enlace de la oferta.
Postcondiciones El usuario puede ver la oferta en la tienda online. Tabla 2.7 - Caso de uso Abrir tienda de oferta
Juan Cazalla Estrella Agregador de ventas online
24 Escuela Politécnica Superior de Jaén
Caso de Uso Marcar oferta como favorita
Actor primario Usuario identificado
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa Estar en la vista de detalle de una oferta
Flujo normal 1- El actor pulsa en añadir a favoritos.
2- Se lanza una petición al servidor añadiendo la oferta a la
lista de favoritas.
Postcondiciones La oferta aparecerá en la lista de favoritos del usuario. Tabla 2.8 - Caso de uso Marcar oferta como favorita
Caso de Uso Ver lista de ofertas favoritas
Actor primario Usuario identificado
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa 1- Haber iniciado sesión en la aplicación.
2- Estar en la vista de perfil de usuario.
Flujo normal
1- El actor pulsa en Favoritos.
2- Se lanza una petición al servidor para solicitar los
favoritos del usuario.
3- Se muestra la lista de favoritos
Postcondiciones El usuario puede ver su lista de favoritos. Tabla 2.9 - Caso de uso Ver lista de ofertas favoritas
Juan Cazalla Estrella Agregador de ventas online
25 Escuela Politécnica Superior de Jaén
Caso de Uso Ver mis ofertas compartidas
Actor primario Usuario identificado
Sistema SnipShare App
Participantes Usuario y servidor
Nivel Objetivo usuario
Condición Previa 1- Haber iniciado sesión en la aplicación.
2- Estar en la vista de perfil de usuario.
Flujo normal
1- El actor pulsa en Mis ofertas.
2- Se lanza una petición al servidor para solicitar las ofertas
compartidas por el usuario.
3- Se muestra la lista de ofertas del usuario
Postcondiciones El usuario puede ver su lista ofertas compartidas Tabla 2.10 - Caso de uso Ver mis ofertas compartidas
2.5. Planificación de tareas
Durante el desarrollo del proyecto se ha utilizado la metodología Scrum[18]
como ya expliqué en apartados anteriores. La planificación de las tareas se ha ido
decidiendo en cada sprint. Durante el desarrollo se ha ido modificando el backlog[18]
a medida que se tenía más conocimiento sobre las distintas dificultades que se iban
planteando.
A continuación, a modo de explicación de la planificación que se ha seguido, se
muestra el estado del backlog al inicio del proyecto (tabla 2.11) y las modificaciones
que se han ido haciendo en éste. Además, se explica cómo se han ido dividiendo las
tareas del backlog en los distintos sprints. Como ya se comentó en la introducción de
esta memoria, se han seguido sprints de una semana de duración debido a que
había muy poco conocimiento de lo que se iba a crear y las estimaciones de dos
semanas podrían ser muy desacertadas. Con el paso del tiempo y una vez se
conocía mejor cuál era la cadencia de puntos de historia por semana y el producto,
los sprint pasaron a ser de hasta cuatro semanas.
Juan Cazalla Estrella Agregador de ventas online
26 Escuela Politécnica Superior de Jaén
2.5.1. Backlog y sprints
ID Historias de usuario Puntos
SS-1 Análisis de requisitos funcionales 10
SS-1.1 - Investigación de soluciones actuales 5
SS-1.2 - Determinación de los requisitos funcionales 5
SS-2 Análisis de requisitos no funcionales 10
SS-2.1 - Investigación de soluciones actuales 5
SS-2.2 - Determinación de los requisitos no funcionales 5
SS-3 Determinación del servicio web que se va a usar para el desarrollo
50
SS-3.1 - Investigación de distintas opciones para crear el
servicio web
40
SS-3.2 - Pequeña prueba con el servicio web elegido para saber
si es lo que se necesita
10
SS-4 Determinación de la arquitectura y herramientas para realizar la aplicación cliente.
50
SS-4.1 - Investigar sobre los distintos lenguajes que es posible
usar para el desarrollo de aplicaciones en el sistema
operativo iOS y seleccionar uno
10
SS-4.2 - Estudio para determinar una arquitectura adecuada
para usar en aplicaciones iOS
20
SS-4.3 - Investigar distintas librerías o herramientas que podrían
ser necesarias durante el desarrollo
10
SS-4.4 - Prueba de la arquitectura y lenguaje elegidos 10 Tabla 2.11 - Backlog inicial
Juan Cazalla Estrella Agregador de ventas online
27 Escuela Politécnica Superior de Jaén
Con este backlog inicial, el primer sprint que realicé fue el de la tabla 2.12:
Historias de usuario Puntos de historia
SS-1 10
SS-2 10
SS-3 50 Tabla 2.12 - Sprint 1
Como se puede ver, la cantidad de puntos de historia asignada al primer sprint
fue 70, sin embargo, la estimación no fue del todo buena porque finalmente tan sólo
se consiguió acabar SS-1, SS-2 y aproximadamente la mitad de la tarea SS-3.1 así
que se modificó la cadencia a unos 40 puntos de historia por sprint.
Con el trabajo de esta semana ya se sabía cuáles iban a ser los requisitos de la
aplicación, sin embargo no se añadieron tareas nuevas al backlog hasta ir
conociendo las posibles soluciones de servicios web y tener claro qué
funcionalidades estarían implementadas en el cliente y en el servidor.
En el segundo sprint (tabla 2.13), volvió a entrar la historia de usuario SS-3 con
los 30 puntos aproximados que le quedaban.
Historias de usuario Puntos de historia
SS-3 30
SS-4.1 10 Tabla 2.13 - Sprint 2
Juan Cazalla Estrella Agregador de ventas online
28 Escuela Politécnica Superior de Jaén
El tercer sprint se muestra en la tabla 2.14:
Historias de usuario Puntos de historia
SS-4.2 20
SS-4.3 10
SS-4.4 10 Tabla 2.14 - Sprint 3
Al final de la tercera semana de trabajo, una vez que se tenía el conocimiento
suficiente sobre la plataforma y la aplicación que se iba a crear, se añadieron nuevas
historias de usuario en el backlog.
El backlog para el comienzo del cuarto sprint quedó como se puede apreciar en
la tabla 2.15:
ID Historias de usuario Puntos
SS5 Crear funcionalidad de inicio de sesión con Twitter 40
SS5.1 - Implementar la funcionalidad de inicio de sesión en el
servidor
15
SS5.2 - Diseño de una interfaz básica en la aplicación para
poder hacer inicio y cierre de sesión 10
SS5.3 - Implementar la funcionalidad de inicio y cierre de
sesión en la aplicación cliente
15
SS6 Añadir funcionalidad para compartir una oferta 40
SS6.1 - Implementación de la funcionalidad de añadir una
oferta en el servidor 10
SS6.2 - Diseño de una interfaz básica en la aplicación para
compartir una oferta
10
SS6.3 - Implementación de la funcionalidad de añadir una
oferta en la aplicación cliente 20
Juan Cazalla Estrella Agregador de ventas online
29 Escuela Politécnica Superior de Jaén
ID Historias de usuario Puntos
SS7 Añadir la pantalla con la lista ordenada de las mejores ofertas 50
SS7.1 - Implementar la funcionalidad que devuelva la lista de
ofertas ordenada por valoración en el servidor
10
SS7.2 - Diseño de la interfaz para la lista de ofertas. 20
SS7.3 - Implementar la funcionalidad que muestra la lista de
ofertas en la aplicación cliente
20
SS8 Añadir vista de detalle de una oferta 30
SS8.1 - Diseñar vista de detalle de una oferta 20
SS8.2 - Implementar la vista de detalle 10
SS9 Añadir la posibilidad de marcar una oferta como favorita 30
SS9.1 - Implementación de la funcionalidad en el servidor 15
SS9.2 - Diseño del botón de favoritos 5
SS9.3 - Implementar funcionalidad en el cliente 10
SS10 Añadir la lista de las ofertas compartidas por un usuario 15
SS10.1 - Implementación de la funcionalidad en el servidor 5
SS10.2 - Implementar funcionalidad en el cliente 10
SS11 Añadir la lista de las ofertas favoritas de un usuario 20
SS11.1 - Implementación de la funcionalidad en el servidor 10
SS11.2 - Implementar funcionalidad en el cliente 10
SS12 Añadir la opción de ir a la tienda desde el detalle de la oferta 5
SS12.1 - Implementar funcionalidad en el cliente para abrir la
tienda en el navegador
5
Tabla 2.15 - Backlog 2
Juan Cazalla Estrella Agregador de ventas online
30 Escuela Politécnica Superior de Jaén
Con este backlog, los siguientes sprints quedaron de la siguiente manera:
Historias de usuario Puntos de historia
SS5 40 Tabla 2.16 - Sprint 4
Historias de usuario Puntos de historia
SS6 40 Tabla 2.17 - Sprint 5
Al acabar estos sprint se detectó que, con la mejora del conocimiento en las
tecnologías usadas, la cadencia de trabajo mejoró. En los siguientes sprints se
incluyeron 50 puntos de historia en cada uno.
Historias de usuario Puntos de historia
SS7 50 Tabla 2.18 - Sprint 6
Historias de usuario Puntos de historia
SS8 30
SS10 15
SS12 5 Tabla 2.19 - Sprint 7
Historias de usuario Puntos de historia
SS9 30
SS11 20 Tabla 2.20 - Sprint 8
Juan Cazalla Estrella Agregador de ventas online
31 Escuela Politécnica Superior de Jaén
Una vez acabado el sprint 8, el prototipo ya era completamente funcional y
tenía todas las utilidades deseadas, sin embargo había que mejorar en algunos
puntos la interfaz de usuario, por lo que se añadió al backlog una serie de tareas
para solventar este aspecto:
ID Historias de usuario Puntos
SS13 Mejorar la interfaz de la aplicación 20
SS13.1 - Mejorar interfaz de perfil del usuario 10
SS13.2 - Mejorar la interfaz de crear producto 10
SS14 Mejorar la fiabilidad de la aplicación 30
SS14.1 - Testear la aplicación a fondo 10
SS14.2 - Corregir los problemas encontrados 20 Tabla 2.21 - Backlog 3
Con este backlog (tabla 2.21) el noveno y último sprint quedó como refleja la
tabla 2.22:
Historias de usuario Puntos de historia
SS13 20
SS14 30 Tabla 2.22 - Sprint 9
En total, el desarrollo de la aplicación se ha distribuido en 9 sprints de una
semana para un total de 400 puntos de historia.
400 / 9 = 44’44 puntos de historia de media por cada sprint.
Durante cada semana, el tiempo dedicado ha sido de 30 horas haciendo un
total de:
30 x 9 = 270 horas de desarrollo de la aplicación.
Juan Cazalla Estrella Agregador de ventas online
32 Escuela Politécnica Superior de Jaén
2.6. Estudio de viabilidad
A continuación, se realiza la estimación de costes para el desarrollo del
prototipo de aplicación que se ha desarrollado. Para ello, se ha considerado que el
tamaño del equipo ha sido de una persona, aunque se ha tenido en cuenta la
diferencia del coste entre las distintas funciones realizadas. Por otra parte, se ha
considerado adecuado excluir de la estimación de costes la redacción de esta
memoria, pues en caso de que se llevase a cabo no sería un requisito.
2.6.1. Gastos de hardware
Los dispositivos hardware que se han necesitado para el desarrollo han sido un
ordenador con sistema operativo OS X Yosemite (requisito para el desarrollo en la
plataforma iOS) y un iPhone para las pruebas debido a que no se podía probar en el
simulador del sistema operativo por la necesidad de integración con redes sociales.
Para el cálculo de los gastos he tenido en cuenta el precio amortizado durante los
dos meses de desarrollo necesarios.
Recurso Precio Años de utilidad Precio mes Coste total (2 meses)
Portátil – MacBook Pro 1.229€ 5 18,82€ 37,64€ iPhone 6 699€ 3 19,42€ 38,84€ Total - - 38,24€ 106,48€ Tabla 2.23 - Gastos de Hardware
2.6.2. Gastos de licencias de software
Las licencias de software usadas han sido las que se presentan en la tabla
2.24:
Licencia Precio OS X Yosemite Gratuito Xcode Gratuito Gitlab UJAÉN Gratuito Frameworks y librerías usadas en el desarrollo Gratuito iOS Gratuito Total 0€
Tabla 2.24 - Gastos de Software
Juan Cazalla Estrella Agregador de ventas online
33 Escuela Politécnica Superior de Jaén
2.6.3. Servicios externos
Los gastos en servicios externos han sido:
Servicio Precio mes Coste total (2 meses)
Fabric - Crashlytics Gratuito 0€ Parse 0€ 0€ ADSL Movistar 41€ 82€ Endesa – Luz (estimado) 20€ 40€ Total 61€ 122€
Tabla 2.25 - Gastos Externos
Se ha indicado que el precio del servicio externo Parse al mes ha sido de 0€
porque con el plan gratuito es suficiente. Este plan incluye 30 peticiones por
segundo al servicio web, 20GB de almacenamiento en disco, 20GB de
almacenamiento en base de datos y 2TB de tráfico al mes.
2.6.4. Gastos de personal
Para estimar esta sección se ha tomado como referencia la tabla salarial del
convenio colectivo de Telefónica publicado en el BOE[20].
Categoría Tiempo Sueldo Coste Analista ½ mes 2.327,19€ 1.163,59€ Programador Senior ½ mes 2.166,79€ 1.083,39€ Programador Junior 1 mes 1.943,28€ 1.943,28€ Total - - 4.190,26€ Tabla 2.26 - Gastos de Personal
2.6.5. Gastos totales y de viabilidad
El total de gastos del desarrollo del prototipo se indica en la tabla 2.27:
Categoría Coste Gastos de hardware 106,48€ Gastos de licencias de software 0€ Gastos de servicios externos 122€ Gastos de personal 4.190,26€ Total 4.418,74€
Tabla 2.27 - Gastos Totales
Juan Cazalla Estrella Agregador de ventas online
34 Escuela Politécnica Superior de Jaén
Este proyecto no está destinado a ninguna entidad pública sino que en caso de
que se llevase a cabo sería por parte de una empresa.
Puestos a analizar la viabilidad de este proyecto, hay que dejar claro que no
tendría sentido sin implementar el cliente en versión web y Android, por lo que los
costes del desarrollo se podrían multiplicar por 3 o 4 fácilmente. El interés que se
busca con este proyecto es mostrar la idea y ofrecer la posibilidad de hacer la
estimación real del desarrollo del producto basándose en el coste para la plataforma
iOS.
Llegado el caso, sería la empresa que se disponga a desarrollar el proyecto la
que debería analizar la viabilidad atendiendo a los planes de rentabilidad planeados.
En mi opinión, la viabilidad del proyecto depende de una estrategia que permita
conseguir una base grande de usuarios. Una vez conseguido esto, debería ser fácil
rentabilizar la aplicación por medio de distintas técnicas como añadir publicidad de
ofertas en las primeras posiciones del ranking o personalizar los enlaces de Amazon
con una cuenta de afiliados para ganar un porcentaje de las compras que se hacen
a través de la aplicación. Para más información de esto último revisar el recurso [21].
Juan Cazalla Estrella Agregador de ventas online
35 Escuela Politécnica Superior de Jaén
3. DISEÑO DEL SISTEMA
3.1. Introducción
Como se introducía en el final del primer capitulo, en esta parte se va a intentar
dar una visión sobre la aplicación que nos ocupa en este proyecto, analizando para
ello el esquema de la base de datos que vamos a necesitar.
Para el diseño del sistema se pueden utilizar infinidad de técnicas de ingeniería
del software, sin embargo, en nuestro caso, las que pueden ofrecer una mejor visión
de la aplicación son las siguientes:
- Diseño de la base de datos
o Modelo Entidad/Relación
o Entidades finales
- Diseño de la aplicación
o Diagrama de flujo
o Storyboard
Si bien es cierto que los diagramas de flujo no son propiamente técnicas de
diseño, junto a un storyboard pueden proporcionar al lector una idea muy clara sobre
el diseño de la aplicación.
Juan Cazalla Estrella Agregador de ventas online
36 Escuela Politécnica Superior de Jaén
3.2. Diseño de la base de datos
3.2.1. Modelo Entidad/Relación
Un modelo entidad-relación[27] es una herramienta para el modelado de datos
que permite representar las entidades relevantes de un sistema de información así
como sus interrelaciones y propiedades.
En la aplicación que estamos desarrollando, el modelo entidad-relación
resultante es bastante sencillo, con tan solo dos entidades, Advertisement y User.
En la ilustración 3.1 se muestra con más detalle.
Ilustración 3.1 - Modelo entidad-relación
En este diagrama se realizan las siguientes relaciones:
- Usuario
o Puede compartir distintas ofertas
o Puede añadir a favoritos distintas ofertas
- Oferta
o Puede ser favorita de muchos usuarios
o Es compartida por un usuario
Juan Cazalla Estrella Agregador de ventas online
37 Escuela Politécnica Superior de Jaén
3.2.2. Bases de datos actuales
En la actualidad existen dos tipos de bases de datos, relacionales y no
relacionales (SQL y NoSQL). SQL fue creado en la década de 1970 para dar a las
bases de datos relacionales una manera de almacenar datos y comunicarse. En la
actualidad, es la opción de almacenamiento más utilizada en proyectos software.
NoSQL, en contraste, se refiere a un nuevo tipo de bases de datos no relacionales
que no utilizan el lenguaje de consulta SQL.
A grandes rasgos, la principal ventaja de las bases de datos NoSQL sobre las
bases de datos SQL es una mayor velocidad en las consultas a medida que la
cantidad de datos crece. Además, las operaciones de inserción son mucho más
rápidas como se puede apreciar en las ilustraciones 3.2 y 3.3.
Ilustración 3.2 - Escalabilidad NoSQL vs SQL
Juan Cazalla Estrella Agregador de ventas online
38 Escuela Politécnica Superior de Jaén
Ilustración 3.3 - Tiempo de inserción NoSQL vs SQL
Sin embargo, también tienen inconvenientes.
- NoSQL no asegura atomicidad en las operaciones por lo que no es
recomendable su uso si necesitamos esta característica.
- En las bases de datos no relacionales no se asegura la consistencia y
es el desarrollador el que se tiene que asegurar de mantener la
integridad.
- Si el problema que se resuelve tiene un enfoque con datos muy
relacionados entre sí y se necesitan muchas consultas con joins de
tablas, las consultas en las bases de datos no relacionales podrían ser
complejas e ineficientes.
Para ampliar información sobre los distintos tipos de base de datos se pueden
revisar los siguientes enlaces interesantes [23] [24] [25] [26].
Juan Cazalla Estrella Agregador de ventas online
39 Escuela Politécnica Superior de Jaén
3.2.3. Estudio de la base de datos a usar
En nuestro caso, el proyecto que estamos desarrollando no necesita relaciones
complejas entre datos y tampoco atomicidad. En cuanto a la consistencia, sería muy
fácil de mantener en nuestro caso. Teniendo esto en cuenta, es factible el uso de
una base de datos NoSQL para el almacenamiento en el sistema.
¿Pero hay motivos para no usar una base de datos relacional?
En realidad sí hay un motivo que justifica que nuestra elección sea una base de
datos NoSQL. Si echamos un vistazo a los caso de uso de la aplicación,
constantemente nos vemos obligados a consultar cuáles son los anuncios marcados
como favoritos por un usuario de forma rápida:
- Por una parte, al entrar en los detalles de una oferta compartida,
debemos saber si el usuario ya la ha marcado como favorita.
- Por otra parte, tenemos un caso de uso que consiste en mostrar los
anuncios favoritos de un usuario.
Además, también se nos presenta el caso contrario, para una oferta tenemos
que saber quién la ha marcado como favorita para poder hacer el recuento de
favoritos de cada anuncio y mostrarlos ordenados atendiendo a esto.
En el caso de que usáramos una base de datos relacional, tendríamos una
tabla Favoritos que crecería con gran rapidez y en la que una de las consultas se
vería seriamente afectada al tener que recorrer la tabla completa. Pongamos el
ejemplo de ambos casos:
- Imaginemos que almacenamos para cada usuario cuáles son las ofertas
que ha marcado como favoritas. Para el caso de uso de consultar cuáles
son las ofertas favoritas de un usuario la consulta sería rápida, pero,
¿qué ocurriría si queremos saber los usuarios que han marcado una
oferta como favorita?. En ese caso tendríamos que recorrer todos los
usuarios para saber si tienen en favoritos dicha oferta.
- Pensemos ahora en el caso contrario, almacenamos para cada oferta
quiénes son los usuarios que la han marcado como favorita, ¿qué
Juan Cazalla Estrella Agregador de ventas online
40 Escuela Politécnica Superior de Jaén
pasaría con la consulta de las ofertas favoritas de un usuario?. En este
caso tendríamos que recorrer la tabla de ofertas completa para saber si
ese usuario la ha marcado como favorita.
Para resolver esta situación se ha optado por usar una base de datos NoSQL,
ya que ninguna de sus desventajas nos afectan y podremos optimizar la solución
para tener todas las consultas en un tiempo óptimo. A continuación se expone el
diseño que se ha planteado.
3.2.4. Entidades en base de datos NoSQL
Para el almacenamiento de datos del sistema planteado y la optimización de
las consultas de ofertas favoritas, las entidades de la base de datos han quedado
compuestas como se refleja en la tabla 3.1:
Usuario
Atributo Tipo
Id String
Username String
authData String
twitterAlias String
imageUrl String
backgroundImageUrl String
favouriteAdvertisements Array<String> Tabla 3.1 - Entidad Usuario
En favouriteAdvertisements hemos almacenado un array con las id de las
ofertas marcadas como favoritos. Se podría haber guardado directamente un array
con todos las ofertas favoritas para tener aún mayor velocidad en la consulta a
cambio de mayor duplicación de los datos. En este punto se ha considerado que no
es necesario llegar a ese extremo.
Juan Cazalla Estrella Agregador de ventas online
41 Escuela Politécnica Superior de Jaén
De igual forma, podríamos haber guardado un array con las id de las ofertas
compartidas por el usuario, pero en este caso no se ha considerado que sea una
consulta crítica en cuanto a velocidad, pues no se realizará tan a menudo.
En la entidad Oferta, como se puede ver en la tabla 3.2, además de almacenar
la id del usuario que ha compartido la oferta en el campo author, se ha duplicado
información almacenando un array de las id de los usuarios que han marcado la
oferta como favorita. Gracias a esto, conseguimos que la consulta de la cantidad de
favoritos de una oferta también sea óptima dado que sólo comprueba la longitud de
dicho array.
Oferta
Atributo Tipo
Id String
name String
description String
shop String
price Number
imageUrl String
advertisementUrl String
author String
favouritedByUsers Array<String> Tabla 3.2 - Entidad oferta
Juan Cazalla Estrella Agregador de ventas online
42 Escuela Politécnica Superior de Jaén
3.3. Diseño de la interfaz
Para obtener una aproximación más tangible de las funcionalidades de la
aplicación hemos utilizado wireframes[22] en los que mostramos la estructura básica
de cada pantalla de la aplicación.
Por su parte, hemos usado un storyboard para mostrar la secuencia de
pantallas que se muestran en respuesta a la interacción de los usuarios de la
aplicación, de forma que sirva de guía para entender el funcionamiento de ésta
antes de realizar el desarrollo.
A continuación, se muestra cómo se ha realizado el diseño de la aplicación
para facilitar el uso y la navegación por la misma. El análisis está basado en los
distintos casos de uso de la aplicación.
3.3.1. Registro e inicio de sesión
En el caso del registro e inicio de sesión, el flujo por la aplicación es
exactamente el mismo, por lo tanto he unificado ambos casos de uso en el mismo
diagrama de flujo y storyboard.
Juan Cazalla Estrella Agregador de ventas online
43 Escuela Politécnica Superior de Jaén
Diagrama de flujo
Ilustración 3.4 - Diagrama de flujo de registro e inicio de sesión
Juan Cazalla Estrella Agregador de ventas online
44 Escuela Politécnica Superior de Jaén
Storyboard
Ilustración 3.5 - Storyboard de registro e inicio de sesión
Juan Cazalla Estrella Agregador de ventas online
45 Escuela Politécnica Superior de Jaén
3.3.2. Cerrar sesión
Diagrama de flujo
Ilustración 3.6 - Diagrama de flujo de cierre de sesión
Juan Cazalla Estrella Agregador de ventas online
46 Escuela Politécnica Superior de Jaén
Storyboard
Ilustración 3.7 - Storyboard de cierre de sesión
Juan Cazalla Estrella Agregador de ventas online
47 Escuela Politécnica Superior de Jaén
3.3.3. Compartir oferta
Diagrama de flujo
Ilustración 3.8 - Diagrama de flujo de compartir oferta
Juan Cazalla Estrella Agregador de ventas online
48 Escuela Politécnica Superior de Jaén
Storyboard
Ilustración 3.9 - Storyboard de compartir oferta
Juan Cazalla Estrella Agregador de ventas online
49 Escuela Politécnica Superior de Jaén
3.3.4. Detalle de una oferta
Diagrama de flujo
Ilustración 3.10 - Diagrama de flujo de detalle de una oferta
Storyboard
Ilustración 3.11 - Storyboard de detalle de una oferta
Juan Cazalla Estrella Agregador de ventas online
50 Escuela Politécnica Superior de Jaén
3.3.5. Marcar oferta como favorita
Diagrama de flujo
Ilustración 3.12 - Diagrama de flujo de marcar una oferta como favorita
Storyboard
Ilustración 3.13 - Storyboard de marcar una oferta como favorita
Juan Cazalla Estrella Agregador de ventas online
51 Escuela Politécnica Superior de Jaén
3.3.6. Abrir tienda de oferta
Diagrama de flujo
Ilustración 3.14 - Diagrama de flujo de abrir tienda de oferta
Storyboard
Ilustración 3.15 - Storyboard de abrir tienda de oferta
Juan Cazalla Estrella Agregador de ventas online
52 Escuela Politécnica Superior de Jaén
3.3.7. Ofertas compartidas por el usuario
Diagrama de flujo
Ilustración 3.16 - Diagrama de flujo de ofertas compartidas por el usuario
Storyboard
Ilustración 3.17 - Storyboard de ofertas compartidas por el usuario
Juan Cazalla Estrella Agregador de ventas online
53 Escuela Politécnica Superior de Jaén
3.3.8. Ofertas favoritas del usuario
Diagrama de flujo
Ilustración 3.18 - Diagrama de flujo de ofertas favoritas del usuario
Storyboard
Ilustración 3.19 - Storyboard de ofertas favoritas del usuario
Juan Cazalla Estrella Agregador de ventas online
54 Escuela Politécnica Superior de Jaén
Juan Cazalla Estrella Agregador de ventas online
55 Escuela Politécnica Superior de Jaén
4. IMPLEMENTACIÓN
Como se mencionó en la definición de los objetivos de este proyecto, la calidad
del software es clave para que una buena idea se convierta en un buen producto. En
las siguientes líneas de este apartado se explicará cómo se han afrontado estos
objetivos a la hora de desarrollar la aplicación. Para ello, se hará un estudio de las
tecnologías utilizadas justificando la elección de cada una y se explicará la
arquitectura completa de la solución planteada y algunos detalles de la
implementación que pueden ser relevantes.
4.1. Selección de tecnologías
En primer lugar, analicemos las principales tecnologías y librerías que se han
elegido para el desarrollo.
4.1.1. Aplicación cliente
4.1.1.1. iOS
iOS[9] es un sistema operativo móvil desarrollado por Apple lanzado junto al
primer iPhone de la compañía en el año 2007. Está formado por 4 capas de
abstracción:
- Core OS
- Core Service
- Media
- Cocoa Touch, que es la capa en la que trabajaremos casi todo el tiempo
al desarrollar la aplicación.
Juan Cazalla Estrella Agregador de ventas online
56 Escuela Politécnica Superior de Jaén
Ilustración 4.1 - Capas del sistema operativo iOS
El desarrollo de esta aplicación está basado en la versión 8 del sistema
operativo que actualmente es la más reciente. Al diferencia de Android, donde hay
una gran fragmentación en el porcentaje de usuarios en cada versión del sistema
operativo, más del 90% de usuarios de iPhone ya usan iOS 8. Teniendo esto en
cuenta solo he dado soporte a iOS 8 o versiones posteriores.
4.1.1.2. Entornos de programación
Existen dos entornos de programación (en adelante IDE) para desarrollar
aplicaciones nativas en el sistema operativo iOS, Xcode[14] y AppCode[13].
Xcode es el IDE oficial para el desarrollo de aplicaciones iOS. Una de sus
principales características, sin duda, es la incorporación de una herramienta gráfica
para la creación de interfaces de usuario llamada Interface Builder. Gracias a esta
herramienta el diseño de la interfaz de usuario se puede diseñar de forma totalmente
independiente a la implementación de las funcionalidades, facilitando en gran
medida el diseño y la modificación de esta.
Juan Cazalla Estrella Agregador de ventas online
57 Escuela Politécnica Superior de Jaén
Xcode puede compilar código para:
- C
- C++
- Objective C
- Objective C++
- Swift
- Java
- AppleScript
En cuanto a Appcode, es un IDE creado por la empresa JetBrains y
especializado para el desarrollo de aplicaciones iOS. Al igual que todos los IDE
creados por JetBrains, las principales características de AppCode son:
- Mecanismos avanzados de análisis de código.
- Editor con IntelliSense, la aplicación de autocompletado creada por
Microsoft para el IDE Visual Studio.
- Potentes refactorizaciones.
- Importación automática de librerías.
- Navegación con un solo clic.
- Formateo de código automático.
Durante el desarrollo de la aplicación se ha hecho uso de ambos IDE,
aprovechando las principales características de cada uno. Así, he usado Xcode para
el diseño de las interfaces de usuario y AppCode para escribir el código fuente.
4.1.1.3. Fabric Crashlytics
Fabric[12] es un SDK (kit de desarrollo de software) desarrollado por Twitter y
formado por Crashlytics[36], Digits[37] y Mopub[38]. Durante el desarrollo de la
aplicación se ha hecho uso de Crashlytics.
Crashlytics es una herramienta de reporte automático de crashes (errores
críticos que rompen la ejecución). Con soporte para Android e iOS, entre sus
principales características se encuentran:
Juan Cazalla Estrella Agregador de ventas online
58 Escuela Politécnica Superior de Jaén
- Reporte del log de crashes con información de la línea en la que ha ocurrido
la excepción y el estado de los distintos hilos que había en ejecución en ese
momento.
- Estadísticas y porcentajes de la cantidad de usuarios a la que afecta cada
bug en la aplicación en cada versión.
- Características de los terminales en los que se ha presentado el fallo,
memoria RAM libre, versión del sistema operativo, modelo del dispositivo y
orientación de la pantalla entre otras.
Además, posee una herramienta de reporte de estadísticas de uso de la
aplicación automática. Las principales estadísticas son la cantidad de nuevas
instalaciones, la cantidad de usuarios nuevos e incluso el tiempo de uso y las veces
que ejecutan la aplicación cada día.
4.1.1.4. CocoaPods
CocoaPods[11] es un gestor de dependencias para proyectos iOS. Esta
herramienta, viene integrada en AppCode y otorga una gran facilidad a la hora de
importar librerías de terceros. Actualmente es el gestor de dependencias más
extendido en el desarrollo para el sistema operativo iOS y OSX.
4.1.1.5. TyphoonFramework
Como se especificó anteriormente, uno de los objetivos de este proyecto era
aplicar los principios de SOLID[15]. Uno de ellos es el principio inversión de control,
que defiende dos conceptos:
- Las clases de alto nivel no deben de depender de las de bajo nivel.
- Las abstracciones no deberían depender de los detalles, los detalles
deberían depender de las abstracciones.
Una solución planteada por Martin Fowler[35] es la inyección de dependencias
que es un patrón de diseño orientado a objetos, en el que se suministran objetos a
una clase en lugar de ser la propia clase quien cree el objeto. Esta tarea puede ser
hecha sin necesidad de ninguna herramienta, sin embargo se ha utilizado
TyphoonFramework[8], un inyector de dependencias para Objective C y Swift que
simplifica el trabajo en gran medida.
Juan Cazalla Estrella Agregador de ventas online
59 Escuela Politécnica Superior de Jaén
4.1.1.6. ReactiveCocoa
ReactiveCocoa[6][7] es un framework para Swift y Objective C que ofrece la
posibilidad de utilizar programación reactiva en el desarrollo para la plataforma iOS.
La programación reactiva es un paradigma de programación orientado alrededor de
dos conceptos, dataflow[39] y la propagación de cambios. Durante el desarrollo de
esta aplicación se ha usado este paradigma en algunos casos de uso y como motor
de data binding[34] para el patrón MVVM.
4.1.2. Servidor
4.1.2.1. Parse
Parse[10] es una herramienta perteneciente a Facebook con la que desarrollar
un backend para servicios rápidamente. Además de esto, posee utilidades como el
envío de notificaciones push a todas las plataformas móviles y la recopilación de
analíticas. Una de sus ventajas es que tiene soporte para dispositivos móviles,
aplicaciones de escritorio, aplicaciones web, dispositivos embebidos y dispositivos
IoT.
Se ha considerado que era el complemento perfecto para este proyecto por la
gran facilidad y rapidez con la que se puede desarrollar una API REST sin necesitar
escribir código.
El funcionamiento de Parse se basa en una base de datos online NoSQL con
soporte para las funciones CRUD mediante el SDK de Parse de forma muy simple.
Para los casos en los que se necesite realizar un procesado de datos permite
integrar código JavaScript. Además, ofrece funciones específicas para iniciar sesión
e integrar Twitter y Facebook.
Juan Cazalla Estrella Agregador de ventas online
60 Escuela Politécnica Superior de Jaén
4.2. Arquitectura del sistema
El sistema desarrollado está basado en una arquitectura cliente/servidor. En
este proyecto tan solo se ha desarrollado un cliente basado en el sistema operativo
iOS. En la siguiente imagen se puede apreciar un esquema más detallado de la
arquitectura:
Ilustración 4.2 - Arquitectura del Sistema
Juan Cazalla Estrella Agregador de ventas online
61 Escuela Politécnica Superior de Jaén
Como se puede apreciar, el funcionamiento de la aplicación está apoyado en
un servidor en Parse donde está alojada la base de datos centralizada. En el
presente caso, el papel del servidor ha sido el de base de datos NoSQL online,
utilidad que el servicio Parse provee sin necesidad de realizar ninguna
implementación. En caso de que se necesite ampliar la funcionalidad se podría
modificar el procesamiento de las peticiones REST.
Si se deseara desarrollar nuevas aplicaciones clientes, como podrían ser una
aplicación web o una aplicación Android, no sería necesario implementar nada
nuevo en la parte del servidor.
Para comprender mejor cómo está compuesta la arquitectura veamos cuál
sería el flujo que se generaría por la arquitectura desde que el usuario realiza una
acción hasta que recibe una respuesta. Para esto, me basaré en el caso de uso
“consultar los anuncios favoritos de un usuario”. ¿Qué sucede desde que el usuario
hace clic para consultar sus anuncios favoritos?. El siguiente diagrama de flujo
representa los pasos que se darían por la aplicación:
Juan Cazalla Estrella Agregador de ventas online
62 Escuela Politécnica Superior de Jaén
Ilustración 4.3 - Diagrama de flujo de un caso de uso
Juan Cazalla Estrella Agregador de ventas online
63 Escuela Politécnica Superior de Jaén
Una vez presentada la arquitectura, en los siguientes apartados se desarrollará
en más profundidad cómo se ha realizado la implementación del sistema. Como he
comentado anteriormente, no se ha necesitado realizar ninguna implementación en
el servidor puesto que el servicio de Parse era capaz de resolver todas nuestras
consultas, por lo tanto, me centraré tan solo en la aplicación cliente.
4.2.1. Arquitectura de la aplicación cliente para iOS
Como se comentó en el primer apartado de esta memoria, entre los objetivos
técnicos a la hora de afrontar el proyecto estaban aplicar los principios de SOLID,
encontrar una arquitectura adecuada para el desarrollo de aplicaciones para
dispositivos móviles y estudiar si un enfoque basado en la programación reactiva
puede ser interesante para trabajar con ejecuciones asíncronas.
La investigación y estudio necesaria para conseguir estos objetivos, está
basada principalmente en las referencias [1] [2] [3] [4] [5] y [6]. Especialmente, se ha
tenido en cuenta la definición de Clean Architecture[5] de Uncle Bob. De esta forma,
se ha dividido la aplicación en 3 capas principales:
- Capa de presentación
- Capa de dominio
- Capa de datos
Con esta división en capas se consiguen distintos beneficios:
- La capa de dominio de la aplicación, que es la que se encarga de ejecutar
la lógica de todos los casos de uso, es independiente completamente del
framework del sistema operativo. En esta capa no debe usarse nada que
sea específico del sistema operativo. Gracias a esto, se consigue que toda
la lógica de la aplicación pueda ser totalmente reusable en un cliente para
otra plataforma.
- En la capa de dominio, no tienes porque preocuparte de si los datos vienen
de red o de una base de datos del teléfono. Solamente se encargará de
realizar las peticiones a la capa de datos y esta será la que se encargue de
consultar en la fuente necesaria.
Juan Cazalla Estrella Agregador de ventas online
64 Escuela Politécnica Superior de Jaén
- Puesto que la capa de datos es la encargada de trabajar con la API y la
base de datos, en caso de que se necesite cambiar el servidor o la
tecnología (REST o SOAP), esta será la única capa que sufra cambios
minimizando los posibles bugs introducidos.
- La capa de presentación sólo se encarga de capturar las interacciones de
los usuarios y de pintar la interfaz. Gracias a esto, el diseño gráfico de la
aplicación se simplifica en gran medida.
- Cuando surge algún problema, encontrar el fallo suele ser mucho más
simple pues se identifica rápidamente en qué capa se ha producido.
- Puesto que el ámbito de las distintas capas es independiente, distintos
desarrolladores pueden estar trabajando en un mismo caso de uso a la vez.
Esto también propicia que la cantidad de fallos disminuya gracias a que los
desarrolladores están focalizados en una tarea más concreta.
- Se pueden tratar las tareas asíncronas de forma muy simple sin afectar al
rendimiento de la interfaz de usuario. En los sistemas operativos móviles,
todo el trabajo realizado en la interfaz de usuario se ejecuta en el hilo
principal. Gracias a esta arquitectura, todas las tareas que no pertenezcan
a la capa de presentación pueden ejecutarse en hilos distintos para
conseguir la máxima fluidez en los teléfonos menos potentes.
- A la hora de realizar modificaciones en trabajos anteriores, es muy fácil
encontrar el código que debe modificarse puesto que todas las funciones
están completamente identificadas y separadas.
- Realizar cambios en la interfaz es muy rápido, y se pueden hacer pruebas
A/B con distintas interfaces de forma muy simple gracias a la inyección de
dependencias.
- Al estar todas las funcionalidades completamente separadas, es muy fácil
implementar test unitarios de la lógica de la aplicación.
Juan Cazalla Estrella Agregador de ventas online
65 Escuela Politécnica Superior de Jaén
En el siguiente gráfico, se puede apreciar como está compuesta la arquitectura
de la aplicación iOS.
Ilustración 4.4 - Arquitectura de la aplicación iOS
Si se desea ampliar información o continuar el estudio de este tema, aunque no
se ha usado como base para realizar el proyecto pues su publicación es posterior al
momento en que lo realicé, recomiendo leer el estudio realizado por Martin Fowler
que se puede encontrar en el enlace [33] de la bibliografía.
4.3. Implementación del sistema
4.3.1. Implementación del servidor en Parse
Como se ha comentado anteriormente, gracias al uso de Parse como servidor
del sistema, hemos ahorrado una gran cantidad de tiempo en la implementación del
servidor. Para la integración de Parse tan sólo son necesarios los siguientes pasos:
- Crear un nuevo proyecto en Parse como se aprecia en la ilustración 4.5:
Ilustración 4.5 - Crear proyecto en Parse
Juan Cazalla Estrella Agregador de ventas online
66 Escuela Politécnica Superior de Jaén
- Copiar las claves de acceso al servidor de Parse para posteriormente
configurar el SDK. En la ilustración 4.6 se puede apreciar la lista de claves.
Ilustración 4.6 - Claves de aplicación en Parse
- Configurar el SDK de Parse para iOS con las claves de la aplicación como
se aprecia en la ilustración 4.7.
Ilustración 4.7 - Configuración de las claves de Parse en iOS
Juan Cazalla Estrella Agregador de ventas online
67 Escuela Politécnica Superior de Jaén
- Por último, será necesario crear las tablas en Parse añadiendo los distintos
campos indicados en el diseño de la base de datos tal y como se aprecia en
la ilustración 4.8.
Ilustración 4.8 - Añadir tablas en Parse
Una vez realizados los pasos anteriores, se podrán ejecutar las distintas
operaciones CRUD por medio del SDK de Parse para iOS y el proyecto funcionará
correctamente.
4.3.2. Implementación de aplicación cliente en iOS
Una vez que ya se conoce como es la arquitectura de la aplicación cliente,
entraremos un poco más en detalle en la implementación de cada capa. Además, se
explicará cómo se consigue mediante inyección de dependencias y programación
orientada a interfaces (o protocolos en Objective C) que la capa de dominio sea
completamente independiente de las demás y no presente ninguna dependencia
externa.
4.3.2.1. Capa de presentación
La capa de presentación es la encargada de lidiar con el framework de iOS.
Tiene solamente dos funciones, pintar en pantalla los distintos elementos de la
interfaz y capturar las interacciones de los usuarios. Es importante que en esta capa
Juan Cazalla Estrella Agregador de ventas online
68 Escuela Politécnica Superior de Jaén
solamente se realicen funciones de este tipo si queremos escribir un código limpio y
muy fácil de entender y mantener.
Es muy común cuando se empieza a desarrollar para un framework que todo
nuestro sistema quede completamente acoplado a éste. Esto provoca que un simple
cambio en la API del framework pueda obligarnos a realizar cambios en numerosas
partes de nuestra aplicación que en realidad no tienen nada que ver.
En el caso concreto de este proyecto, esta capa se ha implementado utilizando
el patrón arquitectónico Model-View-ViewModel[28]. Este patrón, desarrollado por
Microsoft pero basado en Presentation Model design pattern[29] propuesto por Martin
Fowler, es un patrón de diseño de aplicaciones para desacoplar código de interfaz
de usuario del resto de la aplicación.
En la propuesta realizada por Microsoft, el ViewModel es el encargado de toda
la lógica que no tiene que ver con la interfaz de usuario, sin embargo, durante el
desarrollo de este proyecto se ha considerado que no es una solución lo
suficientemente buena para el diseño de aplicaciones mantenibles por el hecho de
agrupar demasiada lógica en un mismo sitio incumpliendo el principio de
responsabilidad única que se defiende en los principios SOLID. Puesto que el
framework de iOS no está adaptado para el uso de este patrón, como en secciones
anteriores se comentó, se ha implementado un motor de data binding utilizando
programación reactiva.
Por lo tanto, para el caso que se nos presenta, se ha utilizado una
implementación en la que el ViewModel tan sólo se encarga de orquestar la
comunicación entre la capa de presentación y la capa del dominio de la aplicación.
También es importante organizar esta capa por paquetes que engloben la
funcionalidad de las pantallas. En la ilustración 4.5 se pude apreciar mejor lo que se
ha aplicado:
Juan Cazalla Estrella Agregador de ventas online
69 Escuela Politécnica Superior de Jaén
Ilustración 4.9 - Organización de la capa de presentación
A menudo se suele utilizar una organización de paquetes con Model, View y
ViewModel en la raíz. Durante la implementación de la aplicación se ha considerado
esto como un error debido a que dispersa el código que pertenece a una misma
funcionalidad.
4.3.2.2. Capa de dominio
La capa de dominio se encarga de toda la lógica correspondiente a los casos
de uso de la aplicación. La lógica de cada caso de uso, se ha encapsulado en clases
que denominadas Interactor. Esta capa se encarga además de trabajar con el
repositorio de la capa de datos de la aplicación.
Es importante que en esta capa no se utilice ningún elemento perteneciente al
framework. Lo ideal es que sea código Objective C (o cualquier otro compatible)
para que pueda ser fácilmente reutilizable en la implementación de distintos clientes.
Por ejemplo, se podría compartir el mismo código para clientes Android, iOS, Mac
OS X y Windows 10 en caso de que lo implementemos en lenguaje C, el cual es
soportado por todos estos sistemas operativos.
Una consideración a tener en cuenta es que, de igual forma que la capa de
presentación tiene su propio modelo, cada una de las capas debe poseer un modelo
independiente de las demás. Esto es importante para conseguir que unas capas no
se vean afectadas por los cambios realizados en los modelos de capas distintas.
Juan Cazalla Estrella Agregador de ventas online
70 Escuela Politécnica Superior de Jaén
Debido a esto, entre las distintas capas, se utiliza una clase encargada de
transformar modelos de una capa en otra.
Por último, apuntar que para no tener dependencia de la capa de datos, esta
capa es la encargada de definir la interfaz que debe tener el repositorio necesario
para el funcionamiento de la aplicación. Posteriormente, mediante inyección de
dependencias se le pasará la instancia de una clase que implemente dicha interfaz.
La estructura queda como se puede apreciar en la ilustración 4.6:
Ilustración 4.10 - Organización de la capa de dominio
4.3.2.3. Capa de datos
La última capa es la de datos. Esta capa es la encargada de todo lo
relacionado con el almacenamiento de los datos de la aplicación. Construida bajo un
patrón repositorio[30], se encarga de la lógica necesaria para consultar los datos
solicitados al DataSource[30] de cache o de red.
Por medio de lo que en nuestro caso ha sido denominado CloudDataStore,
esta capa se encarga de lanzar las peticiones al servidor. Para este cometido se
utiliza el SDK proporcionado por Parse, el cual se encarga de realizar la petición y
transformar la respuesta en objetos de la aplicación.
Juan Cazalla Estrella Agregador de ventas online
71 Escuela Politécnica Superior de Jaén
La estructura de esta capa se puede apreciar en la ilustración 4.7:
Ilustración 4.11 - Organización de la capa de datos
4.3.2.4. Inyección de dependencias con TyphoonFramework
Como ya se apuntó anteriormente, se ha utilizado el framework Typhoon para
facilitar la tarea de inyectar dependencias. Gracias a esta técnica, la creación de
objetos con los que colabora una clase no es responsabilidad suya. En la
implementación, todas las dependencias de una clase han sido pasadas por el
constructor del objeto. Esta técnica, denominada inversión de control y especificada
en los principios de SOLID, es esencial si queremos conseguir que el código pueda
ser testeado fácilmente utilizando mocks y stubs[32] para simular el comportamiento
de cada colaborador.
Así, por ejemplo para crear el ViewModel de la pantalla de compartir anuncio,
lo haríamos tal y como se indica en la ilustración 4.8:
Ilustración 4.12 - Ejemplo de inyección de dependencias
Juan Cazalla Estrella Agregador de ventas online
72 Escuela Politécnica Superior de Jaén
Para la gestión de la creación de todos los objetos, se ha creado un módulo
aparte denominado Assembly que se encarga de crear las instancias de cada uno
de los objetos utilizando el framework comentado anteriormente. Como se puede
apreciar en la ilustración 4.9, se han creado distintas clases para este cometido:
Ilustración 4.13 - Módulo Assembly
Otro de los beneficios de esta técnica es la capacidad de modificar el
comportamiento de una clase inyectando distintos colaboradores. Esta técnica se
utiliza muy a menudo en los test A/B[40] para cambiar la interfaz de usuario de una
aplicación sin necesidad de instalar una nueva versión y recoger analíticas de cómo
los usuarios usan la aplicación en cada caso.
4.3.2.5. Gestión de las dependencias
Para gestionar las dependencias de librerías del proyecto, como se comentó en
el primer apartado de este capítulo, se ha utilizado CocoaPods, el cual de forma muy
simple, importa las distintas librerías a usar en el proyecto.
Para indicar las librerías que deseas usar, tan solo hay que especificarlo en un
archivo denominado Podfile. En la ilustración 4.10 se pueden ver las dependencias
que se han utilizado en el desarrollo de la aplicación:
Juan Cazalla Estrella Agregador de ventas online
73 Escuela Politécnica Superior de Jaén
Ilustración 4.14 - Podfile con las dependencias
4.4. Pruebas y validación
Como se ha explicado en capítulos anteriores, durante el proceso de desarrollo
se ha tenido en cuenta en todo momento escribir código que sea fácil de testear, sin
embargo, puesto que se trata de un prototipo, no se ha considerado necesario la
ejecución de pruebas de caja negra mediante test unitarios[41] automáticos. En caso
de que se desarrolle el proyecto de forma profesional sería conveniente la
implementación de dichas pruebas para evitar regresión entre distintas versiones.
Para validar la aplicación, se han realizado pruebas manuales de caja blanca
durante las distintas iteraciones del desarrollo para verificar el correcto
funcionamiento de los distintos casos de uso. De esta forma, se ha asegurado el
correcto funcionamiento de:
- Registro
- Inicio de sesión
- Cierre de sesión
- Ver lista de las mejores ofertas
- Compartir oferta
- Ver detalle de oferta
- Marcar una oferta como favorita
- Abrir oferta en el navegador
- Ver lista de ofertas compartidas por cada usuario
- Ver lista de ofertas favoritas de un usuario
Juan Cazalla Estrella Agregador de ventas online
74 Escuela Politécnica Superior de Jaén
Juan Cazalla Estrella Agregador de ventas online
75 Escuela Politécnica Superior de Jaén
5. CONCLUSIÓN
El desarrollo de este proyecto ha sido una gran oportunidad para poner en
práctica los conocimientos y habilidades adquiridas durante los años de estudio. Ha
supuesto un gran reto para mí porque nunca había desarrollado una aplicación de tal
envergadura sin la ayuda de compañeros y me ha servido para afianzar los
conocimientos en todos los campos involucrados en el desarrollo de una aplicación.
Al comenzar el desarrollo de este proyecto me planteé objetivos de dos tipos.
Por una parte, tenía unos objetivos relacionados con la utilidad del proyecto en los
que el fin era crear una aplicación que ayudara a los usuarios a encontrar “chollos”
en tiendas online. Puedo decir que he cumplido a la hora de ejecutar la solución que
propuse pero, ¿realmente la solución propuesta crea un producto en el que los
usuarios podrán encontrar estos chollos prometidos?
La respuesta a la anterior pregunta es clave para saber si he cumplido con el
objetivo, pero realmente, es algo que no puedo contestar sin haber tenido la
aplicación funcionando durante unos meses en el mercado. ¿Por qué no puedo
contestarla?. El funcionamiento de mi solución está ligado a que los usuarios
compartan las ofertas que consideran interesantes, pero no hay nada que me
asegure que lo harán. Puedo confiar en que funcionará atendiendo a los resultados
de Meneame.net pero, por otra parte, no hay ningún beneficio para los usuarios que
comparten una oferta, por lo que es probable que nada les anime.
En cuanto a los objetivos relacionados con la calidad del software desarrollado
considero que se han cumplido todos. En todo momento, he tenido en cuenta crear
código modular que cumpliera los principios SOLID, con gran orientación a objetos y
clases que hacen sólo una cosa para conseguir que sea muy fácil de comprender y
extender para funcionalidades futuras. Respecto al paradigma de programación
reactiva, se ha estudiado cómo se amolda a este tipo de aplicaciones, utilizándolo en
la construcción del motor de data binding del patrón de Mode-View-ViewModel y en
el caso de uso de inicio y cierre de sesión. Todo esto se ha hecho en torno a una
arquitectura de aplicación basada en la arquitectura planteada por Robert C.
Martin[5], la cual considero que es idónea para el desarrollo de aplicaciones móviles
donde es muy fácil, a la vez que desaconsejado, acoplarse en exceso al framework.
Juan Cazalla Estrella Agregador de ventas online
76 Escuela Politécnica Superior de Jaén
A la hora de desarrollar la aplicación, elegí iOS como sistema operativo. Hasta
el momento, tan sólo había trabajado con Android, pero suponía para mí un gran
aliciente aprovechar este proyecto para aprender a desarrollar en un nuevo sistema
operativo y la verdad es que apenas he encontrado dificultad. Quizás las mayores
barreras que se me han presentado son las limitaciones que impone Apple a la hora
de desarrollar en su sistema operativo. He tenido que lidiar para poder ejecutar la
aplicación en un iPhone sin tener que pagar las licencias de desarrollo necesarias
para publicar aplicaciones en el App Store y aún así, no he podido utilizar
notificaciones.
Por último, me gustaría hacer mención a la enseñanza recibida durante mis
estudios de Ingeniería Informática. Si bien es cierto que durante los años de estudio
a veces me sentía frustrado porque me deseaba recibir formación en ciertas
tecnologías, con la realización de esta aplicación he comprobado que lo realmente
importante es la base teórica y práctica que hemos adquirido, que nos da la
capacidad de afrontar trabajos en cualquier tecnología con gran capacidad de
adaptación.
5.1. Áreas de mejora y trabajos futuros
He desarrollado una aplicación que satisface los objetivos iniciales, pero esto
no quiere decir que no sea mejorable. Pese a ser un prototipo, funciona a la
perfección y sin ningún problema, aún así, hay una serie de nuevas funcionalidades
que podrían ser muy interesantes para el producto.
- Añadir la opción de iniciar sesión con Facebook. La idea de usar Twitter
para el inicio de sesión era evitar la barrera de entrada que supondría
para muchos usuarios tener que crear una cuenta para la aplicación.
Facebook está hoy en día muy extendido, y prácticamente cualquier
persona que está acostumbrada a usar internet, y que por lo tanto es
usuario potencial de la aplicación, tiene cuenta en una de estas dos
redes sociales.
- Añadir un sistema capaz de extraer los datos de los productos a partir
del enlace de la tienda original, sin necesidad de tener que indicar el
Juan Cazalla Estrella Agregador de ventas online
77 Escuela Politécnica Superior de Jaén
usuario, la descripción, la URL de la imagen o algo más importante, el
precio, que podría cambiar y quedar desactualizado.
- Otra utilidad que puede ser interesante es compartir los anuncios en
redes sociales, lo cual daría más viralidad a la aplicación en caso de que
llegase a lanzarse comercialmente.
- Actualmente, la gente está acostumbrada a dar su opinión sobre todo lo
que compra por internet. En la aplicación desarrollada se busca el
feedback rápido del usuario para establecer a partir de ahí una lista
ordenada de los mejores chollos. Sería interesante además dar la
opción a que añadieran comentarios en los productos.
- El diseño de la aplicación se ha hecho pensando en mostrar siempre el
mejor “chollo”, sin embargo, una utilidad que podría ser clave es la
opción de crear listas de productos por categorías y poder realizar
búsquedas en estas.
- Otra opción para trabajos futuros es la implementación de la aplicación
tanto para el sistema operativo Android como para Web.
Juan Cazalla Estrella Agregador de ventas online
78 Escuela Politécnica Superior de Jaén
Juan Cazalla Estrella Agregador de ventas online
79 Escuela Politécnica Superior de Jaén
Bibliografía
[1] Robert C. Martin, (2008). Clean Code - A handbook of Agile Software Craftsmanship. Editorial Prentice Hall.
[2] Erich Gamma, Richard Helm, Ralph Johnson and John M. Vlissides (1980). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional.
[3] Joshua Kerievsky (2004). Refactoring to Patterns. Editorial Addison-Wesley Signature.
[4] Eric Freeman, Elisabeth Robson, Bert Bates and Kathy Sierra (2004). Head first Design Patterns. Editorial O'Reilly.
[5] Robert C. Martin, (2012). The Clean Architecture. Blog blog.8thlight.com.
[6] Reactive Programming - https://en.wikipedia.org/wiki/Reactive_programming - Recuperado por última vez en Agosto de 2015
[7] ReactiveCocoa - https://github.com/ReactiveCocoa/ReactiveCocoa - Recuperado por última vez en Julio de 2015
[8] TyphoonFramework - http://typhoonframework.org/ - Recuperado por última vez en Julio de 2015
[9] Sistema Operativo iOS - https://es.wikipedia.org/wiki/IOS - Recuperado por última vez en Agosto de 2015
[10] Parse - https://parse.com/ - Recuperado por última vez en Julio de 2015
[11] CocoaPods - https://cocoapods.org/about - Recuperado por última vez en Julio de 2015
[12] Fabric - https://get.fabric.io/ - Recuperado por última vez en Julio de 2015
[13] AppCode - https://www.jetbrains.com/objc/features/ - Recuperado por última vez en Julio de 2015
[14] Xcode - https://es.wikipedia.org/wiki/Xcode - Recuperado por última vez en Julio de 2015
[15] Principios SOLID - https://es.wikipedia.org/wiki/SOLID_(object-oriented_design) - Recuperado por última vez en Julio de 2015
[16] Desarrollo iterativo y creciente - https://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente - Recuperado por última vez en Julio de 2015
[17] Programación extrema - https://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema - Recuperado por última vez en Julio de 2015
[18] Alfonso Álvarez García, Rafael de las Heras del Dedo y Carmen Lasa Gómez (2012). Métodos Ágiles y Scrum. Editorial Anaya. – Recuperado por última vez en Julio de 2015
Juan Cazalla Estrella Agregador de ventas online
80 Escuela Politécnica Superior de Jaén
[19] Roger Pressman (2002). Ingeniería del Software, un enfoque práctico. Editorial Mc-Graw Hill. – Recuperado por última vez en Agosto de 2015
[20] Convenio Colectivo de Telefónica (2013) - https://www.boe.es/boe/dias/2013/02/26/pdfs/BOE-A-2013-2153.pdf - Recuperado por última vez en Agosto de 2015
[21] Afiliados Amazon - https://afiliados.amazon.es/ - Recuperado por última vez en Agosto de 2015
[22] Wireframe - https://es.wikipedia.org/wiki/Wireframe_(Dise%C3%B1o_web) - Recuperado por última vez en Agosto de 2015
[23] Bases de datos SQL - https://es.wikipedia.org/wiki/SQL - Recuperado por última vez en Julio de 2015
[24] Bases de datos NoSQL - https://es.wikipedia.org/wiki/NoSQL - Recuperado por última vez en Julio de 2015
[25] SQL y NoSQL - https://jaromero95.wordpress.com/2014/11/05/nosql/ - Recuperado por última vez en Julio de 2015
[26] SQL vs NoSQL - http://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-server-2008-performance-showdown/ - Recuperado por última vez en Julio de 2015
[27] Modelo entidad-relación - https://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n - Recuperado por última vez en Agosto de 2015
[28] Model-View-ViewModel - https://msdn.microsoft.com/es-es/library/windows/apps/JJ883732.aspx - Recuperado por última vez en Agosto de 2015
[29] Presentation Model design pattern - http://martinfowler.com/eaaDev/PresentationModel.html - Recuperado por última vez en Agosto de 2015
[30] The Repository Pattern - https://msdn.microsoft.com/en-us/library/ff649690.aspx - Recuperado por última vez en Agosto de 2015
[31] Parse SDK - https://parse.com/docs/ios/guide - Recuperado por última vez en Agosto de 2015
[32] Mocks and Stubs - https://adamcod.es/2014/05/15/test-doubles-mock-vs-stub.html - Recuperado por última vez en Agosto de 2015
[33] PresentationDomainDataLayering - http://martinfowler.com/bliki/PresentationDomainDataLayering.html - Recuperado por última vez en Agosto de 2015
[34] Data binding - https://en.wikipedia.org/wiki/Data_binding - Recuperado por última vez en Agosto de 2015
[35] Dependency inyection - http://www.martinfowler.com/articles/injection.html - Recuperado por última vez en Agosto de 2015
Juan Cazalla Estrella Agregador de ventas online
81 Escuela Politécnica Superior de Jaén
[36] Crashlytics - https://get.fabric.io/crashlytics - Recuperado por última vez en Agosto de 2015
[37] Digits - https://get.fabric.io/digits - Recuperado por última vez en Agosto de 2015
[38] Mopub - https://get.fabric.io/mopub - Recuperado por última vez en Agosto de 2015
[39] Dataflow- https://en.wikipedia.org/wiki/Dataflow - Recuperado por última vez en Agosto de 2015
[40] Test A/B - https://es.wikipedia.org/wiki/Test_A/B - Recuperado por última vez en Agosto de 2015
[41] Pruebas unitarias - https://es.wikipedia.org/wiki/Prueba_unitaria - Recuperado por última vez en Agosto de 2015
Juan Cazalla Estrella Agregador de ventas online
82 Escuela Politécnica Superior de Jaén
Juan Cazalla Estrella Agregador de ventas online
83 Escuela Politécnica Superior de Jaén
ANEXO I
Manual de puesta en marcha del sistema
Juan Cazalla Estrella Agregador de ventas online
84 Escuela Politécnica Superior de Jaén
Los pasos necesarios para la ampliación o puesta en marcha del proyecto son
los siguientes:
1- Instalar Xcode
Para instalar Xcode, lo haremos desde App Store, la tienda de aplicaciones
de Mac OS X. Para ello, en el buscador buscamos Xcode y procedemos a
instalar la aplicación.
Ilustración Anexo I.1 – Instalación Xcode
Juan Cazalla Estrella Agregador de ventas online
85 Escuela Politécnica Superior de Jaén
2- Instalar CocoaPods
Para instalar CocoaPods solo es necesario ejecutar el siguiente comando
en consola:
sudo gem install cocoapods
Una vez acabe, ejecutaremos el comando:
pod setup
Para más información consultar https://guides.cocoapods.org/using/getting-
started.html
3- Integrando CocoaPods en nuestro proyecto
Para instalar las librerías configuradas en el archivo Podfile del proyecto
será necesario ejecutar el siguiente comando de CocoaPods en la carpeta
que lo contiene:
pod install
4- Instalar de Fabric
Para instalar Fabric, hay que seguir la siguiente guía oficial:
https://docs.fabric.io/ios/fabric/getting-started.html
Juan Cazalla Estrella Agregador de ventas online
86 Escuela Politécnica Superior de Jaén
5- Abrir el proyecto con Xcode
Para abrir el proyecto, en Xcode, hacer clic en “Open another project”
Ilustración Anexo I.2 – Abrir proyecto
A continuación, habrá que buscar la carpeta del proyecto en el explorador
de archivos y elegir el archivo SnipShare.xcworkspace.
Juan Cazalla Estrella Agregador de ventas online
87 Escuela Politécnica Superior de Jaén
6- Ejecutar proyecto con Xcode
Una vez se haya abierto el proyecto, podrá ejecutarse simplemente
haciendo clic en el botón playa de la parte superior izquierda de la siguiente
captura:
Ilustración Anexo I.3 – Ejecutar el proyecto.
Juan Cazalla Estrella Agregador de ventas online
88 Escuela Politécnica Superior de Jaén
Juan Cazalla Estrella Agregador de ventas online
89 Escuela Politécnica Superior de Jaén
ANEXO II
Manual de usuario de la aplicación
Juan Cazalla Estrella Agregador de ventas online
90 Escuela Politécnica Superior de Jaén
Registro e inicio de sesión
Para poder empezar a disfrutar de la aplicación lo primero que se debe de
hacer es localizar el icono de la aplicación SnipShare en el menú de nuestro iPhone
y pinchar sobre él.
Ilustración Anexo II.1 – Menú iPhone
Juan Cazalla Estrella Agregador de ventas online
91 Escuela Politécnica Superior de Jaén
Una vez que la aplicación se ha abierto, debemos iniciar sesión con nuestra
cuenta de Twitter, la cual ya debe de estar registrada en nuestro iPhone. Para ello,
en primer lugar debemos de pinchar sobre el botón Logan with Twitter que muestra
la siguiente imagen:
Ilustración Anexo II.2 – Inicio de sesión
Seguidamente debemos de elegir la cuenta de Twitter con la que queremos
indicar sesión para poder disfrutar de todas las características de SnipShare. En las
siguientes imágenes se pude apreciar el proceso.
Juan Cazalla Estrella Agregador de ventas online
92 Escuela Politécnica Superior de Jaén
Ilustración Anexo II.3 – Selección usuario Ilustración Anexo II.4 – Perfil
Cerrar sesión
Una vez iniciada la sesión se abre la pantalla Perfil del usuario, desde la cual
podemos cerrarla pulsando el botón Logo que aparece al final de la pantalla, como
se puede ver en la última imagen del apartado anterior.
Juan Cazalla Estrella Agregador de ventas online
93 Escuela Politécnica Superior de Jaén
Ver lista de las mejores ofertas
En este apartado se concentra el principal fin de esta aplicación, ya que es aquí
donde se muestran todas las ofertas que los usuarios han compartido por
considerarlas interesantes.
Una vez iniciada la sesión, para poder ver las mejores ofertas compartidas por
todos los usuarios debemos pinchar sobre el botón SnipShare, que se encuentra en
la parte inferior izquierda de la pantalla. De esta forma accedemos a la lista de las
mejores ofertas, las cuales están ordenadas de mayor a menor número de favoritos.
Ilustración Anexo II.5 – Lista de anuncios
Juan Cazalla Estrella Agregador de ventas online
94 Escuela Politécnica Superior de Jaén
Marcar como favorito
Una vez estamos en la pantalla SnipShare, si una oferta nos parece interesante
podemos añadirla a favoritos. Para ello, debemos acceder a la pantalla de detalle del
anuncio en cuestión.
Ilustración Anexo II.6 – Detalle de anuncio Ilustración Anexo II.7 – Anuncio favorito
Juan Cazalla Estrella Agregador de ventas online
95 Escuela Politécnica Superior de Jaén
Compartir oferta
Pero claro, para poder tener creada la lista de mejores ofertas, es necesario
que los usuarios creen anuncios nuevos. Para ello, deben acceder a la pantalla
SnipShare y una vez ahí pinchar sobre el botón + situado en la esquina superior
derecha, como se puede ver en la imagen del apartado anterior. Hecho esto, se abre
una nueva pantalla en la que tenemos que rellenar los datos requeridos para crear
un nuevo anuncio, los cuales se muestran a continuación:
Ilustración Anexo II.8 – Compartir anuncio
Juan Cazalla Estrella Agregador de ventas online
96 Escuela Politécnica Superior de Jaén
Una vez introducidos todos los datos, tendríamos que darle a Añadir Anuncio,
quedando así creado y visible para los usuarios.
Ver mis anuncios compartidos y mis favoritos
Para ver la lista de anuncios compartidos, desde la pantalla de perfil de
usuario, se puede acceder pulsando en Mis anuncios.
De igual forma, para ver los anuncios marcados como favoritos, habrá que
pulsar en Mis favoritos.
En la siguiente imagen se muestra la pantalla en cuestión.
Ilustración Anexo II.9 – Perfil