Escaparate Interactivo de Actividades Turísticas

Escaparate Interactivo de Actividades Turísticas Proyecto Fin de Carrera Autor: Diego Nieto Muñoz Tutor: Alexis Quesada Arencibia Cotutor: Enrique Ismael Mendoza Robaina Ingeniería en Informática 17/09/2013 EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 2 Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 3 Proyecto fin de carrera de la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria presentado por el alumno: Diego Nieto Muñoz Título del proyecto: Escaparate interactivo de actividades turísticas Tutores: Alexis Quesada Arencibia Enrique Ismael Mendoza Robaina EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 4 Dedicatoria A mis padres, a mi hermana y a mi novia. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 5 Agradecimientos A mis tutores Alexis y Enrique. A Enrique por colaborar y ayudarme en todo lo que ha podido con el robot y el proyecto. A Alexis por apostar desde el principio por el proyecto, por guiarme en cada fase y por dedicar un gran esfuerzo a que saliera adelante. Sin olvidarme de la gran oportunidad que supuso para mí entrar en el grupo AVORA. Una gran persona. Gracias. A mis compañeros y amigos de clase por todo lo que hemos aprendido juntos, especialmente a los de siempre: Dani, Imanol, Mahy y Marcos. Sin ellos este camino no habría sido tan fácil y divertido. Espero que siempre estemos unidos y haciendo proyectos juntos. A mis colaboradores en el proyecto: José Carlos y Cayetano, quienes también me han orientado y apoyado para que todo saliera mejor. A mis amigos de siempre, a todos, pero especialmente Antonio. Siempre está. A los chicos AVORA. Gracias a todos ellos he aprendido mucho y espero que sigamos haciendo robots juntos. A todos los que están en el IUCTC, como Eduardo. Es muy enriquecedor desarrollar proyectos con todos ellos y en un lugar así. Y como no, a toda mi familia y a mi novia. Gracias por ayudarme y apoyarme en todo momento desde siempre. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 6 Índice 1.- Introducción. ............................................................................................... 18 2.- Estado del Arte. .......................................................................................... 19 2.1.- Sistemas de información oficiales. .............................................................................. 19 2.2.- Sistemas de información de los hoteles. ..................................................................... 20 2.3.- Sistemas de información de terceras empresas. ........................................................ 20 2.3.1.- Tripadvisor ........................................................................................................... 20 2.3.2.- Canarying ............................................................................................................. 21 2.3.3.- Wantudu .............................................................................................................. 22 2.4.- Robótica en el turismo. ............................................................................................... 22 2.4.1.- Guías turísticos. ................................................................................................... 22 3.- Objetivos. ................................................................................................... 25 4.- Metodología y recursos utilizados. ............................................................. 26 4.1.- Metodología de desarrollo. ......................................................................................... 26 4.2.- Recursos utilizados. ..................................................................................................... 27 4.2.1.- Recursos hardware. ............................................................................................. 27 4.2.2.- Recursos software. .............................................................................................. 28 4.2.3.- Tecnologías utilizadas. ......................................................................................... 30 5.- El robot Karotz. .......................................................................................... 37 5.1.- Introducción. ............................................................................................................... 37 5.2.- Análisis del robot. ........................................................................................................ 38 5.2.1.- Características del robot. .................................................................................... 38 5.2.2.- Aplicación Karotz Controller. ............................................................................... 42 5.2.3.- Análisis de la API de trabajo de Karotz. ............................................................... 43 5.3.- Comunicación con el robot. ........................................................................................ 46 5.3.1.- Comunicación por voz. ........................................................................................ 47 5.3.2.- Comunicación y uso de RFID. .............................................................................. 48 5.4.- KarotzVM. .................................................................................................................... 50 6.- Sistema de recomendación. ........................................................................ 51 6.1.- Introducción. ............................................................................................................... 51 6.2.- Técnicas de recomendación. ....................................................................................... 52 6.2.1.- Filtros Colaborativos (CF). ................................................................................... 52 Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 7 6.3.- Sistema de recomendación implementado. ............................................................... 56 6.3.1.- Recolección de datos. .......................................................................................... 56 6.3.2.- Proceso de recomendación. ................................................................................ 58 7.- El servidor. ................................................................................................. 62 7.1.- Especificación de requisitos de usuario. ..................................................................... 62 7.1.1.- Descripción. ......................................................................................................... 62 7.1.2.- Glosario de conceptos. ........................................................................................ 62 7.1.3.- Modelo del dominio. ........................................................................................... 63 7.2.- Especificación de requisitos software. ........................................................................ 64 7.2.1.- Descripción. ......................................................................................................... 64 7.2.2.- Glosario de conceptos. ........................................................................................ 64 7.2.3.- Modelo del diseño. .............................................................................................. 66 7.2.4.- Actores del software. .......................................................................................... 67 7.2.5.- Listados de actores y sus roles. ........................................................................... 68 7.2.6.- Listados de actores y sus objetivos. .................................................................... 69 7.2.7.- Diagramas UML de casos de uso. ........................................................................ 71 7.2.8.- Listado de casos de uso. ...................................................................................... 76 7.2.9.- Diagramas de secuencia. ..................................................................................... 78 7.2.10.- Prototipos de las interfaces de usuario. .......................................................... 82 7.2.11.- Base de datos. ................................................................................................. 91 7.2.12.- Modelo de despliegue. .................................................................................... 96 7.2.13.- Diseño arquitectónico. .................................................................................... 98 7.2.14.- Detalles de la implementación. ..................................................................... 106 8.- Módulo de Karotz como interfaz cliente. ................................................. 131 8.1.- Estructura de las aplicaciones en Karotz. .................................................................. 131 8.1.1.- descriptor.xml. .................................................................................................. 131 8.1.2.- screen.xml. ........................................................................................................ 132 8.1.3.- util.js. ................................................................................................................. 133 8.1.4.- main.js. .............................................................................................................. 133 8.2.- Módulo cliente para Karotz ....................................................................................... 134 8.2.1.- Funciones .......................................................................................................... 135 8.2.2.- Flujo de opciones del módulo cliente. .............................................................. 137 9.- Android. .................................................................................................... 138 9.1.- Introducción. ............................................................................................................. 138 EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 8 9.2.- Estructura de las aplicaciones en Android. ............................................................... 138 9.2.1.- Fundamentos. ................................................................................................... 138 9.2.2.- Componentes de aplicación. ............................................................................. 140 9.3.- Desarrollo del módulo cliente del sistema de recomendación de actividades......... 140 9.3.1.- Introducción. ..................................................................................................... 140 9.3.2.- Prototipos de las interfaces de usuario. ............................................................ 141 9.3.3.- Diseño de la arquitectura. ................................................................................. 142 10.- Resultados y conclusiones. ....................................................................... 145 10.1.- El robot Karotz. Pros y contras. ............................................................................. 145 10.2.- Uso de Zend Framework para el desarrollo del servidor. ..................................... 145 10.3.- Desarrollo de una aplicación con sistema de usuarios. ........................................ 146 10.4.- Sistema de recomendación de actividades. .......................................................... 147 10.5.- Desarrollo de aplicaciones en Android.................................................................. 147 10.6.- Uso de componentes, tecnologías y estrategias. .................................................. 147 10.7.- Resultado final del proyecto. ................................................................................ 148 11.- Trabajo futuro. .......................................................................................... 149 11.1.- Ampliación de los servicios del sistema. ............................................................... 149 11.1.1.- Servicios meteorológicos. ............................................................................. 149 11.1.2.- Servicios de información de vuelos. .............................................................. 149 11.1.3.- Reporte de estadísticas más completo. ........................................................ 149 11.1.4.- Capacidad para realizar reservas de actividades directamente desde la web. 149 11.1.5.- Geoposicionamiento y uso del servicio de rutas de Google Maps. .............. 150 11.1.6.- Interfaz multi-idioma. .................................................................................... 150 11.2.- Búsqueda de alternativas o complementarias a Karotz. ....................................... 150 11.3.- Mejora del sistema de recomendación. ................................................................ 150 11.4.- Desarrollo de una aplicación cliente para iOS. ...................................................... 151 12.- Bibliografía. .............................................................................................. 152 13.- Anexos. ..................................................................................................... 155 Anexo A. Detalle de casos de uso.......................................................................................... 155 Anexo B. Manual de usuario del portal web. ........................................................................ 196 Rol de invitado................................................................................................................... 196 Rol de usuario .................................................................................................................... 201 Rol de usuario registrado .................................................................................................. 207 Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 9 Rol de cliente ..................................................................................................................... 208 Rol de hotel ....................................................................................................................... 215 Rol de hotel administrador ............................................................................................... 222 Rol de empresa .................................................................................................................. 224 Rol de empresa administrador .......................................................................................... 225 Rol de administrador local ................................................................................................ 227 Rol tipo empresa ............................................................................................................... 230 Rol de administrador local ................................................................................................ 235 Anexo C. Instalación y configuración de Karotz. ................................................................... 237 Anexo D. Manual de usuario para Karotz. ............................................................................ 238 Anexo E. Manual de instalación de la aplicación para Android. ........................................... 239 Anexo F. Manual de usuario de la aplicación para Android. ................................................. 242 Inicio de sesión y registro .................................................................................................. 242 Panel principal y pestaña de búsqueda ............................................................................. 243 Pestaña For you ................................................................................................................. 246 Pestaña Favs ...................................................................................................................... 248 Pestaña Hotels ................................................................................................................... 249 Detalle de una actividad .................................................................................................... 254 Localización de una actividad ............................................................................................ 257 EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 16 Imagen 13.64. Crear actividad (abajo) ............................................................... 232 Imagen 13.65. Crear actividad. Mensaje de confirmación ................................. 232 Imagen 13.66. Lista de actividades de un hotel ................................................. 233 Imagen 13.67. Lista de actividades de una empresa .......................................... 233 Imagen 13.68. Modificar una actividad .............................................................. 234 Imagen 13.69. Modificar una actividad. Mensaje de confirmación ................... 234 Imagen 13.70. Eliminar una actividad ................................................................ 235 Imagen 13.71. Menú de usuario de una empresa y un hotel .............................. 235 Imagen 13.72. Actualizar perfil de la compañía ................................................ 236 Imagen 13.73. Actualizar perfil de la compañía. Mensaje de error ................... 236 Imagen 13.74. Actualizar perfil de la compañía. Mensaje de confirmación ...... 236 Imagen 13.75. Encendido de Karotz .................................................................. 238 Imagen 13.76. Iniciar la aplicación en Karotz .................................................... 238 Imagen 13.77. Búsqueda de EIAT en Google Play ............................................ 239 Imagen 13.78. Página de EIAT en Google Play ................................................. 240 Imagen 13.79. Instalación de EIAT en el dispositivo Android .......................... 241 Imagen 13.80. Android. Pantalla de login .......................................................... 242 Imagen 13.81. Android. Pestaña search ............................................................. 243 Imagen 13.82. Android. Menú contextual .......................................................... 244 Imagen 13.83. Android. Cuadros de diálogo ...................................................... 244 Imagen 13.84. Android. Pestaña search. Comienzo ........................................... 245 Imagen 13.85. Android. Pestaña For you ........................................................... 246 Imagen 13.86. Android. Pestaña For you. Top ten activities ............................. 247 Imagen 13.87. Android. Pestaña Favs ................................................................ 248 Imagen 13.88. Android. Pestaña hotels. Búsqueda de hotel .............................. 249 Imagen 13.89. Android. Pestaña Hotels. Lista de hoteles .................................. 250 Imagen 13.90. Android. Mensaje de unión a hotel ............................................ 250 Imagen 13.91. Android. Pestaña Hotels. Menú de hotel .................................... 251 Imagen 13.92. Android. Pestaña hotels. Notificación ........................................ 251 Imagen 13.93. Android. Pestaña hotels. Lista de notificaciones ........................ 252 Imagen 13.94. Android. Mensaje de desunión del hotel .................................... 253 Imagen 13.95. Android. Detalle de actividad (arriba) ........................................ 254 Imagen 13.96. Android. Detalle de actividad (abajo) ........................................ 255 Imagen 13.97. Android. Detalle de actividad. Botón quitar de favoritos .......... 256 Imagen 13.98. Android. Detalle de actividad. Votación .................................... 256 Imagen 13.99. Android. Localización de actividad ............................................ 257 Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 17 EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 18 1.- Introducción. En este proyecto se ha pretendido desarrollar un completo sistema de gestión de actividades turísticas. Para ello se ha investigado cómo los hoteles y las empresas interactúan con los turistas y les muestran su oferta de ocio. Como resultado de esa investigación se propone un sistema de recomendación de actividades a los turistas. Este sistema contiene las actividades de las empresas de ocio y hoteles que se registran. La aplicación ha sido diseñada de forma que los usuarios de los diferentes roles puedan acceder y realizar sus funciones mediante un sistema de autenticación y autorización de usuarios. El sistema utiliza un algoritmo de Collaborative Filtering similar al de Amazon para recomendar las actividades a los usuarios. Estos usuarios pueden acceder a las actividades y recomendaciones del sistema mediante tres vías: un portal web, un cliente para Android y un cliente para el robot Karotz. En la aplicación los hoteles pueden tener usuarios unidos a su hotel para poder enviarles notificaciones y mostrar sus actividades. Todas las compañías, empresas y hoteles, gestionan sus actividades y pueden ver sus estadísticas. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 19 2.- Estado del Arte. A continuación se van a mostrar las diferentes vías de información de actividades que existen la actualidad. Para ello nos centraremos en tres categorías: sistemas de información de actividades oficiales, sistemas de información de hoteles y sistemas de información de terceras empresas. Finalmente se mostrarán algunos ejemplos de robots aplicados en el turismo. 2.1.- Sistemas de información oficiales. En la actualidad los sistemas oficiales de información en Gran Canaria tratan de informar al turismo por dos formas diferentes: vía web y por pequeños documentos o trípticos. En los puntos de información turística de la isla se proporcionan mapas y carteleras de eventos. Estos puntos están distribuidos por toda la capital para facilitar al viajero su disponibilidad y cercanía. La mayoría de los eventos que ofrecen pertenecen a actividades oficiales y no a terceras empresas, como por ejemplo ferias, convenciones y actividades culturales. Por otra parte, sí existe un directorio clasificado de actividades en el portal web del Patronato de Turismo de Gran Canaria. En él se proporciona un listado de empresas con las que se puede contactar para realizar las actividades. Además se ofrecen otro tipo de recursos como mapas y guías para el turista. El sitio está ofrecido en más de ocho idiomas, entre los que se encuentran los más populares para los turistas. Imagen 2.1. Tríptico de actividades oficiales Imagen 2.2. Portal de turismo de Gran Canria EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 20 2.2.- Sistemas de información de los hoteles. Los hoteles de menor categoría, por lo general, continúan ofreciendo sus actividades mediante trípticos o documentos a la llegada al hotel. La información contenida suele ser muy escueta y comprimida para ahorrar costes. Además, es habitual que en la recepción del hotel se mantenga una vitrina para la publicación de estas actividades. Los hoteles de mayor categoría, además de las vías anteriores, tienen incorporado en sus portales web un apartado donde muestran de qué actividades dispone el hotel. En la descripción de esas actividades suele estar detallado tanto los horarios como los precios. Las reservas, como canchas de pádel o tenis, se realizan en el mismo hotel con un tiempo de antelación. 2.3.- Sistemas de información de terceras empresas. Los sistemas de información de terceras empresas son los que más han evolucionado y proliferado recientemente. Las empresas más populares en Gran Canaria y relacionadas con este proyecto se comentan a continuación. 2.3.1.- Tripadvisor La web de viajes más grandes del mundo ya no sólo se dedica a mostrar las opiniones de los usuarios en los hoteles, ahora también tiene un directorio de actividades de los lugares. Los usuarios y negocios pueden crear actividades de los sitios y poner su opinión. Estas actividades son localizadas geográficamente y revisadas por los gestores de Tripadvisor para validar su autenticidad. Las actividades creadas son comentadas y valoradas por los usuarios. Estos además pueden añadir sus fotos referentes a la actividad. Imagen 2.3. Tabla de actividades de un hotel Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 21 Imagen 2.4. Portal de actividades de Tripadvisor 2.3.2.- Canarying Canarying es un nuevo portal web centrado en Gran Canaria que pone a disposición del usuario todo un directorio de actividades. Estas actividades pertenecen a terceras empresas que actúan como proveedores del sistema. Casi todas las actividades son reservables y ofrecen información detallada como la localización, su disponibilidad y una descripción. Imagen 2.5. Portal web de Canarying EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 22 2.3.3.- Wantudu La empresa Wantudu es pionera en Gran Canaria en ofrecer un servicio de actividades de la isla. Es una solución para hoteles con el fin de la fidelización de clientes a través de ofrecerles información de ocio. Sus servicios comprenden la instalación de una pantalla táctil en la recepción del hotel y una aplicación para móvil. La información que proporciona ocupa desde la meteorología en la zona hasta una completa gama de actividades organizadas por temática. Imagen 2.6. Pantalla táctil de la empresa Wantudu Existen otros portales como Gran Canaria Info y La Guía de Gran Canaria que también actúan como un directorio de actividades de la isla. 2.4.- Robótica en el turismo. La robótica en el turismo no está demasiado desarrollada aunque hay algunos ejemplos de desarrollos realizados. La podemos dividir en guías turísticos, que son lo que están en contacto casi permanente con el turista, y los asistentes, que son aquellos que ayudan en tareas más concretas al turista. 2.4.1.- Guías turísticos. Los robots que tienen la función de hacer de guías turísticos mantienen un contacto muy estrecho con el turista. Pueden ser guías en los hoteles, museos y centros comerciales, recepcionista o cualquier otro tipo de función que tenga como objetivo orientar al turista. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 23 Este tipo de robots facilitan la vida del turista ya que guían o dan la información que necesitan en cualquier momento y de forma rápida. Se muestran a continuación algunos ejemplos. RoboX RoboX es un robot móvil interactivo capaz de relacionarse con humanos. Su principal función es servir como asistente turístico en hoteles, museos o ferias, guiando a los visitantes por sus instalaciones y respondiendo a sus preguntas. Es totalmente autónomo y es capaz de hablar en 4 idiomas diferentes. Puede ejercer sus funciones durante 12 horas al día durante los 7 días de la semana. También muestra sus “emociones” mediante iconos en sus ojos y pequeñas animaciones. La gran ventaja de este robot es su capacidad de navegación en lugares con muchas personas como ferias o exhibiciones ya que es capaz de manejar 5000 visitantes al día. Debido a esto, podría servir también para realizar campañas de marketing y publicitar productos. EMIEW 2 Imagen 2.8. Robot EMIEW 2 Imagen 2.7. Robot RoboX EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 24 EMIEW 2 es la nueva versión de EWIEW. Está pensado para trabajar dentro de un ambiente de oficina midiendo 80cm de alto y pesando 14K. Es un robot diseñado para ayudar a las personas en su vida diaria y actuar mediante órdenes de humanos. Algunos de los servicios que aporta son guía, acompañante o ayudante. Las habilidades que posee este robot son:  Gran velocidad y agilidad en sus movimientos  Reconocimiento de objetos  Reconocimiento de voz has en ambientes ruidosos.  Brazo con movilidad humana Interactive Guest Assistants Imagen 2.9. Robots del banco Santander Interactive Guest Assistants Así es como se le conoce a toda una flota de robots que ha comprado el banco Santander a la empresa YDreams. Estos robots son capaces de guiar a los visitantes a la parte deseada del banco. Se controlan por Wi-Fi y son operados por una pantalla táctil de manera que permiten al usuario elegir su idioma o acceder a datos de audio y video de la historia del banco o del grupo Santander. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 25 3.- Objetivos. Actualmente el turismo es uno de los grandes motores de la economía española, y más en las Islas Canarias. Por ello, es importante tener siempre una cara moderna, personalizada y atractiva para nuestros visitantes. El punto final de este proyecto es la creación de un sistema que permita a los usuarios de los hoteles obtener información acerca de actividades y eventos en los propios hoteles y empresas cercanas al hotel. Para ello es fundamental conocer los gustos del cliente y ofrecer en función de los mismos los servicios más adecuados a su perfil. Los medios de difusión serán tres clientes: la plataforma robótica Karotz, a partir de la cual es posible interactuar con ella gracias a su conectividad a internet; un portal web; y una aplicación móvil para dispositivos Android, con la que será posible acceder a los servicios de información de actividades y situarlas en un mapa. Para que todo esto sea posible es necesario abordar los siguientes subobjetivos:  Servidor para alojar, registrar y actualizar toda la información referente a los hoteles, usuarios y empresas. Así como la interfaces que harán de puente entre la base de datos y los dispositivos clientes.  Desarrollo de la interfaz de reconocimiento de voz de los usuarios de forma generalista.  Desarrollo de las aplicaciones tanto en la plataforma robótica Karotz como en la aplicación móvil correspondientes a: o Informar de actividades externas según la categoría seleccionada, en Karotz mediante la interacción oral con el robot. o Indicar actividades, eventos u otras circunstancias que se pudieran dar mediante la visualización o escucha de actividades y notificaciones del hotel.  Mostrar el mapa de actividades en el cliente web y Android.  Desarrollo de una interfaz web para facilitar a las empresas, usuarios y hoteles registrarse y gestionar sus datos. Figura 3.1. Arquitectura de la solución EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 32 PHP tiene incorporados unos puentes que permiten realizar conexiones con diferentes tipos de bases de datos como MySQL, PostgreSQL, Oracle,ODBC, Microsoft SQL Server, Firebird y SQLite. En la siguiente porción de código se encuentra incrustado código PHP en HTML: AJAX AJAX no es en sí un lenguaje de programación sino una técnica de desarrollo web para crear aplicaciones interactivas. Como su propio nombre indica, Asynchronous JavaScript And XML, utiliza el lenguaje de programación JavaScript y la estructuración de datos XML en el lado del cliente para comunicarse de forma asíncrona con el servidor. Esta tecnología permite modificar elementos de la página web sin necesidad de recargarla o ir a otra página. De esta forma es posible incrustar datos recuperados de la B.B.D.D. en un elemento concreto de la página. Su principal ventaja es que evita la necesidad de cargar todo el contenido cuando sólo es necesario refrescar o cargar algunos elementos de la página. Su funcionamiento está basado en peticiones realizadas mediante XMLHttpRequest y procesado y modificado de elementos en la parte del cliente con JavaScript y DOM. CSS Las hojas de estilo en cascada son un lenguaje que permiten describir estilos de un documento (página web) a través de marcas. Esta información puede estar incrustada en el propio HTML o por el contrario separada en ficheros .css. Su sintaxis está basado en uno o más selectores y un bloque de estilos donde se definen los valores de las propiedades del documento. Los selectores pueden ser únicos cuando se trata del id de un elemento o múltiple cuando se habla de una clase de elementos. De acuerdo con su definición no es posible usar selectores en arden ascendente en el DOM. Además no están declaradas reglas de cálculo numérico que permitan especificar valores. Pero en contra partida podemos decir que entre sus ventajas es posible encontrarse con un control centralizado de la presentación de <html> <head> <title>Ejemplo PHP</title> </head> <body> <?php echo '<p>Hola Mundo</p>'; ?> </body> </html> Figura. 4.3. Ejemplo de código en PHP Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 33 los sitios web, de manera que se agiliza de forma considerable la actualización del mismo. Es posible la separación del estilo del contenido, lo que habilita al desarrollador a modificar el contenido El siguiente snippet de código nos muestra un selector con su bloque y las propiedades que modifica: SQL El SQL es un lenguaje de consulta estructurado de acceso a bases de datos relaciones que permite especificar diversos tipos de operaciones entre ellas. Una de sus características es el manejo del álgebra y el cálculo relaciones que permiten efectuar consultas con el fin de recuperar, de forma sencilla, información en bases de datos, así como hacer cambios en ella. En SQL una sola sentencia puede equivaler a uno o más programas que se utilizarían en un lenguaje de bajo nivel orientado a registros. Es posible dividir este lenguaje en:  Lenguaje de definición de datos: El LDD de SQL proporciona comandos para la definición de esquemas de relación, borrado de relaciones y modificaciones de los esquemas de relación.  Lenguaje interactivo de manipulación de datos: El LMD de SQL incluye lenguajes de consultas basado tanto en álgebra relacional como en cálculo relacional de tuplas.  Integridad: El LDD de SQL incluye comandos para especificar las restricciones de integridad que deben cumplir los datos almacenados en la base de datos.  Definición de vistas: El LDD incluye comandos para definir las vistas.  Control de transacciones: SQL tiene comandos para especificar el comienzo y el final de una transacción.  SQL incorporado y dinámico: Esto quiere decir que se pueden incorporar instrucciones de SQL en lenguajes de programación como: C++, C, Java, Cobol, Pascal y Fortran.  Autorización: El LDD incluye comandos para especificar los derechos de acceso a las relaciones y a las vistas. Java Es uno de los lenguajes de programación más potentes y populares actualmente. Fue desarrollado por James Gosling de Sun Microsystems (ahora adquirida por Oracle). Su sintaxis deriva de C y C++ aunque no llega hasta tan bajo nivel. .registerLogin { width: 500px; } Figura. 4.4. Ejemplo de código en CSS EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 34 Las aplicaciones Java se ejecutan en una máquina virtual denominada JVM, de forma que el código se abstrae de la arquitectura que tiene debajo, dejando ese trabajo a la máquina virtual. El lenguaje Java es de propósito general, concurrente, orientado a objetos y basado en clases que fue diseñado para que hubiera las menos dependencias de implementación como fuera posible. Las aplicaciones se compilan a un código llamado bytecode (clases de Java) que son las que posteriormente se ejecutan en las máquinas virtuales. Se puede ver un sencillo código en Java que nos muestre el "Hola Mundo" en un Applet: Java es el lenguaje de programación de aplicaciones para el sistema operativo Android. La manera de desarrollar aplicaciones para este SO es algo diferente a la de implementar aplicaciones estándar de Java, pero más bien supone una extensión del propio Java S.E. De esta forma Android nos provee de toda la potencia de Java aplicada al desarrollo de aplicaciones para este entorno. Android Es un sistema operativo basado en Linux y fue diseñado principalmente para dispositivos móviles con pantalla táctil como los teléfonos inteligente o tabletas. Desde sus inicios Google financió y posteriormente compró la compañía que es el producto principal de la Open Handset Alliance, un conglomerado de fabricantes y desarrolladores de hardware y software y operadores de servicio. La estructura del sistema operativo Android se compone de aplicaciones que se ejecutan en un framework Java de aplicaciones orientadas a objetos sobre el núcleo de las bibliotecas de Java en una máquina virtual Dalvik con compilación en tiempo de ejecución. Las bibliotecas escritas en lenguaje C incluyen un administrador de interfaz gráfica (surface manager), un framework OpenCore, una base de datos relacional SQLite, una Interfaz de programación de API gráfica OpenGL ES 2.0 3D, un motor de renderizado WebKit, un motor gráfico SGL, SSL y una biblioteca estándar de C Bionic. El sistema operativo está compuesto por 12 millones de líneas de código, incluyendo 3 millones de líneas // Hello.java import javax.swing.JApplet; import java.awt.Graphics; public class Hello extends JApplet { public void paint(Graphics g) { g.drawString("Hola, mundo!", 65, 95); } } Figura. 4.5. Ejemplo de código en Java Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 35 de XML, 2,8 millones de líneas de lenguaje C, 2,1 millones de líneas de Java y 1,75 millones de líneas de C++. Android cuenta con las siguientes características:  Diseño adaptado al dispositivo.  Almacenamiento en SQLite.  Conectividad con GSM/EDGE, IDEN, CDMA, EV-DO, UMTS, Bluetooth, Wi-Fi, LTE, HSDPA, HSPA+ y WiMAX.  Navegador web incorporado.  Soporte java para la ejecución de aplicaciones.  Soporte multimedia de los siguientes formatos: WebM, H.263, H.264 (en 3GP o MP4), MPEG-4 SP, AMR, AMR-WB (en un contenedor 3GP), AAC, HE-AAC (en contenedores MP4 o 3GP), MP3, MIDI, Ogg Vorbis, WAV, JPEG, PNG, GIF y BMP.  Soporte para streaming.  Soporte para hardware adicional como cámaras de fotos, pantallas táctiles, acelerómetros, giroscopios, etc.  Entorno de desarrollo con emulador de dispositivos, herramientas para depuración y análisis de rendimiento.  Multi-táctil.  Bluetooth  Multitarea real de aplicaciones.  Características basadas en voz.  Tethering permitiendo utilizar al dispositivo como punto de acceso. JavaScript JavaScript es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico. Se utiliza principalmente en su forma del lado del cliente, implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas aunque existe una forma de JavaScript del lado del servidor. JavaScript se diseñó con una sintaxis similar al 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. Fue desarrollado originalmente por Brendan Eich de Netscape con el nombre de Mocha, el cual fue renombrado posteriormente a LiveScript, para finalmente quedar como JavaScript. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 36 Todos los navegadores modernos interpretan el código JavaScript integrado en las páginas web. Para interactuar con una página web se provee al lenguaje JavaScript de una implementación del Document Object Model (DOM). En el siguiente ejemplo de código se muestra la función recursiva de factorial en JavaScript: JQuery Es una biblioteca de código JavaScript que permite de manera sencilla interactuar con los documentos HTML, manipular su DOM e integrar AJAX. Es un software libre y de código abierto bajo la licencia del MIT y GNU v2. Se utiliza como una potente herramienta que permite a los desarrolladores crear efectos atractivos y dinámicos en las páginas web de una manera rápida y limpia. Cuenta con las siguientes características:  Selección de elementos DOM.  Interactividad y modificaciones del árbol DOM, incluyendo soporte para CSS 1-3 y un plugin básico de XPath.  Eventos.  Manipulación de la hoja de estilos CSS.  Efectos y animaciones.  Animaciones personalizadas.  AJAX.  Soporta extensiones.  Utilidades varias como obtener información del navegador, operar con objetos y vectores, funciones para rutinas comunes, etc.  Compatible con los navegadores Mozilla Firefox 2.0+, Internet Explorer 6+, Safari 3+, Opera 10.6+ y Google Chrome 8+.5 function factorial(n) { if (n === 0) { return 1; } return n * factorial(n - 1); } Figura. 4.6. Ejmplo código Javascript Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 37 5.- El robot Karotz. La fase número dos del proyecto presenta todas las características del robot Karotz, las interfaces de comunicación con los usuarios y su máquina virtual. 5.1.- Introducción. Karotz es un robot de la firma francesa Aldebarán Robotics. Esta compañía fabricante de los robots Nao adquirió recientemente estos pequeños conejitos. El origen de Karotz proviene de la empresa Violet cuando comenzó a desarrollar los Nabaztag (que significa liebre en armenio). Son considerados dispositivos electrónicos de comunicación y presentan un aspecto similar al de un conejo. El propósito final de este sistema es proporcionar al usuario una serie de actividades que le parezcan interesantes de manera eficaz y atractiva. Dentro de estos últimos aspectos entra el robot Karotz. Su introducción en el sistema permite generar un interés mayor en los usuarios. Imagen 5.1. Robot Karotz de frente La implementación del módulo cliente de recomendación de actividades ha sido diseñada para aprovechar las características del robot. En el siguiente apartado se describirá todas las funcionalidades con las que cuenta este dispositivo y cómo se aprovechan para el sistema de recomendación de actividades. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 38 5.2.- Análisis del robot. 5.2.1.- Características del robot. El robot Karotz presenta una forma similar a la de un conejo gracias al par de orejas desmontables con el que viene equipado. Entre sus características y funcionalidades principales nos encontramos las siguientes:  Transmisión de datos por internet.  Comunicación mediante el habla. Estas dos características son claves para el propósito del robot en este sistema. Vista frontal de Karotz Imagen 5.2. Partes frontales del Robot Karotz Orejas Lector RFID Luz LED Webcam ajustable Botón Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 39 Vista trasera de Karotz Imagen 5.3. Partes traseras del robot Karotz Flujo de puesta en marcha de Karotz Karotz para iniciarse siempre debe conectarse al servidor de Aldebaran. A continuación se queda en modo espera hasta que se le inicie alguna de sus aplicaciones (módulo cliente de recomendación de actividades) mediante la API REST, el botón o por RFID. Figura. 5.1. Flujo de puesta en marcha de Karotz Micrófono Altavoz Antena Wi-Fi Control de volumen y encendido Puerto USB 1.1 Puerto mini USB EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 40 Características técnicas: Procesador: ARM9 Processor de 400Mhz. Este procesador está basado en la arquitectura ARMv5TE. Consta de un pipeline de 5 etapas (Fetch/Decode/Execute/Memory/Writeback) y 31 registros de 32 bits. Soporta los conjuntos de instrucciones ARM y Thumb. Memoria:  64MB de memoria RAM.  256MB de memoria Flash Interfaces I/O:  Micrófono integrado  Altavoz integrado  Webcam  Antena Wi-Fi  Lector RFID  1 puerto USB 1.1  1 puerto mini USB Dimensiones:  Altura: 23cm.  Peso: 418g. Compatible con:  Windows  Mac  Linux Motores:  2 servo-motores que hacen girar las orejas.  Rotación de las orejas desmontables en 360 grados Idiomas:  Español  Francés  Inglés  Alemán Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 41 Software: Karotz posee un sistema basado en el Linux con kernel 2.6, uClibC y BusyBox. A esta base se le han añadido librerías de sistema, multimedia, web y otras. Figura. 5.2. Arquitectura de componentes en Karotz Contiene diferentes módulos independientes que se comunican unos con otros a través del sistema de comunicación D-Bus. La conjunción de todos ellos da como resultado el sistema operativo de Karotz. Módulos principales:  El controlador (Controller): es el corazón de Karotz, centraliza todos los datos que el recibe desde fuera hacia el servidor, y supervisa el funcionamiento general del robot.  Karotz to Karotz: es el módulo de comunicación por VOIP entre Karotz.  La agenda (The Scheduler): permite planificar la ejecución de las tareas y las aplicaciones JavaScript en el momento preciso (por ejemplo despertar al usuario a las 7:00). EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 48 Karotz realiza un matching entre el sonido que escucha y la gramática ABNF. El resultado será la frase o “<nomatch>” si no encuentra resultados. Es posible observar un ejemplo de código del reconocedor de voz en el siguiente cuadro: Caracterización del micrófono/ASR Karotz presenta problemas de comprensión como cualquier dispositivo reconocedor del habla. Estos problemas pueden ser debidos a varios factores:  Entorno muy ruidoso. Karotz es capaz de entender al usuario en entornos que no se encuentran totalmente en silencio, pero le resulta mucho más complejo cuando el nivel de decibelios es superior a 30 o 40.  Distancia del usuario a Karotz. Esta distancia no debe ser mayor de 50cm porque si no el micrófono de Karotz no captará bien el sonido.  Corrección en el uso de las palabras. La entonación y corrección del hablante es fundamental para que el robot lo entienda. 5.3.2.- Comunicación y uso de RFID. Otra de las vías interesantes para comunicarse con Karotz es utilizando la tecnología RFID (Radio Frequency IDentification). Con ella es posible identificar objetos ya que funciona como un sistema de almacenamiento y recuperación de datos. Los dispositivos que llevan incorporada esta tecnología guardan unas etiquetas con las que es posible ser identificados. Además no es necesario que se encuentren en visión directa para poder comunicarse. Se pueden dividir en dos tipos de dispositivos, los activos y los pasivos. Las etiquetas pasivas no necesitan alimentación interna mientras que las activas sí. En Karotz nos encontramos los Mini Karotz’s que son etiquetas pasivas de RFID. Se distinguen en flatnanoz y nanoztag: var gramatica = "Hola [Mundo] | adios | Karotz | Conejito"; karotz.asr.string(gramatica, "es", function(asrResult) { var he_oido = asrResult.text; if (he_oido == "<nomatch>") setTimeout(2000, function() { has_dicho() }); else karotz.tts.start("Has dicho : " + he_oido, "es", has_dicho); }); Figura. 5.5. Ejemplo de código en Karotz haciendo ASR Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 49 Imagen 5.5. Conjunto de Flatnanoz Imagen 5.6. Conjunto de Nanoztag Los flatnanoz y nanoztag pueden lanzar las aplicaciones que hayan sido asociadas a Karotz. Para ello es necesario seguir los siguientes pasos: 1. Frotar un Mini Karotz por la parte frontal de Karotz. 2. A continuación el objeto aparecerá disponible en la cuenta de Karotz.com 3. Pulsar sobre unir el objeto a Karotz. 4. Hacer clic sobre la aplicación que se quiere asociar. 5. Seleccionar el dispositivo RFID que se desea unir. Otra posibilidad es utilizar el listener de la API de Karotz. Este método nos proporciona los siguientes atributos del chip RFID:  data.id: El identificador único del chip.  data.direction: 1 si se está leyendo, 2 si se deja de leer.  data.app: No es usado.  data.pict: No es usado.  data.type: es NONE_TYPE, FLAT, NANOZTAG, ZTAMPS EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 50  data.color: es NONE_COL ; RED ; BLUE ; GREEN ; YELLOW ; PINK ; BLACK ; GREY ; ORANGE ; PURPLE ; WHITE ; DARK_RED ; DARK_BLUE ; De esta manera, dentro de una aplicación ya ejecutada en Karotz, es posible utilizar los atributos que proporciona para realizar tareas dentro con chips RFID. En el siguiente cuadro se muestra un ejemplo: 5.4.- KarotzVM. Debido a que Karotz no tiene ni teclado ni pantalla ni módulo de programación, se provee a los desarrolladores de una máquina virtual denominada KarotzVM. Esta máquina está programada en Java y viene empaquetada en un fichero JAR. Con ella es posible testear los programas emulando su ejecución en el robot o ejecutarlos directamente en Karotz utilizando el cable USB o por internet. karotz.rfid.addListener(myrfid); var tag_type, tag_id, tag_color, tag_direction; var myRfid =function(data) { tag_id = data.id; tag_app = data.app; tag_color = data.color; tag_type = data.type; tag_direction = data.direction; } Figura. 5.6. Ejemplo de código en Karotz utilizando RFID Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 51 6.- Sistema de recomendación. 6.1.- Introducción. Probablemente todos hemos pasado por motores de recomendación en sitios de compras online como Amazon. Los sistemas de recomendación son la aplicación de técnicas y metodologías para obtener un producto final personalizado. La mayoría de estos sistemas llevan en su núcleo un algoritmo que puede ser entendido como una instancia particular de Data Mining. El proceso de data mining se divide en tres pasos sucesivos: preprocesado de datos, análisis de datos e interpretación. Figura. 6.1. Esquema de recomendación Se puede definir datos como una colección de objetos y sus atributos, donde un atributo está definido como una propiedad o característica de un objeto. El preprocesado se encarga de filtrar, limpiar y transformar los datos de entrada de manera que a continuación puedan ser clasificados o descritos. Para ello tenemos la medidas de similitud, el muestreado y la reducción de dimensión. La procesado y clasificación es el mapeo entre un espacio de componentes y un espacio de nombres, donde los componentes representan un espacio de EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 52 características de objetos a clasificar y el espacio de nombres representan las clases. La interpretación representa el significado final obtenido del conjunto de datos tras ser procesado, de forma que represente un elemento final, como por ejemplo una recomendación. 6.2.- Técnicas de recomendación. En los sitios de recomendación se realiza un seguimiento de los hábitos de compra de todos sus compradores y cuando se loguean en el sitio se usa esta información para realizar sugerencias de productos. Existen gran cantidad de preferencias que pueden ser almacenadas en diferentes formas. En ocasiones los datos son los productos que el usuario ha comprado junto con opiniones representadas por votos en rango 1-5. Las técnicas de recomendación se dividen en cuatro:  Recomendación colaborativa o filtrado colaborativo (CF): La recomendación colaborativa está basada en la premisa de que si has compartido en el pasado intereses con algún usuario, en el futuro tendrás los mismos gustos. Esta es la principal técnica empleada que abordaremos más adelante. La idea es utilizar lo que dice gente similar a ti para recomendarte elementos. Es la técnica más utilizada para recomendación de productos.  Recomendación basada en contenido (CB): La recomendación basada en contenido trata de aprender de las preferencias del usuario. De acuerdo a ellas, busca aquellos elementos que le son similares a los gustos del usuario. La mayoría de estas técnicas están aplicadas a la recomendación de textos.  Recomendación basada en conocimiento: Se utiliza cuando existe un número demasiado bajo de valoraciones y está basado en casos y restricciones.  Recomendación híbrida: mezcla los tres conceptos anteriores para ofrecer al usuario la mejor experiencia. 6.2.1.- Filtros Colaborativos (CF). Los filtros colaborativos representan la técnica más empleada ya que ofrece rendimiento con buenos resultados. El filtro se establece por los vecinos más próximos (kNN, k nearest-neighbors) Este tipo de técnicas están basadas en la idea de que gente similar a ti a la que le gusto algo hará que a ti te guste. Para Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 53 conocer que le gusta a la gente es necesario que realice votaciones y obtener un conjuntos de datos. Recolección de preferencias Para la recolección de preferencias de los usuarios se puede utilizar una lista de votaciones de productos. Esta lista de votaciones supone la matriz de entrada, la matriz de usuarios-elementos, con la que se trabajará durante todo el proceso de recomendación. Entrada  Conjunto U de usuarios, usuarios clientes por ejemplo.  Conjunto I de ítems, como por ejemplo actividades.  Conjunto totalmente ordenado R de valores para votar, por ejemplo {1,2,3}  Relación funcional r: U x I → R  r(u, x) representa la valoración del usuario u por el item x en la escala R Figura. 6.2. Ejemplo de votaciones de actividades Buscando usuarios similares El siguiente paso consiste en determinar cuánto de similares son los usuarios y sus votaciones. Para ello podemos utilizar varios métodos: Distancia Euclídea Es el método más sencillo y más común. Resulta óptimo cuando las valoraciones se encuentran normalizadas (ej. votaciones de 1-3 estrellas). 𝑠𝑖𝑚 𝑥,𝑦 = (𝑥𝑘−𝑦𝑘)2 𝑛 𝑘=1 Figura. 6.3. Distancia Euclídea donde n es el número de dimensiones (atributos) y xk y yk son el kth atributos (componentes) de los objetos de datos x e y respectivamente. Carlos = {"Ciclismo Canarias" : 3, "Rapel Canarias" : 2, "Buceo Marismas" : 1} María = {"Ciclismo Canarias" : 2, "Rapel Canarias" : 2, "Buceo Marismas" : 3} Juan = {"Ciclismo Canarias" : 1, "Rapel Canarias" : 3, "Buceo Marismas" : 1} Luis = {"Ciclismo Canarias" : 2, "Rapel Canarias" : 2, "Buceo Marismas" : 3} EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 54 Figura. 6.4. Ejemplo de Distancia Euclídea Distancia de Minkowski La distancia Minkowski representa una generalización de la Distancia Euclídea: 𝑠𝑖𝑚 𝑥,𝑦 = ( |𝑥𝑘−𝑦𝑘|𝑟 𝑛 𝑘=1 ) 1 𝑟 Figura. 6.5. Distancia de Minkowski donde r es el grado de la distancia. Dependiendo del valor de r la distancia Minkowski toma diferentes nombres. Para r = 1, Distancia Manhattan, norma L1; para r = 2, Distancia Euclídea; para r = ∞, la Distancia suprema. Distancia de Mahalanobis Se define como: 𝑠𝑖𝑚 𝑥,𝑦 = 𝑥−𝑦 𝜎−1 𝑥−𝑦 𝑇 Figura. 6.6. Distancia de Mahalanobis donde σ es la covarianza de la matriz de datos. Figura. 6.7. Ejemplo de distancia de Mahalanobis Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 55 Distancia basada en el coseno Es un enfoque muy común es considerar los elementos como un plano de vectores de un n-dimensional espacio y calcular su similitud como el coseno del ángulo que ellos forman: 𝑠𝑖𝑚 𝑖 ,𝑗 =𝑖 ∗𝑗 |𝑖| ∗|𝑗| Figura. 6.8. Similitud basada en el coseno donde * indica el producto de vectores y |i| es la normal del vector i. Correlación de Pearson La similitud entre elementos también puede ser dada por su correlación, que mide la relación lineal entre objetos. Aunque varios coeficientes de correlación que pueden ser aplicados, el Coeficiente de Pearson es el más común. 𝑠𝑖𝑚 𝑥,𝑦 = 𝑥𝑘𝑦𝑘 𝑛𝑘=1 − 𝑥𝑘 𝑛𝑘=1 𝑦𝑘 𝑛𝑘=1 𝑛 ( 𝑥2 𝑛𝑘=1 −( 𝑥 𝑛𝑘=1 )2 𝑛)( 𝑦2 𝑛𝑘=1 −( 𝑦 𝑛𝑘=1 )2 𝑛) Figura. 6.9. Correlación de Pearson Figura. 6.10. Ejemplo de Correlación de Pearson Realizando el ranking de los ítems Una vez que se obtiene la similitud con el resto de los usuarios debemos hacer un ranking de los ítems basado en las valoraciones de esos usuarios. Para ello se va a tener en cuenta cual de los ítems es el que obtiene mejor puntuación basado en EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 56 las similitudes con los usuarios. La siguiente función nos da la puntuación para un ítem dado en función de las valoraciones y similitudes de los usuarios: 𝑠𝑐𝑜𝑟𝑒 𝑠,𝑟 = 𝑠𝑖𝑟𝑖 𝑛𝑖=1 𝑠𝑖 𝑛𝑖=1 Figura. 6.11. Puntuación de un ítem basado en similitud donde s y r son la similitud y votación respectivamente del usuario i. Finalmente, para obtener el ítem a recomendar sólo es necesario elegir el de mayor puntuación: 𝑖𝑡𝑒𝑚𝑓𝑖𝑛𝑎𝑙 = max⁡(𝑠𝑐𝑜𝑟𝑒) Figura. 6.12. Ítem a recomendar 6.3.- Sistema de recomendación implementado. El sistema de recomendación implementado es una versión híbrida de CF, CB y basada en conocimiento. De modo que siguiendo el esquema de un sistema de recomendación, inicialmente en el preprocesado se utilizan las técnicas de CB y recomendación basada en conocimiento junto con la determinación de la Distancia Euclídea entre los usuarios, CF. A continuación en el análisis utilizamos la clasificación por los kNN. Y finalmente obtenemos una salida que es la actividad a recomendar. 6.3.1.- Recolección de datos. La recolección de datos del usuario se realiza mediante tres vías diferentes, que se presentan a continuación. Visualizaciones del detalle de actividades Cuando ocurre el evento de que un usuario se sienta atraído por el nombre y/o la descripción de una actividad y desee conocer más datos de la misma hace clic sobre el detalle de la actividad. Esta acción queda registrada de forma que es posible conocer cuantas veces se ha visualizado una actividad en detalle desde su creación. A ese número de visualizaciones se le ha denominado score (s). De forma que el conjunto de scores está formado por: 𝑆𝑐𝑜𝑟𝑒𝑠= 𝑠 𝑠 ∈ 𝑁} Figura. 6.13. Conjunto de puntuaciones Y tenemos tantas Scores como actividades existen registradas en el sistema: Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 57 Actividad Score 𝑨𝒄𝒕𝒊𝒗𝒊𝒅𝒂𝒅𝟏 𝑆𝑐𝑜𝑟𝑒1 ⋮ ⋮ 𝑨𝒄𝒕𝒊𝒗𝒊𝒅𝒂𝒅𝒏 𝑆𝑐𝑜𝑟𝑒𝑛 Tabla 6.1. Ejemplo de scores de actividades Ratings de las actividades En el sistema desarrollado en este proyecto se ha implementado la funcionalidad de que los usuarios puedan votar las actividades. Estas votaciones son las que posteriormente nos permite realizar CF. De forma que el espacio de valoraciones es el siguiente: 𝑅𝑣= 1,2,3 𝑦 𝑅𝑣𝑖= 𝑟𝑣𝑖 𝑟𝑣𝑖 ∈ 𝑅𝑣} Figura. 6.14. Espacio de valoraciones Y para nuestro sistema denominamos esas votaciones rate (r) como la tupla de tres elementos: actividad, usuario y votación: 𝑅𝑎𝑡𝑒= { 𝑎1,𝑢1,𝑅𝑣1 , 𝑎1,𝑢1,𝑅𝑣2 ,…, 𝑎𝑛,𝑢𝑛,𝑅𝑣𝑛 } Figura. 6.15. Conjunto de rate Los usuarios pueden haber votado una actividad o no, por tanto a priori no existen los ratings. De esta forma tenemos como mínimo cero ratings y como máximo 𝑎∗𝑢 ratings, donde a y u representan el número de actividades y usuarios respectivamente. Se puede definir una tabla como la siguiente de ratings: Actividad Usuario Rating 𝑨𝒄𝒕𝒊𝒗𝒊𝒅𝒂𝒅𝒊 𝑈𝑠𝑢𝑎𝑟𝑖𝑜𝑚 𝑅𝑎𝑡𝑖𝑛𝑔𝑎 ⋮ ⋮ ⋮ 𝑨𝒄𝒕𝒊𝒗𝒊𝒅𝒂𝒅𝒋 𝑈𝑠𝑢𝑎𝑟𝑖𝑜𝑛 𝑅𝑎𝑡𝑖𝑛𝑔𝑏 ⋮ ⋮ ⋮ 𝑨𝒄𝒕𝒊𝒗𝒊𝒅𝒂𝒅𝒋 𝑈𝑠𝑢𝑎𝑟𝑖𝑜𝑚 𝑅𝑎𝑡𝑖𝑛𝑔𝑐 Tabla 6.2. Ejemplo de ratings de actividades Preferencias de los usuarios Para culminar la recolección de parámetros se ha realizado una categorización de actividades. Basando las preferencias de los usuarios sobre esas categorías es posible realizar una recomendación más acertada. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 64  Noticia: es un elemento de texto informativo que los hoteles pueden mostrar a los usuarios.  U_Hotel: Es el usuario que pertenece a un hotel y tiene la capacidad de añadir, modificar y borrar actividades y notificaciones de y para su hotel.  U_Empresa: Es el usuario que pertenece a una empresa y tiene la capacidad de añadir, modificar y borrar actividades de y para su empresa. 7.2.- Especificación de requisitos software. 7.2.1.- Descripción. El servidor del sistema almacena y gestiona todos los datos del sistema. El servidor esta subdividido en varias secciones porque ofrece servicios a distintos perfiles: usuarios empresa, usuarios hotel y clientes; además del de administrador del sistema. Los hoteles son el servicio central por el cual se interrelaciona todo. Son registrados mediante un formulario en el sistema y pueden incluir datos como servicios propios y noticias, además pueden añadir otros usuarios que gestionará este administrador. Estos usuarios únicamente podrán realizar las acciones asociadas a este hotel. Además, los hoteles son quienes deciden qué actividades de otras empresas son las que promociona su hotel. Las empresas se registran de manera análoga a los hoteles. Una vez registrados pueden ofertar detalladamente las actividades que tengan y gestionar usuarios que publiquen actividades de esa empresa. Los usuarios clientes que deseen recibir recomendaciones personalizadas y unirse a hoteles también deben registrarse en el sistema. Deben indicar sus preferencias en cuanto a los tipos de actividades. El sistema, en función de sus gustos debe recomendarle actividades y servicios. 7.2.2.- Glosario de conceptos.  Usuario: Es cualquier persona que este registrada en el sistema. Un usuario tiene al menos un identificador, un mail, un nombre, un tipo y una contraseña. De él derivan el resto de los usuarios registrados.  Usuario cliente: Un usuario cliente es aquel que utiliza las aplicaciones clientes (robot, portal web o móvil) para visualizar las actividades o servicios de las empresas y hoteles. El usuario cliente tiene unas preferencias. El usuario cuando se encuentre en un hotel registrado y lo desee puede unirse a ese hotel para recibir sus servicios.  Usuario hotel administrador: Un hotel es una persona registrada en el sistema que representa a un hotel y puede ofrecer actividades y realizar notificaciones a sus huéspedes. El usuario hotel administrador puede tener Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 65 actividades y noticias. Además, este usuario puede registrar otros usuarios hotel, darles privilegios de hotel administrador y ver las estadísticas.  Usuario hotel: Es un usuario que pertenece a un hotel determinado. Puede gestionar las actividades y noticias del hotel.  Usuario empresa administrador: Un usuario empresa es una persona que representa a una empresa y ofrece actividades. La empresa gestiona actividades y visualiza estadísticas. Además, puede administrar los usuarios empresa que pertenecen a ella.  Usuario empresa: Es un usuario que pertenece a una empresa determinada. Puede las gestionar actividades de la empresa.  Usuario administrador: Es aquel que tiene la capacidad de gestionar todos los usuarios del sistema.  Usuario anónimo: todo visitante que visualiza las actividades del sistema. No se registra de él ningún dato relevante.  Actividad o servicio: Una actividad o servicio es toda aquella actividad que tiene una fecha de comienzo, de fin, duración, repetición, precio y otros datos relacionados.  Noticia: Las noticias o notificaciones son textos que los hoteles pueden enviar a sus usuarios.  Categoría: Se entiende como una forma de etiquetar la actividad. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 66 7.2.3.- Modelo del diseño. Figura. 7.2. Modelo de diseño Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 67 7.2.4.- Actores del software. En el sistema habrá varios actores de software. A continuación se muestra un diagrama para facilitar la comprensión de las relaciones y un cuadro para describirlos en detalle. Figura. 7.3. Actores del software Los perfiles efectivos del sistema son: anónimo, cliente, administrador, hotel, hotel administrador, empresa y empresa administrador. Usuario registrado Hotel Empresa Hotel Administrador Empresa Administrador Cliente Tipo Empresa Administrador Anónimo Usuario Administrador local EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 68 7.2.5.- Listados de actores y sus roles. Actor (rol) Tipo Definición Usuario cliente Principal Un usuario cliente es aquel que utiliza las aplicaciones clientes (robot, portal web o móvil) para visualizar las actividades o servicios de las empresas y hoteles. El usuario cliente tiene unas preferencias. El usuario cuando se encuentre en un hotel registrado y lo desee puede unirse a ese hotel para recibir sus servicios. Usuario hotel administrador Principal Es una persona registrada en el sistema que representa a un hotel real, y puede ofrecer actividades, realizar notificaciones a sus huéspedes y ver sus estadísticas. El usuario hotel puede tener actividades y notificaciones. Además, administra a los usuarios hotel de esa compañía. Usuario hotel Secundario Es un usuario que pertenece a un hotel y gestiona las actividades y notificaciones del hotel. Usuario empresa administrador Principal Una empresa es una persona que representa a una empresa. Gestiona actividades, usuarios de la empresa y visualiza las estadísticas. Usuario empresa Secundario Es un usuario que pertenece a una empresa y que gestiona sus actividades. Usuario administrador Principal Es aquel que tiene la capacidad de gestionar todos los usuarios. Usuario anónimo Principal Todo visitante que visualiza las actividades que ofrece el sistema. No se registra de él ningún dato relevante. No obtiene información filtrada por hoteles porque no puede unirse a ellos. Puede registrarse y loguearse. Tabla 7.1. Listado de actores y sus roles Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 69 7.2.6.- Listados de actores y sus objetivos. Actor (rol) Objetivos Resumen de la acción Usuario Ver detalle actividad Muestra en detalle la actividad seleccionada. Ver las top diez actividades Se muestra una lista con las diez primeras actividades con mayor puntuación en visualizaciones Buscar actividades Muestra una lista de las actividades en el sistema de acuerdo a los parámetros introducidos. Usuario registrado Cerrar sesión Cierra la sesión actual del usuario para pasar a ser un usuario anónimo. Visualizar datos Muestra los datos del usuario introducidos en el registro. Modificar datos Guarda las modificaciones realizadas en los datos del usuario. Usuario cliente Ver preferencias Obtiene un listado de las categorías de gustos que has seleccionado. Modificar preferencias Guardas los cambios sobre el listado de preferencias mostrado. Ver actividades favoritas Muestra una lista de las actividades favoritas añadidas anteriormente. Añadir a actividades favoritas Añade una actividad a la lista de favoritas del usuario. Eliminar actividad favorita Elimina la actividad seleccionada de la lista de favoritas del usuario. Ver actividad recomendada Se muestra una actividad recomendada para el usuario basada en sus votaciones y preferencias Ver actividades sugeridas por el hotel Muestra la lista de actividades recomendadas por el hotel al que se está vinculado. Ver notificaciones del hotel Muestra una lista de las notificaciones que ha publicado el hotel al que se está unido. Ver actividades del hotel Muestra una lista de las EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 70 actividades que ofrece el propio hotel. Vincularse a hotel Se vincula a un hotel para poder ver sus actividades sugeridas de otras empresas, las propias y sus notificaciones. Desvincularse del hotel Te desvinculas del hotel anteriormente vinculado. Tipo empresa Añadir actividad Añade una actividad a la lista de actividades del hotel. Ver mis actividades Muestra las actividades del hotel. Borrar actividad Borra la actividad seleccionada de la lista de actividades de la compañía. Modificar actividad Modifica la actividad seleccionada de la lista de actividades de la compañía. Usuario hotel Añadir actividad filtrada Estando en la lista de actividades, el usuario hotel añade una actividad a su lista de actividades filtradas. Añadir notificación El usuario hotel añade una notificación a su lista de notificaciones. Borrar actividad filtrada Borra la actividad seleccionada que se encuentra en la lista de actividades filtradas. Borrar notificación Borra la noticia seleccionada de la lista de noticias. Modificar notificación Guarda los cambios de la noticia seleccionada y visualizada. Ver actividades filtradas Muestra la lista de actividades filtradas por el usuario hotel. Ver notificaciones Muestra el listado de las noticias añadidas anteriormente. Usuario administrador local Ver estadísticas Muestra las estadísticas de la empresa. Ver datos de empresa Visualiza los datos de la empresa Modificar datos de empresa Permite editar los datos de la empresa. Añadir usuario Añade un usuario que pertenecerá a esa tipo empresa. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 71 Eliminar usuario Elimina un usuario que pertenece a esa tipo empresa. Ver usuarios Muestra todos los usuarios que pertenecen a esa tipo empresa. Modificar usuario Modifica los datos del usuario seleccionado que pertenece a la empresa. Usuario hotel administrador (ninguno) (ninguno en especial, sólo lo que hereda) Usuario empresa (ninguno) (ninguno en especial, sólo lo que hereda) Usuario empresa administrador (ninguno) (ninguno en especial, sólo lo que hereda) Usuario administrador Borrar usuario Borra el usuario seleccionado. Añadir usuario Muestra un formulario para añadir un usuario al sistema. Modificar usuario Muestra el detalle del usuario seleccionado para modificarlo. Buscar usuario Muestra una lista de usuarios que coinciden con los parámetros de búsqueda. Usuario anónimo Iniciar sesión En el formulario de identificación se introducen los datos para quedar registrado en el sistema. Registrarse En el formulario de registro permite al usuario anónimo quedar registrado en el sistema. Tabla 7.2. Listados de actores y sus objetivos 7.2.7.- Diagramas UML de casos de uso. Usuario Figura. 7.4. Caso de uso del usuario EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 72 Usuario registrado Figura. 7.5. Caso de uso del usuario registrado Usuario tipo empresa Figura. 7.6. Caso de uso del usuario tipo empresa Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 73 Usuario Hotel Figura. 7.7. Caso de uso del usuario hotel Usuario Administrador Local Figura. 7.8. Caso de uso usuario administrador local EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 80 El usuario visualiza su perfil realizando una petición al controlador y este devolverá sus datos. Después de que el usuario haga las modificaciones pertinentes y pulse sobre modificar datos, el controlador procesará los nuevos datos introducidos en el sistema y si son validos los enviará al modelo para que sean sustituidos en la base de datos. Añadir actividad. Finalmente, la secuencia de añadir actividad resulta análoga a otras secuencias como eliminar actividad y modificar actividad. Figura. 7.14. Diagrama de añadir actividad El usuario tipo empresa envía una petición para registrar una nueva actividad al controlador. Este la genera y el usuario envía el formulario de nuevo al controlador para que se procese. Posteriormente el modelo los almacena. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 81 Unirse a un hotel. Unirse al hotel es una de las tareas que puede realizar un usuario cliente para recibir notificaciones, visualizar las actividades del propio hotel y las que recomienda. El siguiente diagrama de secuencia muestra cómo se produce este proceso de unión. Figura. 7.15. Diagrama de secuencia de unirse a un hotel Para poder unirse al hotel es necesario tener el rol de usuario cliente en el sistema. El usuario cliente debe primeramente buscar por nombre el hotel al que quiere asociarse y controlador generará una consulta de los hoteles que concuerden con EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 82 el nombre introducido. A continuación el controlador recibirá del modelo un listado de los hoteles que le mostrará al usuario de forma paginada. El usuario seleccionará un hotel y se unirá. El controlador procesará la petición e indicará al modelo que almacene esa unión en el sistema. 7.2.10.- Prototipos de las interfaces de usuario. Los prototipos de las interfaces de usuario son unos elementos muy importantes en la ingeniería del software y ayudan a representar el aspecto final que debe tener la aplicación. Interfaz principal de usuario anónimo. Figura. 7.16. Prototipo de interfaz principal del usuario anónimo En la interfaz de se diferencian varios módulos. En la parte superior de la página (1) se encuentra una barra que cobra toda su utilidad cuando el usuario ha iniciado sesión. A continuación (2) se puede distinguir un formulario que actúa como buscador de actividades en el sistema y permite introducir varios parámetros para personalizar aún más las búsquedas. 1 2 3 4 Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 83 Inmediatamente debajo (3) aparecen otros dos módulos, a la izquierda un rotatorio de actividades sugeridas y a la derecha un formulario para registrarse en el sistema. Continuando hacia abajo (4), se distribuyen varias imágenes y textos que definen el propósito, las características y funciones de la aplicación. Interfaz principal de usuario cliente. Figura. 7.17. Prototipo de interfaz principal del usuario cliente La interfaz principal del usuario cliente hereda un módulo que heredarán el resto de interfaces en casi todos los casos, el módulo de búsqueda de actividades. Este módulo estará presente en casi todo momento en la aplicación ya que el objetivo principal es que los clientes tengan siempre a mano las actividades que desean. 1 2 EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 84 En esta interfaz personalizada para el usuario cliente, el módulo uno mostrará una actividad sugerida en función del perfil y las preferencias del cliente. El usuario tendrá visibles las opciones de incluirlo a favorito y votarlo. En el módulo dos se encuentra el detalle de la actividad sugerida, que incluye los horarios, el tipo de actividad y un mapa para localizarla. Figura. 7.18. Prototipo de interfaz del menú de usuario cliente Los botones hotel y mi cuenta son desplegables. El botón hotel, cuando el usuario no está a un hotel, redirige al usuario a una página donde buscar hoteles y poder unirse. Por el contrario, cuando el usuario se encuentra unido a un hotel aparece un desplegable donde puede acceder a las notificaciones, actividades propias y de terceros sugeridas por el hotel. En el desplegable mi cuenta están ubicados los accesos a las preferencias del usuario, el perfil y el cierre de sesión. Interfaz de actividades de usuario empresa. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 85 Figura. 7.19. Prototipo de interfaz de actividades del usuario empresa El cometido principal de una empresa en la aplicación es tener actividades que los usuarios cliente quieran ver. Podemos observar como el usuario empresa podrá visualizar sus actividades (2). Desde esa interfaz es posible modificarlas o borrarlas. Para crear una nueva habrá siempre visible en la barra superior (1) el botón nueva actividad. 1 2 EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 86 Interfaz principal de usuario hotel. Figura. 7.20. Prototipo de interfaz principal del usuario hotel El usuario hotel cuenta con un pequeño panel en su interfaz. Este panel incluye los accesos a las funciones que puede desempeñar en el sistema. Estos accesos corresponden a estadísticas, mensajes, actividades propias y recomendaciones. Las estadísticas se muestran como gráficos a partir de los datos obtenidos de las interacciones de los usuarios clientes con ese hotel. El módulo de mensajes comprende la gestión de mensajería que los usuarios pueden recibir. Para las actividades existe un módulo análogo al que disponen los usuarios empresa en su interfaz. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 87 Y finalmente las recomendaciones presentan una interfaz muy similar al de los anteriores, siendo un listado con opciones de gestión. Interfaz específica de usuario cliente. Listar buscar actividades. Figura. 7.21. Prototipo de interfaz principal del usuario cliente buscando o listando actividades Cuando un usuario (general) busca actividades se muestra una interfaz muy parecida a la anterior. La intención es que el usuario cliente tenga además la opción (1) de indicar que quiere seleccionar una actividad de la lista como favorita o eliminarla de su lista si ya la tuviera. En la lista de actividades se muestra la foto, el título y una porción de la descripción, dejando como opción del visitante ver los datos detallados de una actividad. Esto permite tener una interfaz limpia en la que no se muestren a priori todos los datos y mapas de todas las actividades listadas sino que se muestren dinámicamente a petición del usuario. 1 EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 88 Interfaz específica de usuario hotel. Listar buscar actividades. Figura. 7.22. Prototipo de interfaz para el usuario hotel listando o buscando actividades Las interfaces específicas de los usuarios hotel y empresa cuando listan y buscan actividades son prácticamente iguales a diferencia del botón recomendar. De nuevo, el objetivo principal de este vista es generar una apariencia minimalista con la que el gestor de actividades, ya sea una empresa o un hotel, se sienta cómodo para las funciones que puede desempeñar. El sistema muestra un sencillo listado de actividades con el que el usuario hotel puede interactuar. En caso de que una actividad sea anunciada por el mismo le aparecerán las opciones de modificarla y borrarla. Si por el contrario es una actividad de terceros, podrá recomendarla en su hotel. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 89 Interfaz específica de usuario hotel. Listar notificaciones. Figura. 7.23. Prototipo de interfaz de usuario del usuario hotel listando notificaciones Tras traspasar el panel de usuario hotel y dirigirse al módulo de notificaciones debe aparecer algo similar a la figura anterior. El usuario debe encontrarse cómodo y accesibles los botones. Con el objetivo de cumplir esto la interfaz del módulo de notificaciones debe tener una estructura similar al de actividades y otras gestiones en la aplicación. Como las notificaciones son textos simples, se pueden listar de la misma manera que las actividades, mostrando el título de la notificación y sólo una parte del texto. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 96 7.2.12.- Modelo de despliegue. Cuando el sistema es finalizado ha de ser desplegado en los componentes físicos (hardware) que deben cumplir unos requisitos software. Podemos observar el modelo de despliegue en el siguiente diagrama: Figura. 7.29. Modelo de despliegue Servidor principal Requisitos hardware:  Procesador: 2x Intel® Xeon® E7-4820, 8C, 2.00GHz, 18M Cache, 5.86GT/s, 105W TDP, Turbo, HT, DDR3-980MHz  Memoria: 16GB Memory for 2 CPUs, 1066MHz (4x4GB 2R LV RDIMMs), 2 Memory Risers, 1333MHz DIMMs  Almacenamiento: 4x 1TB, SATA, 2.5-in, 7.2K RPM Hard Drive  Tarjeta controladora RAID: PERC H700 Integrated RAID Controller, 512MB Cache  Conectividad RAID: RAID5 for PERC H200/H700, 4 HDDs  Tarjetas de red: Intel Gigabit ET Dual Port Server Adapter, Cu, PCIe-4 1 M 1 1 Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 97 Requisitos software:  SO: Ubuntu Server  Servidor web: Apache + PHP  Servidor de bases de datos: MySQL  Copias de seguridad: Bacula Servidor de respaldo Requisitos hardware:  Procesador: Intel® Xeon® E3-1220, 4C/4T, 3.10GHz, 8M Cache, 80W TDP, Turbo  Memoria: 4GB Memory (1x4GB), 1600Mhz, Dual Ranked, Low Volt UDIMM  Almacenamiento: 2x 1TB, SATA, 2.5-in, 7.2K RPM Hard Drive  Tarjeta controladora RAID: PERC H200 Integrated RAID Controller  Conectividad RAID: RAID1 for PERC H200/H700, 2 HDDs  Tarjetas de red: Intel® PRO/1000PT GbE Single Port Server Adapter, Cu, PCIe1 Requisitos software:  SO: Ubuntu Server  Copias de seguridad: Bacula Clientes Navegadores (versiones más recientes)  Mozilla Firefox  Safari  Google Chrome  Opera Aplicación para Android Aplicación desarrollada en este proyecto para interactuar con el sistema de forma personalizada. Aplicación para Karotz Aplicación desarrollada en este proyecto para interactuar con el sistema. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 98 7.2.13.- Diseño arquitectónico. Arquitectura de la solución. La arquitectura en su capa más superior es tipo cliente-servidor. Este tipo de arquitecturas están basadas en que en uno de los lados se encuentra un servidor, el cual es único, y uno o varios clientes. Los cliente envían solicitudes de algún tipo de recursos al servidor y este último procesa las solicitudes y responde a los clientes. A continuación se muestra una figura donde se puede observar la arquitectura: Figura. 7.30. Arquitectura de la solución Características propias de esta arquitectura:  El servidor puede dar respuesta a varios clientes a la vez.  Cada cliente puede manejar los datos de un usuario concreto.  El cliente web no depende del SO que se esté ejecutando.  El cliente al ser una especie de interfaz de los datos, cualquier cambio en el servidor o en la base de datos no tendrán mayor repercusión sobre los clientes. En función del tipo de cliente se comunicará con el servidor por una vía u otra, el cliente web accederá a los servicios del servidor mediante un portal web. Los clientes robóticos y Androides realizarán peticiones y recibirán las respuestas a través de una API. Funciones de los clientes:  Mostrar los datos al usuario, como actividades y hoteles.  Enviar datos al servidor como nuevos usuarios, actividades y hoteles.  Procesar los efectos de la interfaz. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 99 Funciones del servidor:  Procesar las peticiones que realizan los clientes.  Validar los formularios.  Realizar los cálculos para el sistema de recomendación  Realizar operaciones CRUD a la base de datos.  Devolver respuestas a los clientes. Arquitectura de la aplicación. Este proyecto está diseñado bajo el patrón modelo-vista-controlador impuesto por el framework utilizado y que en conjunción con la arquitectura clienteservidor de PHP se divide en las siguientes capas: Figura. 7.31. Arquitectura servidor Capa de negocio PHP (ZF) Capa de presentación CSS – Javascript - HTML Capa de acceso a datos PHP (ZF) EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 100 Capa de presentación: Es la capa más superior de este diagrama y representa la interfaz de usuario de la aplicación. Esta interfaz contiene código HTML y JavaScript. El formato de presentación viene dado por las hojas de estilo CSS de la aplicación. La función de esta capa es la de interactuar con el usuario, permitiéndole que se comunique con el sistema en ambos sentidos. Capa de negocio: Esta capa se encarga de gestionar las peticiones del usuario. Se ejecutan los procesos asociados a cada petición y respuesta, y hace de intermediaria entre la capa de presentación y la capa de acceso a datos. En esta parte es donde está toda la lógica de la aplicación. Capa de datos: En la capa más inferior nos encontramos con una zona que es donde se almacenan todos los datos del sistema. Contiene métodos y funciones externas al sistema pero que interactúan con este, concretamente con la capa inmediatamente superior, la capa de negocio. El gestor de base de datos se encarga de encolar las peticiones de datos, procesarlas y dar respuesta al sistema. Zend-Framework y su arquitectura. Introducción a Zend-Framework. Para el desarrollo del sistema se ha utilizado ZendFramework. Es un framework de desarrollo de aplicaciones y servicios web con PHP 5. ZF está implementado totalmente orientado a objetos y la estructura de sus componentes es idónea porque cada componente posee una baja dependencia del resto. De esta manera en función de la aplicación a desarrollar sólo es necesaria una parte de la librería de Zend. Aunque se pueden utilizar de forma individual, los componentes de la biblioteca estándar de Zend Framework conforman un potente y extensible framework de aplicaciones web al combinarse. ZF ofrece un gran rendimiento y una robusta implementación MVC, una abstracción de base de datos fácil de usar, y un componente de formularios que implementa la prestación de formularios HTML, validación y filtrado para que los desarrolladores puedan consolidar todas las operaciones usando de una manera sencilla la interfaz orientada a objetos. Otros componentes, como Zend_Auth y Zend_Acl, proveen autentificación de usuarios y autorización diferentes a las tiendas de certificados comunes. También existen componentes que implementan bibliotecas de cliente para acceder de forma sencilla a los web services más populares. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 101 A continuación se muestra una figura donde se observan los componentes del framework. Estos componentes se pueden agrupar en seguridad, MVC, Internacionalización, Datos, Servicios web y el núcleo: Figura. 7.32. Módulos de Zend Framework EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 102 Arquitectura de Zend Framework. Modelo-vista-controlador. La mayoría de las aplicaciones web se estructuran de la siguiente forma: presentación o vista, lógica de negocio y acceso a datos. El patrón MVC separa estos tres conceptos y establece las relaciones entre ellos. Fue introducido por Trygve Reenskaug en los años 70 aunque no fue hasta hace no mucho cuando se comenzó a conocer de manera popular.  Modelo: Esta es la parte de la aplicación que define la funcionalidad básica de un conjunto de abstracciones de datos. En él se encuentran las rutinas de acceso a datos y alguna lógica del sistema. En función del sistema el modelo puede realizar un mapeo total de los objetos de la base de datos a objetos de php.  Vista: Las vistas definen exactamente lo que se va a presentar al usuario. Normalmente los controladores pasan datos a cada vista para después estas mostrarlas con algún formato. Aquí es donde se encuentra HTML mezclado con PHP en las aplicaciones MVC.  Controlador: El controlador es la parte que une todo el patrón junto. Se encargan de la manipulación de los modelos, de la decisión de la vista que se muestra al usuario en función la petición recibida y pasan a la vista los datos que esta necesita, entre otras tareas. En el interior de los controladores están definidas las acciones para ese controlador. Habitualmente los controladores reflejan objetos de la vida real como pueden ser los usuarios. De esta manera un controlador de usuarios tendrá típicamente acciones como loguearse, salir del sistema, modificar sus datos, etc. Figura. 7.33. Arquitectura modelo-vista-controlador Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 103 Interacción de los componentes de una aplicación bajo el patrón MVC: 1. El usuario interactúa con la interfaz de usuario. 2. El controlador la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback. En el caso de Zend Framework ese gestor de eventos se llama Bootstrap. 3. El controlador accede al modelo, modificándolo de forma adecuada a la acción solicitada por el usuario. Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión. 4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo. El modelo no debe tener conocimiento directo sobre la vista. 5. La interfaz de usuario espera nuevas interacciones del usuario y de nuevo comienza el ciclo. Arquitectura de Zend Framework. Elementos de trabajo.  Bootstrap: La clase Bootstrap es usada para cargar los componentes o recursos comunes que son usado por todos o la mayoría de los controladores, vistas y modelos de la aplicación. Las tareas comunes que ejecuta son conexión con la base de datos, inicio de sesión carga de archivos de configuración y carga de librerías.  Plugins: La arquitectura del controlador incluye un sistema de plugins que pueden ser llamados cuando ocurren eventos durante el proceso de vida de la acción. Estas llamadas se producen antes o después del proceso de ruteo, antes o después del bucle de inicio de la acción, y antes o después de la ejecución de la acción. La aplicación de los plugins habitual está enfocada a librerías como control de acceso de usuarios, navegación en el sistema y configuración del layout.  Helpers: Los helpers o action helpers permite inyectar en el tiempo de ejecución de la acción una funcionalidad bajo demanda dentro de la acción, y de esta forma extender su funcionalidad. Esta funcionalidad permite que varios controladores utilicen funcionalidades comunes entre ellos sin necesidad de extenderlos. Zend Framework ya incluye varios de ellos que son muy útiles en casi todas las aplicaciones web: o Action Stacks: que permite enviar solicitudes al ActionStack del Front Controller. De esta forma durante la propia ejecución de la acción se puede añadir a la cola de lanzamiento nuevos plugins. o Autocomplete: ayuda a ofrecer resultados potenciales de las búsquedas realizadas para que se muestre en el layout como sugerencias. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 104 o ContextSwitch and AjaxContext: facilita el cambio de contexto para ofrecer una respuesta u otra en función del formato de la petición. o FlashMessenger: este helper permite pasar mensajes para la siguiente petición. o JSON: convierte rápidamente a este formato la respuesta elegida. De esta forma se puede combinar con las llamadas AJAX que esperan este tipo de conjunto de datos. o Redirector: es un elemento que cubre la necesidad de realizar redirecciones a dentro de la aplicación o cualquier otra URL. o ViewRenderer: está diseñado para eliminar la necesidad de instanciar vistas con controladores, crear una vista que sea despachada por todos los controladores, mostrar una vista determinada sin ninguna intervención y especificar cualquier parámetro de una vista que vaya a ser mostrada. Arquitectura de Zend Framework. Flujo de ejecución. En la arquitectura de Zend Framework nos encontramos con un elemento que se encarga de gestionar todo el proceso de dispatch, el Front Controller. 1. Se inicia el Bootstrap de la aplicación, que registra cada componente del sistema. 2. El Front Controller toma el mando. En ese instante se entra en un bucle donde se rutea la petición y uno por uno los plugins son llamados. 3. Tras la llamada al plugin se inicia la acción requerida. 4. La acción se ejecuta y lanza cada helper asociado o registrado en la acción. 5. Si existen más plugin por lanzarse se vuelve al punto 3. 6. Se envía la respuesta. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 105 Figura. 7.34. Flujo de ejecución en Zend Framework EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 112 permite que desde el mismo portal de entrada se de acceso a los usuarios con diferentes roles. Para desarrollar un sistema de usuarios seguro se ha seguido las recomendaciones de Zend Framework y se ha utilizado su API manejar las sesiones de usuario. Todo sistema basado en usuarios debe almacenar en algún lugar (B.B.D.D.) los datos cada perfil. En este proyecto se ha creado una tabla con este propósito. Los campos que harán de identidad y credencial de cada usuario serán el correo electrónico y su clave personal. No pueden existir dos correos iguales en el sistema y la clave debe tener una longitud entre 6 y 24 caracteres. Seguridad en el sistema con salting En criptografía, la sal comprende bits aleatorios que son usados como una de las entradas en una función derivadora de claves. La otra entrada es habitualmente una contraseña. La salida de la función derivadora de claves se almacena como la versión cifrada de la contraseña. La sal puede también ser usada como parte de una clave en un cifrado u otro algoritmo criptográfico. La función de derivación de claves generalmente usa una función hash. A veces el vector de inicialización, un valor generado previamente, es usado como sal. Supongamos que la clave secreta de un usuario es robada, y se sabe que usa una de 200.000 palabras inglesas como contraseña. El sistema usa una sal de 32 bits. La clave salada es ahora la contraseña original unida a una sal aleatoria de 32 bits. A causa de esto, los hashes precalculados del atacante carecen de valor. Deberá calcular el hash de cada palabra junto con cada una de las 232 (4,294,967,296) posibles combinaciones de sales hasta que se encuentre una coincidencia. El número total de posibles entradas se puede obtener multiplicando el número de palabras en el diccionario por el número de posibles sales: 232𝑥200000 = 8.58993459𝑥1014 Para completar un ataque por fuerza bruta, el atacante deberá ahora computar cerca de 860 billones de hashes, en lugar de sólo 200.000. Incluso cuando la contraseña en sí misma sea simple, la sal secreta hace que romper la contraseña sea radicalmente más difícil. Otro de los beneficios de este tipo de implementaciones es que es bien conocido que los usuarios en internet re usan sus claves para distintas cuentas y esto puede suponer un problema. Gracias a que el salting varía de una aplicación web a otra, las bases de datos no almacenan la contraseña original del usuario sino que guardan una transformación de ella y de esta manera su contraseña nunca quedará al descubierto. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 113 La implementación concreta en este proyecto contempla la concatenación de un vector de 32 bytes (caracteres generados aleatoriamente) con la contraseña introducida por el usuario. Finalmente el resultado de esa concatenación es resumido por la función hash md5 y almacenado en la base de datos. Asimismo, para poder posteriormente realizar la autenticación de usuarios también se guarda el vector de sal creado para ese usuario específico. En el siguiente gráfico podemos ver como se almacenan las credenciales en la base de datos del sistema: Figura. 7.39. Campos y contenido de los usuarios en la base de datos Los usuarios pueden realizar estas tres acciones:  Registrarse  Loguearse  Salir A continuación se detallará cada uno de los procesos desarrollados en el sistema. Registro de un usuario. Durante el proceso de registro los usuarios deben proporcionar al sistema una dirección de correo electrónico, que debe ser única en la base de datos, y una contraseña. El correo electrónico de cada usuario cumplirá la función de identificador único. Mediante el siguiente diagrama de flujo se explicarán los pasos para que un nuevo usuario quede registrado en la base de datos: EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 114 Figura. 7.40. Proceso de registro El código abreviado correspondiente utilizando la API Zend_Auth de Zend Framework es el siguiente: Figura. 7.41. Código de registro en el sistema for ($i = 0; $i < 32; $i++) $dynamicSalt .= chr(rand(33, 126)); $data = array( 'name' => $registerForm->getValue('name'), 'lastname' => $registerForm->getValue('lastname'), 'email' => $registerForm->getValue('email'), 'password' => md5($registerForm- >getValue('password') . $dynamicSalt), 'passwordSalt' => $dynamicSalt, ); $users = new Application_Model_DbTable_User(); $users->insert($data); $finalPass $dynamicSalt El usuario introduce sus datos de registro La aplicación genera un nuevo salt de 32 caracteres for ($i = 0; $i < 32; $i++) $dynamicSalt .= chr(rand(33, 126)); $mail = “[email protected]”; $pass = “password”; Se concatena el password del usuario con la sal $concatPass = $pass . $dynamicSalt; Se realiza el resumen de la ristra con la función md5() $finalPass = md5($concatPass); Se almacena en la base de datos tanto la password derivada como la ristra de sal para posteriormente poder hacer el loguin. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 115 Loguearse Para el proceso de login se realizan una serie de pasos similares a los del proceso de registro. Esta acción del sistema debe comparar que los datos que el usuario está proporcionando son equivalentes a uno de los datos que pertenecen a un usuario registrado. El sistema busca una coincidencia con la identidad del usuario, la dirección de correo electrónico, y si es así realiza los cálculos necesarios para comprobar si las credenciales son equivalentes. Figura. 7.42. Proceso de login en el sistema El usuario introduce su correo electrónico y contraseña La aplicación hace una búsqueda en la base de datos de la identidad del usuario (su mail) con los datos introducidos $mail = “[email protected]”; $pass = “password”; Si la identidad coincide se trae de la base de datos el salt para ese usuario $passwordSalt = db.passwordSalt; $mail = db.mail Se concatena la password introducida por el usuario con la salt recuperada del usuario con la misma identidad. $finalPass = md5($concatPass); Se realiza el hash del password $concatPass = $pass · $passwordSalt; Se comprueba que ambas credenciales son iguales para dejar al usuario como autenticado en el sistema $finalPass = db.password Se crea una sesión SI NO SI NO EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 116 El código correspondiente al login utilizando Zend_Auth es el siguiente: Figura. 7.43. Código de login en el sistema Salir Cuando se realiza un logout de la aplicación el sistema lo que hace es borrar la sesión que se había creado. El código correspondiente al login utilizando Zend_Auth es el siguiente: Figura. 7.44. Código de logout Desarrollo de un sistema autorización de usuarios utilizando ACL de Zend Framework. Las listas de control de acceso o en inglés ACL permiten a un sistema crear una separación de privilegios. Estas listas permiten determinar que permisos de acceso tiene un objeto a un recurso. De esta manera no todos los objetos tienen los mismos privilegios ni pueden acceder a los mismos recursos. Este concepto es ampliamente utilizado en aplicaciones web, como es el caso para este proyecto. $auth = Zend_Auth::getInstance(); $auth->clearIdentity(); $auth->getStorage()->clear(); $this->_redirect('/'); $adapter = new Zend_Auth_Adapter_DbTable( null, 'user', 'email', 'password', 'MD5(CONCAT(?, passwordSalt))' ); $adapter->setIdentity($loginForm->getValue('email')); $adapter->setCredential($loginForm->getValue('password')); $auth = Zend_Auth::getInstance(); $result = $auth->authenticate($adapter); if ($result->isValid()) { // Login success $this->_redirect('/'); } Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 117 Zend Framwork tiene una librería denominada Zend_Acl que provee al desarrollador de un conjunto de elementos muy útiles para manejar listas de control de acceso. Se definen los dos siguiente elementos:  Recursos: Los recursos son aquellos objetos u elementos a los que los usuarios desean acceder, ej. “ver usuarios”.  Roles: Que son los perfiles que pueden tener cada uno de los usuarios, ej. “administrador”. En la aplicación web del proyecto existen una gran cantidad de recursos, tantos como la suma de acciones de todos los controladores, pero no es necesario definir todos. Es posible crear reglas de herencia a partir de los controladores. Figura. 7.45. Esquema de recursos del sistema Definiendo los recursos en Zend Framework: Figura. 7.46. Código de algunos recursos de la aplicación A continuación hay que definir en el sistema son los roles, de nuevo podemos aplicar herencia: Recursos index activities categories companies hotels users $this->_acl ->addResource('index') ->addResource('activities') ->addResource('categories') ->addResource('companies') ->addResource('hotels') ->addResource('users') ->addResource('error'); EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 118 Figura. 7.47. Esquema de roles en Zend Framework El código en PHP abreviado correspondiente es: Figura. 7.48. Código definiendo los roles en Zend Framework Finalmente se aplican la configuración acceso de los roles a los recursos. En este paso final se van definiendo reglas que indican los privilegios de cada rol. Roles user guest userRegistered client tCompany hotel company admin $this->_acl ->addRole('user') ->addRole('guest', 'user') ->addRole('userRegistered', 'user') ->addRole('client', 'userRegistered') ->addRole('tCompany', 'userRegistered') ->addRole('admin', 'userRegistered') ->addRole('hotel', 'tCompany') ->addRole('company', 'tCompany') ->addRole('localAdmin'); $parentsHotelAdmin = array('hotel', 'localAdmin'); $parentsCompanyAdmin = array('company', 'localAdmin'); $this->_acl->addRole(new Zend_Acl_Role('hotelAdmin'), $parentsHotelAdmin) ->addRole(new Zend_Acl_Role('companyAdmin'), $parentsCompanyAdmin); Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 119 Figura. 7.49. Código dando los permisos en Zend Framework Gracias a este control de listas de acceso la barra de navegación que utiliza la API de Zend Framework (Zend_Navigation) es capaz de determinar qué elementos debe mostrar en función del rol que esta autenticado. Conclusiones Zend_Auth y Zend_Acl Con la combinación de estos dos elementos que nos ofrece el framework es posible desarrollar un módulo de autenticación y autorización en el sistema. El módulo de autorización se comunica con el módulo de autenticación para comprobar la existencia de una identidad conocida en el sistema, y si es así obtener el rango (rol) al que pertenece. El potencial de estas herramientas permiten desarrollar aplicaciones web para usuarios con diferentes roles de una manera potente, limpia y segura. Integración de Google Maps Google Maps es un servicio gratuito de Google. Constituye un servidor de aplicaciones de mapas en la web y ofrece imágenes de mapas en los que se puede navegar en altura, inclinación, latitud y longitud. Es posible visualizar los mapas dos tipos de mapa principalmente ya que el resto derivan de ellos:  Roadmap: que dibuja las regiones y vías.  Satellite: que muestra fotografías satélite de las localizaciones. Además, las últimas versiones de estos mapas incluyen construcciones en tres dimensiones y el conocido como streetview, que es un entorno virtual en tres dimensiones creado a partir de fotografías reales de las vías de las ciudades. La API de Google Maps permite a las aplicaciones web integrar los mapas de Google. Cuenta con una gran biblioteca de métodos para modificar el mapa con $this->_acl ->allow('guest', 'auth', 'login') ->allow('guest', 'index', 'index') ->allow('userRegistered', 'auth', 'logout') ->allow('userRegistered', 'logout') ->allow('userRegistered', 'userResources') ->allow('client', 'clientResources') ->allow('tCompany', 'tCompanyResources'); Imagen 7.1. Captura Google Maps IUCTC EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 120 una gran cantidad de elementos diferentes. En este proyecto las necesidades son las siguientes:  Mostrar un mapa: Permite la visualización de un mapa tanto a la compañía que registra actividades como al cliente que las visualiza.  Localizar un punto a través de una dirección: Facilita la obtención del punto exacto de una actividad a partir de la dirección que indica una compañía.  Obtener las coordenadas de un punto: Permite almacenar en la base de datos del sistema la localización exacta de una actividad.  Localizar un punto a través de unas coordenadas: Indica al mapa la localización exacta de una actividad con tan sólo dos números, evitando almacenar direcciones.  Crear un marcador para un punto determinado: Ayuda a que el cliente tenga una clara percepción del lugar de la actividad. Para cubrir estas necesidades se ha empleado Google Maps Javascript API V3 con licencia gratuita que cuenta con las funciones que se muestran en la siguiente tabla comparativa: Funciones API de Google Maps API de Google Maps for Business Street View Servicio web de codificación geográfica 2.500 solicitudes diarias 100.000 solicitudes diarias Servicio web de rutas 2.500 solicitudes diarias con 10 hitos por solicitud 100.000 solicitudes diarias con 23 hitos por solicitud Servicio web de matriz de distancia 100 elementos por consulta 100 elementos cada 10 segundos 2.500 elementos diarios 625 elementos por consulta 1.000 elementos cada 10 segundos 100.000 elementos diarios Servicio web de elevación 2.500 solicitudes diarias con 25.000 muestras diarias 100.000 solicitudes diarias con 1.000.000 muestras diarias Resolución máxima del API de Google Static Maps 640 x 640 2.048 x 2.048 Escala máxima del API de Google Static Maps 2X 4X Resolución máxima 640 x 640 2.048 x 2.048 Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 121 del API de imágenes de Street View Tabla 7.5. Funciones de Google Maps Como se puede observar en la tabla superior la versión Business ofrece mayor respuesta a la demanda de peticiones y resolución pero esto no es algo necesario inicialmente para este proyecto. La siguiente tabla de métodos de la API Javascript V3 de Google Maps han sido utilizados durante el desarrollo de la aplicación. Método Descripción Map(mapDiv:Node, opts?:MapOptions) Crea un nuevo mapa dentro del contenedor HTML, que normalmente es un elemento DIV. setCenter(latlng:LatL ng) Centra el mapa en unas coordenadas dadas por el conjunto latitud-longitud. setZoom(zoom:number) Indica al mapa el zoom que debe aplicar. setMapTypeId(mapTypeI d:MapTypeId|string) Elige tipo de mapa que debe mostrarse (terrain, hybrid, roadmap o satellite). geocode(request:Geoco derRequest, callback:function(Arr ay.<GeocoderResult>, GeocoderStatus)) Busca una localización a partir de una dirección pudiendo indicar los límites en coordenadas entre los que buscar, unas coordenadas como punto central de la búsqueda y una región que acote la búsqueda. Devuelve todos los resultados obtenidos para esa dirección incluyendo las coordenadas exactas de cada uno. Marker(opts?:MarkerOp tions) Crea un nuevo marcador con las opciones especificadas. Es posible indicarle una gran cantidad de opciones pero las más básicas son map, que indica en que mapa se inserta el marcador; y position, que es indicada en coordenadas x e y posicionando el marcador en el mapa. Tabla 7.6. Métodos de Google Maps empleados Control contra CSRF El CSRF significa en inglés Cross-site request forgery, es decir, falsicación de petición en sitios cruzados. Se puede concebir como un tipo de exploit malicioso de un sitio web que acepta comandos no autorizados de un usuario en el que no confía. Este tipo de ataque utiliza la vulnerabilidad de una aplicación web realizándole una petición que hace una acción como si fuera un usuario autorizado. De esta manera es posible que alguien que no se encuentre ni tan siquiera en la web pueda provocar acciones en las que no debería tener acceso. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 128 Figura. 7.57. Código para testear el proceso de login con PHPUnit class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase { public function setUp() { $this->bootstrap = array($this, 'appBootstrap'); parent::setUp(); } public function appBootstrap() { $this->frontController ->registerPlugin(new Bugapp_Plugin_Initialize('development')); } public function testCallWithoutActionShouldPullFromIndexAction() { $this->dispatch('/users'); $this->assertController('users'); $this->assertAction('index'); } public function testIndexActionShouldContainLoginForm() { $this->dispatch('/users/login'); $this->assertAction('index'); $this->assertQueryCount('form#loginForm', 1); } public function testValidLoginShouldGoToProfilePage() { $this->request->setMethod('POST') ->setPost(array( 'username' => 'diego', 'password' => 'pruebas' )); $this->dispatch('/users/login'); $this->assertRedirectTo('/'); $this->resetRequest() ->resetResponse(); $this->request->setMethod('GET') ->setPost(array()); $this->dispatch('/'); $this->assertRoute('default'); $this->assertModule('default'); $this->assertController('index'); $this->assertAction('index'); $this->assertNotRedirect(); } } Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 129 Implementación de estadísticas y uso Google Charts para su visualización. Implementación Para la implementación de estadísticas se han utilizado los siguientes parámetros:  Número de veces que se muestra una actividad  Media de las valoraciones de una actividad  Registro temporal de las visualizaciones de las actividades  Registro temporal de las uniones a los hoteles (sólo en hoteles) Su implementación se ha llevado a cabo totalmente bajo peticiones AJAX integrando las respuestas con la API de Google. Integración con Google Charts Google Charts es una API de Google gratuita con una gran cantidad métodos y tipos de gráficas con las que poder trabajar. En este proyecto para ofrecer las estadísticas a las compañías se han utilizado los siguientes tipos de gráficas:  Pie chart (1)  Table (2)  Line chart (3)  Column chart (4) Imagen 7.2. Captura de pantalla de estadísticas de un hotel 1 2 2 3 EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 130 Imagen 7.3. Captura de pantalla de estadísticas de una actividad Las posibilidades para trabajar con los gráficos de Google son amplísimas. Para este proyecto se han utilizado los siguientes métodos: Método Descripción google.load("visualization", "1", {packages:["corechart"]}); Carga la librería para el tipo de gráficos "corechart" google.setOnLoadCallback(drawA ctivitiesDistributionChart); Ejecuta el callback cuando se carga la página new google.visualization.DataTable (); Crea un nuevo objeto Datatable para poder trabajar con los datos <Table>.addRows(<number>); Crea <number> filas vacías en la tabla seleccionada <Table>.addColumn(<type>,<elem ent>); Añade una columna a la tabla del tipo <type> con el elemento <element> <Table>.setValue(<row>, <column>, <value>); Añade el valor <value> en la fila y columna <row> <column> respectivamente new google.visualization.<charttyp e>(document.getElementById('<b odyelement>')); Crea un nuevo objeto gráfico del tipo indicado en el nodo DOM que se le proporciona <Chart>.draw(<Table>); Dibuja el gráfico con los datos del objeto tabla proporcionados Tabla 7.9. Métodos de Google Charts utilizados 3 4 Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 131 8.- Módulo de Karotz como interfaz cliente. 8.1.- Estructura de las aplicaciones en Karotz. Las aplicaciones para Karotz son desarrolladas en el lenguaje JavaScript Todas las aplicaciones de Karotz siguen la misma estructura, que consiste en un paquete que contiene al menos cuatro ficheros:  descriptor.xml  screen.xml  util.js  main.js A ellos, pueden añadirse otros como 'tinyxmldom.js' para trabajar con objetos en xml o cualquier librería necesaria en JavaScript para la aplicación. A continuación se describen los ficheros básicos de una aplicación para Karotz: 8.1.1.- descriptor.xml. Este fichero contiene la información necesaria para la publicación y la correcta funcionalidad de la aplicación. En él se define desde el tipo de aplicación hasta los accesos funcionales que puede realizar. Al ser un fichero xml todas sus propiedades se definen por tags: <name> : Nombre de la aplicación <version> : Versión de la aplicación. <access> : Acceso funcional permitido de la aplicación. Estos son los elementos más importantes ya que amplían o limitan la funcionalidad de nuestra aplicación. Los accesos funcionales definidos para Karotz son:  led : Debe estar definido si la aplicación utiliza los métodos led.  ears : Debe estar definido si la aplicación hace que las orejas se muevan.  button : Debe estar definido si se desea que la aplicación utilice el botón.  tts : Debe estar definido si la aplicación debe transformar texto a voz.  webcam : Debe estar definido si la aplicación usa la cámara web.  asr : Debe estar definido si la aplicación si la aplicación debe reconocer voz  rfid : Debe estar definido si la aplicación si la aplicación utiliza los nanoztag u otros elementos rfid  http : Debe estar definido si la aplicación accede a internet, por ejemplo para un servicio web.  file : Debe estar definido si la aplicación va a realizar lecturas o escrituras en ficheros.  serial : Debe estar definido si la aplicación utiliza métodos serial EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 132 <editor> (Opcional) : Nombre del publicador. <asrName> (Opcional) : Comando de voz de lanzamiento <deployment> (Opcional) : Para aplicaciones tipo hosted, es decir, embebidas en el robot y realizadas en javascript; o external si la aplicación funcional mediante la API Rest. <multiConf> (Opcional) : Permite que la aplicación utilice o no varios perfiles y configuraciones, true/false. <callback> (Opcional) : La URL de callback utilizada para aplicaciones basadas en la API Rest. Un ejemplo de descriptor es el siguiente: 8.1. Ejemplo de descriptor de fichero de Karotz 8.1.2.- screen.xml. El fichero screen.xml en las aplicaciones de Karotz representa el panel de control y configuración de la aplicación. Para este panel se pueden definir los siguientes elementos:  nanoTrigger: Muestra el panel que gestiona el lanzamiento de la aplicación mediante un nano.  permanentTrigger: Muestra el panel que permite mantener un listener constante para lanzar la aplicación.  scheduledTrigger: Muestra el panel que permite lanzar la aplicación a una hora determinada.  scheduledDateTrigger: Muestra el panel que permite lanzar la aplicación a una fecha y hora determinada  voiceTrigger: Muestra el panel que permite modificar el comando de voz que lanza la aplicación. <descriptor> <name>My first app</name> <version>1.0.0</version> <accesses> <access>http</access> <access>tts</access> <access>ears</access> <access>button</access> <access>led</access> <access>asr</access> <access>multimedia</access> </accesses> <multiConf>false</multiConf> <asrName>top start</asrName> </descriptor> Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 133 Además es posible definir paneles propios utilizando los siguientes elementos:  Text fields  Listas desplegables  Botones Esto permite que el usuario que instale la aplicación desarrollada pueda modificar opciones de la misma desde el panel de la cuenta de usuario. La configuración por defecto que se genera en la aplicaciones Karotz es la siguiente: Figura. 8.2. Descriptor de los paneles de configuración de la aplicación para Karotz 8.1.3.- util.js. Este fichero contiene el código necesario para conectar la aplicación a Karotz Figura. 8.3. Fichero de conexión a Karotz 8.1.4.- main.js. El fichero main.js contiene el código usado en la aplicación. Veamos un ejemplo: karotz.connectAndStart = function(host, port, callback, data){ try{ karotz.connect(host, port); log("connected"); karotz.start(callback, data); }catch(err){ log(err); } }; <screen nanoTrigger="true" permanentTrigger="true" scheduledTrigger="true" scheduledDateTrigger="false" voiceTrigger="true"> </screen> EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 134 Figura. 8.4. Ejemplo de código principal para Karotz 8.2.- Módulo cliente para Karotz La interfaz robótica de Karotz hace que sea demasiado complejo realizar el inicio de sesión de un usuario concreto en EIAT ya que sus elementos RFID son finitos y no programables. Además sus mecanismos de reconocimiento de voz impiden que reconozca una cadena de caracteres que no tenía en su biblioteca a priori, como un nombre de usuario o contraseña. Por estos motivos el módulo desarrollado utiliza el rol guest con el que interactúa de dos formas diferentes: obteniendo las diez primeras actividades y obteniendo una recomendación de una actividad no basada en el usuario. La aplicación desarrollada para Karotz se ha modularizado en varias funciones que se encargan de realizar todas las tareas necesarias para el correcto funcionamiento de la aplicación. Esta relación de funciones se resume a continuación. include("util.js"); var karotz_ip="localhost" var buttonListener = function(event) { if (event == "DOUBLE") { karotz.tts.stop(); exit(); } return true; } var exitFunction = function(event) { if((event == "CANCELLED") || (event == "TERMINATED")) { exit(); } return true; } var onKarotzConnect = function(data) { karotz.button.addListener(buttonListener); karotz.tts.start("Hello World ! My name is Karotz !", "en", exitFunction); } karotz.connectAndStart(karotz_ip, 9123, onKarotzConnect, {}); Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 135 8.2.1.- Funciones A continuación se detallan las principales funciones desarrolladas para el módulo cliente de Karotz. getShowmoreFromServer Obtiene los parámetros detallados de una actividad. Seguidamente los combina con frases para generar un texto que el usuario anónimo pueda entender como el detalle de una actividad. getShowmore Comunica al usuario el detalle de la actividad seleccionada y tras ello, ofrece un menú donde volver a repetir el detalle de la actividad o volver al menú principal. detectActivity Esta función se encarga de reconocer la actividad seleccionada dentro de la lista ofrecida. getActivitiesGrammar Su función es generar una gramática válida para que el sistema ASR de Karotz pueda reconocer la actividad elegida. getToptenFromServer Se conecta al servicio web EIAT y obtiene las diez actividades más populares del sistema de recomendación. getTopten Interactúa con el usuario y le comunica las diez actividades más populares de la aplicación. getCategoriesGrammar Genera la gramática válida para que sistema ASR de Karotz detecte la categoría elegida por el usuario. getCategoriesFromServer Obtiene la lista de categorías del servidor EIAT. selectDayToRecommendation Se comunica con el usuario para seleccionar el día a realizar la actividad y realizar la petición para la recomendación. detectCategory Detecta la categoría seleccionada por el usuario y obtiene su ID para obtener la recomendación. getRecommendation EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 136 Función que se comunica con el usuario para indicarle las categorías disponibles en EIAT y continuar así con el proceso de recomendación. main Punto de entrada principal de la aplicación que se comunica con el usuario para conocer si se desea obtener una recomendación o conocer las diez actividades más populares. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 137 8.2.2.- Flujo de opciones del módulo cliente. Recomendación o actividades populares Inicio Se le comunica al usuario las diez actividades más populares Se solicita que el usuario elija una Se le ofrece al usuario todos los detalles de la actividad Se le comunica al usuario las categorías de EIAT Se solicita al usuario que elija una de ellas Se solicita al usuario que elija un día entre el día actual y el día siguiente Se genera la recomendación Actividades populares Recomendación Se le pregunta al usuario si desea que se le repitan los detalles o prefiere volver al inicio Figura. 8.5. Flujo de opciones en la aplicación para Karotz EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 144 o TextView o EditText o ListView o Tabs o ImageView  Listeners: Son métodos que escuchan las interacciones con el elemento de la interfaz y son disparados cuando ocurre el evento adecuado, como por ejemplo el clic de un botón.  Asynctasks: Las tareas asíncronas permiten dividir la aplicación en varios hilos de forma que el usuario no experimente lags. En background se va ejecutando la tarea asíncrona mientras que la interfaz sigue estando activa. Este es uno de los elementos más útiles porque permite que no se bloquee la aplicación mientras se cargan datos y son posteriormente lanzados a la interfaz.  SQLite: Es el almacenamiento nativo de Android. Se gestiona de manera similar a una base de datos convencional y permite almacenar en el dispositivo móvil datos de forma permanente. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 145 10.- Resultados y conclusiones. 10.1.- El robot Karotz. Pros y contras. El robot Karotz tiene grandes ventajas pero también inconvenientes. Este robot de bajo coste tiene una gran variedad de funcionalidades que se han comentado a lo largo de la memoria de este proyecto pero en la conclusión es necesario dejar patente las limitaciones que también tiene. Uno de los grandes inconvenientes del robot es la necesidad de estar continuamente conectado a internet para poder estar en funcionamiento. Esta necesidad no guarda relación con que la aplicación que se vaya a ejecutar necesite conexión a internet o no, Karotz siempre la necesita. Por supuesto el gran punto fuerte del robot es el reconocedor de voz, este elemento permite que el sistema cobre vida y la interacción sea más natural. El reconocedor de voz de Karotz no permite reconocer cadenas que previamente no se le hayan comunicado que va a recibir, esto es, si en la gramática ABNF definida no consta una de las palabras que el robot va a escuchar, la frase no se reconocerá. Por este motivo no es posible realizar tareas como el inicio de sesión en la aplicación y la flexibilidad se reduce. Aunque también es cierto que funciona en entornos algo ruidosos y procesa de forma rápida. Por otra parte, la documentación para desarrollo de aplicaciones en Karotz no está muy avanzada y no parece que vaya a ir a más de momento. Sin embargo Karotz, teniendo en mente el coste del robot resulta toda una joya. Ha sido posible que mediante comandos de voz el robot interactúe con el servidor de EIAT y con el usuario de forma transparente, algo que supone un objetivo alcanzado para este proyecto enfocado a las tecnologías en el turismo. 10.2.- Uso de Zend Framework para el desarrollo del servidor. Una de las primeras cuestiones que uno se plantea cuando quiere desarrollar un sistema como el de este proyecto es por donde empezar. Siguiendo todas las fases de la Ingeniería del Software llega la hora de decidir cómo implementar la aplicación. Teniendo en cuenta todos los componentes utilizados y la extensión de la aplicación se hizo necesario basarse en una estructura que pudiera ayudar a establecer cada objeto en su sitio y utilizara un flujo de peticiones y respuestas a la aplicación coherentes y no repetitivas. En principio se barajó entre dos alternativas: Zend Framework y Symfony. Symfony por ser un framework del que tenía nociones básicas y Zend Framework porque como bien me recomendó mi tutor Alexis es considerado de los mejores (si no el mejor). EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 146 Finalmente el sistema ha sido íntegramente desarrollado bajo la arquitectura de las aplicaciones en Zend Framework v1.12. Este framework tiene una curva de aprendizaje bastante alta pero con el tiempo resulta beneficioso. Una vez que se va conociendo cómo es el flujo de ejecución y el manejo de todos sus componentes, sería posible desarrollar aplicaciones en muy poco tiempo haciendo uso de toda la potencia de su arquitectura y librerías. Gracias a todos sus componentes ha sido posible tener elementos tan importantes como un sistema de autorización, un sistema de control de listas de acceso (ACL), validación de formularios, interacción coherente y mapeada con la base de datos, paginación, sencillo manejo con respuestas JSON, control de peticiónes y respuestas AJAX, etc. Sin duda, y no menos importante, el trabajar con el patrón modelo-vistacontrolador permite abstraerse e implementar componentes reutilizables. Otro punto importante a tener en cuenta es que Zend Framework trabaja cien por cien con objetos, lo cual me ha permitido continuar el rodaje y aprendizaje continuo con esta filosofía, que es utilizada de forma profesional. Por todo ello el uso de un framework y en concreto Zend Framework ha sido muy fructífero y desde luego muy recomendable para desarrollar cualquier aplicación web. 10.3.- Desarrollo de una aplicación con sistema de usuarios. El desarrollo del sistema de usuarios ha sido uno de los grandes hándicaps de este proyecto. Desde el principio era conocido que era necesario un sistema de usuarios debido a cómo los roles estaban estructurados. Esta parte del proyecto ha comprendido un largo periodo del proyecto pues afecta a cada una de las acciones que son llevadas a cabo en el sistema. Para ello inicialmente se buscaron varias alternativas sobre cómo crear un sistema de usuarios para una aplicación web y finalmente la alternativa elegida fue un componente de Zend Framework. Zend Auth es el componente del que hablamos y su diseño basado en el patrón Singleton de Ingeniería del Software hace posible gestionar de forma correcta a cada usuario en el servidor. Además este sistema era compatible con la forma de gestionar los usuarios en la aplicación desarrollada para Android, algo que había que tener en cuenta. Cómo se quiso implementar un sistema seguro de usuarios con control de listas de acceso fue necesario aprender ciertas técnicas de cifrado criptográfico que se utilizan de forma profesional hoy en día. La implementación ha sido costosa en tiempo pero excelente en resultados. Ha sido probado con tests en PHPUnit y ha superado todos con éxito. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 147 10.4.- Sistema de recomendación de actividades. Los usuarios en general desean obtener algo adecuado a sus gustos y al momento de forma sencilla. Este es el motivo básico por el que existen los sistemas de recomendación. Amazon es una veterana en ellos y en este proyecto se quería profundizar, experimentar e implementar uno, ya que el enfoque de la aplicación es similar al de una tienda de Amazon. Para ello se ha leído numerosa bibliografía y documentación. Existen ya hoy en día varios modelos de sistemas de recomendación pero aún es un campo abierto. En este proyecto se han seguido las técnicas de los sistemas de recomendación implementando un sistema de recomendación final que recomienda a cada usuario una actividad basada en los que se conoce de él y sus vecinos más próximos. Definitivamente este es uno de los puntos fuertes del proyecto, ya que lo que se pretendía es que un usuario que buscaba actividades recibiera una actividad perfecta para él basada en sus gustos. Los resultados obtenidos tras las pruebas son totalmente coherentes y satisfactorios. 10.5.- Desarrollo de aplicaciones en Android. El desarrollo extra de una aplicación en Android suponía todo un reto. Aunque previamente se había hecho prototipos para conocer el alcance que podía tomar el proyecto no se conocía con certeza el coste temporal de lo que se pretendía ni a hasta dónde se iba a llegar. Finalmente su desarrollo ha sido terminado con una funcionalidad y aspecto más que aceptables. Se ha conseguido que la aplicación en Android posea prácticamente las mismas funciones que la parte de un cliente web y todo ello con un buen rendimiento. La conclusión final de desarrollar la aplicación en Android es que me ha sido posible profundizar más en el lenguaje Java y conocer y valorar la arquitectura y el desarrollo de aplicaciones para Android. 10.6.- Uso de componentes, tecnologías y estrategias. En este apartado de las conclusiones me gustaría remarcar la importancia de la reutilización e integración de código. Gracias a librerías y componentes como JQuery, JQuery UI, Bootstap, Spinner y otras ha sido posible mostrar un buen aspecto y funcionalidad. Resulta imprescindible y recomendable en este tipo de proyectos utilizar este tipo de elementos que colaboran de forma activa al desarrollo de las aplicaciones. Git. El control de versiones, tanto para el desarrollo del servidor como para la aplicación para Android ha supuesto un componente esencial para el avance del proyecto. Con este proyecto he conseguido comprender mejor y coger soltura EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 148 con la utilización de estos elementos que ahora me resultan imprescindibles para desarrollar cualquier aplicación de tamaño y duración razonable. PHPUnit. Desde segundo de carrera nos enseñaron a realizar tests unitarios en las aplicaciones aunque la realidad es que no siempre los realizamos. En este proyecto se ha utilizado PHPUnit (muy similar a JUnit para Java) para testear el correcto funcionamiento del login de la aplicación. Esto ha permitido conocer esta herramienta de cerca y saber aplicarla para otros casos como JUnit para Android. 10.7.- Resultado final del proyecto. La conclusión final de este proyecto es que ha sido un proyecto largo pero en el que he adquirido una gran cantidad de conocimientos en áreas que ya conocía y también en disciplinas nuevas. Ha sido un proyecto que ha finalizado cumpliendo los objetivos y metas que se propusieron teniendo como resultado una aplicación web como servidor y servicio web, una aplicación cliente para Karotz y una aplicación cliente para Android. Todo ello conforma un completo sistema de recomendación de actividades ofrecido tanto como sugerencias como escaparate para el turista. Esto permite que la salida de este proyecto concluya con un sistema real donde en cada habitación de un hotel pueda haber un Karotz y cada huésped tenga en su móvil instalada la aplicación cliente del sistema de recomendación de actividades. Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 149 11.- Trabajo futuro. Sin duda, este proyecto pertenece a ese grupo de aplicaciones que pueden llegar a convertirse en algo más. Su expansión se puede abrir por una gran cantidad de frentes, algunos de ellos se comentan en los siguientes apartados. 11.1.- Ampliación de los servicios del sistema. Podemos encontrarnos información por todos lados pero no organizada. El turista continuamente se encuentra en busca de información y necesita que le proporcionen sólo la parte que le interesa. 11.1.1.- Servicios meteorológicos. La adición de los servicios meteorológicos en el sistema es una posible mejora de la aplicación. Para el turista este tipo de información es muy relevante, ya que en función de ella puede planificar qué actividades hará en el futuro. Además, en combinación con el sistema de recomendación puede hacer que las sugerencias a los usuarios sean aún más lógicas teniendo en cuenta este importante factor. 11.1.2.- Servicios de información de vuelos. Otro elemento importante puede ser conectar la aplicación con algún servicio web para proporcionar al usuario las últimas novedades de los vuelos. Con ello los usuarios pueden conocer antes de abandonar el hotel si su vuelo ha sido retrasado o continúa en hora. 11.1.3.- Reporte de estadísticas más completo. Todas las empresas desean mejorar productos y conocer cuáles son los más utilizados para analizarlos. Por ello, el ofrecerle cada vez estadísticas más completas de sus actividades en el sistema les permitiría que hicieran ese análisis y trataran de integrarse cada vez más dentro de la aplicación. Cuando un sistema resulta útil no sólo por su propaganda sino por su feedback aumenta su valor. 11.1.4.- Capacidad para realizar reservas de actividades directamente desde la web. No con todas las actividades es posible o necesario reservarlas. En cambio para otras como el alquiler de una cancha de tenis o las entradas para un espectáculo sí puede ser muy útil. Por eso integrar este servicio dentro de la aplicación aumentaría su utilidad y uso para los usuarios. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 150 11.1.5.- Geoposicionamiento y uso del servicio de rutas de Google Maps. En el proyecto se decidió integrar los mapas de Google para posicionar las actividades, pero si además a los usuarios les proporcionamos la ruta para llegar desde la misma aplicación no decaerán en ir o buscar cómo llegar de otra manera. Utilizando el gps del móvil o la tableta y con la API de Google Maps se podrían trazar las rutas para llegar a las actividades. 11.1.6.- Interfaz multi-idioma. Hoy en día es algo básico para cualquier aplicación pero cuando se desarrollan aplicaciones orientadas al turismo resulta imprescindible. Teniendo en cuenta que en Gran Canaria o Canarias la mayor parte de turismo es inglés y alemán tener la aplicación en estos idiomas es elemental. Zend Framework provee de un gestor de idiomas (Zend_Translate) que permite abstraer la lógica de la aplicación del idioma de la interfaz. Por otra parte, el sistema operativo y la API de Karotz permite operar en cuatro idiomas: español, inglés, francés y alemán. De modo que se puede aprovechar esta característica para que el módulo cliente del robot soportara la comunicación de cualquiera de estas cuatro lenguas. 11.2.- Búsqueda de alternativas o complementarias a Karotz. Como ya se ha comentado en las conclusiones, el robot Karotz tiene todas las características y funcionalidades para ser el cliente ideal del sistema pero la necesidad de mantenerse conectado no sólo a internet sino concretamente al servidor de Aldebaran durante su funcionamiento, hace que su uso sea más que cuestionable. Encontrar una plataforma similar a Karotz, con la funcionalidad básica de internet y de interfaz de comunicación por voz, puede ahorrar muchos problemas en el futuro. Existen una gran cantidad de robots zoomórficos que se ajustan a este perfil, aunque también es cierto que elevan su coste. Por otra parte nos encontramos con dispositivos electrónicos de voz y multimedia, como si de un gps o manos libres se tratase, y aunque no presente un aspecto tan amigable también cumplen los requisitos. Un ejemplo recién nacido es el nuevo robot Aisoy1, de una empresa española, con un coste algo más elevado que Karotz, 200€, pero aún así muy por debajo de la media. Este robot es también programable y está basado en las nuevas tecnologías de desarrollos de robots, Raspberry Pi y ROS, algo que permitiría desarrollar aplicaciones muy completas. Sin duda el futuro de esto proyecto podría estar unido al de este robot. 11.3.- Mejora del sistema de recomendación. Creo profundamente que este es un punto clave de la aplicación. El ofrecer al usuario lo que desea de manera más precisa asegurará el éxito del sistema. En el proyecto el sistema de recomendación es básico y puede mejorarse teniendo en Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 151 cuenta muchos más factores como la climatología, número de personas interesadas ese día en esa actividad o frecuencia de reserva de actividades. 11.4.- Desarrollo de una aplicación cliente para iOS. En el mundo de los smartphones existen esencialmente dos reinos de sistemas operativos Android y iOS. La implementación del cliente para iOS permitiría aumentar el alcance de la aplicación. La estructura de la aplicación sería muy similar y la implementación seguiría un desarrollo muy parecido a la de Android. EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 152 12.- Bibliografía. Segaran, Toby. “Programming Collective Intelligence Building Smart Web 2.0 Applications”. O'Reilly Media. E. Williams, Hugh; Lane, David. “Web Database Applications with PHP and MySQL, Building Effective Database-Driven Web Sites”. O'Reilly Media. Russell, Stuart; Norvig, Peter . “Artificial Intelligence: A Modern Approach”. Pearson. “PHP Manual”. http://www.php.net/manual/en/ “Zend Framework & MVC Introduction”. http://framework.zend.com/manual/1.12/en/learning.quickstart.intro.html “Zend Framework Reference”. http://framework.zend.com/manual/1.12/en/reference.html “Zend Framework”. http://angelorum.blogspot.com.es/2010/09/zend-framework-1-instalacion.html “PHP CSRF Guard”. https://www.owasp.org/index.php/PHP_CSRF_Guard “ZFdes”. http://manual.zfdes.com/es/index.html “Zend Framework API Documentation”. http://framework.zend.com/apidoc/1.12/ “Zend Framework Documentation”. http://www.zendframeworkdocumentation.com/ “Zend Framework Basic Tutorial”. http://www.zendframeworkdocumentation.com/ “Zend Framework and Doctrine ORM”. http://inchoo.net/tools-frameworks/zend/doctrine-orm-and-zend-frameworksample-project-to-get-you-started/ “Using Doctrine 2 in Zend Framework”. http://www.jasongrimes.org/2012/01/using-doctrine-2-in-zend-framework-2/ Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 153 “Creating a PHP REST API Using the Zend Framework”. http://www.chrisdanielson.com/2009/09/02/creating-a-php-rest-api-using-thezend-framework/ “Create RESTful Applications Using The Zend Framework”. http://www.techchorus.net/create-restful-applications-using-zend-framework “Writing a REST Web Service and Client With Zend_Controller”. http://www.zendcasts.com/writing-a-restful-web-service-and-client-withzend_controller-and-zend_httpclient/2009/04/ “Authorization with Zend_Acl in Zend Framework”. http://www.packtpub.com/article/authorization-with-zend_acl-zend-framework1.8 “Zend Acl with Authentication and Reflection”. http://www.youtube.com/watch?v=PALEC6XqCZc “Zend_Acl: autorización y permisos en Zend Framework”. http://otroblogmas.com/zend_acl-autorizacion-y-permisos-en-zend-framework/ “Understanding Zend Framework’s Plugin Parts 1 & 2”. http://devzone.zend.com/2508/understanding-zend-frameworks-plugin-parts-1-2/ “View Helpers in Zend Framework”. http://devzone.zend.com/1235/view-helpers-in-zend-framework/ “Performance Optimisation For Zend Framework Applications”. http://www.survivethedeepend.com/zendframeworkbook/en/1.0/performance.opt imisation.for.zend.framework.applications# “Documentación para desarrolladores de Google Maps”. https://developers.google.com/maps/documentation/?hl=es “Google Charts”. https://developers.google.com/chart/?hl=es “jQuery API Documentation”. http://api.jquery.com/ “jQuery UI”. http://jqueryui.com/ “Bootstrap”. http://getbootstrap.com/2.3.2/index.html EII - IUCTC 2013 Universidad de Las Palmas de Gran Canaria 256 Imagen 13.97. Android. Detalle de actividad. Botón quitar de favoritos Para votar la actividad debemos pulsar sobre el número de estrellas que deseemos otorgarle. Imagen 13.98. Android. Detalle de actividad. Votación Escaparate Interactivo de Actividades Turísticas 2013 Universidad de Las Palmas de Gran Canaria 257 Localización de una actividad Para localizar una actividad debemos pulsar sobre el botón Localize en el detalle de la actividad. Con esta acción se nos mostrará un mapa indicándonos donde se realiza. Imagen 13.99. Android. Localización de actividad