arquitectura multiagente para el servicio de autobuses de sevilla

Arquitecturas Software y Familias

de Productos Master Oficial en Sistemas Telemáticos e Informáticos

2007/2008

Práctica 3:Arquitectura Multiagente para el Servicio de

Autobuses de Sevilla

Realizado por:José Ignacio Huertas Fernández

([email protected])Jesús Moreno Leon([email protected])

Arquitecturas Software y Familias de Productos Arquitectura Multiagente

Índice de contenido 1 Descripción del dominio.....................................................................................3

1.1 Introducción.................................................................................................3 1.2 Descripción de la empresa de transportes: Tussam....................................3

2 Espacio de interacciones....................................................................................5 2.1 Modelo UML global de la jerarquía de subinteracciones..............................5 2.2 Diagrama UML global de jerarquías desempeño de roles...........................6 2.3 Diagrama UML global de la jerarquía de recursos.......................................7

3 Modelos detallados.............................................................................................8 3.1 Modelo UML del tipo de interacción: Viaje...................................................8 3.2 Modelo UML del tipo de agente: Pasajero..................................................10 3.3 Modelo UML del tipo de recurso: Estadísticas (viaje).................................12

4 Diagrama de secuencia....................................................................................13

2 / 15


1 Descripción del dominio

1.1 Introducción

Los transportes públicos de Sevilla incluyen, además de la empresa TUSSAM que proporciona un servicio de autobuses, un servicio de tranvía y uno de trenes de Cercanías; y pronto contará con el metro.

En esta práctica queremos estudiar un sistema multiagente que pueda ser implantado por la empresa de autobuses de Sevilla TUSSAM de forma que los procesos que se llevan a cabo por los usuarios y trabajadores de la empresa queden registrados, para poder tener estadísticas precisas y exactas que ayuden a los responsables a tomar las mejores decisiones para aumentar la productividad y el grado de satisfacción de los usuarios.

Con el sistema multiagente implantado, los usuarios dispondrían de mucha más información a la hora de decidir el transporte a usar en cada momento, ya que podrían, por ejemplo, comparar el tiempo empleado por cada uno de los transportes a diferentes horas del día. También dispondrían de información en tiempo real del estado de los autobuses, situación, etc.

Los horarios actuales son muy estrictos ya que la frecuencia de autobuses es siempre la misma (un autobús cada x1 minutos entre diario y cada x2 minutos los fines de semana). Probablemente esto se debe a que las empresas no disponen de la suficiente información para tomar mejores decisiones y adaptar los horarios a las necesidades reales de los usuarios. Si todos los procesos (esperar el autobús en una parada – número de personas, tiempo medio-, personas que suben y bajan en cada parada...) fueran recogidos por el sistema, los responsables dispondrían de la suficiente información para mejorar el servicio a los usuarios.

¿Quién no ha sufrido alguna vez una situación como esta?. Jesús: Al salir del instituto a las 15 horas (con mucha, mucha hambre), muchos días no podía subirme al autobús porque ya iba lleno al llegar a mi parada, y tenía que esperar media hora hasta el siguiente.

Los responsables podrían modificar los horarios, flexibilizándolos y adaptándolos a las necesidades. No sólo eso, podrían usar autobuses con diferentes capacidades en función de la demanda esperada, aumentando así la productividad.

1.2 Descripción de la empresa de transportes: Tussam

Tussam es una Sociedad Anónima Municipal, creada el 10 de noviembre de 1975, que gestiona el servicio de transporte urbano colectivo en la ciudad de Sevilla.

Presta servicio a una población superior a 700.000 habitantes, distribuidos sobre una extensión de 142 km2, mediante una red de 38 líneas explotadas directamente y 4 más en régimen de concesión. Transporta anualmente

3 / 15


83.902.242 viajeros y realiza diariamente 8.000 viajes, recorriendo anualmente 14.957.077 Km.

Para disfrutar de los servicios de esta empresa (transporte público) un ciudadanos tiene dos opciones:

Adquirir un bono del servicio de transportes. Ejemplo: bonobús 10 viajes (con o sin transbordo), abono 30 días, bonobús joven, ...

Adquirir un billete (sólo para un trayecto) en el mismo autobús.

Tussam facilita la movilidad de sus clientes mediante:

38 líneas propias con un recorrido cercano a los 300 km. de red. Más de 900 paradas distribuidas por toda la ciudad, de las cuales el 70%

disponen de marquesina. Una flota de más de 370 vehículos, todos ellos provistos de Aire

Acondicionado, en constante renovación para reducir progresivamente su edad media.

Sistemas de control y localización de todos los vehículos en tiempo real. La incorporación de las innovaciones tecnológicas que contribuyan a

mejorar la calidad del servicio y el desarrollo sostenible. La disposición de los servicios necesarios que garanticen el

desplazamiento de la población a los acontecimientos especiales que tengan lugar en Sevilla.

Más de 1500 puntos de venta distribuidos por toda la ciudad para facilitar la adquisición de los títulos de viaje.

Debido a la importancia de disponer de información de la percepción de los clientes como puntos de partida y fuente de información prioritaria para establecer objetivos en la empresa, TUSSAM realiza de forma periódica un estudio de la Satisfacción de sus Clientes, mediante encuestas presenciales.

La valoración de la Satisfacción Global de los Clientes fue de 6.60 puntos en 2006.

Si se realiza un análisis pormenorizado de los distintos parámetros que son medidos en cuanto a Satisfacción del Cliente, se puede destacar los valores obtenidos en algunos de ellos, como Amplitud de tarifas, Horario de funcionamiento o Facilidad de reclamación. Sin embargo, por ejemplo, el parámetro Tiempo de espera adecuado obtiene un pobre resultado. Con la implantación de un sistema multiagente como el que se propone en este trabajo pensamos que los resultados obtenidos habrían sido más positivos, ya que se dispone de la información precisa para tomar las mejores decisiones.

4 / 15


2 Espacio de interacciones

2.1 Modelo UML global de la jerarquía de subinteracciones

Vamos a estudiar una comunidad de Transportes que tiene lugar en el contexto de una comunidad de ciudadanos de una ciudad, en concreto de la ciudad de Sevilla. Esta comunidad de Transportes se compone por los transportes públicos de Sevilla, esto es, el servicio de autobuses, el servicio de trenes de cercanías y el servicio de tranvías (en un futuro, el metro)

Nosotros nos vamos a centrar en el servicio de autobuses TUSSAM. En este contexto, los responsables de la empresa, en colaboración con las asociaciones de usuarios y los representantes del ayuntamiento, deciden implantar un conjunto de líneas. Cada línea representa la ruta que seguirá un autobús y las paradas que realizará en el trayecto. Hemos considerado que cada vez que un autobús sale de la primera parada, realiza todo el trayecto y vuelve al punto de partida, se completa un viaje.

5 / 15


2.2 Diagrama UML global de jerarquías desempeño de roles

Los ciudadanos de nuestra comunidad pueden desempeñar diferentes roles.

Podemos tener ciudadadanos que, tras pagar las tasas estipuladas y rellenar los formularios pertinentes, toman el rol de abonados del servicio de autobuses. Estos abonados pueden tomar el rol de pasajero de un viaje en cualquier momento, siempre que se cumplan las siguientes condiciones:

Que el ciudadano esté intentando coger el autobús en una parada donde se encuentra estacionado el autobús.

Que el autobús no esté completo.

Existen otros ciudadanos que, al no estar abonados, podrán tomar el autobús y tomar el rol de pasajero si, además de las condiciones anteriores, abonan el precio estipulado para ese viaje.

Otros ciudadanos desempeñarán el rol de trabajadores de la empresa TUSSAM. Estos trabajadores tendrán unos horarios consensuados con la empresa que indicarán en qué líneas trabajará y a qué horas. Por lo tanto, estos trabajadores contraen la obligación de desempeñar el rol de conductor en determinados viajes.

6 / 15


2.3 Diagrama UML global de la jerarquía de recursos

Hemos localizado los siguientes recursos:

Flota de autobuses del TUSSAM, que requerirá un mantenimiento, seguimiento, reparación, etc... lo que implicaría más procesos. Estos autobuses tendrán sus atributos (velocidad, estado de conservación-que inicide en la probabilidad de avería-, capacidad máxima...)

El servicio de autobuses mantendrá unas estadísticas que incluirán las estadísticas de cada línea (num viajeros totales, tiempo medio, ...), de cada viaje (num pasajeros, tiempo empleado, ocupación media, ...), las estadísticas de las marquesinas (tiempo medio de espera de los usuarios, número de usuarios en cada parada, ...)

Las líneas tendrán unos horarios, paradas y marquesinas digitales. Estas marquesinas digitales estarán equipadas con algún dispositivo que permita a los ciudadanos que se encuentren esperando el autobús, que se registre este proceso. Además podrán tener paneles informativos, que en tiempo real muestren la situación de los autobuses.

7 / 15


3 Modelos detallados

3.1 Modelo UML del tipo de interacción: Viaje

INICIALIZACIÓN

Un viaje consiste en el trayecto realizado por un autobús desde la primera parada hasta la última en el contexto de una línea determinada. El viaje se crea automáticamente por el middleware, estudiando los horarios de cada línea. Los trabajadores del servicio de autobuses tienen asignados una serie de viajes, contrayendo la obligación de tomar el rol de conductor en dichos viajes. Es necesario contar con un autobús (también asignados por el servicio de autobuses).

ACTIVIDAD

El viaje comienza en la primera parada. Los abonados y los viandantes podrán tomar el autobús (hacer un join para tomar el rol de pasajero) siempre que haya sitio (numéro de pasajeros–capacidad total del autobús > 0) y lo intenten desde una parada asignada al viaje. Cuando un pasajero haya llegado a su destino solicitará al conductor que se detenga en la siguiente parada, para que pueda abandonar el autobús (hacer un leave del rol de pasajero).

FINALIZACIÓN

Al llegar al final del trayecto todos los pasajeros abandonarán el autobús y el atributo de salida hora_llegada tomará el valor apropiado, finalizando así el proceso viaje.

8 / 15


INICIALIZACIÓN

Atributos de Entrada

Hora_inicio Momento en el que comienza el viaje (fijado por los horarios de la línea).

Autobús Recurso que representa al autobús que se usará en el viaje y que pertenece a la flota del servicio de autobuses (cada autobús tendrá diferentes valores para atributos como: capacidad máxima, estado de conservación, ..., que influirán en las estadísticas del viaje).

Reglas de SetUp

Ningún agente está capacitado para iniciar un viaje.

Reglas de inicio

Será el middleware el que automáticamente iniciará cada uno de los viajes fijados en los horarios de cada línea. Para que el viaje pueda ser iniciado se tendrá que cumplir:

Tiene que existir un autobús. Tiene que haber un trabajador del servicio de autobuses disponible.

Siempre existirá, al menos dos autobuses en perfecto estado disponibles para ser utilizados en caso de averia de cualquier otro. Así mismo, existirán al menos dos trabajadores del servicio de autobuses que estarán de guardia para suplir posibles bajas.

ACTIVIDAD

Atributos locales

Num_pasajeros Número de pasajeros que hay en cada momento, montados en el autobús, en el viaje.

Ult_parada Número que identifica la última parada por la que ha pasado el autobús.

Entorno

Estadísticas Recurso que recopila las estadísticas del viaje (paradas realizadas, número de pasajeros que suben y bajan en cada parada, duración de las paradas, duración total del viaje, ...)

Miembros

Pasajero Los agentes que pueden formar parte de la interacción son: Ciudadanos abonados al servicio de autobuses. Ciudadanos no abonados que deben abonar el importe

del ticket.

Conductor Uno de los trabajadores del servicio de autobuses tendrá asignado en su horario la obigación de actuar como conductor de este viaje.

FINALIZACIÓN

Atributos de Salida

Hora_llegada Hora en la que el autobús llega a la última parada del viaje, y por tanto termina su servicio.

Reglas de Close

9 / 15


Podrá ser realizado por el conductor, en caso de avería del autobús.

Reglas de Finish

El middleware se encargará de finalizar esta interacción cuando el viaje haya llegado a la última parada. Si el autobús sufre una avería y no puede continuar, los pasajeros deberán abandonarlo y el conductor finalizará la interacción.

3.2 Modelo UML del tipo de agente: Pasajero

INICIALIZACIÓN

El propósito de un ciudadano que toma el rol de pasajero en un viaje, consiste en llegar a su destino, identificado por una parada del viaje.

ACTIVIDAD

“disfrutar del viaje” ;-)

ABANDONO

Un pasajero puede abandonar el viaje expícitamente siempre que el autobús se encuentre realizando una parada. El conductor realizará una parada cuando algún pasajero lo solicite o bien cuando haya ciudadanos esperando en la marquesina de la parada.

10 / 15


INICIALIZACIÓN


Ninguno

Propósito

Llegar a la parada destino.

Reglas de join

Empowerment Los agentes que pueden realizar esta acción son: Ciudadanos que han tomado el rol de abonados al

servicio de autobuses. Ciudadanos de la comunidad top.

Permission Que el número de pasajeros del viaje sea menor que la capacidad máxima del autobús.

Hacer un join en una parada asignada al viaje. Los no abonados deben pagar el importe del ticket.

Obligation Ningún agente está obligado a tomar el rol de pasajero.

Reglas de play

Ninguna.

ACTIVIDAD

Atributos locales

Ninguno

Capacitaciones

Ninguna

ABANDONO

Atributos de Salida

Ninguno

Reglas de Leave

Al llegar a cualquier parada en la que el autobús haya efectuado parada.

Reglas de abandon

Ninguna

11 / 15


3.3 Modelo UML del tipo de recurso: Estadísticas (viaje)

CREACIÓN

Las estadísticas de un viaje se crean automáticamente en el momento en el que inicia dicho viaje.

ACTIVIDAD

Las estadísticas registran: El tiempo que transcurre entre el inicio y fin del viaje. El número de pasajeros total que ha hecho uso del servicio. El número total de paradas que ha efectuado el autobús durante el recorrido.

Además se registrarán estadísticas en cada parada, almacenando los siguientes datos: Número de parada El número de pasajeros que suben al autobús. El número de pasajeros que bajan del autobús. La duración de la parada.

DESTRUCCIÓN

Las estadísticas de un viaje se destruyen al finalizar el mismo. No obstante, se almacenarán para poder realizar un estudio sobre ellas.

12 / 15


CREACIÓN


Ninguno.

Reglas de create

Ninguna

Reglas de New

El middleware creará automáticamente las estadísticas desde el momento en el que comience el viaje hasta su fin.

ACTIVIDAD

Atributos locales

Estadísticas_Parada Recurso que compila las estadísticas de cada parada.

Tiempo Intervalo de tiempo que transcurre entre el inicio y fin del viaje.

Num_pasajeros Número de pasajeros que hacen uso del viaje.

Paradas_efectuadas Número de paradas efectuadas por el autobús en el viaje (puede ocurrir que el autobús no realice algunas paradas: en el caso de que ningún pasajero desee bajar y no existan ciudadanos esperando en las marquesinas).

Operaciones

Ninguna

DESTRUCCIÓN

Atributos de Salida

Ninguno

Reglas de Destroy

Ninguna

Reglas de Delete

Ninguna

4 Diagrama de secuencia

Los responables del Servicio de autobuses habrán acordado en colaboración con ayuntamiento y las asociaciones de usuarios, las líneas que deben ser puestas en marcha en el contexto de la comunidad de transportes de la ciudad de Sevilla. Además se habrán acordado unos horarios para cada línea y por tanto, el middleware en cada momento dispondrá de la información necesaria para iniciar los viajes oportunos. Cuando el middleware inicia un proceso 'viaje' a una hora, en el contexto de una línea, es seguro que alguno de los trabajadores de TUSSAM tiene en su jornada asignado ese autobús, es decir, que el agente 'trabajador' habrá contraído la obligación de tomar el rol de 'conductor' en ese proceso 'viaje' y, por tanto, hará un join. Además el proceso 'viaje' tiene como entrada un recurso autobús.

13 / 15


Veamos el proceso por el que un ciudadano que dispone de su abono coge el autobús. Lo primero será hacer un join para tomar el rol de Abonado (podrá hacerlo si ha pagado el importe correspondiente). Una vez se halla desplazado hasta una parada el abonado podrá pasar su tarjeta por la marquesina digital para que quede constancia en los registros del tiempo que los usuarios esperan el bus. Además podrá consultar en tiempo real la situación del autobús que espera, el tiempo que falta para que llegue y las opciones de otro tipo de transporte más cercanas (paradas de taxi, tranvía o trenes).

Cuando el autobús llegue a la parada, siempre que haya sitio, el abonado podrá hacer un join para tomar el rol de pasajero y realizar su trayecto.

Cuando llegue a la parada deseada solicitará al conductor que se detenga pulsando el botón de stop y abandonará el bus y su rol de pasajero haciendo un leave.

Un ciudadano que no disponga de abono podrá coger el bus y tomar el rol de pasajero si está situado en una parada de la línea y hay sitio en el bus y, además, si paga el ticket correspondiente.

14 / 15


15 / 15

arquitectura multiagente para el servicio de autobuses de sevilla

Technology