T reba ll F ina l de G rau
GRAU D’ENGINYERIA INFORMÀTICA
Módulo de reservas de productos turísticos
GEORGI NIKOLAEV ILIEV
Tutor
Gabriel Fontanet Nadal
Supervisor Miquel Tomas
Escola Politècnica Superior
Universitat de les Illes Balears
Í NDICE GENERAL
Índice general i
Índice de figuras iii
Índice de cuadros v
Acrónimos vii
Resumen ix
1 Introducción 1
1.1 Juniper Consulting . . . 1
1.2 Situación en la empresa . . . 2
1.3 Tema principal del proyecto . . . 2
1.4 Motivación . . . 3
1.5 Objetivos . . . 3
2 Estado del arte 5 2.1 Juniper Booking Engine. . . 5
2.2 Tecnología . . . 6
3 Análisis de requisitos 9 3.1 Descripción general. . . 9
3.1.1 Relación del módulo con otros proyectos/módulos. . . 9
3.1.2 Perspectiva del producto. . . 10
3.1.3 Capacidades generales. . . 11
3.1.4 Restricciones generales. . . 12
3.1.5 Características de los usuarios.. . . 12
4 Módulo de reservas de productos turísticos: Cruceros 15 4.1 Descripción general del módulo . . . 15
4.2 Librería JBE: Datos estáticos de cruceros. . . 16
4.2.1 Estructura de la base de datos. . . 16
4.2.2 Llenado de la base de datos. . . 21
4.2.3 Caché de datos estáticos de cruceros. . . 24
4.3 Librería de WebService.. . . 33
4.3.1 Parte pública. . . 35
4.3.2 Parte privada. . . 36
ii ÍNDICE GENERAL
4.4 CallCenter. . . 39
4.4.1 Librería del CallCenter. . . 40
4.5 Presentación del CallCenter. . . 42
4.5.1 Estructura general. . . 43
4.5.2 Funcionalidad y abstracción.. . . 44
4.6 Realización de una reserva de cruceros. . . 45
5 Líneas futuras 47 5.1 Estructura de la base de datos y su gestión. . . 47
5.2 Obtención de los datos estáticos. . . 48
5.3 Estructura de la caché y gestión de esta. . . 48
5.4 Descripciones de cruceros desde la Intranet de Juniper.. . . 48
6 Conclusiones 49
Bibliografía 51
Í NDICE DE FIGURAS
2.1 Juniper Booking Engine. . . 5
3.1 Módulos del Call Center. . . 10
3.2 Capacidades generales del Call Center. . . 11
3.3 Usuarios del Call Center. . . 13
4.1 Diagrama general del módulo. . . 16
4.2 Base de datos del módulo de cruceros . . . 17
4.3 Modelo de fichas técnicas inicial . . . 18
4.4 Modelo de fichas técnicas múltiples idiomas . . . 18
4.5 Diagrama de llenado de la base de datos. . . 21
4.6 Flujo del proceso para obtener los datos de los cruceros a partir de un XML específico. . . 22
4.7 Flujo del proceso deScrappingde los datos de cruceros. . . 23
4.8 Diagrama general con al implementación de la caché.. . . 24
4.9 Funcionamiento del objeto diccionario. . . 26
4.10 Estructura general del sistema caché.. . . 26
4.11 Obtención de objetos de la caché. . . 27
4.12 Diagrama de flujo de la función Obtener de caché. . . 28
4.13 Creación del diccionario de barcos en el métodoNew().. . . 29
4.14 Creación de diccionarios en cadena. . . 30
4.15 Diccionarios índice. . . 32
4.16 Diagrama de caché de fichas técnicas. . . 33
4.17 Clases delWebService. . . . 33
4.18 Diagrama general junto a la implementación del WebService. . . 34
4.19 Comprobaciones de la librería WebService. . . 36
4.20 Obtención de los datos del barco por WebService. . . 37
4.21 Diagrama general junto a la librería del CallCenter. . . 39
4.22 Funcionamiento de librería CallCenter. . . 40
4.23 Diagrama de funcionamiento delhandlerde cruceros. . . 41
4.24 Clase Results. . . 42
4.25 Estructura de clases general en la parte de presentación. . . 43
4.26 Generación de las páginas HTML. . . 44
4.27 Estructura de la de presentación. . . 45
Í NDICE DE CUADROS
4.1 Tabla de las fichas técnicas de los barcos. . . 19
4.2 Tabla de descripciones en diferentes idiomas.. . . 19
4.3 Tabla de los datos referentes a las cubiertas. . . 20
4.4 Tbl_CruceroCubiertaLeyenda . . . 20
4.5 Tbl_IdiNCruceroCubiertaLeyenda . . . 20
4.6 Tbl_CruceroCategoria. . . 20
4.7 Tbl_IdiNCruceroCategoria . . . 21
A CRÓNIMOS
JBE Juniper Booking Engine
Es una plataforma de distribución personalizada con herramientas que permiten a las empresas actuar y automatizar sus canales de venta en Internet. La mejora de la eficiencia operativa de las empresas, ofrece soluciones innovadoras que automatizan los procesos de consulta, contratación de productos y gestión inter- na, reduciendo los costes y empleando canales más eficientes que los utilizados tradicionalmente.
BE BackEnd
Capa de acceso a datos.
DOM DOM
Document Object Model: Es esencialmente una interfaz de plataforma que pro- porciona un conjunto estándar de objetos para representar documentos HTML, XHTML Y XML, un modelo estándar sobre cómo pueden combinarse dichos objetos y una interfaz estándar para acceder a ellos y manipularlos.
AJAX AJAX
Asynchronous JavaScript And XML: Es una técnica de desarrollo web para crear aplicaciones interactivas. Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas.
WS Web Service
Un Servicio Web oWebServicees un servicio ofrecido por una aplicación que ex- pone su lógica a clientes de cualquier plataforma mediante una interfaz accesible a través de la red utilizando tecnologías (protocolos) estándar de Internet.
CACHE Caché
Habitualmente, se entiende caché como la memoria de acceso rápido de un procesador. En este documento, se habla de caché web. Esta almacena todo tipo de datos — imágenes, descripciones, nombres, códigos, etc. — en el servidor y permite un acceso rápido con tiempos de lectura reducidos.
INTRANET Intranet
viii ACRÓNIMOS
Red informática interna de una empresa u organismo, basada en los estánda- res de Internet, en la que las computadoras están conectadas a uno o varios servidores web.
XML XML
XML es un lenguaje que extiende el lenguaje de marcas. Inicialmente, fue diseña- do para el almacenamiento y la transferencia de datos. Es un lenguaje pensado para ser leído tanto por personas como por máquinas.
XPATH XPATH
XPath es un lenguaje que permite construir expresiones que recorren y proce- san un documento XML. Permite buscar y seleccionar teniendo en cuenta la estructura jerárquica del XML.
WebScrapping Web Scrapping
Es una técnica que, mediante programas de software, permite extraer informa- ción de sitios web. Normalmente, estos programas simulan la navegación huma- na.
SOAP SOAP
Es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML.
Naviera Naviera
Es la persona física o jurídica propietaria de los barcos, la que controla y aporta los recursos necesarios para el mantenimiento de la flota, la tarificación y la venta y/o reserva de su producto.
Handler Handler
Es una clase que permite la comunicación entre un subproceso con el hilo prin- cipal de la aplicación. En este caso, dado que es una aplicación Web, es la clase encargada de conectar la capa de Cliente con la capa de Servidor.
R ESUMEN
A lo largo de mis estudios en la Universidad siempre tenía en mente cómo podría ser mi Trabajo de Fin de Grado, qué temas trataría y con quién lo realizaría. Tuve algunas ideas, como hacer un juego o un compilador. Pero, finalmente, durante el verano anterior a mi último año académico empecé como estudiante en prácticas enJuniper Consulting.
Allí mejoraba día a día mis habilidades y conocimientos informáticos trabajando en el desarrollo y mejora de una aplicación centrada en el sector turístico. Una de las mayores mejoras que se deseaba realizar era el desarrollo de un módulo de venta de cruceros en la aplicación principal. El desarrollo de este módulo me fue asignado como proyecto.
Puesto que aún no tenía claro qué Trabajo de Final de Grado realizar y, dado que el módulo me permitiría desarrollar más aún mis habilidades en diferentes aspectos, decidí utilizarlo. Mi objetivo principal era la creación de un módulo eficiente, óptimo y funcional. Así, en un proyecto, se juntaba todo lo que me gustaba: las estructuras de datos, la optimización y las interfaces de usuario, entre otros.
Cabe destacar que, al ser un proyecto software, sus requisitos han aumentado y sufrido cambios a lo largo de su desarrollo. En el caso de la optimización de la memoria y la obtención de datos, se desarrolló una versión inicial de estructura de datos, sobre la que se hicieron las pruebas pertinentes de rendimiento y, después, se mejoró a un nuevo sistema que nos proporcionaba mejores tiempos de carga.
El documento sigue la estructura habitual utilizada en los trabajos de fin de grado.
Así pues, mediante una introducción se especifica el contenido, el tema del proyecto, las motivaciones y los objetivos. En el siguiente punto se presenta el estado, en aquel entonces, del módulo que se desarrolló y la tecnología que se utilizó durante su im- plementación. Después, en el apartado de análisis de requisitos se expone la relación del módulo con proyectos similares, sus capacidades y restricciones generales y las características de los usuarios que lo utilizan. Posteriormente, se inicia el apartado de descripción detallada del módulo y su completo funcionamiento. Llegado a este punto, el lector ya tendrá en mente el módulo completo, por lo que en el siguiente apartado se presentan las líneas futuras que seguirá la aplicación. Finalmente, se exponen las conclusiones a las que se ha llegado tras desarrollar y realizar este documento del Trabajo de Final de Grado.
C
APÍTULO1
I NTRODUCCIÓN
1.1 Juniper Consulting
La principal actividad de Juniper, empresa tecnológica del sector turístico, es la creación de aplicaciones web — páginas web, intranets y extranets — altamente funcionales y efectivas. El enfoque en la interacción humana con ordenadores y un diseño basado en al usabilidad aseguran que las aplicaciones estén hechas a medida a las necesidades del cliente.
Juniper proporciona una plataforma de distribución — Juniper Booking Engine — personalizada y diversas herramientas para que las empresas tengan total libertad de actuación y automatización sobre sus canales de venta en Internet. Un punto impor- tante, es la mejora de la eficiencia operativa de las empresas, ofreciendo soluciones innovadoras que automatizan los procesos de consulta, contratación de productos y gestión interna, reduciendo así los costes y empleando canales más eficientes que los utilizados tradicionalmente.
Los principales clientes de Juniper, entre otros, son:
• Agencias de viajes online.
• Touroperadoras.
• Cadenas hoteleras.
• Centrales de reserva.
• Proveedores de alojamientos.
1. INTRODUCCIÓN
1.2 Situación en la empresa
Parte de la estructuración del personal de Juniper es:
• Departamento deProject Management: Departamento encargado del trato con el cliente.
• Departamento deFront-End: Departamento encargado del desarrollo de la pre- sentación de los datos a los clientes.
• Departamentos de dasarrollo — Alojamientos, Paquetes, Servicios, Core, etc. —:
Estos son los departamentos encargados del desarrollo de todas las funcionalida- des delBack-Endde los diferentes tipos de producto.
• Departamentos deSistemas yDBA: Departamentos encargados del manteni- miento y gestión de los sistemas de la empresa — servidores, bases de datos, sistemas locales, etc. —.
Actualmente, estoy como desarrollador en el departamento deCore. Como se ha introducido brevemente anteriormente,Corees uno de los departamentos encargados del desarrolloBack-Endde los productos deJuniper. Concretamente, se encarga del desarrollo de todas las funcionalidades comunes a todos los productos, es decir, si se ha de añadir una funcionalidad que permita a un cliente enviar un correo dependiendo del canal de venta, puesto que es común, se deberá encargar el departamento de Core. Los desarrolladores de Core también somos los encargados del mantenimiento y evolución de los módulos de cruceros de laBookingEngine.
1.3 Tema principal del proyecto
La plataforma de reservas de cruceros es un módulo de la Juniper Booking Engine (JBE) que ofrece las herramientas más actuales para poder ofrecer al público de nuestros clientes — para el caso de una agencia, por ejemplo, los usuarios que compran los billetes son su público — la posibilidad de comprar cruceros On-Line. Con este módulo, el usuario podrá, entre otros:
• Vender sus cruceros On-line usando una pasarela de pago segura. Puesto que el módulo está conectado a laJBE, se consigue un control sobre las diferentes transacciones monetarias necesarias a la hora de pagar el producto que se desea adquirir.
• Ofrecer aquellos cruceros contratados directamente o replicar los datos de los cruceros ofrecidos por sus Partners Mayoristas. Es decir, un cliente puede tener contratado un crucero propio, por lo que la gestión de sus reservas no pasará a través de un proveedor o Partner Mayorista.
• Crear itinerarios, ofertas, fichas técnicas, etc. Así como presentarlos a su público.
• Gestionar diferentes tarifas a la hora de vender sus reservas. Es decir, se crean tarifas dependiendo de la edad del pasajero, del tipo de cabina, etc.
• Gestionar todas las reservas realizadas desde un mismo punto de acceso.
2
1.4. Motivación
1.4 Motivación
Como se ha mencionado anteriormente, durante el último año de mis estudios en la Universidad, empecé como estudiante en prácticas enJuniper Consulting. Puesto que era el año de mi graduación, quería hacer mi primera entrada en el mundo laboral como ingeniero y encontrar qué es lo que realmente me gusta y sé hacer. He de destacar que, en los estudios de Ingeniería Informática, pocas veces uno encuentra su vocación.
Los primeros meses de prácticas, aprendí sobre lógica de negocio — puesto que es un producto turístico, esta es extensa — y sobre el funcionamiento del producto principal, por lo que crecí como persona y como ingeniero.
Pese a esto, aún no tenía claro el tema principal de mi Trabajo de Final de Grado.
Mientras tanto, en Juniper, se reactivó el desarrollo de una plataforma de reservas innovadora. Estaba formada por diferentes módulos, dependiendo del producto que se quería vender — Alojamiento, Vuelo, Crucero —. Uno de los módulos que aún se debían concluir era el decruceros.
Puesto que el desarrollo de un módulo completo, conlleva trabajo tanto a bajo nivel, como a nivel de presentación de usuario, la implementación de este, podría ser un buen tema de Trabajo de Final de Grado. Una vez que se me explicó qué se debería realizar — conexiones a base de datos, creación de sistemas Caché (CACHE), conexiones WebService, etc. —, me quedó claro en qué consistiría mi trabajo.
1.5 Objetivos
Mi principal objetivo era el desarrollo de un módulo de reservas rápido y funcional.
Para ello, antes tuve que aprender el funcionamiento y el flujo completo para tener una idea general de qué se desea realizar y qué es necesario mejorar.
El módulo que iba a desarrollar se centraba en la realización de reservas de cruceros.
Como todo producto, este tiene gran cantidad de datos estáticos — descripciones, imágenes, fichas técnicas de los barcos, etc. — a los que se debía acceder lo más rápido posible. Para ello, fue necesaria la implementación de un sistema deCACHEespecial.
El objetivo principal de este módulo, aparte de lo ya mencionado, era permitir a un usuario realizar una búsqueda, una selección y una reserva de un crucero concreto.
Por otro lado, mi principal objetivo personal era encontrar qué es lo que realmente me gusta y sé hacer como ingeniero informático. Otros puntos secundarios eran la ca- pacidad de asumir la responsabilidad de un módulo de la plataforma y de enfrentarme y solucionar problemas.
C
APÍTULO2
E STADO DEL ARTE
En este capítulo se expone cuál era la situación inicial del módulo y qué factores eran los más importantes a la hora de resolver el problema planteado. Además, se exponen las diferentes tecnologías y herramientas que se utilizaron para llegar a la solución deseada.
2.1 Juniper Booking Engine
En elCapítulo 1se presentó el producto principal deJuniper Consulting, laBooking Engine(JBE) — la figura2.1muestra su estructura —.
Figura 2.1: Juniper Booking Engine.
Como se puede observar en la figura2.1, laBooking Enginepermite a los clien-
2. ESTADO DEL ARTE
tes de Juniper tener un control completo sobre sus productos, reservas, canales de distribución, etc.
Antes de introducir la situación del módulo desarrollado, es necesario hacer una breve introducción al términoCall Center[1]. Este es importante dado que el módulo desarrollado forma parte de un sistema similar.
Call Center[1] se traduce comoCentro de llamadasy se define como un área donde personal especializado, especialmente entrenado, realizan o reciben llamadas desde o hacia: clientes, socios comerciales, compañías u otros[2]. En el caso de los clientes de Juniper, esteCall Centeres utilizado para realizar reservas telefónicamente.
En la actualidad, laJBEcuenta con la integración de un móduloCall Centerque permite hacer una reserva de un producto turístico de forma fácil y rápida. Es decir, se pueden crear directamente en el sistema reservas de hoteles, servicios turísticos, traslados, vuelos y presupuestos de reserva de alojamiento. Pese al estado desarrollado del sistema, no estaba implementada la realización de reservas de tipo crucero.
A día de hoy, se está acabando de desarrollar una nueva aplicaciónCall Center con el objetivo de mejorar todas las funcionalidades de la antigua e introducir nuevos módulos.
2.2 Tecnología
Existen varias tecnologías que permitían encontrar de manera óptima la solución al problema planteado, la creación de un módulo de reservas de cruceros. Pero, pese a estos métodos de resolución, como el módulo formaba parte de un proyecto mayor, debía implementarse haciendo uso de las mismas tecnologías usadas en la aplicación madre — elCall Center—.
Para la presentación de las diferentes tecnologías que se han utilizado se hará la siguiente distinción: por una parte tendremos la tecnología usada para la implementa- ción de las funcionalidades de BackEnd (BE), la interfaz de usuario y la gestión/control de las bases de datos necesarias.
Las tecnologías usadas en la implementación delBEy la gestión de las bases de datos son:
• .Net Framework:Todas las funcionalidades de acceso a datos y creación de los documentos HTML se hacen a través de los lenguajes soportados por el frame- work deMicrosoft. En el caso de la plataforma de reservas, el lenguaje utilizado esVisual Basic[3], diseñado para crear de manera productiva aplicaciones con seguridad de tipos orientadas a objetos.
Cualquier funcionalidad del módulo, desde la obtención de los datos de base de datos, hasta la creación dinámica de los documentos HTML se hace por medio de este lenguaje.
La razón principal del por qué usar Visual Basic es por compatibilidad hacia atrás
— laJBEestá desarrollada en este lenguaje —. Algunas de las ventajas de Visual Basic respecto a otos lenguajes de alto nivel son:
– Tiene una rápida curva de aprendizaje.
6
2.2. Tecnología
– Es uno de los lenguajes más extendidos, por lo que resulta sencillo encontrar información, documentación y fuentes para los proyectos.
– Es fácilmente extendible mediante librerías .DLL.
Para la implementación de una de las principales partes del módulo, la caché de cruceros, fue necesaria al utilización de objetos propios de .Net, losDictionary.
Estos representan una colección que relaciona valores con claves de diferente tipo. También permiten la utilización de tipos genéricos, tanto para la indexación de las claves como para los valores que guarda, es decir, un objeto de este tipo, puede tener indexado una lista de listas por una clave identificador. Cabe destacar pero, que elDictionarysolo soporta multiplicidad de lecturas si la colección de datos no es modificada por ninguna de ellas.
• SQL Server:Es un lenguaje declarativo de acceso a bases de datos realcionales que permite especificar diversos tipos de operaciones en ellas. En el caso del proyecto, se utilizaMicrosoft SQL Server[4]. En este caso, el lenguaje de desarro- llo es Transact-SQL, una implementación del estándar ANSI del lenguaje SQL, utilizado para manipular y recuperar datos, crear tablas y definir relaciones entre ellas.
Este es utilizado principalmente para la creación de las bases de datos necesarias para el guardado de los datos tanto estáticos como dinámicos.
• Web Service: Son cualquier pieza de software que, se pone a disposición en internety, utiliza un sistema de mensajería XML estandarizada. Estas plataformas de Web Service están formadas principalmente por tres partes:
– Transporte de servicio: Esta pieza es la encargada de hacer el paso de men- sajes entre las aplicaciones. Normalmente, esta incluye protocolos como HTTP, SMTP o FTP.El primero se utiliza principalmente para mensajes de texto, el segundo para correos y el tercero para ficheros.
– Mensajes XML: Esta es la responsable de codificar los mensajes en un XML (XML) común que pueda ser leído en ambos extremos. Esta, también, suele incluir el protocolo SOAP (SOAP).
– Descripción del servicio: Esta última es la responsable de describir la inter- faz pública del servicio web. Se utiliza el lenguaje de descripción del Web Service, conocido comoWSDL. En esta descripción se muestran todos los objetos y funciones que forman el servicio web.
Estos son utilizados principalmente para el paso de datos entre las diferentes partes que forman el módulo.
Las tecnologías usadas en la implementación de la interfaz de usuario son:
• HTML5:Es un lenguaje de marcado usado para la elaboración de páginas web.
Es un estándar que define una estructura básica y un código para la definición de contenido en una página web — como texto, imágenes, vídeos, juegos, entre otros —. En el caso del proyecto se utilizará la quinta revisión de este lenguaje, el HTML5. Con esta última revisión, se han mejorado, entre otros, los siguientes puntos [5]:
2. ESTADO DEL ARTE
– Código simple y ligero.
– Mejor compatibilidad con los navegadores de dispositivos móviles.
– Se pueden ejecutar páginas sin estar conectado a internet.
– Se ha mejorado la estructura: Hoy en día se abusa del elementodiva la hora de estructurar las páginas web. Con esta revisión se han añadido diferentes elementos, de entre los que destacansection,header,footerynav.
• CSS:Proviene deHojas de estilo en cascada[6] y es un lenguaje de hojas de estilo para definir y crear la presentación de un documento estructurado escrito en un lenguaje de marcado, en este caso HTML5. Es muy usado para establecer el diseño visual de las páginas web. Actualmente, es de las tecnologías más usadas a la hora de crear páginas web visualmente atractivas. La revisión que se utiliza en este proyecto es la deCSS3ya que ha sido dividida en módulos con el objeti- vo de facilitar la estructuración de los documentos. Algunos de estos módulos son los selectores, los modelos de caja, fondos, imágenes, efectos en los textos, animaciones, interfaz de usuario, etc.
• jQuery:Es una biblioteca deJavaScriptque simplifica la manera de interactuar con los documentosHTML, manipular el árbol DOM (DOM), manejar eventos, desarrollar animaciones y agregar interacción con la técnica AJAX (AJAX) a pági- nas web [7]. Al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas enJavaScriptque de otra manera requerirían de mucho más código, es decir, con las funciones propias se logran grandes resultados en menos tiempo y espacio[8]. Las principales características que se pueden destacar sobre jQuery son:
– Permite la selección y la modificación de elementos individuales del árbol DOM.
– Permite la manipulación de las hojas de estilo CSS, la creación de efectos y animaciones personalizadas.
– Soporta, como ya se ha mencionado, la técnicaAJAXy diferentes extensio- nes.
8
C
APÍTULO3
A NÁLISIS DE REQUISITOS
Se destaca que no se realiza una especificación formal de requisitos por dos motivos fundamentales:
• El proyecto no ha seguido el modelo clásico de desarrollo basado en el proceso en cascada[9]. Lo que se ha hecho, siguiendo el modelo de trabajo de la empresa, es un desarrollo de tipoincremental-ágil, sin adaptarse a ninguna metodología concreta — ya seaSCRUM,XP, etc. —.
• El volumen de la documentación que se generaría. Es más importante centrarse en la exposición del módulo en sí, como producto final, haciendo hincapié en los principales aspectos de diseño y eficiencia.
Pese a todo esto, en este capítulo se expone la descripción de las diferentes funcio- nalidades y restricciones del módulo.
3.1 Descripción general.
3.1.1 Relación del módulo con otros proyectos/módulos.
El desarrollo de la nueva aplicación delCall Centerconlleva ser muy cuidadoso a la hora de analizar e implementar diferentes módulos.
El módulo de cruceros, al igual que los otros productos — Alojamiento, Paquetes, Translados —, está fuertemente relacionado con elCall Centery ha de seguir su estruc- tura y estándar. Pero, como diferencia respecto a los otros productos, este no estaba implementado en la versión antigua del Call Center, por lo que se pudo innovar en algunas de sus funcionalidades. La figura3.1muestra esta estructura.
3. ANÁLISIS DE REQUISITOS
Figura 3.1: Módulos del Call Center.
3.1.2 Perspectiva del producto.
Como se ha detallado anteriormente, elCall Center, es una plataforma de reservas, for- mada por diferentes módulos, que permite hacer una reserva de un producto turístico de forma fácil y rápida.
Por lo que, en principio, el módulo de cruceros tenía que permitir a un usuario de la aplicación realizar reservas de cruceros — posteriormente se detallarán los usuarios —.
Pero, realizar una reserva de un producto concreto a través de laJBE, no es tan simple.
Han de cumplirse ciertas condiciones y se han de realizar ciertos pasos obligatorios.
Como consecuencia, las funcionalidades y requisitos necesarios para el funcionamiento del módulo se vieron incrementadas.
En resumen, se deseaba implementar un módulo que permitiera la realización y el filtrado de una búsqueda en un amplio rango de productos, la selección de un producto concreto y la realización de una reserva.
También era necesaria la integración de este módulo con la plataforma completa, ya sea tanto en consultas de las reservas, como en la creación de presupuestos.
10
3.1. Descripción general.
3.1.3 Capacidades generales.
Partiendo de las necesidades básicas del módulo y el flujo de la figura3.2 se han obtenido las siguientes capacidades generales:
Figura 3.2: Capacidades generales del Call Center.
• Larealización de una búsqueda: Para realizar una búsqueda en elCall Center, lo primero que debe hacer un usuario es iniciar sesión como usuario de laJBEy, seleccionar una agencia con la que realizar la reserva. Puesto que esta funcionali- dad es común a todos los productos y ya está implementada, no se contemplará en el análisis.
Una vez que se haya completado el paso anterior, lo siguiente que debe hacer el usuario es introducir una zona de búsqueda — por ejemplo, si desea un crucero por el caribe, debe seleccionarCaribecomo zona de búsqueda —, un mes de salida y una duración de viaje — si lo desea, puede seleccionar entre flexible o de un rango de días —. Se realiza la búsqueda cuando se han proporcionado al módulo los parámetros de búsqueda.
Cuando el módulo devuelve los resultados buscados, el usuario los puede filtrar por diferentes atributos — nombre de barco, nombre de puerto, precio, proveedor, etc. —.
3. ANÁLISIS DE REQUISITOS
• Laselección de un producto concreto: Una vez que el usuario ha realizado y filtrado la búsqueda, este puede seleccionar el producto deseado. Para ayudar a la selección, en este caso, del crucero, el usuario tiene a su disposición cierta información básica de este — descripción, itinerario, imágenes, camarotes y ficha técnica —.
• Laselección de características concretas del producto: Una vez que el usuario ha seleccionado el crucero deseado, este puede cambiar los parámetros de tarifi- cación. Es decir, puesto que los resultados de la primera búsqueda son siempre para dos pasajeros, si se desea cambiar la distribución o se desea añadir algún suplemento a la reserva, este es el momento. Una vez se han seleccionado co- rrectamente los parámetros de la reserva, se debe seleccionar un número de camarote y una cubierta concretas.
• Larealización de la reserva: Puesto que el módulo forma parte delCall Center, este permite el cierre de una reserva o la creación de un presupuesto. El usuario es capaz de introducir los datos del titular de la reserva, los pasajeros y finalmente cerrar la reserva.
3.1.4 Restricciones generales.
Dado que el módulo de cruceros forma parte de una plataformaCall Centerdebe per- mitir la realización de búsquedas y reservas de forma rápida y eficiente. Para conseguir estos objetivos es necesario destacar las siguientes restricciones:
• El módulo respeta la imagen corporativa de la marca Juniper haciendo uso de los estándares de diseño establecidos.
• El módulo respeta y protege la privacidad de los usuarios ante cualquier posible error.
• El módulo es capaz de garantizar el acceso concurrente a los datos que utiliza.
• El módulo no permite la realización de reservas a usuarios o agencias sin permi- sos.
• En caso de que se produzca un error durante la realización de la reserva, esta se cancela automáticamente.
• El módulo muestra únicamente los resultados de búsqueda que tengan disponi- bilidad.
• El módulo garantiza la obtención de resultados de búsqueda en un tiempo menor a diez segundos.
3.1.5 Características de los usuarios.
Dado que elCall Centerno es un producto dirigido a un público amplio, sinó a los clientes de Juniper, los usuarios que tienen acceso al módulo son:
12
3.1. Descripción general.
Figura 3.3: Usuarios del Call Center.
• Administrador Juniper: Persona con permisos de administración Juniper — em- pleado de Juniper—. Tiene todos los permisos de realización y gestión de las reservas, sin ninguna restricción.
• Usuario de intranet: Persona empleada de una empresa cliente de Juniper — empleado de una agencia de viajes, de una cadena hotelera, etc. —. Los permisos que tendrá este usuario dependerán de su configuración en laJBE. Puede ocurrir, que un usuario no tenga permisos de realización de reservas, solo de realización de búsquedas de disponibilidad.
• Agencia: Entidad asociada al turismo cuyo principal objetivo es la intermediación entre el público y el proveedor[10]. Un cliente Juniper puede tener bajo su mando diferentes agencias. Los permisos de estas en el módulo vendrán dados por su configuración en laJBE.
Puesto que los usuarios son completamente diferentes, no se puede jerarquizar según funcionalidades. Pero sí según su nivel de permisos. Como se ha especificado, el usuario Juniper tiene permisos completos de acción en el módulo. La figura3.3muestra la jerarquía de usuarios.
C
APÍTULO4
M ÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS : C RUCEROS
En este capítulo, se exponen todas las partes de desarrollo del módulo de reservas de cruceros. Se introduce la estructura y el funcionamiento completo del módulo, detallando las librerías y clases que lo componen, desde la parte de presentación de los datos, hasta la de obtención y almacenaje de estos.
Primero se introducen todas las partes brevemente y, a continuación, se entra en detalle en cada una de ellas siguiendo el flujo de obtención de datos.
4.1 Descripción general del módulo
En esta sección se explica brevemente la estructura general y las diferentes piezas que forman el módulo y que permiten su correcto funcionamiento.
Dado que elCallCenteres una aplicación web, el módulo de cruceros tiene imple- mentada una parte depresentaciónque permite hacer todo tipo de gestiones, desde hacer búsquedas, hasta realizar reservas reales.
Para la aplicación madre del módulo, elCallCenter, está implementada una librería propia que encapsula todas las funcionalidades del servidor —CallCenterLib—. Esta librería es expandida con las funcionalidades necesarias para la gestión de cruceros.
Pasadas ya la presentación, la librería propia delCallCentery elWeb Service (WS), se llega a la librería que atacará este último. Estalibrería JBEes la encargada de obtener los datos del crucero de caché (CACHE) y base de datos. La figura4.1muestra las piezas que implementa el módulo.
Tras conocer la estructura y su funcionamiento, se expone el proceso de realización de una reserva de un crucero a través de la aplicación web.
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
Figura 4.1: Diagrama general del módulo.
4.2 Librería JBE: Datos estáticos de cruceros.
En esta sección se expone con detalle el almacenamiento y gestión de los datos tanto a nivel de base de datos, como a nivel de memorias caché.
La sección se divide en los siguientes apartados:
• Estructura de la base de datos.
• Llenado de la base de datos.
• Caché de los datos estáticos.
4.2.1 Estructura de la base de datos.
Para la integración de este nuevo módulo de cruceros completamente funcional con la plataforma de reservas completa, se debían guardar los datos necesarios en las bases de datos propias. Para ello se construyó una estructura completa que, permitía obtener los datos con el menor número de accesos a base de datos.
Inicialmente,Juniperya tenía integraciones de cruceros en laIntranet (INTRANET) propia y en las páginas web de algunos clientes, una parte de la base de datos de cruceros ya estaba implementada.
16
4.2. Librería JBE: Datos estáticos de cruceros.
Figura 4.2: Base de datos del módulo de cruceros
La base de datos inicial contiene información básica sobre los barcos (cubiertas, camarotes), las tarifas (precios, suplementos), y los itinerarios (días de salida y llegada, puertos de embarque).
Para la implementación del módulo de cruceros en elCallCenterera necesario tener guardados todos los datos descriptivos de los barcos y cruceros — para ello se debían generar tablas nuevas —. Estos estaban formados por las diferentes descripciones de los cruceros, la información sobre las categorías que tienen, la ficha técnica del barco y las imágenes representativas. La figura4.2muestra una visión general.
Un punto a tener en cuenta es que a la hora de diseñar las tablas necesarias para la información de las fichas técnicas, es que, para mantener la compatibilidad del sistema, los nuevos datos deben estar convenientemente inter-relacionados con los de las tablas preexistentes. Además, de cumplir con los estándares de diseño e implementación.
Antes de diseñar la arquitectura de las tablas era necesario saber la naturaleza de los datos que se deseaba guardar y saber también qué operaciones se realizarían a posteriori, información que se conseguiría en la fase de análisis de requisitos.
Como se ha especificado, los datos referentes a los barcos y tarifas ya se almacena- ban en el sistema. Con el objetivo de mejorar el sistema de datos estáticos, se guardaron en estas fichas los siguientes datos:
• Con referencia a loscruceros: El nombre representativo del crucero, la descrip- ción de este y, si tiene, las imágenes.
• Con referencia a losbarcosde los cruceros:Eel código del barco, su nombre, la descripción, todos los datos de ficha técnica (tonelaje, manga, eslora, tripulación, entre otros.) Dentro de este aspecto, de cada barco, se guardan también los datos de las cubiertas y las categorías. Para las cubiertas, el nombre y el número de cubierta y, para las categorías, el nombre, el identificador de categoría y la des- cripción. Es necesario destacar que, todas las descripciones son almacenadas en tres idiomas (Español, Inglés y Portugués) y que, en caso de que tengan imágenes, también se contemplan.
Una vez se conocía la naturaleza de los datos que se deseaban almacenar en la base de datos, se procedió con el diseño del modelo.
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
Para almacenar todos los datos referentes al crucero y al barco, ya sean descrip- ciones, nombres, códigos y datos técnicos, se utilizó la tabla defichas técnicas, ver figura4.3. Esta, es el eje principal del modelo con la que se obtienen todos los datos necesarios una vez se ha entrado en ejecución. Es decir, si se desea acceder a los datos de las cubiertas y las categorías, gracias a que las cubiertas están relacionadas con una ficha técnica y, las categorías están relacionadas con las cubiertas, partiendo del eje, se obtienen todos los datos estáticos de un crucero concreto.
Figura 4.3: Modelo de fichas técnicas inicial
Se observa que esta estructura ya permitía guardar toda la información básica de las fichas técnicas de los cruceros. El problema es que no hay forma eficiente de guardar la información en los tres idiomas nombrados anteriormente. Por ello, era necesaria la creación de tablas auxiliares con las diferentes traducciones de las descripciones.
Expandiendo la base de datos con las tablas auxiliares, se obtiene el modelo de la figura 4.4.
Figura 4.4: Modelo de fichas técnicas múltiples idiomas
Este modelo permitió obtener correctamente los datos en los idiomas establecidos.
Para poder recorrerlo con facilidad y eficiencia, se pasó el modelo anterior a relacional.
18
4.2. Librería JBE: Datos estáticos de cruceros.
Las tablas resultantes que describen la base de datos son:
Atributo Tipo Primaria/Extranjera
Id_CFT Integer Primaria
SCN_Código Integer Extranjera
Id_Pai Integer Extranjera
SCB_Codigo nVarChar -
CFT_Constructor nVarChar -
CFT_NumeoIMO VarChar -
CFT_AnyoFabricacion Decimal -
CFT_AnyoUltimaRemodelacion Decimal -
CFT_Tonelaje Decimal -
CFT_Eslora Decimal -
CFT_Manga Decimal -
CFT_Calado Decimal -
CFT_Velocidad Decimal -
CFT_CapacidadPasajeros SmallInt -
CFT_Capacidad SmallInt -
CFT_Cubiertas SmallInt -
CFT_Imagenes VarBinary -
CFT_CabinasInterior SmallInt -
CFT_CabinasExterior SmallInt -
CFT_CabinasBalcon SmallInt -
CFT_CapacidadCabinas SmallInt -
Cuadro 4.1: Tabla de las fichas técnicas de los barcos.
La tabla4.1almacena información referente a las fichas técnicas de los barcos — descripciones, imágenes, características técnicas, etc. —.
Atributo Tipo Primaria/Extranjera
Id_ICFT Integer Primaria
Id_CFT Integer Extranjera
Id_Idi Integer Extranjera
ICFT_Nombre nVarChar -
ICFT_Descripcion nVarChar -
Cuadro 4.2: Tabla de descripciones en diferentes idiomas.
La tabla4.2 almacena las descripciones de los cruceros traducidas a distintos idiomas — en este caso español, inglés y portugués— .
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
Atributo Tipo Primaria/Extranjera
Id_CCub Integer Primaria
Id_CFT Integer Extranjera
CCub_Nombre nVarChar -
CCub_Imagenes varBinary - CCub_CodCubierta VarChar -
CCub_FecValidez Date -
Cuadro 4.3: Tabla de los datos referentes a las cubiertas.
La tabla4.3almacena los datos referentes a las cubiertas, ya sea el nombre, las imágenes, el código o la fecha de validez.
Atributo Tipo Primaria/Extranjera
Id_CCCL Integer Primaria
Id_CCub Integer Extranjera
CCCL_Imagenes varBinary -
Cuadro 4.4: Tbl_CruceroCubiertaLeyenda
La tabla4.4almacena las descripciones de las cubiertas en diferentes idiomas.h
Atributo Tipo Primaria/Extranjera
Id_ICCCL Integer Primaria
Id_CCCL Integer Extranjera
ICCCL_Descripcion nVarChar -
Cuadro 4.5: Tbl_IdiNCruceroCubiertaLeyenda
La tabla4.5almacena las descripciones de la leyenda de las cubiertas. Esta leyen- da es utilizada para representar diferentes códigos de colores, así como los tipos de camarotes.
Atributo Tipo Primaria/Extranjera
Id_CCam Integer Primaria
Id_CCub Integer Extranjera
CCam_Nombre nVarChar - CCam_Imagenes varBinary - CCam_Categoria nVarChar -
Cuadro 4.6: Tbl_CruceroCategoria
La tabla4.6almacena los datos referentes a los camarotes del barco — nombre, imágenes, código de categoría —.
20
4.2. Librería JBE: Datos estáticos de cruceros.
Atributo Tipo Primaria/Extranjera
Id_ICC Integer Primaria
Id_CCam Integer Extranjera
CCam_Idi Integer Extranjera
CCam_Descripcion nVarChar -
Cuadro 4.7: Tbl_IdiNCruceroCategoria
La tabla4.7contiene las descripciones de los camarotes en diferentes idiomas.
Tras el paso a relacional y la obtención de las tablas, el próximo paso era rellenarlas con los datos adecuados haciendo uso de las diferentes fuentes de información.
4.2.2 Llenado de la base de datos.
Para la obtención de datos estáticos de cruceros se utilizan dos procesos separados:
para los datos de cruceros, itinerarios y tarifas se utiliza un proceso de llenado a través de tratamiento de ficherosXMLy de peticionesWebService(WS) y, para los datos de las fichas técnicas, se utiliza un proceso deWeb Scrapping (WebScrapping). La figura4.5 muestra una visión general.
Figura 4.5: Diagrama de llenado de la base de datos.
Puesto que los datos que se obtienen de cada proceso tienen finalidades diferentes, estos no se ejecutan con la misma periodicidad. El primero, para tarifas e itinerarios, se ejecuta cuando el sistema tiene menos carga, durante las madrugadas de cada día. El segundo, para las fichas técnicas, puesto que son datos que no cambian con mucha frecuencia, se ejecuta solamente la madrugada del lunes.
Datos estáticos por proceso de tratamiento XML/Excel.
El proceso, para su funcionamiento, necesita que se le pase un fichero Excel oXMLque contenga los datos a tratar — barcos, zonas, categorías, cubiertas, etc.—. Estos ficheros son proporcionados a la empresa por parte de los proveedores de cruceros[11]. A partir del ficheroExcel, gracias a una aplicación propia, se genera un ficheroXML.
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
A partir de los ficheros anteriores, el proceso se ejecuta para cada Naviera (Naviera)
— tipo de producto —. El funcionamiento es el siguiente: a través delXMLobtiene los datos llenando sus diccionarios y guardando la información en base de datos. Para los datos referentes a cruceros, itinerarios y tarifas, se realizan peticiones al proveedor. Una petición para los cruceros y, una para los itinerarios. Después, se procesan y guardan los datos en base de datos, llenando así las tablas existentes. La figura4.6muestra este flujo.
Figura 4.6: Flujo del proceso para obtener los datos de los cruceros a partir de un XML específico.
Datos estáticos de fichas técnicas porWebScrapping.
Con el proceso anterior, se llenan las tablas con datos provenientes del proveedor de cruceros pero, no se obtienen datos de fichas técnicas e imágenes. Para ello, se hace uso de un proceso que, mediante unWebScrapping (WebScrapping), obtiene todos los datos necesarios.La figura4.7refleja el proceso.
• Primero se conecta a una Web de datos de cruceros. En este caso, dependiendo de la ejecución, permite seleccionarla.
• Después para todos los barcos, las cubiertas y categorías de las diferentes navieras se obtienen todos los datos técnicos, descripciones e imágenes.
• Finalmente, a partir de los datos almacenados en sus propios diccionarios, me- diante una función especial, los inserta en las diferentes tablas de fichas técnicas anteriormente descritas.
Cabe destacar ciertos puntos importantes del funcionamiento delWebScrapping[12].
Primero de todo, no fue posible utilizar todas las funcionalidades de obtención de datos que proporciona la librería utilizada puesto que había secciones de la Web que no permitían un buen tratamiento de los datos. Para ello, se utilizaron funciones existentes pero, en principio, con otro objetivo. Por ejemplo, dada una página que no permitía un escaneo perfecto con el objeto de la librería, se descargaba todo el códigoHTML, sobre el cual, con diferentes tratamientos de cadenas de caracteres, se conseguían los datos necesarios. Esto, pero, complicó mucho el funcionamiento y el mantenimiento del proceso deWebScrapping.
El funcionamiento ideal del proceso es aquel donde, el objeto de la librería obtiene los datos en formato XML y los guarda en su propia memoria. Después, a través del 22
4.2. Librería JBE: Datos estáticos de cruceros.
Figura 4.7: Flujo del proceso deScrappingde los datos de cruceros.
XPATH (XPATH), un método de análisis de documentos XML, se obtienen todos los datos necesarios.
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
4.2.3 Caché de datos estáticos de cruceros.
Una vez que los datos están almacenados en las bases de datos, para poder acce- der a estos de forma rápida y eficiente, se guardan en un sistema de memoria caché especialmente preparado. La figura4.8muestra el diagrama general junto con la imple- mentación de la caché.
Los datos que se almacenan en el sistema de "memoria caché", puesto que son consultados constantemente, están formados por la información de los cruceros, los itinerarios, los barcos, sus cubiertas, categorías y todas las fichas técnicas cargadas en el sistema.
Figura 4.8: Diagrama general con al implementación de la caché.
En primer lugar se expone el por qué de guardar estos datos en caché y no acceder a ellos en demanda. En segundo lugar, se describe la construcción de la memoria caché y su pleno funcionamiento en ejecución. Finalmente, se explican las ventajas y los inconvenientes de su uso en el sistema.
¿Por qué caché y no acceso directo a base de datos?
En el caso del módulo de cruceros es necesaria la existencia de una caché de datos estáticos en el servidor por un simple motivo: cada vez que se necesite acceder a la información de un crucero o barco, se accede a la mayoría de tablas en base de datos.
Este hecho provoca una gran latencia a la hora de obtener las disponibilidades de los cruceros en la presentación al usuario.
Con el desarrollo de este sistema de memoria caché, el acceso a los datos es casi instantáneo, sin tiempos de acceso, lectura o filtrado de base de datos. Este, es posible puesto que los datos almacenados en las bases de datos son modificados por el sistema una vez al día — para el proceso deXML—, o una vez a la semana — para el proceso de WebScrapping—.
24
4.2. Librería JBE: Datos estáticos de cruceros.
Descripción del sistema de caché implementado.
Dado que la cantidad de datos que se almacenan en caché es elevada, se desarrolló expresamente una clase especializada para la gestión de esta. Esta clase, es la encargada de gestionar la carga, acceso y destrucción de los datos almacenados.
En primer lugar se exponen los objetos y, el por qué de la estructura de la memoria caché del sistema.
En el módulo desarrollado, como se ha explicado anteriormente, se accede cons- tantemente a estos datos estáticos, tanto para la presentación de las fichas, como para la generación de datosOnline. Por ello, es necesario que el acceso a los datos sea lo más rápido y eficiente posible. Para el lenguaje utilizado en el desarrollo del sistema, una de las mejores opciones es la utilización de los objetosDictionary[13].
Un diccionario, en el contexto actual, es una colección indexada que, permite encontrar valores reales especificando únicamente claves introducidas por el usuario.
Dado que el objeto está indexado, se pueden crear diferentes estructuras medianamente complejas para la gestión y el almacenamiento de la memoria. Además, el índice y el valor que almacena, pueden ser de cualquier tipo, por ejemplo, un diccionario puede estar indexado por claves de tipoStringy contener objetos de tipoDictionary[14].
El funcionamiento de losdiccionarioses similar al de lasTablas de Hash. Mediante el uso de diferentes claves, guarda valores específicos con un coste de búsquedaO(1) independientemente del número de elementos almacenados.
Pese a sus similitudes, existen ciertas diferencias[15]:
• Entre estas se destaca que losdiccionariosalmacenan datos de cualquier tipo, son genéricosy, lasTablas de Hash nolo son.
• LasTablas de Hashno son fuertemente tipificadas, por esta razón, no se debe especificar claramente el tipo de las claves y de los datos que se almacenarán, en losdiccionariossí.
• Otra diferencia importante es la necesidad de implementar la sincronización del acceso a los datos en caso de tener varios hilos de lectura/escritura.
LasTablas de Hashno sufren problemas de sincronización, puesto que permiten variedad de hilos de lectura y uno de escritura. En cambio, losdiccionarios, si se necesitara acceso concurrente, se debería implementar la gestión de la sección crítica por parte del programador.
Para el módulo actual, solo se implementa sección crítica a la hora de cargar la caché, para así, evitar cargas dobles de caché o redundancia de datos.
Desde el punto de vista de las principales funcionalidades de los diccionarios, se destaca:añadir un elemento(Dictionary.Add(key, value)) yobtener un elemento (Dictionary(key)). Haciendo uso de estas funciones y, de la funcióncontiene (Dic- tionary.ConteinsKey(key)), se genera la estructura de datos necesaria para el funcio- namiento del sistema de memoria caché. La figura4.9muestra una visión de este funcionamiento.
Este sistema caché se levanta solo en el caso de que elusuario lo demande, es decir, no se llenarán los diccionarios a no ser que se obtenga una petición de un dato concreto que deba devolverse. El desarrollo se llevó a cabo de esta forma porque, si no
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
Figura 4.9: Funcionamiento del objeto diccionario.
se ha de hacer ninguna búsqueda de cruceros en la aplicación, no haría falta cargar todos los datos y sobrecargar el servidor.
Tras estudiar qué datos se deberían almacenar en el sistema de caché, se obtuvo el esquema de la figura4.10
Figura 4.10: Estructura general del sistema caché.
Se observa que tras un llenado de los diccionarios, existe una clase encargada de 26
4.2. Librería JBE: Datos estáticos de cruceros.
la gestión completa de los diccionarios. Desde cargar nuevos datos, hasta devolver distintas relaciones entreBarco - Cubierta - Camarote.
Con una visión general del sistema y de su estructura, se procedió a planificar qué métodos serían necesarios para su correcta gestión.
Gestión de los datos almacenados en la caché.
Dado que se implementó una clase de caché única y centralizada, en caso de querer acceder a cualquier propiedad de un crucero, para asegurar al sistema que la caché está cargada, se deberá realizar antes una llamada a un método común del gestor de caché.
Poniendo como ejemplo la obtención de los datos estáticos de un barco en concre- to. Este tiene una clase que lo caracteriza, con sus propiedades y métodos privados.
Suponiendo que el sistema requiera elnombredel barco, la propiedad encargada de devolverlo es de la siguiente forma:
1 Public ReadOnly Property Nombre ( ) As S t r i n g
2 Get
3 I f I s Nothing Me. Datos ("Nombre") Then
4 Me. Obtener ( )
5 End I f
6 Return Me. Datos ("Nombre")
7 End Get
8 End Property
9
Figura 4.11: Obtención de objetos de la caché.
Se observa, tanto en la figura4.11como en el código, el siguiente hecho: antes de devolver un atributo de una clase concreta, siempre se comprueba que este exista en el objeto de datos cargado en caché. Si no existe, haciendo uso de la funciónObtener(), la cual se expondrá posteriormente, se vuelve a cargar la caché y, se devuelve el valor demandado.
Una vez descrita la estructura de las propiedades de las diferentes clases, se especi- fica la obtención de los datos completos mediante una de las funciones propias de la caché — estas se explicarán en la próxima sección—. Dada la situación donde la aplica- ción pida la información completa sobre un barco, se utiliza la funcióngetBoatData().
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
Se verá que esta función no carga la caché, sino que opera sobre los datos cargados en memoria.
Para asegurar que la caché está siempre cargada en memoria al utilizarla, se hace una llamada encadenada. Es decir, primero se llama a la funciónObtener()y, justo después a la función concreta. Las funciones específicas — nombres, descripciones, imágenes, propiedades en general— no necesitan de esta cadena de llamadas ya que cargan la caché por medio de las propiedades.
1 ’ Así primero se obtiene e l objeto de caché y después ,
2 ’ sobre este , se obtiene e l barco concreto .
3 CruiseCache . Obtener ( ) . getBoatInfo ( idBoat )
4
Funciones del sistema de caché.
Dado que el sistema de caché se levanta en demanda del usuario, fue necesario el desarrollo de las diferentes funciones que permitieran la obtención, el almacenamiento y el acceso a los datos en tiempo de ejecución.
• Obtener objeto caché — Obtener()
La primera función que se llama antes de cualquier petición de datos de la caché es la llamadaObtener(). El funcionamiento de esta función es descrito por la figura4.12.
Figura 4.12: Diagrama de flujo de la función Obtener de caché.
Cuando se ejecuta una aplicación web,.NET conserva información sobre la aplicación actual, cada sesión de usuario, solicitudes HTTP, la página solicitada, etc. A grandes rasgos, crea uncontextopara la aplicación actual.
28
4.2. Librería JBE: Datos estáticos de cruceros.
.NETcontiene una serie de clases que permiten encapsular esta información, permite almacenar y obtener cualquier objeto.
En la figura4.12se observa que, la primera acción que realiza es intentar obtener el objeto caché del contexto. Si no existe, se crea levantando los diccionarios a partir de la base de datos y, se almacena en el contexto para su posterior uso. En caso de haberlo encontrado, es decir, en caso de que existiera el objeto caché o, que lo haya tenido que crear, devuelve este objeto completo.
Cabe destacar que, se puede dar la situación en que dos hilos pidan datos a la vez y, el sistema de caché no esté levantado. Para evitar errores de concurrencia y, de dobles cargas de caché, en el caso de que no existiera, el alzamiento se haría dentro de la sección crítica gestionada con un semáforo.
• Creación del objeto caché — New()
Esta función se ejecuta siempre y cuando no exista el objeto caché en el contexto web de la aplicación. El objetivo es muy claro, se lee la información de base de datos y se rellenan los diccionarios que forman el sistema de memoria caché.
La figura4.13muestra el funcionamiento de la carga de los cruceros en su res- pectivo diccionario.
Figura 4.13: Creación del diccionario de barcos en el métodoNew().
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
La figura4.13muestra la creación del objetoDictionary()para los barcos almace- nados en la base de datos. Este proceso es similar para la creación de los demás diccionarios — cruceros, barcos, cubiertas, camarotes, fichas técnicas, etc. —.
Se observa que el primer paso es leer los datos de base de datos y guardarlos, en este caso en unalista de objetos del tipo de la tablacon todos sus atributos.
Después, tras comprobar la existencia del diccionario, cada elemento de la lista obtenida es almacenado, siempre y cuando no esté repetido.
En el caso de que se necesite guardar unDiccionario de Diccionarios, para no repetir claves a la hora de guardar cubiertas y categorías, el proceso anterior se ejecuta en cadena, es decir, primero se comprueba que exista el primer dic- cionario — el de las cubiertas—, y después se repite esta comprobación para el segundo, el de categorías. Si ambos existen, se guardan las categorías en su respectivo objeto y, finalmente, al diccionario de cubiertas, se añaden como valor de la clave de cubierta el diccionario completo de categorías. Esta creación se plasma en la figura4.14, siendoX=CubiertasyY=Categorías.
Figura 4.14: Creación de diccionarios en cadena.
• Obtención de datos de crucero — getCruiseData()
Mediante las fichas técnicas y los datos característicos de los barcos almacenados, se crea una especie demapeoodescripción completadel crucero.
30
4.2. Librería JBE: Datos estáticos de cruceros.
A partir de este punto, se entiendemapeoomappingcomodescripción com- pleta,definición del crucero, etc. Elmapping de Juniper es el que se obtiene de analizar los datos obtenidos del proceso deWebScrapping, y elmappingdel cliente, es el obtenido tras analizar los datos introducidos desde laJuniper Boo- kingEngine.s
Para la obtención de los datos estáticos de un crucero concreto, una vez está montado el sistema de caché, hay que acceder al diccionario que almacena dicha información y devolver su contenido. Por ejemplo, dado un identificador de crucero, se accede al diccionario con este como clave y, se obtiene el objeto crucero completo con todos los datos necesarios.
Cabe destacar que, dado que los datos que se almacenan son propios delmapping deJuniper, en caso de que un cliente quiera tener su propiomappingdel crucero, ésteprevaleceante el básico — por lo que, en caso de que para un crucero, el cliente tenga uno generado, se respeta este y se devuelven sus datos—.
En el caso del crucero, si el cliente no tiene información de este y, puesto que la caché solo almacena datos básicos, sin relaciones, por medio de una función de mapping, estas son generadas — nombre, descripciones, cubiertas del crucero concreto, sus categorías, imágenes, etc.—.
• Obtención de datos del barco — getBoatData()
Para la obtención de datos estáticos de un barco del sistema de caché, es nece- sario un identificador propio. Esta función, dado este identificador, devuelve la ficha técnica correspondiente.
En este caso, se comprueba si el barco estámapeadopor el cliente o no, en ambas situaciones se procede igual que en la función anterior, losmappingdel cliente prevalecen ante los básicos deJuniper.
En el caso de que el cliente no tengamapeadoel barco, hay ciertas peculiaridades que es necesario destacar: esta función monta todos los enlaces de imágenes del barco, así como su descripción y características técnicas — tonelaje, eslora, manga, tripulación, etc.—.
• Obtención de datos de las cubiertas y categorías — getDeckData() — getCategoryData()
Para la obtención de las cubiertas y las categorías el proceso es similar al de los barcos, pero con una pequeña peculiaridad. En el caso de las categorías, si el cliente las tienemapeadas, el sistema de caché obtiene los datos de otra caché alojada en el sistema padre.
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
Puntos fuertes del sistema de caché.
El desarrollo del sistema de memoria caché haciendo uso de los diccionarios propios del lenguaje es de las formas más eficientes de almacenaje de datos. Como se ha especificado anteriormente, el acceso a los datos tiene un tiempo de procesado y consumo muy bajo.
Un punto muy importante es la implementación dediccionarios índicepara un acceso más rápido a los datos. Estos diccionarios, indexados por diferentes claves, permiten acceder de forma directa, sin tener que crear relaciones, a datos concretos.
Por ejemplo, si se tiene un diccionario indexado por el índice de cubierta y otro por el índice del barco, un buen diccionario índice, es este en que su clave está formada por la concatenación del código del barco y del código de la cubierta apuntando al mismo objeto que el diccionario de cubiertas propiamente dicho. La figura4.15muestra este funcionamiento.
Figura 4.15: Diccionarios índice.
El esquema de las tablas de fichas junto a sus índices es el representado en la figura4.16. En esta se observa la estructura que siguen los diferentes diccionarios que forman el sistema de caché. Los diccionariosDIC_CUB, DIC_CUB_BARCO, DIC_CAM y DIC_CRU_CUBse utilizan únicamente como índices.
Puesto que en base de datos se guardan las cubiertas y los camarotes en diferentes tablas, por ejemplo, cuando estas se levantan en caché, forman parte de diccionarios di- ferentes. Para relacionarlos, sin tener que hacer búsquedas en los dos a la vez, mientras se levantan, se rellena también este índice, con una clave formada por la concatenación del crucero, el barco, la cubierta y el código de categoría y, la lista de categorías como valor.
Otro punto relevante en la implementación de esta caché, es lacentralización de toda su funcionalidad en una sola clase de gestión. Así, se facilitan las labores de mantenimiento y mejora.
32
4.3. Librería de WebService.
Figura 4.16: Diagrama de caché de fichas técnicas.
4.3 Librería de WebService.
En esta sección se describe el funcionamiento de la librería deWebServicedel módulo.
Se entra en detalle en las clases que la forman y en el desarrollo de estas. La figura4.18 representa una visión general del módulo hasta este punto.
Conocida la definición deWebService, se procede a describir el utilizado en el módulo de cruceros. La figura4.17muestra el funcionamiento delWebService (WS) para la obtención de los datos de cruceros.
Figura 4.17: Clases delWebService.
Se observa claramente que el WebService está formado por dos clases propiamente dichas. La primera es la delWebServiceJP (WS)que recibe todas las peticiones de los clientes y, la segunda — LibreriaWS —, la que las procesa y prepara las respuestas.
Estas dos partes, llamadasParte públicayParte privadaexisten separadas por un
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
simple motivo, encapsulación. Esta estructura permite mantener, expandir o mejorar las funcionalidades del sistema sin obligar a los usuarios conectados a este a cambiar sus peticiones o su análisis de respuestas. Por ejemplo, dado un cliente del WebService que utilice una llamada para obtener un listado de cruceros, con la estructura de dos partes, se puede cambiar la obtención del listado, por una aparentemente mejor, sin afectarle en nada.
Figura 4.18: Diagrama general junto a la implementación del WebService.
34
4.3. Librería de WebService.
4.3.1 Parte pública.
Esta parte es muy importante ya que es la que recibe y gestiona todas las peticiones de los clientes. También es la encargada de describir el WebService, los protocolos y objetos que necesita.
Concretamente para cruceros, esta clase deWebService (WS)tiene todos los diferen- tes métodos para obtener cualquier dato necesario. Dado que todas las funcionalidades y todo el flujo de datos pasa por este servicio, posee peticiones que devuelven desde los datos más básicos de un crucero hasta la reserva de este.
Dado el flujo mostrado en la sección anterior, al servicio le entra una petición concreta en formatoXML. Este, prepara y obtiene los datos haciendo uso de su propia librería. El siguiente código, muestra un ejemplo de una petición de información de barco realizada al Servicio Web:
1 <CruiseShipRQ Version="1.1" Language="es">
2 <Login Password="pass" Email="user@mydomain.com"/>
3 <CruiseShipRequest>
4 <SearchSegmentsShip>
5 <SearchSegmentShip
6 ShipCode="ZEPT0722"
7 Zone="12345"
8 CruiseCode="ZEPT072205/08/2013PUL"
9 Start="2013-08-01"
10 End="2013-08-10"
11 Duration="LeesThan7Days">
12 <CountryOfResidence>
13 ES
14 <CountryOfResidence>
15 </SearchSegmentShip>
16 </SearchSegmentsShip>
17 </CruiseShipRequest>
18 </CruiseShipRQ>
Si esta petición llega al Servicio Web anterior, se lanza el métodoCruiseShipque, tras preparar el objeto de petición en su librería, la ejecuta y, en caso de obtener datos satisfactoriamente, la devuelve al cliente también en formatoXML.
4. MÓDULO DE RESERVAS DE PRODUCTOS TURÍSTICOS: CRUCEROS
4.3.2 Parte privada.
Esta es la encargada de procesar y preparar los datos que necesite la parte pública del WebService.
El primer paso que realiza esta librería, al obtener una petición de su parte pública, es hacer una serie de comprobaciones sobre la petición. La figura4.19muestra este funcionamiento:
Figura 4.19: Comprobaciones de la librería WebService.
Se observa en el modelo anterior que una vez recibida la petición de datos, la librería hace las siguientes comprobaciones:
• Comprobación del tipo de petición: Puesto que el WebService es común para todas las funcionalidades del módulo, tiene flujos similares para la obtención de los datos. En este caso, se muestra un flujo para los datos estáticos de los cruceros.
36
