CTPATH: Desarrollo de una aplicación iOS para el cálculo de rutas ecológicas

3 ESCUELA T ´ ECNICA SUPERIOR DE INGENIER´ IA INFORM ´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA CTPATH: Desarrollo de una aplicaci´ on iOS para el c´ alculo de rutas ecol´ ogicas CTPATH: Development of an iOS application to compute ecological routes Realizado por Francisco Navarro Aguilar Tutorizado por Jos´ e Francisco Chicano Garc´ıa Departamento Lenguajes y ciencias de la computaci´ on UNIVERSIDAD DE M ´ ALAGA M´ ALAGA, Junio de 2016 Fecha defensa: El secretario del tribunal 5 Resumen: El cambio clim´ atico se debe en gran parte a la emisi´ on de gases de efecto invernadero como el di´ oxido de carbono, por tanto, es necesario desarrollar nuevas tecnolog´ ıas que reduzcan la emisi´ on de estos gases a la atm´ osfera. Actualmente, las aplicaciones para calcular rutas no tienen en cuenta la relaci´ on entre el tiempo de viaje y las emisiones, ni el perfil de conducci´ on del usuario y el tipo de coche. El proyecto CTPATH tiene en cuenta estos factores. CTPATH para iOS tiene como objetivo reducir la cantidad de gases de efecto invernadero que emiten los veh´ ıculos cuyo combustible es un derivado del petr´ oleo mediante el uso de rutas m´ as ecol´ ogicas. Cualquier usuario puede utilizar la aplicaci´ on sin necesidad de registrarse, aunque si lo desea, podr´ a hacerlo a trav´ es de la aplicaci´ on web existente. Registrarse en la aplicaci´ on ayuda a calcular cu´ al es la ruta que mejor se adapta a su forma de conducir y por tanto, ofrecer una mejor experiencia al usuario. Cuando el usuario introduce el punto de inicio y el punto de destino se le muestra una lista de tres posibles rutas a tomar, donde la m´ as ecol´ ogica aparece en primer lugar, seguido de otras rutas alternativas que son menos ecol´ ogicas y posiblemente m´ as r´ apidas que la primera. Puede darse el caso de que la ruta m´ as r´ apida y la m´ as ecol´ ogica coincidan, es decir, sean la misma. Tambi´ en puede ocurrir que exista una ´ unica ruta o que existan s´ olo dos rutas diferentes para llegar al destino, en ese caso, una misma ruta aparecer´ a varias veces en la lista. Cuando el usuario seleccione una ruta, podr´ a ver las cantidades de gases nocivos emitidos para esa ruta, y desplegar una tabla con las indicaciones que debe tomar para llegar a su destino. Palabras clave:contaminaci´ on, cambio clim´ atico, iOS, aplicaci´ on m´ ovil 6 Abstract:Climate change is produced by pollution and gases like carbon dioxide, so it is necessary to develop new technologies to reduce the emission of these gases to the atmosphere. Nowadays, the applications to compute routes do not take into account the relation between trip time and pollution,neither driving profile, nor the type of car. CTPATH project takes into account these factors. CTPATH for iOS tries to reduce the amount of pollution emitted by vehicles which uses petroleum-base fuel, by using more ecological routes. Any user can use the application without registering, but if it is desired by the user, it may be done through the web application. Signing in the application helps us to compute the best route for a specific user. When the user enters the starting point and the destination point, a list is shown with three possible routes to take, where the most ecological appears first followed by other additional routes that are less friendly with the environment and possibly faster to the first one. It can happend that the fastest route and the most friendly with environment match, i.e, they are the same. It can also happen that there is just a single path or there are just two different routes to the destination, in this case, the same route appears several times in the list. Once the user selects a route, s/he can see the amount of harmful emitted gases for that route, and s/he can also display a table with the instructions to reach the destination. Keywords:pollution, climate change, iOS, mobile application ´ Indice general ´ Indice general 7 1 Introducci´ on 11 1.1 Contexto.................................... 11 1.2 ProyectoCTPATH............................... 12 1.2.1 C´ alculodeemisiones ........................ 12 1.2.2 Aplicaciones existentes . . . . . . . . . . . . . . . . . . . . . . . 12 1.3 Objetivos ................................... 13 1.3.1 Disminuci´ ondeemisiones...................... 13 1.3.2 Reducci´ on del tr´ afico......................... 13 1.4 Fasesdeltrabajo............................... 14 1.5 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Especificaci´ on de requisitos 17 2.1 Prop´ osito ................................... 17 2.2 ´ Ambitodelsistema.............................. 17 2.3 Perspectiva del producto . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4 Caracter´ ısticas de los usuarios . . . . . . . . . . . . . . . . . . . . . . . 18 2.5 Suposiciones y Dependencias . . . . . . . . . . . . . . . . . . . . . . . 18 2.6 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.7 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.8 Casosdeuso................................. 21 3 Dise˜ no de la aplicaci´ on 27 3.1 Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1.1 Arquitectura Cliente-Servidor . . . . . . . . . . . . . . . . . . . . 27 3.1.2 Arquitectura Modelo, Vista, Controlador . . . . . . . . . . . . . . 28 3.2 Diagramadeclases ............................. 29 4 Dise˜ no de la interfaz de usuario 37 4.1 FNAMapViewController . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1.1 Ventanainicial ............................ 37 4.1.2 Mapa con puntos de inicio y fin . . . . . . . . . . . . . . . . . . . 38 4.1.3 Vista detalle de una ruta . . . . . . . . . . . . . . . . . . . . . . . 39 7 8´ INDICE GENERAL 4.1.4 Instrucciones del itinerario . . . . . . . . . . . . . . . . . . . . . . 40 4.2 FNASuggestionsTableViewController . . . . . . . . . . . . . . . . . . . . 40 4.2.1 Sugerencia de calles . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3 FNALoginViewController . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3.1 Vista de inicio de sesi´ on....................... 42 5 Validaci´ on y pruebas 43 6 Conclusiones y trabajo futuro 45 6.1 Conclusiones................................. 45 6.2 Trabajofuturo................................. 46 Referencias bibliogr´ aficas 47 A Manual de usuario 49 A.1 Splashscreen................................. 49 A.2 Ventana solicitando permiso de geolocalizaci´ on.............. 50 A.3 Ventanainicial ................................ 50 A.3.1 Mapa con posici´ ondelusuario ................... 51 A.3.2 Mapa con punto de inicio . . . . . . . . . . . . . . . . . . . . . . 52 A.3.3 Mapa con puntos de inicio y fin . . . . . . . . . . . . . . . . . . . 52 A.3.4 Vista detalle de una ruta . . . . . . . . . . . . . . . . . . . . . . . 53 A.3.5 Vista con instrucciones de ruta . . . . . . . . . . . . . . . . . . . 54 A.4 Ventana de inicio de sesi´ on ......................... 54 A.4.1 Inicio de sesi´ on realizado con ´ exito................. 55 A.4.2 Inicio de sesi´ on con error inesperado . . . . . . . . . . . . . . . . 56 A.4.3 Inicio de sesi´ on con error en credenciales . . . . . . . . . . . . . 56 A.5 Ventana de b´ usquedadecalles....................... 57 A.5.1 B´ usqueda de calles para punto inicial . . . . . . . . . . . . . . . 57 A.5.2 B´ usqueda de calles para punto final . . . . . . . . . . . . . . . . 57 B Documento de Especificaci´ on de Requisitos 59 B.1 Introducci´ on.................................. 59 B.1.1 Prop´ osito ............................... 59 B.1.2 ´ Ambitodelsistema.......................... 59 B.1.3 Definiciones y acr´ onimos ...................... 60 B.1.4 Referencias.............................. 60 B.1.5 Visi´ on general del documento . . . . . . . . . . . . . . . . . . . . 60 B.2 Descripci´ ongeneral ............................. 61 B.2.1 Perspectiva del producto . . . . . . . . . . . . . . . . . . . . . . . 61 B.2.2 Funciones del producto . . . . . . . . . . . . . . . . . . . . . . . 61 B.2.3 Caracter´ ısticas de los usuarios . . . . . . . . . . . . . . . . . . . 61 B.2.4 Restricciones............................. 61 ´ INDICE GENERAL 9 B.2.5 Suposiciones y Dependencias . . . . . . . . . . . . . . . . . . . 62 B.3 Requisitos espec´ ıficos............................ 62 B.3.1 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . 62 B.3.2 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . 64 B.3.3 Requisitos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 64 B.4 Casosdeuso................................. 65 Cap´ıtulo 2 Especificaci´ on de requisitos Para especificar los requisitos necesarios del sistema se ha seguido la norma IEEE Pr´ acticas recomendadas para la obtenci´ on de requisitos software [6]. Esta norma explica c´ omo deben redactarse las especificaciones del software para la correcta implementaci´ on del mismo. Siguiendo esta gu´ ıa, se ha redactado el documento de especificaci´ on de requisitos (ver Anexo B) donde se detalla toda la informaci´ on necesaria para comprender sin ambig¨ uedades el proyecto a desarrollar. Los requisitos descritos en este documento se han obtenido a partir de varias reuniones con el director del proyecto donde se comentaba el prop´ osito de este TFG, su ´ ambito, la perspectiva del mismo, los requisitos funcionales y no funcionales que deb´ ıa implementar, qu´ e usuarios finales tendr´ ıa la aplicaci´ on desarrollada y algunos comentarios relacionados con el proyecto. En esta secci´ on se comenta la parte fundamental del documento, para una visi´ on m´ as detallada se puede consultar el documento completo en el anexo B de esta memoria. 2.1 Prop´ osito La aplicaci´ on a desarrollar pretende complementar el proyecto CTPATH ya que carece de aplicaci´ on iOS. Por tanto, este documento va dirigido al desarrollador de la aplicaci´ on, el autor de estas l´ ıneas, para conocer las especificaciones requeridas y a su vez, va dirigido al grupo de desarrollo del proyecto CTPATH para que el software desarrollado pueda ser comprendido correctamente. 2.2 ´ Ambito del sistema El futuro sistema, en adelante CTPATH-iOS permitir´ a poder utilizar las rutas proporcionadas por el servidor CTPATH en dispositivos m´ oviles con sistema operativo iOS. Las funciones que se desarrollen en esta aplicaci´ on est´ an limitadas a la funcionalidad 17 18 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS del propio servidor. CTPATH-iOS permitir´ a al usuario seleccionar el punto de inicio y el punto de destino, y mostrar´ a las rutas m´ as ecol´ ogicas que unen estos dos puntos. Estas rutas han sido previamente calculadas por el servidor CTPATH y podr´ an ser personalizadas si el usuario inicia sesi´ on en la aplicaci´ on, pero no es una acci´ on obligatoria para poder utilizar la aplicaci´ on. El registro del usuario en la aplicaci´ on no est´ a contemplado, para poder darse de alta, deber´ a acudir a la p´ agina oficial del proyecto CTPATH (https://mallba3.lcc.uma.es/ctpath/). 2.3 Perspectiva del producto CTPATH-iOS es un complemento de un proyecto mayor denominado CTPATH, el cual posee una aplicaci´ on web, una aplicaci´ on Android y un servidor web, el cual sirve las peticiones solicitadas por estas aplicaciones. Las funcionalidades implementadas en CTPATH-iOS deben ser las mismas al resto de aplicaciones al tratarse del mismo proyecto, y a su vez, estas funcionalidades deben ser implementadas a trav´ es de peticiones HTTP a un servicio REST, de tal manera, que la aplicaci´ on muestra los datos que el servidor ha calculado, esto implica que la aplicaci´ on no realiza c´ alculos, sino que procesa la respuesta que obtiene del servidor. 2.4 Caracter´ısticas de los usuarios Al ser una aplicaci´ on que muestra al usuario las rutas m´ as ecol´ ogicas de acuerdo, entre otros factores, al veh´ ıculo que utiliza, los usuarios finales de la aplicaci´ on ser´ an las personas que dispongan de un veh´ ıculo cuyo combustible sea un derivado del petr´ oleo (gasolina, gas´ oleo...). Adem´ as, en las primeras versiones de la aplicaci´ on, s´ olo es posible calcular rutas en la ciudad de M´ alaga, por tanto, estos usuarios ser´ an ciudadanos de M´ alaga, turistas, y/o visitantes de la ciudad. 2.5 Suposiciones y Dependencias Existen dos lenguajes de programaci´ on para desarrollar aplicaciones en iOS, uno es Objective-C y otro es Swift. La aplicaci´ on se ha programado en Objective-C ya que la versi´ on existente de Swift en estos momentos no es definitiva y en cambio, ObjectiveCes un lenguaje con mucho m´ as tiempo en el mercado, y por tanto, es m´ as estable. Si se hubiese realizado en la versi´ on actual de Swift, una versi´ on futura con grandes cambios podr´ ıa ocasionar la refactorizaci´ on del c´ odigo implementado. No obstante, parece ser que Apple busca hacer de Swift el lenguaje principal, por tanto podr´ ıa ser necesario o conveniente programar la aplicaci´ on en Swift 2.6. REQUISITOS FUNCIONALES 19 2.6 Requisitos funcionales Una vez dada una visi´ on global del producto, vamos a comentar los requisitos funcionales que debe cumplir. Atendiendo a las reuniones con el director del proyecto, se pueden dividir en tres grupos: c´ alculo de rutas ecol´ ogicas, informaci´ on al usuario, seguimiento del perfil del conductor. C´ alculo de rutas ecol´ ogicas •RF01 - Introducir datos de la ruta. La aplicaci´ on debe permitir al usuario introducir el punto inicial y el punto final de la ruta. – RF01.1 - Seleccionar en el mapa. El usuario podr´ a seleccionar un punto presionando la posici´ on en el mapa hasta que aparezca una marca. Si no hay punto de inicio, se colocar´ a una marca de inicio. Si hay punto de inicio, se colocar´ a una marca de destino. – RF01.2 - Buscador de calles. Existir´ a un buscador con dos entradas de texto, una para el punto inicial y otra para el punto final. Dependiendo de donde se introduzca el texto, se colocar´ a marca inicial o final. •RF02 - Modificar datos de la ruta. La aplicaci´ on debe permitir al usuario modificar el punto inicial o el punto final en un momento dado. – RF02.1 - Selecci´ on de marca. El usuario podr´ a seleccionar una marca y desplazarla a una nueva posici´ on. – RF02.2 - Buscador de calles. El usuario insertar´ a una calle en la entrada de texto oportuna y la marca respectiva se trasladar´ a a la nueva posici´ on. – RF02.3 - Seleccionar en el mapa. El usuario presionar´ a una nueva posici´ on en el mapa hasta que aparezca en la nueva posici´ on marcada. •RF03 - Calcular ruta. Cuando el punto inicial y el punto final se especifiquen la aplicaci´ on deber´ a conectarse al servicio web autom´ aticamente y obtener las rutas calculadas en formato JSON. •RF04 - Manejo de errores. Cuando se produzca un error en el c´ alculo de rutas, se mostrar´ a un mensaje al usuario inform´ andole del problema ocurrido. – RF04.1 - Error en el servidor. Informar al usuario en caso de que el servicio no est´ e disponible. – RF04.2 - Error en el c´ alculo de la ruta. Informar al usuario si el servicio no puede calcular una ruta entre los puntos insertados por el usuario. – RF04.3 - Error de conexi´ on. Informar al usuario en caso de que no tenga conexi´ on a Internet. 20 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS Informaci´ on al usuario •RF05 - Mostrar rutas calculadas. Una vez responda el servidor con toda la informaci´ on relativa a las rutas, se debe mostrar al usuario de distintas formas. – RF05.1 - Trazado de las rutas. Se pintar´ a en el mapa el trazado de las rutas devueltas cada una con un color, siendo la m´ as ecol´ ogica pintada de color verde y la menos ecol´ ogica pintada de color negro. Las rutas intermedias tendr´ an un color verde oliva. – RF05.2 - Datos de las rutas. Habr´ a una tabla con el nombre que identifica a cada una de la rutas, la duraci´ on de la ruta y el color que identifica a esta ruta, siguiendo la misma metodolog´ ıa de colores explicada en el punto anterior. Cada fila de la tabla se podr´ a seleccionar. •RF06 - Mostrar detalles de la ruta. Al seleccionar una ruta aparecer´ a una vista con toda la informaci´ on relativa a la ruta seleccionada, duraci´ on, fecha y emisi´ on de gases nocivos. Existir´ a un bot´ on en esta vista que abra el itinerario de la ruta – RF06.1 - Itinerario de la ruta. La aplicaci´ on debe ofrecer al usuario la posibilidad de ver en formato textual los pasos que debe seguir para completar la ruta correctamente. – RF06.2 - Ocultar informaci´ on. Debe existir un bot´ on para volver a la interfaz donde se muestra ´ unicamente el mapa, para que el usuario pueda insertar una ruta nueva. Seguimiento del perfil del conductor •RF07 - Autenticaci´ on. El usuario podr´ a iniciar sesi´ on en la aplicaci´ on con su correo electr´ onico y contrase˜ na. Siempre puede iniciar sesi´ on con otro usuario para cambiar el perfil de conducci´ on despu´ es de haber iniciado sesi´ on anteriormente . – RF07.1 - Autenticaci´ on con ´ exito. El servidor web devolver´ a un token de autenticaci´ on que deber´ a ser almacanedao y utilizado en las siguientes peticiones al servidor. – RF07.2 - Error en el servidor. Se informar´ a al usuario en caso de que el servicio de autenticaci´ on no estuviera disponible. – RF07.3 - Error de conexi´ on. Se informar´ a al usuario en caso de que no tenga conexi´ on a Internet. •RF08 - Peticiones al servidor. En caso de no haber iniciado sesi´ on, se podr´ a utilizar la aplicaci´ on sin impedimentos. Si se inicia sesi´ on previamente, se a˜ nadir´ a a una cabecera AuthenticationToken a la petici´ on HTTP con el token devuelto por el servidor. 2.7. REQUISITOS NO FUNCIONALES 21 2.7 Requisitos no funcionales •RNF01 - Lenguaje. El lenguaje utilizado debe ser propio de Apple:Objective-C oSwift. •RNF02 - Usabilidad. La aplicaci´ on debe poder visualizarse correctamente en todos los dispositivos m´ oviles y tabletas de Apple. 2.8 Casos de uso Una vez definidos los requisitos funcionales y no funcionales, vamos a elaborar los diferentes casos de uso de nuestra aplicaci´ on. Con ellos se pretende dar una visi´ on m´ as detallada de las funciones a implementar. A continuaci´ on se muestra un diagrama de caso de uso que comprende los requisitos funcionales RF01, RF02 yRF07. Posteriormente expondremos otro diagrama de caso de uso comentando otras funcionalidades del sistema. Fig. 2.1: Diagrama de casos de uso conteniendo CU1 y CU2 En la figura 2.1 se muestra un diagrama de casos de uso donde est´ an representados el caso de uso “Buscar rutas ecol´ ogicas” (CU01) y “Modificar ruta” (CU02). En cualquiera de las dos situaciones, buscar o modificar ruta, el usuario deber´ a seleccionar el comienzo y el final de la ruta, a trav´ es de un mapa o desde un callejero, si lo desea podr´ a autenticarse. Vamos a explicar con m´ as detalle cada uno de estos casos de uso y los distintos casos de prueba para dichos casos de uso. 22 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS Caso de uso 01 - Buscar rutas ecol´ ogicas Descripci´ on: El usuario podr´ a buscar rutas ecol´ ogicas para llegar al destino deseado. Precondici´ on: Se deben seleccionar los puntos de inicio y fin de la ruta. Post-condici´ on: Se mostrar´ a en el mapa las distintas rutas calculadas. Escenario principal: 1. El usuario selecciona desde el mapa o el callejero el punto de inicio. 2. El usuario selecciona desde el mapa o el callejero el punto final. 3. El sistema realiza una petici´ on al servidor con los datos insertados. 4. Los datos devueltos se muestran en el mapa. Escenarios alternativos: 4. No conecta con el servidor por un problema: a) El sistema muestra un mensaje con el error. b) Vuelta al paso 1. 2. El callejero no encuentra la calle: a) El usuario cancela la b´ usqueda por callejero. b) Vuelta al paso 1. Casos de prueba: ◦CP01 - Buscar rutas ecol´ ogicas. El usuario selecciona un punto de inicio desde el mapa o el callejero, realiza la misma acci´ on para el punto final de la ruta. El sistema se conecta con el servidor enviando los par´ ametros de la ruta, se recibe una respuesta y se pinta en el mapa. ◦CP02 - Error en la conexi´ on. Desconectar el acceso Internet, seleccionar el punto inicial en el mapa o en el callejero, realizar la misma acci´ on para el punto final de la ruta. El sistema muestra un error avisando del error ocurrido. 2.8. CASOS DE USO 23 Caso de uso CU02 - Modificar ruta Descripci´ on: El usuario podr´ a modificar el punto de inicio y el punto final seleccionados previamente. Precondici´ on: Los puntos inicial y final deben haber sido seleccionados previamente. Post-condici´ on: Se actualizar´ an los puntos inicial y final a los nuevos valores introducidos por el usuario. Escenario principal: 1. El usuario modifica el punto inicial, arrastrando la marca existente en el mapa, o seleccionando un punto desde el callejero. 2. El usuario modifica el punto final, arrastrando la marca existente en el mapa, seleccionando un punto desde el callejero, o manteniendo pulsado el dedo en nuevo lugar en el mapa. 3. El sistema realiza una petici´ on al servidor con los datos insertados. 4. Los datos devueltos se muestran en el mapa. Escenarios alternativos: 2. El usuario cancela el cambio de posici´ on del punto inicial: a) La marca se deja en la misma posici´ on. Casos de prueba: ◦CP03 - Modificar ruta. El usuario modifica la posici´ on del punto de inicio arrastrando la marca en el mapa o desde el callejero, realiza la misma acci´ on para el punto final de la ruta. El sistema se conecta con el servidor enviando los par´ ametros de la ruta, se recibe una respuesta y se pinta en el mapa. ◦CP04 - Cancelar modificaci´ on. El usuario elecciona una marca, cuando est´ e disponible para arrastrarla, el usuario la suelta. El sistema no realiza ninguna acci´ on puesto que la posici´ on es la misma. 24 CAP´ ITULO 2. ESPECIFICACI ´ ON DE REQUISITOS Para completar todos los casos de uso del sistema mostramos el siguiente diagrama donde aparece el caso de uso CU01 y las relaciones de ´ este con otros. Fig. 2.2: Diagrama de casos de uso incluyendo CU01, CU03, CU04, CU05 En este diagrama se pretende explicar que para que el usuario pueda realizar el caso de uso CU03 - Ver emisiones del itinerario debe primero buscar el itinerario implicado. Ya hemos visto en los casos de uso anteriores c´ omo se ejecuta ´ este. La novedad del diagrama anterior es la introducci´ on de nuevos caso de usos relacionados con el caso de uso CU01. Tras buscar la ruta el usuario, la aplicaci´ on debe realizar la petici´ on al servidor CTPATH y mostrar la respuesta recibida para que el usuario pueda ver las emisiones calculadas. Vamos a explicar con detalle cada uno de los casos de uso implicados en el diagrama anterior. Caso de uso CU03 - Ver emisiones del itinerario Descripci´ on: El usuario podr´ a comprobar las emisiones de gases nocivos que emite la ruta elegida. Precondici´ on: Se ha realizado una b´ usqueda de itinerarios. Post-condici´ on: Aparece una vista con los detalles de una ruta incluyendo sus emisiones. Escenario principal: 1. El usuario selecciona una ruta de la tabla mostrada. 2.8. CASOS DE USO 25 2. Se abre una pesta˜ na con los datos de la ruta pudiendose ver las emisiones de la ruta. Casos de prueba: ◦CP05 - Ver emisiones del itinerario. El usuario realiza una b´ usqueda de rutas, se obtiene una lista con las rutas calculadas. El usuario selecciona una de ellas. Tras esto, aparece una ventana con los detalles de la ruta y sus emisiones. Caso de uso CU04 - Realizar petici´ on al servidor CTPATH Descripci´ on: La aplicaci´ on deber´ a conectarse al servicio que realiza los c´ alculos de ruta. Precondici´ on: El usuario solicita una b´ usqueda de rutas. Post-condici´ on: Se obtienen las rutas calculadas por el servidor Escenario principal: 1. Se obtienen los par´ ametros de la b´ usqueda del usuario: ◦Coordenadas de los puntos inicial y final (par´ ametros fromPlace y toPlace) ◦Fecha y hora actual (par´ ametros time y date) ◦Tipo de veh´ ıculo (En esta versi´ on s´ olo es para coche. Par´ ametro mode) 2. Se crea la URL para realizar la petici´ on, por ejemplo: https://mallba3.lcc.uma.es/otp/routers/default/plan?fromPlace=36.712, -4.485&toPlace=36.707,-4.434&time=9:18pm&date=06-27-2016&mode=CAR 3. Se ejecuta la petici´ on. 4. Se obtiene la respuesta del servidor. Escenarios alternativos: 4. Se obtiene un error en la petici´ on del servidor: a) Se muestra un mensaje de error. b) Vuelta al paso 1 32 CAP´ ITULO 3. DISE ˜ NO DE LA APLICACI ´ ON ◦FNAItineraryDetailView. Esta vista es utilizada para mostrar todos la informaci´ on relativa a una ruta espec´ ıfica, cumpliendo as´ ı el requisito funcional RF06.1. Fig. 3.8: FNAItineraryDetailView ◦FNADirectionsTableView. Esta vista es la encargada de mostrar al usuario los pasos que debe seguir para completar la ruta previamente seleccionada. Con esta vista mostrarmos al usuario la informaci´ on comentada en el requisito funcional RF06.1. Fig. 3.9: FNADirectionsTableView ◦FNADirectionsCell. Es la celda personalizada de la tabla anterior, ya que ninguna de las celdas que Cocoa tiene por defecto nos es de utilidad y usando una celda personalizada tenemos m´ as libertad de cambio. Fig. 3.10: FNADirectionsCell ◦FNAMapView. Esta clase es una extensi´ on de UIMapView que se crea para adaptar el mapa propio de Apple a las necesidades de nuestro proyecto. 3.2. DIAGRAMA DE CLASES 33 Fig. 3.11: FNAMapView Controlador ◦FNASuggestionsTableViewController. Este controlador es el encargado de implementar el requisito funcional RF01.2, una vez que el usuario selecciona la calle, ´ este controlador se comunica con FNAMapViewController para colocar una marca en el mapa. De esta manera el usuario podr´ a buscar por el nombre de la calle, si no conoce la posici´ on en el mapa. Fig. 3.12: FNASuggestionsTableViewController ◦FNALoginViewController. Este controlador implementa el requisito funcional RF07 y env´ ıa el token de autenticaci´ on al controlador FNAMapViewController a trav´ es de un protocolo. 34 CAP´ ITULO 3. DISE ˜ NO DE LA APLICACI ´ ON Fig. 3.13: FNALoginViewController ◦FNAMapViewController. Debido a la naturaleza del proyecto, las acciones del usuario se producen en un mapa, dado que este controlador contiene ese mapa, proporciona la mayor´ ıa de la funcionalidad de la aplicaci´ on. Este controlador ser´ a el encargado de comunicar el modelo con las vistas comentadas anteriormente, y a su vez, presentar´ a en pantalla el controlador de inicio de sesi´ on y el controlador para la sugerencia de calles explicados anteriormente. Implementa los requisitos RF01.1, RF02, RF03, RF04, RF05 y RF06. Fig. 3.14: FNAMapViewController 3.2. DIAGRAMA DE CLASES 35 Clases auxiliares ◦FNAStepParser. Esta clase se crea para interpretar la informaci´ on de las direcciones que se deben seguir para completr una ruta. Es una clase auxiliar que nos ayuda implementando m´ etodos de acceso a las direcciones de la ruta devueltas por el servicio. Fig. 3.15: FNAStepParser ◦FNAColor. Esta clase extiende de UIColor implementando m´ etodos auxiliares que retornan algunos colores. Se crea debido a que se necesitar´ a utilizar estos colores en muchas ocasiones, y por tanto, para no tener que ”crear” estos colores continuamente, se crea esta clase con los m´ etodos que los ”crean”. Fig. 3.16: FNAColor 36 CAP´ ITULO 3. DISE ˜ NO DE LA APLICACI ´ ON ◦FNADataSource. Debido a que continuamente mostraremos al usuario informaci´ on en tablas, ´ estas necesitar´ an una clase que ejerza de “DataSource” (Una clase que rellene el contenido de cada celda de la tabla). Implementaremos esta clase para unificar cada uno de los DataSource de cada tabla, de este modo, con una ´ unica clase, instanciamos las tablas de nuestra aplicaci´ on. Fig. 3.17: FNADataSource Cap´ıtulo 4 Dise˜ no de la interfaz de usuario En esta fase del problema explicaremos como se construir´ an las distintas interfaces gr´ aficas mostrando la disposici´ on de cada uno de los elementos gr´ aficos a partir de mockups dise˜ nados con el software Balsamiq [8]. Ya que la aplicaci´ on se centra en el uso de un mapa, buscamos una interfaz de usuario atractiva y a la vez sencilla de utilizar, aportando al usuario la informaci´ on exacta y de manera concisa con el m´ ınimo movimiento entre ventanas. Esto har´ a que el usuario no se pierda entre los elementos gr´ aficos de la interfaz y entienda r´ apidamente el funcionamiento de la aplicaci´ on. Debido a que tenemos tres controladores, vamos a mostrar el dise˜ no de cada una de las vistas asociadas a estos controladores. 4.1 FNAMapViewController Veamos el conjunto de vistas asociadas a este controlador, su dise˜ no, y c´ omo van apareciendo unas y otras dependiendo de las acciones que realice el usuario sobre los elementos gr´ aficos. 4.1.1 Ventana inicial En la figura 4.1 se muestra la primera pantalla que aparece cuando inicia la aplicaci´ on. La disposici´ on de los elementos gr´ aficos es la siguiente. Se puede observar un mapa en la parte central, en el que el usuario podr´ a seleccionar los puntos para calcular las rutas. Cada vez que se cierre la aplicaci´ on, quedar´ a almacenada la regi´ on que estaba a la vista del usuario, y cuando se vuelva a iniciar la aplicaci´ on, el mapa se situar´ a en esta regi´ on. Por defecto, aparece la regi´ on en la ciudad de M´ alaga, al ser ´ este el caso de estudio. En la parte inferior, se observa un bot´ on que nos lleva a la posici´ on del usuario en caso de que nos d´ e permiso de geolocalizaci´ on. En la parte superior, podemos ver tres elementos gr´ aficos: El elemento de la izquierda nos abrir´ a el controlador de inicio de sesi´ on, en medio vemos el nombre de 37 38 CAP´ ITULO 4. DISE ˜ NO DE LA INTERFAZ DE USUARIO la aplicaci´ on, y a la derecha tenemos un bot´ on que al pulsarlo muestra el controlador para sugerir calles al usuario. Fig. 4.1: Pantalla inicial 4.1.2 Mapa con puntos de inicio y fin En la figura 4.2 podemos ver el resultado de insertar el punto inicial y final de nuestra ruta en el mapa. Fig. 4.2: Mapa con puntos de inicio y fin 4.1. FNAMAPVIEWCONTROLLER 39 El objetivo es calcular los itinerarios existentes entre estos dos puntos, y que autom´ aticamente se pinten estas rutas con distintos colores en el mapa y aparezca una tabla con la informaci´ on de cada una de ellas. 4.1.3 Vista detalle de una ruta Una vez que el usuario seleccione la ruta que quiere tomar, aparecer´ a una vista con toda la informaci´ on relativa a ella. En esta vista “detalle” contendr´ a la cantidad de gases nocivos que se emiten al utilizar este itinerario, la duraci´ on y la fecha como se puede ver en la figura 4.3. Fig. 4.3: Vista detalle de una ruta Adem´ as, desde esta vista, se podr´ a seleccionar otro itinerario diferente y por tanto, se modificar´ an los datos existentes mostrando los de la ruta seleccionada. 40 CAP´ ITULO 4. DISE ˜ NO DE LA INTERFAZ DE USUARIO 4.1.4 Instrucciones del itinerario Tambi´ en aparecer´ a en el men´ u de abajo, dos nuevos elementos gr´ aficos: uno para ocultar esta vista detalle volviendose a mostrar el mapa, y un bot´ on con una flecha que abrir´ a una tabla con las direcciones que hay que seguir para completar el itinerario (Figura 4.4). Fig. 4.4: Instrucciones del itinerario 4.2 FNASuggestionsTableViewController Veamos cual es la vista asociada a este controlador y la forma en la que se produce la interacci´ on con el usuario y el resto de controladores. 4.2.1 Sugerencia de calles Esta vista mostrada en la figura 4.5 es la encargada de proporcionar los elementos gr´ aficos para que el usuario pueda insertar texto con el nombre de la calle que desea que sea el inicio o el fin de su ruta. Contiene dos cajas de texto y una tabla. Tras escribir en las cajas de texto, aparecer´ a una lista de sugerencias con el nombre de las calles que son parecidas al texto introducido por el usuario, con el fin de ayudarle en su elecci´ on. En cualquier momento se puede cancelar esta acci´ on, haciendo click en el bot´ on “cancelar”, volviendo a mostrar el controlador anterior, es decir, el mapa. 4.3. FNALOGINVIEWCONTROLLER 41 Una vez que el usuario seleccione una calle de la lista, esta vista desaparecer´ a y se insertar´ a una marca en el mapa. Fig. 4.5: Sugerencia de calles 4.3 FNALoginViewController Como indica el nombre de esta vista, se encarga de proporcionar los elementos gr´ aficos necesarios para que el usuario pueda iniciar sesi´ on en la aplicaci´ on. Veamos como est´ a estructurada. Ap´ endice A Manual de usuario A continuaci´ on se muestra una gu´ ıa de las distintas vistas de la aplicaci´ on explicando c´ omo utilizar cada uno de los elementos que aparecen en la ventana y su funci´ on. A.1 Splashscreen Un Splashscreen consiste en una interfaz con una imagen y/o nombre de la aplicaci´ on que aparece al arrancar la misma y se muestra el tiempo necesario hasta que la aplicaci´ on se inicia completamente. Fig. A.1: Splashscreen con nombre de la aplicaci´ on 49 50 AP ´ ENDICE A. MANUAL DE USUARIO A.2 Ventana solicitando permiso de geolocalizaci´ on En esta ventana, aparece una alerta solicitando al usuario permisos de geolocalizaci´ on para que en cualquier momento el usuario pueda saber donde se encuentra. Estos pemisos pueden derogarse en cualquier momento desde los ajustes del tel´ efono. Fig. A.2: Aplicaci´ on solicitando permisos de geolocalizaci´ on La aceptaci´ on o rechazo de los permisos de geolocalizaci´ on s´ olo influyen a la hora de mostrar la posici´ on del usuario. Si no est´ an aceptados, no se mostrar´ a ninguna posici´ on. A.3 Ventana inicial Una vez iniciada la aplicaci´ on aparece la ventana principal, donde podemos ver el mapa donde seleccionaremos los puntos de la ruta, un men´ u superior con los botones para acceder a los controladores de inicio de sesi´ on y sugerencias de calles, y un men´ u inferior con un bot´ on para localizar nuestra posici´ on en el mapa, en el caso de que hayamos aceptado los permisos de geolocalizaci´ on comentados anteriormente. A.3. VENTANA INICIAL 51 Fig. A.3: Ventana inicial de la aplicaci´ on A.3.1 Mapa con posici´ on del usuario Esta interfaz coincide con la anterior, con la ´ unica diferencia es que aparece la posici´ on del usuario. Hemos accedido a esta interfaz mediante el bot´ on de geolocalizaci´ on. Si no es posible ver el punto azul en el mapa, habr´ ıa que revisar los permisos de geolocalizaci´ on en los ajustes del tel´ efono. Fig. A.4: Mapa con posici´ on del usuario 52 AP ´ ENDICE A. MANUAL DE USUARIO A.3.2 Mapa con punto de inicio Cuando se mantiene el dedo presionado sobre un punto en el mapa aparece una marca en ese punto. Si no tenemos ninguna marca en el mapa, esta marca ser´ a roja, indicando el punto inicial, como podemos ver en la siguiente figura. Fig. A.5: Mapa con marca punto inicial A.3.3 Mapa con puntos de inicio y fin Por otro lado, si ya tenemos una marca situada en el mapa y mantenemos presionado el dedo en el mapa, aparecer´ a una marca verde, indicando el punto final, y autom´ aticamente aparecer´ a una lista de rutas. Si presionamos sobre una ruta nos aparecer´ a la vista detalle de la ruta seleccionada. Modificar puntos de inicio y fin Siempre podremos modificar los puntos seleccionados de tres formas: ◦Manteniendo pulsado en otro punto del mapa, en este caso se modifica ´ unicamente el punto final. ◦Seleccionando y arrastrando una chincheta del mapa a otro lugar. ◦Accediendo al buscador de calles e introduciendo el nombre de la calle en la caja de texto apropiada. A.3. VENTANA INICIAL 53 Fig. A.6: Mapa con marca punto inicial y final A.3.4 Vista detalle de una ruta En esta vista aparece la informaci´ on de una ruta, nombre, duraci´ on, inicio del viaje, cantidad de gases emitidos por gramos. Adem´ as, contin´ ua apareciendo la tabla de rutas del apartado anterior para ver la informaci´ on de las otras dos rutas proporcionadas por el servidor. Bastar´ ıa con seleccionar una de ellas para ver su correspondiente detalle. En la barra inferior aparece un bot´ on para ver las instrucciones a seguir para realizar la ruta. Fig. A.7: Vista detalle de una ruta 54 AP ´ ENDICE A. MANUAL DE USUARIO A.3.5 Vista con instrucciones de ruta La vista de la figura A.8 muestra una tabla con cada uno de los movimientos que el conductor debe realizar para alcanzar con ´ exito el destino marcado, a trav´ es de la ruta seleccionada en el paso anterior. Siempre se puede cerrar esta vista pulsando en Ocultar. Fig. A.8: Vista con instrucciones de ruta A.4 Ventana de inicio de sesi ´ on Esta es la interfaz donde el usuario puede iniciar sesi´ on utilizando el correo electr´ onico y la contrase˜ na. Cuando se escriban estos datos en las cajas de texto apropiadas, se deber´ a pulsar en el bot´ on iniciar sesi´ on. Tras pulsar en este bot´ on pueden ocurrir tres situaciones: se inicia sesi´ on correctamente ya que las credenciales son correctas y disponemos de conexi´ on a Internet, se produce un error inesperado por no disponer de conexi´ on a Internet o el servidor no est´ a en funcionamiento, se produce un error por haber insertado incorrectamente las credenciales. A continuaci´ on se muestran cada una de estas circunstancias. A.4. VENTANA DE INICIO DE SESI ´ ON 55 Fig. A.9: Ventana de inicio de sesi´ on A.4.1 Inicio de sesi´ on realizado con ´ exito En el caso de que el correo electr´ onico y la contrase˜ na del insertadas sean correctas, es decir, hay un usuario registrado con estas credenciales, entonces aparecer´ a el siguiente mensaje que implicar´ a un inicio de sesi´ on realizado correctamente. Podemos verlo en la figura A.9 Fig. A.10: Inicio de sesi´ on realizado con ´ exito 56 AP ´ ENDICE A. MANUAL DE USUARIO A.4.2 Inicio de sesi´ on con error inesperado En este caso, se ha producido un error en el servidor, puede que no este en funcionamiento, o que no se haya podido realizar la conexi´ on al servidor debido a la conexi´ on de Internet del usuario. Fig. A.11: Inicio de sesi´ on con error inesperado A.4.3 Inicio de sesi´ on con error en credenciales Es posible que no se produzcan ninguno de estos dos sucesos y simplemente el usuario haya introducido mal sus credenciales. Fig. A.12: Inicio de sesi´ on con error en credenciales A.5. VENTANA DE B ´ USQUEDA DE CALLES 57 A.5 Ventana de b ´usqueda de calles A continuaci´ on se explica c´ omo se utiliza el controlador de sugerencias de calles. Esta es su apariencia inicial: Fig. A.13: Ventana de b´ usqueda de calles A.5.1 B´usqueda de calles para punto inicial Si deseamos insertar el punto de inicio de nuestra ruta, debemos escribir en la caja de texto “Inicio” el nombre de la calle que estemos buscando. En seguida, ir´ an apareciendo en la tabla de sugerencias las distintas calles que m´ as se parecen al texto insertado. A.5.2 B´usqueda de calles para punto final Del mismo modo, si queremos insertar el destino de nuestra ruta, debemos escribir esta calle en la caja de texto ”Final”, y obtendremos las sugerencias en la tabla. 64 AP ´ ENDICE B. DOCUMENTO DE ESPECIFICACI ´ ON DE REQUISITOS Seguimiento del perfil del conductor ◦RF07 - Autenticaci´ on. El usuario podr´ a iniciar sesi´ on en la aplicaci´ on con su correo electr´ onico y contrase˜ na. Siempre puede iniciar sesi´ on con otro usuario para cambiar el perfil de conducci´ on despu´ es de haber iniciado sesi´ on anteriormente . – RF07.1 - Autenticaci´ on con ´ exito. El servidor web devolver´ a un token de autenticaci´ on que deber´ a ser almacanedao y utilizado en las siguientes peticiones al servidor. – RF07.2 - Error en el servidor. Se informar´ a al usuario en caso de que el servicio de autenticaci´ on no estuviera disponible. – RF07.3 - Error de conexi´ on. Se informar´ a al usuario en caso de que no tenga conexi´ on a Internet. ◦RF08 - Peticiones al servidor. En caso de no haber iniciado sesi´ on, se podr´ a utilizar la aplicaci´ on sin impedimentos. Si se inicia sesi´ on previamente, se a˜ nadir´ a a una cabecera AuthenticationToken a la petici´ on HTTP con el token devuelto por el servidor. B.3.2 Requisitos no funcionales ◦RNF01 - Lenguaje. El lenguaje utilizado debe ser propio de Apple:Objective-C oSwift. ◦RNF02 - Usabilidad. La aplicaci´ on debe poder visualizarse correctamente en todos los dispositivos m´ oviles y tabletas de Apple. B.3.3 Requisitos futuros Por razones de tiempo existen algunos requisitos que no se han especificado para esta versi´ on de la aplicaci´ on pero que pueden implmentarse para mejorar el funcionamiento del sistema actual. Estos requisitos son los siguientes: ◦RFU01 - Direcciones por voz.En relaci´ on al requisito funcional RF06.1. Actualmente se muestra el itinerario de la ruta en formato textual, una mejora considerable del sistema es poder guiar al usuario en su ruta mediante comandos de voz, y as´ ı permitirle usar la aplicaci´ on desde el veh´ ıculo en movimiento. ◦RFU02 - Rutas pasando por un punto intermedio. Aunque esta funci´ on no est´ e implementada por el servidor web, podemos afirmar que si primero calculamos la ruta m´ as ecol´ ogica desde el inicio al punto intermedio y despu´ es calculamos la ruta m´ as ecol´ ogica desde este mismo, hasta el destino, tendr´ ıamos la ruta m´ as ecol´ ogica para ir a nuestro destino pasando por un punto intermedio. Por tanto, esto supondr´ ıa un aumento de funcionalidad del sistema. B.4. CASOS DE USO 65 B.4 Casos de uso Una vez definidos los requisitos funcionales y no funcionales, vamos a elaborar los diferentes casos de uso de nuestra aplicaci´ on. Con ellos se pretende dar una visi´ on m´ as detallada de las funciones a implementar. A continuaci´ on se muestra un diagrama de caso de uso que comprende los requisitos funcionales RF01, RF02 yRF07. Posteriormente expondremos otro diagrama de caso de uso comentando otras funcionalidades del sistema. Fig. B.1: Diagrama de casos de uso conteniendo CU01 y CU02 En la figura 2.1 se muestra un diagrama de casos de uso donde est´ an representados el caso de uso “Buscar rutas ecol´ ogicas” (CU01),“Modificar ruta” (CU02). En cualquiera de las dos situaciones, buscar o modificar ruta, el usuario deber´ a seleccionar el comienzo y el final de la ruta, a trav´ es de un mapa o desde un callejero, si lo desea podr´ a autenticarse. Vamos a explicar con m´ as detalle cada uno de estos casos de uso. 66 AP ´ ENDICE B. DOCUMENTO DE ESPECIFICACI ´ ON DE REQUISITOS Caso de uso CU01 - Buscar rutas ecol´ ogicas Descripci´ on: El usuario podr´ a buscar rutas ecol´ ogicas para llegar al destino deseado. Precondici´ on: Se deben seleccionar los puntos de inicio y fin de la ruta. Post-condici´ on: Se mostrar´ a en el mapa las distintas rutas calculadas. Escenario principal: 1. El usuario selecciona desde el mapa o el callejero el punto de inicio. 2. El usuario selecciona desde el mapa o el callejero el punto final. 3. El sistema realiza una petici´ on al servidor con los datos insertados. 4. Los datos devueltos se muestran en el mapa. Escenarios alternativos: 4. No conecta con el servidor por un problema: a) El sistema muestra un mensaje con el error. b) Vuelta al paso 1. 2. El callejero no encuentra la calle: a) El usuario cancela la b´ usqueda por callejero. b) Vuelta al paso 1. Casos de prueba: ◦CP01 - Buscar rutas ecol´ ogicas. El usuario selecciona un punto de inicio desde el mapa o el callejero, realiza la misma acci´ on para el punto final de la ruta. El sistema se conecta con el servidor enviando los par´ ametros de la ruta, se recibe una respuesta y se pinta en el mapa. ◦CP02 - Error en la conexi´ on. Desconectar el acceso Internet, seleccionar el punto inicial en el mapa o en el callejero, realizar la misma acci´ on para el punto final de la ruta. El sistema muestra un error avisando del error ocurrido. B.4. CASOS DE USO 67 Caso de uso CU02 - Modificar ruta Descripci´ on: El usuario podr´ a modificar el punto de inicio y el punto final seleccionados previamente. Precondici´ on: Los puntos inicial y final deben haber sido seleccionados previamente. Post-condici´ on: Se actualizar´ an los puntos inicial y final a los nuevos valores introducidos por el usuario. Escenario principal: 1. El usuario modifica el punto inicial, arrastrando la marca existente en el mapa, o seleccionando un punto desde el callejero. 2. El usuario modifica el punto final, arrastrando la marca existente en el mapa, seleccionando un punto desde el callejero, o manteniendo pulsado el dedo en nuevo lugar en el mapa. 3. El sistema realiza una petici´ on al servidor con los datos insertados. 4. Los datos devueltos se muestran en el mapa. Escenarios alternativos: 2. El usuario cancela el cambio de posici´ on del punto inicial: a) La marca se deja en la misma posici´ on. Casos de prueba: ◦CP03 - Modificar ruta. El usuario modifica la posici´ on del punto de inicio arrastrando la marca en el mapa o desde el callejero, realiza la misma acci´ on para el punto final de la ruta. El sistema se conecta con el servidor enviando los par´ ametros de la ruta, se recibe una respuesta y se pinta en el mapa. ◦CP04 - Cancelar modificaci´ on. El usuario elecciona una marca, cuando est´ e disponible para arrastrarla, el usuario la suelta. El sistema no realiza ninguna acci´ on puesto que la posici´ on es la misma. 68 AP ´ ENDICE B. DOCUMENTO DE ESPECIFICACI ´ ON DE REQUISITOS Para completar todos los casos de uso del sistema mostramos el siguiente diagrama donde aparece el caso de uso CU01 y las relaciones de ´ este con otros. Fig. B.2: Diagrama de casos de uso incluyendo CU01, CU03, CU04, CU05 En este diagrama se pretende explicar que para que el usuario pueda realizar el caso de uso CU03 - Ver emisiones del itinerario debe primero buscar el itinerario implicado. Ya hemos visto en los casos de uso anteriores c´ omo se ejecuta ´ este. La novedad del diagrama anterior es la introducci´ on de nuevos caso de usos relacionados con el caso de uso CU03. Tras buscar la ruta el usuario, la aplicaci´ on debe realizar la petici´ on al servidor CTPATH y mostrar la respuesta recibida para que el usuario pueda ver las emisiones calculadas. Vamos a explicar con detalle cada uno de los casos de uso implicados en el diagrama anterior. Caso de uso CU03 - Ver emisiones del itinerario Descripci´ on: El usuario podr´ a comprobar las emisiones de gases nocivos que emite la ruta elegida. Precondici´ on: Se ha realizado una b´ usqueda de itinerarios. Post-condici´ on: Aparece una vista con los detalles de una ruta incluyendo sus emisiones. Escenario principal: 1. El usuario selecciona una ruta de la tabla mostrada. B.4. CASOS DE USO 69 2. Se abre una pesta˜ na con los datos de la ruta pudiendose ver las emisiones de la ruta. Casos de prueba: ◦CP05 - Ver emisiones del itinerario. El usuario realiza una b´ usqueda de rutas, se obtiene una lista con las rutas calculadas. El usuario selecciona una de ellas. Tras esto, aparece una ventana con los detalles de la ruta y sus emisiones. Caso de uso CU04 - Realizar petici´ on al servidor CTPATH Descripci´ on: La aplicaci´ on deber´ a conectarse al servicio que realiza los c´ alculos de ruta. Precondici´ on: El usuario solicita una b´ usqueda de rutas. Post-condici´ on: Se obtienen las rutas calculadas por el servidor Escenario principal: 1. Se obtienen los par´ ametros de la b´ usqueda del usuario: ◦Coordenadas de los puntos inicial y final (par´ ametros fromPlace y toPlace) ◦Fecha y hora actual (par´ ametros time y date) ◦Tipo de veh´ ıculo (En esta versi´ on s´ olo es para coche. Par´ ametro mode) 2. Se crea la URL para realizar la petici´ on, por ejemplo: https://mallba3.lcc.uma.es/otp/routers/default/plan?fromPlace=36.712, -4.485&toPlace=36.707,-4.434&time=9:18pm&date=06-27-2016&mode=CAR 3. Se ejecuta la petici´ on. 4. Se obtiene la respuesta del servidor. Escenarios alternativos: 4. Se obtiene un error en la petici´ on del servidor: a) Se muestra un mensaje de error. b) Vuelta al paso 1 70 AP ´ ENDICE B. DOCUMENTO DE ESPECIFICACI ´ ON DE REQUISITOS Casos de prueba: ◦CP06 - Realizar petici´ on. La aplicaci´ on obtiene los par´ ametros de la ruta, construye la URL de la petici´ on y la realiza. El servidor devuelve los datos de las rutas calculadas. ◦CP07 - Error en la petici ´ on. La aplicaci´ on obtiene los par´ ametros de la ruta, construye la URL. Sin conexi´ on a Internet se realiza la petici´ on. El sistema muestra un mensaje de error. Caso de uso CU05 - Mostrar respuesta del servidor Descripci´ on: La aplicaci´ on deber´ a mostrar la informaci´ on devuelta por el servidor. Precondici´ on: El servidor ha respondido con los datos de las rutas. Post-condici´ on: Se mostrar´ a la informaci´ on de cada una de las rutas. Escenario principal: 1. Se obtienen los datos de las rutas calculadas por el servidor: 2. Se recoge la informaci´ on de cada ruta en una estructura de datos: 3. Cuando se seleccione una ruta, se acceder´ a a sus datos y se mostrar´ an en una ventana. Casos de prueba: ◦CP08 - Mostrar datos. La aplicaci´ on obtiene la informaci´ on hallada por el servidor, la procesa y la muestra cuando el usuario selecciona una ruta.