wayfis: prototipo de navegación personal para personas …y por encima de todo a flor, por...
TRANSCRIPT
PROYECTO FIN DE CARRERA
WayFiS: Prototipo de
Navegación Personal para
Personas Mayores
Autor: Alberto del Moral Vargas
Tutor: José Arturo Mora Soto
Leganés, marzo de 2013
Departamento de Informática
1
2
3
4
Título: WayFiS, prototipo de navegación personal para personas mayores
Autor: Alberto del Moral Vargas
Director: José Arturo Mora Soto
EL TRIBUNAL
Presidente: __________________________________________________
Vocal: __________________________________________________
Secretario: __________________________________________________
Realizado el acto de defensa y lectura del Proyecto Fin de Carrera el día __ de _______ de 20__ en Leganés, en la Escuela Politécnica Superior de la Universidad Carlos III de Madrid, acuerda otorgarle la CALIFICACIÓN de
VOCAL
SECRETARIO PRESIDENTE
5
6
AGRADECIMIENTOS
Primero de todo, gracias a mi padre y mi madre, por el cariño y el infinito
apoyo que me han dado durante todo este tiempo, y porque de su ánimo
en todos esos sprints ha salido una gran carrera. Gracias a mi abuela, que
siempre me lo ha dado todo; a mis tíos, Alfredo y Eva, y mis primos, Mario
y Marta, por lo mucho que han hecho por mí. Gracias a toda mi familia,
por el apoyo y el afecto que me han mostrado siempre. Sin ellos esta
carrera habría tenido muchos más obstáculos.
A los de casa, Álvaro, Nacho, Pablo y Sergio, porque sin vosotros Las
Perdices no sería Las Perdices ni mi casa sería mi casa. Por resumir puede
que este sea el párrafo más pequeño, pero en importancia es uno de los
más grandes. Gracias por todo.
A mis compañeros de carrera con los que tanto he aprendido y que tanto
han arrimado el hombro, en especial a Jorge, Sohrab y Obi, por todas las
tardes y noches de trabajo y sacrificio, y sobre todo, por todas las risas. En
gran parte gracias a vosotros estoy aquí ahora.
A mi gente de 1º de carrera por darme un año que recordaré siempre, en
especial a Álvaro y Carlos porque a pesar de haber tomado caminos
distintos hace años, aún seguimos como entonces. Gracias por todos los
buenos ratos que me disteis y seguís dándome, y por no haber olvidado
que hay que decirlo más.
A mis compañeros de la FAM, en especial a Canario, Carla, Olalla, Paco,
Rubén, Seni y Vicki. Y por encima de todo a Flor, por aguantarme,
escucharme y darme ánimos. Por todos esos momentos. Sin ti nada habría
sido igual.
A la Universidad Carlos III de Madrid y a sus profesores. Gracias por
exigirme dar lo mejor de mí y (jamás pensé que diría esto) por todas las
horas de trabajo y estudio que me han traído hasta aquí. Gracias por su
exigencia, calidad y profesionalidad.
7
A mi tutor académico, Arturo, por su constante entrega y porque sin su
inestimable ayuda este proyecto no habría sido posible. Te agradezco
mucho todos los ánimos, consejos y enseñanzas que me has dado a lo
largo de todos estos años.
Gracias muy especialmente a la gente de HI Iberia, que me han acogido
durante todos estos meses y me han permitido desarrollar este proyecto.
Gracias en especial a Inma, mi tutora, por sus consejos, su tiempo y su
esfuerzo, y a mis jefes de proyecto, Anna y Raúl, por su paciencia y
dedicación. Y por último, pero no por ello menos importante, gracias a
todos mis compañeros de trabajo por enseñarme tanto y hacerme el día a
día tan agradable.
A todos los que se han cruzado en mi camino durante todo este tiempo y
me han hecho ser quien soy hoy.
Hoy, como cada día, comienza mi futuro, y ahora estoy más preparado
que nunca para afrontarlo. Es hora de nuevos retos.
Es hora de aventuras.
8
RESUMEN
WayFiS es un prototipo de navegación personal enfocado a personas
mayores. Su principal objetivo es asistir a las personas de la tercera edad
en sus desplazamientos urbanos dotándolos de una mayor confianza a la
hora de afrontar estos trayectos, que con el progresivo deterioro asociado
a la edad van suponiendo un mayor esfuerzo para ellos.
El sistema se basa en un par de aplicaciones cuyas funciones se
complementan: una web y una móvil. A través de la aplicación web, los
usuarios pueden establecer sus preferencias personales, necesidades y
limitaciones y efectuar la planificación de rutas, para lo cual se tienen en
cuenta los parámetros personales definidos previamente por el usuario
con el fin de aportar los itinerarios que mejor se adapten a su perfil. Por
otro lado, la aplicación móvil asiste y guía a los usuarios a lo largo de los
recorridos, monitorizando la posición actual de la persona y suministrando
instrucciones paso a paso para facilitar el trayecto. La herramienta está
principalmente dirigida al colectivo de las personas mayores, y por lo
tanto tiene especialmente en cuenta sus necesidades y preferencias más
habituales, así como las limitaciones físicas, fisiológicas y de movilidad
derivadas de las dolencias más comunes.
Esta aplicación busca mejorar el día a día de nuestros mayores dotándoles
de la confianza y los medios necesarios para realizar trayectos urbanos de
manera independiente, aportando a su vez seguridad a sus familiares,
cuidadores y/o responsables.
Palabras clave:
Accesibilidad, movilidad, navegación, planificación, rutas, transporte, desplazamientos, itinerarios, discapacitados, personas mayores, ancianos, asistencia
9
10
ABSTRACT
WayFiS is a personal navigation prototype for seniors. Its main goal is to
assist the elderly people in their urban trips giving them greater
confidence in themselves in order to tackle these routes, helping them to
overcome the increasing effort entailed by the progressive age-related
deterioration.
The system consists of a couple of applications whose functions are
complementary: a website and a mobile app. Through the web application
users can set their personal preferences, needs and constraints and
eventually perform route planning, which takes into account the personal
parameters previously defined by the user in order to provide the best
itineraries adapted to their profile. Moreover, the mobile application
assists and guides users along the route, monitoring the current position
of the person and also providing step by step instructions to make the
journey easier. The tool is primarily addressed to the elderly, and
therefore takes particularly into account their most common needs and
preferences, as well as physical, physiological and mobility limitations and
impairments.
This application is aimed to improve the everyday life of our seniors
providing them with the confidence and the means to make urban trips by
themselves, while their family, caregivers and / or guardians can rest easy.
Keywords: Navigation, mobility, accessibility, planning, transportation, routes, travel, itineraries, disabled, seniors, elderly, assistance
11
12
ÍNDICE DE CONTENIDO
1 Introducción ............................................................................................................. 22
1.1 Marco general .................................................................................................. 22
1.2 Principales objetivos ........................................................................................ 25
1.3 Estructura de la memoria ................................................................................ 27
2 Estado del arte ......................................................................................................... 30
2.1 Descripción general ......................................................................................... 30
2.2 ¿Por qué utilizar estas herramientas? ............................................................. 32
2.3 Características principales de estas aplicaciones ............................................ 32
2.4 Principales características de la herramienta a diseñar .................................. 34
Principales características .................................................................................................... 35
2.5 Análisis detallado de aplicaciones alternativas ............................................... 37
Planificadores de propósito general ................................................................................. 38
Planificadores de propósito específico ............................................................................ 49
Otros proyectos europeos ................................................................................................... 57
3 Análisis ..................................................................................................................... 62
3.1 Objetivo ............................................................................................................ 62
3.2 Definición de alcance del sistema .................................................................... 62
3.3 Definición de actores ....................................................................................... 64
3.4 Requisitos del sistema ..................................................................................... 65
3.5 Especificación de Casos de Uso ....................................................................... 82
4 Diseño .................................................................................................................... 102
4.1 Arquitectura del sistema ................................................................................ 102
4.2 Diagramas de actividad .................................................................................. 106
Login ......................................................................................................................................... 106
Crear ruta ................................................................................................................................ 107
Guardar punto de interés ................................................................................................... 108
Guardar ruta ........................................................................................................................... 108
Cargar punto de interés ...................................................................................................... 110
Cargar ruta .............................................................................................................................. 111
13
4.3 Diagramas de estado ..................................................................................... 112
Ruta ........................................................................................................................................... 112
Punto de Interés .................................................................................................................... 113
4.4 Necesidades de integración ........................................................................... 114
5 Herramientas y tecnologías empleadas................................................................. 116
5.1 Entorno técnico de trabajo ............................................................................ 116
Eclipse ...................................................................................................................................... 116
Firebug ..................................................................................................................................... 116
gedit .......................................................................................................................................... 117
Microsoft Word ..................................................................................................................... 117
Microsoft Project .................................................................................................................. 118
Mozilla Firefox ....................................................................................................................... 118
pgAdmin .................................................................................................................................. 119
5.2 Tecnologías empleadas .................................................................................. 120
Apache Server ........................................................................................................................ 120
Apache Tomcat ...................................................................................................................... 121
CORS ......................................................................................................................................... 121
HTML ........................................................................................................................................ 123
Java ........................................................................................................................................... 124
JavaScript ................................................................................................................................ 125
JSON .......................................................................................................................................... 126
OAuth ....................................................................................................................................... 127
OpenTripPlanner ................................................................................................................... 128
PHP ............................................................................................................................................ 129
PostgreSQL .............................................................................................................................. 130
XML ........................................................................................................................................... 130
6 Análisis económico ................................................................................................ 132
6.1 Consideraciones iniciales ............................................................................... 132
6.2 Planificación ................................................................................................... 133
Planificación de la primera fase del proyecto .............................................................. 134
Planificación de la segunda fase del proyecto ............................................................. 135
6.3 Costes ............................................................................................................. 136
14
Gastos en personal ............................................................................................................... 137
Gastos en software .............................................................................................................. 137
Gastos en material ............................................................................................................... 137
Resumen de gastos .............................................................................................................. 138
7 Conclusiones .......................................................................................................... 140
7.1 Dificultades encontradas ............................................................................... 141
8 Referencias............................................................................................................. 144
8.1 Artículos ......................................................................................................... 144
8.2 Páginas Web ................................................................................................... 144
9 Apéndices ............................................................................................................... 148
9.1 Acrónimos y abreviaturas .............................................................................. 148
15
16
ÍNDICE DE ILUSTRACIONES
Ilustración 1: Google Maps ............................................................................................. 39
Ilustración 2: Nokia Maps ............................................................................................... 45
Ilustración 3: Foxytour .................................................................................................... 50
Ilustración 4: Handimap ................................................................................................. 54
Ilustración 5: Diagrama general de casos de uso ........................................................... 82
Ilustración 6: Diagrama general de casos de uso II ........................................................ 83
Ilustración 7: Diagrama de casos de uso – Extension: Añadir punto de partida ............ 95
Ilustración 8: Diagrama de casos de uso – Extension: Añadir punto de destino ........... 97
Ilustración 9: Diagrama de casos de uso – Extension: Añadir punto intermedio .......... 99
Ilustración 10: Esquema de la arquitectura del sistema .............................................. 103
Ilustración 11: Diagrama de actividad - Login .............................................................. 106
Ilustración 12: Diagrama de actividad – Crear ruta ...................................................... 107
Ilustración 13: Diagrama de actividad – Guardar punto de interés ............................. 108
Ilustración 14: Diagrama de actividad – Guardar ruta ................................................. 109
Ilustración 15: Diagrama de actividad – Cargar punto de interés ................................ 110
Ilustración 16: Diagrama de actividad – Cargar ruta .................................................... 111
Ilustración 17: Diagrama de estados - Ruta ................................................................. 112
Ilustración 18: Diagrama de estados – Punto de interés ............................................. 113
Ilustración 19: Diagrama de Gantt – Planificación de la 1ª fase del proyecto ............. 134
Ilustración 20: Diagrama de Gantt – Planificación de la 2ª fase del proyecto ............. 135
17
18
ÍNDICE DE TABLAS
Tabla 1: Requisitos funcionales ...................................................................................... 66
Tabla 2: Requisitos no funcionales ................................................................................. 67
Tabla 3: RF-001 Registro en el sistema ........................................................................... 68
Tabla 4: RF-002 Iniciar sesión en el sistema ................................................................... 68
Tabla 5: RF-003 Cerrar sesión en el sistema ................................................................... 69
Tabla 6: RF-004 Cambiar configuración de la cuenta de usuario ................................... 69
Tabla 7: RF-005 Cambiar preferencias de salud de la cuenta ........................................ 69
Tabla 8: RF-006 guardar ruta .......................................................................................... 70
Tabla 9: RF-007 Consultar rutas guardadas .................................................................... 70
Tabla 10: RF-008 Cargar ruta guardada .......................................................................... 70
Tabla 11: RF-009 Eliminar ruta guardada ....................................................................... 70
Tabla 12: RF-010 Editar ruta guardada ........................................................................... 71
Tabla 13: RF-011 Guardar punto de partida de una ruta como punto de interés ......... 71
Tabla 14: RF-012 Guardar punto de destino de una ruta como punto de interés ......... 71
Tabla 15: RF-013 Guardar punto intermedio de una ruta como punto de interés ........ 72
Tabla 16: RF-014 Consultar puntos de interés ............................................................... 72
Tabla 17: RF-015 Eliminar punto de interés ................................................................... 72
Tabla 18: RF-016 Editar punto de interés ....................................................................... 73
Tabla 19: RF-017 Introducir punto de partida desde el mapa ....................................... 73
Tabla 20: RF-018 Introducir punto de partida escribiendo su dirección ........................ 74
Tabla 21: RF-019 Introducir punto de partida cargando un punto de interés ............... 74
Tabla 22: RF-020 Introducir punto de destino desde el mapa ....................................... 75
Tabla 23: RF-021 Introducir punto de destino escribiendo su dirección ....................... 75
Tabla 24: RF-022 Introducir punto de destino cargando un punto de interés .............. 76
Tabla 25: RF-023 Introducir punto intermedio desde el mapa ...................................... 76
Tabla 26: RF-024 Introducir punto intermedio escribiendo su dirección ...................... 77
Tabla 27: RF-025 Introducir punto intermedio cargando un punto de interés ............. 77
Tabla 28: RF-026 Eliminar punto intermedio ................................................................. 78
Tabla 29: RF-027 Generar nueva ruta ............................................................................ 78
19
Tabla 30: RF-028 Mostrar otra ruta creada/cargada ..................................................... 79
Tabla 31: RF-029 Ver etapas de la ruta de forma detallada ........................................... 79
Tabla 32: RF-030 Cerrar una ruta ................................................................................... 79
Tabla 33: RF-031 Intercambiar los puntos de partida y destino de una ruta................. 80
Tabla 34: RF-032 Otorgar un nombre unívoco a un punto de interés guardado ........... 80
Tabla 35: RF-033 Otorgar un nombre unívoco a una ruta guardada ............................. 81
Tabla 36: RF-034 Aumentar el zoom del mapa .............................................................. 81
Tabla 37: RF-035 Reducir el zoom del mapa .................................................................. 81
Tabla 38: RF-035 Desplazarse por el mapa .................................................................... 82
Tabla 39: Caso de uso – Registrarse ............................................................................... 84
Tabla 40: Caso de uso - Iniciar sesión ............................................................................. 84
Tabla 41: Caso de uso - Cerrar sesión ............................................................................. 85
Tabla 42: Caso de uso - Cambiar configuración de cuenta ............................................ 85
Tabla 43: Caso de uso - Cambiar preferencias de salud ................................................. 85
Tabla 44: Caso de uso - Guardar punto de interés ......................................................... 86
Tabla 45: Caso de uso - Editar punto de interés............................................................. 87
Tabla 46: Caso de uso - Eliminar punto de interés ......................................................... 88
Tabla 47: Caso de uso - Crear ruta ................................................................................. 89
Tabla 48: Caso de uso - Visualizar ruta ........................................................................... 89
Tabla 49: Caso de uso - Cerrar ruta ................................................................................ 90
Tabla 50: Caso de uso - Guardar ruta ............................................................................. 90
Tabla 51: Caso de uso - Cargar ruta ................................................................................ 91
Tabla 52: Caso de uso - Editar ruta ................................................................................. 91
Tabla 53: Caso de uso - Eliminar punto de interés ......................................................... 92
Tabla 54: Caso de uso - Repasar recorrido de ruta ........................................................ 92
Tabla 55: Caso de uso - Añadir punto de partida ........................................................... 93
Tabla 56: Caso de uso - Añadir punto de destino ........................................................... 93
Tabla 57: Caso de uso - Intercambiar puntos de partida y destino ............................... 93
Tabla 58: Caso de uso - Añadir punto intermedio .......................................................... 94
Tabla 59: Caso de uso - Eliminar punto intermedio ....................................................... 94
Tabla 60: Caso de uso - Cargar punto de partida ........................................................... 95
Tabla 61: Caso de uso - Establecer punto de partida a partir de una dirección ............ 96
20
Tabla 62: Caso de uso - Establecer punto de partida desde el mapa ............................ 96
Tabla 63: Caso de uso - Cargar punto de destino ........................................................... 97
Tabla 64: Caso de uso - Establecer punto de destino a partir de una dirección ............ 98
Tabla 65: Caso de uso - Establecer punto de destino desde el mapa ............................ 98
Tabla 66: Caso de uso - Cargar punto intermedio .......................................................... 99
Tabla 67: Caso de uso - Establecer punto intermedio a partir de una dirección ......... 100
Tabla 68: Caso de uso - Establecer punto intermedio desde el mapa ......................... 100
Tabla 69: Gastos de Personal ....................................................................................... 137
Tabla 70: Gastos de Software ....................................................................................... 137
Tabla 71: Gastos de Material ........................................................................................ 137
Tabla 72: Coste Total del Proyecto ............................................................................... 138
21
22
1 INTRODUCCIÓN
1.1 MARCO GENERAL
Las sociedades actuales están viendo aumentar el número de personas
mayores a un ritmo nunca antes conocido. Este envejecimiento de la
población en los países desarrollados lleva aparejada la necesidad de una
mayor cobertura social y sanitaria para estas personas, y esto no es
siempre posible desde un punto de vista económico, ya que los grupos
poblacionales encargados de suministrar los medios necesarios para
mantener estos servicios se están viendo menguados precisamente por
este fenómeno. Por lo tanto, la necesidad de mecanismos para cubrir
estas necesidades crecientes es más que evidente.
Las personas mayores ven acentuadas sus necesidades a medida que
envejecen, ya que sus capacidades y autonomía van viéndose reducidas
progresivamente. En muchos casos, esta disminución de sus habilidades
les lleva a verse superados por ciertas tareas cotidianas, provocándoles un
sentimiento de frustración e incapacidad por el que abandonan muchos
de sus hábitos. Esta situación se ve agravada en muchos casos por
dolencias propias de la edad, como la fatiga o los dolores musculares, por
las que van renunciando a tareas que antes les eran habituales, como
realizar desplazamientos urbanos de manera independiente.
Afortunadamente, las nuevas tecnologías tienen mucho que aportar en
este campo. En los últimos años el desarrollo de dispositivos táctiles
portables, como los smartphones o teléfonos inteligentes, ha sido
espectacular. Estos dispositivos ligeros y portables poseen una interfaz
que simplifica considerablemente la aparatosa mecánica de un ordenador
tradicional, sustituyendo el teclado y el ratón por simples toques en la
pantalla. Por lo general, las personas de la tercera edad tienen poca o
ninguna experiencia con los ordenadores y las nuevas tecnologías, y
consideran estas herramientas como algo demasiado complejo y fuera de
su alcance. La testarudez con que pueden rechazar aplicaciones que
podrían revolucionar su vida por el simple hecho de tener que acceder a
23
un ordenador podría echar para atrás a muchos desarrolladores con muy
buenas ideas. En muchos casos, es la forma de presentarlo lo que hace al
usuario acercarse a un producto, por lo que no es suficiente hacer una
buena aplicación que pueda hacerles la vida más fácil a las personas
mayores, sino que es necesario también ponerse en su lugar y
proporcionarles un modo de uso que les resulte atractivo y cómodo.
El caso de los desplazamientos urbanos e interurbanos es particularmente
destacable como ejemplo de rutina que con la edad y las limitaciones
derivadas de ésta pasa de ser una actividad habitual a una labor muy difícil
de realizar sin ayuda. Los entornos urbanos actuales pueden resultar muy
confusos para una persona mayor, y ésta puede sentirse desorientada con
facilidad. Además, en muchos casos, las grandes distancias que se han de
recorrer entre los puntos de origen y destino hacen la tarea algo imposible
para los mayores, cuya capacidad de adquirir información del entorno es
limitada. Memorizar las instrucciones para llegar a una dirección o
descubrir la localización de las paradas y los horarios de transportes
públicos puede resultar algo muy frustrante para ellos, y esa sensación
induce de forma decisiva a acrecentar el sentimiento de indefensión e
incapacidad para desenvolverse en la ciudad.
Por ello, en este Proyecto de Fin de Carrera se propone WayFiS [34] , una
herramienta que cubre una necesidad básica y muy importante para estas
personas. Con el apoyo de WayFiS las personas mayores tendrán la
posibilidad de encontrar maneras de realizar sus desplazamientos de
forma segura y sencilla, a través de un sistema que tendrá en cuenta todas
sus limitaciones y necesidades a la hora de trazar la ruta. Además, al poder
usarlo de forma sencilla desde un dispositivo móvil, podrán llevarlo con
ellos en todo momento sintiéndose así más seguros. Esta pues es la
finalidad última de este proyecto: aumentar la seguridad y la confianza en
sí mismos de las personas mayores a la hora de realizar desplazamientos,
haciéndoles así más autosuficientes.
Este sistema está enmarcado en el contexto del proyecto europeo
“WayFiS” (Way Finding for Seniors), en el que participan varios socios, y
cada uno de ellos está encargado de desarrollar una parte del sistema
24
final. La empresa contratante, HI Iberia, está encargada de las siguientes
tareas:
Estudio de los requisitos de usuario y casos de uso: ha contribuido
en la elección y definición de los casos de uso más significativos
dentro de los identificados a partir de los requisitos de los usuarios.
Especificaciones técnicas: ha llevado a cabo la identificación de las
especificaciones funcionales del servicio a partir de los requisitos de
los usuarios. Tras ello, a partir de la especificación funcional, la
especificación técnica ha sido llevada a cabo con el objetivo de
definir aspectos clave de la arquitectura.
Módulo de recopilación de datos: este módulo incluye el cuadro
común de recopilación de todas las informaciones que se
intercambiarán en el servicio WayFiS. HI Iberia ha contribuido en el
desarrollo de las interfaces con los módulos de búsqueda y en la
identificación de fuentes de información, así como integración del
módulo con la arquitectura global del sistema.
Módulo de creación de perfil de usuario: este módulo gestiona los
perfiles de los usuarios, desde la creación hasta la modificación de
las preferencias que los usuarios expresan en relación a sus
limitaciones de movilidad y otras necesidades relacionadas con su
salud. Su objetivo es trasladar las características de los perfiles que
definan los usuarios a especificaciones y requisitos que permitan
establecer la ruta óptima para el usuario. Además se encargará de la
gestión, autenticación y validación de los usuarios.
Módulo de búsqueda y desarrollo del conocimiento (también
KDM, Knowledge Discovery Module): esta tarea lleva a cabo el
desarrollo del módulo de búsqueda y desarrollo del conocimiento
que se utiliza para identificar los datos y las informaciones útiles
que determinarán la personalización de las rutas, y que por tanto
serán claves para proporcionar una ruta adaptada a las necesidades
del usuario.
25
Servicio de planificación de rutas con antelación: esta tarea incluye
el desarrollo de una interfaz para el ordenador que permite una
planificación previa de la ruta antes de salir de casa. Esta
planificación tiene en cuenta las preferencias del usuario para
personalizar el recorrido, la información obtenida del módulo de
obtención de datos y la proporcionada por el módulo de
conocimiento.
A lo largo de esta memoria se cubrirá la experiencia del estudiante
durante el desarrollo del sistema, centrándose principalmente en su labor
en los módulos de recopilación de datos, creación de perfil de usuario y
planificación de rutas.
1.2 PRINCIPALES OBJETIVOS
El objetivo principal del proyecto es la creación de una plataforma de
asistencia para la planificación de rutas personalizadas y el guiado en
recorridos complejos (interiores, exteriores, a pie y en transporte público)
para personas mayores.
La aplicación permitirá a las personas mayores superar las barreras y
dificultades que a menudo les limitan la posibilidad de sentirse sanos y
seguros y que comprometen gravemente su movilidad tanto en interiores
como al aire libre. Algunas de las innovaciones que proporcionará a las
personas mayores son:
Permitir la identificación de la ruta con la actividad física óptima:
permitirá establecer parámetros tales como un límite de distancia a
pie para realizar las rutas teniendo en cuenta el cansancio
acumulado o la incapacidad de caminar de forma prolongada.
Identificar rutas que tengan en cuenta las necesidades
alimentarias y las limitaciones derivadas de dolencias o
enfermedades: problemas físicos causados por enfermedades como
26
cansancio o fatiga, limitaciones de movilidad que puedan requerir el
uso de ayudas para caminar o necesidades dietéticas específicas
serán contemplados a la hora de realizar la ruta estableciendo
descansos entre etapas del trayecto, limitando la distancia de los
tramos, resaltando los establecimientos que ofrezcan menús
acordes con las necesidades dietéticas del usuario, etc.
Evitar rutas inaccesibles: para reafirmar la autoconfianza e
independencia del usuario se evitarán por todos los medios rutas
que puedan resultar peligrosas o inaccesibles, haciendo así que la
persona se sienta segura de que llegará a su destino.
Recibir notificaciones al desviarse de la ruta trazada: para asegurar
que el usuario no se desvía de la ruta trazada y que no se siente
perdido o desubicado en un estadio posterior del trayecto, recibirá
notificaciones en su dispositivo móvil cuando se detecte que se está
desviando de la ruta establecida.
Encontrar las instalaciones necesarias a lo largo de la ruta
(farmacias, hospitales, baños, etc.): en caso de que la persona
tenga necesidades alimentarias, sanitarias o de movilidad especiales
que precisen de un tipo específico de establecimiento o instalación
durante la ruta, ésta será tenida en cuenta a la hora del cálculo del
trayecto.
Rutas optimizadas de acuerdo a las preferencias del usuario: los
parámetros que se tendrán en cuenta a la hora de la planificación
de la ruta vendrán especificados personalmente por el usuario,
siendo él quien establezca sus preferencias y prioridades.
La aplicación tendrá en cuenta el perfil personalizado del usuario en todo
momento para adecuar los resultados a sus necesidades. Esto implica que
la elaboración de rutas se modificará en función de los criterios definidos
por el usuario para hacer la experiencia de cada persona satisfactoria y
adecuada a sus limitaciones. Además, existirá la posibilidad de guardar
tanto las rutas realizadas como los puntos de interés que el usuario
27
considere relevantes o de uso común (“centro de salud”, “casa de mi
hijo”, “mercado”, etc.) para poder reutilizarlos en el futuro.
El sistema contará con una interfaz doble: un servicio para el hogar de pre-
planificación con el ordenador y un servicio con interfaz intuitiva para el
móvil en tiempo real y guiado continuo a lo largo de la ruta.
1.3 ESTRUCTURA DE LA MEMORIA
Este apartado muestra la estructura en la que se ha articulado esta
memoria y los contenidos desarrollados en cada una de sus secciones. Las
secciones de este documento son las siguientes:
1. Introducción: apartado de apertura en que se expone el marco en el
que se desarrolla el proyecto, unas nociones básicas sobre el área
de acción de la herramienta desarrollada y sus principales objetivos.
2. Estado del arte: en primer lugar en esta sección se aporta una
descripción general del ámbito en que se ubica una herramienta
como WayFiS y del estado del entorno social y de mercado en el
que desarrolla su función. Acto seguido se aportan motivos que
justifican el uso y avalan la utilidad de este tipo de herramientas. A
continuación se abordan las características que definen e identifican
a una aplicación de esta familia y seguidamente se detallan las que
caracterizan más específicamente a WayFiS. Para finalizar se realiza
un análisis de otras herramientas semejantes a WayFiS, clasificadas
en categorías en función de su finalidad y de los rasgos que
comparten con nuestra aplicación.
3. Análisis: en la primera fase del apartado de análisis se establecen
los objetivos de esta importante fase del desarrollo y se definen el
alcance del sistema y los distintos actores que participarán en él. A
continuación se detallan los requisitos del sistema, cuya función es
recoger todas las funcionalidades que contendrá la aplicación. Por
último, se presentan los casos de uso que definirán el sistema, que
28
derivan de los requisitos previamente expuestos. Tras plasmar los
distintos elementos obtenidos en la fase de análisis, la aplicación
queda ya definida en cuanto a funcionalidades y modos de
operación.
4. Diseño: en este apartado, los resultados del proceso de análisis se
traducen en un plan de arquitectura tecnológica y de
procedimientos a seguir para llevar a cabo la solución. Los
principales elementos de este apartado son la arquitectura del
sistema, que aporta la integración de soluciones tecnológicas
estructurales y los diagramas de actividad y de estados, que simulan
la futura estructura lógica y el discurrir de los flujos de datos entre
sus componentes. Al final de este apartado se adjunta una pequeña
sección en la que se comentan las dificultades de integración
encontradas a la hora de implementar las soluciones especificadas
en la fase de diseño.
5. Entorno técnico de trabajo: este apartado tiene dos partes
diferenciadas. En la primera se listan las herramientas principales
que se han empleado a lo largo del desarrollo del proyecto para
editar y crear contenidos, tanto a nivel documental como técnico:
editores de texto, entornos de desarrollo, etc. Y por otro lado, se
encuentran las tecnologías que se han empleado en el apartado
técnico para implementar la solución demandada; en esta sección
figuran: lenguajes de programación, formatos de datos, tecnologías
de autenticación, servidores de aplicaciones, etc.
6. Análisis económico: la sección comienza con la exposición de la
planificación del proyecto y su desglose en distintas fases y tareas,
con el correspondiente seguimiento a lo largo del desarrollo. Acto
seguido, y tomando como base la planificación anterior, se efectúa
un análisis económico de los gastos derivados del proyecto y se
extrae el coste total de éste.
7. Conclusiones: sección en la que se exponen las conclusiones
extraídas del proceso de desarrollo del proyecto y se detallan las
29
dificultades afrontadas y las soluciones propuestas, a la vez que se
valoran los conocimientos y experiencia adquiridos.
8. Referencias: en esta sección se listan las referencias utilizadas para
la elaboración del proyecto y de esta memoria.
9. Apéndices: Adicionalmente se adjunta una lista de referencia con
los acrónimos y abreviaturas empleados a lo largo del documento
para facilitar su consulta y entendimiento por parte del lector.
30
2 ESTADO DEL ARTE
2.1 DESCRIPCIÓN GENERAL
En los últimos tiempos las aplicaciones de mapas online han sufrido una
gran revolución, convirtiéndose en una herramienta de uso frecuente para
millones de usuarios. Estos sistemas cartográficos no son únicamente
mapas o planificadores de rutas, sino herramientas integradas muy
completas, y en su mayoría de uso gratuito, que nos permiten desde la
planificación de largas rutas a la visualización de entornos urbanos a pie
de calle. La popularización de los teléfonos inteligentes (o smartphones)
con acceso a internet junto con la gratuidad de uso de estas aplicaciones
cartográficas, sus amplias funcionalidades, su contenido actualizado y la
cobertura global de estas herramientas ha ido desplazando
progresivamente a los tradicionales dispositivos GPS de navegación
pasando en la actualidad a ser de forma cada vez más notable el estándar
en geolocalización y planificación de rutas tanto para vehículos como para
peatones. El potencial que poseen estas herramientas les hace un material
muy valioso para el desarrollo de nuevas aplicaciones basadas en sus
funcionalidades, de las que este proyecto es un buen ejemplo.
La competencia desatada entre gigantes del mundo de la computación en
los últimos años, como Apple, Google o Microsoft, por el control de este
sector del mercado ha disparado la calidad de las aplicaciones
cartográficas, aportando éstas cada vez nuevas funcionalidades para
diferenciarse de los competidores: análisis de tráfico en tiempo real,
cálculo de rutas teniendo en cuenta el tráfico actual, información del
transporte público, búsqueda de establecimientos (librerías, cines,
restaurantes, etc.), calificación y recomendación de estos
establecimientos por parte de los usuarios, visualización de fotos y
grabaciones de vídeo de entornos públicos en tiempo real o información
de la situación atmosférica entre otros.
Paralelamente a estas aplicaciones han surgido alternativas de código
abierto, como OpenStreetMap [24] , que intentan proveer a la comunidad
31
de desarrolladores de opciones no privadas en las que basar sus
aplicaciones y herramientas cartográficas. Estas plataformas ofrecen por
lo general un amplio abanico de funcionalidades bajo licencias de código
abierto, pero precisamente por este motivo pueden resultar un obstáculo
para el desarrollo de programas comerciales, ya que para cumplir sus
términos de licencia el código desarrollado sobre el original de la
plataforma ha de hacerse de disponibilidad pública.
Por otro lado, el otro sector de mercado concerniente a este proyecto son
las aplicaciones para personas mayores o discapacitadas. Este ámbito a día
de hoy no ha sido extensivamente explotado de forma comercial debido a
diversos factores, entre los que destaca la baja implicación de las personas
mayores con la tecnología moderna. Por lo general, las personas mayores
no están habituadas a utilizar ordenadores o smartphones, y usar una
herramienta de este tipo sin haber tenido ningún tipo de contacto previo
con algo similar les supone una gran dificultad [3] . Al enfrentarse a estas
herramientas se les exige adoptar una nueva forma de pensar que
requiere la memorización de secuencias de pasos para construir
estrategias de uso y la construcción de un fuerte modelo conceptual del
modelo subyacente y de las dimensiones de la tarea a realizar. El
envejecimiento lleva aparejados problemas de percepción y retentiva,
como la disminución de la visión o la reducción de la memoria a corto
plazo, lo cual es un obstáculo mayor si cabe que lo anterior, y dificulta
sobremanera el desempeño de estas labores y, por tanto, la utilización de
estos dispositivos por parte de las personas mayores [2] .
Sin embargo, en los últimos años se han venido desarrollando numerosos
proyectos financiados con fondos tanto privados como públicos para el
desarrollo de aplicaciones enfocadas a este colectivo. Por lo general, la
finalidad de estos proyectos es la de facilitar sus labores diarias y
simplificar la comunicación con sus familiares a través de los dispositivos
modernos. En cierta medida, se enfocan como una extensión de los
servicios sociales y una ampliación de su cobertura a través de las nuevas
tecnologías, ya que estas ofrecen un nuevo horizonte de posibilidades a
los organismos públicos y las familias para velar por la seguridad y
bienestar de sus mayores [5] .
32
2.2 ¿POR QUÉ UTILIZAR ESTAS HERRAMIENTAS?
Actualmente, a causa del trabajo y los niños, muchas familias no pueden
hacerse cargo debidamente de sus mayores. Sin embargo muchos de ellos
quieren valerse por sí mismos, rechazando ser internados en residencias.
No obstante, incluso los ancianos que ingresan en estas instituciones
procuran seguir con un ritmo de vida similar al que tenían anteriormente,
intentando desenvolverse de manera independiente en la medida de lo
posible. A pesar de todo, la edad y el deterioro de facultades que acarrea
perjudica seriamente la independencia de estas personas, que poco a
poco ven mermadas sus capacidades y el normal desarrollo de sus tareas
cotidianas. Por ello, cualquier ayuda que les permita seguir manteniendo
su independencia en la vida diaria les sería bienvenida.
En otro ámbito, los cuidadores de estas instituciones tienen un gran
interés en que sus mayores dispongan del mayor grado de libertad
posible, siempre que se cuente con la debida seguridad. Por ello,
aplicaciones como estas que dotan a las personas mayores de un mayor
grado de independencia sin necesidad de supervisión directa repercuten
positivamente en la labor de estos profesionales y, a su vez, en la felicidad
de sus internos.
Por lo tanto, los asistentes de navegación destinados a facilitar la
orientación y seguridad de los mayores en sus trayectos diarios, aumentan
su independencia y confianza en sí mismos a la hora de realizar por su
cuenta desplazamientos en entornos urbanos, así como en viajes de
mayor distancia. En consecuencia podemos concluir que este tipo de
aplicaciones supone una gran ayuda para estas personas y su entorno.
2.3 CARACTERÍSTICAS PRINCIPALES DE ESTAS APLICACIONES
Las aplicaciones de búsqueda de rutas, por lo general, comparten ciertas
características, que se tornan más específicas en el caso de estar
orientadas a personas mayores:
33
Personalización del producto: las personas a las que va dirigido el
producto necesitan sentirse seguras utilizando la aplicación y
disponer de plena confianza en que el producto siempre buscará lo
mejor para ellos. Por ello la aplicación ha de ser configurable a las
necesidades de cada persona, de tal manera que cada usuario
pueda confiar en que los resultados que ésta le proporcione estén
adaptados a sus necesidades específicas.
Uso de tecnologías amigables para el usuario: al ser un público en
su mayoría reacio a utilizar las nuevas tecnologías, las aplicaciones
dirigidas a este público han de ser lo más sencillas e intuitivas
posibles, de tal forma que no supongan un obstáculo añadido a la
hora de ser usadas por personas mayores. Por lo general, las
aplicaciones dirigidas a este público, se caracterizan por unas
interfaces simplificadas y muy visuales, fácilmente usables y sin
sobrecarga de información, para hacerlas viables para su uso por
parte de este colectivo. Las fuentes y los elementos interactivos,
como los botones o los menús, suelen ser grandes y coloridos, de tal
forma que contrasten vivamente y sean fácilmente reconocibles. En
resumen, las características principales de las aplicaciones dirigidas
a este público son dos: la simplicidad y la accesibilidad.
Adaptación a sus limitaciones de salud: es necesario que la
aplicación presente la posibilidad de establecer una configuración
personalizada para cada usuario que tenga en cuenta sus
limitaciones particulares. Dos personas con diferentes necesidades
no están interesadas en el mismo tipo de ruta ni en los mismos
puntos de interés.
Mostrar los caminos más sencillos: debido a las limitaciones de
movilidad y orientación en el entorno urbano, la aplicación ha de
ser capaz de proveer al usuario de las rutas más sencillas de entre
todas las posibles.
34
Mostrar los puntos de interés cercanos: la orientación en el
entorno urbano no consta únicamente de hacer saber al usuario
dónde está, sino también qué le rodea. La aplicación ha de ser capaz
de mostrar los establecimientos y servicios públicos que el usuario
haya declarado de interés en el entorno en que se encuentre. Esto
facilitará al usuario reaccionar ante una emergencia o situación
imprevista y sentirse más seguro y respaldado.
2.4 PRINCIPALES CARACTERÍSTICAS DE LA HERRAMIENTA A
DISEÑAR
La aplicación que se va a desarrollar está enfocada a facilitar la orientación
y seguridad de los mayores en sus trayectos diarios, aumentando su
independencia y confianza en sí mismos a la hora de realizar por su cuenta
desplazamientos en entornos urbanos. En cierta medida, podría
considerarse como una extensión a través de las nuevas tecnologías de la
cobertura de los servicios sociales, ya que se ofrece un nuevo horizonte de
posibilidades a los organismos públicos y las familias para velar por la
seguridad y bienestar de sus mayores.
Como ya se ha comentado anteriormente, las limitaciones derivadas de la
edad y la falta de contacto con la tecnología exigen que sea la herramienta
la que se acerque a su público. La experiencia en el desarrollo de
interfaces para este colectivo dicta que muy a menudo las personas
mayores encuentran dificultades en la comprensión de la forma en que
funciona una aplicación informática [3] . En muchos casos, tratan de tomar
prestado el modelo de otro mecanismo o dispositivo que conocen, como
por ejemplo el de un reproductor de vídeo, y esperan que todo suceda
con sólo pulsar un botón. Al sentirse desprotegidos ante la tecnología
tienden a aferrarse a lo que ya conocen y sufren el miedo permanente de
romper las cosas si hacen algo mal. El concepto de diálogo con la máquina
y aprender a utilizar un lenguaje en la interfaz a través de ensayo y error
suele resultar un trance nuevo y extraño para ellos. Y además de esta
aparente indefensión que sienten ante la tecnología, existen problemas
35
adicionales que derivan de la falta de comprensión de la relación entre las
teclas de función y las funciones que representan y del concepto de
mapear las tareas a una secuencia de pasos para lograr una meta, lo cual
se agrava en situaciones de deterioro de la memoria interfiriendo
directamente en la actividad exploratoria y dificultando recordar
combinaciones de acciones y resultados [2] .
Se podría decir que, en líneas generales, esta aplicación habrá de
caracterizarse por tener unas interfaces simplificadas y muy visuales,
fácilmente usables y sin sobrecarga de información, para hacerlas viables
para ser usadas por personas mayores [3] ; los pasos necesarios para
efectuar las tareas han de ser simples e intuitivos, de tal forma que
resulten sencillos de recordar y repetir [1] [4] . En resumen, en el apartado
de usabilidad el sistema ha de caracterizarse por dos aspectos: simplicidad
y accesibilidad.
PRINCIPALES CARACTERÍSTICAS
Las funcionalidades más destacadas de la herramienta son:
Creación de rutas: La aplicación permitirá al usuario planificar rutas
entre dos puntos, suministrándole el recorrido más optimizado a
sus necesidades de entre todos los posibles, tomando como
referencia sus preferencias de usuario y sus necesidades de salud.
Las rutas propuestas por la aplicación pueden estar pensadas para
cubrirse completamente a pie o bien utilizando transporte público.
Personalización de rutas: La aplicación permitirá al usuario
configurar parámetros personalizados de movilidad y salud como el
uso de silla de ruedas, la distancia máxima que puede recorrer a pie,
la preferencia en el uso de transportes públicos, y muchos otros,
que se tendrán en cuenta a la hora de planificar sus rutas, dando
como resultado rutas adaptadas a sus necesidades. Para esto se
empleará una herramienta denominada Módulo de Descubrimiento
de Conocimiento (KDM, Knowledge Discovery Module) que
36
aplicando procesos de inteligencia artificial extraerá información
sobre el uso que las personas hacen de la herramienta y los
patrones que emplean al planificar rutas, aplicándolo en las
sesiones futuras para mejorar la experiencia del usuario y adaptar
los resultados aún más a sus necesidades e intereses.
Gestión de puntos de interés: La aplicación permitirá al usuario
guardar las localizaciones que más utilice para que pueda utilizarlas
a menudo en sus rutas con mayor rapidez y facilidad. Esto le
permitirá tener a mano sus direcciones más comunes para
utilizarlas en sus rutas sin tener que introducir los datos cada vez
que desee visitarlas: las casas de sus hijos, los centros de salud
cercanos, los comercios a los que acuda habitualmente, etc.
Gestión de rutas: La aplicación permitirá al usuario guardar y
gestionar las rutas más frecuentes para simplificar su labor con la
herramienta. De esta manera, el usuario tan sólo necesitará
planificar la ruta una vez, y podrá consultarla tantas veces necesite
sin tener que volver a repetir el proceso.
Seguimiento de la ruta: Desde la aplicación móvil se proporcionará
un seguimiento a tiempo real de la posición del usuario y de su
ubicación respecto al trayecto de la ruta. Este servicio no sólo se
ofrece en exteriores, sino que también se dispone de un mecanismo
de posicionamiento en interiores que permite al usuario conocer su
ubicación incluso dentro de lugares cerrados, como edificios.
Intérprete de direcciones escritas y sobre mapa: Las direcciones de
las localizaciones de la ruta, como por ejemplo los puntos de origen
y destino, pueden ser introducidas tanto seleccionando la ubicación
en el mapa como escribiendo su dirección física en los campos
habilitados al efecto.
Navegación guiada por voz: La aplicación móvil ofrece la posibilidad
de guiar al usuario empleando un sistema de instrucciones por voz
37
que reproduce todas los pasos a seguir especificados en la ruta. Este
sistema puede aplicarse a cualquier tipo de ruta generada por la
aplicación, ya sea a pie o utilizando transporte público.
Disponibilidad en varios idiomas: La aplicación estará disponible
inicialmente en tres idiomas: inglés, español y húngaro.
2.5 ANÁLISIS DETALLADO DE APLICACIONES ALTERNATIVAS
La viabilidad de este proyecto pasa por analizar sus posibles competidores
y la situación actual del mercado. A continuación vamos a analizar
diferentes alternativas existentes actualmente en el mercado, así como
sus características más relevantes siempre enfocadas a su uso por parte
de personas mayores.
En el campo de los navegadores existen infinidad de alternativas, pero
muchas de ellas han sido descartadas bien por tener un enfoque
claramente dirigido a otras finalidades o por otras carencias estructurales
o funcionales que no las hacían viables para una aplicación de estas
características.
Antes de comenzar la comparativa, para que el lector no extraiga una
conclusión sesgada de este estudio, hay que remarcar que el uso que se
ha hecho de las herramientas analizadas no ha sido extensivo ni
prolongado. La gran cantidad de opciones con que cuentan muchas de
ellas y el rápido grado de evolución que presentan hace imposible dar una
versión ajustada y rigurosamente actualizada de todas. Los principales
esfuerzos de este estudio se han centrado en analizar los factores
relacionados con la posible aplicación de cada una de estas herramientas
al entorno de los asistentes de navegación para personas mayores y no así
tanto en otros factores como la diversidad de sus capacidades o su
potencia. Una indagación en mayor profundidad de las herramientas
analizadas de manera más exhaustiva y concienzuda podría sacar a la luz
conclusiones diferentes de las extraídas en este pequeño estudio, cuya
38
intención no es otra que esbozar la situación de mercado en que se
encuentra WayFiS respecto a posibles competidores.
Las herramientas analizadas han sido las siguientes:
Planificadores de propósito general:
o Google Maps
o Nokia Here
Planificadores de propósito específico:
o Foxytour
o Handimap
Otros proyectos europeos:
o Stimulate
o Entrance
PLANIFICADORES DE PROPÓSITO GENERAL
Existen numerosas aplicaciones de planificación de rutas que no
contemplan entre sus objetivos servir a un propósito específico o aun
grupo particular de usuarios, como las personas mayores. La función de
estas herramientas suele ser la de cubrir la necesidad del público general
de planificar desplazamientos y rutas; sin embargo, no suelen ofrecer la
posibilidad de personalizar los detalles de la ruta en función de las
necesidades específicas de salud o movilidad del usuario más allá de los
transportes que se pretendan utilizar durante el desplazamiento. Existe
muchas aplicaciones de este tipo, pero aquí sólo vamos a abordar dos de
sus representantes más destacados: Google Maps [22] y Nokia Here [15] ,
aunque existe un gran número de alternativas (Bing Maps [8] , Yahoo
Maps [21] , etc.).
39
GOOGLE MAPS
Google Maps [22] es probablemente la herramienta más conocida y
utilizada para la planificación de rutas. La gran aceptación tanto de su
formato para usuarios como en el de servicios para otras aplicaciones
(geocodificación, mapas, información de establecimientos, mapas con
vista a pie de calle, etc.) unido a uno de los catálogos de datos más
extensos y completos que existen hacen de Google Maps un punto
obligado a tratar en este apartado. Aquí nos centraremos en discutir la
vertiente dirigida a usuarios (y no la de servicio web) , puesto que es la
más próxima está a los servicios ofrecidos por WayFiS. Google Maps está
disponible tanto en aplicación web como en aplicación para móviles,
contando esta última versión con un sistema de localización del
dispositivo basado en diversas tecnologías (GPS, ubicación de redes WiFi y
celdas de telefonía cercanas, etc.) que permite emplearlo como
geolocalizador y dispositivo de navegación.
ILUSTRACIÓN 1: GOOGLE MAPS
La aplicación web cuenta con las siguientes características:
40
Planificación de rutas: es la funcionalidad principal de la aplicación
y consiste en una herramienta capaz de encontrar rutas entre dos
puntos, elaborando en el proceso una lista detallada con las
instrucciones a seguir por parte del usuario para alcanzar el destino.
En esta lista figuran, paso a paso, todas las etapas que se han de
seguir, tales como las distancias a recorrer, los nombres de las calles
por las que se transita, los puntos en que se ha de cambiar de
dirección, etc. Adicionalmente, la ruta obtenida se representa
gráficamente sobre el mapa, destacando la localización de los
puntos de paso establecidos por el usuario.
Destinos múltiples: los destinos son localizaciones establecidas por
el usuario por las que la ruta final ha de pasar. La aplicación ofrece
la opción de establecer tantos como se quiera para una misma ruta
y de recorrerlos en el orden que se desee. La inclusión, eliminación
o reordenación de uno de estos puntos implica un recálculo de la
ruta, ya que sus parámetros se ven modificados. Los dos primeros
destinos que se coloquen se establecerán como principio y final
provisionales de la ruta, de tal forma que esta se calcule
instantáneamente en cuanto se coloque el segundo. Sin embargo,
no existe distinción alguna entre estos dos puntos y los destinos
añadidos después, ya que todos son tratados como lugares por los
que se ha de pasar y lo único que influye en la ruta resultante es el
orden en que se coloquen.
Guardado de puntos de interés y rutas: la aplicación nos permite
guardar las localizaciones y las rutas más comunes o que nos
resulten de especial interés. De esta forma, en caso de que más
adelante se elaboraran nuevas rutas en las que estos puntos
frecuentes tuvieran que estar presentes o se quisiera volver a
consultar una ruta ejecutada con anterioridad no habría más que
acceder a la colección de elementos guardados y reutilizarlos de
nuevo.
41
Intérprete de direcciones escritas y sobre mapa: las direcciones de
las localizaciones de la ruta pueden ser introducidas tanto
seleccionando el punto sobre el mapa como escribiendo su
dirección física en el campo habilitado al efecto. En el caso de la
selección del punto en el mapa se tendrá que elegir en un menú de
qué tipo de punto se trata (origen, destino o destino adicional),
mientras que en el caso de la dirección escrita se tendrá que optar
entre las distintas posibilidades ofrecidas para autocompletar la
dirección a medida que se rellena, puesto que el tipo de punto ya
viene dado por el campo en el que se escribe la dirección.
Rutas a pie, en vehículo y en transporte público: el planificador de
rutas ofrece la opción de elegir entre conducir, caminar o usar
transporte público para efectuar el desplazamiento, y proporciona
un resultado diferente en función de la opción elegida. En todos los
casos, se elabora una lista detallada de los pasos a seguir, pero sin
embargo no se tienen en cuenta aspectos de accesibilidad como las
estaciones de metro con ascensores o los autobuses con rampa
para discapacitados.
Información del estado actual del tráfico: en esta herramienta
también está disponible la opción de mostrar el estado del tráfico
en las principales vías, lo cual es una opción muy a tener en cuenta
en caso de utilizar automóvil o transporte público para el
desplazamiento. El intervalo de actualización de estos datos puede
variar ostensiblemente en función de la zona, aunque siempre es
posible consultar a qué hora se realizó la última actualización.
Sugerencias de rutas: en ciertos casos la aplicación ofrece al usuario
distintos itinerarios posibles. Esto sucede en ocasiones en que haya
varias combinaciones de transporte público disponibles o en caso
de que existan varias rutas posibles cuyo tiempo varía en función
del estado del tráfico. El usuario puede elegir que se muestre
cualquiera de ellas.
42
Crear, guardar y compartir mapas personalizados: existe una
funcionalidad que permite a los usuarios crear mapas
personalizados y guardarlos o compartirlos con otras personas. En
estos mapas personalizados es posible colocar marcadores de
posición (con comentarios e icono personalizados), líneas, trayectos
sobre carreteras o calles, formas geométricas demarcando zonas,
etc.
Vista del entorno a pie de calle: en una gran cantidad de calles y
vías de circulación existe la posibilidad de bajar la vista hasta pie de
calle de tal modo que se visualice el entorno que se observaría
desde esa ubicación.
Además de las funcionalidades descritas de la aplicación web, la aplicación
móvil cuenta con opciones adicionales:
Sistema de geoposicionamiento: valiéndose de diversas técnicas de
geolocalización la aplicación móvil es capaz de ubicar el dispositivo
en el espacio, haciendo posible su utilización como navegador de
viaje.
Navegación guiada por voz: la aplicación móvil ofrece la posibilidad
de guiar al usuario a través de la ruta mediante un mecanismo de
instrucciones por voz similar a las de los sistemas GPS de los
vehículos. En este caso, la función es aplicable tanto a rutas a pie
como en automóvil, y sigue los pasos de la lista de instrucciones
generada al crear la ruta.
La aplicación en general es bastante completa, pero no obstante presenta
también notables carencias. A continuación se pasará a describir las
principales funcionalidades que se echan en falta para que pudiera ser
considerada un competidor directo de WayFiS:
Puntos de interés guardados no personalizables: los puntos de
interés que el usuario guarda en las colecciones no pueden ser
renombrados con un título descriptivo. De esta manera el único
43
factor que permite diferenciar unos puntos de otros son el nombre
de la calle y el número, lo cual en muchos casos no es
suficientemente claro. Esto supone un gran problema para las
personas mayores, ya que no tienen la misma capacidad de
retentiva que una persona joven y les resulta complicado recordar
los nombres de las calles en los que se ubican incluso los lugares
que más frecuentan, siendo mucho más fácil para ellos recordar un
punto otorgándole un nombre descriptivo (como “Casa de mi hija”
en lugar de “Calle de Espoz y Mina 23”).
Rutas guardadas no personalizables: las rutas guardadas no pueden
renombrarse y quedan identificadas por las direcciones de origen y
destino. Puede considerarse por tanto como un problema parejo al
anterior.
Mostrar sólo ciertas categorías de puntos de interés: los mapas
que emplea esta aplicación están repletos de información sobre
establecimientos, museos, monumentos, etc., pero sin embargo no
se cuenta con la posibilidad de mostrar tan sólo algunos de estas
localizaciones, o de filtrarlas según su tipo para no abrumar al
usuario con información. Las personas mayores pueden verse
fácilmente superadas por este exceso de información, y por ello
este aspecto sería muy necesario en caso de que la herramienta se
enfocara a ellos. De ser así, deberían poder mostrarse únicamente
categorías de interés primario para las personas mayores, como
hospitales, centros de asistencia, comisarías, farmacias, aseos
públicos, etc.
Escasa personalización de perfil del usuario: la configuración
personal del perfil de usuario no permite establecer preferencias de
transporte ni limitaciones de movilidad que se tengan en cuenta a la
hora de realizar los cálculos de las rutas. Este factor es
determinante para un buen planificador de rutas para personas
mayores y/o con movilidad reducida.
44
Como ya se dijo al principio, Google Maps puede considerarse como una
de las referencias en el campo de las aplicaciones de mapas, y a día de hoy
es posiblemente la herramienta más frecuentemente usada por el público
general para consultar ubicaciones geográficas y planificar
desplazamientos. Evidentemente esta difusión tan extensa entre el
público es producto de su extensa funcionalidad, que cubre ampliamente
las necesidades habituales de un usuario estándar. Pero precisamente por
ser una herramienta orientada a ser de propósito general presenta
algunas carencias al enfocarla hacia ciertos usos específicos, como es el
caso de su utilización por parte de personas mayores. Por ello se podría
concluir que si bien es una gran herramienta para la planificación de rutas
de propósito general, no debería considerarse un competidor directo de
WayFiS.
NOKIA HERE
Esta aplicación, antes conocida como Nokia Maps [7] [15] , y
perteneciente a la multinacional finlandesa Nokia, cuenta con versiones
tanto para navegador web como para dispositivos móviles. Las
funcionalidades que ofrece son bastante similares a las de WayFiS, con la
salvedad de que está orientada a un uso general y no está adaptada a
personas con necesidades especiales, como los mayores. Por lo tanto, nos
encontramos en una situación similar a la del punto anterior con Google
Maps: la divergencia entre la aplicación analizada y WayFiS en cuanto al
público objetivo. No obstante, debido a su importante presencia en el
mercado, pasaremos a analizar esta herramienta como segundo y último
representante del sector de aplicaciones de mapas de propósito general y
a mostrar sus virtudes y defectos en cuanto a su uso por parte de la
tercera edad.
45
ILUSTRACIÓN 2: NOKIA MAPS
La aplicación web cuenta con las siguientes características:
Planificación de rutas: como viene siendo habitual en aplicaciones
de este género, la planificación de rutas es su elemento básico y
más reconocible. La herramienta cuenta con la capacidad de
encontrar una ruta entre dos o más puntos dados ciertos
parámetros y/o restricciones, y proveer al usuario de una lista con la
información detallada de los pasos a seguir para recorrerla.
Adicionalmente, la ruta obtenida se representa gráficamente sobre
el mapa, destacando la localización de los puntos de partida y
destino así como de los puntos intermedios.
Puntos intermedios: son localizaciones intermedias por las que ha
de pasar la ruta. La aplicación ofrece la opción de establecer tantos
como se desee para una misma ruta. Estos puntos son
emplazamientos independientes, de tal forma que la inclusión o
eliminación de uno de ellos implica un recálculo de la ruta (puesto
46
que las necesidades de la ruta se ven modificadas) pero en ningún
caso modifican el punto de partida y destino.
Colecciones de puntos de interés y rutas: la aplicación nos permite
guardar las localizaciones y las rutas más comunes o que nos
resulten más interesantes organizadas en listas. De esta forma, en
caso de que más adelante se elaboraran nuevas rutas en las que
estos puntos frecuentes hayan de estar presentes, o se quisiera
volver a consultar una ruta ejecutada con anterioridad no habría
más que acceder a la colección en la que esté almacenado y
reutilizarlo de nuevo.
Localizaciones de interés cercanas: esta opción nos permite
mostrar de forma gráfica en el mapa establecimientos, entidades y
comercios de interés en las proximidades de la ruta. Los
establecimientos que podemos mostrar en el mapa están
clasificados en 4 categorías diferenciadas: Comer y beber, Compras,
Turismo y museos y Ocio. Al desplegar una de estas opciones en el
mapa se dibujan, en su correspondiente localización geográfica, los
iconos de los establecimientos de dicha categoría, y al pasar el
cursor sobre alguno de ellos se muestra un panel con información
ampliada.
Direcciones escritas y sobre mapa: las direcciones de la ruta
pueden ser introducidas tanto seleccionando el punto sobre el
mapa como escribiendo su dirección física. Si se selecciona un punto
en el mapa se deberá elegir en un menú el tipo de punto (partida,
destino o intermedio), y si por el contrario se escribe la dirección se
tendrá que elegir una de las direcciones sugeridas por la aplicación
para autocompletar, ya que el tipo de punto viene dado por el
campo en el que se ha escrito la dirección.
Rutas a pie, en vehículo y en transporte público: el planificador de
rutas ofrece una funcionalidad que no sólo se limita a rutas para
vehículos como un dispositivo GPS de automóvil. La aplicación
47
ofrece al usuario la posibilidad de elegir cómo pretende realizar su
desplazamiento: a pie, en un vehículo o utilizando transporte
público. En cualquiera de los casos, el sistema elabora una ruta
adecuada a los criterios del usuario recorriendo todos los puntos
especificados, con la única salvedad de que las rutas de transporte
público a día de hoy no pueden planificarse utilizando puntos
intermedios.
Información del estado actual del tráfico: la herramienta cuenta
con la opción de mostrar los incidentes y la fluidez del tráfico,
aunque sólo está disponible para autovías, autopistas y otras vías
principales.
Además de las funcionalidades descritas de la aplicación web, la aplicación
móvil cuenta con opciones adicionales:
Descarga del mapa de una zona para uso offline: dado que el uso
de esta aplicación en un dispositivo móvil necesita una conexión a
internet operativa para consultar los mapas y ya que no todos los
dispositivos de este tipo cuentan con cobertura en ciertos lugares o
con una conexión de datos permanente, es posible descargar una
zona del mapa para su consulta offline. En este caso, se podrá
consultar el mapa pero no los puntos de interés (establecimientos,
teatros, museos, etc.) y otros servicios para los que sea
indispensable la conexión (como por ejemplo el estado del tráfico).
Navegación guiada por voz: el sistema cuenta con la posibilidad de
guiar al usuario mediante instrucciones interpretadas por un agente
de voz, utilizando instrumentos de geoposicionamiento para
conocer la ubicación actual del dispositivo y siguiendo a partir de ahí
las directrices estipuladas en la lista de instrucciones de la ruta.
Nokia Here es una aplicación bastante completa para la planificación de
rutas, especialmente al combinar sus variantes web y móvil, pero no
obstante no dispone de ciertas funcionalidades muy importantes en el
campo específico de la movilidad para personas mayores:
48
Puntos de interés guardados no personalizables: una vez se han
guardado en las colecciones, los puntos de interés se muestran
identificados por la ubicación a la que representan, pero no se
ofrece la posibilidad de renombrarlos o de asignarles una etiqueta
que los haga más identificables. En muchos casos, y particularmente
en el de las personas mayores, resulta muy difícil relacionar los
puntos guardados con su ubicación física o con la localización que
representan. Por ello es necesario permitir al usuario dar un
nombre a más familiar a los puntos de interés que guarda, para que
le resulte más fácil relacionarlos con lo que en verdad representan.
Rutas guardadas no personalizables: nos encontramos de nuevo en
el problema del punto anterior, haciéndolo extensivo en esta
ocasión a las rutas guardadas.
Sistema de reutilización de puntos de interés poco intuitivo: para
reutilizar un punto previamente guardado no se puede hacer desde
el panel de creación de rutas. Para ello hay que acudir primero a la
pestaña de Colecciones, seleccionar allí el punto y elegir la opción
“Obtener rutas” (cuyo nombre no dice mucho de su funcionalidad).
Al activar esa opción no se nos da a elegir entre los diversos papeles
que puede ejercer el punto, sino que se establece de
imperativamente como punto de destino si la ruta está totalmente
vacía, o como punto de origen si la ruta ya tiene punto de destino.
Además no es posible utilizarlo como punto intermedio a no ser que
previamente se hayan establecido un punto de origen o de destino
en la ruta. Todo este sistema es muy enrevesado y poco intuitivo, y
podría simplificarse dando a elegir en la interfaz de creación de ruta
entre usar un punto nuevo o uno guardado o incluso en la pestaña
de Colecciones preguntando por el papel que queremos que realice
el punto que queremos cargar. Para una persona mayor este
apartado, por muy simplificada que sea la manera en que se
aborde, puede resultar difícil y enrevesado, por lo que añadirle una
complejidad adicional totalmente innecesaria carece de todo
sentido.
49
Ausencia de categorías de puntos de interés para mayores: entre
las categorías de puntos de interés con las que cuenta la aplicación
no figura ninguna de interés primario para las personas mayores,
como hospitales, centros de asistencia, comisarías, farmacias, aseos
públicos, etc.
Escasa personalización de perfil del usuario: no es posible
configurar el perfil personal del usuario para indicar qué lugares han
de tomarse en cuenta a la hora de efectuar sus rutas, como
hospitales, farmacias, aseos públicos, restaurantes, etc. Este un
factor muy importante para que las personas mayores y/o con
movilidad reducida puedan desplazarse con confianza y sepan
dónde acudir en caso de necesitarlo.
En conclusión, podría decirse que esta herramienta es bastante completa
y cubre satisfactoriamente las necesidades de un usuario estándar en
cuanto a planificación de rutas e información del entorno, aunque tiene
ciertas carencias en cuanto personalización. Sin embargo, al no estar
enfocada a un público específico, como es el caso de WayFiS con las
personas mayores, no hace especial énfasis en los aspectos particulares
que hacen de una herramienta de este tipo algo útil para estas personas.
Por lo tanto, se puede decir que es una buena alternativa de planificación
de rutas, pero no un competidor directo de WayFiS.
PLANIFICADORES DE PROPÓSITO ESPECÍFICO
Existe una segunda categoría de planificadores, a la que pertenece
WayFiS, que hacen especial hincapié en aspectos específicos a la hora de
establecer los parámetros de las rutas y se centran más en las
características del usuario para proporcionar unos resultados más
personalizados. Por lo general, estas aplicaciones calculan sus resultados
no sólo contemplando el origen y el destino de las rutas, sino otros
aspectos que puedan resultar de interés para el usuario, como los
50
establecimientos cercanos que más puedan interesarle en función de su
perfil o los lugares próximos que merece la pena visitar según sus gustos
que haya mostrado previamente. A continuación se ofrecerá un análisis de
dos herramientas cuyas funcionalidades se asemejan a las ofrecidas por
WayFiS y se comentarán los pros y los contras de su utilización orientada a
personas mayores. Estas dos herramientas son Foxytour [12] y Handimap
[14] :
FOXYTOUR
Foxytour [12] es una aplicación que permite gestionar etiquetas virtuales
que funcionan como “post-it” digitales que pueden ser vistos y editados
desde un dispositivo móvil o cualquier otro aparato capaz de determinar
su localización. Estas etiquetas pueden ser mostradas sobre un mapa,
pero también pueden funcionar como información de un entorno de
realidad aumentada, en cuyo caso aparecerán superpuestas a la vista del
entorno a través del dispositivo móvil del usuario.
ILUSTRACIÓN 3: FOXYTOUR
51
Estas etiquetas son establecidas por los propios usuarios, quienes a su vez
puntúan el lugar (restaurantes, museos, etc.) y hacen comentarios para
que los vean los otros usuarios. Este enfoque colaborativo favorece la
implicación de los usuarios con el sistema haciendo que la participación
activa de estos tenga un papel fundamental en el desarrollo de la
herramienta y sus contenidos.
El funcionamiento de la aplicación se ilustra más claramente mediante el
uso de ejemplos. Pongamos que un guía de montaña etiqueta un área en
que sospecha que hay riesgo de avalancha; esta información sirve al
sistema para que automáticamente informe a otros usuarios que se
encuentren cerca de ese punto crítico del riesgo detectado. Un segundo
ejemplo podría ser el de un usuario que acude un restaurante y decide
etiquetarlo en la aplicación y dejar que la gente escriba sus comentarios
valorándolo. Como puede verse, las etiquetas se fijan en el mapa no sólo
para el usuario que las pone, sino para todos los usuarios de la plataforma,
de tal manera que la comunidad de usuarios sea la principal generadora
de información.
Las etiquetas funcionan mediante sistemas de geocodificación, o lo que es
lo mismo, sistemas capaces de situar geográficamente la localización de
direcciones físicas o coordenadas y ubicarlas sobre un mapa. Los servicios
que permiten geocodificación pueden ser clasificados en dos categorías,
ambas con una ventaja y una desventaja principales:
Los servicios no colaborativos, donde un particular pone etiquetas.
La calidad de la información es a menudo buena, pero no está
necesariamente actualizada.
Los servicios colaborativos, donde los usuarios ponen etiquetas por
sí mismos. La información es libre y a menudo está actualizada, pero
el usuario desconoce la calidad de los datos.
FoxyTour incluye una solución que permite aprovechar ambos servicios:
un motor de confianza capaz de gestionar e informar al usuario sobre la
relevancia de un dato en un contexto particular. Concretamente, este
motor de confianza analiza los comentarios de los usuarios en las
etiquetas y crea comunidades virtuales de gente que comparte los mismos
52
gustos e intereses. Así, cuanto más se involucra el usuario en el sistema,
más relevante se considera la información que aporta.
Además del motor de confianza, Foxytour cuenta con las siguientes
funciones:
Creación de etiquetas de usuarios para usuarios: los usuarios de la
herramienta pueden añadir etiquetar establecimientos, museos,
paradas de transporte público y cualquier otro elemento que
consideren de interés para la comunidad.
Información de lugares extendida: las etiquetas pueden ser
complementadas con enlaces multimedia a vídeos, artículos
enciclopédicos (como Wikipedia [35] ) o a cualquier contenido
multimedia, de tal forma que la etiqueta no sea tan sólo una
indicación, sino también una completa fuente de información sobre
el lugar. A través del motor de confianza, la aplicación muestra
automáticamente a cada usuario las etiquetas más relevantes en
función de sus gustos e intereses y le da la opción de comentar y
completar etiquetas puestas por otros usuarios, que a su vez sirven
para consolidad su red de confianza.
Comentarios sobre lugares: los usuarios pueden realizar
comentarios y puntuar los lugares representados por etiquetas. Así
otros usuarios pueden consultar la opinión de la comunidad sobre
esos lugares y valorar si son de su interés.
Tour adaptados a las preferencias del usuario: la herramienta es
capaz de mostrar rutas turísticas cercanas adaptadas a las
preferencias del usuario basándose en sus gustos e intereses.
Vistas del entorno con realidad aumentada: en caso de que el
dispositivo en el que se encuentre la aplicación cuente con cámara
la aplicación ofrece la posibilidad de mostrar información ampliada
del entorno a través de una función de realidad aumentada, que
53
reconoce el lugar y muestra la información disponible de los lugares
relevantes cercanos.
Consulta de mapas offline: la aplicación es capaz de funcionar en
modo offline. Las etiquetas y los mapas pueden guardarse en el
teléfono evitando así, por ejemplo, los costes derivados del tráfico
de datos en el extranjero o haciendo posible su consulta en
entornos en los que no se dispone de cobertura.
Lectura de códigos de identificación: decodifica códigos de barras y
RFID. Por ejemplo, en lugares como museos y galerías es suficiente
con enfocar el teléfono hacia el código para poder interpretar la
etiqueta y consultar la información asociada.
Pese a todas estas funcionalidades, Foxytour no deja de estar enfocado al
uso turístico e informativo en entornos urbanos, además de depender
fuertemente del tamaño e implicación de su comunidad de usuarios en lo
que respecta a la cantidad y calidad de su contenido. Ofrece la posibilidad
de consultar rutas turísticas pero no de buscar rutas entre puntos
concretos ni de establecer parámetros de interés que se tengan en cuenta
a la hora de establecer estas rutas, al margen de lo que la propia
aplicación extraiga de la interacción del usuario a través de las etiquetas y
comentarios que este incluya y consulte. Por lo tanto, a pesar de poder
servir como herramienta para las personas mayores en ocasiones
puntuales (por ejemplo, para ubicarse en una situación de desorientación
a través de la función de realidad aumentada), es una aplicación de
utilidad limitada para las personas de este colectivo, y por lo tanto no
supone un sustituto de WayFiS.
HANDIMAP
Handimap [14] es una aplicación gratuita que permite calcular itinerarios
accesibles para personas con movilidad reducida y mostrar en las rutas
distintos tipos de ubicaciones de interés ligadas a la accesibilidad.
54
Actualmente está limitada al entorno de dos ciudades francesas: Rennes
(donde se desarrolló originalmente) y Montpellier. La idea de esta
aplicación es en cierta medida similar a la de WayFiS, con la salvedad de
que está orientada a personas con movilidad reducida y no a personas
mayores. Es decir, Handimap es una herramienta de planificación de rutas
principalmente orientada a la accesibilidad de los entornos urbanos en los
que opera, no una aplicación pensada facilitar los desplazamientos
urbanos personas mayores que adapte las rutas a sus necesidades
específicas.
ILUSTRACIÓN 4: HANDIMAP
En definitiva, Handimap tiene más de servicio municipal de accesibilidad
para el ciudadano que de herramienta de asistencia para la tercera edad,
lo que no excluye que los mayores, al igual que cualquier otro ciudadano,
puedan beneficiarse de sus servicios para conocer los caminos más
accesibles.
La aplicación se basa en un panel lateral en el que se establecen los
puntos de origen y destino y los puntos de interés que se desean mostrar,
y tras calcular la ruta toda esta información se despliega en el mapa
adyacente. El resultado es una ruta accesible (en caso de que sea posible)
55
entre ambos puntos, teniendo en cuenta ciertos parámetros de
accesibilidad del entorno.
Las funciones de Handimap son las siguientes:
Planificación de rutas accesibles: la aplicación es capaz de calcular
la ruta más accesible entre dos puntos empleando la información
sobre las características de accesibilidad del entorno urbano. En
caso de que no sea posible trazar un itinerario completamente
accesible, el usuario es informado de ello y el modo de accesibilidad
del itinerario resultante pasa de Accesible a Peatón, que conlleva
menos restricciones de accesibilidad.
Visualización de las características de accesibilidad de las aceras:
una de las capas de información adicional que pueden añadirse al
mapa (a día de hoy tan sólo en la ciudad de Montpellier) es la que
permite visualizar el tipo y nivel de accesibilidad de las aceras de las
calles de la ciudad: si son plenamente accesibles, si lo es tan sólo el
lado izquierdo o derecho o si no lo son (o no se dispone de
información para determinarlo).
Visualización de información adicional sobre accesibilidad del
entorno: otra funcionalidad de que dispone el apartado de puntos
de interés es la de mostrar los lugares en que se encuentran los
dispositivos asociados a la accesibilidad del tránsito peatonal, tales
como los semáforos con aviso sonoro, las plataformas de pavimento
táctil, los establecimientos accesibles (tanto privados como
públicos), las plazas de aparcamiento reservadas para
discapacitados, etc. No obstante, algunos de estas posibilidades
están únicamente disponibles para una de las dos ciudades.
Rutas no personalizadas para el usuario: Handimap hace de las
rutas urbanas accesibles su principal fin y como tal no ahonda en los
problemas o necesidades particulares que pudiera tener un usuario
concreto. Por ello no se dispone de cuentas de usuario en las que
cada persona pueda establecer sus intereses particulares en cuanto
56
a los parámetros a considerar en las rutas. Esto lleva a que tampoco
puedan guardarse rutas o puntos para usos posteriores ya que no se
efectúa la identificación del usuario, lo cual si bien disminuye la
complejidad de su uso reduce también su potencial. Por lo tanto,
cada vez que una persona desea calcular una ruta tiene que
introducir toda la información desde cero, sin la posibilidad de
reutilizar los puntos empleados con anterioridad. Este aspecto
distancia notablemente a Handimap de WayFiS en cuanto a
usabilidad, ya que nuestro proyecto sí que permite guardar y
reutilizar los puntos y rutas habituales de los usuarios, facilitando
así la labor de consultar rutas frecuentes. Adicionalmente, al no
existir la posibilidad de establecer un conjunto de localizaciones de
interés específicas del usuario, el sistema no integra ningún tipo de
punto de interés en las rutas, y se limita a establecer el itinerario
entre los puntos de origen y destino.
Visualización de los transportes públicos sin integración en ruta:
otra de las funciones de las sección de puntos de interés es la de
ofrecer un diagrama de las rutas del metro y los autobuses de la
ciudad, así como de sus paradas y la accesibilidad de éstas. Sin
embargo, no es posible integrar estos transportes en las rutas que
planifica la aplicación (algo que sí hace WayFiS) por lo que los datos
que se ofrecen sobre el transporte urbano tienen una utilidad
parcial, puesto que son meramente informativos.
Posibilidades limitadas para especificar la ruta: como ya se ha
comentado anteriormente, en Handimap no existe la posibilidad de
cargar una ruta previamente calculada o de establecer un punto
usado antes en otra ruta, pero existen limitaciones adicionales de
usabilidad en lo que respecta a la especificación de los puntos de la
ruta. Ya que se dispone de un mapa, que a ojos del usuario es
plenamente funcional, debería permitirse la opción de establecer
los puntos de origen y destino interaccionando con él en caso de
que el usuario conozca la ubicación física del lugar; sin embargo, la
única opción disponible es escribir el nombre de la localización en
57
los campos habilitados al efecto, en los que, eso sí, se cuenta con un
servicio de autocompletado para facilitar la tarea. No obstante, el
mecanismo de autocompletado se toma la libertad de sustituir la
dirección introducida por la más parecida en caso de que ésta no
figure en su registro sin informar de ello al usuario, lo que puede
dar lugar a confusiones.
No orientado a personas mayores: la aplicación no está adaptada a
su uso por parte de las personas mayores, y por lo tanto la interfaz
carece de la usabilidad que se esperaría de una aplicación de estas
características. Un ejemplo de esto podríamos verlo en el modo de
visualización de los puntos de interés, que cubre todo el mapa con
las ubicaciones de los tipos seleccionados, suponiendo una
sobrecarga de información innecesaria para una persona mayor;
sería mucho más adecuado mostrar tan sólo los que se encontrasen
en las proximidades de la ruta para minimizar el impacto en este
grupo de usuarios.
Ámbito de acción local: Handimap tiene un ámbito de aplicación
localizado: Rennes y Montpellier. Al estar sólo disponible en estas
dos ciudades francesas está justificado que actualmente esté sólo
en idioma francés.
En conclusión, Handimap es una herramienta muy útil en el aspecto de las
rutas accesibles en Rennes y Montpellier, y supone un gran servicio para
los ciudadanos de estas dos ciudades, pero no obstante, no supone
competencia para WayFiS ya que ambas aplicaciones a pesar de sus
parecidos están enfocadas a finalidades, ámbitos y públicos diferentes.
OTROS PROYECTOS EUROPEOS
En el entorno europeo existen iniciativas de financiación para programas
de investigación y desarrollo destinados a mejorar la calidad de vida de las
personas mayores mediante la utilización de las tecnologías de la
58
información y la comunicación (TIC), y WayFiS está enmarcado dentro de
dos de ellas: Ambient Assisted Living (AAL) [5] y como JTI del programa
marco FP7 (7th Framework Programme [9]).
El programa de financiación AAL en particular alberga numerosos
proyectos orientados a las personas mayores, y regularmente abre
convocatorias (o calls) de temática específica, como por ejemplo es el
caso de la que enmarca al proyecto WayFiS, orientada a la movilidad. Es
de esperar por lo tanto que algunos de los proyectos adscritos a una
misma convocatoria de este programa compartan ciertos rasgos comunes.
En este apartado vamos a analizar dos de ellos, actualmente en fase de
desarrollo: Stimulate [32] y Entrance [11] .
Hay que tener en cuenta que por el momento no es posible hacer un
análisis extenso de estas herramientas puesto que no se dispone de
información pública relevante sobre el estado del desarrollo ni de las
funcionalidades implementadas. En su lugar se procederá a comentar los
posibles puntos en común que puedan tener con WayFiS.
STIMULATE
Stimulate [32] es una herramienta destinada a facilitar la movilidad y los
desplazamientos de las personas mayores, que ofrece una interfaz de
planificación a través del ordenador y opciones de optimización de
itinerarios y asistencia a través de móviles y tablets.
Esta plataforma permitirá:
A las personas mayores seleccionar el mejor itinerario de viaje
basándose en sus necesidades y capacidades. Además, durante el
viaje, les ofrecerá ayuda y asistencia a través del teléfono móvil para
hacer más fácil el trayecto y les proporcionará información y
consejos sobre las tiendas y establecimientos cercanos.
A los tour operadores proponer viajes temáticos de relevancia para
las personas mayores y servicios optimizados para ellos.
59
Actualmente no se ha publicado apenas información sobre el estado del
desarrollo de este proyecto, pero dado lo similar del planteamiento y la
finalidad que busca cubrir convendría seguirlo de cerca para ver hasta qué
punto podría considerarse una alternativa a WayFiS.
ENTRANCE
ENTRANCE [11] es una plataforma centrada en la planificación de viajes,
en la navegación en exteriores e interiores y en el uso de servicios de
internet para adultos y personas mayores. La plataforma cuenta con un
terminal fijo con un juego serio y una interfaz multi-sensorial móvil para la
navegación y la señalización de rutas. A su vez, también ayudará a las
personas mayores a mantener y desarrollar sus capacidades cognitivas.
El terminal fijo consiste en un ordenador que dispone de un software que
se adapta a los usuarios con diferentes niveles de dominio de la
tecnología. El software tiene usos tales como enseñar al usuario a adquirir
tickets o paquetes vacacionales por internet, entre otros.
El juego serio tiene la finalidad de ser utilizado por personas mayores para
mejorar su capacidad espacial y, posteriormente, su capacidad de navegar
en interiores y exteriores.
La plataforma móvil comprende software de navegación, que a su vez
también se utiliza en el juego serio del terminal fijo. Este software de
navegación se instala en un dispositivo móvil, y se combina con un sistema
de posicionamiento para interiores y exteriores y un dispositivo de
navegación táctil (como por ejemplo una pulsera) para dar instrucciones y
mensajes informativos durante la navegación.
La funcionalidad principal de ENTRANCE es diferente a la de WayFiS,
aunque compartan ciertas características como la navegación y asistencia
en exteriores e interiores través de un dispositivo móvil. Si bien es cierto
que a fecha de hoy no se cuenta con demasiada información relevante
60
sobre el estado actual del proyecto, no parece que vaya a suponer una
alternativa a WayFiS, sino más bien una útil herramienta complementaria.
61
62
3 ANÁLISIS
3.1 OBJETIVO
El objetivo del análisis es la obtención de una especificación detallada de
las funciones y características que el sistema deberá incluir para cubrir las
necesidades de los distintos usuarios, y que a su vez sirva como referencia
en la elaboración del diseño.
En esta fase se analizarán las principales funcionalidades que ha de
contener el sistema y los posibles usuarios que pueden actuar en él.
Finalmente, todo ello se verá representado en un diagrama de casos de
uso en el que se representarán las relaciones entre los actores y las
funcionalidades y de éstas entre sí.
3.2 DEFINICIÓN DE ALCANCE DEL SISTEMA
El sistema a desarrollar consiste en una aplicación para planificar rutas
personalizadas para personas mayores y/o discapacitadas adaptándose a
sus necesidades y guiarles a lo largo de éstas a tiempo real. Como ya se
detalló en la sección de introducción de este documento, el sistema tiene
numerosas funcionalidades, que en la práctica se traducen en varios
módulos. El apartado desarrollado por el estudiante corresponde a un
subconjunto de los módulos del sistema final, y aunque comprende varios
de los más importantes no abarca todos. Módulos como el de la aplicación
móvil de seguimiento de rutas en tiempo real o el módulo de
descubrimiento de conocimiento quedaron fuera del ámbito desarrollado
por el estudiante, y por ello no se cubrirán en este apartado de análisis.
Las funcionalidades principales del conjunto de módulos desarrollados por
el estudiante y que por consiguiente se cubren en este apartado de
análisis son las siguientes:
63
Guardado de rutas: La aplicación permitirá al usuario guardar las
rutas que haya creado, de modo que pueda volver a acceder a ellas
en el futuro.
Carga de rutas: La aplicación permitirá al usuario cargar rutas que
previamente haya guardado. Cada ruta estará identificada por un
nombre dado por el usuario.
Guardado de puntos de interés: La aplicación permitirá al usuario
guardar los puntos de interés de la ruta, tales como el punto de
inicio o final, o los puntos intermedios establecidos por el usuario.
Cargado de puntos de interés: La aplicación permitirá al usuario
cargar puntos de interés guardados previamente para introducirlos
en una nueva ruta. De esta forma podrá establecer el inicio, el final
o un punto intermedio de una nueva ruta simplemente cargando un
punto personal anteriormente guardado.
Creación de nuevas rutas: La aplicación permitirá al usuario crear
nuevas rutas a partir de, como mínimo, un punto de inicio y un
punto de final. La optimización de la ruta queda a cargo del
planificador, que tomará en cuenta diferentes parámetros como los
puntos intermedios y las limitaciones de movilidad del usuario para
adecuarlo a sus necesidades de la manera más óptima posible.
Análisis de una ruta: La aplicación permitirá al usuario visualizar los
diferentes tramos de una ruta para analizar las diferentes etapas a
recorrer (distancias, nombre de las calles, medios de transporte,
etc.).
Además de estas funciones, el estudiante también ha desarrollado otros
apartados que no se traducen directamente en funcionalidades visibles
para el usuario pero que conforman la arquitectura tecnológica que
posibilita que las expuestas puedan llevarse a cabo. Sin embargo, y
teniendo en cuenta que nos encontramos en la fase de análisis en la que
lo principal es destacar las funciones de que dispondrá la aplicación y que
64
dichas funcionalidades no están disponibles para el usuario sino que
suponen servicios adicionales disponibles a nivel interno, no se ahondará
en ellas, quedando como las principales funciones las listadas
anteriormente.
3.3 DEFINICIÓN DE ACTORES
En la totalidad del proyecto aparecen diversos tipos de actores, que de
forma esquemática y dependiendo de la función que desempeñan podrían
clasificarse, grosso modo, en usuario y administrador o cuidador. Si bien
en el conjunto del proyecto en el que se enmarca este trabajo existen
estos actores potenciales, en el apartado del proyecto abarcado por esta
memoria, el único actor involucrado es el usuario. Aspectos propios del
administrador como la gestión de cuentas de usuario y/o del conjunto del
sistema, quedan fuera de los objetivos de este bloque y por tanto no son
ni serán abordados.
Usuario: es cualquier persona que utiliza el sistema con la intención
de obtener rutas personalizadas. Este actor tiene la capacidad de
acceder a la aplicación con la finalidad de visualizar rutas, ya sea
generando nuevas o cargándolas de entre las previamente
guardadas. En el proceso de creación de una ruta, el usuario puede
elegir entre varios mecanismos a la hora de establecer los puntos
que definirán la ruta, pero independientemente del que elija, podrá
guardarlo en su registro personal de lugares de interés y reutilizarlo
en ocasiones posteriores. El número de rutas y puntos de interés
que puede guardar un usuario es, en principio, ilimitado.
Antes de empezar a describir las funcionalidades, habría que puntualizar
un detalle que afecta al usuario. El término Usuario, tal y como se utiliza
aquí, es en todo momento sinónimo de “usuario registrado”, ya que tanto
el registro como la identificación de usuarios se realiza a través de la
página web y es únicamente desde ésta desde donde se tiene acceso a la
aplicación que nos ocupa. Esto significa que no hay modo alguno en que
65
una persona pueda acceder a la aplicación sin antes registrarse en la
página web, y que por tanto cualquier usuario del sistema de planificación
online de rutas es un usuario registrado, que posee una cuenta propia y
que es capaz de guardar rutas y puntos de interés personales. Por
coherencia, se ha añadido un requisito y un caso de uso referentes al
registro del Usuario en el sistema, si bien éste sería el único punto que
podría realizar en la plataforma un usuario no registrado.
3.4 REQUISITOS DEL SISTEMA
En este apartado se formalizará y refinará el conjunto de requisitos de tal
forma que quede constancia de todas y cada una de las funcionalidades
que ha de incluir el producto final. Estos requisitos han de estar
especificados de forma clara, concisa y detallada, de tal forma que no den
lugar a ambigüedades. La rigurosidad y exactitud de esta sección es muy
importante ya que tendrá una repercusión directa en las posteriores fases
de diseño, implementación y pruebas.
66
TABLA 1: REQUISITOS FUNCIONALES
Requisitos Funcionales
Código Nombre RF-001 Registro en el sistema
RF-002 Iniciar sesión en el sistema
RF-003 Cerrar sesión en el sistema
RF-004 Cambiar configuración de la cuenta de usuario
RF-005 Cambiar preferencias de salud de la cuenta
RF-006 Guardar ruta
RF-007 Consultar rutas guardadas
RF-008 Cargar ruta guardada
RF-009 Eliminar ruta guardada
RF-010 Editar ruta guardada
RF-011 Guardar punto de partida de una ruta como punto de interés
RF-012 Guardar punto de destino de una ruta como punto de interés
RF-013 Guardar punto intermedio de una ruta como punto de interés
RF-014 Consultar puntos de interés guardados
RF-015 Eliminar punto de interés
RF-016 Editar punto de interés
RF-017 Introducir punto de partida desde el mapa
RF-018 Introducir punto de partida escribiendo su dirección
RF-019 Introducir punto de partida cargando un punto de interés
RF-020 Introducir punto de destino desde el mapa
RF-021 Introducir punto de destino escribiendo su dirección
RF-022 Introducir punto de destino cargando un punto de interés
RF-023 Introducir punto intermedio desde el mapa
RF-024 Introducir punto intermedio escribiendo su dirección
RF-025 Introducir punto intermedio cargando un punto de interés
RF-026 Eliminar punto intermedio
RF-027 Generar nueva ruta
RF-028 Mostrar otra ruta creada/cargada
RF-029 Ver etapas de la ruta de forma detallada
RF-030 Cerrar una ruta
RF-031 Intercambiar los puntos de partida y destino de una ruta
RF-032 Otorgar un nombre unívoco a un punto de interés guardado
RF-033 Otorgar un nombre unívoco a una ruta guardada
RF-034 Aumentar el zoom del mapa
RF-035 Disminuir el zoom del mapa
RF-036 Desplazarse por el mapa
67
Requisitos No Funcionales
Código Nombre RNF-001 Los colores de la aplicación seguirán un tema corporativo
RNF-002 Los mensajes y etiquetas de la aplicación serán concisos y claros
RNF-003 Las secuencias de pasos para realizar tareas han de ser sencillas e intuitivas en la medida de lo posible
RNF-004 Una barra de carga aparecerá en los momentos en que el sistema esté ocupado procesando información
RNF-005 El almacenado de datos y preferencias de los usuarios seguirá los protocolos de seguridad correspondientes
RNF-006 La aplicación de rutas sólo será accesible desde la aplicación web (no dispondrá de una URL de acceso público).
RNF-007 En caso de error el usuario será informado debidamente, utilizando un lenguaje no técnico.
TABLA 2: REQUISITOS NO FUNCIONALES
A continuación se describirán detalladamente cada uno de los requisitos
arriba expuestos. Cada requisito cuenta con los campos siguientes:
Identificador: Clave identificativa unívoca que se le asigna a cada requisito
para identificarle a lo largo de todo el documento.
Prioridad: Nivel de prioridad que se considera que tiene el requisito
respecto al resto del conjunto de requisitos. Los valores que puede tomar
este campo son, en orden ascendente de prioridad: Bajo, Normal y Alto.
Estado: Estado actual del requisito. Los valores que puede tomar este
campo son: No comenzado, En proceso, Completado.
Necesidad: Necesidad de que sea completado el requisito para el
conjunto del sistema. Los valores que puede tomar este campo son, en
orden ascendente de necesidad: Baja, Media y Alta. Los requisitos con
necesidad baja en la mayoría de los casos pueden considerarse como
opcionales, y es posible que finalmente no sean incluidos en la versión
final debido a diversas limitaciones.
68
Autor: Autor del requisito. Los valores de este campo pueden ser: HI Iberia
(si era un requisito exigido por la empresa) o A.M.V (si lo propuso el
estudiante, Alberto del Moral Vargas).
Requisitos relacionados: Identificadores de otros requisitos del sistema
que estén de alguna forma relacionados con el requisito en cuestión.
Descripción: Texto explicativo en el que se desarrolla la finalidad del
requisito y la funcionalidad que representa. Este apartado tratará de ser lo
más conciso y descriptivo posible a fin de explicar la funcionalidad descrita
por el requisito de una forma clara en el menor espacio posible.
RF-001: Registro en el sistema
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-002, RF-003
Descripción: Para acceder a la aplicación es necesario registrarse en el sistema creando una cuenta personal. Los datos que identifican la cuenta del usuario son su nombre y su contraseña. El nombre que el usuario dé a la cuenta ha de ser una combinación alfanumérica única en el sistema, lo que implica que no podrá elegir como nombre para su cuenta uno que ya haya sido elegido anteriormente por otro usuario. La opción de crear una nueva cuenta estará disponible desde la página web.
TABLA 3: RF-001 REGISTRO EN EL SISTEMA
RF-002: Iniciar sesión en el sistema
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-001, RF-003
Descripción: Para acceder a la aplicación el usuario ha de identificarse con su usuario y contraseña. Una vez se compruebe su identidad, el usuario tendrá acceso al sistema y se le otorgará acceso a las funcionalidades de la aplicación.
TABLA 4: RF-002 INICIAR SESIÓN EN EL SISTEMA
69
RF-003: Cerrar sesión en el sistema
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-001, RF-002
Descripción: Un usuario puede cerrar la sesión en el sistema en cualquier momento y salir de éste. Para ello es necesario que haya iniciado una sesión previamente y que aún se encuentre dentro del sistema. Una vez el usuario cierre la sesión no podrá acceder a ninguna de las funcionalidades del sistema a menos que vuelva a iniciar sesión.
TABLA 5: RF-003 CERRAR SESIÓN EN EL SISTEMA
RF-004: Cambiar configuración de la cuenta de usuario
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-001
Descripción: El usuario podrá modificar la configuración y parámetros personales (como la contraseña, los datos personales, etc.) de su cuenta en cualquier momento.
TABLA 6: RF-004 CAMBIAR CONFIGURACIÓN DE LA CUENTA DE USUARIO
RF-005: Cambiar preferencias de salud de la cuenta
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-001
Descripción: El usuario podrá modificar en cualquier momento las preferencias de salud de su cuenta, tales como su nivel de movilidad, las dolencias padecidas y todos los parámetros de salud tenidos en cuenta a la hora de personalizar la planificación de las rutas.
TABLA 7: RF-005 CAMBIAR PREFERENCIAS DE SALUD DE LA CUENTA
70
RF-006: Guardar ruta
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-007, RF-008, RF-009, RF-010, RF-027, RF-033
Descripción: Tras pedir al sistema que planifique una ruta, el usuario puede guardar esa ruta en su registro personal para posteriores consultas.
TABLA 8: RF-006 GUARDAR RUTA
RF-007: Consultar rutas guardadas
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-006, RF-008, RF-009, RF-010, RF-033
Descripción: El usuario podrá consultar la lista de todas las rutas que ha guardado hasta ese momento.
TABLA 9: RF-007 CONSULTAR RUTAS GUARDADAS
RF-008: Cargar ruta guardada
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-006, RF-007, RF-009, RF-010, RF-033
Descripción: El usuario podrá elegir una de sus rutas guardadas y cargarla. Esto hará que la ruta se cargue y se muestre de nuevo en el sistema.
TABLA 10: RF-008 CARGAR RUTA GUARDADA
RF-009: Eliminar ruta guardada
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-006, RF-007, RF-008, RF-010, RF-033
Descripción: El usuario podrá elegir una de sus rutas guardadas y eliminarla. Esto hará que la ruta se borre del sistema y no pueda ser consultada ni cargada de nuevo.
TABLA 11: RF-009 ELIMINAR RUTA GUARDADA
71
RF-010: Editar ruta guardada
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-006, RF-007, RF-008, RF-009, RF-033
Descripción: El usuario podrá elegir una de sus rutas guardadas y editar su nombre. El nuevo nombre que el usuario le asigne a la ruta no debe coincidir con el de ninguna de sus otras rutas.
TABLA 12: RF-010 EDITAR RUTA GUARDADA
RF-011: Guardar punto de partida de una ruta como punto de interés
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-012, RF-013, RF-014, RF-015, RF-019, RF-022, RF-025, RF-032
Descripción: El usuario podrá seleccionar el punto de partida de la ruta que esté creando y guardarlo como punto de interés en su registro personal. A partir de ese momento, el punto de interés podrá ser reutilizado e insertado como punto intermedio, de partida o de destino en el proceso de creación de una nueva ruta.
TABLA 13: RF-011 GUARDAR PUNTO DE PARTIDA DE UNA RUTA COMO PUNTO DE INTERÉS
RF-012: Guardar punto de destino de una ruta como punto de interés
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-011, RF-013, RF-014, RF-015, RF-019, RF-022, RF-025, RF-032
Descripción: El usuario podrá seleccionar el punto de destino de la ruta que esté creando y guardarlo como punto de interés en su registro personal. A partir de ese momento, el punto de interés podrá ser reutilizado e insertado como punto intermedio, de partida o de destino en el proceso de creación de una nueva ruta.
TABLA 14: RF-012 GUARDAR PUNTO DE DESTINO DE UNA RUTA COMO PUNTO DE INTERÉS
72
RF-013: Guardar punto intermedio de una ruta como punto de interés
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-011, RF-012, RF-014, RF-015, RF-019, RF-022, RF-025, RF-032
Descripción: El usuario podrá seleccionar un punto intermedio de la ruta que esté creando y guardarlo como punto de interés en su registro personal. A partir de ese momento, el punto de interés podrá ser reutilizado e insertado como punto intermedio, de partida o de destino en el proceso de creación de una nueva ruta.
TABLA 15: RF-013 GUARDAR PUNTO INTERMEDIO DE UNA RUTA COMO PUNTO DE INTERÉS
RF-014: Consultar puntos de interés
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-011, RF-012, RF-013, RF-015, RF-016, RF-019, RF-022, RF-025, RF-032
Descripción: El usuario podrá consultar la lista de todos los puntos de interés que ha guardado hasta ese momento.
TABLA 16: RF-014 CONSULTAR PUNTOS DE INTERÉS
RF-015: Eliminar punto de interés
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-011, RF-012, RF-013, RF-014, RF-019, RF-022, RF-025
Descripción: El usuario podrá elegir uno de sus puntos de interés guardados y eliminarlo. Esto hará que el punto de interés se borre del sistema y no pueda ser consultado ni cargado de nuevo.
TABLA 17: RF-015 ELIMINAR PUNTO DE INTERÉS
73
RF-016: Editar punto de interés
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-011, RF-012, RF-013, RF-014, RF-015, RF-019, RF-022, RF-025, RF-032
Descripción: El usuario podrá elegir uno de sus puntos de interés guardados y editar su nombre. El nuevo nombre que el usuario asigne al punto de interés no debe coincidir con el de ninguno de sus otros puntos de interés.
TABLA 18: RF-016 EDITAR PUNTO DE INTERÉS
RF-017: Introducir punto de partida desde el mapa
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-018, RF-019
Descripción: El usuario podrá establecer el punto de partida de la ruta que esté creando seleccionando un punto en el mapa y designándolo como punto de partida. El punto quedará marcado en el mapa con un icono representativo y la dirección física del punto se mostrará en el campo de texto habilitado al efecto.
TABLA 19: RF-017 INTRODUCIR PUNTO DE PARTIDA DESDE EL MAPA
74
RF-018: Introducir punto de partida escribiendo su dirección
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-017, RF-019
Descripción: El usuario podrá establecer el punto de partida de la ruta que esté creando escribiendo la dirección física de esa localización en un campo de texto habilitado al efecto. Tras escribirlo tendrá que validar su elección eligiendo una de entre todas las coincidencias encontradas por el sistema para la dirección escrita, y tras ello, el punto será establecido como punto de partida de la ruta. El punto quedará representado por un icono representativo en el mapa y el valor del campo de texto en el que se escribió la dirección será sustituido por la dirección elegida a posteriori por el usuario.
TABLA 20: RF-018 INTRODUCIR PUNTO DE PARTIDA ESCRIBIENDO SU DIRECCIÓN
RF-019: Introducir punto de partida cargando un punto de interés
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-011, RF-012, RF-013, RF-014, RF-017, RF-018
Descripción: El usuario podrá elegir uno de sus puntos de interés guardados y establecerlo como punto de partida de la ruta que esté creando. El punto se situará en la misma localización en que estaba cuando fue guardado. El punto quedará representado por un icono representativo en el mapa y el valor del campo de texto de la dirección será sustituido por el valor de la dirección del punto cargado.
TABLA 21: RF-019 INTRODUCIR PUNTO DE PARTIDA CARGANDO UN PUNTO DE INTERÉS
75
RF-020: Introducir punto de destino desde el mapa
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-021, RF-022
Descripción: El usuario podrá establecer el punto de destino de la ruta que esté creando seleccionando un punto en el mapa y designándolo como punto de destino. El punto quedará marcado en el mapa con un icono representativo y la dirección física del punto se mostrará en el campo de texto habilitado al efecto.
TABLA 22: RF-020 INTRODUCIR PUNTO DE DESTINO DESDE EL MAPA
RF-021: Introducir punto de destino escribiendo su dirección
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-020, RF-022
Descripción: El usuario podrá establecer el punto de partida de la ruta que esté creando escribiendo la dirección física de esa localización en un campo de texto habilitado al efecto. Tras escribirlo tendrá que validar su elección eligiendo una de entre todas las coincidencias encontradas por el sistema para la dirección escrita, y tras ello, el punto será establecido como punto de partida de la ruta. El punto quedará representado por un icono representativo en el mapa y el valor del campo de texto en el que se escribió la dirección será sustituido por la dirección elegida a posteriori por el usuario.
TABLA 23: RF-021 INTRODUCIR PUNTO DE DESTINO ESCRIBIENDO SU DIRECCIÓN
76
RF-022: Introducir punto de destino cargando un punto de interés
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-011, RF-012, RF-013, RF-014, RF-020, RF-021
Descripción: El usuario podrá elegir uno de sus puntos de interés guardados y establecerlo como punto de destino de la ruta que esté creando. El punto se situará en la misma localización en que estaba cuando fue guardado. El punto quedará representado por un icono representativo en el mapa y el valor del campo de texto de la dirección será sustituido por el valor de la dirección del punto cargado.
TABLA 24: RF-022 INTRODUCIR PUNTO DE DESTINO CARGANDO UN PUNTO DE INTERÉS
RF-023: Introducir punto intermedio desde el mapa
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-024, RF-025
Descripción: El usuario podrá establecer un punto intermedio de la ruta que esté creando seleccionando un punto en el mapa y designándolo como punto intermedio. El punto quedará marcado en el mapa con un icono representativo y la dirección física del punto se mostrará en el campo de texto habilitado al efecto.
TABLA 25: RF-023 INTRODUCIR PUNTO INTERMEDIO DESDE EL MAPA
77
RF-024: Introducir punto intermedio escribiendo su dirección
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-023, RF-025
Descripción: El usuario podrá establecer un punto intermedio de la ruta que esté creando escribiendo la dirección física de esa localización en un campo de texto habilitado al efecto. Tras escribirlo tendrá que validar su elección eligiendo una de entre todas las coincidencias encontradas por el sistema para la dirección escrita, y tras ello, el punto será establecido como punto intermedio de la ruta. El punto quedará representado por un icono representativo en el mapa y el valor del campo de texto en el que se escribió la dirección será sustituido por la dirección elegida a posteriori por el usuario.
TABLA 26: RF-024 INTRODUCIR PUNTO INTERMEDIO ESCRIBIENDO SU DIRECCIÓN
RF-025: Introducir punto intermedio cargando un punto de interés
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-011, RF-012, RF-013, RF-014, RF-023, RF-024
Descripción: El usuario podrá elegir uno de sus puntos de interés guardados y establecerlo como punto intermedio de la ruta que esté creando. El punto se situará en la misma localización en que estaba cuando fue guardado. El punto quedará representado por un icono representativo en el mapa y el valor del campo de texto de la dirección será sustituido por el valor de la dirección del punto cargado.
TABLA 27: RF-025 INTRODUCIR PUNTO INTERMEDIO CARGANDO UN PUNTO DE INTERÉS
78
RF-026: Eliminar punto intermedio
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-023, RF-024, RF-025
Descripción: El usuario podrá elegir uno de los puntos intermedios establecidos en la ruta que está creando y eliminarlo. Al eliminarlo, el icono representativo en el mapa desaparecerá y su campo de dirección será eliminado. A partir de este momento ya no se tendrá en cuenta a la hora de planificar la ruta.
TABLA 28: RF-026 ELIMINAR PUNTO INTERMEDIO
RF-027: Generar nueva ruta
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-006, RF-011, RF-012, RF-013, RF-017, RF-018, RF-019, RF-020, RF-021, RF-022, RF-023, RF-024, RF-025
Descripción: El usuario podrá elegir generar una nueva ruta solicitando al sistema que la planifique. El sistema tendrá en cuenta en todo momento las limitaciones de movilidad y dolencias del usuario. Para que la generación de la nueva ruta tenga éxito es necesario que previamente el usuario haya establecido al menos un punto de partida y otro de destino, siendo los puntos intermedios un recurso opcional. Si la ruta se genera sin problemas, el usuario podrá guardarla en su registro de rutas personales. La nueva ruta se creará en una nueva pestaña, pudiendo siempre volver al apartado de creación de rutas para planificar nuevos trayectos. La nueva ruta contendrá el trazado sobre el mapa de los tramos a recorrer, los detalles de cada uno de estos tramos y un simulador de recorrido con el que el usuario podrá ver a qué vía corresponde cada tramo del camino y los detalles de éste.
TABLA 29: RF-027 GENERAR NUEVA RUTA
79
RF-028: Mostrar otra ruta creada/cargada
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-008, RF-027
Descripción: El usuario podrá cambiar la ruta que esté visualizando por otra de las que estén abiertas en el sistema en ese momento. Cada una de las rutas se mostrará en una pestaña diferenciada de las demás. Seleccionar la pestaña correspondiente a una de ellas hará que sea ésta la que se muestre.
TABLA 30: RF-028 MOSTRAR OTRA RUTA CREADA/CARGADA
RF-029: Ver etapas de la ruta de forma detallada
Prioridad: Alta Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-008, RF-027, RF-028
Descripción: El usuario podrá visualizar los detalles de los tramos que conforman una ruta, tales como su distancia, el tiempo estimado que se tardará en recorrerlo, las instrucciones necesarias para orientarse correctamente, etc. Este apartado estará disponible tanto en las rutas creadas como en las cargadas.
TABLA 31: RF-029 VER ETAPAS DE LA RUTA DE FORMA DETALLADA
RF-030: Cerrar una ruta
Prioridad: Media Estado: Completado
Necesidad: Media Autor: HI Iberia
Requisitos relacionados: RF-008, RF-027, RF-028
Descripción: El usuario podrá cerrar una pestaña que contenga una ruta creada o cargada en la sesión actual. Una vez cerrada, no se podrá volver a consultar y desaparecerá tanto del panel de pestañas de rutas como del sistema en sí. A menos que haya sido guardada con anterioridad, la ruta se perderá.
TABLA 32: RF-030 CERRAR UNA RUTA
80
RF-031: Intercambiar los puntos de partida y destino de una ruta
Prioridad: Baja Estado: Completado
Necesidad: Baja Autor: AMV
Requisitos relacionados: RF-017, RF-018, RF-019, RF-020, RF-021, RF-022, RF-023, RF-024, RF-025
Descripción: El usuario podrá intercambiar los puntos de origen y destino de una ruta antes de crearla. Para ello, tendrá que haber establecido ambos con anterioridad. Los iconos representativos en el mapa y los valores de los campos de texto de las direcciones también serán intercambiados.
TABLA 33: RF-031 INTERCAMBIAR LOS PUNTOS DE PARTIDA Y DESTINO DE UNA RUTA
RF-032: Otorgar un nombre unívoco a un punto de interés guardado
Prioridad: Media Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-011, RF-012, RF-013, RF-016
Descripción: El usuario podrá otorgarle un nombre unívoco a un punto de interés durante el proceso de guardado. El nombre no podrá coincidir con el de ningún otro de sus puntos de interés guardados, pero sí con el de un punto de interés de otro usuario (algo que él desconocería en cualquier caso). Si el usuario opta por no asignar un nombre al punto de interés en el momento del guardado, automáticamente se le asignará como nombre el valor de su dirección física. Este valor, puede ser editado más tarde, siempre que el nombre elegido mantenga el criterio de unicidad.
TABLA 34: RF-032 OTORGAR UN NOMBRE UNÍVOCO A UN PUNTO DE INTERÉS GUARDADO
81
RF-033: Otorgar un nombre unívoco a una ruta guardada
Prioridad: Media Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-006, RF-010
Descripción: El usuario podrá otorgarle un nombre unívoco a una ruta durante el proceso de guardado. El nombre no podrá coincidir con el de ningún otra de sus rutas guardadas, pero sí con el de una ruta de otro usuario (algo que él desconocería en cualquier caso). El usuario ha de asignarle un nombre a la ruta durante el proceso de guardado obligatoriamente, siendo posible editarlo más tarde, siempre que el nombre elegido mantenga el criterio de unicidad.
TABLA 35: RF-033 OTORGAR UN NOMBRE UNÍVOCO A UNA RUTA GUARDADA
RF-034: Aumentar el zoom del mapa
Prioridad: Media Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-035, RF-036
Descripción: El usuario podrá aumentar el zoom del mapa para ver el callejero desde una perspectiva más cercana.
TABLA 36: RF-034 AUMENTAR EL ZOOM DEL MAPA
RF-035: Reducir el zoom del mapa
Prioridad: Media Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-034, RF-036
Descripción: El usuario podrá reducir el zoom del mapa para ver el callejero desde una perspectiva más alejada.
TABLA 37: RF-035 REDUCIR EL ZOOM DEL MAPA
82
RF-036: Desplazarse por el mapa
Prioridad: Media Estado: Completado
Necesidad: Alta Autor: HI Iberia
Requisitos relacionados: RF-034, RF-035
Descripción: El usuario podrá aumentar desplazarse por el mapa arrastrando el curso sobre él.
TABLA 38: RF-035 DESPLAZARSE POR EL MAPA
3.5 ESPECIFICACIÓN DE CASOS DE USO
En primer lugar, se ilustrará las operaciones más elementales que puede
realizar un usuario: registrarse en el sistema y acceder a él. Registrarse es
requisito indispensable para poder iniciar sesión en el sistema, y para
realizar cualquier acción dentro del sistema se necesita haber iniciado
sesión previamente, por lo que todas las acciones que el usuario puede
llevar a cabo en el sistema requieren de una extensión del caso de uso del
“Iniciar sesión”, que a su vez extiende de “Registrarse”. Por ello, y por
simplicidad de los diagramas, se dividirán los casos de uso en dos
diagramas principales (el de las acciones fundamentales y el diagrama
general) y tres subdiagramas que ahondarán de manera más específica en
el modelo de operación de ciertos casos de uso presentes en el diagrama
general. Por último cabe considerar que el caso de uso “Iniciar sesión”
figurará en todos los diagramas y subdiagramas con la finalidad de
representar los puntos de extensión requeridos por el resto de casos de
uso.
Usuario
Iniciar sesión
Registrarse
<<Extend>
>
ILUSTRACIÓN 5: DIAGRAMA GENERAL DE CASOS DE USO
83
Usuario
ILUSTRACIÓN 6: DIAGRAMA GENERAL DE CASOS DE USO II
Crear ruta
Añadir punto
de partida Añadir punto
de destino
Cargar ruta
Guardar ruta
Eliminar punto
intermedio
Guardar punto de
interés
Añadir punto
intermedio
Eliminar punto
de interés
Visualizar ruta
Repasar recorrido
de ruta
Intercambiar puntos
de partida y destino
Cerrar ruta
Editar ruta
Editar punto de interés
Eliminar ruta
Cambiar configuración de
cuenta
Cambiar preferencias
de salud
Iniciar sesión
Cerrar sesión
<<Extend>
>
<<Extend>
>
84
Nombre Registrarse
Actores Usuario
Objetivo El Usuario creará una nueva cuenta con la que quedará registrado en el sistema y podrá acceder a sus funcionalidades.
Pre-condiciones -
Post-condiciones La cuenta queda creada y el usuario puede utilizarla para acceder al sistema.
Escenario básico 1.El Usuario selecciona la opción “Registrarse”. 2.El Usuario rellena un formulario con sus datos personales, sus preferencias y un nombre y contraseña para la cuenta. 3.El Usuario confirma su elección al Sistema y la cuenta es creada en el sistema.
TABLA 39: CASO DE USO – REGISTRARSE
Nombre Iniciar sesión
Actores Usuario
Objetivo El Usuario se identifica con sus credenciales y obtiene acceso al sistema.
Pre-condiciones El Usuario no ha iniciado sesión en el sistema.
Post-condiciones La sesión queda iniciada y el usuario tiene acceso al sistema.
Escenario básico 1.El Usuario selecciona la opción “Iniciar sesión”. 2.El Usuario introduce el nombre y la contraseña de su cuenta y realiza la petición para entrar en el sistema. 3.El Sistema procede a la autenticación de las credenciales y a la solicitud, autorización y validación de la sesión del usuario según un protocolo de autenticación para acceso a servicios. 4.El Usuario es confirmado como usuario del sistema, y su sesión es iniciada.
TABLA 40: CASO DE USO - INICIAR SESIÓN
85
Nombre Cerrar sesión
Actores Usuario
Objetivo El Usuario cerrará su sesión abierta en el sistema y dejará de tener acceso a sus funcionalidades.
Pre-condiciones El Usuario ha iniciado sesión en el sistema.
Post-condiciones La sesión del Usuario en el sistema queda cerrada.
Escenario básico 1.El Usuario selecciona la opción “Cerrar sesión”. 2.Su sesión queda cerrada.
TABLA 41: CASO DE USO - CERRAR SESIÓN
Nombre Cambiar configuración de cuenta
Actores Usuario
Objetivo El Usuario cambiará la configuración personal de su cuenta (contraseña, email, etc.)
Pre-condiciones -
Post-condiciones Los cambios en la configuración de la cuenta son guardados.
Escenario básico 1.El Usuario selecciona la opción “Configurar cuenta”. 2.El Usuario modifica los campos que considera oportuno y solicita que se guarden los cambios. 3.El sistema guarda los cambios, que son aplicados de forma inmediata.
TABLA 42: CASO DE USO - CAMBIAR CONFIGURACIÓN DE CUENTA
Nombre Cambiar preferencias de salud
Actores Usuario
Objetivo El Usuario cambiará las preferencias de salud que son tomadas en cuenta al planificar rutas.
Pre-condiciones -
Post-condiciones Las preferencias de salud del Usuario son guardadas con efecto inmediato.
Escenario básico 1.El Usuario selecciona la opción “Configuración de perfil”. 2.El Usuario modifica los campos que considera oportuno y solicita que se guarden los cambios. 3.El sistema guarda los cambios, que son aplicados de forma inmediata.
TABLA 43: CASO DE USO - CAMBIAR PREFERENCIAS DE SALUD
86
Nombre Guardar punto de interés
Actores Usuario
Objetivo El Usuario guardará un punto de interés para su posterior uso como punto de inicio, final o intermedio de una ruta. El punto de interés a guardar puede ser bien el punto de inicio de una ruta, su punto final o uno de sus puntos intermedios.
Pre-condiciones El punto de interés ha sido previamente añadido a la ruta (ya sea un punto inicial, final o intermedio).
Post-condiciones El punto de interés queda guardado en el registro personal del usuario y puede ser cargado de ahora en adelante.
Escenario básico 1.El Usuario elige el punto de interés que quiere guardar (punto de inicio, final o intermedio de la ruta) y selecciona la opción “Guardar”. 2.El Sistema le solicita al Usuario un nombre para asignarle al punto de interés (no puede ser el de un punto de interés ya existente). 3.El Usuario escribe el nombre y confirma su elección al Sistema. 4.El Sistema guarda el punto de interés en el registro personal del usuario y puede ser cargado de ahora en adelante.
TABLA 44: CASO DE USO - GUARDAR PUNTO DE INTERÉS
87
Nombre Editar punto de interés
Actores Usuario
Objetivo El Usuario editará el nombre de un punto de interés previamente guardado en su perfil.
Pre-condiciones El punto de interés ha sido previamente guardado.
Post-condiciones El nombre del punto de interés queda cambiado.
Escenario básico 1.El Usuario selecciona la opción “Mostrar Puntos de Interés”. 2.El Sistema muestra al Usuario una lista con todos los puntos de interés previamente guardados por él en su perfil personal. 3.El Usuario selecciona uno de los puntos de interés y selecciona la opción “Editar”. 4.El Usuario modifica el nombre del punto de interés y solicita que se guarde el nuevo nombre. 5.El Sistema confirma el cambio de nombre. A partir de este momento el punto de interés pasa a estar disponible con el nuevo nombre.
TABLA 45: CASO DE USO - EDITAR PUNTO DE INTERÉS
88
Nombre Eliminar punto de interés
Actores Usuario
Objetivo El Usuario eliminará un punto de interés previamente guardado en su perfil.
Pre-condiciones El punto de interés ha sido previamente guardado.
Post-condiciones El punto de interés ha sido eliminado del perfil personal del Usuario.
Escenario básico 1.El Usuario selecciona la opción “Mostrar Puntos de Interés”. 2.El Sistema muestra al Usuario una lista con todos los puntos de interés previamente guardados por él en su perfil personal. 3.El Usuario selecciona uno de los puntos de interés y selecciona la opción “Eliminar”. 4.El Sistema solicita confirmación al Usuario para eliminar el punto de interés. 5.El Usuario confirma el borrado. 6.El Sistema elimina el punto de interés del perfil personal del Usuario. A partir de este momento deja de estar disponible para el Usuario.
TABLA 46: CASO DE USO - ELIMINAR PUNTO DE INTERÉS
89
Nombre Crear ruta
Actores Usuario
Objetivo El Usuario creará una ruta nueva.
Pre-condiciones -
Post-condiciones La planificación de la nueva ruta se mostrará en la aplicación.
Escenario básico 1.El Usuario establece el punto de origen de la ruta (ver caso de uso “Añadir punto de partida”). 2.El Usuario establece el punto de destino de la ruta (ver caso de uso “Añadir punto de llegada”). 3.El Usuario establece puntos intermedios por los que ha de pasar la ruta (ver caso de uso “Añadir punto intermedio”). (Opcional) 4.El Usuario confirma su elección al Sistema y la planificación de la nueva ruta se mostrará en una nueva pestaña en la aplicación inmediatamente después.
TABLA 47: CASO DE USO - CREAR RUTA
Nombre Visualizar ruta
Actores Usuario
Objetivo El Usuario visualizará una ruta creada o cargada.
Pre-condiciones La ruta ha sido previamente creada o cargada (ver casos de uso “Crear ruta” y “Cargar ruta”).
Post-condiciones La ruta mostrada por el Sistema es la seleccionada por el Usuario.
Escenario básico 1.El Usuario selecciona la ruta que quiere visualizar de entre las rutas abiertas (creadas y/o cargadas) en el Sistema seleccionando la pestaña correspondiente. 2.El Sistema le muestra al Usuario la ruta representada sobre el mapa y todos los detalles del trayecto. TABLA 48: CASO DE USO - VISUALIZAR RUTA
90
Nombre Cerrar ruta
Actores Usuario
Objetivo El Usuario cerrará el panel de visualización de una ruta previamente abierta.
Pre-condiciones La ruta ha sido previamente creada (ver caso de uso “Crear ruta”) o cargada (ver caso de uso “Cargar ruta”).
Post-condiciones La ruta deja de poder consultarse. En caso de que no haya sido previamente guardada, se perderá.
Escenario básico 1.El Usuario selecciona el panel de visualización de una ruta y elige la opción “Cerrar”. 2.El Sistema cierra la ruta y la elimina del panel de rutas abiertas.
TABLA 49: CASO DE USO - CERRAR RUTA
Nombre Guardar ruta
Actores Usuario
Objetivo El Usuario guardará una ruta recientemente creada para poder consultarla posteriormente.
Pre-condiciones La ruta ha sido previamente creada (ver caso de uso “Crear ruta”).
Post-condiciones La ruta queda guardada en el registro personal del usuario y puede ser cargada de ahora en adelante.
Escenario básico 1.El Usuario selecciona la opción “Guardar ruta” desde una ruta creada (no cargada). 2.El Sistema le solicita al Usuario un nombre para asignarle a la ruta (no puede ser el de una ruta ya existente). 3.El Usuario escribe el nombre y confirma su elección. 4.El Sistema guarda la ruta en la base de datos con el nombre especificado. Puede ser consultada de ahora en adelante. TABLA 50: CASO DE USO - GUARDAR RUTA
91
Nombre Cargar ruta
Actores Usuario
Objetivo El Usuario cargará una de sus rutas personales y ésta se mostrará en la aplicación.
Pre-condiciones La ruta ha de haber sido guardada previamente.
Post-condiciones La ruta se muestra en la aplicación con todos sus detalles.
Escenario básico 1.El Usuario selecciona la opción “Cargar ruta”. 2.El Usuario selecciona la ruta que quiere cargar de entre sus rutas personales guardadas. 3.El Usuario confirma su elección al Sistema y la ruta se muestra inmediatamente después en la aplicación en una nueva pestaña.
TABLA 51: CASO DE USO - CARGAR RUTA
Nombre Editar ruta
Actores Usuario
Objetivo El Usuario editará el nombre de una ruta previamente guardada en su perfil.
Pre-condiciones La ruta ha sido previamente guardada.
Post-condiciones El nombre de la ruta queda cambiado.
Escenario básico 1.El Usuario selecciona la opción “Mostrar rutas guardadas”. 2.El Sistema muestra al Usuario una lista con todas las rutas previamente guardadas por él en su perfil personal. 3.El Usuario selecciona una de las rutas y selecciona la opción “Editar”. 4.El Usuario modifica el nombre de la ruta y solicita que se guarde el nuevo nombre. 5.El Sistema confirma el cambio de nombre. A partir de este momento la ruta pasa a estar disponible con el nuevo nombre.
TABLA 52: CASO DE USO - EDITAR RUTA
92
Nombre Eliminar punto de interés
Actores Usuario
Objetivo El Usuario eliminará una ruta previamente guardado en su perfil.
Pre-condiciones La ruta ha sido previamente guardada.
Post-condiciones La ruta ha sido eliminada del perfil personal del Usuario.
Escenario básico 1.El Usuario selecciona la opción “Mostrar rutas guardadas”. 2.El Sistema muestra al Usuario una lista con todas las rutas previamente guardadas por él en su perfil personal. 3.El Usuario selecciona una de las rutas y selecciona la opción “Eliminar”. 4.El Sistema solicita confirmación al Usuario para eliminar la ruta. 5.El Usuario confirma el borrado. 6.El Sistema elimina la ruta del perfil personal del Usuario. A partir de este momento deja de estar disponible para el Usuario.
TABLA 53: CASO DE USO - ELIMINAR PUNTO DE INTERÉS
Nombre Repasar recorrido de ruta
Actores Usuario
Objetivo El Usuario repasará las distintas etapas de un trayecto y podrá visualizar los detalles de todas ellas.
Pre-condiciones El Usuario se encuentra visualizando una ruta (ver caso de uso “Visualizar ruta”).
Post-condiciones -
Escenario básico 1.El Usuario selecciona en los detalles de la ruta un tramo y selecciona la opción “Detalles” del tramo. 2.El Sistema muestra el tiempo estimado para recorrer ese tramo, las instrucciones detalladas para recorrerlo y resalta sobre el mapa el tramo de la ruta seleccionado.
TABLA 54: CASO DE USO - REPASAR RECORRIDO DE RUTA
93
Nombre Añadir punto de partida
Actores Usuario
Objetivo El Usuario establecerá el punto de origen de una ruta en creación.
Pre-condiciones -
Post-condiciones El punto de origen de la ruta queda establecido.
Escenario básico (ver “Extensión: Añadir punto de partida”) TABLA 55: CASO DE USO - AÑADIR PUNTO DE PARTIDA
Nombre Añadir punto de destino
Actores Usuario
Objetivo El Usuario establecerá el punto de destino de una ruta en creación.
Pre-condiciones -
Post-condiciones El punto de destino de la ruta queda establecido.
Escenario básico (ver “Extensión: Añadir punto de destino”) TABLA 56: CASO DE USO - AÑADIR PUNTO DE DESTINO
Nombre Intercambiar puntos de partida y destino
Actores Usuario
Objetivo El Usuario intercambiará los puntos de partida y destino establecidos en una ruta en creación.
Pre-condiciones Tanto el punto de partida como el de destino han sido establecidos en la ruta en creación utilizando cualquiera de los métodos disponibles (ver las extensiones “Extensión: Añadir punto de partida” y “Extensión: Añadir punto de destino”)
Post-condiciones El punto de partida pasa a ser el de destino y viceversa.
Escenario básico 1.El Usuario selecciona la opción “Intercambiar puntos de partida y destino”. 2.El sistema intercambia la posición, la dirección y el icono en el mapa del punto de partida con el de destino y viceversa.
TABLA 57: CASO DE USO - INTERCAMBIAR PUNTOS DE PARTIDA Y DESTINO
94
Nombre Añadir punto intermedio
Actores Usuario
Objetivo El Usuario establecerá un punto intermedio para una ruta en creación.
Pre-condiciones -
Post-condiciones El punto intermedio de la ruta queda establecido.
Escenario básico (ver “Extensión: Añadir punto intermedio”) TABLA 58: CASO DE USO - AÑADIR PUNTO INTERMEDIO
Nombre Eliminar punto intermedio
Actores Usuario
Objetivo El Usuario eliminará un punto intermedio establecido en una ruta en creación.
Pre-condiciones El punto intermedio ha sido establecido en la ruta.
Post-condiciones El punto intermedio queda eliminado de la ruta.
Escenario básico 1.El Usuario elige un punto intermedio de la lista de puntos intermedios de la ruta en creación. 2.El Usuario selecciona la opción “Eliminar” del punto intermedio. 3.El sistema elimina el punto intermedio de la ruta y borra todo rastro de él en el mapa y la interfaz. A partir de este momento el punto intermedio deja de figurar en la ruta y no será considerado en ningún paso a la hora de planificarla.
TABLA 59: CASO DE USO - ELIMINAR PUNTO INTERMEDIO
95
Extensión: Añadir punto de partida
Nombre Cargar punto de partida
Actores Usuario
Objetivo El Usuario carga el punto de partida de la ruta a partir de un punto de interés previamente guardado.
Pre-condiciones El punto de interés fue previamente guardado.
Post-condiciones El punto de partida de la ruta queda establecido.
Escenario básico 1.El Usuario selecciona la opción “Cargar punto de partida”. 2.El Sistema muestra la lista de puntos de interés guardados por el Usuario y éste selecciona uno. 3.El Usuario comunica su elección al Sistema y se establece ese punto de interés como punto de partida de la ruta en creación.
TABLA 60: CASO DE USO - CARGAR PUNTO DE PARTIDA
Usuario
ILUSTRACIÓN 7: DIAGRAMA DE CASOS DE USO – EXTENSION: AÑADIR PUNTO DE PARTIDA
Establecer punto
de partida a partir
de una dirección
Cargar punto de
partida
Establecer punto de
partida desde el mapa
Iniciar Sesión
<<Extend>
>
<<Extend>
>
<<Extend>
>
96
Nombre Establecer punto de partida a partir de una dirección
Actores Usuario
Objetivo El Usuario establecerá el punto de partida de la ruta a partir de una dirección física.
Pre-condiciones -
Post-condiciones El punto de partida de la ruta queda establecido.
Escenario básico 1.El Usuario escribe la dirección del punto de partida en el campo habilitado al efecto. 2.El Sistema transforma la dirección en un par de coordenadas y establece el punto en el mapa. El punto de partida de la ruta queda establecido.
TABLA 61: CASO DE USO - ESTABLECER PUNTO DE PARTIDA A PARTIR DE UNA DIRECCIÓN
Nombre Establecer punto de partida desde el mapa
Actores Usuario
Objetivo El Usuario establecerá el punto de partida de la ruta seleccionando un punto concreto del mapa.
Pre-condiciones -
Post-condiciones El punto de partida de la ruta queda establecido.
Escenario básico 1.El Usuario selecciona un punto del mapa y comunica al sistema su intención de establecerlo como punto de partida de la ruta. 2.El Sistema transforma el punto en una dirección física y lo establece como punto de partida.
TABLA 62: CASO DE USO - ESTABLECER PUNTO DE PARTIDA DESDE EL MAPA
97
Extensión: Añadir punto de destino
Nombre Cargar punto de destino
Actores Usuario
Objetivo El Usuario carga el punto de destino de la ruta a partir de un punto de interés previamente guardado.
Pre-condiciones El punto de interés fue previamente guardado.
Post-condiciones El punto de destino de la ruta queda establecido.
Escenario básico 1.El Usuario selecciona la opción “Cargar punto de destino”. 2.El Sistema muestra la lista de puntos de interés guardados por el Usuario y éste selecciona uno. 3.El Usuario comunica su elección al Sistema y se establece ese punto de interés como punto de destino de la ruta en creación.
TABLA 63: CASO DE USO - CARGAR PUNTO DE DESTINO
Usuario
Establecer punto
de destino a partir
de una dirección
Cargar punto de
destino
Establecer punto de
destino desde el mapa
Iniciar Sesión
<<Extend>
>
<<Extend>
>
<<Extend>
>
ILUSTRACIÓN 8: DIAGRAMA DE CASOS DE USO – EXTENSION: AÑADIR PUNTO DE DESTINO
98
Nombre Establecer punto de destino a partir de una dirección
Actores Usuario
Objetivo El Usuario establecerá el punto de destino de la ruta a partir de una dirección física.
Pre-condiciones -
Post-condiciones El punto de partida de la ruta queda establecido.
Escenario básico 1.El Usuario escribe la dirección del punto de destino en el campo habilitado al efecto. 2.El Sistema transforma la dirección en un par de coordenadas y establece el punto en el mapa. El punto de destino de la ruta queda establecido.
TABLA 64: CASO DE USO - ESTABLECER PUNTO DE DESTINO A PARTIR DE UNA DIRECCIÓN
Nombre Establecer punto de destino desde el mapa
Actores Usuario
Objetivo El Usuario establecerá el punto de destino de la ruta seleccionando un punto concreto del mapa.
Pre-condiciones -
Post-condiciones El punto de destino de la ruta queda establecido.
Escenario básico 1.El Usuario selecciona un punto del mapa y comunica al sistema su intención de establecerlo como punto de destino de la ruta. 2.El Sistema transforma el punto en una dirección física y lo establece como punto de destino.
TABLA 65: CASO DE USO - ESTABLECER PUNTO DE DESTINO DESDE EL MAPA
99
Extensión: Añadir punto intermedio
Nombre Cargar punto intermedio
Actores Usuario
Objetivo El Usuario carga un punto intermedio de la ruta a partir de un punto de interés previamente guardado.
Pre-condiciones El punto de interés fue previamente guardado
Post-condiciones El punto intermedio de la ruta queda establecido.
Escenario básico 1.El Usuario selecciona la opción “Cargar punto intermedio”. 2.El Sistema muestra la lista de puntos de interés guardados por el Usuario y éste selecciona uno. 3.El Usuario comunica su elección al Sistema y se establece ese punto de interés como punto intermedio de la ruta en creación.
TABLA 66: CASO DE USO - CARGAR PUNTO INTERMEDIO
Usuario
Establecer punto
intermedio a partir
de una dirección
Cargar punto
intermedio
Establecer punto
intermedio desde el mapa
Iniciar Sesión
<<Extend>
>
<<Extend>
>
<<Extend>
>
ILUSTRACIÓN 9: DIAGRAMA DE CASOS DE USO – EXTENSION: AÑADIR PUNTO INTERMEDIO
100
Nombre Establecer punto intermedio a partir de una dirección
Actores Usuario
Objetivo El Usuario establecerá un punto intermedio de la ruta a partir de una dirección física.
Pre-condiciones -
Post-condiciones El punto intermedio de la ruta queda establecido.
Escenario básico 1.El Usuario escribe la dirección del punto intermedio en el campo habilitado al efecto. 2.El Sistema transforma la dirección en un par de coordenadas y establece el punto en el mapa. El punto intermedio de la ruta queda establecido.
TABLA 67: CASO DE USO - ESTABLECER PUNTO INTERMEDIO A PARTIR DE UNA DIRECCIÓN
Nombre Establecer punto intermedio desde el mapa
Actores Usuario
Objetivo El Usuario establecerá un punto intermedio de la ruta seleccionando un punto concreto del mapa.
Pre-condiciones -
Post-condiciones El punto intermedio de la ruta queda establecido.
Escenario básico 1.El Usuario selecciona un punto del mapa y comunica al sistema su intención de establecerlo como punto intermedio de la ruta. 2.El Sistema transforma el punto en una dirección física y lo establece como punto intermedio.
TABLA 68: CASO DE USO - ESTABLECER PUNTO INTERMEDIO DESDE EL MAPA
101
102
4 DISEÑO
4.1 ARQUITECTURA DEL SISTEMA
En este apartado se abordará la composición estructural del proyecto,
definiendo y explicando la función de los distintos componentes que
conforman la arquitectura de la aplicación. No obstante, al estar
enmarcado en un proyecto empresarial europeo, existen términos de
confidencialidad con la empresa y con el resto de socios del consorcio de
obligado cumplimiento, pudiendo solo hacer uso de aquellos documentos
que son públicos. Por ello, ciertos detalles de la arquitectura han de ser
omitidos para cumplir con los términos de confidencialidad contraídos con
la empresa. La estructura que se definirá a continuación puede distar en
cierta medida de la real, pero se procurará esbozarla lo más aproximada
posible.
Al ser un proyecto empresarial de cierta envergadura, el diseño de la
arquitectura y la elección de los componentes no han correspondido al
estudiante, sino al consorcio de socios del proyecto. Por lo tanto, al ser
unas elecciones ajenas al estudiante y no habiendo participado éste en la
toma de estas decisiones, en este apartado se definirán los componentes,
su función y sus relaciones con el resto de elementos, pero no se
justificará la elección de éstos ni se comparará su utilidad o eficiencia con
respecto a las de otras posibles opciones.
Una vez establecida la situación en la que se desenvolverá este desarrollo,
procedamos a explicar el esquema estructural de la herramienta:
103
La arquitectura de la parte del sistema concerniente a este proyecto, es
decir, de la página y la aplicación web, está basada en un patrón Modelo-
Vista-Controlador (MVC). Este patrón plantea una división del sistema en
tres capas: el Modelo (lógica de negocio y sistema de gestión de base de
datos), la Vista (parte visual que se muestra al usuario) y el Controlador
(manejador de eventos de la vista).[35]
INTERNET
MODELO
DISPOSITIVO MÓVIL
CLIENTE WEB
BASE DE DATOS
PLANIFICADOR DE RUTAS
APLICACIÓN MÓVIL
CONTROLADOR
VISTA
APLICACIÓN WEB
PÁGINA WEB
ILUSTRACIÓN 10: ESQUEMA DE LA ARQUITECTURA DEL SISTEMA
104
La principal ventaja de utilizar este patrón estructural es la modularidad y
desacoplamiento de la que gozan cada una de las partes de la aplicación.
El diseño en tres capas del sistema pretende separar la capa visual gráfica
de su correspondiente programación y del acceso a datos, de tal manera
que los cambios que hayan de acometerse en alguna de estas capas
suponga modificaciones únicamente en esa determinada capa. Esto
mejora el desarrollo y el mantenimiento de las capas, lo cual es de capital
importancia ya que cada una de ellas cumple ciclos de vida muy distintos
entre sí.
De forma más detallada, la utilización del patrón MVC en este proyecto se
traduce en lo siguiente:
Modelo: está comprendido por dos elementos: el planificador de
rutas que correspondería a la lógica de negocio, y el sistema gestor
de base de datos, que controla las inserciones, consultas y borrados
que realizan los demás componentes de la aplicación en la base de
datos. El planificador de rutas es el componente que contiene la
mayor parte del peso operativo de la aplicación, ya que es el
responsable de todos los aspectos concernientes a la planificación y
realización de las rutas para los usuarios. Por otra parte, el sistema
de gestión de la base de datos tiene también un papel crucial en el
desarrollo de las funciones del sistema, pero a un nivel diferente:
alberga la información personal de los usuarios, su configuración y
preferencias, sus rutas y puntos de interés guardados, la
información de los transportes públicos y todos los demás
contenidos que necesitan ser almacenados con la finalidad de hacer
posible la generación de rutas personalizadas por parte del
planificador.
Vista: es la parte visual del sistema destinada al usuario, que a la vez
se encarga de recoger la interacción de éste con la aplicación. Está
compuesta por el conjunto de las páginas que conforman la página
web como tal. Si los contenidos que muestra son modificados, ya
sea como consecuencia de la interacción del usuario o como
derivado de las acciones internas del sistema, éstos serán
105
actualizados por el Modelo en la Vista, manteniendo al usuario al
día del estado del sistema.
Controlador: también interpretado en el lado cliente (al igual que la
Vista), el Controlador es el encargado de recibir los eventos que se
generen en la Vista y llevar a cabo la serie de acciones
correspondiente, comunicándose para ello con el Modelo y, en
ocasiones, con la Vista. El Controlador está también a cargo del
manejo de errores y de la seguridad y la coherencia de la aplicación.
Sus componentes son un conjunto de scripts que dotan de
funcionalidad a la página web, y que en función de su finalidad
pueden ser separados en dos bloques: los encargados de la gestión
de las acciones del usuario en la propia página web y los
relacionados con la aplicación de mapas embebida en ésta, que
funcionan de forma independiente y suponen un subconjunto
autónomo.
106
4.2 DIAGRAMAS DE ACTIVIDAD
LOGIN
ILUSTRACIÓN 11: DIAGRAMA DE ACTIVIDAD - LOGIN
[credenciales correctas]
[credenciales incorrectas]
[usuario no registrado] [usuario registrado]
[token obtenido]
[token obtenido]
[error al obtener el token]
[error al obtener el token]
[sesión no abierta] [sesión abierta]
Introducir credenciales de usuario
Comprobar usuario en registro de
clientes OAuth*
Solicitar request token para el usuario*
Solicitar autorización de access token
para el usuario*
Registrar usuario en
registro de clientes
OAuth*
*Este apartado pertenece a la secuencia de pasos del protocolo de autenticación OAuth
107
CREAR RUTA
[credenciales correctas] [credenciales incorrectas]
[opcional]
[error al establecer los
puntos]
[ruta calculada] [error al calcular la ruta]
[error al abrir el planificador]
Establecer punto
intermedio
Login
Abrir planificador de rutas
Establecer origen y destino
Calcular ruta
[puntos establecidos]
ILUSTRACIÓN 12: DIAGRAMA DE ACTIVIDAD – CREAR RUTA
108
GUARDAR PUNTO DE INTERÉS
[credenciales correctas] [credenciales incorrectas]
[error al establecer el punto]
[nombre válido] [nombre ya utilizado]
[error al abrir el planificador]
Login
Abrir planificador de rutas
Establecer punto de interés*
Seleccionar guardar punto
Asignar nombre al punto
*El punto puede establecerse indistintamente como punto de origen, destino o intermedio de una ruta.
ILUSTRACIÓN 13: DIAGRAMA DE ACTIVIDAD – GUARDAR PUNTO DE INTERÉS
109
GUARDAR RUTA
[credenciales correctas] [credenciales incorrectas]
[error al planificar la ruta]
[nombre válido] [nombre ya utilizado]
[error al abrir el planificador]
Login
Abrir planificador de rutas
Crear ruta
Seleccionar guardar ruta
Asignar nombre a la ruta
ILUSTRACIÓN 14: DIAGRAMA DE ACTIVIDAD – GUARDAR RUTA
110
CARGAR PUNTO DE INTERÉS
[credenciales correctas] [credenciales incorrectas]
[no hay puntos guardados]
[punto establecido]
[error al establecer el punto]
[error al abrir el planificador]
Login
Abrir planificador de rutas
Seleccionar lugares personales guardados
Seleccionar punto para cargar
Asignar función al punto*
*El punto puede establecerse como punto de origen, destino o intermedio.
ILUSTRACIÓN 15: DIAGRAMA DE ACTIVIDAD – CARGAR PUNTO DE INTERÉS
111
CARGAR RUTA
[credenciales correctas] [credenciales incorrectas]
[no hay rutas guardadas]
[ruta cargada correctamente]
(se muestra en el planificador)
[error al cargar la ruta]
Login
Seleccionar apartado de rutas personales guardadas
Seleccionar ruta para cargar
Seleccionar cargar ruta
ILUSTRACIÓN 16: DIAGRAMA DE ACTIVIDAD – CARGAR RUTA
112
4.3 DIAGRAMAS DE ESTADO
RUTA
Ruta En Creación
Ruta Creada
Ruta Guardada
Ruta Cargada
planificar cerrar borrar
guardar cargar cerrar
ILUSTRACIÓN 17: DIAGRAMA DE ESTADOS - RUTA
113
PUNTO DE INTERÉS
Punto No Establecido
Punto Establecido
Punto Guardado
Punto Cargado
establecer eliminar
borrar
guardar cargar eliminar
ILUSTRACIÓN 18: DIAGRAMA DE ESTADOS – PUNTO DE INTERÉS
114
4.4 NECESIDADES DE INTEGRACIÓN
El conjunto de la aplicación está siendo desarrollado por diversos socios
participantes en el proyecto desde distintas partes de Europa. Por tanto es
necesario adherirse a unas interfaces y especificaciones muy concretas a
la hora de desarrollar las secciones que conectarán los componentes de
unos con los de otros. Ocurre lo mismo con los formatos y los tipos de
datos que se almacenan en la base de datos para ser reutilizados por los
componentes de los otros miembros del consorcio o que se intercambian
entre las distintas partes de la aplicación. En consecuencia, ha sido
necesario respetar explícitamente los formatos de las llamadas acordadas
de antemano a la hora de invocar las funciones ofrecidas por los
componentes de los otros socios (en la mayoría de los casos, mediante
peticiones HTTP GET o POST con parámetros adjuntos), así como
almacenar los datos de usuario siguiendo unas directrices concretas a fin
de que al ser accedidos por las otras partes de la aplicación, éstas
obtengan exactamente los datos a los que esperaban acceder, tanto en
contenido como en forma.
Por otra parte, la implementación del protocolo de autenticación OAuth
[23] también acarreó nuevas necesidades de integración. Este requisito se
propuso para proteger el acceso a los datos de usuario ya avanzado el
proyecto, y por lo tanto se carecía de una especificación previa de cómo
implementarlo y qué interfaces utilizar. Por ello, a medida que se
implementaba se fueron acordando los pasos a seguir y los mecanismos
de interacción entre las partes implicadas para habilitar este protocolo.
Nuestra parte consistía en desarrollar el servidor y un cliente; el servidor
cubría los datos de usuario con una capa de seguridad que otorgaba
acceso a los datos únicamente a los clientes autorizados, y el cliente
integraba los mecanismos de comunicación y autenticación requeridos
por el servidor para obtener el acceso a éstos. El servidor por lo tanto
debía ofrecer una interfaz de cara a los clientes que les permitiera
efectuar los pasos necesarios del protocolo. Tras numerosas etapas de
refinamiento y mejora, finalmente se establecieron los métodos de
115
interacción oportunos y se desplegó el protocolo, que actualmente se
encuentra ya en funcionamiento.
116
5 HERRAMIENTAS Y TECNOLOGÍAS EMPLEADAS
5.1 ENTORNO TÉCNICO DE TRABAJO
ECLIPSE
Eclipse [10] es un entorno de desarrollo integrado de código abierto
multiplataforma. Desarrollado originalmente por IBM, ahora está en
manos de la Fundación Eclipse, una organización independiente sin ánimo
de lucro que fomenta una comunidad de código abierto y un conjunto de
productos complementarios, capacidades y servicios.
Eclipse soporta el desarrollo de proyectos en numerosos lenguajes de
programación, pero en el caso particular que nos ocupa ha sido empleado
para desarrollar principalmente código JavaScript y Java. En menor
medida también se ha empleado para modificar documentos XML y hojas
de estilo CSS. Con la finalidad de lidiar adecuadamente con el proyecto, se
han utilizado varias extensiones disponibles desde la plataforma “market”
de la aplicación, tales como los paquetes de compatibilidad con Maven o
con el sistema de versiones GIT. Adicionalmente se le ha incluido un
servidor web Apache Tomcat 6 [6] desde el que lanzar la aplicación web
desarrollada.
FIREBUG
Firebug [13] es una extensión del navegador Mozilla Firefox pensado para
desarrolladores y programadores de contenidos web. Esta extensión
permite a los desarrolladores realizar funciones de depurado y análisis
(debug) del código de una página web tales como monitorización de
variables, consulta de la pila de llamadas o ejecución paso a paso, para
encontrar y corregir los errores que se hayan podido introducir durante el
desarrollo.
117
Gracias a esta herramienta la depuración del código JavaScript se ha
convertido en una tarea más fácil, puesto que al ser un lenguaje
interpretado por el cliente y no por el servidor, habría sido imposible la
depuración con las herramientas del entorno de desarrollo Eclipse [10]
desde el que se realizaba la labor de codificación. Asimismo, la
funcionalidad de monitorización del tráfico de red generado por la
aplicación ha permitido visualizar los problemas de conexión, formato y
permisos de acceso de los mensajes emitidos y/o recibidos, facilitando en
gran medida su depuración.
GEDIT
gedit es un editor de textos multiplataforma de software libre. Es un
editor de propósito general, pero además incluye herramientas para la
edición de código fuente y textos estructurados, como es el caso de los
lenguajes de marcado (como HTML o XML). [35]
Esta herramienta se ha empleado en la labor de creación y edición de
scripts PHP en el servidor. Estos scripts son principalmente los
responsables de manejar las conexiones y consultas a la base de datos
desde la aplicación web. El servidor en el que se han desarrollado y
posteriormente desplegado estos scripts es una máquina que funciona
con la distribución Ubuntu de Linux, y que cuenta con un entorno de
escritorio GNOME, del que gedit es el editor de texto predeterminado; de
ahí que se haya empleado este editor para realizar estas tareas de
desarrollo.
MICROSOFT WORD
Microsoft Word es un software de procesamiento de textos integrado en
la suite de oficina Office de Microsoft.
118
Este editor de texto se ha utilizado para la realización de la memoria de
este proyecto. Ha facilitado en gran medida que el documento final tenga
una presentación adecuada y un formato correcto.
MICROSOFT PROJECT
Microsoft Project es un software de administración de proyectos
integrado en la suite de oficina Office de Microsoft.
Esta aplicación, que facilita la planificación y administración de los
recursos, los tiempos y las tareas de un proyecto, se ha empleado para
elaborar los diagramas de Gantt presentes en el subapartado de
Planificación y Costes del apartado de Análisis Económico.
MOZILLA FIREFOX
Mozilla Firefox es un navegador web libre y de código abierto coordinado
por la Corporación Mozilla y la Fundación Mozilla. Es compatible con
numerosos lenguajes web entre los que se incluyen HTML, XML, XHTML,
SVG, CSS y ECMAScript (JavaScript). [35]
A las características nativas ofrecidas por el navegador se pueden añadir
funciones a través de complementos desarrollados por terceros. Entre la
gran cantidad de complementos y extensiones disponibles existen varios
orientados a los desarrolladores web como Firebug [13] (del que ya se
habló anteriormente).
En este proyecto Mozilla Firefox se ha utilizado a dos niveles: consulta de
información y desarrollo web. En el primer caso se ha empleado para
consultar páginas web con información relevante para el proyecto, hasta
el punto de que la gran mayoría de los elementos que figuran en el
apartado de Referencias son contenido web. Por otro lado, ha sido
empleado para realizar las pruebas de las sucesivas versiones de la
119
aplicación a medida que avanzaba el desarrollo. Gracias a él se han podido
visualizar los efectos de los cambios realizados en el código del apartado
web de la aplicación y depurarlo en consecuencia.
El hecho de que se incluya únicamente este navegador como herramienta
técnica de desarrollo es debido a que ha sido el único empleado durante
la elaboración del proyecto para efectuar pruebas y depuración del
código. No obstante, al margen del navegador empleado como
herramienta de desarrollo, la aplicación puede visualizarse en cualquier
navegador moderno (como Chrome, Opera o Safari).
PGADMIN
pgAdmin es una aplicación de desarrollo y administración multiplataforma
y de código para el sistema gestor de bases de datos PostgreSQL [28] .
pgAdmin proporciona una interfaz gráfica que incluye un editor de SQL
con corrector sintáctico, una consola de SQL y otras herramientas
orientadas a simplificar la administración de los sistemas de bases de
datos basados en PostgreSQL.
pgAdmin está desarrollado por una comunidad de expertos en PostgreSQL
y se distribuye bajo una licencia PostgreSQL.
En este proyecto, pgAdmin se ha utilizado para hacer más sencilla la
creación, edición y administración de la base de datos en la que se aloja la
información de los usuarios del sistema. Esta información es consultada
por las aplicaciones clientes y por la página web, que acceden a ella a
través de los scripts PHP que controlan el acceso a dicha base de datos.
Gracias a pgAdmin es posible comprobar la corrección de los scripts
utilizados para crear, eliminar o editar contenido de la base de datos antes
de efectuar las peticiones, así como consultar el estado de las tablas, su
contenido y su estructura de forma visual y clara.
120
5.2 TECNOLOGÍAS EMPLEADAS
APACHE SERVER
El servidor HTTP Apache es un servidor web HTTP de código abierto
multiplataforma, que se desarrolla dentro del proyecto HTTP Server de la
Apache Software Foundation [6] .
Apache es usado principalmente para enviar páginas web estáticas y
dinámicas, y muchas aplicaciones web están diseñadas asumiendo como
ambiente de implantación a Apache, o que utilizarán características
propias de este servidor web.[35]
Apache es el componente de servidor web en la popular plataforma de
aplicaciones LAMP, compuesta principalmente por cuatro elementos:
Linux como sistema operativo, Apache como servidor web, MySQL como
gestor de bases de datos y Python/PHP/Perl como lenguaje de
programación. A pesar de que estos programas de código abierto
originalmente no fueron diseñados de forma específica para trabajar
juntos, la combinación se popularizó debido a su bajo coste de adquisición
y la ubicuidad de sus componentes (ya que vienen preinstalados en la
mayoría de las distribuciones Linux)[35] . La plataforma de aplicaciones
empleada en el servidor web de este proyecto tan sólo difiere de esta
propuesta en el gestor de bases de datos, ya que se utiliza PostgreSQL en
lugar de MySQL.
En este proyecto, el servidor web de aplicaciones Apache se ha utilizado
para dar soporte a los scripts PHP alojados en el servidor. Estos scripts son
los responsables tanto de la página web de la aplicación como de
proporcionar acceso controlado a las aplicaciones clientes (el cliente web
y la aplicación móvil) al contenido de la base de datos.
121
APACHE TOMCAT
Apache Tomcat es un contenedor de servlets desarrollado bajo el
proyecto Jakarta en la Apache Software Foundation [6] . No es un servidor
de aplicaciones, como JBoss o JOnAS, sino un servidor web con soporte de
servlets y JSPs. Dado que está escrito en Java, funciona en cualquier
sistema operativo que disponga de la máquina virtual Java.
Es mantenido y desarrollado por miembros de la Apache Software
Foundation y voluntarios independientes. El código fuente y su forma
binaria están disponibles para los usuarios de forma libre según los
términos establecidos en la Apache Software License. [35]
El contenedor de servlets Apache Tomcat ha sido utilizado para albergar la
aplicación web, cuyo código ha sido desarrollado en JavaScript (front-end)
y Java (back-end). En este proyecto, Tomcat se ha empleado de forma
integrada con el entorno de desarrollo Eclipse.
CORS
CORS (Cross-Origin Resource Sharing) es un intento reciente del W3C [33]
de introducir un mecanismo estándar para permitir peticiones de dominio
cruzado en navegadores web y servidores. Estas peticiones de dominio
cruzado consisten básicamente en efectuar una petición desde una página
web a otro dominio distinto al suyo, lo cual no están permitidas por los
navegadores web modernos debido a lo que se conoce como cross-origin
security policy (o política de seguridad del mismo origen) que consiste en
una medida de seguridad en la parte cliente que evita que un documento
o script cargado en un origen pueda cargarse o modificar propiedades del
documento desde un origen diferente. La filosofía de esta política es
sencilla: el navegador no debería confiar en contenido cargado desde
sitios web arbitrarios. Las páginas web que se ejecutan de forma aislada
no pueden conectar a recursos de otros orígenes, ya que sin esta
122
protección, una página web maliciosa podría comprometer la
confidencialidad y la integridad de otra página web.[35]
Por tanto, CORS define un método para que el navegador y el servidor
puedan interactuar entre sí para determinar si una petición con distinto
origen es admitida o no.
El sistema CORS estándar funciona añadiendo nuevas cabeceras HTTP a las
peticiones, que permiten a los servidores proporcionar recursos a los
dominios cuyo origen esté permitido. Por su parte, los navegadores dan
soporte a estas cabeceras y obligan a que se cumplan las restricciones que
estas establecen.
Debido a que nuestro sistema está compuesto por diferentes piezas que
conforman un entramado distribuido, este problema se presentó en
numerosas ocasiones. Para abordarlo, empleamos principalmente dos
métodos distintos, en función del tipo de servidor. Como ya se comentó
anteriormente, en el proyecto contamos con un servidor web Apache [6] ,
en el que están alojados los scripts PHP, y un Apache Tomcat [6] , en el
que reside la aplicación web de mapas. Para cada uno de ellos se han
seguido los procedimientos comentados a continuación:
En el Apache Tomcat se empleó CORS Filter [31] . CORS Filter es una
es una biblioteca Java para dar soporte a llamadas CORS en
aplicaciones web Java que opera interceptando las peticiones
entrantes e identificando si son de origen cruzado, en cuyo caso
añade las cabeceras pertinentes antes de dejarlas pasar al destino.
Para ponerla en funcionamiento fue necesario, además de
adjuntarla al resto de bibliotecas del proyecto, definir ciertos
parámetros en el descriptor de despliegue de la aplicación web para
configurar el CORS.
En el servidor Apache, tan sólo fue necesario añadir unas líneas de
código en los scripts PHP afectados por las peticiones de origen
cruzado, de tal forma que se establecieran las cabeceras necesarias
para habilitar el acceso a estos.
123
HTML
HTML es el lenguaje de marcado predominante para la elaboración de
páginas web que se utiliza para describir y traducir la estructura y la
información en forma de texto, así como para complementar el texto con
objetos como imágenes. Cuenta con la capacidad de poder incluir scripts
en lenguajes como JavaScript (tratado a continuación), los cuales pueden
afectar al comportamiento del HTML en los navegadores web,
aportándole mayor complejidad y posibilidades. El HTML se escribe en
forma de etiquetas, rodeadas por corchetes angulares (<,>) y puede
describir, hasta un cierto punto, la apariencia de un documento, aunque el
método más utilizado para este propósito es el lenguaje CSS. La idea que
se encuentra detrás del desarrollo de CSS es separar la estructura de un
documento de su presentación. La información de estilo puede ser
adjuntada como un documento separado o en el mismo documento
HTML, y en este último caso podrían definirse estilos generales en la
cabecera del documento o en cada etiqueta particular.[35]
Al ser este un proyecto basado principalmente en tecnología web, la casi
totalidad de los elementos con los que opera el usuario, es decir, la página
web y la aplicación web de mapas están compuestos en última instancia
por código HTML, ya sea proveniente de código HTML propiamente dicho
u originado como resultado del procesado de scripts en JavaScript. La
estructura de las interfaces con las que interacciona el usuario, así como la
de todos sus componentes (botones, menús, tablas, campos de texto,
etc.) está íntegramente formada por código HTML.
Por otro lado, para definir la apariencia y características visuales de todos
esos elementos se emplean las hojas de estilo CSS, las cuales son
responsables de definir su tamaño, color, transparencia, posición, etc., así
como también el tamaño, color, alineación y fuente de los textos y
etiquetas. En nuestro caso particular, el código CSS se ha empleado en las
dos variantes descritas anteriormente: como hojas de estilo
independientes y como código integrado en cabeceras y etiquetas.
124
Este código HTML y sus directrices de estilo CSS son finalmente
interpretados por el navegador, el cual es el encargado de representar
todo el conjunto de forma visual.
JAVA
Java [17] es un lenguaje de programación cuyas aplicaciones son
generalmente compiladas a bytecode (clase Java) que puede correr en
cualquier máquina virtual Java sin importar la arquitectura de la
computadora. Java es un lenguaje de programación de propósito general,
concurrente, basado en clases, y orientado a objetos, que fue diseñado
específicamente para tener tan pocas dependencias de implementación
como fuera posible. [35]
El back-end del planificador de rutas está íntegramente desarrollado en
Java, y está orientado a ofrecer servicios al front-end (webapp) por medio
de una interfaz REST, la cual ha sido ampliada con funciones adicionales
para dar cobertura a la implementación de OAuth (del que se hablará más
adelante) sobre dicho front-end. El código de la parte Java no se muestra
en el navegador del usuario (lo que sí ocurre con el JavaScript del paquete
webapp), haciéndolo viable para establecerlo como intermediario de
seguridad en las comunicaciones que se efectúan entre el paquete
webapp y el servidor de base de datos. De esta manera, no existe
necesidad de que las claves secretas del protocolo OAuth [23] se tengan
que almacenar en un código descubierto como es el Javascript del
paquete webapp, sino que se mantienen a salvo de intrusiones externas
en el código Java del back-end, al que los usuarios no tienen acceso.
La implementación en Java del back-end aporta numerosas funciones
además de las ya comentadas, puesto que en ella se encuentra contenida
toda la lógica del planificador de mapas. Para facilitar la labor de
implementación de estas funcionalidades se han empleado numerosas
librerías Java como Jersey, Apache HttpComponents o OAuth-Signpost,
entre muchas otras.
125
JAVASCRIPT
JavaScript es un lenguaje de programación interpretado, débilmente
tipado y dinámico, utilizado principalmente en el lado del cliente.
Tradicionalmente se viene utilizando en páginas web HTML para realizar
operaciones y únicamente en el marco de la aplicación cliente, sin acceso
a funciones del servidor.
JavaScript se diseñó con una sintaxis similar al lenguaje de programación
C, aunque adopta nombres y convenciones del lenguaje de programación
Java. Sin embargo Java y JavaScript no están relacionados y tienen
semánticas y propósitos diferentes. Actualmente, el código JavaScript
integrado en las páginas web es interpretado por todos los navegadores
modernos.[35]
En este proyecto se ha realizado un extenso uso de JavaScript,
principalmente en la aplicación de mapas, en la que el front-end está
completamente desarrollado en este lenguaje. La base de este código es
el paquete webapp de OpenTripPlanner [25] (del que se hablará más
adelante), el cual se ha empleado como punto de partida para desarrollar
la aplicación web de mapas. Para la realización de este apartado, parte del
código JavaScript desarrollado ha utilizado los servicios provistos por las
siguientes bibliotecas JavaScript:
jQuery: biblioteca JavaScript de software libre y código abierto que
permite simplificar la manera de interactuar con los documentos
HTML, manipular el árbol DOM, manejar eventos, desarrollar
animaciones y agregar interacción con la técnica AJAX a páginas
web. En nuestro proyecto se ha empleado principalmente por su
capacidad de efectuar llamadas AJAX con las que invocar de forma
dinámica servicios de otros módulos del paquete OpenTripPlanner y
scripts PHP localizados en el servidor. [18]
ExtJS: biblioteca JavaScript para el desarrollo de aplicaciones web
interactivas usando tecnologías como AJAX, DHTML y DOM
desarrollada por Sencha. En el proyecto, esta librería se ha
126
empleado para desarrollar el apartado gráfico y de manejo de
eventos de la interfaz (menús, botones, pestañas, etc.). [30]
Raphael: biblioteca JavaScript para el desarrollo de gráficos
vectoriales en la web. Su meta principal es proveer una herramienta
para hacer el diseño de arte vectorial fácil y multi-navegador. Utiliza
la recomendación SVG del W3C y VML como base para crear los
gráficos, lo que significa que cada objeto gráfico creado es también
un objeto DOM, y por tanto se le puede adjuntar manejadores de
eventos en JavaScript o modificarlos a posteriori. En el proyecto,
Raphael se ha utilizado para desarrollar algunos de los elementos
gráficos dinámicos de la interfaz, como la banda de simulación de la
ruta que aparece bajo el mapa, y que permite al usuario simular el
trayecto tramo por tramo con tan solo desplazar el cursor sobre
ella.[29]
JSON
JSON es un formato ligero para el intercambio de datos. Es un
subconjunto de la notación literal de objetos de JavaScript que no
requiere el uso de XML.
La simplicidad de JSON ha dado lugar a la generalización de su uso,
especialmente como alternativa a XML en AJAX. Una de las supuestas
ventajas de JSON sobre XML como formato de intercambio de datos en
este contexto es que es mucho más sencillo escribir un analizador
sintáctico de JSON. En JavaScript, un texto JSON se puede analizar
fácilmente, lo cual ha sido fundamental para que JSON haya sido aceptado
por parte de la comunidad de desarrolladores AJAX, debido a la ubicuidad
de JavaScript en los navegadores web. [35]
JSON se emplea habitualmente en entornos donde el tamaño del flujo de
datos entre cliente y servidor es de vital importancia cuando la fuente de
datos es explícitamente de fiar y donde no es importante el no disponer
127
de procesamiento XSLT para manipular los datos en el cliente. Si bien es
frecuente ver JSON posicionado contra XML, también es frecuente el uso
de JSON y XML en la misma aplicación, como es nuestro caso.
El intercambio de datos entre la mayoría de los componentes de nuestro
proyecto así como los resultados de las queries efectuadas a la base de
datos y las consultas a los servicios de APIs externas emplean JSON como
formato para estructurar la información que intercambian. De esta forma,
el tráfico de datos se efectúa empleando estructuras con una baja
sobrecarga de información por metadatos y etiquetado y cuya lectura e
interpretación es muy sencilla en destino. Como ya se ha comentado
anteriormente ciertos intercambios de datos en este proyecto no emplean
JSON sino XML, lo que será abordado más adelante.
OAUTH
OAuth (Open Authorization) [16] [23] es un protocolo abierto para
establecer autorización de acceso a recursos. Permite a los usuarios
compartir con un servicio sus recursos privados almacenados en otra
ubicación sin necesidad de mostrar sus credenciales (típicamente nombre
de usuario y contraseña), sustituyéndolas por tokens en su lugar. Cada
token proporciona acceso a una ubicación específica para recursos
concretos y durante un tiempo definido. Esto permite al usuario
proporcionar acceso a un tercero a su información privada almacenada en
otro proveedor de servicios sin tener que compartir sus permisos de
acceso o la totalidad de sus datos. Actualmente es utilizado por muchas de
las principales empresas de servicios online, como Facebook, Twitter,
Dropbox, Flickr o Google para dar acceso a sus APIs.
En WayFiS se ha implementado tanto la parte cliente como la parte
servidor de este protocolo. Los recursos accedidos a través de los scripts
de la base de datos en el lado servidor se han cubierto con una capa de
autenticación OAuth de tal forma que sólo puedan ser consultados por
usuarios autenticados y desde aplicaciones cliente reconocidas. A su vez,
128
cada una de estas aplicaciones ha de implementar el sistema cliente de
OAuth para permitir a sus usuarios contactar con sus datos almacenados
en la base de datos de WayFiS, y así poder esta aplicación utilizarlos para
fines propios sin necesidad de almacenar ni tener acceso directo a las
credenciales de los usuarios en el sistema. El proyecto desarrollado
comprende tanto la parte servidora como una parte cliente (la aplicación
web), por lo que a lo largo del desarrollo del proyecto se han
implementado ambas facetas de este protocolo de autenticación. Cabe
destacar que dicha parte cliente está subdividida en dos módulos: la
página web (elaborada en PHP) y el planificador de rutas (elaborado en
JavaScript y Java), necesitando cada una de ellas una implementación
específica del cliente OAuth, aunque comparten las mismas claves de
cliente (se consideran a todos los efectos una sola aplicación). Además de
implementar la parte cliente y servidor, se ofrece una interfaz abierta
(API) de comunicación con el servidor para que sea usada por otras
aplicaciones clientes que se desarrollen posteriormente, como es el caso
de la aplicación para móviles, cuyo desarrollo está actualmente a cargo de
otro de los socios del consorcio.
OPENTRIPPLANNER
OpenTripPlanner [25] [26] es un planificador de rutas de código abierto
compatible con Linux, Microsoft Windows y potencialmente con cualquier
plataforma que cuente con una máquina virtual Java. Está distribuido bajo
licencia LGPL, y a día de hoy se encuentra en fase de desarrollo activo y
cerca de alcanzar los objetivos para completar la primera fase del
proyecto.
Principalmente desarrollado en Java y JavaScript, este planificador ha sido
empleado como base de la aplicación web de planificación de rutas de
este proyecto.
129
Ofrece distintas vistas del terreno mediante la utilización de diferentes
proveedores de mapas como Mapbox [19] , Mapquest [20] y
OpenStreetMap [24] .
PHP
PHP [27] es un lenguaje de programación de script del lado servidor
originalmente diseñado para el desarrollo web de contenido dinámico.
Fue uno de los primeros lenguajes de programación del lado del servidor
que se podían incorporar directamente en un documento HTML en lugar
de llamar a un archivo externo que procesara los datos.
El código PHP es interpretado por un servidor web con un módulo de
procesamiento de PHP, que genera la página web resultante. Cuando el
cliente hace una petición al servidor para que le envíe una página web, el
servidor ejecuta el intérprete de PHP. Éste procesa el script solicitado,
genera el contenido de manera dinámica (por ejemplo obteniendo
información de una base de datos) y envía el resultado por el intérprete
de vuelta al servidor, quien a su vez se lo envía al cliente.
PHP puede ser ejecutado en la mayoría de los sistemas operativos, como
la familia Unix o Microsoft Windows, y puede interactuar con los
servidores web más populares como CGI, Apache e ISAPI.
En WayFiS, PHP se ha utilizado para desarrollar principalmente dos
elementos: la página web y los scripts del lado servidor que se encargan
de manejar las consultas a la base de datos. Si bien los scripts
responsables de la página web tienen una presencia gráfica en el sistema
dando como resultado la generación dinámica de las distintas páginas que
conforman el sitio web de la aplicación, los manejadores de peticiones a la
base de datos tan sólo reciben peticiones, las procesan, y devuelven la
información que corresponda, sin generar en el proceso código HTML
visible para el usuario.
130
POSTGRESQL
PostgreSQL [28] es un sistema de gestión de bases de datos objeto-
relacional de código libre, distribuido bajo licencia BSD y disponible para
numerosas plataformas, entre las que se encuentran Linux, FreeBSD,
Solaris, Microsoft Windows y Mac OS X. El desarrollo de PostgreSQL está
dirigido por una comunidad de desarrolladores denominada PGDG
(PostgreSQL Global Development Group) que trabajan de forma
desinteresada, altruista y libre, supervisados por organizaciones como
RedHat y EnterpriseDB.
En nuestro proyecto PostgreSQL ha sido usado como sistema gestor de
bases de datos para almacenar y manejar toda la información empleada
en el conjunto de la aplicación, lo cual abarca los datos generados y
consultados en la página web, la aplicación web de mapas, y la aplicación
móvil, así como la información GTFS empleada por el planificador de rutas
y los códigos del sistema de seguridad de acceso a recursos OAuth.
XML
XML es un lenguaje de marcas desarrollado por el W3C [33] que permite
definir la gramática de lenguajes específicos para estructurar documentos
grandes. A diferencia de otros lenguajes, XML da soporte a bases de datos,
siendo útil cuando varias aplicaciones se deben comunicar entre sí o
integrar información. Es un lenguaje extensible, de tal forma que después
de diseñado y puesto en producción, es posible extenderlo con la adición
de nuevas etiquetas, de modo que se pueda continuar utilizando sin
complicación alguna.
XML no ha nacido sólo para su aplicación en Internet, sino que se propone
como un estándar para el intercambio de información estructurada entre
diferentes plataformas. Se puede usar en bases de datos, editores de
texto, hojas de cálculo y casi cualquier cosa imaginable.
131
Es una tecnología que tiene a su alrededor otras que la complementan y la
hacen mucho más grande y con unas posibilidades mucho mayores,
aunque éstas han sido regularmente criticadas por su nivel de detalle y
complejidad. El mapeo del modelo de árbol básico de XML hacia los
sistemas de tipos de lenguajes de programación o bases de datos puede
ser difícil, especialmente cuando se utiliza XML para el intercambio de
datos altamente estructurados entre aplicaciones, lo que no era su
objetivo primario de diseño. [35]
La aplicación de XML en nuestro proyecto se limita a transmisiones que
implican un gran volumen de datos, como el envío de una ruta, con todos
los detalles y elementos que permiten representarla al detalle. Es decir,
cuando al sistema se le exige generar una ruta, independientemente de la
complejidad de esta, la respuesta es un documento XML que contiene
toda la información correspondiente a la ruta codificada siguiendo las
directrices de este formato. El documento es recibido en destino e
interpretado mediante un analizador sintáctico (o parser) de XML, donde
se extrae toda la información contenida en la estructura de datos. Este
documento es la definición completa de la ruta, por lo que si se almacena
nos ofrece la posibilidad de volver a consultarlo más adelante
permitiéndonos volver a representar la ruta sin necesidad de pedir de
nuevo al sistema que la calcule, sino tan sólo que la dibuje ahorrándonos
tiempo de cálculo.
132
6 ANÁLISIS ECONÓMICO
6.1 CONSIDERACIONES INICIALES
Las tareas de análisis relativas a la gestión, planificación y administración
del proyecto fueron realizadas por los responsables correspondientes de
las entidades participantes antes de que el estudiante entrara a formar
parte de él, por lo que éste no estuvo involucrado a ningún nivel en la
toma de decisiones de esta etapa.
El presupuesto total estimado del proyecto se subdivide en los
presupuestos parciales de cada uno de los miembros del consorcio, los
cuales varían en función de las labores que les fueran asignadas durante la
planificación. Partiendo de esta premisa, y asumiendo que el estudiante
no ha tenido acceso al presupuesto total del proyecto ni al parcial
correspondiente a su empresa, en este apartado únicamente se abordarán
los gastos derivados de las etapas del proyecto en las que el estudiante ha
participado activamente y que conoce de primera mano.
Es importante también tener en cuenta que algunas de estas tareas han
sido llevadas a cabo en su totalidad por el estudiante, mientras que otras
se han realizado de manera conjunta entre los distintos miembros de la
empresa involucrados en el proyecto. Por lo tanto no tendría sentido
desglosar el trabajo efectuado especificando quién ha hecho qué de forma
meticulosa, ni tratar de cuantificar la retribución exacta que corresponde
al trabajo realizado por cada uno. En su lugar, se procederá a utilizar una
métrica de estimación de costes basada en los gastos generados durante
el periodo de participación del estudiante en el proyecto: salarios de los
miembros del equipo, software y material.
Para aclarar e ilustrar los gastos declarados en la estimación
presupuestaria, también se adjuntan unos diagramas de Gantt
correspondientes a las dos fases del proyecto en las que el estudiante ha
tomado parte, en los que se especifica la duración de las tareas
133
desarrolladas y en cuáles de ellas ha estado involucrado cada uno de los
miembros del equipo de trabajo del proyecto.
6.2 PLANIFICACIÓN
En esta fase se ilustrará la planificación de las tareas que se han
desarrollado a lo largo del proyecto, así como la participación en ellas de
los distintos miembros del grupo.
Para ello se acudirá a dos diagramas de Gantt que muestran las distintas
fases y subfases llevadas a cabo durante el desarrollo, su duración real,
sus dependencias de otras tareas y los miembros involucrados en cada
una de ellas.
El proyecto se divide en dos fases:
Primera Fase: va desde la fase de análisis previa a la incorporación
del estudiante, en la que se definieron las líneas generales del
proyecto y sus aspectos más importantes hasta la primera revisión
oficial del estado del desarrollo.
Segunda Fase: comprende desde la continuación del proyecto tras
la revisión oficial hasta su conclusión. El estudiante concluyó su
trabajo en este proyecto al final de esta etapa, por lo que no se
contemplan más tareas o hitos más allá de esta fecha (como la
revisión oficial final).
En correspondencia a cada una de estas dos fases, se adjuntan los
correspondientes diagramas de Gantt a continuación:
134
PLANIFICACIÓN DE LA PRIMERA FASE DEL PROYECTO
ILUSTRACIÓN 19: DIAGRAMA DE GANTT – PLANIFICACIÓN DE LA PRIMERA FASE DEL PROYECTO
135
PLANIFICACIÓN DE LA SEGUNDA FASE DEL PROYECTO
ILUSTRACIÓN 20: DIAGRAMA DE GANTT – PLANIFICACIÓN DE LA SEGUNDA FASE DEL PROYECTO
136
6.3 COSTES
Analizando los diagramas anteriores puede comprobarse que la duración
total del proyecto va desde el 1 de mayo de 2012 hasta el 7 de marzo de
2013. Esto implica un intervalo de tiempo ligeramente superior a los 10
meses, pero si se tiene en cuenta el pequeño parón entre la revisión oficial
de la primera fase y el comienzo de la segunda, se podría considerar
redondeando que el tiempo invertido es de 10 meses completos.
El estudiante se incorporó a él el día 1 de agosto de 2012, por lo que a
efectos del cálculo de su salario se han de descontar los tres primeros
meses de este período. A partir de ese punto, tanto el estudiante como los
otros dos miembros del grupo de trabajo (Coordinador y Jefe de Proyecto)
continuaron participando activamente en él hasta su conclusión.
Como puede extraerse de los diagramas, los integrantes del proyecto son
tres: el Coordinador del Proyecto, el Jefe de Proyecto y el estudiante,
desempeñando cada uno diversos roles en el análisis, diseño, desarrollo e
implantación del sistema.
Los recursos tecnológicos requeridos para desarrollar e implantar los
módulos del proyecto han sido 3 ordenadores portátiles (uno por cada
miembro del grupo de trabajo) empleados en la elaboración del código y
la documentación, y un ordenador servidor en el que se han desplegado
los módulos desarrollados haciéndolos accesibles desde el exterior.
Por otra parte, el software empleado para implementar los módulos ha
sido en su totalidad software libre, por lo que al ser de uso gratuito no ha
supuesto ningún gasto adicional. La excepción es el paquete Microsoft
Office, cuyos programas Word, Excel y Project se han empleado para la
elaboración de la documentación del proyecto, y que sí requiere una
licencia de pago.
A continuación se procederá a desglosar los gastos arriba expuestos y a
contabilizar el coste total derivado del desarrollo del proyecto:
137
GASTOS EN PERSONAL
Salario Mensual Meses Trabajados Coste
Coordinador 2500€ 10 25000€
Jefe de Proyecto 1800€ 10 18000€
Estudiante 800€ 7 5600€
Subtotal: 48600€
TABLA 69: GASTOS DE PERSONAL
GASTOS EN SOFTWARE
Coste Unidad Unidades Coste
Microsoft Office 2010 50€ 3 150€
Subtotal: 150€
TABLA 70: GASTOS DE SOFTWARE
GASTOS EN MATERIAL
Coste Unidad Unidades Coste
Ordenador Portátil 1000€ 3 3000€
Servidor 1000€ 1 1000€
Subtotal: 4000€
TABLA 71: GASTOS DE MATERIAL
138
RESUMEN DE GASTOS
Coste
Personal 48600€
Software 150€
Material 4000€
COSTE TOTAL DEL PROYECTO: 52750€
TABLA 72: COSTE TOTAL DEL PROYECTO
El gasto final del proyecto ha sido de 52750 euros.
139
140
7 CONCLUSIONES
Tras haber completado el proceso de desarrollo de la herramienta, es de
esperar que la aplicación final cumpla los objetivos principales que se
definieron al inicio, en el apartado de introducción. Al tratarse de un
proyecto empresarial de investigación y desarrollo llevado a cabo por
distintos socios, fue necesario que la especificación de la herramienta
estuviera bien definida antes de empezar con la implementación, y por
ello los objetivos de los que hablamos anteriormente aseguraron su
presencia quedando plasmados en forma de requisitos.
La aplicación por tanto, no sólo cumple las necesidades expresadas
inicialmente, sino que a medida que el proyecto avanzaba se fueron
proponiendo y añadiendo mejoras y requisitos adicionales que extendían
las funcionalidades iniciales.
La parte de la aplicación desarrollada por el estudiante comprende una
aplicación web cliente, una aplicación de planificación de rutas y una
sección importante del núcleo servidor del proyecto; este núcleo servidor
es una parte vital de la arquitectura ya que es utilizado por todos los
módulos cliente a la hora de acceder a los datos de los usuarios y a sus
configuraciones. Por tanto, puede considerarse de sustancial utilidad la
labor desarrollada por el estudiante en el marco del proyecto WayFiS,
puesto que ha posibilitado la integración del resto de herramientas en un
sistema homogéneo y a su vez ha desarrollado aplicaciones que se sirven
de esta plataforma y amplían sus funciones.
Las necesidades de ampliación de las funcionalidades originales a lo largo
del proyecto han puesto en evidencia la utilidad de que el código
desarrollado por el estudiante fuera modular y ampliable, haciendo
posible a lo largo del período de implementación la inclusión de nuevas
características y tecnologías.
Por último cabría destacar los puntos más reseñables que han supuesto
dificultades al desarrollo a lo largo del proyecto, y las soluciones que se
han aplicado para superarlos. En el siguiente apartado se procederá a ello.
141
7.1 DIFICULTADES ENCONTRADAS
Todo el trabajo plasmado en este proyecto y su memoria ha sido llevado a
cabo por un único estudiante. Esta limitación influye en muchos ámbitos,
que van desde el tiempo invertido para realizarlo hasta la posible falta de
visión global en ciertos aspectos como el de la codificación o el apartado
gráfico. En la medida de lo posible, el estudiante ha tratado de aliviar este
problema recurriendo ocasionalmente a los supervisores y jefes del
proyecto en busca de consejo o de una segunda opinión. El hecho de
contar con puntos de vista adicionales de otras personas involucradas
directamente en el proyecto ha supuesto un recurso muy valioso para
crear un mejor contenido.
Por otra parte, el trabajo realizado en el apartado técnico, principalmente
en lo referente a la codificación, se ha efectuado con numerosas
tecnologías diferentes, que en su mayoría eran nuevas para el estudiante.
Esta situación ha supuesto una dificultad añadida muy importante, puesto
que no sólo ha habido que desarrollar un proyecto complejo manteniendo
unos criterios de calidad y rendimiento elevados, sino que además se ha
tenido que realizar con tecnologías que el estudiante no dominaba, lo que
le ha supuesto un gran esfuerzo adicional. La complejidad que conllevaba
el código a implementar era ya de por sí un desafío, pero lo fue más aun al
tener en cuenta que el estudiante era primerizo con las herramientas.
Una dificultad añadida al desconocimiento de las tecnologías fue la
necesidad de buscar soluciones para los problemas complejos que fueron
surgiendo a lo largo del desarrollo sin conocer plenamente las limitaciones
tecnológicas de estas herramientas. En muchos casos, parecían existir
numerosas vías para solucionar un problema, pero ninguna de ellas
encajaba plenamente en el entorno específico del proyecto. Es muy
importante mencionar este punto en este apartado, debido a que la
necesidad de superar estas situaciones llevó al estudiante a profundizar
ampliamente en las tecnologías utilizadas, en sus limitaciones y en su
filosofía, lo cual acarreó un valioso aprendizaje a la vez que fue de gran
utilidad para solventar los problemas futuros.
142
Al tratarse de un proyecto empresarial, el desarrollo del sistema ha estado
marcado por plazos: revisiones, entregas, pruebas de concepto, etc. Por lo
tanto, al margen del calendario seguido en el ámbito académico, se
tuvieron que cumplir rigurosamente las fechas estipuladas por parte de
los socios. Cada tipo de evento en el calendario del proyecto requería
diferentes requisitos implementados, y en función del tipo de prueba
estos podían cumplirse de forma más o menos rigurosa. No obstante, el
ritmo marcado por estos plazos ha determinado en gran medida el paso
seguido por el proyecto.
El período del proyecto en el que el estudiante ha participado activamente
ha tenido lugar durante un intervalo de unos 8 meses, por lo que a lo largo
de esta etapa ha dado tiempo a que cambiasen muchas cosas. Debido a la
amplitud del proyecto, no sólo se emplean recursos creados internamente
por el equipo de desarrollo, sino que se echa mano de numerosos
servicios externos. Durante este plazo, los términos de licencia y los
protocolos de acceso a algunos de estos servicios en ocasiones se han
visto modificados, dando lugar a que partes del sistema dejaran de
funcionar. No obstante, a medida que fueron surgiendo estos problemas
se fueron solucionando.
Por último, el hecho de hablar del proyecto de un consorcio compuesto
por varios socios conlleva la necesidad de integrar varias partes de forma
que funcionen como un todo. Para ello, se hizo necesario detallar
escrupulosamente todos los cambios en las interfaces y modos de
comunicación de las funciones desarrolladas, de tal forma que pudieran
ser comunicados de forma clara y concisa a los otros miembros. De ahí
que la labor de comunicación entre los distintos miembros del consorcio
haya sido tan relevante.
En definitiva, la necesidad de superar las dificultades afrontadas a lo largo
de este proyecto ha supuesto un reto diario para el estudiante, pero la
voluntad y decisión puestas en solucionarlas ha conllevado un gran y
valioso aprendizaje. Con lo que podemos concluir que el gran esfuerzo
invertido en este proyecto ha conllevado una enorme recompensa.
143
144
8 REFERENCIAS
8.1 ARTÍCULOS
[1] Bien, Z. Z., Park, K. H., Jung, J. W., & Do, J. H. (2005). Intention reading is essential in human-friendly interfaces for the elderly and the handicapped. Industrial Electronics, IEEE Transactions on, 52(6), 1500-1505.
[2] Zajicek, M. (2000). Interface Support for Elderly People with Impaired Sight or Memory. 6th ERCIM Workshop "User Interfaces For All", Short Papers
[3] Lerario, B. R. (2005). Simple Web Interface For the Elderly. Rensselaer
Polytechnic Institute at Hartford, Computer Science Seminar, April 16th
2005.
[4] Murdico, J. (2005). Usability Inspection of a GPS Navigation System.
Rensselaer Polytechnic Institute at Hartford, Computer Science Seminar,
April 16th 2005.
8.2 PÁGINAS WEB
[5] http://www.aal-europe.eu, página web de Ambient Assisted Living
Joint Programme, accedida en enero 2013
[6] http://www.apache.org, página web de Apache Software Foundation, accedida en diciembre 2012
[7] http://betalabs.nokia.com, página web de Nokia Beta Labs, accedida en noviembre 2012
[8] http://www.bing.com/maps, página web de Bing Maps , accedida en enero 2013
145
[9] http://cordis.europa.eu, página web del Servicio de Información Comunitario sobre Investigación y Desarrollo de la Unión Europea, accedida en febrero 2013
[10] http://www.eclipse.org, página web de Eclipse Foundation, accedida en diciembre 2012
[11] http://www.entrance.fr, página web del proyecto Entrance, accedida en diciembre 2012
[12] http://www.foxytour.net, página web de Foxytour, accedida en diciembre 2012
[13] http://www.getfirebug.com, página web de Firebug, accedida en enero 2013
[14] http://www.handimap.org, página web de Handimap, accedida en enero 2013
[15] http://www.here.net, página web de Nokia Here, accedida en diciembre 2012
[16] http://www.hueniverse.com, blog de Eran Hammer, accedido en enero 2013
[17] http://www.java.com, página web de Java, accedida en febrero 2013
[18] http://www.jquery.com, página web de JQuery, accedida en diciembre 2012
[19] http://www.mapbox.com, página web de Mapbox Maps, accedida en enero 2013
[20] http://www.mapquest.com, página web de Mapquest Maps, accedida en diciembre 2012
[21] http://www.maps.yahoo.com, página web de Yahoo Maps, accedida en diciembre 2012
[22] http://www.maps.google.com, página web de Google Maps, accedida en febrero 2013
146
[23] http://www.oauth.net, página web de OAuth, accedida en enero 2013
[24] http://www.openstreetmap.org, página web de OpenStreetMap, accedida en enero 2013
[25] http://www.opentripplanner.com, página web de OpenTripPlanner, accedida en diciembre 2012
[26] http://www.opentripplanner.org/wiki, wiki de OpenTripPlanner, accedida en diciembre 2012
[27] http://www.php.net , página web de PHP, accedida en enero 2013
[28] http://www.postgresql.org.es, página web de PostgreSQL, accedida en diciembre 2012
[29] http://www.raphaeljs.com, página web de RaphaelJS, accedida en diciembre 2012
[30] http://www.sencha.com, página web de Sencha (ExtJS), accedida en diciembre 2012
[31] http://www.software.dzhuvinov.com, página web de Vladimir Dzhuvinov, accedida en enero 2013
[32] http://www.stimulate-aal.eu, página web del proyecto Stimulate, accedida en enero 2013
[33] http://www.w3.org, página web de World Wide Web Consortium, accedida en enero 2013
[34] http://www.wayfis.eu, página web del proyecto WayFiS, accedida en febrero 2013
[35] http://www.wikipedia.org, enciclopedia online Wikipedia, accedida en febrero 2013
147
148
9 APÉNDICES
9.1 ACRÓNIMOS Y ABREVIATURAS
AAL (Ambient Assisted Living): es una iniciativa que involucra a 23 países
(20 países de la UE más Noruega, Suiza e Israel) cuyos principales objetivos
son mejorar las condiciones de vida de los adultos mayores y fortalecer la
competitividad de la industria europea en este ámbito. [5]
AJAX (Asynchronous Javascript And XML): es una técnica de desarrollo
web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en
el cliente, es decir, en el navegador de los usuarios mientras se mantiene
la comunicación asíncrona con el servidor en segundo plano. De esta
forma es posible realizar cambios sobre las páginas sin necesidad de
recargarlas, lo que significa aumentar la interactividad, velocidad y
usabilidad en las aplicaciones.[35]
API (Application Programming Interface): es un conjunto de funciones y
procedimientos o métodos que ofrece cierta biblioteca para ser utilizada
por otro software como una capa de abstracción.[35]
CGI (Common Gateway Interface): es una tecnología que permite a un
cliente solicitar datos de un programa ejecutado en un servidor web. CGI
especifica un estándar para transferir datos entre el cliente y el programa.
Es un mecanismo de comunicación entre el servidor web y una aplicación
externa cuyo resultado final de la ejecución son objetos MIME. Las
aplicaciones que se ejecutan en el servidor reciben el nombre de CGIs.[35]
CORS (Cross-Oriented Resource Sharing): es un mecanismo que permite a
una página web hacer peticiones (XMLHttpRequests) a otro dominio. Tales
peticiones estarían prohibidas por los navegadores web, debido a la
política de seguridad del mismo origen (same origin security policy). CORS
define una manera en la que el navegador y el servidor pueden
interactuar para determinar si se permite o no la solicitud de orígenes
múltiples.[35]
149
CSS (Cascading Style Sheets): es un lenguaje de hojas de estilo usado para
describir la semántica de presentación (el aspecto y el formato) de un
documento escrito en un lenguaje de marcado. Su aplicación más común
es proporcionar la presentación de las páginas web escritas en HTML y
XHTML, pero puede aplicarse a cualquier tipo de documento XML. CSS
está diseñado principalmente para permitir la separación del contenido
del documento (escrito en HTML o un lenguaje de marcado similar) de la
presentación del documento, incluyendo elementos tales como el diseño,
colores y tipos de letra.[35]
DHTML (Dynamic HTML): conjunto de técnicas que permiten crear sitios
web interactivos utilizando una combinación de lenguaje HTML estático,
un lenguaje interpretado en el lado del cliente (como JavaScript), el
lenguaje de hojas de estilo en cascada (CSS) y la jerarquía de objetos de un
Document Object Model (DOM). Una página de HTML Dinámico es
cualquier página web en la que los scripts en el lado del cliente cambian el
HTML del documento, después de que éste haya cargado completamente,
lo cual afecta a la apariencia y las funciones de los objetos de la página. La
característica dinámica del DHTML, por tanto, es la forma en que la página
interactúa con el usuario cuando la está viendo, siendo la página la misma
para todos los usuarios.[35]
DOM (Document Object Model): es una interfaz de programación de
aplicaciones (API) que proporciona un conjunto estándar de objetos para
representar documentos HTML y XML, un modelo estándar sobre cómo
pueden combinarse dichos objetos, y una interfaz estándar para acceder a
ellos y manipularlos. A través del DOM, los programas pueden acceder y
modificar el contenido, estructura y estilo de los documentos HTML y
XML, que es para lo que se diseñó principalmente.[35]
ECMAScript: es una especificación de lenguaje de programación de tipos
dinámicos publicada por ECMA International. Su desarrollo estuvo basado
en el popular lenguaje JavaScript. Actualmente está aceptado como el
estándar ISO 16262.[35]
150
FP7 (7th Framework Programme): el Séptimo Programa Marco es un
programa que agrupa todas las iniciativas relacionadas con la
investigación de la Unión Europea y desempeña un papel crucial en la
consecución de sus objetivos de crecimiento, competitividad y empleo. Es
un pilar clave para el Espacio Europeo de Investigación (ERA, European
Reseach Area). Los amplios objetivos del FP7 están agrupados en cuatro
categorías: Cooperación, Ideas, Personas y Capacidades. Para cada tipo de
objetivo hay un programa específico correspondiente a las áreas
principales de la política de investigación de la Unión Europea. [9]
GIT: es un software de control de versiones diseñado pensando en la
eficiencia y la confiabilidad del mantenimiento de versiones de
aplicaciones cuando éstas tienen un gran número de archivos de código
fuente. Hay algunos proyectos de mucha relevancia que ya usan Git, como
el grupo de programación del núcleo Linux.[35]
GNOME (GNU Network Object Model Environment): es un entorno de
escritorio e infraestructura de desarrollo para sistemas operativos Unix y
derivados Unix compuesto enteramente de software libre.[35]
GNU (GNU is Not Unix, acrónimo recursivo): es un proyecto iniciado con
el objetivo de crear un sistema operativo completamente libre: el sistema
GNU. A fecha de hoy aún no existe un núcleo estable de GNU.[35]
GPS (Global Positioning System): es un sistema global de navegación por
satélite que permite determinar en todo el mundo la posición de un
objeto, una persona o un vehículo con una precisión hasta de centímetros
(si se utiliza GPS diferencial), aunque lo habitual son unos pocos metros de
precisión. El sistema fue desarrollado, instalado y actualmente operado
por el Departamento de Defensa de los Estados Unidos.[35]
GTFS (General Transit Feed Specification): es una especificación de datos
que define un formato común para los horarios de transportes públicos y
la información geográfica asociada a éstos. Los feeds de GTFS permiten a
las agencias de transporte publicar los datos de sus rutas y a los
desarrolladores crear aplicaciones que empleen esos datos.[35]
151
HTML (HyperText Markup Language): es el lenguaje de marcado principal
para la creación de páginas web y otros contenidos que pueden mostrarse
a través de un navegador web. HTML se escribe en forma de elementos
que consisten en etiquetas dentro del contenido de la página web,
encerradas entre paréntesis angulares (como <html>). Entre estas
etiquetas se pueden agregar texto, etiquetas, comentarios y otros tipos de
contenido basado en texto. Los navegadores web no muestran las
etiquetas HTML, pero las utilizan para interpretar el contenido de la
página. HTML hace posible incluir imágenes y crear formularios
interactivos, y permite utilizar scripts escritos en lenguajes como
JavaScript que afectan al comportamiento de la páginas web.[35]
HTTP (HyperText Transfer Protocol): es el protocolo usado en cada
transacción de la World Wide Web. HTTP fue desarrollado por el W3C y la
IETF, colaboración que culminó en 1999. HTTP define la sintaxis y la
semántica que utilizan los elementos de software de la arquitectura web
(clientes, servidores, proxies) para comunicarse. Es un protocolo orientado
a transacciones y sigue el esquema petición-respuesta entre un cliente y
un servidor.[35]
IETF (Internet Engineering Task Force): es una organización internacional
abierta de normalización sin ánimo de lucro, que tiene como objetivos el
contribuir a la ingeniería de Internet, actuando en diversas áreas, como
transporte, encaminamiento, seguridad. La IETF es mundialmente
conocida por ser la entidad que regula las propuestas y los estándares de
Internet, conocidos como RFC (Request For Comments).[35]
ISAPI (Internet Server Application Programming Interface): es una
interfaz, de programación de aplicaciones (API) para el servidor web de
Microsoft, IIS (Internet Information Server). Además del IIS, hay otros
servidores web que soportan ISAPI.[35]
JSON (JavaScript Object Notation): es un estándar abierto basado en
texto diseñado para realizar intercambios de datos de manera legible para
el ser humano. Se utiliza principalmente para transmitir datos entre un
servidor y una aplicación web, sirviendo de alternativa a XML. JSON es una
152
derivación de JavaScript para representar estructuras de datos simples y
arrays asociativos, pero a pesar de ello ambos son independientes.[35]
JSP (JavaServer Pages): es una tecnología Java que permite generar
contenido dinámico para web, en forma de documentos HTML, XML o de
otro tipo. Las JSP permiten la utilización de código Java mediante scripts.
Además, es posible utilizar algunas acciones JSP predefinidas mediante
etiquetas. Para implementar y ejecutar JSP se necesita un servidor web
compatible con un contenedor de servlets, como Apache Tomcat o
Jetty.[35]
JTI (Joint Technology Initiative): son iniciativas tecnológicas conjuntas de
ámbito europeo formadas por asociaciones públicas y privadas, la
industria, la comunidad científica y las autoridades públicas, creadas para
perseguir ambiciosos objetivos de investigación comunes. Están
enmarcadas dentro del Séptimo Programa Marco para acciones de
investigación, desarrollo tecnológico y demostración en áreas estratégicas,
donde la investigación y la innovación son esenciales para la
competitividad europea. [9]
LAMP (Linux Apache MySQL Perl/PHP/Python): un sistema de
infraestructura de internet que usa Linux como sistema operativo, Apache
como servidor web, MySQL como sistema gestor de base de datos y
Perl/PHP/Python como lenguaje de programación. A pesar de que
originalmente estos programas de código abierto fueron específicamente
diseñados para trabajar entre sí, la combinación se popularizó debido a su
bajo coste de adquisición y a la ubicuidad de sus componentes (ya que
vienen pre-instalados en la mayoría de las distribuciones Linux). Cuando
son combinados, representan un conjunto de soluciones que soportan
servidores de aplicaciones.[35]
MVC (Modelo-Vista-Controlador): es un patrón o modelo de abstracción
de desarrollo de software que separa los datos de una aplicación, la
interfaz de usuario, y la lógica de negocio en tres componentes distintos.
El patrón de llamada y retorno MVC se ve frecuentemente en aplicaciones
web, donde la vista es la página HTML y el código que provee de datos
dinámicos a la página; el modelo es el sistema gestor de base de datos y la
153
lógica de negocio, y el controlador es el responsable de recibir los eventos
de entrada desde la vista.[35]
PGDG (PostgreSQL Global Development Group): comunidad de
desarrolladores que trabajan de forma desinteresada y libre en el
desarrollo del sistema gestor de base de datos de código abierto
PostgreSQL.[35]
PHP (PHP Hypertext Pre-processor, acrónimo recursivo): es un lenguaje
de programación interpretado que se utiliza para generar páginas web de
forma dinámica. Se ejecuta en el lado servidor (que ha de disponer de un
módulo procesador de PHP), por lo que el navegador web cliente ya recibe
la página en formato HTML, no pudiendo visualizar el código PHP. Aunque
es menos popular, también puede utilizarse para generar interfaces de
comandos y aplicaciones ejecutables con interfaz gráfica. Debido a su rica
biblioteca, a veces se le hace referencia como una plataforma en lugar de
tan sólo como un lenguaje.[35]
REST (REpresentational State Transfer): es una técnica de arquitectura
software para sistemas distribuidos como la World Wide Web. Si bien el
término se refería originalmente a un conjunto de principios de
arquitectura, en la actualidad se usa en sentido más amplio para describir
cualquier interfaz web simple que utiliza XML y HTTP, sin las abstracciones
adicionales de los protocolos basados en patrones de intercambio de
mensajes como el protocolo de servicios web SOAP.[35]
RFID (Radio-Frecuency IDentification): es un sistema de almacenamiento
y recuperación de datos remoto que usa dispositivos denominados
etiquetas, tarjetas, transpondedores o tags RFID. El propósito
fundamental de la tecnología RFID es transmitir la identidad de un objeto
mediante ondas de radio. Las etiquetas RFID son unos dispositivos
pequeños, similares a una pegatina, que pueden ser adheridas o
incorporadas a un producto, un animal o una persona. Contienen antenas
para permitirles recibir y responder a peticiones por radiofrecuencia
desde un emisor-receptor RFID. Las etiquetas pasivas no necesitan
alimentación eléctrica interna, mientras que las activas sí lo requieren.
Una de las ventajas del uso de radiofrecuencia (en lugar, por ejemplo, de
154
infrarrojos) es que no se requiere visión directa entre emisor y
receptor.[35]
SOAP (Simple Object Access Protocol): es un protocolo estándar que
define cómo dos objetos en diferentes procesos pueden comunicarse por
medio de intercambio de datos XML. Este protocolo deriva de un
protocolo llamado XML-RPC. SOAP puede formar la capa base de una pila
de protocolo de servicio web, ofreciendo un marco de mensajeria básica
en el cual los servicios web se puedan construir. Este protocolo basado en
XML consiste de tres partes: un “sobre”, el cual define qué hay en el
mensaje y cómo procesarlo; un conjunto de reglas de codificación para
expresar instancias de tipos de datos; y una convención para representar
llamadas a procedimientos y respuestas.[35]
SQL (Structured Query Language): es un lenguaje declarativo de acceso a
bases de datos relacionales que permite especificar diversos tipos de
operaciones en ellas. Una de sus características es el manejo del álgebra y
el cálculo relacional que permiten efectuar consultas con el fin de
recuperar de forma sencilla información de interés de bases de datos, así
como hacer cambios en ella. Gracias a su fuerte base teórica y su
orientación al manejo de conjuntos de registros (y no a registros
individuales) permite una alta productividad en codificación y la
orientación a objetos.[35]
SVG (Scalable Vector Graphics): es una especificación para describir
gráficos vectoriales bidimensionales, tanto estáticos como animados, en
formato XML. SVG permite tres tipos de objetos gráficos: elementos
geométricos vectoriales (combinaciones de rectas, curvas), imágenes de
mapa de bits/digitales y texto. SVG se convirtió en una recomendación del
W3C en septiembre de 2001.[35]
TIC (Tecnologías de la Información y la Comunicación): son las
tecnologías que agrupan los elementos y las técnicas usadas en el
tratamiento y la transmisión de la información, principalmente la
informática, internet y las telecomunicaciones.[35]
155
URL (Uniform Resource Locator): es una secuencia de caracteres, de
acuerdo a un formato estándar, que se usa para nombrar recursos en
internet para su localización o identificación, como por ejemplo
documentos textuales, imágenes, vídeos, presentaciones digitales, etc.
Desde 1994, en los estándares de internet el concepto de URL ha sido
incorporado dentro del más general de URI (Uniform Resource Identifier),
pero el término URL aún es ampliamente utilizado.[35]
VML (Vector Markup Language): es un lenguaje XML de programación
abierto, destinado a la creación de gráficos vectoriales elaborados en 2D
(estáticos o animados) en páginas web. En gran medida, VML ha caído en
desus, en favor de otros formatos como SVG. [35]
W3C (World Wide Web Consortium): es un consorcio internacional que
produce recomendaciones para la World Wide Web, con sede central en
el Massachussets Institute of Technology (MIT) y dirigida por Tim Berners-
Lee (creador de las principales tecnologías en que se basa la web: HTML,
HTTP y URL). [33]
WayFiS (WayFinding for Seniors): siglas del proyecto de prototipo de
navegación para mayores sobre el que versa esta memoria. [34]
WiFi (Wireless Fidelity): es un mecanismo de conexión de dispositivos
electrónicos de forma inalámbrica. Los dispositivos habilitados con Wi-Fi
tales como ordenadores personales, videoconsolas, smartphones o
reproductores de audio digital pueden conectarse a internet a través de
un punto de acceso de red inalámbrica. Dicho punto de acceso (o hotspot)
suele tener un alcance de unos 20 metros en interiores y mayor distancia
al aire libre.[35]
XHTML (eXtensible HTML): es básicamente HTML expresado como XML
válido. Es más estricto a nivel técnico, pero esto permite que
posteriormente sea más fácil al hacer cambios o buscar errores entre
otros. En su versión 1.0, XHTML es solamente la versión XML de HTML, por
lo que tiene, básicamente, las mismas funcionalidades, pero cumple las
especificaciones, más estrictas, de XML. Su objetivo es avanzar en el
proyecto del W3C de lograr una web semántica, donde la información y la
156
forma de presentarla estén claramente separadas. En sucesivas versiones
la W3C planea romper con los tags clásicos traídos de HTML.[35]
XML (eXtensible Markup Language): es un lenguaje de marcado que
define un conjunto de reglas para codificación de documentos en un
formato que es a la vez legible por humanos y máquinas. Se define en la
especificación XML 1.0 producida por el W3C, y en varias otras
especificaciones relacionadas, todas ellas estándares abiertos y gratuitos.
Los objetivos de diseño de XML hacen hincapié en la sencillez, la
generalidad y la usabilidad a través de Internet. Aunque el diseño de XML
se centra en los documentos, es ampliamente utilizado para la
representación de estructuras de datos arbitrarias, por ejemplo en los
servicios web.[35]
XSLT (eXtensible Stylesheet Language Transformation): es un estándar
del W3C que presenta una forma de transformar documentos XML en
otros documentos XML e incluso en otros formatos que no son XML. Las
hojas de estilo XSLT realizan la transformación del documento utilizando
una o varias reglas de plantilla. Estas reglas de plantilla unidas al
documento fuente a transformar alimentan un procesador de XSLT, que
realiza las transformaciones deseadas poniendo el resultado en un archivo
de salida. Actualmente, XSLT es muy usado en la edición web, generando
páginas HTML o XHTML. La unión de XML y XSLT permite separar
contenido y presentación, aumentando así la productividad.[35]