Proyecto Taxi Programacion Java

Ta x i !
Memoria del proyecto

Autor: Antonio Rogel Barreiro
Consultor: Jordi Ceballos Villach
Fecha: 10 Junio 2013

Índice general
1. Índice de figuras II
2. Introducción 1
3. Definición General del Proyecto 2

3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2. Funcionalidades Principales . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Calendario del Proyecto 4

4.1. Entregas definidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Detalle entrega de la PAC1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Detalle Entrega Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Recursos e infraestructura 12
5.1. Software para Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Software en el Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Tecnologı́as 14
6.1. Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Riesgos del Proyecto 16
8. Análisis funcional 18
8.1. Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.1. Descripción básica del funcionamiento . . . . . . . . . . . . . . . . . 18
8.1.2. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1.3. Particularidades de la versión móvil . . . . . . . . . . . . . . . . . . 19
8.1.4. Uso de caracterı́sticas de los dispositivos iOS . . . . . . . . . . . . . 19
8.2. Funcionalidades del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 19
I
8.2.1. Plataforma móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2.2. Plataforma web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.3. Usuarios del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.4. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.4.1. Descripción caso de uso [CL00] Reservar Taxi . . . . . . . . . . . . 22
8.4.2. Descripción caso de uso [CL01] Pedir Taxi . . . . . . . . . . . . . . 22
8.4.3. Descripción caso de uso [CL02] Ver Disponibilidad . . . . . . . . . . 23
8.4.4. Descripción caso de uso [CL03] Valorar Servicio . . . . . . . . . . . 23
8.4.5. Descripción caso de uso [TA00] Iniciar Sesión . . . . . . . . . . . . 24
8.4.6. Descripción caso de uso [TA01] Finalizar Sesión . . . . . . . . . . . 24
8.4.7. Descripción caso de uso [TA02] Ver Reputación . . . . . . . . . . . 25
8.4.8. Descripción caso de uso [TA03] Aceptar Servicio . . . . . . . . . . . 25
8.4.9. Descripción caso de uso [TA04] Cómo Llegar . . . . . . . . . . . . . 26
8.4.10. Descripción caso de uso [AD00] Gestionar Taxistas . . . . . . . . . 26
9. Diseño técnico 27
9.1. Arquitectura plataforma web . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Arquitectura plataforma móvil . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.3. Arquitectura fı́sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.4. Arquitectura lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.4.1. Arquitectura lógica de la plataforma móvil . . . . . . . . . . . . . . . 29
9.4.2. Arquitectura iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.4.3. Arquitectura lógica de la plataforma web . . . . . . . . . . . . . . . . 31
9.4.4. Arquitectura lógica de intercambio de información entre plataformas 32
9.5. Arquitectura de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.6. Arquitectura de base de datos . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.6.1. Modelo entidad-relación de la base de datos . . . . . . . . . . . . . 33
9.6.2. Entidad taxi drivers . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.6.3. Entidad taxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.6.4. Entidad rides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.6.5. Entidad assignments . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.6.6. Entidad ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.7. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.7.1. Clases de la plataforma móvil (capa de presentación) . . . . . . . . 37
9.7.2. Clases de la plataforma móvil (capa de negocio) . . . . . . . . . . . 38
9.7.3. Clases de la plataforma web (capa de negocio) . . . . . . . . . . . . 39
9.7.4. Clases de la plataforma web (capa de presentación) . . . . . . . . . 40
9.8. Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.8.1. Diagrama de secuencia – Ejemplo ver disponibilidad . . . . . . . . . 40
II
10. Prototipo 42
10.1.Pantalla de inicio (cliente) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.2.Pantalla de solicitar taxi (cliente) . . . . . . . . . . . . . . . . . . . . . . . . 44
10.3.Pantalla de disponibilidad (cliente) . . . . . . . . . . . . . . . . . . . . . . . 45
10.4.Pantalla de inicio con servicio (cliente) . . . . . . . . . . . . . . . . . . . . . 46
10.5.Pantalla de inicio de sesión (taxista) . . . . . . . . . . . . . . . . . . . . . . 47
10.6.Pantalla inicial (taxista) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.7.Pantalla de reputación (taxista) . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.8.Pantalla de solicitud de servicio (taxista) . . . . . . . . . . . . . . . . . . . . 50
10.9.Pantalla de servicio en curso (taxista) . . . . . . . . . . . . . . . . . . . . . 51
11. Implementación 52
11.1.Caracterı́sticas principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1.1. Facilidad de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1.2. Rapidez de respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1.3. Multiples idiomas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1.4. Legibilidad del código fuente . . . . . . . . . . . . . . . . . . . . . . 53
11.2.Plataforma web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.3.Plataforma móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.3.1. App Taxista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
11.3.2. App Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
12. Funcionamiento de la aplicación 61

12.1.Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
12.1.1. Centrar mapa en usuario . . . . . . . . . . . . . . . . . . . . . . . . 61
12.1.2. Consulta disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . 62
12.1.3. Solicitud /reserva de taxi . . . . . . . . . . . . . . . . . . . . . . . . 63
12.1.4. Servicio en curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
12.1.5. Puntuar último servicio . . . . . . . . . . . . . . . . . . . . . . . . . 66
12.2.Taxista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
12.2.1. Inicio sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
12.2.2. Actualización disponibilidad y posición . . . . . . . . . . . . . . . . . 69
12.2.3. Aceptar o rechazar asignación . . . . . . . . . . . . . . . . . . . . . 69
12.2.4. Cómo llegar a cliente e inicio de servicio . . . . . . . . . . . . . . . . 72
12.2.5. Fin de servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
12.2.6. Reputación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
12.2.7. Cierre sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
13. Conclusiones 75
13.1.Cumplimiento de los objetivos propuestos . . . . . . . . . . . . . . . . . . . 75
III
13.2.Valoración personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
13.3.Futuras mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
14. Fuentes de información 78

14.1.Bibliografı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
14.2.Recursos web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
IV
1 Índice de figuras
8.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Arquitectura cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

9.2. Patrón MVC en Cocoa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Interacción entre los componentes MVC en Cocoa . . . . . . . . . . . . . . 30
9.4. Patrón MVC Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.5. Diagrama de Componentes general . . . . . . . . . . . . . . . . . . . . . . 32
9.6. Modelo Entidad Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.7. Diagrama clases capa presentación móvil . . . . . . . . . . . . . . . . . . . 37
9.8. Diagrama clases capa negocio móvil . . . . . . . . . . . . . . . . . . . . . . 38
9.9. Diagrama clases capa negocio web . . . . . . . . . . . . . . . . . . . . . . 39
9.10.Diagrama clases capa presentación web . . . . . . . . . . . . . . . . . . . . 40
9.11.Diagrama de secuencia para ver disponibilidad . . . . . . . . . . . . . . . . 41
10.1.Pantalla inicial - cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

10.2.Pedir un taxi - cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.3.Disponibilidad - cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.4.Cuánto falta - cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.5.Iniciar sesión - taxista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.6.Pantalla inicial - taxista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.7.Reputación - taxista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.8.Solicitud - taxista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.9.Servicio en curso - taxista . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.1. Árbol de proyecto Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

11.2. Árbol de proyecto iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.3.Storyboard de Taxista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.4.Storyboard de Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
12.1.App Cliente: icono, splash y pantalla principal . . . . . . . . . . . . . . . . . 61

12.2.App Cliente: centrar mapa en usuario . . . . . . . . . . . . . . . . . . . . . 62
12.3.App Cliente: ver taxis disponibles . . . . . . . . . . . . . . . . . . . . . . . . 63
12.4.App Cliente: solicitar taxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
V
12.5.App Cliente: notificación taxi en camino, con la app cerrada y abierta . . . . 64
12.6.App Cliente: taxi en camino . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
12.7.App Cliente: notificación taxi llegando, con la app cerrada y abierta . . . . . 65
12.8.App Cliente: estados de un servicio - pendiente, taxista en camino, iniciado 66
12.9.App Cliente: notificación finalización servicio, con la app cerrada y abierta . 67
12.10.App Cliente: puntuar último servicio . . . . . . . . . . . . . . . . . . . . . . 67
12.11.App Taxista: icono, splash y pantalla de login . . . . . . . . . . . . . . . . . 68
12.12.App Taxista: iniciar sesión con error . . . . . . . . . . . . . . . . . . . . . . 68
12.13.App Taxista: iniciar sesión con éxito . . . . . . . . . . . . . . . . . . . . . . 69
12.14.App Taxista: actualizar disponibilidad . . . . . . . . . . . . . . . . . . . . . . 69
12.15.App Taxista: notificación nuevo servicio asignado, con la app cerrada y
abierta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
12.16.App Taxista: rechazar servicio . . . . . . . . . . . . . . . . . . . . . . . . . . 71
12.17.App Taxista: aceptar servicio . . . . . . . . . . . . . . . . . . . . . . . . . . 71
12.18.App Taxista: cómo llegar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
12.19.App Taxista: finalizar servicio . . . . . . . . . . . . . . . . . . . . . . . . . . 72
12.20.App Taxista: ver reputación . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
12.21.App Taxista: cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
VI
2 Introducción
Quiero un taxi aquı́ y ahora
Una idea ası́ de simple es el origen de este proyecto. La posibilidad de pedir un taxi
simplemente pulsando un “botón”, sin necesidad de saber la dirección donde uno se
encuentra.
1
3 Definición General del Proyecto
Esa idea tan simple tiene muchas implicaciones. Para que al pulsar un botón se pida un
taxi, se necesita lo siguiente:
alguien a quien pedir el taxi
un taxi que pueda acudir a prestar el servicio
Para solventar estas necesidades, el proyecto deberá incluir una plataforma que los taxis-
tas puedan utilizar (lo que cubre la segunda necesidad). Esta plataforma se encargará de
recibir las peticiones y asignarlas al taxi más adecuado (con lo que también se cubre la
primera necesidad).
3.1. Objetivos
Se pretende desarrollar una aplicación en la que prime la facilidad de uso y la eficien-

cia sobre la cantidad de funcionalidades que implemente sólo por el hecho de ofrecer-
las.
Toda funcionalidad que se añada se analizará detalladamente para que su implementa-

ción no impacte negativamente en la experiencia de uso y mantenga una simplicidad y
facilidad de uso como el ejemplo indicado en la introducción.
3.2. Funcionalidades Principales
Para cumplir los objetivos la aplicación deberı́a proporcionar las siguientes funcionalida-
des:
Pedir un taxi: permitir a un usuario solicitar un taxi para el lugar donde se encuentre
Reservar un taxi: permitir a un usuario solicitar un taxi para la hora y lugar que
desee
Mostrar disponibilidad: permitir a un usuario consultar un mapa en tiempo real de

los taxis disponibles
2
PFC: Taxi! 3. Definición General del Proyecto
Cuánto falta: dar al usuario el tiempo estimado para la llegada del taxi
Está llegando: notificar a un usuario de la cercanı́a de la llegada del taxi
Identificación de usuario: permitir a un taxista identificarse en el sistema
Indicar disponibilidad: permitir a un taxista indicar su disponibilidad y su posición

(automáticamente vı́a GPS)
Aceptar servicio: permitir a un taxista aceptar o rechazar un servicio solicitado por

un cliente
Cómo llegar: indicar a un taxista la dirección del cliente y permitirle obtener la ruta
más apropiada
Valoraciones: permitir a un usuario introducir una reseña y puntuación tras haber

recibido un servicio
Mi reputación: permitir a un taxista ver un resumen de sus valoraciones
Estas valoraciones se podrı́an mostrar en el mapa de disponibilidad, pero dado que es

el sistema quien asigna un taxi a un usuario, podrı́a resultar contraproducente.
La app necesitarı́a de un servidor para centralizar la comunicación entre taxista y cliente.

Este componente contendrı́a la base de datos con los taxis disponibles y sus coordena-
das, y se encargarı́a de seleccionar el taxi más adecuado para un cliente dado.
Autor: Antonio Rogel Barreiro 3

4 Calendario del Proyecto
Debido a la naturaleza de los entregables a realizar en cada fecha especificada, se uti-

lizará una planificación en cascada, realizando primero el análisis de requerimientos,
diseño funcional y de interfaz de usuario, y posteriormente la implementación.
Por el tipo de producto que se generará en el proyecto podrı́a ser más apropiada una
planificación utilizando metodologı́as ágiles como las explicadas en otras asignaturas.
De todas formas, se emplearán ciertos aspectos de dichas metodologı́as allı́ donde sea
posible, siempre respetando la planificación indicada.
4.1. Entregas definidas
Los hitos del proyecto según la planificación especificada en el plan docente son:
Fecha de entrega Hito evaluación continua Entregable

11 de Marzo PAC 1 Plan de trabajo
8 de Abril PAC 2 Análisis y diseño prototipo
20 de Mayo PAC 3 Implementación
10 de Junio Entrega Final Memoria y vı́deo con la presentación
4.2. Calendario
Fijando la fecha de entrega final como fecha lı́mite (10 de Junio), y asignando hitos
para cada una de las entregas parciales, propongo el calendario descrito en el siguiente
diagrama de Gantt:
4
PFC: Taxi! 4. Calendario del Proyecto
Se dispone de 102 dı́as para realizar el proyecto (en el diagrama aparecen 161 dı́as
de “esfuerzo”, causados por tener tareas que transcurren en paralelo y no haber podido
asignar una dedicación parcial a cada una de ellas). Se consideran como hábiles los fines
de semana y festivos, habida cuenta que probablemente sean éstos los más aprovecha-
bles para avanzar el desarrollo del proyecto. Las tareas de diferentes grupos están en
distintos colores para facilitar su identificación. Las tareas en gris claro (Pruebas unitarias
y de integración) se realizarán simultáneamente a la implementación, debido a que se
utilizará el paradigma Behaviour Driven Development según el cual se escribirán los tests
de aceptación antes de escribir el código que implemente dicha funcionalidad.

4.3. Detalle entrega de la PAC1
Id tarea Nombre de la tarea Descripción de la tarea

3 Investigación previa Evaluar posibles proyectos a realizar,
tecnologı́as disponibles e inquietudes
4 Preparación propuesta Redacción propuesta del proyecto a realizar
para enviar al consultor
5 Preparación Plan de trabajo Redacción documento con objetivos,
planificación de tareas y riesgos
6 Encuentro virtual Encuentro virtual con el consultor y
compañeros del aula
7 Revisión Plan de trabajo Revisión documentación
8 Entrega Plan de trabajo Entrega documentación

Id Nombre de la tarea Descripción de la tarea

tarea
10 Preparación entorno desarrollo Tareas relacionadas con el entorno de
desarrollo
11 Descarga e instalación software Descarga e instalación software para el
desarrollo: Xcode, MySQL, Ruby on Rails
12 Configuración software (certificados, Configuración de los certificados y perfiles
perfiles) de aprovisionamiento en el portal de Apple
Developer para desarrollo en dispositivos
y para notificaciones push
13 Análisis funcional plataforma web Tareas relacionadas con el análisis de la
plataforma web
14 Especificación de requerimientos Identificación de requerimientos y
funcionalidades deseados
15 Definición casos de uso Detalle de casos de uso que implementen
los requisitos especificados


tarea
16 Análisis funcional plataforma móvil Tareas relacionadas con el análisis de la
plataforma móvil
17 Especificación de requerimientos Identificación de requerimientos y
funcionalidades deseados
18 Definición casos de uso Detalle de casos de uso que implementen
los requisitos especificados
19 Diseño funcional Tareas relacionadas con el diseño
funcional
20 Especificación arquitectura del sistema Identificación de la arquitectura del
sistema y comunicaciones entre las
plataformas
21 Generación diagramas de clases y bases Detalle de los diagramas de clases de la
de datos parte web y la parte móvil, modelo de
datos para parte web y, si es necesario,
modelo de datos para parte móvil
22 Prototipado Tareas relacionadas con el prototipado
23 Diseño interfaz usuario móvil Diseño de la interfaz, interacción y
experiencia de usuario de la aplicación
móvil
24 Preparación documento análisis Redacción de la documentación a partir
funcional, diseño y prototipo de la información generada
25 Revisión documento análisis funcional, Revisión de la documentación
diseño y prototipo
26 Entrega análisis funcional, diseño y Entrega de la documentación
prototipo


tarea
28 Implementación plataforma web Tareas relacionadas con la
implementación de la plataforma web
29 Implementación modelo de datos Implementación del modelo de datos en
Ruby on Rails sobre MySQL
30 Implementación servicios REST JSON Implementación de los servicios web
REST necesarios para la comunicación en
JSON con la plataforma móvil
31 Despliegue en servidor Despliegue en servidor de pruebas en
internet, necesario para poder hacer
pruebas de conectividad lejos del entorno
de desarrollo
32 Pruebas unitarias y de integración (TDD Especificación de requisitos como
/BDD) pruebas de aceptación y definición de
pruebas unitarias. Realizado en paralelo
con la implementación, siempre creando
el test antes que el código que lo satisfaga
(Behaviour Driven Development /Test
Driven Development)


tarea
33 Implementación plataforma móvil Tareas relacionadas con la
implementación de la plataforma móvil
34 Desarrollo aplicación móvil Implementación de la aplicación móvil
35 Pruebas unitarias y de integración (TDD Especificación de requisitos como
/BDD) pruebas de aceptación y definición de
pruebas unitarias. Realizado en paralelo
con la implementación, siempre creando
el test antes que el código que lo satisfaga
(Behaviour Driven Development /Test
Driven Development)
36 Integración Tareas relacionadas con la integración de
las plataformas
37 Pruebas de integración Especificación de tests de integración
automatizados para verificar la correcta
comunicación entre plataformas
38 Beta test Pruebas en el campo con varios
dispositivos simultáneamente para validar
los distintos casos de uso especificados
39 Revisión implementación Revisión documentación y código fuente a
entregar
40 Entrega implementación Entrega documentación y código fuente
4.6. Detalle Entrega Final

Id tarea Nombre de la tarea Descripción de la tarea

42 Elaboración memoria Tareas relacionadas con la elaboración de la
memoria
43 Preparación documento Redacción memoria partiendo de los
documentos generados en las entregas
anteriores
44 Elaboración presentación Tareas relacionadas con el entorno de
desarrollo
45 Preparación diapositivas Elaboración diapositivas para presentación
46 Elaboración guión vı́deo Preparación del guión de la presentación
coordinado con las diapositivas creadas
47 Grabación y edición vı́deo Grabación del vı́deo de la presentación, audio
de la locución, vı́deo de las demos de la
aplicación en el campo, y montaje del vı́deo
final
48 Revisión de la documentación Revisión de la documentación preparada
49 Entrega documentación Entrega de la documentación y vı́deo

5 Recursos e infraestructura
Para el desarrollo del proyecto se utilizarán los recursos definidos a continuación.
Ordenador de desarrollo: MacBook Pro 15” (Intel Core 2 Duo 2,8GHz, 8 GB RAM
DDR3), OS X 10.8.2 - 10.8.4
Servidor web: Para pruebas en local se utilizará el mismo ordenador de desarrollo;

para pruebas desde el móvil por 3G se utilizará una instancia de EC2 de Amazon,
al igual que para el servidor de producción
Teléfono móvil para pruebas: iPhone 4S con iOS 6.1.3
5.1. Software para Desarrollo
Se detalla a continuación el software que se utilizará durante el desarrollo:
Software Función
Xcode Entorno de desarrollo para la aplicación móvil
(Objective-C)
Textmate Editor de texto para desarrollar la aplicación
web (Ruby on Rails) y otros scripts de soporte
Byword Herramienta para la redacción en Markdown
de los documentos a entregar
Omniplan Herramienta para la gestión de proyectos y
preparación de diagramas de Gantt
Acorn Software para el retoque de imágenes
Dropbox Para copia de seguridad del código fuente y
documentos
Github Servicio web para almacenar los repositorios
del código fuente de ambas plataformas y de
la documentación
12
PFC: Taxi! 5. Recursos e infraestructura
5.2. Software en el Servidor
Por lo que respecta al software necesario en el servidor, constarı́a de los siguientes

elementos:
Software Función
nginx Servidor web que recibirá las peticiones web y
las distribuirá al servidor de aplicaciones
unicorn Servidor de aplicaciones basado en eventos
para Ruby on Rails
MySQL Base de datos para almacenar las peticiones,
los taxis y las coordenadas
grocer Software para comunicación con servidores de
Apple para notificaciones Push a los
dispositivos móviles

6 Tecnologı́as
El proyecto se divide en dos partes bien diferenciadas: un servicio web que recibe peti-
ciones de usuarios, asigna el taxi a utilizar y notifica a los interesados, y una app móvil
con la que interactuarán directamente los actores.
Las tecnologı́as implicadas en cada caso se detallan a continuación.
6.1. Web
El servidor web alojará una aplicación Ruby on Rails que implementará los servicios
REST con los que se comunicará la aplicación móvil. Almacenará en la base de datos
MySQL la posición GPS de cada uno de los taxis disponibles, y cuando un cliente solicite
un taxi detectará el más cercano a la posición del cliente y se lo notificará. Estas notifi-
caciones utilizarán la tecnologı́a Push disponible en la plataforma de Apple para que los
usuarios reciban los avisos aunque la aplicación móvil esté cerrada.
6.2. Móviles
La aplicación móvil se desarrollará en Objective-C utilizando el framework Cocoa Touch

que Apple incluye en el sistema operativo iOS 6 del iPhone. Aprovechará las carac-
terı́sticas del dispositivo como el GPS para obtener la posición tanto del cliente como
del taxista, y proporcionará herramientas para proporcionar al taxista la ruta óptima para
llegar al cliente. Además, se aprovechará la posibilidad de definir regiones y eventos al
cruzar la frontera de las mismas para avisar al cliente cuando el taxi esté llegando.
6.3. Comunicaciones
La comunicación entre el dispositivo móvil y la plataforma web se realizará utilizando

servicios REST (Representational State Transfer ), con mensajes en JSON (JavaScript
14
PFC: Taxi! 6. Tecnologı́as
Object Notation). Se trata de tecnologı́as mucho más simples y eficientes que SOAP y
XML para la naturaleza de las comunicaciones a utilizar.
Para las notificaciones Push, el servidor web se comunicará con la plataforma de notifi-
caciones de Apple encargados de distribuir las notificaciones a los dispositivos utilizando
también REST y JSON. Los dispositivos recibirán las notificaciones con el mensaje JSON
indicado por el servidor web a la plataforma de notificaciones de Apple.

7 Riesgos del Proyecto
A continuación se muestra una tabla con una serie de riesgos identificados para el éxito
del proyecto:
Riesgo Descripción Proba- Im- Acciones mitigadoras

bilidad pac-
to
Averı́a de los Tanto del ordenador de Baja Crı́ti- Copias de seguridad del
dispositivos desarrollo como del móvil co entorno para poder replicarlo
para pruebas con la mayor facilidad en
otro equipo. Sustitución
temporal por dispositivos
antiguos durante la
reparación.
Pérdida de Por averı́a o por fallo Baja Gra- Copias de seguridad
datos humano ve múltiples: copias diarias y
clon del equipo de desarrollo
a diversos discos duros,
copias de los documentos y
código del proyecto en la
nube.
16
PFC: Taxi! 7. Riesgos del Proyecto

bilidad pac-
to
Planificación incorrecta Error en las Media Me- Reprogramar tareas, en
estimaciones dio caso extremo reevaluar
el alcance del proyecto y
reducir funcionalidades.
Problemas para Por falta de Media Me- En caso de limitación
implementar conocimiento dio técnica, reevaluar la
funcionalidades /experiencia o funcionalidad deseada
limitaciones técnicas para intentar ofrecer una
para realizar alguna solución
funcionalidad alternativa/equivalente.
Para la falta de
experiencia o
conocimiento,
recopilación de
documentación sobre los
entornos de desarrollo
(libros, videos, etc.).
Enfermedad Por contagio o por Media Me- Añadir a la planificación
accidente dio márgenes adicionales de
tiempo para
eventualidades.

bilidad pac-
to
Puntas de Realización de horas extras Alta Me- Intentar adelantar el progreso
trabajo para cumplir fechas lı́mites dio de las tareas en la medida de
de entrega en el trabajo lo posible para evitar retrasos
cuando sucedan estos
imprevistos.
Cambio de Posibilidad de cambiar de Baja Alto Al igual que en el caso
trabajo empresa, con el añadido de anterior, intentar adelantar el
la disrupción que conllevarı́a progreso de las tareas en la
un traslado a otra ciudad medida de lo posible para
evitar retrasos si se da el
caso.

8 Análisis funcional
En esta sección se detallarán los requisitos del sistema y los casos de uso para ofrecer
una visión global de la solución propuesta.
8.1. Requerimientos funcionales
El sistema tiene como finalidad permitir la comunicación entre taxistas y clientes de ca-
ra a realizar solicitudes de servicio, evitando al cliente la necesidad de saber dónde
está exactamente, o el nombre de la calle. Para cumplir este objetivo, contará con las
funcionalidades descritas a continuación.
8.1.1. Descripción básica del funcionamiento
La aplicación debe cubrir la funcionalidad básica de poder pedir un taxi de la forma más
sencilla posible. Para poder cumplir esta funcionalidad debe permitir:
Pedir o reservar un taxi: permitir a un usuario solicitar un taxi para la hora y el lugar
que indique

un cliente
Notificar al usuario el tiempo estimado y la llegada del taxi
8.1.2. Interfaz
Uno de los objetivos principales de la aplicación es que prime la facilidad de uso y la

eficiencia sobre la cantidad de funcionalidades que implemente sólo por el hecho de
ofrecerlas.
Toda funcionalidad que se añada se analizará detalladamente para que su implementa-

ción no impacte negativamente en la experiencia de uso y mantenga la máxima simplici-
dad y facilidad de uso.
18
PFC: Taxi! 8. Análisis funcional
8.1.3. Particularidades de la versión móvil
Para poder realizar la comunicación entre clientes y taxistas, se necesita de una plata-
forma web que haga de intermediario, reciba los mensajes y notifique a los interesados.
Esta plataforma web podrı́a tener funcionalidades avanzadas, como la posibilidad de
asignar manualmente un servicio a un taxista o consultar estadı́sticas e informes, pe-
ro en el ámbito de este proyecto simplemente consistirá en proveer servicios web a la
aplicación móvil y una simple interfaz para registrar taxistas en el sistema.
8.1.4. Uso de caracterı́sticas de los dispositivos iOS
La aplicación móvil utilizará las caracterı́sticas que ofrece el entorno de desarrollo de iOS
para utilizar los recursos del dispositivo. Se utilizará tanto el módulo GPS presente en
cada iPhone como la conectividad a red. Debido al tipo de uso que tendrá la aplicación,
dicha conectividad será principalmente vı́a 3G.
En este caso, existe una discrepancia en el uso tı́pico del GPS que necesita hacer la
aplicación según el usuario. Si se trata de un cliente, se puede asumir que irá a pie,
por lo que el GPS puede estar apagado gran parte del tiempo, sólo activándose en el
momento de iniciar una solicitud. En cambio, para el caso del taxista el GPS tiene que
estar activo con mucha más frecuencia para que pueda notificar su posición al servidor,
y dicha información ha de tener la mayor vigencia posible.
8.2. Funcionalidades del sistema
A continuación se describen con más detalle las funcionalidades anteriormente mencio-

nadas.
8.2.1. Plataforma móvil
La aplicación móvil debe poder ofrecer las siguientes operaciones:
Pedir un taxi: permitir a un usuario solicitar un taxi para el lugar donde se encuentre
Reservar un taxi: permitir a un usuario solicitar un taxi para la hora y lugar que
desee
Mostrar disponibilidad: permitir a un usuario consultar un mapa en tiempo real de

los taxis disponibles

Cuánto falta: dar al usuario el tiempo estimado para la llegada del taxi
Está llegando: notificar a un usuario de la cercanı́a de la llegada del taxi
Identificación de usuario: permitir a un taxista identificarse en el sistema
Indicar disponibilidad: permitir a un taxista indicar su disponibilidad y su posición

(automáticamente vı́a GPS)

un cliente
Cómo llegar: indicar a un taxista la dirección del cliente y permitirle obtener la ruta
más apropiada
Valoraciones: permitir a un usuario introducir una reseña y puntuación tras haber

recibido un servicio
Mi reputación: permitir a un taxista ver un resumen de sus valoraciones
8.2.2. Plataforma web
La plataforma web tiene como funcionalidad principal el hacer de nexo de unión entre
clientes y taxistas, recibiendo comunicaciones de la aplicación móvil y enviando notifi-
caciones a los usuarios. Para realizar estas tareas implementará una interfaz REST que
permitirá a la aplicación móvil realizar sus operaciones.
Operación en la plataforma móvil Operación en la plataforma web

Pedir un taxi Webservice Pedir Taxi
Reservar un taxi Webservice Pedir Taxi
Mostrar disponibilidad Webservice Ver Disponibilidad
Cuánto falta Webservice Información Servicio
Iniciar sesión Webservice Iniciar Sesión
Indicar disponibilidad Webservice Actualizar Disponibilidad
Aceptar servicio Webservice Actualizar Servicio
Añadir Valoración Webservice Añadir Valoración
Consultar reputación Webservice Consultar Reputación
8.3. Usuarios del sistema
Los actores que intervendrán en el sistema se pueden definir teniendo en cuenta la

plataforma con la que tendrán que interactuar. Ası́ pues, contaremos con usuarios de la

App Móvil Clientes Finales, usuarios de la App Móvil Taxistas, y usuarios del módulo de
gestión de la plataforma web:
Cliente: representa a aquellos usuarios que interactúan con la aplicación móvil para
clientes.
Taxista registrado: representa a aquellos usuarios que han sido dados de alta en el
sistema como taxistas.
Taxista identificado: representa a aquellos usuarios que se han autenticado en la

aplicación móvil para taxistas, por lo que pueden acceder a las funcionalidades
disponibles.
Administrador: representa a aquellos usuarios que se conectan a la plataforma web

para realizar tareas de gestión.
8.4. Casos de uso
Una vez identificados los actores que intervienen en la aplicación, a continuación se

muestra una vista global de los casos de uso que contemplan las funcionalidades espe-
cificadas anteriormente:
Iniciar Sesión
Valorar
Servicio
Finalizar
Sesión Taxista
Reservar Taxi Registrado
Cliente
<extiende> Ver
Reputación
Pedir Taxi
<extiende> Asignar
Servicio
<usa>
Taxista
Identificado
<extiende>
<usa>
Aceptar
Ver Servicio
Disponibilidad
<usa>
<usa>
Mostrar Mapa <extiende>
<usa>
Cómo Llegar
Gestionar
Taxistas
Administrador
Figura 8.1: Diagrama de Casos de Uso

A continuación se describirán los casos de uso con más detalle.
8.4.1. Descripción caso de uso [CL00] Reservar Taxi
Identificador CL00
Nombre Reservar Taxi
Resumen El cliente reserva un taxi para un lugar y una
hora determinados
Actores Cliente
Precondiciones El cliente ha iniciado la aplicación
Postcondiciones El cliente ha enviado una solicitud
Flujo normal 1. El cliente pulsa sobre el botón de pedir taxi -
2. El cliente selecciona una ubicación - 3. El
cliente selecciona una hora - 4. El cliente
pulsa sobre el botón pedir para confirmar
Flujos alternativos 4b. El cliente pulsa sobre el botón volver y
cancela la petición
Inclusiones SY00 Mostrar Mapa
Extensiones Asignar Servicio
8.4.2. Descripción caso de uso [CL01] Pedir Taxi
Identificador CL01
Nombre Pedir Taxi
Resumen El cliente reserva un taxi en su ubicación
actual para ese mismo momento
Actores Cliente
Postcondiciones El cliente ha enviado una solicitud
Flujo normal 1. El cliente pulsa sobre el botón de pedir taxi -
2. El cliente pulsa sobre el botón pedir para
confirmar
Flujos alternativos 2b. El cliente pulsa sobre el botón volver y
cancela la petición
Extensiones Asignar Servicio

8.4.3. Descripción caso de uso [CL02] Ver Disponibilidad
Identificador CL02
Nombre Ver Disponibilidad
Resumen Este caso de uso indica cómo el cliente puede
comprobar los taxis disponibles en un
momento dado
Actores Cliente
Postcondiciones El cliente ha visto los taxis disponibles
Flujo normal 1. El cliente pulsa sobre el botón ver
disponibilidad - 2. Se visualizan los taxis
disponibles sobre el mapa - 3. El cliente pulsa
sobre el botón volver
Flujos alternativos -
Extensiones Ninguno
8.4.4. Descripción caso de uso [CL03] Valorar Servicio
Identificador CL03
Nombre Valorar Servicio
Resumen Este caso de uso indica cómo el cliente puede
valorar un servicio recibido
Actores Cliente
Precondiciones El cliente ha recibido un servicio
Postcondiciones El cliente ha valorado el servicio o ha
declinado hacerlo
Flujo normal 1. El sistema notifica al cliente que el servicio
ha finalizado - 2. El cliente pulsa sobre el
botón valorar - 3. El cliente introduce su
puntuación de 1 a 5 - 4. El cliente pulsa sobre
el botón aceptar
Flujos alternativos 2b. El cliente pulsa sobre el botón declinar -
4b. El cliente pulsa sobre el botón cancelar
Inclusiones Ninguno
Extensiones Ninguno

8.4.5. Descripción caso de uso [TA00] Iniciar Sesión
Identificador TA00
Nombre Iniciar Sesión
Resumen Caso de uso que muestra cómo un taxista
inicia sesión
Actores Taxista Registrado
Precondiciones El usuario no ha iniciado sesión
Postcondiciones El usuario ha iniciado sesión
Flujo normal 1. El cliente rellena el formulario y pulsa sobre
el botón iniciar sesión - 2. El sistema valida los
datos del usuario, si son correctos activa la
sesión del usuario y muestra el menú principal
Flujos alternativos 1b. El usuario cierra la aplicación - 2b. Si los
datos no son correctos se muestra el
formulario de nuevo
Inclusiones Ninguno
Extensiones Ninguno
8.4.6. Descripción caso de uso [TA01] Finalizar Sesión
Identificador TA01
Nombre Finalizar Sesión
Resumen Caso de uso que muestra cómo un taxista
finaliza sesión
Actores Taxista Identificado
Precondiciones Un taxista ha iniciado sesión
Postcondiciones No hay sesión activa
Flujo normal 1. El cliente pulsa sobre el botón salir - 2. En la
ventana de confirmación, el cliente pulsa
sobre el botón confirmar
Flujos alternativos 2b. El cliente pulsa sobre el botón cancelar y
sigue con su sesión activa
Inclusiones Ninguno
Extensiones Ninguno

8.4.7. Descripción caso de uso [TA02] Ver Reputación
Identificador TA02
Nombre Ver Reputación
Resumen Este caso de uso indica cómo el taxista puede
consultar su reputación
Postcondiciones -
Flujo normal 1. El taxista pulsa sobre el botón ver
reputación - 2. Se muestra la puntuación
media de sus valoraciones en pantalla
Inclusiones Ninguno
Extensiones Ninguno
8.4.8. Descripción caso de uso [TA03] Aceptar Servicio
Identificador TA03
Nombre Aceptar Servicio
aceptar un servicio
Postcondiciones El servicio ha sido aceptado y el cliente
notificado
Flujo normal 1. El sistema notifica al taxista del servicio
asignado - 2. El taxista pulsa sobre el botón
aceptar - 3. El sistema notifica al cliente
Flujos alternativos 2b. El taxista pulsa sobre el botón rechazar, el
sistema selecciona otro taxista y le notifica
Extensiones TA04 Cómo Llegar

8.4.9. Descripción caso de uso [TA04] Cómo Llegar
Identificador TA04
Nombre Cómo Llegar
consultar una ruta al cliente
Precondiciones El taxista tiene un servicio aceptado en curso
Postcondiciones El taxista obtiene una ruta para llegar al cliente
Flujo normal 1. El taxista pulsa sobre el botón cómo llegar -
2. Se abre la aplicación de mapas nativa con
la ruta ya introducida
Extensiones Ninguno
8.4.10. Descripción caso de uso [AD00] Gestionar Taxistas
Identificador AD00
Nombre Gestionar Taxistas
Resumen Caso de uso de alto nivel que explica cómo el
administrador añade taxistas en el sistema
Actores Administrador
Precondiciones El administrador ha abierto el sistema
Postcondiciones El taxista ha sido añadido
Flujo normal 1. El administrador pulsa sobre el botón añadir
taxista - 2. El administrador rellena los datos
del taxista en el formulario y le asigna una
contraseña - 3. El administrador pulsa sobre el
botón guardar
Flujos alternativos 3b. El administrador pulsa sobre el botón
cancelar y sale del formulario
Inclusiones Ninguno
Extensiones Ninguno

9 Diseño técnico
La arquitectura del proyecto está basada en un modelo cliente-servidor.
Figura 9.1: Arquitectura cliente-servidor
9.1. Arquitectura plataforma web
La plataforma web corresponderı́a a la parte servidor del modelo de arquitectura men-

cionado anteriormente.
Los componentes que formarán parte de la plataforma web son:
Servidor web: nginx - recibe las peticiones de de los clientes vı́a internet
Servidor de Ruby on Rails: unicorn - servidor para aplicaciones Rack compatible

con Ruby on Rails
Servidor de Bases de Datos: MySQL - persiste el modelo de datos implementado

en la aplicación Ruby on Rails
Adicionalmente, se hará uso de la infraestructura de servidores push de Apple para en-

viar las notificaciones a los dispositivos registrados.
La plataforma web responderá tanto a las peticiones de los clientes mediante servicios
web como a las peticiones del administrador.
27
PFC: Taxi! 9. Diseño técnico
9.2. Arquitectura plataforma móvil
La plataforma móvil corresponderı́a a la parte cliente del modelo de arquitectura utiliza-

do.
En este caso, la aplicación cliente estará implementada para el sistema operativo iOS de
Apple, en concreto para teléfonos móviles iPhone (no habrá versión adaptada para ta-
bletas), utilizando los frameworks proporcionados por Apple y englobados con el nombre
Cocoa Touch.
Además, se hará uso de la infraestructura de servidores push de Apple para poder recibir
las notificaciones del servidor sin obligar a tener abierta la aplicación permanentemen-
te.
9.3. Arquitectura fı́sica
La arquitectura fı́sica tanto en desarrollo como en producción será prácticamente igual,

dado que para poder hacer pruebas en desarrollo con cierta utilidad hay que utilizar
varios dispositivos que no pueden estar en la misma ubicación fı́sica. Por tanto, estén
donde estén tienen que poder acceder al servidor de desarrollo.
Ası́ pues se utilizará un servidor accesible desde internet para realizar el desarrollo,
distinto del servidor de producción donde se alojará definitivamente.
La principal diferencia entre desarrollo y producción será que se utilizarán servidores

push de Apple distintos, que requieren certificados diferentes para poder enviar dichas
notificaciones.
9.4. Arquitectura lógica
Se usará en ambas plataformas una arquitectura Modelo-Vista-Controlador (MVC). Los

beneficios que conlleva son los siguientes:
Separación de la lógica de negocio de la interfaz de usuario
Facilita el evitar repetir código innecesariamente (paradigma conocido por sus ini-
ciales DRY, de Don’t Repeat Yourself o No te repitas)
Simplifica el mantenimiento al dejar claro dónde corresponde ir cada tipo de código
Los componentes de la arquitectura MVC son:

Modelos: Representan la información (datos) de la aplicación y las reglas para

manipular esos datos
Vistas: Representan la interfaz de usuario de la aplicación
Controladores: Proporcionan el “pegamento” entre los modelos y las vistas, hacien-

do de intermediarios entre la interacción del usuario con la interfaz de usuario y los
datos
9.4.1. Arquitectura lógica de la plataforma móvil
Debido a las diferentes necesidades de los usuarios de la plataforma móvil (clientes fina-
les y taxistas), se separará la aplicación cliente en dos aplicaciones especı́ficas, en aras
de una mejor usabilidad y simplicidad de uso. Además, hacerlo de esta forma permite te-
ner caracterı́sticas de uso de los recursos diferentes para cada aplicación, adaptándose
mejor a las necesidades de cada usuario.
Un ejemplo de esta mejor flexibilidad se halla en el uso del GPS, pues se puede asumir
que el cliente final irá a pie cuando realice una solicitud, y no será necesario tenerlo
activo constantemente. En cambio, para un taxista sı́ que es conveniente tenerlo activo
más a menudo para poder notificar su posición más frecuentemente al servidor; además,
se puede asumir que el incremento en gasto de la baterı́a por usar más el GPS no es
tan problemático dado que los taxistas pueden mantener cargado el teléfono en el propio
taxi.
Si bien lo habitual es utilizar una arquitectura de 3 capas, consistente en tener una capa
de presentación, una capa de negocio, y una capa de acceso a datos, en el caso de
aplicaciones para iOS se tiende a fusionar la capa de negocio y la capa de acceso a
datos, implementando ambas en los modelos de MVC. No obstante, esto conlleva una
excesiva aumento de las responsabilidades de los modelos, por lo que sigue siendo
conveniente mantener capas separadas.
9.4.2. Arquitectura iOS
El lenguaje de programación utilizado en iOS es Objective-C. También es posible desa-

rrollar aplicaciones utilizando Ruby o Lua, pero es menos habitual.

Figura 9.2: Patrón MVC en Cocoa
El patrón MVC es parte fundamental de la filosofı́a de programación para Cocoa. Los

frameworks se diseñaron para usar dicho patrón, por lo que el desarrollo es más sencillo
y rápido si se usa MVC. De hecho, muchas de las tecnologı́as subyacentes que ofrece
Cocoa están basadas en MVC y requieren que los objetos desarrollados hagan alguno
de los roles de MVC.
Figura 9.3: Interacción entre los componentes MVC en Cocoa
Una de las particularidades de MVC en Cocoa es que existen objetos que combinan
dos de los roles; uno de los más utilizados es el ViewController, que se tratarı́a de un
controller que se ocupa principalmente de la capa de vista. Su responsabilidad principal
es gestionar la interfaz y comunicarse con el modelo. Son la principal herramienta para
gestionar la interacción con el usuario.

9.4.3. Arquitectura lógica de la plataforma web
Rails es un framework de desarrollo de aplicaciones web escrito en Ruby. Está diseñado

para hacer más fácil la programación de aplicaciones web haciendo suposiciones so-
bre cuál es la “mejor” forma de hacer ciertas cosas y tomando decisiones en lugar de
trasladarlas al desarrollador.
La filosofı́a Rails incluye los siguientes principios básicos:
DRY – “Don’t Repeat Yourself” – escribir el mismo código una y otra vez es malo
Convención por encima de Configuración – Rails toma decisiones sobre qué es lo

que se quiere hacer y cómo se va a hacer, en lugar de requerir que el desarrollador
especifique cada detalle en ficheros de configuración.
El mejor patrón para aplicaciones web es REST – utilizar recursos y verbos HTTP
estándar es la forma más rápida de desarrollar.
Routing
1. URL
1 2. El enrutador localiza el
controlador
2 3. El controlador interactúa
con el modelo
4. El controlador invoca a la
Controller vista
5. La vista renderiza la
siguiente pantalla del
3 navegador
4
5
Active
View Record
Model Database
Figura 9.4: Patrón MVC Ruby on Rails
Por lo que respecta al patrón MVC, el comportamiento de los distintos componentes es

como sigue:
Modelos - se usan principalmente para gestionar las reglas de interacción con la

tabla de base de datos correspondiente. En la mayorı́a de los casos hay una rela-
ción cada tabla de la base de datos corresponde a un modelo. La gran mayorı́a de
la lógica de negocio de la aplicación estará concentrada en los modelos.
Vistas - se trata comúnmente de ficheros HTML con código Ruby incrustado que
realiza tareas exclusivamente relacionadas con la presentación de los datos. Las
vistas proporcionan los datos al navegador web o a quien esté realizando peticio-
nes a la aplicación.

Controladores - son responsables de procesar las peticiones recibidas, pedir infor-

mación a los modelos y pasar dicha información a las vistas para su presentación.
9.4.4. Arquitectura lógica de intercambio de información entre

plataformas
La comunicación entre las plataformas se realizará utilizando REST1 (Representational

State Transfer ), utilizando JSON (JavaScript Object Notation) para el envı́o de mensa-
jes.
9.5. Arquitectura de componentes
Plataforma
Móvil (Cliente)
ViewControllers Modelos
API Client
Vistas Frameworks
Servidor HTTP SGBD
Apple Map Apple Push

Services Services
Plataforma Web
Plataforma
Móvil (Taxi) Modelos
API REST
ActiveRecord
Vistas Frameworks
API Client
ViewControllers Modelos
Figura 9.5: Diagrama de Componentes general

1
http://www.ics.uci.edu/⇠fielding/pubs/dissertation/rest arch style.htm

La comunicación se realiza, en el caso de la plataforma móvil, a través de los frameworks

del sistema, conectando con el servidor HTTP de la plataforma web (que devuelve las
respuestas correspondientes), y con los servicios de Apple de notificaciones push y de
mapas.
Por lo que respecta a la plataforma web, cuando es el momento de enviar una notifica-
ción push lo hace directamente la capa de lógica de negocio, sin pasar por el servidor
HTTP.
9.6. Arquitectura de base de datos
La base de datos del sistema gestiona los datos de los taxistas, la ubicación de cada taxi
en tiempo real, y el histórico de servicios solicitados, asignados y realizados. El modelo
entidad-relación se define a continuación
9.6.1. Modelo entidad-relación de la base de datos
A continuación se muestra el modelo propuesto para la base de datos:

#

$

% %&-

%

)*+

!"! (
)*+

,'

!"! # %
%

(
!"!
!"!

!"!

!"!

%
#

&'( !"!
$ !"!

)*+
% !"!
(
)*+ !"!
!"!
!"!
!"!

!"!

!"!

Figura 9.6: Modelo Entidad Relación
Estas son las funciones de cada una de las tablas:

Entidad Descripción
taxi drivers Almacena los datos del usuario taxista
taxis Almacena los datos actuales del taxi: posición,
disponibilidad. . .
rides Almacena información sobre un servicio: hora,
lugar, dispositivo que ha realizado la
petición. . .
assignments Almacena el histórico de asignaciones de un
servicio a taxistas, y sus respuestas
respectivas hasta que uno lo acepte
ratings Almacea las valoraciones de los clientes sobre
los servicios prestados
admins Almacena los datos del usuario administrador
del sistema
Entidad Cardinalidad Entidad relacionada

taxi drivers 1:1 taxis
taxis 1:N ratings
taxis 1:N assignments
taxis 1:1 assignments (actual)
rides 1:N assignments
rides 1:N ratings
9.6.2. Entidad taxi drivers
La entidad taxi drivers se define como sigue:
Atributo Tipo Descripción

username Texto Guarda el nombre de usuario del taxista
email Texto Guarda el email del taxista
encrypted password Texto Guarda la contraseña del usuario
9.6.3. Entidad taxi
La entidad taxi se define como sigue:


identifier Texto Guarda el identificador del taxi
available Booleano Guarda la última disponibilidad del taxi
latitude Decimal Guarda la última latitud del taxi
longitude Decimal Guarda la última longitud del taxi
taxi driver id Entero Referencia al taxista
current assignment id Entero Referencia a la asignación actual
updated at Hora Guarda la hora de la última actualización de
posición y disponibilidad del taxi
9.6.4. Entidad rides
La entidad rides se define como sigue:

status Texto Guarda el estado del servicio
device Texto Guarda el identificador del dispositivo que ha
solicitado el servicio
locator Texto Guarda el localizador asignado al servicio
booking time Hora Guarda la hora para la que se desea el
servicio
latitude Decimal Guarda la latitud del servicio
longitude Decimal Guarda la longitud del servicio
9.6.5. Entidad assignments
La entidad assignments se define como sigue:

status Texto Guarda el estado de la asignación
taxi id Entero Referencia al taxi
ride id Entero Referencia al servicio
notified at Hora Guarda la hora en que se notificó a un taxista
response received at Hora Guarda la hora en que respondió el taxista

9.6.6. Entidad ratings
La entidad ratings se define como sigue:

taxi id Entero Referencia al taxi
ride id Entero Referencia al servicio
device Texto Guarda el identificador del dispositivo que ha
realizado la valoración
value Entero Guarda la puntuación
created at Hora Guarda la hora en la que se realizó la
valoración
9.7. Diagrama de clases
El diagrama de clases tendrá bastante semejanza con el diagrama entidad-relación, dado

las entidades del diagrama entidad-relación también estarán presentes como clases en
ambas plataformas, principalmente en la web debido a la implementación de MVC que
usa Rails. En el caso de la plataforma móvil, habrá entidades que deriven su información
de las del diagrama entidad-relación, pero no será una relación tan directa.

9.7.1. Clases de la plataforma móvil (capa de presentación)
Taxi
TaxiLoginViewController TaxiReputationViewController
Modelos
TaxiMainViewController
TaxiRideViewController
TaxiAssignmentViewController
MKMapViewController
Cliente
TaxiLocationDelegate
CustomerMainViewController
Modelos
MKMapViewController
Figura 9.7: Diagrama clases capa presentación móvil

9.7.2. Clases de la plataforma móvil (capa de negocio)
Taxi
Taxi Reputation
TaxiLocationDelegate TaxiAPIClient
Ride Assignment
Cliente
Ride Taxi
Request TaxiAPIClient
Figura 9.8: Diagrama clases capa negocio móvil

9.7.3. Clases de la plataforma web (capa de negocio)
TaxiDriver
add_taxi
1
1
Taxi
Rating closest_taxis
* 1
distance_to
1 1 1
1 * 1
Ride Assignment
assign_taxi accept_assignment
begin 1 * reject_assignment
end notify_taxi_driver
rate notify_customer
<<usa>> <<usa>>
Notification
send
Figura 9.9: Diagrama clases capa negocio web

9.7.4. Clases de la plataforma web (capa de presentación)
CustomerAPI
available_taxis
hail_taxi
schedule_pickup
assigned_taxi
requested_ride
unrated
rate
Lógica de
TaxiAPI negocio
login
logout
taxi_information
update_position
update_availability
update_device_id
accept_ride
reject_ride
begin_ride
end_ride
assignment_information
ride_information
reputation
Figura 9.10: Diagrama clases capa presentación web
9.8. Diagrama de secuencia
A continuación se incluye un ejemplo de diagrama de secuencia, que representa la inter-

acción entre los objetos del sistema para visualizar el mapa de disponibilidad.
9.8.1. Diagrama de secuencia – Ejemplo ver disponibilidad
En el diagrama se incluye tanto los componentes de la plataforma móvil como los de la

plataforma web.

Usuario CustomerMainView SystemFrameworks TaxiAPIClient CustomerAPI (web) Taxi < ActiveRecord::Base MySQL
Controller (web)
1. Ver disponibilidad
2. Crea
Availability
2. Crea MKMapViewCont
roller
3. getAvailableTaxis
4. getCurrentPosition
7. getAvailableTaxis
8. filterAvailability
5. locations 9. SELECT ...
6. center
11. Array 10. Array
12. JSON
13. JSON
14. drawAnnotations
15. Mapa con taxis
Figura 9.11: Diagrama de secuencia para ver disponibilidad

10 Prototipo
A continuación se muestran los prototipos de algunas pantallas de las aplicaciones móvi-

les para iPhone. Se tratan de pruebas de concepto, para validar la usabilidad y la funcio-
nalidad de las aplicaciones. No son representativas del diseño visual definitivo.
Estas pantallas se han desarrollado sobre Xcode, utilizando la herramienta visual Interfa-
ce Builder integrada que ofrece ayuda a la hora de insertar elementos y alinearlos según
las recomendaciones de Apple para Interfaces de Usuario en iOS1 . También se ha uti-
lizado la funcionalidad de Storyboards para realizar las transiciones entre pantallas sin
tener que implementar código.
Se valoraron otras opciones para desarrollar las pantallas como por ejemplo FluidUI2 o
usar plantillas con elementos de la interfaz de iOS en Photoshop, pero estas opciones, a
pesar de permitir diseños más elaborados, no ofrecı́an ningún tipo de asistencia a la hora
de respetar los márgenes o ofrecer ayuda al colocar los elementos de la interfaz.
Ası́ mismo, el entorno de desarrollo Xcode ofrece la posibilidad de realizar aplicaciones

multiidioma, pudiendo reutilizar la misma disposición de elementos y cambiar sólo los
textos, o bien cambiar totalmente la disposición según el idioma (por si los textos son
demasiado grandes y hay que recolocar los elementos).
1
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/
Introduction/Introduction.html
2
https://www.fluidui.com
42
PFC: Taxi! 10. Prototipo
10.1. Pantalla de inicio (cliente)
Figura 10.1: Pantalla inicial - cliente
Esta pantalla es la primera que aparece al abrir la aplicación de cliente y permite acceder
a las funcionalidades más importantes de la aplicación:
El botón “Pedir Taxi” permite solicitar un taxi en el lugar y momento que indique el
usuario
El botón “Ver Taxis” permite consultar los taxis disponibles actualmente
El botón con el icono de flecha centra el mapa en la posición actual del usuario
Esta pantalla cambiará su aspecto cuando haya un servicio en curso, como se verá pos-
teriormente.

10.2. Pantalla de solicitar taxi (cliente)
Figura 10.2: Pedir un taxi - cliente
Esta pantalla permite solicitar un taxi, preseleccionando la ubicación actual. También

permite seleccionar cuándo se desea solicitar el taxi, y por defecto está seleccionado el
valor “Ahora”.
Para cambiar la ubicación, basta con arrastrar el pin añadido automáticamente en la

ubicación actual del usuario.
Para cambiar el momento para el que se desea el taxi se puede elegir entre las tres
opciones en el selector: “ahora”, “en 1 hora”, “en 2 horas”.
Finalmente, el botón “Cancelar” cierra la pantalla sin realizar la reserva, mientras que el
botón “Pedir” confirma la solicitud en el sistema.

10.3. Pantalla de disponibilidad (cliente)
Figura 10.3: Disponibilidad - cliente
Esta pantalla visualiza sobre el mapa la ubicación actual, y un icono para cada uno de
los taxis disponibles actualmente.

10.4. Pantalla de inicio con servicio (cliente)
Figura 10.4: Cuánto falta - cliente
Tras solicitar un servicio, la pantalla de inicio cambia para mostrar la distancia a la que
se encuentra el taxi y la posición del mismo sobre un mapa.

10.5. Pantalla de inicio de sesión (taxista)
Figura 10.5: Iniciar sesión - taxista
Esta es la pantalla inicial de la aplicación para taxistas. Muestra un formulario para in-
troducir usuario y contraseña. Tras pulsar en “Iniciar sesión” se procede a mostrar el
menú inicial.

10.6. Pantalla inicial (taxista)
Figura 10.6: Pantalla inicial - taxista
Esta pantalla aparece directamente tras iniciar sesión, o bien tras abrir la aplicación si se
ha iniciado sesión previamente. Consta de los siguientes elementos:
Elementos de la Barra de navegación:
El botón “Cerrar sesión” permite finalizar la sesión
El selector “Mi disponibilidad” permite al taxista indicar su disponibilidad al sistema

de cara a recibir solicitudes de servicio.
En el mapa se visualiza la posición actual del taxi. Esta posición se irá notificando
al sistema en intervalos regulares.
El botón “Ver mi reputación” permite visualizar la reputación del taxista actual

10.7. Pantalla de reputación (taxista)
Figura 10.7: Reputación - taxista
Esta pantalla permite visualizar la reputación actual del taxista, mostrando una media de
todas las valoraciones ası́ como un desglose de las mismas por puntuación.

10.8. Pantalla de solicitud de servicio (taxista)
Figura 10.8: Solicitud - taxista
Esta pantalla aparece tras recibir una notificación del sistema, y permite al taxista aceptar
o rechazar el servicio solicitado. En caso de aceptar, se notificará al cliente y se mos-
trará la pantalla de servicio en curso (descrita a continuación). En caso de rechazar la
solicitud, el sistema asignará el servicio a otro taxista y le notificará para que la acepte o
rechace.

10.9. Pantalla de servicio en curso (taxista)
Figura 10.9: Servicio en curso - taxista
Esta pantalla aparece tras aceptar un servicio. Indica la ubicación del cliente, la distancia
estimada hasta el mismo, e incluye un botón “Cómo llegar” que mostrará una ruta para
llegar a la ubicación del cliente desde la posición actual del taxista.

11 Implementación
A continuación se describen las decisiones tomadas durante la implementación de la

solución propuesta en los puntos anteriores.
11.1. Caracterı́sticas principales
La implementación se ha llevado a cabo teniendo en cuenta las siguientes caracterı́sticas

principales:
11.1.1. Facilidad de uso
11.1.2. Rapidez de respuesta
Las aplicaciones deben responder sin ralentizaciones, dando un feedback al usuario

tras cada acción, para evitar provocar confusión y desconfianza del usuario. Para ello,
y tomando inspiración del comportamiento nativo de iOS, las transiciones se realizan
inmediatamente tras cada acción del usuario, sin esperar a tener los datos necesarios,
para que el usuario tenga una respuesta cuanto antes. Aunque los datos se tengan en
medio segundo, es preferible hacer la transición y luego esperar hasta tenerlos para
mostrarlos, que esperar a tener los datos antes de realizar la transición, lo que podrı́a
hacer pensar al usuario que la aplicación no ha reconocido su acción y vuelva a intentar
pulsar en el botón.
11.1.3. Multiples idiomas
Las aplicaciones móviles utilizan las facilidades proporcionadas por iOS para la presen-
tación de la información en múltiples idiomas. Para ello, todas las cadenas utilizadas en
las aplicaciones se pueden extraer a ficheros de texto fácilmente modificables para cada
idioma que se desee añadir. Ası́ mismo, en caso de que la interfaz no permita fácilmente
la sustitución de cadenas por las de otros idiomas (por ejemplo, las palabras en alemán
suelen ser más largas y quizás no quepan en el espacio disponible), se puede preparar
52
PFC: Taxi! 11. Implementación
una versión de la interfaz, con posiciones y tamaños distintos, para cada idioma que ası́ lo
requiera. De todas formas, la tendencia es a reducir al máximo la necesidad de hacerlo
ası́, aprovechando las facilidades proporcionadas por la tecnologı́a Auto Layout 1 .
Las aplicaciones móviles se han desarrollado en tres idiomas: castellano, catalán e

inglés. El idioma a mostrar lo decide automáticamente el sistema dependiendo del idioma
en que se tenga configurado el dispositivo.
11.1.4. Legibilidad del código fuente
El código fuente se ha desarrollado con el objetivo de ser lo más legible posible, comple-
tando con comentarios en aquellos lugares donde pueda haber alguna confusión.
11.2. Plataforma web
A continuación describiré los procesos empleados en la implementación de la plataforma

web.
Ruby on Rails impone un desarrollo usando el patrón Modelo Vista Controlador. De este
modo, la organización de los ficheros ya viene de forma que es obvio en qué carpeta
tiene que ir cada uno. Los controllers irı́an dentro de /app/controllers, los modelos
dentro de /app/models, las vistas dentro de /app/views y ası́ sucesivamente.
1
http://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/Articles/
adoption.html

Figura 11.1: Árbol de proyecto Rails
La interfaz para la plataforma móvil se ha implementado con 3 controladores:
customer controller: se encarga de la interacción con la aplicación del usuario

final
taxi controller: se encarga de la interacción con la aplicación del taxista, requie-

re autenticación para cada una de las acciones
tokens controller: se encarga del inicio y cierre de sesión por parte de los taxis-
tas, generando los tokens de autenticación correspondientes que se deben utilizar
para interactuar con taxi controller
Para implementar las funcionalidades, se ha utilizado el paradigma BDD (Behaviour-

Driven Development - Desarrollo Dirigido por Comportamiento), utilizando para ello la

herramienta Cucumber. La forma de utilizarlo es como sigue:
1. Antes de escribir ninguna lı́nea de código de la aplicación, se define el compor-

tamiento que se desea que tenga la aplicación para una funcionalidad concreta.
Se hace con un lenguaje llamado Gherkin, que prácticamente es lenguaje natu-
ral con un par de palabras clave. Por ejemplo, para el caso de consultar los taxis
disponibles:
Feature: Show availability

In order to hail a taxi
As a customer
I want to view the available taxis
Scenario: List available taxis

Given there are taxis
When I request the list of available taxis
Then I should only see the available taxis and their positions
2. Al ejecutar la herramienta cucumber, nos indicara que los pasos especificados por
el escenario List available taxis no están definidos. Para ello, hay que crear
un fichero cuyo nombre acabe en steps.rb, y definirlos como con el ejemplo si-
guiente:
When(/^I request the list of available taxis$/) do

header ’Accept’, ’application/json’
get ’/api/v1/available_taxis’
end
En este caso, el contenido de esa función es la especificación de lo que se debe

hacer en cada paso.
3. Al volver a ejecutar la herramienta cucumber, nos indica que la ruta no existe. Por
tanto, hay que añadirla al fichero routes.rb.
4. Al volver a ejecutar la herramienta cucumber, nos indica que el controller no existe,

y una vez creado, indicará que la acción no existe, y ası́ sucesivamente hasta que
pase con éxito este paso.
5. Cuando al ejecutar cucumber ya no dé ningún error, se podrá considerar que la

funcionalidad está implementada.
Obviamente no es necesario ejecutar la herramienta a cada paso (al añadir la ruta tam-
bién podemos añadir la acción en el controller directamente), pero no está de más ha-
cerlo. La idea es implementar el mı́nimo imprescindible para que el test pase.

Especificando de esta forma la aplicación, funcionalidad a funcionalidad, podemos tener

una especificación estricta de la API y un juego de tests, además de saber que no hemos
implementado más código del estrictamente necesario.
Actualmente, la plataforma web cuenta con 29 escenarios, compuestos por 125 pasos,
que definen el comportamiento de la API.
Destacar que los controllers de la API se han creado dentro de la ruta /api/v1/ para, en
el caso de añadir funcionalidad o cambiar algún comportamiento, poder hacerlo en otra
ruta (por ejemplo v2) y ası́ mantener la compatibilidad con las versiones actuales de las
apps cliente.
11.3. Plataforma móvil
Los frameworks de Apple para desarrollar en iOS también incitan a usar el patrón Modelo
Vista Controlador. Aun ası́, no es tan estricto como Rails en ese aspecto.
Debido a la interfaz diseñada para cada una de las apps, la implementación varı́a de una
a otra. El código fuente está en el mismo proyecto, pero se han configurado dos targets
para generar las dos apps.

Figura 11.2: Árbol de proyecto iOS
En la carpeta Lugares de prueba se encuentran ficheros con coordenadas GPS para

simular distintas ubicaciones durante el desarrollo, sin tener que levantarse fı́sicamente
de la mesa.
Se ha utilizado la herramienta CocoaPods2 para gestionar las dependencias con librerı́as

externas. Están definidas en el fichero Podfile. Concretamente, se han usado las si-
guientes librerı́as:
AFNetworking - para comunicación con servicios web y conversiones entre JSON

y NSDictionary.
2
http://cocoapods.org

SVProgressHUD - para mostrar los mensajes de progreso, éxito y error de las ope-
raciones.
LUKeychainAccess - para interactuar con el llavero disponible para cada aplicación

en iOS. En este llavero se pueden almacenar de forma segura los datos que se
deseen; en el caso de las apps, se almacena el identificador para notificaciones y
el token de autenticación en el caso del taxista.
FlatUIKit - para modificar el aspecto visual de los controles estándares de iOS.
11.3.1. App Taxista
Los controllers se encuentran en la carpeta Taxi Controllers. Los modelos que utilizan
están dentro de la carpeta Models, y las vistas especı́ficas para la aplicación (el resto son
las genéricas del sistema) están en la carpeta UI Classes.
En la carpeta Network APIse encuentra la interfaz con la API del servidor, en la clase
TaxiAPIClient, y un singleton para la interacción con la API del sistema de localización,
en la clase TaxiLocationDelegate.
En este caso, se configura la API de localización (con la clase CLLocationManager) con

la máxima precisión, y se establece un filtro de 10 metros para recibir actualizaciones de
posición que superen esa distancia respecto a la anterior posición. Además, se indica al
sistema que la aplicación se debe ejecutar en segundo plano por necesitar de los ser-
vicios de localización (en el archivo de configuración Info.plist, UIBackgroundModes
contiene la cadena location). Esto no es ası́ en la app para el cliente, pues únicamente
se necesita acceder a la posición del usuario en el momento de solicitar un taxi. En el
caso del taxista, se utiliza este modo para actualizar la posición en tiempo real, de cara
a poder tomar decisiones con datos recientes y, además, informar a los usuarios de la
posición del taxi. Aunque estos ajustes tienen un impacto serio en el consumo de baterı́a
del dispositivo, considero que, al tratarse de una aplicación para un taxista, puede tener
el teléfono cargando en el taxi. Además, si usa alguna aplicación de navegación como
TomTom o la incluida en la app de mapas del sistema, el impacto en la duración de la
baterı́a por parte de la app de taxista es despreciable.
La relación entre view controllers, transiciones y las vistas de cada uno se definen en el
fichero TaxiStoryboard. A continuación se muestra una captura de pantalla del conte-
nido de dicho fichero, que define la interacción de la interfaz de usuario de la aplicación
del taxista.

Figura 11.3: Storyboard de Taxista
11.3.2. App Cliente
En este caso, debido al diseño de la interacción con el usuario, el storyboard correspon-

diente sólo hace referencia a un view controller, que muestra y oculta secciones de la
interfaz dependiendo del estado en el que se encuentre.

Figura 11.4: Storyboard de Cliente
En este caso también se utilizan los mismos modelos y clases de interacción con la
API.

12 Funcionamiento de la aplicación
A continuación se mostrarán capturas exhaustivas de la ejecución de ambas aplicaciones

móviles, organizadas por funcionalidad.
12.1. Cliente
Al pulsar sobre el icono, la aplicación arranca, y tras mostrarse brevemente la pantalla

de splash aparece la pantalla principal, con botones para centrar el mapa en la ubicación
del usuario, ver taxis disponibles y pedir un taxi.
Figura 12.1: App Cliente: icono, splash y pantalla principal
12.1.1. Centrar mapa en usuario
Al pulsar en el con el icono con forma de flecha, se activa el modo de seguimiento del
mapa, lo que hace que se centre en la posición del usuario y se acerque hasta ver
la zona alrededor del usuario con más detalle. Mientras el botón esté activo, el mapa
seguirá automáticamente al usuario, por lo que siempre estará centrado en la posición
del usuario. Además de pulsando sobre el botón de nuevo, también se desactiva este
modo al realizar un desplazamiento en el mapa manualmente.
61
PFC: Taxi! 12. Funcionamiento de la aplicación
Figura 12.2: App Cliente: centrar mapa en usuario
12.1.2. Consulta disponibilidad
Al pulsar en el botón con el texto “Ver taxis”, se muestran en el mapa los taxis disponibles
en ese momento, con un icono para cada uno. El mapa se acerca o aleja automática-
mente de forma que queden visibles todos los taxis, además de la posición del usuario.
Al pulsar sobre uno de los taxis, se muestra su identificador.

Figura 12.3: App Cliente: ver taxis disponibles
12.1.3. Solicitud /reserva de taxi
Al pulsar en el botón con el texto “Pedir taxis”, se muestra un panel con las opciones para
solicitar un taxi. Permite seleccionar si se desea solicitar el taxi para ahora, o reservarlo
para que la recogida sea dentro de una hora o dos horas. Además, aparece un pin en la
posición del usuario (mostrando el texto “aquı́” y la dirección de dicho punto), que será la
posición que se indique al sistema para la solicitud. Este pin se puede mover haciendo
una pulsación larga sobre el mismo y arrastrándolo a la ubicación deseada. Al pulsar en
el botón “pedir” se confirma la solicitud.
Figura 12.4: App Cliente: solicitar taxi

12.1.4. Servicio en curso
Cuando el taxista asignado al servicio lo acepta, se envı́a una notificación push al usuario
para indicarle este hecho. La notificación se muestra de forma distinta dependiendo de
si la aplicación se encuentra abierta o cerrada en el momento de recibirla.
Figura 12.5: App Cliente: notificación taxi en camino, con la app cerrada y abierta
Cuando el taxi asignado se encuentra en camino para realizar la recogida, la pantalla de

la aplicación muestra un icono con la posición del taxi y un pin con la posición indicada
para la recogida. También se muestra la distancia a la que se encuentra el taxi.

Figura 12.6: App Cliente: taxi en camino
Cuando el taxi se aproxima a la posición de la recogida, se envı́a una notificación push

al usuario para indicarle este hecho. La notificación se muestra de forma distinta depen-
diendo de si la aplicación se encuentra abierta o cerrada en el momento de recibirla. El
umbral que determina el momento de avisar al usuario es de 200 metros.
Figura 12.7: App Cliente: notificación taxi llegando, con la app cerrada y abierta

El servicio solicitado por el usuario pasa del estado “pendiente” a “taxista en camino”
en el momento de la aceptación, y de “taxista en camino” a “trayecto en curso” en el
momento de la recogida.
Figura 12.8: App Cliente: estados de un servicio - pendiente, taxista en camino, iniciado
12.1.5. Puntuar último servicio
Cuando el trayecto se completa, el taxista indica la finalización del servicio. En ese mo-
mento se envı́a una notificación push al usuario para indicarle este hecho, y que puede
valorar si ası́ lo desea el servicio recién concluido. La notificación se muestra de forma
distinta dependiendo de si la aplicación se encuentra abierta o cerrada en el momento
de recibirla.

Figura 12.9: App Cliente: notificación finalización servicio, con la app cerrada y abierta
Cuando hay un servicio pendiente de puntuar, se muestra un botón con un icono con
forma de estrella en la parte superior derecha de la pantalla principal. Al pulsar sobre
el mismo, aparece un panel con cinco estrellas, sobre las que se puede pulsar para
establecer la puntuación que se desea dar al servicio. Una vez hecho esto, al pulsar
en el botón “puntuar” se registra esta puntuación en el sistema y el icono de puntuar
desaparece.
Figura 12.10: App Cliente: puntuar último servicio

12.2. Taxista
Al pulsar sobre el icono, la aplicación arranca, y tras mostrarse brevemente la pantalla

de splash aparece la pantalla de inicio de sesión, si no hay ninguna sesión iniciada pre-
viamente. En caso de haber una sesión ya iniciada, se muestra directamente la pantalla
principal.
Figura 12.11: App Taxista: icono, splash y pantalla de login
12.2.1. Inicio sesión
Para iniciar la sesión basta con introducir el usuario y la contraseña en los campos indi-
cados. Si alguno de los datos no es correcto, se muestra un mensaje de error.
Figura 12.12: App Taxista: iniciar sesión con error
En caso de que todo sea correcto, se muestra un mensaje de bienvenida y se presenta

la pantalla principal.

Figura 12.13: App Taxista: iniciar sesión con éxito
12.2.2. Actualización disponibilidad y posición
Desde la pantalla principal se muestra la disponibilidad actual del taxi. Pulsando sobre
los botones “disponible” y “ocupado” se cambia la disponibilidad del taxi en el servidor,
de cara a recibir potenciales asignaciones de servicio. En el mapa se muestra la posición
actual del taxi, que se notificará al servidor a medida que se detecte que ha cambiado.
Si se indica que el taxi no está disponible, se deja de actualizar la posición en el servi-
dor.
Figura 12.14: App Taxista: actualizar disponibilidad
12.2.3. Aceptar o rechazar asignación
Cuando hay una nueva solicitud de servicio y el sistema lo asigna a un taxista, se envı́a
una notificación push al taxista para indicarle este hecho. La notificación se muestra

de forma distinta dependiendo de si la aplicación se encuentra abierta o cerrada en el

momento de recibirla.
Figura 12.15: App Taxista: notificación nuevo servicio asignado, con la app cerrada y
abierta
En la pantalla de solicitud se muestra la dirección en la que se encuentra el cliente,

la distancia a la que está, y se muestran en el mapa las posiciones del cliente y del
taxi. Si se pulsa en el botón “rechazar” el sistema seleccionará otro taxi disponible y le
asignará el servicio, hasta que uno lo acepte.

Figura 12.16: App Taxista: rechazar servicio
Cuando se pulsa en el botón “aceptar”, se notifica al cliente y se muestra la pantalla de

servicio en curso.
Figura 12.17: App Taxista: aceptar servicio

12.2.4. Cómo llegar a cliente e inicio de servicio
La pantalla de servicio en curso muestra los mismos datos que la de nueva solicitud:
dirección donde se encuentra el cliente, distancia al mismo, y un mapa con la posición
del cliente y el taxi. El botón “cómo llegar” abre la aplicación nativa de mapas de iOS
en modo navegación con una ruta desde la posición actual del taxi hasta la posición del
cliente.
Figura 12.18: App Taxista: cómo llegar
12.2.5. Fin de servicio
Una vez se ha iniciado el servicio, el botón “como llegar” desaparece y en su lugar se

muestra otro con el texto “finalizar”, para indicar que se ha completado el servicio. En el
momento de hacerlo, se notifica al cliente para que indique su valoración del servicio si
ası́ lo desea, y se muestra de nuevo la pantalla principal, cambiando el estado del taxi a
“disponible”.
Figura 12.19: App Taxista: finalizar servicio

12.2.6. Reputación
Desde la pantalla principal, pulsando en el botón “ver reputación” se muestra una pantalla
con una media de las puntuaciones recibidas, y un desglose del número de valoraciones
recibidas para cada puntuación.
Figura 12.20: App Taxista: ver reputación
12.2.7. Cierre sesión
Desde la pantalla principal, pulsando en el botón “cerrar sesión” se procede a la des-

conexión del sistema, se desactiva la recepción de notificaciones push, y se muestra
la pantalla de inicio de sesión. Las notificaciones push se volverán a activar cuando se
inicie sesión de nuevo.

Figura 12.21: App Taxista: cerrar sesión

13 Conclusiones
Los riesgos descritos en los primeros capı́tulos han estado muy presentes durante el
desarrollo del proyecto. Las previsiones indicadas en el cronograma se han cumplido,
gracias a haber incluido márgenes de seguridad para eventualidades. De este modo, el
completar algunas tareas en menos tiempo del estimado ha permitido que otras tareas
se pudiesen alargar sin tener que recurrir a disminuir el alcance del proyecto para poder
completarlo dentro del plazo.
13.1. Cumplimiento de los objetivos propuestos
Tal y como se menciona en el capı́tulo introductorio, el núcleo del proyecto se resume en

una simple frase.
Quiero un taxi aquı́ y ahora
El objetivo principal se ha conseguido ampliamente, ofreciendo una interfaz sumamente

sencilla y fácil de utilizar para cualquiera, de forma que pedir un taxi sin necesitar de
saber el nombre de la calle donde nos encontremos se ha simplificado al máximo.
Ası́ mismo, en lo que respecta a la aplicación para el taxista, también se ha conseguido

una interfaz sencilla y cómoda, limitando al máximo la interacción necesaria. De hecho,
el único momento en el que se muestra el teclado del dispositivo es a la hora de introducir
el usuario y contraseña.
También se ha dado mucha importancia al rendimiento de las aplicaciones, ya que pro-

blemas en ese aspecto serı́an muy contraproducentes. Aprovechando la infraestructura
proporcionada por el sistema, como las notificaciones, se consigue una integración ópti-
ma con el resto de aplicaciones instaladas, lo que permite al usuario estar avisado del
estado de su solicitud sin que tenga que consultar la aplicación constantemente.
75
PFC: Taxi! 13. Conclusiones
13.2. Valoración personal
Desde el principio me planteé la realización del proyecto como una oportunidad para
explorar áreas que desconocı́a, con ánimo de mejora personal, en lugar de recurrir a lo
conocido o habitual.
Tengo algunos años de experiencia en Ruby on Rails, pero no habı́a utilizado nunca
Cucumber para definir las especificaciones y el comportamiento deseado antes de es-
cribir una lı́nea de código (BDD – Behaviour-Driven Development, Desarrollo Dirigido por
Comportamiento1 ). Los resultados han sido más que satisfactorios y estoy convencido
que seguiré utilizando este paradigma en el futuro.
Ası́ mismo, habı́a desarrollado aplicaciones nativas en iOS con las versiones 3 y 4, pero
nunca habı́a hecho nada con las mejoras tanto en las API como en el lenguaje introduci-
das a partir de iOS 5 como ARC (Automatic Reference Counting)2 o Storyboards3 , que
han resultado reveladoras, pues permiten un desarrollo mucho más rápido y ágil que en
versiones anteriores, escribiendo mucho menos código y menos propenso a bugs.
Como resumen, la experiencia ha sido extremadamente satisfactoria.
13.3. Futuras mejoras
Entre las posibles mejoras que se podrı́an desarrollar en futuras versiones se pueden
encontrar:
Posibilidad de asignar manualmente los taxis a las solicitudes y reservas desde la

interfaz de administración web.
Aumentar la seguridad en la comunicación entre el servidor y las apps. Esto tiene

varias vertientes:
• Utilizar un servidor SSL para que la comunicación con el servidor sea median-
te HTTPS. De este modo la comunicación va encriptada desde el principio.
• Para el caso del taxista autenticado, no pasar el token de autenticación me-

diante parámetro GET o POST en las llamadas HTTP, sino enviarlo en un
header de la llamada HTTP.
1
http://en.wikipedia.org/wiki/Behavior-driven development
2
https://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/
Introduction.html
3
https://developer.apple.com/library/ios/documentation/General/Conceptual/Devpedia-CocoaApp/
Storyboard.html

PFC: Taxi! 13. Conclusiones
• Para evitar comunicaciones con aplicaciones no autorizadas, autenticar a las

aplicaciones mediante API tokens, que se podrı́an generar en el servidor y
que deberı́an utilizar en todas las comunicaciones.
Generar informes y estadı́sticas desde la interfaz de administración web.
Aumentar los rangos de horas disponibles para realizar una reserva.
Permitir a un usuario hacer más de una reserva simultáneamente. Un ejemplo

podrı́a ser hacer una reserva para ir a algún sitio (por ejemplo, el cine) y otra para
volver un par de horas más tarde.
Permitir a un usuario cancelar una reserva aún no asignada.
Permitir a un usuario indicar el destino además del lugar de recogida.
Posibilidad de asignar un servicio a un taxista que actualmente esté realizando uno,

pero que finalice cerca del lugar de recogida del nuevo servicio. Esto permitirı́a una
mejor optimización de los recursos, pero necesitarı́a de información adicional para
poder tomar esas decisiones – entre otras cosas, se necesitarı́a saber el destino
del servicio en curso (lo podrı́a introducir el taxista cuando el cliente se lo indique,
y ası́ poder obtener una ruta de navegación, o bien lo podrı́a indicar el cliente como
en el punto anterior), y se necesitarı́a también una hora estimada de llegada.
Mejorar el método de cálculo de distancia entre el cliente y el taxista. Dadas las li-
mitaciones de tiempo existentes, la distancia euclı́dea ofrecı́a un compromiso ideal
entre practicidad y tiempo de desarrollo; de hecho, debido a su simplicidad, es muy
buena opción para determinar el taxi a asignar (evitando costosas llamadas a APIs
que devuelvan un resultado más exacto), y en esos casos la diferencia respecto
a la distancia real se puede despreciar. No obstante, no es muy práctica para in-
formar al taxista o al cliente, pues no deja de ser la distancia en lı́nea recta entre
dos puntos, sin tener en cuenta accidentes geográficos ni el trayecto que siguen
las carreteras. En este caso serı́a más práctico de cara a ofrecer una información
más fiable obtener esta distancia mediante una API que proporcione además una
estimación del tiempo de llegada teniendo en cuenta el tráfico o la ruta más óptima.
Versión para iPad. Quizás para la versión del cliente pueda ser superflua, de ahı́ que
no se considerase en un principio, pero a medida que ha transcurrido el desarrollo
he podido observar que la aplicación para el taxista se podrı́a beneficiar del mayor
espacio disponible en una tableta para ofrecer una interfaz aún más optimizada y
práctica, especialmente teniendo en cuenta que se podrı́a utilizar un soporte para
tenerlo visible en la consola central del coche.

14 Fuentes de información
14.1. Bibliografı́a
Drance, Matt; Warren, Paul. (2011). iOS Recipes. Estados Unidos: The Pragmatic
Programmers, LLC
Valim, José. (2011). Crafting Rails Applications. Estados Unidos: The Pragmatic
Programmers, LLC
Adamson, Chris; Dudney, Bill. (2012). iOS SDK Development. Estados Unidos: The
Pragmatic Programmers, LLC
Wynne, Matt; Hellesøy, Aslak. (2012). The Cucumber Book. Estados Unidos: The
Pragmatic Programmers, LLC
Dees, Ian; Wynne, Matt; Hellesøy, Aslak. (2013). Cucumber Recipes. Estados Uni-
dos: The Pragmatic Programmers, LLC
Ruby, Sam; Thomas, Dave; Heinemeier Hansson, David. (2013). Agile Web Deve-
lopment with Rails. Estados Unidos: The Pragmatic Programmers, LLC
Thomas, Dave. (2013). Programming Ruby 1.9 & 2.0. Estados Unidos: The Prag-
matic Programmers, LLC
14.2. Recursos web
Comunes a ambas plataformas
• Stack Overflow. http://stackoverflow.com1
iOS
• Apple Developer Connection. WWDC 2011 & 2012: Videos. https://developer.apple.com/

videos/2
1
http://stackoverflow.com
2
https://developer.apple.com/videos/
78
PFC: Taxi! 14. Fuentes de información
• iDeveloper TV. iOS Development. http://ideveloper.tv3
• Stanford on iTunesU. CS193P - iPad and iPhone Application Development.

http://cs193p.stanford.edu4
• Apple Developer Connection. iOS Developer Library. https://developer.apple.com/

library/ios/navigation/5
Ruby on Rails
• Railscasts. http://railscasts.com6
• Ruby on Rails Guides. http://guides.rubyonrails.org7
3
http://ideveloper.tv
4
http://cs193p.stanford.edu
5
https://developer.apple.com/library/ios/navigation/
6
http://railscasts.com
7
http://guides.rubyonrails.org


Proyecto Taxi Programacion Java

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Proyecto Taxi Programacion Java

Caricato da

Copyright:

Formati disponibili

Ta x i !

Memoria del proyecto

Fecha: 10 Junio 2013

3. Definición General del Proyecto 2

4. Calendario del Proyecto 4

7. Riesgos del Proyecto 16

12. Funcionamiento de la aplicación 61

14. Fuentes de información 78

8.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

9.1. Arquitectura cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

10.1.Pantalla inicial - cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

11.1. Árbol de proyecto Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

12.1.App Cliente: icono, splash y pantalla principal . . . . . . . . . . . . . . . . . 61

Quiero un taxi aquı́ y ahora

alguien a quien pedir el taxi

un taxi que pueda acudir a prestar el servicio

Se pretende desarrollar una aplicación en la que prime la facilidad de uso y la eficien-

Toda funcionalidad que se añada se analizará detalladamente para que su implementa-

3.2. Funcionalidades Principales

Mostrar disponibilidad: permitir a un usuario consultar un mapa en tiempo real de

Está llegando: notificar a un usuario de la cercanı́a de la llegada del taxi

Identificación de usuario: permitir a un taxista identificarse en el sistema

Indicar disponibilidad: permitir a un taxista indicar su disponibilidad y su posición

Aceptar servicio: permitir a un taxista aceptar o rechazar un servicio solicitado por

Valoraciones: permitir a un usuario introducir una reseña y puntuación tras haber

Mi reputación: permitir a un taxista ver un resumen de sus valoraciones

Estas valoraciones se podrı́an mostrar en el mapa de disponibilidad, pero dado que es

La app necesitarı́a de un servidor para centralizar la comunicación entre taxista y cliente.

Autor: Antonio Rogel Barreiro 3

Debido a la naturaleza de los entregables a realizar en cada fecha especificada, se uti-

4.1. Entregas definidas

Fecha de entrega Hito evaluación continua Entregable

Autor: Antonio Rogel Barreiro 5

4.3. Detalle entrega de la PAC1

Id tarea Nombre de la tarea Descripción de la tarea

4.4. Detalle entrega de la PAC2

Autor: Antonio Rogel Barreiro 6

Id Nombre de la tarea Descripción de la tarea

Autor: Antonio Rogel Barreiro 7

Id Nombre de la tarea Descripción de la tarea

4.5. Detalle entrega de la PAC3

Autor: Antonio Rogel Barreiro 8

Id Nombre de la tarea Descripción de la tarea

Autor: Antonio Rogel Barreiro 9

Id Nombre de la tarea Descripción de la tarea

4.6. Detalle Entrega Final

Autor: Antonio Rogel Barreiro 10

Id tarea Nombre de la tarea Descripción de la tarea

Autor: Antonio Rogel Barreiro 11

Para el desarrollo del proyecto se utilizarán los recursos definidos a continuación.

Servidor web: Para pruebas en local se utilizará el mismo ordenador de desarrollo;

Teléfono móvil para pruebas: iPhone 4S con iOS 6.1.3

5.1. Software para Desarrollo

Se detalla a continuación el software que se utilizará durante el desarrollo:

5.2. Software en el Servidor

Por lo que respecta al software necesario en el servidor, constarı́a de los siguientes

Autor: Antonio Rogel Barreiro 13

Las tecnologı́as implicadas en cada caso se detallan a continuación.

La aplicación móvil se desarrollará en Objective-C utilizando el framework Cocoa Touch

La comunicación entre el dispositivo móvil y la plataforma web se realizará utilizando

Autor: Antonio Rogel Barreiro 15

Riesgo Descripción Proba- Im- Acciones mitigadoras

Riesgo Descripción Proba- Im- Acciones mitigadoras