Data Collection

Antes de describir el proceso de diseño cabe mencionar la conformación del equipo de desarrollo. El equipo de desarrollo está conformado por 7 grupos, uno por cada socio del proyecto: Universidad de Parma, Universidad de Bath, Universidad Politécnica de Cataluña, Universidad de Costa Rica, Universidad Tecnológica Metropolitana, Instituto Superior Politécnico José Antonio Echeverría, y el Instituto Tecnológico y de Estudios Superiores de Monterrey.

Cada uno de los grupos estuvo conformado por al menos 3 personas, con lo cual en promedio 20 personas conformaron el equipo de desarrollo.

Ya que los diversos grupos pertenecen a diversos países, el equipo de desarrollo y el mismo proceso de desarrollo se volvieron distribuidos, esto quiere decir que cada grupo trabaja de manera independiente y la responsabilidad de coordinación de los grupos recae en el líder del equipo, en este caso, el líder del grupo de la Universidad de Costa Rica fungió como líder del equipo de desarrollo.

A lo largo del ciclo de vida del proyecto se llegó a diversos diseños, cada uno tomando como base el anterior y agregando o modificando características del mismo. Esto podría ser visto como un proceso de desarrollo evolutivo, sin embargo fue la implementación de cada diseño lo que motivó los cambios y reestructuración del mismo. El proceso podría ser visto como un desarrollo basado en prototipos, no obstante, para ninguno de los diseños propuestos se llegó a obtener un prototipo funcional que pudiera ser evaluado y a partir del cual proponer un nuevo diseño. El modelo de desarrollo más similar al utilizado en el proyecto fue el de prueba y error.

En la medida en la que se desarrollaba cada prototipo, el diseño y su evolución no fueron debidamente documentados, por lo que solo se cuenta con algunos diagramas y documentos técnicos.

La figura 6.1 presenta un diagrama en el cual se aprecia la arquitectura originalmente propuesta para el sistema.

Los principales componentes del sistema, presentados en la figura 1, son descritos a continuación:

• Personal Agent (PA). Este agente tiene la tarea de dar al usuario acceso a las

funcionalidades de la aplicación. A través de este agente se generará el perfil del usuario.

• Global Travel Assistant (GTA). Este agente tiene la tarea de coordinar las

búsquedas específicas para proponer al usuario escenarios de turismo y en caso necesario el pago o compra de paquetes, productos y/o servicios.

• International Flight Finder (IF). Como su nombre lo indica, este agente tiene la

tarea de buscar vuelos internacionales en nombre del usuario.

• Weather Finder (WHF). Este agente tiene la tarea de realizar búsquedas tomando

como principal parámetro condiciones de clima.

• Recreation Site Comp (RSC). Este agente tiene la tarea de buscar sitios recreativos

en algún destino turístico especificado.

• Archeological Site Comp (ASC). Este agente tiene la tarea de buscar sitios

arqueológicos en algún destino turístico especificado.

• Accommodation Comp (ACC). Este agente tiene la tarea de buscar alojamientos en

algún destino turístico especificado.

• Food/Beverage Comp (BFC). Este agente tiene la tarea de buscar opciones de

restaurantes en algún destino turístico especificado.

en algún destino turístico especificado.

• Transportation Finder (TRF). Este agente tiene la tarea de buscar medios de

transporte locales en algún destino turístico especificado.

• Forum. Este agente tiene la tarea de coordinar la compra de productos o servicios en

nombre del agente.

• Ranker (RKR). Este agente tiene la tarea de categorizar y calificar las opciones

encontradas por los demás agentes de acuerdo a los criterios establecidos en el perfil del usuario.

• Local Itinerary Planner (LIP). Este agente tiene la tarea planear un itinerario para el

usuario tomando en cuenta las ofertas obtenidas y las características del usuario.

• Tourism Offer Finder (TOF). Este agente tiene la tarea de buscar ofertas turísticas

de interés para el usuario en algún destino turístico especificado.

Personal Agent

Business

Bank Bank

Bank connect broker

Travel Agency LAA LIP IF GTA

TOF = tourism offer finder

GTA = global travel assistant

LIS = local itinerary supervisor

LIP = local itinerary planner

RKR = ranker LIS TOF RKR FRM = forum TRF = transportation finders FRM TRF ACC BFC BFC ACC = food/beverage comp = accommodation comp WHF WHF = weather finder ASC

ASC = archaeological site comp

RSC

RSC = recreation site comp

IF = Int’l flights finder

TO TO TO

RKR

LAA = Launcher assistant

TOF_TOF Business Logic App LAA Business App Travel Agency App VC = venue comp

Figura 6.1. Primera propuesta arquitectural del sistema.

El funcionamiento del sistema de acuerdo a esta primera propuesta arquitectural es bastante simple. El usuario interactúa con el sistema a través del PA, al cual le indica sus preferencias y le solicita la planeación de itinerarios de viaje, así como la compra o reservación de servicios turísticos.

Por su parte, el PA interactúa con el GTA solicitándole itinerarios y ofertas turísticas, con el RKR para clasificar y calificar las ofertas obtenidas de acuerdo a las preferencias del usuario y con el IF para obtener información sobre vuelos internacionales.

El GTA consulta con el LIP para obtener un itinerario, los cuales son conformados por el LIP a partir de las ofertas que los agentes RSC, ASC, BFC, VC, TRF y ACC le proporcionan.

Los agentes RSC, ASC, BFC, VC, TRF y ACC se encargan cada uno de buscar ofertas de servicios específicos como alimentación, hospedaje, transporte, etc.

Como ya se mencionó, este diseño fue evolucionando incorporando nuevos elementos, eliminado elementos innecesarios y simplificando el funcionamiento. Finalmente el diseño final al que se llegó y del cual existe un prototipo implementado es el que se muestra en la figura 6.2.

PA GPA LPA SBA Finder Provider BD XIA

Figura 6.2. Arquitectura final del sistema.

Como se aprecia en la figura 6.2, la arquitectura final es mucho más simplificada que la original, y está basada en el precepto de la descomposición del problema de planeación. Los componentes de esta arquitectura se explican a continuación.

• Personal Agent (PA). Agente de interacción con el usuario, le permite solicitar al

sistema la planeación de un itinerario de acuerdo a sus preferencias.

• Global Planner Agent (GPA). Este agente se encarga de generar la estructura de los

itinerarios y de realizar la planeación global dividiendo el itinerario global en itinerarios locales.

• Local Planner Agent (LPA). Este tipo de agente se encarga de planear itinerarios

para un país en específico.

• Broker Agent (SBA). Este agente sirve como intermediario entre el LPA y los Finder y Provider.

• Finder. Este agente está encargado de buscar ofertas turísticas en un lugar

específico, por ejemplo una ciudad. Hay tres categorías de este tipo de agente:

Accommodation Finder (buscador de alojamientos), Transport Finder (buscador de

transportes) y Activity Finder (buscador de actividades turísticas).

• Provider. Este tipo de agente se encarga de representar al proveedor de un servicio

igual que con el agente Finder, hay tres categorías de agentes Provider: AccommodationProvider, Activity Provider y Tranport Provider.

• Interface Agent (XIA). Este agente tiene la función de permitir al usuario la

búsqueda, selección y reservación de ofertas turísticas.

Esta arquitectura permite dos modos de operación: la búsqueda, selección y reservación de ofertas turísticas una a una y en paquetes o itinerarios creados dinámicamente de acuerdo a las preferencias del usuario.

El primer modo de operación es muy simple, el usuario o cualquier otra entidad solicita al Finder, a través del XIA, una lista de ofertas que cumplan con ciertos criterios, si los hay, el XIA muestra al usuario los resultados de la búsqueda. El usuario puede seleccionar uno de los resultados y solicitar, a través del XIA, al Provider la reservación del

mismo.

El segundo modo de operación (figura 6.3) es un poco más complicado, inicia cuando el usuario indica sus preferencias al PA, el cual almacena dicha información en el perfil del usuario. El PA solicita al GPA la creación de un itinerario de acuerdo a las preferencias que el usuario indicó. Al recibir el itinerario del GPA, el PA lo presenta al usuario.

El GPA identifica los países que incluirá el itinerario y genera sub-itinerarios para cada uno de ellos y solicita al LPA adecuado el llenado de cada sub-itinerario. Al recibir los sub-itinerarios llenos, el GPA los integra en un itinerario completo y se lo comunica al PA

Cada LPA recibe un sub-itinerario a llenar y con base en las preferencias indicadas establece la estructura del sub-itinerario distribuyendo tiempo y presupuesto entre transportes, alojamientos y actividades. El LPA solicita al SBA ofertas turísticas que satisfagan la estructura establecida y con ellas llena el sub-itinerario, el cual es comunicado al GPA que lo solicitó.

El SBA, al recibir una petición del LPA busca al Finder adecuado y le solicita

ofertas turísticas que cumplan con las preferencias indicadas en la petición del LPA. De los resultados obtenidos del Finder, el SBA elige uno y se lo comunica al LPA.

El agente Finder al recibir una petición del SBA busca en su base de datos de

ofertas, aquellas que cumplan con los criterios solicitados y las comunica al SBA.

Para reservar un itinerario (figura 6.4), el usuario debe solicitar la reservación al PA, el cual la comunica al GPA quien a su vez la comunica a cada LPA necesario. Cada LPA solicita al SBA la reservación de cada oferta del itinerario. El SBA solicita al Provider

PA GPA LPA SBA Finder

1. Indica preferencias y solicita inerario

2. Genera sub-itinerario Y solicita itinerario local

3. Establece estructura, Solicita ofertas. 4. Solicita ofertas. 5. Comunica ofertas. 6. Comunica ofertas. 7. Comunica itinerario local. 5. Comunica itinerartio

Figura 6.3. Modelo de interacciones para el segundo modo de operación del diseño original

PA GPA LPA SBA Provider

1. Solicita reservación de inerario 2. Solicita reservación de itinerario local 3. Solicita reserva de ofertas. 4. Solicita reservación de ofertas. 5. Confirma reserva. 6. Confirma reserva. 7. Confirma reserva. 5. Confirma reserva

Figura 6.4. Modelo de interacciones para reservaciones de itinerarios en el diseño original.

Tanto en funcionamiento como en componentes, el diseño final es una simplificación del diseño original. Esta simplificación es el resultado del proceso de desarrollo a prueba y error. Una vez que se generó el diseño original se comenzó a implementar, sin embargo los errores cometidos durante el proceso llevaron a la interrupción de la implementación y a modificar el diseño. Este proceso de interrupción en la implementación, adecuación del diseño y vuelta a implementar se repitió varias veces durante un periodo de dos años, hasta que finalmente se llegó a un diseño lo suficientemente simplificado como para poder terminar una implementación de referencia sin modificar el diseño.

Cabe mencionar que la simplificación del sistema no es del todo mala, pues en términos generales no se eliminaron funcionalidades del sistema y de hecho se eliminaron del diseño y de su respectiva implementación algunos elementos redundantes.