aplicación web para la gestión de viajes en vehículo ... · diseÑo de la base de datos ... no...

Guillermo Pérez Ledesma

Aplicación web para la gestión de viajes en vehículo compartido

Beatriz Pérez Valle

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Proyecto Fin de Carrera

Matemáticas y Computación

2012-2013

Título

Autor/es

Director/es

Facultad

Titulación

Departamento

PROYECTO FIN DE CARRERA

Curso Académico

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013

publicaciones.unirioja.esE-mail: [email protected]

Aplicación web para la gestión de viajes en vehículo compartido, proyecto fin decarrera

de Guillermo Pérez Ledesma, dirigido por Beatriz Pérez Valle (publicado por la Universidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

TITULACIÓN: Ingeniería Técnica en Informática de Gestión TÍTULO: Aplicación Web para la gestión de viajes en vehículo compartido DIRECTOR/ES DEL PROYECTO: Beatriz Pérez Valle DEPARTAMENTO: Matemáticas y Computación ALUMNO/S: Guillermo Pérez Ledesma CURSO ACADÉMICO: 2012/2013

Facultad de ciencias, estudios agroalimentarios e informática

2

Índice

1. DOCUMENTO DE OBJETIVOS DEL PROYECTO (D.O.P) .............................................................4

1.1 ANTECEDENTES Y DESCRIPCIÓN DEL PROYECTO....................................................................................4 1.2. OBJETIVOS DEL PROYECTO ...................................................................................................................7 1.3. ALCANCE DEL PROYECTO .....................................................................................................................7 1.4. PARTICIPANTES DEL PROYECTO Y COMUNICACIÓN ...............................................................................9 1.5. ENTREGABLES ....................................................................................................................................10 1.6. TECNOLOGÍAS A UTILIZAR ..................................................................................................................10 1.7. DOCUMENTACIÓN NECESARIA ............................................................................................................10 1.8. METODOLOGÍA ...................................................................................................................................11 1.9. PLANIFICACIÓN DEL PROYECTO..........................................................................................................11 1.10. CALENDARIO ....................................................................................................................................13 1.11. RIESGOS Y PLANES DE ACCIÓN..........................................................................................................13

2. ANÁLISIS ................................................................................................................................................14

2.1. INTRODUCCIÓN...................................................................................................................................14 2.2. REQUISITOS DEL SISTEMA...................................................................................................................14

2.2.1 Usuario Visitante............................................................................................................................... 14 2.2.2 Usuario Básico .................................................................................................................................. 14 2.2.3 Usuario Facebook ............................................................................................................................. 16

2.3. ESPECIFICACIÓN DE CASOS DE USO.....................................................................................................16 2.3.1 Casos de uso relacionados con el usuario Visitante .......................................................................... 16 2.3.2 Casos de uso relacionados con el usuario Básico.............................................................................. 17 2.3.3 Casos de uso relacionados con el usuario Facebook ......................................................................... 38

2.4. DIAGRAMA DE CLASES........................................................................................................................39 2.4.1 Usuario.............................................................................................................................................. 40 2.4.2 Usuario_facebook ............................................................................................................................. 40 2.4.3 Viaje.................................................................................................................................................. 41 2.4.4 Comentario........................................................................................................................................ 41 2.4.5 Mensaje............................................................................................................................................. 41 2.4.6 Vehículo............................................................................................................................................ 41 2.4.7 Puntuación......................................................................................................................................... 42 2.4.8 Dirección_de_ruta............................................................................................................................. 42

3. DISEÑO....................................................................................................................................................43

3.1. INTRODUCCIÓN...................................................................................................................................43 3.2. DISEÑO DE LA BASE DE DATOS............................................................................................................43

3.2.1 Modelo entidad – relación................................................................................................................. 43 3.2.2 Modelo relacional ............................................................................................................................. 48

3.3. INTERFACES........................................................................................................................................51 3.3.1 Interfaces del usuario Visitante ......................................................................................................... 51 3.3.2 Interfaces del usuario Básico............................................................................................................. 53 3.3.3 Interfaces del usuario Facebook........................................................................................................ 74

3.4. ARQUITECTURA DE LA APLICACIÓN....................................................................................................77 3.4.1 Capa de presentación......................................................................................................................... 77 3.4.2 Capa de lógica de negocio................................................................................................................. 77 3.4.3 Capa de persistencia.......................................................................................................................... 79

3

4. IMPLEMENTACIÓN.............................................................................................................................80

4.1 INTRODUCCIÓN....................................................................................................................................80 4.2 MÉTODOS Y FUNCIONALIDADES MÁS INTERESANTES...........................................................................80

4.2.1 Conexión con la base de datos .......................................................................................................... 80 4.2.2 Validación de los campos de los formularios. ................................................................................... 81 4.2.3 Cambio de estado de un viaje............................................................................................................ 83 4.2.4 Eliminar usuario................................................................................................................................ 84 4.2.5 Añadir vehículo................................................................................................................................. 86 4.2.6 Añadir y confirmar direcciones de ruta ............................................................................................. 87 4.2.7 Mostrar diferentes opciones dependiendo del estado del viaje y del rol del usuario. ........................ 88 4.2.8 Puntuar a compañeros de viaje.......................................................................................................... 88 4.2.9 Buscar Viaje...................................................................................................................................... 90 4.2.10 Integración de Google Maps en la aplicación ................................................................................. 91 4.2.11 Cálculo del coste aproximado del viaje........................................................................................... 96 4.2.12 Integración de Facebook en la aplicación........................................................................................ 97

5. PRUEBAS ..............................................................................................................................................106

6. GESTIÓN DEL PROYECTO ..............................................................................................................111

7. CONCLUSIONES .................................................................................................................................113

8. BIBLIOGRAFÍA...................................................................................................................................114

4

1. Documento de objetivos del Proyecto (D.O.P)

1.1 Antecedentes y descripción del proyecto El proyecto que vamos a desarrollar implementará una aplicación Web llamada subeketellevo.com que gestionará de forma intuitiva y eficiente la organización de viajes con un vehículo compartido. Utilizando nuestra aplicación, tanto conductores como pasajeros obtendrán ventajas, entre las que podemos encontrar:

El conductor podrá compartir los gastos del viaje.

Los pasajeros podrán realizar viajes, en muchos casos, a un coste muy inferior al ofertado por el transporte público, o al que conllevaría utilizar su propio coche.

Los pasajeros podrán acordar con el conductor el traslado al lugar exacto al que se dirigen, evitando realizar transbordos o recorridos a pie, como sucede con el transporte público.

Actualmente, existen numerosas aplicaciones Web que tratan la gestión de viajes en vehículo compartido. Detrás del auge que han experimentado este tipo de aplicaciones, se encuentran las razones económicas ya que los gastos del viaje son compartidos por los integrantes del mismo. También han influido razones de tipo medioambiental y es que al agrupar varios pasajeros en el mismo vehículo, se favorece el consumo responsable de combustible y se evita la masificación de coches en las carreteras. Desde los gobiernos también se ha favorecido la utilización de vehículos por más de un ocupante. La legislación de nuestro país recoge la existencia de carriles para vehículos de alta ocupación en los que se prohíbe o se penaliza la circulación a vehículos utilizados por una única persona. Nuestro proyecto abordará como primera tarea, el análisis de las aplicaciones existentes que tratan de resolver el mismo problema que el propuesto y extraer las funcionalidades que nos parezcan más útiles de dichas aplicaciones. También ser pretende añadir a nuestra aplicación Web características que no se han encontrado en ninguna de las aplicaciones existentes. De esta forma, nuestra aplicación agrupará las características más ventajosas que se han considerado de entre las aplicaciones ya existentes y se añadirán funcionalidades adicionales, obteniendo un valor añadido. En primer lugar, la aplicación permitirá que los usuarios identifiquen a los amigos y conocidos que estén registrados en la misma y puedan organizar viajes con ellos. La aplicación, al igual que las que operan actualmente en Internet, permitirá la organización de viajes con desconocidos. Además, se pretende que la aplicación vaya más allá y ofrezca la posibilidad de relacionarnos con nuestros amigos y controlar los viajes que éstos inscriban dentro de subeketellevo.com. Por otra parte, si los usuarios de nuestra Web tienen una cuenta de Facebook y en ella ya tienen una serie de relaciones sociales, ¿por qué no aprovecharnos de esa información? Teniendo ésto en cuenta, la segunda gran innovación de nuestra aplicación será mantener una comunicación con la cuenta de Facebook de nuestros usuarios. De esta forma se podrán utilizar sus datos personales y sus relaciones de amistad dentro de la aplicación. A continuación pasaremos a enumerar algunas de las aplicaciones relacionadas con la organización de viajes en vehículo compartido que actualmente operan en Internet. De cada una de ellas expondremos los puntos fuertes y débiles que hemos observado.

5

Blablacar.es [1]

Es el líder europeo en las webs que ofrecen este tipo de servicios. Puntos fuertes

La interfaz visual que ofrece es realmente atractiva. Permite una correcta visualización en dispositivos móviles.

Ofrece la posibilidad de poder acceder a la aplicación mediante las credenciales de Facebook del usuario.

Permite organizar viajes a eventos concretos y a campus universitarios.

Permite ofrecer viajes como conductor o como pasajero.

Posee un calculador del precio del viaje en función del coche que se utilicen y del número de kilómetros que se vayan a recorrer.

Ofrece la posibilidad de informar al pasajero de si puede fumar durante el trayecto o si pueden transportar animales.

Puntos débiles

No nos permite buscar ni ver los viajes de los amigos de Facebook de los usuarios.

No permite crear un grupo de amigos dentro de la aplicación.

La valoración de los viajes se realiza a nivel general, mediante una escala de 0 a 5, por lo que no permite realizar una valoración ponderada en función de varios criterios.

No permite proponer direcciones de paso al trayecto del viaje ofrecido por el conductor.

No ofrece la posibilidad de ver en un mapa el recorrido ofertado.

Conduzco.es[2]

Según los creadores de la aplicación, ayuda a realizar viajes a más de 1 millón de personas al mes en toda Europa. Puntos fuertes

Permite acceder a la aplicación mediante las credenciales de Facebook

Ofrece un precio recomendado para el trayecto que ofertamos.

Permite que el pago del trayecto se realice, o bien en mano al comenzar el viaje o mediante la plataforma de pago PayPal.

Al dar de alta un viaje, se publica automáticamente un mensaje en el muro de Facebook, anunciando la oferta que se ha publicado.

Permite sugerir a los amigos de los usuarios que se registren en la aplicación, enviándoles un correo predefinido.

6

Existe la figura de usuarios de confianza. Se puede declarar a cualquier usuario de la aplicación como usuario de confianza y de este modo ver los viajes que oferta y comunicarse con él.

Permite ver el recorrido de un viaje en un mapa Puntos débiles

El aspecto visual no es muy profesional.

No permite ofrecer viajes únicamente a nuestros amigos.

No permite proponer localidades de paso alternativas a las ofertadas.

No podemos crear viajes asociados a un evento, como puede ser un concierto o un festival.

No nos permite buscar ni ver los viajes de los amigos de Facebook de los usuarios.

La gestión de los amigos representados por los usuarios de confianza no se hace de manera natural, ya que se tiene que acceder a ver el perfil del usuario para ver los usuarios de confianza.

No se puede realizar una búsqueda de los viajes ofertados por los usuarios de confianza.

Amovens.com[3]

Se trata de una aplicación con un aspecto visual muy conseguido y que entre sus servicios ofrece soluciones avanzadas para instituciones o empresas. Puntos fuertes

Permite acceder a la aplicación mediante nuestras credenciales de Facebook.

Ofrece soluciones avanzadas y personalizadas a empresas y universidades.

Tiene un aspecto visual muy atractivo.

Permite ver el recorrido del viaje en un mapa. Puntos débiles

No permite ningún tipo de relación entre los usuarios, ni siquiera el envío de mensajes. Únicamente permite realizar preguntas acerca de los trayectos ofertados y se contesta por mail, no dentro de la propia aplicación.

No se pueden proponer localidades de paso alternativas al trayecto ofertado.

No permite buscar viajes entre nuestros amigos de Facebook.

No cuenta con un calculador de tarifas que nos ofrezca de forma aproximada el precio del viaje.

7

Viajamosjuntos.com[4]

Se trata de una aplicación desarrollada en 2004 y es la más simple de todas las expuestas anteriormente. No es tan atractiva visualmente como las anteriores, pero cuenta con funcionalidades interesantes. Puntos fuertes

Permite publicar viajes como conductor o como pasajero.

Posee una calculadora que permite estimar el precio del trayecto ofertado. Puntos débiles

No tiene conexión alguna con Facebook ni ninguna otra red social similar.

El aspecto visual es pobre y desfasado.

No permite comunicación alguna entre los usuarios.

No existe la figura de amigo entre usuarios.

No permite ofrecer alternativas a un trayecto.

No ofrece un mapa que nos informe de la ruta aproximada que el viaje va a seguir.

1.2. Objetivos del proyecto El objetivo principal del proyecto es desarrollar una solución Web que gestione de forma automática la utilización de forma compartida de vehículos para realizar trayectos comunes. De este modo, facilitaremos al usuario la búsqueda de viajeros que compartan los gastos derivados de un viaje que desea realizar o, si es el caso, buscar algún conductor que acepte llevarle. Nuestro sistema tendrá la posibilidad de aprovechar los datos personales y las relaciones de amistad que el usuario tenga almacenadas en su cuenta de la red social Facebook. Esta característica permitirá organizar de una forma sencilla viajes compartidos con nuestros amigos y conocidos, fomentando el uso compartido de vehículos.

1.3. Alcance del proyecto Nuestra aplicación Web tendrá dos vías de acceso. Por un lado, podremos registrarnos mediante un formulario de registro tradicional y obtener un nombre de usuario y una contraseña para acceder a la aplicación. Por otro, podremos acceder utilizando nuestras credenciales de acceso a nuestra cuenta de Facebook. Elijamos el método de registro que elijamos, el funcionamiento de la aplicación será idéntico, salvo que en el caso de acceder con nuestra cuenta Facebook, contaremos con funcionalidades adicionales fruto de la comunicación que se establecerá con el sistema Facebook. Hemos decidido ofrecer dos métodos de registro dado que si únicamente ofertásemos la aplicación a usuarios de Facebook perderíamos todos los potenciales usuarios que no pertenezcan a esta red social. Haciéndolo así, permitimos que cualquier usuario de Internet pueda utilizar nuestro servicio. Nuestra aplicación cuenta con 3 tipos de usuarios:

Usuario Visitante Usuario Básico Usuario Facebook

8

A continuación pasamos a describir cada uno de los usuarios que hemos identificado, junto con las funcionalidades disponibles de cada uno:

Usuario Visitante Es un usuario que trata de acceder a nuestra aplicación sin haberse registrado previamente. Este usuario únicamente tendrá acceso a la portada de nuestra aplicación en la que se le ofrecerá la posibilidad de registrarse, de acceder a la aplicación como usuario básico o de acceder con su cuenta Facebook.

Usuario básico Es un usuario que se ha registrado en la aplicación mediante el formulario de registro tradicional. Entre las funciones que tiene un usuario básico, podemos citar:

Identificarse y acceder a la aplicación. Darse de baja de la aplicación. Ver su perfil y determinados datos públicos del perfil del resto de usuarios. Modificar los datos de su perfil de usuario. Añadir o eliminar algún vehículo a su perfil. Modificar alguna característica de alguno de sus vehículos. Añadir, solicitar o rechazar relaciones de amistad con otros usuarios. Esta acción

generará una alerta para que el usuario receptor de la solicitud de amistad pueda aceptar o rechazar.

Enviar mensajes a cualquier usuario de la aplicación. Al enviar un mensaje, el usuario receptor del mismo recibirá una alerta informándole de que tiene mensajes sin leer.

Ver y eliminar los mensajes recibidos. Buscar usuarios. Listar a sus amigos. Dar de alta viajes compartidos como conductor o como pasajero. Al ofertar un

viaje se podrán seleccionar varias opciones, como por ejemplo, si se puede fumar o transportar animales.

Ver la información asociada a un viaje mostrando un mapa del recorrido. Eliminar un viaje propuesto. Buscar un viaje. Apuntarse a un viaje como conductor o como pasajero. Desapuntarse de un viaje en el que participaba. Al finalizar un trayecto, podrá valorar a un usuario en función de varios

parámetros, como pueden ser simpatía, puntualidad o respeto de las condiciones pactadas.

Escribir un comentario acerca de un viaje. Eliminar un comentario. Ofrecer un coste aproximado del gasto que un viaje conlleva. Proponer una nueva parada o una variación del trayecto ofrecido en un viaje. Este

cambio deberá ser aceptado por el conductor, que recibirá una alerta informándole de que tiene que decidir acerca de aceptar o rechazar una nueva parada propuesta.

Listar los viajes del usuario. Salir de la aplicación.

9

Usuario Facebook Es un usuario registrado en la red social Facebook que ha accedido a nuestra aplicación con sus datos de acceso a su cuenta de Facebook. Facebook solicitará al usuario que confirme que otorga permiso a la aplicación para utilizar sus datos. Una vez aceptado este trámite, puede utilizar nuestra aplicación.

El usuario Facebook disfrutará de todas las funcionalidades de las que dispone el usuario básico y además podrá interactuar con sus amigos de Facebook que, como él, sean usuarios de nuestra aplicación. Además de esas ventajas, podrá utilizar algunas funcionalidades adicionales:

Identificarse y acceder a la aplicación con sus credenciales de acceso a su cuenta de Facebook.

Buscar amigos de Facebook que utilicen la aplicación. Publicar en el muro de Facebook del usuario el anuncio de los viajes en los que

participe. Publicar un anuncio publicitario de la aplicación en el muro de Facebook del

usuario.

Los usuarios básicos y los usuarios Facebook pueden interactuar entre ellos. Es decir, pueden mantener relaciones de amistad, enviarse mensajes o participar en viajes independientemente del tipo de usuario que sea. Los usuarios que se registren como usuarios básicos en la aplicación, podrán registrarse posteriormente en la aplicación mediante su cuenta de Facebook y utilizar las funcionalidades adicionales que un usuario Facebook posee. Un usuario Facebook de la aplicación, no podrá acceder a la misma como usuario básico utilizando el mismo mail con el que accede a su cuenta de Facebook ya que las funcionalidades ofrecidas por la aplicación a los usuarios básicos son las mismas que las ofrecidas a los usuarios Facebook exceptuando las funcionalidades que requieren el uso de los datos recogidos en el perfil de Facebook del usuario. Como se puede apreciar, se recogen las funcionalidades más interesantes que las aplicaciones del sector tienen actualmente y además, se han incluido una serie de innovaciones como son:

Acceder a la aplicación utilizando las credenciales de acceso a Facebook del usuario y buscar a los usuarios de la aplicación que sean amigos de Facebook del usuario.

La propuesta de cambio de recorrido de un viaje.

Establecer relaciones de amistad entre los usuarios para facilitar la creación de viajes entre amigos.

1.4. Participantes del proyecto y comunicación En este caso, ante la ausencia de un cliente real, los participantes del proyecto serán la directora del proyecto, Beatriz Pérez Valle, que representará además la función de cliente, y Guillermo Pérez Ledesma, que será el desarrollador del mismo. La comunicación se llevará a cabo mediante las siguientes vías:

E-Mail. Reuniones, que se pretenderá que sean quincenales.

10

1.5. Entregables Los documentos que se entregarán una vez finalizado el proyecto serán:

El documento de objetivos del proyecto (DOP). La memoria del proyecto. La aplicación Web finalizada y su código. El script de creación de la base de datos.

1.6. Tecnologías a utilizar Las tecnologías que utilizaremos para el desarrollo de la aplicación son:

Sistema gestor de bases de datos MySQL 5.5.16. Servidor Web apache 2.2.21. PHP 5.3.8. JavaScript. Para el aspecto visual HTML5 y hojas de estilo CSS3.

Para la comunicación con Facebook, utilizaremos las siguientes herramientas que el propio Facebook nos proporciona:

Facebook SDK for PHP. FQL (Facebook query language).

1.7. Documentación necesaria En principio, la documentación que consideramos que nos puede ser útil para el desarrollo del proyecto será:

Ingeniería del software - Ian Sommerville [5]

Expert PHP and MySQL - Andrew Curioso, Ronald Bradford, Patrick Galbraith[6]

PHP 5 and MySQL bible - Tim Converse and Joyce Park with Clark Morgan [7]

Apache práctico - Ken Coar y Rich Bowen [8]

HTML5 y CSS3 domine los estándares de las aplicaciones Web - Luc Van

Lancker [9]

También utilizaremos los apuntes de las asignaturas de Ingeniería del software, Diseño de bases de datos, Diseño tecnológico de sistemas de la información y Programación de bases de datos.

11

1.8. Metodología Vamos a basarnos en Métrica V3, la metodología desarrollada por el Ministerio de administraciones públicas, aunque no la vamos a seguir paso a paso dado que el tamaño de nuestro proyecto no lo hace necesario. Hemos decidido seguir un ciclo de vida en cascada en el que primero realizaremos el análisis de toda la aplicación y posteriormente su diseño e implementación. Se ha tomado esta decisión porque los diferentes módulos que componen la aplicación están muy relacionados entre sí y la aplicación no es excesivamente grande. Como desventaja clara de esta decisión, los resultados se verán más tarde que en el caso de utilizar otras opciones de ciclos de vida, pero al estar tan relacionados los diferentes módulos de la aplicación, lo que perdemos por ese lado lo ganamos en una mejor integración de todas las funcionalidades de la misma. Hemos desechado la posibilidad de seguir un ciclo de vida iterativo-incremental en el que se realiza primero el análisis, diseño e implementación de de cada uno de los módulos de forma iterativa y por separado, debido a que la fuerte relación entre los diferentes módulos desaconseja su elaboración en diferentes iteraciones.

1.9. Planificación del proyecto A continuación, vamos a detallar las diferentes tareas y subtareas que vamos a desarrollar para la consecución de nuestro proyecto:

Desarrollo del DOP (5 horas) Planificación del sistema (15 horas)

Análisis del sistema (72 Horas)

o Análisis de los requisitos (10 horas) o Elaboración del diagrama de casos de uso (13 horas) o Elaboración de diagramas de actividad (10 horas) o Elaboración del diagrama de clases del análisis (15 horas) o Documentación y memoria asociada al análisis (24 horas)

12

Diseño de la aplicación (78 horas) o Planificación y diseño del sistema de persistencia (20 horas) o Elaboración del diagrama de clases del diseño (15 horas) o Diseño de Interfaces (20 horas) o Documentación y memoria asociadas al diseño (23 horas)

Implementación (169 Horas)

o Desarrollo de la base de datos (10 horas) o Programación de las funcionalidades de la aplicación (90 horas) o Integración con Facebook (25 horas) o Integración con Google Maps (15 horas) o Elaboración del apartado gráfico de la Web (29 horas)

Pruebas y validación del resultado (18 horas) Redacción de la memoria final (10 horas)

Total: 367 Horas Distribución porcentual del tiempo invertido en el proyecto

13

1.10. Calendario Tomaremos como referencia que el proyecto comenzó el 1 de Marzo de 2012. Durante el proyecto, el calendario estará compuesto por jornadas de 6 horas de lunes a viernes. Los sábados se utilizarán para compensar las posibles pérdidas de tiempo que puedan surgir durante la semana.

1.11. Riesgos y planes de acción

Planificación temporal no realista La planificación efectuada puede volverse inabarcable debido a diferentes causas, como pueden ser, una estimación de tiempos demasiado optimista o una variación de los requisitos de la aplicación

Solución: Planificar de nuevo el proyecto, teniendo en cuenta de nuevo todos los nuevos factores que encontremos, invirtiendo horas extra o modificando las fechas de finalización de las tareas afectadas.

Mala identificación de requisitos Realizar una extracción de requisitos confusa o equivocada.

Solución: Eliminar las ambigüedades en la redacción de los requisitos de la aplicación y replantearnos si las funcionalidades que debe tener la aplicación, son cubiertas por los requisitos obtenidos.

Problemas de software y/o hardware Problemas de software o hardware que hagan que perdamos el trabajo realizado.

Solución: Disponer de copias de seguridad de todos los documentos generados en el desarrollo de la aplicación.

14

2. Análisis

2.1. Introducción

Como hemos comentado anteriormente, nuestra aplicación debe ser capaz de proporcionar un entorno intuitivo y útil a los usuarios que quieran realizar viajes en un vehículo compartido. En la etapa de análisis, identificaremos los requisitos que debe cumplir nuestro sistema y los detallaremos especificando a qué actores afectan. Por último, definiremos el diagrama de clases en el que aparecerán tanto las clases que compondrán nuestro sistema, como las relaciones existentes entre las mismas.

2.2. Requisitos del sistema

A continuación, se expondrán los requisitos que debe cumplir la aplicación. Estos requisitos serán clasificados según el usuario que pueda llevarlos a cabo.

2.2.1 Usuario Visitante

Visitar la portada de la aplicación. Registrarse como usuario básico.

2.2.2 Usuario Básico

El usuario básico tendrá acceso a los cuatro módulos que tiene la aplicación: el módulo de gestión de perfil, el módulo de gestión de amigos, el módulo de gestión de mensajes y el módulo de gestión de viajes.

2.2.2.1 Módulo de gestión de perfil

El módulo de gestión de perfil, se encargará de gestionar de forma eficiente la información personal de cada usuario. Las funcionalidades que ofrece este módulo a los usuarios básicos son las siguientes:

Identificarse y acceder a la aplicación. Darse de baja de la aplicación. Ver el perfil de usuario. Añadir o eliminar algún vehículo a su perfil. Modificar alguna característica de alguno de sus vehículos. Modificar los datos personales del usuario.

2.2.2.2 Módulo de gestión de amigos

El módulo de gestión de amigos se encargará de administrar las relaciones de amistad que los usuarios de la aplicación mantengan entre sí. Estableciendo relaciones de amistad con el resto de usuarios, podremos ver fácilmente los viajes en los que participan los amigos del usuario. Entre las funcionalidades de este módulo, citamos:

Ver el perfil del resto de usuarios. Añadir, solicitar o rechazar relaciones de amistad con otros usuarios. Buscar usuarios. Listar a sus amigos.

15

2.2.2.3 Módulo de gestión de mensajes

El módulo de gestión de mensajes permitirá a los usuarios enviar y recibir mensajes de cualquier usuario de la aplicación. Las funcionalidades de este módulo son las siguientes:

Enviar mensajes al resto de usuarios. Ver y borrar mensajes recibidos.

2.2.2.4 Módulo de gestión de viajes

Este módulo gestionará las funcionalidades que permitan a nuestros usuarios interactuar con los viajes ofertados por el resto de usuarios y ofertar, ellos mismos, viajes compartidos.

Los viajes que se oferten dentro de nuestro sistema tendrán cuatro estados diferentes:

Abierto: Se trata de un viaje dado de alta y para el que todavía hay tiempo y plazas libres.

Cerrado: Será un viaje que aún no se ha llevado a cabo pero sobre el que ya no se pueden realizar modificaciones. Este estado se alcanzará cuando queden menos de 24 horas para la puesta en marcha del mismo.

Finalizado: Este estado se alcanzará una vez que el viaje se ha realizado. En este estado se habilitará la opción de realizar valoraciones.

Fallido: Este estado se le asignará a aquel viaje al que 24 horas antes de llevarse a cabo no se haya apuntado nadie o sea un viaje dado de alta por un pasajero que no haya conseguido un conductor.

Al apuntarnos a un viaje, lo hacemos desempeñando un rol en el mismo. Los roles posibles son los siguientes:

Promotor conductor: Será el usuario del viaje que lo propone y además ejerce como conductor.

Promotor pasajero: Es un usuario que da de alta un viaje, pero no es conductor. De este modo queda a expensas de que un conductor se apunte al mismo.

Conductor: Es un usuario que decide ser el conductor de un viaje promovido por un usuario pasajero.

Pasajero: Es un usuario que se apunta como pasajero a un viaje ya dado de alta por otro usuario.

Los usuarios registrados en la aplicación básica serán capaces de:

Proponer un viaje como conductor. Proponer un viaje como pasajero. Ver la información asociada a un viaje. Eliminar un viaje propuesto. Buscar viajes. Apuntarse o desapuntarse de un viaje como conductor o como pasajero. Valorar a un usuario. Escribir un comentario acerca de un viaje. Generar un precio recomendado para un viaje. Proponer una parada dentro de un viaje. Aceptar o rechazar una propuesta de cambio de trayecto. Listar los viajes de un usuario. Eliminar un comentario.

16

2.2.3 Usuario Facebook

El usuario Facebook puede realizar todas las operaciones de las que dispone el usuario básico y además, dispondrá de algunas funcionalidades adicionales que detallamos a continuación:

2.2.3.1 Módulo de gestión de amigos

Identificarse y acceder a la aplicación con sus credenciales de acceso a su cuenta de Facebook.

Buscar amigos de Facebook que utilicen la aplicación.

2.2.3.2 Módulo de gestión de viajes

Publicar en el muro de Facebook del usuario el anuncio de un viaje en el que esté inscrito.

2.2.3.3 Módulo de gestión de perfil

Publicar en el muro de Facebook del usuario un anuncio de subeKeTeLlevo.com

2.3. Especificación de casos de uso Una vez identificados los requisitos de la aplicación, pasaremos a analizarlos más detalladamente mostrando los diagramas de casos de uso. Para una mejor comprensión de los mismos, los agruparemos en función del tipo de usuario.

2.3.1 Casos de uso relacionados con el usuario Visitante El usuario visitante es un usuario que no está registrado en la aplicación. Únicamente podrá acceder a la portada o registrarse como usuario básico.

2.3.1.1 Visitar portada Identificador Visitar portada. Descripción El usuario será capaz de visitar la portada de la aplicación en la que

se le ofrecerá registrarse en la misma, acceder como usuario Básico o acceder como usuario Facebook.

Precondición - Poscondición El usuario accede a la portada de la aplicación. Secuencia Normal

1. El usuario se conecta a nuestra Web. 2. Se le muestra la portada de nuestra aplicación.

17

2.3.1.2 Registro usuario básico Identificador Registro usuario básico. Descripción El usuario tras visitar nuestra portada, se registra en nuestra

aplicación aportando los datos requeridos. Precondición - Poscondición El usuario queda registrado en nuestra aplicación. Secuencia Normal

1. El usuario accede a la portada. 2. Selecciona la opción de registrarse. 3. Rellena los datos requeridos. 4. Se confirma el registro.

2.3.2 Casos de uso relacionados con el usuario Básico A continuación se muestran los casos de uso definidos para el usuario básico. En primer lugar se muestra un primer nivel de los casos de uso y posteriormente se pasará a describir cada uno de los casos de uso que afectan al usuario básico.

2.3.2.1 Casos de uso pertenecientes al módulo de gestión de perfil

Pasamos a analizar detalladamente los casos de uso del usuario básico relacionados con el módulo de gestión de perfil.

18

2.3.2.1.1 Ver perfil Identificador Ver perfil. Descripción Tras acceder al módulo de gestión de perfil podremos ver nuestro

perfil en el que aparecerán todos nuestros datos personales. Precondición El usuario debe estar registrado en la aplicación como usuario

Básico o usuario Facebook. Poscondición Vemos nuestro perfil. Secuencia Normal

1. El usuario se identifica y accede a nuestra aplicación. 2. Accede al módulo de gestión de perfil. 3. Ve su perfil.

2.3.2.1.2 Modificar datos personales Identificador Modificar datos personales. Descripción El usuario será capaz de modificar los datos que aparecen en su

perfil, como pueden ser contraseña, ciudad o teléfono de contacto. La gestión de los datos de los vehículos del usuario se realizará desde el caso de uso Modificar vehículo.

Precondición El usuario debe estar registrado en la aplicación como usuario Básico o usuario Facebook.

Poscondición El usuario modifica los datos de su perfil que necesite. Secuencia Normal

1. El usuario accede a la aplicación utilizando sus credenciales de acceso.

2. Accede a su perfil y se le muestran todos los datos que disponemos acerca de él.

3. El usuario cambia los datos que desee. 4. Confirma los cambios.

19

2.3.2.1.3 Baja aplicación Identificador Baja aplicación. Descripción El usuario se da de baja de la aplicación, borrando toda la

información que haya generado. Precondición El usuario debe estar registrado en nuestra aplicación como usuario

Básico o usuario Facebook. Poscondición El usuario se da de baja de la aplicación y se elimina toda la

información que ha generado. Se eliminarán los vehículos del usuario, sus comentarios, sus mensajes, sus relaciones de amistad y todos los viajes de los que forme parte como promotor conductor, promotor pasajero o conductor aunque se encuentren en estado abierto.

Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Accede a la página de su perfil, en la que se encuentra la

opción de darse de baja de la aplicación. 3. Confirma su decisión de darse de baja. 4. Se borra toda la información que el usuario haya generado. 5. Se envía un mensaje avisando de este hecho a los demás

usuarios apuntados en cualquiera de los viajes eliminados. 6. Se le expulsa de la aplicación mostrándole un mensaje.

2.3.2.1.4 Listar mis vehículos Identificador Listar mis vehículos. Descripción El usuario, tras acceder a la zona de gestión de perfil puede acceder

a sus vehículos. Se le ofrece un listado de los mismos. Precondición El usuario debe estar registrado en nuestra aplicación como usuario

Básico o usuario Facebook. Poscondición Se le ofrece al usuario un listado de sus vehículos. Secuencia Normal



3. El usuario accede a sus vehículos. 4. Se le presenta un listado de sus vehículos.

2.3.2.1.5 Modificar vehículo Identificador Modificar vehículo. Descripción El usuario, tras acceder a la zona de gestión de perfil y a mis

vehículos, puede seleccionar alguno de la lista y modificar sus datos.

Precondición El usuario debe estar registrado en nuestra aplicación como usuario Básico o usuario Facebook.

Poscondición El usuario modifica uno de los vehículos que ya tenía dados de alta. Secuencia Normal



3. El usuario accede a sus vehículos. 4. Selecciona uno de los vehículos que se le presentan. 5. Se muestran los datos del vehículo. 6. Modifica sus datos. 7. Guarda los cambios.

20

2.3.2.1.6 Eliminar vehículo Identificador Eliminar vehículo. Descripción El usuario, tras acceder a la zona de gestión de perfil y acceder a

sus vehículos, podrá eliminar un vehículo que previamente esté dado de alta.

Precondición El usuario debe estar registrado en nuestra aplicación como usuario Básico o usuario Facebook y tener un vehículo dado de alta previamente.

Poscondición El usuario elimina un vehículo, lo que desencadena que se eliminen todos los viajes en los que participa el vehículo eliminado. Además, se envía un mensaje informativo a todos los usuarios participantes en los viajes eliminados

Secuencia Normal



3. El usuario accede a sus vehículos. 4. El usuario elimina un vehículo. Como consecuencia, se

eliminan todos los viajes en los que participa el vehículo eliminado.

5. Se envía un mensaje informativo a todos los participantes de los viajes borrados.

2.3.2.1.7 Añadir vehículo Identificador Añadir vehículo. Descripción El usuario, tras acceder a la zona de gestión de perfil y acceder a

sus vehículos, podrá añadir uno nuevo. Precondición El usuario debe estar registrado en nuestra aplicación como usuario

Básico o usuario Facebook. Poscondición El usuario añade un vehículo a su perfil. Secuencia Normal



3. El usuario accede a sus vehículos. 4. Selecciona añadir vehículo. 5. Introduce la matrícula del vehículo a añadir. 6. Introduce los datos del vehículo. 7. Lo añade.

Secuencia Alternativa



3. El usuario accede a sus vehículos. 4. Selecciona añadir vehículo. 5. Introduce la matrícula del vehículo a añadir. 6. El vehículo ya se encuentra dado de alta por otra persona.

Se le muestran los datos del vehículo y se le ofrece la posibilidad de cambiarlos.

7. Añade el vehículo.

21

A continuación, mostramos el diagrama de actividad asociado a este caso de uso para una mejor comprensión del mismo:

22

2.3.2.2 Casos de uso pertenecientes al módulo de gestión de amigos

A continuación se detallan los casos de uso relacionados con el módulo de gestión de amigos. Los casos de uso ver viajes usuario y enviar mensajes, serán analizados con más detenimiento en sus respectivos módulos. Se muestran en la imagen porque son accesibles desde ver usuario. 2.3.2.2.1 Buscar usuario Identificador Buscar usuario. Descripción Una vez que el usuario queda identificado dentro de la aplicación,

puede acceder a la herramienta de búsqueda de usuarios dentro del módulo de gestión de amigos. Mediante esta herramienta puede buscar a otros usuarios siguiendo varios criterios como pueden ser nombre, mail o localidad. Se puede buscar a cualquier usuario registrado en la aplicación sean amigos o no, o sean usuarios Básicos o usuarios Facebook.

Precondición El usuario debe estar registrado dentro de la aplicación como usuario Básico o usuario Facebook.

Poscondición Se le muestra al usuario los resultados que la búsqueda ha generado coincidiendo con los criterios que el usuario ha introducido.

Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. El usuario accede a la herramienta de búsqueda de usuarios

dentro del módulo gestión de amigos. 3. Introduce los datos del usuario a buscar. 4. Obtiene los resultados.

23


2.3.2.2.2 Listar amigos Identificador Listar amigos. Descripción Una vez que el usuario queda identificado dentro de la aplicación,

podemos listar a sus amigos para acceder a sus perfiles. Precondición El usuario debe estar registrado dentro de la aplicación como

usuario Básico o usuario Facebook. Poscondición Se le muestra al usuario la lista de sus amigos. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. El usuario accede a su perfil y accede a la zona de gestión

de amigos. 3. Al acceder se le devuelve una lista de los amigos con los

que cuenta dentro de la aplicación. 2.3.2.2.3 Ver usuario Identificador Ver usuario. Descripción Al ver el perfil de un usuario, se mostrarán los datos del usuario y

las opciones de enviarle un mensaje, solicitar su amistad o ver un listado de los viajes en los que ha participado.


Poscondición Vemos el perfil de otro usuario y todas las opciones mediante las cuales podemos interactuar con él.

Secuencia Normal

1. El usuario se identifica y accede a nuestra aplicación. 2. Accede a la zona de gestión de amigos. 3. Busca un usuario. 4. Ve su perfil.

Secuencia alternativa

1. El usuario se identifica y accede a nuestra aplicación. 2. Accede a la zona de gestión de amigos. 3. Lista sus amigos. 4. Accede al perfil de uno de sus amigos.

24

2.3.2.2.4 Solicitar amistad Identificador Solicitar amistad. Descripción Un usuario registrado puede solicitar crear una relación de amistad

con otro usuario. Esta solicitud debe ser confirmada por el usuario que la recibe para hacerse efectiva.

Precondición El usuario debe estar registrado en la aplicación como usuario Básico o usuario Facebook. El usuario solicitante no debe de mantener una relación de amistad previa con el solicitado.

Poscondición Se crea una solicitud de amistad con el usuario seleccionado. Secuencia Normal

1. El usuario se identifica y accede a nuestra aplicación 2. Busca un usuario. 3. Accede a su perfil. 4. Solicita la amistad del mismo. 5. Queda a la espera de que el usuario al que ha enviado la

solicitud confirme la amistad. A continuación, se muestra el diagrama de actividad correspondiente:

25

2.3.2.2.5 Estudio de solicitud de amistad Identificador Estudio de solicitud de amistad. Descripción El usuario que ha recibido una solicitud de amistad, puede decidir

si aceptar dicha relación o no. Precondición El usuario debe tener una solicitud de amistad pendiente de estudio. Poscondición El usuario acepta o rechaza la solicitud de amistad propuesta. Secuencia Normal

1. El usuario accede a nuestra aplicación. 2. Detecta que ha recibido una solicitud de amistad. 3. Decide si aceptarla o no.


2.3.2.2.6 Borrar amigo Identificador Borrar amigo. Descripción El usuario elimina una relación de amistad que mantiene con otro

usuario. Precondición El usuario debe estar registrado en la aplicación como usuario

Básico o usuario Facebook. Poscondición La relación de amistad seleccionada queda borrada. Como

consecuencia de ello al listar las amistades del usuario o los viajes de los amigos del usuario no aparecerán los datos correspondientes al usuario con el que hemos eliminado la amistad.

Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Accede a la zona de gestión de amigos. 3. Lista todos los amigos que tiene en la aplicación. 4. Borra la relación de amistad.

26

2.3.2.3 Casos de uso pertenecientes al módulo de gestión de mensajes

En este apartado detallaremos los casos de uso relacionados con el módulo de gestión de mensajes.

El caso de uso Ver usuario, será analizado con más detenimiento en su respectivo módulo, se muestra en la imagen porque Enviar mensaje es accesible desde Ver usuario. 2.3.2.3.1 Leer mensaje Identificador Leer mensaje. Descripción El usuario al acceder a la aplicación detecta que le han enviado un

mensaje y accede al mismo para leerlo. Precondición El usuario debe estar dado de alta en la aplicación como usuario

Básico o usuario Facebook. El usuario debe haber recibido un mensaje.

Poscondición El usuario lee un mensaje que le han enviado. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Detecta que ha recibido un mensaje. 3. Accede al módulo de gestión de mensajes. 4. Accede al mensaje. 5. Lo lee.

2.3.2.3.2 Eliminar mensaje Identificador Eliminar mensaje. Descripción El usuario elimina un mensaje que ha recibido. Precondición El usuario debe estar dado de alta en la aplicación como usuario

Básico o usuario Facebook y debe de haber recibido algún mensaje.

Poscondición El usuario elimina un mensaje que le han enviado. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Accede al módulo de gestión de mensajes. 3. Accede a sus mensajes. 4. Accede al mensaje. 5. Lo elimina.


1. El usuario se identifica y accede a la aplicación. 2. Accede al módulo de gestión de mensajes. 3. Accede a sus mensajes. 4. Elimina el mensaje que desea borrar sin haber accedido a su

contenido.

27

2.3.2.3.3 Enviar mensaje Identificador Enviar mensaje. Descripción El usuario envía un mensaje privado a cualquier otro usuario de la

aplicación. Precondición El usuario debe estar registrado en la aplicación como usuario

Básico o usuario Facebook. Poscondición Se envía un mensaje al usuario seleccionado. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Busca a un usuario que esté dado de alta en la aplicación. 3. Selecciona al usuario deseado de entre la lista generada. 4. Accede al perfil del usuario y selecciona la opción enviar

mensaje. 5. Escribe el mensaje que desea remitir. 6. Envía el mensaje.


1. El usuario se identifica y accede a la aplicación. 2. Accede al módulo de gestión de mensajes. 3. Accede a sus mensajes. 4. Selecciona enviar nuevo mensaje. 5. Especifica emisor, asunto y mensaje. 6. Envía el mensaje.

A continuación, mostramos el diagrama de actividad asociado a este caso de uso:

28

2.3.2.4 Casos de uso pertenecientes al módulo de gestión de viajes

2.3.2.4.1 Dar de alta viaje como conductor Identificador Dar de alta un viaje como conductor. Descripción El usuario, tras acceder a la aplicación, puede ofertar un viaje como

conductor para que otros usuarios se apunten al mismo y así conformar un viaje.

Precondición El usuario debe estar registrado dentro de la aplicación como usuario Básico o usuario Facebook y tener un vehículo dado de alta.

Poscondición El usuario da de alta un viaje como conductor. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. El usuario accede a la zona de inscripción de viajes. 3. Rellena los datos necesarios para dar de alta el mismo. 4. Se le muestra un mapa con el recorrido y un coste

aproximado del viaje. 5. Define un precio por pasajero para el viaje. 6. El viaje se guarda dentro de la aplicación.


29

2.3.2.4.2 Dar de alta un viaje como pasajero Identificador Dar de alta un viaje como pasajero. Descripción El usuario tras acceder a la aplicación puede ofertar un viaje como

pasajero. En este caso al menos una de las plazas ofertadas se reservará al conductor del mismo. Si no se encuentra uno, no se llevará a cabo el viaje.

Precondición El usuario debe estar registrado como usuario Básico o usuario Facebook.

Poscondición El usuario introduce los datos necesarios para dar de alta un viaje, se genera un mapa de Google Maps marcando el recorrido del mismo y se da de alta el viaje.

Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. El usuario accede a la zona de inscripción de viajes. 3. Rellena los datos necesarios para dar de alta el mismo. 4. Se genera un mapa con el recorrido. 5. El viaje queda registrado dentro de la aplicación.

2.3.2.4.3 Generar viaje y calcular precio recomendado Identificador Generar viaje y calcular precio recomendado. Descripción Antes de confirmar el alta de un viaje, se le presenta al usuario un

mapa de Google Maps en el que se marca la ruta del viaje y se le ofrece un precio estimado a ese viaje. El usuario marca un precio por persona adecuado a ese viaje utilizando el valor ofrecido por la aplicación o no.


Poscondición Se calcula el coste aproximado del viaje. Secuencia Normal

1. El usuario se identifica y accede a la aplicación 2. Accede al apartado de gestión de viajes. 3. Comienza el proceso de dar de alta un viaje. 4. Calcula el recorrido y el precio del mismo en el transcurso

del alta del viaje. 5. Da de alta el viaje.

30

2.3.2.4.4 Eliminar viaje propuesto Identificador Eliminar viaje propuesto. Descripción Una vez que el usuario queda identificado dentro de la aplicación,

puede eliminar cualquier viaje que haya propuesto. Se enviará un mensaje al resto de usuarios que se hubiesen apuntado al mismo informando de este hecho.

Precondición El usuario debe estar registrado dentro de la aplicación como usuario Básico o usuario Facebook, el usuario debe ser el mismo que lo dio de alta y el viaje debe estar en estado abierto.

Poscondición El viaje propuesto queda eliminado. Posteriormente se envía un mensaje a los usuarios que participaban en el mismo informando de la eliminación del viaje.

Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. El usuario accede a su zona de gestión de viajes y localiza

el viaje que quiere eliminar. 3. Se comprueba que el viaje no esta ni cerrado ni finalizado. 4. Elimina el viaje. 5. Confirma la eliminación. 6. Se envía un mensaje informando de la eliminación del viaje

a todos los usuarios que se habían apuntado al mismo. A continuación, mostramos el diagrama de actividad correspondiente:

31

2.3.2.4.5 Listar viajes usuario Identificador Listar viajes usuario. Descripción El usuario puede ver todos los viajes en los que ha participado, ha

dado de alta o se ha apuntado un determinado usuario. Precondición El usuario debe estar dado de alta en la aplicación como usuario

Básico o usuario Facebook. Poscondición El usuario lista todos los viajes en los que ha participado un

usuario. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Accede al módulo de gestión de usuarios. 3. Accede a sus viajes. 4. Se le muestran los viajes en los que ha participado.

Secuencia Alternativa 1

1. El usuario se identifica y accede a la aplicación. 2. Accede al módulo de gestión de usuarios. 3. El usuario busca un usuario. 4. Selecciona un usuario de los que se le presentan. 5. Selecciona la opción de ver los viajes de ese usuario. 6. Se le muestran los viajes de ese usuario.

Secuencia Alternativa 2

1. El usuario se identifica y accede a la aplicación. 2. Accede al módulo de gestión de usuarios. 3. El usuario lista sus amigos. 4. Selecciona un usuario de entre sus amigos. 5. Selecciona la opción de ver los viajes de ese usuario. 6. Se le muestran los viajes de ese usuario.

2.3.2.4.6 Valorar usuario Identificador Valorar usuario. Descripción Una vez realizado el viaje, los usuarios que han tomado parte en el

mismo, pueden valorarse entre sí. Precondición El usuario debe estar registrado dentro de la aplicación como

usuario Básico o usuario Facebook. Debe haber compartido viaje con el usuario a valorar. El viaje que han compartido ha de encontrarse en estado finalizado.

Poscondición El usuario valora a otro usuario con el que ha compartido viaje. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. El usuario accede a su zona de gestión de mensajes y

localiza el viaje que quiere valorar. 3. Valora al usuario siguiendo varios criterios. 4. Confirma la puntuación.

32


2.3.2.4.7 Buscar viaje Identificador Buscar viaje. Descripción Una vez que el usuario queda identificado dentro de la aplicación,

puede buscar los viajes propuestos por otros usuarios siguiendo varios criterios, como pueden ser el nombre del usuario que propone el viaje, el destino y origen del mismo, y la fecha.


Poscondición Se le muestra al usuario una serie de viajes que coinciden con los criterios de búsqueda que ha especificado.

Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. El usuario accede a la herramienta de búsqueda de viajes

dentro de la zona de gestión de viajes. 3. Introduce la información necesaria para efectuar la

búsqueda. 4. Se realiza la búsqueda. 5. Se muestra el resultado.


1. El usuario se identifica y accede a la aplicación. 2. El usuario accede a la zona de gestión de viajes. 3. Accede a uno de los viajes en los que ha participado.

33

2.3.2.4.8 Ver viaje Identificador Ver viaje. Descripción Una vez que el usuario se ha identificado dentro de la aplicación,

puede acceder a los viajes propuestos en ese momento. Se le presentarán a su vez una serie de opciones para interactuar con los viajes, como pueden ser apuntarse al mismo o escribir un comentario.

Precondición El usuario debe estar registrado dentro de la aplicación como usuario Básico o usuario Facebook. El viaje debe de estar en estado abierto. Si está en estado cerrado, sólo podrán acceder al viaje los usuarios que se hayan inscrito en el mismo.

Poscondición Se le muestran al usuario los datos de un viaje y las diferentes formas de interactuar con él.

Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. El usuario accede a la herramienta de búsqueda de viajes

dentro de la zona de gestión de viajes. 3. Introduce la información necesaria para efectuar la

búsqueda. 4. Se realiza la búsqueda. 5. Se obtiene el resultado. 6. Accede a uno de los viajes localizados.


4. El usuario se identifica y accede a la aplicación. 5. El usuario accede a la zona de gestión de viajes. 6. Accede a uno de los viajes en los que ha participado.

A continuación, mostramos el diagrama de actividad correspondiente:

34

2.3.2.4.9 Apuntarse a un viaje como pasajero Identificador Apuntarse a un viaje como pasajero. Descripción Una vez que el usuario quede identificado dentro de la aplicación,

puede buscar un viaje siguiendo diferentes filtros como pueden ser usuario que ha propuesto el viaje o destino y origen del mismo.

Precondición El usuario debe estar registrado en la aplicación como usuario Básico o usuario Facebook. El viaje debe encontrarse en estado abierto y debe haber plazas disponibles en el mismo.

Poscondición Quedamos apuntados a un viaje ofertado. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Busca el viaje dentro de la zona de gestión de viajes. 3. Accede a los datos del viaje que el usuario ha seleccionado. 4. Se apunta al mismo.

A continuación, mostramos el diagrama de actividad correspondiente:

35

2.3.2.4.10 Apuntarse a un viaje como conductor Identificador Apuntarse a un viaje como conductor. Descripción Una vez que el usuario quede identificado dentro de la aplicación,

puede buscar un viaje siguiendo diferentes filtros como pueden ser usuario que ha propuesto el viaje, o destino y origen del mismo. Al apuntarnos, se nos solicitará que definamos un precio por pasajero para el viaje.

Precondición El usuario debe estar registrado en la aplicación como usuario Básico o usuario Facebook. El viaje debe encontrarse en estado abierto.

Poscondición Quedamos apuntados a un viaje ofertado. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Busca el viaje dentro de la zona de gestión de viajes. 3. Accede a los datos del viaje que el usuario ha seleccionado. 4. Se le muestra el recorrido del viaje y define un precio por

pasajero. 5. Se apunta al mismo.

2.3.2.4.11 Desapuntarse de un viaje Identificador Desapuntarse de un viaje. Descripción Una vez el usuario quede identificado dentro de la aplicación, el

usuario puede acceder a sus viajes y seleccionar el viaje del que quiere desapuntarse.

Precondición El usuario debe estar registrado dentro de la aplicación como usuario Básico o usuario Facebook. Debemos estar apuntados al viaje, no desempeñar el rol de promotor conductor, promotor pasajero o conductor. El viaje debe encontrarse en estado abierto.

Poscondición El usuario queda desapuntado del viaje. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Accede a su perfil y selecciona la opción de ver sus viajes. 3. Accede a los datos del viaje del que quiere desapuntarse. 4. Selecciona la opción de desapuntarse. 5. Se borra su participación del viaje.

2.3.2.4.12 Añadir un comentario a un viaje Identificador Añadir un comentario a un viaje. Descripción Una vez el usuario quede identificado dentro de la aplicación,

puede buscar cualquier viaje ofertado y realizar un comentario acerca del mismo. Puede realizar alguna pregunta para el conductor o alguna sugerencia. Esta operación puede ser realizada tanto si se ha dado de alta dentro del viaje como si no.


Poscondición El usuario añade un comentario al viaje. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Accede a su zona de gestión de viajes y selecciona la

opción de buscar viajes. 3. Accede a uno de los viajes que le interesen. 4. Añade un comentario.

36

2.3.2.4.13 Borrar Comentario Identificador Borrar comentario. Descripción El usuario borra un comentario que considera inadecuado. Precondición El usuario debe estar registrado en la aplicación como usuario

Básico o usuario Facebook. Debe de ser el promotor del viaje en el que se borra el comentario.

Poscondición El comentario seleccionado queda borrado. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Accede a su zona de gestión de viajes. 3. Accede al viaje en el que se encuentra el comentario. 4. Borra el comentario. 5. Se le informa al usuario que había escrito el comentario de

que su comentario ha quedado eliminado. 2.3.2.4.14 Listar últimos viajes propuestos Identificador Listar últimos viajes propuestos. Descripción Se ofrece una lista de los últimos viajes propuestos por los usuarios

de la aplicación. Precondición El usuario debe estar registrado dentro de la aplicación como

usuario Básico o usuario Facebook. Poscondición Se muestra una lista de viajes ofertados por los usuarios de la

aplicación. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Se muestran los últimos viajes ofertados por los usuarios de

la aplicación. 2.3.2.4.15 Proponer parada dentro de un trayecto Identificador Proponer parada dentro de un trayecto. Descripción Tras identificarse dentro de la aplicación, el usuario puede buscar

un viaje y si el trayecto ofrecido no se adapta a sus necesidades, puede ofrecer al conductor la posibilidad de incluir una parada dentro del viaje.

Precondición El usuario debe estar registrado dentro de la aplicación como usuario Básico o usuario Facebook y estar apuntado dentro del viaje en el que propone realizar una parada. El viaje debe encontrarse en estado abierto.

Poscondición El usuario propone una parada dentro del viaje. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. Accede a la zona de gestión de viajes. 3. Lista todos los viajes en los que ha participado. 4. Accede al viaje en el que quiere proponer una parada. 5. Propone una nueva parada.

37

2.3.2.4.16 Estudiar propuesta de cambio de trayecto Identificador Estudiar propuesta de cambio de trayecto. Descripción Una vez que el usuario queda identificado dentro de la aplicación,

si uno de sus viajes tiene una propuesta de cambio de trayecto, le aparecerá un aviso. Si selecciona ese aviso, puede ver la propuesta y declinarla o aceptarla.

Precondición El usuario debe estar registrado dentro de la aplicación como usuario Básico o usuario Facebook y tener una propuesta de cambio de trayecto en un viaje. El viaje debe estar en estado abierto.

Poscondición La oferta de cambio de trayecto queda aceptada o declinada. Secuencia Normal

1. El usuario se identifica y accede a la aplicación. 2. El usuario detecta que tiene una aleta y la selecciona. 3. Acepta o declina la oferta. 4. En el caso de que la propuesta sea aceptada se modifica el

viaje. Secuencia alternativa

1. El usuario no responde a la propuesta antes de que el viaje quede cerrado.

2. Se le informa al usuario de que su propuesta no ha sido atendida.

3. Se le elimina del viaje. A continuación, mostramos el diagrama de actividad correspondiente:

38

2.3.3 Casos de uso relacionados con el usuario Facebook En esta sección detallaremos los casos de uso relacionados exclusivamente con el Usuario Facebook.

2.3.3.1 Buscar amigos de Facebook que utilicen la aplicación Identificador Buscar amigos de Facebook que utilicen la aplicación. Descripción Una vez que el usuario ha accedido a la aplicación con su cuenta de

Facebook se le ofrece la posibilidad de buscar a sus amigos de Facebook que utilizan la aplicación.

Precondición El usuario debe estar registrado dentro de la aplicación como usuario Facebook.

Poscondición Se muestran los amigos de Facebook del usuario que utilizan la aplicación.

Secuencia Normal

1. El usuario se identifica con su cuenta de Facebook y accede a la aplicación.

2. El usuario accede a su zona de gestión de amigos y accede a la opción de listar amigos de Facebook.

3. Al utilizarla se le devuelve una lista de los amigos con los que cuenta dentro de la aplicación.

2.3.3.2 Anunciar en el muro de Facebook del usuario un viaje Identificador Anunciar en el muro de Facebook del usuario un viaje. Descripción Una vez identificados dentro de la aplicación con nuestra cuenta de

Facebook, podemos publicitar en el muro del usuario, un viaje que haya dado de alta.


Poscondición Se publica en el muro del usuario un anuncio del viaje que ha dado de alta.

Secuencia Normal

1. El usuario se identifica mediante su cuenta de Facebook y accede a la aplicación.

2. El usuario accede a su zona de gestión de viajes dentro de nuestra aplicación.

3. Selecciona uno de los viajes que haya dado de alta. 4. Y selecciona la opción de anunciar el viaje en su muro.

39

2.3.3.3 Anunciar la aplicación en el muro de Facebook del usuario Identificador Anunciar la aplicación en el muro de Facebook del usuario. Descripción Una vez identificados dentro de la aplicación con nuestra cuenta de

Facebook, podemos publicar en nuestro muro de forma automática un anuncio de nuestra aplicación.


Poscondición Se publica en el muro del usuario un anuncio de la aplicación. Secuencia Normal

5. El usuario se identifica mediante su cuenta de Facebook y accede a la aplicación.

6. El usuario selecciona la opción Anúncianos en Facebook. 7. Se publica un anuncio en el muro de Facebook del usuario.

2.4. Diagrama de clases En este apartado veremos el diseño de las clases que conforman la aplicación. A partir del análisis hecho anteriormente hemos identificado un diagrama de clases con 8 clases: Usuario, Usuario_facebook, Viaje, Vehículo, Mensaje, Comentario, Puntuación y Dirección_de_ruta. A continuación, mostramos el diagrama de clases UML con todas las clases y relaciones identificadas entre ellas. Por claridad, se ha optado por no mostrar los atributos de las distintas clases. A continuación, vamos a pasar a describir cada una de las clases y las relaciones que se observan en el diagrama de clases UML.

40

2.4.1 Usuario

Es, junto con la clase Viaje, la clase más importante de nuestra aplicación. Esta clase representa a un usuario registrado que interactúa con el sistema. En esta clase tendremos como atributos los datos personales de cada usuario y su tipo de usuario. Relaciones

Encontramos una relación reflexiva en la case Usuario. Esta relación trata de representar la relación de amistad entre dos usuarios que podemos encontrar en nuestra aplicación. Tiene como multiplicidad “varios-a-varios” en ambos extremos dado que no existen restricciones en cuanto al número de amigos que podemos tener.

La clase Usuario tiene una relación de tipo “varios-a-varios” con la clase Vehículo porque un vehículo puede ser utilizado por varios usuarios y un usuario puede tener varios vehículos.

Entre la clase Usuario y Viaje encontramos una relación con multiplicidad “varios-a-varios”. Un viaje puede tener varios usuarios inscritos y un usuario puede estar inscrito en varios viajes.

La clase Usuario tiene 2 relaciones de tipo “uno-a-varios” con Puntuación denominadas emisor y receptor. Cada puntuación tiene un único usuario emisor y un único receptor y cada usuario podrá ser emisor o receptor de varias puntuaciones.

La clase Usuario tiene 2 relaciones de tipo “uno-a-varios” con Mensaje con el rol de remitente y destinatario. Cada mensaje tiene un único remitente y un único destinatario. Un usuario puede ser remitente o destinatario de varios mensajes.

Las clases Usuario, Viaje y Dirección de ruta mantienen una relación ternaria en la que un usuario puede dar de alta varias direcciones de ruta en un mismo viaje, un viaje puede tener entre dos o varias direcciones de ruta.

2.4.2 Usuario_facebook

Mediante esta clase especializamos la clase usuario. De esta forma la clase Usuario_facebook podrá utilizar los métodos de la clase Usuario. Además, añadirá algunos métodos más para permitir la comunicación de nuestra aplicación con las cuentas Facebook de nuestros Usuarios Facebook.

41

2.4.3 Viaje

Es una de las clases centrales de la aplicación y representa un viaje compartido que ha sido registrado en el sistema. Esta clase consta de los atributos fecha de salida, precio, número de pasajeros y otros atributos que tienen que ver con el viaje que damos de alta. Relaciones

La clase Viaje tiene una relación con Usuario con multiplicidad “varios-a-varios”. Un viaje puede tener varios usuarios inscritos y un usuario puede estar inscrito en varios viajes.

La clase viaje tiene una relación “uno-a-varios” con la clase puntuación. De un mismo viaje existirán tantas puntuaciones como pasajeros hayan participado en el viaje. Una puntuación sólo hará referencia a un viaje.

La clase viaje tiene una relación con multiplicidad “uno-a-varios” con la clase vehículo ya que cada viaje debe tener un único vehículo asociado y un vehículo puede participar en varios viajes.

Entre las clases Usuario, Viaje y Dirección de ruta mantienen una relación ternaria en la que un usuario puede dar de alta varias direcciones de ruta en un mismo viaje, un viaje puede tener entre dos o varias direcciones de ruta.

2.4.4 Comentario

La clase Comentario se trata de una clase asociativa ya que es una propiedad de la relación. Es una clase asociativa de la relación entre las clases Viaje y Usuario. En esta clase los atributos que tendrá serán el usuario que envía el comentario, el viaje al que hace referencia, el comentario en cuestión y la fecha en la que se efectúa el mismo.

2.4.5 Mensaje

Esta clase representa un mensaje enviado entre dos usuarios de nuestra aplicación. Sus atributos serán el usuario que envía el mensaje, el usuario que lo recibe, la fecha en la que se efectúa y el mensaje en cuestión. Relaciones

La clase usuario tiene 2 relaciones de “uno-a-varios” con Mensaje denominadas remitente y destinatario. Cada mensaje tiene un único remitente y un único destinatario y un usuario puede ser remitente o destinatario de varios mensajes.

2.4.6 Vehículo

Esta clase representa los vehículos utilizados para la realización de los viajes. Los atributos de esta clase serán los datos del vehículo, el tipo de vehículo, su número de plazas y su la marca, modelo y color. Relaciones

La clase vehículo tiene una relación de “varios-a-varios” con la clase usuario porque un vehículo puede ser utilizado por varios usuarios y un usuario puede tener varios vehículos.

La clase viaje tiene una relación con multiplicidad “uno-a-varios” con la clase vehículo ya que cada viaje debe tener un único vehículo asociado y un vehículo puede participar en varios viajes.

42

2.4.7 Puntuación

La clase Puntuación representa cada una de las calificaciones que se asignan mutuamente los usuarios que han participado en un viaje. Los atributos de la clase Puntuación serán el usuario emisor, el receptor, la puntuación de cada uno de los apartados puntuables acerca del viaje (puntualidad, amabilidad…), y el viaje sobre el que se realiza la puntuación. Relaciones

La clase usuario tiene 2 relaciones de “uno-a-varios” con puntuación denominadas emisor y receptor. Cada puntuación tiene un único usuario emisor y un único receptor y cada usuario podrá ser emisor o receptor de varias puntuaciones.

La clase viaje tiene una relación “uno-a-varios” con la clase puntuación. De un mismo viaje existirán tantas puntuaciones como pasajeros hayan participado en el viaje. Una puntuación sólo hará referencia a un viaje.

2.4.8 Dirección_de_ruta

Esta clase representará las direcciones de origen y destino del viaje, y las posibles paradas intermedias que puede tener el viaje. Los atributos que tendrá esta clase serán la dirección, el tipo de localidad que será (origen, destino o paso) y el viaje en el que tomará parte. Relaciones

Está relacionada con las clases Viaje y Usuario mediante una relación ternaria. Un viaje tendrá dos o más direcciones, un usuario puede dar de alta varias direcciones de ruta en un mismo viaje y una dirección puede ser utilizada en varios viajes.

43

3. Diseño

3.1. Introducción En este apartado se detalla el diseño de la base de datos, el diseño de las interfaces y la arquitectura la nuestra aplicación.

3.2. Diseño de la base de datos

3.2.1 Modelo entidad – relación

44

Vamos a pasar a comentar el diagrama de entidad – relación que hemos desarrollado. Encontramos: 3.2.1.1 Vehículo (Entidad fuerte) Atributos

Matrícula Foto Consumo aproximado Marca Modelo Tipo Color Año Número de plazas

Clave primaria

Matrícula

Relaciones Está relacionada con viaje mediante la relación vehículo de. Tiene una cardinalidad en la relación de (0,N). De esta forma podemos dar de alta un vehículo sin que forme parte de viaje alguno y especificamos que un vehículo puede formar parte de más de un viaje.

Está relacionada con el tipo de entidad usuario mediante la

relación Pertenece a. Su cardinalidad en la relación es (1,N) ya que un vehículo debe pertenecer, como mínimo a un usuario y como máximo a varios.

3.2.1.2 Usuario (Entidad fuerte) Atributos

Nombre de usuario E-Mail Nombre Primer apellido Segundo apellido Contraseña Foto Teléfono Localidad Comunidad autónoma Código postal Número Calle Puerta

Clave primaria

Nombre de usuario

Unique E-Mail

45

Relaciones Está relacionada con el tipo de entidad débil mensaje mediante las

relaciones origen y destinatario. En ambos casos tienen una cardinalidad en la relación de (0,N). Podemos dar de alta un usuario sin que sea destinatario u origen de mensaje alguno y podemos a su vez ser destinatarios u origen de varios mensajes.

Tiene una relación reflexiva denominada amistad. Tiene cardinalidad

(0,N). Puede tener tantos amigos como se quiera y podemos tener un usuario sin amigos.

Está relacionado con vehículo mediante la relación Pertenece a. Su

cardinalidad en la relación es de (0,N) . Podemos tener un usuario sin vehículos y un usuario puede tener tantos vehículos como su economía se lo permita.

Está relacionada con la entidad débil estadística mediante sobre.

Tiene una cardinalidad en la relación de (0,N). Puede no tener estadísticas o aparecer varias veces, tantas como sesiones haya iniciado en la aplicación.

Está relacionada con el tipo de entidad débil puntuación mediante

emisor y receptor. Tiene una cardinalidad en la relación de (0,N) en ambos casos. Podemos dar de alta un usuario sin que sea emisor o receptor de puntuación alguna y podemos a su vez ser emisores o receptores de varias puntuaciones.

Con el tipo de entidad viaje comparte la relación Inscrito en. Su

cardinalidad en la relación es de (0,N). Podemos dar de alta usuarios sin que estén previamente inscritos en viaje alguno y podemos inscribirnos en tantos viajes como queramos.

Mantiene una relación con la entidad débil comentario. Denominamos

a esta relación Autor de y tiene una cardinalidad en la relación de (0,N). Podemos escribir tantos comentarios como necesitemos.

Tiene una relación ternaria con los tipos de entidad Dirección de ruta

y viaje. Esta relación se denomina asociación dirección. Tiene una cardinalidad en la relación de (0,1) ya que .una dirección de ruta dada de alta en un viaje sólo puede ser inscrita por un único usuario.

Mantiene una relación con la entidad débil Usuario Facebook

denominada Es un. Tiene una cardinalidad en la relación de (0,1). Un usuario sólo puede participar una vez en la relación con Usuario Facebook.

46

3.2.1.3 Viaje (Entidad fuerte) Atributos

Id Precio Fecha Número de pasajeros Equipaje de mano Maleta grande Fumador Mascotas

Clave primaria

Id

Relaciones Esta relacionada con el tipo de entidad vehículo mediante la relación vehículo de. Tiene una cardinalidad en la relación de (1,1). Cada viaje debe tener un único vehículo asociado.

Está relacionada con usuario mediante la relación Inscrito en.

Tiene una cardinalidad en la relación de (1,N). Un viaje al menos tendrá que tener inscrito a un usuario y podrá tener tantos inscritos como sea posible.

Mantiene una relación con la entidad débil comentario.

Denominamos a esta relación Referido a y tiene una cardinalidad en la relación de (0,N). Podrán referirse a un viaje tantos comentarios como se precise. Un viaje no está obligado a tener comentario alguno.

Tiene una relación ternaria con los tipos de entidad Dirección de

ruta y Usuario. Esta relación se denomina asociación dirección. Tiene una cardinalidad en la relación de (1,N) ya que un viaje poseerá varias direcciones de ruta inscritas por el mismo o varios usuarios.

Con el tipo de entidad Puntuación existe una relación

denominada Respecto a. Su cardinalidad es de (0,N) ya que un viaje puede no tener ninguna puntuación emitida o puede tener varias puntuaciones.

47

3.2.1.4 Dirección de ruta (Entidad fuerte) Atributos

Id Localidad Calle Número Código postal Tipo Confirmada Coordenada_X Coordenada_Y

Clave primaria

Id

Relaciones Tiene una relación ternaria con los tipos de entidad viaje y Usuario. Esta relación se denomina asociación dirección. Tiene una cardinalidad en la relación de (1,N) ya que una dirección de ruta puede aparecer en varios viajes y ser inscrita por varios usuarios en distintos viajes.

3.2.1.5 Puntuación (Entidad débil) Atributos

Criterio1 Criterio2 Criterio3 Criterio4 Total

Clave primaria

Emisor, receptor, viaje

Relaciones Está relacionada con el tipo de entidad usuario mediante las relaciones emisor y receptor. En ambos casos tienen cardinalidad en las relaciones de (1,1). Una puntuación únicamente tiene un usuario emisor y un receptor.

Tiene una relación con el tipo de entidad viaje denominada

Respecto a. Tiene una cardinalidad en la relación de (1,1) ya que una puntuación debe de hacer referencia a un único viaje.

3.2.1.6 Mensaje (Entidad débil) Atributos

Abierto Asunto Contenido Fecha

Clave primaria

Remitente, Destinatario, fecha

Relaciones Está relacionada con el tipo de entidad usuario mediante remitente y destinatario. En ambos casos tienen cardinalidad en las relaciones de (1,1). Un mensaje únicamente tiene un usuario remitente y un usuario destinatario.

3.2.1.7 Comentario (Entidad débil) Atributos

Fecha Contenido Clave primaria

Usuario, Viaje, Fecha

Relaciones Tiene una relación con Viaje. Esta relación se denomina Referido a. Tiene una cardinalidad en la relación de (1,1). Un comentario debe estar relacionado únicamente con un viaje.

Mantiene una relación con Usuario denominada Autor de. Tiene

una cardinalidad en la relación de (1,1). Un comentario debe estar relacionado únicamente con un usuario.

48

Unique

3.2.1.8 Usuario_Facebook (Entidad débil) Atributos

Facebook_id Clave primaria

Usuario

Relaciones Está relacionada con el tipo de entidad usuario mediante la relación Es un. Tiene una cardinalidad en la relación de (1,1). Todo Usuario Facebook debe estar relacionado sólo con un usuario.

3.2.2 Modelo relacional

Mensaje

Remitente Destinatario Fecha Asunto Contenido Abierto CE: Usuario CE: Usuario

Vehículo

Matrícula Marca Modelo Color Consumo aproximado

Año Tipo Número de plazas

Foto

Vehiculo_usuario

Usuario Vehículo CE: Usuario CE: Vehículo

Comentario

Usuario Viaje Fecha Contenido CE: Usuario CE: Viaje

Viaje

Id Precio Fecha Vehículo Fumador Mascota CE: Vehículo

Equipaje de mano Maleta grande Estado Número de pasajeros

Usuario

Nombre de

Usuario

Nombre 1º Apellido

2º Apellido

E-Mail Teléfono Tipo Foto

Contraseña Comunidad

Autónoma Localidad Código

postal Calle Número Fecha Puerta

Amistad

Usuario1 Usuario2 Confirmada CE: Usuario CE: Usuario

49

Usuario_inscrito

Usuario Viaje rol CE:Usuario CE:Viaje

Puntuación

Emisor Receptor Viaje CE: Usuario CE: Usuario CE: Viaje Criterio1 Criterio2 Criterio3 Criterio4 Total Viaje_direcciónRuta_usuario

Viaje Dirección Usuario CE:Viaje CE: Dirección de ruta CE:Usuario Descripción Confirmada Tipo

Dirección_de_ruta

Id Localidad Calle Número Código Postal

Coordenada_x Coordenada_y

Usuario_fb

Usuario Facebook_id CE:Usuario

50

A continuación, mostramos de una manera gráfica el modelo relacional de nuestra base de datos:

51

3.3. Interfaces En este apartado mostraremos las interfaces de nuestra aplicación separándolas dependiendo del usuario que pueda acceder a las mismas.

3.3.1 Interfaces del usuario Visitante

El usuario visitante únicamente tendrá acceso a dos pantallas:

3.3.1.1 Pantalla de inicio

Descripción Es la puerta de acceso a nuestra aplicación. Existen apartados para que accedan los usuarios básicos o los usuarios Facebook y para el registro de usuarios.

Viene de - Interfaces accesibles desde ésta

3.3.1.2 Registro (Botón “Regístrese aquí”) 3.3.2.1 Pantalla principal (Botón “Acceso a la aplicación”) 3.3.3.1 Pantalla principal Facebook. (Botón “acceda con su

cuenta de Facebook”)

52

3.3.1.2 Registro

Descripción En esta pantalla un usuario visitante podrá registrarse como usuario Básico. El registro está dividido en dos fases. En la primera se deberán especificar los datos básicos como pueden ser el E-Mail o el nombre de usuario y en la segunda los datos personales.

Viene de 3.3.1.1 Pantalla de inicio (Botón “Regístrese aquí”) Interfaces accesibles desde ésta

3.3.1.1 Pantalla de inicio (Botón “Cancelar”) 3.3.1.1 Pantalla de inicio (“Finalizar”)

53

3.3.2 Interfaces del usuario Básico

A continuación detallaremos las interfaces relacionadas con los usuarios básicos. Desde cualquier pantalla de la aplicación, son accesibles las siguientes interfaces: 3.3.2.1 Pantalla principal (Logotipo). 3.3.2.2 Pantalla de gestión de perfil (“Mi perfil”). 3.3.2.5 Mensajes (“Mensajes”). 3.3.2.8 Amigos (“Amigos”). 3.3.2.14 Mis viajes (“Viajes”). En todo momento el usuario podrá salir de la aplicación pulsando sobre la opción que aparece en el menú. El usuario volverá a la portada de la aplicación y su sesión quedará finalizada.

3.3.2.1 Pantalla principal

Descripción Ésta es la pantalla inicial que se encontrará el usuario básico al acceder a nuestra aplicación. Podrá acceder a 4 módulos en los que gestionar su perfil, sus mensajes, sus amigos y sus viajes. También podrá ver los 10 últimos viajes propuestos por sus amigos, los 10 últimos viajes propuestos por el resto de usuarios y las alertas que haya recibido.

Viene de 3.3.1.1 Pantalla de inicio (Botón “Acceso a la aplicación”) En cualquier momento podremos volver a la pantalla

principal pulsando sobre el logotipo de la aplicación. Interfaces accesibles desde ésta

3.3.2.2 Pantalla de gestión de perfil (“Mi perfil”) 3.3.2.5 Mensajes (“Mensajes” o “¡Mensajes sin leer!”) 3.3.2.8 Amigos (“Amigos”) 3.3.2.14 Mis viajes (“Viajes”) 3.3.2.26 Estudio de propuestas de dirección de paso

(“¡Dirección por confirmar!”) 3.3.2.10 Estudio de solicitud de amistad (“¡Amigo por

confirmar!”)

54

3.3.2.2 Pantalla de gestión del perfil

Descripción En esta pantalla el usuario puede ver y cambiar cualquiera de sus datos personales excepto su nombre de usuario. Para cambiar cualquier dato debe borrar el dato correspondiente registrado hasta el momento, cambiarlo por el nuevo dato y pulsar sobre confirmar modificación. El usuario puede ver, añadir o borrar vehículos de su perfil pulsando sobre la pestaña “Mis vehículos”.

Viene de 3.3.2.1 Pantalla principal (“Mi perfil”) Interfaces accesibles desde ésta

3.3.2.3 Añadir vehículo (“Botón Añadir vehículo”) 3.3.2.4 Modificar vehículo ( tabla de vehículos)

El botón confirmar modificación nos devolverá a la misma página. La (Eliminar vehículo) de la tabla de vehículos nos devuelve a la misma página.

55

Nota: Toda operación importante o irreversible que se ejecute dentro de la aplicación, requerirá confirmación para llevarla a cabo. Este es el caso de, por ejemplo “Dar de baja un usuario”.

56

3.3.2.3 Añadir vehículo

Descripción El usuario facilita la matrícula del vehículo a añadir. En el caso de que no esté dada de alta previamente, se le presentará un formulario para cumplimentar los datos necesarios. En el caso de que ya esté dado de alta, se le mostrará el mismo formulario con los datos del vehículo, los cuales el usuario podrá modificar.

Viene de 3.3.2.2 Pantalla de gestión de perfil (Botón “Añadir vehículo”)

Interfaces accesibles desde ésta

3.3.2.2 Pantalla de gestión de perfil (Botones “Atrás” o “Confirmar”)

3.3.2.4 Modificar vehículo

Descripción En esta pantalla aparecen los datos a modificar del vehículo que el usuario ha seleccionado. Cambiamos cualquiera de los datos y confirmamos la operación.

Viene de 3.3.2.2 Pantalla de gestión de perfil ( tabla de vehículos) Interfaces accesibles desde ésta

3.3.2.2 Pantalla de gestión de perfil (Botones “Atrás” o “Confirmar”)

57

3.3.2.5 Mensajes

Descripción En esta pantalla podremos ver los mensajes que nos han enviado. Si pulsamos sobre cualquier campo de la tabla, accederemos al mensaje en cuestión. Desde esta pantalla podemos crear un nuevo mensaje o borrar uno existente pulsando sobre el icono eliminar mensaje ( ).

Viene de 3.3.2.1 Pantalla principal (“Mensajes”) Interfaces accesibles desde ésta

3.3.2.6 Ver mensaje ( ) 3.3.2.7 Nuevo mensaje (Botón “Crear nuevo mensaje”)

3.3.2.6 Ver mensaje

Descripción Desde esta pantalla podremos ver quien nos ha enviado el mensaje, el asunto, la fecha del mismo y su contenido. Si pulsamos en “eliminar mensaje” el mensaje quedará borrado.

Viene de 3.3.2.5 Mensajes ( ) Interfaces accesibles desde ésta

3.3.2.5 Mensajes (Botones “Volver” o “Eliminar mensaje”)

58

3.3.2.7 Nuevo mensaje

Descripción Indicaremos el usuario al que queremos mandar el mensaje, el asunto y el propio contenido del mensaje antes de pulsar sobre el botón “Enviar”.

Viene de 3.3.2.5 Mensajes (“Crear nuevo mensaje”) 3.3.2.9 Ver usuario (“Enviar mensaje”)


3.3.2.5 Mensajes (Botones “Volver” o “Enviar”)

3.3.2.8 Amigos

Descripción Accederemos a esta pantalla tras pulsar sobre “Amigos” en la pantalla inicial. En la misma encontramos un listado de los amigos que hemos ido acumulando en la aplicación. Podremos borrar un amigo pulsando sobre el icono o ver su perfil seleccionando en la tabla que se nos presenta. Por último podremos buscar un usuario de la aplicación pulsando sobre el botón “Buscar usuario”.

Viene de 3.3.2.1 Pantalla principal (“Amigos”) Interfaces accesibles desde ésta

3.3.2.9 Ver usuario ( ) 3.3.2.12 Buscar usuario (Botón “Buscar usuario”)

El icono (Eliminar amistad) nos devolverá a la misma página.

59

3.3.2.9 Ver usuario

Descripción Aquí podemos ver los datos de un usuario y enviarle un mensaje, ver sus viajes o solicitar su amistad.

Viene de 3.3.2.8 Amigos ( ) 3.3.2.13 Resultado de la búsqueda de usuarios ( )


3.3.2.7 Nuevo mensaje. (Botón “Enviar mensaje”) 3.3.2.11 Ver viajes de usuario. (Botón “Ver viajes del

usuario”) (Botón “Solicitar amistad”) nos devolverá a la misma pantalla en la que nos encontramos.

3.3.2.10 Estudio de solicitud de amistad

Descripción En esta pantalla el usuario que recibe la solicitud de amistad podrá ver las solicitudes de amistad pendientes de aceptar. A esta pantalla se accederá desde la alerta que se genera en la pantalla inicial al solicitar una amistad.

Viene de 3.3.2.1 Pantalla principal (“¡Amigo por confirmar!”) Interfaces accesibles desde ésta

3.3.2.1 Pantalla principal. (Botón “Volver”) Tanto el icono (“Rechazar amistad”) como el icono (“Aceptar amistad”) nos devolverán a la misma página.

60

3.3.2.11 Ver viajes de usuario

Descripción Desde la pantalla ver usuario se puede acceder a ésta. En ella se visualizan los viajes que un usuario ha efectuado. Pulsando sobre la lupa podremos ver los datos de los viajes que se encuentren abiertos.

Viene de 3.3.2.9 Ver usuario (Botón “Ver viajes del usuario”) Interfaces accesibles desde ésta

3.3.2.9 Ver usuario (Botón “Volver”). 3.3.2.17 Ver viaje ( )

3.3.2.12 Buscar usuario

Descripción En esta pantalla se accede desde la interfaz 2.2.8 (“Amigos”). Podremos buscar un usuario rellenando uno o varios de los campos que podemos ver en la imagen.

Viene de 3.3.2.8 Amigos (Botón “Buscar usuario”) Interfaces accesibles desde ésta

3.3.2.13 Resultado de la búsqueda de usuarios (Botón “Buscar”)

3.3.2.8 Amigos (Botón “Volver”)

61

3.3.2.13 Resultado de la búsqueda de usuarios

Descripción Aquí veremos los usuarios que ha encontrado la búsqueda que hemos efectuado. Podremos acceder a sus perfiles pulsando sobre la lupa que aparece al lado de cada fila.

Viene de 3.3.2.12 Buscar usuario (Botón “Buscar”) Interfaces accesibles desde ésta

3.3.2.12 Buscar usuario (Botón “Volver”) 3.3.2.10 Ver usuario ( )

62

3.3.2.14 Mis viajes

Descripción En esta pantalla, a la que se accede seleccionando “Mis viajes” en la pantalla inicial, nos encontramos una tabla en la que podemos ver los viajes que hemos realizado. Para cada uno de ellos tenemos la opción de desapuntarnos, dar de baja un viaje que hayamos dado de alta nosotros y dar de alta un viaje. En el caso de haber participado en un viaje y que éste haya finalizado, podremos valorar al resto de usuarios pulsando en el mazo ( ). Si el viaje continúa en estado abierto podremos verlo pulsando sobre la lupa.

Viene de 3.3.2.1 Pantalla principal (“Viajes”) Interfaces accesibles desde ésta

3.3.2.15 Buscar viaje. (Botón “Buscar viaje”) 3.3.2.17 Ver viaje. ( ) 3.3.2.24 Ver viaje sin conductor. ( ) 3.3.2.27 Ver viaje en el que ya estamos apuntados. ( ) 3.3.2.27 Valorar usuario ( ) 3.3.2.18 Dar de alta un viaje como conductor (Botón “Dar

de alta viaje como conductor”) 3.3.2.21 Dar de alta un viaje como pasajero (Botón “Dar de

alta viaje como pasajero”) El icono nos permitirá eliminar un viaje o desapuntarnos del mismo cuando sea posible.

63

3.3.2.15 Buscar viaje

Descripción Aquí podremos rellenar cualquiera de los campos que el formulario “Buscar viaje” nos ofrece y buscar un viaje que ya haya sido dado de alta y se encuentre en estado abierto.

Viene de 3.3.2.14 Mis viajes (Botón “Buscar viaje”) Interfaces accesibles desde ésta

3.3.2.14 Mis viajes (Botón “Volver”) 3.3.2.16 Resultado de la búsqueda de viajes (“Botón

Buscar”)

3.3.2.16 Resultado de la búsqueda de viaje

Descripción Aquí podremos ver los viajes que ha encontrado la aplicación. Podremos acceder a la información detallada de los viajes pulsando sobre la lupa que aparece al lado de cada uno de ellos, siempre que se encuentren en estado abierto.

Viene de 3.3.2.15 Buscar viaje (Botón “Buscar”) Interfaces accesibles desde ésta

3.3.2.15 Buscar viaje. (Botón “Volver”) 3.3.2.17 Ver viaje ( ) 3.3.2.24 Ver viaje sin conductor ( )

64

3.3.2.17 Ver viaje

Descripción Aquí podemos ver los datos del viaje, su recorrido en Google Maps, publicar un comentario y apuntarnos al mismo. Solo podremos acceder a esta pantalla si el viaje se encuentra en estado abierto, todavía no tiene conductor designado y no estamos inscritos en el mismo.

Viene de 3.3.2.14 Mis viajes ( ) 3.3.2.16 Resultado de la búsqueda de viaje ( ) 3.3.2.11 Ver viajes de usuario ( )


3.3.2.14 Mis viajes (Botones “Volver” o “Apúntate!!”) El (Botón “Publicar comentario”) nos devolverá a la misma pantalla incluyendo el comentario que hayamos escrito.

65

3.3.2.18 Dar de alta un viaje como conductor

Descripción Si queremos dar de alta un viaje como conductor debemos rellenar los campos que nos aparecen en este formulario. Si queremos añadir más de una dirección de paso, rellenaremos los campos de la tabla definidos para tal fin. Una vez estemos conformes con nuestra selección pulsaremos sobre “Generar recorrido y precio estimado por pasajero”.

Viene de 3.3.2.14 Mis viajes (Botón “Dar de alta viaje como conductor”)


3.3.2.14 Mis viajes ( Botón “Cancelar”) 3.3.2.19 Recorrido y precio generado (Botón “Generar

recorrido y precio estimado por pasajero”) Añadir más direcciones de paso generará nuevas filas a la tabla.

66

3.3.2.19 Recorrido y precio generado

Descripción Tras rellenar los datos para dar de alta el viaje, nos aparecerá el recorrido en Google Maps, un precio estimado del mismo y un campo para que definamos nosotros el precio del viaje. Podemos poner el precio generado u otro diferente.

Viene de 3.3.2.18 Dar de alta un viaje como conductor (Botón “Generar recorrido y precio estimado por pasajero”)


3.3.2.14 Mis Viajes (Botón “Cancelar”) 3.3.2.20 Confirmación de viaje (Botón “Generar viaje”).

3.3.2.20 Confirmación de viaje

Descripción En esta pantalla aparecerán todos los datos relacionados con el viaje. No los podremos modificar y servirá para que confirmemos el viaje que estamos dando de alta.

Viene de 3.3.2.19 Recorrido y precio generado (Botón “Generar viaje”)


3.3.2.14 Mis Viajes (Botón “Cancelar” o Botón “Dar de alta viaje”)

67

3.3.2.21 Dar de alta un nuevo viaje como pasajero

Descripción Si damos de alta un viaje como pasajero, la mecánica es la misma que como conductor, exceptuando que al figurar el usuario como pasajero no podrá asociar un vehículo al mismo y no podrá fijar un precio. Será el conductor el que lo fije.

Viene de 3.3.2.14 Mis viajes (Botón “Dar de alta viaje como pasajero”)


3.3.2.22 Recorrido generado pasajero (Botón “Generar recorrido”)

3.3.2.14 Mis viajes (Botón “Cancelar”) Añadir más direcciones de paso generará nuevas filas a la tabla.

3.3.2.22 Recorrido generado pasajero

Descripción En este caso, al generar el recorrido vemos que no podemos fijar un precio por la razón expuesta en el apartado anterior.

Viene de 3.3.2.21 Dar de alta un viaje como pasajero (Botón “Generar recorrido”)


3.3.2.14 Mis viajes (Botón “Cancelar”) 3.3.2.23 Confirmación viaje generado pasajero (Botón

“Generar viaje”)

68

3.3.2.23 Confirmación viaje generado pasajero

Descripción En esta pantalla aparecerán todos los datos relacionados con el viaje. No los podremos modificar y servirá para que confirmemos el viaje que estamos dando de alta.

Viene de 3.3.2.22 Recorrido generado pasajero (Botón “Generar viaje”)


3.3.2.14 Mis Viajes (Botón “Cancelar” o Botón “Dar de alta viaje”)

69

3.3.2.24 Ver viaje sin conductor

Descripción Si encontramos un viaje en estado abierto en el que todavía no tenemos definido un conductor, se nos ofrecerá la posibilidad de apuntarnos al mismo como pasajero o conductor.

Viene de 3.3.2.14 Mis viajes ( ) 3.3.2.16 Resultado de la búsqueda de viaje ( ) 3.3.2.11 Ver viajes de usuario ( )


3.3.2.14 Mis viajes. (Botón “Apuntarnos como pasajero”) 3.3.2.25 Seleccionar vehículo conductor. (Botón

“Apuntarnos al viaje como conductor”)

70

3.3.2.25 Seleccionar vehículo conductor

Descripción Tendremos que elegir un vehículo y pulsar en “Seleccionar”. Tras esto nos aparecerá la pantalla “Recorrido Apuntarnos a viaje como conductor” (3.3.2.26) en la que veremos el trayecto, se generará un precio estimado del viaje e introduciremos los datos necesarios para dar de alta el viaje.

Viene de 3.3.2.24 Ver viaje sin conductor (Botón “Apuntarnos al viaje como conductor”)


3.3.2.14 Mis viajes. (Botón “Cancelar”) 3.3.2.26 Apuntarnos a viaje como conductor (Botón

“Seleccionar”)

3.3.2.26 Apuntarnos a un viaje como conductor

Descripción Una vez seleccionado el vehículo nos aparecerá esta pantalla en la que podremos definir las condiciones del viaje y ser designados como conductores del mismo.

Viene de 3.3.2.25 Seleccionar vehículo conductor (Botón “seleccionar”)


3.3.2.14 Mis viajes. (Botones “Cancelar” “Confirmar viaje”)

71

3.3.2.27 Ver viaje abierto en el que ya estamos apuntados

Descripción Si accedemos a la opción mis viajes de la pantalla inicial y seleccionamos algún viaje en el que nos hayamos apuntado y se encuentre en estado abierto, veremos una pantalla como la que se nos presenta, en la que vemos la descripción del viaje, podemos hacer comentarios y podemos proponer una localidad de paso.

Viene de 3.3.2.14 Mis viajes ( ) 3.3.2.16 Resultado de la búsqueda de viajes ( ) 3.3.2.10 Ver viajes de usuario ( )


3.3.2.14 Mis viajes (Botón “Volver”) 3.3.2.28 Proponer dirección de paso (Botón “Proponer

dirección de paso”) El icono en las tablas usuarios inscritos y comentarios, aparecerá solamente cuando acceda a esta pantalla el usuario promotor conductor o promotor pasajero del viaje. En la primera tabla, el icono permitirá expulsar a un usuario de un viaje siempre que éste no sea el conductor del viaje. El icono de la tabla comentario permite borrar un comentario que el usuario promotor considere inadecuado.

72

3.3.2.28 Proponer dirección de paso

Descripción En esta pantalla podemos proponer al conductor una localidad de paso en la ruta propuesta.

Viene de 3.3.2.27 Ver viaje abierto en el que ya estamos apuntados (Botón “Proponer dirección de paso”)


3.3.2.27 Ver viaje abierto en el que ya estamos apuntados (Botones “Proponer” y “volver”)

3.3.2.29 Estudio de propuestas de dirección de paso

Descripción Si el viaje en el que somos conductores, recibe una solicitud de localidad de paso, en las alertas de la pantalla principal aparecerá un mensaje informándonos de este hecho. Si pulsamos sobre el mismo, accederemos a esta pantalla, en la que nos aparecen los datos de la localidad a estudiar y los minutos que este cambio supondrá sobre el recorrido inicial. Podremos aceptarla o rechazarla.

Viene de 3.3.2.1 Pantalla principal. (“¡Dirección por confirmar!”) Interfaces accesibles desde ésta

3.3.2.1 Pantalla principal. (Botón “Volver”) Tanto el icono como que se utilizan para rechazar o confirmar una dirección propuesta nos devolverán a la pantalla en la que estamos.

73

3.3.2.30 Valorar usuario

Descripción Si un viaje en el que hemos participado se encuentra en estado finalizado, desde la opción mis viajes podemos seleccionarlo y valorar a los usuarios que han participado en el mismo.



3.3.2.14 Mis viajes (Botones “Volver” o “Valorar usuarios”)

74

3.3.3 Interfaces del usuario Facebook

Vamos a analizar las pantallas que cambian respecto a las que hemos descrito en el apartado de usuario básico. En la descripción de cada una de las pantallas indicaremos a qué pantalla sustituye de las presentadas para los usuarios básicos. Estas pantallas estarán integradas en el entorno de Facebook. Desde cualquier pantalla de la aplicación son accesibles las siguientes interfaces: 3.3.3.1 Pantalla principal usuarios Facebook (Logotipo). 3.2.2.2 Pantalla de gestión de perfil (“Mi perfil”). 3.2.2.5 Mensajes (“Mensajes”). 3.3.3.2 Amigos Facebook(“Amigos”). 3.2.2.14 Mis viajes (“Viajes”).

3.3.3.1 Pantalla principal usuarios Facebook

Descripción Será similar a la del usuario básico salvo que veremos los 10 últimos viajes propuestos por nuestros amigos de Facebook.

Viene de 3.3.1.1 Pantalla inicial (Botón “Acceda con su cuenta de Facebook”)


3.3.2.2 Pantalla de gestión de perfil (“Mi perfil”) 3.3.2.5 Mensajes (“Mensajes” o “¡Mensajes sin leer!”) 3.3.3.2 Amigos Facebook (“Amigos”) 3.3.2.14 Mis viajes (“Viajes”) 3.3.2.29 Estudio de propuestas de dirección de paso

(“¡Dirección por confirmar!”) 3.3.2.10 Estudio de solicitud de amistad (“¡Amigo por

confirmar!”) El icono permite al usuario publicitar el viaje en el que se ha apuntado en su cuenta de Facebook.

75

3.3.3.2 Amigos Facebook

Descripción Al acceder a la opción amigos de la pantalla principal podemos ver que aparece una nueva opción que nos permite buscar los usuarios de Facebook que son amigos nuestros y utilizan nuestra aplicación.

Viene de 3.3.3.1 Pantalla principal usuarios Facebook (“Amigos”) Interfaces accesibles desde ésta

3.3.2.9 Ver usuario ( ) 3.3.2.12 Buscar usuario (Botón (“Buscar usuario”) 3.3.3.3 Listado de amigos de Facebook (Botón “Buscar

amigos de Facebook que utilizan la aplicación”) El icono eliminará la amistad y nos devolverá a la misma página.

3.3.3.3 Listado de amigos de Facebook

Descripción Aquí nos aparecerá un listado de los amigos de Facebook que utilizan la aplicación.

Viene de 3.3.3.2 Amigos Facebook Interfaces accesibles desde ésta

3.3.2.9 Ver usuario ( ) 3.3.3.3 Amigos Facebook (Botón “Volver”)

76

3.3.3.4 Ver viaje en el que ya estamos apuntados Facebook

Descripción Si accedemos a la opción viajes de la pantalla inicial y seleccionamos algún viaje en el que nos hayamos apuntado y se encuentre en estado abierto veremos una pantalla como la que se nos presenta, en la que vemos la descripción del viaje, podemos hacer comentarios y podemos proponer una localidad de paso.



3.3.2.14 Mis viajes (Botón “Volver”) 3.3.2.28 Proponer dirección de paso (Botón “Proponer

dirección de paso”) El icono en las tablas usuarios inscritos y comentarios, aparecerá solamente cuando acceda a esta pantalla el usuario promotor conductor o promotor pasajero del viaje. En la primera tabla, el icono permitirá expulsar a un usuario de un viaje siempre que éste no sea el conductor del viaje. El icono de la tabla comentario permite borrar un comentario que el usuario promotor considere inadecuado. El icono permite al usuario publicitar el viaje en el que se ha apuntado en su cuenta de Facebook.

77

3.4. Arquitectura de la aplicación La aplicación constará de una arquitectura de tres capas correspondientes a la capa de presentación, la capa de lógica de negocio y la capa de persistencia. En el caso de las capas de lógica de negocio y persistencia, mostraremos respectivamente un diagrama de clases y lo explicaremos brevemente.

3.4.1 Capa de presentación.

La capa de presentación estará formada por el código HTML, CSS, PHP y JavaScript que presentará los datos obtenidos de la capa de lógica de negocio de forma útil, intuitiva y comprensible para el usuario. Se encargará a su vez de validar los datos que el usuario introduzca en la aplicación, con el fin de garantizar en la medida de lo posible la veracidad de los mismos.

3.4.2 Capa de lógica de negocio

La capa de lógica de negocio se encargará de realizar las tareas relacionadas con los procesos naturales del ámbito de nuestra aplicación. La capa de lógica de negocio de nuestra aplicación constará de dos apartados, por un lado encontraremos el modelo de dominio y por otro el modelo de negocio. El modelo de dominio de nuestra aplicación, lo formarán las clases que hemos identificado en el apartado 2.4, las cuales son las entidades de negocio básicas sobre las que se construye nuestra aplicación. Cada clase contará con sus respectivos atributos, los getters y setters de los mismos y el constructor de la clase. A continuación podemos observar el diagrama de clases del modelo de dominio de nuestra aplicación. En este caso, por mejorar la legibilidad de la imagen, no hemos incluido los métodos en las clases.

78

El modelo de negocio de nuestra aplicación lo formarán las clases que recogen los métodos que realizan las operaciones básicas de la aplicación. No cuentan con atributos y únicamente tienen un constructor sin parámetros. Todos estos métodos podrían estar recogidos dentro de una única clase, pero dada la cantidad de métodos, hemos estimado que, para su mejor comprensión, lo mejor era organizarlos agrupándolos dependiendo de la clase del modelo de dominio con la que estarían más relacionados. De esta forma hemos creado una clase del modelo de negocio por cada una del modelo de dominio. Para mejorar la legibilidad del diagrama que mostramos a continuación, se han omitido parte de los argumentos de los métodos.

79

3.4.3 Capa de persistencia

Esta capa canalizará la comunicación entre la base de datos y la capa de lógica de negocio de nuestra aplicación. En particular, se encargará de atender las solicitudes que la capa de lógica de negocio le realice para la obtención de datos de la base de datos de la aplicación o cuando se necesite incluir o eliminar algún dato de la base de datos. La implementación de esta capa se apoya fundamentalmente en la definición de una interfaz Persistencia que define los métodos básicos para la persistencia de los objetos de negocio de nuestra aplicación. El objetivo de esta interfaz es preparar la aplicación ante futuros cambios del mecanismo de persistencia. Por ejemplo, actualmente se utilizará una base de datos como mecanismo de persistencia, por lo que se ha definido una clase PersistenciaAplicación que implementa los métodos de la interfaz Persistencia considerando ese método de almacenamiento. Si en el futuro se eligiera otro mecanismo de persistencia, por ejemplo ficheros XML, se implementaría dicha interfaz y sus métodos teniendo en cuenta dicho mecanismo. Además, se ha añadido una clase llamada Util que se encargará de implementar los métodos propios del manejo de las bases de datos como pueden ser el método conexión o desconexion.

80

4. Implementación

4.1 Introducción Como ya hemos comentado en apartados anteriores, en el desarrollo de nuestra aplicación utilizaremos el lenguaje PHP como lenguaje de programación porque es un lenguaje muy extendido en la programación de aplicaciones Web y poco utilizado en la carrera, de esta forma hemos conseguido ampliar los conocimientos sobre el mismo. Por otra parte, es suficientemente poderoso y versátil como para permitirnos realizar todas las funcionalidades que la aplicación requiere. Utilizamos JavaScript para la inclusión de mapas en la aplicación y como validador de los campos de los formularios. Como sistema gestor de bases de datos utilizamos MySQL debido a que es software libre y nos aporta todas las funcionalidades que la gestión de la base de datos de nuestra aplicación necesita como el uso de transacciones o claves extranjeras.

4.2 Métodos y funcionalidades más interesantes Vamos a pasar a enumerar los métodos y funcionalidades más interesantes de la aplicación y ha comentar cómo hemos implementado cada uno de ellos.

4.2.1 Conexión con la base de datos

Para realizar la conexión con nuestra base de datos, se ha utilizado la librería ADOBD. Esta librería permite abstraerse del sistema gestor de base de datos utilizado, de forma que pueda ser compatible con cualquiera que elijamos. De esta forma, si en cualquier momento decidimos cambiar de sistema gestor de bases de datos, lo único que tendríamos que hacer es cambiar en el archivo de propiedades de la librería ADOBD el tipo de base de datos utilizada y los datos de conexión a la misma. A continuación se muestra el fichero en el que se definen los datos de conexión con la base de datos:

El tipo de base de datos se identifica por mysqli, que es el código a introducir para las bases de datos MySQL posteriores a la versión 4.1.

81

Como hemos comentado anteriormente, para que todos los métodos que necesitan acceder a nuestra base de datos utilicen el mismo método para conectarse y desconectarse, hemos creado una clase nueva, denominada Util, que alberga estos dos nuevos métodos. A modo de ejemplo, en las siguientes líneas se muestra el código correspondiente al método conexión de la clase util.

4.2.2 Validación de los campos de los formularios.

En nuestra aplicación existen varios formularios que nos permiten introducir datos, como pueden ser, los formularios de registro, los de alta de viajes o los de envío de mensajes. Los datos que el usuario introduce en estos formularios requieren una validación para evitar que los datos introducidos sean incoherentes respecto al campo en el que se introducen. Por ejemplo, si el usuario debe introducir su mail, los datos introducidos deben tener al menos estructura de mail. La validación de estos campos se ha realizado mediante lenguaje JavaScript. En particular, utilizamos expresiones regulares para validar que los datos introducidos cumplen el formato que nosotros requerimos o si se deja el campo en blanco en un campo obligatorio. En caso de no cumplir las condiciones, se genera una alerta avisando al usuario de que los datos introducidos no son correctos. Para validar los datos que introducimos cuando tratamos de registrarnos utilizamos las siguientes expresiones regulares:

Cada una de estas expresiones regulares valida un tipo de campos.

82

Observando el siguiente código podemos analizar cómo se realiza la validación de los campos de los formularios:

Como podemos ver en la imagen anterior, se recorren todos los formularios y todos los campos de los mismos y se compara cada campo con su patrón. En el caso de no ser validado o estar vacío, se le asigna a la variable j el valor 1 y el color del fondo del campo analizado pasa a estar en rojo (#FF0000). Posteriormente, se comprueba el valor de la variable j y si éste es 1, se lanza la correspondiente alerta. En el caso de validar los datos de entrada de un viaje es un poco más complicado ya que, como hemos explicado en etapas anteriores, si un viaje se da de alta con menos de 24 horas de margen sobre la fecha de salida, el viaje automáticamente pasa a ser declarado como fallido. Mediante JavaScript validamos que el viaje que se dé de alta tenga al menos 24 horas de margen sobre su hora de salida. Para la validación de esta condición se definido una función, de la que se muestra parte del código a continuación:

Mediante la función anterior, recogemos la fecha y la hora que el usuario ha introducido, la convertimos en un objeto Date para comparar la fecha introducida con la fecha actual. Aplicamos a la fecha introducida por el usuario el método getTime() que devuelve el número de milisegundos transcurridos desde el 1/1/1970. A su vez hacemos lo mismo con la fecha actual añadiéndole 86400000 milisegundos, que son los que componen un día. Si la comparación no resulta satisfactoria, se emite un mensaje de error.

83

4.2.3 Cambio de estado de un viaje.

En nuestra aplicación, un viaje puede tener 4 estados diferentes, abierto, cerrado, finalizado y fallido. En función de las condiciones del viaje, este estado debe cambiar automáticamente. Estos cambios se consiguen mediante el método getEstadoViaje($viaje) que a su vez se apoya en los métodos modificarEstadoViaje($viaje,$estado) y compararFechas($fecha). Todos estos métodos forman parte de la clase ViajeLogica, que se encuentra en el modelo de negocio. Recordamos que, un viaje se encuentra en estado abierto hasta que falta 24 horas para que se lleve a cabo. En ese momento, si alguien se ha apuntado a ese viaje, pasa a estado cerrado. Si no se ha apuntado nadie o no se ha conseguido un conductor, pasa a estado fallido. Si el viaje ha sido declarado como cerrado, una vez pasadas 24 horas del viaje, se declara en estado finalizado. Mediante este método, analizamos el estado a asignar a un viaje. Un viaje estará abierto si quedan más de 24 horas para que se lleve a cabo. Estará cerrado si quedan menos de 24 horas, se ha apuntado alguien y existe un conductor. El viaje estará finalizado si han pasado más de 24 horas desde que se realizó y no se ha declarado como fallido. Un viaje será fallido si no consigue pasajeros o no consigue un conductor. Cada vez que listamos o mostramos un viaje, llamamos al método getEstadoViaje($viaje) para que reasigne correctamente el estado del viaje. A continuación mostramos el código del método getEstadoViaje($viaje):

84

4.2.4 Eliminar usuario.

El método eliminar usuario, lo encontramos en la clase LogicaUsuario, a continuación mostramos el código de dicho método:

Observamos que llama al método eliminarUsuarioP de la clase PersistenciaAplicación del paquete persistencia. En el método eliminar usuario de la clase PersistenciaAplicación, vemos que se listan los viajes de los que el usuario es conductor o promotor y los vehículos que utiliza que no son utilizados por otro usuario de la aplicación.

Si el usuario no tiene viajes o vehículos definidos, no tendremos que eliminar esta información de nuestro sistema y se elimina directamente al usuario. Mediante las claves extranjeras de la base de datos y la propiedad On Delete: Cascade que hemos definido, toda la información del usuario quedará eliminada. A continuación mostramos el código perteneciente al método eliminarUsuarioP que comprueba si el usuario a eliminar tiene viajes o vehículos que dar de baja:

85

Si por el contrario tiene vehículos o viajes que se deben eliminar con el usuario, iniciaremos una transacción en la que eliminaremos previamente todos estos elementos y posteriormente el usuario en cuestión. A continuación se muestra el código de la transacción que elimina del sistema al usuario, sus viajes y sus vehículos:

86

4.2.5 Añadir vehículo.

Encontramos el método aniadirVehiculo en la clase VehiculoLogica. A continuación se muestra el código de este método:

Vemos que esta clase llama al método aniadirVehiculoP de la clase PersistenciaAplicación. Este método controla si el vehículo que estamos intentando añadir, ya está siendo utilizado en la aplicación por parte de otro usuario. En el caso de que este hecho se produzca, únicamente se asociaría al usuario con el vehiculo en la tabla vehículo_usuario, en lugar dar de alta el vehículo de nuevo. A continuación se muestra el código del método aniadirVehiculoP que comprueba si un vehículo ha sido dado de alta previamente en el sistema:

Si el vehículo es introducido por primera vez en el sistema, se inicia una transacción en la que se da de alta el vehiculo y se asocia al usuario. A continuación se muestra el código de la transacción mencionada anteriormente:

87

4.2.6 Añadir y confirmar direcciones de ruta

Una vez apuntados a un viaje, se nos permitirá añadir direcciones de ruta al mismo. Esta tarea la realizaremos a través del método aniadirDireccionDeRuta de la clase DireccionDeRutaLogica. A continuación mostramos el código de dicho método:

Este método llama al método aniadirDireccionDeRutaP de la clase PersistenciaAplicacion. En este método se realiza, mediante una transacción, una inserción de datos en la tabla direccion_de_ruta y la tabla viaje_direccionruta_usuario si no se había utilizado antes esa dirección. Si ya se había utilizado esa dirección anteriormente, no se incluirá dato alguno en la tabla dirección_de_ruta. Únicamente se incluirán los datos necesarios en la tabla viaje_direccionruta_usuario en los que se especificará que la dirección de ruta introducida, no ha sido confirmada. Cuando el usuario que ha dado de alta el viaje acceda a la página principal.php de la aplicación, observará que se le ha generado una alerta avisándole que tiene una dirección de ruta de un viaje que ha dado de alta. Esta alerta se genera mediante el siguiente código:

De esta forma, detectamos si el usuario tiene direcciones por confirmar en alguno de los viajes que ha dado de alta y se le muestra el enlace a la página que le permite gestionar este hecho. Una vez dentro de confirmarDireccion.php, se le muestra un listado de las direcciones por confirmar y puede confirmarlas o eliminarlas. La confirmación de una dirección de ruta, lo que conlleva es que en la tabla viaje_direccionruta_usuario de nuestra base de datos, el campo confirmada pasa de estar a 0 (No confirmada) a 1 (Confirmada).

88

4.2.7 Mostrar diferentes opciones dependiendo del estado del viaje y del rol del usuario.

Al acceder a la opción Viajes de la aplicación, entre otras opciones, se nos muestran los viajes en los que tomamos parte. Dependiendo del estado del viaje y el rol que el usuario tenga dentro del mismo, se nos deben de permitir realizar unas operaciones u otras. Esta funcionalidad se obtiene desde la página viajes.php de la aplicación. Obtenemos el rol del usuario mediante el método getRolUsuarioViaje y el estado del viaje mediante el método getEstadoViaje ya comentado previamente. Una vez tenemos los dos datos, mostraremos las opciones adecuadas para cada combinación. Por ejemplo si el viaje se encuentra en estado finalizado, a los participantes del mismo, se les permitirá votarse entre sí. A continuación se muestra un fragmento de código del fichero viajes.php en el que se comprueba el estado de un viaje:

Se actuará de forma similar en el resto de casos.

4.2.8 Puntuar a compañeros de viaje

Una vez que un viaje se encuentra en estado finalizado, se permite a los usuarios que han tomado parte puntuarse entre sí. Al acceder a la página juzgar.php, se muestran los usuarios que han tomado parte en el mismo y una serie de criterios que debemos puntuar de 0 a 10. Para asegurar que no votamos dos veces al mismo usuario con respecto al mismo viaje, hemos desarrollado el método usuarioPuntuado de la clase PuntuacionLogica. Mediante este método, distinguimos si un usuario ha sido valorado anteriormente. A continuación mostramos el código de dicho método:

89

Llamamos al método usuarioPuntuadoP de la clase PersistenciaAplicación y consultamos a la base de datos si existe un registro con el mismo usuario emisor, receptor y viaje que el que se va a valorar. En el caso de que ya esté valorado, ese usuario no se mostrará para ser juzgado. A continuación se muestra el código del método usuarioPuntuadoP que comprueba si un usuario ya ha puntuado a otro respecto a un viaje:

Para dar mayor realismo a las puntuaciones, pedimos a los usuarios que valoren cuatro criterios de cada compañero de viaje: Puntualidad, Cumplimiento de lo acordado, Simpatía y valoración general. Para calcular la nota final de cada usuario, damos mayor peso a unos criterios frente a otros. A continuación se muestra el código del método puntuarUsuario:

Podemos ver que al puntuar un usuario, tenemos más en cuenta la valoración general del usuario que la simpatía.

90

4.2.9 Buscar Viaje

Una de las funcionalidades fundamentales de la aplicación, es la posibilidad de buscar un viaje. Esta funcionalidad se lleva a cabo mediante el método buscarViaje de la clase ViajeLogica. A continuación se muestra el código del método buscarViaje:

Este método llama al método buscarViajeP de la clase PersistenciaAplicacion que se encarga de buscar los viajes que cumplan con los criterios que hemos definido y devuelve un vector de viajes que incluye los resultados. A continuación se muestra un fragmento de código del método buscarViajeP en el que se asigna una consulta diferente dependiendo de los valores que introduzcamos:

Se permite introducir al usuario el origen, el destino del viaje, la descripción del destino, un precio máximo, la fecha en la que se llevará a cabo, la calle de origen y la calle de destino. No todos los datos son obligatorios, y dependiendo de los datos que introduzca, se realizará una consulta u otra. En el caso de la foto, el usuario únicamente ha introducido origen y destino. Una vez ejecutada la consulta SQL de la imagen, los resultados se incluyen en un vector y se listan en la capa de presentación. Existen combinaciones de datos introducidos no permitidas, por ejemplo, no tendría sentido buscar un viaje únicamente introduciendo la calle de destino. En este caso, la función que estamos analizando en lugar de devolver un vector de viajes, devolverá un número 3, que indicará que la combinación de datos introducida, no está permitida.

91

4.2.10 Integración de Google Maps en la aplicación

En una aplicación como la que hemos desarrollado, es fundamental que los viajes se vean reflejados en un mapa. De esta forma aportamos al usuario de una manera muy visual información fundamental acerca del recorrido que se va a llevar a cabo. En nuestra aplicación, utilizamos las funcionalidades que Google Maps ofrece en tres contextos diferentes:

Geolocalizando las direcciones de ruta introducidas por el usuario. Mostrando el recorrido de un viaje mientras lo estamos dando de alta. Mostrando el recorrido del viaje una vez dado de alta dentro de la aplicación.

Para ello se ha utilizado la versión 3 de la API de Google Maps, que es actualmente la más moderna. Para comenzar a trabajar con esta API, debemos generar una clave que nos identifique. Este trámite se realiza accediendo a la Web https://code.google.com/apis/console. Nos logueamos con nuestro usuario de Google y accedemos a la siguiente pantalla:

Activamos el uso de la API v3 de Google Maps y accedemos a la opción API Access:

En esta pantalla podemos ver la clave que debemos utilizar cada vez que nos conectemos a la API de Google Maps. Una vez visto como generar una clave de uso del API de Google Maps vamos a pasar a comentar cada uno de los tres casos en los que utilizamos las funcionalidades que Google Maps nos ofrece.

92

4.2.10.1 Geolocalización de Direcciones

Esta funcionalidad la implementamos desde el método obtenerCoordenadasP de la clase PersistenciaAplicacion. Implementamos este método en la clase PersistenciaAplicacion debido a que aunque no interactúa con la base de datos, únicamente es utilizado cuando damos de alta una nueva dirección de ruta y no está dada de alta previamente dentro del sistema. De esta forma nos evitamos tener que geolocalizar todas las direcciones introducidas ya que guardamos las coordenadas de las que ya se han introducido previamente. Es importante no realizar más consultas a Google Maps de las necesarias ya que con la licencia gratuita que se nos proporciona, únicamente nos permite geolocalizar 2500 direcciones al día y calcular 2500 rutas al día con 10 puntos intermedios como máximo. Por ello debemos optimizar al máximo las consultas que podamos realizar a Google Maps. Vamos a pasar a analizar el método obtenerCoordenadas. La implementación de este método está basada en los ejemplos y explicaciones proporcionados por la API de Google Maps y que se recogen en la siguiente dirección: https://developers.google.com/maps/documentation/geocoding/?hl=es#GeocodingRequests [10] A continuación se muestra el código del método obtenerCoordenadasP:

Tras analizar el código, podemos observar que se realiza una petición a la dirección que vemos en la variable $url en la que se incluyen la localidad, calle, numero y código postal de la dirección. Como podemos ver, al especificar dentro de la URL la opción components=country:ES limitamos los resultados a España, de esta forma los hacemos mucho más fiables, en un futuro, podría ser eliminada esta propiedad si el uso de la aplicación se internacionalizase. Esta URL nos devuelve un fichero con formato JSON en el que se nos incluyen todos los datos relacionados con la dirección introducida. Utilizamos la función PHP json_decode para poder acceder a los datos suministrados y obtenemos la latitud y longitud de la dirección.

93

4.2.10.2 Cálculo de ruta al dar de alta un viaje

Cuando damos de alta un viaje, una vez introducidos los datos del mismo, se generará un mapa de Google Maps en el que se reflejará la ruta introducida. Para generar el mapa y su ruta se utiliza código JavaScript que hemos desarrollado basándonos en la documentación que Google Maps proporciona respecto a la generación de rutas. Esta información se puede consultar en el siguiente enlace: https://developers.google.com/maps/documentation/javascript/ [11] El código JavaScript necesario para que el cálculo de rutas funcione, está recogido en el fichero rutas.js y está basado en el ejemplo direction waypoints que se encuentra en la siguiente dirección: https://developers.google.com/maps/documentation/javascript/examples/directions-waypoints?hl=es [12] Vamos a analizar el funcionamiento de la generación de rutas desde la página generar_viaje.php de nuestra aplicación. En primer lugar debemos importar el Api de Google Maps a la página donde se ejecuta. Podemos ver como tenemos que proporcionar a Google la clave generada en el apartado anterior.

Cuando se carga la página, se llama a la función JavaScript start() para que genere el mapa con la ruta.

Para que el JavaScript cuente con la dirección de origen, destino y las direcciones de paso, se las proporcionamos por medio de inputs. A continuación, mostramos los inputs que podemos encontrar en la página generar_viaje.php y que denominados start, end y waypoints. Corresponden a las direcciones de origen, destino y paso respectivamente:

Una vez dentro del fichero JavaScript rutas.js veremos la función start() que sirve para inicializar las funciones que realmente necesitamos, que son initialize() y clacRoute(). A continuación mostramos el código de la función start():

94

Tras observar el funcionamiento de la función start() vemos que llama en primer lugar a la función initialize() cuyo código podemos ver a continuación:

Mediante esta función se inicializa el mapa con las coordenadas de la localidad de Nájera que hemos introducido por defecto y se inserta en un DIV con id map_canvas de la página generar_viaje.php. Una vez inicializado el mapa, se llama a la función calcRoute() que será la que dibuje en este mapa el recorrido que necesitamos. Podemos observar a continuación el código de la función calcRoute()

Como podemos observar en el código, se asigna un comienzo, un final y unas direcciones de paso al recorrido. Estos datos se obtienen de los inputs comentados anteriormente que podemos encontrar en la página generar_viaje.php. Mediante la variable request, se asignan las opciones de la consulta que se necesiten, en este caso un origen, un final, unas localidades de paso, que el recorrido se realizará en coche y que Google Maps puede ordenar las localidades de paso de la forma más óptima.

95

Si la consulta se ejecuta de forma correcta, se genera un panel en el que se especifican los tramos, los kilómetros de los que consta cada tramo y el tiempo que cuesta recorrerlos en coche. En el caso de que Google Maps no pueda generar el recorrido, se mostrará un mensaje de error. A continuación podemos ver el fragmento de código de la función calcRoute() en el que podemos observar como se genera el panel informativo del recorrido del viaje:

4.2.10.3 Calculo de ruta al consultar un viaje

El funcionamiento de este método será muy similar al anterior. Únicamente se diferencian en que en lugar de utilizar las direcciones de ruta que el usuario introduce, haciendo que se tengan que geolocalizar para procesarlas, se introducen las coordenadas recuperadas de nuestra base de datos. Realizamos este trámite debido a que Google Maps únicamente nos permite geolocalizar 2500 direcciones al día, por lo que debemos de optimizar al máximo este recurso. En este caso el método del fichero rutas.js que utilizaremos será el calcRoute_coord(). A continuación se muestra parte de su código:

Podemos ver que en lugar de introducir las direcciones directamente como hemos hecho en el caso anterior, necesitamos crear un objeto de tipo google.maps.latLng que englobe la latitud y longitud de cada dirección y que evite a Google geolocalizar cada una de las direcciones introducidas.

96

4.2.11 Cálculo del coste aproximado del viaje

Al dar de alta un nuevo viaje la aplicación nos permite calcular el coste aproximado del mismo. Para ello hemos desarrollado una función JavaScript llamada calcCost() que en función del número de kilómetros y el consumo del vehículo utilizado, calcula el coste del trayecto. Este método se encuentra en el fichero rutas.js, el mismo en el que se encontraban las funciones JavaScript que implementaban las funcionalidades de los mapas Google Maps. La razón de incluirlo en este fichero, es que el dato de la distancia del viaje, se apoya en el suministrado por Google Maps. Por ello, sólo incluiremos esta funcionalidad en páginas en las que se muestre el trayecto con un mapa de Google Maps. El dato del consumo de vehículo se obtiene del que ha introducirlo el usuario al registrar su vehículo y se expresa en litros de combustible utilizados para recorrer 100 kilómetros. El coste del combustible que utilice el vehículo debe introducirlo el usuario, de esta forma evitamos tener que estar constantemente actualizado este dato en la aplicación. A continuación se muestra el código de la función calcCost():

Respecto a la implementación del método, podemos ver que al ejecutar este método JavaScript, introduce una nueva celda en una tabla HTML ya definida anteriormente llamada tablacons. En esa celda se incluye el precio aproximado del viaje obtenido a partir del consumo del vehículo, la distancia del viaje suministrada por Google Maps y el precio del litro de combustible, este último dato debe ser introducido por el usuario. En el caso de que ya se haya generado este resultado anteriormente, al volver a llamar a la función, no se volverá a generar otra fila en la tabla sino que se cambiará el dato contenido en el input.

97

4.2.12 Integración de Facebook en la aplicación

En nuestra aplicación, hemos integrado funcionalidades que implican una comunicación con la cuenta de Facebook del usuario. En particular, entre dichas funcionalidades, permitimos al usuario loguearse en la aplicación con sus datos de acceso a su cuenta de Facebook, permitimos buscar los amigos de Facebook del usuario que utilicen la aplicación y que publicite viajes en su muro de Facebook. Toda la documentación necesaria para desarrollar aplicaciones relacionadas con Facebook, se encuentra en la siguiente dirección: https://developers.facebook.com/docs/ [13] Para desarrollar aplicaciones relacionadas con Facebook, necesitamos realizar unos trámites previos. En particular, necesitamos estar registrados previamente en Facebook y registrarnos como desarrolladores. Para registrarnos como desarrolladores debemos acceder a la página Web http://developers.facebook.com/ e introducir nuestros datos de acceso a Facebook. Para autentificar la identidad del desarrollador, es posible que se nos pida facilitar a Facebook una fotocopia del DNI o algún documento que acredite nuestra identidad. Una vez que ya somos desarrolladores de aplicaciones de Facebook, registramos nuestra aplicación en Facebook para que se permita que nuestros usuarios accedan a nuestra aplicación utilizando sus datos de acceso a Facebook. A continuación se muestra la pantalla de configuración de nuestra aplicación en Facebook:

Al registrar la aplicación, se nos genera un App ID y un App Secret que nos servirán para conectarnos con Facebook desde nuestra aplicación. Debemos definir el dominio en el que se encuentra nuestra aplicación y la página de nuestra aplicación desde la que nuestros usuarios introducirán sus datos de acceso a su cuenta de Facebook para acceder a nuestra aplicación. Este dato es muy importante ya que no nos permitirá realizar este trámite desde ninguna otra. Facebook ofrece varias formas de acceder a su social graph. El social graph de Facebook esta compuesto por toda la información que todos los usuarios proporcionan a la red social, como pueden ser sus datos personales, sus gustos, sus fotografías y las relaciones que mantienen con el resto de usuarios. Por supuesto, para acceder a la información de los usuarios, la aplicación que pretenda acceder a estos datos del usuario, debe recibir el consentimiento explícito del usuario de que puede utilizar la información de su cuenta de Facebook.

http://developers.facebook.com/

98

Entre las formas de acceso al social graph de Facebook, vamos a destacar el graph Api, las consultas fql y el PHP SDK. El Graph Api de Facebook es la forma más básica de acceso a los datos de los usuarios de Facebook. Consiste en una API basada en peticiones HTTP a datos de un usuario de Facebook. Al ser peticiones HTTP, con un navegador Web convencional podemos hacer pruebas acerca de su funcionamiento. Si introducimos en nuestro navegador la siguiente petición HTTP: http://graph.facebook.com/guillermo.perezledesma Facebook nos devolverá una respuesta en formato JSON que incluirá los datos básicos de mi perfil de Facebook. A continuación se presenta un ejemplo de respuesta JSON a una petición de información mediante el Graph Api de Facebook:

Estos datos son públicos, si tratamos acceder a datos que requieren de la autorización del usuario sin su consentimiento, Facebook nos devolverá un error. A continuación, se puede observar el mensaje de error devuelto por Facebook:

Para probar el acceso a datos protegidos mediante el Graph API, Facebook pone a disposición de sus usuarios una aplicación llamada Graph API Explorer y que podemos encontrar en la siguiente dirección: https://developers.facebook.com/tools/explorer. Mediante esta herramienta, podemos dar permisos a la aplicación para acceder a nuestros datos privados y probar una petición HTTP en la que se pidan datos restringidos.

http://graph.facebook.com/guillermo.perezledesma

99

Para ello accedemos al Graph API Explorer y pulsamos sobre Get Access Token. Nos aparecerá la siguiente pantalla:

En ella podemos dar a la aplicación permiso sobre cualquier dato o uso de nuestro perfil. Una vez seleccionados los que necesitamos, se generara un String llamado Access Token. Este String es el que se genera siempre que una aplicación solicita permisos a un usuario. Al estar utilizando el Graph API directamente sobre un navegador, necesitamos utilizar el Graph API Explorer para generar el Access Token que necesitamos. A continuación se muestra una petición de datos restringidos mediante el Graph API de Facebook.

Podemos ver que una vez generado el Access Token, nos permite realizar la consulta que antes nos devolvía un error ya que se incluyen en la misma, datos que necesitan la autorización del usuario.

100

El siguiente método de acceso a los datos de Facebook que vamos a probar es el acceso mediante consultas FQL (Facebook query languaje). Las consultas FQL son una forma de intentar adaptar las consultas SQL habituales a la información que almacena Facebook. Las consultas FQL tienen la misma estructura que una consulta SQL salvo que tienen algunas limitaciones. No se pueden hacer consultas a más de una tabla de forma simultanea, por lo tanto, tampoco ningún tipo de JOIN. Las tablas de las que se dispone para realizar consultas vienen recogidas en la documentación de Facebook en la siguiente dirección: https://developers.facebook.com/docs/reference/fql/ [14]. Entre estas tablas, podemos citar a modo de ejemplo la tabla user en la que se almacena la información acerca de los datos personales del usuario o la tabla friend en la que se encuentra la información referente a los amigos del usuario. Vamos a utilizar igual que antes el API Graph Explorer para realizar un ejemplo de una consulta FQL Igual que en el caso anterior, generamos un Access Token para que se nos permita acceder a información que requiera la autorización del usuario. A continuación se muestra la respuesta de Facebook a una petición de información mediante consultas FQL:

De esta forma, accedemos a nuestro identificador de Facebook, nuestro nombre y la dirección en la que se encuentra nuestra foto de perfil. En nuestra aplicación, para acceder a los datos de los usuarios que accedan con sus credenciales de acceso a su perfil de Facebook hemos utilizado el Facebook SDK for PHP. Mediante el Facebook SDK for PHP podremos loguearnos dentro de nuestra aplicación y realizar todas las funcionalidades que nos ofrecían tanto la Graph API como las consultas FQL. Para utilizar este SDK, necesitamos acceder a la siguiente dirección: https://developers.facebook.com/docs/php/gettingstarted/ [15]. En ella se nos indica desde donde podemos descargarnos los ficheros php que contienen los métodos necesarios para poder utilizar este SDK. Una vez descargados los ficheros, debemos incluirlos en el sistema de ficheros de nuestra aplicación e incluirlos en las páginas PHP que utilicen las funcionalidades del Facebook SDK for PHP. Para que funcione correctamente, debemos de activar las extensiones CURL de nuestro servidor PHP. Para ello, accederemos al fichero php.ini de nuestro servidor PHP e introduciremos la siguiente línea, extension=php_curl.dll. De esta forma permitiremos a PHP utilizar CURL.

101

CURL es una herramienta de software libre que sirve para transferir información entre servidores y que soporta gran cantidad de protocolos: DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET y TFTP. Una vez que hemos visto como instalar en nuestro servidor los ficheros necesarios para poder utilizar el Facebook SDK for PHP, vamos a pasar a analizar como lo hemos utilizado en nuestra aplicación. Por un lado comentaremos como accedemos a nuestra aplicación utilizando los datos de acceso a Facebook del usuario y por otro como incluir publicaciones en los muros de los usuarios.

4.2.12.1 Acceder a nuestra aplicación utilizando las credenciales de acceso a la cuenta de Facebook del usuario.

Como hemos visto anteriormente, al registrar nuestra aplicación en Facebook, hemos definido una página que será desde la que los usuarios se conectarán a la aplicación utilizando sus datos de acceso a su cuenta de Facebook. En el caso de nuestra aplicación esta página será loginFacebook.php. A continuación se muestra el fragmento de código de la página loginFacebook.php en el que se realiza la conexión con Facebook:

Podemos observar cómo nos conectamos a Facebook mediante el objeto Facebook especificando nuestro appId y nuestra clave secreta. Tratamos de recuperar el id de Facebook del usuario que está tratando de acceder a nuestra aplicación. Si el usuario ya ha accedido anteriormente a nuestra aplicación, la variable user_id tendrá algún valor, si no tiene ninguno, puede ser porque haya introducido mal sus datos o porque no ha accedido nunca a la aplicación y no nos ha concedido los permisos necesarios para acceder a sus datos. En el caso de que no nos ha concedido permisos todavía, se ejecuta la siguiente parte del código:

Se ejecuta de nuevo la URL de acceso a nuestra aplicación solicitando los siguientes permisos:

Email: Permite el acceso al email del usuario. User_birthday: Permite el acceso a la fecha de cumpleaños del usuario. Status_update: Permite publicar mensajes en el muro del usuarios. Publish_stream: Permite publicar Fotografías, enlaces o información en su

nombre. User_photos: Permite el acceso a las fotos del usuario. Offline_access: Permite acceder a los datos del usuario aunque no esté conectado

en ese momento.

102

En el caso de que el usuario ya nos hubiese concedido permisos previamente, comprobaremos si se encuentra dado de alta en nuestra base de datos. En caso de no ser así, mediante una consulta FQL recuperaríamos los datos del perfil de Facebook del usuario para incluirlos en nuestra base de datos. A continuación se muestra la parte del código de la página loginFacebook.php que se encarga de recuperar los datos personales que el usuario ha introducido en su cuenta de Facebook.

Ejecutamos la consulta y recuperamos los datos personales que el usuario tiene registrados en su cuenta de Facebook. Para añadir un nuevo usuario Facebook a nuestro sistema, utilizamos la función aniadirUsuarioFacebook que se encuentra en la clase UsuarioFacebookLogica.

Podemos observar que lo que hace esta función es llamar a la función aniadirUsuarioFacebookP que se encuentra en la clase PersistenciaAplicacion. A continuación se muestra parte del código del método aniadirUsuarioFacebookP en el que se añade un nuevo usuario Facebook:

103

En el método anterior, comprobamos que el usuario no está ya dado de alta como usuario Básico. En el caso de que así sea, se respetarán los datos que tiene introducidos en la aplicación y únicamente se le añadirá como usuario Facebook. En el caso de que el usuario, no estuviese dado de alta previamente en la aplicación como usuario Básico, se le añadirá como usuario Facebook y sus datos de usuario serán los recogidos de su cuenta de Facebook. A continuación se recoge el código de la transacción que se ejecuta al dar de alta un nuevo usuario Facebook que no fuese antes usuario Básico:

Por medio de una transacción, se añaden los datos del usuario a la tabla usuario, y su id de Facebook, lo añadiremos a la tabla usuario_fb como hemos realizado en el caso anterior. Una vez que se ha añadido al nuevo usuario Facebook a la aplicación, el siguiente paso es acceder a la misma. Este paso deben realizarlo tanto los usuarios de nuevo ingreso, como los usuarios que ya estaban registrados en la aplicación como usuarios Facebook previamente y no han necesitado darse de alta de nuevo en la misma. Para acceder a la aplicación, debemos listar los usuarios Facebook de la aplicación que son amigos del usuario Facebook que está tratando de acceder a la misma. A continuación se muestra el fragmento de código de la página login_facebook.php que realiza las tareas mencionadas anteriormente:

104

Mediante una consulta FQL se listan los amigos de Facebook del usuario. Una vez listados, se comprueba si alguno de ellos utiliza la aplicación. Los usuarios detectados, se introducen en un vector. Una vez detectados los amigos de Facebook del usuario que utilizan la aplicación, se crean las variables de sesión con las que contará el usuario durante el uso de la aplicación, entre ellas se encuentran el nombre de usuario, el tipo de usuario, la URL de cierre de sesión de su cuenta de Facebook y los amigos de Facebook del usuario que utilizan la aplicación.

105

4.2.12.2 Publicar mensajes en el muro de Facebook de los usuarios Facebook.

Los usuarios Facebook de la aplicación, tendrán la capacidad de publicar mensajes en su muro publicitando el uso de nuestra aplicación, o anunciando los viajes en los que participan, promoviendo que sus amigos de Facebook que no son usuarios de la aplicación, la conozcan y se inscriban como usuarios. La publicación de mensajes en los muros de Facebook se realiza desde la página publicarMuro.php. A continuación se muestra un fragmento de código de la página publicarMuro.php en la que se ejecuta la función que publica los mensajes en el muro de Facebook del usuario:

Para publicar este mensaje, se utiliza el método api del objeto Facebook que se había creado al acceder a la aplicación y que se había incluido como variable de sesión. Previamente a la ejecución de este método, se debe de crear un String con los datos que se publicarán en el muro de Facebook del usuario.

106

5. Pruebas Para garantizar que todos los métodos desarrollados cumplen con su cometido y que el funcionamiento de la aplicación es el correcto, vamos a realizar una serie de pruebas que certifiquen que la aplicación realiza las tareas para las que ha sido implementada de forma satisfactoria.

Prueba Nº 1 Descripción Accedemos al registro de usuarios y dejamos alguno de los

campos obligatorios vacíos.

Resultado esperado La aplicación avisa de que se debe introducir algún valor en dichos campos.

Resultado obtenido Correcto.

Prueba Nº 2 Descripción Accedemos al registro de usuarios e introducimos dos valores

diferentes en los campos contraseña y repetir contraseña.

Resultado esperado La aplicación informa de que los datos introducidos en las contraseñas no coinciden.


Prueba Nº 3 Descripción Accedemos al registro de usuarios e introducimos un mail o

una fecha con un formato no apropiado.

Resultado esperado La aplicación avisa de que los datos introducidos son incorrectos.


Prueba Nº 4 Descripción En el registro de usuarios, tratamos de introducir un mail o un

nombre de usuario ya dado de alta previamente en la aplicación.

Resultado esperado La aplicación avisa de que se deben introducir otros datos ya que los suministrados ya han sido utilizados por otro usuario.


Prueba Nº 5 Descripción El usuario al registrarse no introduce ninguna fotografía.

Resultado esperado La aplicación le asigna una fotografía por defecto.


Prueba Nº 6 Descripción El usuario introduce unos datos de acceso incorrectos.

Resultado esperado La aplicación, impide la entrada del usuario e informa de que los datos introducidos no son correctos.


107

Prueba Nº 7 Descripción El usuario accede a la aplicación y se le listan los 10

próximos viajes que se van a llevar a cabo. Tanto por parte de toda la comunidad de la aplicación como por parte de nuestros amigos de la aplicación únicamente.

Resultado esperado Se muestran los 10 próximos viajes de la comunidad y los 10 próximos viajes de nuestros amigos.


Prueba Nº 8 Descripción El usuario accede a su perfil y cambia cualquiera de sus datos

personales.

Resultado esperado Sus datos quedan cambiados.


Prueba Nº 9 Descripción El usuario añade un vehículo que ya había sido añadido

anteriormente por otro usuario.

Resultado esperado Se le muestran los datos del coche y se le ofrece al usuario la posibilidad de actualizarlos.


Prueba Nº 10 Descripción El usuario elimina un vehículo.

Resultado esperado Se elimina el vehículo y todos los viajes en los que había participado ese usuario con ese vehículo. Se envía un mensaje informativo a todos los participantes de dichos viajes.

Resultado obtenido Quedan eliminados todos sus datos salvo la foto del vehículo que no será eliminada.

Prueba Nº 11 Descripción El usuario se da de baja de la aplicación.

Resultado esperado Quedan eliminados todos los viajes, mensajes, vehículos, comentarios o puntuaciones que el usuario haya generado utilizando la aplicación.

Resultado obtenido Quedan eliminados todos sus datos salvo su foto de perfil que no se eliminará de la aplicación.

Prueba Nº 12 Descripción El usuario busca a otro usuario introduciendo los datos

necesarios para su identificación.

Resultado esperado El sistema muestra al usuario buscado.


108

Prueba Nº 13 Descripción Un usuario realiza una solicitud de amistad sobre otro usuario

de la aplicación.

Resultado esperado La solicitud queda registrada a la espera de que el usuario que ha recibido la solicitud tome una decisión.


Prueba Nº 14 Descripción El usuario observa que ha recibido una solicitud de amistad y

acepta o rechaza la misma.

Resultado esperado Si el usuario acepta la solicitud, quedan registrados como amigos, si la rechaza se elimina dicha solicitud.


Prueba Nº 15 Descripción El usuario trata de dar de alta un viaje como conductor,

definiendo más plazas disponibles que la capacidad del vehículo que utiliza.

Resultado esperado La aplicación avisa de que los datos introducidos no son correctos.


Prueba Nº 16 Descripción El usuario, trata de dar de alta un viaje con una hora de salida

inferior a 24 horas con respecto a la fecha actual.

Resultado esperado La aplicación avisa de que los datos introducidos son incorrectos.


Prueba Nº 17 Descripción El usuario, da de alta un viaje con unas direcciones de paso

inventadas.

Resultado esperado El sistema avisa de que los datos introducidos son incorrectos.

Resultado obtenido El sistema acepta los datos introducidos y Google Maps trata de localizarlos. Al no encontrarlos se emite un mensaje de error que indica que las localidades no han sido localizadas pero que puede dar de alta el viaje.

Prueba Nº 18 Descripción El usuario propone una nueva dirección de ruta para un viaje

en el que participa.

Resultado esperado La dirección de ruta queda registrada en el sistema.

Resultado obtenido La dirección de ruta queda registrada en el sistema pero aunque el viaje cambie de estado, el promotor del viaje podrá seguir decidiendo sobre ella e incluirla en el viaje.

109

Prueba Nº 19 Descripción El usuario, da de alta un viaje, Google Maps no consigue

localizar las direcciones de la ruta que el usuario ha introducido y el usuario trata de generar un precio aproximado para el viaje.

Resultado esperado La aplicación, genera un precio aproximado para el viaje.

Resultado obtenido No se genera el precio aproximado dado que el dato de la distancia total del viaje, viene suministrado por Google Maps.

Prueba Nº 20 Descripción El usuario da de alta un viaje y no se apunta nadie.

Resultado esperado El viaje será declarado como fallido 24 horas antes de que llegue la fecha de inicio del mismo.


Prueba Nº 21 Descripción El usuario da de alta un viaje como pasajero y no consigue un

conductor.

Resultado esperado El viaje será declarado como fallido 24 horas antes de que llegue la fecha de inicio del mismo.


Prueba Nº 22 Descripción El usuario realiza un comentario acerca de un viaje, aunque

no esté apuntado al mismo.

Resultado esperado El comentario se ve reflejado en la aplicación.


Prueba Nº 23 Descripción El usuario, envía un mensaje a un usuario de la aplicación.

Resultado esperado El mensaje se envía.


Prueba Nº 24 Descripción El usuario, envía un mensaje a un usuario que no existe

dentro de la aplicación.

Resultado esperado La aplicación le informa de que el usuario introducido no existe.


Prueba Nº 25 Descripción El usuario, puntúa al resto de usuarios una vez que el viaje en

el que ha participado.

Resultado esperado Las puntuaciones del usuario se recogen en la aplicación.


110

Prueba Nº 26 Descripción Un usuario accede a la aplicación utilizando sus datos de

acceso a su cuenta de Facebook.

Resultado esperado El usuario accede a la aplicación.


Prueba Nº 27 Descripción El usuario, tras acceder a la aplicación utilizando los datos de

acceso a su cuenta de Facebook, lista a sus amigos de Facebook que utilizan la aplicación.

Resultado esperado El usuario ve una lista en la que aparecen sus amigos de Facebook que participan en la aplicación.

Resultado obtenido El usuario obtiene una lista con sus amigos de Facebook que utilizan la aplicación al inicio de su sesión en la aplicación. Si uno de sus amigos de Facebook comienza a utilizar la aplicación después de que el usuario haya iniciado la sesión, tendrá que esperar a iniciar la siguiente sesión para que aparezca su amigo de Facebook en el listado de amigos de Facebook que utilizan la aplicación.


acceso a su cuenta de Facebook, anuncia en su muro de Facebook un viaje en el que participa.

Resultado esperado El muro de Facebook del usuario recoge un mensaje en el que se anuncia el viaje del usuario.



acceso a su cuenta de Facebook, publica en su muro de Facebook un anuncio de la aplicación.

Resultado esperado El muro de Facebook del usuario recoge un mensaje en el que se promociona la aplicación.


111

6. Gestión del proyecto Una vez terminado el proyecto, vamos a volver a cuantificar el tiempo real que hemos invertido en cada tarea que planificamos previamente en el D.O.P. Una vez cuantificados los tiempos, realizaremos un análisis en el que reflexionaremos acerca de las diferencias encontradas entre la predicción realizada y la realidad y las causas que nos han llevado a que se produzcan estos desfases. Vamos a pasar a ver una comparación entre el tiempo que estimamos al comenzar el proyecto y el tiempo real invertido para cada tarea:

Desarrollo del DOP (Real: 15h Estimado: 5h)

Planificación del sistema (Real: 12h Estimado: 15h) Análisis del sistema

o Análisis de los requisitos (Real: 20h Estimado: 10h) o Elaboración del diagrama de casos de uso (Real: 22h Estimado: 13h) o Elaboración de diagramas de actividad (Real: 15h Estimado: 10h) o Elaboración del diagrama de clases del análisis (Real: 14h Estimado: 15h) o Documentación y memoria asociada al análisis (Real: 20h Estimado: 24h)

Diseño de la aplicación

o Planificación del sistema de persistencia (Real: 38h Estimado: 20h) o Elaboración del diagrama de clases del diseño (Real: 14h Estimado: 15h) o Diseño de Interfaces (Real: 23h Estimado: 20h) o Documentación y memoria asociadas al diseño (Real: 21h Estimado: 23h)

Implementación

o Desarrollo de la base de datos (Real: 10h Estimado: 10h) o Programación de las funcionalidades de la aplicación (Real: 134h

Estimado: 90h) o Integración con Facebook (Real: 28h Estimado: 25h) o Integración con Google Maps (Real: 20h Estimado: 15h) o Elaboración del apartado gráfico de la Web (Real: 22h Estimado: 29h)

Pruebas y validación del resultado (Real: 15h Estimado: 18h) Redacción de la memoria final (Real: 25h Estimado: 10h)

Tiempo total invertido en la aplicación: (Real: 468h Estimado: 367h)

112

Distribución porcentual del tiempo real invertido en el proyecto

Distribución porcentual del tiempo estimado invertido en el proyecto

Tras comparar los resultados obtenidos al finalizar el proyecto con los que predijimos en el documento de objetivos del proyecto, podemos observar que el proyecto ha sufrido un incremento de 101 horas. Analizados los porcentajes de tiempo que han ocupado cada fase del proyecto, detectamos que no varían sustancialmente. La fase que más ha variado su porcentaje ha sido la fase de redacción de la memoria que ha variado desde el 2,73% al 5,34%. Por lo tanto, hemos sufrido un aumento de las horas que hemos dedicado al proyecto desde la predicción que realizamos en un principio pero el tiempo que hemos aumentado se ha distribuido equitativamente entre las fases que lo componen. La fase que más horas ha aumentado su duración respecto a la predicción que realizamos en un principio, es la fase de implementación. Ha variado desde las 169 horas a las 214. En cuanto al calendario de realización del proyecto que definimos en un principio, se ha incumplido ampliamente por diferentes razones. Durante la realización del proyecto, el alumno ha estado trabajando 8 horas durante dos periodos de tiempo, uno de 3 meses y otro de 2, lo que le ha llevado a incumplir el horario que había propuesto en un principio. Por otra parte, la inexperiencia en la planificación de las tareas ha hecho que se realizara una valoración en horas demasiado optimista que le han llevado a realizar un aumento en las horas reales invertidas en la consecución del proyecto. Por último, diferentes razones familiares y personales han hecho que durante algunas épocas en el desarrollo del proyecto no haya podido tener la dedicación que necesitaba cada tarea.

113

7. Conclusiones En este apartado, vamos a realizar un comentario general sobre el desarrollo del proyecto y los resultados que hemos obtenido. Una vez que hemos terminado el proyecto, podemos ver que hemos tenido un desfase de 101 horas respecto a la planificación inicial. Teniendo en cuenta que es la primera vez que nos enfrentamos a un proyecto de esta envergadura y que no tenemos una gran experiencia previa cuantificando tiempos respecto a las fases de un proyecto, considero que no he cometido un gran desfase. Si el proyecto fuese dirigido a un cliente final real, este desfase si hubiese sido muy significativo y el cliente no aceptaría un retraso como éste. Por ello constatamos que las destrezas que hemos adquirido en la planificación del proyecto van a ser muy importantes en el futuro. Por otra parte, la realización de este proyecto nos ha permitido valorar en su justa medida la etapa de análisis. Es fundamental contar con unos requisitos iniciales adecuados ya que los errores en la etapa de análisis, son un lastre continuo en el desarrollo del proyecto. Es fundamental realizar un análisis adecuado del problema propuesto para no encontrarnos en etapas posteriores preguntas que no somos capaces de responder y que nos hacen tener que volver a analizar el problema retrasando considerablemente el desarrollo del proyecto. En cuanto al desarrollo del proyecto en sí, nos ha ayudado a profundizar en la planificación e implementación de bases de datos y nos ha proporcionado un mayor conocimiento del lenguaje de programación PHP. Durante el desarrollo de la carrera, hemos adquirido destrezas considerables en Java pero otros lenguajes de programación muy utilizados actualmente como es PHP no son prácticamente utilizados en nuestra etapa académica. Por lo tanto este proyecto me ha ayudado a conocer mucho más profundamente el leguaje de programación PHP y la integración de aplicaciones con plataformas como Google Maps o Facebook. Podemos destacar, que bajo mi punto de vista hemos desarrollado una aplicación muy intuitiva y funcional, y que cumple eficientemente con todos los requisitos propuestos en un principio. Como posibles mejoras a la aplicación, podríamos pensar en una completa integración de la aplicación con la red social Facebook, aportando más funcionalidades que enriquezcan la aplicación como pueden ser que sea accesible desde la propia interfaz de Facebook, la posibilidad de ofrecer viajes únicamente para los amigos de Facebook del usuario o el desarrollo de una interfaz que se visualice correctamente en los dispositivos móviles. Por último, queremos destacar que enfrentarnos a un problema real ayuda enormemente a nuestro aprendizaje y la consecución de este proyecto ha sido fundamental en la adquisición de destrezas que serán muy importantes cuando nos enfrentemos a problemas similares en el mundo laboral.

114

8. Bibliografía [1] Página Web: http://www.blablacar.es/ [2] Página Web: http://www.conduzco.es/ [3] Página Web: https://www.amovens.com/es/ [4] Página Web: http://www.viajamosjuntos.com/ [5] Ian Sommerville: Ingeniería del software. Pearson Educación (2005) [6] Andrew Curioso, Ronald Bradford, Patrick Galbraith: Expert PHP and MySQL. Wiley Publishing (2010) [7] Tim Converse and Joyce Park with Clark Morgan: PHP 5 and MySQL bible. Wiley Publishing (2010) [8] Ken Coar y Rich Bowen: Apache práctico. Anaya Multimedia (2004) [9] Luc Van Lancker: HTML5 y CSS3 domine los estándares de las aplicaciones Web. Eni (2011) [10] El API de codificación geográfica de Google. Disponible en: https://developers.google.com/maps/documentation/geocoding/?hl=es#GeocodingRe quests [11] Google Maps JavaScript API V3 Reference. Disponible en: https://developers.google.com/maps/documentation/javascript/ [12] Waypoints in directions. Disponible en: https://developers.google.com/maps/documentation/javascript/examples/directions- waypoints?hl=es [13] Facebook documentation. Disponible en: https://developers.facebook.com/docs/ [14] Facebook Query Language (FQL) Reference. Disponible en: https://developers.facebook.com/docs/reference/fql/ [15] Getting started with the Facebook SDK for PHP. Disponible en: https://developers.facebook.com/docs/php/gettingstarted/

http://www.conduzco.es/

http://www.viajamosjuntos.com/

aplicación web para la gestión de viajes en vehículo ... · diseÑo de la base de datos ... no...

Documents