Aplicación android para pedir cita previa en peluquerías

ESCUELA DE INGENIER´ IA DE TELECOMUNICACI´ ON Y ELECTR´ ONICA TRABAJO FIN DE GRADO Aplicaci´ on Android para pedir cita previa en peluquer´ ıas TITULACI ´ ON: Graduado en Ingenier´ıa en Tecnolog´ıas de la Telecomunicaci´on AUTOR: Adolfo Luzardo Cabrera TUTORAS: Dra. Ernestina Martel Jord´an Dra. Carmen Nieves Ojeda Guerra FECHA: Julio 2014 ESCUELA DE INGENIER´ IA DE TELECOMUNICACI´ ON Y ELECTR´ ONICA TRABAJO FIN DE GRADO Aplicaci´ on Android para pedir cita previa en peluquer´ ıas HOJA DE FIRMAS Alumno: Fdo: Adolfo Luzardo Cabrera Tutora: Tutora: Fdo: Dra. Ernestina Martel Jord´an Fdo: Dra. Carmen Nieves Ojeda Guerra Fecha: Julio 2014 ESCUELA DE INGENIER´ IA DE TELECOMUNICACI´ ON Y ELECTR´ ONICA TRABAJO FIN DE GRADO Aplicaci´ on Android para pedir cita previa en peluquer´ ıas HOJA DE EVALUACI´ ON Calificaci´on: Presidente: Fdo: Vocal: Secretario/a: Fdo: Fdo: Fecha: Julio 2014 ´ INDICE GENERAL I Introducci´on IX Introducci´on XI 0.1. Introducci´on y antecedentes del trabajo . . . . . . . . . . . . . . . . . xi 0.2. Objetivosaconseguir...........................xii 0.3. Peticionario ................................xii 0.4. Organizaci´on de la memoria . . . . . . . . . . . . . . . . . . . . . . . xii II Memoria 1 1. Modelo de Requisitos 1 1.1. Introducci´on................................ 1 1.2. Descripci´on del problema . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Modelo de comportamiento . . . . . . . . . . . . . . . . . . . . . . . 2 1.3.1. Actores .............................. 3 1.3.2. Casosdeuso ........................... 3 1.3.2.1. Inclusi´on ........................ 4 1.3.2.2. Extensi´on........................ 5 1.3.2.3. Generalizaci´on . . . . . . . . . . . . . . . . . . . . . 5 1.4. Modelo de interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Actores y casos de uso de la Aplicaci´on Android para pedir cita previa en peluquer´ıas ............................... 7 1.5.1. Actores .............................. 7 1.5.1.1. Usuario ......................... 7 1.5.1.2. Servidor de la base de datos Externa . . . . . . . . . 7 1.5.1.3. Servidor Google . . . . . . . . . . . . . . . . . . . . . 7 1.5.1.4. GPS........................... 8 1.5.2. CasosdeUso ........................... 8 1.5.2.1. Caso de uso Mostrar Peluquer´ıas ........... 8 1.5.2.2. Caso de uso Mostrar Mapa .............. 9 1.5.2.3. Caso de uso Mostrar localizaci´on usuario ....... 10 1.5.2.4. Caso de uso Pedir cita ................. 11 1.5.2.5. Caso de uso Mostrar Horarios Disponibles ...... 11 1.5.2.6. Caso de uso Mostrar citas ............... 12 1.5.2.7. Caso de uso Gesti´on citas ............... 13 1.5.2.8. Caso de uso Manejo base de datos externa ...... 14 1.6. Clases e interfaces de la vista . . . . . . . . . . . . . . . . . . . . . . 16 i ii ´ INDICE GENERAL 1.6.1. Clase DondeEstamosVistaActivity ................ 16 1.6.2. Clase MapaVistaActivity ..................... 17 1.6.3. Clase PedirCita1VistaActivity .................. 17 1.6.4. Clase PedirCita2VistaActivity .................. 18 1.6.5. Clase PedirCita3VistaActivity .................. 18 1.6.6. Clase ConfirmarCitaVistaActivity ................ 19 1.6.7. Clase MisCitasVistaMaestroActivity ............... 19 1.6.8. Clase MisCitasVistaDetalleActivity ............... 19 2. Modelo de Dise˜no 21 2.1. Arquitectura Modelo-Vista-Presentador ................. 21 2.2. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3. Modelodedatos.............................. 26 2.3.1. Dise˜no de la base de datos . . . . . . . . . . . . . . . . . . . . 27 2.3.1.1. Entidad Peluquerias . . . . . . . . . . . . . . . . . . 27 2.3.1.2. Entidad Horarios . . . . . . . . . . . . . . . . . . . . 28 2.3.1.3. Entidad Festivos . . . . . . . . . . . . . . . . . . . . 29 2.3.1.4. Entidad Citas . . . . . . . . . . . . . . . . . . . . . . 29 2.3.1.5. Entidad Servicios . . . . . . . . . . . . . . . . . . . . 30 2.3.1.6. Entidad CitaServicio . . . . . . . . . . . . . . . . . . 30 2.3.2. Dise˜no de las clases e interfaces del modelo . . . . . . . . . . . 30 2.3.2.1. Clase Modelo ...................... 30 2.3.2.2. Clase Peluquerias .................... 32 2.3.2.3. Clase Horarios ..................... 32 2.3.2.4. Clase Festivos ...................... 33 2.3.2.5. Clase Citas ....................... 33 2.3.2.6. Clase Servicios ..................... 33 2.3.2.7. Clase CitaServicio ................... 33 2.4. Dise˜no de las clases e interfaces del presentador . . . . . . . . . . . . 34 2.4.1. Clase PresentadorDondeEstamos ................ 34 2.4.2. Clase PresentadorMapa ..................... 35 2.4.3. Clase PresentadorPedirCita1 .................. 35 2.4.4. Clase PresentadorPedirCita2 .................. 36 2.4.5. Clase PresentadorPedirCita3 .................. 36 2.4.6. Clase PresentadorConfirmarCita ................ 37 2.4.7. Clase PresentadorMisCitasMaestro ............... 37 2.4.8. Clase PresentadorMisCitasDetalle ................ 38 2.5. Adecuaci´on del dise˜no a Android . . . . . . . . . . . . . . . . . . . . 38 2.5.1. Adecuaci´on de la arquitectura MVP . . . . . . . . . . . . . . . 39 2.5.2. Identificaci´on de los patrones usados . . . . . . . . . . . . . . 41 3. Modelo de implementaci´on 43 3.1. Introducci´on................................ 43 3.2. ClaseAppMediador............................ 44 3.3. Paquetevista ............................... 45 3.3.1. Clase Clase MapaVistaActivity e interfaz IVistaMapa ..... 46 3.3.2. Clase PedirCita1VistaActivity e interfaz IVistaPedirCita1 . . 46 ´ INDICE GENERAL iii 3.3.3. Clase PedirCita2VistaActivity e interfaz IVistaPedirCita2 . . 46 3.3.4. Clase MisCitasVistaMaestroActivity e interfaz IVistaMisCitasMaestro ............................. 47 3.4. Paquete presentador . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.1. Clase PresentadorMapa e interfaz IPresentadorMapa ..... 47 3.5. Paquetemodelo.............................. 48 3.5.1. Clase Modelo e interfaz IModelo ................. 48 4. Modelo de Pruebas 53 4.1. Test de usabilidad de la interfaz de usuario . . . . . . . . . . . . . . . 53 4.1.1. Explicaci´on del producto . . . . . . . . . . . . . . . . . . . . . 53 4.1.2. Objetivos del producto . . . . . . . . . . . . . . . . . . . . . . 54 4.1.3. Usuarios y participantes . . . . . . . . . . . . . . . . . . . . . 54 4.1.3.1. Usuarios finales del producto . . . . . . . . . . . . . 54 4.1.3.2. Criterios de selecci´on del grupo de test . . . . . . . . 55 4.1.4. Dise˜no del proceso de test . . . . . . . . . . . . . . . . . . . . 55 4.1.4.1. Log´ıstica . . . . . . . . . . . . . . . . . . . . . . . . 55 4.1.4.2. Instrumentaci´on . . . . . . . . . . . . . . . . . . . . 56 4.1.4.3. Tareas a realizar . . . . . . . . . . . . . . . . . . . . 56 4.1.4.4. Indicadores de ´exito . . . . . . . . . . . . . . . . . . 57 4.1.4.5. Respuesta de los usuarios a los indicadores . . . . . . 57 4.1.4.6. Resumen de tipo de errores encontrados . . . . . . . 58 4.1.4.7. Resumen del tipo de aspectos negativos expresados . 58 4.1.5. Conclusiones finales . . . . . . . . . . . . . . . . . . . . . . . . 58 4.2. Test de verificaci´on del modelo de datos . . . . . . . . . . . . . . . . 59 4.2.1. Testpedircita........................... 59 4.2.2. Test de cargar lista peluquer´ıas . . . . . . . . . . . . . . . . . 60 III Pliego de condiciones 63 IV Presupuesto 69 V Conclusiones y mejoras 79 A. Conclusiones y mejoras 81 A.1.Conclusiones................................ 81 A.2.Mejoras .................................. 81 INTRODUCCI´ ON 0.1 Introducci´on y antecedentes del trabajo En 2013 se vendieron 225.326.200 unidades de tel´efonos m´oviles seg´un un informe publicado por Gartner [1], una compa˜n´ıa norteamericana especializada en la investigaci´on de tecnolog´ıa. Dicho informe indica que los tres sistemas operativos preferidos por los usuarios son Android, iOS [2] y Windows Phone. Android es sin duda el sistema operativo m´as vendido con casi el 80 por ciento de la participaci´on accionaria. Figura 1: Gr´afica con los sistemas operativos m´oviles m´as utilizados Android es un sistema operativo pensado para tel´efonos m´oviles, al igual que iOS y Windows Phone [3]. iOS es un sistema operativo propio para dispositivos de la compa˜n´ıa Apple Inc [4] que utiliza Objective-C como lenguaje de programaci´on. Windows Phone pertenece a Microsoft y utiliza C como lenguaje de programaci´on. En cambio, Android es una obra de Google y est´a basado en Linux [5], un n´ucleo de sistema operativo libre, gratuito y multiplataforma. El sistema Android tambi´en permite programar aplicaciones en una variaci´on de Java llamada Dalvik [6]. Este sistema operativo a diferencia de los anteriores es un sistema abierto que proporciona todas las interfaces necesarias para desarrollar aplicaciones que accedan a las funciones del tel´efono (como el GPS, las llamadas, la agenda, etc.) de una forma muy sencilla y utilizando un lenguaje de programaci´on muy conocido como es Java. Esta sencillez, junto a la existencia de herramientas de programaci´on gratuitas, hace que una de las cosas m´as importantes de este sistema operativo sea la cantidad de aplicaciones disponibles. xi xii Introducci´on Las aplicaciones para m´oviles abarcan diversos sectores. Aunque existen aplicaciones que permiten pedir cita a m´edicos o cita previa para renovar el DNI [7], no se han encontrado aplicaciones de cita previa en el sector de las peluquer´ıas, sector en el que se centra el presente trabajo fin de grado. 0.2 Objetivos a conseguir La mayor´ıa de las peluquer´ıas permiten pedir cita previa, pero utilizan m´etodos primitivos para la gesti´on de las mismas. Para pedir cita en dichas peluquer´ıas necesitas llamar por tel´efono o acudir presencialmente, lo que supone un trabajo a˜nadido y un gasto de dinero tanto para el cliente como para el propio empresario. Gracias al gran potencial de las aplicaciones m´oviles y al uso masivo en la poblaci´on de los terminales m´oviles, se plantea una soluci´on para la mejora en la gesti´on de las citas previas en las peluquer´ıas. En este trabajo fin de grado se pretende realizar una aplicaci´on m´ovil para que los clientes puedan pedir cita previa en la peluquer´ıa sin ning´un tipo de coste, adem´as de una base de datos online donde el empresario puede ver las citas previas. Tomando como referencia el informe publicado por Gartner, se ha decidido que la aplicaci´on para pedir cita en peluquer´ıas se programar´a para m´oviles Android por ser el sistema operativo m´as utilizado y su lenguaje de programaci´on nos permite realizar las funciones necesarias. En este trabajo fin de grado se pretende crear una aplicaci´on Android intuitiva y f´acil de utilizar, compatible con la mayor´ıa de los dispositivos Android. Como funciones principales destacan la posibilidad de pedir cita, gestionarlas y el almacenamiento de dichas citas en una base de datos online. Y como funci´on extra la aplicaci´on muestra datos de contacto e informaci´on de la peluquer´ıa. 0.3 Peticionario El Trabajo fin de grado presentado en esta memoria ha sido elaborado a petici´on de la Escuela de Ingenier´ıa de Telecomunicaci´on y Electr´onica, para la obtenci´on del t´ıtulo de Graduado en Ingenier´ıa en Tecnolog´ıas de la Telecomunicaci´on. 0.4 Organizaci´on de la memoria La memoria que analiza la informaci´on y desarrollo de este trabajo se divide en seis cap´ıtulos, el pliego de condiciones y el presupuesto. A continuaci´on se comenta brevemente los cap´ıtulos incluidos: Aplicaci´on Android para pedir cita previa en peluquer´ıas xiii El cap´ıtulo 1 realiza una introducci´on a la tecnolog´ıa propia de la programaci´on de aplicaciones para m´oviles, los antecedentes del trabajo y especifica el objetivo principal del trabajo. El cap´ıtulo 2 ampl´ıa la informaci´on de la aplicaci´on delimitando el sistema y buscando la funcionalidad que debe ofrecer desde la perspectiva del usuario final. Presenta los casos de uso y la interfaz de usuario de la aplicaci´on. El cap´ıtulo 3 muestra las especificaciones detalladas de todos los objetos, incluyendo sus caracter´ısticas y operaciones. Se introduce el lenguaje de programaci´on utilizado. El cap´ıtulo 4 utiliza el resultado del cap´ıtulo anterior para generar el c´odigo final en el lenguaje de programaci´on elegido. El cap´ıtulo 5 valida si el resultado es el que se quer´ıa, mediante una serie de pruebas sobre la interfaz de usuario y el c´odigo realizado. El cap´ıtulo 6 incluye una serie de conclusiones del trabajo final y las posibles mejoras del mismo. Por ´ultimo, se adjunta el pliego de condiciones que especifica qu´e condiciones y requisitos ha de satisfacer la aplicaci´on; y el presupuesto, que detalla los costes totales del software generado. Parte II Memoria 1 Cap´ıtulo 1 MODELO DE REQUISITOS 1.1 Introducci´on Un modelo, en el desarrollo de software, define c´omo solucionar los problemas que aparecen en el desarrollo de una aplicaci´on. Para desarrollar el software, existen diferentes metodolog´ıas, que definen los distintos tipos de modelos que se pueden encontrar en este proceso. As´ı, los modelos b´asicos son: de Requisitos, de Dise˜no, de Implementaci´on y de Pruebas [10]. Asimismo, el desarrollo de software debe ser registrado a lo largo de todo el proceso, dando lugar a distintos documentos (Documentaci´on). De todos los modelos indicados, en este cap´ıtulo se tratar´ıa el de requisitos, como primer modelo a definir en el desarrollo de la aplicaci´on objeto de este trabajo fin de grado. El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario (es el contrato entre el desarrollador y el usuario final). El modelo de requisitos consiste, b´asicamente, de tres modelos principales: Modelo de comportamiento: se basa directamente en el modelo de casos de uso y especifica la funcionalidad, desde el punto de vista del usuario. Tiene dos conceptos claves: •Actores: representan los distintos papeles que los usuarios pueden jugar en el sistema. •Casos de uso: representa qu´e pueden hacer los actores con respecto al sistema. Modelo de presentaci´on o de interfaces o de bordes: especifica c´omo interact´ua el sistema con actores externos al ejecutar los casos de uso, es decir, especifica c´omo se ver´an las interfaces gr´aficas y que funci´on tiene cada una de ellas. Modelo de informaci´on o del dominio del problema: conceptualiza el sistema seg´un los objetos que representan las entidades b´asicas de la aplicaci´on. 1 2Modelo de requisitos El modelo de requisitos que se va a presentar en este cap´ıtulo, est´a basado en el modelo de comportamiento y en el modelo de interfaces. Asimismo, antes de realizar estos modelos, el desarrollador debe hacer una descripci´on detallada del problema (contrato con el usuario final). 1.2 Descripci´on del problema La descripci´on del problema es una definici´on muy inicial de las necesidades que sirve como punto de partida para comprender los requisitos del sistema, es decir, debe ser una descripci´on de lo que se necesita y no una propuesta de soluci´on. En este trabajo fin de grado se pretende desarrollar una aplicaci´on Android para pedir cita previa en peluquer´ıas, tomando como ejemplo Peluquer´ıas Naranja, una franquicia de peluquer´ıas canarias. Esta aplicaci´on permite, al usuario del dispositivo, reservar hora o pedir cita en la peluquer´ıa. La cita se reservar´a siguiendo una serie de pantallas, en las que la informaci´on introducida de forma t´actil se almacenar´a posteriormente en una base de datos online. Asimismo, la aplicaci´on ser´a capaz de gestionar las citas previas disponibles permitiendo al usuario cancelar su cita previa. La aplicaci´on presentar´a una ventana principal con cuatro funciones: Presentaci´on de la peluquer´ıa, en la que se describir´a la peluquer´ıa brevemente; Contacto, donde se detallar´an los datos de contacto de la empresa; Pedir Cita, donde se podr´a pedir cita en la peluquer´ıa seleccionada, y Gesti´on de citas, donde se podr´an gestionar las citas. Asimismo, tambi´en contar´a con un men´u donde se podr´a acceder a la configuraci´on de la aplicaci´on, ayuda, informaci´on y salir. Una vez se ha pedido una cita con la aplicaci´on, ´esta queda almacenada en una base de datos online que la peluquer´ıa puede consultar y gestionar. La aplicaci´on del terminal del usuario tambi´en tendr´a acceso a dicha base de datos online, para poder gestionar las citas que ha realizado el usuario final. 1.3 Modelo de comportamiento El modelo de comportamiento describe las diferentes formas de uso de un sistema, en el que cada uno de esas formas se conoce como caso de uso. Cada caso de uso se compone de una secuencia de eventos iniciada por el usuario. Para comprender los casos de uso del sistema, es necesario saber c´omo los usuarios lo van a usar o actor (el actor no corresponde directamente con un usuario). Como se muestra en la figura 1.1, el actor y el caso de uso representan los dos elementos b´asicos de este modelo. Aplicaci´on Android para pedir cita previa en peluquer´ıas 3 Figura 1.1: Representaci´on de las entidades b´asicas para el modelo de comportamiento 1.3.1 Actores Los actores [11] corresponden con el papel que un usuario puede jugar dentro de la aplicaci´on (son entidades distintas a los usuarios). Los actores modelan cualquier entidad externa al sistema, adem´as no est´an restringidos a ser personas f´ısicas, pudiendo representar otros sistemas externos al actual. Cada uno de estos actores podr´a ejecutar una o m´as tareas del sistema. Los actores se identifican antes que los casos de uso, para que estos sean la herramienta principal para encontrar los casos de uso. Al definir todos los actores y los casos de uso se define la funcionalidad completa del sistema. A la hora de definir los actores, se identifican primero aquellos que son la raz´on principal del sistema, conocidos como actores primarios, que son los que rigen la secuencia l´ogica de ejecuci´on del sistema. Adem´as existen otros actores que supervisan y mantienen el sistema, conocidos como actores secundarios. Estos corresponden, por lo general, a m´aquinas o sistemas externos. Para especificar los actores de la aplicaci´on, se pueden diferenciar los siguientes: el actor primario al que se le define como Usuario, que es el encargado de introducir los datos necesarios en la aplicaci´on para que ´esta le puedan proporcionar el servicio que proporciona, y varios actores secundarios, como son: el Servidor de la base de datos externa, que ser´a el responsable de almacenar las citas previas; el servidor Google, que ser´a el encargado de proporcionar los mapas, y el GPS que ser´a el encargado de proporcionar la posici´on del usuario. En la figura 1.2 se presenta un diagrama representando al sistema como una caja cerrada y los diferentes actores como entidades externas a ´el. 1.3.2 Casos de uso Despu´es de haber definido los actores se define la funcionalidad del sistema a trav´es de los casos de uso [11]. Cada caso de uso constituye un flujo completo de 10 Modelo de requisitos Precondiciones: el usuario debe tener una peluquer´ıa seleccionada y presionar en el bot´on Ver en mapa que se encuentra en la vista de la figura 1.5. Flujo principal: se presenta al usuario la vista principal (figura 1.4), donde el usuario selecciona la opci´on ¿D´onde estamos? En este punto se inicia el caso de uso Mostrar peluquer´ıas y se presenta la vista de la figura 1.5. En esta vista, si el usuario selecciona el bot´on Ver en mapa se inicia el caso de uso Mostrar mapa (E-1), representado en la figura 1.6. Flujo secundario: si el usuario presiona el bot´on Peluquer´ıa m´as cercana, se cambia el mapa y se muestra la peluquer´ıa m´as cercana a la posici´on del usuario, con la ayuda del caso de uso Mostrar localizaci´on usuario. Excepciones: •E-1 (Fallo al conectar con el servidor Google): debe de conectarse al servidor Google para cargar el mapa. Figura 1.6: Vista del mapa con la peluquer´ıa elegida 1.5.2.3. Caso de uso Mostrar localizaci´on usuario Actores: Usuario yGPS. Prop´osito: obtener la localizaci´on geogr´afica del usuario. Precondiciones: el usuario debe presionar en el bot´on Peluquer´ıa m´as cercana que se encuentra dentro del caso de uso Mostrar mapa (figura 1.6). Aplicaci´on Android para pedir cita previa en peluquer´ıas 11 Flujo principal: se presenta al usuario la vista principal (figura 1.4) donde el usuario selecciona la opci´on ¿D´onde estamos?, en este paso se inicia el caso de uso Mostrar peluquer´ıas (figura 1.5). En esta vista, si el usuario selecciona el bot´on Ver en mapa se inicia el caso de uso Mostrar mapa, representado en la figura 1.6. Finalmente, al presionar el bot´on Peluquer´ıa m´as cercana, se inicia este caso de uso, de forma que se pedir´a al dispositivo GPS (E-1), la localizaci´on del dispositivo del usuario. Flujo secundario: si el usuario presiona el bot´on Ver todas se muestra un mapa con todas las peluquer´ıas. Excepciones: •E-1 (Fallo al conectar con el GPS): debe de conectar con el GPS para saber la geo-localizaci´on del usuario. 1.5.2.4. Caso de uso Pedir cita Actores: Usuario. Prop´osito: recoger los datos necesarios y pedir cita previa en la peluquer´ıa seleccionada. Precondiciones: ninguna. Flujo principal: se presenta al usuario la vista principal (figura 1.4). En esta vista, el usuario selecciona el bot´on Pedir cita, iniciando este caso de uso y apareciendo la vista de la figura 1.7, donde el usuario deber´a introducir los datos solicitados (E-1). Flujo secundario: se pueden considerar dos flujos secundarios. Un flujo a trav´es del cual se cargan las peluquer´ıas utilizando el caso de uso Mostrar peluquer´ıas y otro que carga los horarios disponibles utilizando el caso de uso Mostrar Horarios Disponibles. Excepciones: •E-1 (Fallo al introducir datos): debe introducir correctamente todos los datos (con el formato adecuado). 1.5.2.5. Caso de uso Mostrar Horarios Disponibles Actores: Usuario yServidor de base de datos externa. Prop´osito: recoger de la base de datos externa y mostrar en pantalla los horarios disponibles en la peluquer´ıa seleccionada. 12 Modelo de requisitos Figura 1.7: Vistas correspondientes a introducir datos para pedir cita Precondiciones: el usuario debe haber seleccionado una peluquer´ıa dentro del caso de uso Pedir cita y encontrarse en la ventana donde se introduce el horario. Flujo principal: se presenta al usuario la vista principal (figura 1.4). En esta vista, el usuario selecciona el bot´on Pedir cita, iniciando el caso de uso Pedir cita (vista de la figura 1.7). Como se puede observar en esta figura, en la ´ultima vista se debe introducir un horario que ha sido previamente cargado gracias al caso de uso Mostrar Horarios Disponibles. Flujo secundario: el flujo secundario de este caso de uso Mostrar Horarios Disponibles, es el encargado de cargar los horarios de la base de datos externa y es posible gracias a la ayuda del caso de uso Manejo base de datos externa. Excepciones: ninguna. 1.5.2.6. Caso de uso Mostrar citas Actores: Usuario. Prop´osito: mostrar una lista con las citas previas que ha pedido el usuario de la aplicaci´on. Aplicaci´on Android para pedir cita previa en peluquer´ıas 13 Precondiciones: el usuario debe haber pedido previamente una cita y haber presionado el bot´on Mis citas. Flujo principal: se presenta al usuario la vista principal (figura 1.4). En esta vista, el usuario selecciona el bot´on Mis citas, iniciando este caso de uso representado en la figura 1.8. Flujo secundario: existen dos flujos secundarios, uno que carga las citas previamente solicitadas gracias a la ayuda del caso de uso Manejo base de datos externa y otro al que se accede presionando en una cita y que permite cancelarla, iniciando el caso de uso Gesti´on Citas. Excepciones: ninguna. Figura 1.8: Vista con el listado de citas para la posterior gesti´on de las mismas 1.5.2.7. Caso de uso Gesti´on citas Actores: Usuario. Prop´osito: es el encargado de gestionar las citas, a˜nadir o eliminar citas, de la base de datos externa. Precondiciones: ninguna. Flujo principal: se presenta al usuario la vista principal (figura 1.4). En esta vista, el usuario selecciona el bot´on Mis citas, iniciando el caso de uso Mostrar citas, representado en la figura 1.8. Al presionar en cualquier cita de la lista, aparece la opci´on de Cancelar la cita, como se puede observar en la 14 Modelo de requisitos figura 1.9. Al presionar el bot´on Cancelar cita, se inicia este caso de uso que elimina la cita de la base de datos (con la ayuda del caso de uso Manejo base de datos externa). Figura 1.9: Vista de la aplicaci´on que permite cancelar una cita Tambi´en se puede acceder a este caso de uso si en la vista principal, figura 1.4, el usuario selecciona el bot´on Pedir cita. Cuando se introducen todos los datos necesarios se puede confirmar la cita tal y como se representa en la figura 1.10. Si se presiona el bot´on Confirmar reserva se inicia este caso de uso para a˜nadir la cita a la base de datos externa. Flujo secundario: ninguno. Excepciones: ninguna. 1.5.2.8. Caso de uso Manejo base de datos externa Actores: Usuario yServidor de base de datos externa. Prop´osito: manejar los datos de la base de datos externa, es decir, escribir, leer y borrar datos en el servidor externo. Precondiciones: se necesita interactuar con la aplicaci´on ya sea mostrando informaci´on de una peluquer´ıa, pidiendo una cita previa o mostrando las citas previas. Flujo principal: este caso de uso tiene varios flujos principales dependiendo del uso que se le de a la aplicaci´on: Aplicaci´on Android para pedir cita previa en peluquer´ıas 15 Figura 1.10: Vista de la aplicaci´on que permite confirmar una cita Si se desea mostrar una peluquer´ıa: se presenta al usuario la vista principal (figura 1.4). El usuario selecciona el bot´on ¿D´onde estamos?, en este paso se inicia el caso de uso Mostrar Peluquer´ıas, representado en la figura 1.5. En este punto, se inicia el caso de uso Manejo base de datos externa para cargar la lista de peluquer´ıas y la informaci´on de la peluquer´ıa seleccionada (E-1). Si se desea pedir cita previa: se presenta al usuario la vista principal (figura 1.4). El usuario selecciona el bot´on Pedir cita, en este paso se inicia el caso de uso Pedir cita, cuya finalidad principal es pedir cita previa que se realiza iniciando el caso de uso Manejo base de datos externa, para escribir en la base de datos externa (E-1). Si se desea mostrar las citas previas: se presenta al usuario la vista principal (figura 1.4). El usuario selecciona el bot´on Mis citas, en este paso se inicia el caso de uso Mostrar citas cuya finalidad principal es mostrar las citas previas y para ello se debe iniciar el caso de uso Manejo base de datos externa, para leer las citas de la base de datos externa (E-1). Flujo secundario: este caso de uso tambi´en puede ser iniciado por los casos de uso Mostrar Horarios Disponibles con el objetivo de leer los horarios disponibles en la base de datos externa y Gesti´on citas con la finalidad de borrar una cita de la base de datos externa (E-1). Excepciones: •E-1 (Fallo al conectar con la base de datos externa): debe conectar con el servidor externo para solicitar, borrar o escribir datos en la base de datos externa. 16 Modelo de requisitos 1.6 Clases e interfaces de la vista Teniendo en cuenta que a la hora de implementar la Aplicaci´on Android para pedir cita previa en peluquer´ıas se utilizar´a la arquitectura, MVP (Modelo-VistaPresentador), que es una variante de la arquitectura MVC, se detallan a continuaci´on, las clases e interfaces m´as importantes que corresponden con la parte de la vista, explicando cada m´etodo y los par´ametros de ´estos, tal y como representa la figura 1.11. Figura 1.11: Clases de la vista de la aplicaci´on con sus interfaces 1.6.1 Clase DondeEstamosVistaActivity Vista correspondiente al caso de uso Mostrar Peluquer´ıas, en la que el usuario debe seleccionar una peluquer´ıa y seguidamente se muestra una foto y una descripci´on de la peluquer´ıa seleccionada, como se observa en la figura 1.5. Esta clase implementa la interfaz IVistaDondeEstamos, la cual aparece representada en el figura 1.11 con los siguientes m´etodos: setListaPeluquerias(datos: Object[]): void. M´etodo que rellenar´a una lista con el listado de peluquer´ıas que entra por par´ametros. Aplicaci´on Android para pedir cita previa en peluquer´ıas 17 getPeluqueriaSeleccionada(): String. M´etodo que obtiene la peluquer´ıa que el usuario ha seleccionado en la lista de peluquer´ıas de la vista. setImagenPeluqueria(imagen: Object): void. M´etodo encargado de cargar la imagen de la peluquer´ıa en la vista. setTextoDescripcionPeluqueria(descripcion: String): void. M´etodo que actualiza la descripci´on de la peluquer´ıa. 1.6.2 Clase MapaVistaActivity Vista en la cual aparece un mapa con un campo de texto en la parte superior y botones en la parte inferior, como se puede ver en la figura 1.6. La vista se mostrar´a cuando el usuario quiera ver un mapa con la ubicaci´on de una peluquer´ıa. Esta clase implementa la interfaz IVistaMapa, la cual aparece representada en el figura 1.11 con los siguientes m´etodos: setTextoMapa(texto: String):void. M´etodo que actualizar´a el texto de la parte superior del mapa. setMapa(mapa: Object): void. M´etodo encargado de actualizar el mapa en la vista. getMapa(): Object. M´etodo que obtiene el mapa la vista. 1.6.3 Clase PedirCita1VistaActivity Primera vista donde el usuario debe introducir datos necesarios para posteriormente generar una petici´on de cita previa. Algunos de los datos que se recogen en esta vista son el nombre, el sexo y la peluquer´ıa a la que desea acudir. Esta clase implementa la interfaz IVistaPedirCita1, la cual aparece representada en el figura 1.11 con los siguientes m´etodos: getTextoNombre(): String. M´etodo que recoge el nombre del usuario. getEstadoBotonHombre(): boolean. M´etodo que recoge el estado del bot´on Hombre (si est´a seleccionado el usuario es un hombre). getEstadoBotonMujer(): boolean. M´etodo que recoge el estado del bot´on Mujer (si est´a seleccionado el usuario es una mujer). setListaPeluquerias(datos: Object[]): void. M´etodo que rellenar´a una lista con el listado de peluquer´ıas que entra por par´ametros. getPeluqueriaSeleccionada(): String. M´etodo que obtiene la peluquer´ıa que el usuario ha seleccionado en la lista de peluquer´ıas de la vista. 18 Modelo de requisitos 1.6.4 Clase PedirCita2VistaActivity Segunda vista donde el usuario debe introducir datos necesarios para posteriormente generar una petici´on de cita previa. En esta vista se recogen los servicios que desea el usuario contratar en la peluquer´ıa. Esta clase implementa la interfaz IVistaPedirCita2, la cual aparece representada en el figura 1.11 con los siguientes m´etodos: getEstadoCorteDePelo(): boolean. M´etodo que recoge el estado del servicio corte de pelo. Si esta seleccionado el usuario quiere contratar dicho servicio. getEstadoManicura(): boolean. M´etodo que recoge el estado del servicio manicura. Si esta seleccionado el usuario quiere contratar dicho servicio. getEstadoPedicura(): boolean. M´etodo que recoge el estado del servicio pedicura. Si esta seleccionado el usuario quiere contratar dicho servicio. getEstadoMechas(): boolean. M´etodo que recoge el estado del servicio mechas. Si esta seleccionado el usuario quiere contratar dicho servicio. getEstadoTinte(): boolean. M´etodo que recoge el estado del servicio tinte. Si esta seleccionado el usuario quiere contratar dicho servicio. getCorteDeFlecos(): boolean. M´etodo que recoge el estado del servicio corte de flecos. Si esta seleccionado el usuario quiere contratar dicho servicio. setPrecioTotal(precio: String): void. M´etodo que actualizar´a el precio total seg´un lo que el usuario haya contratado. 1.6.5 Clase PedirCita3VistaActivity Vista donde el usuario debe elegir una fecha y una hora en la que quiere acudir a la peluquer´ıa. Esta clase implementa la interfaz IVistaPedirCita3 la cual aparece representada en el figura 1.11 con los siguientes m´etodos: setDiasDisponibles(dias: Object[]): void. M´etodo que actualizar´a en la vista los d´ıas disponibles para pedir cita en la peluquer´ıa seleccionada. setHorasDisponibles(horas: Object[]): void. M´etodo que actualizar´a en la vista las horas disponibles para pedir cita en la peluquer´ıa seleccionada. getDia(): String. M´etodo que recoge el d´ıa que el usuario ha seleccionado en la vista. getHora(): String. M´etodo que recoge la hora que el usuario ha seleccionado en la vista. Aplicaci´on Android para pedir cita previa en peluquer´ıas 19 1.6.6 Clase ConfirmarCitaVistaActivity Vista en la que aparece un texto con todos los datos recopilados de la cita previa, donde el usuario debe confirmar todos los datos que ha introducido y seguidamente se genera una petici´on de cita previa. Esta clase implementa la interfaz IVistaConfirmarCita, la cual aparece representada en el figura 1.11 con el m´etodo: setTextoConfirmarCita(informacion: String): void. M´etodo que actualizar´a en la vista el texto que aparece con todos los datos que el usuario introdujo previamente. 1.6.7 Clase MisCitasVistaMaestroActivity Vista en la que aparece un listado con todas las citas que el usuario ha pedido previamente con dicha aplicaci´on. Esta clase implementa la interfaz IVistaMisCitasMaestro, la cual aparece representada en el figura 1.11 con los siguientes m´etodos: setListaCitas(datos: Object[]): void. M´etodo que actualizar´a en la vista, la lista con todas las citas que el usuario ha pedido previamente. getCitaSeleccionada(): String. M´etodo que recoge la cita que el usuario ha seleccionado. 1.6.8 Clase MisCitasVistaDetalleActivity Vista donde aparecen los detalles de la cita seleccionada y un bot´on para cancelar la reserva en la parte inferior, por si desea cancelar la cita. Esta clase implementa la interfaz IVistaMisCitasDetalle, la cual aparece representada en el figura 1.11 con el m´etodo: setTextoMiCita(informacion: String): void. M´etodo que actualizar´a en la vista el texto que aparece con los datos de la cita que el usuario ha seleccionado previamente. 26 Modelo de dise˜no Por ´ultimo, en la figura 2.5 se ve el flujo de mensajes del caso de uso Mostrar Citas que es el encargado de mostrar las citas que ha pedido el usuario mediante la aplicaci´on. Figura 2.5: Diagrama de secuencia del caso de uso Mostrar Citas 2.3 Modelo de datos Un modelo de datos es la descripci´on de la informaci´on que se utiliza en una aplicaci´on. En el caso de la Aplicaci´on Android para pedir cita previa en peluquer´ıas, Aplicaci´on Android para pedir cita previa en peluquer´ıas 27 la informaci´on se almacenar´a en la nube (base de datos externa) ya que ´esta debe estar disponible para todos los usuarios de la aplicaci´on. Para que la informaci´on est´e disponible en cualquier momento y en cualquier lugar, debe estar almacenada en un servidor dise˜nado y mantenido por el desarrollador o por una entidad externa (opci´on escogida). Las bases de datos en la nube pueden estar basadas en SQL o utilizar un modelo de datos NoSQL. Concretamente, en este trabajo se utilizar´a una base de datos en la nube NoSQL que se caracteriza, entre otras cosas, por la ausencia de esquema, es decir, no se dise˜nan las tablas ni la estructura de los datos por adelantado [13]. Sin embargo, y como se conoce el tipo de informaci´on a almacenar, se puede realizar una descripci´on de la estructura de los datos y sus tipos. As´ı, para el dise˜no de la base de datos que utilizar´a la Aplicaci´on Android para pedir cita previa en peluquer´ıas, se presentan a continuaci´on una serie de tablas en las que se definen: Campo: en donde se definir´a su nombre. Clave: definir´a si el campo es clave primaria o for´anea (en este caso se indicar´a entre corchetes a qu´e otra tabla hace referencia en la forma ClaveFor´anea [TablaExterna]). Aunque el concepto de clave no tiene significado en una base de datos NoSQL, si es importante de cara a la aplicaci´on desarrollada. Tipo: definir´a el tipo del campo, y si acepta o no, que el campo est´e vac´ıo. Por defecto no existir´an campos nulos, a excepci´on que se indique en las tablas (con la palabra null). 2.3.1 Dise˜no de la base de datos La base de datos estar´a compuesta por un total de seis tablas: Peluquerias, Horarios, Festivos, Citas, Servicios yCitaServicio. A continuaci´on se procede a definir cada tabla de la base de datos y sus campos como se puede ver en la figura 2.6. 2.3.1.1. Entidad Peluquerias Entidad que contiene las peluquer´ıas que permitan pedir cita a trav´es de la Aplicaci´on Android para pedir cita previa en peluquer´ıas. Esta entidad cuenta con seis campos: id peluqueria: es un campo de tipo String y clave primaria. Almacena un identificador ´unico de la peluquer´ıa. direccion: es un campo de tipo String y almacena la direcci´on de la peluquer´ıa. 28 Modelo de dise˜no Figura 2.6: Diagrama de las tablas de la base de datos con sus campos telefono: es un campo de tipo String y almacena el tel´efono de contacto de la peluquer´ıa. descripcion: es un campo de tipo String y almacena una breve descripci´on de la peluquer´ıa. imagen: es un campo de tipo String y almacena una URL donde se encuentra una imagen representativa de la peluquer´ıa. localizacion: es un campo tipo String y almacena las coordenadas geogr´aficas exactas donde podemos encontrar la peluquer´ıa. 2.3.1.2. Entidad Horarios Entidad que contiene los horarios que han reservado los usuarios de la Aplicaci´on Android para pedir cita previa en peluquer´ıas. Esta entidad cuenta con cuatro campos: id horario: es un campo de tipo String y clave primaria. Almacena un identificador ´unico para cada horario guardado. Aplicaci´on Android para pedir cita previa en peluquer´ıas 29 id peluqueria: es un campo de tipo String y clave For´anea [Peluquerias]. Almacena el identificador de la peluquer´ıa en la que est´a ocupado el horario. hora: es un campo de tipo String y almacena el la hora que est´a ocupada. fecha: es un campo de tipo String y almacena la fecha que est´a ocupada. 2.3.1.3. Entidad Festivos Entidad que contiene los dias festivos y d´ıas en los que no abre la peluquer´ıa. Esta entidad cuenta con tres campos: id horario: es un campo de tipo String y clave primaria. Almacena un identificador ´unico para cada horario guardado. id peluqueria: es un campo de tipo String y clave For´anea [Peluquerias]. Almacena el identificador de la peluquer´ıa en la que est´a ocupado el horario. fecha: es un campo de tipo String y almacena la fecha festiva o en la que cierra la peluquer´ıa. 2.3.1.4. Entidad Citas Entidad que contiene las citas que los usuarios han pedido a trav´es de la Aplicaci´on Android para pedir cita previa en peluquer´ıas. Esta entidad cuenta con cuatro campos: id cita: es un campo de tipo String y clave primaria. Almacena un identificador ´unico para cada cita guardada. id horario: es un campo de tipo String y clave For´anea [Horarios]. Almacena el identificador del horario que pertenece a dicha cita. nombre: es un campo de tipo String y almacena el nombre del usuario que ha pedido cita. sexo: es un campo de tipo String y almacena el sexo del usuario que ha pedido cita (este campo es necesario porque existe un peluquero para hombre y otro para mujer reservado para las peticiones a trav´es de la aplicaci´on, de tal forma que un hombre y una mujer pueden reservar el mismo horario). 30 Modelo de dise˜no 2.3.1.5. Entidad Servicios Entidad que contiene los servicios que se pueden contratar en la peluquer´ıa, por ejemplo: corte de pelo, tinte, corte de flecos, entre otros. Esta entidad cuenta con cuatro campos: id servicio: es un campo de tipo String y clave primaria. Almacena un identificador ´unico para cada cita guardada. nombre: es un campo de tipo String y almacena el nombre del servicio. precio: es un campo de tipo String y almacena el precio del servicio. 2.3.1.6. Entidad CitaServicio Entidad que tiene como prop´osito principal relacionar cada cita con los servicios contratados. S´olo cuenta con dos campos, uno es id cita, el identificador de la cita y clave For´anea [Citas] y el otro es id servicio, el identificador del servicio y For´anea [Servicios]. Ambos campos son de tipo String. 2.3.2 Dise˜no de las clases e interfaces del modelo El modelo de la Aplicaci´on Android para pedir cita previa en peluquer´ıas, como se puede ver en la figura 2.7, contar´a con una clase llamada Modelo y su interfaz IModelo. Tambi´en contar´a con otras seis clases, una por cada tabla de la base de datos. En los siguientes apartados se describen cada una de las clases e interfases del modelo de la aplicaci´on. 2.3.2.1. Clase Modelo Esta clase implementa la interfaz IModelo, la cual define los siguientes m´etodos: obtenerListaPeluquerias(): String[]. M´etodo que devuelve un vector con una lista de todas las peluquer´ıas. obtenerDescripcionPeluqueria(id peluqueria: String): String. M´etodo que obtiene una descripci´on de una peluquer´ıa. obtenerImagenPeluqueria(id peluqueria: String): Bitmap . M´etodo que obtiene una imagen de una peluquer´ıa. Aplicaci´on Android para pedir cita previa en peluquer´ıas 31 Figura 2.7: Clases e interfaces del modelo de la aplicaci´on posicionPeluqueria(id peluqueria: String): String. M´etodo que obtiene la posici´on geogr´afica de una peluquer´ıa. posicionTodasPeluquerias(id peluqueria: String): String[]. M´etodo que obtiene un vector con la posici´on geogr´afica de todas las peluquer´ıas. guardarDatos(id android: String, nombre: String, sexo: String, peluqueria: String): boolean . M´etodo encargado de guardar los datos en el modelo para posteriormente enviar al servidor. guardarDatos(servicios: String[]): boolean . M´etodo encargado de guardar los datos en el modelo para posteriormente enviar al servidor. guardarDatos(fecha: String, hora: String): boolean . M´etodo encargado de guardar ciertos datos en el modelo para posteriormente enviar al servidor. obtenerServicios(): String[] . M´etodo que obtiene un vector con todos los servicios de la peluquer´ıa. calculaPrecioTotal(servicios: String[]): String. M´etodo encargado de calcular el precio de los servicios contratados obtenerFechas(): String[]. M´etodo encargado de obtener las fechas disponibles para poder pedir cita. 32 Modelo de dise˜no obtenerHoras(fecha: String): String[]. M´etodo encargado de obtener las horas disponibles en una fecha determinada. obtenerInfoCita(): String. M´etodo encargado de obtener informaci´on de una cita. confirmarCita(): boolean. M´etodo encargado de confirmar una cita, insertando dicha cita en la base de datos externa. obtenerListaCitas(id usuario: String): String[]. M´etodo encargado de obtener las citas que ha pedido un usuario determinado en la aplicaci´on. obtenerInfoCita(id cita: String): String. M´etodo encargado de obtener informaci´on de una cita. cancelarCita(): boolean. M´etodo encargado de cancelar una cita, eliminando dicha cita de la base de datos externa. 2.3.2.2. Clase Peluquerias Esta clase tiene los siguientes m´etodos: obtenerPeluqueria(id peluqueria: String): Object. M´etodo que devuelve la peluquer´ıa de la base de datos que tiene el identificador que se le pasa por par´ametros. obtenerTodasPeluquerias(): Object[]. M´etodo que devuelve todas las peluquer´ıas que hay guardadas en la base de datos. 2.3.2.3. Clase Horarios Esta clase tiene los siguientes m´etodos: obtenerHorarios(id peluqueria: String): Object[]. M´etodo que devuelve los horarios de la base de datos que tienen el identificador de la peluquer´ıa que se le pasa por par´ametros. insertarHorario(horario: Object): boolean. M´etodo encargado de guardar un horario en la base de datos externa. eliminarHorario(id horario: String): boolean. M´etodo que elimina un horario de la base de datos externa. Aplicaci´on Android para pedir cita previa en peluquer´ıas 33 2.3.2.4. Clase Festivos Esta clase tiene los siguientes m´etodos: obtenerFestivos(id peluqueria: String): Object[]. M´etodo que devuelve los festivos de la base de datos que tienen el identificador de la peluquer´ıa que se le pasa por par´ametros. 2.3.2.5. Clase Citas Esta clase tiene los siguientes m´etodos: insertarCita(cita: Object): boolean. M´etodo encargado de guardar una cita en la base de datos externa. eliminarCita(id cita: String): boolean. M´etodo que elimina una cita de la base de datos externa. obtenerCita(id cita: String): Object. M´etodo que devuelve la cita de la base de datos que tiene el identificador que se le pasa por par´ametros. 2.3.2.6. Clase Servicios Esta clase tiene los siguientes m´etodos: obtenerTodosServicios(): Object[]. M´etodo que devuelve todos los servicios que hay guardados en la base de datos externa. 2.3.2.7. Clase CitaServicio Esta clase tiene los siguientes m´etodos: insertarCitaServicio(citaServicio: Object): boolean. M´etodo encargado de guardar una cita de un servicio (objeto CitaServicio) en la base de datos externa. eliminarCitaServicio(id cita: String): boolean. M´etodo que elimina una cita de un servicio (objeto CitaServicio) de la base de datos externa. obtenerCitaServicio(id cita: String): String[]. M´etodo que devuelve la cita de un servicio (objeto CitaServicio) de la base de datos que tiene el identificador que se le pasa por par´ametros. 34 Modelo de dise˜no 2.4 Dise˜no de las clases e interfaces del presentador En esta secci´on se detallan las clases e interfaces que corresponden con la parte del presentador en el MVP, explicando cada m´etodo que aparece en la figura 2.8. Figura 2.8: Clases del presentador de la aplicaci´on con sus interfaces 2.4.1 Clase PresentadorDondeEstamos Presentador correspondiente a la vista DondeEstamosVistaActivity, que es el encargado de mostrar dicha vista, actualizarla y presentar la informaci´on pertinente en ´esta. Esta clase implementa la interfaz IPresentadorDondeEstamos, la cual aparece representada en la figura 2.8 con los siguientes m´etodos: mostrarVistaDondeEstamos(): void. M´etodo que mostrar´a la vista DondeEstamosVistaActivity. cargarListaPeluquerias(): void. M´etodo que pedir´a al modelo la lista de peluquer´ıas. presentarListaPeluquerias(): void. M´etodo presentar´a en la vista la lista de peluquer´ıas previamente recogida del modelo. Aplicaci´on Android para pedir cita previa en peluquer´ıas 35 cargarDatosPeluqueria(): void. M´etodo que pedir´a al modelo los datos de la peluquer´ıa seleccionada en la vista. presentarDatosPeluqueria(): void. M´etodo que presentar´a en la vista los datos de la peluquer´ıa previamente cargados. lanzarMapa(): void. M´etodo que pedir´a al presentador de la vista MapaVistaActivity que la muestre en pantalla. 2.4.2 Clase PresentadorMapa Presentador correspondiente a la vista MapaVistaActivity, que es el encargado de mostrar dicha vista, actualizarla y presentar la informaci´on pertinente en ´esta. Esta clase implementa la interfaz IPresentadorMapa, que aparece representada en la figura 2.8 con los siguientes m´etodos: mostrarVistaMapa(): void. M´etodo que mostrar´a la vista MapaVistaActivity. descargarMapa(): void. M´etodo que construye y descarga un mapa del servidor externo de Google. presentarMapa(): void. M´etodo que presenta el mapa previamente construido y descargado. 2.4.3 Clase PresentadorPedirCita1 Presentador correspondiente a la vista PedirCita1VistaActivity, que es el encargado de mostrar dicha vista, actualizarla y presentar la informaci´on pertinente en ´esta. Esta clase implementa la interfaz IPresentadorPedirCita1, que aparece representada en la figura 2.8 con los siguientes m´etodos: mostrarVistaPedirCita1(): void. M´etodo que mostrar´a la vista PedirCita1VistaActivity. cargarListaPeluquerias(): void. M´etodo que pedir´a al modelo la lista de peluquer´ıas. presentarListaPeluquerias(): void. M´etodo que presentar´a en la vista la lista de peluquer´ıas previamente recogida del modelo. guardarDatos(): void. M´etodo que guarda en el modelo los datos recogidos en la vista. lanzarPedirCita2(): void. M´etodo que pedir´a al presentador de la vista PedirCita2VistaActivity que la muestre por pantalla. 42 Modelo de dise˜no Figura 2.10: Action Bar Confirmaci´on y Reconocimiento. En los momentos en los que se invoca alguna acci´on, como por ejemplo en el momento en el que el usuario selecciona el bot´on de salir de la aplicaci´on, es una buena idea ofrecer al usuario la opci´on de confirmar la acci´on, por si le ha dado de forma err´onea. En el caso de la Aplicaci´on Android para pedir cita previa en peluquer´ıas habr´a confirmaci´on cada vez que el usuario quiera salir de la aplicaci´on y tambi´en habr´a reconocimiento cuando el usuario, confirme o cancele cita. Preferencias. Se ofrece al usuario un lugar en su aplicaci´on donde indica sus preferencias con la forma en la que su aplicaci´on debe comportarse. Esto beneficia a los usuarios debido a que no es necesario que se les interrumpa con las mismas preguntas una y otra vez cuando se presentan ciertas situaciones. Los ajustes predeterminan lo que siempre va a pasar en esas situaciones. Ayuda. Aunque se debe hacer siempre una aplicaci´on en la que el uso de la ayuda sea innecesario, siempre deber existir una apartado de ayuda en el que el usuario pueda resolver sus dudas y aprender m´as sobre la aplicaci´on. En cuanto a los patrones de dise˜no de software, la Aplicaci´on Android para pedir cita previa en peluquer´ıas usar´a: Singleton: la clase AppMediador implementa este patr´on de forma que s´olo existe un objeto de este tipo en la aplicaci´on (no permiten la creaci´on de m´as de un objeto de este tipo). Delegado: las vistas de la aplicaci´on delegan el tratamiento de las acciones del usuario (por ejemplo, la selecci´on de un determinado bot´on), a sus presentadores. As´ı, los presentadores realizar´an las operaciones oportunas en nombre de sus vistas. Observador: los presentadores de la aplicaci´on deben observar al modelo, de forma que cuando ´este termine de realizar el acceso a la informaci´on, los presentadores deben saberlo. En Android, para realizar este proceso, se usan las notificaciones broadcast (o lo que es lo mismo, un objeto de tipo BroadcastReceiver [19]). Maestro-Detalle: existen dos vistas, la vista maestro con un listado de objetos y la vista detalle con informaci´on del objeto que se ha seleccionado previamente en la vista maestro. En la Aplicaci´on Android para pedir cita previa en peluquer´ıas este patr´on se ve reflejado claramente en el caso de uso Mostrar Citas. Cap´ıtulo 3 MODELO DE IMPLEMENTACI´ ON 3.1 Introducci´on El Modelo de implementaci´on utiliza el resultado del Modelo de dise˜no para generar el c´odigo final en el lenguaje de programaci´on elegido [11]. Aunque el dise˜no de objetos es independiente del lenguaje de programaci´on final, todos los lenguajes tienen particularidades que deben adaptarse durante el proceso de implementaci´on. La elecci´on del lenguaje influye en el dise˜no, pero el dise˜no no debe depender de los detalles del lenguaje, es decir, un cambio de lenguaje no puede hacer que el dise˜no cambie. Asimismo, y como ya se ha comentado en cap´ıtulos anteriores, el dise˜no de la aplicaci´on utiliza la arquitectura Modelo-Vista-Presentador (MVP) adaptada al lenguaje elegido. En esta adaptaci´on, se incorpora una nueva clase, llamada AppMediador (introducida en el Modelo de Dise˜no) que va a funcionar como punto de enlace de las distintas partes de la arquitectura. As´ı, el AppMediador, que representa a la clase Application (aplicaci´on) se encargar´a de: Definir los presentadores, vistas y modelo de la arquitectura y los m´etodos accessor de ´estos. Definir la navegaci´on en la aplicaci´on, es decir, qu´e vistas (de la interfaz de usuario) se deben lanzar cuando se considere oportuno (normalmente, ante peticiones del usuario). Definir las constantes correspondientes a los avisos de notificaci´on, enviadas desde el modelo cuando se haya terminado de realizar una determinada acci´on. Definir las constantes correspondientes a los datos comunicados entre vistas, o recuperados desde el modelo, entre otros, ya que en Android los datos se comunican usando pares clave,valor. Definir los m´etodos propios de Java para Android correspondientes al: lanzamiento de actividades, creaci´on de servicios, registros de receptores broadcast, env´ıos de notificaciones broadcast, entre otros. 43 44 Modelo de implementaci´on Es importante comentar que para que la aplicaci´on desarrollada utilice este objeto AppMediador, en el archivo AndroidManifest hay que indicar que el nombre de la aplicaci´on corresponde con este archivo. Para ello, hay que indicar en este archivo, dentro de la etiqueta application, lo siguiente: <application android:name=“rutaHastaLaClase.AppMediador” ...> </aplication> En la siguientes secciones se especificar´an los cambios realizados en la implementaci´on del dise˜no, empezando por la descripci´on del AppMediador para esta aplicaci´on y siguiendo con las modificaciones realizadas en ciertas clases de los tres paquetes definidos: vista,presentador ymodelo, debido a la implementaci´on en Java para Android y a la arquitectura elegida. 3.2 Clase AppMediador El AppMediador contiene una variable por cada una de las interfaces del presentador, la vista y el modelo de la aplicaci´on Aplicaci´on Android para pedir cita previa en peluquer´ıas. Por otro lado, se definen unas constantes de petici´on y notificaci´on (public y static) que ser´an las claves de los Intent (clave, valor). Se utilizar´an en los objetos BroadcastReceiver y en los m´etodos sendBroadcast para notificar cu´ando ha finalizado un evento en la aplicaci´on (por ejemplo, el modelo notifica cu´ando termina de insertar datos en la base de datos). Asimismo, se implementan: Los m´etodos de creaci´on y eliminaci´on de presentadores: “getPresentadorXXX” y “removePresentadorXXX” (donde XXX corresponde al nombre de un presentador), para cada una de las variables creadas con anterioridad y que representan a los presentadores introducidos en el Modelo de dise˜no. Los m´etodos accessor de las vistas definidas en el Modelo de requisitos: “getVistaXXX” y “setVistaXXX” (donde XXX corresponde al nombre de una vista). Estos m´etodos son utilizados para obtener o iniciar las variables de las actividades (Activity de Android). Los m´etodos accessor del modelo: “getModelo” y “setModelo”. Los m´etodos de navegaci´on. Los m´etodos de uso de Java para Android. Aplicaci´on Android para pedir cita previa en peluquer´ıas 45 El m´etodo “onCreate”, que inicia todas las variables de los presentadores a null e indica que la clase AppMediador es un singleton. La vista principal de la aplicaci´on, que corresponde con la clase PrincipalVistaActivity, crea el objeto AppMediador con el m´etodo “getApplication”, para que el resto de clases del proyecto puedan usarlo. Asimismo, el presentador principal, que corresponde con la clase PresentadorPrincipal, crea al modelo, que se encarga de manejar el almacenamiento de los datos. 3.3 Paquete vista En el paquete vista se han implementado las clases y m´etodos que se observan en la imagen 3.1. A continuaci´on se identifican las diferencias entre las clases e interfaces de la vista propuestas en el Modelo de requisitos y las finalmente implementadas. As´ı, los cambios son los siguientes: En todas las vistas que interact´uan con la base de datos externa se han a˜nadido los m´etodos: •void mostrarAlerta(String titulo). M´etodo que muestra en la vista una alerta con el texto que se le pasa por par´ametros. •void mostrarProgreso(String mensaje). M´etodo que muestra una barra de progreso para indicar que la aplicaci´on est´a realizando alguna operaci´on. •void eliminarProgreso(). M´etodo que elimina la barra de progreso de la vista. En Andrid se requiere que se a˜nadan todas las clases de las vistas mediante los siguientes m´etodos: •void onCreate(Bundle savedInstanceState). M´etodo que inicia la actividad. S´olo se ejecuta una vez. •void onStart(). M´etodo que se ejecuta justo despu´es del onCreate o cuando se vuelve a la actividad. La actividad se vuelve visible para el usuario cuando se llama a este m´etodo. •boolean onCreateOptionsMenu(Menu menu). Inicia el contenido del men´u de opciones de la actividad. •boolean onOptionsItemSelected(MenuItem item). M´etodo que se llama cada vez que se selecciona un elemento en el men´u. •void onClick(View v). M´etodo de la interfaz OnClickListener que se invoca cuando se presiona sobre un bot´on de una vista, para realizar las acciones oportunas. Se ha a˜nadido este m´etodo para aquellas vistas que lo requieran. 46 Modelo de implementaci´on 3.3.1 Clase Clase MapaVistaActivity e interfaz IVistaMapa Al utilizar la API de Google Maps para Android los cambios que se hacen en el presentador sobre el mapa se actualizan directamente en la vista, por ello se ha suprimido el siguiente m´etodo al quedar inutilizado: setMapa(mapa: Object) 3.3.2 Clase PedirCita1VistaActivity e interfaz IVistaPedirCita1 Se ha a˜nadido esta vista un campo de texto en el que se introduce el tel´efono m´ovil por cuestiones de funcionalidad. Por ello ha sido necesario a˜nadir el siguiente m´etodo: String getTextoTelefono(). Devuelve el tel´efono introducido en la vista. 3.3.3 Clase PedirCita2VistaActivity e interfaz IVistaPedirCita2 Se ha decidido que el precio de los servicios se cargue del servidor externo y en consecuencia en la vista se a˜naden los siguientes m´etodos: void setPrecioCorteDePelo(String precio). Actualiza el precio del corte de pelo en la vista. void setPrecioManicura(String precio). Actualiza el precio de la manicura en la vista. void setPrecioPedicura(String precio). Actualiza el precio de la pedicura en la vista. void setPrecioMechas(String precio). Actualiza el precio de las mechas en la vista. void setPrecioTinte(String precio). Actualiza el precio del tinte en la vista. void setPrecioCorteDeFlecos(String precio). Actualiza el precio del corte de flecos en la vista. Aplicaci´on Android para pedir cita previa en peluquer´ıas 47 3.3.4 Clase MisCitasVistaMaestroActivity e interfaz IVistaMisCitasMaestro Para mostrar el listado de citas del usuario es necesario identificarlo y se hace mediante n´umero de tel´efono, se ha a˜nadido el siguiente m´etodo en la vista para recoger el tel´efono del usuario: String getTelefono(). Devuelve el tel´efono introducido en la vista. 3.4 Paquete presentador En el paquete presentador se han implementado las clases y m´etodos que se observan en la imagen 3.2. A continuaci´on se identifican las diferencias entre las clases e interfaces del presentador propuestas en el Modelo de dise˜no y las finalmente implementadas. As´ı, los cambios son los siguientes: En los presentadores que necesitan datos del servidor externo se ha a˜nadido una variable privada de la clase BroadcastReceiver para detectar los avisos desde el modelo cuando termina de descargar, insertar o eliminar datos. 3.4.1 Clase PresentadorMapa e interfaz IPresentadorMapa Se ha suprimido el m´etodo, descargarMapa(): void, porque al utilizar la API de Google Maps, se realiza este m´etodo de manera aut´onoma. Se han a˜nadido los siguientes m´etodos: void presentarMapaTodasPeluquerias(). Presenta un mapa con todas las peluquer´ıas. void presentarMapaPeluqueriaCercana(). Presenta un mapa con la peluquer´ıa m´as cercana. 48 Modelo de implementaci´on 3.5 Paquete modelo En el paquete modelo se han implementado las clases y m´etodos que se observan en la imagen 3.3. A continuaci´on se identifican las diferencias entre las clases e interfaces del modelo propuestas en el Modelo de dise˜no y las finalmente implementadas. As´ı, se han a˜nadido las siguientes clases: DatosCita. Clase necesaria para trabajar con bases de datos externa. Esta clase representa un objeto con los datos de la cita. DatosCitaServicio. Clase necesaria para trabajar con bases de datos externa. Esta clase representa un objeto con las relaciones de las citas con los servicios. DatosHorario. Clase necesaria para trabajar con bases de datos externa. Esta clase representa un objeto con los horarios de las citas. DatosPeluqueria. Clase necesaria para trabajar con bases de datos externa. Esta clase representa un objeto con los datos de la peluquer´ıas. DatosServicios. Clase necesaria para trabajar con bases de datos externa. Esta clase representa un objeto con los datos de los servicios. 3.5.1 Clase Modelo e interfaz IModelo Se modifican los m´etodos del Modelo que interact´uan con el servidor externo, ahora no retornan ninguna variable, son de tipo void. Los datos del modelo ahora se env´ıan utilizando notificaciones broadcast con objetos de tipo BroadcastReceiver. Se han a˜nadido los siguientes m´etodos: void setCitaSeleccionada(String id cita). Guarda la cita seleccionada. String getCitaSeleccionada(). Obtiene la cita seleccionada. void setPeluqueriaSeleccionada(String id peluqueria). Guarda la peluquer´ıa seleccionada. String getPeluqueriaSeleccionada(). Obtiene la peluquer´ıa seleccionada. void setTelefono(String telefono). Guarda el tel´efono del usuario. String getTelefono(). Obtiene el tel´efono del usuario void obtenerDatosPeluquerias(). Obtiene los datos de las peluquer´ıas guardadas en el servidor externo. Aplicaci´on Android para pedir cita previa en peluquer´ıas 49 Figura 3.1: Clases del paquete vista 50 Modelo de implementaci´on Figura 3.2: Clases del paquete presentador Aplicaci´on Android para pedir cita previa en peluquer´ıas 51 Figura 3.3: Clases del paquete modelo 58 Modelo de pruebas 4.1.4.6. Resumen de tipo de errores encontrados En general los usuarios no han encontrado errores en el prototipo utilizado, aunque han expresado algunos aspectos negativos que se detallan en la siguiente secci´on. 4.1.4.7. Resumen del tipo de aspectos negativos expresados Tarea no1: •Letras muy peque˜nas que se confunden con el color del fondo. •Se hace pesado leer tanto texto sin ninguna imagen. Tarea no2: Nombre de secci´on Contacto poco intuitivo. Se recomienda ¿D´onde Estamos? Tarea no3: •Nombre de secci´on Pedir Hora poco intuitivo. Se recomienda Pedir Cita. •Una vez confirmada la cita no hay ninguna secci´on con las citas pedidas. Se recomienda un apartado Mis Citas. Tarea no4: Icono configuraci´on no visible, se confunde con el fondo. Tarea no5: Bot´on Salir muy grande, muchos usuarios salen de la aplicaci´on sin querer. 4.1.5 Conclusiones finales Tras realizar el test a los usuarios y analizar los resultados obtenidos, se han detectado carencias en el dise˜no y en las funciones de la aplicaci´on. La modificaci´on en el dise˜no del prototipo contempla lo siguiente: Quitar el bot´on Configuraci´on porque se confunde con el fondo. A˜nadir un men´u con las opciones (Configuraci´on,Ayuda,Info ySalir). A˜nadir la funci´on Mis Citas para gestionar las citas pedidas. Cambiar la secci´on Contacto por la de ¿D´onde estamos? Puesto que en esta secci´on no s´olo se puede poner en contacto con la peluquer´ıa elegida, sino que tambi´en se puede ver un mapa con su ubicaci´on. Aplicaci´on Android para pedir cita previa en peluquer´ıas 59 Cambiar la secci´on Pedir Hora por Pedir Cita, ya que es algo m´as intuitivo. Se ha modificado el prototipo inicial NaranjaAppPrototipo.pdf y se ha generado uno nuevo llamado NaranjaAppPrototipoCorregido.pdf con todas las modificaciones que se han estimado oportunas. Ambos archivos, as´ı como los test realizados a los usuarios, se encuentran en la documentaci´on de este Trabajo fin de grado. 4.2 Test de verificaci´on del modelo de datos A continuaci´on se detallan los tests realizados al c´odigo de la aplicaci´on. El objetivo principal de este test es comprobar el funcionamiento de la aplicaci´on de forma autom´atica, para lo cual se han desarrollado dos tests en los que se controlan las partes del c´odigo que interact´uan con el modelo (al ser este el m´as susceptible a errores al depender de la nube). Para realizar los tests se utilizan las herramientas que ya integran el SDK de Android, que permiten ejecutar las pruebas en un emulador o directamente en el dispositivo f´ısico [21]. 4.2.1 Test pedir cita En este test se pretende comprobar que al pedir una cita, se queda guardada en la base de datos externa. Para ello se ha realizado un test en el que se inserta una cita en la tabla Citas con los siguientes datos: Nombre: Adolfo Tel´efono: 636175744 Sexo: Hombre Peluquer´ıa: Lanzarote Fecha: 23/03/2015 Hora: 10:00 Para comprobar que se ha escrito la cita en la base de datos externa, se obtiene la lista de citas del usuario (con su n´umero de tel´efono).Acto seguido comprobamos que la cita que se acaba de introducir se encuentra en la lista descargada, en caso afirmativo se procede a comprobar si los datos son correctos. Para comprobar si los datos de la cita son correctos se comparan los datos que se introdujeron en la cita con los datos que se descargan de la base de datos externa. Este test se realiz´o en un tiempo de 6.780 segundos y result´o satisfactorio, por lo que se asume que la implementaci´on es correcta. 60 Modelo de pruebas 4.2.2 Test de cargar lista peluquer´ıas En este test se pretende descargar la lista de peluquer´ıas de la base de datos externa y comprobar que se descarga correctamente. En la base de datos externa existe una tabla con el siguiente listado de peluquer´ıas: La Minilla Lanzarote Las Canteras Siete Palmas Tamaraceite Telde Triana Vecindario Para comprobar si el listado es correcto, el test se encarga de descargar el listado y comprobar que existe la peluquer´ıa Lanzarote. El test se ha realizado correctamente en un tiempo de 1.534 segundos. BIBLIOGRAF´ IA [1] Estudio de la firma norteamericana Gartner. Disponible en: http://www.gartner.com/newsroom/id/2573415 Consultada Marzo 2014. [2] IOS Dev Center. Disponible en: https://developer.apple.com/devcenter/ios/index.action Consultada Marzo 2014. [3] Caracter´ısticas Windows Phone. Disponible en: http://www.windowsphone.com/es-es/features Consultada Marzo 2014. [4] Apple Inc. Disponible en: https://www.apple.com/es/ Consultada Marzo 2014. [5] Petersen, Richard. Linux: manual de referencia (6a. ed.). [6] Dalvik Technical Information. Disponible en: http://source.android.com/devices/tech/dalvik/ Consultada Marzo 2014. [7] Aplicaciones cita previa en el Play Store. Disponible en: https://play.google.com/store/ Consultada Marzo 2014. [8] Entorno de programaci´on Eclipse Android. Disponible en: http://developer.android.com/sdk/index.html Consultada Marzo 2014. [9] Informaci´on Android para desarrolladores. Disponible en: http://developer.android.com/index.html Consultada Marzo 2014. [10] Objectory, por Ivar Jacobson. Disponible en: http://metodologiasoo.wikispaces.com/Objectory, +por+Ivar+Jacobson Consultada Junio 2014. [11] Alfredo Weitzenfield. Ingenier´ıa de software orientada a objeto con UML, Java e Internet. Editorial Thomson. 61 62 Modelo de pruebas [12] Patr´on MVP. Disponible en: http://www.imaginanet.com/blog/patron-mvp.html Consultada Junio 2014. [13] Bases de datos NoSQL. Disponible en: http://www.slideshare.net/dipina/nosql-introduccin-a-las-bases-dedatos-no-estructuradas Consultada Junio 2014. [14] Programaci´on en dispositivos m´oviles portables - Android. Disponible en: https://sites.google.com/site/swcuc3m/home/android Consultada Junio 2014. [15] Clase Activity de Android. Disponible en: http://developer.android.com/reference/android/app/Activity.html Consultada Junio 2014. [16] Clase Application de Android. Disponible en: http://developer.android.com/reference/android/app/Application.html Consultada Junio 2014. [17] Parse.com. Disponible en: https://parse.com/ Consultada Junio 2014. [18] Patrones de dise˜no Android. Disponible en: https://developer.android.com/intl/es/design/patterns/ Consultada Junio 2014. [19] Clase BroadcastReceiver de Android. Disponible en: http://developer.android.com/reference/android/content/BroadcastReceiver.html Consultada Junio 2014. [20] Sitio Web de Balsamiq Mockups. Disponible en: http://balsamiq.com/products/mockups/ Consultada Junio 2014. [21] Test Android. Disponible en: https://developer.android.com/tools/testing/index.html Consultada Junio 2014. Parte III Pliego de condiciones 63 PLIEGO DE CONDICIONES Introducci´on A continuaci´on se especificar´an los requisitos t´ecnicos que permitir´a la ejecuci´on de la aplicaci´on en terminales m´oviles con Android. Para ello, se establecer´an las diferentes condiciones referentes al hardware y al software, as´ı como la instalaci´on de la aplicaci´on. Por ´ultimo, se expondr´a la licencia de uso del software. Requisitos El hardware requerido para el correcto funcionamiento de la aplicaci´on consiste en un terminal Android con la versi´on 2.3.3 o superior de su sistema operativo, GPS (deseable) y conexi´on a Internet. Los distintos fabricantes de terminales m´oviles Android especifican, a trav´es de las hojas de caracter´ısticas, la version del sistema operativo soportado. Asimismo, el terminal tambi´en lo indica accediendo a: Ajustes →Informaci´on del tel´efono → Versi´on de Android. Condiciones de instalaci´on Para la instalaci´on de la aplicaci´on desarrollada, el archivo a instalar se encuentra en la entrada C´odigo del men´u del disco compacto adjunto a esta memoria. As´ı, se procede a copiar el archivo AppNaranja.apk en el terminal m´ovil. Si dispone de memoria externa (sdcard o memoria SD), copia el archivo en una ubicaci´on cualquiera (se recomienda la carpeta Aplicaciones o similar). En el caso que no disponga de memoria externa se copia directamente en la memoria interna del terminal m´ovil. La copia puede llevarse a cabo mediante USB, Bluetooth oWi-Fi. Si bien, para el primero de ellos se realiza la copia directamente mediante el propio explorador de archivos del ordenador, en el caso del Bluetooth yWi-Fi es necesario un gestor de ficheros para la transferencia. 65 66 Pliego de condiciones Asimismo, es necesario tener activada la opci´on de poder instalar aplicaciones que no se hallan descargado desde el Google Play. Para ello hay que activar la opci´on Or´ıgenes desconocidos que se encuentra en ajustes →Seguridad →Or´ıgenes desconocidos. Una vez copiado el archivo apk en la memoria del terminal m´ovil, se procede a la instalaci´on. Para ello es necesario que el usuario haya descargado e instalado previamente, a trav´es del Google Play de Android, cualquier explorador de archivos, tal como Astro administrador de archivos,Root Explorer, entre otros. As´ı, se ejecuta el explorador de archivos en el terminal m´ovil y se entra en la carpeta donde se transfiri´o el archivo AppNaranja.apk. Al seleccionar el archivo debe salir un men´u contextual en el que se sugieren varias opciones. Entre ellas, Instalar. Si se elige Instalar, aparecer´a una ventana que explica al usuario los permisos que concede a la aplicaci´on. Si el usuario est´a de acuerdo, se elige Aceptar, con lo que la instalaci´on queda realizada. Una vez instalada la aplicaci´on, se debe acceder al listado de aplicaciones del terminal, donde la aplicaci´on objeto de este trabajo fin de grado vendr´a representada por un icono caracter´ıstico (figura 1). Mediante la selecci´on del icono ser´a ejecutada la aplicaci´on. Figura 1: Icono de la aplicaci´on AppNaranja Para que la aplicaci´on funcione correctamente debe tener conectado el terminal m´ovil a Internet. Dicha conexi´on se puede establecer mediante Wi-fi o mediante tarifa de datos. La conexi´on a Internet es necesaria porque la aplicaci´on carga e inserta informaci´on de una base de datos externa alojada en Parse.com. Licencia del programa Normas generales Esta aplicaci´on es propiedad de la Universidad de Las Palmas de Gran Canaria y su uso debe estar sujeto a los t´erminos y condiciones establecidas en esta licencia del programa, acept´andose todas las cl´ausulas. El uso de esta aplicaci´on ha de estar bajo la expresa autorizaci´on del autor o de la tutora del proyecto o de la Escuela de Ingenier´ıa de Telecomunicaci´on y Electr´onica de la Universidad de Las Palmas de Gran Canaria. Aplicaci´on Android para pedir cita previa en peluquer´ıas 67 Derechos de autor La aplicaci´on y la documentaci´on est´an protegidos por la ley de Propiedad Intelectual aplicable, as´ı como por las disposiciones de los tratados internacionales. En consecuencia, el usuario podr´a usar copia de esta aplicaci´on, as´ı como del c´odigo fuente de programaci´on y de la documentaci´on, siempre bajo la autorizaci´on del autor o de la tutora del proyecto o de la Escuela de Ingenier´ıa de Telecomunicaci´on y Electr´onica de la Universidad de Las Palmas de Gran Canaria. Garant´ıa Se garantiza el correcto funcionamiento de la aplicaci´on en el momento de la instalaci´on de acuerdo con las especificaciones vistas con anterioridad. La instalaci´on de la aplicaci´on no acarrea la aparici´on de defectos en los dispositivos que cumplan con las especificaciones t´ecnicas. Con la ´unica excepci´on de lo expresamente expuesto en el p´arrafo anterior, la aplicaci´on ha sido desarrollada sin garant´ıas de ninguna clase. El autor no asegura, garantiza o realiza ninguna declaraci´on respecto al uso o los resultados derivados de la utilizaci´on del programa o de la documentaci´on. Tampoco se garantiza que la operaci´on del programa sea interrumpida o sin errores. En ning´un caso ser´an el autor, tutora o la Escuela de Ingenier´ıa de Telecomunicaci´on y Electr´onica de la Universidad de Las Palmas de Gran Canaria responsables de los perjuicios directos, indirectos, incidentales, ejemplarios o consiguientes gastos, lucro cesante, p´erdida de ahorros, interrupci´on de negocios, p´erdida de informaci´on comercial o de negocio o cualquier otra p´erdida que resulte del uso o de la incapacidad de usar la aplicaci´on o la documentaci´on. El usuario conoce y acepta que los derechos de licencia reflejan esta asignaci´on de riesgo como el resto de cl´ausulas y restricciones. Otras consideraciones La fiabilidad de operaci´on de la aplicaci´on puede estar afectada por factores adversos, a los que se denominan “fallas del sistema”. En estos se incluyen errores en el funcionamiento del hardware del dispositivo, sistema operativo o entorno del mismo, compiladores o software de desarrollo usado para realizar la aplicaci´on, software externo para el funcionamiento de la misma, errores de instalaci´on, problemas de compatibilidad del software y hardware, fallos o funcionamiento incorrectos de equipos de control, fallas por uso, errores por parte del usuario de la aplicaci´on o problemas en el acceso de Internet. En el supuesto de que cualquier disposici´on de esta licencia sea declarada total o parcialmente invalida, la cl´ausula afectada ser´a modificada convenientemente de manera que sea ejecutable y una vez modificada, plenamente eficaz, permaneciendo el resto de este contrato en plena vigencia. 74 Presupuesto Amortizaci´on de los equipos empleados Dentro de este concepto se considera tanto la amortizaci´on del hardware como del software empleado en la realizaci´on del trabajo fin de grado presentado. De este modo, se estipula el coste de amortizaci´on para un per´ıodo de 3 a˜nos, utilizando un sistema de amortizaci´on lineal o constante. En este sistema, se supone que el inmovilizado material se deprecia de forma constante a lo largo de su vida ´util. La cuota de amortizaci´on anual se calcula haciendo uso de la siguiente f´ormula: C=V ad−V N Donde: C: cuota de amortizaci´on anual. Vad: valor de la adquisici´on. V: valor residual. N: n´umero de a˜nos de vida ´util de la adquisici´on. Siendo el valor residual el valor te´orico que se supone tendr´a el elemento en cuesti´on despu´es de su vida ´util, teniendo en cuenta los ´ındices de depreciaci´on actual. En el caso del hardware y del software son 3 a˜nos (al 33 % de depreciaci´on m´aximo por a˜no). Amortizaci´on del material hardware Debido a que el trabajo fin de grado se ha elaborado en un periodo inferior a 3 a˜nos, que es el periodo en que se calcula la amortizaci´on de material hardware, se realizar´a una amortizaci´on equiparable al per´ıodo de duraci´on del mismo. Seg´un esto, se obtienen los gastos expuestos en la tabla 2. Por lo tanto, el coste total de hardware asciende a la cantidad de CIENTO TREINTA Y CINCO EUROS Y CUARENTA Y UN C´ ENTIMOS DE EURO. Amortizaci´on del material software El coste total del software utilizado es la suma de las herramientas software empleadas para la realizaci´on del trabajo de fin de grado (tabla 3). De esta manera se describe cada uno de las herramientas utilizadas y el coste supuesto para su utilizaci´on usando la f´ormula de amortizaci´on anteriormente citada. Por tanto, el coste total de software asciende a DIEZ EUROS Y VEINTE Y NUEVE C´ ENTIMOS DE EURO. Aplicaci´on Android para pedir cita previa en peluquer´ıas 75 Descripci´on Valor de adquisici´on Tiempo de uso Coste anual Total Ordenador Ultrabook Samsung Series 5 Ultra, Intel Core i3 , 4 Gb de RAM 800,00 3,75 meses 266,67 83,33  Tel´efono m´ovil Samsung S3 400,00 3,7 meses 133,33 41,66  Impresora Samsung ML2160 100,00 3,7 meses 33,33 10,42  Total 1.300,00 - 433,33 135,41  Tabla 2: Precios y costes de amortizaci´on del hardware Descripci´on Valor de adquisici´on Tiempo de uso Coste anual Total Windows 8.1 0,00 3,7 meses 0,00 0,00  Eclipse 0,00 3,7 meses 0,00 0,00  SDK y ADT Android 0,00 3,7 meses 0,00 0,00  Parse.com (base de datos) 0,00 3,7 meses 0,00 0,00  WinEdt (entorno de L A T EX) 36,89 3,7 meses 12,30 3,84  Balsamiq Mockups (para desarrollo de muestras de la aplicaci´on en formato pdf) 62 3,7 meses 20.67 6,45  Cacoo.com (diagramas e ilustraciones) 0,00 3,7 meses 0,00 0,00  Total 98,89 - 32,97 10.29  Tabla 3: Precios y costes de amortizaci´on del software Coste de acceso a Internet Para la conexi´on a Internet se dispone de una soluci´on ADSL a 10Mbps cuyo coste mensual es de 35 euros. Debido a que se ha usado dicha conexi´on durante cada una de las etapas de creaci´on del mismo (3,7 meses), el coste de acceso a Internet se traduce a un total de CIENTO TREINTA Y UN EUROS Y VEINTE Y CINCO C´ ENTIMOS DE EURO. 76 Presupuesto Redacci´on de la documentaci´on Para calcular el valor monetario de la redacci´on del trabajo fin de grado se aplicar´a la f´ormula siguiente: R= 0,05 ×P(1) Siendo: R: coste de la redacci´on. P: presupuesto. El valor de Pse obtiene sumando los costes de las secciones anteriores tal y como muestra la tabla 4. Concepto Coste Tarifa de honorarios por tiempo empleado 5.430  Amortizaci´on del material hardware 135,41  Amortizaci´on del material software 10,29  Coste de acceso a Internet 131,25  Total 5.706,95  Tabla 4: Precios y costes de la ejecuci´on del trabajo fin de grado m´as la amortizaci´on y acceso a Internet De este modo, se obtiene que: R= 0,05 ×5·706,95 = 285,35 (2) Al coste de redacci´on obtenido hasta el momento se le deben a˜nadir otros gastos, quedando el importe final de redacci´on del trabajo fin de grado como se describe en la tabla 5. Por lo tanto, el coste final de redacci´on del trabajo fin de grado asciende a un total de TRESCIENTOS CATORCE EUROS Y CINCUENTA C´ ENTIMOS DE EURO. Derechos de visado El COITT establece que los derechos de visado para las aplicaciones telem´aticas en el a˜no 2012 se calculan de acuerdo con la siguiente ecuaci´on: V= 0,0035 ×P×C(3) Siendo: Aplicaci´on Android para pedir cita previa en peluquer´ıas 77 Concepto Coste Redacci´on del trabajo fin de grado 285,35  Papel de impresi´on 5  Tinta de impresi´on negra(0.05 )4,35  Tinta de impresi´on color(0.55 )12,65  Encuadernaci´on 6,00  CDs de 700MB 1,15  Total 314,50  Tabla 5: Coste final de redacci´on del trabajo fin de grado V: coste del visado. P: presupuesto. C: coeficiente reductor en funci´on del presupuesto. El valor del coeficiente se obtiene de la tabla 6, mientras que el valor de Pes el valor total del presupuesto, que se pasa a calcular en la tabla 7. Coste del presupuesto ()Factor de Correlaci´on (C) Hasta 30.050 1 Exceso de 30.050 hasta 60.101 0.9 Exceso de 60.101 hasta 90.151 0.8 Exceso de 90.151 hasta 120.202 0.7 ... Tabla 6: Tabla de coeficientes para el c´alculo del visado Concepto Coste Coste del tiempo empleado en la ejecuci´on, amortizaci´on y acceso a Internet 5.706,95  Redacci´on del trabajo fin de grado 314,50  Total 6.021,45  Tabla 7: C´alculo total Ppara el c´alculo del visado (Presupuesto base) Por lo tanto, el valor del visado ser´a de: V= 0,0035 ×6·021,45 ×1 = 21,08 (4) Los costes de derechos de visado del trabajo fin de grado ascienden a un total de VEINTE Y UN EUROS CON OCHO C´ ENTIMOS DE EURO. 78 Presupuesto Gastos de tramitaci´on y env´ıo Los gastos de tramitaci´on y env´ıo seg´un la tarifa asciende a SEIS EUROS por cada documento visado de forma telem´atica. Presupuesto antes de impuestos Sumando todos los conceptos calculados hasta el momento, se obtiene el presupuesto, sin incluir los impuestos, que se muestra en la tabla 8. Concepto Coste Presupuesto base 6.021,45  Derechos de visado 21,08  Gastos de tramitaci´on y env´ıo 6,00  Total 6.048,53  Tabla 8: Presupuesto total sin impuestos El presupuesto calculado, antes de incluir los impuestos, asciende a SEIS MIL CUARENTA Y OCHO EUROS CON CINCUENTA Y TRES C´ ENTIMOS DE EURO. Presupuesto incluyendo impuestos Al presupuesto calculado anteriormente hay que incluirle un 7 % de IGIC obteniendo el coste del presupuesto final (tabla 9). Concepto Coste Total (sin IGIC) 6.048,53  IGIC (7 %) 423,40 Total 6.471,93  Tabla 9: Presupuesto total Por tanto, el presupuesto total, incluyendo impuestos, asciende a la cantidad de SEIS MIL CUATROCIENTOS SETENTA Y UN EUROS CON NOVENTA Y TRES C´ ENTIMOS DE EURO. Las Palmas de Gran Canaria, a 05 de Julio de 2014 Fdo: Adolfo Luzardo Cabrera Parte V Conclusiones y mejoras 79 Ap´endice A CONCLUSIONES Y MEJORAS En este cap´ıtulo se detallar´an los objetivos que se pretenden conseguir con la elaboraci´on de este TFG, as´ı como algunas mejoras que se podr´an aplicar a la Aplicaci´on Android para pedir cita previa en peluquer´ıas. A.1 Conclusiones Mediante la realizaci´on de este TFG se pretende hacer m´as sencillo y r´apido el proceso de pedir cita en una peluquer´ıa. La mayor´ıa de las peluquer´ıas permiten pedir cita previa, pero utilizan m´etodos tradicinales para la gesti´on de las mismas. Para pedir cita en dichas peluquer´ıas necesitas llamar por tel´efono o acudir presencialmente, lo que supone un trabajo a˜nadido y un gasto de dinero tanto para el cliente como para el propio empresario. La principal idea es aprovechar el gran potencial de las aplicaciones m´oviles y el uso masivo en la poblaci´on de los Smartphones, para mejorar la gesti´on de las citas previas en las peluquer´ıas y permitir al usuario pedir cita mediante una aplicaci´on. De esta forma se evitar´ıa cualquier tipo de coste y espera en el proceso de pedir cita previa en una peluquer´ıa. Adem´as la peluquer´ıa dispone de un sistema de gesti´on de citas transparente y organizado con todas las citas de sus clientes. A.2 Mejoras Implementaci´on de una nueva aplicaci´on servidor para el empresario y trabajadores de la peluquer´ıa. Con la aplicaci´on servidor se podr´a gestionar festivos, gestionar citas de los clientes, a˜nadir nuevas peluquer´ıas, a˜nadir nuevos servicios o cambiar los precios, a˜nadir ofertas o avisos publicitarios que sean visibles en la aplicaci´on cliente AppNaranja. Mejoras en la aplicaci´on cliente AppNaranja implementada en este TFG: 81 82 Conclusiones y mejoras Notificaciones nativas de Android, se avisar´a mediante la barra de notificaciones cuando se produzcan los siguientes eventos: •Cita cancelada •Nueva peluquer´ıa •Cambios de precios en servicios •Ofertas o avisos publicitarios Implementaci´on de un calendario donde se pueda elegir la fecha y la hora. Integrar la aplicaci´on con las redes sociales (Twitter, Facebook y Google +).