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



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.



Í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



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



Í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



Í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


10 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.



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.



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



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.



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.



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.



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



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.



• 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.



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



Caso de Uso Iniciar sesión

Actor primario Usuario registrado




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




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



Caso de Uso Ver lista de las mejores ofertas

Actor primario 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





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



Caso de Uso Ver detalle de oferta





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





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



Caso de Uso Marcar oferta como favorita





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





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



Caso de Uso Ver mis ofertas compartidas





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.



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



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.


SS-3 30

SS-4.1 10 Tabla 2.13 - Sprint 2



El tercer sprint se muestra en la tabla 2.14:


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:


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




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



SS11 Añadir la lista de las ofertas favoritas de un usuario 20



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



Con este backlog, los siguientes sprints quedaron de la siguiente manera:


SS5 40 Tabla 2.16 - Sprint 4



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.




SS8 30

SS10 15



SS9 30




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:


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:


SS13 20


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.



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



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



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].



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.



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



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



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].



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é



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.



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



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.



Diagrama de flujo

Ilustración 3.4 - Diagrama de flujo de registro e inicio de sesión



Storyboard

Ilustración 3.5 - Storyboard de registro e inicio de sesión



3.3.2. Cerrar sesión

Diagrama de flujo

Ilustración 3.6 - Diagrama de flujo de cierre de sesión



Storyboard

Ilustración 3.7 - Storyboard de cierre de sesión



3.3.3. Compartir oferta

Diagrama de flujo

Ilustración 3.8 - Diagrama de flujo de compartir oferta



Storyboard

Ilustración 3.9 - Storyboard de compartir oferta



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



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



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



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



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



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.



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.



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:



- 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.



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.



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



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:



Ilustración 4.3 - Diagrama de flujo de un caso de uso



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.



- 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.



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



- 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



- 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



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:



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.



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.



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



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:



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



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.



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



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.



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



[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



[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



ANEXO I

Manual de puesta en marcha del sistema



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



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



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.



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.



ANEXO II

Manual de usuario de la aplicació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



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.



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.



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



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



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



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

tfg - repositorio de la universidad de jaen: pàgina de...

Documents